c7.2 Centralizar o acesso com o IAM Identity Center e permissões por função
Gerenciar o acesso por meio de um sistema de controle de acesso centralizado que cubra todos os componentes do sistema, com negação por padrão, salvo autorização explícita.
Requisito 7
Restringir o Acesso aos Componentes do Sistema e aos Dados do Portador do Cartão pela Necessidade de Conhecimento do Negócio
Sub-requisitos PCI cobertosCobertura mostrada por sub-controle do PCI DSS v4.0.1. “Coberto” = atendido por esta recomendação da AWS. “No roadmap” = técnico, planejado. “Sua responsabilidade” = controle organizacional/de processo. “Fora do escopo” = controle físico ou de terceiros não implementado na AWS.
7.2 O acesso aos componentes do sistema e aos dados é definido e atribuído adequadamente
- 7.2.1 Access control model defined for need-to-know/least-privilege Coberto
- 7.2.2 Access assigned based on job classification and least privilege Coberto
- 7.2.3 Required privileges approved by authorized personnel Sua responsabilidade
- 7.2.4 User accounts and access reviewed at least every 6 months Sua responsabilidade
- 7.2.5 Application/system accounts and access managed by least privilege Coberto
- 7.2.5.1 Access by app/system accounts reviewed periodically Sua responsabilidade
- 7.2.6 Query access to stored CHD restricted via roles/applications Coberto
7.3 O acesso é gerenciado por meio de um sistema de controle de acesso
- 7.3.1 Access control system(s) in place covering all components Coberto
- 7.3.2 Access control system configured to enforce least privilege Coberto
- 7.3.3 Access control system set to 'deny all' by default Coberto
Como implementar na AWS
Adotar o AWS IAM Identity Center com permission sets por função de trabalho, federado com o IdP corporativo. Impor um modelo de negação por padrão reforçado com SCPs no AWS Organizations. Definir data perimeters para limitar o acesso aos recursos do CDE.
Implementação prática
Como este controle é implementado em cada arquitetura de referência:
Em uma única conta, construa acesso baseado em papéis e negação por padrão com papéis IAM nativos por função de trabalho (sem usuários permanentes), e evolua para o IAM Identity Center para federação à medida que cresce.
- Defina papéis IAM por função de trabalho e faça as pessoas assumi-los (via federação ou sessões de curta duração) em vez de usuários IAM permanentes; conceda apenas as ações/recursos específicos de que cada função precisa (negação por padrão).Acesso à conta
IAM - Aplique perímetros de dados (políticas de recursos / condições IAM) para que os recursos do CDE sejam alcançáveis apenas a partir de identidades confiáveis.Camada de dados (CDE) IAM
- Evolução: quando precisar de acesso atribuído de forma central e federado ao IdP por meio de permission sets, adote o IAM Identity Center. Observe que o acesso com permission sets a contas AWS requer uma organization instance, que adota o AWS Organizations (uma account instance standalone cobre apenas acesso a aplicações, não permission sets de conta).Acesso à conta (à medida que escala)
IAM Identity Center
Como validar: O acesso é atribuído por papéis IAM por função de trabalho (sem usuários permanentes com admin inline), o privilégio mínimo é aplicado, e uma solicitação de uma ação fora do papel concedido é negada por padrão.
Evite: Entregar às pessoas usuários IAM permanentes com políticas inline amplas. Defina papéis por função de trabalho, conceda privilégio mínimo e negue por padrão.
Aqui é onde o multi-conta brilha: atribua permission sets em todas as contas de um único lugar, imponha a negação por padrão com SCPs e restrinja os dados do CDE a identidades/redes confiáveis.
- Use o IAM Identity Center para atribuir permission sets em todas as contas de um único lugar, federado ao IdP.Conta de identidade/segurança → OU de PCI IAM Identity Center
AWS Organizations - Imponha guarda-corpos de negação por padrão com SCPs na OU de PCI para que nenhuma conta possa exceder suas ações permitidas.OU de PCI (guarda-corpo) AWS Organizations
- Defina perímetros de dados para que os dados do CDE sejam alcançáveis apenas a partir de identidades e redes confiáveis (bloqueando principals/VPCs não confiáveis).Cada conta de carga do CDE IAM
Como validar: O Identity Center cobre todas as contas, um teste de SCP bloqueia uma ação fora de escopo em uma conta do CDE, e o perímetro de dados rejeita um principal não confiável.
Evite: Federar cada conta separadamente. Centralize no Identity Center para que o acesso, o MFA e a negação por padrão sejam uniformes em toda a organização.
Validação PCI
Procedimentos de teste
- Examinar a documentação do fornecedor e os ajustes do sistema para verificar que o sistema de controle de acesso gerencia o acesso de cada componente conforme a necessidade de conhecimento e cobre todos os componentes (7.3.1).
- Verificar que o sistema de controle de acesso aplica as permissões conforme a classificação e a função de trabalho (7.3.2).
- Verificar que o sistema de controle de acesso está configurado como 'negar tudo' por padrão (7.3.3).
Evidência na AWS
- Permission sets do IAM Identity Center mapeados para funções de trabalho.
- SCPs do Organizations que impõem negação por padrão.
- Configuração de data perimeters restringindo o acesso ao CDE.
Abordagem personalizada
Requer uma análise de risco direcionada (Req 12.3.2).
Objetivo da abordagem personalizada
- 7.2 — Os requisitos de acesso são estabelecidos conforme as funções de trabalho, seguindo os princípios de privilégio mínimo e necessidade de conhecimento.
- 7.3 — Os direitos e privilégios de acesso são gerenciados por meio de um sistema de controle de acesso que restringe o acesso conforme a necessidade de conhecimento e está configurado como negar por padrão.
Serviços AWS
AWS IAM Identity Center AWS Organizations AWS IAM Recursos de aprendizado
Referências
- AWS Security Maturity Model: Federated identity
- PCI DSS v4.0.1 Requirement 7.3