Blog

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

AVD: RDP Shortpath UDP sobre Azure Private Link ya es GA

Resumen

Desde febrero de 2026, RDP Shortpath con UDP sobre Azure Private Link es GA en Azure Virtual Desktop. Esto permite que el tráfico de sesión de usuario (no solo el de gestión) viaje por la red privada de Azure en lugar de internet, combinando la baja latencia de UDP de RDP Shortpath con el aislamiento de red de Private Link. Es la opción recomendada para organizaciones con requisitos estrictos de seguridad de red y conectividad ExpressRoute o VPN.

¿Qué combinación es esta?

AVD tiene dos canales de tráfico diferenciados:

Hasta ahora, Private Link cubría el control plane pero el tráfico de sesión podía salir a internet si no había Shortpath Managed. Con esta GA, el tráfico de sesión también puede mantenerse completamente en la red privada usando UDP.

Arquitectura

flowchart LR
    C[Cliente corporativo] --> VPN[ExpressRoute / VPN Gateway]
    VPN --> VNET[VNet corporativa]
    VNET --> PE[Private Endpoint\nAVD Session data]
    PE --> SH[Session Host AKS/VM]

    subgraph Red privada Azure
        PE
        SH
    end

    note1[No hay tráfico de sesión\nque salga a internet]

Requisitos

• Session hosts: Windows 11 22H2 o superior, o Windows Server 2022
• Cliente: Windows App (actualizado) o Remote Desktop client 1.2.5000+
• Red: Private Endpoint desplegado para el servicio de datos de AVD
• RDP Shortpath Managed habilitado en el host pool

Configurar Private Link para tráfico de sesión

1. Crear el Private Endpoint para sesión

En el portal de Azure → Azure Virtual Desktop → tu host pool → Networking → Private endpoints

O vía CLI:

HOSTPOOL_ID=$(az desktopvirtualization hostpool show \
  --resource-group myRG \
  --name myHostPool \
  --query id -o tsv)

az network private-endpoint create \
  --name avd-session-pe \
  --resource-group myRG \
  --vnet-name myVNet \
  --subnet mySubnet \
  --private-connection-resource-id $HOSTPOOL_ID \
  --group-id sessionHost \
  --connection-name avd-session-connection

2. Crear la zona DNS privada y el vínculo

az network private-dns zone create \
  --resource-group myRG \
  --name "privatelink.wvd.microsoft.com"

az network private-dns link vnet create \
  --resource-group myRG \
  --zone-name "privatelink.wvd.microsoft.com" \
  --name avd-dns-link \
  --virtual-network myVNet \
  --registration-enabled false

3. Verificar que el cliente usa UDP sobre Private Link

Durante una sesión activa, en Windows App o Remote Desktop:

Connection Information → Transport: UDP
                       → Path: Private

Desde PowerShell en el session host:

# Verificar conexiones UDP activas del servicio RDS
Get-NetUDPEndpoint |
    Where-Object { $_.LocalPort -gt 49152 } |
    Select-Object LocalAddress, LocalPort, OwningProcess

Impacto en costes de red

Buenas prácticas

• Despliega el Private Endpoint en una subred dedicada para AVD; facilita las reglas de NSG y el troubleshooting.
• Usa Network Watcher para verificar que el tráfico UDP efectivamente no sale a internet.
• Si tienes clientes remotos sin VPN/ExpressRoute (por ejemplo, BYOD en casa), estos seguirán usando la ruta pública. Private Link solo aplica a clientes dentro de la red privada conectada.

Referencias

• What's new in Azure Virtual Desktop - February 2026
• RDP Shortpath for managed networks
• Azure Private Link for Azure Virtual Desktop

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

GPT-4o Realtime 1.5 y Audio 1.5: mejor seguimiento de instrucciones y soporte multilingüe

Resumen

En febrero de 2026, Microsoft publicó las versiones gpt-4o-realtime-preview-1.5 y gpt-4o-audio-preview-1.5 en Azure OpenAI. Estas versiones mejoran significativamente el seguimiento de instrucciones del system prompt, la calidad de respuesta en conversaciones en múltiples idiomas y la estabilidad de la Realtime API para casos de uso de voz. Si tienes aplicaciones de voz o audio sobre Azure OpenAI, conviene planificar la migración a estas versiones.

¿Qué cambia en estas versiones?

gpt-4o-realtime-preview-1.5

La Realtime API de Azure OpenAI permite conversaciones de baja latencia vía WebSocket: el cliente envía audio y recibe respuesta de voz sin pasar por transcripción intermedia.

Mejoras en 1.5:

• Instruction following: el modelo respeta mejor restricciones del system prompt (idioma forzado, formato de respuesta, limitaciones de dominio)
• Multilingüe: mejor calidad en español, alemán, francés, japonés y portugués
• Latencia reducida: aproximadamente 15-20% menos latencia de TTFB (Time To First Byte de audio) en condiciones de carga estándar (dato estimado según release notes)

gpt-4o-audio-preview-1.5

Versión asíncrona (sin WebSocket) para procesamiento de audio. Acepta audio como input y devuelve texto o audio como output.

Mejoras en 1.5:

• Mejor reconocimiento de acentos regionales
• Soporte de entrada de audio de hasta 25 MB por request
• Reducción de alucinaciones en transcripción de vocabulario técnico

Arquitectura básica con la Realtime API

sequenceDiagram
    participant C as Cliente (browser/app)
    participant A as Azure OpenAI Realtime
    C->>A: WebSocket connect (session.create)
    A-->>C: session.created
    C->>A: input_audio_buffer.append (PCM16)
    C->>A: input_audio_buffer.commit
    A-->>C: conversation.item.created
    A-->>C: response.audio.delta (streaming)
    A-->>C: response.audio.done

Actualizar el modelo en tu configuración

Si ya usas la Realtime API, actualiza el deployment a la nueva versión:

