Proposta pedagógica — por validar pela Ologa/ATDI. Este conteúdo é um rascunho preparado pela equipa. A sua disponibilidade na plataforma não significa aprovação nem validação técnica.
Duração prevista: 100 minutos, em sessão presencial.
Como o tempo desta lição está distribuído
- Acolhimento e objectivos: 10 minutos.
- Exposição: 35 minutos.
- Actividade prática: 45 minutos.
- Partilha e síntese: 10 minutos.
Objectivos da lição
- Distinguir registos, métricas e alertas, e indicar para que serve cada um na deteção de um problema.
- Analisar um conjunto de eventos fictícios e produzir uma triagem fundamentada, com classificação de gravidade e hipótese explicativa.
- Redigir as etapas de resposta a um incidente — contenção autorizada, preservação de evidências, recuperação e lições aprendidas — indicando quem decide cada passo.
Explicação
Monitorar um serviço na nuvem assenta em três materiais diferentes, que se confundem com frequência. Os registos, também chamados logs, são o relato do que aconteceu: entradas com data, hora, origem, identidade e acção. As métricas são medidas numéricas ao longo do tempo: percentagem de utilização do processador, número de pedidos por minuto, tempo de resposta, espaço livre em disco, número de erros. Os alertas são regras que vigiam métricas ou registos e avisam alguém quando uma condição se verifica. Os três são complementares: a métrica mostra que algo mudou, o registo explica o que foi, e o alerta garante que alguém fica a saber sem ter de estar a olhar para o ecrã.
Um alerta só é útil se tiver destinatário, gravidade e acção esperada. Um alerta enviado para uma caixa de correio que ninguém lê é pior do que não ter alerta, porque cria a ilusão de vigilância. Convém escrever para cada alerta quem o recebe, em que horário, o que deve fazer nos primeiros quinze minutos e a quem escala se não conseguir resolver. Também convém limitar o número de alertas: quando tudo alerta, ninguém repara em nada — é o efeito de fadiga de alertas, e é uma das causas mais comuns de incidentes que só são notados dias depois. Três a cinco alertas bem escolhidos, com destinatário claro, valem mais do que trinta.
Triagem é a decisão inicial sobre o que se está a passar, feita com informação incompleta. Pergunta-se: que serviço está afectado e quantas pessoas sente o efeito? É degradação de desempenho, indisponibilidade total, ou suspeita de acesso indevido? Há dados pessoais envolvidos? O que mudou nas últimas horas — uma actualização, uma alteração de permissões, uma nova regra de rede? A triagem termina com uma classificação de gravidade e uma hipótese, ambas escritas com a hora. Escrever a hora de cada decisão é o que permite, dias depois, reconstituir o que se passou; a memória das pessoas, em situação de pressão, é pouco fiável.
A contenção é a fase mais delicada, e neste curso trata-se sempre de contenção autorizada. Conter é limitar o dano — suspender uma conta suspeita, revogar uma chave, retirar um serviço de circulação, bloquear uma origem de rede. Cada uma destas acções tem consequências para o serviço público e algumas são, elas próprias, decisões de gestão: quem autoriza tirar de serviço um portal de licenciamento não é quem descobriu o problema. Por isso a lista de acções de contenção deve estar escrita antes do incidente, com o nome de quem pode autorizar cada uma e a alternativa quando essa pessoa não está contactável. E há um cuidado técnico importante: conter não é apagar. Destruir a máquina afectada resolve o sintoma e elimina a prova.
Preservar evidências significa guardar, antes de reparar, aquilo que permite depois perceber o que aconteceu: exportar os registos do período, guardar uma imagem do disco em vez de o reformatar, anotar quem esteve ligado e a que horas, registar as alterações feitas durante a resposta. As evidências devem ser guardadas com acesso restrito, porque contêm frequentemente dados sensíveis, e nunca circulam em grupos de conversa. Aqui vale também a regra de honestidade deste curso: o que não foi verificado escreve-se como hipótese, não como facto.
A recuperação é o regresso ao funcionamento normal, e faz-se por ordem: repor o serviço a partir de uma fonte de confiança, confirmar que o caminho de entrada usado pelo atacante ou pela avaria está fechado, repor as credenciais que possam ter sido expostas e só depois reabrir o acesso. Por fim, as lições aprendidas: uma reunião curta, dias depois, que produz um documento com o que aconteceu, o que funcionou, o que falhou e três a cinco acções com responsável e prazo. Esta reunião não procura culpados — procura causas. Uma cultura que castiga quem reporta produz incidentes silenciosos, que são os mais caros. Neste curso não se praticam técnicas ofensivas nem se executam comandos de ataque: trabalhamos apenas sobre registos fictícios, em análise documental.
Eventos de uma madrugada no portal de Ondela (registos fictícios)
Os eventos seguintes são inventados para este exercício, com formato simplificado. Não provêm de nenhum sistema real.
02:14 — autenticacao: 47 tentativas falhadas na conta «admin.ondela», origem única fora do país. 02:19 — autenticacao: entrada bem sucedida na conta «admin.ondela», mesma origem, sem segundo factor registado.
02:23 — autorizacao: atribuída função de administrador à identidade «svc-relatorios», âmbito toda a subscrição, por «admin.ondela». 02:26 — armazenamento: contentor «candidaturas-exportacao» alterado de privado para leitura pública, por «admin.ondela».
02:31 — rede: nova regra de permissão na sub-rede de dados, porta 5432, origem qualquer, prioridade 110, por «admin.ondela». 02:40 a 03:05 — armazenamento: 1 240 descarregamentos do ficheiro «export-2026-09-12.csv», origens várias.
03:10 — métrica: saída de dados para a internet sobe de 0,4 GB/hora para 11 GB/hora. 03:12 — alerta de orçamento: consumo mensal atinge 80 % do valor definido; notificação enviada para a caixa geral do departamento.
07:45 — atendimento: primeira chamada de um cidadão a dizer que o portal está muito lento. 08:02 — sistemas: técnico inicia sessão e verifica que a máquina do portal tem o processador a 97 %.
Actividade prática
Trabalho em pares, com 45 minutos de trabalho, seguidos de 10 minutos de partilha e síntese em plenário.
Exercício de análise e simulação documental, feito em papel ou em folha de cálculo. Nesta lição não se criam nem se alteram recursos na nuvem e não se declara nenhum laboratório como executado.
Recomenda-se um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem escreve a cada parte do exercício, de modo que ambas trabalhem no teclado.
Esta actividade é exclusivamente de análise de registos fictícios. Não se executa nenhuma técnica ofensiva, não se corre nenhum comando contra nenhum sistema e não se altera nenhum recurso na nuvem.
Parte 1 — leitura. Reconstituam a sequência dos eventos numa linha de tempo, indicando para cada momento o que é facto registado e o que é interpretação vossa. Identifiquem qual foi, na vossa leitura, o primeiro evento verdadeiramente grave e porquê.
Parte 2 — triagem. Classifiquem a gravidade em baixa, média, alta ou crítica, justificando com o efeito sobre as pessoas e sobre os dados. Escrevam uma hipótese explicativa, começada por «hipótese:», e listem três informações que precisariam de obter para a confirmar ou afastar.
Parte 3 — contenção autorizada. Proponham até cinco acções de contenção, por ordem de execução, indicando para cada uma quem autoriza, o efeito esperado no serviço ao cidadão e o risco de a executar. Pelo menos uma acção deve ter consequência visível para o público e exigir decisão de direcção.
Parte 4 — evidências. Indiquem o que guardam antes de reparar, onde guardam, quem tem acesso e durante quanto tempo. Escrevam uma acção que NÃO devem fazer por destruir prova.
Parte 5 — recuperação e lições aprendidas. Ordenem os passos do regresso ao normal e escrevam três acções de melhoria, cada uma com responsável proposto e prazo. Pelo menos uma deve corrigir um problema visível nos registos que não é técnico, mas de organização.
Rubrica de apreciação, sobre 10 pontos: 2 pontos pela linha de tempo com separação entre facto e interpretação; 2 pontos pela gravidade justificada e pela hipótese escrita como hipótese; 2 pontos pelas acções de contenção com autorização identificada e efeito no serviço; 2 pontos pelas evidências preservadas e pela acção destrutiva evitada; 2 pontos pelas lições aprendidas com responsável e prazo. Perde 2 pontos qualquer trabalho que apresente interpretações como factos registados.
Produto esperado: uma ficha de incidente com linha de tempo, triagem, plano de contenção autorizada, plano de preservação de evidências e três acções de melhoria com responsável e prazo.
Síntese em leitura fácil
- Registos contam o que aconteceu. Métricas medem. Alertas avisam alguém.
- Um alerta sem destinatário e sem acção esperada é apenas ruído.
- Triagem: que serviço, quantas pessoas, que dados, o que mudou — sempre com a hora escrita.
- Conter é limitar o dano; algumas acções de contenção têm de ser autorizadas pela direcção.
- Conter não é apagar: destruir a máquina afectada elimina a prova.
- Guardar as evidências antes de reparar, com acesso restrito.
- Recuperar por ordem: repor, fechar o caminho usado, trocar credenciais, reabrir.
- As lições aprendidas procuram causas e não culpados, com responsável e prazo.
Verificação formativa
Estas perguntas não contam para a nota final e não são perguntas do exame final. Servem para a pessoa formanda confirmar o que percebeu.
- Nos registos fictícios, o alerta de orçamento disparou às 03:12. Porque é que isso não foi suficiente para deter o problema?
- A equipa quer apagar imediatamente a máquina virtual afectada para «ficar tudo limpo». Que objecção levanta?
Respostas comentadas da verificação formativa
As respostas abaixo pertencem às perguntas de verificação formativa desta lição. Não são perguntas nem respostas do exame final e não têm qualquer efeito na nota. Tente responder primeiro e só depois compare.
Pergunta 1. Nos registos fictícios, o alerta de orçamento disparou às 03:12. Porque é que isso não foi suficiente para deter o problema?
Resposta: Porque foi enviado para uma caixa geral do departamento, sem destinatário responsável nem acção esperada, e de madrugada ninguém o leu; além disso um alerta de orçamento avisa sobre despesa, não suspende consumo.
Comentário: Este é o ponto de organização escondido no exercício: a melhoria mais eficaz aqui não é técnica, é definir quem recebe o quê e o que faz a seguir.
Pergunta 2. A equipa quer apagar imediatamente a máquina virtual afectada para «ficar tudo limpo». Que objecção levanta?
Resposta: Apagar destrói as evidências e impede perceber o que aconteceu e se o caminho de entrada foi fechado; deve isolar-se a máquina e guardar registos e imagem do disco antes de qualquer reparação.
Comentário: Isolar e preservar primeiro; recuperar depois, a partir de uma fonte de confiança.
Referências consultadas
- Microsoft Learn — Best practices for Azure RBAC — https://learn.microsoft.com/en-us/azure/role-based-access-control/best-practices (consultado em 21 de Setembro de 2026).
- Microsoft Learn — Tutorial: create and manage budgets (alertas de orçamento) — https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-acm-create-budgets (consultado em 21 de Setembro de 2026).