30 de setembro de 2026 · IT-Sicherheit · Zero Trust · Compliance · Schwachstellenmanagement

Least privilege está no rótulo, não no host

As contas são tidas como de privilégio mínimo, mas o host costuma permitir muito mais. Como verificar os direitos reais e porque é necessária uma prova negativa.

«Least privilege» – o princípio do privilégio mínimo – é um dos poucos princípios de segurança aos quais ninguém se opõe. Precisamente por isso, aparece escrito com frequência: em conceitos de autorização, descrições de papéis, pedidos e manuais de operação. Só que nenhum desses documentos decide o que uma conta realmente pode fazer. Quem decide é a configuração do sistema em que a conta trabalha. Este artigo descreve porque é que as duas coisas podem divergir, como levantar a situação real e o que é preciso ter em conta antes de uma correção.

O que exigem as normas

O requisito em si é formulado com o mesmo conteúdo nos frameworks habituais. O NIST descreve-o na SP 800-53 como controlo AC-6: são permitidos apenas os acessos necessários para as tarefas atribuídas – expressamente também para processos que atuam em nome de utilizadores. A automação e as contas de serviço, portanto, não estão excluídas, mas incluídas. As extensões do controlo são mais concretas: as contas privilegiadas devem ser restringidas a pessoas ou papéis definidos (AC-6(5)), os direitos atribuídos devem ser verificados regularmente quanto à sua necessidade e, se for caso disso, revogados (AC-6(7)), e a execução de funções privilegiadas deve ficar registada em log (AC-6(9)).

O BSI exige no módulo ORP.4 do IT-Grundschutz o mesmo princípio: identificadores e autorizações só podem ser concedidos com base na necessidade real (ORP.4.A2). Digno de nota é o requisito ORP.4.A3. Não exige apenas que os identificadores e os perfis de direitos sejam documentados, mas que essa documentação «seja verificada regularmente» («regelmäßig daraufhin überprüft werden») quanto a «se reflete o estado real da concessão de direitos» («ob sie den tatsächlichen Stand der Rechtevergabe widerspiegelt»).

Com isso, a direção da verificação está dada: do sistema para a documentação, não o contrário. Uma documentação que ninguém confronta com a realidade descreve uma intenção.

O padrão: a documentação diz X, os direitos efetivos dizem Y

A divergência raramente resulta de descuido. Surge porque as autorizações atuam em vários lugares ao mesmo tempo – e porque um nome ou uma descrição é mais fácil de ler do que uma autorização efetiva. Dois exemplos de manual tornam isto palpável.

Suponha-se que uma conta de serviço para backup esteja descrita no conceito de autorização como «apenas leitura». No serviço de diretório, é membro de um grupo que, por sua vez, é membro de um grupo administrativo. Cada pertença, isoladamente, parece plausível. Somadas, a conta pode muito mais do que ler – e quem olha apenas para a pertença direta ao grupo não vê isso.

Suponha-se que um papel numa plataforma tenha o nome «Visualizador», mas contenha, além dos direitos de leitura, também a permissão de alterar atribuições de papéis. O nome foi escolhido corretamente, o papel não. Quem atribui o papel confiando no nome concede, na prática, a possibilidade de atribuir a si próprio mais direitos.

Nos dois casos vale o mesmo princípio: uma restrição só está imposta onde o sistema de destino a verifica. O que consta no conceito, no nome ou numa ferramenta que faz a chamada é uma descrição, não um controlo.

Perguntar ao sistema, não à documentação

Os direitos reais podem, em regra, ser consultados diretamente no sistema:

  • Em Linux com sudo: sudo -n -l lista, segundo o manual, os direitos do utilizador que faz a chamada no host atual. A opção -n impede qualquer pedido de palavra-passe – se for necessário introduzi-la, o sudo aborta com uma mensagem de erro em vez de esperar. Isso torna a chamada adequada para verificações automatizadas. Com um comando anexado, o sudo responde especificamente se exatamente essa chamada seria permitida, sem a executar.
  • Em serviços de diretório: as autorizações efetivas de uma conta sobre um objeto, incluindo grupos aninhados e direitos herdados – não a lista dos grupos de que deveria ser membro.
  • Em serviços de nuvem e plataformas: a política avaliada para uma ação concreta, não a denominação do papel.

