我目前在Azure中具有以下设置：
- Azure API管理API，该API映射到
- 具有多个功能的Azure函数应用程序，可以接受数据并将其存储在
- Azure存储帐户中。
- 私有（无公共访问）Azure SQL数据库。
现在，我想添加更多的API端点和Azure函数，这些函数可从SQL数据库中访问某些数据。我现在面临的问题是我的功能应用程序和API管理是公开的，因此无法连接到VNET（即数据库）中的资源。
是否有一种方法可以使函数连接到私人数据库，而无需使功能私有？而且，如果我必须将功能私有化，我还必须将API管理私有化，对吗？这将使整个API无法从互联网上获得。
支持VNET集成的API管理和功能应用程序的计划更强大和昂贵。我不需要太多的功能，只是VNET集成。
有人知道如何解决这个问题吗？
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?
发布评论
评论（2）
在我自己部署APIM之前，我对如何创建类似设置进行了一些研究，我们的大多数后端服务（Azure功能，应用程序服务等）都生活在虚拟网络中。请注意，我们仍在使用开发人员SKU进行API管理，它的功能几乎与Premium SKU相同（ source ）。对于我们的用例，开发人员Tier具有足够的带宽，而Premium Sku非常昂贵。开发人员层不受Microsoft SLA的支持，因此请在生产环境中谨慎使用。下面，我将从简短的摘要开始，并在最后描述场景。
摘要
希望此概述重点介绍我们的一些问题，这可能有助于您决定最适合自己的方案。最后，我们选择方案二，它提供了我们需要的必要安全性。它降低了攻击表面，因为所有后端都是私人的。主要原因是我们想使用消费计划逻辑应用程序。标准逻辑应用程序很昂贵，而且在部署方面并不是真正的用户友好型。有了额外的前门，它还使我们能够在以后的时间点轻松地移动到三个解决方案。由于将APIM Private放置时，您不必随身携带自定义域和证书，因此前门仍然是您的主要入口处。
1）方案一个
存储基本的sku。这些比优质SKU便宜得多。
cons： Azure功能暴露于公共Internet，因此请小心并通过AAD身份验证进行保护。当您将多个Azure函数部署时，它会增加攻击表面。
2）方案两个
PROS：设置如果您遵循APIM，则不那么困难vnet文档（）。如果您也想将API公开到外部各方，可能会很有用。 APIM背后的所有内容都固定在虚拟网络中。
cons：仅用于此设置的开发人员和高级层。 APIM可以通过公共互联网达到，因此请确保您制定了始终检查JWT的必要政策。您甚至可以投入一项检查IP地址的政策，基本上是一个穷人的防火墙解决方案。
1）方案三个
PROS：最安全的解决方案，因为一切都与公共互联网相保护。我将其称为首选企业设置。如果需要的话，您甚至可以使用或没有前门的应用程序网关扩展此设置，以控制谁可以从虚拟网络外部访问某些API。
cons：这是最广泛的设置，这意味着部署需要更多的时间。您必须考虑所有必要的路线，NSG，私人DNS条目等。建议熟悉Azure策略，也可以自动执行其中的某些操作。
注意：APIM将在不久的将来支持私人端点，这有点令人困惑。我要说的是，这两种VNET模式已经与您将VNET集成和私有端点用于Azure功能和应用程序服务相媲美。
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
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
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
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.
您可以使用a
这意味着VPN网关为您的VPN提供了公共IP！
因此，公共Azure功能可以访问VPN资源。
一种更好的方法是，使用API管理的内部模式：
使用Azure API管理的内部模式的虚拟网络
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