Serviços e Arquitectura na Nuvem

Proposta pedagógica — por validar pela Ologa/ATDI. Este conteúdo é um rascunho preparado pela equipa. A sua disponibilidade na plataforma não significa aprovação nem validação técnica.

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

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

• Acolhimento e objectivos: 10 minutos.
• Exposição: 35 minutos.
• Actividade prática: 55 minutos.
• Partilha e síntese: 10 minutos.

Objectivos da lição

• Explicar o que é uma rede virtual, o que são sub-redes e endereçamento privado, e porque é que a rede se cria antes das máquinas.
• Escrever regras de segurança com prioridades numéricas, sabendo que as regras por omissão permitem o tráfego dentro da própria rede virtual e que negar exige regra explícita.
• Criar a rede virtual, as sub-redes e os grupos de segurança e, só depois, criar uma máquina virtual Linux directamente na sub-rede de aplicação, com acesso administrativo restrito a uma origem conhecida.
• Distinguir regra desenhada, regra configurada e ligação efectivamente testada.

Explicação

Uma rede virtual na nuvem é o espaço de rede privado da instituição dentro da infra-estrutura do fornecedor. Define-se um intervalo de endereços privados — por exemplo 10.20.0.0/16 — e dentro dele criam-se sub-redes, cada uma com o seu pedaço de endereços. As sub-redes servem para separar responsabilidades: uma para os servidores de aplicação, outra para a base de dados, outra para a administração.

A ordem importa e não é detalhe de laboratório: a interface de rede de uma máquina virtual nasce numa sub-rede e não passa depois para outra rede virtual. Por isso a rede desenha-se e cria-se primeiro, e as máquinas criam-se dentro dela. Trocar a ordem obriga a apagar a máquina e a recriá-la.

O endereçamento tem de ser pensado antes. Se a instituição já usa 10.20.0.0/16 na sua rede interna, escolher o mesmo intervalo na nuvem impede depois a ligação entre as duas redes, porque os endereços colidem.

Sobre o tráfego aplicam-se regras de segurança. No Azure chamam-se grupos de segurança de rede e associam-se a uma sub-rede ou à interface de rede de uma máquina. Cada regra tem prioridade entre 100 e 4096, origem, destino, porta e protocolo; ganha a primeira regra que corresponder, por ordem crescente de número. Existe um ponto que engana muita gente: entre as regras por omissão, com prioridade 65000, há uma que PERMITE todo o tráfego de entrada vindo da própria rede virtual. Isso significa que criar uma regra que permite a aplicação falar com a base de dados não implica, de forma nenhuma, que o resto da rede fique impedido de lhe falar. Para restringir de verdade é preciso uma regra de negação explícita, com número menor do que 65000 e maior do que as regras de permissão — por exemplo permissões em 100 e 200, negação em 4000 — para que a negação seja avaliada depois das permissões e antes das omissões.

Verificar também não é o que parece. Uma ligação que fica à espera e acaba por expirar não prova que a regra está a filtrar: pode ser serviço parado, porta errada, encaminhamento ou máquina desligada. A verificação séria tem duas partes: um teste positivo, em que o tráfego autorizado passa mesmo, e um teste negativo apoiado na avaliação de regras efectivas do próprio portal, que diz qual a regra que decidiu o destino daquele tráfego. Há três estados diferentes a não confundir: regra desenhada no papel, regra configurada e associada no portal, e ligação efectivamente testada.

O acesso administrativo nunca se abre a qualquer origem. Neste laboratório usa-se o caminho mais simples que é possível preparar numa sala: uma regra que permite a porta de acesso remoto apenas a partir do endereço público de saída da sala, em barra trinta e dois, e nada mais. Em produção há caminhos melhores — acesso intermediado pelo portal, posto de salto na sub-rede de administração ou rede privada virtual — e a sub-rede de administração é criada aqui já a pensar nisso, embora não se coloque nenhuma máquina lá dentro.

Para ligar a rede da instituição à rede na nuvem há três caminhos habituais: rede privada virtual sobre a internet, ligação dedicada contratada a um operador, e ligação entre redes virtuais, quando há mais do que uma rede ou mais do que um fornecedor. Em Moçambique a escolha depende muito da ligação disponível no local: num distrito com ligação intermitente, o serviço tem de continuar a funcionar localmente e sincronizar depois.

A rede do portal de licenciamento de Ondela (cenário fictício)

