Cómo crear un inventario de activos criptográficos en la nube, CI/CD y dispositivos.

Respuesta rápida: Un inventario de activos criptográficos es un registro estructurado y actualizado continuamente de cada certificado, clave, algoritmo y dependencia criptográfica en toda su infraestructura en la nube, canalizaciones de CI/CD y dispositivos. Es importante porque no puede rotar un certificado, responder a la obsolescencia de un algoritmo ni planificar una migración de PQC para activos cuya existencia desconoce. Los plazos de cumplimiento, como la vida útil de 47 días de los certificados del CA/B Forum (hasta marzo de 2029) y la obsolescencia de algoritmos de NIST IR 8547 para 2030/2035, hacen que esto sea urgente. La acción recomendada es implementar un descubrimiento automatizado y continuo en los tres entornos, en lugar de depender de escaneos periódicos u hojas de cálculo, ya que la infraestructura cambia más rápido de lo que cualquier proceso manual puede rastrear.

Puntos Clave

• Un inventario completo abarca mucho más que los certificados TLS: claves, autoridades de certificación, raíces de confianza de hardware, conjuntos de cifrado, bibliotecas criptográficas y un CBOM para la visibilidad en tiempo de compilación.
• La infraestructura en la nube, las canalizaciones de CI/CD y los dispositivos conectados presentan desafíos de descubrimiento distintos, y es ahí donde la mayoría de las organizaciones tienen los mayores puntos ciegos.
• La propuesta SC-081v3 del Foro CA/B reduce la duración máxima de los certificados TLS a 47 días para marzo de 2029, con una reducción gradual a 200 días (marzo de 2026) y 100 días (marzo de 2027), lo que hace que la automatización sea innegociable.
• El documento NIST IR 8547 (borrador) propone dejar de utilizar algoritmos de 112 bits como RSA-2048 después de 2030 y prohibir por completo RSA/ECC después de 2035, y no se puede iniciar una migración sin saber dónde se encuentran esos algoritmos.
• Un CBOM registra qué criptografía está integrada en un sistema; el descubrimiento en tiempo de ejecución registra qué está realmente implementado. Ambos son necesarios y responden a preguntas diferentes.

La brecha de visibilidad criptográfica

La mayoría de los equipos de seguridad pueden describir sus reglas de firewall. Sin embargo, son muchos menos los que pueden precisar cuántos certificados se están ejecutando en su entorno actualmente, cuáles caducan en los próximos 30 días, si alguna de sus canalizaciones de CI/CD está enviando una clave privada codificada a producción, o dónde se almacenan sus claves KMS, claves SSH, claves de firma JWT y secretos de autenticación de API.

La brecha entre «usamos criptografía en todas partes» y «sabemos dónde reside cada activo criptográfico» es precisamente lo que un inventario criptográfico busca cerrar. La urgencia es real y proviene de múltiples frentes simultáneamente. Sin un inventario completo y actualizado, las organizaciones carecen de una base de referencia: no tienen forma de saber qué certificados están por vencer, qué algoritmos se implementan y dónde, ni qué activos se verán afectados cuando una CA se vea comprometida o un estándar quede obsoleto.

Más allá del riesgo operativo, el plazo para el cumplimiento normativo también está en marcha. La propuesta SC-081v3 del Foro CA/B, aprobada en abril de 2025, anunció una reducción en la duración máxima de los certificados TLS públicos de 398 días a 47 días para marzo de 2029, con reducciones graduales de 200 días a partir del 15 de marzo de 2026 y de 100 días a partir del 15 de marzo de 2027.

En el ámbito cuántico, la norma NIST IR 8547, actualmente un borrador público inicial (noviembre de 2024) y sujeta a revisión, desaconseja el uso de algoritmos de seguridad de 112 bits (por ejemplo, RSA-2048, ECC P-224) a partir de 2030 y prohíbe todos los algoritmos RSA y ECC, incluidos los de mayor tamaño de clave como RSA-3072 y ECC P-256, a partir de 2035. No se puede iniciar una migración sin saber dónde se implementan dichos algoritmos. Si bien la vida útil de los certificados se está reduciendo debido a las preocupaciones sobre la seguridad operativa, la preparación para la computación cuántica plantea un desafío de migración criptográfica a mucho más largo plazo.

Este blog explica cómo crear un inventario de activos criptográficos que funcione correctamente en los tres entornos donde la mayoría de las organizaciones presentan mayores puntos ciegos: infraestructura en la nube, pipelines de CI/CD y dispositivos conectados. En estos tres entornos, los activos criptográficos se implementan rápidamente, a menudo fuera de la supervisión de seguridad centralizada, y suelen ser invisibles para los métodos de detección tradicionales basados ​​en la red. Abordaremos qué descubrir, cómo descubrirlo y cómo mantener la precisión de los datos para poder actuar en consecuencia.

Definición del inventario criptográfico

