5 Min. Lectura<\/p>\n
Las cuentas de servicio, claves de API y agentes de IA superan a menudo a las cuentas humanas por un amplio margen. Muchas de estas accesos no son asignadas por nadie. Exactamente all\u00ed se abre la pr\u00f3xima brecha: fuera del endpoint endurecido.<\/strong><\/p>\n Lo esencial en breve<\/p>\n Relacionado:<\/span>\u00bfQu\u00e9 control permanece tras el despliegue de agentes?<\/a> \/<\/span> Kimi detiene suscripciones: 7 verificaciones para el CAPEX de IA<\/a><\/p>\n \u00bfQu\u00e9 son las identidades de m\u00e1quinas?<\/strong> Las identidades de m\u00e1quinas son accesos t\u00e9cnicos mediante los cuales los sistemas act\u00faan. Incluyen cuentas de servicio, claves de API, tokens, certificados, bots y agentes de IA. Estas identidades autentifican sistemas entre s\u00ed, poseen derechos y crecen con cada integraci\u00f3n. Sin propietario y sin ciclo de vida, a menudo permanecen activos despu\u00e9s de que su prop\u00f3sito haya desaparecido.<\/p>\n<\/div>\n Cada migraci\u00f3n a la nube, cada nuevo microservicio y cada automatizaci\u00f3n generan identidades. Una pipeline de despliegue necesita un token para lanzar c\u00f3digo. Un servicio de monitorizaci\u00f3n necesita una clave para leer m\u00e9tricas. Una integraci\u00f3n entre dos plataformas SaaS crea una cuenta t\u00e9cnica en segundo plano. Ninguno de estos elementos aparece en los procesos cl\u00e1sicos de RR.HH., porque detr\u00e1s de estos accesos no hay un ser humano que sea onboarded o offboarded.<\/p>\n En muchas organizaciones, las identidades no humanas superan con creces a las humanas. Lo decisivo es menos la relaci\u00f3n exacta que la din\u00e1mica de crecimiento. Las identidades humanas crecen de forma lineal con la plantilla. Las identidades de m\u00e1quinas crecen con cada decisi\u00f3n arquitect\u00f3nica, con cada herramienta del stack y, en la actualidad, con cada agente de IA que accede a los sistemas de forma aut\u00f3noma. El volumen crece m\u00e1s r\u00e1pido de lo que la mayor\u00eda de los programas de identidad pueden seguir.<\/p>\n El problema se agrava porque estas identidades est\u00e1n mal documentadas. Una clave de API se crea r\u00e1pidamente para poner en marcha una integraci\u00f3n. Termina en un archivo de configuraci\u00f3n, un script o un gestor de secretos y rara vez se vuelve a tocar. Quien la cre\u00f3, para qu\u00e9 sirve y si a\u00fan se necesita, suele desconocerse despu\u00e9s de algunos cambios de personal.<\/p>\n Al salir, el reflejo de offboarding se activa. Las cuentas de m\u00e1quinas a menudo siguen existiendo hasta que alguien las aborda.<\/p>\n<\/blockquote>\n Cuando una empleada abandona la empresa, entra en vigor un proceso establecido. Bloquear la cuenta, recuperar los equipos, retirar los permisos. En el caso de identidades de m\u00e1quinas, ese reflejo casi no existe. Una cuenta de servicio, creada por un desarrollador que ya dej\u00f3 la compa\u00f1\u00eda para un proyecto, sigue activa. El token de una aplicaci\u00f3n que se apag\u00f3 nunca se revoca. La clave de prueba que logr\u00f3 introducirse por error en producci\u00f3n sigue vigente.<\/p>\n Estos accesos hu\u00e9rfanos resultan especialmente atractivos para los atacantes. Suelen estar dotados de amplios permisos, ya que el principio de privilegios m\u00ednimos se aplica con menos rigor a cuentas t\u00e9cnicas que a usuarios humanos. Rara vez se les supervisa, pues nadie espera que muestren conductas sospechosas. Adem\u00e1s, eluden muchos mecanismos de protecci\u00f3n dise\u00f1ados para usuarios humanos. La autenticaci\u00f3n de m\u00faltiples factores no sirve ante una clave API est\u00e1tica. Un token robado se comporta t\u00e9cnicamente como un token leg\u00edtimo.<\/p>\n Credenciales comprometidas y secretos mal gestionados forman parte de los vectores de ataque recurrentes. Con frecuencia se encuentran claves y tokens en el c\u00f3digo, en un repositorio o en un archivo de registro: m\u00e1s all\u00e1 de la contrase\u00f1a humana. Quien solo asegura la faceta humana protege solo una parte menor de la superficie de ataque.<\/p>\n Donde realmente reside el riesgo<\/p>\n La mayor\u00eda de las identidades en una pila moderna no son humanas.<\/strong> Exactamente esas cuentas permanecen sin supervisi\u00f3n durante el mayor tiempo, suelen contar con los permisos m\u00e1s amplios y eluden los mecanismos de protecci\u00f3n dise\u00f1ados para usuarios humanos. El endpoint est\u00e1 endurecido. La cuenta de servicio de 2021 no lo est\u00e1.<\/p>\n<\/div>\n El camino fuera del caos se aborda mediante una gesti\u00f3n estructurada del inventario. Un producto de seguridad adicional por s\u00ed solo no lo soluciona. Cuatro pasos forman un programa s\u00f3lido.<\/p>\n Primero, descubrimiento e inventario.<\/strong> Antes de asegurar cualquier cosa, se necesita una visi\u00f3n general. \u00bfQu\u00e9 cuentas de servicio, claves, tokens y bots existen, en qu\u00e9 sistemas, con qu\u00e9 permisos? Las plataformas en la nube, pipelines de CI\/CD, gestores de secretos e integraciones SaaS son los lugares t\u00edpicos. Una revisi\u00f3n manual inicial es mejor que esperar a la herramienta perfecta.<\/p>\n Segundo, asignar la propiedad.<\/strong> Cada identidad de m\u00e1quina necesita un responsable humano. Una cuenta sin propietario es una cuenta que nadie desactivar\u00e1, porque nadie se siente responsable. La asignaci\u00f3n de la propiedad convierte un token an\u00f3nimo en una decisi\u00f3n rastreable, que puede revisarse y revocarse.<\/p>\n Tercero, privilegio m\u00ednimo y rotaci\u00f3n.<\/strong> Las cuentas t\u00e9cnicas a menudo reciben m\u00e1s permisos de los necesarios, porque es m\u00e1s r\u00e1pido. Cada identidad deber\u00eda tener solo los permisos que su tarea requiere. Los secretos est\u00e1ticos e indefinidos deben reemplazarse por credenciales de acceso autogeneradas y rotativas. Una clave que se emite de nuevo cada pocas horas es un objetivo mucho m\u00e1s peque\u00f1o.<\/p>\n Cuarto, ciclo de vida y desprovisionamiento.<\/strong> Las identidades de m\u00e1quina necesitan el mismo ciclo de vida que los humanos. Cuando se da de baja una aplicaci\u00f3n, se finaliza un proyecto o se elimina una integraci\u00f3n, el acceso asociado debe desaparecer autom\u00e1ticamente. Un an\u00e1lisis peri\u00f3dico revela cuentas que no muestran actividad desde hace meses. Estas \u201ccarta muertas\u201d son los primeros candidatos para su revocaci\u00f3n.<\/p>\n La pr\u00f3xima ola proviene del propio departamento de innovaci\u00f3n. Los agentes de IA aut\u00f3nomos, que ejecutan tareas de forma independiente, necesitan acceso a sistemas, datos y otros servicios. Cada uno de estos agentes es una nueva identidad de m\u00e1quina, a menudo con amplios permisos para operar de forma flexible. A diferencia de un script r\u00edgido, un agente toma decisiones en tiempo de ejecuci\u00f3n. Su comportamiento es m\u00e1s impredecible y, por tanto, m\u00e1s dif\u00edcil de supervisar.<\/p>\n Quien no controle el desorden de identidades hoy, importar\u00e1 el problema con cada iniciativa de IA en una forma agravada. Un agente con permisos excesivos al que nadie le ha asignado un propietario es exactamente el tipo de acceso que, dentro de dos a\u00f1os, llamar\u00e1 la atenci\u00f3n por estar hu\u00e9rfano. La disciplina que hoy se exige a las cuentas de servicio es la base para desplegar de manera segura agentes de IA.<\/p>\n El inicio es poco espectacular y precisamente por eso resulta eficaz. Un inventario de las identidades no humanas en los entornos m\u00e1s cr\u00edticos, empezando por la plataforma en la nube y las pipelines centrales. Cada identidad encontrada recibe tres datos: prop\u00f3sito, propietario y \u00faltima actividad. Todo aquello sin un prop\u00f3sito claro o sin actividad en los \u00faltimos meses se a\u00f1ade a una lista de verificaci\u00f3n. A partir de esa lista se lleva a cabo la primera acci\u00f3n de limpieza y, a partir de ella, se establece una regla para el futuro. No se crea un nuevo acceso t\u00e9cnico sin un propietario designado y sin una condici\u00f3n de caducidad definida. El n\u00famero de identidades de m\u00e1quinas seguir\u00e1 aumentando. Si crecen de forma controlada o descontrolada depende de esta disciplina.<\/p>\n Se refieren a todos los accesos detr\u00e1s de los cuales no hay una persona: cuentas de servicio, claves API, tokens, certificados, bots y agentes de IA aut\u00f3nomos. Se autentican frente a sistemas y poseen permisos, pero rara vez se gestionan mediante los mismos procesos que las cuentas de usuarios humanos. En entornos actuales, suelen ser la mayor\u00eda en n\u00famero.<\/p>\n<\/details>\n Porque siguen operando con privilegios completos aunque nadie tenga responsabilidad sobre ellos. La autenticaci\u00f3n de m\u00faltiples factores no sirve ante una clave est\u00e1tica. Un token robado se comporta t\u00e9cnicamente como uno leg\u00edtimo. Los atacantes aprovechan precisamente esas cuentas no supervisadas, ya que rara vez son vigiladas y suelen ofrecer amplios permisos.<\/p>\n<\/details>\n Con visibilidad antes que control. Una auditor\u00eda manual de los entornos m\u00e1s cr\u00edticos, empezando por la plataforma en la nube y los pipelines centrales, supera la espera de una herramienta perfecta. Cada identidad recibe prop\u00f3sito, propietario y \u00faltima actividad. Aquellas sin prop\u00f3sito o sin actividad se revisan y, si procede, se eliminan.<\/p>\n<\/details>\n M\u00e1s del medio MBF<\/p>\n\n
Por qu\u00e9 la cifra de identidades de m\u00e1quinas se descontrola<\/h2>\n
\n
Accesos hu\u00e9rfanos permanecen activos despu\u00e9s del proyecto<\/h2>\n
Cuatro pasos para controlar el sprawl de identidad<\/h2>\n
Agentes de IA multiplican el mismo error de ciclo de vida<\/h2>\n
El primer paso en los pr\u00f3ximos 90 d\u00edas<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfQu\u00e9 son las identidades no humanas o de m\u00e1quinas?<\/strong><\/summary>\n
\u00bfPor qu\u00e9 los accesos hu\u00e9rfanos son tan peligrosos?<\/strong><\/summary>\n
\u00bfCon qu\u00e9 comenzar si el inventario es inmanejable?<\/strong><\/summary>\n