Recently I came across what I consider to be a serious security risk when configuring Azure SQL Database for use with Azure services (such as Power Apps), & in my opinion, Microsoft don’t draw enough attention to this risk in the Azure Portal.
The issue is as follows:
When configuring Azure SQL Database to allow connections from an Azure Service, the easy option is to turn on “Allow Azure services and resources to access this server” in the “Firewalls and virtual networks” settings for the Azure SQL Server.
Given that there is no warning on the “Allow Azure services” setting in the Azure Portal, an administrator might be forgiven for believing that it would only allow access from within their own subscription. However, this is not the case! On digging through Microsoft’s documentation, it becomes apparent that turning on this setting will allow connections from other Azure subscriptions.
Given that the Server admin login in Azure SQL Database can’t be disabled (unlike the SA login on an on-premises or IaaS SQL Server instance) & can’t have multi-factor authentication applied (unlike an Azure Active Directory account), this means that all that protects the data in an Azure SQL Database with the “Allow Azure services” setting turned on is a username & (hopefully) strong password.
On top of that, Power Apps doesn’t support Always Encrypted at this time (or if it does, I haven’t seen any documentation about it).
There is a slightly more secure option available, which is to leave the “Allow Azure services” setting turned off & configure the Azure SQL Server’s firewall to only allow the IP addresses for the desired service, rather than all of Azure. This is straightforward enough when allowing an Azure Virtual Machine to connect to an Azure SQL Database as we can set the VM’s IP address, but we don’t have control over the IP addresses of SaaS products like Power Apps. Their IP addresses may change at any time to another in the range.
So at best, we can allow only the published range of IP addresses for our region. But this may still allow connections from other customer’s subscriptions as these IP ranges are used by all services regardless of their subscription. Overall, while this option is more secure, it may not be considered secure enough for an organisation’s compliance or data protection purposes if the Azure SQL Database is used to store personal or sensitive data.
The most secure option that I can identify for Azure services is to not use Azure SQL Database at all, & instead use an installed SQL Server instance (either on-premises or in an Azure VM) with a data gateway. The data gateway is linked to a specific Azure Active Directory tenant, based on the email address supplied during setup.
Be First to Comment