Iniciar sesión Solicitar demo
Docs / SaaS Posture (SSPM)

Para conectar SSPM a tu tenant M365 registrás una App en tu Entra ID con permisos de tipo Application (client credentials flow). Cada tenant cliente registra su propia App — no hay una “app compartida” de eMate en tu directorio.

Paso 1 — Registrar la App

En Azure Portal → Entra ID → App registrations → New registration:

  • Name: eMate Platform Security
  • Supported account types: Single tenant (accounts in this organizational directory only).
  • Redirect URI: en blanco.

Guardá los valores:

  • Application (client) ID (GUID).
  • Directory (tenant) ID (GUID).

Paso 2 — Crear un client secret

En la App → Certificates & secrets → New client secret:

  • Description: eMate — {fecha}.
  • Expires: 12 o 24 meses (el máximo permitido por policy).

Guardá el value inmediatamente — Azure lo muestra una sola vez.

Paso 3 — Otorgar permisos

En la App → API permissions → Add a permission → Microsoft Graph → Application permissions, agregá según lo que querés que la plataforma vea:

Mínimo — Directorio + identidades

  • User.Read.All
  • Directory.Read.All
  • Domain.Read.All
  • RoleManagement.Read.Directory

Auth + MFA

  • UserAuthenticationMethod.Read.All
  • Policy.Read.All

Identity Protection (requiere Entra P2 en el tenant cliente)

  • IdentityRiskyUser.Read.All
  • IdentityRiskEvent.Read.All
  • AuditLog.Read.All — también habilita signInActivity per-user y sign-in history en el drill-down de empleados.

Apps OAuth

  • Application.Read.All
  • DelegatedPermissionGrant.ReadWrite.All (ReadWrite necesario para el revoke con 1-click)
  • AppRoleAssignment.ReadWrite.All

Mail (para phishing auto-purge en Awareness)

  • Mail.Read
  • Mail.ReadWrite
  • MailboxSettings.Read

Files / SharePoint (external shares)

  • Files.Read.All
  • Sites.Read.All
  • SharePointTenantSettings.Read.All

Audit + Security

  • Reports.Read.All
  • SecurityEvents.Read.All
  • InformationProtectionPolicy.Read.All

Exchange (mailbox audit summary, connectors, forwarding, DLP)

  • Exchange.ManageAsApp

Después de agregar todos → Grant admin consent for {tu tenant}.

Paso 3.1 — Roles de Exchange Online (paso adicional en PowerShell)

Exchange.ManageAsApp por sí solo no alcanza — le dice a Entra ID que la App puede conectarse a Exchange “como sí misma”, pero sin un rol asignado la App se conecta y no puede hacer nada. Hace falta un paso extra en Exchange Online PowerShell (Connect-ExchangeOnline como admin).

Primero, una sola vez — registrar la App como Service Principal dentro de Exchange Online (además de existir en Entra ID):

New-ServicePrincipal -AppId <application-client-id> -ObjectId <object-id-de-la-app-en-entra-id> -DisplayName "eMate Platform Security"

Después, asigná los roles según qué partes de SSPM usás — no todos los tenants necesitan los 4:

Rol 1 — lectura de configuración y mail flow (Connectors Policy, Org Config Policy, spam/remote domain — la mayoría de los tenants necesita este):

New-ManagementRoleAssignment -Role "View-Only Configuration" -App <object-id-de-la-app>

Rol 2 — lectura de buzones (Mailbox Delegations, Mailbox Audit Detail, reenvío externo por buzón — si contrataste esos checks):

New-ManagementRoleAssignment -Role "View-Only Recipients" -App <object-id-de-la-app>

Rol 3 — políticas de Defender for Office 365 (Anti-Phish, Safe Links, Safe Attachments — si contrataste esos checks):

New-ManagementRoleAssignment -Role "Security Reader" -App <object-id-de-la-app>

Rol 4 — solo si usás la remediación 1-click de Org Config (activar Modern Auth / MailTips desde la plataforma en vez de solo alertarte): este es el único de escritura, y es un rol distinto del de solo-lectura del Rol 1 — View-Only Configuration no alcanza para escribir:

New-ManagementRoleAssignment -Role "Organization Configuration" -App <object-id-de-la-app>

DLP Policies — caso aparte, no es Exchange RBAC: vive en Microsoft Purview (Compliance Center), un sistema de permisos distinto. Si contrataste el check de DLP Policies, además de todo lo anterior:

  1. Microsoft Purview portal → Roles & scopes → Role groups.
  2. Agregá la App como miembro del role group Compliance Administrator.

Los roles 1-3 son de solo lectura — no habilitan a la App a cambiar nada en tu Exchange. Solo el Rol 4 (Organization Configuration) es de escritura, y la plataforma nunca lo usa salvo que dispares explícitamente la remediación 1-click de esa feature puntual.

Paso 4 — Configurar en la plataforma

En Integraciones → Microsoft 365 → Configurar credenciales, ingresá:

  • Directory (tenant) ID
  • Application (client) ID
  • Client secret (value)

La plataforma:

  1. Valida las credenciales pidiendo un access token.
  2. Confirma qué scopes están efectivamente concedidos.
  3. Corre el primer sync manualmente y muestra el conteo de users descubiertos.

De ahí en adelante, ticks horarios mantienen todo sincronizado.

¿Qué pasa si falta un scope?

La plataforma degrada silenciosamente. Ejemplo:

  • Sin AuditLog.Read.All → no vas a ver last_activity_at ni sign-in history — pero el resto del sync funciona.
  • Sin IdentityRiskyUser.Read.All → el tab “Riesgo” en el drill-down muestra “no disponible” pero users siguen sincronizándose.
  • Sin Mail.ReadWrite → el auto-purge de phishing no funciona pero las alertas siguen llegando.
  • Con Exchange.ManageAsApp concedido pero sin el paso 3.1 de PowerShell (o con el rol equivocado) → Connectors Policy, Mailbox Delegations, Mailbox Audit Detail, reenvío externo, políticas de Defender y/o DLP Policies fallan con un error de permisos genérico (“verify Exchange.ManageAsApp permission has admin consent AND customer ran New-ServicePrincipal + New-ManagementRoleAssignment in EXO”) — no te dice cuál de los 4 roles específicamente falta, así que si ves ese error revisá que los 4 estén asignados según qué checks contrataste.

Podés agregar scopes progresivamente y re-conceder consent. Los roles de PowerShell del paso 3.1 se pueden asignar en cualquier momento, en el orden que quieras.

Rotación del secret

Cuando el secret está por vencer (Azure notifica 30 días antes), en la plataforma vas a ver una alerta en Integraciones. Generá un secret nuevo en Azure, pegalo en la plataforma (reemplaza el viejo), y borrá el viejo del portal.

Multi-tenant vs single-tenant

La plataforma usa single-tenant apps: cada cliente tiene su propia App en su propio Entra ID. Ventajas:

  • Vos controlás el secret y el consent — nada corre “por debajo”.
  • Podés revocar en cualquier momento eliminando la App.
  • La plataforma nunca ve credenciales de otros tenants.

La desventaja: setup manual la primera vez. Un flow “OAuth 1-click multi-tenant” está en roadmap pero requiere que registremos la App de eMate como Microsoft-verified — es un proceso con Microsoft de meses. Mientras tanto, el setup manual es el path oficial.