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

• 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.