Gestión de secretos de identidades no humanas para auditorías de 2026

La alerta de las 02:13 que nadie pudo atribuir

A las 02:13 de un martes por la mañana, se activa el canal de operaciones de seguridad. Ha comenzado una exportación de una base de datos de producción desde una cuenta interna de automatización. La ruta de acceso es legítima. El token es válido. La IP de origen pertenece a un ejecutor en la nube utilizado por el equipo de ingeniería. No hay malware visible. No existe ninguna notificación de phishing.

El director de seguridad de la información (CISO) formula la primera pregunta obvia: «¿Quién es el propietario de esta identidad?»

Silencio.

El responsable de DevOps recuerda que el token se creó durante una migración de cliente hace dos años. El equipo de plataforma indica que quizá lo utilice una integración de facturación. El administrador de la base de datos señala que tiene acceso de lectura porque, cuando se retiró una vez, se rompió un trabajo nocturno. Legal pregunta si había datos personales implicados. Cumplimiento pregunta si se trata de un incidente notificable conforme a NIS2, DORA o RGPD. El auditor solicita evidencias de que las cuentas de servicio, las claves de API, los certificados y los secretos de CI/CD están inventariados, revisados, rotados, supervisados y revocados.

A las 09:00, el borrador del hallazgo de auditoría ya está tomando forma. Se ha descubierto una clave de API codificada de forma fija y sin rotación en un microservicio olvidado. Concede acceso amplio a una base de datos de producción con transacciones de clientes. El desarrollador que la creó dejó la organización hace dos años. El sistema no tiene propietario nominal, finalidad documentada, registro de rotación ni regla de supervisión.

Este es el problema de las identidades no humanas en 2026.

La mayoría de las organizaciones han mejorado el control de acceso humano. Disponen de MFA, flujos de altas, cambios y bajas, revisiones de acceso privilegiado y registros de proveedores de identidad. Pero las identidades de máquina se han multiplicado más rápido que la gobernanza. Cuentas de servicio, identidades de carga de trabajo, claves de API, tokens OAuth, claves SSH, certificados, secretos de Kubernetes, tokens de integración SaaS, cuentas de automatización robótica de procesos y credenciales de despliegue de CI/CD ejecutan ahora acciones críticas para la organización sin ser «usuarios» en sentido humano.

Para proveedores SaaS, fintechs, proveedores de servicios gestionados, operadores en la nube y pymes intensivas en datos, las identidades no humanas no gestionadas ya no son un problema de higiene técnica. Son un riesgo de resiliencia y cumplimiento a nivel del consejo de administración. NIS2 trata el control de acceso, la gestión de activos, la seguridad de la cadena de suministro, la gestión de incidentes y la higiene cibernética como medidas esenciales de gestión de riesgos de ciberseguridad. DORA sitúa el riesgo de TIC, la resiliencia operativa, la notificación de incidentes y el riesgo de terceros de TIC bajo la responsabilidad del órgano de dirección de las entidades financieras. El RGPD exige que responsables y encargados protejan los datos personales y demuestren responsabilidad proactiva.

Lo difícil no es demostrar que existen secretos. Lo difícil es demostrar que cada identidad no humana tiene propietario, finalidad, ciclo de vida, calificación de riesgo, acceso aprobado, método de almacenamiento seguro, regla de rotación, cobertura de supervisión y vía de revocación.

Por qué las identidades no humanas se convirtieron en el nuevo problema de acceso privilegiado

Una identidad no humana, o NHI, es cualquier identidad digital utilizada por software, infraestructura o procesos automatizados en lugar de por una persona. En la práctica, incluye cuentas de servicio utilizadas por aplicaciones, claves de API utilizadas por integraciones SaaS, tokens OAuth y de actualización utilizados por aplicaciones de terceros, claves SSH utilizadas por automatización, certificados TLS y claves privadas, secretos de CI/CD, identidades de carga de trabajo en la nube, cadenas de conexión a bases de datos, credenciales embebidas, cuentas de bots de RPA y credenciales de integración gestionadas por proveedores.

