Gestionar las claves. Limitar el acceso.

Una clave nueva no significa que la antigua pueda eliminarse de inmediato. Determinamos qué datos, firmas o copias de seguridad siguen dependiendo de versiones anteriores. Las aplicaciones necesitan una asignación inequívoca a la versión de la clave. La generación, la activación, la revocación, el archivado y la eliminación reciben estados y aprobaciones separados. Los errores, como sesiones agotadas, inicios de sesión caducados o conexiones interrumpidas, se tratan de forma visible. Los reintentos no deben generar duplicados de clave no deseados ni operaciones duplicadas desde el punto de vista del negocio.

En la prueba comprobamos, además de las llamadas correctas, los roles rechazados y las operaciones no permitidas. Los medios de acceso y los secretos no deben llegar al código fuente, a los registros ni a las copias de seguridad generales. Su equipo recibe la configuración, escenarios de ejemplo y un procedimiento de diagnóstico. Para empezar es importante conocer las bibliotecas y los entornos de ejecución empleados, así como el inventario de claves existente.

PKCS #11 describe el acceso a tokens criptográficos y sus funciones. KMIP aborda la gestión de objetos criptográficos entre el cliente y el sistema de gestión de claves. Un servicio cloud, a su vez, puede ofrecer su propia API REST. De ello no se deriva una intercambiabilidad automática. OTOKO® documenta dónde se ejecuta cada operación, qué material de claves transmite realmente una interfaz y qué atributos se conservan. Así, una lista de protocolos se convierte en una ruta de integración comprensible.

En un cifrado jerárquico, las claves de datos pueden proteger los datos propiamente dichos, mientras que una clave de nivel superior protege esas claves de datos. Así se evita que cada bloque de datos de gran tamaño tenga que pasar por un HSM. Lo decisivo es dónde se necesita una clave de datos en texto claro y cuánto tiempo permanece disponible allí. Aclaramos el comportamiento de la caché, la rotación y el acceso en la aplicación. La afirmación «la clave permanece en el HSM» solo es válida para el rol de clave concreto que se analice y sus atributos.

Varios servicios utilizan hasta ahora sus propios archivos de claves. OTOKO® asigna primero propietarios, finalidades y dependencias de datos. A continuación, probamos la integración compatible de un servicio representativo y definimos permisos por aplicación. La migración se realiza de forma escalonada, con lectura controlada de los datos existentes y escritura de los datos nuevos. Las claves antiguas solo se retiran cuando se han tenido en cuenta la conservación, las copias de seguridad y la recuperación. El resultado es un inventario de claves documentado con procedimientos de uso y sustitución probados.