La Identidad como el Nuevo Perímetro de Seguridad

radio_button_uncheckedshort_text 1. Introducción

La administración de identidades nació de la necesidad de responder a una pregunta simple: ¿quién está intentando utilizar un sistema? En los primeros equipos, pocos operadores trabajaban en entornos físicamente controlados. A medida que los sistemas pasaron a atender a cientos o miles de personas, surgieron cuentas de usuario, contraseñas, directorios centralizados y mecanismos de control de acceso. La popularización de Internet, de la informática en la nube y de las aplicaciones móviles transformó este problema en una disciplina estratégica conocida como administración de identidades y acceso (IAM).

Este conocimiento contribuye directamente a la protección de empresas, gobiernos y ciudadanos. Cuando una organización administra las identidades de forma centralizada, consigue reducir cuentas olvidadas, aplicar directivas coherentes, quitar accesos rápidamente y ofrecer servicios digitales más seguros. Para el lector, comprender la identidad es aprender a observar la seguridad desde el punto de vista de quién solicita acceso, de qué recurso se solicita y de qué evidencias deben verificarse antes de permitir la acción.

A lo largo de este capítulo, la idea de “la identidad como el nuevo perímetro” dejará de parecer solo un eslogan. Verá cómo la autenticación, la autorización, los directorios, los proveedores de identidades, los tokens , el SSO y la federación forman una cadena lógica. Cuando esa cadena se comprende bien, muchos escenarios del SC-900 se vuelven previsibles: basta con descubrir quién afirma la identidad, quién la verifica, quién confía en el resultado y quién decide lo que puede hacerse.

radio_button_uncheckedshort_text 2. Breve evolución de la identidad digital

Al principio de la informática corporativa, la seguridad dependía principalmente de barreras físicas y del control de la red interna. Un usuario que estuviera dentro del edificio, conectado al dominio y utilizando un equipo corporativo era frecuentemente tratado como de confianza. Active Directory Domain Services , introducido por Microsoft con Windows 2000, consolidó cuentas, equipos, grupos, directivas y autenticación en dominios locales. Resolvió un desafío central de la época: administrar de manera uniforme muchos recursos de una infraestructura basada en Windows.

Internet y las aplicaciones SaaS rompieron la correspondencia entre “estar en la red” y “ser de confianza”. Los usuarios pasaron a acceder a datos desde casa, desde dispositivos móviles, desde redes públicas y desde organizaciones asociadas. Las aplicaciones pasaron a existir fuera del centro de datos. Las API y los servicios automatizados comenzaron a actuar sin una persona presente. En este contexto, la dirección IP y la ubicación física ya no eran suficientes para representar la confianza. La identidad se convirtió en el elemento común entre todas esas interacciones.

El cambio no elimina los firewalls, la segmentación ni los controles de red. Altera el orden de prioridad: la identidad es la primera línea de decisión, mientras que la red funciona como protección complementaria. En una arquitectura moderna, cada solicitud se evalúa de acuerdo con el sujeto, el dispositivo, la aplicación, el riesgo, el recurso y el contexto. Este razonamiento acerca la identidad a los principios de Confianza cero y de privilegios mínimos.

radio_button_uncheckedshort_text 3. Qué es la identidad digital

La identidad digital es la representación electrónica de una entidad dentro de un sistema. La entidad puede ser una persona, un dispositivo, una aplicación, un servicio, una carga de trabajo o, en las soluciones actuales, un agente de inteligencia artificial. Esta representación contiene un identificador y un conjunto de atributos que permiten diferenciar la entidad de las demás y tomar decisiones de acceso.

Una identidad no es solo un nombre de usuario. Puede contener un identificador único, un nombre para mostrar, una dirección de correo electrónico, un puesto, un departamento, grupos, roles, dispositivos registrados, métodos de autenticación, el estado de la cuenta y relaciones con aplicaciones. Algunos atributos describen la entidad; otros influyen directamente en los permisos. La calidad, la actualización y la protección de esos atributos afectan a toda la seguridad del entorno.

Principio importante

