Azure AD Cloud Solution Models

#azure AD offers various cloud solutions models, based on #infrastructure , #data location, and operation?sovereignty, described in attached document.

#m365 #microsoft ActiveDirectory Expert #ad #aad

1 Azure Active Directory Security Considerations By Debasis Mallick

?Azure Active Directory Data Security Considerations

This article explains the following aspects of Azure Active Directory:?

Azure AD Components: What are the different components of Azure AD. This will help you to understand the later sections of the document. Core Data and Location: What customer data is used by Azure AD and where is it located.

Data Protection: How is the directory data protected at transit and at rest.

Data Flow: How data from various sources such as on premises directories and applications flows to and from Azure AD.

Data and Operations: What data and operational procedures are used by the Azure AD engineering team to manage the service.?

Azure Active Directory Components

The following major components are outlined.

Directory Data is the data stored for your directory system. The directory data is created from the identity and access data provided by your organization to populate the service. This data includes the following entities and their attributes: Users, groups and group memberships, devices, applications, and roles. Directory Data also includes the metadata necessary to represent the relationships between these objects; some of which is provided by the customer and some of which is created by Azure AD services based on user actions such as registering applications, joining devices, etc.

Core Store is the complete set of an organization’s Directory Data is stored in a logical container (a "tenant") in a specific scale unit in the Azure AD distributed data store. The Azure

AD storage is divided into scale units, and each unique scale unit holds multiple tenants. The Azure AD core store also provides the directory data access interfaces to other services.

Authentication Services: Processes user input, validates credentials, and implements the authentication flows, endpoints, and security tokens required by the different industry standards supported by the system. The industry standards define the format and exchange patterns for issuing, renewing, canceling, and validating security tokens provided by the authentication services as a security token service (STS).

Identity Security and Protection Services: Provides identity-driven protection to users when interacting with the system such as Azure Multifactor Authentication (MFA), Azure AD Identity Protection, and Conditional Access.

Identity and Access Management (IAM) Services: Provides advanced identity management features such as self-service password reset, self-service group management, dynamic group membership, automated app assignment, provisioning for third-party services, management interfaces, and reporting capabilities.

Azure AD Services: Provides customers the infrastructure necessary to integrate existing on- premises infrastructure to Azure AD.?

o??Azure AD Connect provides synchronization of on-premises directory users to the cloud.

o??Azure AD Connect Health provides monitoring and analytics for synchronization, federation, and domain services.?

o??Azure AD Application Proxy enables secure publishing of on-premises web applications for remote access.?

o??Azure AD Domain Services Provides managed domain services, such as domain join, group policy, LDAP, Kerberos, and NTLM authentication. These services are fully compatible with Windows Server Active Directory.?

Azure AD Identity Governance: Provides customers governance capabilities such as Azure AD Privileged Identity Management (PIM) Just In time (JIT) access to privileged roles, access certification, attestation campaigns, alerting, and reporting.

Core Store

Azure AD is an Identity as a Service (IDaaS) solution that enables customers to store and manage Identity and Access data in the cloud and use it to enable and manage access to cloud services, achieve mobility scenarios, and secure their organization. An instance of the Azure AD service for a customer, called a tenant, is an isolated set of Directory Object Data provisioned and owned by the customer. Data operations, such as updates or retrievals, in the Azure AD core store, are scoped to a single tenant based on the user’s security token, to achieve tenant isolation.

?

As indicated above, the core store is made up of individual tenants. Tenants are stored in scale units, each of which contains multiple tenants. The Azure AD service replicates each scale unit to all the physical data centers of a logical region for resiliency and performance.

?

Azure AD currently has the following logical regions: North America, Europe Middle East, and Africa (EMEA), China, Germany, US Government, and Worldwide. Each of these handle directory data based on usability, performance, residency and/or sovereignty requirements. Residency means that Microsoft provides assurance that the data will not be persisted outside of the geographic region. Sovereignty means that a designated company (called a data custodian) runs data centers, as well as controls access to customer data and the systems and infrastructure that controls customer data.

?

The Azure AD service replicates each tenant through its scale unit among multiple data centers based on the following criteria:

?

?????????Reduce latency to assure fast login times for users by storing Directory Data in data centers closest to the locations where they reside.

?????????Assure availability if there are unforeseen geological events by storing Directory Data in data centers that are geographically isolated from each other.

?????????Compliance with data residency or sovereignty requirements for specific customers

and countries/regions.

When a tenant is created (for example, signing up to office 365 or Azure, or when creating additional instances of Azure AD through the Microsoft Azure portal) the user selects a country or region as the primary location. Azure AD automatically maps the selection to a logical region and a single scale unit within it. Tenant administrators cannot change a tenant’s location after it is created.

Azure AD offers various cloud solutions models, based on infrastructure, data location, and operation sovereignty, as described in the below.

(1)??EMEA region and Germany region differences: Signing up with the regular experience (portal.azure.com or office.com) and choosing Germany as the country region will result in an Azure AD tenant created in the EMEA Azure AD logical region. To create a tenant in the Germany national Cloud, please refer to Microsoft Cloud Deutschland