Estas identidades suelen tener tres características que inquietan a los auditores.

Primero, son de larga duración. Un usuario humano puede rotar credenciales, cambiar de función y salir mediante un proceso formal de baja. Un token de API creado durante una ventana de despliegue puede permanecer activo durante años porque nadie quiere arriesgarse a romper producción.

Segundo, son potentes. Un token de despliegue puede modificar infraestructura. Un principal de servicio en la nube puede crear almacenamiento. Una cuenta de base de datos puede exportar registros de clientes. Una clave de firma puede comprometer la integridad de la cadena de suministro de software.

Tercero, su atribución suele ser deficiente. Las identidades humanas están vinculadas a registros de Recursos Humanos. Las identidades no humanas suelen estar vinculadas a scripts, canalizaciones, proveedores, proyectos olvidados o integraciones no documentadas.

Zenith Blueprint: An Auditor’s 30-Step Roadmap de Clarysec Zenith Blueprint lo señala directamente en la fase Controls in Action, paso 22:

Y no olvides las identidades no humanas. Aquí es donde las auditorías suelen descubrir exposición silenciosa. ¿Se realiza seguimiento de los tokens de API? ¿Las cuentas de integración están vinculadas a personas o flotan en el limbo? ¿Cuándo fue la última vez que se rotó esa cadena de acceso a la base de datos, incrustada en un script de hace décadas?

La gestión de identidades no es glamurosa, pero es estructural. Sin ella, tu SGSI es solo una colección de puertas cerradas, sin forma de saber quién tiene las llaves.

La última frase es la clave. Una empresa puede tener una política de control de acceso impecable y aun así fallar una auditoría si las identidades de máquina no están gestionadas. Un SGSI que no puede explicar quién es propietario de un secreto, por qué existe y cuándo se revisó por última vez aún no opera como un sistema controlado.

ISO/IEC 27001:2022 convierte la gestión de secretos en evidencias

ISO/IEC 27001:2022 es eficaz porque no trata la gestión de secretos como una tarea aislada de ingeniería. Exige un SGSI basado en riesgos con alcance definido, requisitos de las partes interesadas, rendición de cuentas de la dirección, evaluación de riesgos, tratamiento de riesgos, selección de controles, una Declaración de Aplicabilidad y mejora continua.

Para las identidades no humanas, la organización no debe empezar comprando una herramienta. Debe empezar por el alcance y las obligaciones.

Conforme a las cláusulas 4.1 a 4.4 de ISO/IEC 27001:2022, la organización determina cuestiones internas y externas, partes interesadas, requisitos legales, regulatorios y contractuales, interfaces y dependencias. En el contexto de NHI, el alcance del SGSI debe identificar entornos en la nube, plataformas SaaS, sistemas CI/CD, aplicaciones de producción, integraciones con clientes, encargados del tratamiento de datos, proveedores de servicios gestionados y servicios criptográficos donde existan credenciales de máquina.

Las cláusulas 5.1 a 5.3 hacen que la dirección sea responsable de la política, los recursos, los roles y la información sobre el desempeño. Esto importa porque la remediación de NHI suele generar tensión operativa. Rotar una credencial de base de datos de producción, sustituir una cuenta de servicio compartida heredada o aplicar inyección de secretos basada en bóveda puede romper flujos de trabajo frágiles. Sin patrocinio ejecutivo, los equipos posponen la limpieza.

Las cláusulas 6.1.1 a 6.1.3 y 6.2 proporcionan el motor de control. La organización define criterios de riesgo, identifica riesgos de confidencialidad, integridad y disponibilidad, asigna propietarios del riesgo, evalúa probabilidad e impacto, elige opciones de tratamiento, selecciona controles, produce la Declaración de Aplicabilidad y realiza seguimiento de objetivos medibles.

