How to configure azure communication services (ACS) to store call recordings in a protected storage behind a vnet

Hi @Ryan5021

Thank you for your reaching regarding securing ACS call recordings containing sensitive PHI in a VNet-protected storage account. Currently, ACS cannot directly write to a storage account that is fully isolated behind a VNet with public access disabled, since public endpoint access is needed for recordings using its managed identity. However, you can still achieve strong security and HIPAA compliance by setting up BYOS with storage firewalls that allow only ACS IP ranges, using RBAC, implementing private endpoints for read access, and enabling encryption. Below, you’ll find a step-by-step guide to help maximize security within ACS’s limitations. If you require stricter VNet isolation, a proxy-based workaround is available, though it will require custom implementation.

Step 1: Securely Set Up BYOS Using Managed Identity and RBAC

This setup allows ACS to write to your storage securely, without needing shared access signatures (SAS) tokens, by using authenticated access.

1. Enable the system-assigned managed identity for your ACS resource:

• Open your ACS resource in the Azure Portal.
• Go to Identity, select System assigned, set the status to On, and click Save.
• Take note of the Object (principal) ID.

      2. Assign the required RBAC role to ACS:

• Navigate to your Storage Account, then to Access Control (IAM), click Add, and choose Add role assignment.
• Select the role Storage Blob Data Contributor.
• For access assignment, choose Managed identity.
• Find your ACS resource by searching with the principal ID.
• Review the selection and assign the role.

      3.Create a private container for recordings:

• In your Storage Account, go to Containers and create a new container (for example, "recordings").
• Set the Public access level to Private (no anonymous access). 4.Begin recordings with BYOS:
• Within your ACS application code (such as when using the ACS SDK in Java, C#, and similar languages), provide the Blob URI when initiating a recording:

    var recordingStorageUri = new Uri("https://<your-storage-account>.blob.core.windows.net/recordings/");
    var startRecordingOptions = new StartRecordingOptions(callLocator)
    {
    RecordingStorageUri = recordingStorageUri
    };
    var response = await callAutomationClient.StartRecordingAsync(startRecordingOptions);
  

  • ACS will append filenames in the format {callId}/{timestamp}.mp4 or similar, depending on your settings.

This configuration prevents anonymous access and leverages secure, identity-based permissions.

Step 2: Restrict Storage Access Using Firewalls and Enable ACS Traffic

To prevent general public access while allowing ACS to write data, set up IP-based firewalls or use service tags. ACS does not have a specific service tag in Azure’s trusted services list, but you can apply IP ranges for your ACS region or resource instance.

1.To identify ACS IP ranges:

• ACS traffic uses region-specific IP addresses. You can download the most recent Azure IP ranges from the Azure IP Ranges and Service Tags JSON file and filter for "AzureCommunicationServices" or for your specific region, such as "CommunicationServices.WestUS2".
• Alternatively, check if ACS is supported by Azure service tags using the Azure CLI command: az network service-tags list --location <your-region>. If ACS is not listed, use the IP ranges instead.This setup ensures only ACS traffic can access storage, helping lower risks for PHI exposure.

2.Set up storage networking:

• Navigate to your Storage Account, then select Networking and go to Firewalls and virtual networks.
• Choose Enabled from selected virtual networks and IP addresses.
• In Firewall under Address range, add the ACS IP ranges for your region (e.g., West US 2: 20.36.0.0/23—confirm your region's ranges).
• Enable Allow Azure services on the trusted services list to access this storage account. ACS may not be listed, but this allows related Azure platform traffic; use IP rules for accuracy.
• Save your changes.

3.ACS test writes:

• Start a test call recording using ACS.
• Check for any errors in the ACS logs through Azure Monitor or review storage activity logs. If a 403 error appears, confirm that the IP ranges correspond with your ACS deployment region.

This measure limits access to traffic originating from ACS, which helps lower the risk associated with PHI.

Step 3: Add Private Endpoints for VNet-Protected Read Access

While ACS writes through the firewalled public endpoint, your VNet-integrated applications (such as VMs and App Services) can read recordings securely and privately.

1. Create a private endpoint:
   • Navigate to your Storage Account > Networking > Private endpoint connections > + Private endpoint.
   • Basics: Choose the resource group, enter a name, and select the region that matches your storage account.
   • Resource: Set the target subresource to blob.
   • Virtual network: Pick your VNet and subnet.
   • Private DNS integration: Enable and link to privatelink.blob.core.windows.net.
   • Review your settings and create the endpoint.
2. Access from VNet resources:
   • Reference the private DNS name (e.g., <account>.privatelink.blob.core.windows.net) in your applications or tools.
   • Verify that Network Security Groups (NSGs) on the subnet allow outbound traffic to port 443 (HTTPS).

This setup ensures your internal applications can access PHI securely without exposure to the public internet.

  Step 4: Strengthen PHI Protection with Encryption, Auditing, and Retention

To comply with HIPAA standards:

1. Enable encryption:
   • Go to Storage Account > Encryption > Choose Customer-managed key > Select or create a key in Azure Key Vault.
   • Turn on infrastructure encryption for added protection.
2. Set up auditing and monitoring:
   • Navigate to Storage Account > Monitoring > Diagnostic settings > Forward logs to Log Analytics or another storage location.
   • Enable blob read/write logging and configure alerts for unusual access.
3. Configure retention policies:
   • Apply lifecycle management to automatically delete old recordings (such as after 30 days).
   • Activate immutable storage (WORM) for compliance using object lock.
4. Review compliance:
   • Refer to Azure's HIPAA documentation: ACS and Storage can be HIPAA-compliant if set up correctly. Use Azure Policy to enforce these configurations.

Step 5: Workarounds for Complete VNet Isolation (If Firewalls Aren't Enough)

If you need to prevent any public endpoint exposure for ACS writes:

Proxying through Azure API Management (APIM) in Internal Mode:

• Set up APIM within your VNet in internal mode.
• Configure an API in APIM to proxy blob write operations to your private storage using managed identities.
• Since ACS BYOS requires direct Blob URIs, adjust your workflow so that ACS sends recording metadata to an Event Grid topic. Then, use APIM or a VNet-integrated Function to perform the actual storage write.

Utilize VNet-Integrated Azure Functions as a Proxy:

• Create an Event Grid subscription for ACS recording events.
• Use a VNet-integrated Function to download files from a temporary location and transfer them to your private storage.
• This process introduces some latency (about 5-10 seconds) but ensures isolation.

Alternative: Post-Processing Copy:

• Allow ACS to write to a firewalled public storage. Then, use Azure Data Factory or Functions to promptly copy the files to a fully private VNet storage and remove the originals.

Test these solutions in a development environment first, as they require custom code. For latency-sensitive needs, the firewall approach is recommended.

Microsoft references:

https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/call-automation/call-recording/bring-your-own-storage?pivots=programming-language-java

https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security

https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security-trusted-azure-services

https://learn.microsoft.com/en-us/azure/private-link/tutorial-private-endpoint-storage-portal?tabs=dynamic-ip

https://learn.microsoft.com/en-us/azure/virtual-network/service-tags-overview

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.

Hmm, but this doesn't seem like a resilient path forward. These IP ranges aren't static right? Is there a reliable set of IP ranges for ACS?

1.To identify ACS IP ranges:

• ACS traffic uses region-specific IP addresses. You can download the most recent Azure IP ranges from the Azure IP Ranges and Service Tags JSON file and filter for "AzureCommunicationServices" or for your specific region, such as "CommunicationServices.WestUS2".
• Alternatively, check if ACS is supported by Azure service tags using the Azure CLI command: az network service-tags list --location <your-region>. If ACS is not listed, use the IP ranges instead.This setup ensures only ACS traffic can access storage, helping lower risks for PHI exposure.