We have created mutiple API Apps for our application. However these API Apps are connected to the internet so we need to protect them. We have chosen for an API Key, but we would like to have the API disconnected from the Internet, such that only our own applications can access them. Is there a way to disconnect them from internet access?
Each API App is automatically connected to the Internet and this can not be disabled. If you want to have an isolated environment you will have to create an App Service Environment. This will create an environment for with mutiple zone that can contain mutiple App Service Providers. It also create a virtual network that protect the resources in the ASE. You can configure the virtual network using access rules to only allow a certain IP address or none at all.
For more information about Azure Service Environment see: https://azure.microsoft.com/en-us/documentation/articles/app-service-app-service-environment-intro/
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.
We have an App Service running in Azure that hosts a website. We've recently had a security review on the web site and one of the items found was that the end point below was exposed.
https://<appName>.azurewebsites.net:8172/msdeploy.axd
The recommendation is that this end point should be blocked and using a whitelist to allow limited access (e.g. the build machine that deploys to Azure). How do I block this end point?
After discussions with Microsoft support it appears that port 8172 is enabled for backwards compatibility with old versions of MsDeploy. This port is being phased out and will be open sometimes and not other times.
The fix was for us to create a new resource group, app service plan and app services multiple times until we ended up a server that had the port closed. This was frustrating but ultimately it did resolve the issue.
You could use IP level limitation in the Azure App Service access restrictions to allow limited IP addresses or VNet access to your app service. In this case, it will work on all the applications in your app service.
For some specific endpoint access control, perhaps, you need to control it with access authorization in your application code. Read Tutorial: Authenticate and authorize users end-to-end in Azure App Service and Managing access to apps.
Alternatively, you select to use Application Gateway integration with service endpoints. In this case, you only want the front end to be accessible to your end-users. The back-end should be locked down so it is only callable from the front-end. Also the front end subnet support NSG, you could restrict the end-users with IP and port to access your front end, meanwhile, it will limit access to your endpoint. See Securing Back-end App Service Web Apps with VNets and Service Endpoints for more details.
Hope this helps you.
I have a .NET Web Api project with several REST endpoints that I only want accessed by resources from within an Azure virtual network I have created. Resources such as Azure Functions and Azure Web Roles will access these endpoints only. In other words, I do not want the endpoints publicly available.
So, I configured the Web Api application with my virtual network but apparently I also need to add the Web Api application to an Application Service Environment (which are quite costly from what I have read). To quote the Azure documentation:
VNET Integration gives your web app access to resources in your virtual network but does not grant private access to your web app from the virtual network.
Do I indeed need to use an Application Service Environment and just deal with the costs or is there another way I can achieve what I want?
I do not want the endpoints publicly available.
Until now, Azure web app only supports for using an internal load balancer with the app service environment feature. If you want to make your Web API can only be accessed internally. An app service environment is required.
If you don't want to move your Web API to app service environment and your Azure function and web role have fixed ip addresses, you could configure the IP whitelist using ipSecurity configuration in your web API. For more information of ipSecurity, link below is for your reference.
IP and Domain Restrictions for Windows Azure Web Sites
I work in a small startup that is only hosted in Azure and I was wondering the best way to secure everything.
I use the below services
Web Apps (public facing)
Virtual machines - Running apps and services
Sql Sever
Service Bus
Storage Account.
The web apps and the Vms need to communicate with the other three services.
Below is what we are currently doing. Is this correct and if not can you provide any resources to work from?
Service bus - This is currently accessed using the connection string and is stored in the app settings of the web app and VM.
Storage Account - This is currently accessed using the connection string and is stored in the app settings of the web app and VM.
Sql server - This is currently using the firewall to Allow access to Azure Services plus restricting it to client machines that need to access the DB's through SSMS
VM - this is restricted using Network Security Groups to only allow client machines to RDP on.
I would appreciate any help that can be provided.
Edit
Things that i am worried about are:
Sql Server allow access to azure. I can turn this off but then the website will need to be added to the firewall and as i understand it the ip address is not static. Is it a security concern to leave this on?
Storage accounts, the connection string allows unlimited access to the account. You can lock this down with SAS to ip addresses but it has the same issues as the sqlsvr when connecting from the website. Also the SAS is time based how is it renewed?
Sql Server allow access to azure. I can turn this off but then the website will need to be added to the firewall and as i understand it the ip address is not static. Is it a security concern to leave this on?
By default, “Allow access to Azure services” is turned on, enabling this feature would allow any traffic from resources/services hosted in Azure to access the database.
Storage accounts, the connection string allows unlimited access to the account. You can lock this down with SAS to ip addresses but it has the same issues as the sqlsvr when connecting from the website. Also the SAS is time based how is it renewed?
A shared access signature can take one of two forms: Ad hoc SAS and SAS with stored access policy. We could re-specify the start time, expiry time, and permissions to get a new ad hoc SAS. When we associate a SAS with a stored access policy, the SAS inherits the constraints - the start time, expiry time, and permissions - defined for the stored access policy, we could modify the stored access policy to revoke the SAS or get a new SAS based on new stored access policy.
For more information about Shared Access Signatures (SAS), you could read this article.
Regarding access to the SQL server from your web apps:
They are using up to four outbound IP addresses when connecting to external services. You could limit the SQL server access to those.
Read this article to find them.
That won't completely close down foreign access to the SQL server, other people's web apps are using the same four outbound IP addresses.
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.