La aparición de lo que hoy conocemos como Hardware Security Modules (HSMs) no fue un capricho de diseño, sino una respuesta ante cierto tipo de vulnerabilidad emergente en contextos específicos. Si retrocedemos a 1972, la aparición del 'Atalla Box' de Mohamed Atalla marcó el punto de inflexión, donde se pasa de confiar la seguridad al software hacia el encapsulamiento en silos físicos inexpugnables. El enfoque radicaba en crear un entorno de confianza (Root of Trust) donde la entropía y el ciclo de vida de las claves de cifrado estuvieran aislados del sistema operativo host con quien interactuaban. 
Desde aquellos primeros racks de IBM en los 80, orientados a la banca mayorista, hasta la estandarización del FIPS 140-1 en los 90, la evolución ha sido una carrera armamentista contra la extracción física de información sensible y confidencial, el material de claves. Hemos pasado de simples cajas de cifrado simétrico a dispositivos con capacidad de respuesta ante manipulaciones, que son capaces de autodestruirse ante intrusiones, evolucionando incluso en el día de hoy hacia modelos que se conocen como Cloud HSM, que deben mantener el mismo rigor de cifrado a la hora de ofrecer servicios a clientes. De alguna manera, es lo que de manera paralela se conoce, o será compatible con la denominación de HSM-as-a-Service. Debemos entender, todos los participantes de la industria de medios de pago por tarjeta, entre otros, que cuando estamos interactuando o inspeccionando estos componentes en un CPD, existen décadas de refinamiento en la ciencia que se dedica a la gestión de claves y que estamos ante, por que no decirlo, a la columna vertebral que gobierna todas las ramificaciones en el cifrado de una organización que se preocupe por la seguridad de los datos que custodia, o que se vea obligada a hacerlo.
¿Y cómo hemos pasado de la sala fría a la nube? ¿Cómo integramos estos servicios de HSM en cloud dentro de un marco de cumplimiento PCI PIN? Simple evolución, partimos en ambos casos de la premisa que caracteriza a estos componentes, la inviolabilidad de su módulo criptográfico, de su core. Un HSM no es simplemente un servidor que cifra y descifra, como acabamos de matizar, es la piedra angular sobre la que se asienta la seguridad criptográfica en la industria de pagos, en el contexto que estamos analizando. Su valor radica en su naturaleza como entorno de ejecución dedicado, diseñado para proteger y gestionar claves sensibles, de manera aislada al entorno productivo que contiene los sistemas que interactúan o deben interactuar con este, así como aislando las amenazas adyacentes que puedan traer consigo estos últimos. Estas características deben de cumplirse tanto en una sala fría como en un entorno cloud, ya que lo único que cambia es el punto de vista de quien disfruta el servicio. En ambos casos se cuenta con componentes físicos que son los que garantizan todos los principios que deben de considerar los HSM.
A día de hoy, la inviolabilidad del módulo se formaliza gracias a la implementación del estándar FIPS 140-2 Nivel 3 (o superior), que debe de garantiza el aislamiento físico y lógico de las Local Master Keys (LMKs), o nomenclatura equivalente según fabricantes, así como el control riguroso de su ciclo de vida. Digamos que estas claves están en el nivel mas alto de la jerarquía de claves de cualquier organización que tenga una madurez suficiente en esta materia. 
En el contexto del estándar PCI PIN, el HSM es considerado una herramienta fundamental para lograr el cumplimiento de la protección de las claves de cifrado utilizadas para la protección del PIN, bien sean aquellas claves que cifran el PIN directamente u otras relacionadas que puedan tener impacto en la seguridad de este dato. Incluso la migración actual del mercado a formatos robustos como los Key Blocks ANSI X9.143 o TR-31 (analizado en otros artículos) subraya aún más la necesidad de contar con una base de gestión de claves inexpugnable. El HSM garantiza que estas estructuras de datos complejas, que encapsulan tanto la clave cifrada como sus atributos de uso, se creen, gestionen y descifren dentro de un ámbito de cifrado de confianza.
Otras operaciones básicas en una organización de esta índole requieren o pueden requerir el empleo de este tipo de dispositivos. Operativas como el cifrado o descifrado del PIN para su intercambio entre zonas, la recepción de claves de diferentes partes a integrar en el core de un negocio para poder traducir la información y ser compartida, la generación de MACs para blindar la integridad de las tramas, o la generación de claves cumpliendo normativas de la industria, de manera que estas puedan ser empleadas en otros dispositivos como claves de trabajo... Las ramificaciones del cifrado en las organizaciones se extienden de extremo a extremo, a veces de manera transparente gracias a la potencia y madurez de los procesos que emplean técnicas de cifrado.
Ahora, bien; ¿Qué interés podría tener una compañía bajo el impacto de PCI PIN en emplear un proveedor de servicios que ofrezca el servicio de HSMs en cloud en lugar de trabajar con los HSM on-premise como venía siendo habitual? Vamos a analizarlo.
Retrocedamos unos breves instantes para evaluar el concepto de proveedor de servicios. El concepto de proveedor de servicios desde el punto de vista de PCI DSS y desde el punto de vista de PCI PIN distan en cierta medida. Si bien, para PCI DSS existiría un complejo entramado de proveedores que de una manera u otra puede ofrecer diversos servicios que pueden ejecutarse en nombre de los clientes (Merchants) y sirven para que estos últimos puedan cumplir requisitos gracias a la actividad de los primeros, el concepto de proveedor de servicios en PCI PIN es ligeramente diferente. PCI DSS comprende de manera innata que exista un proveedor que realice una determinada actividad en nombre de un Merchant y pueda certificar su servicio mediante la existencia de un AOC (Attestation of Compliance) de proveedor que declare de manera oficial dichos servicios. Pueden existir desde proveedores que procesan los datos sensibles, hasta proveedores que gestionan en exclusiva el antivirus de una organización; y el perfilado de estos encaja perfectamente en la definición de un AOC para PCI DSS, gracias en parte a la existencia de una sección concreta que describe el tipo de servicios que se han certificado en la evaluación de estos proveedores:
El propio estándar explica este enfoque:
Cuando el TPSP proporciona un servicio que cumple con los requisitos de PCI DSS en nombre del cliente o cuando ese servicio puede afectar la seguridad de los datos de tarjetahabiente y/o datos de autenticación sensibles del cliente, esos requisitos están dentro del alcance de la evaluación del cliente y el cumplimiento de ese servicio afectará el cumplimiento PCI DSS del cliente. El TPSP debe demostrar que cumple con los requisitos de PCI DSS aplicables para que esos requisitos estén vigentes para sus clientes.
Ahora bien, desde el punto de vista de PCI PIN, un proveedor de servicios es un concepto, como hemos dicho más arriba, ligeramente diferente. El propio programa de PCI PIN hace referencia en una sección a los “proveedores de servicios PCI PIN” como aquellas organizaciones a quien va dirigido el estándar. Es decir, no existe un Merchant o comercio al uso como en PCI DSS y a su vez proveedores de servicio que soporten la actividad de los primeros, sino que las organizaciones a las que va dirigida el cumplimiento de PCI PIN se les considera proveedores de servicios de PIN, y no existe esa figura adicional de una entidad que haga el “trabajo sucio” en nombre de los primeros para facilitar el cumplimiento. Ahora, no decimos que no pueda existir algo en la línea de PCI DSS, solo que requiere de una narrativa adicional, y explicación de la actividad que desempeña la organización en los campos asignados y disponibles (y escasos) de la documentación oficial del SSC para PCI PIN. Si tratamos de identificar la sección de definición de servicios de la entidad que se somete a una evaluación de PCI PIN, en el AOC podríamos ver una aproximación en esta sección (en esta ocasión no tendremos un AOC diferente para Merchant y otro para Service Provider):
Por defecto, para el estándar PCI PIN existen dos tipos de organizaciones, aquellas que procesan transacciones con PIN, y agentes, dentro de los que se encuentran dos bien diferenciadas; tanto las entidades de certificación y registro, y las organizaciones que soportan un KIF, o instalación de inyección de claves. Digamos que los agentes “soportan” la actividad de adquirencia de transacciones con PIN con alguna otra actividad reconocida.
De acuerdo, vamos al grano, ¿Y si quiero moldear un rol de “pseudo agente” como es el caso de las compañías que disponen HSMs en cloud, que nos ocupan en este articulo? Podemos hacerlo, pero deberíamos describir con claridad en la sección “Others” de la imagen superior la actividad que estamos evaluando, con el detalle necesario (incluso con un desglose de controles que abordan en nombre de las organizaciones para las que trabajan), para que un tercero QPA cuando revise la actividad, por ejemplo de adqurencia con PIN en una organización que se soporte parcialmente en la actividad de este nuevo actor, sea capaz de identificar claramanet las responsabilidades que este nuevo “agente” realiza en nombre del proveedor de servicios de PIN y pueda asignar a los controles de este último un “In Place” gracias a la actividad del nuevo actor que además se puede validar en un AOC tangible.
Bien, validada la opción de emplear un tercero de manera similar a un proveedor PCI DSS, ¿Qué interés pudiese tener una organización que debe de abordar PCI PIN en emplear estos servicios de HSM en cloud de una tercera organización? Esto es algo que va a depender en gran medida del tipo de organización de la que estamos hablando. 
Por ejemplo, una entidad de certificación y registro, que basa su operativa en la gestión completa de una CA (Certification Authority) y una RA (Registration Authority), donde se podría resumir enormemente su actividad en la mera emisión de certificados; el núcleo de confianza en los esquemas de distribución remota de claves (RKL). La RA actúa como el filtro crítico de validación, encargada de verificar la identidad y legitimidad de los terminales en este contexto y la CA es el motor técnico que ejecuta la firma bajo un entorno de control dual riguroso. Estas entidades son las responsables de garantizar que la raíz de confianza sea inexpugnable, asegurando que cada certificado emitido sea el resultado de un proceso de registro auditado y una ejecución técnica blindada. Siendo realistas, no existe un número elevado de este tipo de organizaciones por su propia idiosincrasia; además de que la cohesión del producto en si complica el empleo de servicios HSM en cloud. Aunque por poder, podría ser viable, las organizaciones que han tratado de certificar sus servicios de HSM en Cloud se han orientado más a soportar a organizaciones de adquirencia o incluso KIFs. El interés de migrar una CA/RA hacia un modelo de Cloud HSM, en caso de existir, no sería solo una cuestión de ahorro en costes, sino una búsqueda de elasticidad, en la capacidad de desplegar una infraestructura de PKI robusta sin las servidumbres físicas del hardware on-premise, pero manteniendo el rigor criptográfico. Supondría escalabilidad de operaciones sin límites físicos, sujetos obviamente a la disponibilidad del servicio y las constantes que ofrezca el proveedor del Cloud HSM. Aunque estratégicamente puede ser interesante, habría que validar si el proveedor de cloud es capaz de satisfacer los controles del búnker físico requerido específicamente en el Anexo A2 de PCI PIN, que son mucho más exigentes que para el resto de las organizaciones, sobre todo por el riesgo e impacto que tiene la actividad de estas en procesos de adquirencia o distribución de claves remotamente, empleando técnicas asimétricas.
Donde realmente tiene sentido el empleo de este tipo de servicios es en organizaciones que procesan transacciones con PIN. Mantener un HSM es muy complicado en varios niveles. No solamente respecto a coste, ya que son productos muy caros debido a su propia naturaleza, sino que su mantenimiento y la necesidad de personal altamente cualificado en materia de gestión de claves, es realmente necesario. Puede considerarse a un HSM como un templo donde se consolidan los principios de control dual y conocimiento dividido a la hora de abordar procesos de gestión de claves en texto claro; lo que implica que cada vez que se generan claves, se exportan claves, se rotan claves, o existen ceremonias de claves, se requiera la presencia física no solo de los administradores del dispositivo, sino de los custodios del material de claves, y atiendan a lo que conocemos como ceremonias de claves, con el objetivo de respetar la integridad y confidencialidad del material delicado que se va a manipular.
Por lo tanto, necesitamos un espacio físico protegido donde alojar estos componentes críticos en los que se sustenta la arquitectura criptográfica de una organización, equivalente o igual a un CPD, con vigilancia, acceso restringido, además de un presupuesto elevado para adquirir y mantener a estos componentes, sin olvidar personal altamente cualificado y disponibilidad periódica para abordar ceremonias de claves…. ¿Qué ocurriría si todo este trabajo “sucio” podría ser derivado a un tercero? Pongamos una organización adquirente “básica” como ejemplo. Esta organización dispone de un HSM que almacena una LMK y además tiene un host de procesamiento de transacciones que aloja las claves de cifrado operativas en una base de datos, a su vez cifradas con la LMK del HSM. Cada operación de cifrado y descifrado requerirá una llamada al HSM para efectuar la operación, donde se trasladarán tanto el criptograma como la clave cifrada. Si esta compañía es capaz de contar con un tercero que posea el HSM, custodios para el material de claves, con capacidad de orquestar envíos y recepción de claves con otros adquirentes o terceras partes en su nombre, limitara mucho su impacto en los que al cumplimiento de PCI PIN se refiere. (sin mencionar la operativa involucrada).
Una vez integrado este proveedor, cada vez que necesite efectuar una operación de cifrado o descifrado, deberá redirigir la información al cloud en lugar de a sus instalaciones on-premise. La respuesta será equivalente y a lo sumo podrá incluir cierta latencia en las operaciones.
¿Es interesante? Desde luego, al menos desde el punto de vista PCI PIN, siempre que contemos con un partner certificado en estos servicios de Cloud HSM, servicios que estén claramente definidos en su AOC de cumplimiento, como hemos mencionado con anterioridad, y por qué no, detalle de controles abordados en su porfolio de servicios. La otra cara de la moneda será el coste del servicio, bien por volumen de operaciones, o por la manera de cuantificar el servicio que emplee la organización que provee el HSM as a service. Spoiler: El coste será significativo y podrá variar en cuanto a al nivel de servicio que se pueda diseñar (por ejemplo, podríamos encontrar un todo en uno, incluyendo custodios; o únicamente servicios de HSM remotos y necesidad de custodios de la propia organización para asistir a ceremonias. Las variantes pueden ser numerosas)
¿Y qué hay de las instalaciones de inyección de claves? ¿Tiene sentido el empleo de un servicio de HSMs en Cloud? En función de la actividad específica del propio KIF puede tener mayor o menor relevancia. Existen KIFs, con un enfoque cada vez más amplio, que emplean dispositivos de carga de claves para poner a punto el parque de terminales que deben de integrar en cada cliente. Esto significa que el material de claves ha sido inyectado en estos por el fabricante, o mediante componentes por custodios de la organización, en función del esquema de cifrado empleado, y no es necesario la existencia de un HSM. En cambio, puede darse el caso de que en el propio KIF se disponga de un HSM que intervenga en la inyección de claves únicas, gobernado por un SW de carga intermedio. O que se generen las claves TMK que corresponden a un esquema Maestro/Sesión siendo estas generadas por componentes, y a su vez lo operadores cargan los componentes en cada terminal. Analizando cada escenario de manera puntual podría evaluarse la ganancia y la viabilidad de emplear un proveedor de HSM en cloud. Es decir, pese a que el escenario que se antoja con mayor viabilidad de emplear este tipo de partners son aquellas organizaciones que procesan transacciones con PIN, podría darse el caso en el que pudiera ser empleado en un KIF, previo análisis de coste-beneficio y retorno de inversión.
Si cabe, un caso muy interesante que podría ser “ideal” para un KIF en cuanto al empleo de este tipo de proveedores, seria la de un KIF que se encargue de la rotación de claves de los terminales de manera remota. En este contexto, que también podría llevarse a cabo por las organizaciones adquirientes o procesadores (lo que es más habitual en el mundo real), podría ser viable disponer de una interfaz hacia el proveedor de HSM en Cloud para que en un extremo se atendiese a peticiones de rotaciones de claves y en otro extremo se conectase con los N terminales del cliente M de un KIF que necesitan rotar sus claves de trabajo acorde a un esquema especifico. En este contexto, también aplicable a las organizaciones adquirientes, la organización que disfruta del servicio tendría un ahorro en todas esas constantes que hemos ido mencionado durante este estudio (el propio dispositivo, licencias, espacio físico para alojar el dispositivo, etc.)
Habiendo visto el tipo de organizaciones que pueden disfrutar este tipo de servicios, vamos a pasar ahora a catalogar una muestra de controles específicos que se podrían cumplir por defecto al emplear un proveedor de este tipo, por ejemplo, para una organización básica que procesa transacciones con PIN:
▪️1-3 All hardware security modules (HSMs) shall be either FIPS140-2 or FIPS 140-3 Level 3 or higher certified, or PCI approved.
✅ Dado que los HSM son propiedad del partner del servicio Cloud HSM, es algo que
habría sido revisado en su evaluación y cumple en nombre de las organizaciones que
empleen su servicio.
▪️6-1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (for example, unknown cables) and must be inspected prior to the initialization of key-generation activities. Ensure there isn’t any mechanism that might disclose a clear-text key or key component (e.g., a tapping device) between the key-generation device and the device or medium receiving the key or key component.
✅ Por el mismo motivo que el ejemplo anterior, los equipos de generación de claves, en
una organización que procesa transacciones con PIN, si únicamente son aquellos que se
alojan en el proveedor, dará lugar a que este control será asignado a este último y
marcado como compliant en su cliente. Otra cosa será cómo se gestionen los
componentes generados. En función del servicio dispuesto, podría ser necesaria la
asistencia de custodios cliente al emplazamiento del proveedor, o que se incluya en el
servicio custodios de la organización que luego interactúen con las interfaces necesarias
para el intercambio de claves. Alineando esta práctica, eso sí, a que los custodios del
partner se consideran personal contratado tal y como indica el 25-1.1 (“Assigned key
custodians are employees or contracted personnel”)
▪️12-5 Hardware security module (HSM) Master File Keys, including those generated internal to the HSM and never exported, must be at least double-length keys and use the TDEA (including parity bits) or AES using a key size of at least 128 bits.
▪️23-2 An MFK used by host processing systems for encipherment of keys for local storage—and variants of the MFK—must not be used external to the (logical) configuration that houses the MFK itself. For example, MFKs and their variants used by host processing systems for encipherment of keys for local storage shall not be used for other purposes, such as key conveyance between platforms that are not part of the same logical configuration.
▪️29-4 Dual-control mechanisms must exist to prevent substitution or tampering of HSMs—both deployed and spare or back-up devices—throughout their life cycle. Procedural controls, which may be a combination of physical barriers and logical controls, may exist to support the prevention and detection of substituted HSMs but must not supplant the implementation of dual-control mechanisms.
✅ De nuevo en todos ellos, dado que los HSMs son propiedad
del partner del servicio Cloud HSM, es algo que habría sido
revisado en su evaluación y cumple en nombre de las
organizaciones que empleen su servicio.
¿Y cuál será la dimensión real e impacto de la integración de este tipo de partners en la organización? Esto será un punto que requiera un análisis detallado del contexto de la organización y de los servicios contratados con el Cloud HSM, para identificar qué controles son responsabilidad de una organización y cual están realmente cubiertos. Es algo que, como estrategia recomendada, puede gestionarse con ayuda de la propia empresa QPA que va a efectuar la evaluación de manera anticipada a esta.
Otro factor a tener en cuenta en lo que respecta a este tipo de proveedores es que el propio PCI SSC ha reconocido la realidad de los entornos Cloud a través de las Technical FAQs, que para PCI PIN son de obligado cumplimiento y tienen tanta relevancia como el propio estándar. Veamos una muestra especifica respecto a tópicos HSM en Cloud incluidos en la última version de los FAQ disponible:
| REQUISITO / FAQ | Cuestión | Posición del SSC | Comentario del Autor del Artículo |
| General Q5 | January 2020: Can an acquirer use third-party hosted HSM service⎯i.e., HSM in the cloud? | Yes, however the acquirer is responsible for ensuring that all applicable requirements regarding the management of the HSMs are met by the HSM cloud Provider. | Que se alinea con el enfoque que hemos planteado a lo largo del artículo, la organización adquiriente deberá de verificar que sus servicios están incluidos en su AOC y de manera deseable, en su portfolio de servicios, con suficiente detalle |
| General Q10 | May 2024: Can a service provider providing multi-tenant (i.e., concurrent multi-organizational usage) HSM services share secret or private cryptographic keys between tenants? | No. Secret and private cryptographic keys that are managed or owned by the HSM Service Provider to support each of their HSM tenant (clients) must be unique per HSM tenant. This would not apply to keys used to support an HSM’s Virtualization System (e.g., device authentication keys, firmware integrity keys, etc.). | Obviamente, el enfoque del SSC es acertado y no necesita de explicación adicional. Sin embargo, aquí vemos la inclusión de un requisito especifico que aplica a este tipo de organizaciones, debido al auge de estas. |
| General Q11 | May 2024: Can a service provider providing multi-tenant HSM services share the same master/storage ("Local Master Key" or "Master File Key") keys between HSMs? | No. Where multi-tenant HSM services are provided, master/storage keys that are not directly managed or owned by the HSM tenant must be unique per HSM instance, except in cases where a tenant instance pair/cluster has a designated purpose of load balancing or hot-spare backup. | De lo que se deriva que cada tenant deberá tener su partición lógica dentro del HSM con su propia clave maestra para sus operaciones. |
| General Q12 | May 2024: What additional requirements exist for multi-tenant HSMs? | An HSM Service Provider that provides cryptographic key storage and operations across multiple tenants must use both i) HSMs with multi-tenant features; and ii) procedural controls, that ensure: • Compromise of any key within the hierarchy of any one tenant does not impact the security of cryptographic keys for another tenant. • The cryptographic keys of any one tenant cannot be loaded, deleted, used for operational processing, or otherwise accessed in any way by another tenant. • The HSM tenant must be able to query the HSM configuration to determine settings meet the PCI PIN requirements. Changes to settings which may Impact how any PCI PIN requirement is met must be communicated to the HSM tenants prior to the change being made. • The multi-tenant HSM service provider must, at all times, meet all relevant PCI PIN requirements. |
Que vienen a reforzar y securizar el comportamiento de este tipo de organizaciones en auge, indicando limites y requisitos concretos que deben de cumplirse. |
Es interesante mencionar, como estamos observando en esta sección que los proveedores de HSM en Cloud serian considerados también proveedores de HSMs multi tenant. En el mercado también vamos a encontrar el concepto de proveedores HSMaaS (HSM as a service). Al final el incluir “cloud” en el nombre del servicio puede deberse a tendencias de la industria y propósitos comerciales, ya que no deja de ser un servicio de HSM gestionado por un tercero que posee físicamente un numero variable de HSMs que sirven para los propósitos de cifrado de sus clientes, servicio que además tiene un impacto directo en el cumplimiento del estándar PCI PIN en las organizaciones que disfruten de su uso.
A fin de cuentas, ¿Qué debería cualquier organización considerar si se plantea el empleo de servicios HSM en Cloud (o HSMs as a service) frente al no hacerlo?
✔️ Elasticidad y escalabilidad: La ventaja más obvia, ya que permite escalar la capacidad de cifrado al ritmo del negocio sin incurrir en grandes costes de capital, tiempos de adquisición de hardware, tiempos de puesta en marcha.
✔️ Reducción de carga operativa: La gestión del propio hardware (parches, firmware, racks, alimentación, refrigeración) pasa al proveedor del cloud, permitiendo al equipo de la organización enfocarse en la gestión de claves a lo sumo, ya que, en base del planteamiento del proveedor, pudiera está incluido también (incrementando obviamente, el coste del servicio).
✔️ Alta disponibilidad y resiliencia: Los proveedores de HSM en cloud o HSM as a service pueden ofrecer acuerdos de nivel de servicio (SLA) con redundancia geográfica que serían extremadamente costosos de replicar en un entorno on-premise.
✔️ Cumplimiento normativo: Muy a tener en cuenta, ya que pueden facilitar el proceso de manera considerable gracias al aporte de certificados oficiales de cumplimientos de estos partner que soportan el cumplimiento de la propia organización, y la gestión de los procesos de evaluación.
❌ Pérdida de control físico directo: Podría considerarse como el riesgo principal, con todo lo que conlleva. Aunque el proveedor certifique el entorno, se pierde la capacidad de respuesta inmediata y la auditoría visual del recinto donde reside el HSM (cabe decir que para el contexto PCI PIN no se plantearía una opción de un proveedor no certificado pero que “sí que cumpla” ya que la ganancia sería nula por la necesidad de validar la actividad de este en la propia certificación de la organización que usa sus servicios).
❌ Dependencia del proveedor: La migración de LMKs, rotación de claves operativas, compartición de material de claves entre extremos o con otros agentes, o entre diferentes HSMaaS puede ser compleja y costosa.
❌ Exigencia de un modelo de responsabilidad de cifrado compartida: El cliente que vaya a disfrutar de este tipo de servicios debe tener muy claro dónde terminan las obligaciones del proveedor y dónde comienzan las suyas (por ejemplo, en un escenario particular puede darse que un proveedor de Cloud es responsable de la integridad del HSM; y el propio cliente, de la rotación y custodia de las LMKs).
❌ Latencia o fallos de disponibilidad: Aunque cada vez es menor, el rendimiento “en la nube” puede introducir latencia en operaciones, especialmente si el HSM se encuentra geográficamente lejano al host que solicita la operación de la transacción. Un escenario aún peor sería la falla de disponibilidad, algo que debería de quedar reflejado en los SLAs entre partes.
Referencias
🔗 https://www.pcisecuritystandards.org/about_us/
🔗 https://www.pcisecuritystandards.org/document_library/
🔗 https://docs-prv.pcisecuritystandards.org/PIN/Reporting%20Template%20or%20Form/PCI_PIN_v3.1_ROC_Reporting_Template_1d.pdf
🔗 https://docs-prv.pcisecuritystandards.org/Programs%20and%20Certification/Qualified%20PIN%20Assessor%20(QPA)/Qualified_PIN_Assessor_(QPA)_Program_Guide_v1.2.pdf
🔗 https://docs-prv.pcisecuritystandards.org/PIN/Frequently%20Asked%20Questions%20(FAQ)/PCI_PIN_Technical_FAQs_v3_August_2025.pdf
