NHI · Cuentas de servicio · OAuth · API keys · Workload · Vault
Seguridad de identidades no humanas
Tokens, secretos, cuentas de servicio, integraciones SaaS, claves de API y workloads superan a los usuarios humanos en proporciones de 20:1 a 50:1 y muy pocas tienen propietario, rotación o monitorización. Programa completo de gobierno NHI desde el inventario hasta la baja segura.
Resumen ejecutivo
Las identidades no humanas (NHI) crecen mucho más rápido que las humanas, rara vez tienen propietario claro, casi nunca usan MFA, sus secretos no se rotan y mantienen permisos amplios "por si acaso". Cuando un atacante compromete una NHI activa con permisos excesivos, el coste de detectarlo es alto porque no genera el comportamiento anómalo típico de un usuario humano comprometido.
El servicio cubre el ciclo completo específico de NHI: descubrimiento consolidado en cloud, SaaS, on-prem y código; atribución de propietario funcional; gobierno de secretos con rotación automatizada; reducción real de privilegios; monitorización y baja segura. Apto para sostener auditoría ISO 27001:2022 (A.5.16, A.5.17, A.8.2), ENS (op.acc.1, op.acc.4, mp.info.4), NIS2 art. 21.2.i y DORA art. 9.
Riesgo creciente y silencioso
Por cada usuario nuevo se generan decenas de NHI. Sin programa específico, la deuda de identidad crece de forma exponencial y silenciosa.
Ciclo específico, no IAM tradicional
Las NHI no entran y salen con RRHH. No tienen MFA típica. Necesitan rotación automatizada, federación workload y propietario funcional explícito.
Evidencia regulatoria
ISO 27001:2022, ENS, NIS2 y DORA cubren explícitamente NHI. Entregamos inventario, propietarios, rotación, mínimo privilegio y monitorización trazables.
Qué cubrimos en un programa NHI
Doce áreas que sumadas dan visibilidad y control real del ecosistema NHI. No todas tienen que abordarse a la vez: priorizamos las críticas en función del diagnóstico.
Cuentas de servicio en directorio
Active Directory y Entra ID: identificación, atribución, política de contraseñas largas no rotables, restricción de servicios donde se pueden autenticar, gMSA donde aplique.
Tokens OAuth a SaaS
Microsoft 365, Google Workspace, Salesforce, Slack, GitHub: inventario de aplicaciones conectadas, revisión periódica de scopes, política de aprobación de nuevas, deshabilitación de inactivas.
Claves de API
Inventario por proveedor (Stripe, SendGrid, Twilio, AWS, etc.), rotación automatizada, principio de tokens de corta duración cuando el proveedor lo permite, alertas de uso anómalo.
Identidades workload cloud
IAM Roles en AWS, Managed Identities en Azure, Service Accounts en GCP, Workload Identity Federation. Sustituir secretos por federación siempre que se pueda.
Service accounts Kubernetes
ServiceAccounts en clusters, RBAC apropiado por namespace, integración con OIDC del proveedor cloud, evitar tokens de larga duración montados por defecto.
Personal access tokens (PAT)
PATs en GitHub/GitLab/Bitbucket/Atlassian: inventario, atribución a propietario, política de caducidad obligatoria, sustitución por GitHub Apps cuando es viable.
Secretos en código y CI/CD
Escaneo de repositorios e historial Git, secretos en pipelines (GitHub Actions, GitLab CI, Jenkins), variables de entorno en contenedores, archivos .env desplegados.
Gestión centralizada de secretos
Implantación o reforma de Vault/Secrets Manager/Key Vault/CyberArk según stack. Migración progresiva de secretos dispersos al gestor centralizado.
RPA y automatizaciones de oficina
Power Automate, UiPath, Zapier, Make: cada flujo automatizado usa identidades que rara vez se inventarían. Gobernarlas con los mismos criterios que las técnicas.
Identidades de proveedores externos
Tokens y cuentas que damos a auditores, consultores, MSPs, integradores. Caducidad obligatoria, propietario interno responsable, revisión a la salida del proveedor.
Monitorización y alertas
Eventos clave: uso desde geografía nueva, fuera de horario, volumen anómalo, autenticación tras período de inactividad, intento de uso tras expiración.
Baja segura
Procedimiento para dar de baja NHI sin romper integraciones críticas: dependencias mapeadas, ventana de revocación gradual, verificación post-baja, archivado documentado.
Anatomía de un hallazgo crítico
Patrón técnico real anonimizado: OAuth app conectada a Microsoft 365 por un proveedor que ya no trabaja con la empresa, con permisos amplios sobre buzones y SharePoint, sin rotación desde hace más de un año, sin propietario interno reconocido.
Descubrimiento
OAuth app con scopes excesivos en Microsoft 365
Durante el inventario de OAuth apps conectadas al tenant detectamos "AcmeIntegrator SaaS" con scopes Mail.Read, Sites.ReadWrite.All y Files.ReadWrite.All concedidos a nivel de tenant 18 meses atrás. La empresa que registró la app ya no trabaja con el cliente desde hace 9 meses. Token sigue activo. Ningún empleado actual reconoce haberla aprobado.
Riesgo real
Acceso silencioso a correo y SharePoint
Con esos scopes la app puede leer cualquier buzón del tenant y modificar cualquier SharePoint. El token no genera login interactivo, no aparece en logs de inicio de sesión humana, no requiere MFA. La revisión de Unified Audit Log mostró accesos esporádicos en los últimos meses, todos dentro del comportamiento legítimo de la integración original. No es trivial distinguir uso lícito heredado de uso malicioso.
Evidencia
Trazabilidad documentada
Captura del registro de la app en Entra ID con fecha de consentimiento, scopes y empleado que aprobó (ya no en plantilla), histórico de accesos del Unified Audit Log filtrado por AppId, dependencias detectadas de procesos que aún consumían la integración, plan de migración propuesto. Todo apto para informar al DPO y para auditor ENS/ISO.
Remediación
Revocación controlada + política
Inmediato: revocación del consentimiento, invalidación de tokens activos, revisión de cualquier acceso en las 72 horas previas. Una semana: política de aprobación de nuevas OAuth apps (admin consent workflow), revisión trimestral programada de las existentes, deshabilitación automática de inactivas más de 90 días. Mensual: monitorización en alertas de cualquier nueva app con scopes elevados.
Caso técnico anonimizado basado en patrones reales. Sector y nombres alterados; el patrón técnico y el procedimiento de remediación mantienen fidelidad al original.
Cuándo encaja y cuándo no
Encaja muy bien
Cuándo merece la pena
- Organización con SaaS principales múltiples (M365 + Google + Salesforce + Slack + GitHub + integraciones)
- Cloud múltiple (AWS + Azure, o cualquier combinación con on-prem)
- Cumplimiento ISO 27001:2022, ENS Alta, NIS2 o DORA con auditor estricto
- Tras incidente que involucre token o cuenta de servicio comprometida
- M&A: heredar tenants con NHI desconocidas
- Equipo de desarrollo con integraciones múltiples a SaaS
- Modernización IAM: el siguiente paso natural tras consolidar IAM humano
Encaja menos
Cuándo no es lo primero
- Organización pequeña con un único SaaS y un único cloud: empezar con IAM humano básico
- IAM humano sin consolidar: hay que ordenarlo antes
- Sin ningún gestor de secretos y sin presupuesto para implantarlo: el proyecto se quedaría a medias
- Tras un incidente activo sin resolver: primero respuesta a incidentes
Cómo lo entregamos
Cinco fases. Las dos primeras se solapan parcialmente, las tres siguientes son secuenciales. El plan se adapta al diagnóstico: en organizaciones con buen IAM humano se acelera; en las que parten de cero hay que sostener mejor la fase de atribución.
1. Descubrimiento (1-3 semanas)
Inventario consolidado: NHI en cloud (AWS/GCP/Azure IAM), SaaS principales (M365, Google Workspace, Salesforce, GitHub, etc.), AD/Entra ID, gestor de secretos actual si existe, repositorios de código. Salida: inventario maestro con tipo, antigüedad, último uso, scopes.
2. Atribución y priorización (2-3 semanas)
Cada NHI a un propietario funcional con caducidad. Lo que no encuentra propietario, candidato a baja. Priorización por riesgo: scopes elevados sin uso, secretos viejos, cuentas sin MFA donde debería tenerla, accesos cruzados entre entornos productivos y no productivos.
3. Gobierno de secretos (2-4 semanas)
Implantación o reforma del gestor de secretos. Migración progresiva de secretos dispersos. Rotación automatizada de los más críticos. Pre-commit hooks y reglas CI para bloquear nuevos secretos en código.
4. Mínimo privilegio (2-4 semanas)
Análisis de uso real para cada NHI con permisos amplios. Reducción a least privilege real. Sustitución de claves estáticas por federación workload donde el cloud lo soporte. Política y workflow para nuevas concesiones.
5. Monitorización y handover
Alertas operativas en SIEM/SOAR del cliente, dashboard de salud del programa NHI, documentación operacional, formación al equipo de operación. Si se contrata operación continua, asumimos el ciclo; si no, transferencia ordenada.
Qué incluye el paquete documental
1. Inventario maestro NHI
Tabla consolidada con cada identidad: tipo, sistema, propietario, último uso, último rotación, scopes, criticidad y plan asignado.
2. Informe técnico de hallazgos
Cada hallazgo con descripción, riesgo, evidencia, recomendación priorizada y dependencias.
3. Informe ejecutivo
2-3 páginas sin jerga para dirección. KPIs del programa, riesgos top y plan de acción.
4. Roadmap de remediación
Plan priorizado por riesgo + esfuerzo: lo crítico inmediato, lo medio en 30-60 días, lo estructural en 90-180 días.
5. Políticas y workflows
Política de gestión de NHI, política de OAuth apps, workflow de aprobación y bajas, plantillas para propietarios.
6. Repositorio de evidencias
ZIP firmado con capturas, exports de los sistemas auditados, configuración propuesta y logs de actuaciones. Apto para auditor externo.
Adaptación por sector
SaaS B2B y software factory
Volumen muy alto de NHI por uso intensivo de integraciones SaaS y arquitecturas cloud-native. Foco en federación workload (AWS IRSA, GCP Workload Identity, Azure Managed Identities), GitHub Apps en lugar de PAT, gestión de secretos en CI/CD.
Entidades financieras
DORA art. 9 cubre identidades de aplicación. Foco en cuentas de servicio de sistemas de pago, integraciones con proveedores TIC críticos (PSP, core bancario), trazabilidad de cualquier acceso a sistemas que tocan transacciones.
Healthtech y sanidad
RGPD art. 9 (datos especiales). Foco en NHI con acceso a historia clínica, integraciones HL7/FHIR, identidades de dispositivos médicos conectados, segregación entre entornos de producción y pruebas.
AAPP y servicios públicos
ENS por categorización (op.acc.1, op.acc.4, mp.info.4). Foco en cuentas de servicio en sistemas legados, integraciones con plataformas administrativas (SIA, @firma), trazabilidad completa para auditor administrativo.
Industria y OT
NHI en el cruce IT/OT: cuentas de servicio que conectan sistemas industriales con el resto de la red, integraciones con plataformas SCADA/MES, identidades de robots y PLCs. Riesgo de movimiento lateral si están mal gobernadas.
Retail y e-commerce
Foco en API keys de pasarelas de pago, integraciones con marketplaces, OAuth a SaaS de marketing y analítica, cuentas de servicio de plataformas de logística. Volumen estacional alto.
Encaje regulatorio
| Marco | Referencia | Qué exige y cómo lo cubrimos |
|---|---|---|
| ISO 27001:2022 | A.5.16 / A.5.17 / A.8.2 | Gestión de identidades, información de autenticación y privilegios de acceso. Cubre NHI explícitamente. |
| ENS | op.acc.1 / op.acc.4 / mp.info.4 | Identificación, mecanismo de autenticación y cifrado de claves. Aplicable a categorías Media y Alta. |
| NIS2 | Art. 21.2.i | Soluciones de autenticación multifactor o continua y de cifrado donde corresponda. Aplica a las identidades de aplicación con acceso crítico. |
| DORA | Art. 9 + RTS gestión riesgo TIC | Política de gestión de derechos de acceso, incluida la de identidades de aplicación. Trazabilidad para supervisor financiero. |
| PCI DSS v4.0.1 | Req. 8.6 (cuentas no usuarias) | Cuentas de sistema y aplicación con autenticación robusta, sin reutilización, rotación documentada. |
| NIST CSF 2.0 | PR.AA / PR.IR | Identity, authentication and access management como categoría central, también para identidades no humanas. |
| RGPD | Art. 32.1.b/d | Confidencialidad e integridad permanentes y verificación regular de la eficacia. Las NHI con acceso a datos personales entran en alcance. |
Lo que solemos hacer y otros no
Inventario cruzado cloud + SaaS + on-prem + código
Muchos servicios solo cubren NHI en cloud o solo en SaaS. Sin la vista unificada se queda fuera el 30-50% del problema real.
Atribución forzosa con caducidad
Cada NHI tiene propietario funcional con renovación periódica obligatoria. Si nadie la reclama, candidata a baja. Es la única forma de detener el crecimiento silencioso.
Federación workload en lugar de claves
Donde el cloud lo permita (AWS IRSA, GCP Workload Identity Federation, Azure Managed Identities), sustituir secretos estáticos por federación. Elimina la categoría de problema.
Pre-commit + CI bloqueante
Implantamos hooks que bloquean nuevos secretos antes del commit y reglas CI que fallan el build. Evitamos que la deuda vuelva a crecer mientras limpiamos.
Análisis de uso real para least privilege
No reducimos permisos por intuición. Analizamos el uso histórico real de cada NHI privilegiada antes de proponer la reducción concreta.
Plan de baja segura
Procedimiento para revocar NHI sin romper integraciones: dependencias mapeadas previamente, ventana de revocación, verificación post-baja, archivado documentado.
Objeciones que escuchamos y cómo las contestamos
«Nuestro IAM ya lo lleva un proveedor»
Casi siempre se refiere a IAM humano. Las NHI son una disciplina distinta con controles propios. Trabajamos con vuestro proveedor IAM existente, no lo sustituimos: aportamos la capa NHI que normalmente queda fuera del scope habitual.
«Es un proyecto enorme, no nos cabe»
Lo planteamos por fases. Diagnóstico inicial de 1-2 semanas para entender volumen. Primera fase con foco solo en NHI críticas (tokens de admin, cuentas con acceso a datos sensibles, OAuth apps con scopes elevados). Resto se planifica en sprints posteriores. No hay que comerse el plato entero.
«Cualquier rotación rompe integraciones»
Por eso el procedimiento es siempre: identificar dependencias, ventana programada con propietario, plan de rollback, verificación. No rotamos a ciegas. Y donde el riesgo de rotura es alto y el riesgo de secreto comprometido es bajo, lo decimos honestamente y se acepta la deuda con plazo.
«¿Vamos a necesitar más herramientas?»
Depende del punto de partida. Si ya hay gestor de secretos, no. Si no hay, recomendamos uno apropiado al stack, sin sesgo de partner: integración nativa con vuestro cloud principal, precio predecible, rotación automatizada de los proveedores comunes. Si lo vuestro encaja con Vault de código abierto, lo recomendamos sin levante de licencia.
«¿Es solo para empresas grandes?»
No. Una organización mediana con M365 + Google Workspace + GitHub + 5 SaaS principales ya supera los 200-300 NHI sin saberlo. El programa escala: en una organización mediana se hace en 8-12 semanas; en una grande puede llegar a 6 meses por la complejidad organizativa, no técnica.
«¿Esto reduce la productividad de desarrollo?»
Al revés. Bien implantado, el equipo de desarrollo deja de gestionar secretos manualmente: los pide al gestor por API, la rotación es transparente y dejar de mantener archivos .env ahorra trabajo. El coste inicial de migrar se amortiza en pocos meses.
Cómo medimos la salud de un programa NHI
Seis indicadores que reportamos en sesión mensual de gobierno. Permiten al comité de dirección ver si el programa avanza, se estanca o retrocede.
% NHI con propietario asignado
Indicador maestro. Objetivo: >95% en 90 días. Sin propietario no hay quien tome decisiones sobre la identidad.
% NHI con secreto rotado en plazo
Según política definida (30/90/180 días según criticidad). Objetivo: >90%. Indicador directo de salud operativa.
% NHI con scopes least privilege
Identidades cuyos scopes han sido revisados y reducidos en los últimos 12 meses. Objetivo: 100% para críticas, >80% para resto.
Tiempo medio de baja de NHI
Días desde detección de NHI sin uso hasta su baja efectiva. Objetivo: <30 días para no críticas, <7 días si hay incidente.
Nº secretos detectados en código (CI)
Tendencia mensual de secretos bloqueados por hooks/CI. Objetivo: tendencia descendente sostenida.
Cobertura del inventario
Porcentaje de sistemas en alcance cuyo inventario NHI está actualizado en el último trimestre. Objetivo: 100% para críticos.
Errores habituales en programas NHI
- Empezar por la herramienta. Comprar una solución NHI sin haber hecho inventario y atribución previa garantiza tirar el presupuesto.
- Tratar NHI con los mismos controles que humanos. MFA y password expiry no aplican igual: hace falta rotación de secretos automatizada y federación workload donde se pueda.
- Inventariar solo cloud y olvidar SaaS. Las OAuth apps a M365/Google/Salesforce son donde más exposición silenciosa hay.
- No atribuir propietario funcional. Sin propietario nadie decide qué hacer con una NHI dudosa: o se quedan todas o se rompen integraciones críticas al borrar a ciegas.
- Rotar a ciegas sin mapeo de dependencias. La primera vez que se rota un secreto crítico sin saber qué lo consume, se rompen sistemas productivos.
- Reducir privilegios sin análisis de uso. Provoca rotura inmediata o, peor, queda registrada y se revierte sin documentar.
- Limpiar código actual sin tocar historial Git. El secreto sigue accesible para cualquiera que clone el repositorio o tenga clon previo.
- Hacerlo como proyecto puntual sin operación posterior. Sin ciclo continuo, en 6 meses está igual que al principio.
Glosario rápido de la jerga NHI
NHI
Non-Human Identity. Identidad que se autentica frente a un sistema sin ser una persona.
Service Account
Cuenta de servicio en un directorio (AD, Entra ID) usada por aplicaciones o procesos automatizados.
OAuth app
Aplicación registrada en un proveedor de identidad (M365, Google, etc.) con consentimiento para acceder a APIs en nombre del tenant.
API key
Clave estática emitida por un proveedor SaaS o cloud para autenticar peticiones a su API.
Workload Identity
Identidad asignada a una carga de trabajo (pod K8s, lambda, función) que se autentica sin secreto estático mediante federación.
PAT
Personal Access Token. Token emitido a un usuario para uso programático en GitHub/GitLab/Atlassian. Suele heredar permisos amplios.
Vault / Secrets Manager
Gestor centralizado de secretos con API, control de acceso, auditoría y rotación. HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, CyberArk.
gMSA
Group Managed Service Account. Cuenta de servicio de AD con contraseña gestionada automáticamente por el dominio. Útil para servicios on-prem.
IRSA / Workload Identity
Mecanismos de AWS y GCP para que pods de Kubernetes asuman roles cloud sin secretos estáticos.
Admin Consent Workflow
Política en Entra ID/Google Workspace para que un administrador apruebe nuevas OAuth apps antes de que reciban consentimiento.
Token de corta duración
Token con expiración corta (minutos/horas) renovado mediante refresh token o federación. Reduce ventana de uso indebido.
Federación workload
Patrón que sustituye secretos estáticos por confianza basada en identidad de la carga de trabajo (OIDC, certificados). Cloud nativo.
Servicios relacionados en Hard2bit
IAM
Servicio matriz de identidades humanas. NHI es la disciplina hermana centrada en lo no humano.
Ver →
Seguridad Microsoft 365
Buena parte de las NHI críticas de muchas organizaciones viven en M365: OAuth apps, service principals, cuentas de servicio.
Ver →
Auditoría de código fuente
Donde más secretos hardcoded encontramos. Coordinación habitual con NHI para limpieza y rotación.
Ver →
Auditoría de seguridad API
Las APIs autenticadas con tokens NHI son objetivo natural si los tokens están mal gestionados.
Ver →
Auditoría integral
Cuando NHI es parte de un escaneo más amplio que incluye también infraestructura, identidad humana y procesos.
Ver →
Hardening de sistemas
El bastionado de sistemas incluye gestión de identidades locales y de servicio del propio sistema operativo.
Ver →
Superficie de ataque
Detección de secretos filtrados públicamente, repositorios expuestos, tokens en commits públicos.
Ver →
Gestión riesgo terceros
Las integraciones con proveedores externos generan NHI cuya seguridad depende del programa de terceros.
Ver →
Respuesta a incidentes
Si la auditoría revela compromiso activo (token usado por atacante), escalado inmediato a respuesta.
Ver →
Preguntas frecuentes
¿Qué es exactamente una identidad no humana (NHI)?
Cualquier identidad que se autentica frente a un sistema sin ser una persona: cuentas de servicio en Active Directory o Entra ID, tokens OAuth de aplicaciones SaaS, claves de API, secretos de cliente OIDC, certificados de cliente, identidades workload (Kubernetes ServiceAccounts, IAM roles de AWS/GCP/Azure, identidades administradas), tokens personales de acceso (PAT) emitidos a integraciones, credenciales de RPA o de pipelines CI/CD. En la mayoría de organizaciones la proporción NHI:humano va de 20:1 a 50:1. Y crece sola.
¿Por qué se ha convertido en un problema urgente?
Tres causas. Primero, multiplicación silenciosa: cada nueva herramienta SaaS, integración o microservicio crea identidades sin que nadie las contabilice. Segundo, persistencia: las NHI rara vez se borran cuando se desconecta una integración o se va un proveedor. Tercero, falta de controles: muchas no tienen MFA, su rotación es manual y olvidada, y se les conceden permisos amplios 'por si acaso'. Cuando un atacante compromete una NHI activa con permisos excesivos, no hay alerta de comportamiento anómalo como sí ocurriría con un usuario humano.
¿Cómo se diferencia este servicio de la gestión IAM tradicional?
IAM tradicional se diseñó para usuarios humanos: provisión, autenticación con contraseña, MFA, joiners/movers/leavers, revisión periódica. Las NHI siguen reglas distintas: no tienen ciclo de vida ligado a RRHH, los controles típicos (MFA, password rotation) no aplican directamente, requieren rotación de secretos automatizada, federación a través de OIDC/SAML o identidades workload, y cuesta atribuirles propietario funcional. El servicio cubre el ciclo completo específico de NHI: descubrimiento, atribución de propietario, gobierno de secretos, mínimo privilegio, monitorización y baja segura.
¿Qué incluye exactamente vuestro servicio?
Cinco fases. Descubrimiento: inventario consolidado de NHI en cloud (AWS/GCP/Azure), SaaS (Microsoft 365, Google Workspace, Salesforce, Slack, GitHub), on-prem (AD, bases de datos, sistemas legados) y código (secretos en repos). Atribución: cada NHI a un propietario funcional con caducidad. Gobierno de secretos: implantación o reforma de gestor de secretos (Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) con rotación automatizada. Reducción de privilegios: pasar de permisos excesivos a least privilege real, con análisis de uso histórico. Monitorización: alertas sobre uso anómalo, expiración, rotación pendiente, identidades huérfanas.
¿Cuánto cuesta y cuánto dura?
Programa típico de implantación: 8-16 semanas para una organización mediana (500-3.000 empleados, 5-20 SaaS principales, cloud múltiple), con 1-2 consultores. Coste orientativo: 35-90 mil euros. Antes presupuestamos hacemos diagnóstico inicial de 1-2 semanas para dimensionar volumen de NHI y complejidad. Sin eso, cualquier cifra es estimación. La operación posterior (monitorización + rotaciones + onboarding/offboarding de NHI) se gestiona con suscripción mensual o se transfiere al equipo interno con formación.
¿Tenemos que cambiar de gestor de secretos?
No necesariamente. Si ya usáis HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, CyberArk o similar, trabajamos sobre lo existente. Lo evaluamos en el diagnóstico inicial. Si no hay gestor o el existente es insuficiente (típicamente: usar variables de entorno en producción, archivos .env desplegados, GitHub Actions secrets sin rotación, secretos en pipelines de Jenkins viejos), recomendamos uno apropiado al stack y volumen, con criterios claros: integración nativa con vuestro cloud principal, soporte SCIM o federación, rotación automatizada de los proveedores más comunes, y precio total predecible.
¿Sirve para auditoría ISO 27001, ENS, NIS2 o DORA?
Sí. ISO 27001:2022 (A.5.16 Gestión de identidades, A.5.17 Información de autenticación, A.8.2 Privilegios de acceso) cubre explícitamente identidades no humanas. ENS (op.acc.1, op.acc.4, mp.info.4) exige gestión completa de identidades y de claves. NIS2 art. 21.2.i requiere uso de soluciones de autenticación multifactor o continua y de cifrado donde corresponda. DORA art. 9 + RTS de gestión de riesgo TIC cubre identidades de aplicación. Entregamos evidencia trazable de inventario, propietarios, rotación, mínimo privilegio y monitorización lista para auditor.
¿Cómo gestionáis identidades de integraciones con terceros sobre las que no tenemos control?
Es uno de los puntos críticos. Cuando integráis una SaaS de terceros con vuestro Microsoft 365 o Google Workspace mediante OAuth, esa SaaS recibe un token con permisos que perduran sin que nadie controle su rotación. Cubrimos esto en dos niveles: gobierno de OAuth apps (inventario, revisión periódica de scopes excesivos, política de aprobación de nuevas integraciones, deshabilitación automática de apps sin uso reciente) y, donde existe, integración con CASB o gestión de SaaS. Para integraciones legacy con API keys de larga vida, plan de transición a tokens de corta duración con rotación automatizada.
¿Y los secretos hardcoded que ya están en el código y en historia Git?
Lo coordinamos con auditoría de código. Escaneo completo del historial Git con herramientas como Gitleaks/TruffleHog, no solo del HEAD actual. Cada secreto encontrado se valida (¿sigue activo?), se rota inmediatamente en el proveedor correspondiente, se elimina del código actual y, según riesgo y tipo de repositorio, se purga del historial Git (git filter-repo + force-push + notificación a equipo). En paralelo, implantamos pre-commit hooks que bloquean nuevos secretos antes de que entren al repo, más reglas en CI que fallan el build si detectan patrones de secret.
¿Cómo arrancamos un proyecto en Hard2bit?
Llamada de 30 minutos para entender el ecosistema (cloud, SaaS principales, stack de desarrollo, herramienta IAM actual, gestor de secretos si existe) y el motivo de buscar el servicio (cumplimiento, incidente reciente, modernización). Si tiene sentido, diagnóstico inicial de 1-2 semanas con acceso lectura a cloud e IAM para dimensionar el volumen real de NHI. Con eso emitimos propuesta firme: alcance, ventana, equipo, entregables y precio cerrado. Sin compromisos hasta la firma. Si vemos que el proyecto requiere combinarse con consolidación IAM previa o con auditoría de código, lo decimos honestamente.
¿Sabes cuántas identidades no humanas tienes?
Llamada de 30 minutos para entender el ecosistema y el motivo. Diagnóstico inicial de 1-2 semanas para dimensionar volumen real. Propuesta firme tras el diagnóstico. Sin compromisos hasta la firma. NDA estándar previo al primer acceso.