Un inventario criptográfico es un registro estructurado y actualizado continuamente de todos los activos criptográficos que su organización utiliza en toda su infraestructura. Imagínelo como un mapa dinámico: no solo muestra las herramientas criptográficas que tiene implementadas actualmente, sino también dónde se encuentran, qué protegen, quién las posee, cómo están configuradas, qué depende de ellas, en qué etapa de su ciclo de vida se encuentran y si aún cumplen su función.

Como señalan las directrices de migración de NIST PQC, la norma NSA CNSA 2.0 y las recomendaciones de criptoagilidad de ETSI, muchos sistemas actuales carecen de criptoagilidad porque no fueron diseñados para actualizaciones criptográficas rápidas, y las organizaciones a menudo desconocen dónde se utiliza toda su criptografía . Precisamente ese punto ciego es lo que aborda un inventario adecuado.

Un buen inventario criptográfico responde a cuatro preguntas para cada activo que contiene:

• ¿Qué es y dónde reside? El tipo de activo, el algoritmo y los parámetros clave que utiliza, su propósito criptográfico (como la terminación TLS, el cifrado de datos en reposo o en tránsito, la firma de código) y el uso de la clave (cifrado, firma, autenticación), la cadena de confianza en la que participa y el sistema, servicio o dispositivo específico al que está vinculado.
• ¿De quién es el responsable? La rendición de cuentas sin un responsable es solo una lista de problemas sin nadie encargado de solucionarlos. Todo activo necesita un equipo responsable.
• ¿Qué depende de ello? ¿Qué servicios o sistemas empresariales dependen de este activo y cómo están conectados a él? Un certificado puede formar parte de una cadena donde múltiples servicios comparten una dependencia de la misma CA intermedia. Comprender esas relaciones es lo que transforma un hallazgo de «certificado débil» en «certificado débil cuyo fallo se propaga a través de los sistemas dependientes».
• ¿Sigue siendo aceptable? ¿Cumple con los requisitos de la política actual en cuanto a longitud de clave, algoritmo y validez? ¿Caducará pronto? ¿Coincide con lo que debería estar presente según la política de configuración?

¿Qué abarca un inventario completo?

El alcance es más amplio de lo que la mayoría de los equipos suponen. Muchos comienzan con certificados TLS y se detienen ahí. Pero los certificados son solo una capa. Un inventario completo abarca los siguientes activos.

Los certificados constituyen la capa más visible: certificados de servidor TLS, certificados de cliente utilizados en mTLS, certificados de firma de código , certificados de correo electrónico, certificados de respondedor OCSP, certificados de firma de CRL, certificados de identidad de dispositivo y los almacenes de confianza que determinan qué CA raíz aceptan sus sistemas. Esto incluye los certificados autofirmados, que a menudo se olvidan y suelen causar problemas en los sistemas internos.

Las claves criptográficas y el material de clave se encuentran bajo los certificados. Las claves privadas asociadas a los certificados deben controlarse para garantizar su propiedad, ubicación de almacenamiento, controles de acceso y estado de rotación. Además de las claves de certificado, las claves simétricas utilizadas para el cifrado de datos en reposo, las claves de firma de API, las claves SSH, las claves de cifrado de bases de datos, las claves de firma de tokens, las claves KMS en la nube y los secretos almacenados en bóvedas o módulos de seguridad de hardware (HSM) también deben incluirse en el inventario. La ubicación de almacenamiento de las claves también es importante: una clave en un almacén de claves de software presenta un nivel de riesgo diferente al de una clave en un módulo de seguridad de hardware FIPS 140-3 Nivel 3.

Las autoridades de certificación (tanto las CA internas que usted gestiona como las externas en las que confía) son activos criptográficos. La longitud de las claves, los algoritmos de firma, los periodos de validez y la configuración CRL/OCSP de sus CA emisoras determinan el nivel de seguridad de cada certificado que emiten. Es necesario registrar la jerarquía completa de las CA: CA raíz, CA intermedias y cualquier CA subordinada o emisora ​​que se encuentre por debajo de ellas. Cada nivel de la cadena tiene su propio material de clave, periodo de validez, algoritmo de firma y configuración de revocación.

Los anclajes de confianza y las raíces de confianza de hardware completan el panorama. Estos incluyen TPM (utilizados en servidores y terminales), elementos seguros (comunes en dispositivos IoT y móviles), enclaves seguros, claves de arranque seguro que controlan qué firmware e imágenes de sistema operativo puede cargar un dispositivo, mecanismos de atestación respaldados por hardware que permiten a los dispositivos demostrar su identidad e integridad ante sistemas remotos, y raíces de hardware integradas en los dispositivos. Algunos de estos elementos no se pueden actualizar después de la fabricación, lo que tiene implicaciones específicas para la planificación de la migración post-cuántica.