Una identidad describe quién o qué está actuando. Una credencial es solo uno de los medios usados para demostrar que la entidad controla esa identidad. Cambiar la contraseña no crea una nueva identidad; cambia una credencial asociada a ella.

radio_button_uncheckedshort_text 4. Identificación, autenticación, autorización y administración

4.1 Identificación

La identificación es el acto por el que una entidad declara quién es. Al escribir joao@empresa.com, seleccionar un certificado o presentar un identificador de aplicación, el solicitante indica qué identidad desea utilizar. La identificación, por sí sola, no prueba nada. Cualquiera puede escribir el nombre de otra persona; por eso debe ir seguida de la autenticación.

4.2 Autenticación

La autenticación es el proceso de verificar si la entidad realmente es quien afirma ser. El sistema valida una o más evidencias: algo que la persona sabe, como una contraseña; algo que posee, como un teléfono, un token o una clave; algo que es, como una característica biométrica; o un elemento criptográfico, como un certificado. Cuando la verificación es correcta, el sistema establece una sesión o emite un token que representa el resultado.

Autenticar no significa permitir cualquier acción. La autenticación solo proporciona un nivel de confianza sobre la identidad. Un usuario puede estar autenticado y aun así no tener permiso para abrir un informe, cambiar una configuración o acceder a un determinado inquilino.

4.3 Autorización

La autorización es la decisión sobre lo que una identidad autenticada puede hacer. Esta decisión puede considerar roles, grupos, directivas, ámbitos, la propiedad del recurso, la clasificación del dato y las condiciones del contexto. El resultado normalmente permite o deniega una acción. En los sistemas modernos, la autorización también puede exigir una autenticación más fuerte, limitar una sesión o solicitar aprobación.

Una forma simple de memorizarlo es: la autenticación responde “¿quién eres?”; la autorización responde “¿qué puedes hacer?”. El orden lógico es autenticar primero y autorizar después, aunque las aplicaciones pueden evaluar parte de la directiva antes de iniciar el proceso de inicio de sesión.

4.4 Administración de identidades

La administración de identidades es el conjunto de procesos usados para crear, mantener, aprovisionar, revisar y quitar identidades y accesos. Incluye el registro de usuarios, grupos, roles, credenciales, dispositivos, aplicaciones, invitados y cuentas de servicio. También cubre los cambios de puesto, las transferencias entre áreas, las ausencias, la expiración del acceso y las bajas.

El término administración de identidades y acceso (IAM) es más amplio: combina administración, autenticación, autorización, gobernanza, auditoría y protección. Una organización puede tener una autenticación técnicamente fuerte y aun así presentar un alto riesgo si no quita rápidamente las cuentas de exempleados o si mantiene permisos incompatibles con los roles actuales.

radio_button_uncheckedshort_text 5. Por qué la identidad es el nuevo perímetro

El perímetro tradicional era un límite de red: de un lado, la red interna; del otro, Internet. Este modelo funcionaba mejor cuando las aplicaciones, los datos, los usuarios y los dispositivos estaban en el mismo lugar. Hoy, las aplicaciones corporativas están distribuidas entre Azure , Microsoft 365 , otros proveedores y centros de datos locales. Las personas trabajan desde cualquier lugar y los asociados necesitan colaborar sin formar parte de la red interna. El límite dejó de ser fijo.

La identidad permanece presente en todos esos escenarios. Es posible evaluar la identidad de una persona que accede a una aplicación SaaS, de una máquina virtual que llama a un servicio, de una aplicación que consume una API o de un invitado de otra organización. Por eso, los controles y las detecciones se centralizan en torno a las identidades. La decisión no depende solo de dónde vino la solicitud, sino de quién está solicitando, desde qué dispositivo, con qué nivel de riesgo y para qué recurso.

• Las aplicaciones y los datos están fuera de la red corporativa tradicional.
• Los dispositivos personales y móviles hacen que la ubicación sea menos confiable.
• Los usuarios externos y los asociados necesitan acceder a recursos específicos.
• Los servicios automatizados y las API exigen identidades propias.
• Las credenciales robadas pueden permitir acceso remoto sin vulnerar un firewall.
• Una identidad central permite aplicar directivas y auditoría de manera coherente.

Relación con Confianza cero

Tratar la identidad como perímetro no significa confiar automáticamente en quien posee una cuenta. Al contrario: cada solicitud debe verificarse explícitamente, recibir los privilegios mínimos necesarios y supervisarse bajo la suposición de que puede ocurrir una vulneración.

radio_button_uncheckedshort_text 6. Infraestructura de identidad y sus pilares

Una infraestructura de identidad es el conjunto de servicios, procesos, directivas e integraciones que sostiene el ciclo de vida y las decisiones de acceso. El módulo oficial de Microsoft Learn destaca cuatro pilares conceptuales: administración, autenticación, autorización y auditoría. Funcionan como partes interdependientes de un mismo sistema.

Estos pilares necesitan compartir una fuente de verdad. Si el sistema de recursos humanos registra una baja, la administración debe deshabilitar o quitar la identidad; la autenticación debe impedir nuevos inicios de sesión; la autorización debe revocar tokens y accesos; y la auditoría debe registrar el proceso. El fallo de cualquier paso deja una brecha.

radio_button_uncheckedshort_text 7. Proveedores de identidades y autenticación moderna

Un proveedor de identidades, o Identity Provider ( IdP ), es un servicio central que crea y mantiene información de identidad y ofrece autenticación, autorización y auditoría a aplicaciones y servicios. En lugar de que cada aplicación almacene su propia lista de usuarios e implemente reglas de contraseña, las aplicaciones delegan el proceso en el IdP . Microsoft Entra ID es un ejemplo de proveedor de identidades basado en la nube.

Cuando un usuario intenta iniciar sesión en una aplicación, esta lo redirige al proveedor de identidades. El IdP verifica las credenciales y aplica directivas. Si el proceso se aprueba, emite un token de seguridad. La aplicación valida el token según su relación de confianza con el IdP y utiliza la información contenida en él para crear la sesión y decidir el acceso.

Centralizar la autenticación aporta beneficios claros: directivas coherentes, MFA en varias aplicaciones, visibilidad unificada de los inicios de sesión, reducción de contraseñas independientes, desaprovisionamiento más rápido y una mayor capacidad de detectar patrones sospechosos. También reduce el riesgo de que cada equipo intente desarrollar su propio mecanismo de autenticación, una tarea compleja y delicada.

radio_button_uncheckedshort_text 8. Tokens , notificaciones y protocolos

8.1 Tokens de seguridad

Un token de seguridad es un paquete estructurado de datos emitido por una autoridad de confianza después de la autenticación. El token evita que la aplicación reciba y valide directamente la contraseña del usuario. En su lugar, recibe una evidencia firmada por el proveedor de identidades. Los tokens normalmente poseen un emisor, un destinatario, una hora de emisión, una expiración e información sobre el sujeto.

Dos tipos son importantes para la comprensión conceptual. El token de identificador ( ID token ) prueba que el usuario fue autenticado e indica quién es. El token de acceso ( access token ) representa la autorización para acceder a un recurso o a una API . Un token de identificador no debe usarse como sustituto de un token de acceso al llamar a una API ; tienen finalidades distintas.

8.2 Notificaciones ( claims )

Las notificaciones son declaraciones individuales transportadas en un token . Los ejemplos incluyen el identificador del usuario, el nombre, el correo electrónico, los grupos, los roles, el inquilino, el método de autenticación, la hora y el ámbito autorizado. La aplicación no debe aceptar una notificación solo porque existe; debe validar la firma del token , el emisor, el público, la validez y otros requisitos del protocolo.

8.3 Protocolos de autenticación moderna

Trampa frecuente

OAuth 2.0 es un marco de autorización. OpenID Connect agrega una capa de autenticación sobre OAuth 2.0. SAML también puede ofrecer SSO , pero utiliza un modelo y un formato diferentes.

radio_button_uncheckedshort_text 9. Inicio de sesión único (Single Sign-On - SSO )

El inicio de sesión único es la capacidad de un usuario de autenticarse una vez en un proveedor de identidades y acceder a varias aplicaciones de confianza sin proporcionar de nuevo las credenciales en cada inicio de sesión. Esto es posible porque el IdP mantiene una sesión y emite tokens específicos para las aplicaciones solicitadas. Cada aplicación valida el token y confía en el resultado de la autenticación realizada por el IdP .

