Resumen: ILM ahora realiza por sí mismo la firma y el sellado de tiempo RFC 3161, con perfiles de firma, registros por operación y endpoints autenticados de sellado de tiempo. Eso significa un inventario, un modelo de autorización y una pista de auditoría únicos para certificados, claves, secretos, firmas y sellos de tiempo.
La firma y el sellado de tiempo suelen pertenecer al sistema de otra persona. Por eso nadie puede responder, con una sola consulta, qué operaciones criptográficas realizó una organización el mes pasado.
Pregunte a un equipo de seguridad dónde están sus certificados y normalmente obtendrá una respuesta clara. Pregunte dónde están sus claves de firma, quién las utilizó la semana pasada y qué autoridad de sellado de tiempo marcó el resultado, y la respuesta llegará fragmentada. Los certificados están en una plataforma. La firma se ejecuta en otra. El sellado de tiempo es una URL que alguien configuró hace años.
Ninguno de esos sistemas está mal por sí solo. Sin embargo, las uniones entre ellos son el lugar donde la gobernanza falla silenciosamente. Cada sistema tiene su propio modelo de identidad, su propio formato de registro y su propia idea de lo que un operador puede hacer.
ILM ha ido cerrando esas brechas durante varias versiones. Primero llegaron los certificados, después las claves criptográficas, luego los secretos y después las listas de materiales criptográficos. La firma y el sellado de tiempo son las incorporaciones más recientes y son, precisamente, las que con mayor frecuencia viven fuera de la plataforma.
Los perfiles de firma definen cómo; los registros de firma demuestran qué
La firma en ILM comienza con un perfil de firma. El perfil es donde reside la configuración: qué clave, bajo qué perfil de token y con qué restricciones. Como el perfil es un objeto gestionado, hereda el modelo de autorización de la plataforma en lugar de definir uno privado.
Después viene la parte que lo hace operable. Cada operación de firma produce un registro de firma. Cada perfil de firma expone un endpoint que enumera sus registros, y el panel de la plataforma muestra estadísticas de firma junto con las cifras de certificados y claves que ya estaban allí.
Por consiguiente, «quién firmó qué, cuándo y con qué clave» es una consulta en lugar de una investigación. Esa diferencia importa durante una auditoría y aún más durante un incidente. En la práctica, una capacidad de firma que no puede producir su propio historial es una capacidad que no puede defenderse.
ILM también implementa la API de Cloud Signature Consortium como un componente independiente, para que los clientes de firma remota compatibles con CSC dispongan de una vía estándar de acceso.
Sellado de tiempo que habla el estándar que ya hablan sus herramientas
Una firma sin una referencia temporal de confianza es más débil de lo que parece. Una vez que expira el certificado de firma, resulta difícil verificar que la firma existía mientras el certificado era válido. Por tanto, el sellado de tiempo no es un complemento opcional de la firma; forma parte de hacer que una firma sea duradera.
ILM gestiona el sellado de tiempo mediante perfiles TSP y un motor administrado de sellado de tiempo. El motor realiza la operación y endpoints RFC 3161 invocables la exponen. Como esos endpoints siguen el estándar, los clientes existentes y las herramientas de compilación funcionan sin modificaciones.
El acceso se controla correctamente en lugar de depender de la posición en la red. Los perfiles TSP incluyen métodos de autenticación y credenciales Basic, y un filtro de autenticación dedicado se sitúa delante de los endpoints de sellado de tiempo. Además, una caché de perfiles TSP mantiene la búsqueda del perfil fuera de la ruta de la solicitud, algo importante cuando un pipeline sella miles de artefactos.
Qué aporta realmente la consolidación
Es fácil afirmar que se consolida una plataforma y también es fácil exagerarlo. Así que aquí está la versión concreta, expresada como diferencias en lugar de adjetivos.
| Aspecto | Sistemas separados | Una sola plataforma |
|---|---|---|
| Inventario | Certificados aquí, claves de firma allí, configuración de sellado de tiempo en otro sitio | Un único inventario que cubre certificados, claves, secretos, firmas y sellos de tiempo |
| Autorización | Cada sistema tiene sus propios roles y su propia definición de operador | Un único modelo de autorización, incluido un rol de auditor de solo lectura |
| Pista de auditoría | Varios formatos de registro, correlacionados manualmente después de los hechos | Registros de firma e historial de eventos en el mismo lugar que el historial de certificados |
| Custodia de claves | Claves duplicadas o exportadas para llegar al servicio de firma | Las claves permanecen bajo su perfil de token; la firma hace referencia a ellas |
| Informes | Respuestas parciales por sistema | Estadísticas del panel para todas las operaciones |
La fila de custodia de claves merece una pausa. Siempre que un servicio de firma vive fuera del sistema que gestiona las claves, algo tiene que cruzar el límite. Normalmente ese algo es la clave o una copia de ella. Mantener la firma junto a la gestión de claves elimina la necesidad de ese traslado.
Dónde están los límites reales
La consolidación no es lo mismo que el reemplazo, y preferimos ser precisos al respecto.
ILM no reemplaza un módulo de seguridad de hardware. Las claves siguen viviendo donde su política diga que deben vivir, e ILM hace referencia a ellas mediante un perfil de token. Del mismo modo, ILM no decide su política de firma ni sus elecciones de algoritmos criptográficos. Les proporciona un único lugar donde configurarse y un único registro de su aplicación.
Tampoco trasladar la firma a la plataforma elimina la necesidad de servicios de confianza cualificados cuando la regulación los exige. Si un caso de uso requiere un sello de tiempo cualificado de un proveedor cualificado, ese requisito no cambia porque su plataforma también pueda sellar tiempos.
Un paraguas es útil porque cubre todo a la vez, no porque sustituya al cielo.
Primeros pasos
Si ya utiliza ILM, ambas capacidades son configuración en lugar de despliegue. Cree un perfil de firma sobre un perfil de token existente y cree un perfil TSP con un método de autenticación. Después, apunte un cliente al endpoint RFC 3161 y compruebe que aparece un registro de firma.
Si está evaluando ILM, la firma y el sellado de tiempo son un punto razonable para empezar precisamente porque suelen estar separados. Configúrelos junto con unos cuantos certificados y observe si un único panel puede responder preguntas que antes requerían tres sistemas.
Puntos clave
- Los perfiles de firma contienen la configuración; los registros de firma contienen la evidencia, se pueden enumerar por perfil y se resumen en el panel.
- El sellado de tiempo se ejecuta en un motor administrado detrás de endpoints RFC 3161 invocables, por lo que las herramientas existentes funcionan sin cambios.
- Los perfiles TSP incluyen métodos de autenticación y credenciales Basic, con un filtro de autenticación delante de los endpoints.
- Mantener la firma junto a la gestión de claves elimina la necesidad de mover claves para llegar a un servicio de firma.
- ILM no reemplaza un HSM, no establece su política criptográfica ni elimina los requisitos regulatorios de servicios de confianza cualificados.
La firma y el sellado de tiempo llegaron a lo largo de las versiones 2.18.0 y 2.19.0; consulte qué más cambió en 2.19.0. Para una visión más amplia de lo que cubre la plataforma, lea 10 cosas que puede crear con ILM y por qué Trust Lifecycle Management debe incluir secretos. Para hablar sobre un despliegue de firma o sellado de tiempo, póngase en contacto con nosotros.
