Segurança Cibernética Avançada

Duração prevista: 90 minutos, em sessão presencial.

Todos os casos, instituições, endereços, registos e números usados nesta lição são fictícios e servem apenas de exercício.

Como o tempo desta lição está distribuído

• Acolhimento e objectivos: 10 minutos.
• Exposição: 25 minutos.
• Trabalho prático: 40 minutos.
• Partilha e síntese: 15 minutos.

Como trabalhamos na sala: um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem executa a meio do trabalho, de modo que ambas façam. Na partilha apresentam dois grupos, com tempo limitado; os restantes entregam por escrito e recebem comentário do formador. Marcar a lição como concluída é registo de aprendizagem e não é registo de assiduidade.

Objectivos da lição

• Classificar os oito activos da ficha da Direcção de Serviços Digitais de Muteva quanto a confidencialidade, integridade e disponibilidade, numa escala de baixo, médio e alto, justificando cada classificação com uma consequência concreta para o serviço ao cidadão.
• Identificar, no diagrama de dependências fornecido, pelo menos três dependências ocultas que não aparecem no inventário e explicar por que razão a falha de cada uma pára um serviço.
• Calcular o nível de risco de cinco cenários fornecidos multiplicando probabilidade por impacto na escala de 1 a 5 e ordenar os cenários pelo resultado.
• Associar cada uma das seis funções do quadro NIST de segurança cibernética a pelo menos um controlo já existente ou em falta na instituição fictícia.

Explicação

Segurança avançada não começa por ferramentas: começa por saber o que se tem e o que se perde se aquilo falhar. Um curso avançado distingue-se de uma acção de sensibilização exactamente aqui — não ficamos pelo conselho de «usar palavras-passe fortes», passamos a trabalhar com inventário, dependências, risco medido e controlos atribuídos a pessoas com nome.

A tríade clássica continua a ser o esqueleto do raciocínio: confidencialidade (quem pode ver), integridade (o dado está correcto e não foi alterado sem autorização) e disponibilidade (está acessível quando é preciso). O que muda num nível avançado é que estas três propriedades se avaliam por activo e não em geral. Em muitas situações reforçam-se umas às outras — um controlo de acesso bem feito protege confidencialidade e integridade sem custo para a disponibilidade. Noutras situações, e só nessas, é preciso ponderar entre elas: isolar um sistema para conter um ataque protege a confidencialidade e reduz ou interrompe a disponibilidade daquele serviço enquanto durar o isolamento, e pode haver formas parciais de manter o atendimento por outra via; manter um serviço no ar durante uma intrusão preserva o atendimento e pode dificultar ou comprometer a recolha de evidência. Estas ponderações dependem do contexto de cada activo e não são um conflito automático. A decisão é de gestão da instituição, que continua responsável pelo serviço, deve estar escrita antes do incidente, e é isso que se treina.

Inventário de activos é a base de tudo. Sem lista de sistemas, servidores, bases de dados, contas privilegiadas e ligações a terceiros, não é possível corrigir vulnerabilidades (não se sabe onde estão), nem detectar (não se sabe o que é normal), nem recuperar (não se sabe o que restaurar primeiro). Um inventário útil tem, por cada activo: responsável nomeado, onde corre, que dados trata, de que outros activos depende e qual o tempo máximo que o serviço aguenta parado.

Risco, aqui, é uma estimativa e não um número exacto. Usamos risco = probabilidade × impacto, ambos numa escala de 1 a 5, porque é simples, é defensável perante a direcção e chega para ordenar. A escala tem de estar definida por escrito: o que significa impacto 4, quantas pessoas afecta, quantas horas de paragem. Sem essa definição, cada pessoa pontua à sua maneira e a ordenação deixa de significar alguma coisa. Este método não é imposto por nenhuma lei nem por nenhuma norma: é a convenção de trabalho desta formação.

Para organizar o trabalho usamos as seis funções do quadro de segurança cibernética do NIST: Governar, Identificar, Proteger, Detectar, Responder e Recuperar. É um quadro de adesão voluntária, norte-americano na origem e usado internacionalmente como linguagem comum. Não é lei moçambicana, não impõe prazos, não confere certificação e a sua adopção é uma decisão da instituição. A utilidade prática é esta: obriga a verificar se há trabalho em todas as seis funções, incluindo aquelas que a instituição ainda não olhou. No caso fictício desta lição, o trabalho está concentrado em Proteger e quase nada existe em Detectar e Recuperar; se essa distribuição se repete noutras instituições é coisa a apurar em cada levantamento, e não um dado que aqui se afirme.

Caso fictício: Direcção de Serviços Digitais do distrito de Muteva

A Direcção de Serviços Digitais de Muteva (instituição fictícia) atende cerca de 400 pessoas por dia em dois balcões e mantém um portal de marcação de atendimento. Tem seis servidores próprios numa sala técnica, uma ligação à internet de 50 megabits com um único fornecedor, um serviço de correio electrónico contratado a um fornecedor de nuvem e uma aplicação de registo de processos desenvolvida por uma empresa externa em 2021, com contrato de manutenção terminado em Março de 2026.

A equipa de informática tem três pessoas: uma responsável, um administrador de sistemas e um técnico de apoio. Não há inventário escrito. Quando se pergunta quem é responsável pela base de dados de processos, a resposta é «a empresa que fez a aplicação» — e o contrato de manutenção terminou. Note-se que o fim do contrato de manutenção não significa, por si só, que o fornecedor deixe de ter qualquer obrigação: há deveres que podem subsistir conforme o que estiver escrito no contrato e na lei aplicável, como confidencialidade, devolução de dados ou garantias. O que é certo do lado de Muteva é que a responsabilidade pelo serviço e pelos dados dos cidadãos continua a ser da instituição, e que, sem responsável nomeado internamente, ninguém está a tratar daquele activo. O alcance exacto das obrigações do fornecedor é matéria a apreciar pela área jurídica da instituição, com o contrato à frente, e não se decide nesta lição.

Em Julho de 2026 o disco do servidor de ficheiros encheu e o portal de marcação deixou de aceitar pedidos durante dois dias. Ninguém tinha previsto que o portal escrevia os anexos nesse servidor: não estava em lado nenhum. Foi uma dependência oculta, e é o tipo de coisa que o inventário serve para apanhar.

Anexo A — Inventário parcial de activos (dados fictícios)

Ficha de trabalho. As colunas de classificação estão propositadamente vazias: são preenchidas na actividade.

Anexo B — Dependências declaradas e cinco cenários de risco (dados fictícios)

Material de entrada da actividade. Nada aqui corresponde a uma instituição real.

Dependências declaradas pela equipa: o portal (A-01) depende da base de dados (A-02) e do directório (A-05); a base de dados (A-02) depende do servidor SRV-BD e da energia da sala técnica; o correio (A-04) depende da ligação à internet (A-07); as cópias (A-06) dependem de alguém ligar o disco à sexta-feira.

Cenário 1 — Falha do único disco do servidor SRV-BD, sem cópia da semana corrente. Probabilidade estimada 3, impacto estimado 5.

Cenário 2 — Conta do administrador de sistemas comprometida por reutilização de palavra-passe num serviço externo. Probabilidade 4, impacto 5.

Cenário 3 — Corte da ligação à internet durante um dia útil. Probabilidade 4, impacto 3.

Cenário 4 — Vulnerabilidade conhecida na aplicação de processos, sem contrato de manutenção para a corrigir. Probabilidade 3, impacto 4.

Cenário 5 — Disco de cópias de segurança guardado na mesma sala dos servidores, destruído no mesmo incidente que os servidores. Probabilidade 2, impacto 5.

Trabalho prático

Trabalho em grupos de três pessoas, com as fichas dos anexos A e B em papel, com 40 minutos de trabalho, seguidos de 15 minutos de partilha e síntese em plenário.

Exercício em papel. Esta parte é análise documental sobre material fornecido. Não é o laboratório e não pode ser registada como prática executada em ambiente.

Passo 1 (12 minutos). Classifiquem cada um dos oito activos do anexo A quanto a confidencialidade, integridade e disponibilidade, em baixo, médio ou alto. Ao lado de cada classificação alta escrevam, numa frase, a consequência concreta para o cidadão que atende ao balcão.

Passo 2 (10 minutos). Desenhem o mapa de dependências a partir do anexo B e marquem a vermelho pelo menos três dependências que não constam do inventário do anexo A. A dependência do portal em relação ao servidor de ficheiros, referida no caso, é uma delas — encontrem as outras.

Passo 3 (10 minutos). Calculem probabilidade × impacto para os cinco cenários e ordenem-nos do maior para o menor risco. Escrevam o que fariam primeiro se só houvesse dinheiro para tratar dois.

Passo 4 (8 minutos). Associem cada uma das seis funções do quadro NIST — Governar, Identificar, Proteger, Detectar, Responder, Recuperar — a um controlo existente ou em falta nesta instituição. Assinalem as funções onde não conseguem escrever nada: são as lacunas.

Produto esperado: Uma folha por grupo com o inventário classificado, o mapa de dependências com as ligações ocultas marcadas, os cinco cenários ordenados por risco e a grelha das seis funções com lacunas assinaladas.

Como o produto é apreciado

• As classificações altas vêm acompanhadas de consequência concreta, e não de adjectivos como «crítico» sem explicação.
• Foram encontradas pelo menos três dependências ausentes do inventário.
• As contas de risco estão certas e a ordenação corresponde aos valores calculados (cenário 2 com 20, cenário 1 com 15, cenário 3 e cenário 4 com 12, cenário 5 com 10).
• A grelha das seis funções assinala lacunas em vez de as disfarçar; identificar que não há nada em Detectar vale mais do que inventar um controlo.
• O grupo reconhece por escrito que probabilidade e impacto são estimativas da equipa e não medições.

Síntese em leitura fácil

• Primeiro saber o que se tem. Sem lista de sistemas não se protege, não se detecta e não se recupera.
• Cada activo tem um responsável com nome. «A empresa que fez» não é responsável se o contrato acabou.
• Risco é probabilidade vezes impacto. É uma estimativa e serve para ordenar o que se faz primeiro.
• Há dependências que ninguém escreveu. São as que partem o serviço.
• O quadro NIST tem seis funções e serve para ver onde não estamos a fazer nada.

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.

1. A equipa diz que a base de dados de processos é da responsabilidade da empresa que desenvolveu a aplicação, cujo contrato terminou em Março de 2026. Isto resolve a atribuição de responsabilidade? Justifique.
2. O cenário 2 (conta de administrador comprometida) tem risco 20 e o cenário 1 (falha de disco sem cópia) tem risco 15. Significa isto que a falha de disco pode ser ignorada?

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 efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. A equipa diz que a base de dados de processos é da responsabilidade da empresa que desenvolveu a aplicação, cujo contrato terminou em Março de 2026. Isto resolve a atribuição de responsabilidade? Justifique.

Resposta: Não. Sem contrato em vigor não há ninguém obrigado a responder, pelo que na prática o activo está sem responsável. A instituição tem de nomear internamente um responsável e, em paralelo, decidir se renova o contrato ou se assume a manutenção.

Comentário: O erro frequente é confundir quem construiu com quem responde hoje. Responsabilidade é sempre de uma pessoa da instituição, mesmo quando o trabalho técnico está contratado.

Pergunta 2. O cenário 2 (conta de administrador comprometida) tem risco 20 e o cenário 1 (falha de disco sem cópia) tem risco 15. Significa isto que a falha de disco pode ser ignorada?

Resposta: Não. A ordenação diz o que se trata primeiro quando os recursos são limitados, não o que se deixa de tratar. O cenário 1 continua com impacto 5 e exige tratamento logo a seguir.

Comentário: Ordenar risco é decidir sequência, não é apagar linhas. Um risco alto que fica para segundo lugar tem de ficar registado com prazo.

Referências consultadas

• NIST Cybersecurity Framework — quadro voluntário de segurança cibernética — https://www.nist.gov/cyberframework (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Quadro de adesão voluntária organizado em seis funções: Governar, Identificar, Proteger, Detectar, Responder e Recuperar. Serve para organizar o trabalho de segurança e conversar sobre risco com a direcção; não é lei nem certificação.

Estas referências são quadros e guias técnicos internacionais de adesão voluntária. Não são lei moçambicana, não criam prazos nem obrigações legais e não conferem qualquer certificação.

Duração prevista: 90 minutos, em sessão presencial.

Todos os casos, instituições, endereços, registos e números usados nesta lição são fictícios e servem apenas de exercício.

Como o tempo desta lição está distribuído

• Acolhimento e objectivos: 10 minutos.
• Exposição: 25 minutos.
• Trabalho prático: 40 minutos.
• Partilha e síntese: 15 minutos.

Como trabalhamos na sala: um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem executa a meio do trabalho, de modo que ambas façam. Na partilha apresentam dois grupos, com tempo limitado; os restantes entregam por escrito e recebem comentário do formador. Marcar a lição como concluída é registo de aprendizagem e não é registo de assiduidade.

Objectivos da lição

• Distinguir, por escrito e com um exemplo de cada, análise de vulnerabilidades, teste de intrusão e exercício de equipa vermelha, indicando o que cada um produz e o que cada um não prova.
• Priorizar as dez vulnerabilidades da ficha combinando gravidade técnica, exposição do sistema e presença no catálogo de vulnerabilidades exploradas conhecidas da CISA, produzindo uma fila de tratamento justificada.
• Redigir as regras de compromisso de um teste autorizado, com âmbito, alvos, janela temporal, técnicas proibidas, contacto de emergência e critério de paragem imediata.
• Identificar, na minuta fornecida, pelo menos quatro defeitos que tornariam o teste não autorizado ou impossível de documentar.

Explicação

Gestão de vulnerabilidades é um processo contínuo, não uma varredura anual. Tem cinco passos que se repetem: descobrir o que existe (que só funciona se houver inventário), analisar, priorizar, corrigir ou mitigar, e verificar que a correcção ficou feita. O passo que quase sempre falha é o último. Uma vulnerabilidade marcada como «corrigida» sem nova verificação é apenas uma esperança escrita numa folha.

Priorizar é o coração do assunto, porque a lista é sempre maior do que a capacidade da equipa. Três entradas comandam a fila. Primeira, a gravidade técnica, normalmente expressa por uma pontuação de 0 a 10 — é útil, mas descreve a falha em abstracto, não o nosso ambiente. Segunda, a exposição: a mesma falha num servidor publicado na internet e numa máquina de teste isolada não tem o mesmo peso. Terceira, a existência de exploração observada no mundo real; para isso usamos o catálogo de vulnerabilidades exploradas conhecidas mantido pela CISA. Estar nesse catálogo significa que já houve exploração real registada, o que sobe a prioridade. Os prazos de correcção que esse catálogo indica vinculam organismos federais dos Estados Unidos e não instituições moçambicanas: aqui é entrada de decisão, não obrigação legal.

Nem tudo se corrige. Quando não há correcção disponível — por exemplo, aplicação sem contrato de manutenção — mitiga-se: restringir o acesso à rede, colocar atrás de autenticação adicional, desligar a funcionalidade afectada, aumentar a vigilância sobre aquele sistema. A mitigação fica registada com prazo e com o nome de quem a assume, senão torna-se permanente por esquecimento.

Teste de intrusão ético é outra coisa. A análise de vulnerabilidades diz «este serviço parece ter esta falha»; o teste de intrusão tenta demonstrar que a falha é explorável e o que se consegue a partir dela. Três palavras definem a ética aqui: autorização, âmbito e registo. Autorização escrita e prévia da direcção, com identificação das pessoas que executam. Âmbito explícito, com a lista dos alvos permitidos e a indicação clara do que fica de fora. Registo de tudo o que se fez, com data e hora, para que qualquer efeito observado depois possa ser atribuído ou excluído. Sem estes três elementos, a mesma acção técnica deixa de ser teste e passa a ser acesso não autorizado — com as consequências disciplinares e criminais que daí vêm, a apreciar pela área jurídica da instituição e pelas autoridades, nunca pelo técnico.

Um teste de intrusão também não prova o que muita gente julga. Não prova que o sistema é seguro: prova que, naquelas condições, naquele momento e dentro daquele âmbito, encontrou-se ou não se encontrou caminho. Um relatório que conclui «sistema seguro» está mal escrito. O que se escreve é o que foi testado, como, o que se encontrou, com que evidência, e o que ficou por testar.

Caso fictício: pedido de teste na Direcção de Serviços Digitais de Muteva

A direcção de Muteva pede à equipa de informática que «faça um teste de segurança, aproveitando o fim-de-semana, para ver se alguém consegue entrar». O pedido chega por mensagem de telemóvel, sem lista de sistemas e sem indicação de horas.

O administrador de sistemas propõe começar de imediato pelo portal de marcação, que está publicado na internet, e testar também o correio electrónico, que é do fornecedor de nuvem. Propõe ainda experimentar palavras-passe comuns nas contas dos colegas «para mostrar o problema à direcção».

Neste pedido há pelo menos quatro problemas sérios. Testar o serviço do fornecedor de nuvem envolve infra-estrutura de terceiros, que a direcção de Muteva não pode autorizar. Experimentar palavras-passe de contas de colegas sem consentimento e sem âmbito escrito é acesso a contas alheias. Uma mensagem de telemóvel não é autorização documentada. E não há janela temporal nem critério de paragem, pelo que, se o portal cair a meio, ninguém sabe quem manda parar.

Anexo A — Dez vulnerabilidades detectadas na varredura de 14 de Setembro (fictícias)

Os identificadores V-01 a V-10 são internos e fictícios. A coluna «Exploração observada» indica se o caso consta do catálogo de vulnerabilidades exploradas conhecidas.

Anexo B — Minuta de autorização apresentada pela equipa (com defeitos propositados)

Documento fictício. Contém erros deliberados que a actividade pede para encontrar.

«Autorização para teste de segurança. A Direcção autoriza a equipa de informática a realizar testes de segurança aos sistemas da instituição e a outros que se mostrem necessários, durante o mês de Outubro, usando as técnicas que entender adequadas, incluindo testes às contas dos funcionários e aos serviços contratados a fornecedores externos.

Os resultados serão apresentados no final. Em caso de problema, a equipa resolverá internamente. Assinado: a Direcção.»

Trabalho prático

Trabalho em grupos de três pessoas, com os anexos A e B em papel, com 40 minutos de trabalho, seguidos de 15 minutos de partilha e síntese em plenário.

Exercício em papel. Esta parte é análise documental sobre material fornecido. Não é o laboratório e não pode ser registada como prática executada em ambiente.

Passo 1 (15 minutos). Ordenem as dez vulnerabilidades do anexo A numa fila de tratamento. Combinem gravidade, exposição e exploração observada. Escrevam, ao lado de cada uma das três primeiras, a frase que justifica a posição. Atenção a V-09: tem a gravidade mais alta da lista.

Passo 2 (10 minutos). Para V-02, que não tem correcção disponível, escrevam duas mitigações concretas, com responsável e prazo, e digam como se verificaria que a mitigação está mesmo activa.

Passo 3 (15 minutos). Reescrevam a minuta do anexo B em regras de compromisso utilizáveis. Devem constar: alvos permitidos por nome, alvos expressamente excluídos, janela de datas e horas, técnicas proibidas, contacto de emergência com nome e número, critério de paragem imediata, e forma de registo das acções.

Ao reescrever, listem à parte os defeitos da minuta original que corrigiram.

Produto esperado: Uma fila de tratamento justificada, duas mitigações com responsável e prazo para V-02, e uma folha de regras de compromisso completa acompanhada da lista de defeitos corrigidos.

Como o produto é apreciado

• V-09 não está no topo da fila: tem gravidade 9,9 mas está numa máquina isolada, logo a exposição baixa-a.
• V-01 está no topo ou muito perto: está publicada na internet, tem gravidade alta e tem exploração observada.
• As mitigações de V-02 são accionáveis e verificáveis, não são «ter cuidado» nem «avisar os utilizadores».
• As regras de compromisso excluem expressamente os serviços do fornecedor de nuvem e as contas pessoais dos colegas.
• Foram identificados pelo menos quatro defeitos da minuta original, incluindo a autorização aberta a «outros sistemas que se mostrem necessários».
• O grupo escreve que a presença no catálogo da CISA é entrada de priorização e não obrigação legal em Moçambique.

Síntese em leitura fácil

• Descobrir, analisar, priorizar, corrigir, verificar. O passo esquecido é verificar.
• Uma falha muito grave numa máquina isolada é menos urgente do que uma falha média publicada na internet.
• Se já houve exploração real no mundo, a falha sobe na fila.
• O que não se corrige, mitiga-se com prazo e com nome. Mitigação sem prazo torna-se permanente.
• Teste sem autorização escrita, âmbito e registo não é teste: é acesso não autorizado.

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.

1. V-09 tem gravidade 9,9 e exploração observada, mas está numa máquina de teste desligada da rede. Deve encabeçar a fila?
2. A minuta autoriza testes «a outros sistemas que se mostrem necessários». Porque é que esta frase é inaceitável?

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 efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. V-09 tem gravidade 9,9 e exploração observada, mas está numa máquina de teste desligada da rede. Deve encabeçar a fila?

Resposta: Não. A exposição é nula enquanto a máquina estiver isolada, pelo que o risco actual é baixo. Deve ficar registada e ser corrigida antes de a máquina voltar a ser ligada à rede — essa condição tem de ficar escrita.

Comentário: A pontuação de gravidade descreve a falha, não o nosso ambiente. Priorizar só pela pontuação leva a gastar a equipa onde não há risco real.

Pergunta 2. A minuta autoriza testes «a outros sistemas que se mostrem necessários». Porque é que esta frase é inaceitável?

Resposta: Porque transforma o âmbito em algo indefinido e decidido pelo próprio executante. Sem lista fechada de alvos não é possível provar depois que uma acção estava autorizada, nem excluir a equipa quando algo falha noutro sistema.

Comentário: Âmbito aberto protege ninguém e expõe quem executa. O âmbito existe para proteger a instituição e também o técnico.

Referências consultadas

• CISA Known Exploited Vulnerabilities Catalog — vulnerabilidades exploradas conhecidas — https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Catálogo público de vulnerabilidades com exploração observada no mundo real. Usa-se como entrada para priorizar correcções: uma falha que consta do catálogo sobe na fila. Os prazos que o catálogo indica aplicam-se a organismos federais dos Estados Unidos e não a instituições moçambicanas.
• OWASP Web Security Testing Guide — guia de testes de segurança de aplicações web — https://owasp.org/projects/web-security-testing-guide (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Guia aberto que descreve, por categorias, o que testar numa aplicação web e como registar o que se encontra. Dá estrutura ao teste autorizado e ao relatório; é uma referência comunitária, não uma norma obrigatória.

Estas referências são quadros e guias técnicos internacionais de adesão voluntária. Não são lei moçambicana, não criam prazos nem obrigações legais e não conferem qualquer certificação.

Duração prevista: 100 minutos, em sessão presencial.

Todos os casos, instituições, endereços, registos e números usados nesta lição são fictícios e servem apenas de exercício.

Como o tempo desta lição está distribuído

• Acolhimento e objectivos: 10 minutos.
• Exposição: 30 minutos.
• Trabalho prático: 45 minutos.
• Partilha e síntese: 15 minutos.

Como trabalhamos na sala: um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem executa a meio do trabalho, de modo que ambas façam. Na partilha apresentam dois grupos, com tempo limitado; os restantes entregam por escrito e recebem comentário do formador. Marcar a lição como concluída é registo de aprendizagem e não é registo de assiduidade.

Objectivos da lição

• Identificar, na listagem de serviços fornecida, os serviços desnecessários e justificar a desactivação de cada um pelo papel declarado da máquina.
• Escrever regras de filtragem que apliquem negação por omissão e permitam apenas os fluxos necessários entre os três segmentos do diagrama fornecido.
• Executar, em máquina virtual isolada, o endurecimento de um servidor Linux: desactivar serviços, aplicar regras de filtragem e confirmar por verificação observável que o resultado é o esperado.
• Repor a máquina no estado inicial a partir do instantâneo, confirmando que a reversão funcionou.

Explicação

Endurecer um sistema é reduzir a superfície de ataque: menos serviços a ouvir, menos contas com poder, menos caminhos abertos, configurações por omissão substituídas por configurações escolhidas. O princípio de partida é simples de enunciar e difícil de manter: só existe o que é necessário para o papel declarado da máquina, e o papel tem de estar escrito antes de se começar.

Em sistemas operativos, o trabalho de base é sempre o mesmo, com nomes diferentes em Linux e em Windows: remover ou desactivar serviços que não pertencem ao papel; garantir que não há contas partilhadas nem contas de antigos funcionários; separar contas de administração das contas de uso diário; exigir autenticação forte no acesso remoto; ligar o registo de eventos e enviá-lo para fora da máquina; e manter as actualizações em dia. Enviar o registo para fora da máquina é essencial e costuma faltar: quem compromete o servidor apaga os registos locais.

