Introduction
Tarbh Tech manages Microsoft Sentinel as part of the security tooling for an eCommerce client. Microsoft Sentinel is a cloud-native security information and event management (SIEM) solution that helps organisations detect and respond to threats faster and more effectively. It’s configured to collect data from various sources, including Salesforce logs, and provides built-in analytics and machine-learning capabilities to help you identify suspicious activity quickly.
Using Azure Private Link, you can securely add the Microsoft Sentinel connector for Salesforce without exposing the Azure Storage Account used by that connector to the public internet. This guide will show you how to configure Azure Private Link for this use case.
Issues with Default Connector for Salesforce for Microsoft Sentinel
The default Salesforce Sentinel connector comprises a Python-based function app and an Azure Storage Account. The ARM template assumes that these Azure Resources will be publicly accessible. However, the client had configured Azure Policy to block public access to storage accounts by default, with no exceptions, which resulted in a failed deployment of the default connector.
The Tarbh Tech team developed a new ARM template by merging the existing Data Connector and the following elements:
The Azure Function App
The Python-based Function App uses the AzureWebJobsStorage and WEBSITE_CONTENTAZUREFILECONNECTIONSTRING app settings to connect to a private endpoint-secured Storage Account. The code is downloaded from Microsoft, and several additional variables are defined for the Salesforce REST API endpoint.
Elastic Premium Plan
The original app service plan is consumption only and doesn’t support Private Link; thus, the Azure Function app provisioned here uses the upgraded Azure Functions Elastic Premium plan, which supports Private Link.
An Azure Storage account
The Storage account that the Function uses for operation and file contents.
A Virtual Network
The Azure resources here integrate with a virtual network. The use of private endpoints keeps network traffic contained within the virtual network; two subnets are configured:
- snet-func: Subnet for Azure Function virtual network integration. This subnet is delegated to the Function App.
- snet-pe: Subnet for private endpoints. Private IP addresses are allocated from this subnet.
The Private Endpoints
Azure Private Endpoints connect to specific Azure resources using a private IP address. This type of connection ensures that network traffic remains within the designated virtual network and access is available only for specific resources. This sample configures private endpoints for the following resources, which are required to be secured by in-place Azure Policy:
- Azure Storage
- Azure File storage
- Azure Blob storage
- Azure Queue storage
- Azure Table storage
Private DNS Zones
Using a private endpoint to connect to Azure resources means connecting to a private IP address instead of the public endpoint. Existing Azure services are configured to use existing DNS to connect to the public endpoint. Therefore, the DNS configuration must be overridden to connect to the private endpoint.
A private DNS zone will be created for each Azure resource configured with a private endpoint. In addition, a DNS A record is created for each private IP address associated with the private endpoint.
The following DNS zones are created in this sample:
- privatelink.queue.core.windows.net
- privatelink.blob.core.windows.net
- privatelink.table.core.windows.net
- privatelink.file.core.windows.net
Application Architecture
The resulting architecture is as follows:
Using the Custom ARM Template
You can deploy the custom ARM template as follows:
- Copy the code from this GitHub Gist
- Log into the Azure Portal with appropriate permissions
- Search for “Deploy a custom template” or click here.
- Edit the template in the browser and paste the code from GitHub.
- Enter the values for:
- Workspace ID – this is for the Log Analytics Workspace used by Sentinel.
- Workspace Key.
- Salesforce User – this account must have API and Read Event Log Files permissions.
- Salesforce Password.
- Salesforce Security Token – this is required for each account using the Salesforce REST API. Follow the Salesforce documentation on resetting this and have it sent to you by email.
- Salesforce Token URI – the production instance starts with “login” rather than “test”.
- Salesforce Consumer Key – REST API access requires the creation of a “Connected App” in Salesforce, which will have a corresponding Consumer Key.
- Salesforce Consumer Secret.
- Time Interval – recommended leaving this at hourly.
- Once ready, click “Review + Create”, and it should deploy without issue.
Confirming Successful Deployment
It will take the function app several minutes to deploy fully and then start up. The hourly selection for “Time Interval” results in the Function firing every hour, on the hour. In our experience, the app runs for approximately one to five minutes. You can trigger a manual run by navigating to “Function App > unctions > SalesforceSentinelConnector > Code + Test”. After 15-20 minutes, a new custom log table should be visible in the relevant Log Analytics Workspace:
Analytics Rules and Next Steps
Once the connection is configured, you can create analytics rules in Sentinel to monitor for specific security events of interest. Suggested use cases could be:
- Excessive Login failures
- Login activity from malicious IP addresses
- Excessively large queries over API or Reporting interfaces
For more information on using Sentinel for security monitoring, see the Azure Sentinel documentation locate here: Microsoft Sentinel documentation | Microsoft Learn
Salesforce API Reference here: EventLogFile | Object Reference for the Salesforce Platform | Salesforce Developers
If you have similar requirements and would like to discuss how Tarbh Tech can assist, please book a free 30-minute video call at the following link: Book A Consultation – Tarbh Tech