Microsoft AZ-204: Autenticación, autorización y seguridad de Azure — Guía de estudio

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure Developer Associate AZ-204 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Descripción general

La autenticación y autorización en Azure se basan en la Plataforma de identidad de Microsoft, que emite tokens para identidades (usuarios, aplicaciones, cargas de trabajo) y controla el acceso a las API y los recursos. Las aplicaciones se integran a través de OAuth 2.0 y OpenID Connect, adquieren tokens usando MSAL y solicitan permisos declarados en los registros de aplicaciones de Azure AD. Las cargas de trabajo que se ejecutan en Azure pueden eliminar las credenciales por completo utilizando identidades administradas y apoyarse en Azure RBAC para acceder a servicios como Key Vault, Storage y Microsoft Graph. La gestión de secretos se centra en Azure Key Vault, con una clara separación entre el acceso al plano de datos del almacén y el control del plano de administración, y con sólidas garantías de recuperación mediante la eliminación temporal (soft delete) y la protección contra purga. Para el almacenamiento, las Firmas de Acceso Compartido (SAS) proporcionan una delegación de alcance limitado y con restricción de tiempo a los clientes sin exponer las claves de la cuenta.

Plataforma de identidad de Microsoft, OAuth 2.0, MSAL y registros de aplicaciones

La Plataforma de identidad de Microsoft admite múltiples flujos de OAuth 2.0 optimizados para diferentes tipos de aplicaciones:

• Flujo de código de autorización: El estándar para aplicaciones web, SPA y aplicaciones nativas. Los clientes públicos deben usar PKCE para proteger el código de autorización. Las aplicaciones redirigen a los usuarios al endpoint de autorización, reciben un código de autorización en el URI de redirección y luego lo canjean en el endpoint de token por un token de acceso (y opcionalmente un token de actualización). Para las SPA, el flujo de código de autorización + PKCE reemplaza al antiguo flujo implícito y mitiga la fuga de tokens.
• Flujo de credenciales de cliente: Utilizado por daemons y servicios de servidor a servidor sin un usuario. La aplicación solicita tokens utilizando una aserción de cliente (certificado) o un secreto de cliente. Aquí solo están disponibles los permisos de aplicación (app roles), y la mayoría de ellos requieren el consentimiento del administrador. Este flujo utiliza el ámbito /.default para solicitar el conjunto de permisos de aplicación configurados estáticamente.
• Flujo de código de dispositivo: Diseñado para dispositivos o entornos sin un navegador incrustado. La aplicación obtiene un código de usuario y una URL de verificación de la plataforma de identidad, el usuario se autentica en un dispositivo separado y la aplicación sondea el endpoint de token. Se aplican permisos delegados porque un usuario inicia sesión.
• Flujo de concesión implícita: Históricamente utilizado por las SPA para recibir tokens directamente desde el endpoint de autorización. Ahora se desaconseja su uso en favor del código de autorización con PKCE. Si se utiliza, todavía se requiere un URI de redirección durante el registro de la aplicación.

MSAL (Microsoft Authentication Library) proporciona una adquisición de tokens consistente en todos los lenguajes y plataformas. Las aplicaciones de cliente público (de escritorio, móviles, SPA) utilizan AcquireTokenInteractive y AcquireTokenSilent para obtener y almacenar en caché los tokens; las aplicaciones nativas también utilizarán AcquireTokenByDeviceCode para el flujo de código de dispositivo y AcquireTokenByAuthorizationCode para el canje del código de autorización en contextos de cliente confidencial. Los clientes confidenciales (aplicaciones web/API/daemons) adquieren tokens con AcquireTokenForClient cuando usan credenciales de cliente y AcquireTokenOnBehalfOf para escenarios OBO (On-Behalf-Of) donde una API llama a otras API descendentes con el contexto delegado de un usuario.

