c9.2 Gestionar el alcance físico de los componentes propios (híbrido/POI)
Cuando existan medios físicos o dispositivos de punto de interacción (POI) fuera de AWS bajo responsabilidad del cliente, aplicar y documentar los controles de protección de medios y de dispositivos POI.
Requisito 9
Restrict Physical Access to Cardholder Data
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.
9.4 Protección de medios con datos de cuenta
- 9.4.1 All media with CHD physically secured Fuera de alcance
- 9.4.1.1 Offline media backups stored in secure location Fuera de alcance
- 9.4.1.2 Security of offline media storage locations reviewed Fuera de alcance
- 9.4.2 All media classified by data sensitivity Tu responsabilidad
- 9.4.3 Media sent outside facility secured and logged Fuera de alcance
- 9.4.4 Management approval for media moved outside facility Fuera de alcance
- 9.4.5 Inventory logs of electronic media with CHD maintained Tu responsabilidad
- 9.4.5.1 Media inventories conducted at least annually Tu responsabilidad
- 9.4.6 Hard-copy materials with CHD destroyed when no longer needed Fuera de alcance
- 9.4.7 Electronic media with CHD rendered unrecoverable on disposal Cubierto
9.5 Protección de dispositivos de punto de interacción (POI) contra manipulación
- 9.5.1 POI devices protected from tampering and unauthorized substitution Fuera de alcance
- 9.5.1.1 Up-to-date list of POI devices maintained Fuera de alcance
- 9.5.1.2 POI device surfaces periodically inspected Fuera de alcance
- 9.5.1.2.1 Frequency of POI inspections defined by targeted risk analysis Tu responsabilidad
- 9.5.1.3 Training for personnel in POI environments Tu responsabilidad
Cómo implementarlo en AWS
Documentar formalmente si existen medios o dispositivos POI propios; si no aplican en un despliegue 100% AWS, registrar la no aplicabilidad en el alcance. Para componentes híbridos, mantener inventario de POI, inspecciones periódicas antimanipulación y procedimientos de destrucción segura de medios. Vincular la evidencia a la documentación de alcance PCI.
Implementación práctica
Cómo se implementa este control en cada arquitectura de referencia:
Para un despliegue puramente en AWS, el trabajo táctico es documentar la no aplicabilidad de tus propios medios/POI, o gestionar los dispositivos híbridos que sí existan.
- Confirma si hay medios o dispositivos de punto de interacción (POI) propios del cliente en alcance; un despliegue 100% AWS normalmente no tiene ninguno.
- Si no aplican, registra la no aplicabilidad de 9.4 (medios) y 9.5 (POI) con justificación en el documento de alcance PCI.
- Si existen POI/medios híbridos, mantén un inventario de POI, registros de inspección periódica de manipulación y procedimientos de destrucción segura de medios, y vincúlalos al alcance.
Cómo validar: El documento de alcance indica la aplicabilidad de 9.4/9.5 con justificación; donde existan dispositivos, el inventario de POI y los registros de inspección están vigentes.
Evita: Omitir 9.4/9.5 en silencio porque «todo está en AWS». Registra la no aplicabilidad de forma explícita con justificación: un evaluador la necesita en archivo.
Decide la aplicabilidad de medios/POI una vez a nivel de organización y, donde existan entornos híbridos, rastréalos en la cuenta correspondiente contra la matriz compartida.
- Documenta la no aplicabilidad de medios/POI una vez a nivel de organización para que cada cuenta del CDE herede una postura consistente.
- Donde existan entornos POI híbridos, rastrea su inventario e inspecciones en la cuenta de carga correspondiente.
- Referencia la matriz de responsabilidad compartida para que el alcance físico sea inequívoco en toda la OU de PCI.
Cómo validar: El documento de alcance a nivel de organización aborda 9.4/9.5, y cualquier entorno POI híbrido tiene registros de inventario/inspección vigentes referenciados desde la matriz.
Evita: Documentar la aplicabilidad de medios/POI de forma inconsistente por cuenta. Decídela una vez a nivel de organización y rastrea las excepciones donde realmente existen.
Validación PCI
Procedimientos de prueba
- Examinar la documentación para verificar que los procedimientos protegen físicamente, clasifican, inventarían y destruyen de forma segura los medios con datos del titular de la tarjeta (9.4.1, 9.4.2, 9.4.5.a, 9.4.6.a, 9.4.7.a), o documentar la no aplicabilidad en despliegues 100% AWS.
- Examinar la lista de dispositivos POI y los procedimientos de inspección para verificar que los dispositivos se inventarían y se inspeccionan periódicamente contra manipulación y sustitución (9.5.1.1.a, 9.5.1.2.a), o documentar la no aplicabilidad.
Evidencia en AWS
- Documento de alcance PCI indicando aplicabilidad o no aplicabilidad de medios físicos y POI.
- Cuando aplique: inventario de POI, registros de inspección y procedimientos de destrucción de medios.
- Matriz de responsabilidad compartida delimitando lo cubierto por AWS.
Enfoque personalizado
Requiere un análisis de riesgo dirigido (Req 12.3.2).
Objetivo del enfoque personalizado
- 9.4 — Los medios con datos del titular de la tarjeta no pueden ser accedidos por personal no autorizado y se destruyen de forma segura cuando ya no se necesitan.
- 9.5 — Los dispositivos de punto de interacción (POI) están protegidos frente a manipulación y sustitución no autorizada.
Servicios AWS
Recursos de aprendizaje
Referencias
- PCI DSS v4.0.1 Requirements 9.4, 9.5 (customer responsibility for hybrid/POI)
PCI DSS Security Maturity Model