PowerApps Azure SQL security best practice - AAD alone vs Azure Private Link
I have a question about the relative security merits of using AAD authentication alone versus adding a Azure Private Link. This particularly directed at developers building PowerApps using Azure SQL as the data source and what they consider to be sufficient security hardening.
I have built a PowerApp to replace a clunky spreadsheet application for tracking certain client requests. It's a proof of concept to validate the PowerPlatform approach before using it more extensively in other areas. I normalised the data from the spreadsheet and built a fairly simple Azure database in an Azure instance I provisioned myself for development. All interaction from the App to the DB goes via the Microsoft SQL Connector. Associated client documents and correspondence is stored in SharePoint Online, so there isn't much personal information in the DB itself, just contact email and phone numbers.
During development, I used SQL authentication as it's simplest to get working and I had control over it. Now that the time to go live is approaching, I want to move to AAD authentication. This is where our IT department gets involved as I don't have the rights to create the AD group.
The problem is - they say "best practice" is to create a private link to the Azure resource group and at the moment, our organisation is concentrating on a large AWS rollout and they are not inclined to invest time/people/money to setup an official Azure environment for one production app.
They've suggested I migrate to using an on-premises SQL instance and a data gateway (which will send performance down the toilet and also introduce problems as the on-premises version of the connector has several limitations which will be difficult to workaround).
I have 20+ years development experience - mainly C++/COM but I don't pretend to be a specialist DBA nor a security expert but I am sufficiently versed in both to understand the required architectures and ask the right questions when out of my depth.
My question basically boils down to this - is securing an Azure SQL instance with AAD authentication generally regarded as "sufficient" security for corporate databases which aren't mission critical? We're not talking about banking systems here.
At the moment, the "system" is a large spreadsheet of which there are multiple copies emailed back and forth, stored in SharePoint and on staff laptops. My instincts suggest it seems overkill to insist on an Azure Private Link when the current situation is a security joke.
Of course stronger security hardening is always "better", but you've got to balance that against the risks and cost of implementation. Nowhere in the PowerApps SQL connector documentation does it mention Azure Private Links nor in the numerous partner case studies. If it was thought to be a security must have for PowerApps, surely Microsoft would have mentioned it in their best practice guidance.
I would have thought the OData network route from Azure to the connector host would have been entirely on Microsoft's internal network anyway.
Any thoughts about how to push back on this demand or thoughts on alternative approaches would be greatly appreciated.
Private Links do provide an excellent mechanism for locking down the network mechanics in complex scenarios so that you can minimize the possible attack surface of your app by only allowing traffic from a narrow set of entry points. And, they are considered a best practice for hybridizing your on-prem and Azure footprints. BUT, you can accomplish the same thing with a VNet and Firewall Rules, or an App Service Environment, if you don't mind doing it one app at a time. So, I think this is a case where you're both right.
If they are going to scale up Azure implementations to many apps and many services, then a Private Link is the way to go so that the Azure environment might as well be inside their private network. But if you're just trying to get one MVP out the door, then requiring a Private Link is asinine when you could easily constrain traffic with firewall rules.