c7.2 Centralizar el acceso con IAM Identity Center y permisos por función
Gestionar el acceso a través de un sistema de control de acceso centralizado que cubra todos los componentes del sistema, con denegación por defecto salvo autorización explícita.
Requisito 7
Restrict Access to System Components and Cardholder Data by Business Need to Know
Sub-requisitos PCI cubiertosCobertura mostrada por sub-control de PCI DSS v4.0.1. “Cubierto” = atendido por esta recomendación de AWS. “En roadmap” = técnico, planeado. “Tu responsabilidad” = control organizacional/de proceso. “Fuera de alcance” = control físico o de terceros no implementado en AWS.
7.2 Definición y asignación apropiada del acceso
- 7.2.1 Access control model defined for need-to-know/least-privilege Cubierto
- 7.2.2 Access assigned based on job classification and least privilege Cubierto
- 7.2.3 Required privileges approved by authorized personnel Tu responsabilidad
- 7.2.4 User accounts and access reviewed at least every 6 months Tu responsabilidad
- 7.2.5 Application/system accounts and access managed by least privilege Cubierto
- 7.2.5.1 Access by app/system accounts reviewed periodically Tu responsabilidad
- 7.2.6 Query access to stored CHD restricted via roles/applications Cubierto
7.3 Gestión del acceso mediante un sistema de control de acceso
- 7.3.1 Access control system(s) in place covering all components Cubierto
- 7.3.2 Access control system configured to enforce least privilege Cubierto
- 7.3.3 Access control system set to 'deny all' by default Cubierto
Cómo implementarlo en AWS
Adoptar AWS IAM Identity Center con permission sets por función laboral, federado con el IdP corporativo. Aplicar un modelo de denegación por defecto reforzado con SCPs en AWS Organizations. Definir data perimeters para limitar el acceso a recursos del CDE.
Implementación práctica
Cómo se implementa este control en cada arquitectura de referencia:
En una sola cuenta, construye acceso basado en roles y denegación por defecto con roles IAM nativos por función laboral (sin usuarios permanentes), y evoluciona a IAM Identity Center para federación a medida que creces.
- Define roles IAM por función laboral y haz que las personas los asuman (vía federación o sesiones de corta duración) en lugar de usuarios IAM permanentes; otorga solo las acciones/recursos específicos que cada función necesita (denegación por defecto).Acceso a la cuenta
IAM - Aplica perímetros de datos (políticas de recursos / condiciones IAM) para que los recursos del CDE sean alcanzables solo desde identidades confiables.Capa de datos (CDE) IAM
- Evolución: cuando necesites acceso asignado de forma central y federado con el IdP mediante permission sets, adopta IAM Identity Center. Ten en cuenta que el acceso con permission sets a cuentas AWS requiere una organization instance, que adopta AWS Organizations (una account instance standalone solo cubre acceso a aplicaciones, no permission sets de cuenta).Acceso a la cuenta (a medida que escalas)
IAM Identity Center
Cómo validar: El acceso se asigna mediante roles IAM por función laboral (sin usuarios permanentes con admin inline), se aplica el mínimo privilegio, y una solicitud de una acción fuera del rol otorgado se deniega por defecto.
Evita: Entregar a las personas usuarios IAM permanentes con políticas inline amplias. Define roles por función laboral, otorga mínimo privilegio y deniega por defecto.
Aquí es donde brilla el multi-cuenta: asigna permission sets en todas las cuentas desde un solo lugar, fuerza la denegación por defecto con SCPs y limita los datos del CDE a identidades/redes confiables.
- Usa IAM Identity Center para asignar permission sets en todas las cuentas desde un único lugar, federado al IdP.Cuenta de identidad/seguridad → OU de PCI IAM Identity Center
AWS Organizations - Fuerza guardarraíles de denegación por defecto con SCPs en la OU de PCI para que ninguna cuenta pueda exceder sus acciones permitidas.OU de PCI (guardarraíl) AWS Organizations
- Define perímetros de datos para que los datos del CDE sean alcanzables solo desde identidades y redes confiables (bloqueando principals/VPCs no confiables).Cada cuenta de carga del CDE IAM
Cómo validar: Identity Center cubre todas las cuentas, una prueba de SCP bloquea una acción fuera de alcance en una cuenta del CDE, y el perímetro de datos rechaza un principal no confiable.
Evita: Federar cada cuenta por separado. Centraliza en Identity Center para que el acceso, el MFA y la denegación por defecto sean uniformes en toda la organización.
Validación PCI
Procedimientos de prueba
- Examinar la documentación del proveedor y los ajustes del sistema para verificar que el sistema de control de acceso gestiona el acceso de cada componente según la necesidad de conocer y cubre todos los componentes (7.3.1).
- Verificar que el sistema de control de acceso aplica los permisos según la clasificación y la función laboral (7.3.2).
- Verificar que el sistema de control de acceso está configurado como 'denegar todo' por defecto (7.3.3).
Evidencia en AWS
- Permission sets de IAM Identity Center mapeados a funciones laborales.
- SCPs de Organizations que aplican denegación por defecto.
- Configuración de data perimeters restringiendo el acceso al CDE.
Enfoque personalizado
Requiere un análisis de riesgo dirigido (Req 12.3.2).
Objetivo del enfoque personalizado
- 7.2 — Los requisitos de acceso se establecen según las funciones laborales, siguiendo los principios de mínimo privilegio y necesidad de conocer.
- 7.3 — Los derechos y privilegios de acceso se gestionan mediante un sistema de control de acceso que restringe el acceso según la necesidad de conocer y está configurado como denegar por defecto.
Servicios AWS
AWS IAM Identity Center AWS Organizations AWS IAM Recursos de aprendizaje
Referencias
- AWS Security Maturity Model: Federated identity
- PCI DSS v4.0.1 Requirement 7.3