En términos prácticos, un plan de tratamiento de riesgos para identidades no humanas debe responder:

• ¿Qué sistemas y servicios de la organización dependen de NHI?
• ¿Qué secretos pueden acceder a datos personales, servicios financieros regulados, infraestructura de producción o servicios críticos para clientes?
• ¿Qué identidades son privilegiadas, inactivas, compartidas, gestionadas por proveedores o no gestionadas?
• ¿Qué controles reducen el riesgo, como uso de bóvedas, rotación, mínimo privilegio, caducidad, gestión del ciclo de vida de certificados, escaneo de CI/CD, supervisión y revocación de emergencia?
• ¿Qué riesgos residuales requieren aprobación de negocio?

ISO/IEC 27002:2022 proporciona después el catálogo de controles del Anexo A. Los controles más relevantes incluyen 5.9 Inventario de información y otros activos asociados, 5.15 Control de acceso, 5.16 Gestión de identidades, 5.17 Información de autenticación, 5.18 Derechos de acceso, 5.19 Seguridad de la información en las relaciones con proveedores, 5.20 Tratamiento de la seguridad de la información en los acuerdos con proveedores, 5.21 Gestión de la seguridad de la información en la cadena de suministro de TIC, 5.23 Seguridad de la información para el uso de servicios en la nube, 5.24 Planificación y preparación de la gestión de incidentes, 5.28 Recopilación de evidencias, 8.2 Derechos de acceso privilegiado, 8.3 Restricción del acceso a la información, 8.5 Autenticación segura, 8.15 Registro de eventos, 8.16 Actividades de supervisión, 8.24 Uso de la criptografía, 8.25 Ciclo de vida de desarrollo seguro, 8.26 Requisitos de seguridad de las aplicaciones, 8.28 Codificación segura y 8.31 Separación de entornos de desarrollo, prueba y producción.

Zenith Controls: The Cross-Compliance Guide de Clarysec Zenith Controls mapea estas relaciones de ISO/IEC 27002:2022 de forma utilizable por auditores y propietarios de controles. Para el control 5.16, Gestión de identidades, Zenith Controls explica la conexión entre identidad y credenciales:

La gestión de identidades proporciona el quién, mientras que la información de autenticación garantiza el cómo, verificando que la persona que afirma una identidad es legítima. 5.16 gobierna la gestión del ciclo de vida de la identidad, mientras que 5.17 garantiza que contraseñas, tokens, certificados y otras credenciales estén vinculados de forma segura a esas identidades y se gestionen adecuadamente para respaldar una autenticación robusta.

Esa relación es esencial para las NHI. Un token sin propietario de identidad no es auditable. Una cuenta de servicio sin revisión de acceso no cumple el mínimo privilegio. Un certificado sin estado de ciclo de vida no es criptografía controlada. Una credencial de integración de proveedor sin condiciones contractuales no es una gestión eficaz del riesgo de terceros.

El patrón de control de Clarysec: identidad, secreto, privilegio, evidencia

Clarysec implementa la gestión de identidades no humanas y secretos mediante un patrón de control repetible. No tratamos los «secretos» como una cuestión exclusiva de DevOps ni las «cuentas de servicio» como una cuestión exclusiva de IAM. Conectamos identidad, secreto, privilegio y evidencia.

La capa de política es donde esto se vuelve exigible.

Para pymes, la Política de gestión de cuentas de usuario y privilegios-sme de Clarysec Política de gestión de cuentas de usuario y privilegios-sme establece:

Las cuentas de servicio (utilizadas por sistemas o aplicaciones) deben documentarse, restringirse a sistemas específicos y no utilizarse nunca para inicios de sesión interactivos.

Esto evita el antipatrón clásico en el que una cuenta de servicio se convierte en una cuenta de administrador compartida. También proporciona al auditor una prueba clara: mostrar el inventario de cuentas de servicio, demostrar la restricción por sistema y demostrar que el inicio de sesión interactivo está deshabilitado o impedido técnicamente.

