Computação em 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: 105 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: 50 minutos.
• Partilha e síntese: 10 minutos.

Objectivos da lição

• Definir computação em nuvem por palavras próprias e identificar as cinco características essenciais da definição do NIST.
• Distinguir um serviço que é nuvem de um serviço que apenas está alojado noutro sítio.
• Situar no tempo a evolução do modelo, do centro de dados próprio até aos serviços geridos actuais.

Explicação

Computação em nuvem é a possibilidade de usar capacidade informática — servidores, armazenamento, redes, bases de dados, aplicações — pedindo-a pela rede, no momento em que é precisa, com o consumo medido. A instituição deixa de comprar equipamento para responder ao pico previsto e passa a pedir capacidade conforme a procura real. Atenção a um ponto que gera confusão: a medição do consumo é característica do modelo, mas a forma de cobrança depende do contrato. Pode ser cobrança ao consumo, pode ser tarifa fixa ou capacidade reservada por período, e numa nuvem privada da própria administração pode não haver factura externa nenhuma — a medição serve então para repartir custo interno e controlar o uso.

A referência mais usada para esta definição é a publicação SP 800-145 do NIST, o instituto norte-americano de normas e tecnologia. Essa publicação enumera cinco características essenciais. A primeira é o auto-serviço a pedido: a pessoa responsável obtém os recursos sozinha, num portal ou por comando, sem abrir pedido a um técnico do fornecedor. A segunda é o acesso amplo pela rede: os recursos são alcançados por meios de rede normalizados, a partir de computador, telemóvel ou outro equipamento. A terceira é o agrupamento de recursos: o fornecedor mantém uma reserva comum de capacidade servida a vários consumidores, com isolamento entre eles, e o consumidor normalmente não sabe em que máquina física está a correr. Consumidor aqui não quer dizer forçosamente outra instituição: numa nuvem privada, os consumidores que partilham a mesma reserva são as direcções, os departamentos e os projectos da própria organização. A quarta é a elasticidade rápida: a capacidade cresce e diminui depressa, em alguns casos de forma automática, dando a impressão de ser ilimitada. A quinta é o serviço medido: o consumo é contado e apresentado — horas de máquina, gigabytes guardados, pedidos atendidos — o que permite controlar o uso e, quando o contrato assim o determinar, facturar.

Estas cinco características servem de critério prático. Um servidor alugado num centro de dados, que demora três dias a ser entregue e cuja capacidade não muda sem novo contrato, não cumpre o auto-serviço nem a elasticidade: está alojado fora, mas não é nuvem. O teste é simples: consigo obter sozinho, em minutos, aumentar e diminuir, e ver quanto consumi?

Quanto à evolução: durante décadas cada instituição manteve a sua própria sala de servidores, com custo fixo e capacidade dimensionada para o pico. A virtualização permitiu correr várias máquinas lógicas num mesmo equipamento físico, aumentando o aproveitamento. Nos anos 2000, grandes operadores começaram a oferecer essa capacidade virtualizada a terceiros, com o consumo medido. Seguiram-se os serviços geridos, em que o fornecedor trata também do sistema operativo, da base de dados ou da própria plataforma de aplicação, e mais recentemente a execução sem servidor visível, em que a unidade de consumo passa a ser sobretudo a execução do código, embora haja quase sempre outras componentes a contar, como armazenamento, tráfego de rede e serviços associados. A direcção é sempre a mesma: menos infra-estrutura para gerir e mais atenção ao serviço prestado.

Para um serviço público, isto muda a conversa. A pergunta deixa de ser «quantos servidores compramos este ano» e passa a ser «que capacidade precisamos, quando, com que garantias de protecção de dados e a que custo mensal». As respostas a essa segunda pergunta são o assunto do resto do curso.

O portal de inscrições do Serviço Distrital de Ondela (cenário fictício)

O Serviço Distrital de Ondela abre inscrições escolares durante duas semanas por ano. Nessas duas semanas o portal recebe muitos acessos ao mesmo tempo; nos restantes onze meses e meio quase ninguém lhe toca. A sala de servidores do distrito foi dimensionada para o pico: equipamento parado quase todo o ano, que na mesma consome energia e exige manutenção.

Se o portal passar a correr em nuvem, a equipa aumenta a capacidade antes do período de inscrições e reduz depois. O auto-serviço permite fazê-lo no próprio dia; o serviço medido mostra ao director quanto foi consumido no pico, e o contrato dirá se isso se traduz em factura variável ou em tarifa fixa. Passar para a nuvem não garante, por si, poupança: o resultado depende do perfil de utilização, do contrato, da ligação à internet disponível e do trabalho de migração.

Este cenário é fictício e serve de exercício. Não descreve nenhum serviço existente nem apresenta valores de preço.

Actividade prática

Trabalho em pares, com 50 minutos de trabalho, seguidos de 10 minutos de partilha e síntese em plenário.

Escolham um sistema informático que a vossa instituição use hoje: um portal, uma aplicação de gestão, uma pasta de ficheiros partilhada ou o correio electrónico.

Para cada uma das cinco características essenciais, escrevam «cumpre», «não cumpre» ou «não sei», e uma frase a justificar.

Concluam com uma frase: este sistema é nuvem, é alojamento fora da instituição, ou é equipamento próprio? Se a resposta depender de informação que não têm, escrevam «por apurar» e indiquem a quem seria preciso perguntar.

Produto esperado: uma grelha com as cinco características avaliadas e justificadas, e uma conclusão fundamentada sobre a natureza do sistema escolhido.

Síntese em leitura fácil

• Nuvem é pedir capacidade informática pela rede, quando é precisa, com o consumo medido.
• Medir o consumo não é o mesmo que pagar por consumo: a cobrança depende do contrato e pode ser fixa, ou nem existir numa nuvem privada.
• São cinco as características essenciais: peço sozinho; chego pela rede; a capacidade é partilhada por vários consumidores, que podem ser áreas da própria organização; cresce e diminui depressa; o consumo é medido.
• Estar alojado fora da instituição não é, por si, nuvem.
• O modelo evoluiu da sala de servidores própria para a virtualização, depois para serviços geridos e para a execução sem servidor visível.

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 servidor alugado noutra cidade, entregue três dias depois do pedido e com capacidade fixa durante o contrato, é computação em nuvem?
2. Porque é que o serviço medido interessa a quem dirige um serviço público, e não apenas a quem paga a factura?

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. Um servidor alugado noutra cidade, entregue três dias depois do pedido e com capacidade fixa durante o contrato, é computação em nuvem?

Resposta: Não. Falha o auto-serviço a pedido e a elasticidade rápida.

Comentário: O critério não é o sítio onde o equipamento está, mas a forma como a capacidade é obtida, ajustada e medida.

Pergunta 2. Porque é que o serviço medido interessa a quem dirige um serviço público, e não apenas a quem paga a factura?

Resposta: Porque mostra o consumo real e permite definir limites, detectar desperdício e justificar a despesa perante quem decide.

Comentário: A medição é também um instrumento de governação: sem ela, o consumo cresce sem ninguém dar por isso. O tema volta na lição sobre custos e limites.

Referências consultadas

• NIST SP 800-145, The NIST Definition of Cloud Computing — https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-145.pdf (consultado em 21 de Setembro de 2026).

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: 105 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: 50 minutos.
• Partilha e síntese: 10 minutos.

Objectivos da lição

• Distinguir infra-estrutura como serviço, plataforma como serviço e programa como serviço pelo que fica a cargo de cada parte.
• Classificar correctamente três serviços informáticos usados no dia-a-dia de uma instituição.
• Justificar a escolha de um dos três modelos para uma necessidade concreta de um serviço público.

Explicação

Os três modelos de serviço distinguem-se por uma pergunta simples: até onde vai o trabalho do fornecedor e onde começa o trabalho da instituição. Em todos eles o equipamento físico, a electricidade e as instalações são do fornecedor. O que muda é o resto.

Na infra-estrutura como serviço, a instituição recebe os elementos de base: máquinas virtuais, discos, redes. Instala o sistema operativo que quiser, actualiza-o, instala as aplicações e responde pela configuração. É o modelo com mais liberdade e com mais trabalho: quem escolhe este caminho precisa de pessoal com competências de administração de sistemas.

Na plataforma como serviço, a instituição entrega apenas a aplicação e a sua configuração. O fornecedor trata do sistema operativo, do servidor aplicacional e, muitas vezes, da base de dados e da capacidade de crescer com a procura. Perde-se liberdade de configurar o que está por baixo e ganha-se tempo: é o modelo habitual para publicar depressa um serviço em linha com uma equipa pequena.

No programa como serviço, a instituição não gere aplicação nenhuma: usa um programa pronto, pela rede, e configura-o. Correio electrónico institucional, sistemas de videoconferência e ferramentas de escritório em linha são exemplos correntes. O trabalho que resta é de configuração, de gestão de contas e de utilizadores, e de tratamento dos dados que lá ficam guardados.

Uma imagem útil é a da refeição: a infra-estrutura como serviço é a cozinha equipada onde se cozinha tudo; a plataforma como serviço é a cozinha onde já está preparada a base e só se termina o prato; o programa como serviço é a refeição servida à mesa. A imagem ajuda a lembrar a repartição do trabalho, mas não substitui o contrato: é o contrato que diz exactamente quem faz o quê, incluindo em caso de falha.

Uma instituição raramente escolhe um só. É comum ter correio electrónico como programa como serviço, o portal de serviços como plataforma, e uma ou outra máquina virtual de infra-estrutura para aplicações antigas que ainda não foram modernizadas. A regra prática é subir o mais possível na escala — do mais gerido para o menos gerido — e só descer quando houver razão técnica ou legal para o fazer.

Três necessidades da Direcção Provincial de Muteva (cenário fictício)

A Direcção Provincial de Muteva tem três problemas em cima da mesa. Primeiro: o correio electrónico institucional falha e não há quem o mantenha. Segundo: querem publicar um portal simples de marcação de atendimento, escrito por dois técnicos da casa. Terceiro: há uma aplicação antiga de gestão de expediente que só corre numa versão específica de sistema operativo.

A escolha razoável é diferente em cada caso: o correio passa para um programa como serviço, porque não há valor em manter servidor de correio próprio; o portal de marcações vai para uma plataforma como serviço, porque a equipa quer publicar código e não administrar servidores; a aplicação antiga fica, para já, numa máquina virtual de infra-estrutura como serviço, porque exige aquela versão concreta — e fica registada como candidata a modernização.

Cenário fictício, para exercício. Não representa nenhuma direcção provincial existente.

Actividade prática

Trabalho em grupos de três, com 50 minutos de trabalho, seguidos de 10 minutos de partilha e síntese em plenário.

Listem cinco serviços informáticos que a vossa instituição usa hoje ou pretende usar no próximo ano.

Para cada um, indiquem o modelo de serviço mais adequado e escrevam, em duas colunas, o que ficaria a cargo do fornecedor e o que ficaria a cargo da instituição.

Assinalem, para cada linha, uma competência que a equipa precisaria de ter. Se essa competência não existir hoje, escrevam «por formar».

Produto esperado: uma tabela de cinco serviços com o modelo escolhido, a repartição de responsabilidades e as competências necessárias ou por formar.

Síntese em leitura fácil

• Os três modelos diferem no que o fornecedor faz e no que a instituição continua a fazer.
• Infra-estrutura: recebo máquinas e redes, giro tudo o que está por cima.
• Plataforma: entrego a aplicação, o fornecedor trata do que está por baixo.
• Programa como serviço: uso um programa pronto e giro contas, configuração e dados.
• A maioria das instituições usa os três ao mesmo tempo, conforme a necessidade.

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 plataforma como serviço, quem é responsável por actualizar o sistema operativo do servidor?
2. Se a instituição usa correio electrónico institucional em linha, deixa de ter responsabilidades sobre esses 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 qualquer efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. Numa plataforma como serviço, quem é responsável por actualizar o sistema operativo do servidor?

Resposta: O fornecedor.

Comentário: É essa a vantagem principal do modelo. Em contrapartida, a instituição não escolhe livremente versões nem configurações desse nível.

Pergunta 2. Se a instituição usa correio electrónico institucional em linha, deixa de ter responsabilidades sobre esses dados?

Resposta: Não. Continua responsável pelas contas, pelas permissões, pela informação que lá coloca e pelo cumprimento das regras de protecção de dados.

Comentário: Esta é a confusão mais frequente e volta na lição sobre responsabilidade partilhada: contratar um programa como serviço transfere operação, não transfere responsabilidade pelos dados.

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: 105 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: 50 minutos.
• Partilha e síntese: 10 minutos.

Objectivos da lição

• Distinguir nuvem pública, privada, comunitária e híbrida pelo critério de quem a nuvem serve.
• Explicar o que é multinuvem e em que difere de nuvem híbrida.
• Identificar dois riscos e duas vantagens de uma solução híbrida para um serviço público.

Explicação

Os modelos de implantação respondem a outra pergunta: para quem existe esta nuvem. A nuvem pública é operada para uso do público em geral; qualquer organização contrata e a capacidade é partilhada com outros consumidores. A nuvem privada existe para uso exclusivo de uma organização, com as suas várias unidades como consumidores, e pode estar instalada nas instalações da organização ou nas de terceiro que a opere. A nuvem comunitária serve um conjunto de organizações com preocupações comuns, por exemplo várias instituições do mesmo sector com os mesmos requisitos de segurança. A nuvem híbrida é a composição de duas ou mais destas, que permanecem distintas mas são ligadas por tecnologia que permite mover dados ou aplicações entre elas.

A distinção não é sobre o sítio onde estão as máquinas. Uma nuvem privada pode estar alojada fora da instituição e continuar a ser privada, porque serve uma só organização. E uma nuvem pública não deixa de ser pública por a instituição ter lá uma área isolada com rede própria.

Multinuvem é coisa diferente de híbrida. Multinuvem significa usar serviços de mais do que um fornecedor de nuvem, por exemplo armazenamento num e uma aplicação noutro. Pode haver multinuvem sem nenhuma componente privada; e pode haver nuvem híbrida com um único fornecedor. As razões para usar mais do que um fornecedor costumam ser reduzir a dependência de um só, aproveitar um serviço que só existe num deles, ou responder a exigência de continuidade. O custo é a complexidade: duas consolas, dois modelos de identidade, duas facturas e equipas que precisam de conhecer ambos.

Para a administração pública, o caso híbrido aparece com frequência por três razões. Há dados cuja localização ou tratamento está sujeito a exigências que aconselham a mantê-los sob controlo directo. Há aplicações antigas que não correm em nuvem pública sem serem reescritas. E há ligações à internet que, em certos distritos, não sustentam um serviço inteiramente remoto — o que recomenda manter capacidade local para o atendimento continuar quando a ligação cair.

Os riscos de uma solução híbrida são igualmente concretos: a superfície a proteger aumenta, porque há duas redes e uma ligação entre elas; a responsabilidade dilui-se, porque uma falha pode estar de qualquer dos lados; e o custo de operação sobe, porque é preciso manter competências nos dois ambientes. Uma arquitectura híbrida deve ser uma decisão justificada, não o resultado de não se ter decidido.

O registo de licenças da Autarquia de Cambala (cenário fictício)

A Autarquia de Cambala tem um registo de licenças comerciais com dados de identificação dos requerentes e quer publicar um portal onde o munícipe consulta o estado do seu pedido.

A proposta em discussão é híbrida: a base de dados do registo fica numa nuvem privada operada para o sector, por causa dos dados pessoais e de uma exigência interna de controlo directo; o portal de consulta, que só mostra o estado do pedido e não guarda dados sensíveis, fica em nuvem pública, onde é fácil aguentar picos de acesso.

As duas partes ligam-se por um canal cifrado e o portal só pode perguntar pelo estado de um pedido, nunca ler a ficha completa. Cenário fictício, para exercício.

Actividade prática

Trabalho em grupos de três, com 50 minutos de trabalho, seguidos de 10 minutos de partilha e síntese em plenário.

Escolham um serviço da vossa instituição que trate dados de pessoas.

Dividam esse serviço em duas listas: o que poderia estar em nuvem pública e o que, na vossa opinião, deve ficar sob controlo directo. Justifiquem cada colocação com uma razão — legal, técnica ou de ligação à internet.

Desenhem, com caixas e setas, a ligação entre as duas partes e escrevam que informação atravessa essa ligação.

Indiquem um risco que esta divisão cria e como o mitigariam.

Produto esperado: um esquema de duas zonas com a informação que circula entre elas, as justificações de cada colocação e um risco com a respectiva mitigação.

Síntese em leitura fácil

• O modelo de implantação responde a: para quem existe esta nuvem.
• Pública serve o público em geral; privada serve uma organização; comunitária serve um grupo com requisitos comuns; híbrida liga duas ou mais.
• Privada não quer dizer «dentro do edifício»: quer dizer «para uma só organização».
• Multinuvem é usar vários fornecedores; é diferente de híbrida.
• O híbrido resolve problemas reais e aumenta a complexidade e a superfície a proteger.

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. Uma instituição contrata capacidade exclusiva, operada por terceiro, em instalações do terceiro. É nuvem pública ou privada?
2. Usar armazenamento de um fornecedor e aplicações de outro é nuvem híbrida?

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. Uma instituição contrata capacidade exclusiva, operada por terceiro, em instalações do terceiro. É nuvem pública ou privada?

Resposta: Privada, porque é de uso exclusivo de uma organização.

Comentário: O critério é o conjunto de consumidores servidos, não a propriedade do edifício nem a localização do equipamento.

Pergunta 2. Usar armazenamento de um fornecedor e aplicações de outro é nuvem híbrida?

Resposta: Não necessariamente. Isso é multinuvem; só é híbrida se combinar modelos de implantação diferentes.

Comentário: Os dois conceitos aparecem juntos com frequência, mas respondem a perguntas distintas: quantos fornecedores, e que tipo de nuvem.

Referências consultadas

• NIST SP 800-145, The NIST Definition of Cloud Computing — https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-145.pdf (consultado em 21 de Setembro de 2026).

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: 105 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: 50 minutos.
• Partilha e síntese: 10 minutos.

Objectivos da lição

• Enumerar as vantagens habituais da nuvem e o limite prático de cada uma.
• Identificar as componentes de infra-estrutura que sustentam um serviço em nuvem.
• Aplicar o princípio da responsabilidade partilhada, dizendo o que continua a caber à instituição em cada modelo de serviço.

Explicação

As vantagens mais invocadas são quatro. Ajustar a capacidade à procura, evitando comprar para o pico. Reduzir o tempo entre decidir e ter o serviço a funcionar, porque não há aquisição de equipamento. Aceder a serviços geridos que a instituição não teria capacidade de montar sozinha. E melhorar a continuidade, por ser mais fácil ter cópias em locais diferentes.

Cada uma tem o seu limite. O ajuste à procura só poupa se alguém reduzir a capacidade quando o pico passa — máquinas esquecidas ligadas consomem na mesma. A rapidez inicial não elimina o trabalho de migrar dados, rever processos e formar pessoas, que costuma ser a parte mais demorada. Os serviços geridos aumentam a dependência do fornecedor e dificultam a saída. E nada disto funciona sem ligação à internet com qualidade suficiente, o que em vários distritos é a primeira restrição a verificar, antes de qualquer decisão de arquitectura.

Por baixo do serviço estão componentes de infra-estrutura que convém nomear, porque reaparecem em todas as consolas: centros de dados agrupados em regiões, e dentro de cada região zonas separadas para que uma falha não apanhe tudo; capacidade de cálculo, seja em máquinas virtuais, contentores ou funções; armazenamento, em disco ligado à máquina, em contentor de objectos ou em sistema de ficheiros partilhado; rede, com redes virtuais, endereços, balanceadores e ligações privadas; e os serviços de identidade, registo e monitoria que atravessam tudo o resto.

O princípio que organiza as responsabilidades chama-se responsabilidade partilhada. O fornecedor responde pela segurança da nuvem: instalações, equipamento, rede física, e a camada que ele próprio gere. A instituição responde pela segurança na nuvem: que dados coloca lá, quem tem acesso, como configura o que criou, e o cumprimento das regras a que está sujeita. A fronteira desloca-se com o modelo de serviço — em infra-estrutura como serviço a instituição responde também pelo sistema operativo; em plataforma como serviço deixa de responder por ele; em programa como serviço fica sobretudo com contas, configuração e dados. O que nunca se transfere é a responsabilidade pelos dados e pelo serviço prestado ao cidadão.

A maioria dos incidentes públicos conhecidos neste domínio não resulta de falha do fornecedor, mas de configuração indevida do lado do cliente: um contentor de armazenamento aberto ao público, uma permissão excessiva, uma chave deixada dentro do código. É por isso que este curso dedica um módulo inteiro a identidades, permissões mínimas e protecção de dados.

A fronteira mal percebida no Hospital Distrital de Namacurra do Norte (cenário fictício)

O Hospital Distrital de Namacurra do Norte contrata uma plataforma como serviço para uma aplicação de marcação de consultas. A direcção fica com a ideia de que «a segurança é do fornecedor».

Seis meses depois descobre-se que doze pessoas que já saíram do hospital continuam com conta activa, e que o relatório mensal de marcações estava a ser guardado num espaço de partilha acessível a quem tivesse o endereço.

Nenhuma destas falhas é do fornecedor: ambas estão do lado da instituição — gestão de contas e configuração de acesso. Cenário fictício, para exercício.

Actividade prática

Trabalho em pares, com 50 minutos de trabalho, seguidos de 10 minutos de partilha e síntese em plenário.

Desenhem uma tabela com três colunas: infra-estrutura como serviço, plataforma como serviço e programa como serviço.

Nas linhas, coloquem: instalações e equipamento; rede física; sistema operativo; aplicação; configuração de acesso; dados; contas de utilizador; cumprimento das regras aplicáveis.

Preencham cada célula com «fornecedor», «instituição» ou «ambos» e assinalem as células onde tiverem dúvida.

Escolham uma das células marcadas com dúvida e escrevam que pergunta fariam ao fornecedor para a esclarecer.

Produto esperado: a matriz de responsabilidade partilhada preenchida, com as dúvidas assinaladas e uma pergunta concreta a colocar ao fornecedor.

Síntese em leitura fácil

• As vantagens da nuvem são reais e têm limites: poupar exige gerir; a rapidez inicial não elimina o trabalho de migrar.
• Sem ligação à internet com qualidade suficiente, a discussão de arquitectura não avança.
• Componentes a conhecer: regiões e zonas, cálculo, armazenamento, rede, identidade e monitoria.
• O fornecedor responde pela segurança da nuvem; a instituição responde pela segurança na nuvem.
• A responsabilidade pelos dados e pelo serviço ao cidadão não se transfere por contrato.

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 contentor de armazenamento com dados de utentes ficou acessível ao público. De quem é a responsabilidade?
2. Migrar para a nuvem reduz sempre o custo?

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. Um contentor de armazenamento com dados de utentes ficou acessível ao público. De quem é a responsabilidade?

Resposta: Da instituição: é configuração do lado do cliente.

Comentário: Este é o caso típico da responsabilidade na nuvem. O fornecedor entrega o mecanismo de controlo de acesso; usá-lo correctamente é trabalho de quem cria o recurso.

Pergunta 2. Migrar para a nuvem reduz sempre o custo?

Resposta: Não. Depende do perfil de utilização, do contrato, do esforço de migração e da disciplina em reduzir capacidade quando deixa de ser precisa.

Comentário: Vale a pena separar as duas perguntas: «isto melhora o serviço?» e «isto custa menos?». Nem sempre têm a mesma resposta.

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

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

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

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

Objectivos da lição

• Aplicar critérios explícitos para escolher modelo de serviço e modelo de implantação para um serviço público concreto.
• Registar por escrito os pressupostos e as informações em falta que condicionam a escolha.
• Apresentar e defender uma recomendação fundamentada perante o grupo.

Explicação

Esta lição fecha o módulo com a única pergunta que interessa na prática: dado este serviço, que modelo escolher. A resposta não sai de uma tabela universal; sai de critérios aplicados com honestidade, e de dizer o que ainda não se sabe.

Seis critérios cobrem a maior parte dos casos. Primeiro, a natureza dos dados: há dados pessoais ou sensíveis, e que exigências se aplicam ao seu tratamento e localização. Segundo, o padrão de procura: é constante, tem picos previsíveis, ou é imprevisível. Terceiro, a ligação à internet nos locais onde o serviço é usado, incluindo o que acontece ao atendimento quando ela cai. Quarto, as competências da equipa hoje e as que se conseguem formar num horizonte razoável. Quinto, a dependência do fornecedor e o custo de sair: que formatos, que dados, que reescrita seriam precisos para mudar. Sexto, o custo total, que inclui migração, formação e operação, e não apenas a factura mensal de capacidade.

Ao aplicar estes critérios, três regras ajudam a não errar por hábito. Subir na escala de gestão sempre que não houver razão para descer: escolher o serviço mais gerido que sirva. Não decidir a arquitectura antes de conhecer a ligação à internet dos locais de uso. E escrever os pressupostos: «assumimos que os dados de identificação podem ser tratados por operador contratado» é uma frase que tem de ser confirmada por quem tem competência para isso, não pelo técnico que desenha a solução.

Uma recomendação útil tem sempre quatro partes: a opção escolhida; as opções descartadas e porquê; os pressupostos assumidos; e a lista do que falta apurar, com indicação de quem pode responder. Uma recomendação sem a quarta parte costuma ser uma recomendação que esconde o que não se sabe.

Por fim, uma nota de método: a escolha não é definitiva. Serviços começam num modelo e mudam quando as condições mudam — quando a aplicação antiga é reescrita, quando a ligação melhora, quando a equipa ganha competências. Registar a decisão com data e com os pressupostos permite revê-la sem recomeçar do zero.

O cadastro de agricultores do Serviço Provincial de Tuvane (cenário fictício)

O Serviço Provincial de Tuvane quer informatizar o cadastro de agricultores. Os dados incluem nome, documento de identificação e localização das parcelas. O registo é feito por extensionistas em dez postos, quatro deles com ligação à internet instável. A consulta central é feita por seis técnicos na capital provincial. A equipa informática tem duas pessoas, sem experiência de administração de servidores.

Aplicados os critérios, a proposta é: aplicação em plataforma como serviço, por causa da equipa pequena; base de dados sob controlo directo em nuvem privada do sector, por causa dos dados de identificação, ficando a arquitectura híbrida; e registo nos postos com funcionamento local que sincroniza quando há ligação, por causa dos quatro postos instáveis.

Pressupostos escritos: que existe capacidade disponível na nuvem privada do sector; e que a sincronização diferida é aceitável para o processo de cadastro. Por apurar: o prazo legal de conservação dos dados e quem autoriza o tratamento por operador contratado. Cenário fictício, para exercício.

Actividade prática

Trabalho em grupos de quatro, com apresentação, com 45 minutos de trabalho, seguidos de 10 minutos de partilha e síntese em plenário.

Escolham um serviço real da vossa instituição que ainda não esteja em nuvem — sem usar dados reais de pessoas no exercício.

Apliquem os seis critérios, um a um, e escrevam uma linha de conclusão por critério.

Escrevam a recomendação com as quatro partes: opção escolhida, opções descartadas e porquê, pressupostos assumidos, e o que falta apurar com indicação de quem responde.

Na partilha ouvem-se dois grupos, escolhidos por amostra: 3 minutos de exposição e 1 minuto de comentário cada, seguidos de 2 minutos de síntese. Os restantes grupos entregam a ficha ao formador, que devolve apreciação escrita.

Produto esperado: uma ficha de recomendação de uma página com os seis critérios aplicados, a opção escolhida, as descartadas, os pressupostos e a lista do que falta apurar.

Síntese em leitura fácil

• A escolha do modelo faz-se com critérios escritos, não por hábito nem por moda.
• Seis critérios: natureza dos dados, padrão de procura, ligação à internet, competências, dependência do fornecedor e custo total.
• Escolher o serviço mais gerido que sirva, e descer na escala só com razão.
• Uma boa recomendação diz também o que ainda não se sabe e quem pode responder.
• A decisão tem data e pressupostos, e revê-se quando as condições mudarem.

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 recomendação, por que motivo é indispensável a lista do que falta apurar?
2. Um serviço usado em postos com ligação instável: que critério tem de ser avaliado antes de escolher a arquitectura?

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 recomendação, por que motivo é indispensável a lista do que falta apurar?

Resposta: Porque torna visível o que a decisão está a assumir e permite que quem tem competência confirme ou corrija esses pressupostos.

Comentário: Sem esta lista, um pressuposto por confirmar passa a decisão tomada sem que ninguém repare.

Pergunta 2. Um serviço usado em postos com ligação instável: que critério tem de ser avaliado antes de escolher a arquitectura?

Resposta: A ligação à internet nos locais de uso, incluindo o que acontece ao atendimento quando ela cai.

Comentário: Este critério manda muitas vezes mais do que a preferência tecnológica: determina se é preciso funcionamento local com sincronização posterior.

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: 105 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: 50 minutos.
• Partilha e síntese: 10 minutos.

Objectivos da lição

• Distinguir as famílias de recursos de computação — máquina virtual, contentor e execução sem servidor — e indicar quando cada uma serve.
• Distinguir armazenamento de blocos, de ficheiros e de objectos, e escolher o tipo adequado a um caso de serviço público.
• Criar, em ambiente de formação, um recipiente de objectos privado na Amazon Web Services, verificar que está fechado ao exterior e apagá-lo no fim.
• Preparar por escrito os parâmetros da máquina virtual que será criada na lição seguinte, depois de existir rede.

Explicação

Os recursos de computação são as várias formas de correr código na nuvem. A máquina virtual é a mais próxima do que já se conhece: um computador lógico, com sistema operativo próprio, ao qual se liga por acesso remoto e onde se instala o que for preciso. Dá liberdade total e, em troca, deixa à instituição a responsabilidade pelas actualizações, pela segurança do sistema operativo e pelo que lá corre. O contentor é uma forma mais leve: empacota a aplicação com as bibliotecas de que ela precisa e corre sobre um sistema operativo partilhado, arrancando em segundos e sendo fácil de replicar. A execução sem servidor visível, por vezes chamada serverless, vai mais longe: escreve-se uma função, o fornecedor trata de a executar quando é chamada e de a dimensionar, e a equipa deixa de gerir servidores. Serverless não quer dizer que não existam servidores; quer dizer que não são geridos por quem usa o serviço, e o custo tem normalmente várias componentes — execuções, tempo de execução, memória atribuída, tráfego e serviços associados — e não apenas o tempo de execução.

Estas três formas correspondem a graus diferentes de controlo e de trabalho. Uma aplicação antiga, que exige uma versão específica do sistema operativo, tende a ir para máquina virtual. Uma aplicação nova, feita em partes independentes, encaixa melhor em contentores, que são a base do estilo cloud-native e das práticas de integração e entrega contínuas, assunto retomado na última lição do módulo. Uma tarefa esporádica — converter um ficheiro, enviar uma notificação, tratar um formulário — é bom candidato à execução sem servidor.