El SSO mejora la experiencia y puede fortalecer la seguridad. Menos solicitudes de contraseña reducen la reutilización, la fatiga y la exposición a páginas falsas. La organización puede aplicar MFA y directivas en un punto central. Sin embargo, la centralización aumenta la importancia de proteger la cuenta y el IdP : si una identidad central se ve comprometida, varias aplicaciones pueden verse afectadas. Por eso, el SSO debe ir acompañado de autenticación fuerte, supervisión y privilegios mínimos.

El SSO no es lo mismo que la federación. El SSO describe la experiencia de autenticarse una vez y acceder a varias aplicaciones. La federación describe la relación de confianza entre sistemas de identidad distintos. Una solución federada puede proporcionar SSO entre organizaciones, pero también existe SSO dentro de un único proveedor.

radio_button_uncheckedshort_text 10. Servicios de directorio

Un servicio de directorio es un sistema especializado en almacenar, organizar, buscar y administrar información sobre identidades y recursos. Funciona como una fuente estructurada para usuarios, grupos, equipos, aplicaciones y otros objetos. A diferencia de una simple lista de cuentas, un directorio ofrece jerarquía o relaciones, atributos, directivas, mecanismos de consulta e integración con la autenticación y la autorización.

Los directorios ayudan a mantener una identidad coherente. Un grupo puede representar a un equipo; un rol puede conceder permisos; un atributo puede dirigir el aprovisionamiento. Las aplicaciones consultan el directorio o confían en el proveedor de identidades conectado a él. El directorio, por sí solo, no sustituye a todos los componentes de IAM, pero es una pieza central de la infraestructura.

• Almacenar objetos y atributos de identidad.
• Organizar usuarios, grupos, dispositivos y aplicaciones.
• Permitir búsquedas y consultas eficientes.
• Admitir autenticación y directivas de acceso.
• Proporcionar una fuente común para el aprovisionamiento y la auditoría.
• Mantener relaciones de pertenencia, como usuarios que pertenecen a grupos.

radio_button_uncheckedshort_text 11. Active Directory Domain Services ( AD DS )

Active Directory Domain Services es el servicio de directorio de Microsoft para los dominios de Windows Server. Organiza los objetos en una estructura compuesta por bosques, dominios y unidades organizativas. Los controladores de dominio almacenan el directorio, autentican a usuarios y equipos y replican información entre sí. AD DS está profundamente integrado con DNS y utiliza protocolos como Kerberos, NTLM y LDAP.

Un bosque representa el límite más amplio de una implementación de AD DS y puede contener varios dominios. Un dominio reúne objetos que comparten una base de datos, directivas y un espacio de nombres. Las unidades organizativas ayudan a organizar objetos y a delegar la administración, pero no son límites de seguridad equivalentes a un bosque. Los grupos se usan para asignar permisos y simplificar la administración.

AD DS es especialmente adecuado para recursos locales, autenticación integrada de Windows, servidores, estaciones unidas al dominio y aplicaciones heredadas. La organización es responsable de instalar, actualizar, proteger, supervisar y garantizar la disponibilidad de los controladores de dominio.

radio_button_uncheckedshort_text 12. Microsoft Entra ID

Microsoft Entra ID es la solución de administración de identidades y acceso basada en la nube de Microsoft. Conecta personas, dispositivos, aplicaciones y datos y funciona como proveedor de identidades para Microsoft 365 , Azure y miles de aplicaciones. Es un servicio multiinquilino operado por Microsoft y ofrecido como Identity as a Service (IDaaS).

La unidad administrativa central es el inquilino, también llamado directorio de Microsoft Entra . El inquilino posee un identificador exclusivo y contiene usuarios, grupos, dispositivos, registros de aplicaciones, entidades de servicio, roles y directivas. La autenticación moderna utiliza protocolos como OAuth 2.0, OpenID Connect y SAML . El servicio ofrece SSO , MFA , acceso condicional , protección de identidad, gobernanza e integraciones de aprovisionamiento.

