Planeación de la identidad para aplicaciones de Azure Government

Microsoft Azure Government proporciona las mismas maneras de compilar aplicaciones y administrar identidades que Azure Público. Los clientes de Azure Government ya pueden tener un tenant público de Microsoft Entra o pueden crear un tenant en Microsoft Entra Government. En este artículo se ofrece orientación sobre las decisiones de identidad basadas en cómo se aplica y dónde se ubica su identidad.

Modelos de identidad

Antes de determinar el enfoque de identidad de la aplicación, debe saber qué tipos de identidad están disponibles. Hay tres tipos: identidad local, identidad en la nube e identidad híbrida.

Selección de identidad para una aplicación de Azure Government

Al compilar cualquier aplicación Azure, primero debe decidir la tecnología de autenticación:

• Aplicaciones que utilizan autenticación moderna: aplicaciones que usan OAuth, OpenID Connect y/o otros protocolos de autenticación modernos compatibles con Microsoft Entra como aplicaciones recién desarrolladas creadas con tecnologías PaaS, por ejemplo, Web Apps, Azure SQL Database, etc.
• Aplicaciones que usan protocolos de autenticación heredados (Kerberos/NTLM): las aplicaciones normalmente se migran desde el entorno local, por ejemplo, aplicaciones lift-and-shift.

En función de esta decisión, hay diferentes consideraciones al desarrollar e implementar en Azure Government.

Aplicaciones que usan la autenticación moderna en Azure Government

Registrar una aplicación con la plataforma de identidad de Microsoft muestra cómo puede usar Microsoft Entra ID para proporcionar inicio de sesión y autorización seguros a sus aplicaciones. Este proceso es el mismo para Azure Público y Azure Gobierno, una vez que elija la autoridad de identidad.

Elección de la autoridad de identidad

Las aplicaciones de Azure Government pueden usar identidades gubernamentales de Microsoft Entra, pero ¿se pueden usar identidades públicas de Microsoft Entra para autenticar a una aplicación hospedada en Azure Government? Yes! Dado que puede usar cualquiera de las autoridades de identidad, debe elegir cuál utilizar.

• Microsoft Entra Public: se usa habitualmente si la organización ya tiene un inquilino público de Microsoft Entra para admitir Office 365 (Público o GCC) u otra aplicación.
• Microsoft Entra Government: se usa habitualmente si su organización ya tiene un inquilino de Microsoft Entra Government para admitir Office 365 (GCC High o DoD) o está creando un nuevo inquilino en Microsoft Entra Government.

Una vez decidido, una consideración especial es dónde registras la aplicación. Si elige Microsoft Entra Public para las identidades de su aplicación de Azure Government, debe registrar la aplicación en la entidad pública de Microsoft Entra. De lo contrario, si realiza el registro de la aplicación en el directorio en el que confía la suscripción (Azure Government), el conjunto previsto de usuarios no podrá autenticarse.

La otra consideración es la URL de la autoridad de identidad. Necesita la dirección URL correcta en función de la autoridad elegida:

Aplicaciones que usan protocolos de autenticación heredados (Kerberos/NTLM)

La compatibilidad con aplicaciones basadas en la nube de infraestructura como servicio (IaaS) dependientes de la autenticación NTLM/Kerberos requiere una identidad local. El objetivo es admitir inicios de sesión para aplicaciones de línea de negocio y otras aplicaciones que requieren Windows autenticación integrada. Agregar Active Directory controladores de dominio como máquinas virtuales en Azure IaaS es el método típico para admitir estos tipos de aplicaciones, que se muestra en la ilustración siguiente:

El tipo de controlador de dominio que se va a colocar en Azure también es una consideración en función de los requisitos de aplicación para el acceso al directorio. Si las aplicaciones requieren acceso de escritura de directorio, implemente un controlador de dominio estándar con una copia grabable de la base de datos de Active Directory. Si las aplicaciones solo requieren acceso de lectura de directorio, se recomienda implementar un controlador de dominio (RODC) de Read-Only en Azure en su lugar. En concreto, para los RODC se recomienda seguir las instrucciones disponibles en Planificación de la ubicación del controlador de dominio.

La documentación que abarca las instrucciones para implementar controladores de Active Directory Domain y servicios de federación de Active Director (ADFS) está disponible en:

• La virtualización segura de Active Directory Domain Services responde a preguntas como
  • ¿Es seguro virtualizar controladores de Windows Server Active Directory Domain?
  • ¿Por qué implementar Active Directory en Azure Virtual Machines?
  • ¿Puede implementar ADFS en Azure Virtual Machines?
• Deploying Active Directory Federation Services en Azure proporciona instrucciones sobre cómo implementar ADFS en Azure.

Escenarios de identidad para la administración de suscripciones en Azure Government

En primer lugar, consulte Connect to Azure Government using portal para obtener instrucciones sobre cómo acceder al portal de administración de Azure Government.

Hay algunos puntos importantes que establecen la base de esta sección:

• Las suscripciones de Azure confían únicamente en un único directorio, por lo que la identidad de ese directorio debe encargarse de la administración de la suscripción.
• Las suscripciones públicas de Azure confían en los directorios de Microsoft Entra Public, mientras que las suscripciones de Azure Government confían en los directorios de Microsoft Entra Government.
• Si tiene tanto Azure suscripciones públicas como Azure Government, se requieren identidades independientes para ambas.

Los escenarios de identidad admitidos actualmente para administrar simultáneamente Azure suscripciones públicas y Azure Government son:

• Identidades en la nube: las identidades en la nube se usan para administrar ambas suscripciones.
• Identidades híbridas y en la nube: identidad híbrida para una suscripción, identidad en la nube para la otra.
• Identidades híbridas: las identidades híbridas se usan para administrar ambas suscripciones.

Un escenario común, que tiene tanto suscripciones de Office 365 como de Azure, se presenta en las secciones siguientes.

Uso de identidades en la nube para la administración de suscripciones de varias nubes

El diagrama siguiente es el más sencillo de los escenarios que se van a implementar.

Aunque el uso de identidades en la nube es el enfoque más sencillo, también es el menos seguro porque las contraseñas se usan como factor de autenticación. Recomendamos la autenticación multifactor de Microsoft Entra, la solución de verificación en dos pasos de Microsoft, para agregar una segunda capa crítica de seguridad para proteger el acceso a las suscripciones de Azure al usar identidades en la nube.

Uso de identidades híbridas y en la nube para la administración de suscripciones de varias nubes

En este escenario, se incluyen identidades de administrador a través de la sincronización de directorios con el inquilino público, mientras que las identidades en la nube todavía se usan en el inquilino gubernamental.

El uso de identidades híbridas para cuentas administrativas permite el uso de tarjetas inteligentes (físicas o virtuales). Las agencias gubernamentales que usan tarjetas de acceso común (CAC) o tarjetas de verificación de identidad personal (PIV) se benefician de este enfoque. En este escenario, ADFS actúa como proveedor de identidades e implementa la verificación en dos pasos (por ejemplo, tarjeta inteligente + PIN).

Uso de identidades híbridas para la administración de suscripciones de varias nubes

En este escenario, las identidades híbridas se usan para las suscripciones de administrador en ambas nubes.

Preguntas más frecuentes