Do lado do armazenamento há três tipos que não se substituem entre si. O armazenamento de blocos é o disco de uma máquina: rápido, é onde vive o sistema operativo e a base de dados. Na maioria dos casos um disco está ligado a uma máquina de cada vez, mas há discos partilháveis, previstos precisamente para aglomerados de servidores que acedem ao mesmo disco em simultâneo, com um sistema de ficheiros preparado para isso. O armazenamento de ficheiros é uma pasta partilhada em rede, acessível por vários computadores ao mesmo tempo, útil para documentos de trabalho de uma equipa. O armazenamento de objectos guarda ficheiros inteiros, cada um com um nome e com informação descritiva associada, acedidos por interface de rede em vez de sistema de ficheiros: é a escolha habitual para digitalizações, fotografias, cópias de segurança e registos que crescem continuamente.

Convém não exagerar as vantagens do armazenamento de objectos. Cresce muito, mas não é ilimitado: há quotas por conta e por recipiente, limites de pedidos por segundo e limites de tamanho por objecto, e o custo tem várias componentes — capacidade guardada, pedidos, tráfego de saída e, em alguns níveis de acesso, penalizações por leitura frequente ou por remoção antecipada. Dizer que é sempre mais barato é falso: depende do padrão de acesso. Para dados lidos muitas vezes ao dia, outro tipo de armazenamento pode sair melhor.

Nos serviços de objectos a terminologia difere entre fornecedores e convém não a baralhar. Na Amazon Web Services, o recipiente chama-se bucket e faz parte do serviço S3. No Azure, o recipiente equivalente chama-se contentor e vive dentro de uma conta de armazenamento, no serviço Blob Storage. São conceitos equivalentes no papel que desempenham — recipiente nomeado de objectos — mas não são a mesma coisa nem têm as mesmas regras de nomes, de permissões e de níveis de acesso. Dizer «bucket» a um contentor do Azure é impreciso; o que se pode dizer é que um corresponde ao outro. As regras de nomes de bucket admitem mais do que letras, números e hífenes — os pontos são permitidos, com restrições, e desaconselhados em certos usos — pelo que o padrão simplificado adoptado no laboratório é uma convenção nossa, e a regra oficial fica indicada nas referências.

Duas regras atravessam toda esta lição. Primeira: o armazenamento é privado por defeito e só se abre o que tiver mesmo de estar aberto, com justificação escrita. Segunda: tudo o que é criado num exercício é apagado no fim do exercício, junto do fornecedor onde foi criado, e a ordem de eliminação respeita as dependências entre recursos.

O arquivo de digitalizações do Serviço Distrital de Ondela (cenário fictício)

O Serviço Distrital de Ondela digitaliza processos de licenciamento. Hoje os ficheiros estão no disco de um computador do gabinete e são copiados à mão para um disco externo, às sextas-feiras, quando alguém se lembra.

A equipa propõe três mudanças. A aplicação de consulta dos processos passa a correr numa máquina virtual, porque depende de uma versão antiga de um componente. As digitalizações passam para armazenamento de objectos, privado, porque são ficheiros que só crescem e raramente mudam depois de criados. A pasta partilhada de minutas de despacho, essa, continua a fazer sentido como armazenamento de ficheiros, acessível a vários postos ao mesmo tempo.

Antes de decidir, a equipa anota duas perguntas de custo: quantas vezes por dia cada digitalização é consultada, e quanto tráfego de saída isso gera. Cenário fictício, para exercício. Não descreve nenhum serviço existente e não indica preços.

Actividade prática

Trabalho em pares, um computador por par, com alternância de quem executa — o Termo de Referência fixa o máximo de dois formandos por computador e recomenda um por computador sempre que o equipamento chegue, com 50 minutos de trabalho, seguidos de 10 minutos de partilha e síntese em plenário.

Primeira parte, em papel, 10 minutos: para o caso fictício de Ondela, decidam que tipo de computação e que tipo de armazenamento servem cada uma das três necessidades, com uma linha de justificação em cada.

Segunda parte, no ambiente de formação, 40 minutos: executar o laboratório abaixo. Dentro do par, uma pessoa executa a primeira metade dos passos e a outra executa a segunda; ambas registam evidência. Havendo um computador por pessoa, cada uma executa o percurso completo.

Quem ficar bloqueado num passo escreve o número do passo e a mensagem de erro exacta na ficha, e passa ao passo seguinte que não dependa dele.

Produto esperado: ficha do par com as três decisões justificadas, a evidência do laboratório, o registo de quem executou cada metade e a ficha de preparação da máquina virtual da lição seguinte.

Laboratório — Criar um recipiente de objectos privado e preparar a máquina virtual da lição seguinte

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: Amazon S3 para o recipiente de objectos. A máquina virtual não é criada nesta lição: só é criada na lição seguinte, já dentro da rede virtual, porque a interface de rede de uma máquina não se muda para outra rede depois de criada. 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

• Amazon Web Services — conta institucional de formação da entidade formadora, com orçamento e alertas de custo definidos pelo formador.
• Amazon Web Services — utilizador ou papel de formação com permissões limitadas por política aos buckets cujo nome comece pelo prefixo da turma, com autorização para criar, listar, carregar e apagar apenas esses buckets.
• Nenhum participante usa conta pessoal, associa cartão de pagamento ou introduz credenciais próprias. Os dados usados são fictícios.
• Ficheiro de exemplo preparado antes pelo formador, sem dados de pessoas.
• Navegador actualizado e ligação à internet estável. Se o ambiente falhar, a prática fica registada como pendente e é reagendada: a demonstração do formador serve para acompanhar o raciocínio, mas não substitui a execução pelos formandos.

Passos

1. Entrar na consola da Amazon Web Services com o utilizador de formação e confirmar, antes de tudo, que está seleccionada a conta de formação e a região combinada.
2. Abrir o serviço S3 e criar um bucket com um nome único global, seguindo a convenção do laboratório: apenas minúsculas, números e hífenes, começando pelo prefixo da turma, por exemplo formacao-nuvem-t01-g03. A regra oficial de nomes é mais permissiva do que esta convenção; fica indicada nas referências.
3. Manter activo o bloqueio de todo o acesso público. O bucket fica privado; nenhum exercício deste curso torna público um recipiente de objectos.
4. Carregar o ficheiro fictício de exemplo e confirmar que aparece na lista de objectos.
5. Copiar o endereço do objecto e abri-lo numa janela anónima do navegador, sem sessão iniciada.
6. Trocar de executante dentro do par e repetir a leitura da configuração: bloqueio de acesso público, política do bucket e lista de objectos.
7. Preparação da lição seguinte, em papel: escrever na ficha o nome que a máquina virtual vai ter, o tamanho autorizado pelo formador, a região, o utilizador administrativo e o método de autenticação por chave. Nada é criado no Azure nesta lição.
8. Registar na ficha o nome do bucket, a região e as horas de criação e de eliminação.

Como verificar o resultado

• O bucket aparece na lista do S3 e o painel indica que o acesso público está bloqueado.
• O objecto carregado aparece na listagem, com o tamanho esperado.
• A abertura do endereço do objecto na janela anónima devolve explicitamente «acesso negado» — é esse o resultado correcto, e é uma verificação positiva de que a regra actua, e não um simples tempo de espera esgotado.
• A ficha de preparação da máquina virtual está preenchida em todos os campos.

Problemas comuns

• Nome de bucket recusado: os nomes são únicos em todo o mundo; acrescentar o código da turma e do grupo. Se o nome contiver maiúsculas ou sublinhados, é recusado pela própria regra oficial.
• Falta de permissão para criar: confirmar que o nome começa pelo prefixo autorizado pela política de formação, e chamar o formador se persistir.
• O endereço do objecto devolve «não encontrado» em vez de «acesso negado»: confirmar o nome exacto do objecto; ambos os resultados significam que não está público, mas só o primeiro confirma que o objecto existe.
• Ambiente indisponível: registar a prática como pendente, com data de reagendamento, e não a dar por cumprida com a demonstração do formador.

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 propriedades do bucket mostrando o bloqueio de acesso público activo, com o identificador da conta tapado.
• Captura de ecrã da listagem de objectos com o ficheiro fictício carregado.
• Captura de ecrã do resultado «acesso negado» na janela anónima.
• Ficha do par com nome do bucket, região, horas, quem executou cada metade e os parâmetros preparados da máquina virtual.

Limpeza

• Amazon Web Services, por ordem de dependência: apagar primeiro os objectos e só depois o bucket, que não pode ser apagado enquanto tiver conteúdo.
• Confirmar que a listagem de buckets com o prefixo da turma deixou de conter o bucket do par.
• Não há nada a apagar no Azure nesta lição, porque nada foi lá criado.

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

• Máquina virtual dá mais controlo e mais trabalho; contentor é mais leve; sem servidor visível é para tarefas curtas e ocasionais.
• Sem servidor visível não significa sem servidores: significa que não somos nós a geri-los, e o custo tem várias componentes.
• Blocos é o disco de uma máquina, normalmente ligado a uma de cada vez, havendo discos partilháveis para casos próprios; ficheiros é a pasta partilhada; objectos é para ficheiros que só crescem.
• O armazenamento de objectos tem quotas, limites e custo com várias componentes: não é ilimitado nem sempre o mais barato.
• Bucket na Amazon e contentor no Azure desempenham o mesmo papel, mas não são a mesma coisa; o padrão de nomes usado no laboratório é convenção nossa, mais estrita do que a regra oficial.
• O armazenamento é privado por defeito, e o que se cria apaga-se no fim, junto do fornecedor onde foi criado.

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 serviço recebe pedidos de certidão duas ou três vezes por dia e limita-se a enviar um aviso por correio electrónico. Que forma de computação estudar primeiro?
2. «O armazenamento de objectos é ilimitado e é sempre a opção mais barata.» A afirmação está correcta?

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. Um serviço recebe pedidos de certidão duas ou três vezes por dia e limita-se a enviar um aviso por correio electrónico. Que forma de computação estudar primeiro?

Resposta: A execução sem servidor visível, porque a tarefa é curta, esporádica e não exige manter um servidor sempre ligado.

Comentário: Antes de decidir, conviria ainda verificar os requisitos de protecção de dados e se o volume se mantém baixo ao longo do ano.

Pergunta 2. «O armazenamento de objectos é ilimitado e é sempre a opção mais barata.» A afirmação está correcta?

Resposta: Não. Há quotas e limites de pedidos e de tamanho, e o custo depende da capacidade, dos pedidos, do tráfego de saída e do nível de acesso escolhido.

Comentário: Para dados consultados muitas vezes por dia, outro tipo de armazenamento pode custar menos. A comparação faz-se com o padrão de acesso em mãos.

Referências consultadas

• Amazon S3 — Getting started with Amazon S3 — https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html (consultado em 21 de Setembro de 2026).
• Amazon S3 — Regras de nomes de buckets — https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html (consultado em 21 de Setembro de 2026).
• Azure — Discos partilhados entre máquinas virtuais — https://learn.microsoft.com/en-us/azure/virtual-machines/disks-shared (consultado em 21 de Setembro de 2026).

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

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

• Distinguir uma base de dados instalada numa máquina virtual de uma base de dados gerida pelo fornecedor, indicando o que muda em responsabilidade e em trabalho.
• Explicar o que a plataforma como serviço assume por nós e o que continua do nosso lado.
• Publicar uma aplicação simples numa plataforma como serviço, no ambiente de formação, verificando o resultado e apagando o que foi criado.

Explicação

Uma base de dados pode correr de duas maneiras na nuvem. Instalada por nós numa máquina virtual, damos-lhe a versão que quisermos e mandamos em tudo — e ficamos com as actualizações, as cópias de segurança, a alta disponibilidade e a afinação a nosso cargo. Gerida pelo fornecedor, recebemos um ponto de ligação e o fornecedor trata do sistema operativo, das actualizações do motor, das cópias automáticas e, se for contratado, da réplica noutra zona. Continua a ser nossa a modelação dos dados, o desempenho das consultas, quem tem acesso e o cumprimento das regras de protecção de dados.

A escolha entre relacional e não relacional mantém-se igual à de sempre: dados com estrutura estável e necessidade de consistência forte — processos, licenças, pagamentos — pedem base relacional; dados de forma variável e volume grande — registos de eventos, documentos, leituras de sensores — encaixam melhor em bases não relacionais. Na nuvem os dois tipos existem em versão gerida.

A plataforma como serviço aplica a mesma ideia à aplicação. Entrega-se o código e a plataforma trata do servidor, do sistema operativo, do servidor de aplicação e do certificado de segurança do endereço, além de permitir aumentar o número de instâncias quando a procura sobe. Do nosso lado ficam o código, a configuração da aplicação, os segredos — que não vão no código, mas na configuração do serviço ou num cofre de segredos — e as ligações à base de dados. Para equipas pequenas costuma dar mais resultado por menos trabalho, e por isso interessa a serviços públicos com poucas pessoas na área informática — mas não é vantajoso em todos os casos: depende dos limites da plataforma e do plano contratado.

As limitações também se devem conhecer. A plataforma impõe versões de linguagem suportadas, tempos máximos de resposta, e por vezes não permite instalar componentes de sistema. Uma aplicação antiga pode não caber sem alterações. É aí que entra a modernização: dividir a aplicação em partes independentes, os microserviços, trocar componentes locais por serviços geridos, e adoptar práticas de integração e entrega contínuas, em que cada alteração é construída e publicada por um processo automático e repetível. Modernizar tem custo e risco, e faz-se por etapas — nunca é obrigatório modernizar tudo para começar a usar nuvem.

Uma nota sobre custos que vale para todo o módulo: o custo depende do plano contratado e há planos em que a capacidade fica reservada, consumindo mesmo com pouco tráfego. Verifica-se antes, no plano concreto, em vez de assumir. Nada é prometido como gratuito e, no laboratório, o que se cria é apagado no fim.

A consulta pública de estado do processo, em Ondela (cenário fictício)

Ondela quer uma página onde o munícipe introduz o número do processo e vê o estado: recebido, em análise, deferido ou indeferido. Não há dados pessoais na resposta, apenas o estado.

A equipa decide publicar essa página numa plataforma como serviço, ligada a uma base de dados gerida onde os estados são actualizados pelo sistema interno. O sistema interno, mais antigo, continua onde está: não é preciso modernizar tudo para pôr esta consulta no ar.

Ficam definidos três pontos antes de avançar: quem pode alterar os estados, quanto tempo ficam guardados os registos de acesso e o que acontece à consulta quando a ligação do distrito cai. Cenário fictício, para exercício.

Actividade prática

Trabalho nos mesmos pares, um computador por par e 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: para a consulta de estado de Ondela, escrevam o que fica do lado do fornecedor e o que fica do lado da instituição, em duas colunas, incluindo segredos, cópias de segurança e controlo de acesso.

Segunda parte, no ambiente de formação, 45 minutos: executar o laboratório de publicação de uma aplicação simples numa plataforma como serviço, trocando de executante a meio.

Terceira parte, dentro do tempo de laboratório: apagar o que foi criado, pela ordem de dependências, e registar a eliminação.

Produto esperado: tabela de responsabilidades partilhadas e evidência da aplicação a responder e depois eliminada, com o endereço público, as horas e o registo de quem executou cada metade.

Laboratório — Publicar uma aplicação simples numa plataforma como serviço

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: Azure App Service, em Linux, com a aplicação Node.js mínima fornecida com este curso. Método único de publicação: linha de comandos do Azure, com implantação a partir de ficheiro comprimido. 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

