Nuevo proyecto de código abierto brinda acceso de identidad consistente a múltiples nubes



Multicloud es una realidad para muchas organizaciones, ya sea por diseño o por accidente. Y cuando las aplicaciones y los datos se implementan en múltiples entornos de nube, la creación y administración de políticas de acceso de identidad coherentes se convierte en un desafío.

Hexa es un nuevo proyecto de código abierto de la empresa de orquestación de identidad Strata Identification para unificar sistemas de identidad en la nube dispares y permitir políticas consistentes. Dado que cada proveedor de la nube tiene su propia herramienta y formato de política, Hexa se basa en IDQL, un formato de política común para definir políticas de acceso a la identidad, dice Strata.

Cada proveedor de la nube se basa en sistemas de identidad patentados y sus propios lenguajes de políticas para crear y administrar la identidad y el acceso en su plataforma. La mayoría de los ingenieros de seguridad tienden a estar bien versados ​​en una, quizás dos, de las nubes públicas, pero rara vez más que eso. Sin embargo, en la era de las nubes múltiples, los ingenieros de seguridad deben poder crear, leer y administrar políticas en múltiples entornos y mantenerse al día con las herramientas cambiantes y las nuevas capacidades. IDQL es el lenguaje de políticas declarativo common que puede traducir las políticas al formato propietario del proveedor specific, dice Gerry Gebel, jefe de estándares de Strata Identification. Hexa es el program de referencia creado sobre el lenguaje de políticas IDQL y maneja las tareas de descubrimiento, traducción y orquestación de políticas en entornos de nube, dice.

“Hexa es el application de referencia de código abierto que da vida a IDQL y lo hace operativo en el mundo real”, dice Gebel.

Caso para la gestión de identidades en la nube

En una reciente Informe Darkish Looking through sobre el estado de la computación en la nube, solo el 19 % de los encuestados dijo que sus organizaciones trabajan con un solo proveedor de nube, mientras que el 43 % dijo que trabajaba con dos o tres proveedores. Hay muchas razones por las que las organizaciones pueden estar haciendo malabarismos con múltiples proveedores de nube. Las organizaciones pueden requerir multinube para redundancia y resiliencia, como un proveedor que experimenta una interrupción, o para cumplir con los requisitos normativos sobre dónde se pueden almacenar los datos. En algunas organizaciones, es posible que la infraestructura de la nube se haya configurado originalmente sin el conocimiento de TI, por lo que es posible que el proveedor y las políticas no estén sincronizados con los demás.

Independientemente de las razones que llevaron a la multinube, la identidad y el acceso deben ser consistentes y administrados. en un informe de Redes de Palo Alto, Unidad 42 Los investigadores analizaron más de 680 000 identidades en 18 000 cuentas en la nube y más de 200 organizaciones diferentes, y encontraron que al 99 % de los usuarios, roles, servicios y recursos de la nube se les otorgaron permisos excesivos. Los permisos no solo fueron excesivos, sino que también se dejaron sin usar durante 60 días, según el informe.

Las identidades mal configuradas están detrás del 65% de los incidentes de seguridad en la nube detectados, dijo Unit42. Los actores de amenazas pueden abusar de estas identidades y moverse lateralmente a través del entorno de la nube o expandir el grupo de sistemas a los que pueden apuntar.

Investigación propia de Strata Identity descubrió que solo el 25 % de los encuestados dijeron que tenían visibilidad de las políticas de acceso a múltiples nubes.

Un lenguaje de política common

Cada proveedor de la nube tiene su propio sistema de identidad y cada aplicación debe estar codificada para funcionar con ese sistema de identidad. Si la aplicación va a funcionar en múltiples plataformas en la nube, tradicionalmente la aplicación tendría que modificarse para cada una. Hexa, sin embargo, ha sido diseñado para usar IDQL para traer múltiples sistemas de identidad para trabajar juntos como un todo unificado y no tener que hacer cambios en las aplicaciones, según Strata Id. Para el descubrimiento de políticas, Hexa abstrae las políticas de identidad y acceso de las plataformas en la nube, los sistemas de autorización, los recursos de datos y las redes de confianza cero.

Strata Identity configuró una aplicación bancaria multirregional de ejemplo para demostrar Hexa y sus capacidades de administración de descubrimiento de políticas, dice Gebel. La región de EE. UU. en este escenario implementa la aplicación en Google Cloud System mediante App Engine, mientras que otras dos regiones confían en Kubernetes. Hexa se conecta a la instancia de Google Cloud para descubrir los recursos y las políticas asociadas, y luego convierte las políticas en IDQL. El analista puede realizar cambios en las políticas y luego usar Hexa para traducir las nuevas políticas nuevamente al formato GCP e impulsar los cambios en la plataforma, explica.

Hexa maneja el descubrimiento de políticas mediante el análisis del entorno para descubrir las aplicaciones y los recursos que se utilizan y la creación de un inventario de todas las políticas, usuarios y roles existentes. Los equipos de seguridad tienen una vista integral de todas las políticas vigentes una vez que se han recuperado y traducido a IDQL. Las organizaciones pueden potencialmente desarrollar herramientas para analizar el ISQL en busca de brechas de políticas, duplicados u otras condiciones de mistake. Esta capacidad no está en el Hexa de código abierto, dice Gebel, pero es algo que las organizaciones pueden hacer por su cuenta después de convertirse a IDQL.

Si bien puede parecer que IDQL agrega una capa de complejidad a la gestión del acceso a la identidad en la nube, la realidad es que las organizaciones tienen que administrar de cientos a miles de aplicaciones en la nube, SaaS y locales, dice Jack Poller, analista de ESG que cubre identidad y datos. seguridad. Cada aplicación tiene un concepto separado de identidad y autorización de acceso, y las organizaciones actualmente se ven obligadas a traducir manualmente las políticas de acceso comercial de alto nivel al lenguaje de políticas o herramienta de administración de cada aplicación.

«IDQL proporciona una lingua franca para las políticas de autorización», dice Poller. «Las organizaciones pueden usar Hexa o desarrollar sus propias herramientas para orquestar y automatizar las políticas de acceso en todo el entorno de TI, cerrando las brechas que ocurren con la administración manual de políticas y asegurando la aplicación continua y consistente de las políticas de autorización».

Tecnologías multiplataforma

IDQL y Hexa fueron creados por algunos de los coautores de Security Assertion Markup Language (SAML), el estándar multiplataforma para el inicio de sesión único que permite a los usuarios moverse entre plataformas en la nube y aplicaciones internet sin volver a ingresar sus credenciales. Sin embargo, Gebel señala que IDQL no debe verse como un reemplazo de los estándares modernos como el Agente de política abierta (OPA), pero «son complementarios a ellos».

OPA es un lenguaje de política declarativo unificado que permite a los desarrolladores nativos de la nube «desacoplar la política del código del servicio para que pueda publicar, analizar y revisar las políticas (que adoran los equipos de seguridad y cumplimiento) sin sacrificar la disponibilidad o el rendimiento», dice Poller, señalando que IDQL es muy equivalent a OPA.

«Al igual que Kubernetes transformó la informática al permitir que las aplicaciones se movieran de forma transparente de una máquina a otra, IDQL permite que las políticas de acceso se muevan libremente entre los sistemas de identidad patentados», dijo Eric Olden, director ejecutivo de Strata Id y uno de los coautores del estándar SAML. , dijo en un comunicado. «IDQL y Hexa eliminan los silos de identidad en la nube y en las instalaciones mediante la creación de un sistema de identidad inteligente y distribuido con un solo cerebro».



Enlace a la noticia initial