在计算机客户端可以从 KeyVault 读取之前，它必须在 Azure 中注册为应用程序。然后直接在目标计算机上生成自签名证书。它由公钥和私钥组成。现在，公众将导出到文件并上传到 Azure 门户的“证书和机密”下。
通过本地安装的证书，注册的应用程序可以登录 Azure，但尚无法访问 KeyVault。为此，必须为应用程序分配预定义角色“Key Vault Reader”。然后，她准备从 KeyVault 检索计算机服务器的密码。
该图显示了数据流。任何计算机上的客户端应用程序首先选择用于登录 Azure 的已安装证书。然后，Azure 选择访问 KeyVault。从那里，应用程序读取密码并使用它登录到机器。
在 .NET 中，更加透明。 KeyVault 只是在启动时注册为附加配置源。之后，所有秘密都可以像在设置中打开一样使用。
微软入口
如果涉及的所有服务都在 Azure 云中运行，则应使用托管身份。任何应用程序都不需要证书或其他秘密。 Azure 在内部管理身份并自动向所有服务分配预期权限。
托管身份可以由用户或系统分配。用户端身份涵盖了多个资源需要共享身份的特殊情况。 Azure 只为一种资源生成系统端标识。在示例中，我们的计算机客户端将是 Azure 资源，因此在 Azure 中具有一个身份，无需任何进一步操作即可将角色分配给该身份。
在内网上
在这个项目中，Azure 概念由于总体安全概念而失败。不允许机器的控制服务器访问 Internet。也不允许使用到 Azure 的 VPN 路由。同样，我们的客户端应该运行的计算机仅限于安全关键的公司网络。这是非常谨慎的，在这种情况下也是完全合理的。然而，它与仅将机密存储在 KeyVault 中的要求相冲突。
更糟糕的是，客户端必须从同一网络中的配置服务器获 贝宁 whatsapp 数据 取其设置。访问数据将在那里公开可见。所以它们必须被加密。问题再次陷入循环，配置的关键必须在某个地方。
最后，我们在计算机上安装了自签名证书。证书是非对称加密的密钥对。它包含一个私钥，用于解密并永久保留在计算机上；以及一个公钥，专门用于加密，可以存储在配置工具中。从机器制造商处收到的控制服务器密码在上传到配置服务器之前经过非对称安全加密，并且仅在必要时、即在登录之前由客户端程序解密。
前景
尽管云解决方案可能很实用，但总会存在无法使用它们的边缘情况。那么手头有一些不依赖于云提供商的标准解决方案是件好事。
但是，如果 Azure 可用，则最好将所有使用 Azure 资源的程序直接托管在 Azure 中。因为这样所有授权都可以通过托管身份进行管理，关键问题就完全消除了。
在当今的大多数项目中，您自己的资源和云服务的混合操作可能很常见。客户端证书的安全原则是最好的桥梁。
您想了解更多关于 adesso 世界中令人兴奋的话题吗？那么请看一下我们之前发布的博客文章。
图像科琳娜·约翰
作者 科琳娜·约翰
Corinna John 是汉诺威 adesso 的高级软件工程师。她的重点是 C# 开发。
类别： 方法论
标签： 微软Azure 身份验证
阿斯达夫
我们的博客文章一览
在我们的技术博客中，我们将带您踏上令人兴奋的 adesso 世界之旅。您可以在我们之前的博客文章中找到其他有趣的主题。
至所有博客文章
阿斯达夫
我们的 adesso 博客时事通讯
您想定期收到我们的 adesso 博客更新吗？然后只需订阅我们的时事通讯，您将通过电子邮件方便地收到我们技术博客的最新文章。