# Crear deployment de la nueva versión
az cognitiveservices account deployment create \
  --resource-group myRG \
  --name myAOAIresource \
  --deployment-name gpt4o-realtime-15 \
  --model-name gpt-4o-realtime-preview \
  --model-version "2025-06-03" \
  --model-format OpenAI \
  --sku-capacity 10 \
  --sku-name Standard

Ejemplo de cliente Python (Realtime API)

import asyncio
import json
import websockets
from azure.identity import DefaultAzureCredential

AOAI_ENDPOINT = "wss://<resource>.openai.azure.com"
DEPLOYMENT = "gpt4o-realtime-15"
API_VERSION = "2025-01-01-preview"

async def realtime_session():
    token = DefaultAzureCredential().get_token("https://cognitiveservices.azure.com/.default").token
    url = f"{AOAI_ENDPOINT}/openai/realtime?deployment={DEPLOYMENT}&api-version={API_VERSION}"

    headers = {"Authorization": f"Bearer {token}"}

    async with websockets.connect(url, extra_headers=headers) as ws:
        # Enviar configuración de sesión con system prompt estricto
        await ws.send(json.dumps({
            "type": "session.update",
            "session": {
                "modalities": ["text", "audio"],
                "instructions": "Responde siempre en español. Solo responde sobre soporte técnico de Azure.",
                "voice": "alloy",
                "input_audio_format": "pcm16",
                "output_audio_format": "pcm16"
            }
        }))
        response = await ws.recv()
        print(json.loads(response))

asyncio.run(realtime_session())

Coste estimado

Los precios de la Realtime API se cobran por tokens de audio y texto:

Monitoriza el consumo desde Azure Monitor o el dashboard de Azure OpenAI en Foundry para evitar sorpresas en la factura.

Buenas prácticas

• Prueba el instruction following con casos límite antes de desplegar en producción: el modelo es mejor en 1.5 pero no infalible.
• Implementa un VAD (Voice Activity Detection) del lado cliente para reducir tokens innecesarios de silencio.
• Configura turn_detection de tipo server_vad si quieres que el servidor detecte el fin de turno automáticamente.

Referencias

• Azure OpenAI models - February 2026 updates
• Azure OpenAI Realtime API reference
• Azure OpenAI model availability

Azure Backup para Confidential VMs: protección de datos en entornos de computación confidencial

Resumen

Desde enero de 2026, Azure Backup soporta en preview pública la protección de Confidential Virtual Machines. Es un paso importante para organizaciones que usan computación confidencial y necesitan garantías de backup sin comprometer el aislamiento de memoria que ofrecen las Confidential VMs. Si tu organización trabaja con datos sensibles bajo regulaciones estrictas y ya usa Confidential VMs, este es el momento de evaluar la integración.

¿Qué son las Confidential VMs?

Las Confidential VMs de Azure usan hardware TEE (Trusted Execution Environment) —basado en AMD SEV-SNP— para cifrar la memoria de la VM durante la ejecución. Ni los administradores del host ni Microsoft pueden acceder a esa memoria.

Esto tiene una implicación directa en backup: los mecanismos tradicionales de snapshot no pueden leer el contenido cifrado de los discos sin el contexto de la VM.

Cómo funciona el backup de Confidential VMs

Azure Backup usa un mecanismo específico que respeta el modelo de confianza de las Confidential VMs:

flowchart TD
    A[Confidential VM\nAMD SEV-SNP] --> B[Disco OS cifrado\nCMK - Customer Managed Key]
    B --> C[Azure Backup Service]
    C --> D{Tipo de snapshot}
    D --> E[Crash-consistent snapshot\nCifrado en reposo con CMK]
    E --> F[Recovery Services Vault\nCMK heredado]
    F --> G[Restore en VM confidencial\ndel mismo tamaño/familia]

Los puntos clave del comportamiento:

• El snapshot se cifra con la Customer Managed Key (CMK) del disco original
• Los datos nunca se descifran fuera del entorno confidencial
• El restore requiere una VM compatible (misma familia, AMD SEV-SNP)

Requisitos previos

• VM de la serie DCasv5 o ECasv5 (AMD SEV-SNP)
• OS disk cifrado con CMK (no Platform Managed Key)
• Recovery Services Vault con cross-region restore habilitado si se necesita DR

Configurar backup desde la CLI

# Variables
VAULT="my-backup-vault"
RG="my-rg"
VM_ID="/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachines/<vm>"

# Crear Recovery Services Vault si no existe
az backup vault create \
  --resource-group $RG \
  --name $VAULT \
  --location eastus

# Habilitar backup en la Confidential VM
az backup protection enable-for-vm \
  --resource-group $RG \
  --vault-name $VAULT \
  --vm $VM_ID \
  --policy-name DefaultPolicy

Limitaciones en preview

Buenas prácticas

• Almacena la CMK en Azure Key Vault con soft delete y purge protection habilitados. Si pierdes la clave, los backups son irrecuperables.
• Configura alertas de Azure Backup para detectar fallos en la ventana de backup.
• Documenta los requisitos de VM para el restore: si necesitas recuperar en otra región, debes tener la familia DCasv5/ECasv5 disponible allí.

# Verificar que el disco está cifrado con CMK
az vm show \
  --resource-group $RG \
  --name <vm-name> \
  --query "storageProfile.osDisk.managedDisk.securityProfile"

Referencias

• What's new in Azure Backup - January 2026
• Overview of Azure Confidential VMs
• Azure Backup support matrix for Azure VMs

Azure AI Language completo en Microsoft Foundry: migración desde Language Studio

Resumen

Desde enero de 2026, todas las capacidades de Azure AI Language están disponibles en Microsoft Foundry (portal nuevo). Esto incluye la experiencia completa de Language Studio —gestión de proyectos, entrenamiento, despliegue— y una nueva funcionalidad clave: Orchestration workflow, que permite enrutar consultas de usuario entre proyectos CLU y CQA desde una interfaz unificada. Si aún usas Language Studio clásico, es el momento de migrar.