Sem prova negativa, a verificação não prova nada

Uma verificação que só confirma o caso permitido tem uma fraqueza embutida. À pergunta «A conta pode fazer o que pode fazer?» também uma conta com acesso total responde que sim. O resultado, portanto, não distingue entre uma conta corretamente restringida e uma sem restrições.

Significativa é só a contraprova: um pedido que tem de ser recusado. Suponha-se que uma conta deva apenas poder reiniciar um determinado serviço. Então fazem parte da verificação perguntas como: pode editar a configuração de autorizações? Criar contas? Iniciar uma shell qualquer com privilégios elevados? Com sudo -n -l <befehl> é possível fazer estas perguntas sem executar nada; em serviços de diretório e plataformas, as avaliações das autorizações efetivas fazem o mesmo. Um não para sudo -n -l /bin/sh, no entanto, não exclui uma shell de root: programas permitidos com shell escape – como find, vim ou less – ou carateres universais nos argumentos permitidos abrem o mesmo caminho. Se uma destas perguntas receber um sim, a descrição está errada – independentemente do que a verificação positiva tenha mostrado.

Dois pormenores tornam a prova negativa fiável. Primeiro: avaliar a resposta, não apenas a ausência de um sim. Uma chamada que nem chegou a acontecer por causa de um erro de rede ou de um pedido de palavra-passe inesperado parece, caso contrário, uma recusa. Segundo: a prova negativa faz parte da verificação regular segundo AC-6(7) e ORP.4.A3, não apenas da aceitação. As autorizações mudam através da gestão de configuração, de atualizações e de intervenções de emergência.

Antes de restringir, garantir o caminho de reparação

Quem encontra uma autorização demasiado ampla quer fechá-la. Aqui vale um princípio que facilmente falta nos planeamentos: uma restrição não pode remover o único caminho para a sua própria correção. Se a conta restringida for ao mesmo tempo a única que pode alterar a configuração de autorizações, um erro na nova regra só poderá ser corrigido depois através de acesso de consola, restauro ou reconstrução.

A consequência é uma ordem, não um afrouxamento. Antes de revogar um direito, é preciso esclarecer que caminho o poderia devolver e se esse caminho sobrevive à restrição. Uma segunda identidade de administração, independente e com acesso próprio, deve existir e ter sido testada antes de a primeira ser restringida. O BSI formula no ORP.4.A20 uma ideia relacionada para a preparação para emergências: tomar providências para continuar a ser capaz de trabalhar quando a própria gestão de autorizações não estiver disponível.

Contas de automação de amplo alcance são Tier 0

As contas através das quais se faz rollout, configuração ou automação são muitas vezes vistas como ferramenta de operação. Assim que possuem direitos administrativos amplos em muitos sistemas, são mais do que isso: quem as controla controla os sistemas.

A Microsoft descreve no Enterprise Access Model que o antigo nível Tier 0 foi alargado ao «Control Plane» e exige impor a hierarquia de modo que os níveis inferiores não possam controlar os níveis superiores. Isso inclui expressamente procurar continuamente fraquezas de configuração que permitam uma escalada de privilégios não intencional. Para identificadores com autorizações amplas, o BSI recomenda autenticação multifator (ORP.4.A10).

O que deve verificar

  • Levantar os direitos efetivos – para cada conta de serviço e de automação, no sistema.
  • Para cada verificação positiva, definir uma prova negativa que tem de ser recusada.
  • Ancorar as restrições onde são impostas.
  • Antes de cada restrição, estabelecer e testar o caminho de reparação.
  • Tratar as contas de automação de amplo alcance como Tier 0: proteção multifator, registo em log, responsabilidade atribuída nominalmente.

Como a sector7 apoia

Apoiamos a sua organização em conceitos de papéis e direitos, na gestão de contas privilegiadas, na autenticação multifator e no hardening de sistemas operativos – incluindo políticas, documentação e auditorias. Mais sobre isto em Cibersegurança.

Fontes

Vamos falar sobre a sua situação.

Marcar uma conversa+49 212 240915 0