Repaso de seguridad, identidad y gobernanza

Datos de Entra ID fundamentales para el examen: Entra ID (anteriormente Azure AD) es el servicio de identidad en la nube de Microsoft; no es lo mismo que Active Directory Domain Services (AD DS) local. Un tenant de Entra ID representa la instancia de identidad en la nube de una organización. Un tenant puede tener varias suscripciones, pero cada suscripción confía exactamente en un tenant. Objetos principales: Users (cuentas individuales), Groups (colecciones de usuarios o dispositivos), Service Principals (identidades de aplicaciones) y Managed Identities (entidades de servicio administradas por Azure).

Una distinción de AZ-900 que suele causar confusión: Azure RBAC controla el acceso a los recursos de Azure (máquinas virtuales, cuentas de almacenamiento y grupos de recursos) y tiene como ámbito las suscripciones, los grupos de recursos o los recursos individuales. Los roles de Entra ID controlan el acceso a los objetos de Entra ID (usuarios, grupos, aplicaciones y dispositivos) y tienen como ámbito el tenant de Entra ID. Un Global Administrator en Entra ID no obtiene automáticamente acceso a las suscripciones de Azure. Un Contributor en Azure RBAC no puede administrar usuarios de Entra ID. Los dos sistemas de roles son independientes.

Multi-Factor Authentication (MFA) requiere que los usuarios verifiquen su identidad con dos o más factores: algo que saben (contraseña), algo que tienen (aplicación autenticadora o SMS) o algo que son (biometría). En Entra ID, MFA se aplica mediante Conditional Access policies. Una directiva de acceso condicional evalúa señales (identidad del usuario, cumplimiento del dispositivo, ubicación y aplicación a la que se accede) y después aplica controles de acceso (requerir MFA, bloquear el acceso o requerir un dispositivo compatible). El examen evalúa qué nivel de licencia de Entra ID incluye el acceso condicional: la respuesta es Entra ID P1 o superior.

El modelo de seguridad Zero Trust de Microsoft se basa en tres principios: Verificar explícitamente — autentique y autorice cada solicitud utilizando todos los puntos de datos disponibles (identidad, ubicación, dispositivo, servicio y clasificación de datos). Usar el acceso con privilegios mínimos — limite el acceso de los usuarios mediante acceso justo a tiempo y acceso estrictamente necesario, así como directivas adaptables basadas en riesgos. Asumir una vulneración — minimice el alcance del impacto segmentando las redes, cifrando de extremo a extremo y utilizando análisis para obtener visibilidad y facilitar la detección de amenazas. El examen AZ-900 espera que identifique los principios de Zero Trust en preguntas basadas en escenarios.

Puntos clave de Defender for Cloud para el examen: proporciona un Secure Score, un porcentaje que indica en qué medida su entorno sigue las recomendaciones de seguridad de Microsoft. Las recomendaciones se agrupan en controles de seguridad (como «Remediate security configurations» e «Implement advanced data security»). Defender for Cloud funciona en Azure, en entornos locales (mediante Azure Arc) y en otras nubes. Hay dos modos: Free (solo CSPM básico y recomendaciones de seguridad) y Defender plans (de pago, añade protección avanzada contra amenazas para cada tipo de carga de trabajo: máquinas virtuales, SQL, Storage, Containers, etc.).

Datos de Azure Key Vault para el examen: Key Vault almacena tres tipos de objetos: Secrets (contraseñas y cadenas de conexión), Keys (claves RSA o EC para operaciones de cifrado) y Certificates (certificados X.509 con administración del ciclo de vida). El acceso a Key Vault se controla mediante RBAC (más reciente y recomendado) o mediante el modelo heredado Key Vault Access Policy. Key Vault se integra con managed identity para que las aplicaciones nunca almacenen credenciales. Key Vault tiene dos niveles: Standard (claves protegidas por software) y Premium (claves respaldadas por HSM con certificación FIPS 140-2 Level 2).