¿Qué incluye Azure AI Language en Foundry?

Capacidades migradas desde Language Studio

• Conversational Language Understanding (CLU): intents, entities, entrenamiento de modelos de lenguaje conversacional
• Custom Question Answering (CQA): bases de conocimiento para responder preguntas
• Named Entity Recognition, Sentiment Analysis, Key Phrase Extraction y otras capacidades cognitivas
• Custom Text Classification y Custom NER

Novedad: Orchestration Workflow

El Orchestration Workflow es un orquestador que recibe una consulta de usuario y la enruta al proyecto CLU o CQA más adecuado según la intención detectada.

flowchart LR
    U["Usuario"] --> OW["Orchestration Workflow"]
    OW -->|Intent: soporte técnico| CLU["Proyecto CLU
    Soporte"]
    OW -->|Intent: FAQ producto| CQA["Proyecto CQA
    Documentación"]
    CLU --> R1["Respuesta estructurada"]
    CQA --> R2["Respuesta de KB"]

Esto reduce la complejidad de aplicaciones que antes necesitaban lógica de enrutamiento propia en el backend.

Cómo acceder a las capacidades en Foundry

1. Crear un recurso Azure AI Language

az cognitiveservices account create \
  --name my-language-resource \
  --resource-group myRG \
  --kind TextAnalytics \
  --sku S \
  --location eastus \
  --yes

2. Acceder a Foundry

Navega a https://ai.azure.com y asegúrate de que el toggle New Foundry está activado.

En el panel izquierdo verás las secciones de Language con todos los proyectos disponibles.

3. Crear un Orchestration Workflow

Desde Foundry → Language → Orchestration Workflow → New project:

{
  "projectName": "mi-orquestador",
  "language": "es",
  "projectKind": "Orchestration",
  "intents": [
    {
      "category": "SoporteTecnico",
      "target": {
        "targetProjectKind": "Luis",
        "apiVersion": "2022-10-01",
        "projectName": "soporte-clu"
      }
    },
    {
      "category": "FAQ",
      "target": {
        "targetProjectKind": "QuestionAnswering",
        "projectName": "docs-cqa"
      }
    }
  ]
}

4. Llamar al orquestador desde tu aplicación

from azure.ai.language.conversations import ConversationAnalysisClient
from azure.core.credentials import AzureKeyCredential

client = ConversationAnalysisClient(
    endpoint="https://<resource>.cognitiveservices.azure.com/",
    credential=AzureKeyCredential("<key>")
)

result = client.analyze_conversation(
    task={
        "kind": "Conversation",
        "analysisInput": {
            "conversationItem": {
                "id": "1",
                "participantId": "user",
                "text": "¿Cómo instalo el agente de monitorización?"
            }
        },
        "parameters": {
            "projectName": "mi-orquestador",
            "deploymentName": "production"
        }
    }
)

print(result["result"]["prediction"]["topIntent"])

Migración desde Language Studio

Microsoft ha publicado una guía de migración paso a paso. El proceso consiste en:

1. Abrir el proyecto existente en Language Studio clásico
2. Exportar el modelo entrenado (JSON)
3. Importarlo en Foundry desde Language → Import project
4. Reentrenar y validar
5. Actualizar los endpoints en la aplicación (misma API, diferente portal de gestión)

Buenas prácticas

• Prueba el Orchestration Workflow en un entorno de desarrollo antes de apuntar tráfico de producción.
• Configura intents de fallback para evitar que consultas sin match claro lleguen a un proyecto equivocado.
• Usa Managed Identity en lugar de API keys para acceder al recurso de Language desde tu aplicación.

# Asignar rol Cognitive Services User a la identidad gestionada
az role assignment create \
  --assignee <principal-id> \
  --role "Cognitive Services Language Reader" \
  --scope /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.CognitiveServices/accounts/<resource>

Referencias

• What's new in Azure Language in Foundry Tools - January 2026
• Migrate from Azure Language Studio to Microsoft Foundry
• Orchestration workflow quickstart

AVD: gestión centralizada de RDP Shortpath vía Intune y GPO ya es GA

Resumen

Azure Virtual Desktop permite desde enero de 2026 configurar todos los modos de transporte de RDP Shortpath —Managed, Public/STUN y Public/TURN— directamente desde Microsoft Intune o Group Policy. Esta funcionalidad es ahora GA y elimina la necesidad de gestionar configuraciones dispersas en múltiples capas. Los admins de VDI pueden controlar el comportamiento de transporte de red desde una sola política, aplicada a nivel de session host.

¿Qué es RDP Shortpath?

RDP Shortpath es una característica de Azure Virtual Desktop que establece una ruta de transporte UDP directa entre el cliente y el session host, evitando el relay de Azure. Esto reduce la latencia y mejora la experiencia de usuario, especialmente en redes con buena conectividad.

Hay tres modos de transporte configurables:

Qué cambia con la GA de enero 2026

Antes de este cambio, la configuración de Shortpath requería combinar ajustes en:

• Host pool properties (portal de AVD)
• Registry keys en los session hosts (manual o via scripts)

Ahora todo se configura con registry-backed policies desplegadas vía Intune o GPO. Estas configuraciones aplican a nivel de session host, como una capa adicional sobre las host pool settings.

flowchart TD
    A[Admin] --> B{Herramienta de gestión}
    B --> C[Intune / Endpoint Manager]
    B --> D[Group Policy]
    C --> E[Registry-backed policy]
    D --> E
    E --> F[Session Host]
    F --> G{RDP Shortpath Mode}
    G --> H[Managed - ExpressRoute/VPN]
    G --> I[Public/STUN]
    G --> J[Public/TURN]

Configuración vía Intune

1. Crear un perfil de configuración de dispositivo

En el portal de Intune:

1. Ve a Devices → Configuration profiles → Create profile
2. Plataforma: Windows 10 and later
3. Tipo de perfil: Settings catalog

2. Buscar y configurar las políticas de RDP Shortpath

Busca en el catálogo: Remote Desktop

Las claves relevantes están bajo:

Administrative Templates > Windows Components > Remote Desktop Services > 
Remote Desktop Session Host > Connections

3. Valores recomendados para entornos corporativos con red privada

Enable RDP Shortpath for managed networks: Enabled
Enable RDP Shortpath for public networks: Enabled (STUN)
RDP Shortpath maximum transport unit: 1400

Configuración equivalente vía GPO

# Verificar configuración actual en un session host
Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" |
    Select-Object fUseUdpPortRedirector, UdpRedirectorPort

GPO Path: Computer Configuration > Administrative Templates > 
Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections

- Enable RDP Shortpath for managed networks: Enabled
- Enable RDP Shortpath for public networks: Enabled

Cómo verificar que Shortpath está funcionando

En el cliente de Windows App o Remote Desktop, durante una sesión activa:

Connection Information → Transport: UDP (RDP Shortpath)

Desde PowerShell en el session host:

Get-WinEvent -LogName "Microsoft-Windows-RemoteDesktopServices-RdpCoreCDV/Operational" |
    Where-Object { $_.Message -like "*Shortpath*" } |
    Select-Object TimeCreated, Message -First 10

Buenas prácticas

• Las políticas de Intune/GPO se aplican además de las host pool settings, no las reemplazan. Comprueba que no haya conflicto entre capas.
• Para usuarios con NAT simétrico o firewalls corporativos restrictivos, habilita Public/TURN como fallback, pero monitoriza el uso de relay: tiene mayor latencia que STUN.
• Aplica las políticas primero en un grupo piloto antes de desplegarlas a todos los session hosts.
• Documenta qué modo está activo en cada host pool para facilitar el troubleshooting.

Referencias

• What's new in Azure Virtual Desktop - January 2026
• RDP Shortpath overview
• Configure RDP Shortpath

AKS v1.34: FIPS, TLS 1.2 EMS y la retirada definitiva de Azure Linux 2.0

Resumen

AKS v1.34 llega con cambios que afectan directamente a entornos en producción: los componentes del plano de control se compilan ahora con Go 1.25 y módulos criptográficos FIPS, lo que impone el Extended Master Secret (EMS) en conexiones TLS 1.2 de nodos FIPS. Además, a partir del 31 de marzo de 2026 los nodos con Azure Linux 2.0 dejan de funcionar. Si tienes clústeres con esa imagen, debes migrar ya.

¿Qué cambió en AKS v1.34?

Enforcement de EMS en TLS 1.2 (nodos FIPS)

Go 1.25 rechaza handshakes TLS 1.2 que no incluyan el Extended Master Secret (EMS) cuando FIPS está activado. Esto afecta a:

• Aplicaciones cliente que hablan con el API server de Kubernetes
• Admission webhooks registrados contra kube-apiserver
• Cualquier componente compilado con Go < 1.21

Las aplicaciones compiladas con Go < 1.21 no enviaban EMS por defecto en TLS 1.2, por lo que fallarán al conectarse a componentes de AKS v1.34 en nodos FIPS.

sequenceDiagram
    participant App as App (Go < 1.21)
    participant AKS as AKS v1.34 API Server (FIPS)
    App->>AKS: TLS 1.2 ClientHello (sin EMS)
    AKS-->>App: ❌ Handshake rechazado
    Note over App,AKS: Go 1.25 + FIPS exige EMS en TLS 1.2

Retirada de Azure Linux 2.0

Desde el 31 de marzo no puedes escalar ni recuperar nodos con Azure Linux 2.0. Las operaciones de reimage y redeploy fallarán.

Cómo verificar si estás afectado

Comprobar versión de Kubernetes y osSKU

az aks show \
  --resource-group <rg> \
  --name <cluster> \
  --query "agentPoolProfiles[].{name:name, osSku:osSku, k8sVersion:currentOrchestratorVersion}" \
  -o table

Comprobar si FIPS está habilitado en el node pool

az aks nodepool show \
  --resource-group <rg> \
  --cluster-name <cluster> \
  --name <nodepool> \
  --query "enableFips"

Cómo migrar

Opción 1: Actualizar node pools a Azure Linux 3

az aks nodepool upgrade \
  --resource-group <rg> \
  --cluster-name <cluster> \
  --name <nodepool> \
  --os-sku AzureLinux

Opción 2: Actualizar a versión de Kubernetes compatible

Si el node pool está en una versión antigua, primero actualiza Kubernetes:

az aks upgrade \
  --resource-group <rg> \
  --name <cluster> \
  --kubernetes-version 1.32.x

Resolver problemas de TLS 1.2 EMS

Si tienes aplicaciones compiladas con Go < 1.21:

# Verificar versión de Go en tu aplicación
go version

# Rebuild con Go 1.21+
go build -o myapp .

Para webhooks, verificar que el servidor TLS responde con EMS:

openssl s_client -connect <webhook-endpoint>:443 -tls1_2 2>&1 | grep "extended master secret"

Buenas prácticas

• Comprueba la versión de Go de todos los componentes que usen la API de Kubernetes antes de activar FIPS.
• Si usas cert-manager, ingress controllers o admission webhooks de terceros, verifica que estén actualizados.
• Para migration de AzureLinux 2.0, crea primero un nuevo node pool con AzureLinux 3, drena el antiguo y elimínalo.
• Suscríbete a las AKS release notes para anticipar cambios similares.

Referencias

• AKS Security Bulletin AKS-2026-0001
• Azure Linux 2.0 retirement announcement
• Upgrade AKS node pool OS version
• AKS release notes

Seguridad en Azure Storage: Guía Completa de Firewall, Resource Instances y Mejores Prácticas

Introducción

La seguridad de las cuentas de almacenamiento en Azure es crítica para proteger tus datos. En este artículo profundizaremos en las diferentes opciones de firewall disponibles cuando no se usa Azure private endpoint, con especial énfasis en Resource Instances, Trusted Services y las configuraciones recomendadas cuando no se utilizan Private Endpoints.

Conceptos Fundamentales

¿Qué es el Firewall de Storage Account?

El firewall de Azure Storage Account es una capa de seguridad que controla el acceso al endpoint público de tu cuenta de almacenamiento. Es importante entender que:

• Un solo firewall protege TODOS los servicios (Blob, Files, Queue, Table)
• Las reglas aplican a nivel de Storage Account, no por servicio individual
• El firewall controla quién puede conectarse, mientras que RBAC controla qué puede hacer

graph TD
    A[Cliente/Servicio] -->|Intenta acceder| B{Firewall}
    B -->|✅ Permitido| C{RBAC}
    B -->|❌ Bloqueado| D[403 Forbidden]
    C -->|✅ Con permisos| E[Acceso a datos]
    C -->|❌ Sin permisos| F[403 Unauthorized]

Tipos de Reglas de Red

Azure Storage ofrece cuatro tipos de reglas de red que puedes configurar:

1. Virtual Network Rules

Permiten tráfico desde subnets específicas dentro de Azure Virtual Networks.

# Agregar regla de VNet
Add-AzStorageAccountNetworkRule `
    -ResourceGroupName "myRG" `
    -Name "mystorageaccount" `
    -VirtualNetworkResourceId "/subscriptions/xxx/resourceGroups/rg/providers/Microsoft.Network/virtualNetworks/vnet/subnets/subnet"

Límite: Máximo 400 reglas por Storage Account

2. IP Network Rules

Permiten tráfico desde rangos de IP públicas específicas.

# Agregar regla de IP
Add-AzStorageAccountNetworkRule `
    -ResourceGroupName "myRG" `
    -Name "mystorageaccount" `
    -IPAddressOrRange "203.0.113.0/24"

Límite: Máximo 400 reglas por Storage Account

3. Resource Instance Rules ⭐

Permiten tráfico desde recursos Azure específicos identificados por su Resource ID.

# Agregar Resource Instance
Add-AzStorageAccountNetworkRule `
    -ResourceGroupName "myRG" `
    -Name "mystorageaccount" `
    -TenantId "your-tenant-id" `
    -ResourceId "/subscriptions/xxx/resourceGroups/rg/providers/Microsoft.Synapse/workspaces/myworkspace"

Límite: Máximo 200 reglas por Storage Account

4. Trusted Service Exceptions

Permiten tráfico desde servicios de Microsoft en la lista de confianza.

# Habilitar Trusted Services
Update-AzStorageAccountNetworkRuleSet `
    -ResourceGroupName "myRG" `
    -Name "mystorageaccount" `
    -Bypass AzureServices,Logging,Metrics

Límite: Sin límite (es un flag de configuración)

Resource Instances: Control Granular

¿Qué son las Resource Instances?

Las Resource Instance Rules son la forma más segura de permitir acceso a servicios Azure cuando no usas Private Endpoints. A diferencia de Trusted Services (que permite CUALQUIER instancia de un servicio en tu tenant), Resource Instances te permite especificar exactamente qué recurso puede acceder.

Comparación: Trusted Services vs Resource Instances

Ejemplo Práctico

Imagina que tienes múltiples Azure Synapse Workspaces en tu tenant:

Update-AzStorageAccountNetworkRuleSet `
    -Bypass AzureServices

# Resultado:
# ✅ prod-synapse → Acceso permitido
# ✅ dev-synapse → Acceso permitido
# ✅ test-synapse → Acceso permitido
# ✅ Cualquier otro Synapse creado → Acceso permitido

Add-AzStorageAccountNetworkRule `
    -TenantId "xxx" `
    -ResourceId "/subscriptions/xxx/.../Microsoft.Synapse/workspaces/prod-synapse"

# Resultado:
# ✅ prod-synapse → Acceso permitido
# ❌ dev-synapse → Bloqueado
# ❌ test-synapse → Bloqueado
# ❌ Cualquier otro Synapse → Bloqueado

Requerimientos para Resource Instances

Para usar Resource Instances correctamente, necesitas cumplir varios requisitos:

✅ Checklist de Requerimientos

• Managed Identity: El recurso debe tener System-Assigned Managed Identity habilitada
• Mismo Tenant: Recurso y Storage Account en el mismo Microsoft Entra tenant
• Firewall Restrictivo: Storage Account con DefaultAction: Deny
• Permisos para configurar: Rol Storage Account Contributor o superior
• Resource ID completo: Necesitas el Resource ID del recurso Azure
• Rol RBAC asignado: La Managed Identity necesita roles de acceso a datos

Configuración Completa Paso a Paso

# Variables
$rgName = "myResourceGroup"
$storageAccount = "mystorageaccount"
$synapseWorkspaceName = "prod-synapse"
$synapseRG = "synapse-rg"
$tenantId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

# 1. Obtener Resource ID del Synapse Workspace
$synapseResourceId = (Get-AzSynapseWorkspace `
    -ResourceGroupName $synapseRG `
    -Name $synapseWorkspaceName).Id

# 2. Configurar firewall restrictivo
Update-AzStorageAccountNetworkRuleSet `
    -ResourceGroupName $rgName `
    -Name $storageAccount `
    -DefaultAction Deny `
    -Bypass Logging,Metrics

# 3. Agregar Resource Instance Rule
Add-AzStorageAccountNetworkRule `
    -ResourceGroupName $rgName `
    -Name $storageAccount `
    -TenantId $tenantId `
    -ResourceId $synapseResourceId

# 4. Obtener Managed Identity Object ID
$workspace = Get-AzSynapseWorkspace `
    -ResourceGroupName $synapseRG `
    -Name $synapseWorkspaceName
$principalId = $workspace.Identity.PrincipalId

# 5. Asignar rol RBAC para acceso a datos
New-AzRoleAssignment `
    -ObjectId $principalId `
    -RoleDefinitionName "Storage Blob Data Contributor" `
    -Scope "/subscriptions/$((Get-AzContext).Subscription.Id)/resourceGroups/$rgName/providers/Microsoft.Storage/storageAccounts/$storageAccount"

Write-Host "✅ Configuración completa!" -ForegroundColor Green

Excepciones (Bypass): Logging y Metrics

Las Exceptions son configuraciones especiales que permiten que ciertos servicios bypaseen el firewall.

Tipos de Excepciones

1. Allow Azure services on the trusted services list

Bypass: AzureServices

¿Qué hace?
  - Permite TODOS los servicios de la lista de Trusted Services
  - Incluye: Azure Backup, Synapse, SQL, Stream Analytics, etc.

⚠️ Recomendación: Usar Resource Instances en su lugar

2. Allow read access to storage logging

Bypass: Logging

¿Qué hace?
  - Permite leer el contenedor especial "$logs"
  - Solo para diagnósticos de Azure Monitor
  - NO da acceso a tus datos de aplicación

✅ Recomendación: SIEMPRE habilitado

3. Allow read access to storage metrics

Bypass: Metrics

¿Qué hace?
  - Permite leer las tablas "$Metrics*"
  - Solo para métricas de Azure Monitor
  - NO da acceso a tus datos de aplicación

✅ Recomendación: SIEMPRE habilitado

Cómo Configurar Excepciones en el Portal

1. Ve a tu Storage Account
2. Navega a: Security + networking → Networking
3. Click en View junto a "Virtual networks, IP addresses, and exceptions"
4. Scroll down hasta la sección Exceptions
5. Marca/desmarca los checkboxes según necesites:
6. ☐ Allow Azure services on the trusted services list
7. ☑️ Allow read access to storage logging
8. ☑️ Allow read access to storage metrics
9. Click en Save

Configuración Recomendada sin Private Endpoints

Esta es la configuración óptima para máxima seguridad sin el costo adicional de Private Endpoints:

🎯 Configuración de Producción

# 1. Configurar firewall restrictivo con excepciones de lectura
Update-AzStorageAccountNetworkRuleSet `
    -ResourceGroupName "myRG" `
    -Name "mystorageaccount" `
    -DefaultAction Deny `
    -Bypass Logging,Metrics  # SIN AzureServices (a menos que uses Azure Backup)

# 2. Agregar Resource Instances específicas
$resources = @(
    "/subscriptions/xxx/resourceGroups/rg1/providers/Microsoft.Synapse/workspaces/prod-synapse",
    "/subscriptions/xxx/resourceGroups/rg1/providers/Microsoft.DataFactory/factories/prod-adf",
    "/subscriptions/xxx/resourceGroups/rg1/providers/Microsoft.Databricks/workspaces/prod-dbx"
)

foreach ($resourceId in $resources) {
    Add-AzStorageAccountNetworkRule `
        -ResourceGroupName "myRG" `
        -Name "mystorageaccount" `
        -TenantId "your-tenant-id" `
        -ResourceId $resourceId
}

# 3. Agregar IPs de oficina/VPN (opcional)
$officeIPs = @("203.0.113.10", "198.51.100.0/24")
foreach ($ip in $officeIPs) {
    Add-AzStorageAccountNetworkRule `
        -ResourceGroupName "myRG" `
        -Name "mystorageaccount" `
        -IPAddressOrRange $ip
}

Arquitectura Visual

┌─────────────────────────────────────────────────────────────┐
│         Storage Account Firewall Configuration              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ Public network access: Selected networks                    │
│ Default Action: DENY                                        │
│                                                             │
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━│
│                                                             │
│ Exceptions (Bypass):                                        │
│   ☐ AzureServices (NO - demasiado permisivo)               │
│   ☑️ Logging (SÍ - para troubleshooting)                   │
│   ☑️ Metrics (SÍ - para monitoreo)                         │
│                                                             │
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━│
│                                                             │
│ Resource Instances (granular):                             │
│   ✅ prod-synapse                                           │
│   ✅ prod-adf                                               │
│   ✅ prod-databricks                                        │
│                                                             │
│ VNet Rules: [subnets específicas]                          │
│ IP Rules: [oficinas, VPN]                                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Alcance del Firewall: Todos los Servicios

Servicios Afectados

El firewall aplica a todos estos endpoints:

• 🔵 Blob Storage: https://{account}.blob.core.windows.net
• 📁 File Storage: https://{account}.file.core.windows.net
• 📮 Queue Storage: https://{account}.queue.core.windows.net
• 📊 Table Storage: https://{account}.table.core.windows.net

Control Granular por Servicio

Si necesitas que un recurso acceda solo a Blob pero no a Files, usa RBAC:

# Firewall: Permite conexión al endpoint (todos los servicios)
Add-AzStorageAccountNetworkRule -ResourceId $resourceId

# RBAC: Controla acceso específico por servicio
New-AzRoleAssignment `
    -ObjectId $principalId `
    -RoleDefinitionName "Storage Blob Data Contributor" `  # Solo Blob
    -Scope $storageAccountScope

# No asignas roles para Files, Queues o Tables
# → Aunque el firewall permita conexión, no tiene permisos RBAC

Validación de Configuración

Script de Validación Completa

function Test-StorageAccountSecurityConfig {
    param(
        [string]$ResourceGroupName,
        [string]$StorageAccountName
    )

    $rules = Get-AzStorageAccountNetworkRuleSet `
        -ResourceGroupName $ResourceGroupName `
        -Name $StorageAccountName

    Write-Host "`n🔍 VALIDACIÓN DE CONFIGURACIÓN ÓPTIMA" -ForegroundColor Cyan
    Write-Host "═══════════════════════════════════════`n" -ForegroundColor Cyan

    $score = 0
    $maxScore = 5

    # Check 1: DefaultAction
    if ($rules.DefaultAction -eq "Deny") {
        Write-Host "✅ DefaultAction: Deny (Correcto)" -ForegroundColor Green
        $score++
    } else {
        Write-Host "❌ DefaultAction: Allow (Cambiar a Deny)" -ForegroundColor Red
    }

    # Check 2: Bypass óptimo
    if ($rules.Bypass -notlike "*AzureServices*" -and 
        $rules.Bypass -like "*Logging*" -and 
        $rules.Bypass -like "*Metrics*") {
        Write-Host "✅ Bypass: Logging,Metrics (Óptimo)" -ForegroundColor Green
        $score++
    } elseif ($rules.Bypass -like "*AzureServices*") {
        Write-Host "⚠️  Bypass incluye AzureServices (Considerar usar Resource Instances)" -ForegroundColor Yellow
    }

    # Check 3: Resource Instances
    if ($rules.ResourceAccessRules.Count -gt 0) {
        Write-Host "✅ Resource Instances: $($rules.ResourceAccessRules.Count) configuradas" -ForegroundColor Green
        foreach ($rule in $rules.ResourceAccessRules) {
            $resourceName = $rule.ResourceId.Split('/')[-1]
            Write-Host "   → $resourceName" -ForegroundColor Gray
        }
        $score++
    } else {
        Write-Host "⚠️  No hay Resource Instances configuradas" -ForegroundColor Yellow
    }

    # Check 4: VNet Rules
    if ($rules.VirtualNetworkRules.Count -gt 0) {
        Write-Host "✅ VNet Rules: $($rules.VirtualNetworkRules.Count)" -ForegroundColor Green
        $score++
    }

    # Check 5: IP Rules
    if ($rules.IpRules.Count -gt 0) {
        Write-Host "✅ IP Rules: $($rules.IpRules.Count)" -ForegroundColor Green
        $score++
    }

    # Resumen
    Write-Host "`n════════════════════════════════════════" -ForegroundColor Cyan
    Write-Host "Puntaje de Seguridad: $score/$maxScore" -ForegroundColor $(
        if ($score -eq $maxScore) { "Green" } 
        elseif ($score -ge 3) { "Yellow" } 
        else { "Red" }
    )

    if ($score -ge 4 -and $rules.Bypass -notlike "*AzureServices*") {
        Write-Host "🎉 CONFIGURACIÓN ÓPTIMA" -ForegroundColor Green
    } else {
        Write-Host "⚠️  Revisar configuración según recomendaciones" -ForegroundColor Yellow
    }
}

