I'm trying to understand whether the Azure API Management suite includes any WAF functionality (as described by OWASP for example) within its Security or Policy settings.
If "no" or "don't" know does it make sense to front public-facing APIs (that handle PII), exposed via the Azure API Management with a Web Application Firewall (WAF), or anywhere else in the Cloud -> APIM -> VPN -> Firewall -> On-Premise services topology?
Thanks in advance
Based on this list of WAF capabilities, API Management can do some of these things out of the box, many could be implemented using custom policies and some of these things cannot be done. Policies can manipulate HTTP requests and responses. However they cannot function at a level lower than this.
There is no built-in functions to try and prevent injection attacks, but it is possible to build them. It is also a reasonable option to deploy a dedicated WAF between API Management gateway and your APIs.
You can make your API Management Service private inside a subnet and put App Gateway with WAF in front of it. The tricky part is that this is available only in the Premium plan for API Management.
However, since ultimately you want to protect your application not the APIMS from attacks like SQL injection, you can put AppGateway+WAF between APIMS and your application. At the same time AppGateway will be your Load Balancer.
SSL and end-to-end encryption will need some attention.
Its best to have a separate WAF module on top of your APIMS.
APIMS <-> WAF <-> LB
API abusing is trending these days .I think WAF protection inbuilt to many cloud providers are basically in its infantry stage . Better to use some dedicated WAF modules
Related
I currently have the following setup in Azure:
An Azure API Management API that maps to
an Azure Function App with multiple functions that accept data and store it in
an Azure Storage Account.
A private (no public access) Azure SQL database.
Now I want to add a few more API endpoints and Azure functions that provide access to some data from the SQL database. I am now facing the problem that my Function App and API Management are public and therefore cannot connect to resources within my VNet (i.e. the database).
Is there a way to have functions connect to the private database without making the functions private, too? And if I have to make the functions private I would also have to make the API Management private, right? Which would make the whole API unavailable from the internet.
The plans for API Management and Function App that support VNet integration are way more powerful and expensive. I don't need so much power, just the VNet integration.
Does anyone know how to solve this issue?
Before deploying APIM myself, I did some research on how to create a similar setup, where most of our backend services (azure functions, app services etc.) live inside a virtual network. Note that we are still using the developer SKU for API Management, it has almost the same features as the premium SKU (source). For our use case, developer tier has enough bandwidth and the premium SKU is pretty darn expensive. The developer tier is not backed by a Microsoft SLA, so be careful using this in production environments. Below, I'll start with a short summary and describe the scenario's at the end.
Summary
I hope this overview highlights some of our concerns, which may help you to decide the best fit for your scenario. In the end, we choose scenario two, which provides the necessary security we needed. It reduces the attack surface because all backends are private. The main reason is that we wanted to use consumption plan logic apps. Standard logic apps are expensive and not really user-friendly in terms of deployment. With an additional Front Door in place, it also enables us to easily move to solution three at a later point in time. Since you don’t have to move around with custom domains and certificates when putting APIM private, Front Door still remains your main entry point.
1) Scenario one
APIM without vnet integration (public)
Azure Function with Vnet integration
Azure SQL and Storage with private endpoints
Pros: In this scenario your are able to choose APIM standard or basic sku. These are a lot cheaper than the premium sku.
Cons: The Azure function is exposed to the public internet, so be careful and protect it with AAD authentication. When you would deploy multiple azure functions like this, it increases the attack surface.
2) Scenario two
APIM with vnet integration (external mode)
Azure Function with private endpoint
Azure SQL and Storage with private endpoints
Pros: Setup is not that difficult if you follow the APIM vnet documentation (source). May be useful if you want to expose your APIs to external parties as well. Everything behind APIM resides securly within a virtual network.
Cons: Only developer and premium tiers are available for this setup. APIM is reachable over the public internet, so make sure you put in the necessary policies that always checks the JWT. You could even put in a policy that check's the IP address, basically a poor man's firewall solution.
1) Scenario three
APIM with vnet integration (internal mode)
Azure function with private endpoint
Azure SQL and Storage with private endpoints
Optional: Application gateway with or without Front Door to safely expose certain routes to the outside world.
Pros: Most secure solution, since everything is shielded from the public internet. I would call this the preferred enterprise setup. If needed, you could even extend this setup with an application gateway with or without Front Door to control who has access to certain API’s from outside the virtual network.
Cons: This is the most extensive setup, meaning that it takes a lot more time to deploy. You have to take into account all the necessary routes, NSGs, private DNS entries, etc. Advisable to be familiar with azure policies as well to do some of this automatically.
Note: APIM is going to support private endpoints as well in the near future, which is a bit confusing. I would say the two vnet modes are already comparable to how you would use vnet integration and private endpoints for azure functions and app services.
You can achieve this with a VPN Gateway
This means the VPN Gateway provides a public IP to your VPN!
So the public Azure Functions can access the VPN resources.
Tutorial: Create and manage a VPN gateway using the Azure portal
A better approach is, to use the internal mode of API Management:
Connect to a virtual network in internal mode using Azure API Management
With Azure virtual networks (VNets), Azure API Management can manage internet-inaccessible APIs using several VPN technologies to make the connection. For VNet connectivity options, requirements, and considerations, see Using a virtual network with Azure API Management.
I understand that Azure Web Apps as a PaaS offering are inherently more secure than if hosting on your own VM ... but does that mean a firewall solution is not required at all?
Azure offers a few solutions, but anything acting as a firewall seems expensive - so we are wondering if we can just do without one.
Not required as long as you are secured login for sensitive data and enabled CORN rules. For other protections you can definitely add to your subscription like firewall and DDoS protection.
It is not required; however, depending on the type of application you are building it is greatly encouraged, if not required by specific industries.
Depending on your architecture and/or approach and if cost is a concern I'd recommend Azure FrontDoor w/ Web Application Firewall (WAF) enabled. This will cover additional security for your application at a reasonable cost as well as potentially server as a Traffic/Manager Load balancer.
We are looking at using webhooks from various vendors outside our network. They would publish the event to us. We would be the webhook listener/receiver, not pushing the events. We have done proof of concept of creating an Azure Function to receive the event. From the research we have done most have the security of passing a sha1/sha256/sha512 hash for us to verify they are who we want to receive the events. This all worked as expected with the POC Azure Function.
From a enterprise network security standpoint is there anything else available? The process above puts the security in the function. I'm sure our Network Security group would not want us to have 10 functions, one for each vendor to worry about the security. I've read about whitelisting of IP's that would be sending the events but most of our vendors are Cloud based so I'm not sure how readily that would be available. Maybe one function to validate all events that come in then let pass through? Would that be an acceptable solution? Azure API Gateway or API Management able to address somehow? Any other network type of product that handles webhook security specifically?
Any insight or link to information most appreciated.
Thanks.
Wow, that's really really so open conversation.
You can use Azure Front Door with the Web Application Firewall attached to it. So any SQL injection, DDoS or similar attacks can be prevented by AFD and WAF.
However, I would say the securest way is to put IP restriction as well. So you need to force your vendor to get their IP address. That can be multiple maybe hundreds. But that doesn't matter. You can implement CIDR IP address format so you can cover all network. And you can easily set these IP address restriction during the CI/CD pipeline with Azure PowerShell script.
You can also useAPI Management in front of Azure Functions and you can create access restriction policies. You can either restrict IP based or JWT based. APIM might be a little bit pricey tho.
https://learn.microsoft.com/en-us/azure/api-management/api-management-access-restriction-policies
You can also create advanced policies with APIM
https://learn.microsoft.com/en-us/azure/api-management/api-management-advanced-policies
Apart from that, the AFD & WAF and IP restriction are on the network layer. But you can also implement token-based authentication on your code side.
https://learn.microsoft.com/en-us/azure/app-service/overview-authentication-authorization
You can either you Azure Active Directory, IdentityServer or JWT for this.
Good luck!
I have domain example.com I bought in azure.And I have two appservices app1 and app2.
I can link example.com to app1
But I want to link example.com/one to app1(appservices)
and example.com/two to app2(appservices).
Can anyone plz suugest me how to do this in Microsoft Azure
Using Azure Application Gateway and creating the relevant routing rules would be a good way to do this.
Here's a quick screenshot from Microsoft Docs which talks about a similar scenario..
Do know that there is price associated with it (and a lot of other features). So you may need to evaluate a bit.
Application Gateway Pricing
You will need to assign the custom domain to a load balancer. Azure App Gateway supports URL based routing. Since Azure App Services are multi-tenant you will need to follow these docs to configure App Gateway with an App Server. This is a great solution for single region applications.
If you need mutli-region support, check out our new Azure Front Door Service. Azure Front Door Service enables you to define, manage, and monitor the global routing for your web traffic by optimizing for best performance and instant global failover for high availability. With Front Door, you can transform your global (multi-region) consumer and enterprise applications into robust, high-performance personalized modern applications, APIs, and content that reach a global audience with Azure.
We need to develop integration between ERP (Dynamics Nav) and cloud-based telephony provider.
The provider needs to have an endpoint published and accessible from internet but for security reasons it is not possible for us to allow inbound connections to our network. I think it should be possible to solve this by hosting small application in Azure which will serve as endpoint for telephony provider and to which ERP will connect as outbound persistent connection. The app will just forward requests to ERP.
Since I'm new to Azure the question is what of azure capabilities I could use to solve the task aside from hosting actual VM with application there?
I've just implemented the same using Azure Service Bus.
The VOIP system is putting a small JSON with call details after the end of the call and I'll get the messages from the Service Bus Queue from NAV.
The code is not complicated at all the whole solution is simple and cheap!
Let me know if you want to know more (= you need the code).
Cheers!
Azure AD has the concept of an "application proxy" that will open internal applications up using a connector that runs on prem. This doesn't require inbound ports and is protected by Azure AD authentication.
It's intended more as a user-facing way to get access to Legacy applications, although I don't see why it couldn't be used for integration as well.
https://learn.microsoft.com/en-us/azure/active-directory/application-proxy-publish-azure-portal
Otherwise, you could link an Azure Site to Site VPN up and use a service like API gateway to manage connections though this is more complicated.