Em redes, a regra estruturante é negação por omissão: tudo o que não está expressamente permitido é bloqueado. O contrário — permitir tudo e ir bloqueando o que incomoda — parece mais prático no primeiro dia e torna-se impossível de auditar no primeiro ano. A segunda regra é a segmentação: os postos de atendimento não precisam de falar directamente com a base de dados; falam com a aplicação, e é a aplicação que fala com a base de dados. Segmentar limita o alcance de quem entra, que é a diferença entre um posto comprometido e a instituição comprometida.

A terceira ideia é a defesa em profundidade. Nenhum controlo isolado é suficiente: filtragem, endurecimento do sistema, autenticação forte, registo e cópias funcionam em camadas, para que a falha de uma não signifique o fim. Quando se avalia uma proposta técnica, pergunta-se sempre: se este controlo falhar, o que é que ainda nos protege?

Uma advertência prática antes do laboratório. Aplicar regras de filtragem numa máquina remota pode cortar o próprio acesso de quem está a configurar. Por isso se trabalha com instantâneo tirado antes, com acesso de consola disponível e com uma ordem de aplicação pensada. É exactamente isto que se treina no laboratório, e é o motivo pelo qual nada disto se experimenta em máquinas de produção.

Caso fictício: o servidor SRV-FIC de Muteva depois da instalação

O servidor de ficheiros SRV-FIC foi instalado com a configuração por omissão e nunca foi revisto. O papel declarado é um só: guardar documentos digitalizados e servi-los à aplicação de processos.

A listagem de serviços a ouvir mostra, no entanto, um servidor web, uma base de dados, um serviço de impressão, acesso remoto por palavra-passe aberto a toda a rede e um serviço de transferência de ficheiros sem cifra. Nenhum destes, excepto a partilha de ficheiros usada pela aplicação, pertence ao papel declarado.

Não é um caso invulgar: a maior parte das instalações por omissão traz mais do que é preciso, e o que não se usa continua a ouvir na rede, continua desactualizado e continua a ser um caminho.

Anexo A — Listagem de serviços a ouvir em SRV-FIC (saída fictícia, formato simplificado)

Saída ilustrativa preparada para a aula. Não foi recolhida de nenhum sistema real; serve de material de entrada.

porta 22/tcp — acesso remoto seguro — a ouvir em 0.0.0.0 — autenticação por palavra-passe activa

porta 21/tcp — transferência de ficheiros sem cifra — a ouvir em 0.0.0.0

porta 80/tcp — servidor web — a ouvir em 0.0.0.0 — página por omissão da instalação

porta 139/tcp e 445/tcp — partilha de ficheiros — a ouvir em 0.0.0.0

porta 631/tcp — serviço de impressão — a ouvir em 0.0.0.0

porta 3306/tcp — base de dados — a ouvir em 0.0.0.0 — sem utilização conhecida

Contas locais com sessão permitida: raiz (acesso remoto directo permitido), admin, tecnico, antigo_estagiario (última utilização há 14 meses), partilha_geral (usada por três pessoas).

Anexo B — Segmentos de rede do laboratório e fluxos necessários (fictícios)

Endereçamento do laboratório, usado nas regras de filtragem.

Segmento A — postos de atendimento: 10.20.1.0/24.

Segmento B — servidores de aplicação: 10.20.2.0/24, onde está a aplicação de processos em 10.20.2.10.

Segmento C — dados: 10.20.3.0/24, onde estão SRV-FIC em 10.20.3.20 e a base de dados em 10.20.3.30.

Fluxos necessários declarados: postos falam com a aplicação em 10.20.2.10 na porta 443; a aplicação fala com SRV-FIC na porta 445 e com a base de dados na porta 5432; a estação de administração 10.20.1.200 acede aos servidores por acesso remoto seguro na porta 22; todas as máquinas enviam registos para o recolector em 10.20.2.50 na porta 514.

Nada mais está declarado como necessário.

Trabalho prático

Trabalho em pares, com os anexos A e B em papel, antes de tocar no ambiente, com 45 minutos de trabalho, seguidos de 15 minutos de partilha e síntese em plenário. Desses 45 minutos, 25 são do exercício em papel e 20 são do laboratório descrito mais abaixo. A explicação e a apreciação do produto decorrem nos blocos de exposição e de partilha, e não dentro deste tempo.

Exercício em papel. Esta parte é análise documental sobre material fornecido. Não é o laboratório e não pode ser registada como prática executada em ambiente.

Passo 1 (10 minutos). Sobre o anexo A, marquem cada serviço como necessário ou desnecessário para o papel declarado de SRV-FIC e escrevam a justificação numa linha. Façam o mesmo para as contas locais, indicando o que fazer a cada uma.

Passo 2 (10 minutos). Escrevam, em linguagem corrente e em forma de tabela, o conjunto de regras de filtragem para os três segmentos do anexo B: origem, destino, porta, decisão. Comecem pela regra final de negação por omissão e construam para cima. Contem quantas regras de permissão são precisas.

Passo 3 (5 minutos). Escrevam a ordem de aplicação das regras numa máquina a que se acede remotamente, de modo a não perder o próprio acesso, e indiquem o que fariam se o perdessem.

Produto esperado: Uma folha por par com a listagem anotada, a tabela de regras de filtragem com negação por omissão e a ordem de aplicação segura.

Como o produto é apreciado

• Todos os serviços fora do papel declarado estão marcados para desactivação, incluindo a base de dados sem utilização conhecida.
• A conta do antigo estagiário é removida e a conta partilhada é substituída por contas nominais; o acesso remoto directo da conta de raiz é desactivado.
• A tabela de regras termina em negação por omissão e permite exactamente os fluxos declarados — cinco regras de permissão são suficientes.
• Os postos não têm regra directa para o segmento de dados.
• A ordem de aplicação prevê o risco de perder o acesso e indica a consola como recurso.

Laboratório em ambiente isolado — Endurecer SRV-FIC numa máquina virtual isolada

Regras do laboratório, sem excepção. Todos os alvos são máquinas virtuais do próprio laboratório, numa rede isolada e sem ligação à rede de produção da instituição. Nunca se usa como alvo um sistema real da instituição, de outra entidade ou de terceiros na internet, mesmo para «experimentar». Qualquer exercício de teste exige autorização escrita prévia da direcção, com âmbito, janela de tempo e pessoas identificadas. Não se descarrega, não se distribui e não se executa software malicioso real: a análise de ameaças é feita sobre indicadores, registos e descrições fornecidos no material. Não se pede conta pessoal nem pagamento de serviços.

Objectivo: Aplicar, num servidor Linux de laboratório, a desactivação de serviços e as regras de filtragem escritas na actividade, confirmar o resultado por verificação observável e repor o estado inicial.

Tempo: 20 minutos, dentro do bloco de trabalho prático desta lição. Os minutos do exercício em papel e os minutos do laboratório somam o tempo desse bloco e não se contam duas vezes.

Recursos e versões, preparados antes da sessão

• Programa de virtualização com suporte de instantâneos (VirtualBox 7.x ou equivalente disponível na instituição), instalado e testado antes da sessão.
• Imagem de máquina virtual «SRV-FIC-LAB» com uma distribuição Linux de longo prazo de suporte, preparada pelo formador com os serviços do anexo A activos e com as contas indicadas.
• Imagem de máquina virtual «EST-ADMIN» com ferramentas de linha de comandos para listar portas abertas e testar ligações.
• Rede virtual interna, sem interface ligada à rede física da sala, com os três segmentos do anexo B configurados.
• Ficha impressa com os comandos equivalentes para a distribuição usada, entregue no início do laboratório.

Dependências ainda por preparar, não entregues com a lição

Enquanto qualquer um dos pontos seguintes estiver por preparar, o laboratório regista-se como pendente. Nenhum destes laboratórios foi ainda executado nem testado em sala pela equipa autora: os tempos e os resultados descritos são previsões a confirmar na primeira execução.

• Programa de virtualização e imagem «SRV-FIC-LAB» não são entregues com o curso: a instituição de acolhimento tem de os preparar, com os serviços do anexo A activos e as contas indicadas. Enquanto faltarem, o laboratório fica pendente.
• A imagem «EST-ADMIN» e a rede virtual com os três segmentos do anexo B também são preparação local, e não material entregue.
• A ficha de comandos equivalentes depende da distribuição de Linux que a instituição escolher; o curso entrega o exercício e os critérios, não a ficha de comandos dessa distribuição.
• Este laboratório ainda não foi executado numa sala com formandos nem testado pela equipa autora: os 20 minutos previstos e os resultados descritos são estimativa a confirmar na primeira execução, e devem ser corrigidos no guião depois dela.

Preparação prévia, a cargo do formador

• Copiar as duas imagens para todos os computadores no dia anterior e arrancar uma vez cada uma para confirmar que abrem.
• Tirar um instantâneo chamado «inicial» em ambas as máquinas, com as máquinas desligadas.
• Confirmar que a rede virtual está marcada como interna e que a máquina não alcança a internet nem a rede da sala: é uma verificação obrigatória antes de começar.
• Deixar aberta a consola da máquina no programa de virtualização, para o caso de o acesso remoto se perder.

Passos

1. Arrancar SRV-FIC-LAB e EST-ADMIN e confirmar, a partir de EST-ADMIN, que as portas do anexo A estão de facto a ouvir. Registar a lista observada na folha de laboratório.
2. Em SRV-FIC-LAB, parar e desactivar os serviços marcados como desnecessários na actividade, um a um, registando o comando usado e o resultado.
3. Remover a conta do antigo estagiário, converter a conta partilhada em contas nominais e desactivar o acesso remoto directo da conta de raiz, deixando a conta de administração nominal com acesso.
4. Aplicar as regras de filtragem locais pela ordem definida no passo 3 da actividade: primeiro permitir explicitamente o acesso remoto da estação de administração, só depois a negação por omissão.
5. A partir de EST-ADMIN, repetir a listagem de portas e tentar as ligações que devem estar bloqueadas e as que devem continuar permitidas. Registar cada resultado.
6. Confirmar que o envio de registos para o recolector continua a funcionar depois das regras aplicadas.

Verificação de sucesso

• A nova listagem a partir de EST-ADMIN mostra apenas as portas 22 e 445 acessíveis em SRV-FIC-LAB; as portas 21, 80, 631 e 3306 deixam de responder.
• A ligação por acesso remoto a partir de 10.20.1.200 continua a funcionar; a partir de um posto do segmento A é recusada.
• A tentativa de entrar directamente com a conta de raiz é recusada, e a conta nominal de administração entra.
• Os registos continuam a chegar ao recolector: há linha nova com a hora da última operação.
• A folha de laboratório fica preenchida com as duas listagens, antes e depois, e assinada pelo par que executou.

Reversão ao estado inicial

• Desligar a máquina e restaurar o instantâneo «inicial» nas duas máquinas virtuais.
• Arrancar de novo SRV-FIC-LAB e confirmar, a partir de EST-ADMIN, que as portas do anexo A voltaram a estar a ouvir: é a prova de que a reversão funcionou.
• Deixar as máquinas desligadas no fim da sessão.

Se o ambiente não estiver disponível: análise offline

A análise offline permite estudar o material e chegar às mesmas conclusões no papel, mas não equivale à execução. Quando se recorre a ela, a lição é registada como análise documental e o laboratório fica pendente, para ser reagendado.

• Trabalhar sobre a listagem impressa do anexo A e escrever, para cada serviço e conta, o comando que seria usado e o efeito esperado.
• Comparar a listagem «antes» fornecida com uma listagem «depois» impressa pelo formador e identificar as diferenças, explicando cada uma.
• Escrever a sequência de verificação que faria a seguir e o que provaria cada teste.
• Registar a lição como análise documental e o laboratório como pendente, a reagendar quando houver ambiente.

Síntese em leitura fácil

• Endurecer é tirar o que não é preciso. Primeiro escreve-se para que serve a máquina.
• Negação por omissão: bloquear tudo e abrir só o que está na lista.
• Os postos não falam com a base de dados. Falam com a aplicação.
• Os registos saem da máquina, senão quem entra apaga-os.
• Antes de mexer, tirar instantâneo. Depois de mexer, verificar. No fim, repor.

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.

1. Porque é que se aplica primeiro a regra que permite o acesso remoto da estação de administração e só depois a negação por omissão?
2. Executar o laboratório com sucesso significa que o servidor real de ficheiros da instituição está protegido?

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 efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. Porque é que se aplica primeiro a regra que permite o acesso remoto da estação de administração e só depois a negação por omissão?

Resposta: Porque a negação por omissão fecha tudo o que não está expressamente permitido, incluindo a ligação que está a ser usada para configurar. Permitindo primeiro o acesso da estação de administração, a sessão sobrevive à aplicação da regra final.

Comentário: Este é o erro que mais vezes deixa um servidor inacessível. Em produção, além da ordem, prepara-se acesso por consola e uma janela de reversão automática.

Pergunta 2. Executar o laboratório com sucesso significa que o servidor real de ficheiros da instituição está protegido?

Resposta: Não. Significa que o par sabe executar o procedimento num ambiente controlado. Aplicar ao servidor real exige inventário actualizado, autorização, janela de manutenção, cópia de segurança verificada e plano de reversão.

Comentário: Distinguir competência demonstrada em laboratório de alteração autorizada em produção é parte do trabalho profissional, não uma formalidade.

Referências consultadas

• NIST Cybersecurity Framework — quadro voluntário de segurança cibernética — https://www.nist.gov/cyberframework (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Quadro de adesão voluntária organizado em seis funções: Governar, Identificar, Proteger, Detectar, Responder e Recuperar. Serve para organizar o trabalho de segurança e conversar sobre risco com a direcção; não é lei nem certificação.

Estas referências são quadros e guias técnicos internacionais de adesão voluntária. Não são lei moçambicana, não criam prazos nem obrigações legais e não conferem qualquer certificação.

Duração prevista: 100 minutos, em sessão presencial.

Todos os casos, instituições, endereços, registos e números usados nesta lição são fictícios e servem apenas de exercício.

Como o tempo desta lição está distribuído

• Acolhimento e objectivos: 10 minutos.
• Exposição: 30 minutos.
• Trabalho prático: 45 minutos.
• Partilha e síntese: 15 minutos.

Como trabalhamos na sala: um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem executa a meio do trabalho, de modo que ambas façam. Na partilha apresentam dois grupos, com tempo limitado; os restantes entregam por escrito e recebem comentário do formador. Marcar a lição como concluída é registo de aprendizagem e não é registo de assiduidade.

Objectivos da lição

• Reatribuir os acessos das doze contas da matriz fornecida segundo privilégio mínimo, separando contas de administração de contas de uso diário e eliminando contas partilhadas.
• Explicar a diferença entre cifra em trânsito, cifra em repouso e resumo criptográfico, indicando qual delas protege contra que ameaça concreta.
• Executar, em ambiente isolado, a substituição de autenticação por palavra-passe por autenticação por chave no acesso remoto e verificar que a palavra-passe deixou de ser aceite.
• Verificar a integridade de um ficheiro comparando resumos criptográficos e explicar o que a coincidência prova e o que não prova.

Explicação

Gestão de identidades e acessos responde a quatro perguntas em cadeia: quem é a pessoa (identificação), como prova que é ela (autenticação), o que pode fazer (autorização) e onde fica escrito o que fez (registo). Falhar a última anula as três primeiras, porque sem registo não se consegue atribuir nada a ninguém.

Privilégio mínimo significa cada pessoa com o acesso estritamente necessário à função, e nada mais. Na prática há três padrões que quebram isto e aparecem em quase todas as instituições: contas partilhadas, que tornam impossível saber quem fez; contas de administração usadas para o trabalho diário, que expõem o poder máximo ao correio electrónico e à navegação; e acumulação de privilégios por mudança de funções, em que a pessoa muda de serviço e leva consigo os acessos antigos. Contra o último, a única defesa que funciona é a revisão periódica de acessos, com data marcada e com o responsável de cada área a confirmar, por escrito, quem continua a precisar de quê.

A autenticação multifactor continua a ser o controlo com melhor relação entre custo e efeito contra credenciais roubadas. Não é infalível: há técnicas de fadiga de aprovações, em que a pessoa aceita um pedido só para parar as notificações, e há interposição em tempo real. Isso não é argumento para não a activar; é argumento para a configurar com cuidado e para continuar a vigiar os acessos.

Na criptografia aplicada, o essencial para quem administra sistemas é saber que problema cada ferramenta resolve. Cifra em trânsito protege os dados enquanto viajam na rede: sem ela, quem observa o tráfego lê o que passa. Cifra em repouso protege os dados guardados em disco: é o que evita que um disco roubado ou descartado seja lido, mas não protege nada contra quem tem sessão iniciada legitimamente no sistema. Resumo criptográfico não protege confidencialidade nenhuma — serve para detectar alteração: se um bit muda, o resumo muda.

Duas advertências importantes. Primeira: palavras-passe não devem ser guardadas nem cifradas nem em texto simples, mas sim através de funções próprias para o efeito, desenhadas para serem lentas e com valor aleatório por utilizador. Segunda: o problema difícil da criptografia não é escolher o algoritmo, é gerir as chaves — onde ficam, quem lhes acede, como se substituem e o que acontece quando se perdem. Uma cópia de segurança cifrada cuja chave se perdeu é uma cópia que não existe.

Caso fictício: o que a matriz de acessos de Muteva revela

A responsável de informática de Muteva pediu a lista de contas com acesso à base de dados de processos. Apareceram doze, para uma equipa de três pessoas.

Entre elas está «partilha_geral», usada por três funcionários do balcão; «admin», usada indistintamente pelos dois técnicos; «consultor_2021», criada para a empresa que desenvolveu a aplicação e nunca desactivada; e a conta pessoal do técnico de apoio, que é simultaneamente a conta com que lê correio electrónico e a conta com poder total na base de dados.

Quando se perguntou quem tinha exportado uma tabela de processos em Agosto, a resposta possível foi: alguém que usava «admin». Não se conseguiu ir mais longe. É este o custo das contas partilhadas — não é teórico, é a impossibilidade de responder.

Anexo A — Matriz de acessos actual (fictícia)

Ficha de trabalho. A coluna «Decisão» é preenchida na actividade.

Trabalho prático

Trabalho em pares, com a matriz do anexo A em papel, com 45 minutos de trabalho, seguidos de 15 minutos de partilha e síntese em plenário. Desses 45 minutos, 25 são do exercício em papel e 20 são do laboratório descrito mais abaixo. A explicação e a apreciação do produto decorrem nos blocos de exposição e de partilha, e não dentro deste tempo.

Exercício em papel. Esta parte é análise documental sobre material fornecido. Não é o laboratório e não pode ser registada como prática executada em ambiente.

Passo 1 (10 minutos). Preencham a coluna «Decisão» para as doze contas. As decisões possíveis são: manter como está; converter em contas nominais; reduzir privilégios, indicando quais; desactivar; ou remover. Cada decisão leva uma justificação de uma linha.

Passo 2 (10 minutos). Para as duas contas de serviço (backup_svc e portal_svc), escrevam que privilégios exactos são necessários ao trabalho de cada uma e como se controlaria o segredo que as autentica.

Passo 3 (5 minutos). Escrevam o procedimento de revisão periódica de acessos: com que frequência, quem confirma, o que acontece a uma conta sem confirmação e onde fica o registo da revisão.

Produto esperado: Matriz preenchida com decisão e justificação por conta, especificação dos privilégios das duas contas de serviço e procedimento de revisão periódica.

Como o produto é apreciado

• As contas partilhadas (admin, partilha_geral, balcao2) são convertidas em nominais, não apenas «reforçadas».
• consultor_2021, estagiario1 e auditor_ext são desactivadas ou removidas, com justificação pelo fim do vínculo.
• A conta j.matola perde o poder total na base de dados ou passa a ter duas contas separadas: uma de uso diário e outra de administração.
• As contas de serviço recebem privilégio mínimo real: backup_svc precisa de leitura, não de escrita; portal_svc não precisa de poder de administração.
• O procedimento de revisão indica frequência, responsável e consequência da não confirmação.

Laboratório em ambiente isolado — Autenticação por chave e verificação de integridade

Regras do laboratório, sem excepção. Todos os alvos são máquinas virtuais do próprio laboratório, numa rede isolada e sem ligação à rede de produção da instituição. Nunca se usa como alvo um sistema real da instituição, de outra entidade ou de terceiros na internet, mesmo para «experimentar». Qualquer exercício de teste exige autorização escrita prévia da direcção, com âmbito, janela de tempo e pessoas identificadas. Não se descarrega, não se distribui e não se executa software malicioso real: a análise de ameaças é feita sobre indicadores, registos e descrições fornecidos no material. Não se pede conta pessoal nem pagamento de serviços.

Objectivo: Substituir a autenticação por palavra-passe por autenticação por chave no acesso remoto de uma máquina de laboratório, confirmar que a palavra-passe deixou de ser aceite e verificar a integridade de um ficheiro por comparação de resumos.

Tempo: 20 minutos, dentro do bloco de trabalho prático desta lição. Os minutos do exercício em papel e os minutos do laboratório somam o tempo desse bloco e não se contam duas vezes.

Recursos e versões, preparados antes da sessão

• As máquinas virtuais «SRV-FIC-LAB» e «EST-ADMIN» da lição anterior, restauradas ao instantâneo «inicial».
• Cliente de acesso remoto seguro e ferramenta de geração de pares de chaves, já incluídos nas imagens.
• Ficheiro de exercício «relatorio-fic.txt» e o seu resumo criptográfico publicado, entregues em papel e copiados para EST-ADMIN pelo formador.
• Segunda cópia do mesmo ficheiro, alterada num único carácter, chamada «relatorio-fic-alterado.txt».

Dependências ainda por preparar, não entregues com a lição

Enquanto qualquer um dos pontos seguintes estiver por preparar, o laboratório regista-se como pendente. Nenhum destes laboratórios foi ainda executado nem testado em sala pela equipa autora: os tempos e os resultados descritos são previsões a confirmar na primeira execução.

• Depende inteiramente das máquinas «SRV-FIC-LAB» e «EST-ADMIN» da lição anterior. Se esse laboratório ficou pendente, este também fica.
• Os ficheiros «relatorio-fic.txt», a versão alterada e os resumos publicados são gerados localmente pelo formador; o curso entrega o procedimento e os critérios, não os ficheiros.
• Este laboratório ainda não foi executado numa sala com formandos nem testado pela equipa autora: os 20 minutos previstos e os resultados descritos são estimativa a confirmar na primeira execução, e devem ser corrigidos no guião depois dela.

Preparação prévia, a cargo do formador

• Restaurar o instantâneo «inicial» nas duas máquinas e tirar novo instantâneo chamado «antes-chaves».
• Colocar os dois ficheiros de exercício em EST-ADMIN e imprimir a folha com o resumo publicado do ficheiro original.
• Confirmar de novo que a rede virtual está isolada.

Passos

1. Em EST-ADMIN, gerar um par de chaves para a conta nominal de administração, protegendo a chave privada com frase-passe.
2. Copiar a chave pública para SRV-FIC-LAB e confirmar que a ligação por chave funciona.
3. Em SRV-FIC-LAB, desactivar a autenticação por palavra-passe no serviço de acesso remoto e recarregar o serviço, mantendo a sessão actual aberta como rede de segurança.
4. A partir de EST-ADMIN, numa nova sessão, tentar entrar com palavra-passe e registar o resultado; entrar em seguida com a chave e registar o resultado.
5. Calcular o resumo criptográfico de «relatorio-fic.txt» e compará-lo, carácter a carácter, com o resumo publicado na folha.
6. Calcular o resumo de «relatorio-fic-alterado.txt» e comparar com o publicado, registando a diferença observada.

Verificação de sucesso

• A tentativa de entrada com palavra-passe é recusada pelo servidor, com mensagem registada na folha de laboratório.
• A entrada com chave é aceite e a sessão abre com a conta nominal.
• O resumo de «relatorio-fic.txt» coincide exactamente com o resumo publicado.
• O resumo de «relatorio-fic-alterado.txt» é completamente diferente, apesar de o ficheiro diferir num só carácter.
• A folha de laboratório regista os quatro resultados e é assinada pelo par.

Reversão ao estado inicial

• Restaurar o instantâneo «antes-chaves» nas duas máquinas.
• Confirmar que a autenticação por palavra-passe voltou a ser aceite, o que prova que a reposição funcionou.
• Apagar as chaves geradas em EST-ADMIN antes de restaurar, se o exercício tiver usado uma pasta partilhada.

