小编Pro*_*dip的帖子

当使用 vnet 和防火墙保护时，无法从 Key Vault 获取机密。

我想使用 DevOps Build Pipeline 任务中存储在 Key Vault 中的秘密，我想遵循安全最佳实践和深度防御。作为安全最佳实践，我希望可以从选定的虚拟网络、选定的 azure 服务和受信任的 Internet ip 访问密钥保管库。当然，我会使用服务主体和适当的权限（列表/获取）。

不幸的是，Azure DevOps 不是值得信赖的服务之一。因此，我的替代方案是将 DevOps IP 列入白名单。我发现我的 DevOps 位于美国东部 2 区域，我下载了 Azure 数据中心 IP（使用美国东部 2 过滤）。US East 2 大约有 285 个 IP。Key Vault 防火墙对您可以添加的防火墙规则数量有限制，它是 127 个！所以，我倒霉了！

目前，只有在我允许所有网络的情况下，我才能在构建管道中从密钥保管库中获取机密！是的，我仍然需要通过身份验证才能获得秘密，但我在纵深防御上失败了。我真的需要将密钥保管库锁定到受信任的网络，但我不能。为什么？我添加的防火墙规则不能超过 127 个（覆盖该区域），而且 DevOps 不是值得信赖的 Azure 服务之一！

我正在尝试在天蓝色资源管理的上下文中找到应用程序权限的安全最佳实践。

目前，management.azure.com 仅列出了一项权限，即 management.azure.com/user_impersonation（预览版）。这种委托用户模拟可能是一个严重的问题，并可能导致恶意应用程序接管帐户。

考虑这样一个场景：具有全局管理员角色同意的用户并向应用程序授权访问令牌。应用程序可以使用该令牌并对 azure 租户执行任何它想要的操作。

另一种情况是特权用户将贡献者角色分配给多个订阅。应用程序可能会滥用该用户授权的令牌来修改任何订阅中的资源。

与图 (graph.microsoft.com) api 不同，您可以手动选择权限 (user.read)，资源管理 api 只有一个选项 - user_impersonation！

您可能会争论为什么特权用户会授权该操作，但人们会犯错误。我们的工作是通过设计来阻止或最小化此类风险。那么，允许应用程序在azure中管理资源并最大程度地降低安全风险的最佳方式是什么？

我正在尝试连接到 Azure vNET 网关，但没有成功。它以 ErrorCode = 720 ErrorSource = RAS 结束。有没有人在以下情况下遇到过这个问题？

• 配置有基本 SKU 的 Azure vNET 网关。
• VpnStrategy 是 Windows 10 的 SSTP
• 身份验证：客户端证书（自签名）
• 根证书和客户端证书都在当前用户个人存储中。他们已经解决了。
• 根证书存储在当前用户的可信根路径中
• 根证书保存在 Azure vpn 网关用户配置中，无需换行
• 不想创建其他 SKU 以在 poc 上节省 $$
• 删除了所有 WAN 微型端口适配器并重新启动了机器，但没有成功。它们会自动重新创建
• 我无法在此论坛中共享证书（root 或客户端），因为我在日志中显示了 vpn 网关端点（出于安全原因）

按执行顺序来自本地机器的事件日志：

CoId={3285D778-432A-4746-B74C-8B95FECEB53E}: The user SYSTEM has started dialing a Connection Manager connection using a per-user connection profile named az-aks-vnet-v2. The connection settings are: 
Dial-in User = P2SDemoClientCert
VpnStrategy = SSTP
DataEncryption = Require
PrerequisiteEntry = 
AutoLogon = …