Para identidad y más allá: un punto de vista de un arquitecto

En este artículo, Alex Shteynberg,arquitecto técnico principal de Microsoft, analiza las estrategias de diseño principales para las organizaciones empresariales que adoptan Microsoft 365 y otros servicios en la nube de Microsoft.

Acerca del autor

Soy arquitecto técnico principal en el Centro de tecnología de Microsoft de NuevaYork. Trabajo principalmente con clientes grandes y requisitos complejos. Mi punto de vista y opiniones se basan en estas interacciones y puede que no se apliquen a todas las situaciones. Sin embargo, en mi experiencia, si podemos ayudar a los clientes con los desafíos más complejos, podemos ayudar a todos los clientes.

Normalmente trabajo con más de 100 clientes cada año. Aunque cada organización tiene características únicas, es interesante ver tendencias y aspectos comunes. Por ejemplo, una tendencia es el interés entre sectores para muchos clientes. Después de todo, una sucursal bancaria también puede ser una cafetería y un centro de la comunidad.

En mi rol, me enfoque en ayudar a los clientes a llegar a la mejor solución técnica para abordar su conjunto único de objetivos empresariales. Oficialmente, me foco en Identidad, Seguridad, Privacidad y Cumplimiento. Me encanta el hecho de que estos toquen todo lo que hacemos. Me da la oportunidad de participar en la mayoría de los proyectos. Esto me mantiene bastante ocupado y disfrutando de este rol.

Vivo en la ciudad de Nueva York (¡la mejor!) y realmente me gusta la diversidad de su cultura, comida y personas (no tráfico). Me encanta viajar cuando puedo y espero ver la mayor parte del mundo en mi vida. Actualmente estoy investigando un viaje a África para aprender sobre la vida silvestre.

Principios de guía

• Simple suele ser mejor: puedes hacer (casi) cualquier cosa con tecnología, pero no significa que debas hacerlo. Especialmente en el espacio de seguridad, muchos clientes sobreingeniería soluciones. Me gusta este vídeo de la conferencia Stripe de Google para destacar este punto.
• Personas, proceso, tecnología: diseño para que las personas mejoren el proceso, no primero la tecnología. No hay soluciones "perfectas". Debemos equilibrar varios factores de riesgo y las decisiones serán diferentes para cada empresa. Demasiados clientes diseñan un enfoque que sus usuarios más adelante evitan.
• Céntrate en "por qué" primero y "cómo" más adelante: Sé el molesto niño de 7 años con un millón de preguntas. No podemos llegar a la respuesta correcta si no conocemos las preguntas correctas que hacer. Muchos clientes asumen cómo deben funcionar las cosas en lugar de definir el problema empresarial. Siempre hay varias rutas de acceso que se pueden tomar.
• Larga cola de procedimientos recomendados pasados: reconocer que los procedimientos recomendados están cambiando a velocidad de luz. Si ha mirado el Azure AD hace más de tres meses, es probable que esté des actualizado. Todo aquí está sujeto a cambios después de la publicación. La opción "Mejor" hoy puede no ser la misma de seis meses a partir de ahora.

Conceptos de línea base

No omita esta sección. A menudo encuentro que debo dar un paso atrás en estos temas, incluso para los clientes que han estado usando servicios en la nube durante años. Lamentablemente, el idioma no es una herramienta precisa. A menudo usamos la misma palabra para significar conceptos diferentes o palabras diferentes para significar el mismo concepto. A menudo uso este diagrama siguiente para establecer alguna terminología de línea base y "modelo de jerarquía".

Cuando aprendes a nado, es mejor empezar en la piscina y no en medio del océano. No intento ser técnicamente preciso con este diagrama. Es un modelo para analizar algunos conceptos básicos.

En el diagrama:

• Tenant = una instancia de Azure AD. Está en la "parte superior" de una jerarquía o en el nivel 1 del diagrama. Podemos considerar que este es el"límite"donde ocurre todo lo demás (Azure AD B2B aparte). Todos los servicios en la nube de microsoft enterprise forman parte de uno de estos inquilinos. Los servicios de consumidor son independientes. "Inquilino" aparece en la documentación Office 365 inquilino, inquilino de Azure, inquilino de WVD, y así sucesivamente. A menudo encuentro que estas variaciones causan confusión para los clientes.
• Servicios/suscripciones, nivel 2 en el diagrama, pertenecen a un único espacio empresarial. La mayoría de los servicios SaaS son 1:1 y no se pueden mover sin la migración. Azure es diferente, puede mover la facturación o una suscripción a otro inquilino. Hay muchos clientes que necesitan mover suscripciones de Azure. Esto tiene varias implicaciones. Los objetos que existen fuera de la suscripción no se mueven (por ejemplo, control de acceso basado en roles o RBAC de Azure y objetos Azure AD, incluidos grupos, aplicaciones, directivas, entre otros). Además, algunos servicios (como Azure Key Vault, Data Bricks, entre otros). No migre los servicios sin una buena necesidad empresarial. Algunos scripts que pueden ser útiles para la migración se comparten en GitHub.
• Un servicio determinado suele tener algún tipo de límite "subnivel" o nivel 3 (L3). Esto es útil para comprender la segregación de la seguridad, las directivas, el gobierno, y así sucesivamente. Desafortunadamente, no hay ningún nombre uniforme que conozca. Algunos nombres de ejemplo para L3 son: Suscripción de Azure = recurso; Dynamics 365 CE = instancia; Power BI = área de trabajo; Power Apps = entorno,y así sucesivamente.
• El nivel 4 es donde viven los datos reales. Este "plano de datos" es un tema complejo. Algunos servicios usan Azure AD para RBAC, otros no. Lo analizaré un poco cuando lleguemos a temas de delegación.