Se o ambiente não estiver disponível: análise offline

A análise offline permite estudar o material e chegar às mesmas conclusões no papel, mas não equivale à execução. Quando se recorre a ela, a lição é registada como análise documental e o laboratório fica pendente, para ser reagendado.

• Trabalhar sobre a folha impressa com a configuração do serviço de acesso remoto antes e depois, identificando a linha alterada e explicando o efeito.
• Comparar à vista os dois resumos impressos, do ficheiro original e do alterado, e contar quantos caracteres diferem.
• Escrever o que a coincidência de resumos prova e o que não prova, e como se protegeria a própria lista de resumos publicada.
• Registar a lição como análise documental e o laboratório como pendente, a reagendar.

Síntese em leitura fácil

• Cada pessoa tem a sua conta. Conta partilhada significa que ninguém responde.
• Quem administra tem duas contas: uma para o trabalho do dia, outra para administrar.
• Rever acessos com data marcada. Quem muda de serviço não leva os acessos antigos.
• Cifra em trânsito protege na rede; cifra em repouso protege o disco; resumo detecta alteração.
• A chave perdida transforma a cópia cifrada em cópia inútil. Guardar chaves é o trabalho difícil.

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.

1. O resumo criptográfico de um ficheiro descarregado coincide com o resumo publicado no sítio de onde foi descarregado. O que é que isto prova?
2. A base de dados está cifrada em repouso. A conta j.matola, com poder total, foi comprometida. A cifra em repouso protege os dados?

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 efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. O resumo criptográfico de um ficheiro descarregado coincide com o resumo publicado no sítio de onde foi descarregado. O que é que isto prova?

Resposta: Prova que o ficheiro que está na máquina é idêntico àquele a que corresponde o resumo publicado, ou seja, que não houve alteração nem corrupção na transferência. Não prova que o ficheiro é seguro nem que o sítio é de confiança: se quem publica o ficheiro também publica o resumo, quem controlar o sítio controla os dois.

Comentário: Integridade não é autenticidade nem inocuidade. Para ganhar garantia de origem é preciso assinatura com chave de quem publica, verificada contra uma chave obtida por outro caminho.

Pergunta 2. A base de dados está cifrada em repouso. A conta j.matola, com poder total, foi comprometida. A cifra em repouso protege os dados?

Resposta: Não. A cifra em repouso protege contra acesso ao disco fora do sistema — roubo, descarte, cópia física. Quem entra com uma sessão legítima e com privilégios lê os dados já decifrados pelo próprio sistema.

Comentário: Cada controlo tem uma ameaça-alvo. Contra credencial comprometida vale privilégio mínimo, autenticação multifactor, registo e detecção — não a cifra em repouso.

Referências consultadas

• NIST Cybersecurity Framework — quadro voluntário de segurança cibernética — https://www.nist.gov/cyberframework (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Quadro de adesão voluntária organizado em seis funções: Governar, Identificar, Proteger, Detectar, Responder e Recuperar. Serve para organizar o trabalho de segurança e conversar sobre risco com a direcção; não é lei nem certificação.

Estas referências são quadros e guias técnicos internacionais de adesão voluntária. Não são lei moçambicana, não criam prazos nem obrigações legais e não conferem qualquer certificação.

Duração prevista: 100 minutos, em sessão presencial.

Todos os casos, instituições, endereços, registos e números usados nesta lição são fictícios e servem apenas de exercício.

Como o tempo desta lição está distribuído

• Acolhimento e objectivos: 10 minutos.
• Exposição: 30 minutos.
• Trabalho prático: 45 minutos.
• Partilha e síntese: 15 minutos.

Como trabalhamos na sala: um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem executa a meio do trabalho, de modo que ambas façam. Na partilha apresentam dois grupos, com tempo limitado; os restantes entregam por escrito e recebem comentário do formador. Marcar a lição como concluída é registo de aprendizagem e não é registo de assiduidade.

Objectivos da lição

• Atribuir correctamente, para os três modelos de serviço, quem responde por cada uma das dez camadas da tabela fornecida, distinguindo o que é do fornecedor e o que é da instituição.
• Identificar, nas cinco configurações fictícias fornecidas, as que expõem dados e propor a correcção concreta de cada uma.
• Escrever as cláusulas mínimas de segurança de um contrato de serviço em nuvem: localização dos dados, registos, notificação de incidente, reversibilidade e fim do contrato.
• Explicar por que razão «está na nuvem» não é resposta à pergunta sobre cópias de segurança e indicar o que é preciso verificar.

Explicação

O modelo de responsabilidade partilhada é o ponto de partida: na nuvem, parte da segurança é do fornecedor e parte é da instituição, e a fronteira muda conforme o modelo de serviço. Em infra-estrutura como serviço, o fornecedor responde pelas instalações, pelo equipamento físico e pela camada de virtualização; a instituição responde pelo sistema operativo da máquina virtual, pelas actualizações, pela configuração de rede, pelas identidades e pelos dados. Em plataforma como serviço, o fornecedor sobe também ao sistema operativo e ao ambiente de execução. Em aplicação como serviço, o fornecedor gere quase tudo — mas nunca gere por nós as contas, os privilégios, as partilhas que criamos e os dados que decidimos lá colocar.

Há uma constante nos três modelos: identidades, permissões e dados são sempre da instituição. A maior parte dos incidentes conhecidos em nuvem não vem de falhas do fornecedor, mas de configuração errada do cliente — um depósito de ficheiros deixado com leitura pública, uma chave de acesso colocada dentro do código, uma conta de administração sem segundo factor, uma partilha criada «temporariamente» para qualquer pessoa com o endereço.

Registos merecem atenção especial. Muitos serviços não activam por omissão o registo detalhado de acessos, ou guardam-no por poucos dias. Se ninguém activou e ninguém verificou a retenção, no dia do incidente não há o que analisar. Activar registos, definir por quanto tempo ficam e confirmar que estão mesmo a ser escritos é trabalho da instituição, não do fornecedor.

No contrato, cinco pontos fazem diferença prática: onde ficam fisicamente os dados e quem lhes pode aceder; que registos o fornecedor entrega e em quanto tempo; em quanto tempo e por que via notifica um incidente; como se exportam os dados durante a vigência do contrato, num formato utilizável; e o que acontece no fim — prazo de eliminação e prova de que foi feita. Convém escrever isto antes de contratar, porque depois a margem de negociação é pequena. Estas são boas práticas contratuais e de gestão; não estamos a enunciar obrigações legais nem prazos legais moçambicanos, matéria que cabe à área jurídica da instituição verificar em concreto.

Finalmente, a frase que se ouve com frequência: «está na nuvem, está seguro». Não é uma resposta. A redundância do fornecedor protege contra falha de equipamento dele; não protege contra apagamento por engano, contra alteração maliciosa feita com credenciais válidas, nem contra a perda da própria conta. A pergunta certa é: existe cópia independente, com que frequência, guardada onde, e quando foi a última vez que alguém restaurou e confirmou que o restauro funcionou?

Caso fictício: a migração do correio e do arquivo de Muteva

Muteva contratou correio electrónico em nuvem em 2024 e, em 2026, decidiu colocar o arquivo digitalizado num serviço de armazenamento do mesmo fornecedor, para libertar espaço no servidor de ficheiros.

A migração foi feita por um técnico, num fim-de-semana, com uma conta de administração criada à pressa e sem segundo factor. Para que a aplicação de processos conseguisse ler os documentos, criou-se uma partilha do depósito de arquivo acessível «a qualquer pessoa com o endereço». Funcionou logo à primeira, e ninguém voltou ao assunto.

Três meses depois, a responsável perguntou quem tinha descarregado documentos do arquivo no mês anterior. O registo detalhado de acessos nunca tinha sido activado. A resposta disponível foi: não se sabe.

Anexo A — Camadas e responsabilidade por modelo de serviço

Ficha de trabalho: as três colunas da direita são preenchidas com «fornecedor», «instituição» ou «partilhada».

Anexo B — Cinco configurações do ambiente em nuvem de Muteva (fictícias)

Extractos simplificados, preparados para a aula. Nenhum corresponde a um ambiente real.

Configuração 1 — Depósito «muteva-arquivo»: acesso de leitura concedido a «qualquer pessoa com a ligação»; contém 41 200 documentos digitalizados de processos.

Configuração 2 — Conta «admin-nuvem»: função de administração total; segundo factor desactivado; usada por dois técnicos.

Configuração 3 — Chave de acesso do serviço do portal: escrita directamente no ficheiro de configuração da aplicação, que está guardado no repositório de código partilhado com a empresa externa.

Configuração 4 — Registo detalhado de acessos ao depósito: desactivado. Registo de autenticação: activo, com retenção de 7 dias.

Configuração 5 — Cópias de segurança: «asseguradas pelo fornecedor, com redundância em três centros de dados». Não existe cópia fora da conta do fornecedor; nunca foi feito um restauro de ensaio.

Trabalho prático

Trabalho em grupos de três pessoas, com os anexos A e B em papel, com 45 minutos de trabalho, seguidos de 15 minutos de partilha e síntese em plenário.

Exercício em papel. Esta parte é análise documental sobre material fornecido. Não é o laboratório e não pode ser registada como prática executada em ambiente.

Passo 1 (15 minutos). Preencham a tabela do anexo A com «fornecedor», «instituição» ou «partilhada» nas três colunas. Onde escreverem «partilhada», expliquem numa linha o que cabe a cada lado.

Passo 2 (20 minutos). Para cada uma das cinco configurações do anexo B, digam se expõe dados ou não, qual é o risco em concreto e qual é a correcção. A correcção tem de ser executável: quem faz, o que altera e como se confirma que ficou feito.

Passo 3 (10 minutos). Escrevam as cláusulas mínimas de segurança que Muteva devia ter exigido no contrato, cobrindo localização dos dados, registos entregues, notificação de incidente, exportação durante o contrato e eliminação no fim.

Produto esperado: Tabela de responsabilidades preenchida, cinco fichas de correcção e uma folha com as cláusulas contratuais mínimas.

Como o produto é apreciado

• Nas três colunas, contas, permissões e dados ficam sempre do lado da instituição.
• A configuração 1 é identificada como exposição grave e a correcção substitui a partilha aberta por acesso concedido à identidade da aplicação.
• A configuração 3 é tratada como segredo exposto: além de retirar a chave do código, prevê-se a substituição da chave, porque o que esteve no repositório deve considerar-se comprometido.
• A configuração 5 é identificada como ausência de cópia independente; a redundância do fornecedor não é aceite como resposta.
• As cláusulas contratuais são apresentadas como boas práticas de gestão, sem invocar prazos legais inexistentes.

Síntese em leitura fácil

• Na nuvem, parte da segurança é do fornecedor e parte é nossa. Contas, permissões e dados são sempre nossos.
• A maior parte dos problemas vem de configuração nossa, não de falha do fornecedor.
• Partilha «para qualquer pessoa com a ligação» é partilha pública.
• Chave dentro do código é chave comprometida: retirar e substituir.
• Redundância do fornecedor não é cópia de segurança. Cópia só conta se já foi restaurada e verificada.

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.

1. O fornecedor garante redundância em três centros de dados. A instituição precisa de cópias de segurança próprias?
2. Retirou-se a chave de acesso do ficheiro de configuração guardado no repositório. Está resolvido?

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 efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. O fornecedor garante redundância em três centros de dados. A instituição precisa de cópias de segurança próprias?

Resposta: Sim. A redundância protege contra falha de equipamento do fornecedor, replicando também os apagamentos e as alterações feitas com credenciais válidas. Contra erro humano, acção maliciosa ou perda de acesso à conta é precisa cópia independente, com restauro de ensaio verificado.

Comentário: Replicação e cópia respondem a problemas diferentes. Quando a pergunta for «e se apagarmos por engano?», a redundância não ajuda.

Pergunta 2. Retirou-se a chave de acesso do ficheiro de configuração guardado no repositório. Está resolvido?

Resposta: Não. A chave esteve acessível a quem tinha o repositório e pode ter ficado no histórico. Tem de ser substituída por uma nova, guardada num cofre de segredos, e devem rever-se os registos de utilização da chave antiga.

Comentário: Segredo exposto é segredo queimado. A regra é substituir, não esconder.

Referências consultadas

• NIST Cybersecurity Framework — quadro voluntário de segurança cibernética — https://www.nist.gov/cyberframework (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Quadro de adesão voluntária organizado em seis funções: Governar, Identificar, Proteger, Detectar, Responder e Recuperar. Serve para organizar o trabalho de segurança e conversar sobre risco com a direcção; não é lei nem certificação.
• CISA Known Exploited Vulnerabilities Catalog — vulnerabilidades exploradas conhecidas — https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Catálogo público de vulnerabilidades com exploração observada no mundo real. Usa-se como entrada para priorizar correcções: uma falha que consta do catálogo sobe na fila. Os prazos que o catálogo indica aplicam-se a organismos federais dos Estados Unidos e não a instituições moçambicanas.

Estas referências são quadros e guias técnicos internacionais de adesão voluntária. Não são lei moçambicana, não criam prazos nem obrigações legais e não conferem qualquer certificação.

Duração prevista: 120 minutos, em sessão presencial.

Todos os casos, instituições, endereços, registos e números usados nesta lição são fictícios e servem apenas de exercício.

Como o tempo desta lição está distribuído

• Acolhimento e objectivos: 10 minutos.
• Exposição: 35 minutos.
• Trabalho prático: 60 minutos.
• Partilha e síntese: 15 minutos.

Como trabalhamos na sala: um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem executa a meio do trabalho, de modo que ambas façam. Na partilha apresentam dois grupos, com tempo limitado; os restantes entregam por escrito e recebem comentário do formador. Marcar a lição como concluída é registo de aprendizagem e não é registo de assiduidade.

Objectivos da lição

• Classificar as oito ocorrências da ficha segundo a categoria de falha aplicacional a que pertencem — controlo de acesso, injecção, configuração, autenticação, exposição de dados — justificando cada classificação.
• Escrever, para as duas ocorrências que vão ser testadas, o caso de teste correspondente no formato do guia de testes da OWASP: objectivo, pré-condição, passos, resultado esperado e evidência a recolher.
• Executar, na aplicação vulnerável instalada em máquina virtual isolada, dois testes autorizados de controlo de acesso e registar a evidência observada.
• Redigir um achado de relatório com descrição, impacto, passos de reprodução, evidência e recomendação, sem afirmar que a aplicação é segura.

Explicação

Boa parte das falhas graves que aparecem em aplicações web não é exótica: é controlo de acesso mal feito. O padrão repete-se — a aplicação esconde o botão na interface, mas o pedido continua a funcionar se for feito directamente; ou usa o identificador que vem do cliente para decidir que registo mostrar, sem verificar se aquele utilizador tem direito àquele registo. A regra é: a autorização verifica-se no servidor, a cada pedido, a partir da identidade da sessão e das regras de acesso definidas pela instituição, e nunca a partir de algo que o cliente possa alterar. Atenção a um erro frequente na formulação da regra: ter direito ao registo não é o mesmo que ser o seu titular. Há acessos legitimamente concedidos por perfil ou por âmbito — o funcionário do balcão que trata do processo, a chefia da unidade, a auditoria interna dentro do seu mandato. O que o servidor tem de verificar é se aquela sessão tem, naquele momento, uma permissão aplicável àquele registo; quem pode ver o quê é uma decisão escrita de quem gere o serviço, e não uma regra técnica universal.

A segunda família é a injecção. Acontece quando dados enviados pelo utilizador são misturados com uma instrução — uma consulta à base de dados, um comando do sistema, uma página devolvida ao navegador — e o sistema passa a executar parte dos dados como se fossem instrução. A defesa que funciona é estrutural: separar instrução de dados, com consultas parametrizadas, e codificar a saída conforme o contexto onde ela vai aparecer. Validar entradas por lista de valores permitidos ajuda, mas não substitui a separação.

A terceira família é configuração: páginas de administração acessíveis, mensagens de erro que revelam a estrutura interna, listagem de directórios ligada, credenciais por omissão que ficaram, componentes desactualizados com falhas conhecidas. É a família mais barata de corrigir e das mais frequentes.

O guia de testes de segurança de aplicações web da OWASP dá estrutura ao trabalho. Não é uma norma obrigatória nem uma lei: é um guia comunitário aberto que organiza o que testar por categorias e ajuda a não esquecer áreas inteiras. A utilidade prática está em dois pontos: transforma «vamos ver se está seguro» numa lista de casos de teste concretos, e dá um formato de registo que torna o achado reproduzível por outra pessoa.

Um achado bem escrito tem sempre cinco partes: o que se encontrou, qual o impacto para o serviço e para os dados, como se reproduz passo a passo, que evidência foi recolhida, e o que se recomenda. O que não deve ter é a conclusão «a aplicação é segura». O que se escreve no fim é o que foi testado, o que ficou por testar e em que condições — é nisso que se distingue um relatório profissional de uma opinião.

Caso fictício: o portal de marcação de Muteva e o número de processo

No portal de marcação, depois de entrar, o cidadão vê os seus pedidos através de um endereço que termina em «/pedido/4821». Um funcionário reparou que, mudando o número para 4820, aparecia o pedido de outra pessoa, com nome, contacto e motivo.

A empresa que desenvolveu a aplicação respondeu que «o ecrã só mostra os pedidos do utilizador» — e mostra mesmo, na lista. O problema está na página de detalhe, que aceita qualquer número e devolve o registo correspondente sem verificar de quem é.

Este é o caso clássico de referência directa insegura a objectos. É uma falha de controlo de acesso, não de interface, e corrige-se no servidor: antes de devolver o registo, a aplicação tem de verificar se a sessão tem permissão para aquele pedido concreto. No portal de Muteva, a regra escrita pela direcção é que o cidadão vê os seus próprios pedidos e que os funcionários do balcão vêem os pedidos da sua unidade; a verificação no servidor aplica essa regra, em vez de aceitar o número recebido do cliente como se bastasse. Noutro serviço, com outras regras de perfil e âmbito, a verificação é a mesma ideia com outro critério.

Anexo A — Oito ocorrências observadas no portal de laboratório (fictícias)

Ficha de trabalho. As colunas de classificação e prioridade são preenchidas na actividade.

Anexo B — Autorização escrita para os testes do laboratório (modelo fictício)

Modelo a assinar pelo formador antes do laboratório; é também o exemplo de boa redacção.

«Autorização de teste em ambiente de formação. Alvos permitidos: exclusivamente a máquina virtual APP-LAB, endereço 10.20.4.10, na rede virtual isolada da sala. Alvos expressamente excluídos: qualquer sistema da instituição anfitriã, qualquer endereço fora da rede virtual e qualquer serviço na internet.

Janela: durante a sessão desta lição, das 09h00 às 11h00 do dia da formação. Técnicas proibidas: negação de serviço, alteração ou destruição de dados fora da aplicação de laboratório, e qualquer acção sobre máquinas de outros participantes.

Critério de paragem imediata: qualquer efeito observado fora de APP-LAB. Contacto de emergência: o formador da sessão, presente na sala. Registo: cada par regista na folha de laboratório a hora, o teste executado e o resultado observado.»

Anexo C — Aplicação didáctica APP-LAB, código completo (app_lab.py)

Aplicação de formação DELIBERADAMENTE VULNERÁVEL, escrita para este curso. Usa apenas a biblioteca padrão do Python 3 (requer Python 3.8 ou superior; a equipa autora executou-a em Python 3.13) e não instala nem descarrega nada. Guardar como app_lab.py na máquina virtual isolada e arrancar com «python3 app_lab.py»; fica a escutar em 127.0.0.1:8080, apenas dentro da própria máquina. Contas: utilizador1/lab1 e utilizador2/lab2. Pedidos fictícios: 4821 pertence a utilizador1 e 4820 pertence a utilizador2. NUNCA colocar esta aplicação em rede da instituição, na internet ou na plataforma de formação.

#!/usr/bin/env python3
# app_lab.py - aplicacao didactica DELIBERADAMENTE VULNERAVEL.
# Uso exclusivo em maquina virtual isolada, sem ligacao a redes reais.
# Biblioteca padrao apenas. Nao instala nada. Arranque: python3 app_lab.py
from http.server import BaseHTTPRequestHandler, HTTPServer
from urllib.parse import parse_qs
import uuid

CONTAS = {'utilizador1': 'lab1', 'utilizador2': 'lab2'}

PEDIDOS = {
    '4820': {'dono': 'utilizador2', 'nome': 'Ana Cumbe (ficticio)',
             'contacto': '84 000 0002', 'motivo': 'Segunda via de certidao'},
    '4821': {'dono': 'utilizador1', 'nome': 'Bento Mate (ficticio)',
             'contacto': '84 000 0001', 'motivo': 'Marcacao de atendimento'},
}

SESSOES = {}

PAGINA_ENTRAR = ('<h1>Portal de laboratorio</h1>'
                 '<form method=post action=/entrar>'
                 'Utilizador: <input name=u> Senha: <input name=p type=password>'
                 '<button>Entrar</button></form>')


class App(BaseHTTPRequestHandler):
    def sessao(self):
        for parte in self.headers.get('Cookie', '').split(';'):
            if parte.strip().startswith('sid='):
                return SESSOES.get(parte.strip()[4:])
        return None

    def responder(self, codigo, corpo, cookie=None):
        dados = corpo.encode('utf-8')
        self.send_response(codigo)
        self.send_header('Content-Type', 'text/html; charset=utf-8')
        self.send_header('Content-Length', str(len(dados)))
        if cookie:
            self.send_header('Set-Cookie', cookie)
        self.end_headers()
        self.wfile.write(dados)

    def do_GET(self):
        utilizador = self.sessao()
        if self.path == '/':
            if not utilizador:
                return self.responder(200, PAGINA_ENTRAR)
            meus = [n for n, p in PEDIDOS.items() if p['dono'] == utilizador]
            itens = ''.join('<li><a href=/pedido/' + n + '>Pedido ' + n + '</a></li>' for n in meus)
            return self.responder(200, '<h1>Os meus pedidos</h1><ul>' + itens + '</ul>')
        if self.path.startswith('/pedido/'):
            numero = self.path[len('/pedido/'):]
            pedido = PEDIDOS.get(numero)
            if not pedido:
                return self.responder(404, '<p>Pedido nao encontrado.</p>')
            # FALHA DIDACTICA O-01: devolve o pedido sem verificar a sessao.
            return self.responder(200, '<h1>Pedido ' + numero + '</h1><p>Nome: ' + pedido['nome']
                                  + '</p><p>Contacto: ' + pedido['contacto']
                                  + '</p><p>Motivo: ' + pedido['motivo'] + '</p>')
        if self.path == '/admin':
            # FALHA DIDACTICA O-03: painel de administracao sem autenticacao.
            linhas = ''.join('<li>' + n + ' - ' + p['dono'] + ' - ' + p['nome'] + '</li>'
                             for n, p in PEDIDOS.items())
            return self.responder(200, '<h1>Administracao</h1><ul>' + linhas + '</ul>')
        return self.responder(404, '<p>Nao encontrado.</p>')

    def do_POST(self):
        if self.path != '/entrar':
            return self.responder(404, '<p>Nao encontrado.</p>')
        tamanho = int(self.headers.get('Content-Length', '0'))
        campos = parse_qs(self.rfile.read(tamanho).decode('utf-8'))
        u = campos.get('u', [''])[0]
        p = campos.get('p', [''])[0]
        if CONTAS.get(u) != p:
            return self.responder(401, '<p>Credenciais invalidas.</p>')
        sid = uuid.uuid4().hex
        SESSOES[sid] = u
        return self.responder(200, '<p>Sessao iniciada. <a href=/>Continuar</a></p>',
                              cookie='sid=' + sid + '; Path=/')


if __name__ == '__main__':
    print('APP-LAB a escutar em http://127.0.0.1:8080 (ambiente isolado)')
    HTTPServer(('127.0.0.1', 8080), App).serve_forever()

Anexo D — Pedidos e respostas completos dos dois testes (material da alternativa offline)

Registo integral dos pedidos e das respostas obtidos nesta aplicação, para trabalhar no papel quando não houver ambiente. O identificador de sessão mostrado é de uma execução de exemplo e muda a cada arranque. Trabalhar sobre este registo é análise documental: não conta como laboratório executado.

A. Iniciar sessao como utilizador1
POST /entrar HTTP/1.1
Host: 127.0.0.1:8080
Content-Type: application/x-www-form-urlencoded
Content-Length: 20

u=utilizador1&p=lab1

HTTP/1.0 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 47
Set-Cookie: sid=f19214ad60fa44c7b56af3e9ce1915c4; Path=/

<p>Sessao iniciada. <a href=/>Continuar</a></p>