• Conta institucional de formação com limites de consumo e alertas definidos pelo formador, e grupo de recursos do exercício criado.
• Microsoft Azure — subscrição institucional de formação e grupo de recursos do exercício, com utilizador de formação limitado a esse grupo de recursos. Nada é necessário do lado da Amazon nesta lição.
• Aplicação de exemplo já disponível nesta plataforma, para descarregar: os ficheiros index.js e package.json estão em /exemplos/paas-node/index.js e /exemplos/paas-node/package.json. Usam apenas o módulo http do Node.js, sem dependências a instalar, sem base de dados, sem dados de pessoas e sem segredos no código. O código completo está transcrito mais abaixo.
• Linha de comandos do Azure instalada e sessão iniciada com a conta institucional de formação, feita pelo formador antes da sessão. Não se usam tokens, nem credenciais de publicação, nem autenticação básica.
• Programa para criar ficheiros comprimidos, disponível no sistema operativo da sala.
• Nenhum participante associa cartão de pagamento nem cria subscrição própria. O escalão de serviço a usar é o indicado pelo formador; o material não promete gratuitidade.
• Se a turma não tiver ambiente de desenvolvimento, o formador disponibiliza o código já preparado num arquivo, para carregamento directo.

Ficheiros do exemplo

O exemplo está completo aqui e também disponível para descarregar. Não tem dependências a instalar.

index.js — descarregar

// Exemplo mínimo para o laboratório de plataforma como serviço.
// Proposta pedagógica — por validar pela Ologa/ATDI. Sem dependências externas.
// Usa apenas o módulo http do Node.js.

const http = require("http");

const port = process.env.PORT || 8080;
const mensagem = process.env.MENSAGEM_EXEMPLO || "Mensagem por definir na configuração do serviço.";

const servidor = http.createServer((pedido, resposta) => {
  // Registo mínimo: apenas o método HTTP. Não regista o caminho nem os
  // parâmetros do endereço, que podem conter dados pessoais; não regista
  // cabeçalhos, corpo, endereços nem qualquer dado que possa identificar
  // uma pessoa.
  console.log(pedido.method);

  resposta.writeHead(200, { "Content-Type": "text/plain; charset=utf-8" });
  resposta.end(
    "Laboratório de plataforma como serviço — exemplo de formação.\n" +
      `Mensagem configurada: ${mensagem}\n`,
  );
});

// Escuta em todas as interfaces: exigido pela plataforma.
servidor.listen(port, "0.0.0.0", () => {
  console.log(`Servidor de exemplo à escuta na porta ${port}`);
});

package.json — descarregar

{
  "name": "exemplo-paas-formacao",
  "version": "1.0.0",
  "private": true,
  "description": "Exemplo mínimo de aplicação Node.js para o laboratório de plataforma como serviço do curso Computação em Nuvem.",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "engines": {
    "node": ">=20"
  },
  "dependencies": {}
}

Passos

1. Teste local, antes de qualquer publicação: descarregar os dois ficheiros do exemplo, colocá-los numa pasta e executar «node index.js». Abrir http://localhost:8080 e confirmar a resposta. Parar, executar de novo definindo a variável MENSAGEM_EXEMPLO e confirmar que o texto muda. Este teste é local e não usa nuvem nenhuma; serve para separar problemas do código de problemas da publicação.
2. No portal do Azure, dentro do grupo de recursos do exercício, criar uma aplicação Web indicando pilha de execução Node.js e sistema operativo Linux, com nome que identifique a turma e o grupo.
3. Escolher o plano de serviço indicado pelo formador e a região combinada. Não subir de escalão por iniciativa própria.
4. Rever e criar. Esperar pela conclusão e abrir a página do recurso.
5. Preparar o ficheiro comprimido: colocar index.js e package.json numa pasta vazia e comprimir os DOIS ficheiros de forma a ficarem na raiz do arquivo, e não dentro de uma subpasta. Verificar a listagem do arquivo antes de publicar.
6. Publicar com um único comando, a partir da pasta onde está o arquivo: az webapp deploy --resource-group <grupo-de-recursos> --name <nome-da-aplicacao> --src-path exemplo-paas.zip --type zip
7. Confirmar nas definições gerais da aplicação que a versão de Node.js corresponde à indicada no package.json e que o comando de arranque é «node index.js». O arquivo publicado não é construído automaticamente, por isso a aplicação tem de correr tal como está — é por essa razão que o exemplo não tem dependências a instalar.
8. Abrir o endereço público atribuído à aplicação e confirmar que a página responde.
9. Nas definições da aplicação, criar a variável de configuração MENSAGEM_EXEMPLO com um valor fictício, guardar, aguardar o reinício e recarregar a página: o texto apresentado muda. A variável não é segredo, mas demonstra o mecanismo — é assim que se tratam também as palavras-passe, fora do código.
10. Confirmar nos registos da aplicação que o pedido feito no navegador aparece registado.
11. Registar na ficha o endereço público, a hora da publicação e o escalão usado.
12. Limpeza: apagar a aplicação Web. Quanto ao plano de serviço, apagar apenas se tiver sido criado para este exercício; se for partilhado ou já existisse, NÃO se apaga e regista-se na ficha. O plano continua a consumir mesmo sem aplicação, por isso o formador confirma no fim que não ficou nenhum plano exclusivo esquecido.

Como verificar o resultado

• O endereço público da aplicação abre no navegador e mostra a página de exemplo.
• A variável de configuração definida no portal é visível no comportamento da aplicação, sem constar do código.
• Os registos mostram o pedido correspondente ao acesso feito.
• Depois da limpeza, o endereço deixa de responder e o grupo de recursos do exercício fica apenas com os recursos partilhados que já lá estavam antes da sessão, se existirem.

Problemas comuns

• Nome de aplicação já usado: o endereço é único; acrescentar o código da turma e do grupo.
• A página mostra erro de aplicação: quase sempre falta o ficheiro de arranque esperado ou a pilha de execução escolhida não corresponde ao código; verificar os registos antes de repetir a publicação.
• Publicação concluída mas página antiga: aguardar o reinício da aplicação ou forçá-lo; não publicar várias vezes seguidas às cegas.
• Escalão indisponível na região: escolher outra região da lista autorizada, mantendo o mesmo escalão.
• Plano de serviço esquecido depois de apagar a aplicação: é um recurso separado; se foi criado só para este exercício, apaga-se também.
• Comando recusado por falta de sessão: a sessão da linha de comandos é iniciada pelo formador com a conta institucional; os participantes não introduzem credenciais próprias.
• Arquivo com uma pasta a envolver os ficheiros: a aplicação não arranca; recriar o arquivo com index.js e package.json na raiz.

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ã da execução local do exemplo, antes de qualquer publicação.
• Captura de ecrã da página publicada, com o endereço visível.
• Captura de ecrã das definições de configuração mostrando a variável de exemplo, com valores fictícios apenas.
• Captura de ecrã da lista de recursos depois da limpeza, mostrando que a aplicação já não consta; se o plano de serviço era exclusivo do exercício, a captura mostra também que ele já não consta.
• Linha na ficha com endereço, escalão, hora de publicação e hora de eliminação.

Limpeza

• Apagar por ordem de dependências, apenas no Azure e apenas os recursos deste exercício: primeiro a aplicação Web, que depende do plano de serviço.
• Apagar o plano de serviço apenas se tiver sido criado para este exercício. Se o plano for partilhado com outros grupos ou já existisse, NÃO se apaga; regista-se na ficha que ficou por ser partilhado.
• Conferir que no grupo de recursos do exercício ficaram apenas os recursos partilhados anteriores à sessão, e registar 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

• Base de dados gerida: o fornecedor trata do motor e das cópias; nós tratamos dos dados, dos acessos e das consultas.
• Plataforma como serviço: entregamos código, a plataforma trata do servidor e do certificado do endereço.
• Os segredos ficam na configuração do serviço ou num cofre, nunca no código.
• A plataforma impõe limites, como versões suportadas; aplicações antigas podem precisar de alterações.
• Modernizar — microserviços, serviços geridos, entrega automática — faz-se por etapas e não é condição para começar.
• Conforme o plano, a capacidade pode ficar reservada e consumir mesmo sem tráfego: verifica-se antes, e no exercício apaga-se o que foi criado, incluindo o plano se tiver sido criado para o exercício.

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. Com uma base de dados gerida, deixamos de ser responsáveis pela protecção dos dados pessoais que lá estão?
2. Onde deve ficar a palavra-passe de ligação à base de dados numa aplicação publicada em plataforma como serviço?

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. Com uma base de dados gerida, deixamos de ser responsáveis pela protecção dos dados pessoais que lá estão?

Resposta: Não. O fornecedor trata da infra-estrutura e do motor; a instituição continua responsável pelos dados, por quem lhes acede e pelo cumprimento das regras aplicáveis.

Comentário: Esta é a linha de responsabilidade partilhada que já apareceu no módulo 1 e que volta no módulo sobre protecção de dados.

Pergunta 2. Onde deve ficar a palavra-passe de ligação à base de dados numa aplicação publicada em plataforma como serviço?

Resposta: Na configuração do serviço ou num cofre de segredos, nunca escrita no código nem no material de formação.

Comentário: Segredos no código acabam quase sempre em repositórios partilhados, e a partir daí deixam de ser segredos.

Referências consultadas

• Azure App Service — Quickstart: criar uma aplicação Web Node.js — https://learn.microsoft.com/en-us/azure/app-service/quickstart-nodejs (consultado em 21 de Setembro de 2026).
• Azure App Service — Implantar ficheiros comprimidos (nota: o envio pela interface Kudu não funciona em Linux e o arquivo não é construído por defeito) — https://learn.microsoft.com/en-us/azure/app-service/deploy-zip (consultado em 21 de Setembro de 2026).

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

• Distinguir disponibilidade, cópia de segurança e recuperação de desastre, e explicar porque é que uma não substitui a outra.
• Definir, para um serviço concreto, o tempo máximo de paragem aceitável e a perda máxima de dados aceitável.
• Elaborar um plano de cópias e um procedimento de restauro testável, com responsáveis e periodicidade.

Explicação

Três conceitos costumam ser confundidos. Disponibilidade é a capacidade de o serviço continuar a responder quando uma peça falha: consegue-se com várias instâncias, distribuídas por zonas diferentes, com um distribuidor de carga à frente. Cópia de segurança é a existência de uma versão anterior dos dados, que permite voltar atrás quando alguém apaga ou corrompe informação. Recuperação de desastre é a capacidade de repor o serviço inteiro noutro sítio quando o primeiro deixa de existir. Ter três instâncias da aplicação não protege contra alguém apagar a tabela de processos; ter cópias diárias não evita que o serviço esteja em baixo durante a manhã.

Para planear, usam-se duas medidas. A primeira é o tempo máximo de paragem aceitável: quanto tempo pode o serviço estar indisponível sem consequência inaceitável. A segunda é a perda máxima de dados aceitável: quanto trabalho se admite perder, medido em tempo — uma hora, um dia. Estas duas medidas não são escolhas técnicas: são decisões de quem dirige o serviço, porque determinam custo. Um serviço que admite meio dia de paragem e uma hora de perda tem um desenho muito mais barato do que um que não admite paragem nenhuma.

Do lado técnico, os instrumentos habituais são: várias instâncias em zonas diferentes da mesma região, para falhas locais; réplica noutra região, para desastre; cópias automáticas com retenção definida, para erro humano; e versões de objectos no armazenamento, para recuperar ficheiros apagados. Muitos serviços geridos oferecem cópias automáticas com um período de retenção, mas o período por omissão pode não corresponder ao que a instituição precisa — e a retenção por omissão nunca deve ser assumida sem verificação.

Há uma regra que vale mais do que toda a tecnologia: uma cópia de segurança que nunca foi restaurada não é uma cópia de segurança, é uma esperança. O restauro tem de ser ensaiado, com periodicidade definida, para um ambiente separado, e o ensaio tem de ser registado: quem fez, quando, quanto tempo demorou e o que correu mal. É esse registo que permite dizer, com honestidade, quanto tempo demora a repor o serviço.

Por fim, o plano tem de prever a comunicação. Quando um serviço público pára, as pessoas continuam a precisar dele. Saber quem avisa, por que meio e o que se faz manualmente enquanto o sistema não volta é parte do plano, e não um detalhe administrativo. Em contextos com ligação intermitente, o procedimento manual de recurso é especialmente importante.

A manhã em que o portal de Ondela ficou em baixo (cenário fictício)

Numa terça-feira de manhã, o portal de licenciamento de Ondela deixa de responder. A equipa descobre que uma actualização mal sucedida corrompeu parte dos dados às 22 horas do dia anterior.

A cópia automática mais recente é das 20 horas. Restaurar significa perder duas horas de registos, que terão de ser reintroduzidos a partir dos formulários em papel. O restauro demora 40 minutos, mas ninguém tinha ensaiado antes e passa-se mais uma hora a perceber o procedimento.

Na revisão, o serviço define: perda máxima aceitável de uma hora, o que obriga a cópias de hora a hora; tempo máximo de paragem de duas horas; ensaio de restauro trimestral com registo; e um procedimento em papel para o atendimento continuar enquanto o sistema não volta. Cenário fictício, para exercício.

Actividade prática

Trabalho em grupos de quatro, com 55 minutos de trabalho, seguidos de 10 minutos de partilha e síntese em plenário.

Escolham um serviço da vossa instituição, real na função mas descrito sem dados de pessoas.

Definam e justifiquem o tempo máximo de paragem aceitável e a perda máxima de dados aceitável, dizendo quem, na instituição, tem competência para aprovar esses valores.

Escrevam o plano de cópias: o que se copia, com que periodicidade, quanto tempo se guarda, onde fica guardado e quem verifica que a cópia foi feita.

Escrevam o procedimento de restauro em passos numerados, incluindo como se confirma que o restauro correu bem, e marquem no calendário o primeiro ensaio.

Acrescentem meia página de plano de comunicação e de recurso manual: quem avisa, por que meio, e o que o atendimento faz enquanto o serviço não volta.

Produto esperado: plano de continuidade de duas páginas com as duas medidas justificadas, plano de cópias, procedimento de restauro numerado e plano de comunicação e recurso manual.

Síntese em leitura fácil

• Disponibilidade é continuar a responder; cópia é poder voltar atrás; recuperação de desastre é repor noutro sítio. São três coisas diferentes.
• Decidir quanto tempo o serviço pode estar parado e quanto trabalho se pode perder é decisão de direcção, porque determina o custo.
• Cópia que nunca foi restaurada não conta: o ensaio de restauro faz-se com periodicidade e fica registado.
• A retenção por omissão do fornecedor pode não servir; verifica-se sempre.
• O plano inclui avisar as pessoas e ter um procedimento manual enquanto o serviço não volta.

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 serviço corre em três instâncias, em zonas diferentes. Está protegido contra a eliminação acidental de uma tabela de dados?
2. Quem deve decidir que o serviço pode estar parado no máximo 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 qualquer efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. Um serviço corre em três instâncias, em zonas diferentes. Está protegido contra a eliminação acidental de uma tabela de dados?

Resposta: Não. Várias instâncias protegem contra falha de infra-estrutura, não contra erro humano nos dados. Para isso é preciso cópia de segurança com retenção.

Comentário: As três instâncias replicariam a eliminação de imediato. É exactamente por isso que disponibilidade e cópia são planeadas em separado.

Pergunta 2. Quem deve decidir que o serviço pode estar parado no máximo duas horas?

Resposta: A direcção responsável pelo serviço, porque é uma decisão sobre risco e custo, informada pela equipa técnica.