Microsoft Entra ID no es simplemente un controlador de dominio en la nube. No utiliza bosques, dominios y unidades organizativas como AD DS y no depende de Kerberos o LDAP como interfaz principal para las aplicaciones modernas. Su arquitectura se creó para Internet, SaaS, API y entornos distribuidos. Cuando las aplicaciones requieren características tradicionales de dominio, pueden ser necesarias otras soluciones, como AD DS local o Microsoft Entra Domain Services .

• Administración central de identidades para la nube y los entornos híbridos.
• Autenticación para Microsoft 365 , Azure y aplicaciones integradas.
• SSO y federación con organizaciones y proveedores externos.
• Identidades para usuarios, dispositivos, aplicaciones y cargas de trabajo.
• Directivas de acceso basadas en el contexto y el riesgo.
• Registros de inicio de sesión, auditoría, gobernanza y protección de identidades.

radio_button_uncheckedshort_text 13. Active Directory Domain Services frente a Microsoft Entra ID

Cuidado con la terminología

Microsoft Entra ID se llamaba Azure Active Directory ( Azure AD ). El cambio de nombre no transformó el servicio en AD DS . En las preguntas del examen, observe si el escenario implica un dominio Windows y protocolos tradicionales o identidad en la nube y autenticación moderna.

radio_button_uncheckedshort_text 14. Confianza entre dominios

En Active Directory Domain Services , una relación de confianza permite que las identidades autenticadas en un dominio se reconozcan para acceder a recursos de otro dominio, de acuerdo con los permisos configurados. La confianza no concede acceso automáticamente; crea un camino para que la autenticación sea aceptada. La autorización en el recurso de destino sigue siendo necesaria.

Las confianzas pueden tener dirección y transitividad. Una confianza unidireccional permite que un lado acepte identidades del otro en un sentido específico. Una confianza bidireccional establece reconocimiento en ambos sentidos. Las confianzas transitivas pueden extender el camino entre dominios relacionados, mientras que una confianza no transitiva se limita a las partes configuradas.

En el SC-900, lo más importante es entender la idea de confianza y no memorizar todas las variaciones administrativas de AD DS . La misma noción general aparece en la federación: una parte acepta una evidencia de identidad emitida por otra parte de confianza.

radio_button_uncheckedshort_text 15. Federación de identidades

La federación es el establecimiento de relaciones de confianza entre sistemas de identidad separados para permitir el acceso a través de límites organizativos o de dominio. El usuario se autentica en el proveedor de su organización y utiliza esa identidad para acceder a un recurso externo. El sistema de destino no necesita almacenar la contraseña del usuario ni administrar una credencial separada.

La analogía del pasaporte es útil: un país emite un documento y otro lo acepta como evidencia porque confía en el emisor y puede verificar su autenticidad. En la federación, el proveedor de identidades emite un token o una aserción; la aplicación o el proveedor de destino valida la firma, el emisor, el destinatario y las notificaciones. Después, aplica sus propias reglas de autorización.

La federación puede utilizar SAML , OpenID Connect, WS-Federation u otros protocolos compatibles. Active Directory Federation Services ( AD FS ) es un rol de servidor que permite emitir tokens a partir de identidades de AD DS e integrarlos con aplicaciones externas. Microsoft Entra ID también ofrece federación y colaboración externa sin exigir que cada aplicación implemente directamente todos esos detalles.

radio_button_uncheckedshort_text 16. Autenticación entre organizaciones, aplicaciones y proveedores externos

16.1 Colaboración entre empresas

En una asociación entre empresas, los empleados de la Organización B pueden acceder a un proyecto hospedado por la Organización A usando sus credenciales corporativas. La Organización A confía en la autenticación realizada por el proveedor de B o utiliza características de colaboración B2B. La autorización sigue bajo el control de A: solo deben liberarse los documentos, grupos y aplicaciones necesarios.

16.2 Proveedores sociales y de consumidores