Algunos conceptos adicionales que encuentro que muchos clientes (y empleados de Microsoft) están confundidos o tienen preguntas sobre:

• Cualquier persona puede crear muchos inquilinos sin costo. No es necesario que se aprovisione un servicio dentro de él. Tengo decenas. Cada nombre de inquilino es único en el servicio en la nube mundial de Microsoft (es decir, no hay dos inquilinos que puedan tener el mismo nombre). Todos tienen el formato de TenantName.onmicrosoft.com. También hay procesos que crean inquilinos automáticamente (inquilinos no administrados). Por ejemplo, esto puede ocurrir cuando un usuario se inscribe en un servicio de empresa con un dominio de correo electrónico que no existe en ningún otro espacio empresarial.
• En un inquilino administrado, muchos dominios DNS se pueden registrar en él. Esto no cambia el nombre del inquilino original. Actualmente no hay una forma fácil de cambiar el nombre de un inquilino (aparte de la migración). Aunque el nombre del inquilino no es técnicamente crítico en estos días, algunos pueden encontrar que esto sea limitante.
• Debe reservar un nombre de inquilino para su organización incluso si aún no está planeando implementar ningún servicio. De lo contrario, alguien puede quitarlo y no hay ningún proceso sencillo para recuperarlo (mismo problema que los nombres DNS). Oigo esto con demasiada frecuencia por parte de los clientes. El nombre del inquilino también debe ser un tema de debate.
• Si es propietario de espacios de nombres DNS, debe agregarlos todos a los inquilinos. De lo contrario, se podría crear un inquilino no administrado con este nombre, lo que, a continuación, provocaría una interrupción para que se administrara.
• El espacio de nombres DNS (como contoso.com) puede pertenecer a un único inquilino. Esto tiene implicaciones para varios escenarios (por ejemplo, compartir un dominio de correo electrónico durante una fusión o adquisición, y así sucesivamente). Hay una forma de registrar un sub DNS (como div.contoso.com) en un inquilino diferente, pero eso debe evitarse. Al registrar un nombre de dominio de nivel superior, se supone que todos los subdominios pertenecen al mismo inquilino. En escenarios multiinquilino (vea a continuación) normalmente se recomienda usar otro nombre de dominio de nivel superior (como contoso.ch o ch-contoso.com).
• Quién ¿debe ser "propietario" de un inquilino? A menudo veo clientes que no saben quién es propietario actualmente de su inquilino. Esta es una gran marca roja. Llame al soporte técnico de Microsoft lo antes posible. Igual de problemático es cuando un propietario del servicio (a menudo un administrador de Exchange) se designa para administrar un espacio empresarial. El espacio empresarial contendrá todos los servicios que desee en el futuro. El propietario del espacio empresarial debe ser un grupo que pueda tomar decisiones para habilitar todos los servicios en la nube de una organización. Otro problema es cuando se pide a un grupo de propietarios del espacio empresarial que administre todos los servicios. Esto no escala para organizaciones grandes.
• No hay ningún concepto de inquilino sub/super. Por alguna razón, este mito se repite a sí mismo. Esto también se aplica Azure AD inquilinos B2C. Oigo demasiadas veces: "Mi entorno B2C está en mi inquilino XYZ" o "¿Cómo puedo mover mi inquilino de Azure a mi espacio empresarial Office 365?"
• Este documento se centra principalmente en la nube comercial mundial, ya que esto es lo que usan la mayoría de los clientes. A veces resulta útil conocer las nubes soberanas. Las nubes soberanas tienen implicaciones adicionales para analizar cuáles están fuera del ámbito de esta discusión.

Temas de identidad de línea base

Hay mucha documentación sobre la plataforma de identidad de Microsoft: Azure Active Directory (Azure AD). Para los que están empezando, a menudo resulta abrumador. Incluso después de conocerlo, mantenerse al día con la innovación y el cambio constantes puede ser un desafío. En las interacciones de mis clientes, a menudo me encuentro como "traductor" entre los objetivos empresariales y los enfoques "Bueno, Mejor, Mejor" para abordar estos (y las "notas de precipicio" humanas para estos temas). Rara vez hay una respuesta perfecta y la decisión "correcta" es un equilibrio de varios factores de riesgo. A continuación se muestran algunas de las preguntas y áreas de confusión comunes que suelo tratar con los clientes.

Aprovisionamiento

