Managing export controls in Azure and Azure Government

Stevan Vidich

Disclaimer: Customers are wholly responsible for ensuring their own compliance with all applicable laws and regulations. Information provided in this post does not constitute legal advice, and customers should consult their legal advisors for any questions regarding regulatory compliance.

In Part 1 of this blog series, we provided an overview of the U.S. export control regulations and their implications on cloud computing. In this Part 2, we cover Azure and Azure Government features in support of export control requirements.

Microsoft provides customers with contractual commitments, operational processes, and technical features to help them meet their export control obligations when using Azure and Azure Government. To help customers navigate export control rules, Microsoft has published the Microsoft Azure Export Controls White Paper that customers can download from the Service Trust Portal (see FAQ and White Papers section). Read on to learn more about the key features in Azure and Azure Government that enable you to meet export control requirements:

Location of Customer Data

Microsoft provides strong customer commitments regarding cloud services data residency and transfer policies. Most Azure services are deployed regionally and enable the customer to specify the region into which the service will be deployed, e.g., the United States. This commitment helps ensure that Customer Data stored in a U.S. region will remain in the United States and will not be moved to another region outside the United States.

Access to Customer Data by Microsoft personnel

Microsoft takes strong measures to protect Customer Data from inappropriate access or use by unauthorized persons. Microsoft engineers do not have default access to Customer Data in the cloud and access to Customer Data is not needed to operate Azure. Even for most support scenarios involving customer troubleshooting tickets, access to Customer Data is not needed. For those rare instances where resolving customer support requests requires elevated access to Customer Data, Microsoft engineers can be granted access to Customer Data under management oversight using temporary credentials via Just-in-Time (JIT) access. Using the restricted access workflow, access to Customer Data is carefully controlled, logged, and revoked when it is no longer needed.

This approach ensures that there is appropriate oversight for all access to Customer Data and that all JIT actions (consent and access) are logged for audit. Evidence that procedures have been established for granting temporary access for Azure personnel to Customer Data and applications upon appropriate approval for customer support or incident handling purposes is available from the Azure SOC 2 Type 2 attestation report produced by an independent third-party auditing firm.

Azure Customer Lockbox is a service that provides customers with the capability to control how a Microsoft engineer accesses their data. As part of the support workflow, a Microsoft engineer may require elevated access to Customer Data. Azure Customer Lockbox puts the customer in charge of that decision by enabling the customer to Approve/Deny such elevated requests. Azure Customer Lockbox is an extension of the JIT workflow and comes with full audit logging enabled.

Microsoft employee background screening

All Azure and Azure Government employees in the United States are subject to the Microsoft background screening, as outlined in the Table below. Personnel with the ability to access Customer Data for troubleshooting purposes in Azure Government are additionally subject to the verification of U.S. persons.

Table: Background screening for US-based Azure and Azure Government personnel

Data encryption in transit

Azure has extensive support for data encryption. Azure uses the Transport Layer Security (TLS) protocol to help protect data when it is traveling between Customers and Azure services. TLS provides strong authentication, message privacy, and integrity. Perfect Forward Secrecy (PFS) protects connections between a customer’s client systems and Microsoft cloud services by generating a unique session key for every session a customer initiates. PFS protects past sessions against potential future key compromises. Connections also use RSA-based 2,048-bit encryption key lengths. This combination makes it difficult for someone to intercept and access data that is in transit. Customers should review Azure best practices for the protection of data in transit and properly configure HTTPS endpoints for their resources provisioned in Azure to help ensure that all traffic going to and from their Virtual Machines is encrypted.

Data encryption at rest

Azure provides extensive options for data encryption at rest to help customers safeguard their data and meet their compliance needs using both Microsoft managed encryption keys, as well as customer managed encryption keys.

Azure Key Vault is a multi-tenant secrets management service that uses Hardware Security Modules (HSMs) to store and control access to secrets, encryption keys, and certificates. Key Vault HSMs are FIPS 140-2 Level 2 validated, which includes requirements for physical tamper evidence and role-based authentication. With Key Vault, customers can import or generate encryption keys in HSMs that never leave the HSM boundary to support Bring Your Own Key (BYOK) scenarios. Key Vault is designed, deployed, and operated such that Microsoft and its agents do not see or extract customer keys.

Azure Storage Service Encryption for Data at Rest helps ensure that data is automatically encrypted before persisting it to Azure Storage and decrypted before retrieval. All data written to Azure Storage is encrypted through 256-bit AES encryption, and the handling of encryption, decryption, and key management in Storage Service Encryption is transparent to customers. However, customers can also use their own encryption keys for Azure Storage encryption at rest and manage their keys in Azure Key Vault. Storage Service Encryption is enabled by default for all new and existing storage accounts and cannot be disabled.

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 is secured via a certificate stored in the master database of the server or an asymmetric key called TDE Protector stored under customer control in Azure Key Vault. Azure Key Vault supports Bring Your Own Key (BYOK), which enables customers to store TDE Protector in Key Vault and control key management tasks including key rotation, permissions, deleting keys, enabling auditing/reporting on all TDE Protectors, etc.  See Always Encrypted for more information.

Encryption support is also in place for customer IaaS Virtual Machines, enabling customers to encrypt their Windows and Linux IaaS VM disks. Disk encryption leverages the industry standard BitLocker feature of Windows and the DM-Crypt feature of Linux to provide volume encryption for the OS and data disks. The solution is integrated with Azure Key Vault to help customers control and manage the disk encryption keys.

Conclusion

Microsoft Azure and Azure Government provide important technical features, operational processes, and contractual commitments to help customers manage export control risks. Customers should carefully assess how their use of cloud services may implicate U.S. export controls and determine whether any of the data they want to store or process in the cloud may be subject to export controls. Where technical data subject to U.S. export controls may be involved, Azure and Azure Government are configured to offer features that help mitigate the potential risk of customers inadvertently violating U.S. export controls when accessing controlled technical data. With appropriate planning, customers can use these features in connection with their own internal procedures to help ensure full compliance with U.S. export controls.

To help customers navigate export control rules, Microsoft has published the Microsoft Azure Export Controls White Paper that customers can download from the Service Trust Portal (see FAQ and White Papers section). The whitepaper describes U.S. export controls (particularly as they apply to software and technical data), reviews potential sources of export control risks, and offers specific guidance to help Azure and Azure Government customers assess their obligations under these controls.

To learn more about how Microsoft helps customers meet their own compliance obligations across regulated industries and markets worldwide, see “Microsoft Azure Compliance Offerings.”

Stevan Vidich Principal Program Manager, Microsoft Strategic Missions and Technologies

Follow