Como projetar uma estratégia de acessos humanos para ambientes multi-accounts

Por André Cavalcante, consultor de segurança sênior na AWS e Mariana Queiroz, consultora de segurança na nuvem AWS.

À medida que uma organização expande sua presença na AWS para dezenas ou centenas de contas, uma pergunta aparentemente simples passa a ser difícil de responder: quem pode acessar o quê, onde, por qual motivo e por quanto tempo? Sem uma estratégia definida, o acesso humano tende a crescer de forma orgânica. Usuários do AWS Identity and Access Management (IAM) com chaves de acesso de longa duração se acumulam em contas individuais, permissões amplas concedidas temporariamente se tornam permanentes e os registros de auditoria ficam espalhados, o que dificulta verificar se o acesso concedido corresponde ao acesso realmente necessário.

Nesta publicação, apresentamos um mecanismo para definir a estratégia e controlar como as pessoas (administradores, desenvolvedores, operadores e analistas de segurança) acessam um ambiente AWS multicontas usando o AWS IAM Identity Center. Mostramos os princípios que orientam as decisões, como escolher e aplicar os métodos de acesso permitidos, como organizar o acesso em padrões mapeados para pipelines de provisionamento automatizado, quais guardrails preventivos aplicar em camadas, como preparar um processo de break glass e como monitorar e auditar o resultado. O conteúdo é destinado a arquitetos, líderes de segurança e equipes de plataforma de nuvem responsáveis por definir como as pessoas se autenticam, quais permissões recebem e como essas permissões são aplicadas e monitoradas.

A estratégia prioriza três resultados: reduzir o acesso humano ao mínimo necessário, centralizar o gerenciamento de identidades e tornar cada evento de acesso rastreável e auditável. O resultado é uma postura de acesso minimizada por design, governada por automação e validada continuamente.

Quem são as identidades humanas

Identidades humanas (human identities) são as pessoas que precisam de uma identidade para acessar seus ambientes e aplicações na AWS: administradores, desenvolvedores, operadores e consumidores das suas aplicações. Quando fazem parte da sua organização, também são chamadas de identidades da força de trabalho (workforce identities). Em todos os casos, essas pessoas acessam a AWS por meio de um navegador ou de ferramentas interativas de linha de comando. Esta publicação trata de uma estratégia para esse tipo de identidade. Identidades de máquina (aplicações, pipelines e serviços) seguem práticas distintas e ficam fora do escopo.

Sete princípios que orientam a estratégia

Os princípios a seguir derivam do pilar de segurança do AWS Well-Architected Framework, do AWS Cloud Adoption Framework (AWS CAF) e das práticas recomendadas de segurança no IAM. Eles aparecem ao longo de toda a publicação para justificar cada decisão de projeto.

1. Implemente uma base de identidade forte. Centralize o gerenciamento de identidades por meio da federação com o IAM Identity Center e substitua credenciais de longa duração (usuários do IAM e chaves de acesso) por credenciais temporárias emitidas pelo AWS Security Token Service (AWS STS). Aplique privilégio mínimo (least privilege) e segregação de funções.
2. Elimine ou reduza o acesso humano. Esta é a abordagem preferencial. Use automação, pipelines de CI/CD e infraestrutura imutável para que as pessoas não precisem interagir diretamente com ambientes de produção. O melhor acesso humano é aquele que não precisa acontecer, como resume o princípio de design Keep people away from data (mantenha as pessoas longe dos dados) do pilar de segurança. Onde não for possível eliminar o acesso, minimize-o: conceda acesso somente leitura ou somente visualização por padrão.
3. Audite o acesso humano. Quando o acesso ocorrer, torne-o totalmente rastreável. Monitore, alerte e audite as ações em tempo real, registre toda a atividade da sessão e faça com que cada acesso seja visível para pelo menos uma outra pessoa (visibilidade compartilhada entre mais de uma pessoa).
4. Use acesso elevado temporário (just-in-time). Para os casos em que o acesso elevado é realmente necessário, conceda permissões apenas por uma duração e finalidade específicas, mediante solicitação e aprovação explícitas, com revogação automática.
5. Aplique segurança em todas as camadas. Combine controles em cada camada do ambiente: Service Control Policies (SCPs) e Resource Control Policies (RCPs) no nível da organização; permission sets, permissions boundaries e políticas de VPC endpoint no nível da conta; security groups e network ACLs no nível de rede. Nenhuma camada isolada deve ser a única barreira contra o acesso não autorizado. Se um controle falhar, a próxima camada ajuda a detectar o problema.
6. Automatize as práticas de segurança. Substitua ações manuais por automação sempre que possível. Defina a segurança como código para que as mudanças sejam revisadas, versionadas e repetíveis. Automatize o provisionamento e o desprovisionamento de acesso por meio do gerenciamento do ciclo de vida das identidades. Menos interação humana significa menor superfície de exposição e menos espaço para erro humano.
7. Prepare-se para eventos de segurança. Planeje considerando que o acesso humano pode ser usado de forma indevida, intencionalmente ou por engano. Mantenha runbooks documentados para revogar credenciais comprometidas, investigar acessos não autorizados e responder a escalonamento de privilégios. Execute simulações que testem a capacidade da equipe de detectar e conter incidentes envolvendo atores humanos, e registre toda a atividade humana para permitir investigação forense e análise de causa raiz.