Comentário: Quando esta decisão fica implícita, acaba por ser tomada por omissão, e descobre-se o valor real no dia da avaria.

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: 105 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: 50 minutos.
• Partilha e síntese: 10 minutos.

Objectivos da lição

• Desenhar uma arquitectura simples para um serviço público, indicando componentes, fluxos e fronteiras de segurança.
• Justificar, em cada componente, a escolha entre máquina virtual, contentor, execução sem servidor e serviço gerido.
• Identificar onde entram microserviços, práticas cloud-native e entrega automática, e o que fica para uma etapa posterior de modernização.

Explicação

Desenhar uma arquitectura é responder, por escrito, a cinco perguntas: que componentes existem, por onde entra o pedido, onde ficam os dados, que fronteiras de segurança separam as partes e o que acontece quando uma parte falha. Um desenho que não responda a estas cinco perguntas é um diagrama bonito, não uma arquitectura.

A arquitectura mais comum num serviço público simples tem quatro camadas: entrada — o endereço público, com certificado e, se necessário, filtragem de pedidos; aplicação — uma ou mais instâncias, em plataforma como serviço ou em contentores; dados — base de dados gerida numa sub-rede privada, sem endereço público; e armazenamento de objectos, privado, para documentos e digitalizações. Entre camadas, regras de permissão mínima, como se viu na lição de redes.

Microserviços são a divisão da aplicação em partes pequenas e independentes, cada uma com a sua responsabilidade e o seu ritmo de actualização. Resolvem problemas de equipas grandes e de sistemas que crescem; introduzem em troca complexidade de comunicação, de observação e de resolução de problemas. Para um serviço distrital com uma aplicação e duas pessoas na informática, uma aplicação única bem organizada é normalmente a decisão certa, e dividir só quando houver razão concreta.

Cloud-native descreve o estilo de construir para este ambiente: componentes substituíveis, configuração fora do código, estado guardado em serviços próprios e não no disco da máquina, e capacidade de arrancar mais instâncias sem intervenção manual. DevOps é a prática de trabalho que acompanha: mesma equipa responsável por construir e por manter, alterações pequenas e frequentes, e um processo automático que constrói, testa e publica sempre da mesma maneira. O ganho não é a moda: é que a publicação deixa de depender da memória de uma pessoa.

A modernização faz-se por etapas e cada etapa tem de valer por si. Uma sequência frequente: primeiro mover a aplicação como está, depois trocar componentes instalados por serviços geridos, depois automatizar a publicação, e só então, se houver razão, separar partes em serviços independentes. Escrever a ordem das etapas, com o benefício esperado de cada uma, é tão importante como o desenho final — e evita a promessa de que tudo muda ao mesmo tempo.

Por último, o desenho tem de dizer o que fica de fora. Um bom documento de arquitectura tem uma secção de pressupostos e outra de pontos por apurar: ligação disponível no local, volume esperado, exigências de localização dos dados, competências da equipa. Nenhum deles é detalhe técnico — todos podem inverter a decisão.

Arquitectura da consulta de processos de Ondela (cenário fictício)

Entrada: endereço público com certificado, apenas para a página de consulta. Aplicação: uma aplicação única em plataforma como serviço, com duas instâncias. Dados: base de dados gerida em sub-rede privada, sem endereço público, acessível apenas a partir da sub-rede da aplicação. Documentos: armazenamento de objectos privado, com acesso concedido à aplicação e a mais ninguém.

Falhas previstas: se uma instância cair, a outra responde; se a base de dados falhar, a página mostra aviso e o atendimento passa ao procedimento manual; se a ligação do distrito cair, a consulta interna fica indisponível e o balcão usa a listagem impressa do dia.

Etapas de modernização propostas: primeiro publicar a consulta; depois automatizar a publicação; só mais tarde, se o volume crescer, separar a componente de digitalizações. Pressupostos por confirmar: volume diário de consultas e exigências sobre onde os dados podem residir. Cenário fictício, para exercício.

Actividade prática

Trabalho em grupos de quatro, com apresentação por amostra, com 50 minutos de trabalho, seguidos de 10 minutos de partilha e síntese em plenário.

Escolham um dos dois casos fictícios propostos pelo formador, ou o serviço que trabalharam na lição anterior.

Desenhem a arquitectura em papel A3: componentes, setas de fluxo, fronteiras de rede e o que é privado.

Numa folha à parte, justifiquem cada componente — porquê máquina virtual, contentor, execução sem servidor ou serviço gerido — em uma linha cada.

Escrevam as etapas de modernização por ordem, com o benefício esperado de cada uma, e a secção de pressupostos e pontos por apurar.

Verifiquem o desenho contra as cinco perguntas da exposição, e corrijam o que faltar.

Produto esperado: desenho de arquitectura em A3, folha de justificações por componente, lista ordenada de etapas de modernização e secção de pressupostos e pontos por apurar.

Síntese em leitura fácil

• Uma arquitectura responde a cinco perguntas: que componentes, por onde entra, onde ficam os dados, que fronteiras e o que falha.
• O desenho simples tem quatro camadas: entrada, aplicação, dados privados e armazenamento de objectos privado.
• Microserviços resolvem problemas de escala e de equipa; para serviços pequenos, uma aplicação única bem organizada costuma bastar.
• Cloud-native e DevOps significam configuração fora do código, estado fora da máquina e publicação automática e repetível.
• A modernização faz-se por etapas, cada uma com benefício próprio.
• Um bom documento diz também o que ainda não se sabe.

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 serviço distrital com uma aplicação e duas pessoas na informática deve começar por dividir o sistema em microserviços?
2. Porque é que a base de dados não deve ter endereço público, mesmo com palavra-passe forte?

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. Um serviço distrital com uma aplicação e duas pessoas na informática deve começar por dividir o sistema em microserviços?

Resposta: Normalmente não. A divisão acrescenta complexidade de comunicação e de manutenção; justifica-se quando há razão concreta, como partes com ritmos de mudança muito diferentes.

Comentário: A decisão certa depende do problema a resolver, e não da modernidade do vocabulário.

Pergunta 2. Porque é que a base de dados não deve ter endereço público, mesmo com palavra-passe forte?

Resposta: Porque a exposição amplia a superfície de ataque sem necessidade: o acesso deve vir apenas da sub-rede da aplicação, por regra de permissão mínima.

Comentário: É a mesma regra da lição de redes, aplicada agora ao desenho global.

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

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

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

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

Objectivos da lição

• Distinguir autenticação de autorização e explicar, com exemplo próprio, o que cada uma resolve.
• Aplicar o princípio do menor privilégio escolhendo função e âmbito adequados para os seis intervenientes — pessoas e sistemas — de um serviço público.
• Elaborar uma matriz de permissões completa que inclua contas humanas, identidades de aplicação, separação de tarefas, autenticação multifactor e prazos de revisão e revogação.

Explicação

Autenticação e autorização são duas perguntas diferentes e são respondidas por mecanismos diferentes. A autenticação responde a «quem é esta pessoa ou este sistema?» e apoia-se em algo que se sabe (uma palavra-passe), algo que se tem (um telemóvel, uma chave física) ou algo que se é (uma característica biométrica). A autorização responde a «o que é que esta identidade, já reconhecida, pode fazer, e sobre que recursos?». Um erro frequente na administração pública é resolver bem a primeira e descuidar a segunda: toda a gente entra com a sua conta pessoal, mas toda a gente é administradora de tudo. Nesse desenho, uma única conta comprometida — ou um único engano de boa-fé — chega para apagar o que existe.

A autorização nas plataformas de nuvem organiza-se, em regra, em três peças: uma identidade (a pessoa, o grupo ou a identidade de uma aplicação), um conjunto de acções permitidas (a função, também chamada papel) e o conjunto de recursos onde essa função se aplica (o âmbito). O âmbito é hierárquico: atribuir uma função no nível mais alto da hierarquia faz com que ela desça a tudo o que está por baixo. A recomendação da documentação do Azure sobre boas práticas de controlo de acesso baseado em funções é precisamente esta: atribuir a função mais limitada que resolve a necessidade, no âmbito mais estreito que resolve a necessidade, e preferir funções específicas em vez da função de proprietário. Quem precisa de ler as facturas de um projecto não precisa de poder apagar máquinas desse projecto; quem precisa de reiniciar uma máquina não precisa de poder alterar as regras de rede.

O princípio do menor privilégio ganha força quando é acompanhado de separação de tarefas. Separação de tarefas quer dizer que actos com consequências grandes não dependem de uma só pessoa: quem pede a criação de um recurso não é quem aprova a despesa; quem administra as identidades não é, ao mesmo tempo, quem audita os registos de acesso; quem desenvolve não é quem autoriza a colocação em produção. Nas instituições pequenas, com poucas pessoas técnicas, a separação completa nem sempre é possível. Nesse caso escreve-se o que é possível — por exemplo, exigir uma segunda aprovação por escrito do responsável do serviço — e regista-se a limitação em vez de a esconder.

Convém não confundir duas expressões que costumam ser usadas como sinónimos. «Autenticação em dois passos» quer dizer apenas que são pedidas duas provas seguidas; «autenticação multifactor» exige que essas provas pertençam a categorias diferentes — algo que se sabe, algo que se tem, algo que se é. Pedir uma palavra-passe e, a seguir, uma pergunta de segurança são dois passos, mas continuam a ser duas coisas que a pessoa sabe: não é multifactor e cai com o mesmo tipo de compromisso. O que deve ser exigido em todas as contas com permissões administrativas, e é boa prática exigir em todas as contas humanas, é multifactor. O segundo factor mais acessível costuma ser uma aplicação geradora de códigos no telemóvel, que funciona sem ligação à internet e por isso serve bem onde a rede é fraca; chaves físicas são outra opção da mesma categoria. Os códigos de recuperação impressos NÃO são um segundo factor equivalente nem um método de uso corrente: são um mecanismo de recuperação excepcional, para quando o factor habitual se perde, e têm de ser guardados em condições de segurança definidas na política da instituição, com registo de quem lhes acede e substituição depois de usados. É preciso ter em conta a acessibilidade: pessoas com baixa visão ou com dificuldade motora podem precisar de mais tempo para introduzir códigos, de códigos com contraste adequado ou de um método alternativo previamente combinado. Um segundo factor que exclui parte dos trabalhadores não é segurança, é barreira.

Contas humanas e identidades de aplicação não se governam da mesma maneira. Uma pessoa tem nome, vínculo, chefia e data de saída; uma aplicação, um serviço agendado ou um script de cópias de segurança tem uma identidade própria que não deve ser a conta pessoal de ninguém. Quando um programa corre com a conta de uma pessoa, acontecem dois problemas: o registo de auditoria deixa de dizer quem fez o quê, e o dia em que essa pessoa sai da instituição o serviço pára. As plataformas oferecem identidades próprias para aplicações, algumas geridas pela própria plataforma sem segredo para guardar. Sempre que existir essa possibilidade, é preferível a uma chave escrita num ficheiro de configuração.

Por fim, permissões são coisa viva: precisam de revisão e de revogação. Revisão é olhar periodicamente para quem tem o quê e confirmar que ainda faz sentido — trimestral para permissões administrativas é uma periodicidade razoável de propor. Revogação é retirar o acesso quando termina o motivo: fim de contrato, mudança de funções, fim de um projecto, fim de um estágio. O momento mais esquecido é a mudança interna de funções, em que a pessoa acumula as permissões novas sobre as antigas; ao fim de alguns anos acumulou acesso a quase tudo. A regra prática é acrescentar sempre com prazo e retirar o que deixou de ser necessário no mesmo acto administrativo que muda as funções.

A Direcção Distrital de Serviços de Ondela e o portal de licenciamento (cenário fictício)

A Direcção Distrital de Serviços de Ondela tem um portal de licenciamento a correr na nuvem. Trabalham nele seis intervenientes: a directora, que precisa de ver o consumo e aprovar despesa; um técnico de sistemas, que cria e reinicia máquinas; uma técnica de base de dados, que só trabalha sobre a base de dados do portal; um fornecedor externo contratado por três meses para migrar dados; um serviço automático de cópias de segurança que corre todas as noites; e uma estagiária que produz relatórios de atendimento a partir de dados já anonimizados.

Hoje todos entram com a mesma conta partilhada «admin.ondela», cuja palavra-passe está escrita num papel dentro da gaveta da secretária. Quando algo corre mal, ninguém consegue dizer quem fez a alteração. Quando o fornecedor terminar o contrato, não há nada para revogar — a palavra-passe continuará a servir.

O caso é fictício e serve de exercício. Não descreve nenhuma instituição existente.

Actividade prática

Trabalho em pares, com 45 minutos de trabalho, seguidos de 10 minutos de partilha e síntese em plenário.

Exercício de análise e simulação documental, feito em papel ou em folha de cálculo. Nesta lição não se criam nem se alteram recursos na nuvem e não se declara nenhum laboratório como executado.

Recomenda-se um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem escreve a cada parte do exercício, de modo que ambas trabalhem no teclado.

A partir do caso de Ondela, construam uma matriz de permissões completa com uma linha por interveniente: directora, técnico de sistemas, técnica de base de dados, fornecedor externo, serviço automático de cópias de segurança e estagiária.

Cada linha deve ter, obrigatoriamente, sete colunas preenchidas: (1) tipo de identidade — conta humana nominal ou identidade de aplicação; (2) o que precisa mesmo de fazer, em linguagem de tarefa e não de tecnologia; (3) função atribuída, com nome que descreva a acção permitida, por exemplo «leitor de custos» ou «operador de máquinas virtuais»; (4) âmbito — toda a subscrição, apenas o grupo de recursos do portal, ou apenas um recurso concreto; (5) autenticação multifactor exigida sim ou não, com justificação e indicação da categoria do segundo factor; (6) prazo de validade do acesso e data de revisão; (7) evento que obriga a revogar imediatamente.

Acrescentem duas linhas finais: uma que identifique um par de tarefas que não deve ficar na mesma pessoa, explicando porquê, e outra que declare o que não é possível separar nesta direcção por falta de pessoal, com a medida compensatória proposta.

Nenhuma linha pode ficar com «administrador de tudo» sem uma justificação escrita. Se faltar informação para decidir, escrevam «por apurar» e indiquem a quem seria preciso perguntar.

Rubrica de apreciação, sobre 10 pontos: 3 pontos pela matriz completa, com os seis intervenientes e as sete colunas preenchidas; 3 pontos pelo ajuste entre a tarefa e a função e o âmbito escolhidos, sem permissões a mais; 2 pontos pelo tratamento correcto do serviço automático como identidade de aplicação e não como conta de pessoa; 1 ponto pela separação de tarefas identificada e justificada; 1 ponto pelos prazos de revisão e pelos eventos de revogação. Perde 1 ponto qualquer matriz que invente informação em vez de escrever «por apurar».

Produto esperado: uma matriz de permissões com seis intervenientes e sete colunas preenchidas, mais duas linhas sobre separação de tarefas e sobre a limitação assumida, pronta a ser discutida com a chefia.

Síntese em leitura fácil

• Autenticação é saber quem é. Autorização é saber o que pode fazer.
• Menor privilégio: a função mais limitada, no âmbito mais estreito, durante o tempo necessário.
• Dois passos não é o mesmo que multifactor: as duas provas têm de ser de categorias diferentes.
• Códigos de recuperação servem para casos excepcionais, guardados com segurança; não são o segundo factor do dia-a-dia.
• O âmbito desce na hierarquia: o que é dado no nível de cima vale para tudo o que está por baixo.
• Contas partilhadas apagam a responsabilidade: cada pessoa tem a sua conta, com o seu nome.
• Programas e serviços automáticos usam identidades de aplicação, nunca a conta de uma pessoa.
• Autenticação multifactor para todas as contas administrativas: duas provas de categorias diferentes, com alternativa acessível combinada.
• Tarefas com grande consequência não ficam todas na mesma pessoa; quando não for possível separar, escreve-se a limitação.
• Permissões revêem-se com data marcada e revogam-se quando termina o motivo.

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. Uma pessoa precisa de ver quanto custou o portal no mês passado. Que função e que âmbito lhe atribui?
2. Porque é que o serviço nocturno de cópias de segurança não deve correr com a conta do técnico de sistemas?

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. Uma pessoa precisa de ver quanto custou o portal no mês passado. Que função e que âmbito lhe atribui?