B. Teste O-01, primeira parte: o proprio pedido (resultado esperado, legitimo)
GET /pedido/4821 HTTP/1.1
Host: 127.0.0.1:8080
Cookie: sid=f19214ad60fa44c7b56af3e9ce1915c4

HTTP/1.0 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 120

<h1>Pedido 4821</h1><p>Nome: Bento Mate (ficticio)</p><p>Contacto: 84 000 0001</p><p>Motivo: Marcacao de atendimento</p>

C. Teste O-01, segunda parte: pedido de outra conta com a MESMA sessao (falha de autorizacao)
GET /pedido/4820 HTTP/1.1
Host: 127.0.0.1:8080
Cookie: sid=f19214ad60fa44c7b56af3e9ce1915c4

HTTP/1.0 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 119

<h1>Pedido 4820</h1><p>Nome: Ana Cumbe (ficticio)</p><p>Contacto: 84 000 0002</p><p>Motivo: Segunda via de certidao</p>

D. Teste O-01, terceira parte: o mesmo pedido SEM qualquer sessao
GET /pedido/4820 HTTP/1.1
Host: 127.0.0.1:8080

HTTP/1.0 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 119

<h1>Pedido 4820</h1><p>Nome: Ana Cumbe (ficticio)</p><p>Contacto: 84 000 0002</p><p>Motivo: Segunda via de certidao</p>

E. Teste O-03: painel de administracao sem sessao
GET /admin HTTP/1.1
Host: 127.0.0.1:8080

HTTP/1.0 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 132

<h1>Administracao</h1><ul><li>4820 - utilizador2 - Ana Cumbe (ficticio)</li><li>4821 - utilizador1 - Bento Mate (ficticio)</li></ul>

Trabalho prático

Trabalho em pares, com os anexos A e B em papel, antes de tocar no ambiente, com 60 minutos de trabalho, seguidos de 15 minutos de partilha e síntese em plenário. Desses 60 minutos, 35 são do exercício em papel e 25 são do laboratório descrito mais abaixo. A explicação e a apreciação do produto decorrem nos blocos de exposição e de partilha, e não dentro deste tempo.

Exercício em papel. Esta parte é análise documental sobre material fornecido. Não é o laboratório e não pode ser registada como prática executada em ambiente.

Passo 1 (15 minutos). Classifiquem as oito ocorrências do anexo A por categoria — controlo de acesso, injecção, configuração, autenticação ou exposição de dados — e atribuam prioridade de 1 a 3, justificando a prioridade pelo que um atacante consegue a partir daquilo. Onde a ocorrência for apenas indício de uma categoria, escrevam «indício» e digam que teste confirmaria.

Passo 2 (10 minutos). Para O-01 e O-03, escrevam o caso de teste no formato do guia: objectivo do teste, pré-condição, passos numerados, resultado esperado se a falha existir, resultado esperado se estiver corrigida, e evidência a recolher. São estes os dois casos que vão executar no laboratório.

Passo 3 (10 minutos). Escrevam o achado completo de O-01 como entraria num relatório: descrição, impacto, reprodução, evidência e recomendação. A recomendação deve dizer onde se corrige, não apenas o que se corrige.

Produto esperado: Anexo A classificado e priorizado, dois casos de teste escritos no formato do guia e um achado de relatório completo para O-01.

Como o produto é apreciado

• O-01 e O-03 estão classificadas como controlo de acesso; O-05 como injecção no navegador; O-06, O-07 e O-08 como configuração; O-04 como gestão de sessão e autenticação.
• O-02 é classificada como indício de injecção na consulta à base de dados, e não como injecção confirmada: uma mensagem de erro provocada por uma plica mostra que a entrada chega ao motor da base de dados sem tratamento adequado e que a aplicação revela detalhes internos no erro, o que já é achado próprio. A confirmação exige um teste adicional, autorizado e registado, que demonstre alteração do comportamento da consulta.
• A prioridade de O-08 é alta e justificada assim: um ficheiro de configuração acessível com credenciais é exposição grave de credenciais e obriga a trocá-las. Não se conclui daí, sem verificação, que exista acesso directo à base de dados — isso depende de a base aceitar ligações a partir de onde o atacante está, de as credenciais ainda serem válidas e das permissões associadas. O achado escreve-se com esta distinção entre o que foi observado e o que ainda é hipótese.
• Os casos de teste indicam evidência concreta a recolher — captura de ecrã, pedido e resposta, hora — e não apenas «verificar se funciona».
• A recomendação de O-01 exige verificação de autorização no servidor, aplicando as regras de acesso escritas da instituição — titular, perfil ou âmbito, conforme o caso — e não esconder a ligação na interface.
• O achado não conclui que a aplicação é segura nem generaliza para além do que foi testado.

Laboratório em ambiente isolado — Dois testes autorizados de controlo de acesso em APP-LAB (app_lab.py)

Regras do laboratório, sem excepção. Todos os alvos são máquinas virtuais do próprio laboratório, numa rede isolada e sem ligação à rede de produção da instituição. Nunca se usa como alvo um sistema real da instituição, de outra entidade ou de terceiros na internet, mesmo para «experimentar». Qualquer exercício de teste exige autorização escrita prévia da direcção, com âmbito, janela de tempo e pessoas identificadas. Não se descarrega, não se distribui e não se executa software malicioso real: a análise de ameaças é feita sobre indicadores, registos e descrições fornecidos no material. Não se pede conta pessoal nem pagamento de serviços.

Objectivo: Executar, na aplicação didáctica app_lab.py do anexo C, os casos de teste de O-01 e O-03 escritos na actividade, recolher evidência e registá-la no formato do relatório.

Tempo: 25 minutos, dentro do bloco de trabalho prático desta lição. Os minutos do exercício em papel e os minutos do laboratório somam o tempo desse bloco e não se contam duas vezes.

Material entregue com a lição

• Anexo C: código completo da aplicação app_lab.py, entregue com esta lição. Não é preciso o formador inventar nem procurar aplicação nenhuma — copia-se o código do anexo para um ficheiro com esse nome.
• Anexo C: contas (utilizador1/lab1 e utilizador2/lab2), pedidos fictícios (4821 de utilizador1 e 4820 de utilizador2) e rotas (/, /entrar, /pedido/{numero}, /admin) já coerentes entre si, sem passo de configuração adicional.
• Anexo D: pedidos e respostas completos dos dois testes, para imprimir e usar na alternativa offline.
• Anexo B: autorização de teste pronta a assinar.

Recursos e versões, preparados antes da sessão

• Uma máquina virtual «APP-LAB» com Python 3.8 ou superior já instalado (qualquer distribuição de Linux corrente serve; a equipa autora executou a aplicação em Python 3.13). A aplicação não instala pacotes e não precisa de internet.
• O ficheiro app_lab.py, criado a partir do anexo C, arrancado com «python3 app_lab.py». Escuta em 127.0.0.1:8080 e só responde dentro da própria máquina.
• Um navegador na mesma máquina virtual, com as ferramentas de programador para ver pedidos e respostas. Em alternativa, a ferramenta de linha de comandos curl, se estiver disponível.
• Rede virtual isolada, sem encaminhamento para a rede da sala nem para a internet.
• Autorização do anexo B impressa e assinada, afixada na sala durante o laboratório.
• Folha de laboratório com espaço para hora, teste, resultado e evidência.

Dependências ainda por preparar, não entregues com a lição

Enquanto qualquer um dos pontos seguintes estiver por preparar, o laboratório regista-se como pendente. Nenhum destes laboratórios foi ainda executado nem testado em sala pela equipa autora: os tempos e os resultados descritos são previsões a confirmar na primeira execução.

• A máquina virtual em si — imagem, memória e instalação — não é entregue com o curso: é preparada pela instituição de acolhimento. Enquanto não existir, o laboratório fica pendente.
• Este laboratório ainda não foi executado numa sala com formandos: os 25 minutos previstos e a sequência dos passos são estimativa a confirmar na primeira execução, e devem ser corrigidos no guião depois dela.
• Se a sala não tiver máquinas virtuais mas tiver Python instalado numa máquina isolada da rede, o formador decide, por escrito, se autoriza a execução nessa máquina; se não autorizar, usa-se o anexo D e regista-se o laboratório como pendente.

Preparação prévia, a cargo do formador

• Na véspera, criar app_lab.py a partir do anexo C na máquina virtual, arrancar com «python3 app_lab.py» e confirmar que a página inicial abre em http://127.0.0.1:8080.
• Confirmar a entrada com as duas contas do anexo C e que cada conta vê apenas o seu pedido na lista inicial.
• Tirar instantâneo «inicial» da máquina virtual com a aplicação já a funcionar.
• Confirmar que a rede virtual está isolada e que APP-LAB não alcança a internet nem a rede da sala.
• Imprimir o anexo D, para o caso de o ambiente falhar, e ler em voz alta a autorização do anexo B antes de qualquer teste.

Passos

1. Arrancar a aplicação com «python3 app_lab.py» e abrir http://127.0.0.1:8080 no navegador da própria máquina.
2. Entrar como «utilizador1» com a senha «lab1» e anotar o número do próprio pedido (4821).
3. Executar o caso de teste de O-01: com a mesma sessão, escrever no endereço /pedido/4820, que é o pedido de «utilizador2», e registar o que a aplicação devolve, com captura de ecrã e hora.
4. Repetir /pedido/4820 depois de fechar o navegador ou apagar o cookie de sessão, para distinguir falha de autorização de falha de autenticação, e registar o resultado.
5. Executar o caso de teste de O-03: aceder a /admin sem sessão iniciada e registar se a página abre, que informação mostra e que evidência foi recolhida.
6. Registar na folha, para cada teste, a hora de início, a acção exacta e o resultado observado, sem interpretações.
7. Não alterar nem apagar dados na aplicação: os testes desta lição são apenas de leitura e de acesso.

Verificação de sucesso

• A folha de laboratório tem, para cada um dos dois testes, hora, acção e resultado observado, com evidência anexada.
• O resultado observado em /pedido/4820 corresponde ao que está no anexo D: a aplicação devolve o pedido de outra conta. Se não corresponder, anota-se a diferença em vez de forçar a conclusão esperada.
• O par consegue reproduzir o resultado de O-01 uma segunda vez seguindo apenas os passos que escreveu — se não conseguir, os passos estão incompletos e são corrigidos.
• O teste repetido sem sessão iniciada permite dizer, com fundamento, se a falha é de autorização ou de autenticação.
• Nenhum efeito foi observado fora de APP-LAB, conforme o critério de paragem.

Reversão ao estado inicial

• Parar a aplicação com Ctrl+C: os dados vivem em memória e desaparecem ao parar, pelo que a aplicação volta ao estado inicial em cada arranque.
• Restaurar o instantâneo «inicial» da máquina virtual no fim da sessão.
• Apagar app_lab.py e as capturas de ecrã das máquinas partilhadas depois de anexadas à folha do par, para a aplicação vulnerável não ficar esquecida em nenhum computador.

Se o ambiente não estiver disponível: análise offline

A análise offline permite estudar o material e chegar às mesmas conclusões no papel, mas não equivale à execução. Quando se recorre a ela, a lição é registada como análise documental e o laboratório fica pendente, para ser reagendado.

• Trabalhar sobre o anexo D impresso, que traz os pedidos e as respostas completos das cinco situações (entrada em sessão, pedido próprio, pedido alheio com sessão, pedido alheio sem sessão e painel /admin).
• Comparar a resposta B com a resposta C e escrever, numa frase, o que a diferença — ou a ausência de diferença — mostra sobre a verificação de autorização no servidor.
• Localizar, no código do anexo C, a linha comentada como falha didáctica O-01 e explicar que verificação falta ali.
• Escrever os passos de reprodução a partir do material impresso e verificar se outra pessoa da sala os consegue seguir sem dúvidas.
• Redigir o achado completo com a evidência impressa em vez da evidência recolhida.
• Registar a lição como análise documental e o laboratório como pendente, a reagendar.

Síntese em leitura fácil

• A autorização verifica-se no servidor, em cada pedido. Esconder o botão não protege nada.
• Injecção resolve-se separando instrução de dados, não confiando só em filtrar texto.
• Configuração por omissão deixada como está é das falhas mais comuns e mais baratas de corrigir.
• Testar sem autorização escrita e sem lista de alvos não é teste.
• O relatório diz o que foi testado e o que ficou por testar. Nunca diz «a aplicação é segura».

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.

1. A empresa propõe corrigir O-01 removendo a ligação para a página de detalhe e passando a abrir o pedido por um botão da lista. Resolve?
2. No laboratório encontraram duas falhas e nenhuma outra. Podem escrever no relatório que as restantes áreas da aplicação estão seguras?

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 efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. A empresa propõe corrigir O-01 removendo a ligação para a página de detalhe e passando a abrir o pedido por um botão da lista. Resolve?

Resposta: Não. O endereço continua a existir e continua a responder a quem o escrever directamente. A correcção tem de ser no servidor: antes de devolver o registo, verifica-se se a sessão tem permissão para aquele pedido, segundo as regras de acesso escritas — titular, perfil ou âmbito —, e devolve-se «não encontrado» quando não tem.

Comentário: Alterações de interface não são controlo de acesso. Qualquer defesa que o cliente possa contornar não é defesa.

Pergunta 2. No laboratório encontraram duas falhas e nenhuma outra. Podem escrever no relatório que as restantes áreas da aplicação estão seguras?

Resposta: Não. Podem escrever que testaram dois casos, com que método e em que janela, e que essas áreas não foram testadas. Ausência de achado no que não foi testado não é prova de segurança.

Comentário: A honestidade do âmbito é o que dá valor ao relatório. Quem lê precisa de saber o que ficou de fora para decidir o que fazer a seguir.

Referências consultadas

• OWASP Web Security Testing Guide — guia de testes de segurança de aplicações web — https://owasp.org/projects/web-security-testing-guide (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Guia aberto que descreve, por categorias, o que testar numa aplicação web e como registar o que se encontra. Dá estrutura ao teste autorizado e ao relatório; é uma referência comunitária, não uma norma obrigatória.
• CISA Known Exploited Vulnerabilities Catalog — vulnerabilidades exploradas conhecidas — https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Catálogo público de vulnerabilidades com exploração observada no mundo real. Usa-se como entrada para priorizar correcções: uma falha que consta do catálogo sobe na fila. Os prazos que o catálogo indica aplicam-se a organismos federais dos Estados Unidos e não a instituições moçambicanas.

Estas referências são quadros e guias técnicos internacionais de adesão voluntária. Não são lei moçambicana, não criam prazos nem obrigações legais e não conferem qualquer certificação.

Duração prevista: 120 minutos, em sessão presencial.

Todos os casos, instituições, endereços, registos e números usados nesta lição são fictícios e servem apenas de exercício.

Como o tempo desta lição está distribuído

• Acolhimento e objectivos: 10 minutos.
• Exposição: 35 minutos.
• Trabalho prático: 60 minutos.
• Partilha e síntese: 15 minutos.

Como trabalhamos na sala: um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem executa a meio do trabalho, de modo que ambas façam. Na partilha apresentam dois grupos, com tempo limitado; os restantes entregam por escrito e recebem comentário do formador. Marcar a lição como concluída é registo de aprendizagem e não é registo de assiduidade.

Objectivos da lição

• Situar, no diagrama de cadeia de entrega fornecido, em que ponto entra cada tipo de verificação automática e o que cada uma detecta e não detecta.
• Definir critérios de bloqueio e de aviso para uma cadeia de entrega, distinguindo o que interrompe a entrega do que apenas gera registo, com justificação.
• Analisar o relatório fictício de dependências e decidir, para cada componente, entre actualizar, substituir, mitigar ou aceitar com prazo.
• Escrever cláusulas de segurança para um caderno de encargos de desenvolvimento externo, incluindo entrega de inventário de componentes e correcção de falhas após a entrega.

Explicação

DevSecOps é a ideia de que a segurança entra no processo de desenvolvimento desde o início, de forma automática e repetível, em vez de aparecer no fim como uma auditoria que atrasa tudo. O motivo é prático: corrigir uma falha na fase de desenho custa pouco; corrigi-la depois de o serviço estar em produção custa muito mais e envolve janelas de manutenção, comunicação e risco.

Há quatro verificações que cobrem a maior parte do terreno. A análise estática lê o código sem o executar e apanha padrões perigosos, como consultas construídas por concatenação de texto. A análise de dependências compara os componentes usados com listas públicas de falhas conhecidas — é a que dá mais retorno imediato, porque a maior parte do código de uma aplicação moderna vem de componentes de terceiros. A varredura de segredos procura chaves e senhas dentro do código. A análise dinâmica testa a aplicação a correr, num ambiente de ensaio, e apanha o que só se vê em execução. Cada uma tem ponto cego: a estática não vê erros de lógica de negócio; a de dependências não vê código próprio; a de segredos não vê segredos bem disfarçados; a dinâmica não vê o que não chega a exercitar.

Uma cadeia de entrega útil distingue bloqueio de aviso. Bloquear tudo paralisa a equipa e leva a que alguém desligue as verificações. Avisar tudo é o mesmo que não verificar. O critério tem de estar escrito e ser defensável: por exemplo, segredo detectado bloqueia sempre; componente com falha grave e com exploração observada bloqueia; falha de gravidade média gera aviso com prazo para tratamento; questão de estilo não bloqueia. Quem define este critério é a instituição, não a ferramenta.

Inventário de componentes é o documento que diz que peças entram no produto e em que versão. Sem ele, quando surge uma falha grave num componente muito usado, a pergunta «nós usamos isso?» fica dias sem resposta — e esses dias são exactamente a janela do atacante. Para software encomendado a terceiros, exigir este inventário na entrega é das cláusulas mais úteis que se podem escrever.

Para instituições que não desenvolvem, quase tudo isto continua a aplicar-se, na forma de exigências contratuais: entrega do inventário de componentes, prazo de correcção de falhas descobertas depois da entrega, direito a fazer teste de segurança antes de entrar em produção, e proibição de entregar com segredos embutidos. São cláusulas de contrato e boas práticas de gestão, não obrigações legais.

Caso fictício: a aplicação de processos e as suas 214 dependências

A aplicação de processos de Muteva foi entregue em 2021. Quando a equipa quis saber que componentes usava, não havia lista. Um levantamento feito à mão encontrou 214 componentes de terceiros, alguns dos quais já não são mantidos por ninguém desde 2019.

Em Agosto de 2026 foi divulgada uma falha grave num componente de tratamento de ficheiros muito comum. A pergunta «usamos este componente?» demorou quatro dias a ser respondida, porque foi preciso abrir a aplicação e procurar.

A resposta acabou por ser sim, em duas versões diferentes, uma delas na parte que recebe anexos dos cidadãos — exactamente a parte exposta.

Anexo A — Relatório de dependências da aplicação de processos (fictício, extracto)

Oito dos 214 componentes. A coluna «Decisão» é preenchida na actividade.

Anexo B — Cadeia de entrega actual da empresa externa (descrição fictícia)

Material de entrada. Descreve o processo tal como a empresa o declarou.

Etapa 1 — A pessoa que programa escreve o código no computador pessoal e envia-o para o repositório partilhado.

Etapa 2 — Não há revisão por outra pessoa; quem envia pode aprovar o seu próprio trabalho.

Etapa 3 — Uma tarefa automática compila o código e corre os testes funcionais. Se falharem, a entrega pára.

Etapa 4 — Não existe análise estática, nem análise de dependências, nem varredura de segredos.

Etapa 5 — A entrega é copiada directamente para o servidor de produção, à sexta-feira à tarde.

Etapa 6 — Não existe ambiente de ensaio; a verificação é feita em produção, depois de instalar.

Trabalho prático

Trabalho em grupos de três pessoas, com os anexos A e B em papel, com 60 minutos de trabalho, seguidos de 15 minutos de partilha e síntese em plenário.

Exercício em papel. Esta parte é análise documental sobre material fornecido. Não é o laboratório e não pode ser registada como prática executada em ambiente.

Passo 1 (20 minutos). Redesenhem a cadeia de entrega do anexo B, indicando em que etapa entra cada uma das quatro verificações automáticas e o que cada uma detecta. Marquem também as duas alterações de processo que fariam mesmo sem ferramentas nenhumas.

Passo 2 (20 minutos). Definam a política de bloqueio e aviso: que resultados interrompem a entrega, que resultados apenas registam, e com que prazo os avisos têm de ser tratados. Justifiquem cada limite.

Passo 3 (20 minutos). Decidam, para cada componente do anexo A, entre actualizar, substituir, mitigar ou aceitar com prazo. Para o motor de modelos, que não tem versão corrigida, escrevam a mitigação concreta e o prazo de substituição.

Produto esperado: Diagrama da cadeia de entrega revista, política escrita de bloqueio e aviso, e tabela de decisões para os oito componentes.

Como o produto é apreciado

• As quatro verificações estão colocadas em etapas onde fazem sentido, e não todas no fim.
• Entre as alterações de processo sem ferramentas está a revisão por outra pessoa e o fim da instalação directa em produção à sexta-feira.
• A política bloqueia segredos detectados e falhas graves com exploração observada, e deixa em aviso com prazo as de gravidade média.
• O componente de tratamento de ficheiros e o de compressão são tratados como prioritários por terem exploração observada.
• Para o motor de modelos abandonado há mitigação concreta e prazo de substituição, e não apenas «aceitar o risco».

Síntese em leitura fácil

• Segurança entra no princípio do trabalho, não no fim como auditoria.
• Quatro verificações: código, dependências, segredos e aplicação a correr. Cada uma tem pontos cegos.
• A cadeia distingue o que bloqueia do que apenas avisa. Bloquear tudo faz com que alguém desligue.
• Lista de componentes com versões: sem ela, no dia da falha ninguém sabe se somos afectados.
• Quem não desenvolve exige no contrato: lista de componentes, prazo de correcção e teste antes de entrar em produção.

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.

1. A análise de dependências não encontrou nada de grave. Significa que a aplicação não tem falhas graves?
2. O motor de modelos tem falha grave e o projecto foi abandonado, sem versão corrigida. Qual é a decisão defensável?

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 efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. A análise de dependências não encontrou nada de grave. Significa que a aplicação não tem falhas graves?

Resposta: Não. Essa análise só compara os componentes de terceiros com listas de falhas conhecidas. Não vê falhas no código próprio, nem erros de lógica de negócio, nem problemas de configuração ou de controlo de acesso.

Comentário: Cada verificação cobre uma fatia. A leitura conjunta é que dá imagem; nenhuma delas isolada autoriza a conclusão «não há falhas».

Pergunta 2. O motor de modelos tem falha grave e o projecto foi abandonado, sem versão corrigida. Qual é a decisão defensável?

Resposta: Mitigar agora e planear a substituição com prazo: restringir quem pode submeter conteúdo tratado por esse componente, reforçar a validação à entrada, aumentar a vigilância sobre aquela funcionalidade e marcar data para trocar o componente. Aceitar sem prazo não é decisão, é adiamento.

Comentário: Componentes abandonados não melhoram com o tempo, pioram. A aceitação de risco só é séria quando tem prazo e responsável.

Referências consultadas

• CISA Known Exploited Vulnerabilities Catalog — vulnerabilidades exploradas conhecidas — https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Catálogo público de vulnerabilidades com exploração observada no mundo real. Usa-se como entrada para priorizar correcções: uma falha que consta do catálogo sobe na fila. Os prazos que o catálogo indica aplicam-se a organismos federais dos Estados Unidos e não a instituições moçambicanas.
• OWASP Web Security Testing Guide — guia de testes de segurança de aplicações web — https://owasp.org/projects/web-security-testing-guide (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Guia aberto que descreve, por categorias, o que testar numa aplicação web e como registar o que se encontra. Dá estrutura ao teste autorizado e ao relatório; é uma referência comunitária, não uma norma obrigatória.

Estas referências são quadros e guias técnicos internacionais de adesão voluntária. Não são lei moçambicana, não criam prazos nem obrigações legais e não conferem qualquer certificação.

Duração prevista: 120 minutos, em sessão presencial.

Todos os casos, instituições, endereços, registos e números usados nesta lição são fictícios e servem apenas de exercício.

Como o tempo desta lição está distribuído

• Acolhimento e objectivos: 10 minutos.
• Exposição: 35 minutos.
• Trabalho prático: 60 minutos.
• Partilha e síntese: 15 minutos.

Como trabalhamos na sala: um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem executa a meio do trabalho, de modo que ambas façam. Na partilha apresentam dois grupos, com tempo limitado; os restantes entregam por escrito e recebem comentário do formador. Marcar a lição como concluída é registo de aprendizagem e não é registo de assiduidade.

Objectivos da lição