Defina os métodos de acesso permitidos

Um passo fundamental de qualquer estratégia de acesso humano é decidir quais métodos de acesso às contas da AWS são permitidos e, em seguida, aplicar controles para bloquear todos os demais. Com os métodos aprovados definidos, você pode usar guardrails preventivos (como SCPs e RCPs) para fechar os caminhos de acesso não governados.

A tabela a seguir resume os principais métodos de acesso humano a contas da AWS.

A AWS recomenda que todas as identidades humanas acessem a AWS por meio de federação com um provedor de identidade, usando credenciais temporárias. Isso ajuda a reduzir a sobrecarga operacional e o risco de gerenciar usuários do IAM individuais em cada conta.

Arquitetura de acesso com o IAM Identity Center

O desafio do acesso em várias contas

Os dois primeiros métodos de acesso da seção anterior foram projetados para o acesso a uma única conta. Em um ambiente multicontas, configurar e gerenciar a federação conta por conta cria desafios operacionais: a sobrecarga administrativa de manter uma configuração de federação por conta, políticas de acesso que divergem entre as contas ao longo do tempo, visibilidade limitada dos padrões de acesso em toda a organização, um ciclo de vida de usuário complexo (toda mudança precisa ser replicada em cada conta) e logs de auditoria distribuídos, que dificultam a verificação de conformidade.

Componentes da arquitetura

O IAM Identity Center fornece gerenciamento de acesso centralizado para várias contas da AWS e aplicações. Ele funciona como ponto único de controle para as contas da AWS em toda a estrutura do seu AWS Organizations, para aplicações gerenciadas da AWS e para aplicações de nuvem de terceiros habilitadas para SAML. A arquitetura usa três componentes:

• Fonte de identidade. Você escolhe uma: o diretório do próprio IAM Identity Center (um repositório de usuários integrado), o Microsoft Active Directory (por meio do AWS Directory Service for Microsoft Active Directory ou do AD Connector para um AD on-premises) ou um IdP externo via SAML 2.0 (Okta, Microsoft Entra ID ou outros).
• Permission sets (conjuntos de permissões). Coleções de políticas que definem níveis de acesso. Cada permission set pode incluir políticas gerenciadas pela AWS, políticas gerenciadas pelo cliente (referências a políticas do IAM existentes nas contas-membro), políticas em linha e, opcionalmente, um permissions boundary. Os permission sets são provisionados como roles do IAM nas contas de destino, com relações de confiança para o IAM Identity Center.
• Atribuições de conta (account assignments). Mapeiam identidades para contas com permission sets específicos: identidade (usuário ou grupo) → conta da AWS → permission set. A mesma identidade pode ter várias atribuições em contas diferentes, com permission sets diferentes.

Modelo de administrador delegado

Registre uma conta-membro dedicada como administradora delegada do IAM Identity Center em vez de operar o serviço a partir da conta de gerenciamento. Você pode usar a conta de segurança criada pelo AWS Control Tower ou criar uma conta específica para esse fim (por exemplo, uma conta Identity). Essa abordagem traz três benefícios:

• Separação de responsabilidades: as operações de gerenciamento de identidade ficam isoladas das funções de gerenciamento da organização.
• Menor exposição da conta de gerenciamento: menos pessoas precisam de acesso à conta de gerenciamento.
• Permission sets especializados: permite criar permission sets específicos para a conta de gerenciamento sem conceder acesso amplo.

Observe que, ao delegar a administração do IAM Identity Center a outra conta, algumas tarefas continuam restritas à conta de gerenciamento. Consulte a documentação de administração delegada para a lista de limitações.

Proteja o usuário root

