Azure for secure worldwide public sector cloud adoption

Microsoft Azure is a multi-tenant cloud services platform that government agencies can use to deploy various solutions. A multi-tenant cloud platform implies that multiple customer applications and data are stored on the same physical hardware. Azure uses logical isolation to segregate each customer's applications and data. This approach provides the scale and economic benefits of multi-tenant cloud services while rigorously helping prevent customers from accessing one another's data or applications. Azure is available globally in more than 60 regions and can be used by government entities worldwide to meet rigorous data protection requirements across a broad spectrum of data classifications, including unclassified and classified data.

This article addresses common data residency, security, and isolation concerns pertinent to worldwide public sector customers. It also explores technologies available in Azure to safeguard both unclassified and classified workloads in the public multi-tenant cloud in combination with Azure Stack Hub and Azure Stack Edge deployed on-premises and at the edge.

Executive summary

Microsoft Azure provides strong customer commitments regarding data residency and transfer policies. Most Azure services enable you to specify the deployment region. For those services, Microsoft won't store your data outside your specified geography. You can use extensive and robust data encryption options to help safeguard your data in Azure and control who can access it.

Listed below are some of the options available to you to safeguard your data in Azure:

• You can choose to store your most sensitive content in services that store data at rest in Geography.
• You can obtain further protection by encrypting data with your own key using Azure Key Vault.
• While you can't control the precise network path for data in transit, data encryption in transit helps protect data from interception.
• Azure is a 24x7 globally operated service; however, support and troubleshooting rarely require access to your data.
• If you want extra control for support and troubleshooting scenarios, you can use Customer Lockbox for Azure to approve or deny access to your data.
• Microsoft will notify you of any breach of your data – customer or personal – within 72 hours of incident declaration.
• You can monitor potential threats and respond to incidents on your own using Microsoft Defender for Cloud.

Using Azure data protection technologies and intelligent edge capabilities from the Azure Stack portfolio of products, you can process confidential and secret data in secure isolated infrastructure within the public multi-tenant cloud or top secret data on premises and at the edge under your full operational control.

Introduction

Governments around the world are in the process of a digital transformation, actively investigating solutions and selecting architectures that will help them transition many of their workloads to the cloud. There are many drivers behind the digital transformation, including the need to engage citizens, empower employees, transform government services, and optimize government operations. Governments across the world are also looking to improve their cybersecurity posture to secure their assets and counter the evolving threat landscape.

For governments and the public sector industry worldwide, Microsoft provides Azure – a public multi-tenant cloud services platform – that you can use to deploy various solutions. A multi-tenant cloud services platform implies that multiple customer applications and data are stored on the same physical hardware. Azure uses logical isolation to segregate each customer's applications and data. This approach provides the scale and economic benefits of multi-tenant cloud services while rigorously helping prevent other customers from accessing your data or applications.

A hyperscale public cloud provides resiliency in time of natural disaster and warfare. The cloud provides capacity for failover redundancy and empowers sovereign nations with flexibility regarding global resiliency planning. Hyperscale public cloud also offers a feature-rich environment incorporating the latest cloud innovations such as artificial intelligence, machine learning, IoT services, intelligent edge, and many more to help government customers increase efficiency and unlock insights into their operations and performance.

Using Azure’s public cloud capabilities, you benefit from rapid feature growth, resiliency, and the cost-effective operation of the hyperscale cloud while still obtaining the levels of isolation, security, and confidence required to handle workloads across a broad spectrum of data classifications, including unclassified and classified data. Using Azure data protection technologies and intelligent edge capabilities from the Azure Stack portfolio of products, you can process confidential and secret data in secure isolated infrastructure within the public multi-tenant cloud or top secret data on-premises and at the edge under your full operational control.

This article addresses common data residency, security, and isolation concerns pertinent to worldwide public sector customers. It also explores technologies available in Azure to help safeguard unclassified, confidential, and secret workloads in the public multi-tenant cloud in combination with Azure Stack products deployed on-premises and at the edge for fully disconnected scenarios involving top secret data. Given that unclassified workloads comprise most scenarios involved in worldwide public sector digital transformation, Microsoft recommends that you start your cloud journey with unclassified workloads and then progress to classified workloads of increasing data sensitivity.

Data residency

Established privacy regulations are silent on data residency and data location, and permit data transfers in accordance with approved mechanisms such as the EU Standard Contractual Clauses (also known as EU Model Clauses). Microsoft commits contractually in the Microsoft Products and Services Data Protection Addendum (DPA) that all potential transfers of customer data out of the EU, European Economic Area (EEA), and Switzerland shall be governed by the EU Model Clauses. Microsoft will abide by the requirements of the EEA and Swiss data protection laws regarding the collection, use, transfer, retention, and other processing of personal data from the EEA and Switzerland. All transfers of personal data are subject to appropriate safeguards and documentation requirements. However, many customers considering cloud adoption are seeking assurances about customer and personal data being kept within the geographic boundaries corresponding to customer operations or location of customer’s end users.

Data sovereignty implies data residency; however, it also introduces rules and requirements that define who has control over customer data stored in the cloud. In many cases, data sovereignty mandates that customer data be subject to the laws and legal jurisdiction of the country/region in which data resides. These laws can have direct implications on data access even for platform maintenance or customer-initiated support requests. You can use Azure public multi-tenant cloud in combination with Azure Stack products for on-premises and edge solutions to meet your data sovereignty requirements, as described later in this article. These other products can be deployed to put you solely in control of your data, including storage, processing, transmission, and remote access.

Among several data categories and definitions that Microsoft established for cloud services, the following four categories are discussed in this article:

• Customer data is all data that you provide to Microsoft to manage on your behalf through your use of Microsoft online services.
• Customer content is a subset of customer data and includes, for example, the content stored in your Azure Storage account.
• Personal data means any information associated with a specific natural person, for example, names and contact information of your end users. However, personal data could also include data that isn't customer data, such as user ID that Azure can generate and assign to your administrator – such personal data is considered pseudonymous because it can't identify an individual on its own.
• Support and consulting data mean all data provided by you to Microsoft to obtain support or Professional Services.

For more information about your options to control data residency and meet your data protection obligations, see Enabling data residency and data protection in Microsoft Azure regions. The following sections address key cloud implications for data residency and the fundamental principles guiding Microsoft’s safeguarding of your data at rest, in transit, and as part of support requests that you initiate.

Data at rest

Microsoft provides transparent insight into data location for all online services available to you from Where your data is located. Expand Cloud service data residency and transfer policies section to reveal links for individual online services.

If you want to ensure your data is stored only in your chosen Geography, you should select from the many regional services that make this commitment.

Regional vs. non-regional services

Microsoft Azure provides strong customer commitments regarding data residency and transfer policies:

• Data storage for regional services: Most Azure services are deployed regionally and enable you to specify the region into which the service will be deployed. Microsoft won't store your data outside the Geography you specified except for a few regional services and Preview services as described on the Azure data location page. This commitment helps ensure that your data stored in a given region will remain in the corresponding Geography, and won't be moved to another Geography for most regional services. For service availability, see Products available by region.
• Data storage for non-regional services: Certain Azure services don't enable you to specify the region where the services will be deployed as described on the data location page. For a complete list of non-regional services, see Products available by region.

Your data in an Azure Storage account is always replicated to help ensure durability and high availability. Azure Storage copies your data to protect it from transient hardware failures, network or power outages, and even massive natural disasters. You can typically choose to replicate your data within the same data center, across availability zones within the same region, or across geographically separated regions. Specifically, when creating a storage account, you can select one of the following redundancy options:

• Locally redundant storage (LRS)
• Zone-redundant storage (ZRS)
• Geo-redundant storage (GRS)
• Geo-zone-redundant storage (GZRS)

Data in an Azure Storage account is always replicated three times in the primary region. Azure Storage provides LRS and ZRS redundancy options for replicating data in the primary region. For applications requiring high availability, you can choose geo-replication to a secondary region that is hundreds of kilometers away from the primary region. Azure Storage offers GRS and GZRS options for copying data to a secondary region. More options are available to you for configuring read access (RA) to the secondary region (RA-GRS and RA-GZRS), as explained in Read access to data in the secondary region.

Azure Storage redundancy options can have implications on data residency as Azure relies on paired regions to deliver geo-redundant storage (GRS). For example, if you're concerned about geo-replication across regions that span country boundaries, you may want to choose LRS or ZRS to keep Azure Storage data at rest within the geographic boundaries of the country in which the primary region is located. Similarly, geo replication for Azure SQL Database can be obtained by configuring asynchronous replication of transactions to any region in the world, although it's recommended that paired regions be used for this purpose as well. If you need to keep relational data inside the geographic boundaries of your country/region, you shouldn't configure Azure SQL Database asynchronous replication to a region outside that country/region.

As described on the data location page, most Azure regional services honor the data at rest commitment to ensure that your data remains within the geographic boundary where the corresponding service is deployed. A handful of exceptions to this rule are noted on the data location page. You should review these exceptions to determine if the type of data stored outside your chosen deployment Geography meets your needs.

Non-regional Azure services don't enable you to specify the region where the services will be deployed. Some non-regional services don't store your data at all but merely provide global routing functions such as Azure Traffic Manager or Azure DNS. Other non-regional services are intended for data caching at edge locations around the globe, such as the Content Delivery Network – such services are optional and you shouldn't use them for sensitive customer content you wish to keep in your Geography. One non-regional service that warrants extra discussion is Microsoft Entra ID, which is discussed in the next section.

Customer data in Microsoft Entra ID