• Determinar, a partir da tabela de fontes fornecida, que registos recolher primeiro com orçamento limitado, justificando pela detecção que cada fonte permite.
• Reconstituir, a partir dos vinte registos fornecidos, a sequência de acontecimentos e identificar o momento exacto em que o acesso deixa de ser normal.
• Escrever duas regras de detecção com condição, limiar, janela temporal e acção esperada, e estimar o efeito de cada uma em falsos positivos.
• Executar, no ambiente de laboratório, a criação de uma regra de correlação e confirmar que ela dispara com dados de ensaio e não dispara com actividade normal.

Explicação

Detectar exige três coisas: registos que existam, registos que cheguem a um sítio central e alguém que olhe. Falta qualquer uma delas e a detecção não acontece. É comum encontrar instituições com registos em todas as máquinas e nenhuma detecção, porque ninguém os lê e porque ninguém os junta.

Nem tudo se recolhe. Com orçamento e espaço limitados, a ordem que costuma dar melhor retorno é: autenticação (quem entrou, de onde, com que resultado), alterações de privilégios e de contas, registos dos sistemas expostos à internet, tráfego de saída da rede, e registos aplicacionais dos serviços críticos. Autenticação vem primeiro porque quase todos os incidentes passam por lá.

Um SIEM é um sistema que recolhe registos de várias fontes, normaliza-os para um formato comum, correlaciona acontecimentos e gera alertas. O valor não está na ferramenta: está nas regras e em quem as afina. Um SIEM comprado e deixado com as regras de fábrica produz milhares de alertas irrelevantes, a equipa deixa de os ler, e o resultado é pior do que não ter nada — porque existe a ilusão de que se está a detectar.

Uma regra de detecção útil tem quatro elementos: a condição (o que se procura), o limiar (a partir de que quantidade), a janela temporal (em quanto tempo) e a acção (alerta com que prioridade, para quem). Sem limiar e janela, a regra ou dispara sempre ou nunca. Escrever regras é um trabalho de equilíbrio: baixar o limiar aumenta a detecção e aumenta o ruído; subi-lo reduz o ruído e deixa passar. A decisão depende de quantas pessoas há para tratar alertas, e isso é uma conversa de gestão.

Duas condições práticas fazem a diferença na análise. Primeira: horas sincronizadas em todas as máquinas, com fuso declarado — sem isso, a reconstituição da sequência é impossível e a evidência perde valor. Segunda: registos guardados fora da máquina de origem e protegidos contra alteração, porque quem compromete o sistema apaga o rasto local. Num centro de operações de segurança, mesmo pequeno, acrescenta-se uma terceira: uma lista escrita do que se faz em cada tipo de alerta, para que a resposta não dependa de quem está de serviço.

Caso fictício: a madrugada de 3 de Setembro em Muteva

Entre as 02h11 e as 02h48 de 3 de Setembro, a conta «a.chirindza» — administradora de sistemas, que estava de férias — autenticou-se com sucesso no servidor de directório, a partir de um endereço nunca visto, depois de 41 tentativas falhadas em três minutos.

Nos vinte minutos seguintes, foi criada uma conta nova, «svc_update», com privilégios de administração, e o serviço de envio de registos foi parado.

Nada disto gerou alerta. Os registos existiam, estavam nas máquinas, e ninguém os lia. A descoberta foi feita onze dias depois, quando o serviço de cópias falhou por razão não relacionada e alguém foi ver porquê.

Anexo A — Fontes de registo disponíveis e custo estimado (fictício)

Ficha de trabalho: escolher a ordem de recolha com espaço para 200 gigabytes por mês.

Anexo B — Vinte linhas de registo da madrugada de 3 de Setembro (fictícias)

Formato simplificado para leitura em papel: hora (fuso de Maputo, UTC+2), fonte, conta, acontecimento, origem.

02h08 — directório — a.chirindza — autenticação falhada — 41.x.y.z (endereço nunca visto)

02h08 — directório — a.chirindza — autenticação falhada — 41.x.y.z

02h09 — directório — a.chirindza — autenticação falhada (mais 37 tentativas em 3 minutos) — 41.x.y.z

02h11 — directório — a.chirindza — autenticação com sucesso — 41.x.y.z

02h12 — SRV-DIR — a.chirindza — sessão remota iniciada — 41.x.y.z

02h14 — SRV-DIR — a.chirindza — leitura da lista de contas de administração — local

02h19 — SRV-DIR — a.chirindza — criação da conta svc_update — local

02h20 — SRV-DIR — a.chirindza — atribuição de privilégios de administração a svc_update — local

02h23 — SRV-BD — svc_update — sessão iniciada — 10.20.3.30

02h26 — SRV-BD — svc_update — exportação da tabela de processos (41 200 registos) — local

02h31 — rede — — ligação de saída de 10.20.3.30 para destino externo, 2,4 GB transferidos — saída

02h38 — SRV-DIR — a.chirindza — paragem do serviço de envio de registos — local

02h39 — recolector — — deixam de chegar registos de SRV-DIR — —

02h44 — SRV-FIC — svc_update — sessão iniciada — 10.20.3.30

02h46 — SRV-FIC — svc_update — leitura de 3 100 ficheiros do arquivo — local

02h48 — SRV-DIR — a.chirindza — sessão remota terminada — 41.x.y.z

07h02 — directório — j.matola — autenticação com sucesso — 10.20.1.45 (posto habitual)

07h05 — portal — — 1 200 acessos normais de cidadãos — internet

08h30 — directório — r.sitoe — autenticação com sucesso — 10.20.1.12 (posto habitual)

14 de Setembro, 09h10 — cópias — backup_svc — falha da cópia semanal — local

Trabalho prático

Trabalho em grupos de três pessoas, com os anexos A e B em papel, com 60 minutos de trabalho, seguidos de 15 minutos de partilha e síntese em plenário. Desses 60 minutos, 35 são do exercício em papel e 25 são do laboratório descrito mais abaixo. A explicação e a apreciação do produto decorrem nos blocos de exposição e de partilha, e não dentro deste tempo.

Exercício em papel. Esta parte é análise documental sobre material fornecido. Não é o laboratório e não pode ser registada como prática executada em ambiente.

Passo 1 (10 minutos). Com espaço para 200 gigabytes por mês, escolham as fontes do anexo A a recolher primeiro e justifiquem cada escolha pela detecção que permite. Digam o que deixam de fora e que detecção perdem com isso.

Passo 2 (15 minutos). Reconstituam a sequência do anexo B numa linha temporal. Marquem o momento em que deixa de ser actividade normal e escrevam a frase que justifica essa marcação. Identifiquem os três momentos em que um alerta deveria ter disparado e não disparou.

Passo 3 (10 minutos). Escrevam duas regras de detecção com condição, limiar, janela e acção. Uma delas deve apanhar o início desta sequência. Para cada regra, estimem quantos alertas por semana geraria numa instituição com 62 funcionários e digam se a equipa consegue tratá-los.

Produto esperado: Lista ordenada de fontes com justificação, linha temporal com o momento de ruptura e os três alertas em falta, e duas regras de detecção com estimativa de ruído.

Como o produto é apreciado

• Autenticação e alterações de contas estão entre as primeiras fontes escolhidas; os registos dos postos, que são o maior volume, não ocupam o orçamento todo.
• O momento de ruptura está identificado às 02h11, na autenticação com sucesso após 41 falhas, a partir de endereço nunca visto e com a titular de férias.
• Entre os alertas em falta constam a criação de conta com privilégios às 02h19, a exportação em massa às 02h26 e a paragem do serviço de registos às 02h38.
• As regras têm os quatro elementos; nenhuma fica sem limiar nem sem janela.
• A estimativa de ruído é feita e confrontada com a capacidade real da equipa.

Laboratório em ambiente isolado — Criar e ensaiar uma regra de correlação no recolector de registos

Regras do laboratório, sem excepção. Todos os alvos são máquinas virtuais do próprio laboratório, numa rede isolada e sem ligação à rede de produção da instituição. Nunca se usa como alvo um sistema real da instituição, de outra entidade ou de terceiros na internet, mesmo para «experimentar». Qualquer exercício de teste exige autorização escrita prévia da direcção, com âmbito, janela de tempo e pessoas identificadas. Não se descarrega, não se distribui e não se executa software malicioso real: a análise de ameaças é feita sobre indicadores, registos e descrições fornecidos no material. Não se pede conta pessoal nem pagamento de serviços.

Objectivo: Configurar, no ambiente de laboratório, uma regra que dispare perante múltiplas autenticações falhadas seguidas de sucesso, e confirmar que dispara com os dados de ensaio e não dispara com actividade normal.

Tempo: 25 minutos, dentro do bloco de trabalho prático desta lição. Os minutos do exercício em papel e os minutos do laboratório somam o tempo desse bloco e não se contam duas vezes.

Recursos e versões, preparados antes da sessão

• Máquina virtual «SIEM-LAB» com um recolector de registos de código aberto pré-instalado pelo formador, com interface de regras simples.
• Ficheiro de registos de ensaio «ensaio-03set.log» com as linhas do anexo B em formato normalizado, copiado para SIEM-LAB.
• Segundo ficheiro «ensaio-normal.log» com uma semana de actividade normal fictícia, para medir falsos positivos.
• Folha de laboratório com espaço para a regra escrita, o número de alertas em cada ensaio e a conclusão.

Dependências ainda por preparar, não entregues com a lição

Enquanto qualquer um dos pontos seguintes estiver por preparar, o laboratório regista-se como pendente. Nenhum destes laboratórios foi ainda executado nem testado em sala pela equipa autora: os tempos e os resultados descritos são previsões a confirmar na primeira execução.

• A máquina «SIEM-LAB» e o recolector de registos de código aberto não são entregues com o curso: instalação e escolha da ferramenta são decisão e trabalho da instituição de acolhimento.
• Os ficheiros «ensaio-03set.log» e «ensaio-normal.log» têm de ser montados pelo formador no formato que o recolector escolhido aceitar. O curso entrega as linhas do anexo B e o cenário, não os ficheiros já formatados.
• Sem o recolector, faz-se a análise offline sobre as linhas impressas e regista-se o laboratório como pendente.
• Este laboratório ainda não foi executado numa sala com formandos nem testado pela equipa autora: os 25 minutos previstos e os resultados descritos são estimativa a confirmar na primeira execução, e devem ser corrigidos no guião depois dela.

Preparação prévia, a cargo do formador

• Arrancar SIEM-LAB no dia anterior e confirmar que a interface de regras abre e que a importação de ficheiros funciona.
• Tirar instantâneo «inicial» com o recolector vazio, sem regras criadas.
• Confirmar que a hora da máquina virtual está correcta e com fuso declarado: sem isso a correlação por janela temporal não funciona.
• Confirmar o isolamento da rede virtual.

Passos

1. Importar «ensaio-normal.log» e confirmar que o recolector mostra os acontecimentos e que não existe nenhuma regra activa.
2. Criar a regra escrita no passo 3 da actividade: cinco ou mais autenticações falhadas da mesma conta em dez minutos, seguidas de uma autenticação com sucesso da mesma conta na mesma janela, com acção de alerta de prioridade alta.
3. Correr a regra sobre «ensaio-normal.log» e registar quantos alertas gera. Este número é a estimativa de falsos positivos.
4. Importar «ensaio-03set.log» e correr a mesma regra; registar se o alerta dispara e a que hora corresponde.
5. Criar uma segunda regra para a criação de conta com privilégios de administração fora do horário de expediente e correr sobre os dois ficheiros.
6. Registar na folha as duas regras, os quatro números de alertas obtidos e a conclusão sobre a capacidade de tratamento.

Verificação de sucesso

• A primeira regra dispara sobre «ensaio-03set.log» e o alerta aponta para as 02h11.
• A mesma regra gera zero ou muito poucos alertas sobre «ensaio-normal.log»; se gerar muitos, o grupo ajusta o limiar e volta a correr, registando as duas versões.
• A segunda regra dispara na criação de svc_update às 02h19.
• A folha de laboratório tem as regras escritas e os quatro números registados, assinada pelo grupo.

Reversão ao estado inicial

• Apagar as regras criadas e os ficheiros importados.
• Restaurar o instantâneo «inicial» de SIEM-LAB.
• Confirmar que o recolector volta a abrir sem regras, o que prova a reposição.

Se o ambiente não estiver disponível: análise offline

A análise offline permite estudar o material e chegar às mesmas conclusões no papel, mas não equivale à execução. Quando se recorre a ela, a lição é registada como análise documental e o laboratório fica pendente, para ser reagendado.

• Correr a regra à mão sobre as vinte linhas impressas do anexo B, marcando as linhas que a satisfazem.
• Fazer o mesmo sobre uma amostra impressa de trinta linhas de actividade normal fornecida pelo formador e contar falsos positivos.
• Escrever o ajuste de limiar que faria e recontar à mão.
• Registar a lição como análise documental e o laboratório como pendente, a reagendar.

Síntese em leitura fácil

• Para detectar é preciso ter registos, juntá-los num sítio e alguém olhar. Faltando uma, não há detecção.
• Recolher primeiro autenticação e alterações de contas: quase tudo passa por aí.
• Uma regra precisa de condição, limiar, janela e acção.
• Regra sem afinação enche a equipa de alertas e ninguém lê nenhum.
• Horas certas e registos guardados fora da máquina. Quem entra apaga o que está na máquina.

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.

1. Porque é que às 02h11 o acesso deixa de poder ser tratado como normal, se a autenticação teve sucesso com a palavra-passe certa?
2. A regra nova gerou 180 alertas numa semana de actividade normal. A equipa tem duas pessoas. O que se faz?

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 efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. Porque é que às 02h11 o acesso deixa de poder ser tratado como normal, se a autenticação teve sucesso com a palavra-passe certa?

Resposta: Porque o sucesso vem depois de 41 tentativas falhadas em três minutos, a partir de um endereço nunca visto, de madrugada, numa conta cuja titular está de férias. O sucesso da autenticação prova que a credencial estava correcta, não que era a titular a usá-la.

Comentário: Autenticação com sucesso não é sinónimo de pessoa legítima. A detecção vive do contexto: hora, origem, sequência e comportamento.

Pergunta 2. A regra nova gerou 180 alertas numa semana de actividade normal. A equipa tem duas pessoas. O que se faz?

Resposta: Afina-se antes de a pôr em serviço: subir o limiar, restringir a origens externas, excluir contas de serviço conhecidas ou reduzir a janela. Depois volta-se a medir. Pôr em serviço uma regra que a equipa não consegue tratar leva ao abandono de todos os alertas.

Comentário: A capacidade de resposta faz parte do desenho da detecção. Uma regra boa que ninguém consegue acompanhar é uma regra má na prática.

Referências consultadas

• NIST Cybersecurity Framework — quadro voluntário de segurança cibernética — https://www.nist.gov/cyberframework (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Quadro de adesão voluntária organizado em seis funções: Governar, Identificar, Proteger, Detectar, Responder e Recuperar. Serve para organizar o trabalho de segurança e conversar sobre risco com a direcção; não é lei nem certificação.

Estas referências são quadros e guias técnicos internacionais de adesão voluntária. Não são lei moçambicana, não criam prazos nem obrigações legais e não conferem qualquer certificação.

Duração prevista: 120 minutos, em sessão presencial.

Todos os casos, instituições, endereços, registos e números usados nesta lição são fictícios e servem apenas de exercício.

Como o tempo desta lição está distribuído

• Acolhimento e objectivos: 10 minutos.
• Exposição: 35 minutos.
• Trabalho prático: 60 minutos.
• Partilha e síntese: 15 minutos.

Como trabalhamos na sala: um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem executa a meio do trabalho, de modo que ambas façam. Na partilha apresentam dois grupos, com tempo limitado; os restantes entregam por escrito e recebem comentário do formador. Marcar a lição como concluída é registo de aprendizagem e não é registo de assiduidade.

Objectivos da lição

• Distinguir, com um exemplo de cada, as famílias de software malicioso pelo efeito que produzem e pelo modo de propagação, e situá-las nas fases de uma intrusão prolongada.
• Extrair da ficha fornecida os indicadores de compromisso e classificá-los por durabilidade, explicando por que razão um endereço muda com facilidade e um resumo de ficheiro não.
• Executar, em ambiente isolado e sem qualquer amostra de software malicioso real, a recolha ordenada de evidência volátil e não volátil, registando resumos criptográficos e cadeia de custódia.
• Escrever a primeira página de um relatório forense com factos observados, separando-os das hipóteses e indicando o que não foi possível determinar.

Explicação

Começar pelo essencial: nesta lição não se descarrega, não se distribui e não se executa software malicioso real. Trabalha-se sobre indicadores, registos, descrições e ficheiros inertes preparados para formação. Quem quiser trabalhar com amostras reais precisa de ambiente dedicado, isolado fisicamente, com procedimento aprovado e autorização própria — não é matéria de sala de formação.

As famílias distinguem-se pelo efeito e pela propagação. Software de resgate cifra ficheiros e exige pagamento, e hoje quase sempre exfiltra dados antes de cifrar, para pressionar mesmo quem tem cópias. Porta traseira mantém acesso ao sistema. Ladrão de credenciais recolhe palavras-passe e testemunhos de sessão. Verme propaga-se sozinho pela rede; cavalo de Tróia depende de alguém o executar. Minerador consome recursos e é frequentemente o primeiro sinal visível de uma intrusão que entrou por outra via.

Ameaça avançada persistente descreve menos uma ferramenta e mais um modo de operar: acesso inicial discreto, permanência prolongada, movimentação lateral, recolha paciente. As fases repetem-se: acesso inicial, execução, persistência, elevação de privilégios, evasão, recolha de credenciais, reconhecimento interno, movimentação lateral, recolha de dados, exfiltração e impacto. Reconhecer a fase em que se está muda a resposta — quem encontra sinais de reconhecimento interno tem tempo; quem encontra exfiltração em curso não tem.

Indicadores de compromisso não valem todos o mesmo. Um endereço de rede muda num minuto. Um nome de domínio muda em horas. Um resumo criptográfico de um ficheiro muda se o ficheiro mudar um bit, mas identifica exactamente aquele ficheiro. Uma regra que descreve comportamento — «processo do servidor web a lançar interpretador de comandos» — é a mais duradoura, porque descreve o que o atacante precisa de fazer, não a ferramenta que usou desta vez.

Na forense básica, três regras comandam tudo. Primeira, ordem de volatilidade: recolhe-se primeiro o que desaparece — memória, ligações de rede activas, processos em execução, sessões abertas — e só depois o que fica em disco. Segunda, integridade: calcula-se o resumo criptográfico de cada peça recolhida no momento da recolha e trabalha-se sobre cópias, nunca sobre o original. Terceira, cadeia de custódia: quem recolheu, quando, de onde, onde ficou guardado e quem lhe tocou desde então. Uma evidência sem cadeia de custódia pode continuar tecnicamente correcta e ser inútil para efeitos disciplinares ou judiciais. Se houver hipótese de processo, a decisão sobre o que fazer a seguir envolve a direcção e a área jurídica — o técnico recolhe e preserva, não decide sozinho.

Caso fictício: o que se encontrou em SRV-BD a 14 de Setembro

Depois da falha da cópia semanal, a administradora olhou para SRV-BD e encontrou um processo chamado «updatesvc» a correr desde 3 de Setembro, a partir de uma pasta temporária, com o utilizador svc_update.

O processo mantinha uma ligação estabelecida para um endereço externo na porta 443, e havia uma tarefa agendada que o voltava a lançar ao arranque. O ficheiro tinha 4,2 megabytes e data de criação de 3 de Setembro às 02h24.

Nenhum antivírus assinalou nada. Isto é comum e não significa que o antivírus esteja avariado: detecção por assinatura não apanha ficheiros que nunca viu, e é por isso que o comportamento — um processo desconhecido a correr de pasta temporária com ligação permanente para fora — vale mais do que a ausência de alerta.

Anexo A — Indicadores recolhidos no caso (fictícios)

Ficha de trabalho. A coluna «Durabilidade» é preenchida na actividade.

Anexo B — Folha de cadeia de custódia (modelo a preencher)

Modelo fictício de trabalho. Uma folha por peça de evidência recolhida.

Peça n.º ___ | Descrição da peça: ___ | Origem (máquina, caminho): ___

Data e hora da recolha, com fuso: ___ | Recolhida por (nome e função): ___

Método de recolha e ferramenta usada: ___ | Resumo criptográfico no momento da recolha: ___

Onde ficou guardada: ___ | Quem tem acesso: ___

Transferências: de ___ para ___, em ___, motivo ___, resumo verificado (sim/não) ___

Observações e limitações: ___

Trabalho prático

Trabalho em grupos de três pessoas, com os anexos A e B em papel, com 60 minutos de trabalho, seguidos de 15 minutos de partilha e síntese em plenário. Desses 60 minutos, 35 são do exercício em papel e 25 são do laboratório descrito mais abaixo. A explicação e a apreciação do produto decorrem nos blocos de exposição e de partilha, e não dentro deste tempo.

Exercício em papel. Esta parte é análise documental sobre material fornecido. Não é o laboratório e não pode ser registada como prática executada em ambiente.

Passo 1 (10 minutos). Classifiquem a durabilidade de cada indicador do anexo A em baixa, média ou alta e escrevam, para os três de durabilidade mais alta, como os usariam para procurar o mesmo problema noutras máquinas.

Passo 2 (15 minutos). Escrevam a ordem de recolha de evidência em SRV-BD, do mais volátil ao menos volátil, listando pelo menos oito peças. Ao lado de cada uma, digam o que se perde se for recolhida tarde.

Passo 3 (10 minutos). Preencham a folha de cadeia de custódia do anexo B para duas peças, com dados do caso, e escrevam a primeira página do relatório com três secções separadas: factos observados, hipóteses em avaliação, e o que não foi possível determinar.

Produto esperado: Anexo A com durabilidades, lista ordenada de recolha com justificação, duas folhas de custódia preenchidas e a primeira página do relatório com as três secções.

Como o produto é apreciado

• O endereço e o domínio são classificados como durabilidade baixa; o resumo do ficheiro média; o comportamento alta.
• A ordem de recolha começa pela memória, ligações activas, processos e sessões, e só depois passa ao disco e aos registos.
• As folhas de custódia estão completas, com hora, fuso, método, resumo e responsável nomeado.
• A secção de factos não contém hipóteses; a de hipóteses está marcada como tal; a terceira secção existe e é honesta.
• O relatório não afirma a identidade de quem atacou nem conclui por prova que não foi recolhida.

Laboratório em ambiente isolado — Recolha ordenada de evidência em máquina de laboratório, sem software malicioso real

Regras do laboratório, sem excepção. Todos os alvos são máquinas virtuais do próprio laboratório, numa rede isolada e sem ligação à rede de produção da instituição. Nunca se usa como alvo um sistema real da instituição, de outra entidade ou de terceiros na internet, mesmo para «experimentar». Qualquer exercício de teste exige autorização escrita prévia da direcção, com âmbito, janela de tempo e pessoas identificadas. Não se descarrega, não se distribui e não se executa software malicioso real: a análise de ameaças é feita sobre indicadores, registos e descrições fornecidos no material. Não se pede conta pessoal nem pagamento de serviços.

Objectivo: Executar a recolha de evidência volátil e não volátil numa máquina virtual preparada, calculando resumos criptográficos e preenchendo a cadeia de custódia, sem qualquer amostra de software malicioso.

Tempo: 25 minutos, dentro do bloco de trabalho prático desta lição. Os minutos do exercício em papel e os minutos do laboratório somam o tempo desse bloco e não se contam duas vezes.

Recursos e versões, preparados antes da sessão

• Máquina virtual «SRV-BD-LAB» preparada pelo formador com um processo inofensivo de demonstração, chamado «updatesvc», que apenas escreve a hora num ficheiro de texto e mantém uma ligação a outra máquina do laboratório. Não é software malicioso e o seu código-fonte é entregue impresso.
• Máquina virtual «EST-FORENSE» com ferramentas de linha de comandos para listar processos, ligações e utilizadores, e para calcular resumos criptográficos.
• Disco virtual de recolha, vazio, montado em EST-FORENSE para guardar as peças.
• Folhas de cadeia de custódia impressas, em número suficiente, e a ficha de comandos equivalentes para o sistema usado.

Dependências ainda por preparar, não entregues com a lição

Enquanto qualquer um dos pontos seguintes estiver por preparar, o laboratório regista-se como pendente. Nenhum destes laboratórios foi ainda executado nem testado em sala pela equipa autora: os tempos e os resultados descritos são previsões a confirmar na primeira execução.