Puntos de Azure Policy para el examen: una Policy Definition especifica qué se debe evaluar y qué acción se debe realizar (Audit, Deny, DeployIfNotExists, Modify). Una Policy Assignment aplica una definición a un ámbito (grupo de administración, suscripción o grupo de recursos). Una Policy Initiative (también denominada conjunto de directivas) agrupa varias definiciones. El efecto DeployIfNotExists es especial: implementa automáticamente un recurso de corrección si se cumple la condición (por ejemplo, implementa un agente de Log Analytics en las máquinas virtuales que no lo tienen). Los resultados de cumplimiento se muestran como porcentajes en el panel Compliance.

Datos sobre los grupos de administración: puede anidar grupos de administración hasta 6 niveles de profundidad por debajo de la raíz. El Tenant Root Group es el grupo de administración de nivel superior y se crea automáticamente. Las directivas y asignaciones de RBAC realizadas en el nivel de un grupo de administración se heredan en todos los grupos de administración secundarios y suscripciones situados por debajo. Un diseño empresarial habitual es: raíz → Platform (suscripciones de conectividad, identidad y administración) → Landing Zones (producción y no producción) → suscripciones específicas de cada producto. Esta jerarquía permite una gobernanza centralizada a gran escala.

Datos sobre los bloqueos de recursos: el bloqueo CanNotDelete permite leer y modificar, pero impide eliminar. El bloqueo ReadOnly solo permite operaciones de lectura; no permite modificaciones ni eliminaciones. Los bloqueos se pueden aplicar en el nivel de suscripción, grupo de recursos o recurso, y se heredan en los recursos secundarios. Solo los roles Owner y User Access Administrator pueden crear o eliminar bloqueos. Las etiquetas de recursos son pares de metadatos clave-valor; NO se heredan, a diferencia de los bloqueos y las directivas. Se permiten hasta 50 etiquetas por recurso, con un nombre de etiqueta de 512 caracteres como máximo y un valor de 256 caracteres.

Servicios de seguridad de red de AZ-900: Azure DDoS Protection Basic es gratuito y protege automáticamente todos los recursos de Azure frente a ataques DDoS comunes de las capas 3 y 4. Azure DDoS Protection Standard es de pago (aproximadamente 2944 USD al mes por VNet protegida), y añade ajuste adaptable, métricas de ataques en tiempo real y análisis posteriores a los ataques. Azure Firewall es un firewall con estado administrado, con alta disponibilidad integrada y escalado automático; no es un NSG. Azure Firewall funciona en la capa 7 (reglas de aplicación con filtrado FQDN), mientras que los NSG funcionan en la capa 4 (reglas de puertos e IP).

Patrones habituales de escenarios de seguridad de AZ-900:

• Evitar la eliminación accidental de una máquina virtual → bloqueo de recursos (CanNotDelete)
• Obligar a que todos los recursos tengan una etiqueta CostCentre → Azure Policy (efecto Deny)
• Alertar cuando un usuario inicia sesión desde una ubicación inusual → Entra ID Identity Protection / Conditional Access
• Almacenar de forma segura la contraseña de la base de datos de una aplicación → Azure Key Vault Secret
• Ver las recomendaciones de seguridad y la puntuación de cumplimiento → Secure Score de Microsoft Defender for Cloud
• Detectar amenazas en los registros de auditoría de la suscripción → Microsoft Sentinel

Compruebe su comprensión de los conceptos de Microsoft Azure Fundamentals (AZ-900) tratados en esta lección.

En esta lección ha repasado: Entra ID frente a Azure RBAC (dos sistemas independientes de control de acceso para la identidad en la nube y los recursos de Azure), Secure Score de Defender for Cloud (mide la postura de seguridad y muestra recomendaciones) y los bloqueos ReadOnly prevalecen sobre RBAC (ni siquiera los Owners pueden escribir en recursos bloqueados como ReadOnly). A continuación trataremos la estrategia del examen y la gestión del tiempo para AZ-900.