O princípio do privilégio mínimo (PoLP) é um conceito de segurança da informação segundo o qual usuários, aplicações e processos recebem apenas os direitos de acesso mínimos de que precisam para realizar uma tarefa, pelo menor tempo necessário, e nada além disso.
Todo usuário, aplicação e processo em uma organização precisa de algum nível de acesso para desempenhar sua função. Um desenvolvedor precisa enviar código para um repositório. Um funcionário do faturamento precisa consultar registros de pagamento. Um serviço de backup precisa ler dados de um banco de dados.
Sob o princípio do privilégio mínimo, cada uma dessas entidades recebe exatamente o acesso que essas tarefas exigem e nada mais.
O conceito às vezes é chamado de acesso com privilégio mínimo ou acesso mínimo. Ele se aplica tanto a contas de usuários humanos quanto a identidades não humanas (NHIs), incluindo aplicações, dispositivos, contas de serviço, chaves de API e agentes de IA.
O PoLP é um componente central do gerenciamento de identidade e acesso (IAM), o framework de segurança mais amplo que rege quem obtém acesso, o que pode fazer com ele e por quanto tempo. Em outras palavras, o IAM é o sistema que coloca o PoLP em prática.
O PoLP também é um dos mecanismos fundamentais da segurança zero trust. No modelo zero trust, nenhum usuário, dispositivo ou aplicação é confiável por padrão, nem mesmo na rede corporativa. Em vez disso, cada solicitação de acesso é analisada e concedida caso a caso. As solicitações legítimas recebem acesso conforme o PoLP e nada além disso. Dessa forma, o PoLP pode ajudar as organizações a fazer cumprir a conformidade, conter incidentes de segurança e reforçar sua postura de segurança como um todo.
Junte-se aos líderes de segurança que confiam no boletim informativo Think para receber notícias selecionadas sobre IA, cibersegurança, dados e automação. Aprenda rápido com tutoriais e explicações de especialistas, entregues diretamente em sua caixa de entrada. Consulte a Declaração de privacidade da IBM.
O argumento mais direto a favor do PoLP é o cenário de credencial comprometida. Um invasor obtém um nome de usuário e uma senha válidos, geralmente por meio de um e-mail de phishing, de um mercado na dark web ou de um malware infostealer. Em seguida, o invasor faz login. Da perspectiva da rede, isso parece uma sessão normal de um usuário legítimo.
Se a conta comprometida possuir privilégios excessivos (acesso a sistemas, bancos de dados e compartilhamentos de arquivos que o usuário real nunca acessa no dia a dia) o invasor agora também tem todas essas permissões. Ele pode se movimentar lateralmente pela rede em direção a alvos de maior valor e a informações sensíveis, como registros financeiros, bancos de dados de clientes e código-fonte proprietário.
É esse movimento lateral que pode transformar uma única senha comprometida em uma violação de dados de grandes proporções.
Segundo o relatório do custo das violações de dados da IBM, as violações que começam com credenciais comprometidas custam em média USD 4,67 milhões e levam cerca de 246 dias para serem encontradas e contidas.O IBM X-Force Threat Intelligence Index constatou que contas sequestradas estiveram envolvidas em 32% dos ataques cibernéticos analisados.
Ao limitar o acesso que qualquer conta possui, o princípio do privilégio mínimo ajuda a reduzir significativamente o raio de impacto dos ataques. Ele reduz o que um invasor consegue alcançar com a conta inicial, ajuda a impedir o acesso não autorizado a sistemas não relacionados e limita os danos potenciais de qualquer violação isolada.
Por exemplo, imagine que um hacker comprometa a conta de um analista de marketing. Com o privilégio mínimo em vigor, ele poderia acessar alguns dashboards em uma ferramenta de gerenciamento de relacionamento com o cliente (CRM), mas nada além disso. Sem o PoLP, essa mesma conta ainda poderia ter acesso a bancos de dados de produção, APIs internas e servidores de arquivos de projetos que terminaram meses atrás. É o mesmo ataque, mas com um raio de impacto muito maior.
As identidades não humanas (NHIs), contas de serviço, identidades de carga de trabalho, bots e agentes de IA, hoje representam a maioria das identidades na maior parte dos ambientes corporativos. Segundo uma estimativa, as identidades de máquina superam as humanas em uma proporção de 45:1.
Em conjunto, as NHIs representam uma enorme superfície de ataque. Cada uma é uma vulnerabilidade em potencial se suas permissões não forem cuidadosamente delimitadas.Os ambientes de nuvem, as arquiteturas de acesso remoto e a proliferação de serviços de software fazem com que haja muito mais identidades solicitando acesso a sistemas críticos do que havia antes.
Segundo a OWASP, o excesso de privilégios é um dos 10 principais riscos associados às identidades não humanas. Por serem parte integrante de fluxos de trabalho essenciais (como o ciclo de vida de DevOps e os backups de sistema), as NHIs costumam ter acesso privilegiado a informações sensíveis. E, no intuito de fazer esses processos "simplesmente funcionarem", as organizações muitas vezes concedem às NHIs privilégios maiores do que precisam.
A exposição de credenciais é outra questão a considerar. Aplicações e dispositivos não usam senhas, mas usam chaves de API, tokens OAuth, certificados e outros segredos para se autenticar. Esses segredos podem ser roubados e usados indevidamente da mesma forma que as senhas dos usuários humanos, possibilitando acesso não autorizado e movimento lateral pelos sistemas.
Ao contrário dos usuários humanos, as NHIs não podem usar autenticação de dois fatores, por isso, uma única credencial roubada costuma ser tudo o que é preciso para sequestrar uma conta. O PoLP não impede o roubo de credenciais, mas limita o que uma credencial roubada consegue alcançar.
As NHIs muitas vezes permanecem ativas depois que as aplicações ou dispositivos associados são desativados, sem monitoramento e com todas as suas permissões intactas. Na verdade, o desligamento inadequado é o principal risco associado às NHIs de acordo com a OWASP.
O PoLP ajuda a lidar com esses riscos ao garantir que cada NHI opere apenas com o acesso de que precisa. Essas restrições podem ajudar a limitar os danos caso uma credencial seja roubada e a reduzir as exposições quando uma NHI é desativada.
O PoLP também ajuda a proteger contra ameaças internas. Essas ameaças incluem tanto agentes internos maliciosos que abusam deliberadamente de seu acesso quanto funcionários bem-intencionados que causam danos acidentalmente com permissões de que não precisam e que talvez nem saibam que têm.
De acordo com o relatório do custo das violações de dados, os ataques de agentes internos maliciosos são o vetor de violação mais dispendioso, com um custo médio de USD 4,92 milhões por incidente. Esse valor é maior do que o de phishing, ransomware e credenciais comprometidas.
O custo é tão alto em parte porque os agentes internos já têm acesso legítimo. Não há perímetro a ser violado nem login suspeito a ser sinalizado. Quando um usuário tem permissões que vão muito além de sua função, o dano que ele pode causar, seja intencionalmente ou por acidente, é limitado apenas pelo que ele consegue alcançar. O PoLP limita esse alcance.
Vários padrões regulatórios e frameworks de conformidade tratam o privilégio mínimo como um requisito básico para restringir o acesso a dados sensíveis.
O PoLP começa com uma postura de negação padrão. Todo usuário, aplicação e processo começa com acesso zero. As permissões são adicionadas apenas conforme a necessidade. As permissões são delimitadas a uma tarefa específica ou a uma função definida, em vez de senioridade, conveniência ou outros critérios menos relevantes. Cada usuário recebe apenas o conjunto mínimo de direitos de acesso que seu trabalho exige, conforme documentado em políticas de acesso formais definidas pelas equipes de identidade e segurança.
Na prática, isso significa que o PoLP pode ser bastante granular.
Considere um sistema de controle de acesso baseado em funções (RBAC). No RBAC padrão, um agente de suporte ao cliente pode receber um amplo acesso permanente ao sistema de faturamento da empresa. Em um sistema RBAC que opera de acordo com o princípio do privilégio mínimo, esse mesmo agente pode receber permissões somente leitura por padrão. Se um chamado específico exigir algo como atualizar as informações de um cliente, o agente pode solicitar acesso temporário para essa interação.
O princípio do privilégio mínimo se aplica a quatro etapas do ciclo de vida do acesso.
Quando alguém entra em uma organização, assume uma nova função ou configura uma conta em um novo recurso, recebe um nível básico de acesso. O acesso pode ser baseado em funções, baseado em atributos ou provisionado sob demanda, sem nenhuma permissão permanente, dependendo do modelo de acesso em uso.
O que o PoLP acrescenta, independentemente do modelo, é que o acesso deve sempre ser delimitado ao mínimo necessário para a função ou tarefa em questão. Por exemplo, um novo analista financeiro de um banco poderia, tecnicamente, ter acesso a uma ampla gama de ferramentas de relatórios e conjuntos de dados. No entanto, sob o PoLP, esse analista recebe apenas os dashboards e conjuntos de dados específicos que seu trabalho atual exige, não tudo o que as ferramentas poderiam oferecer. Se suas responsabilidades mudarem ou se expandirem, o acesso é ajustado conforme necessário.
Quando os usuários estão exercendo ativamente suas permissões, os mecanismos de controle de acesso fazem valer, no curso normal do trabalho, os limites definidos durante o provisionamento.
Por exemplo, o analista financeiro mencionado anteriormente pode executar consultas nos conjuntos de dados aos quais recebeu acesso provisionado, mas, se tentar abrir um arquivo fora de seu escopo, o acesso é negado. O limite definido no provisionamento se mantém.
Se o mesmo analista for temporariamente designado para outro projeto e precisar de acesso a um conjunto de dados diferente, pode enviar uma solicitação de acesso. O sistema de IAM a avalia, verificando identidade, função, contexto e intenção, e concede a permissão adicional durante a vigência desse projeto. Quando ele termina, o acesso elevado é revogado.
As equipes de identidade e segurança realizam auditorias periódicas para verificar se as permissões e as políticas de acesso ainda correspondem às responsabilidades dos usuários, às configurações de rede, às operações de negócios e a outros critérios relevantes. Essas revisões podem ajudar a identificar uma série de problemas comuns de acesso, como um funcionário que mudou de equipe, mas manteve todas as suas permissões antigas, ou uma conta de prestador de serviços que nunca foi desprovisionada.
Quando o acesso deixa de ser necessário (porque alguém saiu da empresa, mudou de equipe ou concluiu uma tarefa), as permissões são revogadas. O acesso remanescente em contas antigas ou esquecidas é uma vulnerabilidade comum. Muitas vezes, ninguém está monitorando o que acontece nelas, o que torna essas contas alvos fáceis para os invasores. O desprovisionamento adequado das contas ajuda as organizações a reduzir sua superfície de ataque e a impedir o acesso não autorizado a partir de contas inativas comprometidas.
O princípio do privilégio mínimo e a segurança zero trust se sobrepõem, mas não são a mesma coisa.Zero trust é uma arquitetura de cibersegurança construída com base na ideia de que nunca se deve confiar e sempre se deve verificar toda solicitação de acesso, não importa de onde ela venha. O princípio do privilégio mínimo é um modelo para definir quanto acesso conceder a uma solicitação legítima.
O zero trust rejeita o antigo modelo de perímetro, que presumia que tudo dentro do firewall da rede era seguro. O zero trust reconhece que os invasores podem ultrapassar o perímetro externo e que os agentes internos também podem causar violações de segurança.
No modelo zero trust, nenhum usuário, dispositivo ou aplicação é confiável por padrão, nem mesmo na rede corporativa. Toda solicitação de acesso é avaliada com base na identidade, no dispositivo, na localização e nos padrões de comportamento. Mesmo após a autenticação, os usuários recebem apenas o acesso mínimo de que precisam para o que estão fazendo naquele momento.
Em outras palavras, o zero trust controla as condições para conceder acesso, enquanto o PoLP controla o escopo. Juntos, eles possibilitam uma abordagem de defesa em profundidade para o gerenciamento de acesso.
O acesso just-in-time (JIT) é uma forma de implementar o PoLP. Ele é frequentemente considerado a expressão mais rigorosa e granular do privilégio mínimo, porque elimina completamente as permissões permanentes. Isso significa que ele não provisiona um nível básico de acesso para depois gerenciar o que estiver acima dele. Em vez disso, o JIT concede acesso sob demanda para uma tarefa específica e o revoga automaticamente quando a tarefa é concluída.
Por exemplo, um engenheiro de banco de dados que precisa executar um script de migração em um banco de dados de produção não tem nenhum acesso permanente a esse sistema. Em vez disso, ele solicitaria acesso por uma janela de quatro horas, o receberia, o usaria e o perderia. Não há nível básico nem permissões remanescentes.
Para as organizações que desejam aplicar o PoLP da forma mais rigorosa possível, o JIT costuma ser a abordagem mais eficaz. Se ninguém nunca tem acesso permanente, não há contas inativas nem permissões remanescentes para os hackers explorarem. No entanto, ele pode trazer desafios. Provisionar tudo sob demanda pode gerar atrito operacional, sobretudo em tarefas rotineiras, e integrar o JIT em sistemas legados e ambientes de nuvem pode ser tecnicamente complexo.
As organizações aplicam o PoLP por meio de modelos de controle de acesso, frameworks que definem como as permissões são atribuídas, gerenciadas e revisadas.
Dois modelos de segurança são comuns nas implementações de PoLP: o controle de acesso baseado em funções e o controle de acesso baseado em atributos.
O controle de acesso baseado em funções (RBAC) agrupa permissões em funções de usuário predefinidas ("analista financeiro", "engenheiro de redes", "help desk") e atribui pessoas a essas funções, em vez de configurar permissões individualmente para cada usuário. A estrutura espelha o modo como a maioria das organizações já funciona, com departamentos, cargos e linhas de subordinação.
Embora o RBAC seja mais seguro do que muitos outros modelos de acesso, ele raramente alcança o privilégio mínimo sozinho. Em vez disso, com frequência ele precisa ser combinado com outros controles, como revisões de acesso e provisionamento JIT.
Por exemplo, o RBAC padrão pode criar um conjunto de permissões permanentes para cada função, enquanto o RBAC de privilégio mínimo pode usar o JIT em vez de privilégios permanentes.
Enquanto o RBAC atribui permissões com base em quem é o usuário, o ABAC toma decisões com base em um conjunto mais amplo de atributos. Os atributos podem incluir características do usuário (departamento, nível hierárquico, localização), do recurso (classificação de sensibilidade, tipo de dado), do ambiente (horário do dia, rede, tipo de dispositivo) e da ação solicitada (leitura, escrita, exclusão).
Por exemplo, uma política de ABAC em uma empresa de serviços financeiros pode permitir que um analista acesse dados sensíveis de transações apenas durante o horário comercial, apenas a partir de um notebook corporativo gerenciado e apenas enquanto estiver conectado à rede da empresa. O mesmo analista que tentasse acessar os mesmos dados à meia-noite, de um celular pessoal usando o wi-fi de um aeroporto, seria bloqueado.
Muitas implementações de PoLP usam o ABAC pela precisão com que ele consegue delimitar as decisões de acesso, com uma combinação complexa de usuário, recurso, contexto e ação. E muitas das ferramentas das quais o PoLP depende, como o acesso just-in-time, usam alguma forma de ABAC para tomar decisões de acesso.
Enquanto os modelos de controle de acesso definem como as permissões devem ser estruturadas, as ferramentas de IAM ajudam a aplicar essas permissões. Essas ferramentas gerenciam, monitoram e controlam o acesso de usuários em escala, em endpoints locais, data centers e ambientes de nuvem.
As ferramentas de gerenciamento de acesso privilegiado (PAM) concentram-se nas contas de maior risco: contas de superusuário, contas de serviço e outros usuários privilegiados com privilégios de administrador. Uma conta privilegiada comprometida pode expor toda a configuração de um sistema, o banco de dados de usuários e as chaves de criptografia, não apenas os dados de uma única pessoa.
As ferramentas de PAM lidam com esse risco armazenando credenciais privilegiadas em cofres criptografados, registrando sessões e aplicando fluxos de trabalho de aprovação, de modo que os privilégios elevados estejam sempre controlados, monitorados e limitados no tempo.
Por exemplo, um administrador de banco de dados que precise de acesso root para executar uma operação de manutenção não pode simplesmente fazer login quando quiser. Ele precisa solicitar acesso, obter aprovação e concluir o trabalho dentro de uma janela de tempo definida.
As plataformas de governança e administração de identidades (IGA) vinculam o gerenciamento de acesso ao ciclo de vida do funcionário. Elas se conectam aos sistemas de RH, de modo que, quando alguém entra na organização, muda de equipe ou sai, seus direitos de acesso se ajustam automaticamente. Essa automação pode ajudar a agilizar o provisionamento e o desprovisionamento, além de evitar o aumento indevido de privilégios.
Os fluxos de trabalho automatizados de IGA são importantes em grandes organizações, nas quais gerenciar o provisionamento e o desprovisionamento manualmente é uma receita para o excesso de permissões e contas não desativadas.
Embora o PoLP seja fácil de almejar, pode ser mais difícil de manter.
O acúmulo de privilégios é o aumento gradual de direitos de acesso que ocorre quando os usuários mudam de função, assumem projetos paralelos ou acumulam permissões temporárias que ninguém se lembra de revogar.
Por exemplo, um analista de marketing muda para a equipe de produto, mas mantém o acesso ao drive compartilhado do marketing e ao dashboard de análise da equipe. Ou um desenvolvedor recebe acesso temporário a um banco de dados de produção para depurar um problema de um cliente, e esse acesso temporário se torna permanente por inércia.
Com o tempo, esses privilégios excessivos acumulados criam contas infladas, com muito mais acesso do que qualquer função exige. Os próprios usuários podem não perceber tudo a que têm acesso.
O privilégio mínimo levado longe demais pode paralisar o trabalho. Se um funcionário precisa abrir um chamado e esperar dois dias para ter acesso a um sistema de que precisa para o trabalho de uma tarde, ele pode tentar encontrar soluções alternativas: pegar emprestadas as credenciais de um colega, usar uma conta de serviço compartilhada ou recorrer a uma ferramenta não autorizada que não exige aprovação da TI. Essas soluções alternativas podem, então, criar riscos de segurança piores do que os que uma política de acesso um pouco mais permissiva teria criado.
De acordo com o relatório do custo das violações de dados, a IA oculta, ferramentas de inteligência artificial não autorizadas, foi um fator em 20% das violações.
A IA oculta é, em parte, um problema de privilégio mínimo. Quando as ferramentas autorizadas são restritas demais ou lentas demais para acessar, as pessoas podem se sentir tentadas a contorná-las.
As organizações podem ajudar a equilibrar essas demandas trabalhando para tornar o acesso fácil de solicitar e rápido de conceder. Portais de autoatendimento, fluxos de trabalho de aprovação automatizados e o acesso just-in-time podem ajudar a provisionar exatamente as permissões certas pelo tempo exato que a tarefa exigir.
Proteja o acesso sem atrito em ambientes híbridos e multinuvem com uma solução de IAM confiável e independente de fornecedor.
As soluções de segurança zero trust conectam com segurança os usuários a dados confidenciais, protegendo as organizações contra ameaças cibernéticas.
Coloque sua força de trabalho e o programa de IAM do consumidor no caminho para o sucesso com skills, estratégia e suporte de especialistas em identidade e segurança.