|
| 1 | +--- |
| 2 | +title: Data operational considerations |
| 3 | +description: Learn how |
| 4 | +services: active-directory |
| 5 | +author: janicericketts |
| 6 | +manager: martinco |
| 7 | +ms.service: active-directory |
| 8 | +ms.workload: identity |
| 9 | +ms.subservice: fundamentals |
| 10 | +ms.topic: conceptual |
| 11 | +ms.date: 01/26/2023 |
| 12 | +ms.author: jricketts |
| 13 | +ms.reviewer: jricketts |
| 14 | +ms.custom: "it-pro" |
| 15 | +ms.collection: |
| 16 | +--- |
| 17 | + |
| 18 | +# Data operational considerations |
| 19 | + |
| 20 | +## Log files |
| 21 | + |
| 22 | +Azure Active Directory (Azure AD) generates log files for auditing, investigation, and debugging for actions and events in the service. Log files might contain data about users, devices, and Azure AD configuration, for instance policies, apps, and groups. Log files are created and stored in Azure Storage in the data center where the Azure AD service runs. |
| 23 | + |
| 24 | +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 data centers in the continental United States. |
| 25 | + |
| 26 | +## Usage data |
| 27 | + |
| 28 | +Usage data is metadata generated by the Azure AD service that indicates how the service is being used. This metadata is used to generate administrator- and user-facing reports. The Azure AD 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. |
| 29 | + |
| 30 | +## Operator security |
| 31 | + |
| 32 | +Access to Azure AD 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. |
| 33 | + |
| 34 | +Admininstrator 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. |
| 35 | + |
| 36 | +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. |
| 37 | + |
| 38 | +## Physical security |
| 39 | + |
| 40 | +Physical access to servers that comprise the Azure AD service, and access to Azure AD back-end systems, is restricted by Azure facility, premises, and physical security. Azure AD 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. |
| 41 | + |
| 42 | +Learn more: [Azure facilities, premises, and physical security](physical-security.md) |
| 43 | + |
| 44 | +## Change control process |
| 45 | + |
| 46 | +To roll out changes to the service across data centers, the Azure AD 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 does not meet the exit criteria when applied to a deployment layer, it is rolled back to the prior, stable state. |
| 47 | + |
| 48 | +## Resources |
| 49 | + |
| 50 | +[Azure AD and data residency](azure-ad-data-residency.md) |
| 51 | +[Data protection considerations](data-protection-considerations.md) |
| 52 | +[Microsoft Service Trust Documents](https://servicetrust.microsoft.com/Documents/TrustDocuments) |
| 53 | +[Microsoft Azure Trusted Cloud](https://azure.microsoft.com/explore/trusted-cloud/) |
| 54 | +[Where is my data? Office 365 documentation](http://o365datacentermap.azurewebsites.net/) |
0 commit comments