Proper Securing http trigger Azure Function - best practices

Question

Hello,

I am currently encountering a challenge that necessitates the development of an effective solution for the following scenario: I possess a database in Azure Virtual Network with public access deactivated. My objective is to design an Azure Function, utilizing Python, capable of interacting with this database to retrieve results and return them as JSON objects via POST requests. I must also facilitate access for an external application to this function, though I lack specific details or a design for this application at present. Consequently, I am considering two potential scenarios:

1. The application is external and on-premises, with the only known detail being its static IP address.
2. The application is hosted on Azure, but within a different tenant. In this case, I will be aware of the subscription ID, resource group name, and IP address.

The steps I have undertaken so far include:

1. Establishing an Azure Function App using the Premium Plan, creating a new Storage Account, and employing default network settings. Due to limitations with Python applications, it is not feasible to modify Storage Account network settings during the creation process, so these were left unchanged at that stage.
2. In the database's Virtual Network, I added a Subnet and executed Virtual Network Integration within my Function App, enabling the Function to query the database.
3. For the Storage Account Networking Settings associated with the Function App, I chose "Enabled from selected virtual networks and IP addresses" and included the Virtual Network utilized by the SQL Database. Is this approach correct?
4. I deployed the function using the 'Function' Authorization method.
5. In the Networking section of the Function App, under Inbound Traffic Configuration -> Public Network Access, I selected 'Enable from selected virtual networks and IP Addresses.' For testing purposes, my local IP was added.
6. All variables used in the Function code are local, stored in the Configuration section as Key Vault references. I had previously activated Managed Identity for the Function App and granted access to the Key Vault containing these variables as secrets.
7. I tested the function from my PC using the Function Key in the headers. This, combined with my authorized IP address, ensured smooth operation of the Function. In the scenario I am addressing, I considered adding the external application's IP address to the list and securely sharing the Function Key with the app owner.

My questions and concerns are as follows:

1. First and foremost, is this a robust and secure solution?
2. After reviewing documentation, I understand that sharing Function Keys is generally discouraged. However, I intend to use this key as an additional layer of security, supplementing the Network Access IP restriction.
3. Could anyone suggest a more robust solution that wouldn't be excessive?

Regrettably, my understanding of the application set to call the function is somewhat vague. I have devised a concept that functions well in my tests, but I am seeking community input to determine if there are aspects that could be improved.

Answer 1

@11-4688 Here are my opinions to your questions

1. Yes. This is robust considering your IP Restrictions in place, which should prevent any other requests from reaching your function app. For most scenarios that require public endpoints, this is perfect to lock down function apps.
2. While there may be cases where you would not want to share the keys, in your case, it serves the purpose of an API Key to call your API. This would not be scalable when have multiple separate applications though. But you can design for this, if required.

For a more robust solution that goes beyond IP Restrictions and allows you to expose your API to multiple external applications, you should use Azure API Management.

This would provide a couple of benefits

• You can share separate subscription keys instead of the function's key to access
• You can leverage Azure AD based Authentication for external applications to access your application
• Throttle requests from overloading your API
• And many more features as required...