# Uso
Test-StorageAccountSecurityConfig -ResourceGroupName "myRG" -StorageAccountName "mystorageaccount"

Mejores Prácticas

✅ Recomendaciones de Seguridad

1. Usa Resource Instances en lugar de Trusted Services
2. Mayor control y trazabilidad
3. Cumple con Zero Trust

4. Mejor para compliance

5. Siempre habilita Logging y Metrics

6. Necesario para troubleshooting
7. No expone tus datos

8. Bajo riesgo de seguridad

9. Aplica el principio de menor privilegio

10. Firewall: Solo recursos que realmente necesitan acceso

11. RBAC: Solo los permisos mínimos necesarios

12. Documenta tus Resource Instances

13. Mantén un registro de qué recurso accede y por qué

14. Facilita auditorías y compliance

15. Revisa periódicamente las reglas

16. Elimina recursos que ya no existen
17. Verifica que las reglas siguen siendo necesarias

⚠️ Errores Comunes a Evitar

Casos Especiales: Servicios que Requieren Trusted Services

Algunos servicios de Azure NO soportan Resource Instances y requieren que tengas habilitado Bypass: AzureServices. Es importante conocer estos casos para planificar tu estrategia de seguridad.

Azure Backup

Azure Backup es uno de los servicios más importantes que requiere Trusted Services para ciertos escenarios:

Configuración para Azure Backup

Si usas Azure Backup, tienes dos opciones:

# Habilitar Trusted Services para Azure Backup
Update-AzStorageAccountNetworkRuleSet `
    -ResourceGroupName "myRG" `
    -Name "mystorageaccount" `
    -DefaultAction Deny `
    -Bypass AzureServices,Logging,Metrics

# ⚠️ Esto permite acceso a TODOS los servicios trusted
# No solo Azure Backup

# Combinar Trusted Services + Resource Instances
Update-AzStorageAccountNetworkRuleSet `
    -ResourceGroupName "myRG" `
    -Name "mystorageaccount" `
    -DefaultAction Deny `
    -Bypass AzureServices,Logging,Metrics  # Para Azure Backup

# Agregar Resource Instances para otros servicios
Add-AzStorageAccountNetworkRule `
    -TenantId "xxx" `
    -ResourceId "/subscriptions/xxx/.../Microsoft.Synapse/workspaces/prod-synapse"

# Resultado:
# ✅ Azure Backup funciona (via Trusted Services)
# ✅ Synapse tiene acceso controlado (via Resource Instance)
# ⚠️ Otros servicios trusted también tienen acceso

Otros Servicios que Pueden Requerir Trusted Services

Estrategia Recomendada con Azure Backup

