HSM en la nube con un control de claves claro.

La conexión privada, la resolución de nombres, la autenticación y la latencia influyen en cada llamada criptográfica. Probamos la conexión con el perfil de carga real y planificamos el comportamiento en caso de conexión interrumpida. Un segundo punto de conexión solo ayuda si allí también están disponibles las claves y los permisos adecuados. Los servicios de claves externos o las claves gestionadas por el cliente difieren además en qué datos y servicios controlan realmente. Documentamos estos límites de forma que los responsables de negocio comprendan la influencia que conserva el proveedor.

Un plan de salida describe qué claves se pueden exportar, qué datos habría que volver a cifrar y qué servicios hay que sustituir. También forman parte de él los plazos, las confirmaciones de eliminación y las dependencias de las copias de seguridad. En el proyecto acordamos objetivos de operación alcanzables y comprobamos el restablecimiento y la revocación de permisos. Sin esta comprobación, una promesa genérica de portabilidad completa no sería fiable.

AWS CloudHSM y Azure Key Vault Managed HSM representan modelos de integración y operación distintos. AWS CloudHSM ofrece conexiones de cliente HSM para las aplicaciones que se prestan a ello; Azure Managed HSM proporciona un servicio de claves gestionado con integración en Azure. Comprobamos la API, los tipos de clave, las identidades y el modelo de recuperación para cada carga de trabajo. Por eso, un cambio de servicio no consiste simplemente en sustituir una dirección de servidor. Lo decisivo es si la aplicación concreta y el alcance de control exigido se ajustan al servicio.

Bring Your Own Key (BYOK) describe, en primer lugar, la incorporación de material de clave propio a un servicio compatible. Por sí sola, no responde a quién puede iniciar operaciones con la clave ni dónde se procesan los datos en texto claro. En la gestión externa de claves se añaden dependencias técnicas adicionales, por ejemplo un servicio externo para determinadas operaciones de autorización o de desempaquetado. Documentamos estos límites de confianza y probamos también la revocación selectiva de permisos. Las funciones y limitaciones se comprueban para el servicio cloud concreto.

Una aplicación existente debe trasladarse, pero su operación de claves debe seguir siendo controlable. OTOKO® comprueba primero si se puede seguir utilizando la interfaz existente o si es necesaria una adaptación. En el piloto medimos los tiempos de respuesta desde la red de destino, comprobamos la separación de roles de administrador y probamos la recuperación. El plan de salida describe tanto las claves exportables como los casos en los que sería necesaria una nueva generación de claves y una migración de datos. De ahí resulta un modelo de operación con responsabilidades asignadas.