In this part I cover:
- Configure a resource firewall, including storage account, Azure SQL, Azure Key Vault or Azure App Service
- Configure network isolation for Web Apps and Azure Functions
Table of Contents
Why to isolate resources inside Azure?
If You enable every network and Identity access to resources the end result could be hazardous.
One user account or service will be affected by attacker and they will have access to all services across the networks.
How to secure Storage Accounts?
By default Storage accounts are open from all networks.
When choosing selected networks, You can limit the access to Storage accounts.
You can Add existing VNet or create a new one.
From here You can enable DDoS protection and see what Service Endpoint will be created.
I will be covering DDoS in my next posts but here’s a small description.
Azure DDoS basic protection is integrated into the Azure platform by default and at no additional cost. Azure DDoS standard protection is a premium paid service that offers enhanced DDoS mitigation capabilities via adaptive tuning, attack notification, and telemetry to protect against the impacts of a DDoS attack for all protected resources within this virtual network.
You can enable or leave Firewall disabled. If You enable it will create an Azure Firewall.
Note! Classic storage accounts do not support firewalls and virtual networks.
You will find the VNet that we just created under Virtual Networks and the Service Endpoint under it.
And Subnets You can see the subnets created.
Exceptions and routing
You can have Exceptions to allow Azure native services to access the Storage account and add routing preference.
Microsoft network routing will direct your traffic to enter the Microsoft cloud closer to the requesting client. Internet routing will direct your traffic to enter the Microsoft cloud closer to the Azure storage endpoint.
Determine which route-specific public endpoints to publish. You can find published endpoints under Properties.
You can create sub-resource for Storage account. With this You can allow access only to a specific type of storage
How to secure Azure SQL?
With SQL You have the same kind of securing options. While creating an SQL You can create Private endpoint.
And also Private DNS-zone integration
System assigned managed identity
You can also assign system managed identities.
Azure SQL has Server firewall option.
In firewall, You can add Your client IP to allowed list, Allow native Azure services and resources connect to Your SQL.
And also add the name VNet rules than inside Storage account.
Although the configuration is a little bit different but same terms and services.
What about Key Vault?
Again with Key Vault, You have the same options for firewalls and private endpoints.
You can connect to the private endpoint we created for the SQL in the previous steps and to possible sub-resources.
Private DNS-zone integration
And securing App services
App services have a little bit different menus but almost same ideas.
Access restrictions allow you to define lists of allow/deny rules to control traffic to your app. Rules are evaluated in priority order. If there are no rules defined then your app will accept traffic from any address.
With Access restrictions You can deny or allow connections. Add priority to different rules with IP patters and header info.
You can use certificates from Key Vault, which is kinda neat feature.
But first You need to add a Custom domain to the app.
You also have Private Endpoints but You can only use them in better App service plans.
So You have to scape up if not running there versions.
Once upgraded, You will see Private Endpoints.
You can also add a VNet integration.
App Service integration with hybrid connections enables your app to access a single TCP endpoint per hybrid connection. Here you can manage the new and classic hybrid connections used by your app.
You can also publish Your application with Front Door.
An finally securing Function app
Actually function app has identical security solutions than App service so I won’t be writing anything else from it than about Authentication
Authentication with Identity providers
App Service uses federated identity, in which a third-party identity provider manages the user identities and authentication flow for you. The following identity providers are available by default:
|Provider||Sign-in endpoint||How-To guidance|
|Microsoft Identity Platform||App Service Microsoft Identity Platform login|
|App Service Facebook login|
|App Service Google login|
|App Service Twitter login|
|Any OpenID Connect provider||App Service OpenID Connect login|
Considerations for using built-in authentication
Enabling this feature will cause all requests to your application to be automatically redirected to HTTPS, regardless of the App Service configuration setting to enforce HTTPS. You can disable this with the
requireHttps setting in the V2 configuration. However, we do recommend sticking with HTTPS, and you should ensure no security tokens ever get transmitted over non-secure HTTP connections.
App Service provides a built-in token store, which is a repository of tokens that are associated with the users of your web apps, APIs, or native mobile apps. When you enable authentication with any provider, this token store is immediately available to your app. If your application code needs to access data from these providers on the user’s behalf, such as:
- post to the authenticated user’s Facebook timeline
- read the user’s corporate data using the Microsoft Graph API
You typically must write code to collect, store, and refresh these tokens in your application. With the token store, you just retrieve the tokens when you need them and tell App Service to refresh them when they become invalid.
The ID tokens, access tokens, and refresh tokens are cached for the authenticated session, and they’re accessible only by the associated user.
If you don’t need to work with tokens in your app, you can disable the token store in your app’s Authentication / Authorization page.
Things to remember
Azure storage account contains all of your Azure Storage data objects, including blobs, file shares, queues, tables, and disks.
Service Endpoint provides secure and direct connectivity to Azure services over an optimized route over the Azure backbone network. Endpoints allow you to secure your critical Azure service resources to only your virtual networks.
Private Endpoint is a network interface that uses a private IP address from your virtual network. This network interface connects you privately and securely to a service powered by Azure Private Link.
Azure SQL Server firewall allows You to create server-level and database-level firewall rules
Azure Virtual Network (VNet) is a representation of your own network in the cloud. It is a logical isolation of the Azure cloud dedicated to your subscription.
Private DNS-zone manages and resolves domain names in the virtual network without the need to configure a custom DNS solution.
Azure App Service is an HTTP-based service for hosting web applications, REST APIs, and mobile back ends.
Azure Functions is an event driven, compute-on-demand experience that extends the existing Azure application platform with capabilities to implement code triggered by events occurring in Azure or third party service as well as on-premises systems.