Microsoft Entra ID is a non-regional service that may store identity data globally, except for Microsoft Entra deployments in:

• The United States, where identity data is stored solely in the United States.
• Europe, where Microsoft Entra ID keeps most of the identity data within European datacenters except as noted in Identity data storage for European customers in Microsoft Entra ID.
• Australia and New Zealand, where identity data is stored in Australia except as noted in Customer data storage for Australian and New Zealand customers in Microsoft Entra ID.

Microsoft Entra ID provides a dashboard with transparent insight into data location for every Microsoft Entra component service. Among other features, Microsoft Entra ID is an identity management service that stores directory data for your Azure administrators, including user personal data categorized as End User Identifiable Information (EUII), for example, names, email addresses, and so on. In Microsoft Entra ID, you can create User, Group, Device, Application, and other entities using various attribute types such as Integer, DateTime, Binary, String (limited to 256 characters), and so on. Microsoft Entra ID isn't intended to store your customer content and it isn't possible to store blobs, files, database records, and similar structures in Microsoft Entra ID. Moreover, Microsoft Entra ID isn't intended to be an identity management service for your external end users – Azure AD B2C should be used for that purpose.

Microsoft Entra ID implements extensive data protection features, including tenant isolation and access control, data encryption in transit, secrets encryption and management, disk level encryption, advanced cryptographic algorithms used by various Microsoft Entra components, data operational considerations for insider access, and more. Detailed information is available from a whitepaper Active Directory Data Security Considerations.

Generating pseudonymous data for internal systems

Personal data is defined broadly. It includes not just customer data but also unique personal identifiers such as Probably Unique Identifier (PUID) and Globally Unique Identifier (GUID), the latter being often labeled as Universally Unique Identifier (UUID). These unique personal identifiers are pseudonymous identifiers. This type of information is generated automatically to track users who interact directly with Azure services, such as your administrators. For example, PUID is a random string generated programmatically via a combination of characters and digits to provide a high probability of uniqueness. Pseudonymous identifiers are stored in centralized internal Azure systems.

Whereas EUII represents data that could be used on its own to identify a user (for example, user name, display name, user principal name, or even user-specific IP address), pseudonymous identifiers are considered pseudonymous because they can't identify an individual on their own. Pseudonymous identifiers don't contain any information that you uploaded or created.

Data in transit

While you can't control the precise network path for data in transit, data encryption in transit helps protect data from interception.

Data in transit applies to the following scenarios involving data traveling between:

• Your end users and Azure service
• Your on-premises datacenter and Azure region
• Microsoft datacenters as part of expected Azure service operation

While data in transit between two points within your chosen Geography will typically remain in that Geography, it isn't possible to guarantee this outcome 100% of the time because of the way networks automatically reroute traffic to avoid congestion or bypass other interruptions. That said, data in transit can be protected through encryption as detailed below and in Data encryption in transit section.

Your end users connection to Azure service

Most customers will connect to Azure over the Internet, and the precise routing of network traffic will depend on the many network providers that contribute to Internet infrastructure. As stated in the Microsoft Products and Services Data Protection Addendum (DPA), Microsoft doesn't control or limit the regions from which you or your end users may access or move customer data. You can increase security by enabling encryption in transit. For example, you can use Azure Application Gateway to configure end-to-end encryption of traffic. As described in Data encryption in transit section, Azure uses the Transport Layer Security (TLS) protocol to help protect data when it's traveling between you and Azure services. However, Microsoft can't control network traffic paths corresponding to your end-user interaction with Azure.

Your datacenter connection to Azure region

Virtual Network (VNet) provides a means for Azure virtual machines (VMs) to act as part of your internal (on-premises) network. You have options to securely connect to a VNet from your on-premises infrastructure – choose an IPSec protected VPN (for example, point-to-site VPN or site-to-site VPN) or a private connection by using Azure ExpressRoute with several data encryption options.

• IPSec protected VPN uses an encrypted tunnel established across the public Internet, which means that you need to rely on the local Internet service providers for any network-related assurances.
• ExpressRoute allows you to create private connections between Microsoft datacenters and your on-premises infrastructure or colocation facility. ExpressRoute connections don't go over the public Internet and offer lower latency and higher reliability than IPSec protected VPN connections. ExpressRoute locations are the entry points to Microsoft’s global network backbone and they may or may not match the location of Azure regions. For example, you can connect to Microsoft in Amsterdam through ExpressRoute and have access to all Azure cloud services hosted in Northern and Western Europe. However, it’s also possible to have access to the same Azure regions from ExpressRoute connections located elsewhere in the world. Once the network traffic enters the Microsoft backbone, it's guaranteed to traverse that private networking infrastructure instead of the public Internet.

Traffic across Microsoft global network backbone

As described in Data at rest section, Azure services such as Storage and SQL Database can be configured for geo-replication to help ensure durability and high availability especially for disaster recovery scenarios. Azure relies on paired regions to deliver geo-redundant storage (GRS), and paired regions are also recommended when configuring active geo-replication for Azure SQL Database. Paired regions are located within the same Geography.

Inter-region traffic is encrypted using Media Access Control Security (MACsec), which protects network traffic at the data link layer (Layer 2 of the networking stack) and relies on AES-128 block cipher for encryption. This traffic stays entirely within the Microsoft global network backbone and never enters the public Internet. The backbone is one of the largest in the world with more than 200,000 km of lit fiber optic and undersea cable systems. However, network traffic isn't guaranteed to always follow the same path from one Azure region to another. To provide the reliability needed for the Azure cloud, Microsoft has many physical networking paths with automatic routing around congestion or failures for optimal reliability. Therefore, Microsoft can't guarantee that network traffic traversing between Azure regions will always be confined to the corresponding Geography. In networking infrastructure disruptions, Microsoft can reroute the encrypted network traffic across its private backbone to ensure service availability and best possible performance.

Data for customer support and troubleshooting

Azure is a 24x7 globally operated service; however, support and troubleshooting rarely requires access to your data. If you want extra control over support and troubleshooting scenarios, you can use Customer Lockbox for Azure to approve or deny access requests to your data.

Microsoft Azure support is available in markets where Azure is offered. It's staffed globally to accommodate 24x7 access to support engineers via email and phone for technical support. You can create and manage support requests in the Azure portal. As needed, frontline support engineers can escalate your requests to Azure DevOps personnel responsible for Azure service development and operations. These Azure DevOps engineers are also staffed globally. The same production access controls and processes are imposed on all Microsoft engineers, which include support staff comprised of both Microsoft full-time employees and subprocessors/vendors.

As explained in Data encryption at rest section, your data is encrypted at rest by default when stored in Azure and you can control your own encryption keys in Azure Key Vault. Moreover, access to your data isn't needed to resolve most customer support requests. Microsoft engineers rely heavily on logs to provide customer support. As described in Insider data access section, Azure has controls in place to restrict access to your data for support and troubleshooting scenarios should that access be necessary. For example, Just-in-Time (JIT) access provisions restrict access to production systems to Microsoft engineers who are authorized to be in that role and were granted temporary access credentials. As part of the support workflow, Customer Lockbox puts you in charge of approving or denying access to your data by Microsoft engineers. When combined, these Azure technologies and processes (data encryption, JIT, and Customer Lockbox) provide appropriate risk mitigation to safeguard confidentiality and integrity of your data.

Government customers worldwide expect to be fully in control of protecting their data in the cloud. As described in the next section, Azure provides extensive options for data encryption through its entire lifecycle (at rest, in transit, and in use), including customer control of encryption keys.

Data encryption

Azure has extensive support to safeguard your data using data encryption. If you require extra security for your most sensitive customer content stored in Azure services, you can encrypt it using your own encryption keys that you control in Azure Key Vault. While you can't control the precise network path for data in transit, data encryption in transit helps protect data from interception. Azure supports the following data encryption models:

• Server-side encryption that uses service-managed keys, customer-managed keys (CMK) in Azure, or CMK in customer-controlled hardware.
• Client-side encryption that enables you to manage and store keys on-premises or in another secure location.

Data encryption provides isolation assurances that are tied directly to encryption key access. Since Azure uses strong ciphers for data encryption, only entities with access to encryption keys can have access to data. Revoking or deleting encryption keys renders the corresponding data inaccessible.

Encryption key management

Proper protection and management of encryption keys is essential for data security. Azure Key Vault is a cloud service for securely storing and managing secrets. The Key Vault service supports two resource types:

• Vault supports software-protected and hardware security module (HSM)-protected secrets, keys, and certificates. Vaults provide a multi-tenant, low-cost, easy to deploy, zone-resilient (where available), and highly available key management solution suitable for most common cloud application scenarios. The corresponding HSMs have FIPS 140 validation.
• Managed HSM supports only HSM-protected cryptographic keys. It provides a single-tenant, fully managed, highly available, zone-resilient (where available) HSM as a service to store and manage your cryptographic keys. It's most suitable for applications and usage scenarios that handle high value keys. It also helps you meet the most stringent security, compliance, and regulatory requirements. Managed HSM uses FIPS 140 Level 3 validated HSMs to protect your cryptographic keys.

Key Vault enables you to store your encryption keys in hardware security modules (HSMs) that are FIPS 140 validated. With Azure Key Vault, you can import or generate encryption keys in HSMs, ensuring that keys never leave the HSM protection boundary to support bring your own key (BYOK) scenarios. Keys generated inside the Azure Key Vault HSMs aren't exportable – there can be no clear-text version of the key outside the HSMs. This binding is enforced by the underlying HSM.

For more information, see Azure Key Vault.

Data encryption in transit

