Security

Defender for Containers en GA en Azure Government y AKS Automatic K8s gated deployment

Resumen

La semana del 22 de abril cierra el ciclo de novedades del primer cuatrimestre de 2026 con dos GAs relevantes en Defender for Cloud: Defender for Containers alcanza GA en Azure Government —igualando la paridad con la nube comercial— y Kubernetes gated deployment en AKS Automatic pasa a GA (disponible desde el 12 de marzo). Este último permite bloquear automáticamente el despliegue de cargas de trabajo en AKS que no cumplan las políticas de seguridad definidas en Defender for Cloud, sin intervención manual.

Defender for Containers GA en Azure Government

Hasta ahora, los clientes en Azure Government tenían acceso limitado a Defender for Containers. Con la GA de abril 2026, las capacidades disponibles en la nube comercial son ahora paridad completa:

Habilitar en Azure Government

# Conectarse al entorno de Government
az cloud set --name AzureUSGovernment
az login

# Habilitar Defender for Containers
az security pricing create \
  --name Containers \
  --tier Standard

AKS Automatic K8s Gated Deployment (GA desde 12 marzo)

¿Qué es Kubernetes Gated Deployment?

Gated Deployment integra Defender for Cloud con el flujo de despliegue de AKS Automatic. Cuando un deployment llega al cluster, la gate evalúa el estado de seguridad antes de permitir que los pods se inicien:

flowchart LR
    DEV[Developer\nkubectl apply] --> API[AKS API Server]
    API --> GATE[Security Gate\nDefender for Cloud]
    GATE --> EVAL{Evaluación}
    EVAL -->|Cumple políticas| OK[Pods iniciados]
    EVAL -->|No cumple| BLOCK[Deployment bloqueado\nEvento de auditoría]
    BLOCK --> ALT[Alerta en\nDefender for Cloud]

Qué políticas puede evaluar la gate

• Imagen con vulnerabilidades críticas no parcheadas
• Imagen desde registry no confiable
• Contenedor con privileged: true sin excepción
• Ausencia de readiness/liveness probes
• Uso de latest como tag de imagen

Habilitar Gated Deployment

Requiere AKS Automatic (no AKS Standard):

# Crear cluster AKS Automatic con Gated Deployment
az aks create \
  --resource-group myRG \
  --name myAKSAutomatic \
  --tier standard \
  --aks-custom-headers AKSHTTPCustomFeatures=Microsoft.ContainerService/AKSAutomatic \
  --enable-defender \
  --defender-config '{
    "gatedDeployment": {
      "enabled": true,
      "blockOnVulnerabilities": true,
      "blockOnUntrustedRegistry": true
    }
  }'

Configurar excepciones

Para workloads legítimas que requieren privilegios especiales:

apiVersion: v1
kind: Pod
metadata:
  name: my-privileged-pod
  annotations:
    security.microsoft.com/gated-deployment-exception: "approved"
    security.microsoft.com/gated-deployment-approver: "security-team"
    security.microsoft.com/gated-deployment-reason: "Required for node monitoring"
spec:
  containers:
  - name: monitor
    image: myacr.azurecr.io/node-monitor:1.2.3  # imagen con tag explícito
    securityContext:
      privileged: true

Integrar Gated Deployment con el pipeline CI/CD

La práctica recomendada es que los problemas se detecten antes de llegar al cluster:

flowchart LR
    PR[Pull Request] --> SAST[Análisis estático\nDefender for DevOps]
    SAST --> BUILD[Build imagen]
    BUILD --> SCAN[Scan de imagen\nMicrosoft Defender]
    SCAN --> PUSH[Push a ACR]
    PUSH --> DEPLOY[kubectl apply]
    DEPLOY --> GATE[Gated Deployment\nDefender for Cloud]
    GATE --> PROD[Producción]

La gate actúa como última línea de defensa, no como sustituto del análisis en pipeline.

Buenas prácticas

• Empieza con la gate en modo audit (solo registra, no bloquea) para identificar qué deployments existentes no cumplirían las políticas antes de activar el bloqueo.
• Define un proceso de gestión de excepciones claro: quién aprueba, cuánto tiempo dura la excepción y cómo se revisa.
• Para Azure Government: verifica que las políticas de seguridad de tu agencia permiten el uso de capacidades en preview (como Code to Runtime) antes de habilitarlas.

# Ver eventos de gated deployment en el cluster
kubectl get events --namespace kube-system |
    grep -i "gated\|blocked\|security"

Referencias

• Defender for Cloud - What's new - March/April 2026
• Kubernetes gated deployment in AKS
• Defender for Containers in Azure Government
• AKS Automatic overview

Defender for Cloud: protección de modelos de IA en Azure ML registries y workspaces

Resumen

El 30 de marzo de 2026, Defender for Cloud lanzó en preview la protección de seguridad para modelos de IA en Azure Machine Learning. Cubre dos activos críticos de MLOps: los model registries (donde se almacenan y versionan los modelos) y los workspaces (donde se entrenan y despliegan). La feature detecta anomalías en acceso a modelos, cambios no autorizados en artefactos y comportamientos de inferencia sospechosos en endpoints desplegados.

¿Por qué proteger los modelos de ML?

Los modelos de ML son activos de alto valor y vectores de ataque emergentes:

flowchart TD
    REG[Model Registry\nAzure ML] --> D[Defender for Cloud\nAI Model Security]
    WS[ML Workspace] --> D
    EP[Inference Endpoint] --> D
    D --> A1[Acceso anómalo\nal registro]
    D --> A2[Cambio no autorizado\nen artefacto]
    D --> A3[Comportamiento\nde inferencia inusual]
    A1 & A2 & A3 --> ALT[Security Alert\nDefender for Cloud]

Qué detecta la preview

En Model Registries

• Descarga masiva de artefactos de modelos fuera del patrón habitual
• Acceso desde IPs o identidades no habituales al registro
• Cambios en versiones de modelos sin actividad de entrenamiento previa (posible sustitución)

En Workspaces

• Notebooks que acceden a datasets fuera del scope del proyecto
• Jobs de entrenamiento con destinos de almacenamiento inusuales
• Acceso a secretos del workspace desde identidades no esperadas

En Inference Endpoints

• Volumen de requests anómalo (posible model extraction)
• Prompts con patrones de adversarial attack detectados
• Respuestas que contienen patrones de PII no esperados

Habilitar la protección

Requiere Defender for Azure Machine Learning habilitado:

az security pricing create \
  --name MachineLearning \
  --tier Standard

Verificar que los workspaces están cubiertos

az security pricing show --name MachineLearning \
  --query "{Tier:pricingTier, Extensions:extensions}" \
  --output json

Revisar alertas de AI model security

En Defender for Cloud → Security alerts, filtra por categoría Machine Learning:

# Listar alertas activas de ML vía CLI
az security alert list \
  --query "[?contains(alertType,'MachineLearning')].{Alert:alertDisplayName, Severity:severity, Time:timeGeneratedUtc}" \
  --output table

KQL para Microsoft Sentinel

SecurityAlert
| where ProductName == "Azure Defender for Machine Learning"
| extend ResourceId = tostring(Entities[0].ResourceId)
| summarize Alerts = count() by AlertDisplayName, Severity, bin(TimeGenerated, 1d)
| sort by Alerts desc

Recomendaciones de endurecimiento para workspaces de ML

Defender for Cloud genera recomendaciones específicas para reducir la superficie de ataque:

• Desactivar acceso público al workspace: usar Private Link
• Restringir el rol Contributor del workspace a pipelines de CI/CD solamente
• Habilitar customer-managed keys para el storage de artefactos
• Activar audit logging en el workspace

# Deshabilitar acceso público al workspace de Azure ML
az ml workspace update \
  --name myWorkspace \
  --resource-group myRG \
  --public-network-access Disabled

Buenas prácticas

• Aplica el principio de mínimo privilegio en el acceso a model registries: separa roles de lectura (para inferencia) y escritura (para pipelines de entrenamiento).
• Versiona los modelos con checksums verificables y almacénalos en contenedores de storage con immutability policies habilitadas.
• Configura alertas de Azure Monitor en los inference endpoints para detectar picos de uso fuera de las horas habituales.

Referencias

• Defender for Cloud - What's new - March 2026
• Threat protection for AI workloads in Azure ML
• Security best practices for Azure Machine Learning

Defender for Storage: remediación automática de malware en GA y escaneo bajo demanda para Azure Files

Resumen

El 31 de marzo de 2026, Defender for Storage alcanza GA en dos funcionalidades de alto impacto: automated malware remediation (eliminación automática de blobs infectados en Blob Storage) y on-demand malware scanning para Azure Files en preview. Si tienes flujos de upload de ficheros de usuario o compartición de ficheros en Azure, estas novedades reducen el tiempo de exposición ante ficheros maliciosos de horas a minutos.

¿Qué es Defender for Storage?

Defender for Storage analiza el contenido subido a cuentas de Azure Storage en busca de malware, datos sensibles y anomalías de acceso. Hasta ahora, cuando detectaba malware, generaba una alerta pero no tomaba acción automática: el blob infectado permanecía en el storage hasta que alguien lo eliminaba manualmente.

Automated Malware Remediation (GA)

Con esta funcionalidad en GA, cuando se detecta un blob infectado:

1. Defender for Storage genera la alerta habitual
2. Automáticamente mueve o elimina el blob infectado según la configuración
3. Escribe un log del evento con hash del fichero, contenedor de origen y acción tomada

sequenceDiagram
    participant U as Usuario/App
    participant S as Azure Blob Storage
    participant D as Defender for Storage
    participant Q as Quarantine Container

    U->>S: Upload fichero
    S->>D: Notificación de nuevo blob
    D->>D: Análisis antimalware
    alt Limpio
        D-->>S: OK - blob queda disponible
    else Infectado
        D->>Q: Mover blob a cuarentena
        D-->>S: Blob eliminado del contenedor original
        D->>D: Alerta + log de evento
    end

Configurar automated remediation

Desde el portal: Defender for Cloud → Environment settings → [Storage account] → Malware scanning → Remediation action

O vía ARM/Bicep:

resource storageDefender 'Microsoft.Security/defenderForStorageSettings@2022-12-01-preview' = {
  name: 'current'
  scope: storageAccount
  properties: {
    isEnabled: true
    malwareScanning: {
      onUploadIsEnabled: true
      sensitiveDataDiscovery: {
        isEnabled: true
      }
    }
    overrideSubscriptionLevelSettings: true
  }
}

Para la acción de remediación automática, configura la Event Grid subscription que Defender for Storage usa internamente:

# La acción de remediación se configura en el portal de Defender for Cloud
# Settings > Malware scanning > On detection: Delete / Move to quarantine

On-demand Malware Scanning para Azure Files (Preview)

Azure Files (SMB y NFS) ahora puede analizarse bajo demanda. Esto cubre el caso de uso de:

• Comparticiones de ficheros legados que ya tenían contenido antes de habilitar Defender
• Auditorías periódicas de storage compartido
• Respuesta a incidentes para escanear una compartición sospechosa

Iniciar un escaneo bajo demanda

# Via Azure CLI (preview extension)
az security storage malware-scan trigger \
  --resource-group myRG \
  --storage-account myStorageAccount \
  --share-name myFileShare

O desde el portal: Storage account → Microsoft Defender for Cloud → Scan now

Revisar resultados

# Los resultados aparecen en Log Analytics si tienes Diagnostic Settings configurado
# Query KQL
AzureDiagnostics
| where Category == "StorageMalwareScan"
| where OperationName == "ScanCompleted"
| project TimeGenerated, ResourceId, ResultType, FilePath, ThreatName
| sort by TimeGenerated desc

Consideraciones de coste

Defender for Storage cobra por:

• Transacciones analizadas (on-upload scanning): tarifa por millón de transacciones
• GB escaneados (on-demand scan): tarifa por GB analizado

Buenas prácticas

• Configura el contenedor de cuarentena con acceso restringido: solo los admins de seguridad deben poder acceder a los ficheros en cuarentena para análisis forense.
• Integra las alertas de Defender for Storage con Microsoft Sentinel para correlacionar con otros eventos de seguridad.
• Para Azure Files, programa escaneos bajo demanda periódicos en comparticiones de acceso externo o compartido entre equipos.

Referencias

• Defender for Cloud - What's new - March 2026
• Malware scanning in Defender for Storage
• Configure automated malware remediation

Defender for Cloud: Code to Runtime, visibilidad de la cadena SDLC hasta producción

Resumen

El 10 de marzo de 2026, Defender for Cloud lanzó en preview Code to Runtime enrichment, una funcionalidad que conecta una vulnerabilidad encontrada en código fuente o imagen de contenedor con su radio de explosión en producción: qué recursos del cluster están expuestos, qué identidades pueden acceder a ellos y qué flujos de red están activos. Está diseñada para que los equipos de seguridad prioricen remediaciones no por criticidad CVSS, sino por impacto real.

¿Qué problema resuelve?

Un scanner de imágenes puede generar cientos de CVEs por semana. Sin contexto de producción, es imposible decidir cuáles parchear primero.

Code to Runtime enrichment responde a:

• ¿Este CVE está en un contenedor que está realmente corriendo en producción?
• ¿Ese pod tiene permisos de RBAC para acceder a secrets o APIs críticas?
• ¿Hay tráfico de red real hacia ese pod desde internet?

