Procedimientos recomendados para todas las arquitecturas de aislamiento
Las siguientes son consideraciones de diseño para todas las configuraciones de aislamiento. En este contenido, hay muchos vínculos. Son vínculos al contenido, para no duplicarlo aquí; así siempre tendrá acceso a la información más actualizada.
Para obtener instrucciones generales sobre cómo configurar Microsoft Entra inquilinos (aislados o no), consulte la guía de implementación de características de Microsoft Entra.
Nota:
Para todos los inquilinos aislados, se recomienda usar la personalización de marca clara y diferenciada para evitar los errores humanos al trabajar en el inquilino incorrecto.
Principios de seguridad de aislamiento
Al diseñar entornos aislados, es importante tener en cuenta los siguientes principios:
Usar solo la autenticación moderna: las aplicaciones implementadas en entornos aislados deben usar la autenticación moderna basada en notificaciones (por ejemplo, SAML, * Auth, OAuth2 y OpenID Connect) para aprovechar funcionalidades como la federación, la colaboración Microsoft Entra B2B, la delegación y el marco de consentimiento. De este modo, las aplicaciones heredadas que dependen de métodos de autenticación heredados como NT LAN Manager (NTLM) no continuarán en entornos aislados.
Exigir autenticación segura: esta debe usarse siempre al acceder a los servicios y la infraestructura del entorno aislado. Siempre que sea posible, se debe usar autenticación sin contraseña, como Windows Hello para empresas o claves de seguridad FIDO2.
Implementar estaciones de trabajo seguras: las estaciones de trabajo seguras proporcionan el mecanismo para asegurarse de que la plataforma y la identidad que representa la plataforma se atestiguan y protegen correctamente frente a la explotación. Otros dos enfoques que se deben tener en cuenta son:
El uso de PC en la nube Windows 365 (PC en la nube) con Microsoft Graph API.
Uso de acceso condicional y filtro para los dispositivos como condición.
Eliminar los mecanismos de confianza heredados: los directorios y los servicios aislados no deben establecer relaciones de confianza con otros entornos mediante mecanismos heredados, como las confianzas de Active Directory. Todas las confianzas entre entornos deben establecerse con construcciones modernas, como la federación y la identidad basada en notificaciones.
Aislar servicios: minimice el área expuesta a ataques mediante la protección de las identidades subyacentes y la infraestructura de servicio frente a la exposición. Habilite el acceso solo mediante la autenticación moderna para los servicios y el acceso remoto seguro (también protegido por la autenticación moderna) para la infraestructura.
Asignaciones de roles de nivel de directorio: evite o reduzca el número de asignaciones de roles de nivel de directorio (administrador de usuarios en el ámbito del directorio en lugar del ámbito de AU) o de roles de directorio específicos del servicio con acciones de plano de control (administrador de conocimiento con permisos para administrar las pertenencias a grupos de seguridad).
Además de las instrucciones de la guía de operaciones generales de Microsoft Entra, también se recomiendan las siguientes consideraciones para los entornos aislados.
Aprovisionamiento de identidades humanas
Cuentas con privilegios
Aprovisione cuentas en el entorno aislado para el personal administrativo y los equipos de TI que operan el entorno. Esto le permite agregar directivas de seguridad más seguras, como el control de acceso basado en dispositivos para las estaciones de trabajo seguras. Como se explicó en las secciones anteriores, los entornos que no son de producción pueden usar la colaboración Microsoft Entra B2B para incorporar cuentas con privilegios a los inquilinos que no son de producción mediante la misma posición y controles de seguridad diseñados para el acceso con privilegios en su entorno de producción.
Las cuentas solo en la nube son la manera más sencilla de aprovisionar identidades humanas en un inquilino de Microsoft Entra y es una buena opción para entornos sin desarrollar. Sin embargo, si hay una infraestructura local existente que corresponde al entorno aislado (por ejemplo, bosque de preproducción o administración de Active Directory), podría considerar la posibilidad de sincronizar las identidades desde allí. Esto es especialmente cierto si la infraestructura local aquí descrita también se usa para las soluciones IaaS que requieren acceso al servidor para administrar el plano de datos de la solución. Para más información sobre este escenario, consulte Protección de Microsoft 365 contra ataques locales. También puede ser necesaria sincronización desde entornos locales aislados si hay requisitos de cumplimiento normativo específicos, como autenticación solo de tarjeta inteligente.
Nota:
No hay controles técnicos para la corrección de identidades para las cuentas Microsoft Entra B2B. Las identidades externas aprovisionadas con Microsoft Entra B2B se arrancan con un único factor. La organización logra la mitigación con un proceso para comprobar las identidades necesarias antes de que se emita una invitación B2B y con revisiones de acceso periódicas de las identidades externas para administrar el ciclo de vida. Considere la posibilidad de habilitar una directiva de acceso condicional para controlar el registro de MFA.
Subcontratación de roles de alto riesgo
Para mitigar las amenazas internas, es posible externalizar el acceso a los roles Administrador global y Administrador de roles con privilegios, y hacer que los administre el proveedor de servicios mediante la colaboración B2B de Azure o delegar el acceso mediante un asociado o faro de CSP. Este acceso se puede controlar mediante el personal interno a través de flujos de aprobación en Azure Privileged Identity Management (PIM). Este enfoque puede reducir considerablemente las amenazas internas. Se trata de un enfoque que puede usar para satisfacer las demandas de cumplimiento de los clientes con preocupaciones.
Aprovisionamiento de identidades no humanas
Cuentas de acceso de emergencia
Microsoft recomienda que las organizaciones tengan dos cuentas de acceso de emergencia de solo nube con el rol de administrador global asignado permanentemente. Estas cuentas tienen privilegios elevados y no se asignan a usuarios específicos. Las cuentas se limitan a escenarios de emergencia o de "romper el vidrio" en los que las cuentas normales no se pueden usar o todos los demás administradores se bloquean accidentalmente. Estas cuentas deben crearse siguiendo las recomendaciones de cuentas de acceso de emergencia.
Identidades administradas de Azure
Use identidades administradas de Azure para los recursos de Azure que requieran una identidad de servicio. Compruebe la lista de servicios que admiten las identidades administradas al diseñar las soluciones de Azure.
Si las identidades administradas no se admiten o no son posibles, considere la posibilidad de aprovisionar objetos de entidad de servicio.
Cuentas de servicio híbridas
Algunas soluciones híbridas pueden requerir acceso a recursos tanto locales como en la nube. Un ejemplo de un caso de uso sería una aplicación que usa una cuenta de servicio en AD DS para acceder a servidores unidos a un dominio local y también tiene una cuenta en Microsoft Entra ID, ya que requiere acceso a Microsoft Online Services.
Las cuentas de servicio locales normalmente no pueden iniciar sesión de forma interactiva, lo que significa que en escenarios en la nube no cumplen los requisitos de credenciales seguras, como la autenticación multifactor. En este escenario, no use una cuenta de servicio que se haya sincronizado desde el entorno local, sino que use una identidad administrada o entidad de servicio. Para la entidad de servicio, use un certificado como credencial o protéjala con acceso condicional.
Si hay restricciones técnicas que lo impiden y se debe usar la misma cuenta tanto para el entorno local como para la nube, implemente controles de compensación como el acceso condicional para hacer que la cuenta híbrida no pueda proceder de una ubicación de red específica.
Asignación de recursos
Una solución empresarial puede estar formada por varios recursos de Azure y su acceso debe administrarse y controlarse como unidad lógica de asignación: un grupo de recursos. En ese escenario, los grupos de seguridad de Microsoft Entra se pueden crear y asociar con los permisos adecuados y la asignación de roles en todos los recursos de la solución, de modo que agregar o quitar usuarios de esos grupos signifique permitir o denegar el acceso a toda la solución.
Se recomienda utilizar licencias basadas en grupos y grupos de seguridad para los servicios de Microsoft que dependen de que un usuario tenga una asignación de puesto de licencia como requisito previo antes de proporcionar acceso (por ejemplo, Dynamics 365, Power BI).
Microsoft Entra grupos nativos en la nube se pueden regular de forma nativa desde la nube cuando se combinan con revisiones de acceso Microsoft Entra y administración de derechos de Microsoft Entra.
Microsoft Entra ID también admite la asignación directa de usuarios a servicios SaaS de terceros (por ejemplo, Salesforce, Service Now) y aplicaciones locales para el inicio de sesión único y el aprovisionamiento de identidades. Microsoft Entra grupos nativos en la nube se pueden regular de forma nativa desde la nube cuando se combinan con revisiones de acceso Microsoft Entra y administración de derechos de Microsoft Entra. La asignación directa puede ser una buena opción para la asignación orientada al usuario final.
Algunos escenarios pueden requerir que se conceda acceso a recursos locales mediante grupos de seguridad locales de Active Directory. En esos casos, considere la opción del ciclo de sincronización con Microsoft Entra ID al diseñar el Acuerdo de Nivel de Servicio de procesos.
Administración de la autenticación
En esta sección se describen las comprobaciones que se deben realizar y las medidas que se deben tomar para la administración de credenciales y las directivas de acceso en función de la posición de seguridad de la organización.
Administración de credenciales
Credenciales seguras
Todas las identidades humanas (cuentas locales e identidades externas aprovisionadas mediante colaboración B2B) del entorno aislado deben aprovisionarse con credenciales de autenticación sólidas, como la autenticación multifactor o una clave FIDO. Los entornos con una infraestructura local subyacente con autenticación segura, como la autenticación con tarjeta inteligente, pueden seguir usando la autenticación de tarjeta inteligente en la nube.
Credenciales sin contraseña
Una solución sin contraseña es lo mejor para garantizar el método de autenticación más seguro y práctico. Se recomiendan credenciales sin contraseña como las claves de seguridad FIDO y Windows Hello para empresas para identidades humanas con roles con privilegios.
Protección con contraseña
Si el entorno se sincroniza desde un bosque de Active Directory local, debe implementar la protección con contraseña de Microsoft Entra para eliminar las contraseñas no seguras de la organización. El bloqueo inteligente de Microsoft Entra también debe usarse en entornos híbridos o solo en la nube para bloquear a los actores no válidos que intentan adivinar las contraseñas de los usuarios o usar métodos de fuerza bruta para entrar.
Self-service Password Management (Administración de contraseñas de autorservicio)
Los usuarios que necesitan cambiar o restablecer sus contraseñas son uno de los principales orígenes de volumen y costo debido a las llamadas que realizan al departamento de soporte técnico. Además del costo, cambiar la contraseña como una herramienta para mitigar el riesgo de un usuario es un paso fundamental para mejorar la posición de seguridad de su organización. Como mínimo, implemente la administración de contraseñas de autoservicio para las cuentas humanas y de prueba con contraseñas para anular la selección de llamadas del departamento de soporte técnico.
Contraseñas de las identidades externas
Mediante la colaboración Microsoft Entra B2B, un proceso de invitación y canje permite usar sus propias credenciales para acceder a los recursos de la empresa a los usuarios externos, como asociados, desarrolladores y subcontratistas. Esto elimina la necesidad de más contraseñas en los inquilinos aislados.
Nota
Algunas aplicaciones, infraestructura o flujos de trabajo pueden requerir una credencial local. Valore el caso de manera individual.
Credenciales de las entidades de servicio
En escenarios en los que se necesitan entidades de servicio, use credenciales de certificado para estas o el acceso condicional para las identidades de carga de trabajo. Si es necesario, use secretos de cliente como excepción a la directiva de la organización.
En ambos casos, Azure Key Vault se puede usar con las identidades administradas de Azure de modo que el entorno en tiempo de ejecución (por ejemplo, una función de Azure) pueda recuperar la credencial del almacén de claves.
Consulte este ejemplo para crear entidades de servicio con un certificado autofirmado para la autenticación de las entidades de servicio con credenciales de certificado.
Directivas de acceso
En las secciones siguientes se muestran recomendaciones para las soluciones de Azure. Para instrucciones generales sobre las directivas de acceso condicional para entornos individuales, consulte los Procedimientos recomendados de acceso condicional, la Guía de operaciones de Microsoft Entra y el Acceso condicional para Confianza cero:
Defina directivas de acceso condicional para la aplicación en la nube Windows Azure Service Management API para aplicar la posición de seguridad de identidad al acceder a Azure Resource Manager. Esto debe incluir controles en MFA y otros basados en dispositivos para habilitar el acceso solo mediante estaciones de trabajo seguras (más información sobre esto en la sección Roles con privilegios de Gobernanza de identidades). Además, use Acceso condicional: filtro para dispositivos.
Todas las aplicaciones incorporadas a entornos aislados deben tener directivas de acceso condicional explícitas aplicadas como parte del proceso de incorporación.
Defina directivas de acceso condicional para el registro de información de seguridad que refleje una raíz segura del proceso de confianza local (por ejemplo, para estaciones de trabajo en ubicaciones físicas, identificables por direcciones IP, que los empleados deban visitar en persona para la verificación).
Considere la posibilidad de usar el acceso condicional para restringir las identidades de carga de trabajo. Cree una directiva para limitar o controlar mejor el acceso en función de la ubicación u otras circunstancias pertinentes.
Desafíos de la autenticación
Es posible que las identidades externas aprovisionadas con Microsoft Entra B2B necesiten volver a aprovisionar las credenciales de autenticación multifactor (MFA) en el inquilino de recursos. Esto puede ser necesario si no se ha configurado una directiva de acceso entre inquilinos con el inquilino de recursos. Esto significa que la incorporación al sistema se arranca con un único factor. Con este enfoque, los riesgos se reducen en la organización con un proceso para comprobar el perfil de riesgo de los usuarios y credenciales antes de que se emita una invitación B2B. Además, defina el acceso condicional al proceso de registro como se ha descrito anteriormente.
Use la configuración de acceso entre inquilinos de External Identities para gestionar cómo colaboran con otras organizaciones de Microsoft Entra y con otras nubes de Microsoft Azure mediante la colaboración B2B y la conexión directa B2B.
Para el control y la configuración de dispositivos específicos, puede usar filtros del dispositivo en las directivas de acceso condicional para seleccionar o excluir dispositivos específicos. Esto le permite restringir el acceso a las herramientas de administración de Azure desde una estación de trabajo de administración segura (SAW) designada. Otros enfoques que puede adoptar incluyen el uso de Azure Virtual Desktop, Azure Bastion o PC en la nube.
Las aplicaciones de administración de facturación, como Azure EA Portal o las cuentas de facturación de MCA, no se representan como aplicaciones en la nube para el destino del acceso condicional. Como control de compensación, defina cuentas de administración independientes y dirija las directivas de acceso condicional a esas cuentas mediante una condición "Todas las aplicaciones".
Identity Governance
Roles con privilegios
A continuación se muestran algunos principios de gobernanza de identidades que se deben tener en cuenta en todas las configuraciones de inquilino para el aislamiento.
Sin acceso permanente: ninguna identidad humana debe tener acceso permanente para realizar operaciones con privilegios en entornos aislados. El control de acceso basado en rol (RBAC) de Azure se integra con Microsoft Entra Privileged Identity Management (PIM). PIM proporciona activación Just-In-Time determinada por puertas de seguridad como la autenticación multifactor, el flujo de trabajo de aprobación y la duración limitada.
Número de administradores: las organizaciones deben definir el número mínimo y máximo de personas que tienen un rol con privilegios para mitigar los riesgos de continuidad empresarial. Con demasiado pocos roles con privilegios, puede que no haya suficiente cobertura de zona horaria. Mitigue los riesgos de seguridad con tantos administradores como sea posible, siguiendo el principio de privilegios mínimos.
Limitación del acceso con privilegios: cree grupos solo en la nube y a los que se puedan asignar roles para privilegios elevados o confidenciales. Esto ofrece protección para los usuarios asignados y el objeto de grupo.
Acceso con privilegios mínimos: solo se deben conceder a las identidades los permisos necesarios para realizar las operaciones con privilegios según su rol en la organización.
Los roles personalizados de RBAC de Azure permiten diseñar roles con privilegios mínimos en función de las necesidades de la organización. Se recomienda que los equipos de seguridad especializados creen o revisen las definiciones de roles personalizados y mitiguen los riesgos de privilegios excesivos no deseados. La creación de roles personalizados se puede auditar mediante Azure Policy.
Para mitigar el uso accidental de roles que no están diseñados para un uso más amplio en la organización, con Azure Policy especifique explícitamente qué definiciones de roles se pueden usar para asignar acceso. Más información en este ejemplo de GitHub.
Acceso con privilegios desde estaciones de trabajo seguras: todo el acceso con privilegios debe producirse desde dispositivos seguros y bloqueados. La separación de estas tareas y cuentas confidenciales de las estaciones de trabajo y dispositivos de uso diario protege las cuentas con privilegios de los ataques de suplantación de identidad (phishing), las vulnerabilidades de las aplicaciones o del sistema operativo, diversos ataques de suplantación y ataques de robo de credenciales, como registro de pulsaciones de teclas, y ataques pass-the-hash y pass-the-ticket.
Algunos enfoques para usar dispositivos seguros como parte del artículo de acceso con privilegios incluyen el uso de directivas de acceso condicional para dirigirse a dispositivos específicos o excluirlos, mediante Azure Virtual Desktop, Azure Bastion o PC en la nube, o la creación de estaciones de trabajo administradas por Azure o de acceso con privilegios.
Límites de protección de procesos de rol con privilegios: las organizaciones deben definir procesos y límites de protección técnicos para garantizar que las operaciones con privilegios se puedan ejecutar siempre que sea necesario al tiempo que se cumplen los requisitos normativos. Algunos criterios de límites de protección son los siguientes:
Calificación de personas con roles con privilegios (por ejemplo, empleado/proveedor a tiempo completo, nivel de autorización, ciudadanía)
Incompatibilidad explícita de roles (también conocida como división de tareas). Por ejemplo, los equipos con funciones de directorio de Microsoft Entra no deberían ser responsables de administrar las funciones privilegiadas de Azure Resource Manager, etc.
La preferencia porasignaciones directas de usuarios o de grupos para los roles.
La supervisión de asignaciones de IAM fuera de Microsoft Entra PIM no se automatiza mediante directivas de Azure. Esto se mitiga con no conceder roles de propietario de la suscripción ni de administrador de acceso de usuario a los equipos de ingeniería. En su lugar, cree grupos asignados a roles con privilegios mínimos, como Colaborador y delegue la administración de esos grupos a los equipos de ingeniería.
Acceso a los recursos
Atestación: las identidades que contienen roles con privilegios se deben revisar periódicamente para mantener la pertenencia actualizada y justificada. Las revisiones de acceso de Microsoft Entra se integran con roles RBAC de Azure, las pertenencias a grupos y las identidades externas de Azure AD B2B.
Ciclo de vida: las operaciones con privilegios pueden requerir acceso a varios recursos, como aplicaciones de línea de negocio, aplicaciones SaaS y grupos de recursos y suscripciones de Azure. La administración de derechos de Microsoft Entra permite definir paquetes de acceso que representan un recurso establecido que se asigna a los usuarios como una unidad, establecer un período de validez, flujos de trabajo de aprobación, etc.
Administración del ciclo de vida de la suscripción y del inquilino
Ciclo de vida del inquilino
Se recomienda implementar un proceso para solicitar un nuevo inquilino corporativo de Microsoft Entra. El proceso debe tener en cuenta:
La justificación comercial para crearlo. La creación de un nuevo inquilino de Microsoft Entra aumentará significativamente la complejidad, por lo que es clave determinar si es necesario.
La nube de Azure en la que se debe crear (por ejemplo, comercial, gubernamental, etc.).
Si se trata de producción o no.
Los requisitos de residencia de datos de directorio.
Quién lo administrará
El aprendizaje y la comprensión de los requisitos de seguridad comunes.
Tras la aprobación, se creará el inquilino de Microsoft Entra, se configurará con los controles de línea base necesarios y se incorporará en el plano de facturación, en la supervisión, etc.
Es necesario implementar una revisión periódica de los inquilinos de Microsoft Entra en el plano de facturación para detectar la creación de inquilinos fuera del proceso regulado. Consulte la sección Inventario y visibilidad de este documento para más detalles.
La creación de inquilinos de Azure AD B2C se puede controlar mediante Azure Policy. La directiva se ejecuta cuando una suscripción de Azure se asocia al inquilino de B2C (un requisito previo para la facturación). Los clientes pueden limitar la creación de inquilinos de Azure AD B2C a grupos de administración específicos.
No hay controles técnicos para subordinar la creación de inquilinos a una organización. Sin embargo, la actividad se registra en el registro de auditoría. La incorporación al plano de facturación es un control de compensación en la puerta. En su lugar, esto debe complementarse con supervisión y alertas.
Ciclo de vida de la suscripción
A continuación se muestran algunas consideraciones al diseñar un proceso de ciclo de vida de suscripción regulado:
Defina una taxonomía para las aplicaciones y soluciones que requieran recursos de Azure. Todos los equipos que solicitan suscripciones deben proporcionar su "identificador de producto" al hacerlo. Esta taxonomía de la información determinará:
Microsoft Entra inquilino para aprovisionar la suscripción
La cuenta del Contrato Enterprise de Azure que se va a usar para la creación de la suscripción
Convención de nomenclatura
Asignación de grupos de administración
Otros aspectos, como el etiquetado, la carga cruzada, el uso de la vista del producto, etc.
no permiten la creación de suscripciones ad hoc mediante los portales ni por otros medios. En su lugar, considere la posibilidad de administrar suscripciones mediante programación con Azure Resource Manager y extraer informes de consumo y facturación mediante programación. Esto puede ayudar a limitar el aprovisionamiento de la suscripción a los usuarios autorizados y a aplicar los objetivos de directiva y taxonomía. Se pueden usar instrucciones sobre las siguientes entidades de seguridad de AZOps para ayudar a crear una solución práctica.
Al aprovisionar una suscripción, cree grupos en la nube de Microsoft Entra para que contengan los roles estándar de Azure Resource Manager necesarios para los equipos de aplicaciones, como colaborador, lector y roles personalizados aprobados. Esto permite administrar asignaciones de roles RBAC de Azure con acceso con privilegios regulados a escala.
Configure los grupos para que sean aptos para los roles RBAC de Azure mediante Microsoft Entra PIM con los controles correspondientes, como la directiva de activación, las revisiones de acceso, los aprobadores, etc.
A continuación, delegue la administración de los grupos a los propietarios de las soluciones.
Como límite de protección, no asigne propietarios de productos a roles de administrador de acceso de usuario o propietario para evitar la asignación directa involuntaria de roles fuera de Microsoft Entra PIM o el cambio de la suscripción a un inquilino diferente por completo.
Para los clientes que decidan habilitar la administración de suscripciones entre inquilinos que no son de producción mediante Azure Lighthouse, asegúrese de que se aplican las mismas directivas de acceso de la cuenta con privilegios de producción (por ejemplo, el acceso con privilegios solo desde estaciones de trabajo protegidas) al autenticarse para administrar las suscripciones.
Si su organización tiene arquitecturas de referencia aprobadas previamente, el aprovisionamiento de suscripciones se puede integrar con herramientas de implementación de recursos como Azure Blueprints o Terraform.
Dada la afinidad del inquilino con las suscripciones de Azure, el aprovisionamiento de suscripciones debe tener en cuenta varias identidades para el mismo actor humano (empleado, asociado, proveedor, etc.) en varios inquilinos y asignar el acceso en consecuencia.
Roles de EA y MCA
El portal del contrato Enterprise (Azure EA) de Azure no se integra con RBAC de Azure ni con el acceso condicional. Esto se mitiga con cuentas de administración dedicadas a las que se puede dirigir uno mediante directivas y supervisión adicional.
El portal del contrato Enterprise Azure EA no proporciona registros de auditoría. Esto se puede mitigar con un proceso controlado automatizado para aprovisionar suscripciones con las consideraciones descritas anteriormente y usar cuentas de EA dedicadas y auditar los registros de autenticación.
Los roles de Contrato de cliente de Microsoft (MCA) no se integran de forma nativa con PIM. Para mitigar esto, use cuentas de MCA dedicadas y supervise el uso de estas cuentas.
Inquilinos de Azure AD B2C
En un inquilino de Azure AD B2C, los roles integrados no admiten PIM. Para aumentar la seguridad, se recomienda usar la colaboración Microsoft Entra B2B para incorporar los equipos de ingeniería que administran Customer Identity Access Management (CIAM) desde el inquilino de Azure, asignarlos a roles con privilegios de Azure AD B2C y aplicar directivas de acceso condicional a estas cuentas de administración dedicadas.
Los roles con privilegios de inquilino de Microsoft Entra B2C no se integran con Microsoft Entra revisiones de acceso. La mitigación consiste en crear cuentas dedicadas en el inquilino de Microsoft Entra de la organización, agregar estas cuentas a un grupo y realizar revisiones de acceso periódicas en este grupo.
Siguiendo las directrices de acceso de emergencia para Microsoft Entra ID anteriores, considere la posibilidad de crear cuentas de acceso de emergencia equivalentes además de los administradores externos ya descritos.
Se recomienda que la propiedad lógica de la suscripción subyacente de Microsoft Entra del inquilino de B2C se alinee con los equipos de ingeniería de CIAM, de la misma manera que se usan el resto de las suscripciones de Azure para las soluciones B2C.
Operations
A continuación se muestran consideraciones operativas adicionales para Microsoft Entra ID específicas de varios entornos aislados. Consulte Azure Cloud Adoption Framework, Azure Security Benchmark y la guía de referencia de operaciones de Microsoft Entra para instrucciones detalladas para operar entornos individuales.
Roles y responsabilidades entre entornos
Arquitectura de SecOps para toda la empresa: los miembros de los equipos de operaciones y seguridad de todos los entornos de la organización deben definir conjuntamente lo siguiente:
Principios para definir cuándo es necesario crear, consolidar o desusar entornos.
Principios para definir la jerarquía de los grupos de administración en cada entorno.
Posición de seguridad del plano de facturación (EA Portal/MCA), posición operativa y enfoque de delegación.
Proceso de creación de inquilinos.
Taxonomía de las aplicaciones empresariales.
Proceso de aprovisionamiento de la suscripción de Azure.
Límites de autonomía de aislamiento y administración, y evaluación de riesgos en los equipos y los entornos.
Los controles de seguridad y configuración de línea base comunes (técnicos y compensadores) y líneas base operativas que se usarán en todos los entornos.
Procedimientos operativos estándar comunes y herramientas para varios entornos (por ejemplo, supervisión, aprovisionamiento).
Se ha acordado la delegación de roles en varios entornos.
Segregación del deber entre entornos.
Administración común de cadenas de suministros para estaciones de trabajo con privilegios.
Convenciones de nomenclatura.
Mecanismos de correlación entre entornos.
Creación de inquilinos : un equipo específico debe ser propietario de la creación del inquilino siguiendo los procedimientos estandarizados definidos por la arquitectura de SecOps en toda la empresa. Esto incluye:
Aprovisionamiento de licencias subyacente (por ejemplo, Microsoft 365).
Incorporación al plan de facturación corporativo (por ejemplo, Azure EA o MCA).
Creación de una jerarquía para los grupos de administración de Azure.
Configuración de directivas de administración para varios perímetros, incluida la identidad, la protección de datos, Azure, etc.
Implementación de la pila de seguridad según la arquitectura de ciberseguridad acordada, incluida la configuración de diagnóstico y la incorporación de SIEM, de CASB y de PIM, etc.
Configuración de los roles de Microsoft Entra en función de la delegación acordada.
Configuración y distribución de las estaciones de trabajo con privilegios iniciales.
Aprovisionamiento de las cuentas de acceso de emergencia.
Configuración de la pila de aprovisionamiento de identidades.
Arquitectura de herramientas entre entornos: es posible que algunas herramientas como el aprovisionamiento de identidades y las canalizaciones de control de código fuente deban funcionar en varios entornos. Estas herramientas deben considerarse críticas para la infraestructura y organizarse, diseñarse, implementarse y administrarse como tales. Como resultado, los arquitectos de todos los entornos deben participar siempre que sea necesario definir herramientas entre entornos.
Inventario y visibilidad
Detección de suscripciones de Azure: para cada inquilino detectado, un administrador global de Microsoft Entra puede elevar el acceso para obtener visibilidad de todas las suscripciones del entorno. Esta elevación los asignará al rol integrado Administrador de acceso de usuario en el grupo de administración raíz.
Nota:
Esta acción tiene privilegios elevados y podría conceder al administrador acceso a las suscripciones que contienen información extremadamente confidencial si esos datos no se han aislado correctamente.
Habilitación del acceso de lectura para detectar recursos: los grupos de administración habilitan la asignación de RBAC a gran escala en varias suscripciones. Los clientes pueden conceder el rol Lector a un equipo de TI centralizado mediante la configuración de una asignación de roles en el grupo de administración raíz que se propague a todas las suscripciones del entorno.
Detección de recursos: después de obtener acceso de lectura de recursos en el entorno, se puede usar Azure Resource Graph para consultar los recursos del entorno.
Registro y supervisión
Administración central de los registros de seguridad: ingiera registros de cada entorno de forma centralizada, siguiendo procedimientos recomendados coherentes entre los entornos (por ejemplo, configuración de diagnóstico, retención de registros, ingesta de SIEM, etc.). Azure Monitor se puede usar para ingerir registros de diferentes orígenes, como dispositivos de punto de conexión, red, registros de seguridad de sistemas operativos, etc.
Puede encontrar información detallada sobre el uso de procesos y herramientas automatizados o manuales para supervisar los registros como parte de las operaciones de seguridad en la guía de operaciones de seguridad de Microsoft Entra.
Algunos entornos pueden tener requisitos normativos que limiten los datos (si los hubiera) que pueden dejar un entorno determinado. Si no es posible la supervisión centralizada entre entornos, los equipos deben tener procedimientos operativos para correlacionar las actividades de las identidades entre entornos con fines de auditoría y análisis forense, como los intentos de movimiento lateral entre entornos. Se recomienda que se puedan reconocer los identificadores únicos de objeto que pertenecen a la misma persona, posiblemente como parte de los sistemas de aprovisionamiento de identidades.
La estrategia de registro debe incluir los siguientes registros de Microsoft Entra para cada inquilino que se use en la organización:
Actividad de inicio de sesión
Registros de auditoría
Eventos de riesgo
Microsoft Entra ID proporciona la integración de Azure Monitor para los registros de auditoría y el registro de actividad de inicio de sesión. Los eventos de riesgo se pueden ingerir mediante Microsoft Graph API.
En el diagrama siguiente se muestran los distintos orígenes de datos que deben incorporarse como parte de la estrategia de supervisión:
Los inquilinos de Azure AD B2C se pueden integrar con Azure Monitor. Se recomienda supervisar Azure AD B2C con los mismos criterios descritos anteriormente para Microsoft Entra ID.
Las suscripciones que han habilitado la administración entre inquilinos con Azure Lighthouse pueden habilitar la supervisión entre inquilinos si Azure Monitor recopila los registros. Las áreas de trabajo de Log Analytics correspondientes pueden residir en el inquilino de recursos y se pueden analizar de forma centralizada en el inquilino de administración mediante libros de Azure Monitor. Para más información, consulte Supervisión de los recursos delegados a escala: Azure Lighthouse.
Registros de seguridad del sistema operativo de infraestructura híbrida
Todos los registros del sistema operativo de infraestructura de identidad híbrida deben archivarse y supervisarse detenidamente como un sistema de nivel 0, dadas las consecuencias en el área expuesta. Esto incluye:
Servidores de AD FS y proxy de aplicación web
Microsoft Entra Connect
Agentes de Application Proxy
Agentes de escritura diferida de contraseñas
Máquinas de puertas de enlace de protección de contraseñas
NPS que tiene la extensión RADIUS de autenticación multifactor Microsoft Entra
Microsoft Entra Connect Health debe implementarse para supervisar la sincronización de las identidades y la federación (cuando corresponda) para todos los entornos.
Retención de almacenamiento de registros: todos los entornos deben tener una estrategia de retención de almacenamiento de registros, diseño e implementación coherentes para facilitar un conjunto de herramientas coherente (por ejemplo, sistemas SIEM como Azure Sentinel), las consultas comunes, la investigación y los cuadernos de estrategias forenses. Se puede usar Azure Policy para configurar las opciones de diagnóstico.
Supervisión y revisión de registros: las tareas operativas en torno a la supervisión de las identidades deben ser coherentes y tener propietarios en cada entorno. Como se ha descrito anteriormente, intente consolidar estas responsabilidades en todos los entornos en la medida en que lo permitan los requisitos de cumplimiento normativo y aislamiento.
Los escenarios siguientes deben supervisarse e investigarse explícitamente:
Actividad sospechosa: todos los eventos de riesgo de Microsoft Entra deben supervisarse en busca de actividad sospechosa. Defina las ubicaciones con nombre de la red para evitar detecciones ruidosas en las señales basadas en la ubicación. Microsoft Entra ID Protection se integra de forma nativa con Azure Security Center. Se recomienda que cualquier investigación de detección de riesgos incluya todos los entornos a los que se aprovisiona la identidad (por ejemplo, si una identidad humana tiene una detección de riesgos activa en el inquilino corporativo, el equipo que opera el inquilino orientado al cliente también debe investigar la actividad de la cuenta correspondiente en ese entorno).
Alertas del análisis de comportamiento de entidades de usuario (UEBA): UEBA debe usarse para obtener información detallada basada en la detección de anomalías. Microsoft 365 Defender for Cloud Apps de Microsoft proporciona UEBA en la nube. Los clientes pueden integrar UEBA local desde Microsoft 365 Defender for Identity de Microsoft. MCAS lee señales de Protección de id. de Microsoft Entra.
Actividad de las cuentas de acceso de emergencia: se debe supervisar cualquier acceso que use cuentas de acceso de emergencia y se deben crear alertas para las investigaciones. Esta supervisión debe incluir lo siguiente:
Inicios de sesión
Administración de credenciales
Todas las actualizaciones de pertenencias a grupos
Asignaciones de aplicaciones
Cuentas de administración de facturación: dada la confidencialidad de las cuentas con roles de administración de facturación en Azure EA o MCA, y sus altos privilegios, se recomienda supervisar y alertar sobre lo siguiente:
Los intentos de inicio de sesión por parte de cuentas con roles de facturación.
Cualquier intento de autenticación en aplicaciones distintas de EA Portal.
Cualquier intento de autenticarse en aplicaciones distintas de Azure Resource Management si usa cuentas dedicadas para las tareas de facturación de MCA.
La asignación a recursos de Azure mediante cuentas dedicadas para las tareas de facturación de MCA.
Actividad de roles con privilegios: configure y revise las alertas de seguridad generadas por Microsoft Entra PIM. Si el bloqueo de las asignaciones directas de RBAC no es totalmente aplicable con controles técnicos (por ejemplo, el rol propietario debe concederse a los equipos de productos para realizar su trabajo), supervise la asignación directa de los roles con privilegios fuera de PIM mediante la generación de alertas siempre que un usuario se asigne directamente para acceder a la suscripción con RBAC de Azure.
Asignaciones de roles clásicas: las organizaciones deben usar la infraestructura de roles RBAC de Azure moderna en lugar de los roles clásicos. Como resultado, se deben supervisar los siguientes eventos:
- Asignación a roles clásicos en el nivel de suscripción
Configuraciones para todo el inquilino: cualquier servicio de configuración para todo el inquilino debe generar alertas en el sistema.
Actualización de dominios personalizados
Actualización de la personalización de marca
Microsoft Entra lista de permitidos o bloqueados de B2B
Proveedores de identidades permitidos de Microsoft Entra B2B (IDP de SAML mediante federación directa o inicios de sesión sociales)
Cambios en las directivas de acceso condicional
Objetos de aplicación y de entidad de servicio
Nuevas aplicaciones o entidades de servicio que podrían requerir directivas de acceso condicional
Actividad de consentimiento de la aplicación
Actividad del grupo de administración: se deben supervisar los siguientes aspectos de identidad de los grupos de administración:
Asignaciones de roles RBAC en MG
Directivas de Azure aplicadas en MG
Suscripciones movidas entre MG
Cualquier cambio en las directivas de seguridad en el MG raíz
Roles personalizados
Actualizaciones de las definiciones de roles personalizados
Nuevos roles personalizados creados
Reglas personalizadas de división de tareas: si las organizaciones han establecido reglas de división de tareas, use paquetes de acceso incompatibles de Administración de derechos de Microsoft Entra para aplicar la división de tareas y cree alertas o configure revisiones periódicas para detectar infracciones por parte de los administradores.
Otras consideraciones de supervisión: las suscripciones de Azure que contienen recursos usados para la administración de registros deben considerarse como infraestructura crítica (nivel 0) y bloquearse en el equipo de operaciones de seguridad del entorno correspondiente. Considere la posibilidad de usar herramientas como Azure Policy para aplicar controles adicionales a estas suscripciones.
Herramientas operativas
Consideraciones de diseño de herramientas entre entornos:
Siempre que sea posible, las herramientas operativas que se usarán en varios inquilinos deben diseñarse para ejecutarse como una aplicación multiinquilino de Microsoft Entra y así evitar la reimplementación de varias instancias en cada inquilino y problemas de eficacia operativa. La implementación debe incluir lógica de autorización para garantizar que se conserve el aislamiento entre los usuarios y los datos.
Agregue alertas y detecciones para supervisar cualquier automatización entre entornos (por ejemplo, el aprovisionamiento de identidades) y los límites de umbral para las notificaciones de error. Por ejemplo, puede que desee una alerta si el desaprovisionamiento de cuentas de usuario alcanza un nivel específico, ya que puede indicar un fallo u error operativo de amplio efecto.
Cualquier automatización que organice las tareas entre entornos debe funcionar como sistema con privilegios elevados. Este sistema debe estar alojado en el entorno de seguridad mayor y extraer los datos de orígenes externos si se requieren de otros entornos. Es necesario aplicar la validación de datos y los umbrales para mantener la integridad del sistema. Una tarea común entre entornos es la administración del ciclo de vida de identidades para quitar la identidad de todos los entornos de un empleado cuyo contrato haya terminado.
Herramientas de administración de servicios de TI: las organizaciones que usan sistemas de administración de servicios de TI (ITSM), como ServiceNow, deben configurar la activación de roles de Microsoft Entra PIM para solicitar un número de incidencia para los fines de activación.
De forma similar, Azure Monitor se puede integrar con sistemas ITSM mediante el Conector de Administración de servicios de TI.
Prácticas operativas: minimice las actividades operativas que requieren acceso directo al entorno de las identidades humanas. En su lugar, puede modelarlas con Azure Pipelines, que ejecuta operaciones comunes (por ejemplo, agregar capacidad a una solución PaaS, ejecutar diagnósticos, etc.) y modela el acceso directo a las interfaces de Azure Resource Manager para escenarios de "emergencia".
Desafíos operativos
La actividad de la supervisión de la entidad de servicio está limitada en algunos escenarios.
Las alertas de Microsoft Entra PIM no tienen API. Esto se mitiga con una revisión periódica de esas alertas de PIM.
Azure EA Portal no proporciona funcionalidades de supervisión. Esto se mitiga con cuentas de administración dedicadas y la supervisión de la actividad de la cuenta.
MCA no proporciona registros de auditoría para las tareas de facturación. Esto se mitiga con cuentas de administración dedicadas y la supervisión de la actividad de la cuenta.
Algunos servicios de Azure necesarios para operar el entorno deben volver a implementarse y configurarse en los entornos, ya que no pueden ser multiinquilino ni pertenecer a varias nubes.
No hay ninguna cobertura completa de API en Microsoft Online Services para lograr completamente la infraestructura como código. Esto se mitiga usando las API tanto como sea posible y, para el resto, portales. Esta iniciativa de código abierto le ayudará a determinar un enfoque que podría funcionar para su entorno.
No hay ninguna funcionalidad para detectar mediante programación inquilinos de recursos con acceso delegado de suscripción a identidades en un inquilino de administración. Por ejemplo, si una dirección de correo electrónico habilitó un grupo de seguridad en el inquilino contoso.com para administrar suscripciones en el inquilino fabrikam.com, los administradores de contoso.com no tienen una API para detectar que esta delegación tuvo lugar.
La supervisión específica de la actividad de la cuenta (por ejemplo, cuenta de emergencia, cuenta de administración de facturación) no se proporciona de forma predeterminada. Esto se mitiga si los clientes crean sus propias reglas de alerta.
La supervisión de la configuración para todo el inquilino no se proporciona de forma predeterminada. Esto se mitiga si los clientes crean sus propias reglas de alerta.
Pasos siguientes
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente las Cuestiones de GitHub como mecanismo de retroalimentación para el contenido y lo sustituiremos por un nuevo sistema de retroalimentación. Para más información, consulta: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de