Edit

Data operational considerations

  • Article

In this article, learn about data operational considerations for your configuration. There's information about how log files and other features work in relation to Microsoft Entra ID, such as usage data and operator security. You'll learn about physical security considerations in addition to guidance on how the Microsoft Entra team defines deployments and change.

Log files

Microsoft Entra ID generates log files for auditing, investigation, and debugging for actions and events in the service. Log files might contain data about users, devices, and Microsoft Entra configuration, for instance policies, apps, and groups. Log files are created and stored in Azure Storage in the datacenter where the Microsoft Entra service runs.

Log files are used for local debugging, security, usage analysis, system-health monitoring, and service-wide analysis. These logs are copied over a Transport Layer Security (TLS) connection to Microsoft reporting machine learning systems, which are in Microsoft-owned datacenters in the continental United States.

Usage data

Usage data is metadata generated by the Microsoft Entra service that indicates how the service is being used. This metadata is used to generate administrator- and user-facing reports. The Microsoft Entra engineering team uses the metadata to evaluate system usage and identify opportunities to improve the service. Generally, this data is written to log files, but in some cases, is collected by our service monitoring and reporting systems.

Operator security

Access to Microsoft Entra ID by Microsoft personnel, contractors, and vendors (system admins) is highly restricted. Wherever possible, human intervention is replaced by an automated, tool-based process, including routine functions such as deployment, debugging, diagnostic collection, and restarting services.

Administrator access is limited to a subset of qualified engineers and requires completion of an authentication challenge with phishing-resistant credentials. System access and update functions are assigned to roles managed by the Microsoft just-in-time (JIT) privileged-access management system. System administrators request elevation using the JIT system, which routes the request for manual or automated approval. Upon approval, JIT elevates the account. Requests for elevation, approval, elevation into roles, and removal from roles are logged for future debugging or investigations.

Microsoft personnel can execute operations only from a secure access workstation, which uses an internal isolated strong authentication identity platform. Access to other Microsoft identity systems doesn't grant access to the security access workstation. The identity platform runs separately from other Microsoft identity systems.

Physical security

Physical access to servers that comprise the Microsoft Entra service, and access to Microsoft Entra back-end systems, is restricted by Azure facility, premises, and physical security. Microsoft Entra customers have no access to physical assets or locations, therefore they can't bypass the logical role-based access control (RBAC) policy checks. Personnel with operator access are authorized to run approved workflows for maintenance.

Learn more: Azure facilities, premises, and physical security

Change control process

To roll out changes to the service across datacenters, the Microsoft Entra team defines the layers of a deployment environment. Applying the change layers is constrained by strict exit criteria. The amount of time to roll a change across layers is defined by the operations team and is based on potential effects. Typically a rollout takes between 1 to 2 weeks. Critical changes, such as security fixes or hot fixes, can be deployed faster. If a change doesn't meet the exit criteria when applied to a deployment layer, it's rolled back to the prior, stable state.

Resources

Next steps