A equipa de Ondela desenha a rede do portal com três sub-redes: aplicação, dados e administração. A base de dados não tem endereço público e só deve aceitar ligações vindas da sub-rede da aplicação.

Na primeira versão do desenho, a equipa escreve apenas a regra que permite a aplicação falar com a base de dados e dá o trabalho por terminado. Na revisão, alguém lembra que a regra por omissão permite o tráfego dentro da rede virtual: qualquer máquina de qualquer sub-rede continuaria a alcançar a base de dados. Acrescenta-se então uma negação explícita com prioridade 4000.

Para a avaria de fim-de-semana, a equipa recusa abrir a porta de administração ao mundo: autoriza o endereço concreto de quem vai intervir, regista a autorização e fecha-a depois. Cenário fictício, para exercício.

Actividade prática

Trabalho em pares, um computador por par, com alternância de quem executa; havendo equipamento, um computador por pessoa, conforme o máximo de dois formandos por computador fixado no Termo de Referência, com 55 minutos de trabalho, seguidos de 10 minutos de partilha e síntese em plenário.

Primeira parte, em papel, 10 minutos: desenhem o plano de endereçamento das três sub-redes e escrevam a tabela de regras com prioridade, origem, destino, porta e razão de ser, incluindo as negações explícitas.

Segunda parte, no ambiente de formação, 35 minutos: executar o laboratório abaixo pela ordem indicada — rede, sub-redes e grupos de segurança primeiro, máquina virtual depois. A meio, trocar de executante dentro do par.

Terceira parte, 10 minutos: apagar tudo o que foi criado, pela ordem de dependências, e registar a eliminação.

Produto esperado: plano de endereçamento e tabela de regras com prioridades justificadas, evidência do teste positivo e do teste negativo por avaliação de regras, e registo da limpeza com quem executou cada parte.

Laboratório — Criar rede virtual, regras de segurança e, dentro delas, a máquina virtual

Laboratório por executar. Este guião ainda não foi executado por nós. O ambiente de formação está por preparar: a conta institucional de formação, os limites de consumo e as permissões são definidos pelo formador antes da sessão. Nunca se usam dados reais de pessoas, nunca se escrevem credenciais no material e nada é adquirido durante a aula. A leitura deste guião é preparação; não substitui a prática no ambiente real.

Percurso didáctico: Microsoft Azure: rede virtual, sub-redes, três grupos de segurança de rede e uma máquina virtual Linux criada já dentro da sub-rede de aplicação. O fornecedor é exemplo de ensino, escolhido pela clareza da documentação, e não uma imposição do Termo de Referência nem uma recomendação de compra.

Pré-requisitos

• Microsoft Azure — subscrição institucional de formação da entidade formadora, com orçamento e alertas de custo definidos pelo formador.
• Microsoft Azure — grupo de recursos do exercício já criado, com nome que identifique a turma e a data, e utilizador de formação com permissões de contribuidor limitadas a esse grupo de recursos.
• Este laboratório é apenas no Azure. O bucket da lição anterior é da Amazon Web Services, não pertence a este grupo de recursos e já foi apagado lá.
• Ficha de preparação da máquina virtual, preenchida na lição anterior: nome, tamanho autorizado, região, utilizador administrativo e autenticação por chave.
• Endereço público de saída da sala, apurado pelo formador antes da sessão e escrito no quadro, para usar como origem autorizada. Não é escrito em documento partilhado publicamente.
• Ferramenta de avaliação de fluxo já disponível e com as permissões necessárias, tratadas pelo formador antes da sessão. O utilizador de formação está limitado ao grupo de recursos e não deve activar serviços fora desse âmbito. Se a ferramenta não estiver disponível, o teste negativo fica registado como pendente e não se dá por bem sucedido.
• Se o ambiente falhar, a prática fica registada como pendente e é reagendada. A demonstração do formador não a substitui.

Passos

