Controle de acesso e princípio do menor privilégio

Controle de acesso responde quem pode fazer o quê

Controle de acesso é o conjunto de políticas e mecanismos que decide se um sujeito pode realizar determinada ação sobre um recurso. Em vez de perguntar apenas “a pessoa entrou no sistema?”, ele precisa responder algo mais preciso: esta identidade pode executar esta operação, neste recurso, agora e sob estas condições?

Essa precisão importa porque entrar em uma aplicação não deveria significar receber todas as suas funções. Uma pessoa pode consultar pedidos sem alterar preços; outra pode aprovar uma devolução até determinado limite; uma integração pode gravar em uma fila, mas não ler dados de clientes.

Na aula sobre controles de segurança e defesa em profundidade, o controle de acesso apareceu como uma camada. Aqui aprofundamos seu propósito e seu ciclo de vida. A pergunta central deixa de ser quais camadas existem e passa a ser como limitar e manter autorizações coerentes com o trabalho.

Sujeito, recurso, operação e política formam a decisão

Uma decisão de acesso pode ser compreendida com cinco elementos:

• sujeito: pessoa, processo, dispositivo ou serviço que solicita acesso;
• recurso ou objeto: informação, arquivo, aplicação, equipamento, sala ou função protegida;
• operação: ação solicitada, como visualizar, criar, alterar, aprovar, excluir ou administrar;
• contexto: condições relevantes, como horário, localização, dispositivo, vínculo e prazo;
• política: regras que relacionam esses elementos e orientam permitir ou negar.

Permissão é a autorização para uma operação sobre um recurso. “Acesso ao financeiro” é vago; “consultar notas fiscais da própria unidade” descreve melhor recurso, operação e limite. Quanto mais genérica a concessão, mais difícil verificar se ela continua necessária.

A política precisa ser aplicada no ponto em que o acesso acontece. Uma aprovação por e-mail, por exemplo, não limita tecnicamente uma conta se as permissões configuradas continuarem amplas. Processo administrativo e mecanismo técnico devem representar a mesma decisão.

Identificar, autenticar e autorizar são etapas diferentes

Três verbos próximos respondem perguntas distintas:

Autenticar com sucesso não torna toda ação legítima. Uma conta pode ser autêntica e ainda assim pedir algo fora de suas atribuições; também pode estar comprometida e usar permissões excessivas. Por isso, o sistema deve autorizar cada operação relevante segundo a política aplicável.

A aula sobre autenticação, senhas e múltiplos fatores aprofunda como uma identidade demonstra controlar seus autenticadores. Nesta página, autenticação é apenas uma entrada para a decisão de acesso — não o seu resultado final.

Menor privilégio limita escopo, ação e duração

O princípio do menor privilégio orienta conceder a cada entidade somente os recursos e autorizações necessários para cumprir sua função. “Mínimo” não significa impedir o trabalho nem escolher uma quantidade arbitrária. Significa justificar o acesso a partir da tarefa autorizada e retirar o que não contribui para ela.

Uma análise útil considera pelo menos quatro dimensões:

• alcance: quais sistemas, bases, pastas ou ambientes são necessários;
• operação: consultar, alterar e administrar não são equivalentes;
• tempo: o acesso é permanente ou necessário apenas durante uma atividade;
• contexto: existem condições adicionais, como dispositivo gerenciado ou aprovação específica?

Assim, uma pessoa que precisa corrigir uma configuração em produção durante uma janela de manutenção pode receber elevação temporária apenas para a operação aprovada. Ao fim do prazo, a permissão expira. Isso reduz a exposição de privilégios permanentes sem depender da memória de alguém para removê-los.

O princípio também se aplica a serviços, aplicações e processos automatizados. Uma integração que somente envia registros não deveria obter permissão para excluir a base inteira. Se a credencial for comprometida ou o software falhar, a extensão do dano possível fica limitada pelo que essa identidade técnica realmente podia fazer.

Necessidade de conhecimento restringe a informação

Necessidade de conhecimento aplica uma pergunta específica à informação: a pessoa precisa conhecer aquele conteúdo para executar uma atividade autorizada? Cargo, senioridade ou confiança pessoal não criam por si só essa necessidade.

Uma analista pode precisar consultar o status de uma solicitação, mas não o diagnóstico médico anexado a ela. Um fornecedor pode precisar de dados para entregar um serviço, mas não do cadastro completo usado por outras áreas. O recorte deve acompanhar finalidade, classificação da informação e responsabilidade.