• A máquina «EST-FORENSE», o processo de demonstração inofensivo e os ficheiros de registo do cenário são preparados localmente; o curso entrega o cenário, os indicadores e as folhas, não o ambiente.
• Não é entregue, e nunca se usa, qualquer amostra real de programa malicioso: o exercício trabalha sobre indicadores e registos fornecidos.
• Este laboratório ainda não foi executado numa sala com formandos nem testado pela equipa autora: os 25 minutos previstos e os resultados descritos são estimativa a confirmar na primeira execução, e devem ser corrigidos no guião depois dela.

Preparação prévia, a cargo do formador

• Arrancar as máquinas no dia anterior e confirmar que o processo de demonstração arranca e que a ligação entre as duas máquinas se estabelece.
• Tirar instantâneo «inicial» das duas máquinas.
• Confirmar o isolamento da rede virtual e que nenhuma máquina alcança a internet.
• Mostrar à turma, antes de começar, o código-fonte impresso do processo de demonstração, para que fique claro que não há software malicioso envolvido.

Passos

1. Registar a hora do sistema das duas máquinas e o fuso, e anotá-la na folha: é a primeira peça.
2. Em SRV-BD-LAB, recolher a lista de processos em execução, as ligações de rede estabelecidas e as sessões abertas, gravando a saída em ficheiros no disco de recolha.
3. Calcular o resumo criptográfico de cada ficheiro de saída imediatamente após a recolha e anotá-lo na folha de custódia correspondente.
4. Recolher a tarefa agendada de demonstração e o ficheiro do processo, calculando também os respectivos resumos.
5. Copiar os registos do sistema relevantes ao período e calcular o resumo do conjunto.
6. Preencher uma folha de custódia por peça, com hora, método, responsável e local de guarda, e verificar no fim que todos os resumos anotados coincidem com os ficheiros no disco de recolha.

Verificação de sucesso

• Existem pelo menos seis peças recolhidas, cada uma com folha de custódia preenchida e resumo anotado.
• A verificação final mostra que todos os resumos coincidem: nenhuma peça foi alterada depois da recolha.
• A ordem registada nas folhas respeita a volatilidade: hora e estado em memória antes dos ficheiros em disco.
• Outra pessoa da sala consegue, lendo apenas as folhas, dizer de onde veio cada peça e quem lhe tocou.

Reversão ao estado inicial

• Restaurar o instantâneo «inicial» nas duas máquinas.
• Apagar o conteúdo do disco virtual de recolha depois de as folhas estarem preenchidas e recolhidas pelo formador.
• Confirmar que SRV-BD-LAB volta ao estado inicial com o processo de demonstração activo.

Se o ambiente não estiver disponível: análise offline

A análise offline permite estudar o material e chegar às mesmas conclusões no papel, mas não equivale à execução. Quando se recorre a ela, a lição é registada como análise documental e o laboratório fica pendente, para ser reagendado.

• Trabalhar sobre as saídas impressas de processos, ligações e sessões fornecidas pelo formador, identificando o que estaria a mais.
• Preencher as folhas de custódia com os dados impressos, incluindo os resumos fornecidos, e verificar a coerência entre folhas.
• Escrever a ordem de recolha que teria seguido e o que se perderia em cada peça recolhida tarde.
• Registar a lição como análise documental e o laboratório como pendente, a reagendar.

Síntese em leitura fácil

• Nesta formação não se usa software malicioso real. Trabalha-se com indicadores, registos e ficheiros inertes.
• Recolher primeiro o que desaparece: memória, ligações, processos, sessões. Só depois o disco.
• Calcular o resumo na hora da recolha e trabalhar sempre sobre cópias.
• Sem cadeia de custódia, a evidência pode estar certa e não servir para nada.
• Endereços mudam depressa; o comportamento descrito dura muito mais.

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.

1. O antivírus não assinalou o ficheiro encontrado em SRV-BD. Isso permite concluir que o ficheiro é inofensivo?
2. A equipa desligou imediatamente o servidor para «parar o ataque». Que consequência tem esta decisão para a análise?

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 efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. O antivírus não assinalou o ficheiro encontrado em SRV-BD. Isso permite concluir que o ficheiro é inofensivo?

Resposta: Não. A detecção por assinatura só reconhece o que já viu antes. Um ficheiro novo ou alterado passa sem alerta. A avaliação faz-se pelo comportamento observado e pelo contexto: processo desconhecido, a correr de pasta temporária, criado às 02h24 por uma conta criada nessa madrugada, com ligação permanente para fora.

Comentário: Ausência de alerta não é prova de ausência de problema. É por isso que a detecção por comportamento e os registos valem mais do que a lista de assinaturas.

Pergunta 2. A equipa desligou imediatamente o servidor para «parar o ataque». Que consequência tem esta decisão para a análise?

Resposta: Perde-se toda a evidência volátil: memória, processos em execução, ligações activas e sessões abertas. Pode ser a decisão certa quando a exfiltração está em curso, mas é uma decisão de contenção que tem custo probatório e deve ser tomada com consciência disso e registada.

Comentário: Conter e preservar entram em conflito. A escolha faz-se com critério escrito antes, e não no momento de pânico.

Referências consultadas

• NIST Cybersecurity Framework — quadro voluntário de segurança cibernética — https://www.nist.gov/cyberframework (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Quadro de adesão voluntária organizado em seis funções: Governar, Identificar, Proteger, Detectar, Responder e Recuperar. Serve para organizar o trabalho de segurança e conversar sobre risco com a direcção; não é lei nem certificação.
• CISA Known Exploited Vulnerabilities Catalog — vulnerabilidades exploradas conhecidas — https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Catálogo público de vulnerabilidades com exploração observada no mundo real. Usa-se como entrada para priorizar correcções: uma falha que consta do catálogo sobe na fila. Os prazos que o catálogo indica aplicam-se a organismos federais dos Estados Unidos e não a instituições moçambicanas.

Estas referências são quadros e guias técnicos internacionais de adesão voluntária. Não são lei moçambicana, não criam prazos nem obrigações legais e não conferem qualquer certificação.

Duração prevista: 120 minutos, em sessão presencial.

Todos os casos, instituições, endereços, registos e números usados nesta lição são fictícios e servem apenas de exercício.

Como o tempo desta lição está distribuído

• Acolhimento e objectivos: 10 minutos.
• Exposição: 35 minutos.
• Trabalho prático: 60 minutos.
• Partilha e síntese: 15 minutos.

Como trabalhamos na sala: um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem executa a meio do trabalho, de modo que ambas façam. Na partilha apresentam dois grupos, com tempo limitado; os restantes entregam por escrito e recebem comentário do formador. Marcar a lição como concluída é registo de aprendizagem e não é registo de assiduidade.

Objectivos da lição

• Classificar os cinco incidentes fictícios por gravidade segundo a matriz fornecida e justificar cada classificação pelos efeitos no serviço e nos dados.
• Decidir, para o incidente do caso, a sequência de contenção imediata, erradicação e recuperação, indicando em cada passo o que se perde e o que se ganha.
• Definir o critério de regresso ao serviço, com as verificações que têm de estar cumpridas antes de repor cada sistema.
• Escrever o registo cronológico de decisões do incidente, com hora, decisão, fundamento e responsável.

Explicação

Responder a um incidente é uma sequência com seis momentos: preparação, detecção e análise, contenção, erradicação, recuperação e lições aprendidas. A preparação é a única que se faz antes e é a que determina se as outras correm bem. Quem não tem lista de contactos, acessos de emergência, cópias verificadas e critérios escritos, decide tudo no pior momento possível.

Contenção divide-se em imediata e de médio prazo. A imediata trava a hemorragia: isolar a máquina da rede, suspender contas comprometidas, bloquear a comunicação de saída para o destino observado, revogar sessões activas. A de médio prazo mantém o serviço a funcionar de forma degradada enquanto se prepara a erradicação. Isolar não é sempre desligar — desligar apaga a evidência volátil, e por vezes é preferível cortar a ligação de rede mantendo a máquina ligada.

Erradicar é retirar a presença do atacante: eliminar contas criadas, tarefas agendadas, chaves de acesso e componentes instalados; corrigir o caminho de entrada; e trocar todas as credenciais que possam ter sido comprometidas. Se o caminho de entrada não for corrigido, a recuperação limita-se a devolver ao atacante um sistema arrumado. Quando a profundidade do compromisso não é conhecida, a única via defensável é reinstalar a partir de fonte de confiança e restaurar dados de cópia anterior ao incidente.

Recuperar é repor o serviço com critério, não à pressa. Cada sistema só regressa quando se confirma que as credenciais foram trocadas, que o caminho de entrada foi fechado, que a vigilância reforçada está activa e que os dados restaurados são anteriores ao comprometimento. A ordem de reposição segue as dependências: primeiro identidades, depois dados, depois aplicações, por fim o acesso do público.

Duas coisas correm sempre mal quando não estão escritas antes. Primeira, quem decide: numa madrugada, sem decisor identificado, ou não se decide nada ou decide quem não tem mandato. Segunda, o registo cronológico: se não for escrito em tempo real, no dia seguinte ninguém reconstitui as horas, e a reconstituição é o que permite aprender e responder a quem pergunta.

Caso fictício: 14 de Setembro, 09h20, sala de reunião de Muteva

Onze dias depois da madrugada de 3 de Setembro, a equipa percebe o que aconteceu: conta de administração comprometida, conta nova com privilégios, exportação de 41 200 registos de processos, 2,4 gigabytes enviados para fora, registos parados e um processo desconhecido a correr desde então em SRV-BD.

São 09h20 de uma segunda-feira. Os balcões estão abertos, com 60 pessoas em fila. A cópia semanal falhou na sexta-feira; a última cópia verificada é de 29 de Agosto, anterior ao incidente.

A direcção pergunta três coisas: fechamos o atendimento? em quanto tempo volta? e temos de comunicar a alguém? A equipa tem de responder com critério e não com adivinhação.

Anexo A — Matriz de gravidade e cinco incidentes para classificar (fictícios)

Escala: G1 baixo, G2 moderado, G3 alto, G4 crítico. Os critérios estão na primeira linha; a coluna «Gravidade» é preenchida na actividade.

Anexo B — Estado dos recursos no momento da decisão (fictício)

Material de entrada da actividade.

Última cópia verificada dos processos: 29 de Agosto, restaurada com sucesso num ensaio feito nesse dia.

Cópia de 12 de Setembro: existe, nunca foi restaurada; é posterior ao comprometimento.

Registos de SRV-DIR: interrompidos entre 3 e 14 de Setembro, por paragem do serviço de envio.

Registos do recolector central: existem para as outras máquinas, sem interrupção.

Equipa disponível: três pessoas, uma das quais de férias e contactável.

Contactos: existe lista de telefones actualizada; não existe canal alternativo caso o correio institucional fique indisponível.

Atendimento: dois balcões abertos, com atendimento manual possível em papel, a metade do ritmo.

Trabalho prático

Trabalho em grupos de três pessoas, com os anexos A e B, em exercício de mesa, com 60 minutos de trabalho, seguidos de 15 minutos de partilha e síntese em plenário.

Exercício em papel. Esta parte é análise documental sobre material fornecido. Não é o laboratório e não pode ser registada como prática executada em ambiente.

Passo 1 (15 minutos). Classifiquem os cinco incidentes do anexo A e justifiquem cada gravidade numa linha. Digam também qual deles obrigaria a acordar alguém de madrugada.

Passo 2 (25 minutos). Para o caso das 09h20, escrevam a sequência de contenção imediata, com hora prevista para cada acção, dizendo em cada uma o que se ganha e o que se perde. Decidam explicitamente se o atendimento fecha ou continua em modo degradado, e fundamentem.

Passo 3 (20 minutos). Escrevam o critério de regresso ao serviço para cada sistema, indicando a ordem de reposição e as verificações obrigatórias antes de cada reposição. Decidam que cópia usar, entre a de 29 de Agosto e a de 12 de Setembro, e justifiquem.

Produto esperado: Matriz preenchida com justificações, plano de contenção com horas e trocas explicitadas, e critério de regresso ao serviço com ordem de reposição e escolha de cópia fundamentada.

Como o produto é apreciado

• I-3 é classificado como G4 por envolver dados de cidadãos exfiltrados, apesar de o serviço continuar a funcionar.
• A contenção prevê isolar sem desligar quando ainda houver evidência volátil a recolher, e diz o que se perde em cada opção.
• A decisão sobre o atendimento é fundamentada e considera o atendimento manual em papel como alternativa.
• A cópia escolhida é a de 29 de Agosto, por ser anterior ao comprometimento e ter restauro verificado; escolher a de 12 de Setembro sem verificação é assinalado como risco de restaurar o problema.
• A ordem de reposição começa pelas identidades e termina no acesso do público.
• O grupo escreve que a comunicação a entidades externas é decisão da direcção com apoio jurídico, sem inventar prazos legais.

Síntese em leitura fácil

• Seis momentos: preparar, detectar, conter, erradicar, recuperar, aprender. Preparar é o único que se faz antes.
• Conter é travar já. Isolar da rede nem sempre é desligar: desligar apaga a memória.
• Erradicar é tirar contas, tarefas e chaves do atacante e fechar a porta de entrada.
• Só se repõe um sistema quando as credenciais mudaram e a porta está fechada.
• Escrever hora, decisão, motivo e quem decidiu, enquanto acontece.

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.

1. Há uma cópia de 12 de Setembro, mais recente, e uma de 29 de Agosto, verificada. Qual se usa para restaurar a base de dados?
2. A equipa quer repor o portal de marcação primeiro, porque é o que o público vê. Faz sentido?

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 efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. Há uma cópia de 12 de Setembro, mais recente, e uma de 29 de Agosto, verificada. Qual se usa para restaurar a base de dados?

Resposta: A de 29 de Agosto. É anterior ao comprometimento de 3 de Setembro e o seu restauro já foi verificado. A de 12 de Setembro é posterior ao compromisso e pode conter as alterações do atacante; além disso nunca foi restaurada, pelo que não se sabe se funciona.

Comentário: Restaurar uma cópia posterior à intrusão pode repor a presença do atacante. A perda de dados entre as duas datas trata-se depois, com reconciliação a partir dos registos disponíveis.

Pergunta 2. A equipa quer repor o portal de marcação primeiro, porque é o que o público vê. Faz sentido?

Resposta: Não. A ordem segue as dependências e o risco: primeiro identidades, com credenciais trocadas e contas do atacante eliminadas; depois dados restaurados de cópia limpa; depois aplicações; e só no fim o acesso do público. Repor o portal antes disso expõe de novo um sistema ainda comprometido.

Comentário: A pressão para mostrar serviço reposto é real e tem de ser respondida com prazo comunicado e serviço degradado, não com reposição prematura.

Referências consultadas

• NIST Cybersecurity Framework — quadro voluntário de segurança cibernética — https://www.nist.gov/cyberframework (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Quadro de adesão voluntária organizado em seis funções: Governar, Identificar, Proteger, Detectar, Responder e Recuperar. Serve para organizar o trabalho de segurança e conversar sobre risco com a direcção; não é lei nem certificação.

Estas referências são quadros e guias técnicos internacionais de adesão voluntária. Não são lei moçambicana, não criam prazos nem obrigações legais e não conferem qualquer certificação.

Duração prevista: 90 minutos, em sessão presencial.

Todos os casos, instituições, endereços, registos e números usados nesta lição são fictícios e servem apenas de exercício.

Como o tempo desta lição está distribuído

• Acolhimento e objectivos: 10 minutos.
• Exposição: 25 minutos.
• Trabalho prático: 40 minutos.
• Partilha e síntese: 15 minutos.

Como trabalhamos na sala: um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem executa a meio do trabalho, de modo que ambas façam. Na partilha apresentam dois grupos, com tempo limitado; os restantes entregam por escrito e recebem comentário do formador. Marcar a lição como concluída é registo de aprendizagem e não é registo de assiduidade.

Objectivos da lição

• Preencher as sete secções obrigatórias de um plano de resposta a incidentes para a instituição fictícia, com nomes de funções, contactos alternativos e critérios de accionamento.
• Definir os níveis de gravidade e, para cada um, quem decide, em quanto tempo se reúne a equipa e quem é informado.
• Escrever o procedimento de preservação de evidência que acompanha o plano, com ordem de recolha, registo de custódia e regra de trabalho sobre cópias.
• Identificar, no plano fictício fornecido, pelo menos cinco lacunas que o tornariam inútil numa madrugada.

Explicação

Um plano de resposta a incidentes serve para tirar decisões do momento de pânico e passá-las para um momento de calma. Se durante o incidente for preciso discutir quem manda, o plano falhou antes de começar. Sete secções resolvem a maior parte: âmbito e definição do que conta como incidente; funções e responsabilidades com nomes; níveis de gravidade e critérios de accionamento; contactos e canais alternativos; procedimentos por tipo de incidente; preservação de evidência; e comunicação, interna e externa.

Funções, não pessoas apenas: coordenação do incidente, análise técnica, comunicação, ligação à direcção, registo cronológico. Numa equipa de três pessoas, uma acumula funções — o que importa é que esteja escrito quem acumula o quê e quem substitui cada um. Um plano com um único nome em todas as linhas falha no dia em que essa pessoa está de férias ou é ela própria a conta comprometida.

Canais alternativos são frequentemente esquecidos. Se o incidente afecta o correio electrónico institucional, convocar a equipa por correio institucional não funciona. O plano tem de indicar um segundo canal acordado, com números de telefone verificados, e essa lista tem de existir em papel, porque pode não haver acesso aos sistemas.

A preservação de evidência entra no plano e não num documento à parte, porque as decisões de contenção afectam a evidência. A regra escrita antes: recolher primeiro o volátil, calcular resumo criptográfico no momento, trabalhar sobre cópias, preencher a folha de custódia por peça. Quando houver hipótese de consequências disciplinares ou de participação às autoridades, quem decide é a direcção com apoio jurídico; a equipa técnica recolhe, preserva e documenta, e não decide sozinha nem antecipa qualificações jurídicas.

Por fim, um plano que nunca foi ensaiado é uma intenção. O ensaio de mesa, de noventa minutos, com um cenário e as pessoas reais, revela em cada edição o mesmo tipo de problemas: contactos desactualizados, ninguém sabe onde estão as cópias, ninguém tem acesso fora do horário, e a lista de sistemas críticos não existe. É trabalho barato com retorno alto.

Caso fictício: o plano de Muteva, aprovado em 2023 e nunca usado

Muteva tem um plano de resposta a incidentes de quatro páginas, aprovado em 2023. Define incidente como «qualquer evento que afecte os sistemas», nomeia como responsável «o sector de informática» e manda «comunicar de imediato à direcção».

Não tem níveis de gravidade, não tem contactos, não diz quem decide fora do horário, não fala de evidência e não indica onde estão as cópias de segurança. Na madrugada de 3 de Setembro, ninguém o abriu — e, se o tivesse aberto, não teria encontrado uma única instrução accionável.

Não é um plano mau por falta de vontade: é um plano escrito para ser aprovado, e não para ser usado. A diferença nota-se nos detalhes aborrecidos: nomes, números, horas e critérios.

Anexo A — Plano de resposta actual de Muteva (extracto fictício com lacunas)

Material de entrada. Contém lacunas deliberadas que a actividade pede para encontrar.

«1. Objecto. O presente plano estabelece os procedimentos a adoptar em caso de incidente informático.

2. Definição. Considera-se incidente qualquer evento que afecte o normal funcionamento dos sistemas.

3. Responsabilidade. Compete ao sector de informática detectar, analisar e resolver os incidentes.

4. Comunicação. Todos os incidentes são comunicados de imediato à direcção.

5. Recuperação. Os sistemas são repostos logo que possível, com recurso às cópias de segurança.

6. Disposições finais. O presente plano é revisto sempre que necessário.»

Anexo B — Dados da instituição para preencher o plano (fictícios)

Usar exclusivamente estes dados; não inventar contactos nem entidades.

Equipa de informática: r.sitoe (responsável, telefone 82-000-0001), a.chirindza (administradora de sistemas, 82-000-0002), j.matola (técnico de apoio, 82-000-0003).

Direcção: directora de serviços (82-000-0010), chefe de gabinete (82-000-0011).

Horário de funcionamento: 07h30 às 15h30, de segunda a sexta-feira. Fora deste horário não há escala definida.

Sistemas críticos por ordem declarada: directório de contas, base de dados de processos, portal de marcação, servidor de ficheiros, correio electrónico.

Cópias: disco externo no armário da sala técnica, cópia semanal à sexta-feira, feita manualmente pelo técnico de apoio; chave do armário com o responsável.

Fornecedores: empresa de desenvolvimento da aplicação (contrato terminado), fornecedor de correio em nuvem (apoio por portal), fornecedor de internet (linha de apoio 800-000-000).

Trabalho prático

Trabalho em grupos de três pessoas, com os anexos A e B em papel, com 40 minutos de trabalho, seguidos de 15 minutos de partilha e síntese em plenário.

Exercício em papel. Esta parte é análise documental sobre material fornecido. Não é o laboratório e não pode ser registada como prática executada em ambiente.

Passo 1 (10 minutos). Leiam o anexo A e listem as lacunas que tornariam o plano inútil numa madrugada. Escrevam pelo menos cinco, cada uma com a consequência prática.

Passo 2 (20 minutos). Escrevam as sete secções do plano novo usando apenas os dados do anexo B. Nas funções, indiquem titular e substituto. Nos níveis de gravidade, indiquem quem decide, em quanto tempo a equipa se reúne e quem é informado.

Passo 3 (10 minutos). Escrevam o procedimento de preservação de evidência que acompanha o plano, em não mais de dez linhas, e a regra sobre quem decide em matéria de participação a terceiros.

Produto esperado: Lista de lacunas com consequências, plano de sete secções preenchido com dados do anexo B e procedimento de preservação de evidência.

Como o produto é apreciado

• Entre as lacunas identificadas estão a ausência de níveis de gravidade, de contactos, de decisor fora do horário, de canal alternativo e de tratamento de evidência.
• Cada função tem titular e substituto; nenhuma linha fica com uma só pessoa.
• O plano prevê canal alternativo ao correio institucional, com números do anexo B.
• Os níveis de gravidade têm critério observável e não apenas adjectivos.
• O procedimento de evidência inclui ordem de volatilidade, resumo no momento da recolha e trabalho sobre cópias.
• A decisão de participar a terceiros é atribuída à direcção com apoio jurídico, sem invocar prazos legais inventados.

Síntese em leitura fácil

• O plano existe para não se discutir quem manda durante o incidente.
• Cada função tem titular e substituto. Um nome sozinho falha no dia de férias.
• Se o correio estiver em baixo, o plano tem de dizer por onde se fala. Em papel.
• Recolher a evidência pela ordem certa faz parte do plano, não é assunto à parte.
• Plano nunca ensaiado é intenção. Um ensaio de mesa por ano revela sempre falhas.

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.

1. O plano diz «comunicar de imediato à direcção». Porque é que isto não chega?
2. Durante a recolha, a equipa percebe que o caso pode ter consequências disciplinares. O que muda no procedimento técnico?

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 efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. O plano diz «comunicar de imediato à direcção». Porque é que isto não chega?

Resposta: Porque não diz a quem, por que via, com que informação mínima, nem o que fazer se não houver resposta. Fora do horário, «a direcção» não é um contacto. Uma instrução accionável indica nome, número, canal alternativo e prazo para escalar.

Comentário: A qualidade de um plano mede-se pela quantidade de decisões que já não é preciso tomar durante o incidente.

Pergunta 2. Durante a recolha, a equipa percebe que o caso pode ter consequências disciplinares. O que muda no procedimento técnico?

Resposta: O procedimento técnico não muda: continua a recolher pela ordem de volatilidade, com resumos e folhas de custódia. O que muda é quem decide os passos seguintes — a direcção, com apoio jurídico — e o rigor no registo, porque a evidência pode ser examinada por terceiros.

Comentário: A equipa técnica não qualifica juridicamente nem decide participações. Recolhe, preserva e documenta, para que quem decide possa decidir com base sólida.

Referências consultadas

• NIST Cybersecurity Framework — quadro voluntário de segurança cibernética — https://www.nist.gov/cyberframework (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Quadro de adesão voluntária organizado em seis funções: Governar, Identificar, Proteger, Detectar, Responder e Recuperar. Serve para organizar o trabalho de segurança e conversar sobre risco com a direcção; não é lei nem certificação.

Estas referências são quadros e guias técnicos internacionais de adesão voluntária. Não são lei moçambicana, não criam prazos nem obrigações legais e não conferem qualquer certificação.

Duração prevista: 90 minutos, em sessão presencial.

Todos os casos, instituições, endereços, registos e números usados nesta lição são fictícios e servem apenas de exercício.

Como o tempo desta lição está distribuído

• Acolhimento e objectivos: 10 minutos.
• Exposição: 25 minutos.
• Trabalho prático: 40 minutos.
• Partilha e síntese: 15 minutos.