Resposta: Uma função apenas de leitura de custos, no âmbito do grupo de recursos ou do projecto do portal — nunca uma função de administração, nem no âmbito de toda a subscrição.

Comentário: Ver despesa não exige poder alterar recursos. Escolher o âmbito mais estreito limita o dano de um engano ou de uma conta comprometida.

Pergunta 2. Porque é que o serviço nocturno de cópias de segurança não deve correr com a conta do técnico de sistemas?

Resposta: Porque a auditoria deixa de distinguir quem agiu, o serviço herda todas as permissões da pessoa e pára no dia em que essa conta for desactivada.

Comentário: Identidades de aplicação existem para isto: permissões próprias, mínimas, e ciclo de vida separado do das pessoas.

Referências consultadas

• Microsoft Learn — Best practices for Azure RBAC — https://learn.microsoft.com/en-us/azure/role-based-access-control/best-practices (consultado em 21 de Setembro de 2026).
• NIST SP 800-145, The NIST Definition of Cloud Computing — https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-145.pdf (consultado em 21 de Setembro de 2026).

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

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

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

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

Objectivos da lição

• Classificar um conjunto de dados de um serviço público em três níveis de sensibilidade e justificar cada classificação.
• Distinguir criptografia em trânsito de criptografia em repouso e indicar o que cada uma protege e o que não protege.
• Elaborar um plano de protecção de dados, sem usar dados reais, que cubra minimização, retenção, gestão de chaves e segredos, controlo de acessos e cópias de segurança.

Explicação

Proteger dados na nuvem começa antes de qualquer configuração técnica: começa por saber que dados existem e quanto valem. Classificar é atribuir a cada conjunto de dados um nível de sensibilidade — por exemplo público, interno e confidencial — e derivar desse nível as regras de tratamento. Dados públicos são os que podem ser divulgados sem dano: um horário de atendimento, uma lista de documentos exigidos. Dados internos circulam dentro da instituição e o seu conhecimento por terceiros causa incómodo ou vantagem indevida. Dados confidenciais são os que, divulgados, causam dano a pessoas concretas: dados de saúde, dados de identificação, situação familiar, dados sobre deficiência. Sem esta classificação, a instituição trata tudo com o mesmo cuidado — o que na prática significa tratar tudo com o cuidado do dado menos sensível.

A seguir vem a minimização, que é a medida mais barata e a mais esquecida: recolher apenas o que é necessário para a finalidade, e guardar apenas enquanto for necessário. Cada campo a mais num formulário é um risco a mais, um custo a mais de armazenamento e uma obrigação a mais de protecção. Uma pergunta útil para cada campo é: se este dado desaparecer, que decisão deixa de ser possível? Se não houver resposta, o campo não deveria estar a ser recolhido. A retenção é a mesma ideia no tempo: definir por escrito quanto tempo cada conjunto de dados é conservado, o que acontece no fim desse prazo — apagar, anonimizar ou arquivar — e quem executa essa operação. Um plano de retenção que não diz quem executa não é executado.

A criptografia protege os dados de quem não deve conseguir lê-los, e trabalha em dois momentos distintos. Em trânsito, protege os dados enquanto viajam pela rede — entre o navegador e o serviço, ou entre dois serviços — normalmente com protocolo TLS; sem isso, quem estiver na rede no meio do caminho pode ler ou alterar o que passa. Em repouso, protege os dados gravados em discos, em contentores de objectos, em cópias de segurança e em bases de dados; nas grandes plataformas de nuvem, a documentação de referência descreve a cifra em repouso como comportamento por omissão em vários serviços de armazenamento, com possibilidade de o cliente gerir as suas próprias chaves. O que a criptografia em repouso protege é sobretudo o cenário de alguém aceder ao suporte físico ou a cópias em bruto.

É importante ser honesto sobre os limites da criptografia, porque há muita expectativa mal colocada. A cifra em repouso não impede o acesso indevido de quem tem permissão válida na plataforma: para esse utilizador, o sistema decifra os dados de forma transparente. Não protege contra uma aplicação mal construída que mostre dados a quem não deve, nem contra uma exportação feita por alguém autorizado, nem contra uma ligação partilhada publicamente por engano. Não protege contra a perda da chave — perder a chave é perder os dados. E não substitui a minimização: dado que não existe não precisa de ser cifrado. A criptografia é uma camada entre várias, não um selo que dispensa as restantes.

As chaves e os segredos exigem governação própria. Chaves de cifra, palavras-passe de bases de dados, credenciais de integração e tokens de aplicações não pertencem a ficheiros de configuração, a mensagens de correio electrónico, a grupos de conversa nem a repositórios de código. Guardam-se num cofre de segredos da plataforma, com acesso atribuído por função e registo de quem os leu. Convém definir por escrito quem pode criar, ler, substituir e destruir cada segredo, com que periodicidade é substituído e o que se faz quando uma pessoa com esse acesso sai da instituição. Nas contas em que a plataforma gere a chave por omissão, a instituição deve saber que assim é e registar a decisão; nas contas em que a instituição gere a chave, tem de existir procedimento de guarda e de recuperação, porque a responsabilidade passa a ser sua.

Por fim, protecção de dados inclui os acessos e as cópias de segurança, que são frequentemente o ponto mais fraco. De pouco vale cifrar a base de dados se a exportação diária fica num contentor de objectos aberto ao público, ou se as cópias são copiadas para um disco externo que anda na mala de alguém. As cópias herdam a classificação dos dados que contêm: se o original é confidencial, a cópia é confidencial, e o mesmo se aplica aos ambientes de teste. Usar dados reais de pessoas para testar é uma prática a evitar; dados de teste devem ser inventados ou despersonalizados. É o que fazemos neste curso, e é também por isso que o plano de protecção que vamos escrever a seguir não usa nenhum dado real.

O registo de apoio social de Ondela (cenário fictício)

O Serviço Distrital de Acção Social de Ondela mantém um registo de candidaturas a apoio social. Cada candidatura tem nome, número de documento de identificação, morada, agregado familiar, rendimento declarado, informação sobre deficiência quando aplicável e uma cópia digitalizada do documento de identificação. O formulário pede ainda o nome da escola dos filhos e a profissão dos avós, campos que ninguém consegue explicar para que servem.

O sistema corre na nuvem. Todas as noites é exportado um ficheiro com todas as candidaturas do dia para um contentor de objectos, de onde uma técnica o descarrega para preparar um relatório em folha de cálculo, que guarda no seu computador pessoal. A palavra-passe da base de dados está escrita num ficheiro de configuração dentro da máquina virtual, e a mesma palavra-passe é usada no ambiente de testes, que contém uma cópia integral dos dados reais.

O caso é fictício. Serve para exercício de análise e não descreve nenhum registo existente.

Actividade prática

Trabalho em pares, com 45 minutos de trabalho, seguidos de 10 minutos de partilha e síntese em plenário.

Exercício de análise e simulação documental, feito em papel ou em folha de cálculo. Nesta lição não se criam nem se alteram recursos na nuvem e não se declara nenhum laboratório como executado.

Recomenda-se um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem escreve a cada parte do exercício, de modo que ambas trabalhem no teclado.

Não se usam dados reais nesta actividade. Trabalha-se apenas sobre o caso fictício de Ondela; se algum par quiser aproximar-se da sua instituição, descreve categorias de dados («nome», «número de documento»), nunca dados de pessoas concretas.

Parte 1 — classificação e minimização. Listem os campos do registo de candidaturas e, para cada um, indiquem o nível (público, interno ou confidencial), a finalidade em uma frase e a decisão: manter, anonimizar ou deixar de recolher. Os campos sem finalidade demonstrada devem ser propostos para eliminação.

Parte 2 — retenção. Definam, para três conjuntos de dados (candidaturas activas, candidaturas indeferidas e cópias digitalizadas de documentos), o prazo de conservação proposto, o destino no fim do prazo e o responsável pela execução. Prazos que dependam de norma que não conhecem escrevem-se como «por confirmar com a área jurídica».

Parte 3 — criptografia. Indiquem o que deve estar cifrado em trânsito e o que deve estar cifrado em repouso, e escrevam duas ameaças concretas que a criptografia NÃO resolve neste caso.

Parte 4 — chaves e segredos. Proponham onde passam a estar a palavra-passe da base de dados e as credenciais de integração, quem pode lê-las, de quanto em quanto tempo são substituídas e o que acontece quando alguém com esse acesso sai.

Parte 5 — acessos e cópias. Corrijam o percurso da exportação nocturna e do relatório em folha de cálculo, e escrevam a regra que passa a valer para o ambiente de testes.

Rubrica de apreciação, sobre 10 pontos: 2 pontos pela classificação coerente de todos os campos; 2 pontos pela minimização, com pelo menos dois campos propostos para eliminação e a razão; 2 pontos pela retenção com prazo, destino e responsável; 2 pontos pela distinção correcta entre trânsito e repouso e pelas duas ameaças não resolvidas pela criptografia; 1 ponto pela solução de guarda de segredos com periodicidade de substituição; 1 ponto pela correcção do percurso das cópias e do ambiente de testes. Perde 2 pontos qualquer trabalho que utilize dados reais de pessoas.

Produto esperado: um plano de protecção de dados com cinco partes, construído sobre o caso fictício e sem qualquer dado real de pessoas.

Síntese em leitura fácil

• Primeiro saber que dados existem e quanto são sensíveis; só depois escolher medidas.
• Recolher só o necessário e guardar só o tempo necessário é a protecção mais barata.
• Em trânsito protege os dados na viagem pela rede; em repouso protege os dados gravados.
• A cifra não impede o acesso de quem tem permissão a mais nem o envio de um ficheiro para fora.
• Perder a chave é perder os dados: a guarda e a recuperação de chaves escrevem-se.
• Palavras-passe e chaves ficam num cofre de segredos, nunca em ficheiros nem em conversas.
• As cópias de segurança e os ambientes de teste têm a mesma sensibilidade dos dados que contêm.
• Para testar, usam-se dados inventados.

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 base de dados está cifrada em repouso. Uma conta com permissão de leitura exporta toda a tabela de candidaturas e envia-a por correio electrónico. A criptografia impediu alguma coisa?
2. Porque é que o ambiente de testes com uma cópia integral dos dados reais é um problema, mesmo estando dentro da instituição?

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. A base de dados está cifrada em repouso. Uma conta com permissão de leitura exporta toda a tabela de candidaturas e envia-a por correio electrónico. A criptografia impediu alguma coisa?

Resposta: Não impediu nada. Para quem tem permissão válida, o sistema decifra os dados de forma transparente; o problema é de permissões, de minimização e de controlo de exportações.

Comentário: É o limite mais importante a reter: a cifra em repouso protege sobretudo o acesso ao suporte e às cópias em bruto, não o excesso de permissões.

Pergunta 2. Porque é que o ambiente de testes com uma cópia integral dos dados reais é um problema, mesmo estando dentro da instituição?

Resposta: Porque o ambiente de testes costuma ter menos controlos, mais pessoas com acesso e menos vigilância, mas os dados mantêm a mesma sensibilidade do original.

Comentário: A regra prática é despersonalizar ou inventar os dados de teste; a cópia integral só se justifica com controlos equivalentes aos da produção e decisão escrita.

Referências consultadas

• Microsoft Learn — Azure encryption overview — https://learn.microsoft.com/en-us/azure/security/fundamentals/encryption-overview (consultado em 21 de Setembro de 2026).
• Microsoft Learn — Best practices for Azure RBAC — https://learn.microsoft.com/en-us/azure/role-based-access-control/best-practices (consultado em 21 de Setembro de 2026).

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

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

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

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

Objectivos da lição

• Distinguir registos, métricas e alertas, e indicar para que serve cada um na deteção de um problema.
• Analisar um conjunto de eventos fictícios e produzir uma triagem fundamentada, com classificação de gravidade e hipótese explicativa.
• Redigir as etapas de resposta a um incidente — contenção autorizada, preservação de evidências, recuperação e lições aprendidas — indicando quem decide cada passo.

Explicação

Monitorar um serviço na nuvem assenta em três materiais diferentes, que se confundem com frequência. Os registos, também chamados logs, são o relato do que aconteceu: entradas com data, hora, origem, identidade e acção. As métricas são medidas numéricas ao longo do tempo: percentagem de utilização do processador, número de pedidos por minuto, tempo de resposta, espaço livre em disco, número de erros. Os alertas são regras que vigiam métricas ou registos e avisam alguém quando uma condição se verifica. Os três são complementares: a métrica mostra que algo mudou, o registo explica o que foi, e o alerta garante que alguém fica a saber sem ter de estar a olhar para o ecrã.

Um alerta só é útil se tiver destinatário, gravidade e acção esperada. Um alerta enviado para uma caixa de correio que ninguém lê é pior do que não ter alerta, porque cria a ilusão de vigilância. Convém escrever para cada alerta quem o recebe, em que horário, o que deve fazer nos primeiros quinze minutos e a quem escala se não conseguir resolver. Também convém limitar o número de alertas: quando tudo alerta, ninguém repara em nada — é o efeito de fadiga de alertas, e é uma das causas mais comuns de incidentes que só são notados dias depois. Três a cinco alertas bem escolhidos, com destinatário claro, valem mais do que trinta.

Triagem é a decisão inicial sobre o que se está a passar, feita com informação incompleta. Pergunta-se: que serviço está afectado e quantas pessoas sente o efeito? É degradação de desempenho, indisponibilidade total, ou suspeita de acesso indevido? Há dados pessoais envolvidos? O que mudou nas últimas horas — uma actualização, uma alteração de permissões, uma nova regra de rede? A triagem termina com uma classificação de gravidade e uma hipótese, ambas escritas com a hora. Escrever a hora de cada decisão é o que permite, dias depois, reconstituir o que se passou; a memória das pessoas, em situação de pressão, é pouco fiável.

A contenção é a fase mais delicada, e neste curso trata-se sempre de contenção autorizada. Conter é limitar o dano — suspender uma conta suspeita, revogar uma chave, retirar um serviço de circulação, bloquear uma origem de rede. Cada uma destas acções tem consequências para o serviço público e algumas são, elas próprias, decisões de gestão: quem autoriza tirar de serviço um portal de licenciamento não é quem descobriu o problema. Por isso a lista de acções de contenção deve estar escrita antes do incidente, com o nome de quem pode autorizar cada uma e a alternativa quando essa pessoa não está contactável. E há um cuidado técnico importante: conter não é apagar. Destruir a máquina afectada resolve o sintoma e elimina a prova.

Preservar evidências significa guardar, antes de reparar, aquilo que permite depois perceber o que aconteceu: exportar os registos do período, guardar uma imagem do disco em vez de o reformatar, anotar quem esteve ligado e a que horas, registar as alterações feitas durante a resposta. As evidências devem ser guardadas com acesso restrito, porque contêm frequentemente dados sensíveis, e nunca circulam em grupos de conversa. Aqui vale também a regra de honestidade deste curso: o que não foi verificado escreve-se como hipótese, não como facto.