Azure provides many options for encrypting data in transit. Data encryption in transit isolates your network traffic from other traffic and helps protect data from interception. For more information, see Data encryption in transit.

Data encryption at rest

Azure provides extensive options for encrypting data at rest to help you safeguard your data and meet your compliance needs using both Microsoft-managed encryption keys and customer-managed encryption keys. This process relies on multiple encryption keys and services such as Azure Key Vault and Microsoft Entra ID to ensure secure key access and centralized key management. For more information about Azure Storage encryption and Azure Disk encryption, see Data encryption at rest.

Azure SQL Database provides transparent data encryption (TDE) at rest by default. TDE performs real-time encryption and decryption operations on the data and log files. Database Encryption Key (DEK) is a symmetric key stored in the database boot record for availability during recovery. It's secured via a certificate stored in the master database of the server or an asymmetric key called TDE Protector stored under your control in Azure Key Vault. Key Vault supports bring your own key (BYOK), which enables you to store the TDE Protector in Key Vault and control key management tasks including key permissions, rotation, deletion, enabling auditing/reporting on all TDE Protectors, and so on. The key can be generated by the Key Vault, imported, or transferred to the Key Vault from an on-premises HSM device. You can also use the Always Encrypted feature of Azure SQL Database, which is designed specifically to help protect sensitive data by allowing you to encrypt data inside your applications and never reveal the encryption keys to the database engine. In this manner, Always Encrypted provides separation between those users who own the data (and can view it) and those users who manage the data (but should have no access).

Data encryption in use

Microsoft enables you to protect your data throughout its entire lifecycle: at rest, in transit, and in use. Azure confidential computing and Homomorphic encryption are two techniques that safeguard your data while it's processed in the cloud.

Azure confidential computing

Azure confidential computing is a set of data security capabilities that offers encryption of data while in use. This approach means that data can be processed in the cloud with the assurance that it's always under your control, even when data is in use while in memory during computations. Azure confidential computing supports different virtual machines for IaaS workloads:

• Trusted launch VMs: Trusted launch is available across generation 2 VMs, bringing hardened security features – secure boot, virtual trusted platform module, and boot integrity monitoring – that protect against boot kits, rootkits, and kernel-level malware.

• Confidential VMs with AMD SEV-SNP technology: You can choose Azure VMs based on AMD EPYC 7003 series CPUs to lift and shift applications without requiring any code changes. These AMD EPYC CPUs use AMD Secure Encrypted Virtualization – Secure Nested Paging (SEV-SNP) technology to encrypt your entire virtual machine at runtime. The encryption keys used for VM encryption are generated and safeguarded by a dedicated secure processor on the EPYC CPU and can't be extracted by any external means. These Azure VMs are currently in Preview and available to select customers. For more information, see Azure and AMD announce landmark in confidential computing evolution.

• Confidential VMs with Intel SGX application enclaves: You can choose Azure VMs based on Intel Software Guard Extensions (Intel SGX) technology that supports confidentiality in a granular manner down to the application level. With this approach, when data is in the clear, which is needed for efficient data processing in memory, the data is protected inside a hardware-based trusted execution environment (TEE, also known as an enclave), as depicted in Figure 1. Intel SGX isolates a portion of physical memory to create an enclave where select code and data are protected from viewing or modification. TEE helps ensure that only the application designer has access to TEE data – access is denied to everyone else including Azure administrators. Moreover, TEE helps ensure that only authorized code is permitted to access data. If the code is altered or tampered with, the operations are denied, and the environment is disabled.

  

  Figure 1. Trusted execution environment protection

  Azure DCsv2, DCsv3, and DCdsv3 series virtual machines have the latest generation of Intel Xeon processors with Intel SGX technology. For more information, see Build with SGX enclaves. The protection offered by Intel SGX, when used appropriately by application developers, can prevent compromise due to attacks from privileged software and many hardware-based attacks. An application using Intel SGX needs to be refactored into trusted and untrusted components. The untrusted part of the application sets up the enclave, which then allows the trusted part to run inside the enclave. No other code, irrespective of the privilege level, has access to the code executing within the enclave or the data associated with enclave code. Design best practices call for the trusted partition to contain just the minimum amount of content required to protect customer’s secrets. For more information, see Application development on Intel SGX.

Technologies like Intel Software Guard Extensions (Intel SGX), or AMD Secure Encrypted Virtualization – Secure Nested Paging (SEV-SNP) are recent CPU improvements supporting confidential computing implementations. These technologies are designed as virtualization extensions and provide feature sets including memory encryption and integrity, CPU-state confidentiality and integrity, and attestation. Azure provides extra Confidential computing offerings that are generally available or available in preview:

• Microsoft Azure Attestation – A remote attestation service for validating the trustworthiness of multiple Trusted Execution Environments (TEEs) and verifying integrity of the binaries running inside the TEEs.
• Azure Confidential Ledger – A tamper-proof register for storing sensitive data for record keeping and auditing or for data transparency in multi-party scenarios. It offers Write-Once-Read-Many guarantees, which make data non-erasable and non-modifiable. The service is built on Microsoft Research's Confidential Consortium Framework.
• Enclave aware containers running on Azure Kubernetes Service (AKS) – Confidential computing nodes on AKS use Intel SGX to create isolated enclave environments in the nodes between each container application.
• Always Encrypted with secure enclaves in Azure SQL – The confidentiality of sensitive data is protected from malware and high-privileged unauthorized users by running SQL queries directly inside a TEE when the SQL statement contains any operations on encrypted data that require the use of the secure enclave where the database engine runs.
• Confidential computing at the edge – Azure IoT Edge supports confidential applications that run within secure enclaves on an Internet of Things (IoT) device. IoT devices are often exposed to tampering and forgery because they're physically accessible by bad actors. Confidential IoT Edge devices add trust and integrity at the edge by protecting the access to data captured by and stored inside the device itself before streaming it to the cloud.

Based on customer feedback, Microsoft has started to invest in higher-level scenarios for Azure confidential computing. You can review the scenario recommendations as a starting point for developing your own applications using confidential computing services and frameworks.

Homomorphic encryption

Homomorphic encryption refers to a special type of encryption technology that allows for computations to be performed on encrypted data, without requiring access to a key needed to decrypt the data. The results of the computation are encrypted and can be revealed only by the owner of the encryption key. In this manner, only the encrypted data are processed in the cloud and only you can reveal the results of the computation.

To help you adopt homomorphic encryption, Microsoft SEAL provides a set of encryption libraries that allow computations to be performed directly on encrypted data. This approach enables you to build end-to-end encrypted data storage and compute services where you never need to share your encryption keys with the cloud service. Microsoft SEAL aims to make homomorphic encryption easy to use and available to everyone. It provides a simple and convenient API and comes with several detailed examples demonstrating how the library can be used correctly and securely.

We also announced a multi-year collaboration with Intel and the Defense Advanced Research Projects Agency (DARPA) to lead the commercialization of fully homomorphic encryption (FHE). This technology will enable computation on always-encrypted data or cryptograms. With FHE, the data never needs to be decrypted, reducing the potential for cyber threats.

Data encryption in the cloud is an important risk mitigation requirement expected by government customers worldwide. As described in this section, Azure helps you protect your data through its entire lifecycle whether at rest, in transit, or even in use. Moreover, Azure offers comprehensive encryption key management to help you control your keys in the cloud, including key permissions, rotation, deletion, and so on. End-to-end data encryption using advanced ciphers is fundamental to ensuring confidentiality and integrity of your data in the cloud. However, many customers also expect assurances regarding any potential customer data access by Microsoft engineers for service maintenance, customer support, or other scenarios. These controls are described in the next section.

Insider data access

Insider threat is characterized as potential for providing back-door connections and cloud service provider (CSP) privileged administrator access to your systems and data. Microsoft provides strong customer commitments regarding who can access your data and on what terms. Access to your data by Microsoft operations and support personnel is denied by default. Access to your data isn't needed to operate Azure. Moreover, for most support scenarios involving customer-initiated troubleshooting tickets, access to your data isn't needed.

No default access rights and Just-in-Time (JIT) access provisions reduce greatly the risks associated with traditional on-premises administrator elevated access rights that typically persist throughout the duration of employment. Microsoft makes it considerably more difficult for malicious insiders to tamper with your applications and data. The same access control restrictions and processes are imposed on all Microsoft engineers, including both full-time employees and subprocessors/vendors.

For more information on how Microsoft restricts insider access to your data, see Restrictions on insider access.

Government requests for your data

Government requests for your data follow a strict procedure according to Microsoft practices for responding to government requests. Microsoft takes strong measures to help protect your data from inappropriate access or use by unauthorized persons. These measures include restricting access by Microsoft personnel and subcontractors and carefully defining requirements for responding to government requests for your data. Microsoft ensures that there are no back-door channels and no direct or unfettered government access to your data. Microsoft imposes special requirements for government and law enforcement requests for your data.

As stated in the Microsoft Products and Services Data Protection Addendum (DPA), Microsoft won't disclose your data to law enforcement unless required by law. If law enforcement contacts Microsoft with a demand for your data, Microsoft will attempt to redirect the law enforcement agency to request that data directly from you. If compelled to disclose your data to law enforcement, Microsoft will promptly notify you and provide a copy of the demand unless legally prohibited from doing so.

Government requests for your data must comply with applicable laws.

• A subpoena or its local equivalent is required to request non-content data.
• A warrant, court order, or its local equivalent is required for content data.