Los algoritmos, los conjuntos de cifrado y las configuraciones de protocolo son la capa que la mayoría de las organizaciones pasan por alto por completo. Saber que un sistema usa TLS no es suficiente. ¿Qué versión está ejecutando? ¿Qué conjuntos de cifrado están habilitados? ¿Qué mecanismos de intercambio de claves utiliza? Si un sistema está configurado para aceptar TLS 1.0 como alternativa o usa RSA de 1024 bits no es visible en un simple escaneo de certificados de alto nivel. Esta información proviene de un análisis exhaustivo de la configuración que abarca los algoritmos de firma (RSA, ECDSA, EdDSA), los algoritmos de intercambio de claves (ECDH, DHE y sus equivalentes resistentes a ataques cuánticos) y los algoritmos hash (SHA-1, SHA-256 , SHA-384) utilizados en cada sistema.

Es necesario realizar un seguimiento de las bibliotecas criptográficas, tanto por versión como por vulnerabilidades conocidas. OpenSSL, Bouncy Castle, wolfSSL, Botan y Microsoft CNG constituyen la base de las implementaciones criptográficas en diversas aplicaciones y servicios. Las versiones obsoletas o sin soporte de cualquiera de ellas introducen riesgos de seguridad, incluso cuando se configuran algoritmos robustos. Dado que cada biblioteca tiene su propio historial de vulnerabilidades, conjunto de características y ciclo de vida de soporte, el inventario debe registrar qué bibliotecas criptográficas y versiones se utilizan en las distintas aplicaciones y servicios.

Una lista de materiales criptográficos (CBOM, por sus siglas en inglés) es un registro estructurado de la criptografía presente en un sistema de software, una imagen de firmware o un dispositivo. Enumera los algoritmos, los tamaños de clave, las bibliotecas criptográficas, los certificados y los protocolos en uso. Una CBOM no descubre los activos por sí sola. Captura la información presente en un artefacto de software mediante análisis estático o en tiempo de compilación. Esto difiere del descubrimiento en tiempo de ejecución, que rastrea lo que se está ejecutando en el entorno. Se necesitan ambos: la CBOM indica lo que se ha integrado; el descubrimiento en tiempo de ejecución indica lo que está en funcionamiento.

Por qué el inventario es lo primero

El inventario no es una tarea preparatoria que se realiza antes de que comience el trabajo de seguridad propiamente dicho. Es un requisito previo para cada acción posterior.

No se puede rotar un certificado cuya existencia se desconoce. No se puede responder a la obsolescencia de un algoritmo si se desconoce qué sistemas lo utilizan. No se puede planificar una migración de PQC sin un mapa de las implementaciones de RSA y ECC. Y durante un período de renovación de certificados de 47 días, no se pueden mantener operaciones de renovación manuales en miles de certificados sin un inventario preciso y actualizado que impulse la automatización.

Para ilustrarlo mejor: cuando se produce una brecha de seguridad en una CA, la primera pregunta siempre es: "¿Qué certificados emitimos a través de esa CA?". Las organizaciones que no cuentan con un inventario actualizado dedican las primeras 24 horas a responder esta pregunta en lugar de revocar y volver a emitir certificados. Cuando OpenSSL lanza una vulnerabilidad crítica, los equipos que responden con mayor rapidez son aquellos que pueden consultar de inmediato qué aplicaciones ejecutan la versión afectada. Cuando se dejó de usar SHA-1, las organizaciones que se vieron desprevenidas fueron aquellas que no contaban con un método sistemático para identificar todos los certificados SHA-1 en su entorno. En ambos casos, el inventario no era un lujo, sino la clave para una respuesta eficaz y una reacción desesperada.

Esta es también la razón por la que las hojas de cálculo estáticas fallan. Un entorno en constante cambio, con nuevas implementaciones, actualizaciones de configuración, aprovisionamiento en la nube y lanzamientos de software, superará en cuestión de semanas cualquier lista mantenida manualmente. El inventario debe ser continuo y automatizado para seguir siendo útil.

Cómo crear tu inventario de activos criptográficos

Una cosa es saber qué incluir en un inventario criptográfico. Otra muy distinta es crear uno que funcione correctamente en un entorno empresarial real. La mayoría de las organizaciones tienen activos criptográficos distribuidos en cargas de trabajo en la nube, flujos de trabajo de desarrollo y dispositivos físicos, y a menudo ningún equipo tiene visibilidad de los tres. Los pasos que se describen a continuación explican cómo abordar el descubrimiento en cada entorno, cómo integrar esos datos para que sean útiles y cómo evitar que queden obsoletos.

Paso 1: Establecer la visibilidad criptográfica en toda la infraestructura en la nube.

La infraestructura en la nube es donde la proliferación criptográfica es más rápida. Los certificados y las claves son emitidos y consumidos por instancias de computación, bases de datos administradas, pasarelas API, plataformas de contenedores, balanceadores de carga, mallas de servicios y servicios de CA nativos de la nube.

Qué descubrir:

• Certificados y claves en recursos IaaS y PaaS, incluidos los gestionados por servicios de CA nativos de la nube.
• Los recursos de KMS en la nube, incluidas las claves de AWS KMS, los secretos y certificados de Azure Key Vault, los llaveros de Google Cloud KMS y los HSM administrados, a menudo se tratan como infraestructura opaca en lugar de activos criptográficos que requieren inventario.
• Configuración criptográfica en balanceadores de carga, pasarelas y mallas de servicios, que con frecuencia mantienen almacenes de certificados independientes.
• Certificados emitidos directamente a través de los servicios de certificación del proveedor de la nube, que pueden no enrutarse a través de su infraestructura de clave pública (PKI) interna.

