Security Model

Security & permissions model

A consolidated view of how the solution authenticates, what it can access, and how data is protected. The detailed, step-by-step grants live on Prerequisites and Deployment Guidance; this page explains the model.

Identities

The solution uses two Entra ID app registrations (service principals):

• Installer — used only during install/upgrade to create & configure the Azure resources. Needs Owner of the resource group + Reader on the subscription.
• Runtime — used by the running importers to read Microsoft 365 data and access the Azure resources.

See Prerequisites → Solution service principals.

What the runtime account can access

Two distinct kinds of access, both held by the runtime service principal:

1. Microsoft Graph & Microsoft 365 API permissions (application permissions, admin-consented) — read-only access to the workloads you enable. Full list and per-permission reasons: Prerequisites → Permissions.
2. Azure RBAC roles — data-plane access to the solution's own Azure resources (Storage, Redis, Service Bus, Cognitive). Assigned automatically by the installer on the resource group. Full list: Prerequisites → Azure RBAC roles.

All Microsoft 365 access is read-only — the solution never writes back to your tenant's workloads.

Secrets & Key Vault

• The runtime account's client secret is stored in Key Vault and read by the importer at run time; it is also present as the ClientSecret app setting created by the installer.
• Prefer certificate authentication for the runtime account where possible — the certificate's private key lives in Key Vault and no client secret is needed. See Certificate authentication.
• The runtime account is granted Get/List secrets on the vault via a Key Vault access policy (not an Azure RBAC role).

Authenticating to Azure services (RBAC-first)

The solution prefers Entra ID (RBAC) authentication over keys wherever the service supports it:

Service	How the runtime authenticates
Service Bus	Entra ID RBAC (Azure Service Bus Data Owner). No SAS keys — works with namespaces that have local/SAS auth disabled.
Redis	Entra ID (AAD) token auth when access keys are disabled (Data Owner access-policy assignment).
Storage	Entra ID RBAC (Storage Blob Data Contributor).
Cognitive Services	Key, with automatic fallback to Entra ID RBAC (Cognitive Services User) when key auth is disabled.
Key Vault	Entra ID token + a vault access policy (Get/List secrets).
SQL Database	SQL authentication via the SPOInsightsEntities connection string.

Network security

• Private endpoints can lock every PaaS resource to a VNet with public access disabled — see Private endpoints.
• The installer can enable the Key Vault firewall and the SQL Server firewall, allow-listing the installer's IP and the App Service outbound IPs.
• See the Network & firewall rules the installer machine needs.

Data privacy

• All collected data stays in your own tenant and Azure subscription — in the analytics SQL database. Nothing about your tenant leaves your environment.
• De-identified (anonymised) usage reports must be turned off in the Microsoft 365 admin center, otherwise activity can't be matched to real users. See Prerequisites → Tenant & subscription configuration.
• Content & sentiment: when Azure AI Language (Cognitive Services) is enabled, Teams chat, page comments and (optional) sent-email bodies are scored for sentiment/keywords. This is optional and off unless configured.
• Anonymous usage telemetry is opt-in and contains no tenant data — only build version and which imports are enabled. Source is public and the receiver is documented: Telemetry Service.
• What is (and isn't) collected per workload: What data is collected.