【OpenAI 架构】Azure OpenAI服务中的“基础设施/安全内容”

过去的几个月非常繁忙。我的客户数量增加了一倍，那些因假期而进入休眠状态的客户决定全力醒来。伴随着这种新的需求，出现了有趣的新用例和博客主题。

除非你一直生活在岩石下，否则你很清楚人工智能领域的大量创新和技术发展。似乎每天都有10篇关于OpenAI模型的文章（最近在ChatGPT上有一集搞笑的《南方公园》）。微软决定直接深入研究，并与OpenAI建立了合作伙伴关系。从这种合作关系中产生了Azure OpenAI服务，该服务在Azure基础设施上运行像ChatGPT这样的OpenAI模型。正如你所能想象的，这项服务对新的和现有的Azure客户都有很大的吸引力。

考虑到我在自己的客户中看到的需求，我决定看看服务中可用的安全控制（或我的一位数据同行所说的基础设施/安全）。在加入该服务之前，我使用兼职拉里的这篇精彩教程对OpenAI自己的服务进行了一些基本的实验。我发现他对一些示例代码的逐步演练在理解与服务交互的简单性方面非常出色。

在对如何与OpenAI的API交互有了非常基本的理解（我确实强调了基本的理解）之后，我决定了一个用例。我决定的用例是使用总结功能he davinci GPT-3模型来总结NIST关于零信任的文件。我感兴趣的是，它将从文档中提取哪些关键点，以及在完全阅读文档后，这些关键点是否与我从文档中得出的内容一致（重读文档仍在我的待办事项列表中！）。

在我能做任何很酷的事情之前，我必须加入这项服务。此时，客户必须使用Microsoft公共文档中描述的流程请求将其订阅加入该服务。在等待订阅时，我阅读了公共文档，重点是“基础设施/安全”方面的内容。与Azure中的大多数数据服务一样，客户可以绕过网络、静态加密和身份等安全控制的杠杆信息级别非常高，用处不大。很多人提到了单词，但没有真正解释这些功能在服务中启用时会“看起来”。还有一个问题是微软如何处理和保护数据，即服务的客户数据。

与所有云提供商一样，微软在共享责任模式下运营，即微软负责云的安全，而您（客户）则负责云内的安全。简单地说，微软在幕后管理着一些控制措施，微软把这些控制措施交给了客户，而客户有责任启用这些控制措施。微软在公开文档中描述了如何为Azure OpenAI服务处理和保护数据。客户还应查看Microsoft产品和服务数据保护附录以及特定的产品条款。另一个值得查看的资源是Microsoft Services Trust Portal中的文档。在信任门户中，您可以找到所有与合规性相关的文档，如SOC-2 Type II，它将提供有关Microsoft用于保护数据的流程和控制的详细信息。为了更深入地了解，您可以查看FedRAMP SSP（系统安全计划）。我通常会发现自己先浏览SOC2，然后经常通过阅读FedRAMP SSP中的相关章节来深入了解。我将让您通读并使用上面的文档（您应该为您使用的每一项服务都这样做）。出于这篇博客文章的目的，我将研究“云中的安全”。

我非常喜欢退一步，从高层架构的角度来看待事物。在阅读了文档之后，我设想以下Azure组件是受监管行业内任何服务实现所需的关键组件。

Azure OpenAI Azure组件

让我们浏览一下这些组件中的每一个。

第一个组件是Azure OpenAI服务实例，它是认知服务保护伞下的服务。Azure认知服务包括语音转文本、图像分析等现有服务。这是微软的一个好主意，因为它将允许管理Azure OpenAI服务的产品组（PG）利用认知服务保护伞下其他服务已经采用的现有架构标准。

下一个组件是Azure密钥保管库实例。在Azure OpenAI服务的实例中，有三种类型的数据可以存储在客户的服务实例中。我说可以，因为只有当您选择使用服务的特定功能和功能时，才会存储这些数据。这些数据包括您可能为微调模型提供的训练数据、微调模型本身以及提示和完成。只有当您选择训练自己的微调模型时，才会存储训练数据，并且训练数据可以在您完成微调模型的训练后立即删除。从与我聪明得多的同行交谈来看，需要创建微调模型的客户比例非常低。我听说只有1%的客户需要这样做，因为所包含的模型已经得到了非常有效的培训。提示和完成默认情况下存储30天，以供人工评估，以确保模型以不适当的方式使用。客户可以选择不使用本公开文档中概述的流程进行内容筛选。如果他们选择退出，这些数据将永远不会被存储。

如果客户选择使用创建此数据的功能，则当数据存储在Microsoft管理的边界内时，默认情况下会使用Microsoft管理的密钥对其进行静态加密。这意味着Microsoft管理密钥的授权和轮换。许多受监管的客户都有监管要求或内部策略，要求客户管理用于加密其环境中数据的任何密钥的授权和轮换。因此，微软等云提供商提供了使用CMK（客户托管密钥）的选项。在Azure中，这些CMK存储在客户订阅中的Azure密钥库实例中，客户控制对密钥的授权和访问。

Azure OpenAI服务支持使用CMK来保护其中三组数据中的至少两组。该文档不清楚是否可以使用CMK对提示和完成进行加密。如果你碰巧知道，请在评论中告诉我。请注意，目前您需要请求访问权限，才能通过Azure OpenAI服务批准您的CMK订阅。