O usuário root é o usuário inicial de cada conta da AWS e o método mais privilegiado de acesso. Ele deve ser usado apenas para as tarefas que exigem privilégios de root, e sua estratégia de acesso humano deve identificar e documentar esses casos de uso. Use a lista de tarefas que exigem credenciais do usuário root como referência.

Centralize o acesso root das contas-membro

Quando você usa o AWS Organizations, cada conta-membro tem seu próprio usuário root, com permissão para executar qualquer ação naquela conta. Recomendamos centralizar o gerenciamento do acesso root por meio do AWS Organizations para ajudar a impedir a recuperação de credenciais e o acesso do usuário root em escala. Depois de centralizar o acesso root, você pode remover as credenciais de root das contas-membro existentes. Novas contas criadas no AWS Organizations já nascem sem credenciais de root, e as contas-membro deixam de poder fazer login como root ou recuperar a senha do root.

Seguindo o princípio “Aplique segurança em todas as camadas”, adicione também uma SCP que negue as ações do usuário root nas contas-membro. Com isso, apenas o acesso root da conta de gerenciamento precisa ser gerenciado diretamente.

Proteja o acesso root da conta de gerenciamento

Estabeleça um processo documentado para acessar e proteger as credenciais root da conta de gerenciamento, seguindo as práticas recomendadas para o usuário root: habilite autenticação multifator (MFA) e, preferencialmente, com um dispositivo de hardware. Não crie chaves de acesso para o root e use uma senha forte. O processo deve descrever como cada fator (e-mail, senha, dispositivo MFA e número de telefone) é protegido e quem tem acesso a cada um.

Nenhuma pessoa deve ter acesso simultâneo à caixa de e-mail e ao número de telefone associados à conta, porque ambos são canais de verificação para recuperar a senha do root. Mantenha dois grupos distintos: um com acesso ao endereço de e-mail principal e outro com acesso ao número de telefone principal usado na recuperação de acesso.

Estabeleça os pré-requisitos: ambiente multicontas e infraestrutura como código

Antes de definir padrões de acesso e casos de uso, dois elementos precisam estar em vigor: uma estratégia multicontas, que fornece os limites estruturais para o controle de acesso, e práticas de infraestrutura como código (IaC), que reduzem a necessidade de acesso humano direto à produção.

Estratégia multicontas

Uma estratégia multicontas resolve vários desafios que surgem conforme a organização escala na AWS:

• Isolamento de segurança: equipes, workloads e ambientes (desenvolvimento, homologação e produção) exigem limites de segurança distintos. Uma conta separada fornece um limite rígido de isolamento que reduz o impacto de incidentes, configurações incorretas e acessos não autorizados.
• Separação de conformidade: workloads sujeitos a requisitos regulatórios diferentes (por exemplo, PCI DSS ou workloads que utilizem serviços elegíveis a HIPAA) podem ficar em contas dedicadas, com controles próprios, reduzindo o escopo de auditoria.
• Visibilidade de custos: cada conta é um limite natural de custo. Mapear contas para unidades de negócio, projetos ou equipes fornece atribuição clara dos gastos sem depender apenas de tags.
• Gerenciamento de cotas de serviço: as cotas são aplicadas por conta. Separar workloads evita que o consumo de uma equipe cause throttling em outra e dá a cada equipe visibilidade direta dos próprios limites.

A estratégia de acesso humano é construída sobre essa estrutura. A forma como as contas são organizadas determina como os permission sets são atribuídos, quais roles existem em cada conta, quais limites são aplicados por SCPs e RCPs e como o acesso é auditado. Sem essa base, falta aos controles de acesso a estrutura necessária para aplicar privilégio mínimo, segregação de funções e isolamento de ambientes em escala. Para orientações sobre como estruturar as contas, consulte o whitepaper Organizing your AWS environment using multiple accounts.

Infraestrutura como código e seu impacto no acesso humano

IaC é a prática de definir, provisionar e gerenciar a infraestrutura por meio de arquivos de configuração legíveis por máquina, em vez de processos manuais. Seus benefícios operacionais são conhecidos: reprodutibilidade entre contas, Regiões da AWS e estágios; menos erro humano, porque as mudanças são declarativas e aplicadas por automação; controle de versão e auditabilidade de cada mudança; e revisão por pares antes que qualquer alteração chegue à produção.

O impacto no acesso humano é igualmente significativo e frequentemente subestimado. Quando a infraestrutura é provisionada e modificada exclusivamente por pipelines de CI/CD, as pessoas deixam de precisar de acesso de escrita às contas de produção para operações rotineiras. O pipeline passa a ser o único ator com permissões de escrita, e o envolvimento humano se desloca da execução direta para a autoria e a revisão de código.