flowchart LR
    A["Repositorio
    de código"] -->|Scan SAST| B["CVE en librería"]
    B -->|Enriquecimiento| C["¿Imagen desplegada
    en producción?"]
    C -->|Sí| D["Pod en AKS"]
    D --> E["Permisos RBAC
    del pod"]
    D --> F["Tráfico de red
    hacia el pod"]
    D --> G["Datos accesibles
    desde el pod"]
    E & F & G --> H["Blast radius score"]
    H --> I["Prioridad de remediación"]

Fuentes de datos que correlaciona

Requisitos para habilitar la funcionalidad

• Defender for Containers habilitado (plan Standard)
• Defender for DevOps conectado a al menos un repositorio (GitHub o Azure DevOps)
• AKS con el agente de Defender instalado

# Verificar que el agente de Defender está instalado en AKS
kubectl get daemonset -n kube-system | grep defender

# Habilitar Defender for DevOps (requiere conexión al repositorio desde el portal)
az security connector create \
  --name my-github-connector \
  --resource-group myRG \
  --hierarchy-identifier <github-org-id> \
  --environment-name GitHub

Cómo usar Code to Runtime en la práctica

Desde Defender for Cloud → Recommendations → Code to Runtime insights:

1. Selecciona un CVE de alta criticidad
2. Observa el panel Runtime context: te muestra si hay pods afectados en producción
3. Revisa Blast radius: identidades, secretos y endpoints accesibles desde el pod vulnerable
4. Exporta el path completo para el equipo de desarrollo con contexto de priorización

Consulta KQL en Microsoft Sentinel (si integrado)

SecurityRecommendation
| where RecommendationName contains "Code to Runtime"
| extend BlastRadius = tostring(Properties["blastRadiusScore"])
| where toint(BlastRadius) > 70
| project TimeGenerated, AffectedResourceId, RecommendationName, BlastRadius
| sort by BlastRadius desc

Limitaciones en preview

• Actualmente cubre AKS únicamente (no otros runtimes de contenedores)
• La correlación con código fuente requiere que el repositorio esté conectado a Defender for DevOps
• No hay SLA de latencia para la actualización del blast radius cuando cambia el estado del cluster

Buenas prácticas

• Integra Code to Runtime en tu proceso de revisión de vulnerabilidades semanal o quincenal; no como alerta en tiempo real.
• Combina el blast radius score con el SLA de parches de tu organización para crear una matriz de priorización: CVE crítico + blast radius alto → parche urgente.
• Usa los datos de permisos RBAC del pod para aplicar el principio de mínimo privilegio: si un pod tiene acceso a secrets que no necesita, es el momento de reducirlo.

Referencias

• Defender for Cloud - What's new - March 2026
• Code to runtime context overview
• Defender for DevOps overview

Azure Key Vault API 2026-02-01: RBAC como modelo de autorización por defecto

Resumen

Con la versión de API 2026-02-01 de Azure Key Vault, RBAC se convierte en el modelo de autorización por defecto para nuevas vaults. Las vaults creadas sin especificar explícitamente el modelo de acceso ya no usarán Vault Access Policies; usarán RBAC de Azure. Este cambio alinea Key Vault con el resto de servicios de Azure y simplifica la gestión de accesos, pero requiere atención si tienes scripts o plantillas de IaC que asumen el comportamiento anterior.

Vault Access Policies vs. RBAC: la diferencia clave

Roles built-in relevantes para Key Vault

Key Vault Administrator         → Acceso completo (gestión + datos)
Key Vault Certificates Officer  → Gestión de certificados
Key Vault Crypto Officer        → Gestión de claves
Key Vault Secrets Officer       → Gestión de secrets
Key Vault Reader                → Lectura de metadatos (sin leer valores)
Key Vault Secrets User          → Leer valores de secrets
Key Vault Crypto User           → Usar claves (encrypt, decrypt, sign)

Crear una vault con RBAC (nueva API)

Con la API 2026-02-01, RBAC es el default. No es necesario especificar el parámetro enableRbacAuthorization:

az keyvault create \
  --name myVault \
  --resource-group myRG \
  --location westeurope
  # enableRbacAuthorization = true por defecto

Para crear una vault con Access Policies (modelo anterior) hay que ser explícito:

az keyvault create \
  --name myVault \
  --resource-group myRG \
  --location westeurope \
  --enable-rbac-authorization false

Migrar una vault existente de Access Policies a RBAC

flowchart LR
    A["Vault con
    Access Policies"] --> B["Inventariar
    permisos actuales"]
    B --> C["Crear role assignments
    equivalentes en RBAC"]
    C --> D["Validar acceso
    de aplicaciones"]
    D --> E["Activar RBAC
    en la vault"]
    E --> F["Vault con
    Azure RBAC"]

Paso 1: Inventariar Access Policies actuales

az keyvault show \
  --name myVault \
  --query "properties.accessPolicies[].{Object:objectId, Permissions:permissions}" \
  --output table

Paso 2: Crear role assignments equivalentes

VAULT_ID=$(az keyvault show --name myVault --query id -o tsv)

# Dar acceso a secrets a una Managed Identity
az role assignment create \
  --assignee <principal-id> \
  --role "Key Vault Secrets User" \
  --scope "$VAULT_ID"

# Acceso más restrictivo: solo a un secret específico
az role assignment create \
  --assignee <principal-id> \
  --role "Key Vault Secrets User" \
  --scope "$VAULT_ID/secrets/myDatabasePassword"

Paso 3: Activar RBAC

az keyvault update \
  --name myVault \
  --enable-rbac-authorization true

Actualizar templates Bicep/Terraform

Bicep

resource keyVault 'Microsoft.KeyVault/vaults@2026-02-01' = {
  name: vaultName
  location: location
  properties: {
    sku: {
      family: 'A'
      name: 'standard'
    }
    tenantId: subscription().tenantId
    enableRbacAuthorization: true  // explícito por claridad
    enableSoftDelete: true
    softDeleteRetentionInDays: 90
  }
}

Terraform

resource "azurerm_key_vault" "main" {
  name                       = var.vault_name
  resource_group_name        = var.resource_group_name
  location                   = var.location
  tenant_id                  = data.azurerm_client_config.current.tenant_id
  sku_name                   = "standard"
  enable_rbac_authorization  = true  # default en API 2026-02-01, pero explícito aquí
  soft_delete_retention_days = 90
  purge_protection_enabled   = true
}

Buenas prácticas

• Usa el scope más restrictivo posible para los role assignments: un secret específico en lugar de toda la vault cuando sea posible.
• Activa Privileged Identity Management (PIM) para roles con acceso a datos (Secrets Officer, Crypto Officer) y exige justificación y aprobación para activarlos.
• Revisa periódicamente los role assignments con Microsoft Entra ID Access Reviews.

Referencias

• Azure Key Vault REST API 2026-02-01
• Azure built-in roles for Key Vault
• Migrate from Vault Access Policy to Azure RBAC

Defender for Cloud: anti-malware en runtime y bloqueo de binary drift en contenedores

Resumen

El 22 de febrero de 2026, Defender for Cloud publicó dos nuevas capacidades en preview para seguridad de contenedores en runtime: anti-malware scanning en pods de Kubernetes y binary drift blocking. Ambas operan a nivel de nodo, sin modificar las imágenes, y amplían la protección más allá del análisis estático de imágenes de contenedor. Son especialmente relevantes para equipos que ejecutan cargas de trabajo en AKS y necesitan detección de amenazas en tiempo de ejecución.

¿Qué problema resuelven?

El análisis de imágenes (Defender for Containers ya lo hacía) detecta vulnerabilidades y malware conocido antes del despliegue. Pero no cubre:

• Malware descargado o generado en runtime dentro de un contenedor
• Binarios que aparecen en el sistema de ficheros del contenedor después del inicio (binary drift)

Estos dos vectores son los usados habitualmente en ataques post-compromiso a clusters Kubernetes.

flowchart TD
    A[Imagen de contenedor] --> B[Análisis estático\nDefender for Containers]
    B --> C[Pod en ejecución]
    C --> D[Runtime protection\nNueva en preview feb 2026]
    D --> E[Anti-malware scanning\nScanning de ficheros en memoria/disco]
    D --> F[Binary drift detection\nBinarios añadidos tras inicio]
    E --> G[Alerta en Defender for Cloud]
    F --> G
    G --> H{Acción configurada}
    H --> I[Alertar]
    H --> J[Bloquear - blocking mode]

Anti-malware scanning en runtime

Escanea ficheros en los sistemas de ficheros de contenedores activos en busca de firmas de malware conocido y comportamiento heurístico.

Cobertura: - Ficheros escritos en el sistema de ficheros del contenedor durante runtime - Ficheros en volúmenes montados (emptyDir, PVC) - Memoria de procesos (análisis heurístico)

Modo de despliegue: DaemonSet en los nodos del cluster AKS.

Binary drift blocking

Un contenedor debería ejecutar únicamente los binarios presentes en su imagen original. Si durante el runtime aparece un binario nuevo (descargado con curl, compilado en el contenedor, etc.), se trata de binary drift.

Esta feature puede configurarse en modo alert (solo registra) o block (bloquea la ejecución del binario nuevo).

Habilitar las funcionalidades

Requieren Defender for Containers habilitado en el plan:

# Habilitar Defender for Containers
az security pricing create \
  --name Containers \
  --tier Standard

La protección en runtime se despliega automáticamente como un DaemonSet llamado microsoft-defender-collector-ds en los nodos del cluster.

Verificar el despliegue en AKS

kubectl get daemonset -n kube-system | grep defender

# Output esperado:
# microsoft-defender-collector-ds   <node-count>   <node-count>   ...

Configurar binary drift en modo blocking

En el portal de Defender for Cloud → Environment settings → [Tu suscripción] → Defender plans → Containers → Settings

O vía API:

az security setting update \
  --name "Containers" \
  --input-type "binaryDriftPolicy" \
  --value '{"mode": "Block"}'

Alertas generadas

En Defender for Cloud → Security alerts, busca categoría Containers:

Buenas prácticas

• Implementa read-only root filesystems en los pods que no necesiten escritura. Esto previene binary drift por diseño antes de que la feature tenga que bloquearlo.

# securityContext en el pod spec
securityContext:
  readOnlyRootFilesystem: true

• Usa el modo Alert durante las primeras semanas para identificar procesos legítimos que podrían activar falsos positivos.
• Correlaciona las alertas de binary drift con los logs de tu pipeline CI/CD para confirmar si el binario fue introducido por un proceso propio o por un atacante.

Referencias

• Defender for Cloud - What's new - February 2026
• Container runtime protection overview
• Binary drift detection

Defender for Cloud: CIEM en GA y threat protection para agentes de IA en preview

Resumen

La semana del 2 de febrero de 2026 fue relevante para Defender for Cloud: el módulo CIEM (Cloud Infrastructure Entitlement Management) alcanzó GA, y al día siguiente —3 de febrero— se lanzó en preview la protección contra amenazas para AI agents. Son dos novedades independientes pero complementarias: la primera para gestionar el exceso de permisos en identidades cloud, la segunda para detectar ataques emergentes en sistemas que usan modelos de lenguaje como agentes autónomos.

CIEM GA: gestión de permisos con lookback de 90 días

¿Qué es CIEM en Defender for Cloud?

CIEM analiza los permisos efectivos de identidades en Azure (usuarios, service principals, managed identities) y los compara con su uso real. El resultado es una lista de recomendaciones de reducción de permisos basadas en actividad.

Diferencia clave con RBAC estático: CIEM observa qué permisos se usan realmente durante un período de tiempo, no solo qué permisos están asignados.

Qué trae la versión GA

flowchart LR
    A[Identidad Azure] --> B[CIEM Engine\nDefender for Cloud]
    B --> C[Análisis de actividad\n90 días lookback]
    C --> D{¿Permiso usado?}
    D -->|Sí| E[Permiso necesario]
    D -->|No| F[Recomendación:\nRevocar permiso]
    F --> G[Security Posture Score]

Cómo revisar las recomendaciones CIEM

Desde el portal de Defender for Cloud:

Defender for Cloud → Recommendations → Identity and access

O directamente vía REST API:

az security assessment list \
  --scope /subscriptions/<sub-id> \
  --query "[?contains(name,'identity')].{Name:displayName, Status:status.code}" \
  --output table

Threat Protection para AI Agents: preview

¿Qué detecta?

Los AI agents son sistemas que usan LLMs para ejecutar acciones autónomas (llamar APIs, leer bases de datos, modificar recursos). Esta preview añade detección de:

• Prompt injection: intentos de manipular el comportamiento del agente mediante inputs maliciosos
• Jailbreak attempts: intentos de evadir las instrucciones del system prompt
• Anomalous tool use: el agente accede a herramientas o datos fuera de su patrón habitual
• Data exfiltration via LLM output: el agente devuelve datos sensibles embebidos en respuestas

Cobertura actual

La preview cubre agentes construidos sobre:

• Azure OpenAI (GPT-4o, GPT-4)
• Azure AI Foundry (agentes con herramientas)

Habilitar la protección

Requiere Defender for AI Services habilitado:

az security pricing create \
  --name AiServices \
  --tier Standard

Las alertas aparecerán en Defender for Cloud → Security alerts con categoría AI.

Buenas prácticas combinadas

• Usa CIEM para revisar los permisos de la Managed Identity que usa tu AI agent. Los agentes tienden a requerir permisos amplios; CIEM ayuda a detectar si puedes restringirlos.
• Configura alertas CIEM en Azure Monitor para recibir notificaciones cuando una identidad no usa un permiso durante más de 60 días.
• Para AI agents en producción, habilita logging detallado de inputs/outputs y almacénalos en Log Analytics; las alertas de Defender for AI se correlacionan con estos logs.

# Exportar recomendaciones CIEM a CSV para revisión
az security assessment list \
  --scope /subscriptions/<sub-id> \
  --query "[?contains(name,'identity')]" \
  --output json > ciem-recommendations.json

Referencias

• Defender for Cloud - What's new - February 2026
• Cloud Infrastructure Entitlement Management (CIEM)
• Threat protection for AI workloads

Azure DevOps Pipelines: environments, approvals y seguridad de secretos

Resumen

Azure DevOps Pipelines permite CI/CD seguro con environments, approvals y gestión avanzada de secretos. Este post va directo: cómo definir environments, configurar approvals, proteger secretos y auditar despliegues.

¿Qué es Pipelines avanzado?

• Environments para dev, test, prod
• Approvals y checks antes de despliegue
• Secure secrets (Key Vault, variable groups)
• Auditoría y compliance
• Integración con Azure Monitor

Arquitectura / Cómo funciona

flowchart LR
    Dev[Dev] --> Repo[Repo]
    Repo --> Pipeline[Pipeline]
    Pipeline --> Env1[Environment: Dev]
    Pipeline --> Env2[Environment: Prod]
    Pipeline -.-> KeyVault[Key Vault]
    Pipeline -.-> Monitor[Azure Monitor]

Definir environments y approvals

1. Crear environment:

   # Portal: Pipelines > Environments > New environment
   # Ejemplo: "prod-env"
   

2. Configurar approval:

   environments:
     - name: prod-env
       resourceType: VirtualMachine
       approval:
         steps:
           - script: echo "Aprobado por admin"
   

3. Checks avanzados:

4. Deployment gates (Azure Monitor, REST API, Query Work Item)

Seguridad de secretos

• Usar Azure Key Vault:

  variables:
  - group: kv-secrets
  steps:
  - task: AzureKeyVault@2
    inputs:
      azureSubscription: 'MySub'
      KeyVaultName: 'kv-prod'
      SecretsFilter: 'DbPassword,ApiKey'
      RunAsPreJob: true
  

• Variable groups (portal):

  # Pipelines > Library > Variable groups > Link secrets
  

• Secure files (certificados, pfx):

  # Pipelines > Library > Secure files
  

Auditoría y compliance

• Auditar deployments:

  az pipelines runs list --pipeline-name "prod-pipeline"
  

• Monitorizar cambios:

  az monitor activity-log list --resource-group $RESOURCE_GROUP
  

• Alertas por cambios no aprobados:

  az monitor metrics alert create --name alert-unapproved --resource-group $RESOURCE_GROUP --scopes /subscriptions/$SUB_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.DevOps/pipelines/prod-pipeline --condition "total UnapprovedDeployments > 0" --window-size 5m --action $ACTION_GROUP_ID
  

Buenas prácticas

• Usar environments y approvals en todos los despliegues a prod
• Proteger secretos en Key Vault o variable groups
• Auditar deployments y cambios semanalmente
• Integrar alertas con Monitor y Sentinel
• Usar secure files para certificados

Costes

• Azure DevOps: gratis hasta 1,800 min/mes
• Key Vault: ~$0.03/secret/mes
• Monitor: ~$2.30/GB

Referencias

• Azure DevOps Environments
• Approvals and Checks
• Key Vault Integration
• Audit and Compliance

Azure Bicep avanzado: testing, linting y despliegue seguro multi-entorno

Resumen

Bicep permite IaC declarativo en Azure, pero en producción necesitas testing, linting y despliegue seguro por entorno. Este post va al grano: cómo testear plantillas, usar linting, parametrizar para dev/prod y evitar errores comunes.

¿Qué es Bicep avanzado?

• Modularización y reutilización
• Testing de plantillas antes de deploy
• Linting para calidad y seguridad
• Parametrización por entorno (dev, prod, test)
• Integración con pipelines CI/CD

Arquitectura / Cómo funciona

flowchart LR
    Dev[Dev] --> CI[CI Pipeline]
    CI --> Lint[Lint]
    CI --> Test[Test]
    CI --> Deploy[Deploy]
    Deploy --> Azure[Azure]
    Azure --> RG1[Resource Group Dev]
    Azure --> RG2[Resource Group Prod]

Testing de plantillas Bicep

1. Validar sintaxis:

   bicep build main.bicep
   

2. Test de despliegue (dry-run):

   az deployment sub validate \
     --location westeurope \
     --template-file main.bicep \
     --parameters environment="dev"
   

3. Test unitario con PSRule for Azure:

   pwsh -c "Invoke-PSRule -Path ./main.bicep"
   

Linting y calidad

• Usar bicep linter:

  bicep build main.bicep
  bicep linter main.bicep
  

• Reglas custom en .bicepconfig.json:

  {
    "analyzers": {
      "core": {
        "rules": {
          "no-hardcoded-secrets": "warning",
          "secure-parameters": "error"
        }
      }
    }
  }
  

Parametrización multi-entorno

• Usar parámetros y archivos por entorno:

  az deployment group create \
    --resource-group rg-dev \
    --template-file main.bicep \
    --parameters @dev.parameters.json
  az deployment group create \
    --resource-group rg-prod \
    --template-file main.bicep \
    --parameters @prod.parameters.json
  

• Ejemplo de parámetros:

  {
    "environment": {"value": "dev"},
    "adminPassword": {"value": "SuperSecret123!"}
  }
  

Integración CI/CD

• Pipeline YAML ejemplo:

  trigger:
    - main
  pool:
    vmImage: 'ubuntu-latest'
  steps:
    - script: bicep build main.bicep
      displayName: 'Build Bicep'
    - script: bicep linter main.bicep
      displayName: 'Lint Bicep'
    - script: pwsh -c "Invoke-PSRule -Path ./main.bicep"
      displayName: 'Test Bicep'
    - script: az deployment group create --resource-group rg-dev --template-file main.bicep --parameters @dev.parameters.json
      displayName: 'Deploy Dev'
  

Buenas prácticas

• Nunca hardcodear secretos en plantillas
• Usar Key Vault para parámetros sensibles
• Validar y testear antes de cada despliegue
• Mantener módulos reutilizables y versionados
• Revisar resultados de linting y testing en cada PR

Costes

• Bicep: gratis
• PSRule: gratis
• Azure DevOps: desde $0 (hasta 1,800 min/mes)

Referencias

• Bicep Linter
• PSRule for Azure
• Multi-environment deployments

Scripts de Reporte para Credenciales Federadas de Azure: Visibilidad Total de tus Identidades Administradas

¡Hola a todos! En el mundo de la seguridad en la nube, mantener un control exhaustivo sobre las credenciales federadas es fundamental para una gestión de identidades robusta. Hoy quiero compartir con vosotros una solución que he desarrollado para resolver uno de los retos más comunes: generar reportes completos de las credenciales federadas de identidades administradas en Azure.

Si habéis trabajado con GitHub Actions, Azure DevOps, o cualquier sistema CI/CD que se integre con Azure usando identidades administradas, sabréis lo importante que es tener visibilidad sobre qué credenciales están configuradas, dónde y cómo.

El Problema: Falta de Visibilidad

Cuando gestionáis múltiples suscripciones de Azure con decenas o cientos de identidades administradas, es muy difícil responder a preguntas básicas como:

• ¿Qué credenciales federadas tengo configuradas en todas mis suscripciones?
• ¿Qué repositorios de GitHub tienen acceso a mis recursos de Azure?
• ¿Hay credenciales obsoletas que debería eliminar?
• ¿Cómo puedo auditar todas mis configuraciones de identidad federada?

El portal de Azure nos permite ver esto recurso por recurso, pero no hay una vista consolidada que nos permita tener el "big picture" de toda nuestra configuración de seguridad.

La Solución: Scripts de Reporte Automatizados

He desarrollado una solución completa que incluye scripts tanto en Python como en PowerShell para generar reportes detallados de todas las credenciales federadas de identidades administradas en vuestro entorno Azure.

Características Principales

✅ Soporte Multi-Suscripción: Procesa todas las suscripciones disponibles o las que especifiquéis
✅ Filtrado por Tenant: Permite filtrar suscripciones por tenant específico
✅ Múltiples Formatos: Exporta a JSON, CSV y Excel
✅ Logging Robusto: Logs detallados separados de los datos de salida
✅ Validación de Datos: Evita procesar identidades con datos inválidos
✅ Autenticación Flexible: Soporta Managed Identity, Azure CLI, MFA, etc.
✅ Archivo de Tuplas: Genera un archivo adicional con solo las tuplas de credenciales

¿Qué Información Captura?

Los scripts capturan información completa tanto de las identidades administradas como de sus credenciales federadas:

Información de la Identidad: - Nombre y ID de la identidad - Grupo de recursos y ubicación - Principal ID y Client ID - Tenant ID

Información de las Credenciales Federadas: - Nombre e ID de la credencial - Issuer (emisor) - Subject (sujeto) - Audiences (audiencias) - Descripción y tipo

Metadatos del Reporte: - ID y nombre de la suscripción - Tenant ID - Timestamp del reporte

¿Cómo Empezar?

Requisitos Previos

Para Python:

pip install azure-identity azure-mgmt-msi azure-mgmt-resource pandas openpyxl

Para PowerShell:

Install-Module -Name Az.Accounts, Az.ManagedServiceIdentity, Az.Resources, ImportExcel

Ejemplos de Uso

Script de Python:

# Reporte de todas las suscripciones
python federated-identity-credentials-report.py --all-subscriptions --format excel

# Reporte filtrado por tenant
python federated-identity-credentials-report.py --tenant-id "your-tenant-id" --all-subscriptions --format json

# Reporte de una suscripción específica
python federated-identity-credentials-report.py --subscription-id "12345678-1234-1234-1234-123456789012" --format csv

Script de PowerShell:

# Reporte de todas las suscripciones
.\federated-identity-credentials-report.ps1 -AllSubscriptions -Format Excel

# Reporte filtrado por tenant
.\federated-identity-credentials-report.ps1 -TenantId "your-tenant-id" -AllSubscriptions -Format JSON

# Reporte de un grupo de recursos específico
.\federated-identity-credentials-report.ps1 -SubscriptionId "12345678-1234-1234-1234-123456789012" -ResourceGroupName "my-rg" -Format CSV

Características Avanzadas

Archivo de Tuplas de Credenciales

Además del reporte principal, los scripts generan automáticamente un archivo adicional con solo las tuplas de credenciales (credential_issuer, credential_subject, credential_audiences, credential_type). Esto es especialmente útil para:

• Análisis de patrones de configuración
• Auditorías de seguridad
• Integración con otras herramientas de análisis

Logging Separado

Una característica importante es que los logs nunca se mezclan con los datos de salida. Los logs van a stderr y a un archivo de log separado, mientras que los datos puros van a stdout o al archivo especificado. Esto es crucial para la automatización y integración con pipelines de CI/CD.

Validación de Datos

Los scripts incluyen validación robusta para evitar procesar identidades con nombres vacíos o nulos, lo que puede ocurrir en ciertos escenarios de configuración incompleta.

Casos de Uso Reales

1. Auditoría de Seguridad

# Generar reporte completo en Excel para auditoría
python federated-identity-credentials-report.py --all-subscriptions --format excel --output security-audit-$(date +%Y%m%d).xlsx

2. Cleanup de Credenciales Obsoletas

# Exportar a CSV para análisis con herramientas de datos
python federated-identity-credentials-report.py --all-subscriptions --format csv | grep "old-repo-name"

3. Monitoreo Continuo

# Integrar en pipeline de CI/CD para monitoreo continuo
python federated-identity-credentials-report.py --tenant-id "$TENANT_ID" --all-subscriptions --format json > daily-report.json

Estructura de Archivos Generados

Archivo Principal (federated_identity_credentials_report_YYYYMMDD_HHMMSS.json/csv/xlsx):

[
  {
    "identity_name": "github-actions-identity",
    "identity_id": "/subscriptions/.../userAssignedIdentities/github-actions-identity",
    "identity_resource_group": "security-rg",
    "identity_location": "eastus",
    "credential_name": "GitHub-Main-Branch",
    "credential_issuer": "https://token.actions.githubusercontent.com",
    "credential_subject": "repo:myorg/myrepo:ref:refs/heads/main",
    "credential_audiences": "api://AzureADTokenExchange",
    "subscription_name": "Production",
    "tenant_id": "12345678-1234-1234-1234-123456789012",
    "report_timestamp": "2025-07-01T10:30:00"
  }
]

Archivo de Tuplas (credential_tuples_YYYYMMDD_HHMMSS.json/csv/xlsx):

[
  {
    "credential_issuer": "https://token.actions.githubusercontent.com",
    "credential_subject": "repo:myorg/myrepo:ref:refs/heads/main",
    "credential_audiences": "api://AzureADTokenExchange",
    "credential_type": "Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials"
  }
]

Mejores Prácticas de Uso

1. Automatización

Integrad estos scripts en vuestros pipelines de CI/CD para generar reportes automáticos:

# GitHub Actions ejemplo
- name: Generate Federated Credentials Report
  run: |
    python federated-identity-credentials-report.py --all-subscriptions --format json --output report-${{ github.run_number }}.json

- name: Upload Report as Artifact
  uses: actions/upload-artifact@v3
  with:
    name: federated-credentials-report
    path: report-*.json

2. Monitoreo Regular

Ejecutad los scripts de forma regular (diaria o semanal) para detectar cambios no autorizados:

# Cron job ejemplo
0 6 * * 1 /usr/bin/python3 /path/to/federated-identity-credentials-report.py --all-subscriptions --format excel --output /reports/weekly-$(date +\%Y\%m\%d).xlsx

3. Análisis de Drift

Comparad reportes de diferentes fechas para detectar cambios de configuración:

# Comparar reportes para detectar cambios
diff <(jq -S . report-20250701.json) <(jq -S . report-20250708.json)

Consideraciones de Seguridad

⚠️ Permisos Mínimos: Los scripts requieren permisos de lectura sobre las identidades administradas y sus credenciales federadas
⚠️ Datos Sensibles: Los reportes contienen información de configuración sensible - almacenadlos de forma segura
⚠️ Logs: Revisad los logs regularmente para detectar errores de autenticación o acceso

Conclusión

Tener visibilidad completa sobre las credenciales federadas de vuestras identidades administradas es fundamental para mantener una postura de seguridad sólida en Azure. Estos scripts os permitirán:

• Reducir el riesgo de seguridad mediante auditorías regulares
• Cumplir con requisitos de compliance generando reportes detallados
• Optimizar la gestión identificando credenciales obsoletas o mal configuradas
• Automatizar el monitoreo integrando los scripts en vuestros procesos existentes

Los scripts están disponibles en mi repositorio y son completamente gratuitos y de código abierto. Si os resultan útiles, no dudéis en contribuir con mejoras o reportar issues.

¡Espero que esta herramienta os ayude a mantener vuestros entornos Azure más seguros y mejor documentados!

Enlaces útiles: - 📖 Documentación completa y scripts