Problema

Muchas organizaciones deben colaborar con contratistas, freelancers o partners que no forman parte del directorio interno. En entornos basados en Microsoft 365 y Intune, el reto es ofrecerles las herramientas que necesitan (Outlook, Teams, SharePoint, GitLab, Slack) sin abrir la puerta a riesgos innecesarios: fuga de datos, acceso a recursos críticos o exposición de credenciales. El patrón típico es “acceso limitado pero funcional”: el usuario externo necesita trabajar, pero su perfil debe quedar aislado de los recursos internos y su actividad debe ser monitorizable.

Causa

  1. Identidades mixtas – Cuando un contratista se registra como usuario normal en Azure AD, hereda políticas diseñadas para empleados permanentes (por ejemplo, acceso a aplicaciones internas).
  2. BYOD sin control de endpoint – Sin gestión de dispositivos, no se puede garantizar que el equipo cumpla con los requisitos de seguridad (antivirus, cifrado, parches).
  3. Permisos excesivos en SharePoint/OneDrive – Compartir carpetas mediante enlaces “anyone with the link” elimina cualquier control de auditoría.
  4. Políticas de Conditional Access genéricas – Aplicar la misma regla a todos los usuarios ignora la diferencia de riesgo entre empleados y externos.
  5. Ausencia de etiquetas de clasificación y DLP – Los datos sensibles pueden copiarse a cuentas personales sin que exista una barrera automática.
  6. Falta de monitorización de riesgo – Sin licencias que habiliten Azure AD Identity Protection, los comportamientos anómalos (login desde ubicación inesperada, dispositivos no registrados) pasan desapercibidos.

Solución

Una arquitectura de “Zero Trust para externos” se basa en cuatro pilares: identidad verificada, dispositivo confiable, acceso con menor privilegio y monitorización continua. A continuación, un proceso reutilizable que cubre esos pilares.

1. Crear un grupo dinámico de “External Users”

Usar Azure AD para agrupar automáticamente a cualquier usuario cuyo UserType sea Guest o cuyo dominio de correo sea externo. Así todas las políticas posteriores se pueden aplicar al grupo sin mantenimiento manual.

# PowerShell (AzureAD) – crear grupo dinámico
Connect-AzureAD
$rule = "user.userType -eq `"Guest`" -or user.mail -contains `"@partnerdomain.com`""
New-AzureADMSGroup -DisplayName "External Users" -MailEnabled $false -SecurityEnabled $true -GroupTypes @("DynamicMembership") -MembershipRule $rule -MembershipRuleProcessingState "On"

2. Aplicar Conditional Access específico

  • Requerir MFA mediante la app Microsoft Authenticator para todos los inicios de sesión del grupo.
  • Bloquear acceso a aplicaciones críticas (Azure Management, Exchange On‑Prem, Power BI) añadiendo esas apps a la lista de exclusión.
  • Exigir dispositivo registrado: solo permitir acceso si el endpoint está inscrito en Intune. Para BYOD, usar Hybrid Azure AD Join o Microsoft Endpoint Manager enrollment.

Ejemplo de política (JSON simplificado) que se puede importar desde el portal:

{
  "conditions": {
    "users": { "include": ["External Users"] },
    "applications": { "include": ["All"] },
    "deviceStates": { "exclude": ["Compliant"] }
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["mfa"]
  }
}

3. Limitar permisos en SharePoint y OneDrive

  • Usar enlaces de compartición con expiración (7‑30 días) y con view only cuando sea posible.
  • Aplicar etiquetas de confidencialidad a bibliotecas que contengan datos sensibles; la etiqueta activa automáticamente DLP y encripta el contenido.
  • Configurar “External sharing” a nivel de sitio: desactivar “Anyone” y habilitar solo “New and existing guests”.

4. Implementar Azure AD Identity Protection (Entra ID P2)