Ao transferir a execução das mudanças das pessoas para o pipeline, o IaC reduz o número de equipes que precisam de acesso de escrita à produção, encurta a duração do acesso elevado que ainda for necessário e move o ponto de controle do tempo de execução (quem pode acessar o console) para o tempo de desenvolvimento (quem pode fazer merge). Em ambientes com práticas maduras de IaC, o acesso padrão da maioria das equipes à produção passa de permission sets com capacidade de escrita para somente visualização. O acesso de escrita à produção torna-se uma exceção, tratada pelo mecanismo de acesso elevado temporário e reservada aos cenários em que o pipeline não consegue resolver o problema.

Trate a maturidade de IaC como uma alavanca para restringir progressivamente o acesso humano: conforme mais infraestrutura é codificada e implantada por pipelines, a justificativa para acesso de escrita persistente diminui, e a matriz de acesso deve ser atualizada para refletir essa redução. Esse é o princípio “Elimine ou reduza o acesso humano” em ação.

Mapeie casos de uso e padrões de acesso

Casos de uso por equipe

Antes de definir permissões, identifique e documente os casos de uso que realmente exigem acesso humano. Nem todo acesso é igual: cada caso de uso tem um perfil de risco diferente, exige níveis de privilégio diferentes e pode requerer métodos de acesso diferentes (console, CLI ou ambos). A tabela a seguir mostra casos de uso comuns.

Esses casos variam conforme os processos, as tecnologias e a estrutura de cada organização. O ponto central é que todo caso de uso seja explicitamente mapeado e alinhado ao privilégio mínimo. Para cada um, documente quem precisa de acesso (persona ou equipe), o que precisa fazer (ações e serviços), onde (contas e ambientes), quando (somente leitura persistente ou acesso elevado just-in-time) e como (console, CLI ou ambos). Esse mapeamento é a base para projetar permission sets, políticas de acesso e guardrails.

Três padrões de acesso

Agrupar o acesso humano em padrões ajuda a visualizar quem precisa de acesso, onde e sob quais condições, e orienta a escolha de ferramentas, automação e governança para cada tipo.

Os três padrões não são mutuamente exclusivos. Uma mesma equipe pode ter acesso horizontal somente leitura em todas as contas (linha de base), acesso vertical às contas do seu produto (operação do dia a dia) e acesso elevado temporário para cenários excepcionais. A estratégia deve definir quais padrões se aplicam a cada equipe e sob quais condições.

Para o padrão de acesso elevado temporário, a AWS disponibiliza a solução de exemplo Temporary Elevated Access Management (TEAM), de código aberto no AWS Samples, que se integra ao IAM Identity Center e oferece solicitações com prazo definido, fluxos de aprovação e revogação automática. Você também pode avaliar soluções de parceiros da AWS para gerenciamento de acesso privilegiado, que podem complementar ou estender a abordagem nativa com recursos como gravação de sessão e cofre de credenciais. A escolha depende do seu ecossistema de ferramentas de segurança, dos requisitos de conformidade e da maturidade operacional.

Agrupamento de contas

Os padrões de acesso são aplicados sobre a estrutura de contas, e a forma de agrupá-las influencia diretamente como o acesso é restrito e governado. Um modelo comum é o seguinte.

Cada grupo tem requisitos de acesso diferentes. As contas core exigem os controles mais restritivos (poucas personas, fluxos de aprovação fortes, trilhas de auditoria completas). As contas de desenvolvimento podem permitir acesso mais amplo para experimentação. As contas de produção ficam no meio: somente visualização por padrão, com acesso elevado temporário para exceções operacionais. Cruzar padrões de acesso com grupos de contas produz uma matriz que se torna o blueprint para o projeto dos permission sets, para a aplicação de SCPs e RCPs e para a estratégia de automação.

Projete os permission sets e a matriz de acesso

Os privilégios que cada equipe recebe em cada conta variam conforme a estrutura, o modelo operacional e a cultura da organização. Projetar permissões de privilégio mínimo não é um exercício único: é um processo contínuo que evolui com as equipes, os workloads e os requisitos.

Os três elementos do acesso humano

No IAM Identity Center, o acesso humano é definido pela interseção de três elementos.

Uma única atribuição conecta uma identidade a um permission set em uma ou mais contas. A combinação de todas as atribuições da organização forma a matriz de acesso humano.

A matriz de acesso humano

A matriz mapeia identidades para permission sets por grupo de contas e fornece uma visão única de quem pode fazer o quê, e onde. O exemplo a seguir ilustra uma matriz possível.