?

(2)??Data Custodians: Data centers in Microsoft's Worldwide region are operated by Microsoft. In China, Azure AD is operated through a partnership with 21Vianet. In Germany, Azure is available through a data trustee model with Deutsche Telekom.?

(3)??Authentication Data: Tenants outside of the National Clouds have authentication information at rest in the continental US.

?Learn more:

???????Understand Azure Active Directory architecture

???????Which Azure region is right for me?

???????Microsoft Trust Center - Microsoft National Clouds

Data Location across Azure AD Components

Aside from authentication service data (described in more detail in the table in the "Data storage across Azure AD Components" section below), Azure AD components, and service data is located or stored inside the region of the Azure AD edition.

Learn more: #Azure Active Directory Features and Capabilities

NOTE:

To understand the data location of additional services (such as Exchange Online, or Skype for Business), please refer to the

corresponding service’s documentation.

Data Storage across Azure AD Components

Below, is a summary of the data storage per Azure AD Components.

Azure AD Authentication Services: The current Azure AD Authentication Service is stateless. The data needed to perform authentication resides in the Azure

AD core store. It has no Directory Data on its own.

The Authentication Service generates log data that is stored in Azure storage in the data center where the service instance is running. When users attempt to authenticate using Azure AD, they are automatically routed to an instance at the geographically nearest data center, which is part of its Azure AD logical region. Some applications and services, such as Office 2010 desktop clients, use an earlier generation of the Azure AD Authentication Services. That generation of authentication Services has the following differences with the current iteration (described above):

?

1. It implements the delegation flows of Oasis WS-Trust that are used by legacy clients.

2. It stores its own state and has objects representing Azure AD users. This user object has the following attributes: (1) User namespace identifier (System Generated based on the user’s domain),(2) Username, (3) Password Hash, (4) First Name, (5) Last Name, and (6) User unique identifier (System Generated) that identifies the user across Microsoft cloud services.

3.???The China logical region has its own instance of this earlier generation of authentication services.

4.???For Worldwide, North America and EMEA logical regions, Microsoft hosts the service in two data centers in the continental United States. Azure AD copies the User Objects with the attributes mentioned to these two data centers.

5.???The legacy authentication service is not available in Germany or US Government clouds.?

Learn more: How modern authentication works for Office 2013 and Office 2016 client apps - Office 365

#Azure AD IAM Services:?

·????User Experience and Management Experience: The Azure AD management experience is entirely stateless and has no Directory Data of its own. It generates log and usage data, which is stored in Azure table storage. Identity Management Business Logic and Reporting Services: These services have locally cached data storage for groups and users.

?These services also generate log and usage data that is stored in Azure table storage, Azure SQL and in Microsoft's Elastic Search reporting services.

?

Azure MFA: The Azure MFA service logs the username (UPN) and telephone number for voice calls and SMS challenges. For challenges sent to mobile app modes, the service logs the username and a unique device token. The Azure MFA service and the logs it creates are currently stored in data centers in the North America region.

Azure AD Domain Services: Regions where Azure AD Domain Services is published at: Products available by region. The service holds system metadata globally in azure tables, and it does

not contain any personal data.

Azure AD Connect Health: Azure AD Connect Health generates alerts and reports in Azure Table Storage and blob storage.

Azure AD Dynamic Membership for Groups/ Azure AD Self-Service Group Management: The definition of dynamic membership rules is stored in Azure Table storage.

Azure AD Application Proxy: Azure AD Application Proxy stores metadata about the tenant, connector machines, and configuration data in SQL Azure.

Azure AD Password Reset: Azure AD Password Reset backend service uses Redis Cache to track session state.

Azure AD Device Registration Service: Provides lifecycle management of computers and devices in the directory, which enable scenarios such as device-state conditional access, and mobile device management.

Azure AD B2B Collaboration: Azure AD B2B Collaboration does not have Directory Data of its own. It is important to note that users and other directory objects participating in a B2B relationship with another tenant will result in copying user data in other tenants, which may have data residency implications.

Azure AD Identity Protection: Azure AD Identity Protection uses real-time user login data along with multiple signals from company and industry sources to feed to its machine learning systems to detect anomalous logins. Personal data is scrubbed from this real-time login data before it is passed into the machine learning system, along with the remaining login data used to identify users and logins that are potentially risky. After the analysis is complete and the data is sent to Microsoft's reporting systems, the risky logins and usernames are flagged so administrators can generate reports.

Azure AD PIM: The Azure AD PIM service consists of two main components: a database stored in SQL Azure and the background service responsible for orchestrating events and tasks necessary to satisfy role assignment requests.

Production Azure AD PIM uses two separate Azure SQL databases to store tenant settings. The first database is used exclusively for European tenants. The first database is in and replicated between the European datacenters (North Europe and West Europe) for redundancy and availability purposes. Azure AD stores all other tenant settings in a SQL Azure database in US datacenters (Central US and East US 2). National clouds have their own database instances for PIM settings. PIM stores the role definitions for each tenant in the database. A role definition, for example, for Global Administrators, include role settings like the duration limits, multi-factor authentication requirements, and the role assignments eligible member and active member. The SQL Azure database also keeps current and past request information.