1. No portal do Azure, dentro do grupo de recursos do exercício, criar a rede virtual com o intervalo combinado, por exemplo 10.20.0.0/16, na região da ficha de preparação.
2. Criar três sub-redes: aplicacao (10.20.1.0/24), dados (10.20.2.0/24) e administracao (10.20.3.0/24).
3. Criar os três grupos de segurança de rede, um por sub-rede: nsg-aplicacao, nsg-dados e nsg-administracao, com o código do par no nome.
4. Em nsg-aplicacao: regra de entrada prioridade 100, protocolo TCP, porta 22, origem o endereço de saída da sala em barra trinta e dois, destino 10.20.1.0/24, acção permitir. Regra de entrada prioridade 4000, qualquer protocolo, qualquer porta, origem qualquer, destino 10.20.1.0/24, acção negar.
5. Em nsg-dados: regra de entrada prioridade 100, protocolo TCP, porta 5432, origem 10.20.1.0/24, destino 10.20.2.0/24, acção permitir. Regra de entrada prioridade 4000, qualquer origem, destino 10.20.2.0/24, acção negar. Sem esta segunda regra, a regra por omissão 65000 continuaria a permitir o tráfego vindo de toda a rede virtual.
6. Em nsg-administracao: regra de entrada prioridade 100, TCP, porta 22, origem o endereço da sala em barra trinta e dois, e regra de entrada prioridade 4000 a negar tudo o resto. A sub-rede fica preparada para um futuro posto de salto; nesta sessão não se cria máquina nenhuma nela.
7. Associar cada grupo de segurança à sua sub-rede e confirmar a associação na página de cada sub-rede.
8. Só agora criar a máquina virtual Linux, com os dados da ficha de preparação, escolhendo explicitamente a rede virtual criada e a sub-rede aplicacao, com endereço público atribuído e SEM permitir portas de entrada no assistente.
9. No separador de rede da criação, definir explicitamente o grupo de segurança da interface de rede como «Nenhum», ou equivalente na interface usada. A filtragem já vem do grupo associado à sub-rede; um segundo grupo na interface acumula-se com esse e pode bloquear o acesso remoto sem razão aparente.
10. Escolher autenticação por chave e guardar a chave privada na pasta local do exercício. A chave nunca é enviada por correio electrónico, colada na ficha ou fotografada.
11. Teste positivo: a partir da sala, estabelecer sessão de acesso remoto à máquina, com a chave, e executar um comando simples que confirme a ligação.
12. Teste negativo por avaliação de regras, na interface de rede desta máquina, que é a única que existe: avaliar a entrada na porta 22 a partir de um endereço qualquer da internet, que deve resultar em negado, com indicação da regra 4000.
13. Revisão do grupo de segurança da sub-rede de dados: ler no portal as regras e a associação e confirmar, uma a uma, que existe a permissão em 100 e a negação em 4000. Não há nesta sessão nenhuma máquina na sub-rede de dados, por isso não existe destino real e a conectividade dessa sub-rede fica por testar — é revisão de configuração, não teste executado.
14. Registar na ficha o resultado de cada avaliação, com o nome da regra que decidiu, e não apenas «não liguei». Se a ferramenta de avaliação não estiver disponível, escrever «teste pendente» em vez de qualquer conclusão.

Como verificar o resultado

• As três sub-redes existem com os intervalos planeados, sem sobreposição, e cada uma mostra o seu grupo de segurança associado.
• Cada grupo de segurança tem, no mínimo, uma regra de permissão específica e uma negação explícita com prioridade inferior a 65000.
• Teste positivo: a sessão de acesso remoto a partir da sala estabelece-se e o comando responde.
• Teste negativo: a avaliação de regras do portal devolve «negado» para a porta 22 vinda de origem não autorizada e nomeia a regra responsável.
• Sub-rede de dados: regras e associação revistas no portal. A conectividade fica assinalada como NÃO TESTADA, por não existir máquina de destino nesta sessão.
• Nenhuma regra de PERMISSÃO tem origem «qualquer» ou 0.0.0.0/0 numa porta administrativa. As regras de negação podem e devem ter origem qualquer — é essa a sua função.
• A interface de rede da máquina não tem grupo de segurança próprio associado.

Problemas comuns

• Regra criada mas sem efeito: confirmar a associação do grupo de segurança à sub-rede e verificar se alguma regra de número menor corresponde primeiro ao mesmo tráfego.
• Base de dados alcançável de outra sub-rede apesar da regra de permissão: falta a negação explícita; as regras por omissão permitem o tráfego interno da rede virtual.
• Máquina criada fora da sub-rede pretendida: não se resolve movendo a interface de rede para outra rede virtual, porque isso não é possível; apaga-se a máquina com o disco e a interface e cria-se de novo na sub-rede certa.
• Sessão remota falha depois de tudo configurado: distinguir causas — regra, serviço parado, chave errada ou endereço de saída da sala alterado. A avaliação de regras do portal diz se o problema é de filtragem.
• Endereço de saída da sala muda durante a sessão, o que é comum em ligações móveis: pedir o novo endereço ao formador e actualizar a regra, nunca alargá-la.