As células marcadas com “—” indicam que não há acesso persistente. Para qualquer cenário não coberto pela matriz, as equipes solicitam acesso elevado temporário por meio de um mecanismo just-in-time, como o TEAM.

A matriz revela decisões de projeto deliberadas:

• Developers têm acesso progressivamente restrito ao avançar de desenvolvimento (DevAccess) para homologação (ReadOnly) e produção (ViewOnly). Eles escrevem e testam livremente em desenvolvimento, verificam o comportamento em homologação sem modificá-lo e observam a produção sem acessar dados. Se uma exceção operacional exigir acesso elevado, eles o solicitam pelo mecanismo just-in-time.
• Incident Response tem acesso horizontal a todas as contas porque sua responsabilidade abrange toda a organização. O permission set IRAccess é construído para investigação e contenção, não para administração geral.
• Cloud Security tem acesso amplo na conta de segurança, mas nenhum acesso de escrita persistente às demais contas (exceto auditoria de segurança). O acesso elevado para remediação é concedido via just-in-time quando necessário.

Dois tipos de permission sets

Cada permission set combina políticas em linha, políticas gerenciadas pela AWS e um permissions boundary. Projetá-los exige entender quais ações cada equipe precisa executar, em quais serviços e sob quais condições. O processo é iterativo: comece com permissões mais amplas, use o IAM Access Analyzer para identificar permissões não utilizadas e refine continuamente em direção ao privilégio mínimo.

Nenhuma matriz cobre todos os cenários. Manutenções planejadas, escalonamento de incidentes e tarefas operacionais pontuais exigirão acesso além do definido. Trate essas exceções exclusivamente pelo mecanismo de acesso elevado temporário, para que cada exceção seja solicitada, justificada, aprovada, limitada no tempo, registrada e revogada automaticamente.

ViewOnlyAccess, ReadOnlyAccess e PowerUserAccess não são intercambiáveis

As políticas gerenciadas pela AWS para funções de trabalho são um bom ponto de partida, mas seus nomes podem enganar. Revise o que cada política concede antes de atribuí-la a uma equipe. Um equívoco comum é tratar ReadOnlyAccess e ViewOnlyAccess como equivalentes.

A distinção importa. Atribuir ReadOnlyAccess a uma equipe em uma conta de produção significa que ela pode ler dados de clientes, segredos de aplicação armazenados em serviços como o AWS Secrets Manager e objetos em buckets do Amazon Simple Storage Service (Amazon S3). Se a intenção é permitir que a equipe observe a infraestrutura sem acessar dados sensíveis, ViewOnlyAccess é a escolha apropriada. Como regra geral, comece com a política gerenciada mais restritiva que atenda à equipe e adicione permissões em camadas, por meio de políticas em linha, apenas onde um requisito operacional específico justificar.

Automatize o acesso como código

A seção sobre IaC mostrou que codificar a infraestrutura reduz a necessidade de acesso humano de escrita à produção. O mesmo princípio se aplica à própria estratégia de acesso: permission sets, atribuições, guardrails e ciclo de vida das identidades devem ser definidos, versionados e implantados como código.

Quando os controles de acesso são gerenciados manualmente, pelo console ou por comandos ad hoc, surgem desvios de configuração entre contas, mudanças não documentadas que escapam da revisão, atrasos de provisionamento que pressionam as equipes a conceder acesso amplo como atalho e dificuldade para reproduzir ou auditar o estado atual. Segurança como código aplica à camada de acesso as mesmas práticas usadas para o código de aplicação e de infraestrutura: controle de versão, revisão por pares, testes automatizados e implantação por pipeline.

Os componentes que se beneficiam de ser gerenciados como código incluem:

• Permission sets: políticas em linha, políticas gerenciadas anexadas, permissions boundaries e duração da sessão.
• Atribuições de conta: os mapeamentos de grupos para permission sets em contas específicas, que implementam a matriz de acesso.
• SCPs e RCPs: os guardrails preventivos descritos na próxima seção.
• Configuração do acesso elevado temporário: fluxos de aprovação, permission sets elegíveis, durações máximas de sessão e regras de notificação.
• Funções de break glass: políticas de confiança, políticas de permissão e requisitos de MFA das funções de emergência.

Cada padrão de acesso pede uma abordagem de automação diferente.

Acesso horizontal: pipeline de permission sets do IAM Identity Center

O acesso horizontal se aplica de forma consistente a muitas ou todas as contas da organização. Sua característica definidora é que a definição de acesso é estável (o mesmo permission set, para o mesmo grupo, em um conjunto amplo de contas), mas o conjunto de contas de destino muda conforme a organização cresce.