Every year, Microsoft rejects many law enforcement requests for your data. Challenges to government requests can take many forms. In many of these cases, Microsoft simply informs the requesting government that it's unable to disclose the requested information and explains the reason for rejecting the request. Where appropriate, Microsoft challenges requests in court.

Our Law Enforcement Request Report and US National Security Order Report are updated every six months and show that most of our customers are never impacted by government requests for data.

CLOUD Act provisions

The CLOUD Act is a United States law that was enacted in March 2018. For more information, see Microsoft’s blog post and the follow-up blog post that describes Microsoft’s call for principle-based international agreements governing law enforcement access to data. Key points of interest to government customers procuring Azure services are captured below.

• The CLOUD Act enables governments to negotiate new government-to-government agreements that will result in greater transparency and certainty for how information is disclosed to law enforcement agencies across international borders.
• The CLOUD Act isn't a mechanism for greater government surveillance; it's a mechanism toward ensuring that your data is ultimately protected by the laws of your home country/region while continuing to facilitate lawful access to evidence for legitimate criminal investigations. Law enforcement in the US still needs to obtain a warrant demonstrating probable cause of a crime from an independent court before seeking the contents of communications. The CLOUD Act requires similar protections for other countries/regions seeking bilateral agreements.
• While the CLOUD Act creates new rights under new international agreements, it also preserves the common law right of cloud service providers to go to court to challenge search warrants when there's a conflict of laws – even without these new treaties in place.
• Microsoft retains the legal right to object to a law enforcement order in the United States where the order clearly conflicts with the laws of the country/region where your data is hosted. Microsoft will continue to carefully evaluate every law enforcement request and exercise its rights to protect customers where appropriate.
• For legitimate enterprise customers, US law enforcement will, in most instances, now go directly to customers rather than to Microsoft for information requests.

Microsoft doesn't disclose extra data as a result of the CLOUD Act. This law doesn't practically change any of the legal and privacy protections that previously applied to law enforcement requests for data – and those protections continue to apply. Microsoft adheres to the same principles and customer commitments related to government demands for user data.

Most government customers have requirements in place for handling security incidents, including data breach notifications. Microsoft has a mature security and privacy incident management process in place that is described in the next section.

Breach notifications

Microsoft will notify you of any breach of your data (customer or personal) within 72 hours of incident declaration. You can monitor potential threats and respond to incidents on your own using Microsoft Defender for Cloud.

Microsoft is responsible for monitoring and remediating security and availability incidents affecting the Azure platform and notifying you of any security breaches involving your data. Azure has a mature security and privacy incident management process that is used for this purpose. You're responsible for monitoring your own resources provisioned in Azure, as described in the next section.

Shared responsibility

The NIST SP 800-145 standard defines the following cloud service models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). The shared responsibility model for cloud computing is depicted in Figure 2. With on-premises deployment in your own datacenter, you assume the responsibility for all layers in the stack. As workloads get migrated to the cloud, Microsoft assumes progressively more responsibility depending on the cloud service model. For example, with the IaaS model, Microsoft’s responsibility ends at the Hypervisor layer, and you're responsible for all layers above the virtualization layer, including maintaining the base operating system in guest Virtual Machines.

Figure 2. Shared responsibility model in cloud computing

In line with the shared responsibility model, Microsoft doesn't inspect, approve, or monitor your individual applications deployed on Azure. For example, Microsoft doesn't know what firewall ports need to be open for your application to function correctly, what the back-end database schema looks like, what constitutes normal network traffic for the application, and so on. Microsoft has extensive monitoring infrastructure in place for the cloud platform; however, you're responsible for provisioning and monitoring your own resources in Azure. You can deploy a range of Azure services to monitor and safeguard your applications and data, as described in the next section.

Essential Azure services for extra protection

Azure provides essential services that you can use to gain in-depth insight into your provisioned Azure resources and get alerted about suspicious activity, including outside attacks aimed at your applications and data. The Azure Security Benchmark provides security recommendations and implementation details to help you improve the security posture of your provisioned Azure resources.

For more information about essential Azure services for extra protection, see Customer monitoring of Azure resources.

Breach notification process

Security incident response, including breach notification, is a subset of Microsoft’s overall incident management plan for Azure. All Microsoft employees are trained to identify and escalate potential security incidents. A dedicated team of security engineers within the Microsoft Security Response Center (MSRC) is responsible for always managing the security incident response for Azure. Microsoft follows a five-step incident response process when managing both security and availability incidents for Azure services. The process includes the following stages:

1. Detect
2. Assess
3. Diagnose
4. Stabilize and recover
5. Close

The goal of this process is to restore normal service operations and security as quickly as possible after an issue is detected, and an investigation started. Moreover, Microsoft enables you to investigate, manage, and respond to security incidents in your Azure subscriptions. For more information, see Incident management implementation guidance: Azure and Office 365.

If during the investigation of a security or privacy event, Microsoft becomes aware that customer or personal data has been exposed or accessed by an unauthorized party, the security incident manager is required to trigger the incident notification subprocess in consultation with the Microsoft legal affairs division. This subprocess is designed to fulfill incident notification requirements stipulated in Azure customer contracts (see Security Incident Notification in the Microsoft Products and Services Data Protection Addendum). Customer notification and external reporting obligations (if any) are triggered by a security incident being declared. The customer notification subprocess begins in parallel with security incident investigation and mitigation phases to help minimize any impact resulting from the security incident.

Microsoft will notify you, Data Protection Authorities, and data subjects (each as applicable) of any breach of customer or personal data within 72 hours of incident declaration. The notification process upon a declared security or privacy incident will occur as expeditiously as possible while still considering the security risks of proceeding quickly. In practice, this approach means that most notifications will take place well before the 72-hr deadline to which Microsoft commits contractually. Notification of a security or privacy incident will be delivered to one or more of your administrators by any means Microsoft selects, including via email. You should provide security contact details for your Azure subscription – this information will be used by Microsoft to contact you if the MSRC discovers that your data has been exposed or accessed by an unlawful or unauthorized party. To ensure that notification can be delivered successfully, it's your responsibility to maintain correct administrative contact information for each applicable subscription.

Most Azure security and privacy investigations don't result in declared security incidents. Most external threats don't lead to breaches of your data because of extensive platform security measures that Microsoft has in place. Microsoft has deployed extensive monitoring and diagnostics infrastructure throughout Azure that relies on big-data analytics and machine learning to get insight into the platform health, including real-time threat intelligence. While Microsoft takes all platform attacks seriously, it would be impractical to notify you of potential attacks at the platform level.

Aside from controls implemented by Microsoft to safeguard customer data, government customers deployed on Azure derive considerable benefits from security research that Microsoft conducts to protect the cloud platform. Microsoft global threat intelligence is one of the largest in the industry, and it's derived from one of the most diverse sets of threat telemetry sources. It's both the volume and diversity of threat telemetry that makes Microsoft machine learning algorithms applied to that telemetry so powerful. All Azure customers benefit directly from these investments as described in the next section.

Threat detection and prevention

The Microsoft Graph Security API uses advanced analytics to synthesize massive amounts of threat intelligence and security signals obtained across Microsoft products, services, and partners to combat cyberthreats. Millions of unique threat indicators across the most diverse set of sources are generated every day by Microsoft and its partners and shared across Microsoft products and services (Figure 3). Across its portfolio of global services, each month Microsoft scans more than 400 billion email messages for phishing and malware, processes 450 billion authentications, executes more than 18 billion page scans, and scans more than 1.2 billion devices for threats. Importantly, this data always goes through strict privacy and compliance boundaries before being used for security analysis.

Figure 3. Microsoft global threat intelligence is one of the largest in the industry

The Microsoft Graph Security API provides an unparalleled view into the evolving threat landscape and enables rapid innovation to detect and respond to threats. Machine learning models and artificial intelligence reason over vast security signals to identify vulnerabilities and threats. The Microsoft Graph Security API provides a common gateway to share and act on security insights across the Microsoft platform and partner solutions. You benefit directly from the Microsoft Graph Security API as Microsoft makes the vast threat telemetry and advanced analytics available in Microsoft online services, including Microsoft Defender for Cloud. These services can help you address your own security requirements in the cloud.

Microsoft has implemented extensive protections for the Azure cloud platform and made available a wide range of Azure services to help you monitor and protect your provisioned cloud resources from attacks. Nonetheless, for certain types of workloads and data classifications, government customers expect to have full operational control over their environment and even operate in a fully disconnected mode. The Azure Stack portfolio of products enables you to provision private and hybrid cloud deployment models that can accommodate highly sensitive data, as described in the next section.

Private and hybrid cloud with Azure Stack

Azure Stack portfolio is an extension of Azure that enables you to build and run hybrid applications across on-premises, edge locations, and cloud. As shown in Figure 4, Azure Stack includes Azure Stack Hyperconverged Infrastructure (HCI), Azure Stack Hub (formerly Azure Stack), and Azure Stack Edge (formerly Azure Data Box Edge). The last two components (Azure Stack Hub and Azure Stack Edge) are discussed in this section. For more information, see Differences between global Azure, Azure Stack Hub, and Azure Stack HCI.

Figure 4. Azure Stack portfolio

Azure Stack Hub and Azure Stack Edge represent key enabling technologies that allow you to process highly sensitive data using a private or hybrid cloud and pursue digital transformation using Microsoft intelligent cloud and intelligent edge approach. For many government customers, enforcing data sovereignty, addressing custom compliance requirements, and applying maximum available protection to highly sensitive data are the primary driving factors behind these efforts.

Azure Stack Hub

