Uma conta pode permanecer ativa depois do encerramento de um contrato. Um colaborador transferido de área pode acumular permissões antigas e novas. Uma aplicação pode executar operações sensíveis por meio de uma identidade técnica cujos responsáveis já não estão claramente definidos.
Essas situações mostram por que a auditoria de acessos exige mais do que uma relação de usuários cadastrados. O exame precisa relacionar identidades, necessidades operacionais, autorizações, permissões efetivas e registros de utilização, considerando o período e os sistemas abrangidos pelo trabalho.
Na Auditoria de Sistemas, a gestão de identidades e acessos é examinada como parte do ambiente tecnológico e dos processos organizacionais. A questão central é verificar se os acessos concedidos correspondem aos critérios definidos e se os controles funcionam nas condições observadas.
Identificação, autenticação e autorização
Identificar uma conta, autenticar seu acesso e autorizar uma operação são etapas distintas. A autenticação verifica os elementos apresentados para demonstrar uma identidade; a autorização determina quais recursos e ações ficam disponíveis. A OWASP destaca essa distinção e recomenda a aplicação do menor privilégio, a negação por padrão e a verificação das permissões em cada requisição. Referência: OWASP — Authorization Cheat Sheet.
Uma autenticação bem-sucedida, portanto, não demonstra que todas as operações posteriores estavam adequadamente autorizadas. Da mesma forma, a adoção de autenticação multifator não corrige uma permissão excessiva concedida dentro de uma aplicação.
O exame deve acompanhar o caminho entre a entrada no ambiente e o acesso ao recurso. Dependendo da arquitetura, esse caminho pode envolver um diretório corporativo, um provedor externo de identidade, grupos, perfis locais e regras específicas da aplicação.
Definir o universo de contas e recursos
O planejamento começa pela identificação dos sistemas, recursos e categorias de identidade relevantes. Além de colaboradores, podem existir convidados, prestadores de serviços, administradores, contas de emergência e identidades utilizadas por aplicações, integrações e rotinas automatizadas.
Para cada conjunto, convém identificar o responsável, a finalidade, o mecanismo de autenticação, os privilégios e as condições de encerramento do acesso. Uma conta sem proprietário conhecido exige esclarecimento; isso não demonstra, isoladamente, uso indevido.
Um inventário extraído apenas do diretório central pode ser insuficiente. Aplicações com autenticação própria, contas locais de equipamentos e credenciais de integrações podem permanecer fora dessa relação. A cobertura do inventário precisa ser explicitada antes de apresentar conclusões sobre todo o ambiente.
Ciclo de vida: concessão, mudança e revogação
O NIST SP 800-53, no controle AC-2, trata a gestão de contas como um ciclo que inclui aprovação, criação, alteração, desativação, monitoramento e revisão. Também estabelece a relação desse processo com transferências e desligamentos de pessoas. Os controles AC-5 e AC-6 abordam, respectivamente, segregação de funções e menor privilégio. Sua utilização como critério deve ser delimitada conforme o trabalho. Referência: NIST SP 800-53 Rev. 5.
Na auditoria, esses processos podem ser examinados pela comparação entre solicitações, aprovações e alterações efetivamente executadas. Entre as perguntas úteis estão:
- O acesso foi aprovado por pessoa com competência para autorizá-lo?
- As permissões concedidas correspondem à solicitação?
- A mudança de função levou à revisão dos acessos anteriores?
- O encerramento do vínculo foi comunicado e tratado no prazo definido?
- As exceções possuem justificativa, responsável e revisão prevista?
O prazo aplicável deve decorrer dos critérios selecionados e da criticidade do ambiente. Uma referência genérica a “bloqueio imediato” precisa ser transformada em condição verificável, com eventos de início e término claramente definidos.
Permissões efetivas e privilégios administrativos
O nome de um perfil não descreve necessariamente tudo o que ele permite fazer. Um usuário classificado como leitor em uma aplicação pode receber permissões adicionais por outro grupo, por compartilhamento direto ou por acesso ao banco de dados.
Por isso, a auditoria deve examinar os caminhos de concessão relevantes. Uma matriz de perfis documenta a intenção do controle; configurações e testes ajudam a demonstrar seu funcionamento.
Privilégios administrativos merecem atenção porque podem permitir alterações de configuração, concessão de acessos e modificação de mecanismos de registro. O exame pode verificar a separação entre uso cotidiano e administração, as condições de elevação temporária e a documentação das operações realizadas.
Não basta constatar que uma ferramenta de gestão de privilégios foi contratada. É necessário verificar quais recursos estão cobertos, quais acessos continuam permanentes e como as exceções são acompanhadas.
Segregação de funções e controles compensatórios
A segregação de funções busca limitar combinações de atribuições que concentrem poderes incompatíveis com os critérios do processo. Em um fluxo de mudanças, por exemplo, pode ser necessário distinguir quem solicita, quem aprova e quem implanta uma alteração.
O exame precisa considerar possibilidades efetivas. Ter nomes diferentes no procedimento não resolve a questão se uma mesma pessoa puder utilizar contas alternativas para executar todas as etapas.
Em equipes pequenas, a separação completa pode não ser viável. Nesse caso, a análise pode considerar controles compensatórios, como revisão independente, registro de operações e acompanhamento de exceções. A conclusão deve avaliar o desenho e a execução desses controles, sem presumir que sua simples previsão elimina o risco.
Revisão periódica de acessos
A revisão periódica permite reavaliar a necessidade de acessos existentes. Como exemplo de implementação, a documentação do Microsoft Entra descreve revisões de participação em grupos, acesso a aplicações e atribuições de funções. Essa funcionalidade ilustra um mecanismo de governança; sua existência não comprova, por si só, a qualidade das decisões tomadas pelos revisores. Referência: Microsoft — What are access reviews?.
Na prática, é importante examinar quem revisou, quais informações estavam disponíveis, como as exceções foram justificadas e se as decisões de remoção produziram mudanças efetivas.
Uma revisão concluída com aprovação de todos os usuários não é necessariamente inadequada. Porém, o relatório de conclusão, isoladamente, não demonstra que cada acesso foi confrontado com uma necessidade atual. Podem ser necessárias evidências complementares sobre os critérios e a execução da revisão.
Exemplo: transferência de área com acesso residual
Considere um caso hipotético em que uma colaboradora deixa a equipe de implantação e passa a trabalhar no suporte. O perfil principal é atualizado, mas sua participação em um grupo antigo continua permitindo publicar alterações em produção.
A auditoria poderia confrontar a data da transferência, a solicitação de ajuste, a composição dos grupos e as permissões resultantes. Se houver registros suficientes, também poderá examinar se o privilégio residual foi utilizado.
São conclusões diferentes: demonstrar que a permissão permaneceu disponível, demonstrar que uma operação ocorreu e atribuir essa operação a determinada pessoa. Cada conclusão exige elementos próprios. A existência do acesso residual não comprova seu uso nem a ocorrência de dano.
Evidências, testes e limitações
As fontes podem incluir inventários, matrizes de acesso, registros de aprovação, configurações, contratos de terceiros, informações de movimentação de pessoal e logs de autenticação e administração. A coleta deve ficar limitada ao escopo autorizado e às informações necessárias ao exame.
Testes controlados podem verificar se uma conta consegue executar uma operação permitida e se uma operação proibida é bloqueada. Devem ser planejados com contas apropriadas, autorização e condições que evitem alterações indevidas em produção.
A interpretação precisa considerar o período. Uma exportação das permissões atuais não reconstrói automaticamente os acessos de meses anteriores. Quando faltam históricos, essa limitação deve acompanhar os achados afetados.
Também é necessário distinguir a ausência de uso observado da ausência de capacidade de acesso. Uma conta pode ter privilégios excessivos sem eventos registrados de utilização; os logs disponíveis podem ser incompletos.
Resultados que apoiam decisões
Um achado útil identifica o recurso, a conta ou o conjunto afetado, o critério, a condição observada e as evidências que sustentam a conclusão. Também informa suas limitações e os efeitos tecnicamente demonstráveis.
As recomendações podem envolver ajustes de permissões, melhoria de aprovações, tratamento de contas sem responsável ou aperfeiçoamento da revisão periódica. Sua prioridade deve considerar a sensibilidade dos recursos, o alcance do acesso e os controles existentes. Alterações em identidades de aplicações exigem planejamento para evitar interrupções de serviços dependentes.
A Divisão de Auditoria de Sistemas da IBPTECH Brasil examina identidades, acessos e controles no contexto do ambiente tecnológico e das questões apresentadas. Quando o objeto envolve as regras internas de autorização de uma aplicação, o trabalho pode integrar a especialidade de Auditoria de Software.