Si necesitas usar Azure Backup pero quieres mantener la máxima seguridad:

1. Evalúa si realmente necesitas Trusted Services

   # ¿Usas discos no administrados?
   Get-AzVM | Where-Object {$_.StorageProfile.OsDisk.ManagedDisk -eq $null}
   
   # Si el resultado está vacío, NO necesitas Trusted Services para Backup
   

2. Migra a Managed Disks si es posible

3. Los managed disks NO requieren Trusted Services
4. Mejor rendimiento y gestión

5. Recomendado por Microsoft

6. Si DEBES usar Trusted Services, documéntalo

   Storage Account: mystorageaccount
   Bypass: AzureServices
   Motivo: Azure Backup de VMs con discos no administrados
   VMs afectadas: 
     - vm-legacy-01
     - vm-legacy-02
   Plan de migración: Q2 2026
   

7. Usa Resource Instances para todo lo demás

8. Synapse, Data Factory, Databricks → Resource Instances
9. Solo Azure Backup usa Trusted Services
10. Documenta qué servicios usan cada método

Ejemplo de Configuración Real con Azure Backup

# Escenario: Necesitas Azure Backup + Synapse + Data Factory

$rgName = "myResourceGroup"
$storageAccount = "mystorageaccount"
$tenantId = "your-tenant-id"

