Understanding cloud operator access

When running workloads in the public cloud, a common concern around digital sovereignty is the extent to which the cloud operator has access to the systems running your workload. This article provides a technical overview of the cloud operator’s access to help you make risk-based decisions that drive workload architecture. For information on access to customer data for law enforcement requests, see the Law Enforcement Requests Report.

Operator access

Operating the cloud infrastructure and platform is a collaborative effort between different service teams, such as datacenter technicians, software engineers, and cybersecurity experts. At a high level, there are two types of operations:

• Physical operations: Managing the datacenters and physical infrastructure in the cloud regions.
• Logical operations: Managing the logical (software) components that deliver cloud services.

The different nature of these operations means they require different types of specialists. Separation of concerns ensures that these separate teams perform these types of operations.

Physical operations

Microsoft designs, builds, and operates datacenters in a way that strictly controls physical access to the areas where your data is stored. Microsoft takes a layered approach to physical security, to reduce the risk of unauthorized users gaining physical access to data and other datacenter resources. Datacenters physically managed by Microsoft have extensive layers of protection: access approval at the facility’s perimeter, at the building’s perimeter, inside the building, and on the datacenter floor. For more information see Datacenter security overview.

Datacenter technicians keep the physical infrastructure running, which includes installing, fixing, and replacing networking and server equipment, and maintaining power and cooling systems. If technicians require logical access to Microsoft online services systems, their access is scoped to the operations they need to perform.

Datacenter technicians might handle physical storage devices. All data on storage devices is encrypted, often with multiple layers of encryption, with keys to which datacenter technicians don't have access. For more information, see Encryption and key management overview. Storage devices are securely disposed, as mentioned in Data-bearing device destruction.

Server equipment is designed with a hardware root-of-trust that validates the integrity of components such as the host, Baseboard Management Controller (BMC), and all peripherals. For more information see Azure platform integrity and security.

Datacenter technicians might need to perform operations on networking equipment. With some exceptions, network traffic is encrypted in transit, so accidental or malicious access to network traffic doesn't expose any data.

Logical operations

Most logical operations, also known as platform operations, are automated and don't require operator access. However, engineers might occasionally need to perform preventive maintenance, fix an issue identified by monitoring systems, or fix an issue based on a customer support ticket. In most customer support cases, the engineers don’t need access to the platform to fix the issue.

Identity and access

Microsoft online services are designed to allow Microsoft's engineers to operate services without accessing customer content. By default, Microsoft engineers have Zero Standing Access (ZSA) to customer content and no privileged access to the production environment. Microsoft online services use a Just-In-Time (JIT), Just-Enough-Access (JEA) model to provide service team engineers with temporary privileged access to production environments when such access is required to support Microsoft online services. The JIT access model replaces traditional, persistent administrative access with a process for engineers to request temporary elevation into privileged roles when required. For more information, see Identity and access management overview.

In cases where Microsoft engineers need access because of a support ticket, you can grant the access through Customer Lockbox, if it's available for the service and you have enabled it. For more information about Customer Lockbox and the supported services, see Customer Lockbox for Azure and Microsoft Purview Customer Lockbox.

If access is approved, that access is scoped to the operations the engineer must perform and is time bound. All requests and approval are logged and monitored for anomalies. Also, Azure operations personnel are required to use secure admin workstations (SAWs). With SAWs, administrative personnel use an individually assigned administrative account separate from a standard user account. For more information, see Azure information system components and boundaries.

Encryption keys

By default, Microsoft online services encrypt data at rest and in transit with Microsoft-managed keys. When using Microsoft-managed keys, Microsoft online services automatically generate and securely store the root keys used for service encryption. You can use Service Encryption with customer-managed keys to control your encryption keys. Microsoft employees can’t directly access customer-managed keys because they're stored in Azure Key Vault or Azure Key Vault managed HSM. Microsoft services use envelope encryption. Furthermore, the Key encryption key is stored in Azure Key Vault service and can’t be exported. For more information, see Encryption and key management overview.

If your organization needs to control the key management infrastructure, you can consider using Azure Key Vault Managed HSM, which provides key sovereignty, availability, performance, and scalability.

Access to service components and data

The extent to which an engineer with the appropriate permissions and approvals has access to service components and data depends on the service, workload architecture, and configuration.

Prevention and detection

Individual services might provide configuration options that help you prevent certain types of operator access. The configuration can affect functionality or Microsoft’s ability to provide support. So, you must take these factors into account when deciding on the acceptable level of risk. Microsoft Cloud for Sovereignty can help with policies that enforce configuration of services to meet specific requirements.

Microsoft Cloud for Sovereignty Transparency logs provide visibility into occasions when Microsoft engineers have accessed customer resources using the Just-In-Time access service. This enables you to detect such Just-In-Time operator access and understand the scope of data that could have been visible to an operator. The services can also help you detect operator access in more detail through auditing, logging, and monitoring capabilities. You can feed the logging and monitoring data into a Security Information and Event Management (SIEM) system such as Microsoft Sentinel for a thorough security analysis.