PCI DSS Security Maturity Model·AWS v1.0.0
Inicio / Matriz / Requisito 2 / r2.3
Foundational Identity and Access Management 🤝 Compartida

r2.3 Cifrar y endurecer accesos administrativos non-console

Asegurar que todo el acceso administrativo que no es por consola física se cifra con criptografía fuerte, evitando protocolos y accesos administrativos inseguros.

Quick Wins
Foundational
Efficient
Optimized
Esfuerzo: Medio Impacto: Medio Aplica al CDE: Sí

Servicios AWS

AWS Systems Manager AWS KMS Amazon VPC

Requisito 2

Apply Secure Configurations to All System Components

Sub-requisitos PCI cubiertos

  • 2.2 Configuraciones seguras aplicadas a todos los componentes del sistema

Cómo implementarlo en AWS

Eliminar el acceso administrativo por protocolos en claro. Usar AWS Systems Manager Session Manager para acceso administrativo sin puertos abiertos ni SSH/RDP directos, con sesiones cifradas y auditadas. Cuando se requiera SSH, forzar claves y algoritmos fuertes.

Implementación práctica

Cómo se implementa este control en cada arquitectura de referencia:

Reemplaza SSH/RDP con Session Manager para que el acceso administrativo sea cifrado, registrado y no requiera puertos entrantes abiertos.

  1. Alcanza las instancias de las capas de app y datos solo a través de Systems Manager Session Manager, con la sesión cifrada usando una clave de KMS.
    Capa de app (CDE) / Capa de datos (CDE) Systems Manager AWS KMS
  2. Registra cada sesión en CloudWatch Logs o S3 para que el acceso administrativo sea auditable.
    Registro de la cuenta CloudWatch Amazon S3
  3. Confirma que los security groups del CDE no mantengan reglas entrantes de SSH (22) ni RDP (3389).
    Capa de app (CDE) / Capa de datos (CDE) Amazon VPC

Cómo validar: Session Manager está configurado con cifrado KMS y registro, existen logs de sesión, y ningún security group permite entrada 22/3389.

Evita: Mantener un bastión SSH «break-glass» con un puerto abierto. Usa roles break-glass de Session Manager para que nunca se exponga un puerto administrativo en texto claro.

Una sola cuenta, 3 capas →

Estandariza el acceso cifrado y registrado con Session Manager en toda la organización y haz imposibles por política los protocolos administrativos en texto claro.

  1. Define una configuración común de Session Manager (clave de KMS, destino de registro) y distribúyela a todas las cuentas del CDE.
    Cuenta de herramientas de seguridad → OU de PCI Systems Manager AWS KMS
  2. Entrega los logs de sesión de forma central a la cuenta de log-archive para una retención resistente a manipulaciones.
    Cuenta de log-archive Amazon S3
  3. Adjunta una SCP a la OU de PCI que deniegue abrir protocolos administrativos en texto claro (p. ej. autorizar entrada 22/3389) en cualquier cuenta del CDE.
    OU de PCI (guardarraíl) AWS Organizations

Cómo validar: Los logs de sesión de cada cuenta del CDE llegan a la cuenta de log-archive, y una prueba de SCP bloquea autorizar SSH entrante en una cuenta del CDE.

Evita: Configurar Session Manager por cuenta con claves y destinos de logs inconsistentes. Estandariza de forma central para que el cifrado y la auditoría sean uniformes y demostrables.

Multi-cuenta con un OU dedicado a PCI →

Validación PCI

Métodos de comprobación: examineobserve

Procedimientos de prueba

  • Examinar los estándares de configuración para verificar que exigen cifrar todo el acceso administrativo que no es por consola con criptografía fuerte (2.2.7.a).
  • Observar a un administrador iniciando sesión y examinar las configuraciones para verificar que el acceso administrativo fuera de consola está cifrado (2.2.7.b).
  • Examinar los ajustes de los componentes y de los servicios de autenticación para verificar que no hay servicios de login remoto inseguros para el acceso administrativo fuera de consola (2.2.7.c).

Evidencia en AWS

  • Configuración de SSM Session Manager con cifrado KMS y registro de sesiones.
  • Logs de sesión en CloudWatch/S3 que evidencian acceso administrativo auditado.
  • Ausencia de reglas de Security Group que permitan protocolos administrativos en claro.

Enfoque personalizado

Requiere un análisis de riesgo dirigido (Req 12.3.2).

Objetivo del enfoque personalizado

  • 2.2 — Todos los componentes del sistema están configurados de forma segura y consistente, conforme a estándares de endurecimiento aceptados por la industria o a las recomendaciones del proveedor.

Recursos de aprendizaje

Referencias

  • AWS Security Maturity Model: Restrict administrative access