El principal desafío en entornos de nube radica en la propiedad y el alcance. Un certificado proporcionado por un desarrollador a través de una API en la nube puede no figurar en ningún registro central, y una clave KMS utilizada para el cifrado de datos puede carecer de metadatos asociados que la vinculen con la aplicación o el equipo propietario. El descubrimiento automatizado y continuo, tanto de certificados como de servicios criptográficos, es la única solución práctica para mantenerse al día con la velocidad de cambio de la infraestructura nativa de la nube. Los análisis puntuales quedan obsoletos rápidamente. El objetivo es una transmisión de datos en tiempo real, no una instantánea.

Paso 2: Ampliar el descubrimiento al proceso de entrega de software

Las canalizaciones de CI/CD se encuentran entre los puntos ciegos más frecuentes en los inventarios criptográficos y entre las de mayor riesgo. También constituyen un vector principal para los ataques a la cadena de suministro de software. Se han utilizado canalizaciones de compilación comprometidas para inyectar código malicioso en artefactos firmados en los que los consumidores finales habían confiado implícitamente. Esto convierte el material criptográfico en su infraestructura de compilación en una brecha de seguridad y una superficie de ataque activa.

El material criptográfico integrado en las aplicaciones durante el proceso de compilación no aparece en los análisis de certificados a nivel de red, lo que convierte el descubrimiento de la canalización en una disciplina distinta del análisis de la infraestructura.

Qué buscar:

• Certificados y claves integrados en configuraciones de compilación, Dockerfiles y plantillas de infraestructura como código.
• Bibliotecas criptográficas incluidas en el código fuente o compiladas en binarios de la aplicación, con su versión y estado CVE.
• Claves y secretos codificados o reutilizados que se hayan incluido en el control de versiones, incluidas las confirmaciones históricas que pueden ya no estar presentes en la rama actual, pero que siguen siendo accesibles a través del historial del repositorio.
• Certificados y claves de firma de código utilizados para firmar artefactos de compilación, incluidas integraciones con servicios de firma de compilación como Sigstore y Cosign.
• Los flujos de trabajo de firma de artefactos y las claves que los respaldan.
• Los procesos de generación de SBOM y CBOM deben considerarse como infraestructura criptográfica.

El concepto CBOM resulta útil en este caso. Generar un CBOM para cada versión de la aplicación proporciona un registro estructurado de las capacidades criptográficas integradas, lo que permite a las organizaciones realizar un seguimiento de las dependencias criptográficas a medida que las aplicaciones evolucionan. Sin embargo, el CBOM debe combinarse con el descubrimiento en tiempo de ejecución para cerrar la brecha entre lo que admite el binario y lo que realmente hace la instancia desplegada.

Integrar las prácticas de inventario criptográfico en el propio proceso de CI/CD, en lugar de tratarlas como una cuestión posterior al despliegue, es el enfoque más práctico. El análisis de secretos en las etapas previas a la confirmación y la fusión detecta el código incrustado antes de que llegue a producción. El análisis de bibliotecas durante la compilación identifica las dependencias criptográficas obsoletas o vulnerables antes de su distribución.

Paso 3: Abordar la exposición criptográfica en dispositivos y firmware

Estos dispositivos crean una categoría de riesgo criptográfico que no existe en los entornos de nube o de procesamiento en cadena: los activos son difíciles de alcanzar, difíciles de actualizar y, a menudo, siguen funcionando durante años o décadas después de su implementación inicial.

Los dispositivos de larga duración acumulan deuda criptográfica de maneras que pueden pasar desapercibidas. Una imagen de firmware que se envía con una versión específica de una biblioteca criptográfica no se actualiza automáticamente. Un certificado de identidad del dispositivo emitido en el momento de la fabricación puede tener un período de validez de 10 años y carecer de un mecanismo de renovación automática. Las decisiones criptográficas tomadas al diseñar el dispositivo pueden no reflejar los estándares actuales, y para los dispositivos que ya están en funcionamiento, la solución puede implicar una actualización completa del firmware o un reemplazo físico.

Qué inventariar:

• Los certificados de identidad de los dispositivos y las bases de confianza que los sustentan.
• Las claves de arranque seguro y los certificados de firma de firmware suelen ser más críticos para el funcionamiento que los certificados TLS en el mismo dispositivo. Una clave de firma de firmware comprometida implica dispositivos comprometidos a gran escala.
• Claves de autenticación de dispositivos utilizadas en flujos de trabajo de autenticación remota.
• Las claves privadas se almacenan en hardware dedicado, como TPM y elementos seguros.
• Claves de firma de código de larga duración utilizadas para autenticar las actualizaciones de firmware y software.
• Bibliotecas criptográficas y configuraciones de algoritmos en imágenes de firmware.