Menor privilégio e necessidade de conhecimento se complementam. O primeiro limita recursos e capacidades; o segundo ajuda a limitar a exposição do conteúdo. Ambos evitam a ideia de que estar “dentro da empresa” torna todo acesso apropriado.

Segregação de funções evita concentração perigosa

Segregação de funções distribui etapas incompatíveis entre pessoas ou papéis para que uma única identidade não consiga concluir sozinha uma operação sensível sem supervisão. Em um pagamento, por exemplo, quem cadastra os dados bancários não deveria também aprovar e liberar a mesma transação.

O objetivo não é duplicar trabalho indiscriminadamente. A separação deve responder a um risco claro: fraude, erro não detectado, alteração sem revisão ou ocultação de evidências. Ela pode ser:

• estática: papéis conflitantes não podem ser atribuídos à mesma pessoa;
• dinâmica: a mesma pessoa pode exercer papéis diferentes, mas não em etapas conflitantes da mesma operação;
• organizacional: responsabilidades são divididas entre equipes ou linhas de supervisão.

Ter duas contas usadas pela mesma pessoa não cria segregação real. O controle precisa garantir independência suficiente entre quem inicia, aprova, executa e revisa uma ação, conforme a criticidade.

Autorizações possuem ciclo de vida

Uma permissão correta hoje pode se tornar excessiva amanhã. Pessoas mudam de projeto, assumem funções temporárias, trocam de equipe ou deixam a organização. Serviços são substituídos e contas técnicas perdem sua finalidade. Por isso, acesso não é uma configuração feita uma única vez.

Um ciclo consistente inclui:

1. solicitar: indicar recurso, operação, justificativa e duração;
2. aprovar: uma autoridade adequada avalia necessidade, risco e conflitos;
3. conceder: a configuração implementa exatamente o que foi aprovado;
4. usar e registrar: ações relevantes produzem registros proporcionais ao risco;
5. revisar: responsável, dono do recurso ou gestor confirma a necessidade atual;
6. alterar ou revogar: mudanças de função, prazo e vínculo são refletidas sem demora.

A revisão periódica complementa eventos de mudança; não deve substituí-los. Esperar o próximo trimestre para retirar o acesso de uma pessoa desligada cria uma janela desnecessária de exposição.

Exemplo: da equipe de suporte ao financeiro

Imagine Lara, que trabalha no suporte de uma plataforma educacional. Seu papel permite consultar chamados, visualizar dados básicos de contato e registrar soluções. Ela não pode alterar pagamentos nem exportar a base de estudantes.

Ao mudar temporariamente para um projeto financeiro, Lara precisa consultar conciliações e registrar divergências por 60 dias. O fluxo adequado não adiciona um pacote genérico de “acesso total ao financeiro” sobre tudo o que ela já tinha:

1. a solicitação descreve as duas operações necessárias e o prazo;
2. a liderança do projeto e o responsável pelo recurso aprovam o recorte;
3. o papel temporário é atribuído com expiração automática;
4. acessos antigos de suporte incompatíveis são retirados, não apenas acumulados;
5. ações sensíveis ficam registradas e sujeitas a revisão;
6. ao término do projeto, a permissão temporária expira;
7. no desligamento futuro, identidade e autorizações remanescentes são desabilitadas de forma coordenada.

Esse exemplo mostra por que o processo de entrada, movimentação e saída precisa integrar gestores, responsáveis pelos recursos, tecnologia e área de pessoas. Se cada sistema receber a informação em tempos diferentes, surgem contas órfãs e privilégios acumulados.

RBAC organiza permissões por papéis

No controle de acesso baseado em papéis, ou RBAC, permissões são associadas a papéis que representam responsabilidades relativamente estáveis. Pessoas recebem os papéis adequados, em vez de cada permissão ser negociada individualmente.

Um papel “Analista de suporte”, por exemplo, pode reunir consulta de chamados e atualização de status. Isso facilita concessão e revisão quando muitos profissionais executam atividades semelhantes. Papéis excessivamente amplos ou criados para cada exceção, porém, podem reproduzir o problema em outra camada.

ABAC avalia atributos e contexto

No controle baseado em atributos, ou ABAC, a decisão avalia atributos do sujeito, do recurso, da operação e, quando aplicável, do ambiente. Uma regra poderia permitir a consulta se a unidade da pessoa corresponder à unidade do registro, o dispositivo for gerenciado e a solicitação ocorrer durante a atribuição ativa.

