Repensando a identidade e o acesso para nativos da nuvem

O mercado de gerenciamento de identidade e acesso (IAM) é gigantesco: centenas de fornecedores e um mercado projetado de US$ 19 bilhões em 2024, de acordo com o Gartner.

Mas as soluções IAM prontas para uso, bem como os recursos dos provedores de serviços em nuvem, estão sendo ampliados pelo novo mundo de cenários de privilégios mínimos nativos da nuvem. E como tantos outros exemplos nativos da nuvem, algumas das abordagens mais interessantes são, na verdade, esforços personalizados de engenheiros de plataforma, nascidos da necessidade dentro das paredes de suas próprias organizações.

Qualquer fornecedor que ajude os clientes a proteger as suas cadeias de abastecimento, ou que forneça software como imagens de contentores que se tornam um componente importante das cadeias de abastecimento dos seus clientes, precisa de levar esta abordagem à segurança de forma séria e meticulosa. Aqui estão algumas maneiras de conseguir isso.

Novas pressões para abordagens clássicas de IAM

As equipes de engenharia de plataforma estão sendo encarregadas de descobrir melhores estratégias de “defesa em profundidade”. Tirando uma página da mentalidade da engenharia de confiabilidade de sites (SRE) do Google, se assumirmos que nossas linhas de defesa são apenas 99% confiáveis, então é lógico que com o tempo veremos falhas, então como uma equipe de plataforma pode construir camadas? de proteção redundante que interrompe as ameaças depois que elas violam uma ou mais dessas camadas de proteção?

Uma parte fundamental disso é sua estratégia de IAM e uma prática chamada “privilégio mínimo”. O princípio do menor privilégio é uma prática recomendada de segurança amplamente aceita, onde o objetivo é minimizar o acesso (ou privilégio) concedido às identidades em diversas dimensões:

• Minimalismo: Nível de acesso (admin > escritor > leitor > nenhum)
• Minimalismo: Escopo de acesso (org > unidade organizacional/pasta > conta/projeto > recurso > nenhum)
• Efemeridade: Duração (para sempre > longa duração > curta duração > nenhuma)

Geralmente, as identidades nas plataformas de nuvem são criadas do zero: sem acesso a nada.

figura 1

Este é um excelente ponto de partida, e os privilégios são adicionados por meio de concessões de uma função específica (conjunto de recursos) em um escopo IAM específico, de preferência, o recurso exato com o qual esses recursos são necessários para interagir.

Supondo que todos adiram a esses ideais, o menor privilégio será alcançado. Um bom nome para este modelo é “privilégio mínimo cooperativo”, porque exige que todos os participantes do modelo de controle de acesso trabalhem juntos para garantir que o privilégio mínimo seja alcançado (semelhante à multitarefa cooperativa).

A evolução para o menor privilégio auditado

A crença da equipe de engenharia da plataforma deve ser a de que qualquer controle de segurança é falível e, portanto, um modelo de defesa profunda deve ser implantado onde vários controles sobrepostos são usados ​​para verificar se o sistema geral está funcionando corretamente. Por exemplo, Chainguard analisa esta crença ainda mais profundamente para o nosso design de segurança, perguntando-nos como verificamos os pressupostos de um modelo cooperativo de privilégios mínimos e garantimos que não haja acesso indevido aos nossos recursos.

Figura 2

É bastante comum focar no ator ao raciocinar sobre privilégios mínimos, como evidenciado pela visualização centrada na identidade acima, mas e se reorientarmos em torno dos átomos do outro lado das setas de concessão de acesso? Como seria uma visão centrada em recursos de privilégios mínimos?

No entanto, devido à natureza hierárquica dos modelos IAM, as concessões que permitem o acesso podem ser difíceis de descobrir na íntegra. Então, como podemos garantir que nossos recursos sejam acessados ​​apenas da maneira que esperamos pelas identidades que esperamos interagir com eles? A resposta ficou bastante clara: registros de auditoria do IAM.

A base do privilégio mínimo cooperativo são as concessões de acesso IAM muito boas. Quando invertemos as coisas, as políticas de log de auditoria do IAM são muito boas. É um modelo que chamamos de “privilégio mínimo auditado”.

No modelo de privilégio mínimo auditado, emparelhamos cada recurso de nuvem que provisionamos com uma política de alerta de log de auditoria do IAM que é acionada sempre que um recurso é acessado fora do mínimo esperado. Este mínimo é normalmente definido em termos de um conjunto de princípios IAM mapeados para interações aceitáveis ​​(como no nosso diagrama acima). Meu apelido para essas políticas de alerta do IAM tornou-se “grade de laser”, porque evoca o visual do roubo de Hollywood do artefato de valor inestimável cercado por raios laser.

Mapeamento para 99,9% esperados + auditoria: um padrão vencedor

Semelhante à construção de sistemas distribuídos e confiáveis ​​a partir de componentes menos confiáveis, ao colocar sua defesa em camadas com apenas duas camadas com 99% de confiabilidade e presumindo que as formas como elas falharão não estão correlacionadas, você aumenta a probabilidade de que a defesa em camadas se mantenha para 99,99. %.

Existem muitas armadilhas no IAM que são bastante conhecidas, mas ainda comuns. As concessões do IAM tendem a ser excessivamente amplas, por exemplo, concedendo privilégios em nível de conta ou projeto em vez de nível de recurso. Às vezes, as capacidades concedidas são demasiado amplas, possivelmente devido a políticas integradas excessivamente grosseiras. Coisas como reutilizar identidades de carga de trabalho em vários serviços são outra proibição, porque quando três coisas diferentes usam o mesmo serviço e qualquer uma delas precisa se comunicar com algo novo, você acaba concedendo essa capacidade a todos os três serviços que usam essa identidade.

Pense no IAM como um bloqueio (também conhecido como mutex). Você deseja minimizar a quantidade de trabalho que realiza enquanto mantém esses privilégios. Os microsserviços permitem extrair a funcionalidade que precisa de certos privilégios com uma interface agradável e restrita apenas para esse serviço.

Foi assim que a Chainguard desenvolveu sua implementação com menos privilégios em torno do nosso produto Chainguard Images. Acreditamos que o princípio do menor privilégio (minimalismo) através de credenciais de curta duração (efemeridade) é fundamental para a melhor postura de segurança. Quando criamos abstrações de serviço em torno de recursos, configuramos grades de laser em torno desses recursos que codificam nossa auditoria para que recebamos alertas sempre que alguma entidade estiver tentando acessar dados, o que é anômalo em relação aos 99,9% do acesso esperado.

Estamos em um momento interessante na engenharia de plataforma, onde o isolamento possibilitado pelos microsserviços, a maturidade do OpenID Connect e outros mecanismos de autenticação, e a capacidade das equipes de plataforma criarem novas camadas de encapsulamento, estão todos se unindo. Como tantas inovações anteriores em nuvem nativa, o que começa como esforços personalizados nascidos da necessidade pelas equipes de engenharia de plataforma é uma espiada no futuro. E acho que veremos uma programação e auditoria muito mais profundas sendo introduzidas no IAM à medida que a indústria se torna mais inteligente sobre como encapsula a segurança em sistemas distribuídos.

A postagem Repensando a identidade e o acesso para o Cloud Native apareceu pela primeira vez em The New Stack.