Esta categoría merece especial atención en el contexto de la criptografía de clave pública debido a la amenaza de "recolectar ahora, descifrar después" (HNDL). Según este modelo de amenaza, los adversarios podrían recopilar y almacenar tráfico cifrado hoy, con la expectativa de que los avances futuros en computación cuántica permitan descifrar los datos protegidos por los algoritmos criptográficos de clave pública actualmente implementados.

Los sistemas y dispositivos que se prevé que permanezcan en servicio durante muchos años son motivo de especial preocupación, ya que podrían seguir dependiendo de algoritmos criptográficos vulnerables a la computación cuántica mucho después de su implementación. Por lo tanto, identificar estos activos con una larga vida útil y requisitos de confidencialidad a largo plazo es fundamental para evaluar la exposición criptográfica futura y priorizar los esfuerzos de migración a PQC.

Paso 4: Consolidación y normalización de los datos de inventario

El análisis de datos en tres entornos genera información en tres formatos diferentes a partir de tres conjuntos de herramientas. Los datos brutos del análisis no constituyen un inventario, sino su base. El proceso de normalización permite convertir los registros dispersos en información útil para realizar consultas, generar informes y tomar decisiones.

La normalización es importante porque los datos inconsistentes crean puntos ciegos incluso después de que se haya completado el descubrimiento. Por ejemplo, una fuente puede registrar un algoritmo como "RSA-2048", mientras que otra lo registra como "RSA 2048" o simplemente "2048". Sin normalización, estos podrían tratarse como activos distintos. Del mismo modo, si las huellas digitales de los certificados no se capturan de forma consistente, el mismo certificado descubierto a través de múltiples rutas de escaneo puede aparecer varias veces en el inventario.

Las convenciones de nomenclatura y los metadatos inconsistentes entre los proveedores de nube y las plataformas de gestión también pueden dificultar la atribución de propiedad y la correlación de activos. Concretamente, la normalización implica estandarizar el tamaño de las claves RSA para lograr una representación coherente en todas las fuentes, utilizar las huellas digitales de los certificados (huellas digitales SHA-256) como identificador canónico para la deduplicación y eliminar los registros de activos duplicados.

Algunos aspectos que hacen que la centralización funcione en la práctica:

• Metadatos consistentes: Cada registro de activo debe incluir, como mínimo, el tipo de activo, el algoritmo y los parámetros, la fecha de vencimiento, el equipo responsable, el entorno y el alcance de cumplimiento asociado. Sin datos de propiedad, los hallazgos no pueden dirigirse a las personas adecuadas para su corrección.
• Integración con las herramientas existentes: El inventario debe extraer y enviar datos a las plataformas de gestión del ciclo de vida de los certificados (CLM), a los registros de la base de datos de gestión de la configuración (CMDB) y a los flujos de trabajo de operaciones de seguridad. Un inventario aislado de las herramientas que utilizan los equipos no se mantendrá actualizado.
• Fuente única de información veraz: En entornos donde las normativas o arquitecturas locales exigen almacenamiento federado, sigue siendo necesario contar con una visión unificada a nivel superior. Un enfoque federado que no genere una visibilidad consolidada resulta contraproducente.

Paso 5: Enriquecer el inventario con contexto de riesgo y cumplimiento.

Una lista de activos no constituye un inventario en el sentido práctico. El inventario se convierte en una herramienta de toma de decisiones cuando se asocia un contexto de riesgo a cada activo. El enriquecimiento de riesgos abarca tres dimensiones. Cada dimensión pone de manifiesto diferentes tipos de problemas y alimenta distintos flujos de trabajo de remediación.

Los indicadores de riesgo de seguridad señalan activos con exposición técnica directa: certificados próximos a caducar sin automatización implementada, certificados autofirmados en entornos de producción donde se requiere un certificado emitido por una CA, algoritmos obsoletos o insuficientemente basados ​​en claves para los estándares actuales, bibliotecas con CVE conocidos, prácticas débiles de generación de claves, anclas de confianza no autorizadas, falta de protección de hardware para claves que deberían estar en HSM o TPM, y claves huérfanas sin dependencia de aplicación activa.

Los indicadores de riesgo de cumplimiento señalan desviaciones de los requisitos normativos o de política: algoritmos programados para su desautorización según NIST IR 8547; certificados o claves fuera de las políticas de gestión de claves aprobadas ; y activos incluidos en el ámbito de aplicación de marcos específicos (PCI DSS, FedRAMP, etc.) que no cumplen con esos requisitos.

El riesgo operacional señala los activos que tienen probabilidades de causar incidentes: certificados que caducan en los próximos 30 días, activos sin propietario identificado y sistemas para los que la renovación o rotación carece de un proceso automatizado.

La priorización debe basarse en la criticidad del negocio y la sensibilidad de los datos, no solo en la gravedad técnica. Un algoritmo débil en un servidor de desarrollo presenta un perfil de riesgo diferente al del mismo algoritmo que protege un sistema de pagos en producción. El inventario debe reflejar esta distinción.

