Backdoor no XZ Utils: o caso CVE-2024-3094 e as lições para segurança e gestão de riscos

Em março de 2024, administradoras(es) de sistemas Linux de todo o mundo receberam um alerta que rapidamente se tornou um dos episódios mais comentados da história recente do software livre.

Um código malicioso havia sido introduzido no XZ Utils, um conjunto de ferramentas de compressão utilizado em inúmeras distribuições Linux.

A vulnerabilidade recebeu a identificação:

CVE-2024-3094

e classificação crítica, com pontuação CVSS 10.0 atribuída pela Red Hat. (nvd.nist.gov)

Na época, a Diretoria Geral de Tecnologia da Informação — DGTI/Uerj publicou um alerta direcionado às(aos) administradoras(es) de sistemas Linux da Universidade.

A preocupação era justificável.

O código malicioso tinha sido desenvolvido de forma extremamente sofisticada e poderia, em determinadas configurações, interferir justamente em um dos principais mecanismos utilizados para administração remota de servidores Linux:

o SSH.

O que é o XZ Utils?

O XZ Utils é um conjunto de ferramentas utilizado para compressão e descompressão de dados.

Entre seus componentes está a biblioteca:

liblzma

utilizada por diversos programas no ecossistema Linux.

Isso significa que o problema não precisava ficar restrito ao aplicativo xz.

Uma biblioteca pode ser utilizada indiretamente por outros programas.

É justamente essa característica que tornou o caso tão preocupante.

A vulnerabilidade atingia especificamente os tarballs distribuídos das versões:

XZ Utils 5.6.0

e

XZ Utils 5.6.1. (tukaani.org)

Uma descoberta quase acidental

A história de como o problema foi descoberto é uma das partes mais interessantes.

Andres Freund, desenvolvedor do PostgreSQL e engenheiro da Microsoft, estava investigando um comportamento estranho em instalações Debian.

Algumas conexões SSH estavam consumindo mais CPU do que deveriam e determinadas ferramentas de análise apresentavam erros relacionados à liblzma.

Em vez de simplesmente aceitar aquilo como um pequeno problema de desempenho, Freund continuou investigando.

Em 29 de março de 2024, publicou suas conclusões na lista de segurança oss-security.

Ele havia encontrado algo muito mais grave:

o XZ Utils havia sido deliberadamente adulterado.

Sua mensagem original alertava que partes do código malicioso estavam presentes nos pacotes distribuídos das versões 5.6.0 e 5.6.1 e poderiam comprometer o servidor SSH em determinadas configurações. (openwall.com)

Uma investigação de desempenho havia encontrado uma:

backdoor.

O que é uma backdoor?

Uma backdoor — literalmente, uma “porta dos fundos” — é um mecanismo que permite contornar formas normais de autenticação, controle ou proteção de determinado sistema.

Ela pode ser criada legitimamente para alguma função específica, embora isso gere riscos.

Mas também pode ser introduzida de maneira maliciosa.

No caso do XZ Utils, tratava-se de:

código malicioso inserido deliberadamente no processo de distribuição do software.

O objetivo era interferir em sistemas que atendessem a determinadas condições e potencialmente permitir execução remota de código antes mesmo da autenticação normal do SSH.

O CERT da União Europeia classificou o cenário como possibilidade de execução remota de código pré-autenticação, desde que determinadas condições fossem atendidas e o atacante possuísse a chave correspondente. (cert.europa.eu)

Mas o XZ não é um programa de compressão? O que ele tem a ver com SSH?

Essa foi uma das perguntas mais frequentes na época.

O OpenSSH não precisava utilizar diretamente a biblioteca XZ para que o ataque funcionasse.

Em determinadas distribuições Linux, o serviço sshd utilizava componentes relacionados ao systemd.

Essas dependências acabavam carregando:

libsystemd → liblzma

e, consequentemente, a versão comprometida da biblioteca podia acabar dentro do processo do servidor SSH.

Foi essa cadeia de dependências que criou o caminho utilizado pelo código malicioso. (cert.europa.eu)

Esse detalhe traz uma importante lição:

uma vulnerabilidade em uma biblioteca aparentemente distante pode atingir aplicações muito mais sensíveis por meio das dependências de software.

O ataque não atingia qualquer computador Linux

Nos primeiros momentos do incidente, havia muita incerteza.

Hoje sabemos que o cenário era mais específico.

O código malicioso precisava encontrar determinadas condições de:

• sistema operacional;

• arquitetura;

• processo de compilação;

• distribuição;

• biblioteca;

• configuração do sshd.

Além disso, as versões comprometidas eram muito recentes.

Por isso, o código havia chegado principalmente a versões de desenvolvimento, teste ou atualização contínua de algumas distribuições.

A Red Hat, por exemplo, informou que:

Red Hat Enterprise Linux — RHEL não foi afetado.

O Fedora 40 Beta chegou a possuir versões do XZ 5.6.0, embora a empresa tenha informado que aquela versão não parecia vulnerável à exploração completa e recomendasse a reversão para a série 5.4. (redhat.com)

O Kali Linux informou que usuários que haviam atualizado seus sistemas entre 26 e 29 de março de 2024 poderiam ter recebido o pacote comprometido e deveriam atualizar imediatamente. (kali.org)

Esse alcance limitado foi extremamente importante.

O ataque foi descoberto antes de as versões comprometidas serem incorporadas de maneira ampla às principais distribuições estáveis utilizadas em servidores de produção.

Se tivesse permanecido oculto por mais tempo, o cenário poderia ter sido muito diferente.

O que realmente havia nos arquivos?

Aqui também vale atualizar a informação publicada nos primeiros dias.

Inicialmente, parecia especialmente intrigante que parte do código malicioso não aparecesse claramente no repositório Git.

A estratégia utilizada era bastante sofisticada.

O processo envolvia:

• arquivos aparentemente relacionados a testes;

• dados maliciosos escondidos nesses arquivos;

• scripts ofuscados;

• diferenças entre o repositório e os pacotes de distribuição;

• código executado durante a compilação;

• alteração da liblzma.

O NIST atualmente descreve a vulnerabilidade como um processo no qual o sistema de compilação da liblzma extraía um objeto pré-compilado escondido dentro de um arquivo de testes e o utilizava para modificar funções da biblioteca. (nvd.nist.gov)

Ou seja:

não se tratava simplesmente de alguém acrescentando uma linha chamada:

“backdoor = true”.

O código foi deliberadamente desenvolvido para dificultar sua descoberta.

E quem colocou a backdoor?

No alerta inicial da época, ainda existia dúvida.

Poderia ter ocorrido:

• comprometimento do computador de uma pessoa desenvolvedora;

• invasão de uma conta;

• participação deliberada de alguém ligado ao projeto.

Hoje temos uma compreensão muito mais clara.

A página oficial do XZ Utils afirma que Jia Tan, que atuou como co-mantenedor do projeto entre 2022 e 2024, e o grupo associado a ele introduziram deliberadamente a backdoor nas versões 5.6.0 e 5.6.1. (tukaani.org)

Isso transforma o episódio em algo ainda mais relevante:

um ataque à cadeia de suprimentos de software.

O que é um ataque à cadeia de suprimentos?

Uma organização pode proteger:

• seus servidores;

• suas senhas;

• suas redes;

• seus computadores.

Mas ela também utiliza programas criados por terceiros.

E esses programas dependem de:

bibliotecas;

frameworks;

pacotes;

plugins;

código aberto.

Imagine que o invasor perceba que atacar diretamente milhares de servidores é difícil.

Existe outra possibilidade:

comprometer um componente utilizado por milhares de servidores.

Depois, esperar que as próprias organizações:

baixem;

instalem;

atualizem

o código malicioso.

Esse é o problema da cadeia de suprimentos.

Em vez de atacar cada vítima individualmente, tenta-se comprometer aquilo em que todas elas confiam.

O aspecto humano do ataque talvez seja ainda mais interessante

O caso XZ não começou apenas com código.

A história do projeto mostra um processo de longo prazo de conquista de confiança.