El almacenamiento en caché de tokens es fundamental para MSAL: almacena tokens de acceso y de actualización indexados por cuenta, cliente y ámbito, lo que permite a AcquireTokenSilent evitar solicitudes interactivas innecesarias. Las aplicaciones web y las API que se ejecutan en múltiples instancias deben persistir y proteger la caché de tokens utilizando un almacén compartido y cifrado (p. ej., una caché distribuida con cifrado adecuado en reposo y en tránsito). Los hooks de serialización de caché en MSAL permiten una persistencia segura. Los ámbitos (scopes) identifican los permisos que una aplicación está solicitando. Para los permisos delegados, solicite los ámbitos mínimos y específicos del recurso (p. ej., https://graph.microsoft.com/User.Read). Para las credenciales de cliente, solicite el ámbito /.default basado en el recurso, que se asigna a los permisos de aplicación otorgados estáticamente a la aplicación (p. ej., scope = https://graph.microsoft.com/.default). Utilice el consentimiento incremental para solicitar ámbitos de forma progresiva y reducir la fricción.

Los registros de aplicaciones de Azure AD definen la identidad de la aplicación, las credenciales, los URI de redirección y los permisos. Los permisos delegados requieren un usuario con sesión iniciada y, a menudo, los propios usuarios pueden dar su consentimiento para sus datos; los permisos de aplicación se otorgan a la propia aplicación y casi siempre requieren que un administrador dé su consentimiento porque se aplican a todo el inquilino o de forma amplia. Las aplicaciones que exponen API declaran ámbitos (para permisos delegados) y roles de aplicación (para permisos de aplicación) en la sección “Exponer una API”. Configure el acceso para un solo inquilino (single-tenant) o multinquilino (multi-tenant) según los límites de confianza, y utilice certificados en lugar de secretos de cliente para obtener credenciales más sólidas y una rotación más sencilla.

Microsoft Graph utiliza la misma emisión de tokens. Autentíquese con MSAL apuntando al recurso de Graph y solicite los ámbitos de privilegio mínimo. Algunos endpoints comunes incluyen:

• GET https://graph.microsoft.com/v1.0/me para el perfil de usuario con tokens delegados (p. ej., User.Read)
• GET https://graph.microsoft.com/v1.0/users y /groups para objetos de directorio (requiere permisos delegados o de aplicación apropiados como User.Read.All o Group.Read.All)
• GET https://graph.microsoft.com/v1.0/sites o /drives para operaciones de SharePoint/OneDrive Cuando se utilizan credenciales de cliente, solicite el ámbito /.default y asegúrese de que exista el consentimiento del administrador para los permisos de aplicación requeridos. Elija la autoridad correcta (específica del inquilino frente a común/organizaciones) para controlar dónde pueden iniciar sesión los usuarios y dónde se pueden emitir los tokens.

Identidades administradas y acceso seguro a recursos de Azure, además de referencias de Key Vault

Las identidades administradas para recursos de Azure eliminan los secretos al permitir que Azure gestione las credenciales de las entidades de servicio (service principals). Las identidades administradas asignadas por el sistema están vinculadas 1:1 con un recurso (App Service, Function App, VM, VMSS, Logic App, etc.) y comparten su ciclo de vida; cuando se elimina el recurso, la identidad también se elimina. Las identidades administradas asignadas por el usuario se crean como recursos de Azure independientes que se pueden asociar a múltiples recursos de computación y existen independientemente del ciclo de vida de cualquier carga de trabajo individual. Este modelo permite la reutilización de identidades y la separación de responsabilidades.

Para acceder a los recursos de Azure con una identidad administrada, asígnele el rol de Azure RBAC apropiado en el ámbito correcto:

• Para el plano de datos de Azure Storage con Azure AD, asigne roles como Storage Blob Data Reader/Contributor en el ámbito de una cuenta de almacenamiento, un contenedor o un grupo de recursos/suscripción.
• Para Key Vault (modelo de plano de datos con RBAC), asigne roles como Key Vault Secrets User o Key Vault Crypto Officer.
• Para Microsoft Graph a través de permisos de aplicación, las identidades administradas solo pueden llamar a API descendentes después de que se asocie un registro de aplicación. Utilice la federación de identidades de carga de trabajo o configure los permisos de la aplicación empresarial y el consentimiento del administrador según sea necesario.

En tiempo de ejecución, utilice el Servicio de metadatos de instancia (IMDS) en las VM o el punto de conexión administrado de App Service para obtener tokens; los SDK como DefaultAzureCredential de Azure Identity utilizarán automáticamente el punto de conexión de la identidad administrada cuando esté disponible. Esto elimina la necesidad de almacenar secretos y permite la rotación por parte de la plataforma.

Las referencias de Key Vault en App Service y Azure Functions permiten recuperar secretos de forma segura en la configuración de la aplicación sin cambios en el código. En el valor de una configuración de aplicación, utilice la sintaxis de referencia @Microsoft.KeyVault(SecretUri=https://{vault-name}.vault.azure.net/secrets/{name}/{version}). La plataforma resuelve la referencia utilizando la identidad administrada de la aplicación durante el inicio y la actualiza periódicamente. Asegúrese de que la identidad administrada tenga el permiso Get para secretos a través de las directivas de acceso de Key Vault o el rol Key Vault Secrets User cuando se utiliza el modelo de plano de datos con RBAC. Las referencias de Key Vault son ideales para valores de configuración que nunca deben almacenarse en texto plano en el almacén de configuración de la aplicación y eliminan la lógica de manejo de secretos del código de la aplicación.

Azure Key Vault: Secretos, claves, certificados y control de acceso

Azure Key Vault almacena tres tipos de objetos:

• Secretos: Cadenas opacas como contraseñas, cadenas de conexión o claves de API. Tienen versiones; los clientes suelen realizar operaciones Get y Set.
• Claves: Claves criptográficas (RSA, EC) utilizadas para operaciones de firma/verificación, cifrado/descifrado y empaquetado/desempaquetado (wrap/unwrap). El material de la clave está protegido por el servicio respaldado por HSM; los clientes invocan operaciones criptográficas a través del servicio en lugar de exportar el material de la clave privada.
• Certificados: Objetos X.509 con gestión del ciclo de vida, opcionalmente integrados con CA asociadas. Los certificados se materializan como un certificado más un secreto correspondiente (PFX) y, opcionalmente, una clave administrada.

La eliminación temporal (soft delete) está activada por defecto, conservando los objetos eliminados durante un período de retención. Habilite la protección contra purga para evitar la eliminación irreversible dentro del período de retención y para hacer cumplir las garantías de recuperación (a menudo un requisito de retención de 90 días). Combine la eliminación temporal y la protección contra purga para cumplir con políticas de recuperación estrictas. Además, proteja el acceso de red al almacén con puntos de conexión privados y deshabilite el acceso a la red pública siempre que sea posible.

El control de acceso puede utilizar las directivas de acceso del almacén (legacy) o Azure RBAC para el plano de datos. Las directivas de acceso se configuran por almacén y otorgan explícitamente permisos (Get, List, Set, Sign, Wrap) a las entidades de seguridad; no se heredan y pueden volverse pesadas de operar a escala. El modelo de plano de datos con RBAC utiliza roles de Azure (p. ej., Key Vault Administrator, Key Vault Secrets Officer, Key Vault Secrets User, Key Vault Crypto Officer) y admite el ámbito a nivel de suscripción, grupo de recursos o almacén, con la auditoría integrada en Azure RBAC. Elija un modelo; si RBAC está habilitado para el plano de datos, las directivas de acceso se ignoran. Las operaciones del plano de administración (crear/actualizar el almacén) siempre utilizan Azure RBAC.

Integre Key Vault con aplicaciones utilizando los SDK de Azure (p. ej., SecretClient, KeyClient, CertificateClient) y DefaultAzureCredential. Prefiera las identidades administradas para la autenticación, evite incrustar credenciales e implemente directivas de reintento y de limitación de velocidad (throttling) al llamar a las API del almacén.

SAS de Azure Storage y Políticas de Acceso Almacenadas

Las Firmas de Acceso Compartido (SAS) delegan un acceso detallado y por tiempo limitado a Azure Storage sin revelar las claves de la cuenta:

• SAS de delegación de usuario (solo Blob): Respaldada por Azure AD. La aplicación obtiene una clave de delegación de usuario del servicio Blob usando credenciales de Azure AD, y luego crea tokens SAS para los clientes. Este es el enfoque más seguro para escenarios centrados en el usuario porque evita el uso de claves de cuenta y se alinea con la autorización basada en roles.
• SAS de servicio: Con ámbito a un recurso específico (blob, contenedor, mensaje de cola, entidad de tabla, archivo). Firmada con una clave de cuenta. Soporta permisos como leer, escribir, agregar, crear, eliminar, listar, establecer inmutabilidad y etiquetas, dependiendo del servicio.
• SAS de cuenta: El ámbito más amplio sobre múltiples servicios (Blob, Queue, Table, File) y tipos de recursos. Úsela con moderación debido a su amplio radio de impacto.

Los tokens SAS incluyen restricciones como el tiempo de expiración (se), tiempo de inicio (st), permisos (sp), rangos de IP (sip), protocolos permitidos (spr), recurso firmado (sr) y, cuando se vincula a una política de acceso almacenada, un identificador firmado (si). Siga el principio de privilegio mínimo otorgando solo los permisos necesarios, manteniendo las expiraciones cortas y forzando HTTPS (spr=https). Prefiera la SAS de delegación de usuario siempre que sea posible; de lo contrario, use una SAS de servicio con una política de acceso almacenada para la revocación.

Las políticas de acceso almacenadas residen en contenedores, recursos compartidos de archivos, colas o tablas y definen un conjunto reutilizable de restricciones (permisos, inicio, expiración). Al crear una SAS, haga referencia a la política por su identificador. Esto permite la revocación centralizada o el ajuste del ámbito sin tener que volver a emitir todos los tokens SAS; actualizar o eliminar la política afecta inmediatamente a todos los tokens SAS vinculados a ella. Rote las claves de cuenta regularmente si se utilizan SAS de servicio o de cuenta, y supervise el uso a través de la configuración de diagnóstico y los registros de Azure Monitor.

Escenario de Problema Práctico

Adobe está desplegando un portal de procesamiento de medios multi-tenant en Azure. Los clientes inician sesión con sus propios tenants de Microsoft Entra ID, suben archivos multimedia grandes directamente a Blob storage y rastrean el estado del procesamiento. La solución debe evitar almacenar secretos, centralizar los permisos y garantizar la recuperabilidad de los secretos durante al menos 90 días.

1. Registrar aplicaciones en Microsoft Entra ID:

   • Crear una SPA para la UI del portal y un cliente confidencial para la API de backend. Exponer ámbitos de API para acceso delegado y definir roles de aplicación para trabajos en segundo plano. Configurar la SPA para usar el flujo de código de autorización + PKCE con URIs de redirección exactos. Esto alinea cada cliente con el flujo OAuth correcto y aplica límites de consentimiento de privilegio mínimo.

2. Implementar MSAL en la SPA y el backend:

   • La SPA adquiere tokens para la API de backend usando AcquireTokenInteractive/AcquireTokenSilent con consentimiento incremental. El backend usa AcquireTokenOnBehalfOf para llamar a Microsoft Graph y leer el perfil básico del usuario que ha iniciado sesión. Esto preserva el contexto del usuario de extremo a extremo y minimiza las solicitudes de autenticación mediante el almacenamiento en caché de tokens.

3. Habilitar identidades administradas asignadas por el sistema en App Service (API) y Azure Functions (procesadores de medios):

   • Asignar los roles Storage Blob Data Contributor en el contenedor de medios y Key Vault Secrets User en el almacén. Las identidades administradas eliminan la proliferación de secretos y permiten que la plataforma rote las credenciales automáticamente, al tiempo que habilitan el acceso seguro a Storage y Key Vault a través de Azure RBAC.

4. Configurar Azure Key Vault con plano de datos RBAC, eliminación temporal (soft delete) y protección contra purga:

   • Almacenar certificados de firma para la aserción del backend, claves de API de terceros y cualquier secreto de conexión que no pueda ser reemplazado por AAD. Aplicar protección contra purga más eliminación temporal para garantizar la recuperación durante 90 días. RBAC simplifica la auditoría y escala entre entornos en comparación con las políticas de acceso por almacén.

5. Usar referencias de Key Vault para la configuración:

   • Hacer referencia a secretos en la configuración de la aplicación de App Service y Functions usando @Microsoft.KeyVault(SecretUri=…). La plataforma resuelve y actualiza los valores con la identidad administrada, eliminando cambios en el código y evitando que los secretos se almacenen en texto plano en la configuración.

6. Delegar subidas directas desde el navegador con SAS:

   • El backend emite tokens SAS de delegación de usuario para un acceso de solo escritura y de corta duración a una ruta de blob específica, limitado por IP y HTTPS. Para herramientas operativas por lotes, crear una SAS de servicio vinculada a una política de acceso almacenada en el contenedor para que los tokens puedan ser revocados de forma centralizada actualizando o eliminando la política. Esto habilita subidas de cliente de alto rendimiento sin exponer las claves de la cuenta y soporta la revocación de emergencia.

7. Integrar Microsoft Graph mínimamente:

   • Solicitar https://graph.microsoft.com/User.Read en la SPA para mostrar el perfil y usar https://graph.microsoft.com/.default en el backend si se requieren permisos de aplicación (con consentimiento previo del administrador). Usar /.default asegura que el backend respete los permisos de aplicación otorgados centralmente y evita solicitar ámbitos excesivos en tiempo de ejecución.

Este diseño utiliza el flujo de código de autorización + PKCE para proteger la SPA, OBO para preservar el contexto del usuario en los servicios posteriores, identidades administradas y RBAC para eliminar secretos, Key Vault con garantías sólidas de recuperación, referencias de Key Vault para la higiene de la configuración, Graph con ámbitos de privilegio mínimo y SAS con políticas de acceso almacenadas para subidas de cliente seguras y revocables.

← Soluciones de contenedores de Azure · Todos los dominios · Gestión de API de Azure →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Microsoft →