Azure AD no resuelve la falta de gobierno en el mundo de la identidad. El gobierno de identidades debe ser un elemento crítico independiente de las decisiones en la nube. Los requisitos de gobierno cambian con el tiempo, por lo que es un programa y no una herramienta.

Azure AD Conectar vs. Microsoft Identity Manager (MIM) frente a otra cosa (de terceros o personalizado)? Ahorre mucho dolor de cabeza ahora y en el futuro y vaya con Azure AD Conectar. Hay todo tipo de smarts en esta herramienta para abordar configuraciones de clientes peculiares e innovaciones continuas.

Algunos casos perimetrales que pueden conducir hacia una arquitectura más compleja:

• Tengo varios bosques de AD sin conectividad de red entre estos. Hay una nueva opción denominada Aprovisionamiento en la nube.
• No tengo Active Directory ni quiero instalarlo. Azure AD Conectar puede configurarse para que se sincronice desde LDAP (es posible que se requiera un partner).
• Necesito aprovisionar los mismos objetos a varios inquilinos. No se admite técnicamente, pero depende de la definición de "igual".

¿Debo personalizar las reglas de sincronización predeterminadas(objetos de filtro, atributos decambio, identificador de iniciode sesión alternativo, y así sucesivamente)? Evitarlo. Una plataforma de identidad es tan valiosa como los servicios que la usan. Aunque puede hacer todo tipo de configuraciones de nuez, para responder a esta pregunta necesita ver el impacto en las aplicaciones. Si filtra objetos habilitados para correo, la GAL de los servicios en línea estará incompleta; si la aplicación se basa en atributos específicos, el filtrado de estos tendrá un impacto impredecible; y así sucesivamente. No es una decisión de equipo de identidad.

Xyz SaaS admite el aprovisionamiento just-in-time (JIT), ¿por qué me necesita sincronizar? Vea arriba. Muchas aplicaciones necesitan información de "perfil" para la funcionalidad. No puede tener una GAL si todos los objetos habilitados para correo no están disponibles. Lo mismo se aplica al aprovisionamiento de usuarios en aplicaciones integradas con Azure AD.

Autenticación

Sincronización de hash de contraseña (PHS) frente a autenticación de paso a través (PTA) frente a federación.

Por lo general, hay un debate apasionado en torno a la federación. Lo más sencillo suele ser mejor y, por lo tanto, usar PHS a menos que tenga una buena razón para no hacerlo. También es posible configurar distintos métodos de autenticación para distintos dominios DNS en el mismo inquilino.

Algunos clientes habilitan la federación + PHS principalmente para:

• Una opción para volver a (para la recuperación ante desastres) si el servicio de federación no está disponible.
• Capacidades adicionales (por ejemplo: Azure AD DS) y servicios de seguridad (por ejemplo: credenciales filtradas)
• Compatibilidad con servicios de Azure que no comprenden la autenticación federada (por ejemplo, Azure Files).

A menudo, paso a los clientes por el flujo de autenticación de cliente para aclarar algunos conceptos erróneos. El resultado es similar a la imagen siguiente, que no es tan bueno como el proceso interactivo de llegar allí.

Este tipo de dibujo de pizarra ilustra dónde se aplican directivas de seguridad dentro del flujo de una solicitud de autenticación. En este ejemplo, las directivas aplicadas a través del servicio de federación de Active Directory (AD FS) se aplican a la primera solicitud de servicio, pero no a las solicitudes de servicio posteriores. Este es al menos un motivo para mover los controles de seguridad a la nube tanto como sea posible.

Llevamos buscando el sueño del inicio de sesión único (SSO) durante el tiempo que pueda recordar. Algunos clientes creen que pueden lograrlo eligiendo el proveedor de federación "correcto" (STS). Azure AD puede ayudar significativamente a habilitar las funcionalidades de SSO, pero ningún STS es mágico. Hay demasiados métodos de autenticación "heredados" que todavía se usan para aplicaciones críticas. La extensión Azure AD con soluciones de partners puede solucionar muchos de estos escenarios. SSO es una estrategia y un recorrido. No se puede llegar sin avanzar hacia los estándares de las aplicaciones. Relacionado con este tema es un viaje a la autenticación sin contraseña, que tampoco tiene una respuesta mágica.

La autenticación multifactor (MFA) es esencial hoy endía (aquí para obtener más información). Agrega análisis de comportamiento de usuario y tienes una solución que evita los ataques cibernéticos más comunes. Incluso los servicios de consumidores se mueven para requerir MFA. Sin embargo, aún me encuentro con muchos clientes que no desean pasar a los enfoques de autenticación modernos. El argumento más importante que oigo es que afectará a los usuarios y las aplicaciones heredadas. A veces, una buena idea puede ayudar a los clientes a avanzar: Exchange Online cambios anunciados. Ahora hay Azure AD informes disponibles para ayudar a los clientes con esta transición.

Authorization