A recuperação é o regresso ao funcionamento normal, e faz-se por ordem: repor o serviço a partir de uma fonte de confiança, confirmar que o caminho de entrada usado pelo atacante ou pela avaria está fechado, repor as credenciais que possam ter sido expostas e só depois reabrir o acesso. Por fim, as lições aprendidas: uma reunião curta, dias depois, que produz um documento com o que aconteceu, o que funcionou, o que falhou e três a cinco acções com responsável e prazo. Esta reunião não procura culpados — procura causas. Uma cultura que castiga quem reporta produz incidentes silenciosos, que são os mais caros. Neste curso não se praticam técnicas ofensivas nem se executam comandos de ataque: trabalhamos apenas sobre registos fictícios, em análise documental.

Eventos de uma madrugada no portal de Ondela (registos fictícios)

Os eventos seguintes são inventados para este exercício, com formato simplificado. Não provêm de nenhum sistema real.

02:14 — autenticacao: 47 tentativas falhadas na conta «admin.ondela», origem única fora do país. 02:19 — autenticacao: entrada bem sucedida na conta «admin.ondela», mesma origem, sem segundo factor registado.

02:23 — autorizacao: atribuída função de administrador à identidade «svc-relatorios», âmbito toda a subscrição, por «admin.ondela». 02:26 — armazenamento: contentor «candidaturas-exportacao» alterado de privado para leitura pública, por «admin.ondela».

02:31 — rede: nova regra de permissão na sub-rede de dados, porta 5432, origem qualquer, prioridade 110, por «admin.ondela». 02:40 a 03:05 — armazenamento: 1 240 descarregamentos do ficheiro «export-2026-09-12.csv», origens várias.

03:10 — métrica: saída de dados para a internet sobe de 0,4 GB/hora para 11 GB/hora. 03:12 — alerta de orçamento: consumo mensal atinge 80 % do valor definido; notificação enviada para a caixa geral do departamento.

07:45 — atendimento: primeira chamada de um cidadão a dizer que o portal está muito lento. 08:02 — sistemas: técnico inicia sessão e verifica que a máquina do portal tem o processador a 97 %.

Actividade prática

Trabalho em pares, com 45 minutos de trabalho, seguidos de 10 minutos de partilha e síntese em plenário.

Exercício de análise e simulação documental, feito em papel ou em folha de cálculo. Nesta lição não se criam nem se alteram recursos na nuvem e não se declara nenhum laboratório como executado.

Recomenda-se um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem escreve a cada parte do exercício, de modo que ambas trabalhem no teclado.

Esta actividade é exclusivamente de análise de registos fictícios. Não se executa nenhuma técnica ofensiva, não se corre nenhum comando contra nenhum sistema e não se altera nenhum recurso na nuvem.

Parte 1 — leitura. Reconstituam a sequência dos eventos numa linha de tempo, indicando para cada momento o que é facto registado e o que é interpretação vossa. Identifiquem qual foi, na vossa leitura, o primeiro evento verdadeiramente grave e porquê.

Parte 2 — triagem. Classifiquem a gravidade em baixa, média, alta ou crítica, justificando com o efeito sobre as pessoas e sobre os dados. Escrevam uma hipótese explicativa, começada por «hipótese:», e listem três informações que precisariam de obter para a confirmar ou afastar.

Parte 3 — contenção autorizada. Proponham até cinco acções de contenção, por ordem de execução, indicando para cada uma quem autoriza, o efeito esperado no serviço ao cidadão e o risco de a executar. Pelo menos uma acção deve ter consequência visível para o público e exigir decisão de direcção.

Parte 4 — evidências. Indiquem o que guardam antes de reparar, onde guardam, quem tem acesso e durante quanto tempo. Escrevam uma acção que NÃO devem fazer por destruir prova.

Parte 5 — recuperação e lições aprendidas. Ordenem os passos do regresso ao normal e escrevam três acções de melhoria, cada uma com responsável proposto e prazo. Pelo menos uma deve corrigir um problema visível nos registos que não é técnico, mas de organização.

Rubrica de apreciação, sobre 10 pontos: 2 pontos pela linha de tempo com separação entre facto e interpretação; 2 pontos pela gravidade justificada e pela hipótese escrita como hipótese; 2 pontos pelas acções de contenção com autorização identificada e efeito no serviço; 2 pontos pelas evidências preservadas e pela acção destrutiva evitada; 2 pontos pelas lições aprendidas com responsável e prazo. Perde 2 pontos qualquer trabalho que apresente interpretações como factos registados.

Produto esperado: uma ficha de incidente com linha de tempo, triagem, plano de contenção autorizada, plano de preservação de evidências e três acções de melhoria com responsável e prazo.

Síntese em leitura fácil

• Registos contam o que aconteceu. Métricas medem. Alertas avisam alguém.
• Um alerta sem destinatário e sem acção esperada é apenas ruído.
• Triagem: que serviço, quantas pessoas, que dados, o que mudou — sempre com a hora escrita.
• Conter é limitar o dano; algumas acções de contenção têm de ser autorizadas pela direcção.
• Conter não é apagar: destruir a máquina afectada elimina a prova.
• Guardar as evidências antes de reparar, com acesso restrito.
• Recuperar por ordem: repor, fechar o caminho usado, trocar credenciais, reabrir.
• As lições aprendidas procuram causas e não culpados, com responsável e prazo.

Verificação formativa

Estas perguntas não contam para a nota final e não são perguntas do exame final. Servem para a pessoa formanda confirmar o que percebeu.

1. Nos registos fictícios, o alerta de orçamento disparou às 03:12. Porque é que isso não foi suficiente para deter o problema?
2. A equipa quer apagar imediatamente a máquina virtual afectada para «ficar tudo limpo». Que objecção levanta?

Respostas comentadas da verificação formativa

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

Pergunta 1. Nos registos fictícios, o alerta de orçamento disparou às 03:12. Porque é que isso não foi suficiente para deter o problema?

Resposta: Porque foi enviado para uma caixa geral do departamento, sem destinatário responsável nem acção esperada, e de madrugada ninguém o leu; além disso um alerta de orçamento avisa sobre despesa, não suspende consumo.

Comentário: Este é o ponto de organização escondido no exercício: a melhoria mais eficaz aqui não é técnica, é definir quem recebe o quê e o que faz a seguir.

Pergunta 2. A equipa quer apagar imediatamente a máquina virtual afectada para «ficar tudo limpo». Que objecção levanta?

Resposta: Apagar destrói as evidências e impede perceber o que aconteceu e se o caminho de entrada foi fechado; deve isolar-se a máquina e guardar registos e imagem do disco antes de qualquer reparação.

Comentário: Isolar e preservar primeiro; recuperar depois, a partir de uma fonte de confiança.

Referências consultadas

• Microsoft Learn — Best practices for Azure RBAC — https://learn.microsoft.com/en-us/azure/role-based-access-control/best-practices (consultado em 21 de Setembro de 2026).
• Microsoft Learn — Tutorial: create and manage budgets (alertas de orçamento) — https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-acm-create-budgets (consultado em 21 de Setembro de 2026).

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

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

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

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

Objectivos da lição

• Identificar as principais rubricas de custo de um serviço na nuvem: computação, armazenamento, rede e saída de dados, cópias de segurança, registos e suporte.
• Calcular o custo mensal de um cenário fictício a partir de uma tabela de preços dada, apresentando todos os operandos e o resultado em dólares e em meticais, com os pressupostos escritos.
• Propor medidas de optimização com poupança estimada, distinguindo o que reduz custo do que apenas o adia, e explicar os limites dos alertas de orçamento.

Explicação

A factura de um serviço na nuvem não tem uma linha só. Tem, tipicamente, seis famílias de rubricas. A computação paga-se sobretudo por tempo com a máquina ligada, e por tamanho da máquina. O armazenamento paga-se por capacidade ocupada e por tempo, havendo classes mais baratas para dados pouco consultados. A rede é o ponto que mais surpreende: a entrada de dados costuma não ser cobrada, mas a saída para a internet é cobrada por gigabyte, e tráfego entre regiões também pode ser cobrado. As cópias de segurança pagam-se por volume guardado e por tempo de retenção. Os registos de monitoria pagam-se por volume recebido e por tempo de conservação — guardar tudo, sempre, sai caro. E o suporte costuma ser um plano à parte, muitas vezes com percentagem do consumo e com valor mínimo mensal.

Há três verdades incómodas que convém dizer cedo. A primeira: parar uma máquina virtual não elimina todos os custos associados, e «parar» não quer sempre dizer a mesma coisa. A documentação do Azure sobre estados e facturação de máquinas virtuais distingue o estado «parada» (Stopped), em que a máquina continua com a capacidade reservada e a computação CONTINUA a ser facturada, do estado «parada e desalocada» (Stopped/Deallocated), em que a capacidade é libertada e a computação por consumo deixa de ser facturada. Mesmo desalocada, o disco continua a ocupar espaço e a ser cobrado, e endereços reservados, cópias e licenças associadas podem continuar a contar; e, se existirem compromissos contratuais — capacidade reservada, planos de poupança, licenças subscritas —, esses continuam a ser pagos independentemente de a máquina estar ligada ou não. Desligar a máquina pelo sistema operativo, de dentro, costuma deixá-la no primeiro estado, não no segundo. Para deixar de pagar tudo, é preciso eliminar os recursos — depois de confirmar que não são precisos e de guardar o que interessa. A segunda: os alertas de orçamento avisam, não travam. Um orçamento definido na plataforma envia notificação quando o consumo atinge determinadas percentagens do valor previsto; por si, não suspende serviços nem impede que a despesa continue a crescer. A documentação do próprio fornecedor descreve o orçamento como instrumento de aviso, e qualquer acção automática tem de ser configurada à parte, com todos os riscos que suspender um serviço público acarreta. A terceira: o preço listado não é a despesa total — falta o câmbio, faltam impostos quando aplicáveis, falta o tempo de pessoas.

Por isso, todo o cálculo de custos tem de trazer os pressupostos à superfície. Quantas horas por dia a máquina está mesmo ligada? Quantos dias tem o mês considerado? Que volume de saída de dados se prevê, e com que base? Qual o câmbio usado e de que data? Um orçamento em que estes números não estão escritos não pode ser discutido nem corrigido: só pode ser acreditado ou rejeitado. Escrever os pressupostos é o que transforma uma estimativa numa proposta discutível. E quando um número não é conhecido, escreve-se «por apurar» e indica-se como será apurado — nunca se preenche com um valor bonito.

A optimização faz-se por camadas, começando pelo que não tem risco. Primeiro, eliminar o que não é usado: discos órfãos de máquinas já apagadas, endereços reservados sem uso, ambientes de demonstração esquecidos, cópias antigas fora da política de retenção. Depois, ajustar o que está sobredimensionado: máquinas com processador quase sempre abaixo de dez por cento, bases de dados com capacidade muito acima do uso real. A seguir, ajustar horários: ambientes de teste e de formação raramente precisam de estar ligados de noite e ao fim-de-semana. Depois, arrumar os dados: mover para classes de armazenamento mais baratas o que é raramente consultado, reduzir a retenção de registos para o que é realmente necessário, comprimir exportações. Só no fim se consideram compromissos de longo prazo — capacidade reservada por um ou três anos — porque estes trocam flexibilidade por desconto e, num serviço público, exigem previsibilidade que nem sempre existe.

É útil distinguir três tipos de medida, porque são frequentemente confundidos na mesma lista. Há medidas que reduzem o custo de forma permanente, como apagar um disco órfão. Há medidas que adiam ou deslocam o custo, como mover dados para uma classe mais barata com custo de leitura mais alto: se os dados forem muito consultados, a poupança desaparece. E há medidas que reduzem risco sem reduzir custo, como criar um orçamento com alertas — valiosas, mas que não devem ser somadas à coluna da poupança. Uma proposta de optimização honesta separa estas três colunas.

Finalmente, a governação do custo é uma responsabilidade partilhada e precisa de dono. Convém haver etiquetas nos recursos que identifiquem o serviço, a direcção responsável e o projecto, para que a factura possa ser repartida e discutida; sem isso, a despesa aparece como um bloco único que ninguém consegue explicar. Convém haver revisão mensal do consumo com a direcção, com comparação entre previsto e realizado e explicação dos desvios. E convém que quem cria recursos saiba o que custam — muitos excessos nascem de boa-fé técnica, não de desleixo.

A factura mensal do portal de Ondela (preços e consumo FICTÍCIOS)

A tabela de preços que se segue é inventada para este exercício. Os valores são redondos de propósito, para que o cálculo possa ser feito à mão. Não correspondem aos preços de nenhum fornecedor e não servem para orçamentar nada.

Máquina virtual padrão (2 vCPU, 8 GB de memória): 0.1 USD por hora ligada.

Disco ligado à máquina: 0.12 USD por GB por mês, cobrado mesmo com a máquina parada.

Armazenamento de objectos: 0.025 USD por GB por mês.

Saída de dados para a internet: 0.09 USD por GB, com os primeiros 10 GB do mês sem custo.

Entrada de dados: 0 USD por GB.

Cópias de segurança: 0.05 USD por GB por mês.

Registos (logs) recebidos pelo serviço de monitoria: 0.5 USD por GB.

Plano de suporte: 10 % do consumo do mês, com mínimo de 25 USD.

Câmbio de referência assumido para o exercício: 64 MZN por 1 USD.

Todos estes preços são FICTÍCIOS, arredondados e construídos para o exercício. Não são preços de nenhum fornecedor e não servem para orçamentar nada.

Consumo declarado no mês, também fictício, para um mês de 30 dias: portal ligado 24 horas por dia, 30 dias, ou seja 720 horas; máquina de relatórios ligada 10 horas por dia, 22 dias úteis, ou seja 220 horas; 128 GB de disco na máquina do portal e 64 GB de disco na máquina de relatórios, ou seja 192 GB de discos no total; 400 GB em armazenamento de objectos; 150 GB de saída de dados para a internet; 200 GB de cópias de segurança; 30 GB de registos recebidos pelo serviço de monitoria.

Repare-se em dois detalhes que costumam ser esquecidos no cálculo: os primeiros gigabytes de saída não são cobrados, pelo que a saída facturável é menor do que a saída total; e o plano de suporte tem um valor mínimo, que se aplica quando a percentagem calculada fica abaixo desse mínimo.

Actividade prática

Trabalho em pares, com 45 minutos de trabalho, seguidos de 10 minutos de partilha e síntese em plenário.

Exercício de análise e simulação documental, feito em papel ou em folha de cálculo. Nesta lição não se criam nem se alteram recursos na nuvem e não se declara nenhum laboratório como executado.

Recomenda-se um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem escreve a cada parte do exercício, de modo que ambas trabalhem no teclado.

Trabalho em papel ou em folha de cálculo, a partir da tabela de preços fictícios e do consumo declarado acima. Nenhum recurso é criado e nenhuma factura real é consultada.

Parte 1 — cálculo. Preencham uma tabela com uma linha por rubrica: computação, discos, armazenamento de objectos, saída de dados, cópias de segurança, registos e suporte. Em cada linha têm de escrever os operandos usados — quantidade, preço unitário e resultado — e não apenas o total. Apresentem o consumo do mês, o valor do suporte, o total em dólares e o total convertido em meticais ao câmbio assumido.

Parte 2 — pressupostos. Escrevam a lista dos pressupostos do vosso cálculo, incluindo o número de dias do mês, as horas de funcionamento assumidas, os gigabytes de saída sem custo e o câmbio. Marquem com «por apurar» qualquer número que, num caso real, teria de ser confirmado e indiquem onde seria confirmado.