Paso 6: Mantener la precisión del inventario a medida que evoluciona la infraestructura.

Un inventario que era preciso hace seis meses no es un inventario. Es un registro histórico. Los entornos en la nube, las canalizaciones de CI/CD y las flotas de dispositivos cambian continuamente, y el inventario debe mantenerse actualizado.

En la práctica, esto significa:

• Descubrimiento basado en eventos, no solo escaneos programados. Los eventos de aprovisionamiento en la nube, las notificaciones de creación de claves KMS, los hooks de Git sobre cambios en el repositorio y los eventos del ciclo de vida de los certificados deben activar las actualizaciones del inventario. Los nuevos activos se detectan a medida que se aprovisionan, no en el siguiente escaneo programado.
• Integración con los eventos del ciclo de vida de los certificados: Cuando un certificado se renueva, se revoca o se reemplaza, el registro de inventario debe actualizarse automáticamente.
• Supervisión de cambios externos que afecten a los activos existentes: nuevas vulnerabilidades CVE contra bibliotecas en el inventario, actualizaciones de las directrices de algoritmos, eventos de desconfianza de las autoridades de certificación y cambios en los requisitos de cumplimiento.
• La revisión periódica debe formar parte de las operaciones de seguridad, no ser solo un mero trámite de cumplimiento. El inventario resulta más valioso cuando los equipos lo consultan con regularidad, no únicamente cuando se acerca una auditoría.

La salud del inventario debe ser cuantificable. Algunos indicadores clave de rendimiento (KPI) útiles incluyen el porcentaje de activos detectados con propietarios confirmados, el porcentaje del entorno cubierto por la detección activa, el número de certificados que caducan en 30, 60 o 90 días, y el porcentaje de activos que utilizan algoritmos obsoletos. Estos indicadores proporcionan una señal concreta de si el inventario está mejorando o deteriorándose.

Errores Comunes que se deben Evitar

Completar los seis pasos no significa que el trabajo esté terminado. Significa que ya tienes la base establecida. El valor se acumula con el tiempo: cuanto más tiempo funcione el inventario, más precisos serán los datos de propiedad, más fiable será la automatización y mejor posicionada estará la organización cuando llegue la próxima obsolescencia de algoritmos, un evento de desconfianza de CA o una fecha límite de cumplimiento. Dicho esto, incluso los esfuerzos de inventario bien intencionados caen en trampas predecibles. Estos son los errores más comunes que debes evitar al crear y mantener el tuyo.

1. Centrarse únicamente en los certificados. Si bien los certificados son la capa más visible, las claves, los algoritmos, las bibliotecas criptográficas, los recursos KMS en la nube y otros activos también conllevan riesgos reales. Un inventario que se limita a los certificados ofrece una visión parcial.
2. Falta de mapeo de dependencias. Saber que existe un certificado no es suficiente; es necesario saber qué aplicaciones y servicios dependen de él. Sin datos de dependencias, no se puede evaluar el alcance de un fallo ni coordinar las medidas correctivas entre los equipos que deben actuar.
3. Considerar todos los hallazgos como igualmente urgentes. Sin datos sobre la criticidad de los activos, todos los elementos marcados parecen iguales. Esto genera saturación de alertas y provoca que los problemas de alto impacto se aborden sin un orden específico. La priorización requiere un contexto de criticidad empresarial.
4. Excluyendo entornos en la nube, canalizaciones de CI/CD o dispositivos de punto final. Estos constituyen ahora la infraestructura principal. Las brechas en este ámbito no son casos excepcionales; es donde suelen residir los activos no gestionados más importantes.
5. Realizar el descubrimiento como un ejercicio puntual o periódico. La infraestructura no deja de cambiar entre escaneos. El descubrimiento continuo es el único enfoque que permite mantenerse al día.
6. Depender del seguimiento manual. Las hojas de cálculo se vuelven obsoletas. En entornos dinámicos, se vuelven obsoletas rápidamente.
7. Mantener registros sin datos de propiedad. Identificar un activo es solo el primer paso. La remediación requiere un equipo responsable para cada activo.
8. Gestiona los datos de CBOM por separado del inventario de tiempo de ejecución. CBOM te indica qué capacidades criptográficas están integradas en una aplicación. El inventario de tiempo de ejecución te indica qué se está utilizando realmente en producción. Necesitas ambos.

Estos errores comparten un denominador común: tratan el inventario como un producto que se entrega una sola vez, en lugar de un sistema operativo dinámico. Establecer una base sólida desde el principio es lo que diferencia un inventario que se mantiene útil de uno que se vuelve obsoleto en cuestión de meses.

Un punto de partida práctico

Si su organización parte de cero en materia de inventario criptográfico, el primer paso práctico es definir el alcance. Defina los límites: qué entornos se incluirán en el análisis inicial, qué equipos deben participar y cómo será un inventario completo para la primera fase.

Un enfoque por fases hace que esto sea manejable:

• Fase 1 – Servicios críticos: Comience con los activos donde el riesgo operativo de caducidad o configuración incorrecta sea mayor. Los puntos finales HTTPS con acceso a Internet, las puertas de enlace VPN y las puertas de enlace API suelen ser el punto de partida adecuado; son los lugares donde un fallo criptográfico provoca un incidente inmediato. Los servicios internos utilizados por la infraestructura de autenticación (LDAP sobre TLS, RADIUS, servicios AD CS OCSP/CRL) y cualquier servicio que participe en políticas de acceso a la red de confianza cero también pertenecen a esta fase.
• Fase 2 – CI/CD: Integre la generación de CBOM en sus pipelines de compilación y el escaneo de secretos en sus flujos de trabajo de pre-commit y PR. Esto elimina la brecha de visibilidad en la cadena de suministro de software antes de expandirse.
• Fase 3 – Nube: Ampliar a entornos en la nube mediante el descubrimiento basado en API, que abarca tanto los almacenes de certificados como los recursos KMS de diferentes proveedores.
• Fase 4 – Dispositivos: Los entornos de dispositivos y OT pueden continuar mediante la monitorización pasiva de la red y el análisis del firmware, priorizando según la vida útil operativa y la sensibilidad de los datos.

El inventario no es un proyecto con fecha de finalización. Es una infraestructura operativa. Una vez creado, requiere mantenimiento, ampliación a medida que se incorporan nuevos entornos y conexión con los flujos de trabajo de remediación que permiten utilizar los datos de forma eficaz. Las organizaciones que lo gestionan correctamente tratan la visibilidad criptográfica del mismo modo que la gestión de vulnerabilidades: como una disciplina operativa continua, no como una auditoría periódica.

Cómo puede ayudar la consultoría de cifrado

Para la mayoría de las organizaciones, crear un inventario criptográfico completo y migrar a la criptografía postcuántica no es posible solo con las herramientas y la capacidad interna existentes. Encryption Consulting colabora con las empresas en cada etapa de este proceso, desde el descubrimiento inicial hasta la migración completa a la criptografía postcuántica, ofreciendo servicios y herramientas diseñadas específicamente para la complejidad de los entornos PKI empresariales reales.

Servicios de asesoramiento de PQC

Esto es lo que obtendrá con nuestro servicio de asesoramiento estructurado:

• Un registro de activos criptográficos, generado mediante un análisis sistemático de sus puntos finales, aplicaciones, API e infraestructura. Este es el punto de partida que posibilita cada paso posterior.
• Un informe de evaluación de riesgos, que evalúa su exposición a amenazas cuánticas, identificando RSA y sistemas dependientes de ECC, y entregando hallazgos priorizados con calificaciones de gravedad de riesgo por categoría: seguridad, cumplimiento y operaciones.
• Una hoja de ruta para la migración a PQC, un plan por fases alineado con su tolerancia al riesgo, los requisitos reglamentarios y los plazos del NIST, que incluye agilidad criptográfica para que sus sistemas puedan adaptarse a medida que los estándares sigan evolucionando.
• Ofrecemos asistencia para la evaluación de proveedores y las pruebas piloto, ayudándole a seleccionar las herramientas adecuadas, realizar pruebas de concepto y validar la interoperabilidad antes de cualquier implementación a gran escala.
• Implementación completa, que abarca el despliegue de modelos híbridos clásicos y cuánticos seguros, la implementación de PQC en toda su infraestructura y PKI, y la configuración de la monitorización para garantizar la salud criptográfica a largo plazo.

CBOM seguro

Cabe destacar que CBOM Secure no es lo mismo que una CBOM. Una CBOM (Lista de Materiales Criptográficos) es un artefacto estructurado, un registro de los componentes criptográficos de una aplicación o sistema. CBOM Secure genera y consume datos CBOM, pero también realiza un descubrimiento continuo y una gestión del inventario en tiempo de ejecución en todo el entorno empresarial. Esta distinción es importante porque una CBOM por sí sola indica qué componentes se integraron en una aplicación en un momento dado. CBOM Secure, en cambio, indica qué componentes se están ejecutando, dónde se ejecutan y cómo están cambiando.

Una transición exitosa a la era post-cuántica comienza con la visibilidad. Las organizaciones no pueden modernizar la criptografía si desconocen la ubicación de los certificados, las claves, los algoritmos y las dependencias criptográficas en su entorno.

CBOM Secure de Encryption Consulting ofrece una visión continua de los activos criptográficos en toda la infraestructura empresarial, entornos en la nube, aplicaciones y servicios criptográficos. En lugar de generar un inventario puntual, ayuda a las organizaciones a comprender cómo se utiliza la criptografía, dónde se implementa y cómo evoluciona con el tiempo.

CBOM Secure descubre y rastrea continuamente certificados, claves, algoritmos y dependencias criptográficas en toda la empresa. Proporciona visibilidad sobre la propiedad de los activos, las relaciones entre certificados y claves, el uso de algoritmos, los eventos del ciclo de vida y la exposición criptográfica, lo que ayuda a los equipos a identificar activos no administrados, algoritmos obsoletos y sistemas que pueden requerir modernización.