Por Wikipedia,"autorizar" es definir una directiva de acceso. Muchas personas lo ven como la capacidad de definir controles de acceso a un objeto (archivo, servicio, entre otros). En el mundo actual de las amenazas cibernéticas, este concepto está evolucionando rápidamente a una directiva dinámica que puede reaccionar a varios vectores de amenazas y ajustar rápidamente los controles de acceso en respuesta a estas. Por ejemplo, si tengo acceso a mi cuenta bancaria desde una ubicación inusual, recibiré pasos de confirmación adicionales. Para abordar esto, debemos considerar no solo la directiva en sí, sino el ecosistema de metodologías de detección de amenazas y correlación de señales.

El motor de directivas de Azure AD se implementa mediante directivas de acceso condicional. Este sistema depende de la información de una variedad de otros sistemas de detección de amenazas para tomar decisiones dinámicas. Una vista sencilla sería algo parecido a la siguiente ilustración:

La combinación de todas estas señales permite directivas dinámicas como estas:

• Si se detecta una amenaza en el dispositivo, el acceso a los datos solo se reducirá a la web sin la capacidad de descarga.
• Si está descargando un volumen de datos inusualmente alto, todo lo que descargue se cifrará y restringirá.
• Si accedes a un servicio desde un dispositivo no administrado, se te bloquearán los datos altamente confidenciales, pero se te permitirá acceder a datos no restringidos sin la posibilidad de copiarlo en otra ubicación.

Si está de acuerdo con esta definición expandida de autorización, debe implementar soluciones adicionales. Las soluciones que implemente dependerán de la dinámica que desee que sea la directiva y de las amenazas que desee priorizar. Algunos ejemplos de estos sistemas son:

• Azure AD Identity Protection
• Microsoft Defender for Identity
• Microsoft Defender para punto de conexión
• Microsoft Defender para Office 365
• Microsoft Defender para aplicaciones en la nube (Defender para aplicaciones en la nube)
• Microsoft 365 Defender
• Microsoft Intune
• Microsoft Information Protection (MIP)
• Microsoft Sentinel

Por supuesto, además de Azure AD, varios servicios y aplicaciones tienen sus propios modelos de autorización específicos. Algunos de estos temas se analizan más adelante en la sección de delegación.

Auditoría

Azure AD capacidades detalladas de auditoría e informes. Sin embargo, esta no suele ser la única fuente de información necesaria para tomar decisiones de seguridad. Vea más información al respecto en la sección de delegación.

No hay ninguna Exchange

No entres en pánico. Esto no significa que Exchange esté en desuso (o SharePoint, y así sucesivamente). Sigue siendo un servicio básico. Lo que quiero decir es que, desde hace bastante tiempo, los proveedores de tecnología han estado transfiriendo experiencias de usuario (UX) para abarcar componentes de varios servicios. En Microsoft 365, un ejemplo sencillo es "datosadjuntos modernos " donde los datos adjuntos al correo electrónico se almacenan en SharePoint Online o OneDrive para la Empresa.

Si observa el Outlook cliente, puede ver muchos servicios que están "conectados" como parte de esta experiencia, no solo Exchange. Esto incluye Azure AD, Búsqueda de Microsoft, Aplicaciones, Perfil, cumplimiento y Office 365 grupos.

Obtenga información Microsoft Fluid Framework para obtener una vista previa de las próximas funcionalidades. En vista previa ahora, puedo leer y responder a Teams conversaciones directamente en Outlook. De hecho, el Teams cliente es uno de los ejemplos más destacados de esta estrategia.

En general, es cada vez más difícil dibujar una línea clara entre Office 365 y otros servicios en las nubes de Microsoft. Lo veo como una gran ventaja para los clientes, ya que pueden beneficiarse de la innovación total en todo lo que hacemos, incluso si usan un componente. Bastante interesante y tiene implicaciones de gran alcance para muchos clientes.

Hoy en día, me parece que muchos grupos de IT de clientes están estructurados en torno a "productos". Es lógico para un mundo local, ya que necesita un experto para cada producto específico. Sin embargo, estoy totalmente contento de no tener que depurar una base de datos de Active Directory o Exchange a medida que estos servicios se han movido a la nube. La automatización (que es el tipo de nube) quita ciertos trabajos manuales repetitivos (mira lo que sucedió con las fábricas). Sin embargo, se reemplazan por requisitos más complejos para comprender la interacción entre servicios, el impacto, las necesidades empresariales, etc. Si está dispuesto a aprender,hay grandes oportunidades habilitadas por la transformación en la nube. Antes de saltar a la tecnología, a menudo conversa con los clientes sobre cómo administrar los cambios en las habilidades de TI y las estructuras de equipo.

Para todos los SharePoint y desarrolladores, por favor deje de preguntar "¿Cómo puedo hacer XYZ en SharePoint en línea?" Use Power Automate (o Flow) para el flujo de trabajo, es una plataforma mucho más eficaz. Use Azure Bot Framework para crear una experiencia de usuario mejor para la lista de elementos de 500 K. Comience a usar Microsoft Graph en lugar de CSOM. Microsoft Teams incluye SharePoint pero también un mundo más. Hay muchos otros ejemplos que puedo enumerar. Hay un vasto y maravilloso universo por ahí. Abra la puerta y comience a explorar.

