Obtendo controle sobre o caos do Cloud IAM

Voando às cegas pela complexidade do Cloud IAM

A natureza efêmera e dinâmica dos recursos de nuvem, combinada com novos recursos habilitados por rede definida por software na nuvem, torna os perímetros de segurança tradicionais insuficientes para o gerenciamento de risco bem-sucedido. Portanto, os principais usuários da nuvem mudaram seu foco de segurança para um novo perímetro – identidade. Isso é substancialmente diferente e mais complexo do que o perímetro de firewall dos data centers tradicionais.

A complexidade das ferramentas de gerenciamento de identidade e acesso (IAM) do provedor de serviços de nuvem torna excepcionalmente desafiador determinar quem – ou o quê – tem acesso a um recurso de nuvem. Por exemplo, Amazon Web Services (AWS) oferece uma ampla lógica de avaliação de política, começando com um contexto de solicitação e, em seguida, derivando todas as políticas aplicáveis a partir dele. Em uma única conta da AWS, essa lógica de avaliação envolve até cinco camadas de política sobrepostas para permitir ou negar acesso. Combine essas camadas de política com a identidade local e o resultado é uma confusão de privilégios de IAM sobrepostos e muitas vezes conflitantes.

Quando se trata de IAM na nuvem, as equipes de segurança e operações estão voando quase às cegas. Essa visibilidade cai para zero à medida que as implantações de nuvem aumentam e a complexidade do IAM da nuvem aumenta com a escala. Esse quebra-cabeça resultante de políticas e regras de IAM significa que as organizações perdem qualquer capacidade de atribuir e gerenciar o acesso menos privilegiado (LPA) à nuvem, muito menos compreender a permissividade de seu acesso à nuvem. Ainda mais importante, quando as organizações não estão totalmente no controle da governança do IAM da nuvem, elas são incrivelmente vulneráveis. Se houver um incidente de segurança, a falta de visibilidade do IAM na nuvem torna a determinação do raio de explosão potencial uma tarefa difícil, se não impossível.

Para aumentar a visibilidade da identidade da nuvem e reduzir o risco, as equipes de segurança precisam encontrar uma maneira de destilar clareza da complexidade do IAM da nuvem. Eles devem ser capazes de:

Obtenha visibilidade de toda a imagem do IAM na nuvem para avaliar, priorizar e corrigir combinações de permissões impróprias que concedem acesso não intencional ou excessivamente permissivo;
Explore o acesso efetivo por usuário principal, recurso ou aplicativo;
Compreenda o verdadeiro acesso a combinações complexas de IAM;
Estabelecer e manter privilégios mínimos; e
Limite e entenda o raio de explosão da segurança na nuvem.

Parafraseando Albert Einstein, não podemos obter clareza a partir da complexidade do IAM em nuvem com o mesmo nível de pensamento que o criou. Essa mudança de pensamento começa com a compreensão do que é necessário para conceder acesso a um recurso de nuvem.

A complexidade e o caos atuais do Cloud IAM

Quer seus recursos estejam na nuvem ou no local, a maioria das organizações tem três objetivos principais de IAM:

Avaliar e limitar o raio de explosão de uma falha potencial do IAM;
Resposta eficaz às falhas do IAM no caso de uma exploração; e
Estabelecer e manter o controle sobre o LPA.

Mesmo antes do advento da nuvem, esses objetivos eram difíceis de alcançar. O comprometimento da identidade e o aumento de privilégios foram, são e continuarão sendo vetores de ataque primários.

Tudo tem uma identidade

Uma prática já complicada torna-se quase impossível em face da escala, escopo e natureza efêmera dos serviços em nuvem. Cada serviço e ativo na nuvem tem sua própria identidade com várias camadas de permissão.

Em ambientes de nuvem pública como AWS, Microsoft Azure e Google Cloud Platform, cada componente (por exemplo, VM, intervalo de armazenamento, serviço de infraestrutura, função sem servidor) está associado a funções e permissões. Mesmo pequenas pegadas na nuvem exigem centenas de regras de permissão de identidade, cada uma construída por um ou mais controles IAM do provedor de serviços em nuvem. E, há uma sobreposição de controle significativa. Por exemplo, uma permissão de política de grupo pode cancelar, aumentar ou reduzir uma permissão de política individual.

