Gestão Avançada do Risco Cibernético

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.