El otro impacto común está en el área de cumplimiento. Este enfoque entre servicios parece confundir completamente muchas directivas de cumplimiento. Sigo viendo a las organizaciones que den el estado: "Necesito realizar un registro en diario de todas las comunicaciones de correo electrónico a un sistema de exhibición de documentos electrónicos". ¿Qué significa esto realmente cuando el correo electrónico ya no es solo correo electrónico, sino una ventana a otros servicios? Office 365 un enfoque completo para el cumplimiento,pero cambiar personas y procesos suele ser mucho más difícil que la tecnología.

Hay muchas otras personas y implicaciones del proceso. En mi opinión, este es un área crítica y poco discutida. Quizás más en otro artículo.

Opciones de estructura de inquilinos

Inquilino único frente a multiinquilino

En general, la mayoría de los clientes deben tener solo un inquilino de producción. Hay muchas razones por las que varios inquilinos son desafiantes (darle una Bingbúsqueda ) o leer esta whitepaper. Al mismo tiempo, muchos clientes empresariales con los que trabajo tienen otro inquilino (pequeño) para aprendizaje, pruebas y experimentación de TI. El acceso de Azure entre inquilinos es más fácil con Azure Lighthouse. Office 365 y muchos otros servicios SaaS tienen límites para escenarios entre inquilinos. Hay mucho que tener en cuenta en Azure AD escenarios B2B.

Muchos clientes terminan con varios inquilinos de producción después de una fusión y adquisición (M&A) y desean consolidarse. Hoy en día eso no es sencillo y requeriría Servicios de consultoría de Microsoft (MCS) o un partner más software de terceros. Hay trabajo de ingeniería en curso para abordar diversos escenarios con clientes multiinquilino en el futuro.

Algunos clientes eligen ir con más de un inquilino. Esta debe ser una decisión muy cuidadosa y casi siempre basada en motivos de negocio. Algunos ejemplos son los siguientes:

• Una estructura de empresa de tipo de retención en la que no es necesaria una colaboración fácil entre diferentes entidades y hay necesidades administrativas y de aislamiento muy fuertes.
• Después de una adquisición, se toma una decisión empresarial para mantener dos entidades separadas.
• Simulación del entorno de un cliente que no cambia el entorno de producción del cliente.
• Desarrollo de software para clientes.

En estos escenarios multiinquilino, los clientes suelen querer mantener la misma configuración en todos los inquilinos o informar sobre los cambios y derivas de configuración. Esto suele significar pasar de los cambios manuales a la configuración como código. El soporte técnico de Microsoft Premiere ofrece un taller para este tipo de requisitos basados en esta IP pública: https://Microsoft365dsc.com .

Multi-Geo

Para Multi-Geo o no para Multi-Geo, esa es la pregunta. Con Office 365 Multi-Geo, puede aprovisionar y almacenar datos en reposo en las ubicaciones geográficas que haya elegido para cumplir los requisitos de residencia de datos. Hay muchos conceptos erróneos sobre esta funcionalidad. Tenga en cuenta lo siguiente:

• No proporciona ventajas de rendimiento. Podría empeorar el rendimiento si el diseño de red no es correcto. Obtener dispositivos "cercanos" a la red de Microsoft, no necesariamente a los datos.
• No es una solución para el cumplimiento del RGPD. El RGPD no se centra en la soberanía de los datos ni en las ubicaciones de almacenamiento. Existen otros marcos de cumplimiento para ello.
• No resuelve la delegación de administración (vea a continuación) ni las barreras de información.
• No es lo mismo que multiinquilino y requiere flujos de trabajo de aprovisionamiento de usuarios adicionales.
• No mueve el espacio empresarial (su Azure AD) a otra geografía.

Delegación de administración

En la mayoría de las organizaciones grandes, la separación de funciones y el control de acceso basado en roles (RBAC) es una realidad necesaria. Voy a pedirme disculpas antes de tiempo. Esto no es tan sencillo como algunos clientes quieren que sea. Los requisitos de cliente, legales, de cumplimiento y otros son diferentes y, a veces, en conflicto en todo el mundo. La simplicidad y la flexibilidad suelen estar en lados opuestos entre sí. No me mal conste, podemos hacer un mejor trabajo en esto. Ha habido (y habrá) mejoras significativas con el tiempo. Visite su Centro de tecnología de Microsoft local para averiguar el modelo que se ajusta a sus requisitos empresariales sin leer documentos de 379230. Aquí, me centraré en lo que debería pensar y no en por qué es así. A continuación se muestran cinco áreas diferentes para planear y algunas de las preguntas comunes que he encontrado.

Azure AD y Microsoft 365 de administración

Hay una larga y creciente lista de roles integrados. Cada función consta de una lista de permisos de función agrupados para permitir que se realicen acciones específicas. Puede ver estos permisos en la pestaña "Descripción" dentro de cada rol. Como alternativa, puede ver una versión más legible de estos en el Centro de Administración de Microsoft 365 humanos. Las definiciones de roles integrados no se pueden modificar. Por lo general, los agrupa en tres categorías:

• Administrador global: este rol "todo eficaz" debe estar altamente protegido como lo haría en otros sistemas. Entre las recomendaciones típicas se incluyen: sin asignación permanente y Azure AD Privileged Identity Management (PIM); autenticación segura, y así sucesivamente. Es interesante que este rol no le dé acceso a todo de forma predeterminada. Por lo general, veo confusión sobre el acceso de cumplimiento y el acceso de Azure, que se describe más adelante. Sin embargo, este rol siempre puede asignar acceso a otros servicios en el espacio empresarial.
• Administradores de servicios específicos: algunos servicios (Exchange, SharePoint, Power BI, y así sucesivamente) consumen roles de administración de alto nivel de Azure AD. Esto no es coherente en todos los servicios y hay más roles específicos del servicio que se debate más adelante.
• Funcional: hay una larga (y creciente) lista de roles centrados en operaciones específicas (invitado invitado, y así sucesivamente). Periódicamente, se agregan más de estos en función de las necesidades del cliente.

No es posible delegar todo (aunque la diferencia está disminuyendo), lo que significa que el rol de administrador global tendría que usarse a veces. La configuración como código y la automatización deben considerarse en lugar de la pertenencia de personas a este rol.

Nota: el Centro de administración de Microsoft 365 tiene una interfaz más fácil de usar, pero tiene un subconjunto de capacidades en comparación con la experiencia Azure AD administrador. Ambos portales usan los mismos Azure AD, por lo que los cambios se producen en el mismo lugar. Sugerencia: si desea una interfaz de usuario de administrador centrada en la administración de identidades sin todo el desorden de Azure, use https://aad.portal.azure.com .

¿Cuál es el nombre? No hagas suposiciones a partir del nombre del rol. El idioma no es una herramienta muy precisa. El objetivo debe ser definir las operaciones que deben delegarse antes de ver qué roles son necesarios. Agregar a alguien al rol "Lector de seguridad" no hace que vean la configuración de seguridad en todo.

La capacidad de crear roles personalizados es una pregunta común. Esto es limitado en Azure AD actual (vea a continuación), pero crecerá en capacidades con el tiempo. Las veo como aplicables a las funciones de Azure AD y no pueden abarcar "abajo" el modelo de jerarquía (se ha mencionado anteriormente). Siempre que trato con "personalizado", tiendo a volver a mi director de "simple es mejor".

Otra cuestión común es la capacidad de ámbito de roles en un subconjunto de un directorio. Un ejemplo es algo así como "Administrador del departamento de soporte técnico solo para usuarios de la UE". Las unidades administrativas (AU) están diseñadas para solucionar este problema. Al igual que antes, creo que son aplicables a las funciones de Azure AD y puede que no se abarquen "hacia abajo". Por supuesto, ciertos roles no tienen sentido en el ámbito (administradores globales, administradores de servicio, entre otros).

Hoy en día, todos estos roles requieren pertenencia directa (o asignación dinámica si usa Azure AD PIM). Esto significa que los clientes deben administrarlos directamente en Azure AD y no pueden basarse en una pertenencia a un grupo de seguridad. No soy un fan de crear scripts para administrarlos, ya que tendría que ejecutarse con derechos elevados. Por lo general, recomiendo la integración de la API con sistemas de procesos como ServiceNow o el uso de herramientas de gobierno de partners como Saviynt. Hay trabajo de ingeniería que se va a solucionar con el tiempo.

He mencionado Azure AD PIM varias veces. Hay una solución Microsoft Identity Manager (MIM) privileged Access Management (PAM) para controles locales. También es posible que desee ver Privileged Access Workstations (PAWs) y Azure AD Identity Governance. También hay varias herramientas de terceros, que pueden habilitar la elevación de roles just-in-time, just-enough y dynamic role elevation. Esto suele formar parte de una discusión más amplia para proteger un entorno.

A veces, los escenarios llaman para agregar un usuario externo a un rol (vea la sección multiinquilino, arriba). Esto funciona bien. Azure AD B2B es otro tema grande y divertido para que los clientes puedan recorrerlo, tal vez en otro artículo.

Centro de seguridad y cumplimiento (SCC)

Los permisos del Centro de Office 365 seguridad & cumplimiento son una colección de "grupos de roles", que son independientes y distintos de Azure AD roles. Esto puede resultar confuso porque algunos de estos grupos de roles tienen el mismo nombre que Azure AD (por ejemplo, Lector de seguridad), pero pueden tener una pertenencia diferente. Prefero el uso de Azure AD roles. Cada grupo de roles consta de uno o más "roles" (vea lo que quiero decir acerca de la nueva utilización de la misma palabra)) y tiene miembros de Azure AD, que son objetos habilitados para correo electrónico. Además, puede crear un grupo de roles con el mismo nombre que un rol, que puede contener o no esa función (evite esta confusión).

En cierto sentido, se trata de una evolución del modelo Exchange de grupos de roles. Sin embargo, Exchange Online tiene su propia interfaz de administración de grupos de roles. Algunos grupos de roles de Exchange Online se bloquean y administran desde Azure AD o el Centro de cumplimiento de & de seguridad, pero otros pueden tener los mismos nombres o similares y se administran en Exchange Online (lo que se agrega a la confusión). Te recomiendo que evites usar la interfaz Exchange Online usuario a menos que necesites ámbitos para Exchange administración.