Como trabalhamos na sala: um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem executa a meio do trabalho, de modo que ambas façam. Na partilha apresentam dois grupos, com tempo limitado; os restantes entregam por escrito e recebem comentário do formador. Marcar a lição como concluída é registo de aprendizagem e não é registo de assiduidade.

Objectivos da lição

• Escrever três mensagens sobre o mesmo incidente — para o público no balcão, para o pessoal interno e para a direcção — mantendo os factos coerentes e adaptando o que cada destinatário precisa de saber.
• Aplicar critérios de acessibilidade à mensagem pública: linguagem simples, frases curtas, aviso legível impresso, leitura em voz alta e alternativa para quem não usa internet.
• Identificar, nos três comunicados fictícios fornecidos, as afirmações que não podem ser feitas por não estarem apuradas e reescrevê-las.
• Definir o calendário de actualizações e o que se diz quando ainda não há informação nova.

Explicação

Durante um incidente comunica-se sempre, mesmo quando não há novidades — o silêncio é preenchido por rumor. A regra que sustenta tudo é a separação entre o que se sabe, o que se está a apurar e o que se vai fazer a seguir. Misturar estas três coisas produz comunicados que envelhecem mal e que obrigam a desmentidos.

Cada destinatário precisa de coisas diferentes, a partir dos mesmos factos. O cidadão no balcão precisa de saber se é atendido hoje, como, e quando voltar; não precisa de saber que servidor está em baixo. O pessoal interno precisa de saber o que não deve fazer — não usar determinado sistema, não reencaminhar mensagens, não tentar resolver por iniciativa própria — e a quem comunicar o que observar. A direcção precisa de impacto, prazo estimado, decisões pendentes e riscos. Os factos têm de ser os mesmos nas três mensagens: versões diferentes descobrem-se sempre e destroem a confiança.

Acessibilidade não é um extra da comunicação de incidente; é o que determina se a informação chega. Se o portal está em baixo, publicar apenas no portal não comunica nada. A mensagem pública precisa de existir em papel afixado à entrada, em letra grande e com bom contraste, dita em voz alta por quem recebe as pessoas, com linguagem simples e frases curtas, e com uma alternativa concreta para quem não usa internet nem telemóvel. Quem tem baixa visão, quem não lê com facilidade e quem não fala a língua do aviso são exactamente as pessoas que ficam de fora quando isto é esquecido.

Há afirmações que não se podem fazer nas primeiras horas, e que aparecem com frequência: «os dados não foram acedidos» quando ainda não se analisou; «o problema está resolvido» quando se está em contenção; «foi um ataque de fora» quando não está apurado; «não há risco para os cidadãos» quando não se sabe. Substituem-se por formulações verdadeiras e úteis: o que está confirmado, o que está em apuramento, e quando haverá informação nova.

Por fim, a comunicação a entidades externas — reguladores, parceiros, autoridades — é decisão da direcção, com apoio jurídico, e não da equipa técnica. Esta formação não indica prazos legais nem obrigações de notificação: essa verificação faz-se em concreto, na data, com a área jurídica da instituição.

Caso fictício: os avisos do dia 14 em Muteva

Às 10h00 do dia 14, com o incidente ainda em contenção, foi afixado à entrada um papel A4 impresso em letra pequena: «Serviços informáticos em manutenção. Agradecemos a compreensão.»

Às 10h30, uma mensagem interna dizia: «Houve um ataque informático. Os dados não foram comprometidos. Já está tudo controlado.» Nenhuma destas três frases estava apurada nesse momento.

No balcão, as pessoas continuavam a chegar sem saber se seriam atendidas. Quem não lia o papel — por não ver bem, por não ler com facilidade, ou por não passar pela entrada principal — não recebeu informação nenhuma. O atendimento manual em papel existia, mas ninguém o anunciou.

Anexo A — Factos apurados às 10h00 do dia 14 (fictícios)

Base factual comum às três mensagens. Não acrescentar nada que não conste desta lista.

Confirmado: uma conta de administração foi usada indevidamente na madrugada de 3 de Setembro.

Confirmado: foi criada uma conta adicional com privilégios e foram exportados 41 200 registos de processos.

Confirmado: houve transferência de 2,4 gigabytes para um destino externo.

Confirmado: o atendimento presencial pode continuar em papel, a ritmo mais lento, nos dois balcões.

Em apuramento: que dados concretos estavam nos registos exportados e se incluem documentos digitalizados.

Em apuramento: se outras contas foram usadas indevidamente.

Previsto: o portal de marcação em linha fica indisponível até nova informação; próxima actualização às 16h00.

Não determinado: a origem e a autoria do acesso.

Anexo B — Três comunicados propostos (fictícios, com afirmações indevidas)

Material de entrada para correcção.

Comunicado 1, para afixar: «Sistema em manutenção. Voltamos em breve.»

Comunicado 2, para o pessoal: «Fomos vítimas de um ataque externo. Os dados dos cidadãos não foram acedidos. A situação está controlada e resolvida.»

Comunicado 3, para a direcção: «Tudo sob controlo, sem impacto relevante. O sector de informática está a tratar do assunto e informará quando estiver concluído.»

Trabalho prático

Trabalho em grupos de três pessoas, com os anexos A e B em papel, com 40 minutos de trabalho, seguidos de 15 minutos de partilha e síntese em plenário.

Exercício em papel. Esta parte é análise documental sobre material fornecido. Não é o laboratório e não pode ser registada como prática executada em ambiente.

Passo 1 (10 minutos). Marquem, nos três comunicados do anexo B, todas as afirmações que não são sustentadas pelo anexo A. Escrevam ao lado por que razão cada uma é indevida.

Passo 2 (20 minutos). Reescrevam as três mensagens a partir dos factos do anexo A. A pública deve caber numa folha, em frases curtas, dizer se há atendimento hoje e como, e indicar quando haverá informação nova.

Passo 3 (10 minutos). Escrevam a lista de verificação de acessibilidade da mensagem pública e o calendário de actualizações, incluindo a frase-tipo a usar quando, à hora marcada, ainda não houver informação nova.

Produto esperado: Anexo B anotado, três mensagens reescritas e uma folha com a lista de acessibilidade e o calendário de actualizações.

Como o produto é apreciado

• Foram marcadas, no mínimo, as afirmações «ataque externo», «dados não acedidos», «resolvida» e «sem impacto relevante».
• A mensagem pública diz que há atendimento presencial em papel, a ritmo mais lento, e a hora da próxima actualização.
• As três mensagens assentam nos mesmos factos, sem contradições entre elas.
• A lista de acessibilidade inclui letra grande e contraste, afixação em mais do que um ponto, leitura em voz alta por quem recebe, linguagem simples e alternativa para quem não usa internet.
• A frase-tipo para «sem novidades» mantém a confiança sem inventar progresso.
• Nenhuma mensagem afirma obrigação legal de notificação nem prazos legais.

Síntese em leitura fácil

• Separar sempre: o que se sabe, o que se está a apurar, o que se vai fazer.
• Mesmos factos para todos; só muda o que cada destinatário precisa de saber.
• Se o portal está em baixo, o aviso tem de estar em papel e ser dito em voz alta.
• Letra grande, frases curtas, e uma alternativa para quem não usa internet.
• Comunicar mesmo sem novidades, à hora prometida.

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.

1. Porque é que «os dados dos cidadãos não foram acedidos» não pode ser dito às 10h00 do dia 14?
2. Chegou a hora da actualização prometida e não há informação nova. O que se comunica?

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 efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. Porque é que «os dados dos cidadãos não foram acedidos» não pode ser dito às 10h00 do dia 14?

Resposta: Porque está confirmado que 41 200 registos foram exportados e que houve transferência para fora; o que está em apuramento é o conteúdo concreto. A afirmação é contrariada pelos factos conhecidos e teria de ser desmentida mais tarde.

Comentário: Uma negação prematura custa mais do que o silêncio prudente. Diz-se o que está confirmado e o que está em apuramento, com hora da próxima actualização.

Pergunta 2. Chegou a hora da actualização prometida e não há informação nova. O que se comunica?

Resposta: Comunica-se à mesma: confirma-se que não há elementos novos, repete-se o que está em apuramento, mantém-se a informação prática sobre o atendimento e marca-se a hora seguinte.

Comentário: Cumprir a hora prometida, mesmo sem novidades, é o que sustenta a credibilidade das actualizações seguintes.

Referências consultadas

• NIST Cybersecurity Framework — quadro voluntário de segurança cibernética — https://www.nist.gov/cyberframework (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Quadro de adesão voluntária organizado em seis funções: Governar, Identificar, Proteger, Detectar, Responder e Recuperar. Serve para organizar o trabalho de segurança e conversar sobre risco com a direcção; não é lei nem certificação.

Estas referências são quadros e guias técnicos internacionais de adesão voluntária. Não são lei moçambicana, não criam prazos nem obrigações legais e não conferem qualquer certificação.

Duração prevista: 100 minutos, em sessão presencial.

Todos os casos, instituições, endereços, registos e números usados nesta lição são fictícios e servem apenas de exercício.

Como o tempo desta lição está distribuído

• Acolhimento e objectivos: 10 minutos.
• Exposição: 30 minutos.
• Trabalho prático: 45 minutos.
• Partilha e síntese: 15 minutos.

Como trabalhamos na sala: um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem executa a meio do trabalho, de modo que ambas façam. Na partilha apresentam dois grupos, com tempo limitado; os restantes entregam por escrito e recebem comentário do formador. Marcar a lição como concluída é registo de aprendizagem e não é registo de assiduidade.

Objectivos da lição

• Definir, para os cinco serviços da ficha, o tempo máximo de paragem tolerável e a perda máxima de dados tolerável, e explicar como cada valor determina a frequência das cópias.
• Avaliar o esquema de cópias fornecido contra a regra de três cópias, dois suportes e uma fora do local, identificando o que falha.
• Executar, em ambiente isolado, o restauro de uma cópia e verificar por comparação de resumos e por leitura dos dados que o restauro é íntegro e utilizável.
• Registar o tempo real de restauro medido e compará-lo com o tempo de paragem tolerável declarado.

Explicação

Continuidade responde a duas perguntas por serviço. Quanto tempo o serviço pode estar parado antes de o dano ser inaceitável? E quanta informação se pode perder, medida em tempo, desde a última cópia? A primeira determina a preparação para repor depressa; a segunda determina a frequência das cópias. Declarar quatro horas de paragem tolerável e fazer cópias uma vez por semana é uma contradição — significa aceitar perder até uma semana de trabalho.

A regra prática mais conhecida é três cópias, em dois tipos de suporte diferentes, com pelo menos uma fora do local. Cada elemento cobre uma falha: várias cópias cobrem corrupção; suportes diferentes cobrem defeito comum de um tipo de suporte; a cópia fora do local cobre incêndio, inundação e furto. Hoje acrescenta-se um quarto elemento: pelo menos uma cópia inalterável ou desligada, porque software de resgate procura e cifra as cópias acessíveis a partir da rede.

A parte que quase sempre falta é a verificação. Uma cópia que nunca foi restaurada é uma hipótese. Verificar tem três níveis: confirmar que o trabalho de cópia terminou sem erro; confirmar que a cópia se lê e que os resumos coincidem; e restaurar para um ambiente separado e abrir os dados, confirmando que a aplicação funciona com eles. Só o terceiro nível prova alguma coisa útil, e é o que se treina no laboratório.

Continuidade não é só técnica. Um serviço público pode continuar a funcionar em modo degradado — atendimento em papel, com registo posterior — e isso tem de estar preparado: formulários impressos, sequência de números, instruções para quem atende e regra de reconciliação quando o sistema voltar. Se a reconciliação não estiver pensada, o retorno gera duplicados e perde-se informação.

Finalmente, o tempo de restauro mede-se, não se estima. A primeira vez que uma equipa restaura a sério costuma demorar muito mais do que o esperado: procurar o suporte, encontrar a chave de cifra, instalar a ferramenta, esperar a cópia dos dados. Medir uma vez por ano, com cronómetro, e comparar com o tempo declarado é o exercício que torna o plano realista.

Caso fictício: as cópias de Muteva vistas de perto

Muteva faz uma cópia semanal, à sexta-feira, para um disco externo guardado no armário da sala técnica — a mesma sala onde estão os servidores. A cópia é manual e depende de o técnico de apoio estar presente.

Não há cópia fora do local, não há segundo tipo de suporte, e não há cópia desligada da rede durante a semana. A cópia de 12 de Setembro existe mas nunca foi lida. O último restauro verificado foi a 29 de Agosto.

Quando se perguntou quanto tempo demoraria repor a base de dados de processos, a resposta foi «umas duas horas». Ninguém tinha cronometrado. A base tem 41 200 registos e 180 gigabytes de documentos associados.

Anexo A — Serviços, tolerâncias declaradas e esquema de cópias actual (fictício)

Ficha de trabalho. As duas últimas colunas são preenchidas na actividade.

Trabalho prático

Trabalho em grupos de três pessoas, com o anexo A em papel, com 45 minutos de trabalho, seguidos de 15 minutos de partilha e síntese em plenário. Desses 45 minutos, 25 são do exercício em papel e 20 são do laboratório descrito mais abaixo. A explicação e a apreciação do produto decorrem nos blocos de exposição e de partilha, e não dentro deste tempo.

Exercício em papel. Esta parte é análise documental sobre material fornecido. Não é o laboratório e não pode ser registada como prática executada em ambiente.

Passo 1 (10 minutos). Preencham as duas colunas em falta: a perda máxima real que o esquema actual permite e se há contradição com a paragem tolerável declarada. Escrevam, para os dois casos mais graves, a frequência de cópia que seria coerente.

Passo 2 (10 minutos). Avaliem o esquema actual contra a regra de três cópias, dois suportes, uma fora do local, e uma inalterável ou desligada. Digam o que falha e proponham um esquema corrigido executável com os meios da instituição.

Passo 3 (5 minutos). Escrevam o procedimento de atendimento em modo degradado para o balcão: que formulário, que numeração, que instruções e como se faz a reconciliação quando o sistema voltar.

Produto esperado: Anexo A preenchido, avaliação do esquema de cópias com proposta corrigida e procedimento de modo degradado com regra de reconciliação.

Como o produto é apreciado

• A perda máxima real é identificada como até sete dias em todos os serviços com cópia semanal.
• A contradição é assinalada em todos os serviços: nenhuma paragem tolerável declarada é compatível com cópia semanal manual.
• A avaliação identifica a ausência de cópia fora do local, de segundo suporte e de cópia desligada, e o facto de o disco estar na mesma sala dos servidores.
• O correio em nuvem é identificado como sem cópia própria; a redundância do fornecedor não é aceite como cópia.
• O procedimento de modo degradado inclui numeração e reconciliação, evitando duplicados no retorno.

Laboratório em ambiente isolado — Restaurar e verificar uma cópia, medindo o tempo real

Regras do laboratório, sem excepção. Todos os alvos são máquinas virtuais do próprio laboratório, numa rede isolada e sem ligação à rede de produção da instituição. Nunca se usa como alvo um sistema real da instituição, de outra entidade ou de terceiros na internet, mesmo para «experimentar». Qualquer exercício de teste exige autorização escrita prévia da direcção, com âmbito, janela de tempo e pessoas identificadas. Não se descarrega, não se distribui e não se executa software malicioso real: a análise de ameaças é feita sobre indicadores, registos e descrições fornecidos no material. Não se pede conta pessoal nem pagamento de serviços.

Objectivo: Restaurar uma cópia de base de dados para um ambiente separado, verificar a integridade por resumos e a utilidade por leitura dos dados, e medir o tempo total.

Tempo: 20 minutos, dentro do bloco de trabalho prático desta lição. Os minutos do exercício em papel e os minutos do laboratório somam o tempo desse bloco e não se contam duas vezes.

Recursos e versões, preparados antes da sessão

• Máquina virtual «REST-LAB» com o motor de base de dados instalado e vazio, preparada pelo formador.
• Ficheiro de cópia «processos-29ago.dump» com dados fictícios (1 500 registos de exercício) e o respectivo resumo criptográfico publicado em papel.
• Ficheiro de cópia «processos-12set.dump», propositadamente truncado, com o resumo publicado que NÃO corresponde ao ficheiro.
• Cronómetro ou relógio com segundos, e folha de laboratório com campos para tempo de cada etapa.

Dependências ainda por preparar, não entregues com a lição

Enquanto qualquer um dos pontos seguintes estiver por preparar, o laboratório regista-se como pendente. Nenhum destes laboratórios foi ainda executado nem testado em sala pela equipa autora: os tempos e os resultados descritos são previsões a confirmar na primeira execução.

• A máquina «REST-LAB» com o motor de base de dados instalado não é entregue com o curso.
• Os ficheiros «processos-29ago.dump», «processos-12set.dump» truncado e os resumos publicados são gerados pelo formador com dados fictícios; o curso entrega o procedimento, os critérios e a folha de tempos.
• Este laboratório ainda não foi executado numa sala com formandos nem testado pela equipa autora: os 20 minutos previstos e os resultados descritos são estimativa a confirmar na primeira execução, e devem ser corrigidos no guião depois dela.

Preparação prévia, a cargo do formador

• Arrancar REST-LAB no dia anterior e confirmar que o motor de base de dados inicia e que a ferramenta de restauro está disponível.
• Tirar instantâneo «inicial» com a base vazia.
• Copiar os dois ficheiros de cópia para a máquina e imprimir a folha com os dois resumos publicados.
• Confirmar o isolamento da rede virtual.

Passos

1. Iniciar o cronómetro e registar a hora de início na folha.
2. Calcular o resumo criptográfico de «processos-29ago.dump» e compará-lo com o publicado. Registar o resultado antes de restaurar.
3. Restaurar essa cópia para REST-LAB, registando o tempo que a operação demora.
4. Abrir os dados restaurados e executar três verificações de conteúdo: contar os registos, ler o registo mais antigo e ler o mais recente. Registar os três resultados.
5. Repetir a verificação de resumo para «processos-12set.dump» e registar a não coincidência; não restaurar este ficheiro.
6. Parar o cronómetro e registar o tempo total, desde o início até à confirmação de que os dados são legíveis.

Verificação de sucesso

• O resumo de «processos-29ago.dump» coincide com o publicado.
• O restauro termina sem erro e a contagem devolve 1 500 registos.
• Os registos mais antigo e mais recente são legíveis e coerentes com o esperado.
• O resumo de «processos-12set.dump» não coincide com o publicado, e o grupo regista que essa cópia não é utilizável.
• O tempo total está registado em minutos e é comparado, por escrito, com as duas horas de paragem tolerável declaradas.

Reversão ao estado inicial

• Restaurar o instantâneo «inicial» de REST-LAB, deixando a base vazia.
• Confirmar que a base está vazia depois da reposição.
• Apagar os ficheiros de cópia copiados para a máquina.

Se o ambiente não estiver disponível: análise offline

A análise offline permite estudar o material e chegar às mesmas conclusões no papel, mas não equivale à execução. Quando se recorre a ela, a lição é registada como análise documental e o laboratório fica pendente, para ser reagendado.

• Comparar à vista os resumos impressos dos dois ficheiros com os resumos publicados e identificar qual não coincide.
• Percorrer no papel o registo de uma operação de restauro fornecida pelo formador, com as marcas de tempo de cada etapa, e somar o tempo total.
• Comparar esse tempo com a paragem tolerável declarada e escrever a conclusão.
• Registar a lição como análise documental e o laboratório como pendente, a reagendar.

Síntese em leitura fácil

• Duas perguntas por serviço: quanto tempo pode estar parado e quanta informação se pode perder.
• Cópia semanal com duas horas de paragem tolerável é uma contradição.
• Três cópias, dois suportes, uma fora do local, e uma desligada da rede.
• Cópia nunca restaurada é uma esperança. Restaurar e abrir os dados é que prova.
• Medir o tempo de restauro com relógio. A primeira vez demora sempre mais do que se pensa.

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.

1. O relatório da ferramenta diz «cópia concluída com sucesso» todas as semanas. Isto prova que a instituição consegue recuperar?
2. O restauro no laboratório demorou 55 minutos com 1 500 registos. A base real tem 41 200 registos e 180 gigabytes de documentos. O que se conclui para a paragem tolerável de duas horas?

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 efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. O relatório da ferramenta diz «cópia concluída com sucesso» todas as semanas. Isto prova que a instituição consegue recuperar?

Resposta: Não. Prova que o trabalho de cópia terminou sem erro registado. Não prova que o ficheiro se lê, que está completo, que a chave de cifra existe, nem que a aplicação funciona com os dados restaurados. Só o restauro de ensaio, com leitura dos dados, prova isso.

Comentário: É exactamente o caso do ficheiro de 12 de Setembro do laboratório: a cópia existe, o relatório não acusou nada, e o ficheiro não serve.

Pergunta 2. O restauro no laboratório demorou 55 minutos com 1 500 registos. A base real tem 41 200 registos e 180 gigabytes de documentos. O que se conclui para a paragem tolerável de duas horas?

Resposta: Que a tolerância declarada não está demonstrada. O tempo cresce com o volume e com a procura do suporte e da chave, pelo que é preciso medir com dados de volume realista antes de manter as duas horas ou de as rever.

Comentário: Extrapolar linearmente também não é seguro. O valor honesto vem de uma medição com volume próximo do real, registada e datada.

Referências consultadas

• NIST Cybersecurity Framework — quadro voluntário de segurança cibernética — https://www.nist.gov/cyberframework (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Quadro de adesão voluntária organizado em seis funções: Governar, Identificar, Proteger, Detectar, Responder e Recuperar. Serve para organizar o trabalho de segurança e conversar sobre risco com a direcção; não é lei nem certificação.

Estas referências são quadros e guias técnicos internacionais de adesão voluntária. Não são lei moçambicana, não criam prazos nem obrigações legais e não conferem qualquer certificação.

Duração prevista: 100 minutos, em sessão presencial.

Todos os casos, instituições, endereços, registos e números usados nesta lição são fictícios e servem apenas de exercício.

Como o tempo desta lição está distribuído

• Acolhimento e objectivos: 10 minutos.
• Exposição: 30 minutos.
• Trabalho prático: 45 minutos.
• Partilha e síntese: 15 minutos.

Como trabalhamos na sala: um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem executa a meio do trabalho, de modo que ambas façam. Na partilha apresentam dois grupos, com tempo limitado; os restantes entregam por escrito e recebem comentário do formador. Marcar a lição como concluída é registo de aprendizagem e não é registo de assiduidade.

Objectivos da lição

• Percorrer, em equipa e dentro do tempo, a sequência completa de um incidente de laboratório: alerta, triagem, recolha de evidência, contenção, decisão de recuperação e relatório.
• Justificar cada decisão tomada durante o exercício por referência ao que estava escrito no plano e ao que foi observado, e não por intuição.
• Produzir um relatório de incidente de duas páginas com cronologia, factos, evidência recolhida, decisões, estado final e recomendações.
• Identificar, na revisão final, pelo menos três melhorias concretas ao plano e às regras de detecção, com responsável e prazo.

Explicação

Esta lição não introduz matéria nova: junta o que foi trabalhado nas catorze anteriores e submete-o à prova do tempo e da pressão. A aprendizagem está na sequência completa, que raramente se experimenta antes de um incidente real.

A equipa organiza-se por funções antes de começar, como definido na lição sobre o plano: coordenação, análise técnica, registo cronológico e comunicação. A função de registo é a que mais vezes é sacrificada e a que mais falta faz depois — sem cronologia escrita em tempo real, o relatório é reconstituição de memória.

A triagem responde a três perguntas em poucos minutos: isto é um incidente ou um falso positivo? qual a gravidade segundo a matriz? e há algo a conter já? Não é o momento de perceber tudo; é o momento de decidir se se acorda alguém e se se corta alguma coisa.

Durante o exercício, cada decisão tem de ser fundamentada e registada com hora. É aqui que se vê se as lições anteriores foram assimiladas: conter sem apagar a memória, escolher a cópia anterior ao comprometimento, trocar credenciais antes de repor, e não afirmar em comunicado o que não está apurado.

O tempo é parte do exercício e não um detalhe de organização. Numa situação real há pressão de várias direcções ao mesmo tempo: a direcção quer uma resposta, os balcões querem saber se atendem, e a análise técnica ainda não tem conclusões. A disciplina que resolve isto é decidir o que é suficiente para o passo seguinte, em vez de esperar pela certeza. Contém-se com informação incompleta, comunica-se o que está confirmado, e continua-se a apurar. Quem espera pela certeza para agir perde, normalmente, a janela de contenção.

