A veces las cosas pueden ser tan fundamentales que resulta difícil verlas con claridad, o incluso invisibles. Imagine un entorno de oficina típico, por ejemplo: ¿qué ve? Probablemente haya sillas, escritorios, teléfonos y archivadores. Estas cosas son tan fundamentales para lo que es una oficina que normalmente no nos detenemos a pensar en el hecho de que están ahí.
La gestión de identidad y acceso (IAM), la disciplina de garantizar que las personas adecuadas tengan acceso a las cosas adecuadas en el momento adecuado, a veces cae en este grupo invisible. IAM es tan fundamental para la seguridad empresarial (y tan importante para la forma en que se protegen los recursos) que no nos detenemos a pensar en ello. Como muchas tecnologías que han alcanzado un alto nivel de madurez, se convierte en plomería estándar y realiza sus funciones necesarias y críticas sin que nadie se dé cuenta, a menos que haya un problema importante.
A pesar de lo plácidas que puedan parecer las aguas de IAM en la superficie, se están produciendo cambios de marea fundamentales debajo. Consideremos, por ejemplo, cómo la nube ha impactado la identidad. En los últimos años han surgido muchas estrategias de IAM basadas en la nube, desde la identidad como servicio (IDaaS) hasta la autenticación como servicio, así como sistemas de identidad ofrecidos dentro de entornos de nube. Además, piense en cómo las arquitecturas orientadas a servicios han afectado a IAM, incluida la creación y rápida adopción de un nuevo mecanismo de transferencia de estado de autenticación, Open Authorization (OAuth).
Han ocurrido (y continúan sucediendo) tantos cambios interesantes en el espacio IAM que corresponde a las organizaciones prestar atención. Del mismo modo, tecnologías como la nube afectan los sistemas IAM: pueden cambiar cómo se usan los mecanismos IAM, para qué se usan, cuándo se usan y qué capacidades técnicas se necesitan para lograr los objetivos empresariales.
A pesar de lo plácidas que puedan parecer las aguas de IAM en la superficie, se están produciendo cambios de marea fundamentales debajo.
Dicho esto, hay muchos puntos de vista arquitectónicos de IAM que se deben considerar, incluidos los diferentes enfoques, principios de diseño y qué considerar al evaluar la mejor opción para las necesidades comerciales específicas de su organización.
La arquitectura IAM en evolución
Desde un punto de vista arquitectónico, el diseño de la mayoría de las implementaciones de IAM es relativamente sencillo a primera vista. Las complejidades sólo surgen cuando las implicaciones se consideran y se extienden a casos de uso particulares.
Considere el patrón de diseño del proyecto Open Security Architecture (OSA) para la gestión de identidades, SP-010. OSA representa un repositorio abierto y colaborativo para patrones de diseño arquitectónico de seguridad, es decir, estrategias que encapsulan sistemas en formato pictórico para uso de la comunidad.
Figura 1. SP-010: Patrón de gestión de identidades de OSA, con licencia CC BY-SA.
Esta es la parte del diagrama del patrón de diseño OSA IAM. Los elementos textuales, que explican con más detalle la visión conceptual, la descripción y otras notas destacadas, se han omitido por motivos de brevedad y porque la mayoría de estos detalles están implícitos en el diagrama.
Algunas suposiciones están implícitas en el diagrama. En primer lugar, aborda múltiples roles que interactúan con los componentes de IAM, así como con los sistemas que dependen de ellos. En segundo lugar, separa la aplicación de políticas (en este diagrama, aplicadas a nivel de servidor) de las decisiones de políticas, que se manejan mediante la combinación del directorio y el servidor de autenticación. Por último, se basa en el supuesto de que la organización posee y gestiona la identidad del usuario.
Este es un patrón de diseño tradicional y es importante señalar que algunos de sus supuestos subyacentes están cambiando en el siglo XXI. Está la cuestión de la federación de proveedores de servicios externos, cuya instalación y mantenimiento pueden requerir una infraestructura separada. Luego, está la cuestión de extender la identidad a la nube, que, según el modelo empleado, puede utilizar la transferencia de estado (por ejemplo, Security Assertion Markup Language (SAML) u OAuth) para federar entre el entorno local y la nube. o puede utilizar proveedores de identidad nativos de la nube directamente.
También está la cuestión de quién se autentica y con qué propósito. El diagrama OSA, si bien es apropiado para los empleados internos, está claramente dirigido a los empleados. Hoy en día, las organizaciones deben mantener múltiples identidades más allá de sus empleados, por ejemplo, clientes, usuarios de aplicaciones, usuarios administrativos del sistema y otros tipos de usuarios que no están integrados en el modelo de interconexión de sistemas abiertos. Una organización que emplee un modelo como este para la autenticación de usuarios internos y el control de acceso también podría tener una aplicación de producción que contenga cuentas de usuarios de clientes. Esto podría ser tan sofisticado como una plataforma IAM de cliente (CIAM) o, según el uso, podría ser tan simple como una tabla de base de datos que contenga credenciales de usuario específicas de la aplicación.
Si bien es una descripción de cómo ha funcionado IAM históricamente, es probable que el diagrama OSA no sea particularmente descriptivo de cómo la mayoría de las organizaciones utilizan IAM en la actualidad. Esto es cierto tanto por los cambios en la forma en que se utiliza IAM para los empleados como porque no aborda las identidades de los clientes.
Diferencias en los enfoques IAM
Si los métodos de IAM están cambiando y los enfoques heredados se encuentran en un estado de transición, ¿cómo deberían las empresas seleccionar el mejor enfoque para sus necesidades? Hay algunas cosas a considerar:
¿Qué busca hacer la organización? ¿Cuál es el alcance? ¿Dónde está la fuente?
Es importante recordar que IAM es una disciplina enorme. Incluye varias subdisciplinas, como autenticación, gestión de identidades privilegiadas, autorización y control de acceso, federación, control de acceso basado en roles (RBAC) y transferencia de estado, que son necesarias para una operación exitosa.
También hay varios tipos diferentes de usuarios, desde clientes y cuentas privilegiadas hasta cuentas de servicio, empleados internos, socios comerciales y más.
Al seleccionar una arquitectura IAM, las organizaciones también deben considerar los puntos de intersección con los entornos (y, en particular, las fuentes de identidad y los proveedores de identidad) que ellas mismas no controlan directamente.
Cuando se considera todo esto, las empresas podrían terminar con un diseño diferente al modelo OSA presentado anteriormente. Por ejemplo, tomemos dos modelos completamente diferentes: una aplicación CIAM versus una interna centrada en los empleados, como la descrita anteriormente. En una aplicación CIAM, podría haber un componente de interfaz de usuario que resida en un proveedor de IaaS o esté implementado en una PaaS, así como API RESTful que implementen la lógica empresarial. En ese contexto, se pueden emplear un servidor y directorio de autenticación tradicional, como se ilustra en la Figura 1, o se pueden usar herramientas en la nube, como un proveedor IDaaS externo, como se ilustra en la Figura 2.
Figura 2. Aplicación CIAM de ejemplo que utiliza herramientas en la nube
Este enfoque, si bien utiliza los mismos elementos lógicos (directorio, puntos de aplicación de políticas, puntos de decisión de políticas) que el modelo local heredado, los emplea para un propósito diferente.
Tres pasos clave para seleccionar una arquitectura IAM
En última instancia, para obtener la mejor arquitectura IAM para sus casos de uso específicos, una organización necesitará hacer un poco de trabajo preliminar. Tendrá que ser claro acerca de lo que espera lograr; a quién autenticará y por qué; qué aplicaciones emplean sus usuarios; y dónde se encuentran los usuarios. Mientras se responden estas preguntas, preste especial atención a dos elementos:
Aplicaciones SaaS alojadas fuera del entorno empresarial; y uso que presupone identidades que no pertenecen a la organización.
El proceso se puede dividir en tres pasos.
Paso 1
Los equipos de seguridad deben hacer una lista de usos (aplicaciones, servicios, componentes y otros elementos) con los que anticipan que los usuarios interactuarán. Consolidar esto en una lista ayuda a validar con otros miembros de la organización que las suposiciones de uso son correctas. También se puede utilizar como aportación al proceso de selección de productos cuando llega el momento de evaluar si los mecanismos IAM proporcionan las capacidades necesarias.
Paso 2
Piense en cómo se vincularán entre sí los diferentes entornos, como las aplicaciones SaaS en la nube y las aplicaciones locales, como el inicio de sesión de dominio. En ocasiones, es posible que se necesiten diferentes sistemas para adaptarse a diferentes tipos de aplicaciones y usos. Es útil comprender qué otros sistemas existen fuera de los límites de la empresa porque es posible que estos sistemas necesiten federarse de maneras específicas. Por ejemplo, el proveedor de nube A podría habilitar la federación a través de SAML, mientras que el proveedor B lo hace a través de OpenID Connect.
Paso 3
Considere detenidamente qué áreas específicas de IAM son más importantes para el negocio. La siguiente lista de preguntas ayudará a las empresas a evaluar proveedores y sistemas potenciales:
¿Se necesita MFA? ¿Es necesario que los clientes y los empleados estén respaldados en el mismo sistema? ¿Se requiere aprovisionamiento y desaprovisionamiento automatizado? ¿Qué estándares deben apoyarse?