Azure Stack Hub (formerly Azure Stack) is an integrated system of software and validated hardware that you can purchase from Microsoft hardware partners, deploy in your own data center, and then operate entirely on your own or with the help from a managed service provider. With Azure Stack Hub, you're always fully in control of access to your data. Azure Stack Hub can accommodate up to 16 physical servers per Azure Stack Hub scale unit. It represents an extension of Azure, enabling you to provision various IaaS and PaaS services and effectively bring multi-tenant cloud technology to on-premises and edge environments. You can run many types of VM instances, App Services, Containers (including Azure AI containers), Functions, Azure Monitor, Key Vault, Event Hubs, and other services while using the same development tools, APIs, and management processes you use in Azure. Azure Stack Hub isn't dependent on connectivity to Azure to run deployed applications and enable operations via local connectivity.

In addition to Azure Stack Hub, which is intended for on-premises deployment (for example, in a data center), a ruggedized and field-deployable version called Tactical Azure Stack Hub is also available to address tactical edge deployments for limited or no connectivity, fully mobile requirements, and harsh conditions requiring military specification solutions.

Azure Stack Hub can be operated disconnected from Azure or the Internet. You can run the next generation of AI-enabled hybrid applications where your data lives. For example, you can rely on Azure Stack Hub to bring a trained AI model to the edge and integrate it with your applications for low-latency intelligence, with no tool or process changes for local applications.

Azure and Azure Stack Hub can help you unlock new hybrid use cases for externally facing or internally deployed line-of-business application, including edge and disconnected scenarios, cloud applications intended to meet data sovereignty and compliance requirements, and cloud applications deployed on-premises in your data center. These use cases may include mobile scenarios or fixed deployments within highly secure data center facilities. Figure 5 shows Azure Stack Hub capabilities and key usage scenarios.

Figure 5. Azure Stack Hub capabilities

Azure Stack Hub brings the following value proposition for key scenarios shown in Figure 5:

• Edge and disconnected solutions: Address latency and connectivity requirements by processing data locally in Azure Stack Hub and then aggregating in Azure for further analytics, with common application logic across both (connected or disconnected). Aircraft, ship, or truck-delivered, Azure Stack Hub meets the tough demands of exploration, construction, agriculture, oil and gas, manufacturing, disaster response, government, and military efforts in the most extreme conditions and remote locations. For example, with Azure Stack Hub architecture for edge and disconnected solutions, you can bring the next generation of AI-enabled hybrid applications to the edge where the data lives and integrate it with existing applications for low-latency intelligence.
• Cloud applications to meet data sovereignty: Deploy a single application differently depending on the country/region. You can develop and deploy applications in Azure, with full flexibility to deploy on-premises with Azure Stack Hub based on the need to meet data sovereignty or custom compliance requirements. For example, with Azure Stack Hub architecture for data sovereignty, you can transmit data from an Azure VNet to Azure Stack Hub VNet over private connection and ultimately store data in a SQL Server database running in a VM on Azure Stack Hub. You can use Azure Stack Hub to accommodate even more restrictive requirements such as the need to deploy solutions in a disconnected environment managed by security-cleared, in-country/region personnel. These disconnected environments may not be permitted to connect to the Internet for any purpose because of the security classification they operate at.
• Cloud application model on-premises: Use Azure Stack Hub to update and extend legacy applications and make them cloud ready. With App Service on Azure Stack Hub, you can create a web front end to consume modern APIs with modern clients while taking advantage of consistent programming models and skills. For example, with Azure Stack Hub architecture for legacy system modernization, you can apply a consistent DevOps process, Azure Web Apps, containers, serverless computing, and microservices architectures to modernize legacy applications while integrating and preserving legacy data in mainframe and core line-of-business systems.

Azure Stack Hub requires Microsoft Entra ID or Active Directory Federation Services (ADFS), backed by Active Directory as an identity provider. You can use role-based access control (RBAC) to grant system access to authorized users, groups, and services by assigning them roles at a subscription, resource group, or individual resource level. Each role defines the access level a user, group, or service has over Azure Stack Hub resources.

Azure Stack Hub protects your data at the storage subsystem level using encryption at rest. By default, Azure Stack Hub's storage subsystem is encrypted using BitLocker with 128-bit AES encryption. BitLocker keys are persisted in an internal secret store. At deployment time, it's also possible to configure BitLocker to use 256-bit AES encryption. You can store and manage your secrets including cryptographic keys using Key Vault in Azure Stack Hub.

Azure Stack Edge

Azure Stack Edge (formerly Azure Data Box Edge) is an AI-enabled edge computing device with network data transfer capabilities. The latest generation of these devices relies on a built-in Graphical Processing Unit (GPU) to enable accelerated AI inferencing. Azure Stack Edge uses GPU hardware natively integrated into the appliance to run machine learning algorithms at the edge efficiently. The size and portability allow you to run Azure Stack Edge as close to your users, apps, and data as needed. Figure 6 shows Azure Stack Edge capabilities and key use cases.

Figure 6. Azure Stack Edge capabilities

Azure Stack Edge brings the following value proposition for key use cases shown in Figure 6:

• Inference with Azure Machine Learning: Inference is a part of deep learning that takes place after model training, such as the prediction stage resulting from applying learned capability to new data. For example, it’s the part that recognizes a vehicle in a target image after the model has been trained by processing many tagged vehicle images, often augmented by computer synthesized images (also known as synthetics). With Azure Stack Edge, you can run Machine Learning (ML) models to get results quickly and act on them before the data is sent to the cloud. The necessary subset of data (if there are bandwidth constraints) or the full data set is transferred to the cloud to continue to retrain and improve customer’s ML models.
• Preprocess data: Analyze data from on-premises or IoT devices to quickly obtain results while staying close to where data is generated. Azure Stack Edge transfers the full data set (or just the necessary subset of data when bandwidth is an issue) to the cloud to perform more advanced processing or deeper analytics. Preprocessing can be used to aggregate data, modify data (for example, remove personally identifiable information or other sensitive data), transfer data needed for deeper analytics in the cloud, and analyze and react to IoT events.
• Transfer data over network to Azure: Use Azure Stack Edge to transfer data to Azure to enable further compute and analytics or for archival purposes.

Being able to gather, discern, and distribute mission data is essential for making critical decisions. Tools that help process and transfer data directly at the edge make this capability possible. For example, Azure Stack Edge, with its light footprint and built-in hardware acceleration for ML inferencing, is useful to further the intelligence of forward-operating units or similar mission needs with AI solutions designed for the tactical edge. Data transfer from the field, which is traditionally complex and slow, is made seamless with the Azure Data Box family of products.

These products unite the best of edge and cloud computing to unlock never-before-possible capabilities like synthetic mapping and ML model inferencing. From submarines to aircraft to remote bases, Azure Stack Hub and Azure Stack Edge allow you to harness the power of cloud at the edge.

Using Azure in combination with Azure Stack Hub and Azure Stack Edge, you can process confidential and sensitive data in a secure isolated infrastructure within the Azure public multi-tenant cloud or highly sensitive data at the edge under your full operational control. The next section describes a conceptual architecture for classified workloads.

Conceptual architecture

Figure 7 shows a conceptual architecture using products and services that support various data classifications. Azure public multi-tenant cloud is the underlying cloud platform that makes this architecture possible. You can augment Azure with on-premises and edge products such as Azure Stack Hub and Azure Stack Edge to accommodate critical workloads over which you seek increased or exclusive operational control. For example, Azure Stack Hub is intended for on-premises deployment in your data center where you have full control over service connectivity. Moreover, Azure Stack Hub can be deployed to address tactical edge deployments for limited or no connectivity, including fully mobile scenarios.

Figure 7. Conceptual architecture for classified workloads

For classified workloads, you can provision key enabling Azure services to secure target workloads while mitigating identified risks. Azure, in combination with Azure Stack Hub and Azure Stack Edge, can accommodate private and hybrid cloud deployment models, making them suitable for many government workloads involving both unclassified and classified data. The following data classification taxonomy is used in this article:

• Confidential
• Secret
• Top secret

Similar data classification schemes exist in many countries/regions.

For top secret data, you can deploy Azure Stack Hub, which can operate disconnected from Azure and the Internet. Tactical Azure Stack Hub is also available to address tactical edge deployments for limited or no connectivity, fully mobile requirements, and harsh conditions requiring military specification solutions. Figure 8 depicts key enabling services that you can provision to accommodate various workloads on Azure.

Figure 8. Azure support for various data classifications

Confidential data

Listed below are key enabling technologies and services that you may find helpful when deploying confidential data and workloads on Azure:

• All recommended technologies used for Unclassified data, especially services such as Virtual Network (VNet), Microsoft Defender for Cloud, and Azure Monitor.
• Public IP addresses are disabled allowing only traffic through private connections, including ExpressRoute and Virtual Private Network (VPN) gateway.
• Data encryption is recommended with customer-managed keys (CMK) in Azure Key Vault backed by multi-tenant hardware security modules (HSMs) that have FIPS 140 validation.
• Only services that support VNet integration options are enabled. Azure VNet enables you to place Azure resources in a non-internet routable network, which can then be connected to your on-premises network using VPN technologies. VNet integration gives web apps access to resources in the virtual network.
• You can use Azure Private Link to access Azure PaaS services over a private endpoint in your VNet, ensuring that traffic between your VNet and the service travels across the Microsoft global backbone network, which eliminates the need to expose the service to the public Internet.
• Customer Lockbox for Azure enables you to approve/deny elevated access requests for your data in support scenarios. It’s an extension of the Just-in-Time (JIT) workflow that comes with full audit logging enabled.

