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
Protección HSM
Especificaciones y ciclo de vida del HSM{
AWS La criptografía de pagos utiliza una flota de productos disponibles en el mercado. HSMs HSMs Están validados por el FIPS 140-2 de nivel 3 y también utilizan versiones de firmware y la política de seguridad que figuran en la lista de dispositivos PCI PTS aprobados por el Consejo de Normas de Seguridad PCI que cumplen con la norma PCI HSM v3
Los asesores externos comprueban la marca, el modelo, el firmware, la configuración, el ciclo de vida, la gestión física, el control de cambios, los controles de acceso de los operadores, la gestión de las claves principales y todos los requisitos de PCI PIN y P2PE relacionados con las operaciones del HSM. HSMs
Todos funcionan en modo PCI y HSMs se configuran con la política de seguridad PCI PTS HSM. Solo están habilitadas las funciones necesarias para admitir los casos AWS de uso de la criptografía de pagos. AWS La criptografía de pagos no permite imprimir, mostrar ni devolver texto sin cifrar. PINs
Seguridad física del dispositivo HSM
El servicio solo podrá utilizar aquellos dispositivos HSMs que cuenten con las claves del dispositivo firmadas por una autoridad certificadora de criptografía de AWS pagos (CA) por el fabricante antes de la entrega. La criptografía de AWS pagos es una subentidad de certificación de la entidad emisora de certificados del fabricante y constituye la base de confianza de los certificados de fabricante y dispositivo de HSM. La CA del fabricante ha certificado el cumplimiento del anexo A de seguridad PCI PIN y el anexo A de 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
HSMs están guardadas de forma segura o bajo un 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.
Se mantiene y supervisa un sistema completo chain-of-custody, con responsabilidad individual, para cada HSM.
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 a cero de forma lógica antes de sacarlos de su rack, si están en funcionamiento, y luego se destruyen en 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 de 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 Payment Cryptography HSMs ejecuta off-the-shelf el firmware que coincide con las versiones del PCI PTS que figuran en la lista HSM. La integridad de las nuevas versiones de firmware se valida con las versiones de firmware certificadas por PCI o FIPS y, a continuación, se comprueba su funcionalidad antes de lanzarlas a todas. HSMs
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 la conformidad con los procesos y los posibles cambios en la supervisión del HSM, el proceso de non-console-access gestión o la formación de los operadores.
Administración general 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.
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.
La identificación y la protección de las claves simétricas distribuidas son compatibles con la norma ANSI X9 TR-34 y el PCI PIN anexo A1, excepto en lo que respecta a los algoritmos asimétricos y las intensidades de las teclas adecuadas para proteger las claves AES de 256 bits.
Las claves principales de la región se establecen para las HSMs que se han autenticado y aprovisionado para una región mediante:
Se genera una clave principal en un HSM de la región. Ese HSM se designa como host de distribución de claves.
Todas las provisiones HSMs en la región generan un token de autenticación KRD, que contiene la clave pública del HSM e información de autenticación que no se puede reproducir.
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 de criptografía AWS 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.
El operador accede a las claves principales de HSM
Las claves principales solo existen en el HSM administrado por el servicio y protegido en instalaciones seguras de AWS. Las claves principales no se pueden exportar desde ningún HSM ni sincronizarse con un HSM que no esté inicializado por el fabricante para su uso en el servicio. Los operadores de AWS no pueden obtener claves principales de ninguna forma que puedan cargarse en un HSM no administrado por el servicio.
Gestión de las claves de los clientes
En AWS, la confianza del cliente es nuestra principal prioridad. Usted mantiene el control total de las claves que importe o cree en el servicio en su cuenta de AWS. Usted es responsable de configurar el acceso a las claves.
AWS Payment Cryptography es un proveedor de servicios que usa HSMs y administra las claves en nombre de los clientes, de forma similar a los proveedores de servicios de pago tradicionales. El servicio es totalmente responsable de la seguridad física y lógica de HSM. La responsabilidad de administrar las claves la comparten el servicio y los clientes, ya que el cliente debe proporcionar información precisa sobre las claves creadas por el servicio o importadas al mismo, que el servicio utiliza para garantizar el uso y la administración correctos de las claves. Las protecciones de segregación de datos de AWS se utilizan para garantizar que las claves que pertenecen a una cuenta de AWS no puedan comprometer las claves que pertenecen a otra.
AWS Payment Cryptography es plenamente responsable de la conformidad física del HSM y de la administración de claves de las claves gestionadas por el servicio. Esto requiere la propiedad y la administración de las claves principales del HSM y la protección de las claves de los clientes gestionadas mediante la AWS criptografía 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 una clave se comparta explícitamente con otra cuenta.
Las cuentas de AWS proporcionan una segregación completa del entorno entre clientes o aplicaciones de forma análoga a las implementaciones no basadas en la nube en diferentes centros de datos. Cada cuenta proporciona control de acceso aislado, redes, recursos informáticos, almacenamiento de datos, claves criptográficas para la protección de datos y las transacciones de pago, y todos los recursos de AWS. Los servicios de AWS, como Organizations y Control Tower, permiten la administración empresarial de cuentas de aplicaciones independientes, de forma análoga a las jaulas o salas de un centro de datos empresarial.
El operador accede a las claves de los clientes
Las claves de cliente gestionadas por el servicio se almacenan protegidas por las claves principales de la partición y solo las puede utilizar la cuenta del cliente propietario o la cuenta que el propietario haya configurado específicamente para compartir las claves. Los operadores de AWS no pueden exportar ni realizar operaciones criptográficas o de administración de claves con las claves de los clientes mediante el acceso manual al servicio, que se administra mediante los mecanismos de acceso manual de los operadores de AWS.
El código de servicio que implementa la administración y el uso de las claves del cliente está sujeto a las prácticas de código seguro de AWS, según se evalúa en la evaluación PCI DSS de AWS.
Copia de seguridad y recuperación
Las claves y la información clave almacenadas internamente por el servicio para una región se guardan en archivos cifrados mediante. AWS Los archivos requieren un doble control AWS para restaurarlos.
Bloques de claves
Todas las claves se almacenan y procesan en bloques de claves con formato ANSI X9.143.
Las claves se pueden importar al servicio desde criptogramas u otros formatos de bloques de claves compatibles con. ImportKey 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 PINs o archivan datos, incluidas las claves de intercambio de claves (KEK) utilizadas para compartir esas claves, no compartan las mismas claves con ninguna otra organización. Se recomienda que las claves simétricas se compartan solo entre dos partes con un único propósito, 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, las claves KEK y BDK para diferentes instalaciones de inyección de claves se pueden identificar configurando «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.
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 1.2 o superior 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. La red interna VPCs y la red HSM se supervisan para detectar actividades inesperadas y cambios de configuración.
Registro y supervisió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.