La plataforma también respalda la gobernanza basada en políticas, validando las configuraciones criptográficas según los estándares de la organización y destacando las desviaciones antes de que se conviertan en riesgos operativos o de cumplimiento.

Para las organizaciones que se preparan para la criptografía postcuántica , CBOM Secure identifica los sistemas que dependen de algoritmos vulnerables a la computación cuántica y proporciona la visibilidad necesaria para priorizar las actividades de corrección y migración.

Tanto si su organización parte de cero sin un inventario formal como si busca convertir un programa de descubrimiento existente en un programa de gobernanza continua, Encryption Consulting le ofrece la experiencia en asesoramiento y la capacidad de plataforma necesarias para impulsar su progreso. Para obtener más información sobre nuestros servicios de asesoramiento PQC o CBOM Secure, visite encryptionconsulting.com o póngase en contacto directamente con nuestro equipo.

Conclusión

Un inventario criptográfico no es un simple requisito de cumplimiento ni un resultado de auditoría puntual. Es la base operativa que permite la gestión del ciclo de vida de los certificados , la migración de algoritmos y la planificación de la preparación para la computación cuántica. Los tres entornos que se abordan aquí (infraestructura en la nube, canalizaciones de CI/CD y dispositivos conectados) son donde la mayoría de las organizaciones tienen la visibilidad más limitada en la actualidad, y donde las consecuencias de esta brecha son más significativas.

Las organizaciones no pueden automatizar, corregir ni migrar sistemas criptográficos que no pueden visualizar. El punto de partida es el mismo independientemente del entorno: saber qué se tiene, dónde se encuentra y mantener ese conocimiento actualizado. La preparación para la computación cuántica comienza con la visibilidad criptográfica. Todo lo demás se deriva de ahí.

Preguntas frecuentes

¿Cuál es la diferencia entre un CBOM y un descubrimiento criptográfico en tiempo de ejecución?

Una lista de materiales criptográficos (CBOM, por sus siglas en inglés) registra las capacidades criptográficas integradas en un artefacto de software, basándose en análisis estáticos o en tiempo de compilación. El descubrimiento en tiempo de ejecución rastrea lo que está realmente implementado y en funcionamiento en su entorno. Necesita ambos: la CBOM le indica qué se integró y el descubrimiento en tiempo de ejecución le indica qué está activo.

¿Por qué una hoja de cálculo no puede funcionar como inventario criptográfico?

Los entornos en constante cambio, con nuevas implementaciones, actualizaciones de configuración, aprovisionamiento en la nube y lanzamientos de software, superan en cuestión de semanas cualquier lista mantenida manualmente. Para que siga siendo útil, el inventario debe ser continuo y automatizado, con un descubrimiento basado en eventos que se active mediante eventos de aprovisionamiento, ganchos de Git y cambios en el ciclo de vida de los certificados.

¿Con qué entorno deberían empezar las organizaciones al crear un inventario?

Comience con los servicios críticos: puntos finales HTTPS con acceso a internet, puertas de enlace VPN y puertas de enlace API, ya que un fallo criptográfico en ellos provoca un incidente inmediato. A partir de ahí, extienda a las canalizaciones de CI/CD, luego a los entornos en la nube, y finalmente a los dispositivos y sistemas OT, priorizando según su ciclo de vida operativo y la sensibilidad de los datos.

¿Por qué las canalizaciones de CI/CD representan un importante punto ciego criptográfico?

El material criptográfico integrado en las aplicaciones durante el proceso de compilación (claves codificadas, certificados incrustados, claves de firma de código) no aparece en los análisis de certificados a nivel de red. Además, se han utilizado procesos de compilación comprometidos para inyectar código malicioso en artefactos firmados en los que los usuarios finales confían implícitamente, lo que representa una brecha en el inventario y una superficie de ataque activa.

¿Por qué los dispositivos de larga duración conllevan un riesgo criptográfico único?

Los dispositivos que llevan años o décadas en funcionamiento acumulan deuda criptográfica: el firmware se distribuye con una versión fija de la biblioteca, los certificados de identidad del dispositivo pueden tener una validez de 10 años sin renovación automática, y la solución puede requerir una actualización completa del firmware o un reemplazo físico. Sumado al riesgo de recopilar datos ahora y descifrarlos después, los dispositivos de larga duración que utilizan algoritmos vulnerables a la computación cuántica son una prioridad particular para la planificación de la migración a PQC.

¿Qué indicadores clave de rendimiento (KPI) señalan si un inventario criptográfico está en buen estado?

Porcentaje de activos descubiertos con propietarios confirmados, porcentaje del entorno cubierto por la detección activa, número de certificados que caducan en 30, 60 o 90 días, y porcentaje de activos que utilizan algoritmos obsoletos. Estos datos proporcionan una señal concreta de si el inventario está mejorando o deteriorándose.