Using Azure public multi-tenant cloud capabilities, you can achieve the level of isolation and security required to store confidential data. You should use Microsoft Defender for Cloud and Azure Monitor to gain visibility into your Azure environments including the security posture of your subscriptions.

Secret data

Listed below are key enabling technologies and services that you may find helpful when deploying secret data and workloads on Azure:

• All recommended technologies used for confidential data.
• Use Azure Key Vault Managed HSM, which provides a fully managed, highly available, single-tenant HSM as a service that uses FIPS 140 Level 3 validated HSMs. Each Managed HSM instance is bound to a separate security domain controlled by you and isolated cryptographically from instances belonging to other customers.
• Azure Dedicated Host provides physical servers that can host one or more Azure VMs and are dedicated to one Azure subscription. You can provision dedicated hosts within a region, availability zone, and fault domain. You can then place VMs directly into provisioned hosts using whatever configuration best meets your needs. Dedicated Host provides hardware isolation at the physical server level, enabling you to place your Azure VMs on an isolated and dedicated physical server that runs only your organization’s workloads to meet corporate compliance requirements.
• Accelerated FPGA networking based on Azure SmartNICs enables you to offload host networking to dedicated hardware, enabling tunneling for VNets, security, and load balancing. Offloading network traffic to a dedicated chip guards against side-channel attacks on the main CPU.
• Azure confidential computing offers encryption of data while in use, ensuring that data is always under your control. Data is protected inside a hardware-based trusted execution environment (TEE, also known as enclave) and there's no way to view data or operations from outside the enclave.
• Just-in-time (JIT) virtual machine (VM) access can be used to lock down inbound traffic to Azure VMs by creating network security group (NSG) rules. You select ports on the VM to which inbound traffic will be locked down and when a user requests access to a VM, Microsoft Defender for Cloud checks that the user has proper role-based access control (RBAC) permissions.

To accommodate secret data in the Azure public multi-tenant cloud, you can deploy extra technologies and services on top of those technologies used for confidential data and limit provisioned services to those services that provide sufficient isolation. These services offer various isolation options at run time. They also support data encryption at rest using customer-managed keys in single-tenant HSMs controlled by you and isolated cryptographically from HSM instances belonging to other customers.

Top secret data

Listed below are key enabling products that you may find helpful when deploying top secret data and workloads on Azure:

• All recommended technologies used for secret data.
• Azure Stack Hub (formerly Azure Stack) enables you to run workloads using the same architecture and APIs as in Azure while having a physically isolated network for your highest classification data.
• Azure Stack Edge (formerly Azure Data Box Edge) allows the storage and processing of highest classification data but also enables you to upload resulting information or models directly to Azure. This approach creates a path for information sharing between domains that makes it easier and more secure.
• In addition to Azure Stack Hub, which is intended for on-premises deployment (for example, in a data center), a ruggedized and field-deployable version called Tactical Azure Stack Hub is also available to address tactical edge deployments for limited or no connectivity, fully mobile requirements, and harsh conditions requiring military specification solutions.
• User-provided hardware security modules (HSMs) allow you to store your encryption keys in HSMs deployed on-premises and controlled solely by you.

Accommodating top secret data will likely require a disconnected environment, which is what Azure Stack Hub provides. Azure Stack Hub can be operated disconnected from Azure or the Internet. Even though “air-gapped” networks don't necessarily increase security, many governments may be reluctant to store data with this classification in an Internet connected environment.

Azure offers an unmatched variety of public, private, and hybrid cloud deployment models to address your concerns regarding the safeguarding of your data. The following section covers select use cases that might be of interest to worldwide government customers.

Select workloads and use cases

This section provides an overview of select use cases that showcase Azure capabilities for workloads that might be of interest to worldwide governments. In terms of capabilities, Azure is presented via a combination of public multi-tenant cloud and on-premises + edge capabilities provided by Azure Stack Hub and Azure Stack Edge.

Processing highly sensitive or regulated data on Azure Stack Hub

Microsoft provides Azure Stack Hub as an on-premises, cloud-consistent experience for customers who don't have the ability to connect directly to the Internet, or where certain workload types are required to be hosted in-country/region due to law, compliance, or sentiment. Azure Stack Hub offers IaaS and PaaS services and shares the same APIs as the global Azure cloud. Azure Stack Hub is available in scale units of 4, 8, and 16 servers in a single-server rack, and 4 servers in a military-specification, ruggedized set of transit cases, or multiple racks in a modular data center configuration.

Azure Stack Hub is a solution if you operate in scenarios where:

• For compliance reasons, you can't connect your network to the public Internet.
• For geo-political or security reasons, Microsoft can't offer connectivity to other Microsoft clouds.
• For geo-political or security reasons, the host organization may require cloud management by non-Microsoft entities, or in-country/region by security-cleared personnel.
• Microsoft doesn't have an in-country/region cloud presence and therefore can't meet data sovereignty requirements.
• Cloud management would pose significant risk to the physical well-being of Microsoft resources operating the environment.

For most of these scenarios, Microsoft and its partners offer a customer-managed, Azure Stack Hub-based private cloud appliance on field-deployable hardware from major vendors such as Avanade, Cisco, Dell EMC, Hewlett Packard Enterprise, and Lenovo. Azure Stack Hub is manufactured, configured, and deployed by the hardware vendor, and can be ruggedized and security-hardened to meet a broad range of environmental and compliance standards, including the ability to withstand transport by aircraft, ship, or truck, and deployment into colocation, mobile, or modular data centers. Azure Stack Hub can be used in exploration, construction, agriculture, oil and gas, manufacturing, disaster response, government, and military efforts in hospitable or the most extreme conditions and remote locations. Azure Stack Hub allows you the full autonomy to monitor, manage, and provision your own private cloud resources while meeting your connectivity, compliance, and ruggedization requirements.

Machine learning model training

Artificial intelligence (AI) holds tremendous potential for governments. Machine learning (ML) is a data science technique that allows computers to learn to use existing data, without being explicitly programmed, to forecast future behaviors, outcomes, and trends. Moreover, ML technologies can discover patterns, anomalies, and predictions that can help governments in their missions. As technical barriers continue to fall, decision-makers face the opportunity to develop and explore transformative AI applications. There are five main vectors that can make it easier, faster, and cheaper to adopt ML:

• Unsupervised learning
• Reducing need for training data
• Accelerated learning
• Transparency of outcome
• Deploying closer to where data lives

In the following sections, we expand on areas that can help you with some of the above vectors.

IoT analytics

In recent years, we have been witnessing massive proliferation of Internet of Things (IoT) devices and sensors. In almost all cases, these sensors gather signals and data from the environments and conditions they’re designed for. The spectrum of capabilities for IoT sensors expands from measuring the level of moisture in soil all the way to gathering intelligence at 5,000-meters altitude. The high number of use cases imposes the necessity of applying data-analysis tools and procedures to realize value from the huge volumes of gathered data by IoT devices.

Governments are increasingly employing IoT devices for their missions, which could include maintenance predictions, borders monitoring, weather stations, smart meters, and field operations. In many cases, the data is often analyzed and inferred from where it’s gathered. The main challenges of IoT analytics are: (1) large amount of data from independent sources, (2) analytics at the edge and often in disconnected scenarios, and (3) data and analysis aggregation.

With innovative solutions such as IoT Hub and Azure Stack Edge, Azure services are well positioned to help you with these challenges.

Precision Agriculture with Farm Beats

Agriculture plays a vital role in most economies worldwide. In the US, over 70% of the rural households depend on agriculture as it contributes about 17% to the total GDP and provides employment to over 60% of the population. In project Farm Beats, we gather numerous data from farms that we couldn’t get before, and then by applying AI and ML algorithms we're able to turn this data into actionable insights for farmers. We call this technique data-driven farming. What we mean by data-driven farming is the ability to map every farm and overlay it with data. For example, what is the soil moisture level 15 cm below surface, what is the soil temperature 15 cm below surface, and so on. These maps can then enable techniques, such as Precision Agriculture, which has been shown to improve yield, reduce costs, and benefit the environment. Despite the fact the Precision Agriculture as a technique was proposed more than 30 years ago, it hasn’t taken off. The biggest reason is the inability to capture numerous data from farms to accurately represent the conditions in the farm. Our goal as part of the Farm Beats project is to be able to accurately construct precision maps at a fraction of the cost.

Unleashing the power of analytics with synthetic data

Synthetic data is data that is artificially created rather than being generated by actual events. It's often created with the help of computer algorithms and it's used for a wide range of activities, including usage as test data for new products and tools, as well as for ML models validation and improvements. Synthetic data can meet specific needs or conditions that aren't available in existing real data. For governments, the nature of synthetic data removes many barriers and helps data scientists with privacy concerns, accelerated learning, and data volume reduction needed for the same outcome. The main benefits of synthetic data are:

• Overcoming restrictions: Real data may have usage constraints due to privacy rules or other regulations. Synthetic data can replicate all important statistical properties of real data without exposing real data.
• Scarcity: Providing data where real data doesn't exist for a given event.
• Precision: Synthetic data is perfectly labeled.
• Quality: The quality of synthetic data can be precisely measured to fit the mission conditions.

Synthetic data can exist in several forms, including text, audio, video, and hybrid.

Knowledge mining

The exponential growth of unstructured data gathering in recent years has created many analytical problems for government agencies. This problem intensifies when data sets come from diverse sources such as text, audio, video, imaging, and so on. Knowledge mining is the process of discovering useful knowledge from a collection of diverse data sources. This widely used data mining technique is a process that includes data preparation and selection, data cleansing, incorporation of prior knowledge on data sets, and interpretation of accurate solutions from the observed results. This process has proven to be useful for large volumes of data in different government agencies.