ABAC permite decisões mais contextuais, mas exige atributos confiáveis, políticas compreensíveis e avaliação cuidadosa. Um dado de departamento desatualizado pode produzir uma decisão errada com a mesma velocidade de uma regra correta.

Não existe obrigação de escolher apenas um. Uma organização pode usar papéis como base e atributos para impor limites adicionais. A escolha deve equilibrar risco, escala, capacidade operacional e clareza da política.

Acesso privilegiado exige limites adicionais

Acessos capazes de alterar configurações, administrar identidades, ler grandes volumes de dados ou desativar controles merecem tratamento proporcional ao impacto. Além do menor privilégio, práticas úteis incluem:

• separar conta comum de conta administrativa;
• conceder elevação somente para a tarefa e pelo tempo necessários;
• exigir aprovação adequada antes de atividades de maior risco;
• registrar ações e proteger os próprios registros contra alteração indevida;
• revisar contas de serviço, chaves e privilégios permanentes;
• preparar revogação rápida e acesso emergencial controlado.

Uma ferramenta de gestão de acesso privilegiado pode apoiar esse processo, mas não substitui inventário, política, responsabilidade e revisão. Automatizar uma concessão mal definida apenas torna o erro mais rápido e uniforme.

Registro e revisão tornam o acesso verificável

Uma organização precisa conseguir explicar quem aprovou um acesso, por que ele existe, qual escopo foi concedido, quando expira e o que ocorreu durante ações sensíveis. Esses registros apoiam responsabilização, investigação e melhoria, respeitando também finalidade, retenção e proteção dos próprios dados registrados.

O conteúdo sobre Compliance em TI aprofunda como requisitos se conectam a controles e evidências. Em controle de acesso, uma captura de tela isolada raramente conta toda a história. Solicitação, aprovação, configuração, revisão e revogação formam evidências complementares.

Uma revisão de acesso de qualidade pergunta:

• a responsabilidade ainda existe?
• o recurso e a operação continuam necessários?
• permissões diretas ou exceções escapam do papel esperado?
• há combinações incompatíveis de funções?
• o prazo e o responsável estão definidos?
• contas sem dono, sem uso ou de pessoas desligadas foram tratadas?

Erros comuns em controle de acesso

• confundir login com autorização: entrar no sistema não legitima qualquer ação;
• copiar acesso de outra pessoa: o conjunto copiado pode conter exceções antigas e responsabilidades diferentes;
• somar sem retirar: mudanças de função acumulam permissões ao longo do tempo;
• aprovar nomes genéricos: “perfil avançado” não deixa claro recurso e operação;
• revisar por formalidade: marcar toda a lista como correta sem confrontá-la com a função atual;
• ignorar identidades técnicas: serviços, robôs e integrações também possuem privilégios;
• confiar apenas na rede interna: localização não substitui decisão explícita de acesso;
• manter elevação permanente por conveniência: tarefas ocasionais não justificam privilégio contínuo.

O que você deve guardar

• Controle de acesso decide se um sujeito pode executar uma operação sobre um recurso conforme uma política.
• Identificação, autenticação e autorização respondem perguntas diferentes.
• Menor privilégio limita alcance, operação, contexto e duração ao necessário.
• Necessidade de conhecimento reduz exposição de informação; segregação de funções evita concentração perigosa.
• Autorizações precisam acompanhar entrada, movimentação e saída de pessoas e serviços.
• RBAC organiza permissões por papéis; ABAC avalia atributos e contexto; os modelos podem ser combinados.
• Aprovação, configuração, registro, revisão e revogação precisam contar a mesma história.

O próximo passo da trilha é entender como a identidade é verificada por mecanismos de autenticação e por que senhas e múltiplos fatores precisam ser tratados separadamente da autorização.

Referências

• NIST — SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations. Release 5.2.0 consultada. Acesso em 28 ago. 2026.
• NIST — SP 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations. Acesso em 28 ago. 2026.
• NIST — Role Based Access Control: FAQ. Acesso em 28 ago. 2026.
• NIST CSRC Glossary — Authorization. Acesso em 28 ago. 2026.
• NIST CSRC Glossary — Least Privilege. Acesso em 28 ago. 2026.
• NIST CSRC Glossary — Separation of Duty. Acesso em 28 ago. 2026.
• Gabinete de Segurança Institucional — OSIC 08/2023: Gestão de Acesso Privilegiado. Acesso em 28 ago. 2026.