O XZ Utils era mantido durante muitos anos principalmente por um número extremamente pequeno de pessoas.

Jia Tan começou contribuindo com o projeto e gradualmente recebeu maior participação e confiança.

Posteriormente tornou-se co-mantenedor.

Quando as versões comprometidas foram lançadas, a pessoa responsável pelo ataque já ocupava uma posição que lhe permitia interferir diretamente no processo de desenvolvimento e distribuição.

Isso mostra que segurança da informação não depende apenas de:

firewall;

antivírus;

criptografia.

Também depende de:

governança.

Uma pequena biblioteca sustentava uma enorme cadeia

Talvez essa seja uma das maiores lições do episódio.

XZ Utils não era uma empresa gigantesca com centenas de programadoras(es).

Era um projeto de código aberto mantido por pouquíssimas pessoas.

Mesmo assim, seu código estava presente ou poderia ser utilizado indiretamente em:

milhões de sistemas.

Isso cria uma assimetria impressionante.

Um componente pequeno pode se tornar infraestrutura para organizações enormes.

Uma universidade.

Um banco.

Uma empresa de tecnologia.

Um governo.

Todos podem depender de um pequeno projeto mantido por poucas pessoas em seu tempo disponível.

O que a Administração pode aprender com o caso XZ?

À primeira vista, esse parece ser um assunto apenas para profissionais de Tecnologia da Informação.

Não é.

É também um excelente caso de:

• gestão de riscos;

• governança;

• gestão de fornecedores;

• controles internos;

• continuidade;

• gestão do conhecimento;

• cadeia de suprimentos.

1. Conheça suas dependências

Uma organização sabe quais softwares utiliza?

E sabe:

de quais bibliotecas esses softwares dependem?

A quantidade de dependências pode ser enorme.

Por isso, surgiu uma prática chamada:

SBOM — Software Bill of Materials

ou:

Lista de Materiais de Software.

A lógica é semelhante à composição de um produto industrial.

Se ocorre um problema com determinado componente, precisamos conseguir responder:

Onde ele está sendo utilizado?

Sem inventário, a primeira pergunta durante uma vulnerabilidade vira:

“Será que temos isso em algum servidor?”

2. Atualização também é risco

Normalmente ensinamos:

mantenha tudo atualizado.

Continua sendo uma boa recomendação.

Mas o episódio XZ mostra uma nuance.

As versões antigas não estavam contaminadas.

As versões:

5.6.0

e

5.6.1

estavam.

Ou seja, naquele caso específico, quem havia atualizado primeiro poderia estar mais exposto.

Não significa que devemos deixar de atualizar sistemas.

Significa que uma política de atualizações precisa considerar:

• criticidade;

• testes;

• homologação;

• origem dos pacotes;

• canais de distribuição;

• estabilidade da versão.

Em ambientes sensíveis, “instalar imediatamente qualquer nova versão” também pode representar risco.

3. Não dependa apenas da reputação

XZ Utils era um projeto legítimo.

O problema estava dentro do próprio processo de desenvolvimento.

Isso ensina algo importante sobre controles:

confiança não substitui verificação.

Uma pessoa confiável pode ter uma conta comprometida.

Um fornecedor tradicional pode ser atacado.

Uma biblioteca conhecida pode receber código malicioso.

Uma boa estrutura de controle trabalha com a ideia de:

confiança + verificação.

4. Monitore comportamentos estranhos

A backdoor foi descoberta porque alguém observou:

algumas conexões SSH estavam consumindo CPU demais.

Era um detalhe.

Andres Freund poderia simplesmente ter pensado:

“deve ser algum bug”.

Mas investigou.

Segurança também depende da capacidade de perceber:

algo mudou.

Isso vale para TI e para Administração.

Despesas aumentando inesperadamente.

Prazo de atendimento se tornando maior.

Número de reclamações subindo.

Processamento ficando mais lento.

Indicadores anormais podem ser sintomas de problemas muito maiores.

5. Revisão independente importa

Código aberto possui uma vantagem importante:

em princípio, outras pessoas podem examinar o código.

Mas:

código disponível para revisão

não significa automaticamente:

código efetivamente revisado.

Milhares de projetos utilizavam XZ.

Pouquíssimas pessoas provavelmente acompanhavam cada mudança realizada em seu desenvolvimento.

A mesma lógica vale para organizações.

Um procedimento pode ter:

dupla conferência.

Um pagamento pode exigir:

segregação de funções.

Uma análise pode passar por:

revisão independente.

Não porque todas as pessoas sejam suspeitas.

Mas porque controles existem justamente para evitar que um único ponto de falha comprometa todo o sistema.

6. Pessoas sobrecarregadas também são risco organizacional

Projetos críticos mantidos por poucas pessoas criam riscos.

Se apenas uma pessoa conhece determinado sistema:

temos um risco.

Se apenas uma pessoa sabe executar determinado procedimento:

temos um risco.

Se apenas uma pessoa pode revisar determinado código:

temos um risco.

Isso se relaciona diretamente à:

gestão do conhecimento

e à:

continuidade organizacional.

A dependência excessiva de indivíduos cria fragilidade mesmo quando não existe qualquer intenção maliciosa.

7. Segurança também é governança

O episódio XZ mostra que segurança da informação precisa participar das decisões de gestão.

Não basta perguntar:

“Nosso antivírus está atualizado?”

Também é necessário perguntar:

Quais softwares utilizamos?

Quem pode instalá-los?

De onde vêm?

Como atualizamos?

Como identificamos componentes vulneráveis?

Quem acompanha alertas de segurança?

Quem decide quando uma atualização urgente precisa ser aplicada?

Como respondemos se uma biblioteca utilizada em dezenas de servidores for comprometida?

Essas são questões administrativas.

O alerta da DGTI/Uerj estava correto?

Considerando as informações disponíveis na manhã de 30 de março de 2024, o alerta da DGTI cumpriu exatamente aquilo que uma área de Tecnologia da Informação deveria fazer:

avisar rapidamente as(os) administradoras(es) para verificar seus ambientes.

Naquele momento ainda existiam muitas dúvidas sobre:

• abrangência;

• mecanismo;

• autoria;

• distribuições afetadas;

• possíveis consequências.

Por isso, a recomendação de verificar a presença das versões 5.6.0 e 5.6.1 fazia sentido diante da incerteza existente.

Hoje, entretanto, sabemos que o alcance foi mais limitado do que se temia inicialmente e que muitas distribuições estáveis nunca chegaram a oferecer as versões comprometidas.

O caso deixou de ser uma emergência mundial em andamento.

Mas tornou-se um extraordinário:

estudo de caso.

E qual é a situação hoje?

Se um sistema Linux moderno está devidamente mantido e utiliza os repositórios oficiais atualmente disponíveis, não há motivo para instalar deliberadamente versões vulneráveis do XZ Utils 5.6.0 ou 5.6.1.

Essas são versões historicamente comprometidas.

O próprio projeto XZ identifica oficialmente os tarballs 5.6.0 e 5.6.1 como contendo a backdoor e não os distribui como versões seguras. (tukaani.org)

O registro CVE continua existindo porque vulnerabilidades não desaparecem do histórico quando são corrigidas.

Elas permanecem documentadas justamente para:

• auditoria;

• investigação;

• gestão de ativos antigos;

• análise forense;

• inteligência de ameaças.

Em 2026, o NVD continua registrando especificamente as versões 5.6.0 e 5.6.1 como afetadas. (nvd.nist.gov)

O detalhe que mudou uma história

Talvez o aspecto mais fascinante de todo esse episódio seja pensar no que poderia ter acontecido se Andres Freund simplesmente tivesse ignorado aquele pequeno aumento no consumo de CPU.

Uma diferença de desempenho levou a:

uma investigação;

que encontrou:

uma biblioteca modificada;

que revelou:

uma backdoor;

que expôs:

um ataque à cadeia de suprimentos construído durante anos.

E tudo foi identificado antes que as versões comprometidas chegassem amplamente às distribuições Linux estáveis.

Foi um caso no qual:

curiosidade técnica + investigação + compartilhamento rápido da informação