No puede crear roles personalizados. Los roles se definen mediante los servicios creados por Microsoft y crecerán a medida que se introduzcan nuevos servicios. Esto es similar en concepto a los roles definidos por las aplicaciones en Azure AD. Cuando se habilitan nuevos servicios, a menudo es necesario crear nuevos grupos de roles para conceder o delegar el acceso a estos (por ejemplo, la administración de riesgos de insider).

Estos grupos de roles también requieren pertenencia directa y no pueden contener Azure AD grupos. Desafortunadamente, actualmente estos grupos de roles no son compatibles con Azure AD PIM. Al igual Azure AD roles, suelo recomendar la administración de estos a través de API o un producto de gobierno de partners como Saviynt u otros.

Los roles & centro de cumplimiento de seguridad abarcan Microsoft 365 y no puede establecer el ámbito de estos grupos de roles en un subconjunto del entorno (como puede hacer con las unidades administrativas en Azure AD). Muchos clientes preguntan cómo pueden subdelegarse. Por ejemplo, "crear una directiva DLP solo para los usuarios de la UE". Hoy en día, si tiene derechos sobre una función específica en el Centro de seguridad & cumplimiento, tiene derechos sobre todo lo que cubre esta función en el espacio empresarial. Sin embargo, muchas directivas tienen capacidades para dirigirse a un subconjunto del entorno (por ejemplo, "hacer que estas etiquetas estén disponibles solo para estos usuarios"). El gobierno y la comunicación adecuados son un componente clave para evitar conflictos. Algunos clientes eligen implementar un enfoque de "configuración como código" para abordar la subdelegación en el Centro de seguridad & cumplimiento. Algunos servicios específicos admiten subdelegaciones (vea a continuación).

Vale la pena señalar que los controles administrados actualmente a través del Centro de seguridad & y cumplimiento (protection.office.com) están en proceso de migrarse a dos portales de administración independientes: security.microsoft.com y compliance.microsoft.com. El cambio es la única constante.

Específico del servicio

Como se mencionó anteriormente, muchos clientes buscan lograr un modelo de delegación más detallado. Un ejemplo común: "Administrar el servicio XYZ solo para usuarios y ubicaciones de división X" (o alguna otra dimensión). La capacidad para hacerlo depende de cada servicio y no es coherente en todos los servicios y capacidades. Además, cada servicio puede tener un modelo RBAC independiente y único. En lugar de hablar de todos estos (llevará para siempre), estoy agregando vínculos relevantes para cada servicio. Esta no es una lista completa, pero le ayudará a empezar.

• Exchange Online - (/exchange/permissions-exo/permissions-exo)

• SharePoint Online: (/sharepoint/manage-site-collection-administrators)

• Microsoft Teams - (/microsoftteams/itadmin-readiness)

• Exhibición de documentos electrónicos : (.. /compliance/index.yml)

  • Filtrado de permisos : (.. /compliance/index.yml)
  • Límites de cumplimiento: (.. /compliance/set-up-compliance-boundaries.md)
  • Advanced eDiscovery - (.. /compliance/overview-ediscovery-20.md)

• Yammer - (/yammer/manage-yammer-users/manage-yammer-admins)

• Multi-geo - (.. /enterprise/add-a-sharepoint-geo-admin.md)

• Dynamics 365 – (/dynamics365/)

  Nota: este vínculo se encuentra en la raíz de la documentación. Hay varios tipos de servicios con variaciones en el modelo de administración y delegación.

• Power Platform: (/power-platform/admin/admin-documentation)

  • Power Apps - (/power-platform/admin/wp-security)

    Nota: hay varios tipos con variaciones en los modelos de administración y delegación.

  • Power Automate - (/power-automate/environments-overview-admin)

  • Power BI - (/power-bi/service-admin-governance)

    Nota: la seguridad y delegación de la plataforma de datos (Power BI es un componente) es un área compleja.

• MEM/Intune: (/mem/intune/fundamentals/role-based-access-control)