# 1. Configurar con Trusted Services (requerido para Azure Backup)
Update-AzStorageAccountNetworkRuleSet `
    -ResourceGroupName $rgName `
    -Name $storageAccount `
    -DefaultAction Deny `
    -Bypass AzureServices,Logging,Metrics

Write-Host "✅ Trusted Services habilitado (Azure Backup)" -ForegroundColor Yellow

# 2. Agregar Resource Instances para control granular de otros servicios
# Aunque Trusted Services está habilitado, esto añade trazabilidad
$resources = @(
    "/subscriptions/xxx/resourceGroups/rg1/providers/Microsoft.Synapse/workspaces/prod-synapse",
    "/subscriptions/xxx/resourceGroups/rg1/providers/Microsoft.DataFactory/factories/prod-adf"
)

foreach ($resourceId in $resources) {
    Add-AzStorageAccountNetworkRule `
        -ResourceGroupName $rgName `
        -Name $storageAccount `
        -TenantId $tenantId `
        -ResourceId $resourceId

    Write-Host "✅ Resource Instance agregada: $($resourceId.Split('/')[-1])" -ForegroundColor Green
}

# 3. Documentar en tags
$tags = @{
    "FirewallConfig" = "TrustedServices+ResourceInstances"
    "TrustedServicesReason" = "Azure Backup - Unmanaged Disks"
    "MigrationPlan" = "Move to Managed Disks by Q2-2026"
}