For instance, captured data from the field often includes documents, pamphlets, letters, spreadsheets, propaganda, videos, and audio files across many disparate structured and unstructured formats. Buried within the data are actionable insights that can enhance effective and timely response to crisis and drive decisions. The objective of knowledge mining is to enable decisions that are better, faster, and more humane by implementing proven commercial algorithm-based technologies.

Scenarios for confidential computing

Security is a key driver accelerating the adoption of cloud computing, but it’s also a major concern when customers are moving sensitive IP and data to the cloud.

Microsoft Azure provides broad capabilities to secure data at rest and in transit, but sometimes the requirement is also to protect data from threats as it’s being processed. Azure confidential computing supports two different confidential VMs for data encryption while in use:

• VMs based on AMD EPYC 7003 series CPUs for lift and shift scenarios without requiring any application code changes. These AMD EPYC CPUs use AMD Secure Encrypted Virtualization – Secure Nested Paging (SEV-SNP) technology to encrypt your entire virtual machine at runtime. The encryption keys used for VM encryption are generated and safeguarded by a dedicated secure processor on the EPYC CPU and can't be extracted by any external means.
• VMs that provide a hardware-based trusted execution environment (TEE, also known as enclave) based on Intel Software Guard Extensions (Intel SGX) technology. The hardware provides a protected container by securing a portion of the processor and memory. Only authorized code is permitted to run and to access data, so code and data are protected against viewing and modification from outside of TEE.

Azure confidential computing can directly address scenarios involving data protection while in use. For example, consider the scenario where data coming from a public or unclassified source needs to be matched with data from a highly sensitive source. Azure confidential computing can enable that matching to occur in the public cloud while protecting the highly sensitive data from disclosure. This circumstance is common in highly sensitive national security and law enforcement scenarios.

A second scenario involves data coming from multiple sources that needs to be analyzed together, even though none of the sources have the authority to see the data. Each individual provider encrypts the data they provide and only within the TEE is that data decrypted. As such, no external party and even none of the providers can see the combined data set. This capability is valuable for secondary use of healthcare data.

If you're deploying the types of workloads discussed in this section, you may need assurances from Microsoft that the underlying cloud platform security controls for which Microsoft is responsible are operating effectively. To address the needs of customers across regulated markets worldwide, Azure maintains a comprehensive compliance portfolio based on formal third-party certifications and other types of assurances to help you meet your own compliance obligations.

Compliance and certifications

Azure has the broadest compliance coverage in the industry, including key independent certifications and attestations such as ISO 27001, ISO 27017, ISO 27018, ISO 22301, ISO 9001, ISO 20000-1, SOC 1/2/3, PCI DSS Level 1, PCI 3DS, HITRUST, CSA STAR Certification, CSA STAR Attestation, US FedRAMP High, Australia IRAP, Germany C5, Japan ISMAP, Korea K-ISMS, Singapore MTCS Level 3, Spain ENS High, UK G-Cloud and Cyber Essentials Plus, and many more. Azure compliance portfolio includes more than 100 compliance offerings spanning globally applicable certifications, US Government-specific programs, industry assurances, and country/region-specific offerings. You can use these offerings when addressing your own compliance obligations across regulated industries and markets worldwide.

When deploying applications that are subject to regulatory compliance obligations on Azure, customers often seek assurances that all cloud services comprising the solution are included in the cloud service provider’s audit scope. Azure offers industry-leading depth of compliance coverage judged by the number of cloud services in audit scope for each Azure certification. You can build and deploy realistic applications and benefit from extensive compliance coverage provided by Azure independent third-party audits.

Azure Stack Hub also provides compliance documentation to help you integrate Azure Stack Hub into solutions that address regulated workloads. You can download the following Azure Stack Hub compliance documents:

• PCI DSS assessment report produced by a third-party Qualified Security Assessor (QSA).
• Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) assessment report, including Azure Stack Hub control mapping to CCM domains and controls.
• FedRAMP High System Security Plan (SSP) precompiled template to demonstrate how Azure Stack Hub addresses applicable controls, Customer Responsibility Matrix for the FedRAMP High baseline, and FedRAMP assessment report produced by an accredited third-party assessment organization (3PAO).

Azure Policy regulatory compliance built-in initiatives map to compliance domains and controls in key standards, including:

• Australian Government ISM PROTECTED
• Canada Federal PBMM
• ISO/IEC 27001
• US Government FedRAMP High
• And others

For more regulatory compliance built-in initiatives, see Azure Policy samples.

Regulatory compliance in Azure Policy provides built-in initiative definitions to view a list of the controls and compliance domains based on responsibility – customer, Microsoft, or shared. For Microsoft-responsible controls, we provide extra audit result details based on third-party attestations and our control implementation details to achieve that compliance. Each control is associated with one or more Azure Policy definitions. These policies may help you assess compliance with the control; however, compliance in Azure Policy is only a partial view of your overall compliance status. Azure Policy helps to enforce organizational standards and assess compliance at scale. Through its compliance dashboard, it provides an aggregated view to evaluate the overall state of the environment, with the ability to drill down to more granular status.

Azure compliance and certification resources are intended to help you address your own compliance obligations with various standards and regulations. You may have an established cloud adoption mandate in your country/region and the corresponding regulation to facilitate cloud onboarding. Or you may still operate traditional on-premises datacenters and are in the process of formulating your cloud adoption strategy. Azure’s extensive compliance portfolio can help you irrespective of your cloud adoption maturity level.

Frequently asked questions

This section addresses common customer questions related to Azure public, private, and hybrid cloud deployment models.

Data residency and data sovereignty

• Data location: How does Microsoft keep data within a specific country/region’s boundaries? In what cases does data leave? What data attributes leave? Answer: Microsoft provides strong customer commitments regarding cloud services data residency and transfer policies:
  • Data storage for regional services: Most Azure services are deployed regionally and enable you to specify the region into which the service will be deployed, for example, Europe. Microsoft won't store your data outside your specified Geography except for a few regional services and Preview services as described on the Azure data location page. This commitment helps ensure that your data stored in a given region will remain in the corresponding Geography and won't be moved to another Geography for most regional services, including Storage, SQL Database, Virtual Machines, and many more.
  • Data storage for non-regional services: Certain Azure services don't enable you to specify the region where the services will be deployed as described on the data location page. For a complete list of non-regional services, see Products available by region.
• Air-gapped (sovereign) cloud deployment: Why doesn’t Microsoft deploy an air-gapped, sovereign, physically isolated cloud instance in every country/region? Answer: Microsoft is actively pursuing air-gapped cloud deployments where a business case can be made with governments across the world. However, physical isolation or “air gapping”, as a strategy, is diametrically opposed to the strategy of hyperscale cloud. The value proposition of the cloud, rapid feature growth, resiliency, and cost-effective operation, are diminished when the cloud is fragmented and physically isolated. These strategic challenges compound with each extra air-gapped cloud or fragmentation within an air-gapped cloud. Whereas an air-gapped cloud might prove to be the right solution for certain customers, it isn't the only available option.
• Air-gapped (sovereign) cloud customer options: How can Microsoft support governments who need to operate cloud services completely in-country/region by local security-cleared personnel? What options does Microsoft have for cloud services operated entirely on-premises within customer owned datacenter where government employees exercise sole operational and data access control? Answer: You can use Azure Stack Hub to deploy a private cloud on-premises managed by your own security-cleared, in-country/region personnel. You can run many types of VM instances, App Services, Containers (including Azure AI containers), Functions, Azure Monitor, Key Vault, Event Hubs, and other services while using the same development tools, APIs, and management processes that you use in Azure. With Azure Stack Hub, you have sole control of your data, including storage, processing, transmission, and remote access.
• Local jurisdiction: Is Microsoft subject to local country/region jurisdiction based on the availability of Azure public cloud service? Answer: Yes, Microsoft must comply with all applicable local laws; however, government requests for customer data must also comply with applicable laws. A subpoena or its local equivalent is required to request non-content data. A warrant, court order, or its local equivalent is required for content data. Government requests for customer data follow a strict procedure according to Microsoft practices for responding to government requests. Every year, Microsoft rejects many law enforcement requests for customer data. Challenges to government requests can take many forms. In many of these cases, Microsoft simply informs the requesting government that it's unable to disclose the requested information and explains the reason for rejecting the request. Where appropriate, Microsoft challenges requests in court. Our Law Enforcement Request Report and US National Security Order Report are updated every six months and show that most of our customers are never impacted by government requests for data. For example, in the second half of 2019, Microsoft received 39 requests from law enforcement for accounts associated with enterprise cloud customers. Of those requests, only one warrant resulted in disclosure of customer content related to a non-US enterprise customer whose data was stored outside the United States.
• Autarky: Can Microsoft cloud operations be separated from the rest of Microsoft cloud and connected solely to local government network? Are operations possible without external connections to a third party? Answer: Yes, depending on the cloud deployment model.
  • Public Cloud: Azure regional datacenters can be connected to your local government network through dedicated private connections such as ExpressRoute. Independent operation without any connectivity to a third party such as Microsoft isn't possible in the public cloud.
  • Private Cloud: With Azure Stack Hub, you have full control over network connectivity and can operate Azure Stack Hub in disconnected mode.