接下来我们有虚拟网络、专用端点和Azure专用DNS。与认知服务保护伞中的其他服务一样，OpenAI服务支持私人端点，以此锁定对私人IP空间的网络访问。该服务的DNS命名空间为privatelink.openai.azure.com。最佳做法是让您在azure Private DNS中托管此区域，稍后我将在共享示例架构时看到。值得注意的是，Azure Open AI服务也支持我所说的服务防火墙。这允许您通过服务端点将对服务的访问限制在特定的一组公共IP（如企业的转发web代理）或特定的虚拟网络。

接下来，我们有Azure存储。如果您选择构建微调模型，则可以将培训数据上传到客户订阅内的Azure存储帐户。然后，客户的Azure OpenAI服务实例可以使用我稍后将在本文中解释的方法检索数据。

然后我们有了管理身份和Azure RBAC。对于该服务，托管身份用于访问存储在客户密钥库实例中的CMK。Azure RBAC将用于控制对Azure OpenAI Services实例的访问，以及用于调用服务API的密钥。回过头来看上面的组件，以及它们是如何组合在一起以提供跨身份、网络、加密和加密的安全控制的，我看到的如下所示。

对于运行模型的Azure OpenAI服务实例，您可以使用Azure RBAC锁定该服务。通过一组API密钥支持对服务的身份验证，您需要管理的轮换。或者，（我自己还没有测试过），您可以使用Azure AD身份验证来获得承载令牌，以对服务进行身份验证。通过使用专用端点限制对服务的访问，可以确保网络访问的安全。数据可选择使用存储在客户管理的密钥库实例中的CMK进行加密，以使客户能够控制对密钥的访问、轮换密钥以及审核这些密钥的使用情况。Azure OpenAI服务还提供日志和指标，这些日志和指标可以通过实例上配置的诊断设置传递到Azure存储、日志分析工作区或事件中心。您感兴趣的特定于安全性的日志是审核日志，可能还有提示日志和完成日志。

当客户选择使用CMK时使用的Azure密钥库实例可以访问使用Azure RBAC（当使用为Azure RBAC保险库策略启用的密钥库实例时）和托管身份控制的密钥。Azure OpenAI服务实例将使用分配给该服务的托管身份访问CMK。请注意，从今天起，您不能使用密钥保管库服务防火墙来限制网络访问。Azure认知服务不被视为密钥保管库的受信任Azure服务，因此在启用服务防火墙时不能允许网络访问。

如果客户选择在上传到服务之前将培训数据存储在Azure存储帐户中，则可以使用Azure RBAC或SAS令牌保护该帐户以供用户访问。由于SAS令牌对人类来说是一场噩梦，因此您需要使用Azure RBAC控制人类对数据的访问。Azure OpenAI服务本身目前不支持使用托管身份访问Azure存储。这意味着您需要使用SAS令牌来保护数据的安全，以便在上传过程中进行数据的非人工访问。由于Azure OpenAI服务还不支持访问Azure存储的托管身份，因此无法利用服务实例授权规则。在我的测试中，只允许Azure存储的可信服务似乎也不起作用。这意味着您需要允许所有公共网络访问存储帐户。您保护数据的手段将是SAS令牌，主要用于来自Azure OpenAI服务的访问。不太理想，但是嘿，服务很新。

那么，把我们所学到的一切放在一起，在架构上会是什么样子呢？

Azure OpenAI服务示例架构

以上是采用Azure VWAN的受监管组织中常见的架构示例。在这种模式中，所有与部署相关的服务实例都将被放置在一个专用的工作负载订阅中，如橙色轮廓所示。这包括包含Azure OpenAI服务私有端点的虚拟网络、Azure OpenAI Service实例、由Azure OpenAI Services实例使用的用户分配的托管身份、包含用于加密Azure OpenAI Service持有的数据的CMK的工作负载密钥库，以及用于暂存要上载到服务的训练数据的Azure存储帐户。

Azure OpenAI服务将确保其对专用端点的网络访问安全。Azure密钥保管库实例和存储帐户的网络访问都将对公共网络开放。对Azure密钥保管库数据的访问将通过Azure AD身份验证和Azure RBAC保管库策略进行授权。Azure存储帐户将使用Azure AD身份验证和Azure RBAC来控制人类用户的访问，并使用SAS令牌来控制来自Azure OpenAI服务实例的访问。

最后，尽管没有在图片中列出，但毫无疑问，应该制定Azure策略，以确保所有资源的外观与您和您的安全团队决定的资源外观一致。

随着该服务的发展和成熟，我希望通过支持访问存储帐户的托管身份以及将该服务添加到Azure Key Vault的可信服务中，来解决网络控制方面的一些差距。我也不会惊讶地看到一些类型的VNet注入或VNet集成将被引入，类似于Azure机器学习中的可用内容。

好吧，伙计们，我希望这能帮助你们基础设施和安全人员完成当天的“基础设施/安全工作”，现在你们可以更好地了解一些可以用来保护服务的杠杆和开关。随着我对服务和人工智能总体学习的进展，我计划添加一些帖子，这些帖子将深入了解该架构在实施时的外观。我让它在我的演示环境中运行，但现在时间非常有限。

谢谢各位，我希望你们的人工智能之旅和我的一样有趣！

查看我在此服务上的其他帖子：

• Authentication in the Azure OpenAI Service
• Authorization in the Azure OpenAI Service
• Logging in the Azure OpenAI Service