¿Por qué Office 365 GCC usa Microsoft Entra Público?
El primer entorno Office 365 gobierno de EE. UU., Government Community Cloud (GCC), se creó cuando Microsoft tenía un único directorio en la nube. El entorno Office 365 GCC se diseñó para usar Microsoft Entra Público, a la vez que seguía cumpliendo los controles y requisitos descritos en FedRAMP Moderate, Criminal Justice Information Services (CJIS), Internal Revenue Service (IRS) 1075 y National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171. Azure Government, con su infraestructura de Microsoft Entra, se creó más adelante. En ese momento, GCC ya había protegido las autorizaciones de cumplimiento necesarias (por ejemplo, FedRAMP Moderate y CJIS) para cumplir los requisitos federales, estatales y gubernamentales locales, a la vez que atiende a cientos de miles de clientes. Ahora, muchos clientes de Office 365 GCC tienen dos inquilinos de Microsoft Entra: uno de la suscripción de Microsoft Entra que admite Office 365 GCC y el otro de su suscripción de Azure Government, con identidades en ambos.

¿Cómo puedo identificar un inquilino de Azure Government?
Esta es una manera de averiguarlo usando el navegador de su elección:

• Obtenga el nombre del inquilino (por ejemplo, contoso.onmicrosoft.com) o un nombre de dominio registrado en el inquilino de Microsoft Entra (por ejemplo, contoso.gov).

• Vaya a https://login.microsoftonline.com/<domainname>/.well-known/openid-configuration.

  • <domainname> puede ser el nombre de inquilino o el nombre de dominio que ha recopilado en el paso anterior.
  • Una dirección URL de ejemplo: https://login.microsoftonline.com/contoso.onmicrosoft.com/.well-known/openid-configuration

• El resultado se devuelve a la página como pares de atributo/valor mediante el formato de Notación de Objetos de JavaScript (JSON) similar al siguiente:

  {
    "authorization_endpoint":"https://login.microsoftonline.com/b552ff1c-edad-4b6f-b301-5963a979bc4d/oauth2/authorize",
    "tenant_region_scope":"USG"
  }
  

• Si el valor del atributo tenant_region_scope es USG tal como se muestra o USGov, tiene un inquilino de Azure Government.

  • El resultado es un archivo JSON que se representa de forma nativa en exploradores más modernos, como Microsoft Edge, Mozilla Firefox y Google Chrome. Internet Explorer no representa de forma nativa el formato JSON, por lo que, en su lugar, le pide que abra o guarde el archivo. Si debe usar Internet Explorer, elija la opción guardar y ábrala con otro explorador o lector de texto sin formato.
  • La propiedad tenant_region_scope es, tal y como suena, regional. Si tiene un inquilino en Azure Public en Norteamérica, el valor sería NA.

Si soy un cliente de Office 365 GCC y quiero crear soluciones en Azure Government ¿necesito tener dos inquilinos?
Sí, el inquilino de Microsoft Entra Government es necesario para la administración de las suscripciones de Azure Government.

Si soy un cliente de Office 365 GCC que tiene cargas de trabajo integradas en Azure Government, ¿dónde debo autenticar: Público o Gobierno?
Consulte Cómo elegir tu autoridad de identidad más arriba en este artículo.

Soy un cliente Office 365 y he elegido la identidad híbrida como modelo de identidad. También tengo varias suscripciones Azure. ¿Es posible usar el mismo inquilino de Microsoft Entra para controlar el inicio de sesión para Office 365, las aplicaciones integradas en mis suscripciones de Azure o las aplicaciones reconfiguradas para usar Microsoft Entra ID para el inicio de sesión?
Sí, consulte Associate o agregue una suscripción de Azure al inquilino de Microsoft Entra para obtener más información sobre la relación entre las suscripciones de Azure y las Microsoft Entra ID. También contiene instrucciones sobre cómo asociar suscripciones al directorio común de su elección.

¿Se puede asociar una suscripción Azure Government a un directorio en Microsoft Entra Público?
No, la capacidad de administrar suscripciones Azure Government requiere identidades procedentes de un directorio en Microsoft Entra Government.

Pasos siguientes

• guía para desarrolladores de Azure Government
• Seguridad de Azure Government
• cumplimiento de Azure Government
• Comparar Azure Government y Azure global
• Gestión de usuarios multitenant
• Documentación sobre los aspectos básicos de Microsoft Entra