DLP y Protección de Datos

Detectar y reaccionar ante exposiciones

Data Loss Prevention es una familia de políticas de Microsoft Purview que escanean contenido en busca de información sensible y disparan acciones automáticas cuando la encuentran. En Power BI, las políticas DLP evalúan los datasets (modelos semánticos) y pueden activarse al publicar, al aplicar un refresh o al cambiar la sensitivity label.

Es la capa que responde a preguntas como:

• "¿Hay datasets con números de tarjeta o DNI que no deberían existir?"
• "¿Alguien acaba de publicar un modelo con datos médicos?"
• "¿Cómo aviso al equipo de compliance sin frenar la operativa?"

Tipos de información sensible

DLP usa Sensitive Information Types (SITs) de Microsoft Purview, que vienen con catálogos preconstruidos y se pueden extender:

• Datos financieros: tarjetas de crédito (PCI), IBAN, SWIFT, números de cuenta
• Datos personales (PII): DNI/NIE, NIF, pasaportes, números de la seguridad social
• Información sanitaria: identificadores de pacientes, códigos ICD-10, datos HIPAA
• Sensitivity labels específicos: p. ej. "todo dataset con label Highly Confidential"
• Custom SITs: patrones regex propios + diccionarios + funciones de validación
• Trainable classifiers: modelos ML que detectan categorías como "contratos", "currículums", "código fuente"

Lo que puede hacer una política cuando salta

• Alerta al admin: notificación en Purview compliance + email a la lista de seguridad
• Tooltip al usuario: cuando intenta hacer una acción restringida, se le muestra una explicación y el contacto
• Override con justificación: el usuario puede continuar si aporta motivo (auditado)
• Bloqueo duro: la acción no se puede completar
• Incident report: creación de incidente en el flujo de compliance
• Aplicar sensitivity label automáticamente: si detecta PII, sube la etiqueta a "Confidential"

Acciones específicas en Power BI

• Bloquear export a Excel / PowerPoint
• Bloquear publicación si la sensitivity label no cumple política
• Alertar al cambiar tenant settings sensibles

Ejemplo: detectar datasets con PII y avisar al CoE

1. Microsoft Purview compliance portal → Data Loss Prevention → Policies → New policy
2. Plantilla: Custom (o "Financial → PCI" si encaja)
3. Locations: marcar Power BI (la única ubicación relevante aquí)
4. Rule: condición Content contains → Sensitive info types → "EU National Identification Number"
5. Definir threshold: por ejemplo, ≥ 10 ocurrencias detectadas
6. Acciones:
   • Enviar email a governance@empresa.com
   • Generar incident report con detalles
   • Notificación in-product al propietario del dataset
7. Modo: empezar siempre en Test mode con tips antes de activar enforcement
8. Publicar y revisar incidents durante 2 semanas para afinar

Modo de despliegue recomendado

• Fase 1 (2 semanas): Test mode sin notificaciones (silencioso)
• Fase 2 (2 semanas): Test mode con notificaciones al CoE (medir falsos positivos)
• Fase 3: Enforce con overrides permitidos
• Fase 4 (opcional): Enforce sin overrides para los SITs más críticos

Por qué van juntas

Las sensitivity labels dicen "este dato es confidencial". DLP es lo que hace que esa etiqueta tenga consecuencias.

• Sin DLP, la sensitivity label es solo un indicador visual (y la herencia)
• Sin sensitivity labels, DLP tiene que detectar todo desde patrones — más caro y más falsos positivos
• Combinadas: si el dataset tiene "Highly Confidential", DLP bloquea exports a destinos externos automáticamente

Patrón habitual

• Política DLP A: detectar PII no etiquetada → forzar sensitivity label automática
• Política DLP B: si label = "Highly Confidential" → bloquear export y notificar

Antes de comprometerte con DLP

• DLP en Power BI escanea datasets; no escanea informes, dashboards ni dataflows en el mismo nivel de detalle
• Solo disponible con capacidades Premium / PPU / Fabric; no aplica a workspaces en capacidad Pro compartida
• El escaneo no es instantáneo — puede tardar minutos u horas tras un cambio
• Custom SITs requieren ajuste fino para evitar falsos positivos (regex demasiado permisivos son enemigos)
• El override con justificación se registra en el log, pero no se notifica en tiempo real al admin a menos que lo configures explícitamente
• Algunos eventos (consumo en Mobile, exports vía API) tienen cobertura DLP limitada