La Política de Gestión de Activos-sme de Clarysec Política de Gestión de Activos-sme amplía la definición de activos para incluir:

Credenciales y servicios digitales: nombres de dominio, certificados digitales, claves de API, cuentas de correo electrónico, accesos a servicios en la nube

Esto importa porque muchas organizaciones solo inventariarían servidores, portátiles y aplicaciones. En 2026, una clave de API puede ser más sensible que un portátil. La clave privada de un certificado puede ser un activo de autenticación de producción. Un acceso a servicios en la nube utilizado por automatización puede generar exposición de datos regulados. Tratar las credenciales como activos es la base de una gestión de secretos preparada para auditorías.

Para entornos corporativos, la Política de gestión de cuentas de usuario y privilegios de Clarysec Política de gestión de cuentas de usuario y privilegios eleva el nivel de evidencia:

La organización deberá mantener un inventario detallado de todas las credenciales activas e inactivas, cuentas privilegiadas y cuentas de servicio a nivel de sistema. Este inventario deberá actualizarse de forma continua y revisarse trimestralmente.

La revisión trimestral es donde aparecen muchas deficiencias. Credenciales inactivas, principales de servicio huérfanos, usuarios de integración antiguos, cuentas de proveedor no gestionadas y tokens de emergencia solo se hacen visibles cuando alguien compara el registro con los registros reales de IAM, bóvedas, CI/CD y nube.

Los secretos son información de autenticación, no una comodidad para desarrolladores

La frase más peligrosa en gestión de secretos es «clave temporal».

Las claves temporales se vuelven permanentes. Las credenciales de prueba llegan a producción. El código fuente revela tokens. Los registros de compilación exponen contraseñas. Los equipos de soporte comparten certificados mediante tickets. Los desarrolladores copian archivos de entorno en chats. Un contratista crea un principal de servicio en la nube y se marcha.

Zenith Blueprint, en la fase Controls in Action, paso 22, describe la información de autenticación de forma amplia:

Este control no trata solo de contraseñas, aunque las contraseñas forman parte del conjunto. Trata de toda credencial utilizada para afirmar una identidad: contraseñas, PIN, claves criptográficas, plantillas biométricas, tarjetas inteligentes, tokens, certificados, tokens OAuth, claves SSH, secretos de API. Son las llaves del reino, y el Control 5.17 garantiza que esas llaves se traten con la seriedad que merecen.

Seamos claros: la mala gestión de la autenticación sigue siendo una de las principales causas raíz de las brechas de seguridad. Contraseñas débiles o compartidas. Credenciales codificadas de forma fija en el código fuente. Inicios de sesión por defecto sin cambiar en portales de administración. Certificados caducados o con titularidad desconocida. En todos esos casos, no falló la identidad; falló la capacidad de proteger y gobernar el mecanismo utilizado para probar esa identidad.

Las políticas de Clarysec traducen esto en reglas operativas.

La Política de Controles Criptográficos-sme Política de Controles Criptográficos-sme establece:

Las claves no deben almacenarse en texto claro ni incrustarse en código fuente, documentos o correos electrónicos

La Política de Desarrollo Seguro-sme Política de Desarrollo Seguro-sme establece:

No se permiten credenciales ni secretos codificados de forma fija en el código fuente

Para equipos corporativos, la Política de Desarrollo Seguro Política de Desarrollo Seguro establece:

Los secretos no deben codificarse de forma fija ni almacenarse en texto claro en repositorios.

Y la Política de requisitos de seguridad de las aplicaciones Política de requisitos de seguridad de las aplicaciones es aún más directa:

El almacenamiento de contraseñas o claves criptográficas en texto claro está estrictamente prohibido.

