Modificación de una arquitectura de zona de aterrizaje de Azure para cumplir los requisitos en varias ubicaciones
Las organizaciones de muchos sectores están sujetas a requisitos normativos, incluidos los requisitos de residencia de datos, seguridad de datos y soberanía de datos. Algunas organizaciones deben cumplir normativas en conflicto en varias ubicaciones geográficas. En este caso, deben modificar su arquitectura de zona de aterrizaje de Azure de acuerdo con todas las normativas aplicables.
Por ejemplo, podría haber dos normativas conflictivas, la normativa A y la normativa B. La normativa A podría requerir residencia de datos en el país o la región A, y la normativa B podría requerir residencia de datos en el país o región B.
Estos conflictos normativos se pueden aplicar a:
Organizaciones multinacionales, como corporaciones multinacionales u organizaciones no gubernamentales (ONG), que deben cumplir las normativas locales en los países o regiones en los que operan.
Los proveedores de software independientes (ISV) que proporcionan soluciones a las organizaciones en varias ubicaciones, y la solución deben cumplir las normativas locales en cada ubicación.
ISV que proporcionan soluciones a organizaciones multinacionales que necesitan cumplir las normativas locales de cada país o región en los que operan.
Si solo necesita cumplir un único conjunto de requisitos normativos, consulte Adaptar la arquitectura de zona de aterrizaje de Azure para cumplir los requisitos.
Consideraciones normativas
Los requisitos normativos suelen estar relacionados con la protección de datos, la residencia de datos, las transferencias de datos, el aislamiento o la autorización del personal. Estos requisitos pueden entrar en conflicto entre varias ubicaciones geográficas. Por ejemplo, una normativa de la Unión Europea (UE) podría requerir residencia de datos en un país de la UE, mientras que una normativa del Reino Unido podría requerir residencia de datos en el Reino Unido.
Si las normativas causan controles de directiva en conflicto, debe ajustar la arquitectura de la zona de aterrizaje de Azure y las asignaciones de directivas en consecuencia. Para obtener más información, consulte la sección de este artículo: Escenarios que requieren modificación.
Cuando se aplican varias normativas, no es necesario modificar la arquitectura de la zona de aterrizaje de Azure si:
Varias normativas requieren asignaciones idénticas de Azure Policy.
Los controles de una normativa son un superconjunto de otra normativa. Los controles del superconjunto se aplican automáticamente a ambas normativas.
Los controles de varias normativas no se superponen. Al implementar varios conjuntos de controles, una sola implementación cubre todas las normativas. Las asignaciones de Azure Policy son complementarias.
Varias normativas tienen diferentes tipos de implementación. Desde una perspectiva normativa, no importa qué implementación elija. Por ejemplo, puede haber dos normativas que tengan un modelo de autorización diferente, pero ambos modelos de autorización son aceptables. Puede elegir la implementación que mejor se adapte a su organización.
Sugerencia
Debe intentar tener el menor número posible de asignaciones de directivas y excepciones o exenciones.
Consideraciones sobre ISV
Hay tres modelos de implementación para ISV.
Software como servicio puro (SaaS): el ISV proporciona la solución como servicio.
Implementado por el cliente: el cliente implementa la solución en su propio entorno.
SaaS de implementación dual: este modelo combina el modelo implementado por el cliente y el modelo SaaS puro.
En un modelo SaaS puro, el ISV es responsable de administrar el cumplimiento en nombre del cliente. El ISV debe demostrar el cumplimiento al cliente y potencialmente a los auditores o reguladores. Si usa el modelo SaaS, la arquitectura podría estar sujeta a varias normativas que pueden entrar en conflicto. El ISV debe administrar el cumplimiento de estas diversas normativas. Para obtener más información, consulte la sección de este artículo: Escenarios que requieren modificación.
En un modelo implementado por el cliente, el cliente es responsable de administrar el cumplimiento. Para este modelo, el ISV no necesita modificar las zonas de aterrizaje. Sin embargo, la solución se implementa en una zona de aterrizaje que el cliente implementa, incluidos los controles de directiva y las directivas personalizadas.
Sugerencia
Los ISV pueden tener como objetivo a iniciativas de directiva en determinados requisitos de cumplimiento para probar una solución. Esta práctica puede ayudar a minimizar la posibilidad de conflictos con las directivas que usan los clientes para cumplir sus requisitos de cumplimiento.
En un modelo SaaS de implementación dual, se aplican todas las consideraciones para el modelo SaaS puro y el implementado por el cliente.
Consideraciones para organizaciones multinacionales
Las organizaciones multinacionales usan varias estructuras para organizar su gobernanza de TI.
Estructura descentralizada: las funciones de TI se rigen localmente en cada ubicación geográfica.
Estructura centralizada: las funciones de TI se rigen desde un lugar centralizado, normalmente la sede central de la organización.
Estructura híbrida: las funciones de TI globales se proporcionan de forma centralizada, mientras que las funciones de TI necesarias solo localmente se rigen en cada ubicación geográfica.
En un escenario descentralizado, el equipo de TI local es responsable de administrar el cumplimiento y puede adaptar su zona de aterrizaje en consecuencia.
En un escenario centralizado, el equipo de TI central es responsable de administrar el cumplimiento y debe asegurarse de que las soluciones cumplan los requisitos de cumplimiento local de todas las ubicaciones geográficas donde opera la organización multinacional. Los requisitos de cumplimiento de varias ubicaciones geográficas pueden entrar en conflicto y puede ser necesario modificar las zonas de aterrizaje.
En un escenario híbrido, se aplican las consideraciones para los escenarios descentralizados y centralizados. La organización centralizada proporciona soluciones que las organizaciones locales necesitan implementar en su entorno. La organización centralizada también prueba que esas soluciones se implementan en todas las zonas de aterrizaje de las organizaciones locales.
Escenarios que requieren modificación
Es posible que tenga que modificar las zonas de aterrizaje si hay conjuntos de directivas en conflicto asignados a varias implementaciones. Puede haber varias soluciones o una única solución que deba estar disponible para varias ubicaciones geográficas o clasificaciones de datos.
La cantidad de modificaciones necesarias depende del nivel de aislamiento que requiere la normativa. Cuantas más condiciones tenga una normativa, más será necesario modificar la zona de aterrizaje. Por ejemplo, si las normativas requieren condiciones como personal con autorización, varios proveedores de identidades o directorios, infraestructura de administración independiente o infraestructura de conectividad independiente, la zona de aterrizaje requiere una modificación extensa. Si las normativas solo requieren que la infraestructura de la aplicación y la conectividad estén aisladas, la zona de aterrizaje necesita una modificación mínima.
Inquilinos de Microsoft Entra
Se recomienda usar un solo inquilino de Microsoft Entra para la mayoría de los escenarios, incluidos los escenarios multinacionales. Sin embargo, hay escenarios en los que puede preferir o requerir varios inquilinos de Microsoft Entra, como:
Si necesita separar el inquilino corporativo de Microsoft Entra del inquilino de Microsoft Entra de SaaS para mejorar la seguridad y crear límites claros entre el producto y las operaciones empresariales.
Si hay normativas en conflicto y necesita inquilinos independientes de Microsoft Entra para diferentes regímenes normativos. Por ejemplo, las normativas pueden tener requisitos de autorización y nacionalidad que necesitan aislamiento completo entre los inquilinos de Microsoft Entra o los requisitos de residencia de datos que requieren inquilinos independientes. Entre los escenarios comunes se incluyen un ISV que necesita implementar instancias aisladas de una solución SaaS o una organización multinacional que necesite implementar instancias aisladas de la misma solución.
Al colaborar en varios inquilinos de Microsoft Entra, debe planear cuidadosamente para lidiar con los desafíos y necesidades importantes. Cree solo el número mínimo de inquilinos de Microsoft Entra que necesita para cumplir los requisitos operativos o normativos. Puede utilizar grupos de administración y el control de acceso basado en roles (RBAC) de Azure para controlar el acceso a las suscripciones y los recursos de un único inquilino, como se describe en la siguiente sección.
Sugerencia
El inquilino de Microsoft Entra que seleccione para la zona de aterrizaje no afecta a la autenticación de nivel de aplicación. Todavía puede usar otros proveedores de identidades independientemente del inquilino que elija. En el caso de los clientes del sector público y clientes en sectores regulados, las identidades de usuario final suelen proporcionarse cuando se integra con un proveedor de identidades aprobado, como un proveedor de identidades certificado o propiedad del gobierno.
En los diagramas siguientes se muestran las opciones que puede usar para organizar los inquilinos de Microsoft Entra.
Sugerencia
Si tiene varios inquilinos de Microsoft Entra con los que cumplir los requisitos normativos, asigne un nombre a los inquilinos en función de la ubicación geográfica en lugar de normativas específicas, por ejemplo: contoso-ops-us.com en el diagrama de ejemplo.
Para obtener más información, consulte Zonas de aterrizaje de Azure y varios inquilinos de Microsoft Entra y Consideraciones de ISV para zonas de aterrizaje de Azure.
Grupos de administración
Si no necesita inquilinos de Microsoft Entra independientes para proporcionar aislamiento estricto, debe implementar varias zonas de aterrizaje de Azure en un solo inquilino de Microsoft Entra. Puede ajustar la jerarquía del grupo de administración para satisfacer los requisitos de las normativas en conflicto.
Puede implementar una arquitectura de zona de aterrizaje completa para cada conjunto de normativas que quiera separar. Este modelo requiere la menor cantidad de personalización y le permite aprovechar las ventajas de la automatización existente para la implementación.
Nota:
Este diagrama no muestra todos los grupos de administración.
Compartir el grupo de administración de plataformas
Si lo permite la normativa, se puede compartir el grupo de administración de plataformas. Puede crear grupos de administración independientes en el grupo de administración de zonas de aterrizaje para cada conjunto de normativas que deba separarse. Puede asignar las directivas adecuadas a cada uno de los grupos de administración de aplicaciones. Las zonas de aterrizaje de la aplicación comparten los grupos de administración que se encuentran en el grupo de administración de la plataforma. Los recursos de los grupos de administración de aplicaciones también se pueden separar por suscripción o grupo de recursos.
Esta jerarquía de grupos de administración es un diseño sencillo y rentable para aislar aplicaciones con normativas en conflicto. Sin embargo, en este diseño, los grupos de administración de plataformas para la conectividad, la identidad o la seguridad y la administración deben compartir el mismo conjunto de directivas. Es posible que necesite conjuntos de directivas diferentes para cada grupo de administración de plataformas si la normativa impone restricciones a la infraestructura de conectividad compartida, los servicios de identidad, los servicios de administración de claves o la infraestructura desde la que se administra todo el entorno.
Aislamiento de la identidad y la seguridad
Si las normativas impiden compartir la infraestructura de administración de identidades y claves, puede dividir el grupo de administración de plataformas. Mantenga los grupos de administración para la conectividad y administración en el grupo de administración de plataformas compartidas y tenga un grupo de administración de identidades y seguridad asociado a cada conjunto de normativas.
Esta jerarquía de grupos de administración es significativamente más compleja que un grupo de administración de plataformas totalmente compartido porque tiene que replicar parcialmente el grupo de administración de plataformas. Para limitar la complejidad, puede implementar la jerarquía completa para cada uno de los conjuntos de normativas y el entorno compartido, y omitir o eliminar los grupos de administración superfluos.
Aislamiento de la conectividad
Muchas normativas tienen requisitos relacionados con el procesamiento y el almacenamiento de datos en una determinada ubicación geográfica, con pocos requisitos sobre cómo los usuarios se conectan a las aplicaciones. Para esas normativas, puede compartir la administración de conectividad como se muestra en la arquitectura anterior. Es posible que no haya ninguna normativa que requiera duplicar la infraestructura en varias regiones, pero es posible que tenga que hacerlo con fines de latencia. Las directivas asignadas deben admitir la duplicación de la infraestructura en varias regiones.
Cuando las normativas tienen requisitos de conectividad en conflicto, puede crear un grupo de administración de conectividad asociado a cada conjunto de normativas. Esta estructura es similar a la arquitectura anterior que asocia grupos de administración de identidades y seguridad con cada conjunto de normativas.
Si las normativas entran en conflicto para la conectividad y también la identidad y la seguridad, puede usar el siguiente diseño.
Pasos siguientes
- Zonas de aterrizaje de Azure y varios inquilinos de Microsoft Entra
- Consideraciones de ISV para zonas de aterrizaje de Azure
- Microsoft Cloud Adoption Framework para Azure
- Microsoft Entra ID y residencia de datos
- Información general sobre el pilar de seguridad
- Recomendaciones para la administración de identidad y acceso
- Adaptar la arquitectura de zona de aterrizaje de Azure para cumplir los requisitos