O guia Manage AWS IAM Identity Center permission sets as code by using AWS CodePipeline, do AWS Prescriptive Guidance, resolve isso diretamente. Ele implanta um pipeline de CI/CD com AWS CodeBuild e AWS CodePipeline na conta de administrador delegado do IAM Identity Center. Os permission sets e as atribuições são definidos em templates JSON armazenados em um repositório de código, e o fluxo funciona assim:

1. Os templates de permission set definem as políticas, a duração da sessão e o relay state de cada permission set, com um arquivo JSON por conjunto.
2. Os templates de atribuição mapeiam principals do IAM Identity Center (usuários ou grupos) para permission sets em contas, OUs ou na raiz da organização. Quando o destino é a raiz, o permission set é atribuído a todas as contas-membro, exceto a conta de gerenciamento. Um padrão curinga permite a atribuição recursiva a OUs aninhadas.
3. Quando alguém faz commit no repositório, o pipeline inicia automaticamente, valida os templates (nomes únicos, sintaxe de política verificada com o IAM Access Analyzer e ARNs de políticas gerenciadas válidos) e implanta os permission sets e as atribuições.
4. Quando uma regra do Amazon EventBridge detecta que uma conta foi criada em uma OU ou movida para ela no AWS Organizations, uma função do AWS Lambda na conta de gerenciamento dispara o mesmo pipeline, que reavalia os templates de atribuição e aplica os permission sets definidos à nova conta.

Esse comportamento orientado a eventos é o que torna o pipeline eficaz para o acesso horizontal. Quando o template aponta para uma OU ou para a raiz, toda nova conta nesse escopo recebe os permission sets corretos sem intervenção manual. O acesso de auditoria da equipe de SOC, o IRAccess da equipe de resposta a incidentes e qualquer outro padrão horizontal da matriz passam a valer assim que a conta entra na organização, fechando a lacuna entre a criação da conta e o provisionamento do acesso.

Acesso vertical: customizações de provisionamento do Account Factory for Terraform

O acesso vertical está vinculado à identidade da conta (a que produto pertence, qual equipe é a dona, qual ambiente representa), e não a um escopo organizacional amplo. O Account Factory for Terraform (AFT) fornece o mecanismo de automação por meio do seu framework de customizações de provisionamento:

• A solicitação de conta (account request) define os metadados da conta, como tags, posicionamento na OU, produto e ambiente. Esses metadados podem ser registrados com custom_fields no arquivo Terraform da solicitação.
• Depois que a conta é provisionada e posicionada na OU correta, o pipeline do AFT executa o estágio de account provisioning framework, que chama uma máquina de estado do AWS Step Functions definida por você. É nesse ponto que a lógica de provisionamento de identidade entra: por exemplo, uma função do Lambda que cria os grupos apropriados no IdP para a equipe dona da nova conta e os associa à conta no IAM Identity Center com base nos metadados.

Na prática, quando uma nova conta de produto é criada pelo AFT, o pipeline cria ou referencia os grupos da equipe dona (por exemplo, ProductA-Developers e ProductA-Operations) e atribui a eles os permission sets apropriados na nova conta (DevAccess na conta de desenvolvimento, ViewOnly na de produção), seguindo a matriz de acesso. A postura de acesso da conta fica definida antes do primeiro login humano e é consistente com todas as outras contas. Conforme o portfólio da equipe cresce (uma nova conta de homologação, uma conta de dados dedicada), cada conta herda o padrão vertical correto pela mesma customização, sem mudanças no pipeline de permission sets e sem intervenção da equipe de identidade.

Combinando as duas automações

Os dois pipelines operam em paralelo e se complementam. O pipeline de permission sets gerencia a camada horizontal (permission sets e atribuições que abrangem OUs ou a organização inteira) e reage a mudanças organizacionais, como contas movidas entre OUs. As customizações do AFT gerenciam a camada vertical (permission sets e atribuições restritos a contas específicas, com base em dono, produto e ambiente) e reagem a eventos de criação de conta.

Juntos, eles preenchem automaticamente cada célula da matriz de acesso: os padrões horizontais preenchem as linhas que atravessam todas as colunas de contas, e os padrões verticais preenchem as colunas de cada produto ou workload. O resultado é uma postura de acesso codificada, provisionada automaticamente e aplicada de forma contínua, com muito menos solicitações manuais, atrasos de provisionamento e desvios de configuração. Esse é o princípio “Automatize as práticas de segurança” aplicado à camada de acesso.

Aplique guardrails em camadas