• Data flow restrictions: What provisions exist for approval and documentation of all data exchange between customer and Microsoft for local, in-country/region deployed cloud services? Answer: Options vary based on the cloud deployment model.
  • Private cloud: For private cloud deployment using Azure Stack Hub, you can control which data is exchanged with third parties. Azure Stack Hub telemetry can be turned off based on your preference and Azure Stack Hub can be operated disconnected. Moreover, Azure Stack Hub offers the capacity-based billing model in which no billing or consumption data leaves your on-premises infrastructure.
  • Public cloud: In Azure public cloud, you can use Network Watcher to monitor network traffic associated with your workloads. For public cloud workloads, all billing data is generated through telemetry used exclusively for billing purposes and sent to Microsoft billing systems. You can download and view your billing and usage data; however, you can't prevent this information from being sent to Microsoft.
• Patching and maintenance for private cloud: How can Microsoft support patching and other maintenance for Azure Stack Hub private cloud deployment? Answer: Microsoft has a regular cadence in place for releasing update packages for Azure Stack Hub. You're the sole operator of Azure Stack Hub and you can download and install these update packages. An update alert for Microsoft software updates and hotfixes will appear in the Update blade for Azure Stack Hub instances that are connected to the Internet. If your instance isn’t connected and you would like to be notified about each update release, subscribe to the RSS or ATOM feed, as explained in our online documentation.

Safeguarding of customer data

• Microsoft network security: What network controls and security does Microsoft use? Can my requirements be considered? Answer: For insight into Azure infrastructure protection, you should review Azure network architecture, Azure production network, and Azure infrastructure monitoring. If you're deploying Azure applications, you should review Azure network security overview and network security best practices. To provide feedback or requirements, contact your Microsoft account representative.
• Customer separation: How does Microsoft logically or physically separate customers within its cloud environment? Is there an option for my organization to ensure complete physical separation? Answer: Azure uses logical isolation to separate your applications and data from other customers. This approach provides the scale and economic benefits of multi-tenant cloud services while rigorously enforcing controls designed to keep your data and applications off limits to other customers. There's also an option to enforce physical compute isolation via Azure Dedicated Host, which provides physical servers that can host one or more Azure VMs and are dedicated to one Azure subscription. You can provision dedicated hosts within a region, availability zone, and fault domain. You can then place VMs directly into provisioned hosts using whatever configuration best meets your needs. Dedicated Host provides hardware isolation at the physical server level, enabling you to place your Azure VMs on an isolated and dedicated physical server that runs only your organization’s workloads to meet corporate compliance requirements.
• Data encryption at rest and in transit: Does Microsoft enforce data encryption by default? Does Microsoft support customer-managed encryption keys? Answer: Yes, many Azure services, including Azure Storage and Azure SQL Database, encrypt data by default and support customer-managed keys. Azure Storage encryption for data at rest ensures that data is automatically encrypted before persisting it to Azure Storage and decrypted before retrieval. You can use your own encryption keys for Azure Storage encryption at rest and manage your keys in Azure Key Vault. Storage encryption is enabled by default for all new and existing storage accounts and it can't be disabled. When provisioning storage accounts, you can enforce “secure transfer required” option, which allows access only from secure connections. This option is enabled by default when creating a storage account in the Azure portal. Azure SQL Database enforces data encryption in transit by default and provides transparent data encryption (TDE) at rest by default allowing you to use Azure Key Vault and bring your own key (BYOK) functionality to control key management tasks including key permissions, rotation, deletion, and so on.
• Data encryption during processing: Can Microsoft protect my data while it's being processed in memory? Answer: Yes, Azure confidential computing supports two different technologies for data encryption while in use. First, you can use VMs based on Intel Xeon processors with Intel Software Guard Extensions (Intel SGX) technology. With this approach, data is protected inside a hardware-based trusted execution environment (TEE, also known as enclave), which is created by securing a portion of the processor and memory. Only authorized code is permitted to run and to access data, so application code and data are protected against viewing and modification from outside of TEE. Second, you can use VMs based on AMD EPYC 7003 series CPUs for lift and shift scenarios without requiring any application code changes. These AMD EPYC CPUs make it possible to encrypt your entire virtual machine at runtime. The encryption keys used for VM encryption are generated and safeguarded by a dedicated secure processor on the EPYC CPU and can't be extracted by any external means.
• FIPS 140 validation: Does Microsoft offer FIPS 140 Level 3 validated hardware security modules (HSMs) in Azure? If so, can I store AES-256 symmetric encryption keys in these HSMs? Answer: Azure Key Vault Managed HSM provides a fully managed, highly available, single-tenant HSM as a service that uses FIPS 140 Level 3 validated HSMs. Each Managed HSM instance is bound to a separate security domain controlled by you and isolated cryptographically from instances belonging to other customers. With Managed HSMs, support is available for AES 128-bit and 256-bit symmetric keys.
• Customer provided cryptography: Can I use my own cryptography or encryption hardware? Answer: Yes, you can use your own HSMs deployed on-premises with your own crypto algorithms. However, if you expect to use customer-managed keys for services integrated with Azure Key Vault (for example, Azure Storage, SQL Database, Disk encryption, and others), then you must use hardware security modules (HSMs) and cryptography supported by Azure Key Vault.
• Access to customer data by Microsoft personnel: How does Microsoft restrict access to my data by Microsoft engineers? Answer: Microsoft engineers don't have default access to your data in the cloud. Instead, they can be granted access, under management oversight, only when necessary using a restricted access workflow. Most customer support requests can be resolved without accessing your data as Microsoft engineers rely heavily on logs for troubleshooting and support. If a Microsoft engineer requires elevated access to your data as part of the support workflow, you can use Customer Lockbox for Azure to control how a Microsoft engineer accesses your data. Customer Lockbox for Azure puts you in charge of that decision by enabling you to approve/deny such elevated access requests. For more information on how Microsoft restricts insider access to your data, see Restrictions on insider access.

Operations

• Code review: What can Microsoft do to prevent malicious code from being inserted into services that my organization uses? Can I review Microsoft code deployments? Answer: Microsoft has invested heavily in security assurance processes and practices to correctly develop logically isolated services and systems. For more information, see Security assurance processes and practices. For more information about Azure Hypervisor isolation, see Defense-in-depth exploit mitigations. Microsoft has full control over all source code that comprises Azure services. For example, the procedure for patching guest VMs differs greatly from traditional on-premises patching where patch verification is necessary following installation. In Azure, patches aren't applied to guest VMs; instead, the VM is simply restarted and when the VM boots, it's guaranteed to boot from a known good image that Microsoft controls. There's no way to insert malicious code into the image or interfere with the boot process. PaaS VMs offer more advanced protection against persistent malware infections than traditional physical server solutions, which if compromised by an attacker can be difficult to clean, even after the vulnerability is corrected. With PaaS VMs, reimaging is a routine part of operations, and it can help clean out intrusions that haven't even been detected. This approach makes it more difficult for a compromise to persist. You can't review Azure source code; however, online access to view source code is available for key products through the Microsoft Government Security Program (GSP).
• DevOps personnel (cleared nationals): What controls or clearance levels does Microsoft have for the personnel that have DevOps access to cloud environments or physical access to data centers? Answer: Microsoft conducts background screening on operations personnel with access to production systems and physical data center infrastructure. Microsoft cloud background check includes verification of education and employment history upon hire, and extra checks conducted every two years thereafter (where permissible by law), including criminal history check, OFAC list, BIS denied persons list, and DDTC debarred parties list.
• Data center site options: Is Microsoft willing to deploy a data center to a specific physical location to meet more advanced security requirements? Answer: You should inquire with your Microsoft account team regarding options for data center locations.
• Service availability guarantee: How can my organization ensure that Microsoft (or particular government or other entity) can’t turn off our cloud services? Answer: You should review the Microsoft Product Terms (formerly Online Services Terms) and the Microsoft Products and Services Data Protection Addendum (DPA) for contractual commitments Microsoft makes regarding service availability and use of online services.
• Non-traditional cloud service needs: What options does Microsoft provide for periodically internet free/disconnected environments? Answer: In addition to Azure Stack Hub, which is intended for on-premises deployment and disconnected scenarios, a ruggedized and field-deployable version called Tactical Azure Stack Hub is also available to address tactical edge deployments for limited or no connectivity, fully mobile requirements, and harsh conditions requiring military specification solutions.

Transparency and audit

• Audit documentation: Does Microsoft make all audit documentation readily available to customers to download and examine? Answer: Yes, Microsoft makes independent third-party audit reports and other related documentation available for download under a non-disclosure agreement from the Azure portal. You'll need an existing Azure subscription or free trial subscription to access the Microsoft Defender for Cloud audit reports blade. Extra compliance documentation is available from the Service Trust Portal (STP) Audit Reports section. You must log in to access audit reports on the STP. For more information, see Get started with the Microsoft Service Trust Portal.
• Process auditability: Does Microsoft make its processes, data flow, and documentation available to customers or regulators for audit? Answer: Microsoft offers a Regulator Right to Examine, which is a program Microsoft implemented to provide regulators with direct right to examine Azure, including the ability to conduct an on-site examination, to meet with Microsoft personnel and Microsoft external auditors, and to access any related information, records, reports, and documents.
• Service documentation: Can Microsoft provide in-depth documentation covering service architecture, software and hardware components, and data protocols? Answer: Yes, Microsoft provides extensive and in-depth Azure online documentation covering all these topics. For example, you can review documentation on Azure products, global infrastructure, and API reference.

Next steps

Learn more about:

• Azure Security
• Azure Compliance
• Azure compliance offerings
• Azure guidance for secure isolation
• Azure for government - worldwide government
• Enabling data residency and data protection in Microsoft Azure regions
• Azure Policy regulatory compliance samples