Una aplicación dirigida al público puede permitir el inicio de sesión con cuentas de Microsoft, Google, GitHub u otros proveedores. La aplicación confía en el proveedor externo para autenticar a la persona y recibe notificaciones básicas. Esto reduce la fricción del registro, pero la aplicación todavía necesita crear su perfil interno, aplicar el consentimiento, proteger los datos personales y definir los permisos.

16.3 Una aplicación que accede a una API

Una aplicación puede recibir autorización para llamar a una API en nombre del usuario o en su propio nombre. En el primer caso, el token de acceso representa una combinación de la aplicación, el usuario y los ámbitos concedidos. En el segundo, la aplicación utiliza una identidad de servicio, un certificado o una identidad administrada. En ambos, la API valida el token antes de autorizar la operación.

16.4 Identidad híbrida

La identidad híbrida permite que una misma persona tenga una representación coherente en entornos locales y en la nube. Las organizaciones que usan AD DS pueden sincronizar usuarios y atributos con Microsoft Entra ID . Según el diseño, la autenticación puede ocurrir en la nube, utilizar agentes o estar federada con la infraestructura local. El objetivo es ofrecer una identidad común sin obligar al usuario a mantener cuentas desconectadas.

radio_button_uncheckedshort_text 17. Ciclo de vida, aprovisionamiento y desaprovisionamiento

La seguridad de la identidad no termina en el inicio de sesión. Cada identidad pasa por un ciclo de vida: incorporación, cambios y baja. Este modelo se describe a menudo como joiner, mover y leaver. En la incorporación, la organización crea la identidad, asigna atributos y concede accesos iniciales. En un cambio de rol, deben quitarse los permisos antiguos y concederse permisos nuevos. En la baja, las sesiones, los tokens , los dispositivos y los accesos deben revocarse rápidamente.

El aprovisionamiento es la creación y actualización de identidades y cuentas en los sistemas de destino. Puede ser manual, automatizado mediante integraciones con RR. HH. o estandarizado con SCIM. El desaprovisionamiento es la eliminación o desactivación coordinada. Una cuenta olvidada en una aplicación no integrada puede permanecer accesible incluso después de que la identidad central se haya deshabilitado; por eso, el inventario y la automatización son importantes.

1. Una fuente autoritativa registra el vínculo de la persona, como el sistema de RR. HH.
2. El directorio o el IdP crea la identidad y sus atributos.
3. Los grupos, los roles y los paquetes de acceso conceden lo mínimo necesario.
4. Las aplicaciones reciben o crean cuentas mediante el aprovisionamiento.
5. Los cambios de rol desencadenan una revisión y un ajuste de permisos.
6. La baja deshabilita la autenticación, revoca sesiones y quita accesos.
7. Los registros y las revisiones verifican que el proceso se completó.

El principio de privilegios mínimos

Una identidad debe recibir solo los permisos necesarios, en el ámbito necesario y durante el tiempo necesario. El ciclo de vida evita que los privilegios se acumulen indefinidamente.

radio_button_uncheckedshort_text 18. Riesgos y ataques basados en la identidad

Si la identidad es el nuevo perímetro, los atacantes intentarán atravesarlo. El objetivo puede ser robar una credencial, engañar al usuario, reutilizar una sesión, registrar un método de autenticación u obtener privilegios adicionales. El conocimiento de estos riesgos ayuda a comprender por qué la centralización, la MFA , los tokens de corta duración, la auditoría y el desaprovisionamiento son relevantes.

Ningún control aislado elimina todo el riesgo. La MFA reduce el valor de una contraseña robada, pero no corrige una autorización excesiva. El SSO reduce la cantidad de credenciales, pero exige una protección rigurosa del proveedor central. La auditoría permite detectar e investigar, pero debe ir acompañada de procesos de respuesta.

radio_button_uncheckedshort_text 19. Cómo se conectan los conceptos

Considere el acceso de una empleada a una aplicación de nóminas en la nube. La identidad se creó a partir del proceso de contratación y recibió atributos de departamento. Al abrir la aplicación, ella indica su identificador. La aplicación redirige el navegador a Microsoft Entra ID , que autentica a la usuaria y aplica directivas. Un token de identificador indica quién es; un token de acceso permite llamar a una API específica. La aplicación analiza las notificaciones y autoriza solo las pantallas adecuadas para su rol.