Estas cláusulas de política crean una pista de auditoría clara. Los equipos de seguridad pueden comprobar repositorios, variables de CI/CD, imágenes de contenedores, almacenes de configuración, gestores de incidencias, plataformas de documentación y registros frente a requisitos explícitos. También respaldan la seguridad del tratamiento del Article 32 del RGPD, porque la exposición de secretos puede conducir directamente a acceso no autorizado a datos personales.

La gobernanza criptográfica corporativa también necesita titularidad. La Política de Controles Criptográficos de Clarysec Política de Controles Criptográficos exige:

Debe mantenerse un Registro de Gestión de Claves centralizado para registrar todas las claves criptográficas, su estado de ciclo de vida, custodios asignados y contextos de uso.

Para las identidades no humanas, ese registro debe conectar claves de certificados, claves de firma, claves de API y claves gestionadas en la nube con el registro NHI más amplio. El auditor debe poder trazar un certificado de producción desde el servicio de negocio hasta el propietario, el custodio, la caducidad, las evidencias de rotación y el procedimiento de respuesta a incidentes.

NIS2, DORA y RGPD: un modelo de evidencias, muchos reguladores

La gobernanza de identidades no humanas es un problema de cumplimiento transversal porque el mismo fallo puede activar múltiples obligaciones.

Un token de API filtrado en un proveedor SaaS puede causar una indisponibilidad del servicio conforme a NIS2, exposición de datos personales conforme al RGPD y notificación contractual de incidentes a clientes financieros conforme a las expectativas de cadena de suministro de DORA. Un secreto de CI/CD comprometido en un proveedor de servicios de TIC puede afectar a la resiliencia de clientes, la integridad del software y la continuidad operativa. Una cuenta de integración de proveedor olvidada puede crear acceso a sistemas regulados sin la diligencia debida ni los controles contractuales adecuados.

NIS2 Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas. Las áreas mínimas incluyen análisis de riesgos, políticas de seguridad de los sistemas de información, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, adquisición, desarrollo y mantenimiento seguros, gestión de vulnerabilidades, evaluación de la eficacia, higiene cibernética, criptografía, seguridad de Recursos Humanos, control de acceso y gestión de activos, y, cuando proceda, MFA o autenticación continua. Las identidades no humanas atraviesan casi todas esas áreas. NIS2 Article 23 también establece una notificación escalonada de incidentes significativos, incluida una alerta temprana en un plazo de 24 horas, una notificación del incidente en un plazo de 72 horas y un informe final no más tarde de un mes tras la notificación del incidente.

DORA es aplicable desde el 17 de enero de 2025 y cubre gestión del riesgo de las TIC, notificación de incidentes graves relacionados con las TIC, pruebas de resiliencia operativa, intercambio de información y riesgo de terceros de TIC. Los Articles 5 y 6 exigen gobernanza, responsabilidad del órgano de dirección y un marco documentado de gestión del riesgo de las TIC. El Article 8 exige identificar funciones de negocio soportadas por TIC, activos de información y dependencias. Los Articles 17 a 19 exigen gestión, clasificación y notificación de incidentes. Los Articles 28 a 30 exigen gestión del riesgo de terceros de TIC, registros contractuales, diligencia debida, estándares de seguridad, derechos de auditoría, soporte ante incidentes, controles de subcontratación y estrategias de salida.

El RGPD se aplica allí donde se traten datos personales dentro de su ámbito territorial. El Article 5 exige integridad, confidencialidad y responsabilidad proactiva. El Article 32 exige medidas técnicas y organizativas adecuadas para la seguridad del tratamiento. Si una cuenta de servicio o una clave de API puede acceder a datos personales, los secretos no gestionados son un fallo de control de privacidad, no solo un problema de TI.

Las mismas evidencias pueden respaldar la certificación ISO/IEC 27001:2022, la supervisión NIS2, los exámenes DORA y la responsabilidad proactiva del RGPD cuando están estructuradas correctamente.

