Customer Lockbox for Microsoft Azure
Note
To use this feature, your organization must have an Azure support plan with a minimal level of Developer.
Most operations and support performed by Microsoft personnel and subprocessors do not require access to customer data. In those rare circumstances where such access is required, Customer Lockbox for Microsoft Azure provides an interface for customers to review and approve or reject customer data access requests. It is used in cases where a Microsoft engineer needs to access customer data, whether in response to a customer-initiated support ticket or a problem identified by Microsoft.
This article covers how to enable Customer Lockbox for Microsoft Azure and how requests are initiated, tracked, and stored for later reviews and audits.
Supported services
The following services are currently supported for Customer Lockbox for Microsoft Azure:
- Azure API Management
- Azure App Service
- Azure AI Search
- Azure AI Services
- Azure Chaos Studio
- Azure Communications Gateway
- Azure Container Registry
- Azure Data Box
- Azure Data Explorer
- Azure Data Factory
- Azure Data Manager for Energy
- Azure Database for MySQL
- Azure Database for MySQL Flexible Server
- Azure Database for PostgreSQL
- Azure Edge Zone Platform Storage
- Azure Energy
- Azure Functions
- Azure HDInsight
- Azure Health Bot
- Azure Intelligent Recommendations
- Azure Information Protection
- Azure Kubernetes Service
- Azure Load Testing (CloudNative Testing)
- Azure Logic Apps
- Azure Monitor (Log Analytics)
- Azure Red Hat OpenShift
- Azure Spring Apps
- Azure SQL Database
- Azure SQL Managed Instance
- Azure Storage
- Azure Subscription Transfers
- Azure Synapse Analytics
- Commerce AI (Intelligent Recommendations)
- DevCenter / DevBox
- ElasticSan
- Kusto (Dashboards)
- Microsoft Azure Attestation
- OpenAI
- Spring Cloud
- Unified Vision Service
- Virtual Machines in Azure
Enable Customer Lockbox for Microsoft Azure
You can now enable Customer Lockbox for Microsoft Azure from the Administration module.
Note
To enable Customer Lockbox for Microsoft Azure, the user account needs to have the Global Administrator role assigned.
Workflow
The following steps outline a typical workflow for a Customer Lockbox for Microsoft Azure request.
Someone at an organization has an issue with their Azure workload.
After this person troubleshoots the issue, but can't fix it, they open a support ticket from the Azure portal. The ticket is assigned to an Azure Customer Support Engineer.
An Azure Support Engineer reviews the service request and determines the next steps to resolve the issue.
If the support engineer can't troubleshoot the issue by using standard tools and service generated data, the next step is to request elevated permissions by using a Just-In-Time (JIT) access service. This request can be from the original support engineer or from a different engineer because the problem is escalated to the Azure DevOps team.
After the Azure Engineer submits an access request, Just-In-Time service evaluates the request taking into account factors such as:
- The scope of the resource.
- Whether the requester is an isolated identity or using multifactor authentication.
- Permissions levels. Based on the JIT rule, this request might also include an approval from Internal Microsoft Approvers. For example, the approver might be the Customer support lead or the DevOps Manager.
When the request requires direct access to customer data, a Customer Lockbox request is initiated.
The request is now in a Customer Notified state, waiting for the customer's approval before granting access.
One or more approvers at the customer organization for a given Customer Lockbox request are determined as follows:
- For Subscription scoped requests (requests to access specific resources contained within a subscription), users with the Owner role or the Azure Customer Lockbox Approver for Subscription role on the associated subscription.
- For Tenant scope requests (requests to access the Microsoft Entra tenant), users with the Global Administrator role on the Tenant.
Note
Role assignments must be in place before Customer Lockbox for Microsoft Azure starts to process a request. Any role assignments made after Customer Lockbox for Microsoft Azure starts to process a given request will not be recognized. Because of this, to use PIM eligible assignments for the Subscription Owner role, users are required to activate the role before the Customer Lockbox request is initiated. Refer to Activate Microsoft Entra roles in PIM / Activate Azure resource roles in PIM for more information on activating PIM eligible roles.
Role assignments scoped to management groups are not supported in Customer Lockbox for Microsoft Azure at this time.
At the customer organization, designated lockbox approvers (Azure Subscription Owner/Microsoft Entra Global admin/Azure Customer Lockbox Approver for Subscription receive an email from Microsoft to notify them about the pending access request. You can also use the Azure Lockbox alternate email notifications feature to configure an alternate email address to receive lockbox notifications in scenarios where Azure account is not email enabled or if a service principal is defined as the lockbox approver.
Example email:
The email notification provides a link to the Customer Lockbox blade in the Administration module. The designated approver signs in to the Azure portal to view any pending requests that their organization has for Customer Lockbox for Microsoft Azure:
The request remains in the customer queue for four days. After this time, the access request automatically expires and no access is granted to Microsoft engineers.To get the details of the pending request, the designated approver can select the Customer Lockbox request from Pending Requests:
The designated approver can also select the SERVICE REQUEST ID to view the support ticket request that was created by the original user. This information provides context for why Microsoft Support is engaged, and the history of the reported problem. For example:
The designated approver reviews the request and selects Approve or Deny:
As a result of the selection:- Approve: Access is granted to the Microsoft engineer for the duration specified in the request details, which is shown in the email notification and in the Azure portal.
- Deny: The elevated access request by the Microsoft engineer is rejected and no further action is taken.
For auditing purposes, the actions taken in this workflow are logged in Customer Lockbox request logs.
Auditing logs
The auditing logs for Customer Lockbox for Azure are written to the activity logs for subscription-scoped requests and to the Entra Audit Log for tenant-scoped requests.
Subscription-scoped requests - Activity Logs
In the Azure portal, Customer Lockbox for Microsoft Azure blade, select Activity Logs to view auditing information related to Customer Lockbox requests. You can also view the Activity Logs in the subscription details blade for the subscription in question. In both cases, you can filter for specific operations, such as:
- Deny Lockbox Request
- Create Lockbox Request
- Approve Lockbox Request
- Lockbox Request Expiry
As an example:
Tenant-Scoped requests - Audit Log
For tenant-scoped Customer Lockbox requests, log entries are written to the Entra Audit Log. These Log entries are created by the Access Reviews service with activities such as:
- Create request
- Request approved
- Request denied
You can fiiter for Service = Access Reviews and Activity = one of the above activities.
As an example:
Note
The History tab in the Azure Lockbox portal has been removed due to existing technical limitations. To see Customer Lockbox request history, please use the Activity Log for subscription-scoped requests and the Entra Audit Log for tenant-scoped requests.
Customer Lockbox for Microsoft Azure integration with the Microsoft cloud security benchmark
We introduced a new baseline control (PA-8: Determine access process for cloud provider support) in the Microsoft cloud security benchmark that covers Customer Lockbox applicability. Customers can now use the benchmark to review Customer Lockbox applicability for a service.
Exclusions
Customer Lockbox requests are not triggered in the following scenarios:
- Emergency scenarios that fall outside of standard operating procedures and require urgent action from Microsoft to restore access to online services or to prevent corruption or loss of customer data, or to investigate a security or abuse incident. For instance, a major service outage or a security incident demands immediate attention to recover or restore services under unexpected or unpredictable circumstances. These "break glass" events are rare and, in most cases, do not necessitate access to customer data for resolution. The controls and processes governing Microsoft's access to customer data in core online services align with NIST 800-53 and are validated through SOC 2 audits. For further information, refer to the Azure security baseline for Customer Lockbox for Microsoft Azure.
- A Microsoft engineer accesses the Azure platform as part of troubleshooting and is inadvertently exposed to customer data. For example, the Azure Network Team performs troubleshooting that results in a packet capture on a network device. It is rare that such scenarios would result in access to meaningful quantities of customer data. Customers can further protect their data through the use of Customer-managed keys (CMK), which is available for some Azure service. For more information see Overview of Key Management in Azure.
External legal demands for data also do not trigger Customer Lockbox requests. For details, see the discussion of government requests for data on the Microsoft Trust Center.
Next steps
Enable Customer Lockbox from the Administration module in the Customer Lockbox blade. Customer Lockbox for Microsoft Azure is available for all customers who have an Azure support plan with a minimal level of Developer.