La inmunidad de la estructura de identidad es un enfoque para gestionar la identidad en un entorno de infraestructura complejo como la nube híbrida o multicloud.
Un hecho eterno en el desarrollo de software es que la complejidad aumenta. Para el CISO, esta verdad se ve en el trabajo en la infraestructura de la empresa - el número de componentes se expande junto con la sofisticación y la diversidad de las plataformas que los alojan.
La seguridad y el cumplimiento de las normativas se ven muy afectados por este hecho, lo que exige algún tipo de marco de seguridad ampliamente aplicable que no aumente la complejidad ni impida el impulso de los desarrolladores. La inmunidad del tejido de identidad (IFI) es un intento de responder a esa llamada.
De la gestión de identidades al tejido de identidades
La IFI comienza como una forma de pensar sobre el panorama del software empresarial y su relación con la seguridad. Está en la línea de la arquitectura de confianza cero, en el sentido de que ofrece una estrella del norte mental que puede utilizarse para pilotar a través del pantano de complejidad que es el software moderno.
IFI dice: crear una capa de seguridad compartida y distribuida que cubra toda la empresa. Incorpore a esta capa la supervisión y la gobernanza. Hacer que las aplicaciones y los servicios dependan de la capa para la autorización y la autenticación.
Otro término para "tejido de identidad" es "identidad convergente". Significan lo mismo: extraer la identidad en una capa abstracta. A costa de una planificación y configuración iniciales adicionales, esta capa propone reducir las oportunidades de ataque, mejorar la mitigación y la respuesta, y simplificar los controles de identidad y acceso incluso en las circunstancias más intrincadas.
El tejido de identidades frente a la gestión tradicional del acceso a las identidades
El telón de fondo o la tesis a la que responde IFI es que las soluciones existentes de gestión de acceso a la identidad (IAM) son insuficientes. La IAM surgió de la necesidad de proteger las aplicaciones basadas en la nube y existe como otro tipo de servicio en la nube del que dependen otros servicios para obtener información de autorización y autenticación.
Este modelo funciona bien hasta cierto punto, pero cuando la empresa digital abarca muchos proveedores de nube y/o tiende puentes entre implantaciones públicas, privadas y locales, empieza a quebrarse. La realidad es que las implantaciones de nubes múltiples e híbridas son un hecho en el desarrollo moderno.
La infraestructura híbrida, en la que algunos componentes se alojan en las instalaciones y otros en proveedores de nube, necesita especialmente un modelo de seguridad mejorado. Esto se debe a que cuantos más límites haya que cruzar -cuantos más componentes interactúen entre sí-, más posibilidades habrá de que se produzcan ataques y de que se ponga en peligro información o servicios sensibles.
¿Cuándo es necesaria la inmunidad de tejido de identidad?
Un tejido de identidad se convierte en una opción atractiva cuando lo merece, pero su adopción antes de que sea realmente necesaria añade una complejidad innecesaria. La clave está en conocer el punto de inflexión.
Si hace su trabajo con un mínimo de fricción, basta con un simple marco de proveedor de identidad. Cuando la complejidad infraestructural empieza a causar serias dificultades dentro de la organización, la capa de abstracción de seguridad descrita por IFI ofrece una salida, afirma Dmitry Sotnikov, jefe de producto de Cayosoft. "Las aplicaciones están ahora muy distribuidas, y los usuarios, socios y clientes se conectan a los sistemas desde dondequiera que estén, lo que deja a los equipos de seguridad sin una red y unos límites físicos fácilmente definidos que proteger."
Los signos de que las soluciones de identidad son inadecuadas incluyen la dificultad para gestionar el acceso de los usuarios, el aprovisionamiento de cuentas y la respuesta a incidentes de seguridad tanto reales como simulados. Los directivos pueden encontrarse con que es muy difícil obtener una perspectiva general de la disposición de seguridad de una empresa y tomar medidas que afecten a la seguridad en su conjunto resulta engorroso o extremadamente difícil.
La IFI ofrece una forma de abstraer la identidad cuando las partes constituyentes del sistema son homogéneas y descentralizadas. Esta situación se conoce como "dispersión de la identidad". Todo el mundo, desde el CISO hasta el usuario final, conoce la proliferación de identidades. Para el usuario, es molesto y peligroso. Para el CSO, es un gran problema. Cuanto más distribuidos están los elementos de seguridad, más difícil resulta formarse una imagen completa de ellos, gestionarlos, identificar y corregir agujeros y responder a los incidentes.
Las ventajas de la inmunidad del tejido de identidad
La "inmunidad" en IFI se refiere a una resistencia inherente integrada en el tejido del sistema. Una capa de seguridad integrada crea un lugar para aplicar una política coherente, una supervisión continua y una gestión centralizada de los cambios. En otras palabras, el tejido ofrece un contexto unificado para aplicar los principios de seguridad.
Un tejido de identidad busca proporcionar una capa en la que puedan apoyarse otros componentes. Esta capa parte de la diversidad de la infraestructura como supuesto y simplifica al máximo la participación en ella de los componentes con perfiles diferentes.
Sin un enfoque holístico como la IFI, el CISO y su equipo están siempre jugando a la lotería con las vulnerabilidades y los atacantes. La principal ventaja de la IFI es que reúne el universo de la seguridad en un todo cohesionado y abordable.
"Identity Fabric Immunity (IFI) no puede compararse con la IAM tradicional; más bien, describe un estado ideal que una organización puede alcanzar utilizando enfoques IAM dispares y los mejores servicios de identidad disponibles que permiten construir un tejido de identidad cohesivo", afirma Mark Callahan, director senior de marketing de producto en Strata.io.
"Una inmunidad de tejido de identidad no es un producto, sino el resultado de implementar un software de orquestación de identidad que permite a la organización crear un tejido de identidad que integra sus soluciones y productos IAM existentes e incompatibles."
Cómo se aplica la inmunidad del tejido de identidad
He aquí algunas funciones clave en la implantación de una IFI:
IdP (proveedor de identidad): Debe existir un directorio central de registro para los servicios de autenticación de las distintas funciones de la IFI, y es éste. Puede ser un almacén de datos como el protocolo ligero de acceso a directorios (LDAP) o un IAM en la nube. Al pasar a la IFI, algunas credenciales pueden migrarse desde almacenes de datos independientes.
Pasarela API: Este componente facilita la comunicación segura entre las aplicaciones y el tejido de identidad. Es el aspecto de enrutamiento de la red que proporciona un punto central de orquestación y seguridad para las distintas aplicaciones y servicios.
Identity broker (IB): Una especie de fachada que simplifica la comunicación entre los componentes cliente para negociar la autenticación. Es un componente dedicado a facilitar las interacciones iniciales de autenticación entre consumidores y proveedores de ID.
Motor de políticas: Este componente define las reglas de autorización en función de las funciones, los atributos y el contexto del usuario (por ejemplo, ubicación, dispositivo). Junto con el ID broker, proporciona una abstracción de alto nivel para suavizar las irregularidades de la infraestructura.
En general, la IFI avanza hacia respuestas coherentes y gestionables de forma centralizada a las preguntas: ¿Cómo se autentica y autoriza una aplicación? ¿Cómo se aprovisiona e interactúa con una API? ¿Cómo se crean y revocan credenciales?
Integrar estas respuestas en un marco coherente significa reducir la superficie de ataque y los misterios preocupantes de un sistema. Cuanto mayor sea la empresa, más difícil será alinearlas, por lo que resulta útil pensar en un modelo por etapas o de madurez.
Cuando falla la IAM convencional, la IFI es una respuesta convincente
En un modelo convencional de gestión de identidades, las distintas aplicaciones y servicios que componen las operaciones empresariales dependen directamente de almacenes de datos concretos para sus credenciales. Las interacciones y las redes que las soportan suelen ser soluciones puntuales nacidas de las necesidades específicas de la aplicación en desarrollo en ese momento.
La realidad de la empresa moderna es que a menudo incluye un espectro que abarca servicios heredados y modernos en la nube y todo lo que hay en medio. A veces, lo que podría calificarse de heredado es un valioso proceso empresarial que funciona bien, salvo por la dificultad de gestionar e integrar sus procesos de seguridad.
A veces, el cumplimiento de la normativa u otras consideraciones exigen implantaciones locales, en la nube privada o entre proveedores. La conclusión es que este tipo de complejidad de infraestructuras y procesos está aquí para quedarse y, sin embargo, la seguridad exige uniformidad y control con la misma insistencia.
"Un CSO que esté modernizando aplicaciones e identidades para la nube mientras lucha con la deuda técnica de IAM heredada debería considerar la construcción de un tejido de identidades", dice Callahan. "Un indicador clave de bandera para implementar IFI se produce cuando una empresa está luchando para gestionar identidades en múltiples proveedores de identidad en múltiples nubes y en nubes híbridas (IDP en las instalaciones e IDP basado en la nube)."
Un escenario de inmunidad al tejido identitario
Para ayudar a visualizar el concepto, considere un escenario donde hay un backend - podría ser Java, .NET, NodeJS o algo más, la pila particular no es importante - que expone APIs e implementa la lógica de negocio. Habla con un almacén de datos en algún lugar y, en cuanto a la seguridad, acepta credenciales (probablemente nombre de usuario/contraseña) y las valida.
Una vez validadas, se añade algún tipo de token a la sesión del usuario. El token podría ser manejado de varias maneras, como a través de una cookie o una cabecera de petición. El componente backend requeriría algo como lo siguiente para pasar a una configuración IFI:
Colocarlo detrás de una pasarela API. Las solicitudes de los clientes se envían ahora a la pasarela API, que es responsable de la autenticación y, potencialmente, también de la autorización.
Alojar las credenciales de usuario en un proveedor de identidad independiente. Esto podría gestionarse de dos formas básicas: migrar las credenciales existentes al IdP o pedir a los usuarios que se vuelvan a registrar en el nuevo IdP.
La pasarela de API se comunica ahora con el IdP para proponer credenciales de usuario y recibir un token de autorización, probablemente un JWT (token web JSON) y preferiblemente a través de un protocolo estándar como OIDC.
Una vez autenticado el usuario, las solicitudes posteriores son juzgadas por su token. Un token como JWT puede contener declaraciones de usuario como roles, y sobre esa información se puede procesar la autorización con la pasarela API y el IdP. Esto implica más modificaciones de la aplicación existente.
Otros componentes pueden ser vistos como variaciones de esto. Por ejemplo, puede haber un frontend JavaScript que hable con este backend. Ahora apuntaría a la pasarela de API y se ocuparía de la negociación de la autenticación (y posiblemente de la autorización) utilizando el nuevo mecanismo basado en tokens. Los componentes de microservicios que ya utilizan una pasarela de API son más fáciles de migrar, dependiendo de su proceso de autenticación existente.
Sin embargo, algunos elementos de la empresa son más difíciles de gestionar por razones que van más allá de la tecnología necesaria, como los procesos de desarrollo, como las herramientas de creación, la integración continua y el acceso de alojamiento a máquinas virtuales, PaaS y serverless.
Si bien IFI está diseñado para abordar directamente el acceso de los usuarios finales a estos (los empleados, socios y clientes que los utilizan), el acceso entre bastidores que utilizan los propios desarrolladores puede resultar más complicado debido a sus herramientas únicas y su necesidad de agilidad.
"Antes de que se pueda hacer nada, los CSO deben exponer sus argumentos a la dirección de la empresa para que los apruebe, explicando que una inversión en IFI sirve como habilitador del negocio y como ruta crítica para contener los riesgos empresariales", afirma Sotnikov.
La idea de un tejido de identidad seguirá cobrando importancia en los próximos años. Requiere una inversión significativa de tiempo y dinero, pero afortunadamente puede abordarse en etapas incrementales a medida que la necesidad se justifica ante la empresa.
Fuente: CSO
Comments