evitaram um problema potencialmente muito maior.

Para guardar

O CVE-2024-3094 não deve ser lembrado apenas como:

“aquele problema do XZ Utils”.

Ele demonstra que uma organização pode possuir excelente segurança interna e continuar vulnerável por meio de seus fornecedores e dependências.

Também demonstra que:

pequenos componentes podem sustentar grandes infraestruturas;

confiança precisa ser acompanhada de controles;

dependências precisam ser conhecidas;

atualizações precisam ser gerenciadas;

conhecimento não deveria ficar concentrado em poucas pessoas;

e comportamentos aparentemente pequenos podem revelar grandes problemas.

Para quem trabalha com Administração, fica uma lição especialmente importante:

gestão de riscos não consiste apenas em imaginar o que pode dar errado dentro da organização. É preciso compreender também de quem — e de quê — a organização depende para continuar funcionando.

---

Matéria original

Este texto foi inspirado no alerta publicado pela Diretoria Geral de Tecnologia da Informação — DGTI/Uerj em março de 2024:

Aos administradores de sistemas Linux

https://www.dgti.uerj.br/aos-administradores-de-sistemas-linux/

Para saber mais

National Vulnerability Database — CVE-2024-3094
Registro oficial da vulnerabilidade no NIST. (nvd.nist.gov)

Divulgação original de Andres Freund — oss-security
Mensagem que apresentou publicamente a descoberta em 29 de março de 2024. (openwall.com)

XZ Utils
Página oficial do projeto com o registro histórico da backdoor. (tukaani.org)

POPs nas Secretarias de Graduação da Uerj: apresentação do projeto no SINTAE UFRJ 2023

Em novembro de 2023 tive a oportunidade de apresentar, no XI Seminário de Integração dos Técnico-Administrativos em Educação da UFRJ — SINTAE UFRJ, o projeto:

“Elaboração de Procedimentos Operacionais Padrão (POPs) nas Secretarias de Graduação da Uerj”.

O SINTAE é um espaço destinado à troca de conhecimentos, experiências profissionais e práticas desenvolvidas por servidoras(es) técnico-administrativas(os) de instituições públicas de ensino superior de diferentes partes do país.

Na edição de 2023, realizada entre 27 de novembro e 1º de dezembro, o evento aconteceu no Centro de Ciências Matemáticas e da Natureza — CCMN, na Cidade Universitária da UFRJ, em formato híbrido. Foram apresentados 137 trabalhos, distribuídos por diferentes grupos temáticos relacionados ao cotidiano das universidades e instituições públicas de ensino. (pessoal.ufrj.br)

O projeto apresentado

O projeto “Elaboração de Procedimentos Operacionais Padrão (POPs) nas Secretarias de Graduação da Uerj” surgiu a partir de uma questão bastante presente no cotidiano administrativo:

como preservar e compartilhar o conhecimento sobre os procedimentos realizados por uma unidade?

Em uma secretaria universitária, existem inúmeras atividades que precisam ser realizadas ao longo do ano:

• atendimento às(aos) estudantes;

• orientações sobre procedimentos acadêmicos;

• abertura e instrução de processos;

• tratamento de documentos;

• acompanhamento de solicitações;

• utilização dos sistemas institucionais;

• comunicação com departamentos e coordenações;

• cumprimento de normas e prazos.

Muitas vezes, parte do conhecimento necessário para executar essas atividades permanece apenas com as pessoas que possuem maior experiência.

Isso pode gerar dificuldades quando:

• uma(um) servidora(or) se afasta;

• ocorre mudança na equipe;

• pessoas trabalham em horários diferentes;

• surgem dúvidas sobre determinada rotina;

• uma nova pessoa chega à unidade;

• o procedimento é realizado apenas algumas vezes ao ano.

A proposta dos Procedimentos Operacionais Padrão — POPs é justamente registrar essas rotinas de maneira organizada.

O que é um POP?

Um Procedimento Operacional Padrão é um documento que descreve como determinada atividade deve ser realizada.

Dependendo do procedimento, pode responder perguntas como:

O que precisa ser feito?

