Skip to content

2026/02

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:

Canal Descripción Opción privada disponible
Control plane Gestión, registro de sesión, configuración Private Link (GA desde 2023)
Session data Tráfico de la sesión de usuario (pantalla, audio, input) RDP Shortpath UDP + Private Link (GA feb 2026)

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

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

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

Note

El tráfico a través de Private Endpoints tiene coste de proceso. Para sesiones de usuario con alto consumo de ancho de banda (vídeo, CAD), evalúa el coste de Private Endpoint frente al coste de ancho de banda de salida a internet que evitas.

Coste Con Private Link Sin Private Link (internet)
Proceso PE ~0,01 $/hora por PE
Datos inbound ~0,01 $/GB
Datos outbound ~0,01 $/GB Tarifa de salida a internet

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

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"}'

Warning

El modo Block puede interrumpir operaciones legítimas si algún proceso del cluster genera binarios en runtime como parte de su funcionamiento normal (por ejemplo, compiladores JIT, scripts de inicialización). Prueba primero en modo Alert y revisa las alertas durante al menos una semana antes de activar Block.

Alertas generadas

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

Alerta Descripción
Malware detected in container Firma de malware encontrada en fichero del contenedor
Binary drift detected Binario nuevo ejecutado en contenedor existente
Suspicious process in container Proceso con comportamiento anómalo

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: 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

Característica Preview anterior GA (feb 2026)
Lookback de actividad 30 días 90 días
Soporte PCI DSS No No (aún limitado)
Identidades analizadas Usuarios, SPNs Usuarios, SPNs, Managed Identities
Exportación a CSV No
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.

Warning

La preview de threat protection para AI agents no cubre agentes desplegados fuera de Azure OpenAI o Foundry (por ejemplo, agentes usando modelos open-source en contenedores propios). Revisa los límites de cobertura antes de incluirlo en tu arquitectura de seguridad.

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

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

Note

El nombre del modelo en la API sigue siendo gpt-4o-realtime-preview; la versión 2025-06-03 corresponde al release 1.5. Verifica el nombre exacto de versión disponible en tu región en el Azure OpenAI model availability table.

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())

Warning

Usa siempre DefaultAzureCredential o Managed Identity en producción. No hardcodees API keys en el código; usa variables de entorno o Azure Key Vault.

Coste estimado

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

Tipo Precio estimado (consultar precios actuales)
Audio input ~$0.10 / 1K audio tokens
Audio output ~$0.20 / 1K audio tokens
Text tokens Similar a gpt-4o estándar

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