Depois que a equipe de segurança ativa todos os dials do IAM para definir as políticas e regras do IAM, o que resta são as permissões efetivas. Eles constituem o conjunto de permissões de rede para o ativo ou principal da nuvem. Permissões efetivas são uma construção poderosa do IAM na nuvem, mas, conforme descrito abaixo, simplesmente determinar o que são não é suficiente para o sucesso do IAM na nuvem. A boa notícia é que existem maneiras de enriquecer e aumentar as permissões eficazes com os dados, insights, contexto de risco e perspectiva certos para impulsionar o IAM na nuvem de sucesso.

AWS como uma verificação da realidade do Cloud IAM

A AWS oferece um conjunto robusto de recursos de IAM. Conforme mostrado na figura abaixo, a lógica de avaliação da política da AWS inclui cinco etapas da política mais uma negação explícita. Essencialmente, uma ação do IAM começa com uma negação e então flui pelas etapas da política para tomar uma decisão final de permissão/negação. Este modelo de cinco portas é uma abordagem clássica baseada em ameaças, em que cada etapa de permissão/negação reduz o potencial de uma exploração por um agente de ameaça malicioso (por exemplo, um estranho, interno, usuário ou aplicativo).

Negação explícita – primeiro, a AWS avalia todas as políticas aplicáveis do IAM para determinar se há uma negação explícita para esta solicitação. Por exemplo, pode haver uma política que negue explicitamente qualquer chamada de API da Coreia do Norte. Sem uma negação explícita, a primeira porta de política é ativada.

SCPs do AWS Organizations – uma política de controle de serviço (SCP) do AWS Organizations limita as “permissões que as políticas baseadas em identidade ou políticas baseadas em recursos concedem às entidades”. Em outras palavras, a unidade organizacional possui um SCP aplicável? Se houver uma licença, o próximo portão será ativado. Se não houver permissão, haverá uma negação implícita. No entanto, se não houver um SCP conectado à unidade organizacional, a próxima porta de política ainda será ativada.

Políticas baseadas em recursos – esta porta de política avalia as permissões inline para um recurso (por exemplo, bucket S3 e políticas de confiança de função IAM). Como acontece com os SCPs, se não houver uma política baseada em recursos, a próxima porta de política será ativada. Ao contrário dos SCPs, no entanto, se houver uma política baseada em recursos com uma permissão, o acesso é concedido sem maiores obstáculos.

Limites de permissões do IAM – esta política define as “permissões máximas que as políticas baseadas em identidade podem conceder a uma entidade IAM”. A permissão máxima é o oposto do LPA. Como acontece com SCPs e políticas baseadas em recursos, a próxima porta é ativada se não houver um limite de permissão definido. Se o limite de permissão do IAM for definido e não houver permissão, haverá uma negação implícita.

Políticas de sessão – políticas de sessão “limitam as permissões que a função ou as políticas baseadas na identidade do usuário concedem à sessão. As políticas de sessão limitam as permissões para uma sessão criada, mas não concedem permissões ”. Tal como acontece com as portas de política acima, se não houver uma política de sessão definida, a próxima porta será ativada. Se houver uma política de sessão e não houver permissão, haverá uma negação implícita.

Políticas baseadas em identidade – neste portão final, uma negação implícita é dada se não houver uma política associada ao indivíduo, ou se houver uma política e nenhuma permissão. Essencialmente, uma licença explícita ocorre apenas quando há uma política baseada em identidade e uma licença.

O Cloud IAM Inferno

Trabalhar por meio desse processo de bloqueio de política de IAM de nuvem deixa as equipes de segurança com uma pilha de políticas sobreposta que consiste em vários pontos de decisão de permissão/negação para cada ativo de nuvem. Determinar as permissões efetivas requer a realização de uma análise extensa do diagrama de Venn. Além disso, esse processo é contínuo, pois cada alteração de configuração do IAM afeta cada permissão de política sobreposta. Dado que uma pegada de nuvem corporativa típica tem centenas de ativos e principais de nuvem, as organizações geralmente lidam com milhares de regras de identidade e acesso. Coloque todos os diagramas de Venn juntos e o IAM da nuvem rapidamente se torna um inferno furioso de regras de política conflitantes, sobrepostas e em constante mudança.