Guardrails são controles preventivos e detectivos que aplicam os limites da estratégia de acesso no nível da organização. Eles operam independentemente dos permission sets individuais e valem uniformemente para todas as contas. Assim, mesmo que um permission set seja configurado incorretamente ou uma exceção seja concedida, outra camada ajuda a manter a postura de segurança da organização. Use o tipo de política adequado para cada objetivo de controle.

Recomendamos os guardrails a seguir como parte da estratégia de acesso humano, organizados por objetivo de controle.

Todos os guardrails devem ser definidos como código (AWS CloudFormation, Terraform ou AWS Cloud Development Kit (AWS CDK)), armazenados em controle de versão e implantados por um pipeline de CI/CD, de forma consistente com os princípios de IaC desta estratégia. Teste cada política em uma OU de testes antes de aplicá-la amplamente: políticas baseadas em negação podem bloquear o uso de serviços se as exceções necessárias não forem incluídas. Para um exemplo de automação, consulte o padrão Manage AWS Organizations policies as code.

Prepare o acesso de break glass

Toda estratégia de acesso humano precisa de um mecanismo de break glass. O termo vem do ato de quebrar o vidro para acionar um alarme de incêndio e designa um meio rápido para que uma pessoa sem privilégios de acesso a determinadas contas os obtenha, em circunstâncias excepcionais, por um processo aprovado. Break glass não substitui o acesso do dia a dia: é um mecanismo de último recurso para cenários em que a cadeia primária de acesso está rompida e uma ação sensível ao tempo é necessária. Por isso, seu uso precisa ser monitorado e disparar alarmes e alertas imediatamente. Esta seção implementa o princípio “Prepare-se para eventos de segurança”.

Quando o break glass é necessário

Em operação normal, as pessoas se autenticam no IdP corporativo e acessam as contas pelo IAM Identity Center. O break glass é necessário quando um ou mais componentes dessa cadeia estão indisponíveis ou comprometidos.

Caminho de escalonamento

Quando um incidente exige acesso de emergência a uma conta, siga a ordem a seguir, avançando para o próximo nível somente quando o anterior estiver indisponível. A Figura 1 ilustra esse caminho.

Figura 1: Árvore de decisão do acesso de break glass, ilustrando o caminho de escalonamento quando o acesso normal está indisponível

1. Acesso pelo IAM Identity Center. Um usuário que já tenha um permission set administrativo na conta afetada executa a remediação pelo caminho normal. Esta opção deve sempre ser tentada primeiro.
2. Federação SAML direta com o IdP. Se esse usuário não estiver disponível ou o próprio IAM Identity Center tiver falhado, mas o IdP continuar operacional e confiável, grupos pré-configurados no IdP fornecem acesso federado ao conjunto apropriado de contas por meio de federação SAML 2.0 direta com funções do IAM nas contas de destino, sem passar pelo IAM Identity Center. Cada grupo é restrito a um conjunto específico de contas e permissões, mantendo o privilégio mínimo mesmo na emergência. Uma pessoa pode ser adicionada a um desses grupos por um change request temporário de alta prioridade, ou um grupo seleto de usuários privilegiados e confiáveis pode ser pré-populado. Para a implementação, consulte Set up emergency access to the AWS Management Console.
3. Usuários de break glass do IAM na conta de gerenciamento. Se o IdP estiver indisponível ou comprometido, usuários do IAM de break glass pré-provisionados na conta de gerenciamento assumem funções de break glass implantadas em todas as contas-membro. Essas funções existem independentemente da federação e do IAM Identity Center. Crie pelo menos dois usuários de break glass para evitar um bloqueio acidental e proteja as credenciais com um processo de conhecimento dividido: uma pessoa confiável tem acesso à senha e outra, ao dispositivo MFA de hardware. As funções de break glass nas contas-membro devem ser configuradas para contornar controles como SCPs quando isso for necessário para a remediação de emergência. Para orientações adicionais, consulte Break glass access no whitepaper Organizing your AWS environment.

Independentemente do caminho usado, todo acesso de break glass deve ser registrado pelo CloudTrail e disparar alertas imediatos para a equipe de SOC e para a gestão. Implante e teste essa configuração antes de precisar dela: não é possível criar as funções necessárias se o acesso para criá-las também estiver indisponível.

Monitore e audite o acesso