Request information includes role ID, user ID, type of request and start/end time. Furthermore, Azure AD PIM generates and stores alerts against violation of best practice rules, such as too many permanent administrators in the database. Azure AD PIM logs requests and assignments in the Azure AD audit log.

Azure AD Managed Identities for Azure resources: With managed identities systems can?authenticate to Azure services, without storing credentials in their system. Rather than using username and password, managed identities authenticate to Azure services with certificates. The service writes certificates it issues in Azure Cosmos DB in the East US region. Azure Cosmos DB provides geo-redundancy by globally replicating the data. Replicating the database provides a read- only copy in each Azure region Azure AD managed identities runs. Microsoft isolates each Cosmos DB instance in a specific Azure AD Cloud solution model.

The resource provider, such as the virtual machine host, will also store the certificate to use for authentication and identity flows with other Azure services.

?

The service stores its master key for accessing the Azure Cosmos DB in a datacenter secrets management service and the master encryption keys are stored in Azure Key Vault.

Data Protection Considerations

Access Control

As shown in the diagram below, services store and retrieve Directory Object Data through a role-based access control authorization layer that calls the internal

directory data access layer. This ensures that the data requested is allowed for the user requesting it:

Azure AD Internal Interfaces Access: Azure AD internal interfaces are used for service-to-service communication with other Microsoft services, such as Office

365. Those interfaces authorize the service’s callers using client certificates.

?

Azure AD External Interfaces Access: Azure AD external interface prevents data leakage by employing role-based access controls. When a security principal, such as a user, makes an access request to read information through Azure AD’s interfaces, a security token must accompany the request that contains claims about the principal making the request.

?

The security tokens are issued by the Azure AD Authentication Services. Information on the user’s existence, enabled state, and role is used by the authorization system to determine whether the requested access to the target tenant is authorized for this user in this session.

?

Application Access: Since applications can access the Application Programming Interfaces (APIs) directly (without any user context), the access check also includes information about the user’s application as well as the scope of access requested (for example read only, read/write, etc.). For example, 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 will not receive a token from the Security Token Service (STS), and they can only access data from within the specific scope they were granted.

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 at any time using the Azure AD audit API.

Learn more: Azure Active Directory audit report events

?Tenant Isolation: Enforcement of security in Azure AD’s multi-tenant environment involves two primary elements:?

A. Preventing data leakage and access across tenants. This means that data belonging to Tenant 1 cannot in any way be obtained by users in Tenant 2 without explicit authorization by Tenant 1.

B.?Resource access isolation across tenants. This means that operations performed by Tenant 1 cannot in any way impact access to resources for Tenant 2.

Below are some aspects on tenant isolation:

?

Each tenant is secured using Role-Based Access Control (RBAC) policy to ensure data isolation.

?

To enable access to a specific 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 is not authorized in the tenant, the resulting token will NOT carry any permissions and, as a result the RBAC system will reject any requests in this context.

RBAC ensures that access to a tenant is performed by a security principal that is explicitly defined and authorized within the tenant. Access across tenants is only possible where a tenant administrator explicitly creates a security principal representation in the same tenant. Examples of these representations are configuring a federation or provisioning a guest user account using B2Bcollaboration. This is because each tenant is an isolation boundary; existence in one tenant does not equate to existence in another tenant unless the administrator allows it.

?

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.

A customer application cannot access Azure AD without proper authentication. The request is rejected if not accompanied by the proper credentials as part of the initial connection negotiation process. This is core to preventing unauthorized access to a tenant by neighboring tenants. Only user credential’s token (or Security Assertion Markup Language (SAML) token) is brokered as part of a federated trust, and therefore validated by Azure AD based on the shared keys configured by the Global Administrator of your Azure AD tenant.

?

Since there is no application component that can execute directly from within the Core Store itself, it is not possible for one tenant to forcibly breach the integrity of a neighboring tenant.

Data Security

Encryption in Transit: To assure data security, Directory Data in Azure AD is signed and encrypted while in transit between data centers within a scale unit. The data is encrypted and unencrypted by the Azure AD core store tier, which resides inside secured server hosting areas of the associated Microsoft data centers.

?

Customer-facing web services are secured with the Transport Layer Security (TLS) protocol.

?

Secret Storage: Azure AD service back-end utilizes secret stores for storing of sensitive material for service use such as certificates, keys, credentials, and hashes using technology that is proprietary to Microsoft. The specific store used depends on the service, the operation, the scope of the secret (user- wide or tenant-wide), and other requirements.

?

These stores are operated by a security-focused group for the Azure fabric/service (the Azure Security Team) via established automation and workflows, including certificates’ request, renewal, revocation, and destruction.

?

There is auditing of activities related to these stores/workflows/processes and there is no ‘standing accesses. Access is request- and approval-based, and only for a limited amount of time.

?#microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.