How to secure APIM protected Azure Functions so that they will only respond to a request from an Azure Web App in same resource group?

huangapple go评论67阅读模式
英文:

How to secure APIM protected Azure Functions so that they will only respond to a request from an Azure Web App in same resource group?

问题

我有一个托管在Azure上的Web应用(MVC/C#/ .Net Core 3.1)。

将添加两个新的Azure函数,由HTTP触发,并受APIM保护,这些函数将添加到与Web应用相同的父资源组,以便从中获取数据。

如何使Azure函数只响应应用程序发出的GET请求?是否有一种方式可以实现“如果发出请求的服务器不是Azure box 123-South或123-West,则返回HTTP 403”的功能,或者如果添加了更多函数,是否有更好的扩展方式?

另外,是否有一种方法可以在Azure函数中使用代码检查HTTP标头?

我们以前的Web API,这些函数的前身,托管在“on prem”上。它检查HTTP请求的标头,查找特定的base-64编码标头。如果找到,将解码标头的值并检查其正确性。这是否仍然是Azure的有效方法?

注意:我们的Web应用要求用户通过Microsoft或任何其他身份提供者进行登录。我们的用户是一般公众,不属于我们的域。

英文:

I have a webapp hosted on Azure (MVC/C#/ .Net Core 3.1).

Two new Azure functions, triggered by HTTP and protected by APIM, will be added to the same parent resource group for the webapp to GET data from.

How can I make it such that the Azure functions only respond to GET requests issued by the app? Is there a way of implementing "if originating server is neither Azure box 123-South nor 123-West, return HTTP 403" - or something that might scale better if more functions are added?

Alternatively, is there a way of inspecting HTTP headers in the Azure functions with code?

Our previous Web API, the functions' predecessor, was hosted "on prem". It inspected the headers of the HTTP request looking for a specific base-64 encoded header. If found, the header's value was decoded and checked for correctness. Is it still a valid approach for Azure?

Note: our web app does not require users to login via Microsoft or any other identity provider. Our users are the general public and not part of our domain.

答案1

得分: 1

I assume your Azure Functions are already secured from direct calls except from APIM by using IP Restrictions or other means, but just wanted to put this out for others coming across this.

There are a few options for you to consider based on your scenario

1. Use Client Certificate Authentication
This would require your Web App to set the client certificate in its requests to APIM.

2. Use Azure AD Auth
Since your clients don't have a token to pass, this could be acceptable in your case. Here your Web App would get a token, using Managed Identity or Client Credentials, and pass that along in its requests to APIM.

3. Set a Custom Header
This might be the least secure but simplest to implement. You would just add a header in your requests from your Web App, and APIM would validate that value using policies.

Note that if this is a static value, and your customers somehow get a hold of it, they could then make the calls to APIM directly. Making it dynamic would increase complexity of this option, at which point it might be better to go with #1 or #2.

英文:

I assume your Azure Functions are already secured from direct calls except from APIM by using IP Restrictions or other means, but just wanted to put this out for others coming across this.

There are a few options for you to consider based on your scenario

1. Use Client Certificate Authentication
This would require your Web App to set the client certificate in its requests to APIM.

2. Use Azure AD Auth
Since your clients don't have a token to pass, this could be acceptable in your case. Here your Web App would get a token, using Managed Identity or Client Credentials, and pass that along in its requests to APIM.

3. Set a Custom Header
This might be the least secure but simplest to implement. You would just add a header in your requests from your Web App and APIM would validate that value using policies.

Note that if this is a static value, and your customers somehow get a hold of it, they could then make the calls to APIM directly. Making it dynamic would increase complexity of this option, at which point it might be better to go with #1 or #2.

huangapple
  • 本文由 发表于 2023年3月7日 00:51:20
  • 转载请务必保留本文链接:https://go.coder-hub.com/75653606.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定