Quem realiza?

Quando deve ser feito?

Quais documentos são necessários?

Qual sistema deve ser utilizado?

Qual é a sequência das atividades?

Que normas precisam ser observadas?

O que fazer quando surgir uma situação diferente da prevista?

Um bom POP não existe para aumentar a quantidade de burocracia.

Sua função é justamente evitar que cada pessoa tenha de descobrir novamente, por tentativa e erro, como realizar uma atividade que a organização já conhece.

O projeto na Uerj

A iniciativa foi coordenada pela equipe técnico-administrativa do Instituto de Geografia da Uerj, que me convidou para participar do trabalho como integrante externo do Instituto de Física Armando Dias Tavares — IFADT/Uerj.

O projeto também integrou as iniciativas submetidas pela Universidade ao Protec 2022, aparecendo nos registros institucionais da Uerj como projeto do Instituto de Geografia. (sgp.uerj.br)

A proposta previa não apenas produzir documentos, mas trabalhar a própria compreensão das equipes sobre a construção dos POPs.

Entre os temas previstos estavam:

• introdução aos Procedimentos Operacionais Padrão;

• vantagens e tipos de POP;

• legislação e normas relacionadas;

• elaboração passo a passo;

• identificação de falhas;

• revisão de procedimentos;

• elaboração dos POPs nas próprias secretarias;

• implementação;

• acompanhamento e atualização.

O resumo apresentado no SINTAE também previa relatórios, avaliações, verificações nas unidades e desenvolvimento de material para apoiar a capacitação permanente das equipes.

Padronizar não significa engessar

Essa é uma questão importante.

Quando falamos em padronização, pode surgir a impressão de que todas as situações precisam receber respostas idênticas ou de que a(o) servidora(or) perde a possibilidade de analisar casos específicos.

Não é esse o objetivo.

Um POP procura registrar:

o procedimento normalmente adotado.

Se surgir uma situação excepcional, ela poderá exigir análise própria.

Além disso, o procedimento escrito não deve ser considerado definitivo.

Se:

• a legislação mudar;

• o sistema for alterado;

• uma etapa deixar de ser necessária;

• surgir uma forma melhor de executar a atividade;

o POP também precisa ser atualizado.

Por isso, tão importante quanto produzir um procedimento é estabelecer uma rotina de revisão.

Minha apresentação no SINTAE UFRJ

A apresentação aconteceu na manhã de 29 de novembro de 2023, no Auditório PANGEA, durante a sessão conjunta:

GT 10 — Gerenciamento e Acompanhamento Acadêmico

e

GT 13 — Integração Acadêmica.

O Caderno de Resumos do SINTAE registra o trabalho como Comunicação Oral — Presencial, representando a Uerj.

Dividir a sessão com trabalhos de outras universidades também tornou a experiência especialmente interessante.

Além de apresentar aquilo que estava sendo construído na Uerj, foi possível conhecer outras iniciativas relacionadas ao acompanhamento acadêmico, emissão de diplomas e certificados, orientação acadêmica e organização das atividades universitárias.

Essa troca é uma das partes mais interessantes de eventos voltados às(aos) servidoras(es) técnico-administrativas(os).

Problemas que inicialmente parecem exclusivos de uma unidade muitas vezes aparecem, com pequenas diferenças, em várias instituições.

E soluções construídas em uma universidade podem inspirar adaptações em outras.

Por que registrar o conhecimento administrativo?

Quando uma pessoa executa determinada atividade durante vários anos, ela acumula conhecimentos que dificilmente aparecem em um manual institucional.

Ela sabe:

• quais documentos precisam ser conferidos;

• onde encontrar determinada informação;

• qual é a sequência mais adequada;

• quais erros aparecem com frequência;

• quem precisa ser consultado;

• quais normas regulam o procedimento.

Se esse conhecimento permanecer apenas na memória, a organização corre o risco de perdê-lo.

A saída de uma única pessoa pode significar a perda de anos de experiência.

Registrar os procedimentos transforma parte desse conhecimento individual em:

conhecimento institucional.

