|
| 1 | +--- |
| 2 | +title: Data protection considerations |
| 3 | +description: Learn how services store and retrieve Azure AD object data through an RBAC authorization layer. |
| 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/19/2023 |
| 12 | +ms.author: jricketts |
| 13 | +ms.reviewer: jricketts |
| 14 | +ms.custom: "it-pro" |
| 15 | +ms.collection: |
| 16 | +--- |
| 17 | + |
| 18 | +# Data protection considerations |
| 19 | + |
| 20 | +The following diagram illustrates how services store and retrieve Azure Active Directory (Azure AD) object data through a role-based access control (RBAC) authorization layer. This layer calls the internal directory data access layer, ensuring the user's data request is permitted: |
| 21 | + |
| 22 | +  |
| 23 | + |
| 24 | +**Azure AD Internal Interfaces Access**: Service-to-service communication with other Microsoft services, such as Microsoft 365 use Azure AD interfaces, which authorize the service's callers using client certificates. |
| 25 | + |
| 26 | +**Azure AD External Interfaces Access**: Azure AD external interface helps prevent data leakage by using RBAC. When a security principal, such as a user, makes an access request to read information through Azure AD interfaces, a security token must accompany the request. The token contains claims about the principal making the request. |
| 27 | + |
| 28 | +The security tokens are issued by the Azure AD Authentication Services. Information about the user’s existence, enabled state, and role is used by the authorization system to decide whether the requested access to the target tenant is authorized for this user in this session. |
| 29 | + |
| 30 | +**Application Access**: Because applications can access the Application Programming Interfaces (APIs) without user context, the access check includes information about the user’s application and the scope of access requested, for example read only, read/write, etc. Many applications use OpenID Connect or OAuth to obtain tokens to access the directory on behalf of the user. These applications must be explicitly granted access to the directory or they won't receive a token from Azure AD Authentication Service, and they access data from the granted scope. |
| 31 | + |
| 32 | +**Auditing**: Access is audited. For example, authorized actions such as create user and password reset create an audit trail that can be used by a tenant administrator to manage compliance efforts or investigations. Tenant administrators can generate audit reports by using the Azure AD audit API. |
| 33 | + |
| 34 | +Learn more: [Audit logs in Azure Active Directory](../reports-monitoring/concept-audit-logs.md) |
| 35 | + |
| 36 | +**Tenant Isolation**: Enforcement of security in Azure AD multi-tenant environment helps achieve two primary goals: |
| 37 | + |
| 38 | +* Prevent data leakage and access across tenants: Data belonging to Tenant 1 can't be obtained by users in Tenant 2 without explicit authorization by Tenant 1. |
| 39 | +* Resource access isolation across tenants: Operations performed by Tenant 1 can't affect access to resources for Tenant 2. |
| 40 | + |
| 41 | +## Tenant isolation |
| 42 | + |
| 43 | +The following information outlines tenant isolation. |
| 44 | + |
| 45 | +* The service secures tenants using RBAC policy to ensure data isolation. |
| 46 | +* To enable access to a tenant, a principal, for example a user or application, needs to be able to authenticate against Azure AD to obtain context and has explicit permissions defined in the tenant. If a principal isn't authorized in the tenant, the resulting token won't carry permissions, and the RBAC system rejects requests in this context. |
| 47 | +* RBAC ensures access to a tenant is performed by a security principal authorized in the tenant. Access across tenants is possible when a tenant administrator creates a security principal representation in the same tenant (for example, provisioning a guest user account using B2B collaboration), or when a tenant administrator creates a policy to enable a trust relationship with another tenant. For example, a cross-tenant access policy to enable B2B Direct Connect. Each tenant is an isolation boundary; existence in one tenant doesn't equate existence in another tenant unless the administrator allows it. |
| 48 | +* Azure AD data for multiple tenants is stored in the same physical server and drive for a given partition. Isolation is ensured because access to the data is protected by the RBAC authorization system. |
| 49 | +* A customer application can't access Azure AD without needed authentication. The request is rejected if not accompanied by credentials as part of the initial connection negotiation process. This dynamic prevents unauthorized access to a tenant by neighboring tenants. Only user credential’s token, or Security Assertion Markup Language (SAML) token, is brokered with a federated trust. Therefore, it's validated by Azure AD, based on the shared keys configured by the Azure AD tenant Global Administrator. |
| 50 | +* Because there's no application component that can execute from the Core Store, it's not possible for one tenant to forcibly breach the integrity of a neighboring tenant. |
| 51 | + |
| 52 | +## Data security |
| 53 | + |
| 54 | +**Encryption in Transit**: To assure data security, directory data in Azure AD is signed and encrypted while in transit between data centers in a scale unit. The data is encrypted and unencrypted by the Azure AD Core Store tier, which resides in secured server hosting areas of the associated Microsoft data centers. |
| 55 | + |
| 56 | +Customer-facing web services are secured with the Transport Layer Security (TLS) protocol. |
| 57 | + |
| 58 | +**Secret Storage**: Azure AD Service back-end uses encryption to store sensitive material for service use, such as certificates, keys, credentials, and hashes using Microsoft proprietary technology. The store used depends on the service, the operation, the scope of the secret (user-wide or tenant-wide), and other requirements. |
| 59 | + |
| 60 | +These stores are operated by a security-focused group via established automation and workflows, including certificate request, renewal, revocation, and destruction. |
| 61 | + |
| 62 | +There's activity auditing related to these stores/workflows/processes, and there is no standing access. Access is request- and approval-based, and for a limited amount of time. |
| 63 | + |
| 64 | +For more information about Secret encryption at rest, see the following table. |
| 65 | + |
| 66 | +**Algorithms**: The following table lists the minimum cryptography algorithms used by Azure AD components. As a cloud service, Microsoft reassesses and improves the cryptography, based on security research findings, internal security reviews, key strength against hardware evolution, etc. |
| 67 | + |
| 68 | +|Data/scenario|Cryptography algorithm| |
| 69 | +|---|---| |
| 70 | +|Password hash sync</br>Cloud account passwords|Hash: Password Key Derivation Function 2 (PBKDF2), using HMAC-SHA256 @ 1000 iterations | |
| 71 | +|Directory in transit between data centers|AES-256-CTS-HMAC-SHA1-96</br>TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | |
| 72 | +|Pass-through authentication user credential flow|RSA 2048-Public/Private key pair </br> Learn more: [Azure Active Directory Pass-through Authentication security deep dive](../hybrid/how-to-connect-pta-security-deep-dive.md)| |
| 73 | +|Self-service password reset password writeback with Azure AD Connect: Cloud to on-premises communication |RSA 2048 Private/Public key pair</br>AES_GCM (256-bits key, 96-bits IV size)| |
| 74 | +|Self-service password reset: Answers to security questions|SHA256| |
| 75 | +|SSL certificates for Azure AD application</br>Proxy published applications |AES-GCM 256-bit | |
| 76 | +|Disk-level encryption|XTS-AES 128| |
| 77 | +|[Seamless single sign-on (SSO)](../../active-directory/hybrid/how-to-connect-sso-how-it-works.md) service account password</br>SaaS application provisioning credentials|AES-CBC 128-bit | |
| 78 | +|Azure AD Managed Identities|AES-GCM 256-bit| |
| 79 | +|Microsoft Authenticator app: Passwordless sign-in to Azure AD |Asymmetric RSA Key 2048-bit| |
| 80 | +|Microsoft Authenticator app: Backup and restore of enterprise account metadata |AES-256 | |
| 81 | + |
| 82 | +## Resources |
| 83 | +* [Azure AD and data residency](azure-ad-data-residency.md) |
| 84 | +* [Microsoft Service Trust Documents](https://servicetrust.microsoft.com/Documents/TrustDocuments) |
| 85 | +* [Microsoft Azure Trust Center](https://azure.microsoft.com/overview/trusted-cloud/) |
| 86 | +* [Where is my data? - Office 365 documentation](http://o365datacentermap.azurewebsites.net/) |
| 87 | +* [Recover from deletions in Azure Active Directory](recover-from-deletions.md) |
0 commit comments