Evidência a recolher

A evidência não pode conter segredos: sem chaves, sem palavras-passe, sem tokens, sem dados pessoais. Tapar identificadores de subscrição nas imagens.

• Captura de ecrã das três sub-redes com os intervalos e os grupos de segurança associados.
• Captura de ecrã das regras de entrada de cada grupo, mostrando prioridades, origens restritas e a negação explícita.
• Captura de ecrã do resultado da avaliação de fluxo para a porta 22 de origem não autorizada, com a regra que decidiu, ou registo de «teste pendente» se a ferramenta não estiver disponível.
• Captura de ecrã das regras e da associação do grupo da sub-rede de dados, identificada como revisão de configuração e não como teste de conectividade.
• Captura de ecrã do comando executado na sessão remota, sem conteúdo sensível.
• Ficha com hora de eliminação, lista de recursos apagados e nome de quem executou cada parte.

Limpeza

• Apagar por ordem de dependências, tudo dentro do grupo de recursos do exercício: primeiro a máquina virtual, depois o disco e a interface de rede que lhe pertencem, depois o endereço público.
• Remover as associações dos grupos de segurança às sub-redes e apagar os três grupos de segurança.
• Apagar por fim a rede virtual, que não pode ser apagada enquanto tiver interfaces ligadas.
• Conferir que ficaram apenas os recursos partilhados que já existiam antes da sessão, se os houver, e comunicar ao formador o que foi apagado.

Apagar apenas os recursos criados neste exercício, dentro do grupo de recursos do exercício. Não apagar nada fora dele.

Síntese em leitura fácil

• A rede cria-se primeiro e as máquinas nascem dentro dela: a interface de rede não muda de rede virtual depois.
• As sub-redes separam aplicação, dados e administração; o plano de endereços decide-se antes e não pode colidir com a rede da instituição.
• As regras por omissão permitem o tráfego dentro da rede virtual: permitir a aplicação não chega, é preciso negar explicitamente o resto.
• As prioridades mandam: permissões em números baixos, negação explícita antes das omissões.
• Nunca se abre a porta administrativa a qualquer origem; neste laboratório só o endereço de saída da sala.
• Tempo de espera esgotado não prova filtragem: confirma-se com teste positivo e com a avaliação de regras do portal.

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. Numa sub-rede de dados existe apenas uma regra que permite a porta da base de dados vinda da sub-rede de aplicação. O resto do tráfego interno fica bloqueado?
2. A tentativa de ligação ficou à espera e expirou. Isso prova que a regra de segurança está a funcionar?

Respostas comentadas da verificação formativa

As respostas abaixo pertencem às perguntas de verificação formativa desta lição. Não são perguntas nem respostas do exame final e não têm qualquer efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. Numa sub-rede de dados existe apenas uma regra que permite a porta da base de dados vinda da sub-rede de aplicação. O resto do tráfego interno fica bloqueado?

Resposta: Não. A regra por omissão de prioridade 65000 permite o tráfego vindo da própria rede virtual, por isso é preciso uma negação explícita com prioridade inferior a esse número.

Comentário: É o erro mais comum nestas configurações e não aparece em testes feitos a partir da máquina certa — só a partir das outras.

Pergunta 2. A tentativa de ligação ficou à espera e expirou. Isso prova que a regra de segurança está a funcionar?

Resposta: Não. Pode ser serviço parado, porta errada, máquina desligada ou encaminhamento. Confirma-se com a avaliação de regras do portal, que nomeia a regra que decidiu.

Comentário: Vale a pena distinguir sempre: regra desenhada, regra configurada e ligação testada são três coisas diferentes.

Referências consultadas

• Azure — Quickstart: criar uma rede virtual — https://learn.microsoft.com/en-us/azure/virtual-network/quickstart-create-virtual-network (consultado em 21 de Setembro de 2026).
• Azure — Descrição geral dos grupos de segurança de rede, incluindo as regras por omissão — https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview (consultado em 21 de Setembro de 2026).
• Azure — Quickstart: criar uma máquina virtual Linux no portal — https://learn.microsoft.com/en-us/azure/virtual-machines/linux/quick-create-portal (consultado em 21 de Setembro de 2026).