Guardrails ajudam a impedir o acesso não autorizado. A automação aplica controles consistentes. Monitoramento e auditoria fecham o ciclo, fornecendo visibilidade contínua sobre como o acesso humano está sendo usado de fato, se ele está alinhado à matriz pretendida e onde os desvios exigem investigação ou remediação. O monitoramento responde à pergunta “o que está acontecendo agora?”. A auditoria responde a “o que aconteceu, e estava autorizado?”. Juntos, eles cumprem o princípio “Audite o acesso humano”.

Registro centralizado

Toda atividade de acesso humano deve fluir para um repositório de logs centralizado e com proteção contra adulteração. A base é uma trilha do AWS CloudTrail no nível da organização, que captura os eventos de gerenciamento de todas as contas e os entrega à conta de arquivamento de logs. Configure a trilha com as propriedades a seguir.

Se você usa o AWS Control Tower, a trilha da organização e a conta de arquivamento de logs provavelmente já estão configuradas. Os logs do CloudTrail são o fluxo bruto de eventos. Para torná-los acionáveis, integre-os a mecanismos de detecção e alerta.

Detecção e alerta em tempo real

Os eventos a seguir são exemplos que podem gerar alertas em tempo real quando envolverem identidades humanas. Cada um mapeia para um cenário de risco relevante para a estratégia de acesso humano.

Entregue os alertas pelo sistema de gerenciamento de incidentes da organização (por exemplo, uma ferramenta de plantão ou um tópico do Amazon Simple Notification Service (Amazon SNS) integrado a um canal de chat dedicado), com níveis de severidade alinhados ao cenário de risco. A atividade do root e a assunção de função de break glass devem ser tratadas como alertas de alta severidade, com reconhecimento imediato.

Detecção de anomalias

Além do alerta baseado em regras, implemente detecção comportamental para identificar padrões de acesso tecnicamente autorizados, mas operacionalmente incomuns.

Painéis por público

Apresente os dados de monitoramento e auditoria em painéis com visões distintas para cada público.

Painéis do Amazon CloudWatch, o Amazon QuickSight ou a integração com uma plataforma SIEM centralizada (por exemplo, o Amazon Security Lake alimentando um SIEM) podem servir como camada de visualização, dependendo das ferramentas já existentes na organização.

Conclusão

Uma estratégia de acesso humano bem projetada é uma disciplina contínua, que evolui junto com o ambiente de nuvem, contexto do negócio, estrutura das equipes e o cenário regulatório da organização. Nesta publicação, mostramos um caminho estruturado do projeto à implementação: centralizar a identidade por meio de federação, reduzir o uso de credenciais de longa duração, codificar os controles de acesso, automatizar o provisionamento para cada padrão de acesso, aplicar guardrails preventivos em camadas e manter visibilidade contínua com monitoramento e auditoria. Implementados em conjunto, esses componentes criam uma postura de acesso que reduz o risco operacional, diminui a superfície de exposição e escala com a organização, sem sacrificar a agilidade de que as equipes precisam para entregar.

Para começar, recomendamos uma abordagem em fases, em que cada fase se apoia na anterior e permite restringir os controles progressivamente conforme a maturidade operacional aumenta:

1. Fundação: habilite o gerenciamento centralizado do acesso root, configure o IAM Identity Center com um IdP externo e estabeleça o mecanismo de break glass.
2. Projeto do acesso: defina a matriz de acesso humano, projete os permission sets e implante-os por meio de um pipeline de CI/CD.
3. Reforço: aplique guardrails preventivos (SCPs e RCPs) em camadas, implemente monitoramento e alertas e estabeleça auditorias periódicas de acesso.

Implementar essa estratégia envolve gerenciamento de identidades, arquitetura multicontas, projeto de políticas de segurança, pipelines de automação e gestão de mudança organizacional. Se precisar de apoio, o AWS Professional Services e os parceiros da AWS têm experiência prática no projeto e na implantação de estratégias de acesso humano adaptadas ao ambiente, aos requisitos de conformidade e à maturidade de cada organização. Para aprofundar o tema, consulte também a AWS Security Reference Architecture (AWS SRA).

Sobre os autores

	André Cavalcante é consultor de segurança sênior com mais de 15 anos de experiência em segurança da informação. Atua em gestão de identidade e acessos, resposta a incidentes, testes de intrusão, modelagem de ameaças e revisão e implementação de arquiteturas seguras. No Professional Services, ajuda clientes a aprimorar sua maturidade em segurança.
	Mariana Queiroz é consultora de segurança na nuvem AWS, com especialidade em gestão de identidade e acessos (IAM), tema central de boa parte dos projetos em que atua. Trabalha também com modelagem de ameaças, arquiteturas seguras e segurança de dados. No Professional Services, apoia clientes na evolução de sua maturidade em segurança na nuvem.