NIST CSF 2.0 puede utilizarse como capa de comunicación para las mismas evidencias. Su función GOVERN cubre expectativas de partes interesadas, obligaciones legales y contractuales, apetito de riesgo, responsabilidad de la dirección, política y supervisión. Sus resultados operativos cubren inventarios de activos, servicios prestados por proveedores, gestión de identidades y credenciales, mínimo privilegio, seguridad de datos, registro de eventos, supervisión, respuesta a incidentes y recuperación.

COBIT 2019 y los equipos de aseguramiento de estilo ISACA suelen fijarse en la gobernanza y la capacidad de proceso. Preguntarán si la responsabilidad está asignada, si los controles están integrados en los procesos operativos, si las excepciones están aprobadas, si las métricas se informan a la dirección y si las evidencias demuestran repetibilidad en lugar de una limpieza puntual.

Un sprint práctico para crear un registro de identidades no humanas

Un encargo práctico de Clarysec suele empezar con un sprint focalizado, no con un programa de herramientas de seis meses. El objetivo es producir un registro NHI defendible, una priorización de riesgos y un plan de remediación que alimenten el Plan de Tratamiento de Riesgos y la Declaración de Aplicabilidad de ISO/IEC 27001:2022.

Empieza por un servicio de la organización, como una plataforma de facturación de clientes, una aplicación de trading, un portal de pacientes o un sistema de gestión de tenants SaaS. Incluye producción, preproducción, CI/CD, infraestructura en la nube, herramientas de supervisión, bases de datos, integraciones SaaS y servicios gestionados por proveedores.

Vincula esto con Zenith Blueprint, fase Risk Management, paso 14, donde Clarysec alinea las políticas de tratamiento con referencias regulatorias cruzadas. En ese paso, los controles de desarrollo seguro y de canalización incluyen ausencia de secretos codificados de forma fija, revisión por pares, análisis estático automatizado, escaneo de dependencias, separación de desarrollo, pruebas y producción, MFA para acceso a canalizaciones, integridad de artefactos de compilación y registro de CI/CD.

Recopila identidades y secretos del proveedor de identidad, IAM en la nube, bóveda de secretos, Kubernetes, variables de CI/CD, configuración de repositorios, usuarios de bases de datos, consolas de administración SaaS, herramientas de gestión de certificados y documentación de proveedores.

Evalúa el riesgo de las identidades que tienen acceso a producción, derechos privilegiados, acceso a datos personales, dependencia de funciones críticas o importantes, control por proveedores, tokens de larga duración, ausencia de propietario, ausencia de rotación, ausencia de supervisión o almacenamiento codificado de forma fija. Usa los criterios de riesgo de ISO/IEC 27001:2022 para puntuar probabilidad e impacto. Usa el análisis de funciones críticas o importantes de DORA cuando corresponda. Usa consideraciones de impacto del RGPD cuando haya datos personales accesibles. Usa el impacto de servicio de NIS2 cuando sea plausible una interrupción o daño a clientes.

Para cada NHI de alto riesgo, aplica acciones de tratamiento. Traslada secretos desde código fuente, documentos y variables de CI/CD en texto claro a una bóveda o almacén de secretos gestionado. Sustituye cuentas de servicio compartidas por identidades únicas de carga de trabajo. Deshabilita el inicio de sesión interactivo para cuentas de servicio. Aplica mínimo privilegio y credenciales específicas por entorno. Configura rotación, caducidad y revocación de emergencia. Vincula secretos a propietarios y custodios. Añade registro de eventos para autenticación, uso de tokens y acciones sensibles. Añade alertas por geografía anómala, horario inusual, volumen inusual o acceso a nuevos recursos. Actualiza contratos de proveedores para manejo de credenciales, soporte ante incidentes y derechos de auditoría. Documenta excepciones con aprobación del propietario del riesgo y fecha de caducidad.