As permissões efetivas por si só são insuficientes

Esse inferno de IAM na nuvem torna a determinação de permissões efetivas extremamente complicada. Mais importante, mesmo que a equipe de segurança descubra como reprimir o inferno e os músculos por meio da análise do diagrama de Venn, as permissões eficazes por si só são insuficientes para atender às metas do IAM. O motivo é que as permissões efetivas determinam se um ator (usuário ou aplicativo) deve ter acesso a um ativo de nuvem, não o impacto potencial ou o alcance desse acesso.

Dito de outra forma, as permissões eficazes são um conceito baseado em ameaças, enquanto uma determinação de raio de explosão é um conceito baseado em risco (ou seja, envolvendo a compreensão do impacto da ameaça). Especificamente, as permissões eficazes carecem de dois componentes principais necessários para lidar com o risco:

Contexto de risco – Determinar um raio de explosão ou LPA requer um conhecimento profundo das aplicações de uma organização. Embora as permissões efetivas definam o acesso aos ativos de nuvem da organização, elas não delineiam o acesso aos seus aplicativos de nuvem: os ativos não são equivalentes aos aplicativos. Os aplicativos consistem em dezenas ou mesmo centenas de ativos espalhados por vários serviços. Só porque um bucket S3 está acessível (ou seja, por meio das permissões efetivas), isso não significa que uma organização pode calcular o raio de explosão até que conheça o aplicativo que contém o bucket S3 e seu aplicativo de negócios específico.

Identidade verdadeira – o Cloud IAM requer um entendimento completo dos atores que acessam o aplicativo. Mesmo que provedores como AWS se federem com diretórios corporativos (por exemplo, Active Directory, LDAP, Okta, Ping), apenas um subconjunto de informações de identidade é transferido porque vem de um sistema externo.

Uma nova visão do Cloud IAM

Infelizmente, o contexto de risco e a verdadeira identidade não são recursos complementares. O alinhamento do contexto de risco, da identidade verdadeira e das permissões eficazes requer a remontagem da pilha de políticas IAM da nuvem de uma organização. As equipes devem primeiro desconstruir a pilha em seus elementos mais básicos (por exemplo, ativos, permissões, regras e contas). Em seguida, eles combinam esses elementos com a fonte de verdade do IAM empresarial (ou seja, Active Directory, LDAP ou armazenamentos de identidade de terceiros). Finalmente, eles devem corresponder aos aplicativos e seus respectivos recursos, metadados de negócios e contexto histórico de um banco de dados de gerenciamento de configuração (CMDB). O resultado mostra qual usuário / função está acessando um ativo de nuvem (ou seja, identidade verdadeira) e o impacto potencial desse acesso (ou seja, contexto de risco).

Aqui está uma ilustração de como isso funciona. O Módulo de governança de IAM da DivvyCloud desconstrói e reconstrói a pilha de políticas de IAM da nuvem criando uma visão de limite de IAM. A visão de limite do IAM consiste em três lentes que a equipe de operações, analistas, equipe de resposta a incidentes (IR) e auditores podem usar para analisar e simular seu ambiente de IAM em nuvem. Essas lentes são:

Diretores – os usuários federados, funções do IAM e usuários do IAM que definem a identidade e o acesso aos recursos da nuvem.

Aplicativos – Aplicativos críticos identificados pelo alinhamento de vários ativos de nuvem por meio de esquemas de marcação e nomenclatura.

Recursos – Os recursos subjacentes que suportam aplicativos que definem os relacionamentos entre todos os ativos de nuvem – por exemplo, descobrir quais diretores podem acessar um bucket S3 crítico ou tópico SNS. Isso é extremamente poderoso, especialmente quando considerado no contexto de identidades baseadas em recursos comprometidas ou “sequestradas”, uma causa emergente de violações de dados.

Usando essas lentes, as equipes podem identificar rapidamente todos os recursos aos quais um usuário federado tem acesso, porque e o que eles fizeram para obter acesso. Essa perspectiva dá à equipe o que ela precisa para eliminar todos os diferentes limites de permissão e estabelecer áreas críticas de risco e não conformidade. Por exemplo, o DivvyCloud IAM Governance Module fornece respostas imediatas às seguintes questões principais relevantes para estabelecer uma avaliação de linha de base no caso de um evento de IAM na nuvem:

Quais aplicativos e recursos estão vinculados a um principal? Em outras palavras, quais principais (usuários) têm acesso a um recurso ou grupo de recursos?
Quais aplicativos e principais estão vinculados a um recurso? Com base nessa análise, é fácil determinar quais funções têm permissões entre contas.
Quais princípios e recursos estão vinculados a um aplicativo? É possível determinar quem tem permissão de leitura (ou gravação) para acessar o aplicativo respondendo a esta pergunta.

Ciclo de vida do Cloud IAM

Seguir uma abordagem como os limites do IAM na nuvem configura uma organização para gerenciar e governar o IAM na nuvem. Dado o dinamismo da infraestrutura em nuvem e a necessidade de atualizações contínuas de permissões para gerenciar riscos, a implementação bem-sucedida de uma abordagem de limite de IAM em nuvem requer uma abordagem de ciclo de vida.

Etapa 1: avalie o risco

Compreender o risco é a base do IAM de nuvem bem-sucedido. As equipes podem usar o Módulo de Governança IAM da DivvyCloud, Filtros e Scorecard para avaliar as permissões efetivas. As equipes podem usar dados históricos para comparar os esforços atuais com as ações anteriores. Essa comparação ajuda a lidar com alertas de permissão falsos (ou seja, permissões não eficazes) e destacar atividades anômalas que podem representar riscos de política de IAM ou indicar áreas de não conformidade.

Etapa 2: priorizar e corrigir

Usando os recursos de simulação do Módulo de governança de IAM da DivvyCloud, as equipes podem realizar análises what-if para procurar problemas de IAM em nuvem em potencial de maneira proativa. A simulação é essencial para modelar o raio de explosão de uma possível exploração de IAM na nuvem e identificar permissões excessivas e não utilizadas que indicam permissão “inchada”.

Etapa 3: Cloud LPA

Depois de avaliar o risco, priorizar configurações incorretas de IAM na nuvem e corrigir o inchaço de permissão, as equipes podem estabelecer e gerenciar LPA definindo o privilégio mínimo possível para atingir as metas de risco da organização. LPA é um processo sem fim, que exige avaliação contínua dos níveis de privilégio em relação às funções e permissões organizacionais. As equipes podem usar a automação de bot do DivvyCloud para corrigir as permissões que são muito restritivas ou não suficientemente restritivas.

Etapa 4: automatizar para escalabilidade

Finalmente, para lidar com o crescimento contínuo de sua pegada na nuvem, as organizações devem implementar a correção automatizada de problemas comuns de IAM de alto risco, como comportamentos anômalos, aumento de permissão e provisionamento insuficiente ou excessivo de LPA. Esta automação é essencial para economizar tempo e melhorar continuamente a postura de risco da organização, enquanto acelera sua resposta às mudanças.

Criando clareza e contexto a partir do caos

No final das contas, a equipe de operações, analistas, equipe de RI e até mesmo as equipes de DevOps precisam responder a esta pergunta simples: qual é o risco associado ao acesso aos meus aplicativos e dados em nuvem por diferentes usuários e sistemas?

Ao se concentrar em ameaças e riscos, adotando uma abordagem como a visão de limite do IAM da nuvem e seguindo uma abordagem do ciclo de vida do IAM da nuvem, as equipes podem eliminar a complexidade dos controles IAM do provedor de nuvem atual. Essa abordagem fornece às equipes a clareza e o contexto de que precisam para responder a essa pergunta com segurança e facilidade. Com respostas precisas, as organizações podem determinar rapidamente o raio de explosão de um incidente de IAM e estabelecer e gerenciar LPA em escala.

O resultado é estabelecer a identidade como o novo perímetro de segurança na nuvem, identificando e reduzindo continuamente o risco de identidade na nuvem e, por fim, diminuindo a chance de violações e seus danos resultantes. Para obter mais informações, visite https://divvycloud.com/capabilities/iam-governance/.

Fonte: https://divvycloud.com/iam-whitepaper/

Palavras chaves: divvycloud, iam, nuvem, governança,