Con la licencia P2, habilitar:

  • Risky sign‑in detections: bloquea automáticamente logins con IP desconocida o anomalías de comportamiento.
  • User risk policy: eleva el nivel de riesgo cuando se detecta credencial comprometida y fuerza el restablecimiento de contraseña + MFA.

5. Auditar y monitorizar

  • Log Analytics: enviar los logs de Azure AD, Intune y SharePoint a un workspace de Log Analytics. Crear alertas para eventos como “guest added to privileged group” o “download de más de 1 GB desde SharePoint”.
  • Microsoft Defender for Cloud Apps: habilitar la detección de actividades de alto riesgo (descarga masiva, uso de aplicaciones no aprobadas).

6. Proceso de off‑boarding automático

Al cerrar el contrato, remover al usuario del grupo “External Users” y revocar sus tokens con:

# Revocar sesiones y tokens
Connect-AzureAD
Revoke-AzureADUserAllRefreshToken -ObjectId <UserObjectId>
Remove-AzureADUser -ObjectId <UserObjectId>

Esto garantiza que cualquier sesión activa quede invalidada inmediatamente.

Cuándo aplicar esta solución

  • Contratistas o partners que usan BYOD y necesitan acceso a Office 365, Teams y SharePoint.
  • Entornos donde la separación de datos es obligatoria (normativas GDPR, ISO 27001).
  • Organizaciones con licencias Microsoft 365 Business Premium o E3/E5 que pueden habilitar Conditional Access y Entra ID.
  • No aplica cuando el externo es un proveedor de infraestructura con acceso a la red interna mediante VPN; en ese caso se requiere segmentación de red y firewalls adicionales.

Código

# 1. Conectar a Azure AD
Connect-AzureAD

# 2. Crear grupo dinámico para externos
$rule = "user.userType -eq `"Guest`" -or user.mail -contains `"@partnerdomain.com`""
New-AzureADMSGroup -DisplayName "External Users" -MailEnabled $false -SecurityEnabled $true -GroupTypes @("DynamicMembership") -MembershipRule $rule -MembershipRuleProcessingState "On"

# 3. Revocar tokens al terminar contrato
$uid = (Get-AzureADUser -ObjectId [email protected]).ObjectId
Revoke-AzureADUserAllRefreshToken -ObjectId $uid
Remove-AzureADUser -ObjectId $uid

Verificación

  1. Comprobar membresía del grupo: Get-AzureADGroupMember -ObjectId <GroupId> debe listar solo usuarios externos.
  2. Probar MFA: iniciar sesión con una cuenta externa y confirmar que se solicita el código de la app Authenticator.
  3. Validar política de dispositivo: intentar acceder desde un equipo no enrolado; la sesión debe ser bloqueada.
  4. Revisar logs: en Log Analytics, buscar eventos SignInRiskEvent y SharePointFileDownloaded.
  5. Confirmar expiración de enlaces: crear un enlace de compartición y verificar que desaparece tras el período configurado.

Notas adicionales

  • Licencias: la mayoría de las políticas de Conditional Access están disponibles con Microsoft 365 Business Premium o Azure AD Premium P1. Las políticas de riesgo requieren P2.
  • Slack Connect: aunque no forma parte de M365, aplicar la misma lógica de grupos dinámicos en Slack (usando SCIM) ayuda a mantener la coherencia.
  • GitLab: si está auto‑hosteado, usar SAML con Azure AD y asignar al grupo “External Users” solo los permisos de proyecto necesarios.
  • Alertas de DLP: configurar notificaciones por correo a los administradores de seguridad cuando se active una regla de DLP en SharePoint.
  • Revisión periódica: programar una revisión trimestral de los grupos dinámicos y de las políticas de Conditional Access para evitar que usuarios inactivos sigan con acceso.

Con este enfoque, los contratistas pueden trabajar con las herramientas habituales sin que la organización abra brechas de seguridad. La clave está en tratar a los externos como una categoría distinta desde el momento de la creación de la identidad y aplicar controles de acceso y monitorización que reflejen su nivel de confianza.