La Política de Datos de Prueba y Entornos de Prueba Política de Datos de Prueba y Entornos de Prueba respalda la separación de entornos:

La integración con canalizaciones de CI/CD debe aplicar la separación de entornos y credenciales de autenticación.

Esa cláusula suele ser decisiva. Si desarrollo, pruebas y producción comparten secretos, un entorno de bajo riesgo puede convertirse en una ruta de brecha de seguridad hacia producción.

El sprint debe terminar con un paquete de evidencias, no solo con una lista de hallazgos. Incluye la exportación del registro NHI, entradas de evaluación de riesgos, plan de tratamiento, mapeo de la Declaración de Aplicabilidad, referencias de políticas, capturas de pantalla de la bóveda, registros de rotación, aprobaciones de revisiones de acceso, resultados de escaneo de secretos en CI/CD, definiciones de reglas de supervisión, matriz de responsabilidades sobre credenciales de proveedores, runbook de incidentes y excepciones con propietarios y fechas de caducidad.

Registro de eventos y detección: demostrar que el uso de identidades de máquina es visible

Una identidad de máquina bien inventariada pero invisible en los registros sigue siendo peligrosa. La detección forma parte de la narrativa de control.

La Política de registro y supervisión-sme de Clarysec Política de registro y supervisión-sme incluye evidencias de autenticación:

Registros de autenticación: intentos de inicio de sesión correctos y fallidos, duración de la sesión, uso de MFA

Para las NHI, adapta este requisito a la autenticación de máquina. Puede que no exista uso de MFA para una identidad de carga de trabajo, pero deben existir eventos de autenticación, uso de tokens, uso de certificados, metadatos de llamadas de API, carga de trabajo de origen, servicio de destino, vida útil del token, eventos de fallo y acciones privilegiadas.

En Zenith Controls, el control 8.2 de ISO/IEC 27002:2022, Derechos de acceso privilegiado, se vincula al registro y la supervisión porque las cuentas privilegiadas requieren registros detallados y supervisión. Zenith Controls también vincula 8.2 con la gestión de identidades, derechos de acceso, restricción del acceso a la información y autenticación segura. Para los auditores, esto significa que las identidades no humanas privilegiadas deben revisarse y supervisarse con la misma seriedad que los administradores humanos, a veces más.

Buenas preguntas de supervisión incluyen:

• ¿Se autenticó una cuenta de servicio desde una carga de trabajo o rango IP inesperado?
• ¿Accedió una clave de API a un endpoint o conjunto de datos nuevo?
• ¿Se utilizó un certificado después de su sustitución?
• ¿Desplegó un token de CI/CD fuera de una canalización aprobada?
• ¿Intentó una cuenta de solo lectura realizar operaciones de escritura?
• ¿Se activó una credencial inactiva?
• ¿Accedió una integración de proveedor a datos fuera de los horarios o volúmenes acordados?

Cuando se produzca la alerta de las 02:13, necesitas responder qué identidad se utilizó, qué secreto la autenticó, qué derechos de acceso se ejercieron, qué datos o sistemas se vieron afectados, si la actividad era esperada, qué propietario puede validarla y si se cumplen los umbrales de notificación de incidentes.

La mirada del auditor: el mismo proceso, preguntas distintas

La posición de auditoría más sólida no es «cumplimos con todo». Es «operamos un único proceso controlado que produce evidencias para múltiples obligaciones». Auditores distintos inspeccionarán ese proceso de formas distintas.

En todas esas perspectivas, los hallazgos recurrentes son previsibles: ausencia de un inventario NHI único, falta de propietario para identidades de máquina, secretos almacenados en código o documentación, credenciales compartidas entre entornos, ausencia de rotación o caducidad, credenciales gestionadas por proveedores fuera de las revisiones de acceso, supervisión que cubre humanos pero no máquinas, y runbooks de incidentes que ignoran la fuga de secretos.