• Microsoft Defender para endpoint : (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

• Microsoft 365 Defender - (.. /security/defender/m365d-permissions.md)

• Microsoft Defender para aplicaciones en la nube : (/cloud-app-security/manage-admins)

• Stream: (/stream/assign-administrator-user-role)

• Barreras de información : (.. /compliance/information-barriers.md)

Registros de actividad

Office 365 tiene un registro de auditoría unificado. Es un registro muy detallado,pero no lea demasiado en el nombre. Puede que no contenga todo lo que desee o necesite para sus necesidades de seguridad y cumplimiento. Además, algunos clientes están realmente interesados en la auditoría avanzada.

Algunos ejemplos de Microsoft 365 a los que se accede a través de otras API son los siguientes:

• Azure AD (actividades no relacionadas con Office 365)
• Exchange de mensajes
• Sistemas threat/UEBA mencionados anteriormente (por ejemplo, Azure AD Identity Protection, Microsoft Defender para aplicaciones en la nube, Microsoft Defender para endpoint, y así sucesivamente)
• protección de la información de Microsoft
• Microsoft Defender para punto de conexión
• Microsoft Graph

Es importante identificar primero todos los orígenes de registro necesarios para un programa de seguridad y cumplimiento. Tenga en cuenta también que los distintos registros tienen diferentes límites de retención en línea.

Desde la perspectiva de delegación de administración, la mayoría Microsoft 365 registros de actividad no tienen un modelo RBAC integrado. Si tiene permiso para ver un registro, puede ver todo en él. Un ejemplo común de un requisito de cliente es: "Quiero poder consultar la actividad solo para los usuarios de la UE" (o cualquier otra dimensión). Para lograr este requisito, debemos transferir registros a otro servicio. En la nube de Microsoft, se recomienda transferirla a Microsoft Sentinel o Log Analytics.

Diagrama de alto nivel:

El diagrama anterior representa las capacidades integradas para enviar registros a Event Hub y/o Azure Storage y/o Azure Log Analytics. Todavía no todos los sistemas incluyen esta opción. Pero hay otros métodos para enviar estos registros al mismo repositorio. Por ejemplo, vea Protecting your Teams with Microsoft Sentinel.

La combinación de todos los registros en una ubicación de almacenamiento incluye ventajas adicionales, como correlaciones cruzadas, tiempos de retención personalizados, aumento con datos necesarios para admitir el modelo RBAC, y así sucesivamente. Una vez que los datos están en este sistema de almacenamiento, puede crear un panel de Power BI (u otro tipo de visualización) con un modelo RBAC adecuado.

Los registros no tienen que dirigirse a un solo lugar. También puede ser beneficioso integrar registros de Office 365 con Microsoft Defender para aplicaciones en la nube o un modelo RBAC personalizado en Power BI. Los diferentes repositorios tienen diferentes ventajas y audiencias.

Vale la pena mencionar que hay un sistema de análisis integrado muy enriquecido para seguridad, amenazas, vulnerabilidades, y así sucesivamente en un servicio denominado Microsoft 365 Defender.

Muchos clientes grandes desean transferir estos datos de registro a un sistema de terceros (por ejemplo, SIEM). Hay diferentes enfoques para esto, pero en general Azure Event Hub y Graph son buenos puntos de partida.

Azure

A menudo se me pregunta si hay una forma de separar roles de privilegios altos entre Azure AD, Azure y SaaS (por ejemplo: Administrador global para Office 365 pero no azure). La verdad es que no. La arquitectura multiinquilino es necesaria si se requiere una separación administrativa completa, pero eso agrega una complejidad significativa (vea más arriba). Todos estos servicios forman parte del mismo límite de seguridad e identidad (consulte el modelo de jerarquía anterior).

Es importante comprender las relaciones entre varios servicios del mismo inquilino. Estoy trabajando con muchos clientes que están creando soluciones empresariales que abarcan Azure, Office 365 y Power Platform (y a menudo también servicios en la nube locales y de terceros). Un ejemplo común:

1. Deseo colaborar en un conjunto de documentos/imágenes/etc. (Office 365)
2. Enviar cada uno de ellos a través de un proceso de aprobación (Power Platform)
3. Después de que se aprueben todos los componentes, ensamble estos en una API de Microsoft Graph de entrega unificada (Azure) es su mejor amigo para estos. No es imposible, pero es mucho más complejo diseñar una solución que abarca varios inquilinos.

Azure Role-Based Access Control (RBAC) permite una administración de acceso detallada para Azure. Con RBAC, puede administrar el acceso a los recursos concediendo a los usuarios el menor número de permisos necesarios para realizar sus trabajos. Los detalles están fuera del ámbito de este documento, pero para obtener más información sobre RBAC, vea ¿Qué es el control de acceso basado en roles (RBAC) en Azure? RBAC es importante, pero solo una parte de las consideraciones de gobierno para Azure. Cloud Adoption Framework es un excelente punto de partida para obtener más información. Me gusta cómo mi amigo, Andrés Ravinet, guía a los clientes paso a paso a través de varios componentes para decidir sobre el enfoque. La vista de alto nivel para varios elementos (no es tan buena como el proceso para llegar al modelo de cliente real) es algo así:

Como puede ver en la imagen anterior, muchos otros servicios deben considerarse como parte del diseño (por ejemplo: Directivas de Azure,Planos de Azure,Grupos de administración,y así sucesivamente).

Conclusión

Se inició como un resumen breve y terminó por más tiempo de lo que esperaba. Espero que ahora esté listo para aventurarse en una vista profunda de cómo crear un modelo de delegación para su organización. Esta conversación es muy común con los clientes. No hay ningún modelo que funcione para todos. Esperar algunas mejoras planeadas de ingeniería de Microsoft antes de documentar patrones comunes que vemos en todos los clientes. Mientras tanto, puede trabajar con su equipo de cuenta de Microsoft para organizar una visita al Centro de tecnología de Microsoft más cercano. Nos vemos allí.