Si la empleada accede a una aplicación de un asociado, una relación federada puede permitir el uso de la misma identidad. Si la organización mantiene AD DS local, la identidad puede sincronizarse con Microsoft Entra ID y utilizarse de forma híbrida. Cuando la empleada cambia de área, la administración actualiza los atributos y los grupos; los permisos se recalculan. En la baja, la cuenta se deshabilita, las sesiones se revocan y las aplicaciones integradas quitan el acceso.

Este ejemplo muestra que el directorio, el IdP , el SSO y la federación no son conceptos independientes. El directorio organiza las identidades; el IdP las autentica y emite tokens ; el SSO mejora la experiencia entre aplicaciones de confianza; la federación extiende la confianza entre sistemas distintos; la autorización protege cada recurso; y la auditoría registra todo el camino.

radio_button_uncheckedshort_text 20. Trampas comunes en el SC-900

radio_button_uncheckedshort_text 21. Escenario integrado: colaboración entre dos empresas

La Empresa Alfa usa Microsoft 365 y hospeda un portal de proyecto. La Empresa Beta participa en el proyecto y necesita conceder acceso a veinte consultores. El objetivo es evitar cuentas y contraseñas separadas en el portal, garantizar que Beta siga siendo responsable de autenticar a sus profesionales y permitir que Alfa controle exactamente qué recursos se pueden acceder.

21.1 Arquitectura de identidad

• Cada empresa mantiene su propio proveedor de identidades y ciclo de vida de usuarios.
• Alfa establece una colaboración B2B o una relación federada compatible.
• Los consultores inician sesión con las credenciales corporativas de Beta.
• Alfa recibe una identidad externa y asigna grupos o roles limitados al proyecto.
• El portal confía en el IdP de Alfa y recibe tokens con notificaciones relevantes.

21.2 Flujo de acceso

1. El consultor indica su identidad en el portal de Alfa.
2. El flujo identifica que la autenticación debe realizarla el proveedor de confianza de Beta.
3. Beta autentica al usuario y emite una evidencia o participa en el flujo federado.
4. Alfa valida la confianza y representa al consultor como usuario externo.
5. El portal recibe un token y autoriza solo el área de trabajo del proyecto.
6. Los inicios de sesión y las acciones se registran para la auditoría.

21.3 Cambio y baja

Si un consultor deja Beta, su proveedor de identidades debe impedir nuevas autenticaciones. Alfa también debe tener revisiones de acceso y expiración para reducir la dependencia de procesos manuales. Al final del proyecto, el grupo y los accesos externos se quitan. Este diseño combina federación, SSO , autorización local, privilegios mínimos y gobernanza del ciclo de vida.

Resultado

Beta controla la autenticación de sus profesionales; Alfa controla la autorización sobre sus recursos. Ninguna contraseña corporativa necesita compartirse con el portal de la otra empresa.

radio_button_uncheckedshort_text 22. Repaso rápido para el examen

radio_button_uncheckedshort_text 23. Conclusión

La identidad se convirtió en el nuevo perímetro porque la seguridad moderna no puede depender solo de un límite de red. Las personas, los dispositivos, las aplicaciones y los servicios acceden a recursos distribuidos entre la nube, el SaaS y los entornos locales. La identidad ofrece un punto común para verificar quién solicita acceso, evaluar el contexto, aplicar privilegios mínimos y registrar decisiones.

En este capítulo, diferenciamos identificación, autenticación, autorización y administración; analizamos los pilares de una infraestructura de identidad; explicamos el papel del proveedor de identidades, de los tokens y de las notificaciones; y separamos el SSO de la federación. También comparamos Active Directory Domain Services y Microsoft Entra ID y mostramos cómo la confianza y los protocolos estandarizados permiten la colaboración entre organizaciones.

En mi evaluación, la identidad es el tema que más ayuda al candidato a comprender el resto del SC-900. La MFA , el acceso condicional , la protección de identidad, el RBAC , PIM , la gobernanza y la colaboración externa son extensiones naturales de los aspectos básicos estudiados aquí. Cuando puede narrar el flujo completo - desde la creación de la cuenta hasta la emisión del token y la autorización del recurso -, deja de memorizar productos aislados y pasa a entender la arquitectura. Este cambio de perspectiva hace que el estudio sea más coherente y prepara el camino para los próximos capítulos sobre Microsoft Entra ID .

