Governação, Segurança e Custos

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