Update-AzStorageAccount `
    -ResourceGroupName $rgName `
    -Name $storageAccount `
    -Tag $tags

Write-Host "✅ Configuración documentada en tags" -ForegroundColor Green

Troubleshooting

Error 403: Acceso Denegado

Si recibes errores 403, verifica en este orden:

1. Firewall: ¿El recurso tiene una Resource Instance Rule?

   (Get-AzStorageAccountNetworkRuleSet -ResourceGroupName "rg" -Name "sa").ResourceAccessRules
   

2. RBAC: ¿La Managed Identity tiene roles asignados?

   Get-AzRoleAssignment -ObjectId $principalId -Scope $storageScope
   

3. Managed Identity: ¿Está habilitada?

   $workspace = Get-AzSynapseWorkspace -Name "myworkspace"
   $workspace.Identity.Type
   

4. Tenant: ¿Ambos recursos están en el mismo tenant?

   (Get-AzResource -ResourceId $resourceId).TenantId
   

Verificar Acceso por Servicio

$ctx = New-AzStorageContext -StorageAccountName "sa" -UseConnectedAccount

# Probar Blob
try {
    Get-AzStorageContainer -Context $ctx -MaxCount 1
    Write-Host "✅ Blob: Accesible"
} catch {
    Write-Host "❌ Blob: $($_.Exception.Message)"
}

# Probar Queue
try {
    Get-AzStorageQueue -Context $ctx | Select-Object -First 1
    Write-Host "✅ Queue: Accesible"
} catch {
    Write-Host "❌ Queue: $($_.Exception.Message)"
}

Cuándo Usar Private Endpoints

Considera usar Private Endpoints en lugar de o además de las configuraciones de firewall cuando:

• ✅ Necesitas cumplimiento estricto de compliance
• ✅ No quieres exponer endpoints públicos en absoluto
• ✅ Requieres conectividad desde On-Premises vía ExpressRoute
• ✅ La latencia es crítica y necesitas tráfico privado
• ✅ Presupuesto disponible (hay costos adicionales)

La configuración con Resource Instances es suficiente cuando:

• ✅ Los recursos están en Azure (no on-premises)
• ✅ El endpoint público con firewall es aceptable
• ✅ Quieres balancear seguridad y costos
• ✅ No hay requisitos de red privada obligatorios

Conclusión

La seguridad de Azure Storage Account requiere una configuración cuidadosa del firewall. Las principales conclusiones son:

1. Resource Instances > Trusted Services para control granular
2. Siempre habilita Logging y Metrics para observabilidad
3. Combina Firewall + RBAC para defensa en profundidad
4. Un firewall protege todos los servicios (Blob, Files, Queue, Table)
5. Sin Private Endpoints, usa Resource Instances como mejor práctica
6. Azure Backup requiere Trusted Services para discos no administrados (considera migrar a managed disks)

Configuración Resumida Óptima

# La configuración perfecta para producción sin Private Endpoints
Update-AzStorageAccountNetworkRuleSet `
    -DefaultAction Deny `
    -Bypass Logging,Metrics  # NO AzureServices

# Agregar solo recursos específicos necesarios
Add-AzStorageAccountNetworkRule -ResourceId $specificResourceId

# Asignar roles RBAC mínimos necesarios
New-AzRoleAssignment -ObjectId $principalId -RoleDefinitionName "Storage Blob Data Reader"

# Si necesitas Azure Backup para discos no administrados
Update-AzStorageAccountNetworkRuleSet `
    -DefaultAction Deny `
    -Bypass AzureServices,Logging,Metrics  # Requerido para Azure Backup

# Agregar Resource Instances para trazabilidad de otros servicios
Add-AzStorageAccountNetworkRule -ResourceId $specificResourceId

# Asignar roles RBAC
New-AzRoleAssignment -ObjectId $principalId -RoleDefinitionName "Storage Blob Data Reader"

# Documentar y planificar migración a Managed Disks

Referencias

• Azure Storage network security
• Resource instance network rules
• Trusted Azure services
• Manage network security exceptions