We need to expose one of our Azure VMs located in a VNet to Internet. We are using F5 ADC for all inbound traffic both to on-premise and to Azure.
What is the best practice to expose an Azure VM to Internet if you have zero-trust approach in mind?
Appreciate all kinds of advice
If you are planning to expose Azure VM to the Internet considering Zero Trust strategy, you should check:
Workloads are monitored and alerted to abnormal behavior.
Every workload is assigned an app identity—and configured and deployed consistently.
Human access to resources requires Just-In-Time.
After above items are completed, check next:
Unauthorized deployments are blocked, and alert is triggered.
Granular visibility and access control are available across workloads.
User and resource access segmented for each workload.
https://learn.microsoft.com/en-us/security/zero-trust/infrastructure
https://learn.microsoft.com/en-us/security/zero-trust/
It depends what on the VM you want to expose to the Internet.
If it is a web site running on the VM you could use a web appication firewall https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/ag-overview
If it is RDP access to the VM you could use Azure Bastion
https://azure.microsoft.com/en-us/services/azure-bastion/
Related
I have an Azure Web App and an Azure SQL Server, both in the same subscription. Both of them are connected to the same VNet Subnet as shown in the below snapshots. The SQL Server is configured not to Allow Azure Resources and Services to access the server, as it should only permit access from either the connected subnet or a set of IP rules.
Unfortunately, the SQL Server is actively refusing any connection from the web app stating that the web app IP is not allowed to access the server.
The interesting thing is that I have the exact same configuration working on another subscription.
What could I be missing?
Snapshots:
1- Here you can see the web application connected to the "webapps" subnet
2- And here you can see the SQL Server connected to the same subnet
3- And that's the error I get
TLDR
The configuration is correct, but an app service restart may be required.
VNET Integration
The configuration of using a virtual network to connect a web app to a SQL database is correct: if the web app is connected to the same subnet/vnet which is allowed in the database's ACLs, and the Microsoft.Sql service endpoint is enabled on the subnet, the web app is able to communicate to the database. This is the whole reason for service endpoints: you do not need to configure with IP allowances on the database.
As to why the configuration still resulted in an error, it could be the order in which the resources were configured. We were experiencing the exact same setup and issue (which is what let me to this question)!
We connected our web app to the subnet/vnet but had not enabled the service endpoint on the subnet. We then added/allowed the subnet/vnet as an ACL in the database, during which we were prompted to enable the Microsoft.Sql service endpoint (we did). However, even after waiting ~20 minutes, we were still seeing the same connection issue.
However, once we restarted the app service, the issue went away and the web app could connect to the SQL database.
I suspect the issue is due to enabling the subnet's service endpoint after the app service was connected to the subnet. The app service must need a restart to refresh the app service's vnet config/routing.
Configuration NOT needed
Contrary to other answers, you do not need to configure firewall IP allowances nor enable access to Azure services and resources. In fact, there are downsides to both approaches:
Enabling access to Azure services and resources allows any Azure-based resource to connect to your database, which includes resources not owned by you. From doc:
This option configures the firewall to allow all connections from Azure, including connections from the subscriptions of other customers.
Unless you're using an App Service Environment (which is significantly more expensive than normal App Service plans), your web app's outbound IP addresses are neither static nor specific to your application. From doc:
Azure App Service is a multi-tenant service, except for App Service Environments. Apps that are not in an App Service environment (not in the Isolated tier) share network infrastructure with other apps. As a result, the inbound and outbound IP addresses of an app can be different, and can even change in certain situations.
The second point is further elaborated upon in this Github issue:
IPs are indeed shared with other App Service plans (including other customer's plans) that are deployed into the same shared webspace. The network resources are shared among the plans in a workspace even if the computing instances are dedicated (e.g. in Standard tier). This is inherent to the App Service multi-tenant model. The only way to have a dedicated webspace (i.e. outbound IPs) is to deploy an App Service plan into an App Service Environment (ASE) (i.e. Isolated tier). ASE is the only thing that offers true single-tenency in App Service.
So neither of the above options will truly harden your SQL database if you want to isolate communication from only your web app. If you have resources in the same subnet, using vnet integration is the correct way to solve the problem.
If resources cannot be in the same subnet, the solution is to use Private Endpoints.
Virtual networking in Azure is quite different from how it would work on premises.
I had similar problems in production environment and digging deep, the working solution (meeting security standards and create a secure connection to the database) was to create a private endpoint for SQL access in the virtual network. Then all the calls to the SQL were performed internally (it did not go on the internet), and the databases were denying all public calls.
In your case now, you deactivated the Allow Azure apps to access so when your app is trying to access the SQL the server checks the ip to find out if it is white listed or not. So fast solutions would be one of the following:
Enable Azure Web apps to access SQL
Find all outbound IPs of your web app and register them in you SQL firewall/ security settings.
If you talk about a proper production environment with security regulations I would suggest you go down the more tedious path of private endpoints.
You have to configure the outbound IPs from the app service in the sql fw.
You can find them under properties of your app service. Documentation.
The reason why is that the VNET integration doesn't give your app service an outbound IP in the VNET you configured it in, so the FW you configured doesn't work.
I have working web apps which access storage accounts and KVs. These storage accounts and KVs accept traffic from a particular subnet and the web apps have been configured to integrate with those subnets. I did face an issue where even after integration apps were not able to access these resources. What worked for me was, I changed the App service SKU from Standard to Premium and restarted the app. As you can see, it warns that "Outgoing IPs of your app might change". This is not guaranteed solution but it worked for me.. several times! Not sure about SQL server though. Private endpoint does seem like the way to go but you can give this a try.
I have a web app that is currently deployed in an App Service Environment. One of the advantages of this is the security offered by the VNet within which the ASE resides.
Unfortunately this is a very expensive option for a low traffic solution (currently costing approx. £1500 a month). Is there an alternative solution that offers the same level of security as the ASE solution, e.g. is it possible to deploy a standard Web App to a VNet?
Yes and no.
A way to do that would be to use VNet integration of a WebApp. Unfortunately, it doesn't isolate the WebApp from the internet (that can be done via the webconfig). The other problem is that it only allows the webapp to access resources inside the VNet, not vice-versa. For that you would have to allow resources to access WebApp from the internet.
No other way currently.
It is not possible to deploy an Azure web app to a VNET (allowing for 2-way communication) without using App Service Environment (ASE). If you want your web app to only be available to internal systems, you'd have to rely on IIS ipSecurity config (https://www.iis.net/configreference/system.webserver/security/ipsecurity).
Essentially, whitelist all allowed public IPs (from the systems accessing the website). This might get difficult to maintain, so you might want to investigate a reverse proxy type solution either deployed in IaaS, or use AppGateway, or use a 3rd party such as incapsula/silverline.
As it has already been mentioned, Azure Web App cannot be added to your VNET. There is a VNET integration option which allows it to act as a P2S client, however it may not be acceptable in all scenarios. Here are the alternate options:
Azure Cloud Services (PaaS)
Azure Virtual Machines (IaaS)
App Service Environment (Expensive)
I think the best option would be cloud services as it can sit inside a VNET and provide some benefits of being a PaaS based service. Refer here: https://learn.microsoft.com/en-in/azure/cloud-services/
If I create a node on Azure through the Docker Cloud Service, will the Azure vm be managed for me? For example, will I have to manage security on the VM (firewalls etc), and updates?
Every virtual machine created in Azure will be secured by Microsoft by various ways. But here it would be helpful to know what you mean by the security - some of features are enabled as a service.
There is Azure Trust Center where you can find what Microsoft does for the security.
Basic information, including some Security-Features-As-a-Service, can be found on the Azure VMs landing page.
We are having multiple web apps running on Azure using PaaS offering.
The requirement is, though all the hosted applications(web apps) are accessible all over the internet, still only a specific number of users (say IPs) will only be allowed to do FTP on the Azure cloud environment.
I need some advise on how to achieve that.
Azure offers NSG for complete isolation and full control over managing inbound / outbound traffic to the Web apps but we believe to implement NSG, we need to implement Virtual Network and ASE before that.
but then, if all the web apps resides under the VNET, then whoever will access the applications will be needing to have VNET client in their local machines.
Kindly guide me on this.
I have a azure cloud service (a server) where i host a Redis database. I also have a web site hosted in azure web sites. I want the web site to be able to talk to the Redis DB on port 6379. I know I can configure a public endpoint for that port on my server but that would open it for whole Internet. I want it opened only for azure web sites (or even better, only for my web site). How can i do this?
Windows Azure Web Sites is in an isolation bubble separate from your Cloud Services and there's no way to bridge that gap. Ideally you'd do this by connecting the web site machine to other Azure services via a Virtual Network, but this FAQ confirms you can't do that right now:
Can I use Windows Azure websites with Virtual Network?
No. We do not support websites with virtual networks.
Opening Redis up over the internet shouldn't even be considered as it doesn't have the kind of security you'd want out of the box to be opening up its port publicly as it is meant to be co-located with your application, so you really wouldn't want to do that. Never mind the added network overhead which will eat into the performance you expect to get by leveraging something like Redis anyway.
I believe your best bet given your current configuration is to add a Web Role that's part of the same Azure Cloud Service and run your web based application out of that so that it can communicate with worker role. It only requires a little bit of configuration to get this going (i.e. adding an InternalEndpoint to the Redis Worker Role). While I realize Web Roles don't offer as frictionless a development model as Web Sites, you have to choose the right tool for the job.
Another option, if you want to setup your Redis on a VM instead of tying it to the Cloud Service directly, is that you can setup a Virtual Network, put the Redis VM on the virtual network and then configure the Cloud Service so that it's part of the same affinity group and add the NetworkConfiguration/VirtualNetworkSite configuration section to the Cloud Service's .cscfg.
Which approach makes more sense all depends on how you leverage your Redis instance, but the main benefit of the latter approach is that the Redis instance is not recreated each time you deploy your Cloud Service and, so, any data that's in it will stay available between deployments. Another benefit is if you want to build and leverage a Redis cluster across multiple Cloud Services this enables you to do that.