radio_button_uncheckedshort_text 24. Preguntas de repaso

Intente responder antes de consultar la solución comentada.

Pregunta 1

Un usuario indica su dirección de correo electrónico y, a continuación, confirma una solicitud en Microsoft Authenticator . ¿Qué pasos ocurrieron, respectivamente?

• A) Autorización y auditoría.
• B) Identificación y autenticación.
• C) Autenticación e identificación.
• D) Aprovisionamiento y autorización.

Solución comentada

Respuesta correcta: B. Indicar la dirección declara la identidad; confirmar la evidencia verifica que el usuario controla esa identidad.

Pregunta 2

¿Qué afirmación describe correctamente el inicio de sesión único?

• A) Todas las aplicaciones almacenan la misma contraseña del usuario.
• B) El usuario recibe autorización irrestricta después del primer inicio de sesión.
• C) El usuario se autentica en el IdP y las aplicaciones de confianza aceptan tokens sin exigir de nuevo las credenciales.
• D) El SSO solo funciona entre dos dominios de AD DS .

Solución comentada

Respuesta correcta: C. El SSO depende de la confianza en el proveedor de identidades y de los tokens ; no comparte la contraseña ni elimina la autorización.

Pregunta 3

¿Qué diferencia entre AD DS y Microsoft Entra ID es correcta?

• A) Microsoft Entra ID es solo un controlador de dominio operado por Microsoft.
• B) AD DS usa principalmente OAuth 2.0, mientras que Entra ID usa Kerberos.
• C) AD DS atiende dominios Windows y protocolos tradicionales; Entra ID es un IAM/ IdP en la nube para SaaS, aplicaciones y API modernas.
• D) Los dos productos poseen exactamente la misma estructura de bosques y OU.

Solución comentada

Respuesta correcta: C. Tratan de la identidad, pero poseen arquitectura, protocolos y escenarios diferentes y pueden coexistir en entornos híbridos.

Pregunta 4

Una empresa acepta tokens emitidos por el proveedor de identidades de un asociado. ¿Qué representa esto?

• A) Cifrado simétrico.
• B) Federación de identidades.
• C) Solo identificación local.
• D) Un permiso automático a todos los recursos.

Solución comentada

Respuesta correcta: B. La federación establece confianza entre sistemas de identidad. La empresa de destino todavía debe autorizar cada recurso.

radio_button_uncheckedshort_text 25. Referencias y fuentes para profundizar

Contenido del plan de estudios SC-900 proporcionado por el usuario: Capítulo 2 - La Identidad como el Nuevo Perímetro de Seguridad.

• Microsoft Learn. Study guide for Exam SC-900: Microsoft Security, Compliance, and Identity Fundamentals. Actualizado el 26 de junio de 2026; consultado el 23 de julio de 2026.
• Microsoft Learn. Describe identity concepts. Módulo de entrenamiento del SC-900; consultado el 23 de julio de 2026.
• Microsoft Learn. Describe the role of the identity provider. Unidad sobre IdP, tokens, notificaciones, protocolos y SSO; consultada el 23 de julio de 2026.
• Microsoft Learn. Describe the concept of federation. Unidad sobre confianza entre proveedores y colaboración externa; consultada el 23 de julio de 2026.
• Microsoft Learn. Compare Active Directory to Microsoft Entra ID. Documentación de aspectos básicos de Microsoft Entra.
• Microsoft Learn. Azure identity management and access control security best practices. Documentación sobre la identidad como perímetro y la centralización de IAM.
• Microsoft Learn. Introduction to Microsoft Entra y Describe the function and identity types of Microsoft Entra ID. Rutas oficiales de aprendizaje.

Cierre del capítulo

Has completado los fundamentos conceptuales de identidad. El siguiente paso natural es estudiar la estructura de Microsoft Entra ID , sus tipos de identidad y la integración entre entornos locales y en la nube.