Cada hallazgo se mapea de forma natural a controles, políticas y plantillas de remediación de Clarysec. Más importante aún, cada uno puede convertirse en evidencia medible dentro del SGSI.

Cómo Clarysec te ayuda a prepararte para auditorías

El enfoque de Clarysec es práctico porque empieza por las evidencias que solicitarán los auditores y trabaja hacia atrás hasta controles, políticas y rutinas operativas.

En Zenith Blueprint, fase Controls in Action, paso 19, Clarysec proporciona orientación directa para la autenticación máquina a máquina:

Para autenticación máquina a máquina, como cuentas de servicio o llamadas de API, las claves, certificados y tokens deben protegerse con el mismo rigor. Evita incrustar credenciales en código. Utiliza sistemas de gestión de secretos o bóvedas para almacenarlas y rotarlas de forma segura.

Un flujo de trabajo típico de Clarysec para identidades no humanas incluye descubrimiento de NHI en nube, SaaS, CI/CD, repositorios, bóvedas y bases de datos; análisis de brechas de política frente a conjuntos de políticas Clarysec para pymes o corporativas; evaluación de riesgos y mapeo de tratamiento ISO/IEC 27001:2022; actualizaciones de la Declaración de Aplicabilidad; mapeo de evidencias para NIS2, DORA, RGPD y NIST CSF; diseño del registro NHI; alineación con el Registro de Gestión de Claves; escaneo de secretos; procesos de revisión de acceso; matrices de responsabilidad sobre credenciales de proveedores; runbooks de incidentes; y paquetes de auditoría con capturas de pantalla, exportaciones, registros, aprobaciones y registros de excepciones.

Para pymes, el enfoque es proporcionado. Un proveedor SaaS de 70 personas no necesita el mismo despliegue de herramientas que un banco global, pero sí necesita titularidad, política, tratamiento de riesgos y evidencias. Para entidades financieras reguladas y proveedores de TIC, el mismo modelo escala hacia el mapeo de funciones críticas de DORA, la gobernanza del riesgo de terceros y las pruebas de resiliencia.

Si tu próxima auditoría es en 2026, no esperes a que el auditor descubra por ti las identidades no humanas. Empieza por un servicio crítico y formula cinco preguntas:

1. ¿Conocemos cada cuenta de servicio, clave de API, token, certificado y secreto de CI/CD utilizado por este servicio?
2. ¿Tiene cada NHI un propietario nominal, custodio, finalidad y calificación de riesgo?
3. ¿Están los secretos en bóvedas, rotados y protegidos frente a código fuente, documentos, correos electrónicos y almacenamiento en texto claro?
4. ¿Se revisan, supervisan y restringen frente a uso interactivo las identidades de máquina privilegiadas?
5. ¿Podemos producir evidencias para ISO/IEC 27001:2022, NIS2, DORA y RGPD desde un único proceso controlado?

Usa Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint para estructurar tu recorrido de implantación del SGSI. Usa Zenith Controls: The Cross-Compliance Guide Zenith Controls para conectar los controles de identidad, autenticación, privilegios, registro de eventos, criptografía, desarrollo seguro y proveedores de ISO/IEC 27002:2022 con evidencias regulatorias. Usa la biblioteca de políticas de Clarysec para pymes y empresas, incluida la Política de gestión de cuentas de usuario y privilegios-sme Política de gestión de cuentas de usuario y privilegios-sme, la Política de Controles Criptográficos Política de Controles Criptográficos, la Política de Desarrollo Seguro Política de Desarrollo Seguro y la Política de requisitos de seguridad de las aplicaciones Política de requisitos de seguridad de las aplicaciones, para convertir buenas intenciones en requisitos exigibles.

La alerta de las 02:13 ocurrirá en algún lugar. La cuestión es si tu organización puede responder, con evidencias, quién tenía la llave, qué abrió, por qué existía y con qué rapidez puedes dejarla en condiciones seguras.