Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Operaciones internas
Este tema describe los requisitos internos implementados por el servicio para asegurar las claves de los clientes y las operaciones criptográficas para un servicio de criptografía de pagos y gestión de claves distribuido y escalable a nivel mundial.
Temas
Especificaciones y ciclo de vida del HSM{
AWS La criptografía de pagos utiliza una flota de HSM disponibles en el mercado. Los HSM cuentan con la validación FIPS 140-2 de nivel 3 y también utilizan las versiones de firmware y la política de seguridad que figuran en la lista de dispositivos PTS PCI aprobados
Todos los HSM funcionan en modo PCI y están configurados con la política de seguridad PCI PTS HSM. Solo están habilitadas las funciones necesarias para admitir los casos de uso de la criptografía de AWS pagos. AWS La criptografía de pagos no permite imprimir, mostrar ni devolver los PIN de texto no cifrado.
Seguridad física del dispositivo HSM
El servicio solo puede utilizar los HSM que tengan claves de dispositivo firmadas por una autoridad certificadora (CA) de criptografía de AWS pagos por el fabricante antes de la entrega. La criptografía AWS de pagos es una entidad de certificación secundaria de la entidad emisora de certificados del fabricante y constituye la base de confianza de los certificados de fabricantes y dispositivos de los HSM. La CA del fabricante implementa la norma ANSI TR 34 y ha certificado el cumplimiento del anexo A de seguridad del PCI PIN y del anexo A de la PCI P2PE. El fabricante verifica que todos los HSM con claves de dispositivo firmadas por la CA de criptografía de AWS pagos se envíen al receptor designado de AWS.
Tal y como exige la seguridad PCI PIN, el fabricante suministra una lista de números de serie a través de un canal de comunicación distinto al del envío del HSM. Estos números de serie se comprueban en cada paso del proceso de instalación del HSM en los centros de datos de AWS. Por último, los operadores AWS de criptografía de pago validan la lista de HSM instalados comparándola con la lista del fabricante antes de añadir el número de serie a la lista de HSM autorizados a recibir claves de criptografía de pago. AWS
Los HSM están almacenados de forma segura o bajo doble control en todo momento, lo que incluye:
-
El envío desde el fabricante a una instalación de montaje en bastidor de AWS.
-
Durante el montaje en bastidor.
-
Envío desde la instalación de montaje en bastidor a un centro de datos.
-
Recepción e instalación en una sala de procesamiento segura de un centro de datos. Los bastidores HSM aplican un doble control con cerraduras de acceso controlado por tarjeta, sensores de puerta con alarma y cámaras.
-
Durante las operaciones.
-
Durante el desmantelamiento y la destrucción.
Para cada chain-of-custody HSM se mantiene y supervisa un sistema completo, con responsabilidad individual.
Inicialización de HSM
Un HSM solo se inicializa como parte del conjunto de criptografía de AWS pagos después de validar su identidad e integridad mediante los números de serie, las claves de dispositivo instaladas por el fabricante y la suma de verificación del firmware. Una vez validada la autenticidad e integridad de un HSM, se configura, incluyendo la habilitación del Modo PCI. A continuación, se establecen las claves principales de la región de criptografía de AWS pagos y las claves principales del perfil, y el HSM queda a disposición del servicio.
Servicio y reparación del HSM
Los HSM tienen componentes reparables que no requieren la violación del límite criptográfico del dispositivo. Estos componentes incluyen ventiladores de refrigeración, fuentes de alimentación y baterías. Si un HSM u otro dispositivo dentro del bastidor de HSM necesita servicio, se mantiene el control dual durante todo el periodo en que el bastidor está abierto.
Desactivación de HSM
El desmantelamiento se produce debido a un HSM end-of-life o a un fallo de éste. Los HSM se ponen lógicamente a cero antes de retirarlos de su rack, si son funcionales, y luego se destruyen dentro de las salas de procesamiento seguras de los centros de datos de AWS. Nunca se devuelven al fabricante para su reparación, ni se utilizan para otro fin, ni se sacan de otro modo de una sala de procesamiento segura antes de su destrucción.
Actualización del firmware del HSM
Las actualizaciones del firmware del HSM se aplican cuando es necesario mantener la alineación con las versiones incluidas en la lista PCI PTS HSM y FIPS 140-2 (o FIPS 140-3), si se trata de una actualización relacionada con la seguridad o si se determina que los clientes pueden beneficiarse de las funciones de una nueva versión. AWS Los HSM de criptografía de pagos utilizan un firmware que coincide con las versiones incluidas en el PCI PTS HSM. off-the-shelf Se valida la integridad de las nuevas versiones de firmware con las versiones de firmware certificadas PCI o FIPS y, a continuación, se comprueba su funcionalidad antes de implantarlas en todos los HSM.
Acceso del operador
Los operadores pueden tener acceso no consular a los HSM para la resolución de problemas en los raros casos en que la información recopilada de los HSM durante las operaciones normales sea insuficiente para identificar un problema o planificar un cambio. Se ejecutan los siguientes pasos:
-
Se desarrollan y aprueban las actividades de resolución de problemas y se programa la sesión no consular.
-
Se retira un HSM del servicio de procesamiento del cliente.
-
Se eliminan las claves principales, bajo doble control.
-
Se permite al operador el acceso no consular al HSM para realizar las actividades de resolución de problemas aprobadas, bajo control dual.
-
Tras la finalización de la sesión no consular, se realiza el proceso de aprovisionamiento inicial en el HSM, devolviendo el firmware y la configuración estándar y sincronizando la clave principal, antes de devolver el HSM al servicio de los clientes.
-
Los registros de la sesión se graban en el seguimiento de cambios.
-
La información obtenida de la sesión se utiliza para planificar futuros cambios.
-
Todos los registros de acceso ajenos a la consola se revisan para comprobar si cumplen con los procesos y si se producen posibles cambios en la supervisión del HSM, el proceso de gestión o la formación de los operadores non-console-access .
Administración de claves
Todos los HSM de una región se sincronizan con una clave principal de región. Una clave principal de región protege al menos una clave principal de perfil. Una clave principal de perfil protege claves de cliente.
Todas las claves principales son generadas por un HSM y distribuidas a mediante la distribución de claves simétricas utilizando técnicas asimétricas, alineadas con ANSI X9 TR 34 y PCI PIN Anexo A.
Temas
- Generación
- Sincronización de la clave principal de región
- Rotación de la clave principal de la región
- Sincronización de la clave principal de perfil
- Rotación de la clave principal del perfil
- Protección
- Durabilidad
- Seguridad de las comunicaciones
- Gestión de las claves de los clientes
- Registro y monitorización
Generación
Las claves principales AES de 256 bits se generan en uno de los HSM aprovisionados para la flota de HSM de servicio, utilizando el generador de números al azar PCI PTS HSM.
Sincronización de la clave principal de región
Las claves principales de la región HSM son sincronizadas por el servicio en toda la flota regional con mecanismos definidos por ANSI X9 TR-34, que incluyen:
-
Autenticación mutua mediante claves del host de distribución de claves (KDH) y del dispositivo receptor de claves (KRD) y certificados para proporcionar autenticación e integridad de las claves públicas.
-
Los certificados están firmados por una autoridad de certificación (CA) que cumple los requisitos del Anexo A2 del PIN de la PCI, excepto para los algoritmos asimétricos y las intensidades de clave apropiadas para proteger las claves AES de 256 bits.
-
Identificación y protección de claves para las claves simétricas distribuidas coherentes con ANSI X9 TR-34 y PCI PIN Anexo A1, excepto para los algoritmos asimétricos y las intensidades de clave apropiadas para proteger las claves AES de 256 bits.
Las claves principales de región se establecen para los HSM que han sido autenticados y aprovisionados para una región por:
-
Se genera una clave principal en un HSM de la región. Ese HSM se designa como host de distribución de claves.
-
Todos los HSM aprovisionados en la región generan tokens de autenticación KRD, que contienen la clave pública del HSM e información de autenticación no reproducible.
-
Los tokens KRD se añaden a la lista de permitidos del KDH después de que éste valide la identidad y el permiso del HSM para recibir claves.
-
El KDH produce un token de clave principal autenticable para cada HSM. Los tokens contienen la información de autenticación del KDH y la clave principal cifrada que sólo se puede cargar en el HSM para el que se ha creado.
-
A cada HSM se le envía el token de clave principal creado para él. Tras validar la información de autenticación propia del HSM y la información de autenticación del KDH, la clave principal se descifra mediante la clave privada del KRD y se carga en la clave principal.
En caso de que un único HSM deba volver a sincronizarse con una región:
-
Se vuelve a validar y se aprovisiona con firmware y configuración.
-
Si es nuevo en la región:
-
El HSM genera un token de autenticación KRD.
-
El KDH añade el token a su lista de permitidos.
-
El KDH genera un token de clave principal para el HSM.
-
El HSM carga la clave principal.
-
El HSM se pone a disposición del servicio.
-
Esto garantiza que:
-
Solo los HSM validados para el procesamiento AWS de criptografía de pagos en una región pueden recibir la clave maestra de esa región.
-
Solo se puede distribuir una clave maestra de un HSM de criptografía de AWS pagos a un HSM de la flota.
Rotación de la clave principal de la región
Las claves principales de región se rotan al expirar el periodo de criptografía, en el improbable caso de que se sospeche que la clave está comprometida, o tras cambios en el servicio que se determine que afectan a la seguridad de la clave.
Se genera y distribuye una nueva clave principal de región como en la provisión inicial. Las claves principales de perfil guardadas deben traducirse a la nueva clave principal de región.
La rotación de la clave principal de región no afecta al procesamiento del cliente.
Sincronización de la clave principal de perfil
Las claves principales de perfil están protegidas por las claves principales de región. Esto restringe un perfil a una región específica.
Las claves principales de perfil se aprovisionan en consecuencia:
-
Se genera una clave principal de perfil en un HSM que tenga sincronizada la clave principal de región.
-
La clave principal del perfil se almacena y encripta con la configuración del perfil y otros contextos.
-
El perfil es utilizado para las funciones criptográficas del cliente por cualquier HSM de la región con la clave principal de la región.
Rotación de la clave principal del perfil
Las claves principales de perfil se rotan al expirar el periodo criptográfico, tras sospecha de compromiso de la clave o tras cambios en el servicio que se determine que afectan a la seguridad de la clave.
Pasos de la rotación:
-
Se genera una nueva clave principal de perfil y se distribuye como clave principal pendiente al igual que con la provisión inicial.
-
Un proceso en segundo plano traduce el material de la clave de cliente de la clave principal de perfil establecida a la clave principal pendiente.
-
Cuando todas las claves de cliente se han cifrado con la clave pendiente, ésta se promueve a clave principal de perfil.
-
Un proceso en segundo plano borra el material de las claves de cliente protegido por la clave pendiente.
La rotación de la clave principal del perfil no afecta al procesamiento de los clientes.
Protección
Las claves sólo dependen de la jerarquía de claves para su protección. La protección de las claves principales es fundamental para evitar la pérdida o el compromiso de todas las claves de cliente.
Las claves principales de región son restaurables desde la copia de seguridad sólo para HSM autenticados y aprovisionados para el servicio. Estas claves sólo pueden almacenarse como tokens de clave principal mutuamente autenticables y cifrados de un KDH específico para un HSM específico.
Las claves principales de perfil se almacenan con la configuración del perfil y la información de contexto encriptada por región.
Las claves de cliente se almacenan en bloques de claves, protegidos por una clave maestra de perfil.
Todas las claves existen exclusivamente dentro de un HSM o se almacenan protegidas por otra clave de igual o mayor fuerza criptográfica.
Durabilidad
Las claves de cliente para la criptografía de las transacciones y las funciones empresariales deben estar disponibles incluso en situaciones extremas que suelen provocar interrupciones. AWS La criptografía de pagos utiliza un modelo de redundancia de varios niveles en todas las zonas y regiones de disponibilidad. AWS Los clientes que requieran una mayor disponibilidad y durabilidad para las operaciones criptográficas de pago que la proporcionada por el servicio deberán implementar arquitecturas multirregión.
Los tokens de autenticación del HSM y de la clave principal se guardan y pueden utilizarse para restaurar una clave principal o sincronizarse con una nueva clave principal, en caso de que deba restablecerse un HSM. Los tokens se archivan y sólo se utilizan bajo doble control cuando es necesario.
Seguridad de las comunicaciones
Externo
AWS Los terminales de la API de criptografía de pagos cumplen con los estándares de AWS seguridad, como el TLS igual o superior a 1.2 y la versión 4 de Signature para la autenticación e integridad de las solicitudes.
Las conexiones TLS entrantes se terminan en equilibradores de carga de red y se reenvían a los gestores de API a través de conexiones TLS internas.
Interno
Las comunicaciones internas entre componentes de servicio y entre componentes de servicio y otro servicio de AWS están protegidas por TLS utilizando criptografía fuerte.
Los HSM se encuentran en una red privada no virtual a la que sólo se puede acceder desde los componentes de servicio. Todas las conexiones entre los HSM y los componentes de servicio están protegidas con TLS mutuo (mTLS), igual o superior a TLS 1.2. Los certificados internos para TLS y mTLS son administrados por el Gestor de certificación de Amazon mediante una Autoridad de certificación privada de AWS. Las VPC internas y la red HSM se monitorizan para detectar actividades no aceptadas y cambios de configuración.
Gestión de las claves de los clientes
En AWS, la confianza de los clientes es nuestra principal prioridad. Usted mantiene el control total de las claves que cargue o cree en el servicio bajo su cuenta de AWS y la responsabilidad de configurar el acceso a las claves.
AWS La criptografía de pagos es totalmente responsable de la conformidad física del HSM y de la gestión de claves de las claves gestionadas por el servicio. Esto requiere la propiedad y administración de las claves principales de HSM y el almacenamiento de las claves de los clientes protegidas en la base de datos de claves de criptografía AWS de pagos.
Separación del espacio de claves del cliente
AWS La criptografía de pagos aplica políticas clave para todos los usos de las claves, incluida la limitación del capital a la cuenta propietaria de la clave, a menos que la clave se comparta explícitamente con otra cuenta.
Copia de seguridad y recuperación
Las claves y la información sobre claves de una región se respaldan en archivos cifrados por AWS. Los archivos requieren un doble control para restaurarlos. AWS
Bloques de claves
Todas las claves se almacenan en bloques de claves con formato ANSI X9 TR-31.
Las claves se pueden importar al servicio desde criptogramas u otros formatos de bloques de claves compatibles ImportKey con. Del mismo modo, las claves pueden exportarse, si son exportables, a otros formatos de bloques de claves o criptogramas soportados por perfiles de exportación de claves.
Uso de claves
El uso de claves está restringido a lo configurado KeyUsage por el servicio. El servicio fallará cualquier solicitud con un uso de clave, modo de uso o algoritmo inapropiados para la operación criptográfica solicitada.
Relaciones de intercambio de claves
PCI PIN Security y PCI P2PE exigen que las organizaciones que comparten claves que cifran PIN, incluida la KEK utilizada para compartir esas claves, no compartan esas claves con ninguna otra organización. Es una práctica recomendada que las claves simétricas se compartan sólo entre 2 partes, incluso dentro de la misma organización. Esto minimiza el impacto de presuntos compromisos de claves que obliguen a reemplazar las claves afectadas.
Incluso los casos empresariales que requieren compartir claves entre más de 2 partes, deben mantener el número de partes al mínimo.
AWS La criptografía de pagos proporciona etiquetas clave que se pueden usar para rastrear y hacer cumplir el uso de las claves dentro de esos requisitos.
Por ejemplo, KEK y BDK para diferentes instalaciones de inyección de claves pueden identificarse estableciendo un “KIF”=“POSStation” para todas las claves compartidas con ese proveedor de servicios. Otro ejemplo sería etiquetar las claves compartidas con las redes de pago con «Network» = «PayCard». El etiquetado le permite crear controles de acceso y crear informes de auditoría para hacer cumplir y demostrar sus prácticas de gestión de claves.
Eliminación de claves
DeleteKey marca las claves de la base de datos para eliminarlas después de un período configurable por el cliente. Transcurrido este periodo, la llave se borra irremediablemente. Se trata de un mecanismo de seguridad para evitar el borrado accidental o malintencionado de una clave. Las claves marcadas para su eliminación no están disponibles para ninguna acción excepto: RestoreKey
Las llaves borradas permanecen en las copias de seguridad del servicio durante 7 días después de su borrado. No son restaurables durante este periodo.
Las claves pertenecientes a cuentas AWS cerradas se marcan para su borrado. Si la cuenta se reactiva antes de que se alcance el periodo de borrado, las claves marcadas para borrado se restauran, pero se desactivan. Deberá volver a habilitarlas para poder utilizarlas en operaciones criptográficas.
Registro y monitorización
Los registros de servicios internos incluyen:
-
CloudTrail registros de las llamadas al servicio de AWS realizadas por el servicio
CloudWatch registros de ambos eventos registrados directamente en los CloudWatch registros o eventos de HSM
Archivos de registro de HSM y sistemas de servicio
Archivos de registro
Todas las fuentes de registros controlan y filtran la información confidencial, incluida la relativa a las claves. Los registros se revisan sistemáticamente para garantizar que no contienen información sensible de los clientes.
El acceso a los registros está restringido a las personas necesarias para completar las funciones de su trabajo.
Todos los registros se retienen de acuerdo con las políticas de conservación de registros de AWS.
