A vital security goal of an organization is to protect their data stores from random access over the internet, may it be an on-premise or a Cloud/ SaaS data store.
Typically a cloud data store controls access using the below mechanisms:
Firewall rules that limit connectivity by IP address
Authentication mechanisms that require users to prove their identity
Authorization mechanisms that restrict users to specific actions and data
With the introduction of Static IP address range, you can now whitelist IP ranges for the particular Azure integration runtime region to ensure you don’t have to allow all Azure IP addresses in your cloud data stores. This way, you can restrict the IP addresses that are permitted to access the data stores.
Note: The IP address ranges are blocked for Azure integration runtime and is currently only used for Data Movement, pipeline and external activities. Dataflows now do not use these IP ranges. If you use Azure-SSIS integration runtime, you can bring your own static public IP addresses (BYOIP) to allow in your firewall rules, see this blog.
Though this should work in many scenarios, we do understand that a unique Static IP address per integration runtime would be desirable, but this wouldn't be possible using Azure Integration Runtime currently, which is serverless. If required, you can always set up a Self-hosted Integration Runtime and use your Static IP with it.
Summarizing data access strategies through Azure Data Factory
Trusted Service - Azure Storage (Blob, ADLS Gen2) supports firewall configuration that enables select trusted Azure platform services to access the storage account securely. Trusted Services enforces Managed Identity authentication, which ensures no other data factory can connect to this storage unless whitelisted to do so using it's managed identity. You can find more details in this blog. Hence, this is extremely secure and recommended.
Unique Static IP - You will need to set up a self-hosted integration runtime to get a Static IP for Data Factory connectors. This mechanism ensures you can block access from all other IP addresses. If you use Azure-SSIS integration runtime, you can bring your own static public IP addresses (BYOIP) to allow in your firewall rules, see this blog.
Static IP range - You can use Azure Integration Runtime's IP addresses to whitelist it in your storage (say S3, Salesforce, etc.). It certainly restricts IP addresses that can connect to the data stores but also relies on Authentication/ Authorization rules.
Service Tag - A service tag represents a group of IP address prefixes from a given Azure service (like Azure Data Factory). Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change, minimizing the complexity of frequent updates to network security rules. It is useful when whitelisting data access on IaaS hosted data stores in Virtual Network.
Allow Azure Services - Some services lets you allow all Azure services to connect to it in case you choose this option.
*Applicable only when Azure Data Explorer is VNet injected, and IP range can be applied on NSG/ Firewall.
See the following related articles for more details: