Administración de identidades y acceso para cargas de trabajo de SaaS en Azure
La identidad de la aplicación es un área crítica para las cargas de trabajo de SaaS, ya que sirve como primera línea de defensa para proteger los datos. A menudo se pasa por alto hasta finales de un proyecto, pero muchas decisiones sobre otros elementos de la aplicación dependen de una estrategia de identidad sólida. No subestime la importancia de la identidad para ayudar a proteger los datos de los clientes.
En el contexto de las cargas de trabajo de SaaS, hay dos tipos distintos de identidad.
La identidad de la aplicación, también conocida como administración de identidades y acceso de clientes (CIAM), permite a los usuarios finales autenticarse y usar la aplicación SaaS. Hay dos métodos principales para iniciar sesión de los usuarios en un proveedor de identidades de aplicación:
Identidades federadas. Los usuarios inician sesión con credenciales existentes que mantiene otro proveedor de identidades. Ese proveedor podría ser un proveedor de identidades sociales, como Google, Facebook o LinkedIn, o un proveedor de identidades de empresa que usen los clientes, como Microsoft Entra o Okta. El mantenimiento de la cuenta del usuario es responsabilidad del proveedor de identidades federado.
Identidades locales. Los usuarios crean una cuenta solo para la aplicación. La cuenta está protegida por el nombre de usuario y la contraseña, la clave de acceso u otros métodos de autenticación. El mantenimiento de la cuenta del usuario es su responsabilidad.
La identidad empresarial es la solución de identidad que se usa para autenticar usuarios internos y cargas de trabajo en herramientas de productividad empresarial, herramientas internas o servicios y servicios de Azure. Use una solución de identidad empresarial para los usuarios internos y las cargas de trabajo para autenticarlos en herramientas de productividad empresarial, herramientas internas o servicios y servicios de Azure.
Las identidades de aplicación y empresa sirven para distintos propósitos y pueden usar diferentes proveedores de identidades. Este artículo se centra en las consideraciones de diseño para la identidad de la aplicación, aunque es probable que ambos tipos estén presentes en el entorno de carga de trabajo de SaaS.
La administración de identidades implica dos problemas relacionados: autenticación (comprobación de la identidad de un usuario) y autorización (concesión de permisos basados en la identidad). Las tres primeras secciones de este artículo se centran en la autenticación para SaaS. La sección final aborda las consideraciones de autorización para los proveedores de SaaS.
Identidad en una aplicación multiinquilino
Mantener los datos de inquilino independientes en una aplicación multiinquilino es fundamental. Esa segmentación está controlada por su elección de autenticación y autorización de usuario eficaces. Además, la elección del modelo de arrendamiento influye significativamente en sus decisiones sobre el proveedor de identidades. Priorice la identidad como perímetro principal.
Consideraciones de diseño
Comprenda los modelos de inquilino e implementación de la aplicación. Puede haber matices que influyen en la estrategia de identidad. Por ejemplo, es un error erróneo que el patrón de stamps de implementación requiere un proveedor de identidades en cada sello. Para la mayoría de los proveedores de identidades, a menudo puede usar un modelo de aislamiento alternativo.
Al elegir el proveedor de identidades para multiinquilino, evalúe el impacto de los errores. Las configuraciones incorrectas pueden reducir toda la aplicación para todos los inquilinos. Pesa los costos de sobrecarga contra el riesgo del posible radio de impacto.
Si implementa la solución en el entorno de Azure de un cliente y la administra en su nombre, es posible que tenga que integrarse con su proveedor de identidades empresariales. Tenga una comprensión clara de estos aspectos:
- Los tipos de usuarios y sus necesidades de acceso cuando interactúan con los inquilinos de la aplicación. Por ejemplo, es posible que el usuario A solo necesite acceso para iniciar sesión en el inquilino 1, pero el usuario B podría necesitar acceso para iniciar sesión en el inquilino 1 y en el inquilino 2.
- Cumplimiento de las regulaciones de residencia de datos, si son aplicables a su proveedor de identidades. En algunos casos, los datos almacenados por un proveedor de identidades pueden estar sujetos a regulaciones. Muchos proveedores de identidades proporcionan instrucciones y funcionalidades específicas para este escenario. Evalúe si este escenario es relevante para usted y realice los pasos necesarios para garantizar el cumplimiento.
Recomendaciones de diseño
| Recomendación | Prestación |
|---|---|
| Siga los procedimientos recomendados y directrices del proveedor de identidades para crear particiones de la solución para varios inquilinos. | El aislamiento de inquilinos le ayuda a lograr sus objetivos de seguridad y cumplimiento. |
| Evite tener varias cuentas para el mismo usuario. Un usuario debe tener una sola cuenta con un conjunto de credenciales, incluso si necesitan acceso a varios inquilinos. Conceda acceso a cada inquilino según sea necesario en lugar de crear varias cuentas para el mismo usuario. | La creación de varias cuentas para el mismo usuario aumenta los riesgos de seguridad y puede confundir a los usuarios que necesitan recordar varios nombres de usuario y contraseñas para el mismo software. |
| Cuando considere la residencia de datos, planee cómo almacenar datos de usuario en ubicaciones independientes. Si implementa una marca de implementación independiente para los usuarios de otras zonas geográficas, es posible que también necesite proveedores de identidades independientes. Asegúrese de que tiene una manera de identificar dónde se almacenan los datos de los usuarios para que pueda dirigirlos a la región correcta para el inicio de sesión, si es necesario. |
Podrá admitir los requisitos de cumplimiento y mejorar la experiencia del usuario mediante el enrutamiento de los usuarios a la experiencia de inicio de sesión adecuada para su ubicación. |
Selección del proveedor de identidades
Cada proveedor de identidades ofrece características únicas, limitaciones, modelos de precios e patrones de implementación. Microsoft Entra y Okta son opciones populares de identidad como servicio (IDaaS). También hay otros proveedores de código abierto, como Keycloak y Authentik.
Consideraciones de diseño
Documente los requisitos de identidad. Empiece por enumerar las características que necesita la aplicación ahora y las necesitará en el futuro. Entre las características típicas que se deben tener en cuenta se incluyen:
-
- Compatibilidad con el proveedor de identidades federado para integrarse con las soluciones de identidad de los clientes. Esta característica le permite evitar la creación de nuevas identidades.
- Flujo de inicio de sesión o registro personalizable para modificar la apariencia y el aspecto para mantener la personalización de marca. Esta característica también proporciona la capacidad de insertar lógica de negocios personalizada en el proceso de inicio de sesión o registro.
- Separación de datos de inquilino en silos distintos para mantener el aislamiento del inquilino.
- Audite la compatibilidad para conservar o exportar registros de inicio de sesión para la administración de seguridad.
Importante
Tenga en cuenta el crecimiento planeado del usuario al evaluar el costo de una solución de identidad. Es posible que una solución no siga siendo rentable o escalable a largo plazo, pero podría ser útil por ahora. Tenga un plan de migración que pueda usar si surge la necesidad.
Por ejemplo, una solución podría ser asequible para 500 usuarios, pero no sostenible para 5 millones. Si requiere una configuración mínima y es fácil de migrar, podría seguir siendo la opción adecuada hasta que el escalado justifica el cambio a una solución diferente.
Investigue exhaustivamente las funcionalidades del proveedor de identidades. Asegúrese de que la solución de identidad coincide con la lista de características necesarias. Incluso si actualmente no necesita escenarios complejos como la identidad federada, considere las necesidades futuras. En el caso de las soluciones SaaS de negocio a negocio (B2B), probablemente será necesaria la identidad federada.
Factorizar la sobrecarga de administración. Los distintos proveedores de identidades requieren distintos niveles de sobrecarga de administración. Las soluciones de IDaaS conocidas suelen tener menos sobrecarga porque controlan el hospedaje, el mantenimiento y la seguridad. Sin embargo, la sobrecarga adicional de una solución de código abierto puede merecer la pena si la solución es una mejor opción para sus necesidades especializadas.
Recomendaciones de diseño
| Recomendación | Prestación |
|---|---|
| No cree su propia solución de identidad. La identidad es un área altamente especializada y la creación de una solución de identidad es compleja y costosa. Es difícil crear una solución de identidad segura y confiable. | Evitará el antipatrón de crear su propio proveedor y mejorará la seguridad, confiabilidad y eficacia operativa de la solución. |
| Cree una matriz de funcionalidades de las características que ofrecen los proveedores de identidades y asígnela a sus requisitos de identidad. | Se asegurará de que la capacidad de evolucionar sin estar restringida por un conjunto limitado de características de identidad. |
| Prefiere las opciones de IDaaS sobre las soluciones de código abierto. Hospedar una solución código abierto usted mismo incurre en importantes riesgos de seguridad y sobrecarga operativa. Sin embargo, puede elegir esa opción para cumplir los requisitos específicos de cumplimiento, residencia de datos o confiabilidad que un proveedor no puede cumplir. Para más información, consulte Proveedores de identidades de IDaaS. |
Mediante el uso de un proveedor de identidades de IDaaS, evitará la complejidad innecesaria y podrá centrar sus esfuerzos en su negocio principal. |
Identidad federada
La identidad federada, también conocida como inicio de sesión único (SSO), permite a los usuarios iniciar sesión con credenciales que ya usan en otro lugar. Para habilitar la identidad federada, establezca una relación de confianza entre el proveedor de identidades de la aplicación y el proveedor de identidades existente del cliente. La identidad federada es un requisito común para las soluciones SaaS, especialmente en B2B, ya que los clientes prefieren que sus empleados usen credenciales corporativas. Ofrece varias ventajas para las soluciones B2B, como la administración centralizada de identidades y la administración automática del ciclo de vida. En los productos SaaS de B2C, la integración con proveedores de identidades sociales es habitual permitir a los usuarios iniciar sesión con credenciales existentes.
Compensación: complejidad y eficiencia operativa. Al trabajar con proveedores de identidades federados, descarga la complejidad de administrar las identidades de los usuarios. Sin embargo, se toma el costo de la integración con otro proveedor de identidades. Decida dónde desea centrar sus esfuerzos operativos.
Aunque la implementación de la identidad federada es inicialmente sencilla, se vuelve más compleja a medida que aumenta el número de proveedores de identidades admitidos. El planeamiento cuidadoso es esencial, especialmente si cada cliente usa un proveedor de identidades único. Incluso si usan el mismo proveedor de identidades, las relaciones de confianza únicas suelen ser necesarias para cada cliente debido a detalles de configuración específicos.
En esta imagen se muestra la relación entre la aplicación, el proveedor de identidades de la aplicación y los proveedores de identidades de nivel inferior que puede implementar mediante la federación de identidades.
Consideraciones de diseño
Calcule los tipos y el número de proveedores de identidades que necesita admitir. Es posible que necesite un número estático de proveedores de identidades sociales o que necesite proveedores de identidades federados únicos para cada cliente. Debe saber si los clientes usarán OpenID Connect (OIDC), lenguaje de marcado de aserción de seguridad (SAML) o ambos para la integración.
Asigne la experiencia de inicio de sesión. Visualice el flujo de usuario del proceso de registro e inicio de sesión. Tenga en cuenta los requisitos especiales que puedan modificar el diseño del flujo de usuario. Por ejemplo:
Personalización de marca. Etiquetado en blanco o dominios de inicio de sesión personalizados por cliente.
Información personalizada. Recopilar información adicional del usuario durante el registro o el inicio de sesión, como la selección de inquilinos para los usuarios con acceso a varios inquilinos.
Selección del proveedor de identidades. Si usa un único proveedor de identidades de aplicación que tiene muchos proveedores de identidades federados en los que confía, decida cómo seleccionar un proveedor. Esta selección puede realizarse manualmente a través de un botón o automáticamente en función de la información de usuario conocida. A medida que aumenta el número de proveedores, la selección automática se vuelve más práctica. Esta funcionalidad se conoce como Detección de dominios de inicio.
Recomendaciones de diseño
| Recomendación | Prestación |
|---|---|
| Elija un proveedor de identidades que pueda escalar para adaptarse al número de proveedores de identidades federados que necesita. Tenga en cuenta los límites estrictos del proveedor, que no se pueden superar. |
Se asegurará de que la solución de identidad pueda escalar a medida que crezca. |
| Planee la incorporación de cada proveedor de identidades federado y automatice el proceso tanto como sea posible. Este esfuerzo colaborativo entre su organización y sus clientes implica intercambiar información para establecer una relación de confianza, normalmente a través de protocolos OIDC o SAML. |
La integración de identidades puede tardar tiempo y esfuerzo tanto para usted como para sus clientes. Al planear el proceso, mejorará la eficiencia operativa. |
| Refleje la complejidad y el costo de la identidad federada en los precios y el modelo de negocio. Permitir que los clientes usen su propio proveedor de identidades aumenta la complejidad operativa y los costos debido a la sobrecarga de mantener varias relaciones de confianza de identidad federada. Es habitual que las empresas paguen por un nivel superior que permita el inicio de sesión federado. |
La federación con el proveedor de identidades de un cliente puede ser un costo oculto en las soluciones saaS. Al planearlo, evitará costos inesperados durante la implementación. |
| Planee cómo se seleccionará el proveedor de identidades de un usuario durante el flujo de inicio de sesión. Considere la posibilidad de usar la detección de dominios principales. Microsoft Entra ID proporciona detección integrada del dominio de inicio. |
Simplificará la experiencia del cliente y garantizará que los usuarios se dirijan al proceso de inicio de sesión correcto. |
Authorization
La autorización de usuario es fundamental para las aplicaciones SaaS, que a menudo almacenan datos para varios inquilinos. Defina claramente cómo se autorizarán a los usuarios para acceder solo a sus datos sin acceder involuntariamente a los datos de otros inquilinos. Además, proporcione una autorización granular dentro de un inquilino, lo que permite a los usuarios leer o acceder a cierta información al restringir las actualizaciones o el acceso a otros datos.
Consideraciones de diseño
Elija el modelo de autorización adecuado para el caso de uso. Hay dos tipos principales:
- Autorización basada en roles. A los usuarios se les asignan roles o grupos, y las características específicas están restringidas a determinados roles. Por ejemplo, los administradores pueden realizar cualquier acción, pero los usuarios de otros roles tienen permisos limitados.
- Autorización basada en recursos. Cada recurso tiene su propio conjunto de permisos. Un usuario puede ser administrador de un recurso, pero no tiene acceso a otro.
Decida dónde almacenar los datos de autorización. Los datos de autorización de la aplicación se pueden almacenar en:
- El proveedor de identidades. Aproveche las ventajas de los roles o grupos integrados, que exponen permisos como notificaciones en el token emitido a la aplicación. A continuación, la aplicación puede aplicar reglas de autorización mediante estas notificaciones de token.
- Su aplicación. Desarrolle su propia lógica de autorización y almacene los permisos de usuario en una base de datos o en un sistema similar, lo que permite controles de autorización específicos basados en roles o de nivel de recurso.
Compensación: complejidad, flexibilidad y seguridad. El almacenamiento de datos de autorización en un proveedor de identidades y la exposición a través de notificaciones de token suele ser más sencillo que administrar su propio sistema de autorización. Sin embargo, la autorización basada en notificaciones limita la flexibilidad y debe aceptar que las notificaciones solo se actualizan cuando se vuelve a emitir un token, lo que puede provocar un retraso en la aplicación de permisos modificados.Evaluar el impacto de la administración delegada. En la mayoría de las aplicaciones SaaS, especialmente en las aplicaciones B2B, la administración de roles y permisos se delega a los clientes. Sin esta funcionalidad, puede aumentar la sobrecarga de administración si los clientes cambian con frecuencia los permisos de sus usuarios.
Evaluar el acceso multiinquilino. En algunos sistemas, es posible que un único usuario necesite acceder a los datos de varios inquilinos. Por ejemplo, es posible que los consultores necesiten acceder a los datos de varios inquilinos. Planee cómo los clientes concederán acceso a estos usuarios y cómo el flujo de inicio de sesión admitirá la selección y el cambio entre inquilinos.
Recomendaciones de diseño
| Recomendación | Prestación |
|---|---|
| Impedir que los usuarios accedan a datos a través de los límites del inquilino a menos que se permita explícitamente ese acceso. | El acceso no autorizado a los datos de otro inquilino, incluso el acceso accidental, se puede ver como un incidente de seguridad importante y dañar la confianza del cliente en su plataforma. Bloquear el acceso innecesario le ayudará a evitar estas situaciones. |
| Si los datos son estáticos y cambian con poca frecuencia, almacénelo en el proveedor de identidades. Si se necesitan cambios frecuentes mientras el usuario usa el software, almacene los datos de autorización en la aplicación. | La selección del mejor almacén de datos para los datos de autorización mejorará la eficacia operativa y le ayudará a satisfacer sus necesidades de escalabilidad. |
| Si delega la administración de permisos a los clientes, proporcione un método claro para que administren los permisos. Por ejemplo, cree un portal web al que solo puedan acceder los administradores de inquilinos para cambiar los permisos de usuario. | Proporcionará más control a los clientes y evitará una carga operativa innecesaria en el equipo de soporte técnico. |
Recursos adicionales
Multiinquilino es una metodología empresarial básica para diseñar cargas de trabajo de SaaS. En estos artículos se proporciona más información sobre la administración de identidades y acceso:
- Consideraciones de arquitectura para la identidad en soluciones multiinquilino
- Enfoques arquitectónicos para la identidad en soluciones multiinquilino
Paso siguiente
Obtenga información sobre cómo elegir el modelo de hospedaje de proceso, los aspectos operativos y cómo optimizar las opciones de tecnología para ayudarle a cumplir los acuerdos y objetivos de nivel de servicio.