¿Debería prohibirse a un sistema de prueba / demostración / no producción usar el mismo HSM que la producción? Dado que la misma clave maestra se usaría tanto para la prueba como para la presión, parece que podría llamar la atención pero no puedo encontrar ninguna guía específica sobre este tema.
Sí.
Compartir los mismos HSM (s) en múltiples entornos (por ejemplo, dev, test, pre-prod, production) es el equivalente corporativo de usar la misma contraseña en varios sitios web.
Muchas grandes empresas copian periódicamente sus datos de producción en sus entornos de QA / prueba. Estos entornos inferiores suelen tener controles de acceso a datos mucho menos estrictos. Esto significa que si los mismos HSM están en uso en ambas ubicaciones, los datos que se habían protegido adecuadamente en el entorno de producción podrían ser accedidos indebidamente en un entorno de no producción y luego filtrarse al mundo exterior (o "exfiltrados", por ejemplo). aquellos de ustedes que usan Google para encontrar esto). Por lo tanto, la defensa contra esto es garantizar que no haya una forma posible en que los sistemas de no producción puedan acceder a las claves que los sistemas de producción utilizaron para proteger los datos. Lo que significa infraestructuras de HSM separadas para producción y no producción.
Y desde una perspectiva de PCI, si simplemente puede decirle a sus auditores que sus entornos que no son de producción simplemente no tienen forma de acceder a las claves utilizadas para proteger los datos de producción, eso le ahorraría más que el costo de los HSM adicionales .
Lo importante es esto:
Aunque el HSM se encarga de una gran parte de la administración, no lo exime de las obligaciones descritas en los estándares en los que está trabajando.
Estoy seguro de que hay una verborrea similar en cualquier otro estándar con el que estarías trabajando.
Desde una perspectiva PCI-DSS:
En el estándar PCI-DSS 2.0, sección 3.5.1 y 3.5.2b:
3.5.1 Examine user access lists to verify that access to keys is restricted to the fewest number of custodians necessary.
3.5.2.b Identify key storage locations to verify that keys are stored in the fewest possible locations and forms.
En términos generales, un entorno de control de calidad tiene un número mucho mayor de personas con acceso al sistema, lo que infringiría la 3.5.1. Si una infracción en el sistema de control de calidad permitiera una interrupción en la producción, estoy seguro de que 3.5.2.b también se retiraría.
Una de las inquietudes que puede tener con el uso de un solo HSM para diferentes entornos es que los requisitos clave de administración para los entornos Dev / Test pueden no ser compatibles con los requisitos de un entorno de producción.
Por ejemplo, entiendo que algunos HSM se pueden colocar en un modo de "desarrollo o prueba" que puede permitir recuperar material clave del HSM.
Esto podría ser deseable en un dev. entorno con fines de depuración, pero sería extremadamente indeseable en un entorno de producción.
Así que mi conclusión sería que si el HSM se gestiona en todo momento como un HSM de producción, no debería haber ningún problema en particular, pero esto podría reducir su utilidad como un HSM de prueba / demostración. ...
Lea otras preguntas en las etiquetas key-management hsm