Parte 3 — optimização. Proponham cinco medidas para reduzir o custo mensal deste cenário. Para cada uma indiquem a poupança estimada em dólares, como a estimaram, o risco para o serviço e a classificação da medida: reduz custo de forma permanente, adia ou desloca o custo, ou reduz risco sem reduzir custo. As três colunas não se somam entre si.

Parte 4 — limites. Respondam por escrito a duas perguntas: (a) se a direcção definir um orçamento com alerta aos 80 %, o consumo pára quando o alerta dispara? (b) se a máquina de relatórios ficar parada E DESALOCADA durante todo o mês seguinte — pressuposto expresso deste exercício: a capacidade é libertada e não existe nenhum compromisso contratual de capacidade reservada, plano de poupança ou licença subscrita associado a essa máquina —, quanto deixamos de pagar e que custos continuam a ser cobrados? Apresentem a conta. Escrevam também o que mudaria na resposta se a máquina ficasse apenas parada, sem ser desalocada.

Rubrica de apreciação, sobre 10 pontos: 3 pontos pelo cálculo correcto com todos os operandos visíveis; 1 ponto pelo tratamento correcto dos gigabytes de saída sem custo; 1 ponto pelo tratamento correcto do mínimo do plano de suporte; 1 ponto pela conversão com câmbio identificado como pressuposto; 2 pontos pelas cinco medidas com poupança estimada e classificação nas três colunas; 2 pontos pelas duas respostas da parte 4, com a conta feita. Perde 2 pontos qualquer trabalho que apresente um total sem mostrar os operandos.

Produto esperado: uma folha de cálculo de custos com todos os operandos visíveis, lista de pressupostos, cinco medidas de optimização classificadas em três colunas e as respostas fundamentadas sobre os limites dos alertas de orçamento e da paragem de máquinas.

Síntese em leitura fácil

• A factura tem várias rubricas: computação, armazenamento, rede e saída, cópias, registos e suporte.
• A entrada de dados costuma não pagar; a saída para a internet paga.
• Parar não é o mesmo que desalocar: só a máquina desalocada deixa de pagar computação por consumo.
• Mesmo desalocada, o disco continua a ser cobrado.
• Compromissos já assumidos (capacidade reservada, licenças) continuam a pagar-se com a máquina desligada.
• Os alertas de orçamento avisam; não suspendem o consumo.
• Todo o cálculo mostra os operandos, os pressupostos e o câmbio usado.
• Optimizar começa por apagar o que não é usado e ajustar o que está grande demais.
• Reduzir custo, adiar custo e reduzir risco são três coisas diferentes e não se somam.
• Etiquetar os recursos permite saber de quem é cada despesa.

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 direcção definiu um orçamento mensal com aviso aos 80 % e aos 100 %. Em que medida isso protege a instituição de uma despesa inesperada?
2. No cenário fictício, porque é que o plano de suporte fica em 25,00 USD e não em 16,46 USD?

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. A direcção definiu um orçamento mensal com aviso aos 80 % e aos 100 %. Em que medida isso protege a instituição de uma despesa inesperada?

Resposta: Protege por aviso apenas: a notificação chega a quem estiver indicado, mas o consumo continua. Travar exige acção humana ou uma automatização configurada à parte, decidida com cuidado num serviço público.

Comentário: Por isso o alerta precisa de destinatário responsável e de acção esperada, como se viu na lição de monitoria.

Pergunta 2. No cenário fictício, porque é que o plano de suporte fica em 25,00 USD e não em 16,46 USD?

Resposta: Porque 10 % de 164,64 USD dá 16,46 USD, valor inferior ao mínimo mensal de 25 USD previsto na tabela; aplica-se o mínimo.

Comentário: Valores mínimos e escalões são a origem mais frequente de erro nos orçamentos feitos à pressa.

Referências consultadas

• Microsoft Learn — Estados e facturação de máquinas virtuais no Azure — https://learn.microsoft.com/en-us/azure/virtual-machines/states-billing (consultado em 21 de Setembro de 2026).
• Microsoft Learn — Tutorial: create and manage Azure budgets — https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-acm-create-budgets (consultado em 21 de Setembro de 2026).

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

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

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

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

Objectivos da lição

• Redigir requisitos mensuráveis para a contratação de um serviço de nuvem, distinguindo requisito de desejo.
• Interpretar um nível de serviço acordado e as suas exclusões, e relacionar objectivos de recuperação com necessidades do serviço público.
• Comparar duas propostas fictícias com uma grelha de critérios e produzir uma recomendação fundamentada, identificando o que fica por validar.

Explicação

Um requisito só serve para alguma coisa se puder ser verificado. «O serviço deve ser rápido» não é requisito; «o tempo de resposta mediano das páginas de consulta não deve exceder dois segundos, medido a partir de Maputo e de Nampula, em horário útil» é requisito, porque se pode medir e porque diz onde e quando. A regra prática é escrever cada requisito com três elementos: o que se exige, como se mede e qual o valor ou limite. Convém ainda separar o que é obrigatório do que é valorizado: uma lista em que tudo é obrigatório reduz a concorrência e pode deixar a instituição sem propostas admissíveis; uma lista em que nada é obrigatório não protege ninguém.

O nível de serviço acordado, muitas vezes designado pela sigla inglesa SLA, é o compromisso do fornecedor quanto à disponibilidade e, por vezes, quanto ao desempenho e ao tempo de resposta do apoio. Três cuidados. Primeiro, o que conta como indisponibilidade está definido no próprio documento e pode ser mais estreito do que a experiência do utilizador: um serviço lento pode não contar como indisponível. Segundo, as exclusões costumam ser extensas — manutenções programadas, falhas da ligação do cliente, casos de força maior, utilização fora das condições previstas. Terceiro, a compensação por incumprimento é tipicamente um crédito na factura, não uma indemnização pelo prejuízo causado ao serviço público; para um serviço de atendimento ao cidadão, um crédito de cinco por cento não repara nada. Ler as exclusões é mais importante do que ler a percentagem.

Dois números merecem discussão própria, porque são frequentemente copiados sem se perceber o que exigem. O objectivo de ponto de recuperação, RPO, é quanto trabalho a instituição aceita perder, medido em tempo: um RPO de uma hora significa aceitar perder até uma hora de dados introduzidos. O objectivo de tempo de recuperação, RTO, é em quanto tempo o serviço tem de voltar a funcionar. Ambos custam dinheiro: quanto mais curtos, mais cara é a solução. Por isso definem-se por serviço e não por instituição — o registo de candidaturas a apoio social pode justificar um RPO curto, enquanto o sítio informativo tolera um RPO de um dia. Estes valores devem sair de uma conversa com quem presta o serviço, não do que estava escrito no caderno de encargos anterior.

A portabilidade e a saída são o capítulo mais esquecido e o que mais custa quando falha. Antes de entrar, escreve-se como se sai: em que formatos os dados podem ser exportados, com que periodicidade, em quanto tempo, a que custo, com que apoio do fornecedor, e o que acontece aos dados depois de terminado o contrato — prazo de eliminação e prova dessa eliminação. Convém exigir que a exportação seja demonstrada durante a vigência do contrato, e não apenas prometida; uma exportação que nunca foi ensaiada é uma promessa por verificar. Convém também acautelar a dependência técnica: quanto mais o serviço assentar em componentes específicos de um fornecedor, mais caro é mudar. Isso não é razão para os evitar sempre, mas é razão para os escolher conscientemente e para registar o custo estimado de saída.

Localização dos dados e responsabilidades são o quarto bloco. É preciso saber em que país ou países os dados ficam guardados, onde são processados, onde ficam as cópias de segurança, quem tem acesso técnico a partir de onde e em que condições o fornecedor pode aceder ao conteúdo. É preciso saber também o que a instituição continua a ter de fazer: nas nuvens públicas, a responsabilidade é partilhada, e a configuração, as permissões e os dados são quase sempre responsabilidade do cliente. Um contrato pode exigir notificação de incidentes de segurança em prazo definido, com conteúdo mínimo, e exigir que subcontratações sejam comunicadas. Atenção a um limite deste curso: o enquadramento jurídico concreto aplicável a cada contratação — legislação de contratação pública, protecção de dados e requisitos sectoriais — tem de ser confirmado com a área jurídica da instituição. Aqui trabalha-se a formulação técnica dos requisitos; não se produzem pareceres jurídicos nem se inventam obrigações legais.

A acessibilidade e o apoio entram nos requisitos como qualquer outro critério e não como boa intenção final. Pode exigir-se que as interfaces destinadas a pessoas utilizadoras respeitem critérios reconhecidos de acessibilidade, que o fornecedor apresente uma declaração de conformidade com identificação do que não cumpre, que existam alternativas de texto e navegação por teclado, e que o apoio esteja disponível em português, em horário definido, por mais do que um canal — telefone, correio electrónico e um canal escrito assíncrono — porque nem todas as pessoas conseguem usar todos os canais. Uma nota importante de honestidade: a meta de 99,5 % de disponibilidade que consta do Termo de Referência aplica-se à plataforma objecto daquele concurso. Não é um valor a copiar automaticamente para qualquer contratação de serviços de nuvem: o nível exigido define-se caso a caso, em função da criticidade do serviço e do que se está disposto a pagar.

Duas propostas para o arquivo digital de Ondela (propostas fictícias)

O Distrito de Ondela quer contratar serviço de nuvem para um arquivo digital de processos, com consulta interna diária e consulta pública ocasional. Recebeu duas propostas, ambas inventadas para este exercício.

Proposta A: disponibilidade anunciada de 99,9 %, com exclusão de manutenções programadas até 8 horas por mês e de falhas de ligação do cliente; compensação de 10 % de crédito na factura por mês em incumprimento; cópias de segurança diárias com retenção de 14 dias; exportação de dados em formato próprio do fornecedor, mediante pedido, em prazo não especificado; dados alojados em dois centros de dados fora do país, sem indicação de quais; apoio em inglês por correio electrónico, com resposta em 24 horas úteis; sem declaração de acessibilidade.

Proposta B: disponibilidade anunciada de 99,5 %, com exclusão de manutenções programadas até 4 horas por mês, comunicadas com 7 dias de antecedência; compensação de 5 % de crédito; cópias de segurança de 6 em 6 horas com retenção de 30 dias; exportação em formatos abertos, a pedido, em 5 dias úteis, com um ensaio de exportação por ano incluído no contrato; dados alojados em dois centros de dados, com país indicado no contrato e cópias na mesma jurisdição; apoio em português por telefone e correio electrónico em horário útil, com resposta em 8 horas úteis; declaração de acessibilidade com lista do que não cumpre e plano de correcção.

Nenhuma das propostas indica o custo de saída no fim do contrato nem o prazo de eliminação dos dados após o termo.

Actividade prática

Trabalho em pares, com 45 minutos de trabalho, seguidos de 10 minutos de partilha e síntese em plenário.

Exercício de análise e simulação documental, feito em papel ou em folha de cálculo. Nesta lição não se criam nem se alteram recursos na nuvem e não se declara nenhum laboratório como executado.

Recomenda-se um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem escreve a cada parte do exercício, de modo que ambas trabalhem no teclado.

Exercício de análise documental sobre propostas fictícias. Não se contacta nenhum fornecedor, não se produz nenhuma peça de procedimento real e não se emitem conclusões jurídicas.

Parte 1 — requisitos. Escrevam oito requisitos para esta contratação, cada um com três elementos: o que se exige, como se verifica e qual o valor ou limite. Marquem cada requisito como obrigatório ou valorizado. Pelo menos um requisito deve ser de acessibilidade e pelo menos um de apoio em português.

Parte 2 — recuperação. Definam o RPO e o RTO propostos para o arquivo digital, justificando com o efeito de uma falha sobre o atendimento, e digam que consequência esses valores têm sobre a frequência das cópias de segurança.

Parte 3 — saída. Escrevam três cláusulas sobre portabilidade e saída: formato e prazo de exportação, ensaio de exportação durante o contrato, e destino e prazo de eliminação dos dados no fim. Indiquem também como estimariam o custo de mudar de fornecedor.

Parte 4 — comparação. Construam uma grelha com os critérios que escolheram, atribuam a cada proposta «cumpre», «cumpre parcialmente» ou «não cumpre» e escrevam uma recomendação de meia página. A recomendação tem de indicar o que ficaria por esclarecer com cada concorrente e o que teria de ser confirmado com a área jurídica da instituição.

Atenção: não copiem automaticamente o valor de 99,5 % do Termo de Referência da plataforma para este contrato. Escolham o nível que este serviço justifica e escrevam a razão da escolha.

Rubrica de apreciação, sobre 10 pontos: 3 pontos pelos oito requisitos mensuráveis, com forma de verificação e separação entre obrigatório e valorizado; 2 pontos pelo RPO e RTO justificados e ligados à frequência das cópias; 2 pontos pelas três cláusulas de saída e pela estimativa de custo de mudança; 2 pontos pela grelha comparativa preenchida e pela recomendação fundamentada; 1 ponto pela identificação honesta do que fica por esclarecer e do que é matéria jurídica. Perde 2 pontos qualquer trabalho que afirme obrigações legais concretas sem base dada no exercício.

Produto esperado: um caderno de requisitos com oito requisitos mensuráveis, valores de RPO e RTO justificados, três cláusulas de saída e uma grelha comparativa com recomendação fundamentada e pontos por validar.

Síntese em leitura fácil

• Requisito é o que se pode verificar: o que se exige, como se mede, que valor.
• Separar o que é obrigatório do que é valorizado.
• No nível de serviço, as exclusões contam mais do que a percentagem anunciada.
• A compensação por incumprimento costuma ser crédito na factura, não reparação do prejuízo.
• RPO é quanto trabalho se aceita perder; RTO é em quanto tempo o serviço volta.
• Antes de entrar, escrever como se sai: formato, prazo, ensaio, eliminação e prova.
• Saber onde ficam os dados, onde ficam as cópias e quem lhes pode aceder.
• Acessibilidade e apoio em português são requisitos, não boas intenções.
• O valor de 99,5 % do Termo de Referência é daquela plataforma; cada contrato define o seu.
• Matéria jurídica confirma-se com a área jurídica da instituiçã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. Uma proposta anuncia 99,9 % de disponibilidade e outra 99,5 %. Basta este número para escolher a melhor?
2. Porque é que exigir um ensaio de exportação durante o contrato é diferente de exigir que a exportação seja possí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 qualquer efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. Uma proposta anuncia 99,9 % de disponibilidade e outra 99,5 %. Basta este número para escolher a melhor?

Resposta: Não. É preciso ver o que conta como indisponibilidade, quais são as exclusões, quanto tempo de manutenção programada fica de fora, como se comprova o incumprimento e o que se recebe em compensação.

Comentário: No caso fictício, a proposta com percentagem mais baixa tem menos horas de manutenção excluídas, cópias mais frequentes e saída mais segura.

Pergunta 2. Porque é que exigir um ensaio de exportação durante o contrato é diferente de exigir que a exportação seja possível?

Resposta: Porque a possibilidade fica por verificar até ao dia em que é precisa; o ensaio prova o formato, o prazo e a integridade enquanto ainda há relação contratual para corrigir problemas.

Comentário: É a mesma lógica das cópias de segurança: só conta o que foi testado.

Referências consultadas

• Microsoft Learn — Azure encryption overview — https://learn.microsoft.com/en-us/azure/security/fundamentals/encryption-overview (consultado em 21 de Setembro de 2026).
• Microsoft Learn — Best practices for Azure RBAC — https://learn.microsoft.com/en-us/azure/role-based-access-control/best-practices (consultado em 21 de Setembro de 2026).

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.