Isso ajuda na continuidade das atividades e também facilita a chegada de novas(os) integrantes à equipe.

POP não deve ser apenas um manual guardado em uma pasta

Outro aprendizado importante é que produzir o documento não basta.

Um POP que ninguém consulta perde grande parte de sua finalidade.

O procedimento precisa ser:

encontrável;

compreensível;

atualizado;

utilizado;

avaliado.

Também é importante ouvir justamente quem executa a atividade.

Muitas vezes, a melhor descrição de determinado processo não está em uma norma ou organograma, mas na experiência de quem lida diariamente com aquela rotina.

Por isso, a construção colaborativa dos procedimentos foi um aspecto importante do projeto.

A experiência no SINTAE

Apresentar esse trabalho no SINTAE foi também uma oportunidade de mostrar que a produção de conhecimento dentro das universidades não acontece apenas nos laboratórios e nas atividades docentes.

As(os) servidoras(es) técnico-administrativas(os) também:

• analisam problemas;

• desenvolvem métodos;

• criam soluções;

• organizam processos;

• produzem conhecimento sobre gestão universitária;

• compartilham experiências que podem ser utilizadas por outras instituições.

O próprio SINTAE foi criado com essa proposta de promover integração e diálogo entre profissionais das instituições públicas de ensino superior e dar visibilidade às experiências desenvolvidas pela categoria.

Participar do evento permitiu não apenas apresentar um projeto, mas colocá-lo em diálogo com outras experiências de gestão acadêmica.

O que ficou dessa experiência

O projeto reforçou para mim uma ideia que continua bastante atual:

organizações precisam cuidar do conhecimento que produzem durante seu funcionamento cotidiano.

Toda vez que ouvimos:

“só fulana sabe fazer isso”

ou

“quando acontecer, pergunta para sicrano”

existe um alerta.

Talvez estejamos diante de um procedimento importante que ainda não foi adequadamente documentado.

O conhecimento das pessoas continua indispensável.

Mas a organização não deveria depender exclusivamente da memória de uma única pessoa para realizar uma atividade necessária ao seu funcionamento.

É justamente nesse ponto que os POPs podem contribuir.

Eles ajudam a transformar:

experiência individual

em

memória institucional.

E foi muito gratificante poder levar essa discussão, construída a partir do cotidiano administrativo da Uerj, para um espaço nacional de compartilhamento entre servidoras(es) técnico-administrativas(os).

Para conhecer o registro da apresentação

O trabalho integra o Caderno de Resumos do XI SINTAE UFRJ 2023, na área de Gerenciamento e Acompanhamento Acadêmico e Integração Acadêmica.

O registro oficial informa:

Trabalho: Elaboração de Procedimentos Operacionais Padrão (POPs) nas Secretarias de Graduação da UERJ
Formato: Comunicação Oral, Presencial
Data: 29 de novembro de 2023
Local: Auditório PANGEA (CCMN/UFRJ)
Instituição: Uerj.

Músicas para curtir: Classic Rock para estudar, trabalhar e se concentrar

Há momentos em que preciso diminuir o barulho ao redor, colocar os fones de ouvido e me concentrar no que estou fazendo.

Nessas horas, uma das minhas escolhas é o Classic Rock.

É uma playlist para acompanhar aqueles períodos de leitura, estudo, escrita ou trabalho em que uma boa música ajuda a criar um ambiente próprio e torna a tarefa um pouco mais agradável.

O rock clássico atravessou gerações e reúne estilos bastante diferentes entre si: há músicas mais tranquilas, outras mais intensas, grandes solos de guitarra, refrões conhecidos e canções que continuam agradáveis mesmo depois de muitas audições.

Para mim, funciona especialmente bem quando quero manter o foco sem abrir mão de ouvir algo de que gosto.

Então, fica a sugestão:

🎧 coloque os fones, escolha uma tarefa e dê o play.

Classic Rock

Se você também costuma ouvir música enquanto estuda ou trabalha, vale experimentar e montar sua própria seleção. Afinal, a melhor trilha sonora para se concentrar é aquela que funciona para você.

E você, o que costuma ouvir quando precisa se concentrar?