O relatório final não é burocracia: é o que permite à instituição aprender e responder a quem pergunta. Duas páginas chegam, desde que tenham cronologia, factos separados de hipóteses, evidência com custódia, decisões com fundamento, estado final e recomendações com responsável e prazo. O que transforma o relatório em melhoria é a revisão feita a frio, dias depois, com a pergunta certa: não «de quem foi a culpa», mas «que condição permitiu que isto acontecesse e não fosse detectado». Culpar pessoas faz com que o incidente seguinte seja escondido; corrigir condições faz com que seja detectado mais cedo.

Caso fictício: cenário do exercício — alerta das 08h47

Durante o exercício, o recolector de registos do laboratório gera um alerta às 08h47: cinco autenticações falhadas seguidas de sucesso na conta «j.matola», a partir de um endereço da rede de laboratório que não corresponde ao posto habitual.

Minutos depois há um segundo alerta: criação de uma tarefa agendada em SRV-FIC-LAB e uma ligação de saída persistente. Os balcões do cenário estão abertos e a direcção fictícia pede informação às 09h30, a meio do exercício.

O cenário é conduzido pelo formador, que entrega novos elementos em envelopes à medida que o tempo passa. Nada disto envolve sistemas reais: todo o exercício decorre nas máquinas virtuais do laboratório.

Anexo A — Envelopes do exercício (conteúdo fictício, entregue pelo formador)

Os grupos não abrem os envelopes antes da hora indicada pelo formador.

Envelope 1 (minuto 0) — Texto do alerta das 08h47 e ligação para a consola do recolector do laboratório.

Envelope 2 (minuto 10) — Saída da listagem de processos de SRV-FIC-LAB, com um processo de demonstração inofensivo a correr de pasta temporária.

Envelope 3 (minuto 20) — Pergunta da direcção: «temos de fechar o atendimento?», a responder por escrito em três frases.

Envelope 4 (minuto 30) — Informação de que a cópia mais recente é posterior ao primeiro alerta e nunca foi restaurada.

Envelope 5 (minuto 40) — Novo alerta indicando tentativa de acesso a partir de uma segunda conta.

Anexo B — Grelha de avaliação do exercício (usada pelo formador e pelos grupos)

Os grupos recebem a grelha no início e avaliam-se a si próprios no fim.

Funções atribuídas e registo cronológico iniciado nos primeiros cinco minutos.

Triagem feita com a matriz de gravidade e decisão de contenção fundamentada.

Evidência recolhida pela ordem de volatilidade, com resumos e folhas de custódia.

Resposta à direcção assente apenas em factos apurados.

Decisão de cópia justificada e credenciais trocadas antes da reposição.

Relatório entregue dentro do tempo, com as seis secções pedidas.

Trabalho prático

Trabalho em equipas de quatro a cinco pessoas, com funções atribuídas, em exercício cronometrado, com 45 minutos de trabalho, seguidos de 15 minutos de partilha e síntese em plenário. Desses 45 minutos, 25 são do exercício em papel e 20 são do laboratório descrito mais abaixo. A explicação e a apreciação do produto decorrem nos blocos de exposição e de partilha, e não dentro deste tempo.

Exercício em papel. Esta parte é análise documental sobre material fornecido. Não é o laboratório e não pode ser registada como prática executada em ambiente.

Passo 1 (5 minutos). Atribuam funções — coordenação, análise técnica, registo cronológico, comunicação — e abram a folha de registo com a hora de início.

Passo 2 (15 minutos). Conduzam o incidente à medida que os envelopes chegam. Cada decisão entra na folha com hora, fundamento e quem decidiu. A resposta à direcção é escrita, em três frases, apenas com factos apurados.

Passo 3 (5 minutos). Escrevam o relatório de duas páginas com as seis secções: cronologia, factos, evidência com custódia, decisões com fundamento, estado final e recomendações com responsável e prazo.

Produto esperado: Folha de registo cronológico completa, resposta escrita à direcção e relatório de incidente com as seis secções.

Como o produto é apreciado

• O registo cronológico começou nos primeiros cinco minutos e tem horas reais, não reconstituídas no fim.
• A triagem usa a matriz de gravidade e não a impressão pessoal.
• A contenção preserva a evidência volátil quando ainda há recolha por fazer, e a escolha é justificada.
• A resposta à direcção não contém afirmações não apuradas.
• A cópia escolhida é anterior ao alerta inicial e a troca de credenciais antecede qualquer reposição.
• As recomendações têm responsável e prazo; recomendações sem dono não contam.

Laboratório em ambiente isolado — Exercício integrado nas máquinas virtuais do laboratório

Regras do laboratório, sem excepção. Todos os alvos são máquinas virtuais do próprio laboratório, numa rede isolada e sem ligação à rede de produção da instituição. Nunca se usa como alvo um sistema real da instituição, de outra entidade ou de terceiros na internet, mesmo para «experimentar». Qualquer exercício de teste exige autorização escrita prévia da direcção, com âmbito, janela de tempo e pessoas identificadas. Não se descarrega, não se distribui e não se executa software malicioso real: a análise de ameaças é feita sobre indicadores, registos e descrições fornecidos no material. Não se pede conta pessoal nem pagamento de serviços.

Objectivo: Executar o ciclo completo de resposta num incidente simulado, usando o recolector, as máquinas e os procedimentos das lições anteriores.

Tempo: 20 minutos, dentro do bloco de trabalho prático desta lição. Os minutos do exercício em papel e os minutos do laboratório somam o tempo desse bloco e não se contam duas vezes.

Recursos e versões, preparados antes da sessão

• As máquinas virtuais «SIEM-LAB», «SRV-FIC-LAB», «EST-FORENSE» e «REST-LAB» das lições anteriores, restauradas aos instantâneos iniciais.
• Ficheiro de registos do cenário «ensaio-integrado.log», preparado pelo formador com a sequência do exercício.
• Processo de demonstração inofensivo, o mesmo da lição de forense, com código-fonte disponível em papel.
• Envelopes do anexo A impressos e selados, folhas de registo cronológico, folhas de custódia e cronómetro.

Dependências ainda por preparar, não entregues com a lição

Enquanto qualquer um dos pontos seguintes estiver por preparar, o laboratório regista-se como pendente. Nenhum destes laboratórios foi ainda executado nem testado em sala pela equipa autora: os tempos e os resultados descritos são previsões a confirmar na primeira execução.

• Depende de todas as máquinas das lições anteriores («SIEM-LAB», «SRV-FIC-LAB», «EST-FORENSE», «REST-LAB»). Cada laboratório anterior que tenha ficado pendente reduz este exercício à parte documental correspondente.
• O ficheiro «ensaio-integrado.log» é montado pelo formador a partir do cenário entregue; não vem pronto com o curso.
• Este laboratório ainda não foi executado numa sala com formandos nem testado pela equipa autora: os 20 minutos previstos e os resultados descritos são estimativa a confirmar na primeira execução, e devem ser corrigidos no guião depois dela.

Preparação prévia, a cargo do formador

• Restaurar os instantâneos iniciais de todas as máquinas e confirmar que arrancam e comunicam entre si na rede isolada.
• Importar previamente «ensaio-integrado.log» para SIEM-LAB e confirmar que a regra criada na lição de monitorização dispara com ele.
• Confirmar, mais uma vez, o isolamento da rede virtual.
• Preparar os cinco envelopes e o relógio do exercício.

Passos

1. Arrancar as máquinas e confirmar o alerta inicial no recolector, registando a hora observada.
2. Fazer a triagem com a matriz de gravidade e decidir, por escrito, se há contenção imediata a executar.
3. Recolher a evidência em SRV-FIC-LAB pela ordem de volatilidade, com resumos e folhas de custódia, como na lição de forense.
4. Executar a contenção decidida — isolar a máquina na rede virtual, suspender a conta comprometida — registando hora e efeito observado.
5. Restaurar em REST-LAB a cópia escolhida e verificar a integridade por resumo antes de a dar por boa.
6. Encerrar o exercício com o estado final registado e o relatório escrito dentro do tempo.

Verificação de sucesso

• O alerta inicial foi observado na consola do recolector e a hora registada coincide com a do cenário.
• Existem pelo menos quatro peças de evidência com folha de custódia e resumo coincidente.
• A contenção executada é observável: a máquina isolada deixa de comunicar e a conta suspensa deixa de autenticar.
• O restauro em REST-LAB conclui e a verificação de resumo confirma a integridade da cópia escolhida.
• O relatório de duas páginas é entregue no tempo, com as seis secções e a cronologia coerente com as folhas de registo.

Reversão ao estado inicial

• Restaurar os instantâneos iniciais das quatro máquinas.
• Confirmar que o recolector volta ao estado sem regras nem ficheiros importados e que REST-LAB volta a ter a base vazia.
• Recolher envelopes, folhas de custódia e registos para a revisão final da lição seguinte.

Se o ambiente não estiver disponível: análise offline

A análise offline permite estudar o material e chegar às mesmas conclusões no papel, mas não equivale à execução. Quando se recorre a ela, a lição é registada como análise documental e o laboratório fica pendente, para ser reagendado.

• Conduzir o exercício integralmente em mesa, com os cinco envelopes e as saídas impressas de registos, processos e ligações.
• Manter o cronómetro, as funções e o registo cronológico: a parte de decisão treina-se igualmente em mesa.
• Escrever o relatório com a evidência impressa, indicando expressamente que a recolha não foi executada em ambiente.
• Registar a lição como exercício de mesa e o laboratório como pendente, a reagendar.

Síntese em leitura fácil

• Primeiro distribuir funções e começar a escrever as horas. Depois pensar.
• Triagem: é incidente? que gravidade? há algo a cortar já?
• Cada decisão fica escrita com hora, motivo e quem decidiu.
• À direcção só se diz o que está apurado.
• O relatório tem cronologia, factos, evidência, decisões, estado e recomendações com dono 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.

1. A meio do exercício a equipa percebe que não iniciou o registo cronológico. O que se faz?
2. A equipa conseguiu conter, restaurar e escrever o relatório dentro do tempo. Pode concluir que a instituição está preparada para um incidente real?

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 efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. A meio do exercício a equipa percebe que não iniciou o registo cronológico. O que se faz?

Resposta: Começa-se imediatamente, marcando com clareza o que é registo em tempo real e o que é reconstituição a partir de memória e de registos das máquinas. Não se escreve reconstituição como se fosse observação directa.

Comentário: A honestidade da cronologia é o que lhe dá valor. Misturar reconstituição com observação compromete o relatório inteiro.

Pergunta 2. A equipa conseguiu conter, restaurar e escrever o relatório dentro do tempo. Pode concluir que a instituição está preparada para um incidente real?

Resposta: Não. Pode concluir que, neste cenário, com estas pessoas presentes, com o ambiente a funcionar e em horário de trabalho, a sequência foi cumprida. Um incidente real acontece com pessoas ausentes, sistemas em produção e pressão externa; o exercício mede preparação, não garante resultado.

Comentário: É a mesma distinção de todo o curso: competência demonstrada em laboratório não é o mesmo que capacidade organizacional comprovada em produção.

Referências consultadas

• NIST Cybersecurity Framework — quadro voluntário de segurança cibernética — https://www.nist.gov/cyberframework (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Quadro de adesão voluntária organizado em seis funções: Governar, Identificar, Proteger, Detectar, Responder e Recuperar. Serve para organizar o trabalho de segurança e conversar sobre risco com a direcção; não é lei nem certificação.
• OWASP Web Security Testing Guide — guia de testes de segurança de aplicações web — https://owasp.org/projects/web-security-testing-guide (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Guia aberto que descreve, por categorias, o que testar numa aplicação web e como registar o que se encontra. Dá estrutura ao teste autorizado e ao relatório; é uma referência comunitária, não uma norma obrigatória.

Estas referências são quadros e guias técnicos internacionais de adesão voluntária. Não são lei moçambicana, não criam prazos nem obrigações legais e não conferem qualquer certificação.

Duração prevista: 100 minutos, em sessão presencial.

Todos os casos, instituições, endereços, registos e números usados nesta lição são fictícios e servem apenas de exercício.

Como o tempo desta lição está distribuído

• Acolhimento e objectivos: 10 minutos.
• Exposição: 30 minutos.
• Trabalho prático: 45 minutos.
• Partilha e síntese: 15 minutos.

Como trabalhamos na sala: um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem executa a meio do trabalho, de modo que ambas façam. Na partilha apresentam dois grupos, com tempo limitado; os restantes entregam por escrito e recebem comentário do formador. Marcar a lição como concluída é registo de aprendizagem e não é registo de assiduidade.

Objectivos da lição

• Distinguir, com exemplos, norma internacional, quadro voluntário, guia técnico, política interna e obrigação legal, indicando de onde vem a força de cada um.
• Escrever uma política de segurança da informação de uma página com âmbito, princípios, responsabilidades, regras obrigatórias, excepções e revisão.
• Construir o plano de melhoria a partir das recomendações do exercício integrado, com responsável, prazo, evidência de conclusão e indicador.
• Definir quatro indicadores de segurança mensuráveis com os dados que a instituição realmente tem.

Explicação

Há que separar coisas que se confundem com frequência. Uma norma internacional é um documento técnico publicado por um organismo de normalização, cuja adopção é voluntária salvo se um contrato ou uma lei a tornar exigível. Um quadro como o de segurança cibernética do NIST organiza o trabalho em funções e também é de adesão voluntária. Um guia como o de testes de aplicações da OWASP é uma referência comunitária aberta. Uma política interna é aprovada pela direcção e vincula quem trabalha na instituição. Uma obrigação legal decorre de lei ou regulamento aplicável, e a sua identificação é matéria jurídica, a verificar em concreto com a área jurídica da instituição — esta formação não enuncia obrigações nem prazos legais moçambicanos e não confere qualquer certificação.

Uma política de segurança útil cabe numa página e é lida. Precisa de âmbito (a quem e a que sistemas se aplica), princípios (privilégio mínimo, responsabilidade nominal, registo), responsabilidades por função, um conjunto curto de regras obrigatórias, um mecanismo de excepção com prazo e aprovação, e uma data de revisão. Políticas de trinta páginas com tudo lá dentro não são cumpridas nem verificadas, e a sua existência dá uma falsa sensação de cobertura.

O mecanismo de excepção é o que distingue uma política aplicável de uma política ignorada. Haverá sempre casos em que a regra não pode ser cumprida — um sistema antigo que não suporta segundo factor, por exemplo. Se não existir forma de registar a excepção, com prazo e com quem a autorizou, o que acontece é o incumprimento silencioso e generalizado.

Melhoria contínua faz-se com uma lista curta e viva, não com relatórios anuais. Cada linha tem: o que se vai fazer, quem, até quando, qual a evidência que prova a conclusão, e que indicador melhora. Sem evidência de conclusão, as listas enchem-se de itens «em curso» há dois anos.

Os indicadores devem ser poucos e construídos com dados que existam. Quatro que costumam ser exequíveis: percentagem de sistemas críticos com cópia restaurada e verificada nos últimos noventa dias; tempo mediano entre a divulgação de uma falha grave com exploração observada e a sua correcção nos sistemas expostos; número de contas privilegiadas e quantas delas foram confirmadas na última revisão de acessos; e número de ensaios de resposta realizados no ano, com melhorias fechadas. Um indicador que ninguém consegue calcular com os dados disponíveis é um indicador inútil, por muito bem que soe em relatório.

Caso fictício: o que ficou por fazer em Muteva, doze semanas depois

Doze semanas depois do incidente, Muteva tem uma lista de vinte e três recomendações, das quais quinze estão «em curso», seis «por iniciar» e duas concluídas. Nenhuma tem prazo e apenas quatro têm responsável.

A direcção aprovou entretanto uma política de segurança de vinte e oito páginas, adaptada de um modelo encontrado na internet, que menciona certificações e procedimentos que a instituição não tem. Ninguém a leu por inteiro e nenhuma das regras é verificada.

As duas recomendações concluídas foram as que tinham dono: trocar as credenciais de administração e passar a guardar uma cópia fora da sala técnica. Não é coincidência.

Anexo A — Dez afirmações para classificar (fictícias)

Classificar cada uma como norma internacional, quadro voluntário, guia técnico, política interna, obrigação contratual ou afirmação indevida.

Trabalho prático

Trabalho em grupos de três pessoas, com o anexo A e as recomendações do exercício integrado, com 45 minutos de trabalho, seguidos de 15 minutos de partilha e síntese em plenário.

Exercício em papel. Esta parte é análise documental sobre material fornecido. Não é o laboratório e não pode ser registada como prática executada em ambiente.

Passo 1 (10 minutos). Classifiquem as dez afirmações do anexo A e, para as que forem indevidas, escrevam a formulação correcta.

Passo 2 (20 minutos). Escrevam a política de segurança de uma página para a instituição fictícia, com âmbito, princípios, responsabilidades, cinco a sete regras obrigatórias, mecanismo de excepção e data de revisão.

Passo 3 (15 minutos). Transformem as recomendações que a vossa equipa escreveu no exercício integrado num plano de melhoria com responsável, prazo, evidência de conclusão e indicador associado. Definam também os quatro indicadores que a instituição consegue calcular com os dados que tem.

Produto esperado: Anexo A classificado com correcções, política de uma página e plano de melhoria com indicadores.

Como o produto é apreciado

• As afirmações 2, 5, 8 e 10 são classificadas como indevidas e reescritas: não há certificação por aplicar um quadro; o catálogo não obriga instituições moçambicanas; boas práticas não equivalem a conformidade legal; e nenhum guia garante segurança.
• A política cabe numa página e tem mecanismo de excepção com prazo e aprovação.
• As regras obrigatórias são verificáveis: cada uma permite dizer se está cumprida ou não.
• Cada linha do plano de melhoria tem responsável, prazo e evidência de conclusão.
• Os quatro indicadores são calculáveis com os dados disponíveis e o grupo diz de onde vem cada número.

Síntese em leitura fácil

• Norma, quadro, guia, política e lei são coisas diferentes. Só a política interna e a lei obrigam, cada uma à sua maneira.
• Aplicar um quadro internacional não dá certificação nem conformidade legal.
• A política cabe numa página e diz o que é obrigatório, quem responde e como se pede excepção.
• Sem prazo, sem dono e sem prova de conclusão, a recomendação fica «em curso» para sempre.
• Poucos indicadores, calculáveis com os dados que existem.

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.

1. Um relatório interno afirma que a instituição «está em conformidade por seguir boas práticas internacionais». Que problema tem esta frase?
2. Um sistema antigo não suporta autenticação multifactor, exigida pela política. Qual é o caminho correcto?

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 efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. Um relatório interno afirma que a instituição «está em conformidade por seguir boas práticas internacionais». Que problema tem esta frase?

Resposta: Confunde adesão voluntária a boas práticas com conformidade legal. Seguir um quadro internacional pode melhorar a segurança e não diz nada sobre cumprimento de leis ou contratos, que é matéria a verificar em concreto com a área jurídica.

Comentário: A frase correcta é descritiva: «adoptámos o quadro X como referência de organização do trabalho», sem qualquer conclusão jurídica.

Pergunta 2. Um sistema antigo não suporta autenticação multifactor, exigida pela política. Qual é o caminho correcto?

Resposta: Registar uma excepção formal, com justificação técnica, medidas compensatórias — restringir o acesso à rede, reduzir o número de contas, reforçar a vigilância — prazo de validade e aprovação de quem tem mandato, com data de reavaliação.

Comentário: Excepção registada é gestão; excepção silenciosa é incumprimento. A diferença está em existir prazo e alguém que a autorizou.

Referências consultadas

• NIST Cybersecurity Framework — quadro voluntário de segurança cibernética — https://www.nist.gov/cyberframework (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Quadro de adesão voluntária organizado em seis funções: Governar, Identificar, Proteger, Detectar, Responder e Recuperar. Serve para organizar o trabalho de segurança e conversar sobre risco com a direcção; não é lei nem certificação.
• CISA Known Exploited Vulnerabilities Catalog — vulnerabilidades exploradas conhecidas — https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Catálogo público de vulnerabilidades com exploração observada no mundo real. Usa-se como entrada para priorizar correcções: uma falha que consta do catálogo sobe na fila. Os prazos que o catálogo indica aplicam-se a organismos federais dos Estados Unidos e não a instituições moçambicanas.
• OWASP Web Security Testing Guide — guia de testes de segurança de aplicações web — https://owasp.org/projects/web-security-testing-guide (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Guia aberto que descreve, por categorias, o que testar numa aplicação web e como registar o que se encontra. Dá estrutura ao teste autorizado e ao relatório; é uma referência comunitária, não uma norma obrigatória.

Estas referências são quadros e guias técnicos internacionais de adesão voluntária. Não são lei moçambicana, não criam prazos nem obrigações legais e não conferem qualquer certificação.

O que a lei exige

A pessoa com deficiência tem direito de acesso ao ambiente físico, transporte, informação e tecnologias e sistemas de comunicação com base no desenho universal e ajustamento razoável.

O que significa na prática para um servidor público

Ao criar ou escolher um serviço, comece por torná-lo utilizável pelo maior número de pessoas. Quando uma pessoa ainda encontra uma barreira, faça o ajustamento adequado à sua necessidade.

Exemplo concreto de serviço digital moçambicano

No Portal do Governo de Moçambique, um formulário deve poder ser preenchido só com o teclado e lido por um leitor de ecrã.

Fonte: Lei n.º 10/2024, de 7 de Junho, artigo 16.

O que a lei exige

As entidades públicas e privadas que prestam serviços públicos devem procurar disponibilizar informação em formatos acessíveis. O Estado deve garantir formação de comunicadores e agentes do Estado em língua de sinais.

O que significa na prática para um servidor público

Publique a mesma informação em formatos que pessoas diferentes consigam usar. Use texto claro, documentos acessíveis, legendas, áudio e Língua de Sinais Moçambicana quando necessário.

Exemplo concreto de serviço digital moçambicano

Num aviso publicado num portal de um ministério, disponibilize texto acessível, versão áudio e vídeo com legendas e interpretação em Língua de Sinais Moçambicana.

Fonte: Lei n.º 10/2024, de 7 de Junho, artigo 17.

O que a lei exige

Os processos de contratação de empreitadas, fornecimento de bens e prestação de serviços devem ter em conta as necessidades da pessoa com deficiência.

O que significa na prática para um servidor público

Inclua requisitos de acessibilidade desde o caderno de encargos. Avalie esses requisitos antes de contratar. Verifique o seu cumprimento na entrega.

Exemplo concreto de serviço digital moçambicano

Na contratação de um sistema de marcação de consultas para uma unidade pública de saúde, exija navegação por teclado, compatibilidade com leitor de ecrã e atendimento alternativo acessível.

Fonte: Lei n.º 10/2024, de 7 de Junho, artigo 20.

O que a lei exige

A pessoa com deficiência tem direito à educação em instituições públicas e privadas. O Estado deve adequar metodologias, materiais, infra-estruturas, mobiliário e equipamento. Deve também incluir matérias sobre deficiência na formação de professores, quadros administrativos e gestores.

O que significa na prática para um servidor público

Planeie a formação para diferentes formas de aprender e participar. Dê materiais acessíveis. Garanta que a sala, a plataforma e os equipamentos não criam barreiras.

Exemplo concreto de serviço digital moçambicano

Numa plataforma pública de ensino à distância, disponibilize os materiais em texto acessível e áudio. Legende os vídeos. Permita concluir as actividades sem usar o rato.

Fonte: Lei n.º 10/2024, de 7 de Junho, artigo 24.

O que a lei exige

O Estado promove a recolha, a análise, o armazenamento e a divulgação de dados sobre pessoas com deficiência em todas as esferas da vida.

O que significa na prática para um servidor público

Recolha apenas os dados necessários, com uma finalidade clara. Proteja a informação individual. Use os dados agregados para melhorar políticas e serviços.

Exemplo concreto de serviço digital moçambicano

Num serviço digital de inscrição para formação pública, o tipo de deficiência é opcional e autodeclarado. A pessoa pode alterá-lo ou removê-lo. Os relatórios não identificam indivíduos.

Fonte: Lei n.º 10/2024, de 7 de Junho, artigo 30.

O que a lei exige

O Estado garante a produção estatística com indicadores que permitam desagregar os dados por sexo, idade, tipo de deficiência, causas, prevalência e outras variáveis relevantes.

O que significa na prática para um servidor público

Prepare os sistemas para produzir indicadores desagregados. Ao divulgar, proteja grupos pequenos para impedir a identificação das pessoas.

Exemplo concreto de serviço digital moçambicano

No Painel Nacional desta plataforma, os resultados podem ser cruzados por género e tipo de deficiência. Grupos com menos de cinco pessoas aparecem como informação insuficiente para divulgação.

Fonte: Lei n.º 10/2024, de 7 de Junho, artigo 31.