请注册以接收此页面的任何变更通知。如果发生变更，您将收到一封电子邮件，地址为您提供的地址。
最后更新：2022年8月31日。要查看变更内容，请点击此处。
以下技术与组织安全措施（“安全措施”）纳入并构成您与MongoDB之间关于使用MongoDB Atlas（“协议”）的适用协议的一部分。这些安全措施也适用于MongoDB Atlas for Government，由协议的MongoDB Atlas for Government附加协议修改。
安全措施规定了适用于MongoDB Atlas的安全功能、流程和控制，包括客户可配置的选项，这些选项采用行业标准的信息安全最佳实践。
1. 定义
在安全措施中使用以下术语时具有以下含义。未在安全措施中定义的大写术语具有协议中的含义。
1.1. "云服务提供商"是指客户选择的亚马逊网络服务（AWS）、微软Azure（Azure）或谷歌云平台（GCP）。
1.2. "客户数据"是指您或您的最终用户上传到MongoDB Atlas的任何数据。
1.3. "数据泄露"是指导致客户数据意外或非法破坏、丢失、更改、未经授权披露或访问的安全事件。
1.4. "信息安全计划"是指MongoDB的书面安全计划、政策和程序，规定了旨在保护客户数据的行政、技术和物理安全措施。
1.5. "MongoDB Atlas集群"是指运行MongoDB数据库软件的每个数据承载节点副本集或分片集群，由MongoDB Atlas管理，并根据您选择的配置。
1.6. "MongoDB Atlas项目"是指具有共享授权和网络配置的一个或多个相关的MongoDB Atlas集群。
1.7. "MongoDB系统"是指MongoDB的内部基础设施，包括MongoDB Atlas的开发、测试和生产环境。
1.8. "特权用户"是指被授予独特权限以访问客户数据或MongoDB系统（以执行其工作职能所需）的精选MongoDB员工或第三方承包商。
1.9. "安全事件响应计划"是指MongoDB评估疑似安全威胁和应对已确认数据泄露和其他安全事件的记录协议。
2. 信息安全计划概述。
2.1. 一般。 MongoDB维护了一个全面的书面信息安全计划，以建立有效的行政、技术和物理安全措施，以保护客户数据，并识别、检测、预防、应对和恢复安全事件。MongoDB的信息安全计划符合适用的数据保护法，并与NIST网络安全框架（NIST）保持一致。此外，MongoDB Atlas已通过ISO 27001:2013、ISO 27017:2015、ISO 27018:2019、SOC 2 Type II、支付卡行业数据安全标准v.4和云安全联盟（CSA）安全、信任、保证和风险（STAR）二级认证。MongoDB Atlas还经过由合格第三方评估师验证的HIPAA审查，并可配置为构建符合HIPAA的应用程序。
2.2. 维护与合规。 MongoDB的信息安全计划由专门的安全团队维护，由我们的首席信息安全官领导。MongoDB监控其信息安全计划的合规性，并对人员进行持续的教育和培训，以确保合规。信息安全计划至少每年审查和更新一次，以反映我们组织、业务实践、技术、服务和适用法律和法规的变化。我们不会以削弱或损害其安全控制有效性的方式更改或修改信息安全计划。
2.3. MongoDB人员控制。
2.3.1. 背景调查。 MongoDB对所有MongoDB员工以及任何有权访问客户数据或MongoDB系统的第三方承包商进行行业标准背景调查。
2.3.2. 人员义务。 任何获授权访问客户数据的特权用户都必须书面承诺遵守信息安全保密义务，这些义务在终止或更换工作后将继续有效。MongoDB对其安全政策和程序违反的人员维持正式的惩戒程序。
2.3.3. 培训。 在雇用后和之后至少每年一次，获授权访问客户数据的特权用户必须接受特定安全主题的培训，包括网络钓鱼、安全编码、内部威胁以及客户数据和可识别个人信息的妥善处理。此外，MongoDB为获授权访问客户数据的特权用户提供强制性的、基于角色的培训。MongoDB维护培训发生和内容的记录。除了这些强制性培训外，MongoDB还为员工提供额外的培训资源，例如内部安全意识和教育小组以及黑客马拉松。
2.4. 第三方。 MongoDB在上线之前维护并遵守第三方服务提供商的评估和审批流程，包括对每个第三方的安全流程和控制进行适当的尽职调查。我们要求第三方合同承诺保密、安全责任、安全控制和数据报告义务，并且我们每季度进行持续的针对性尽职调查。
2.5. 安全联系人。 如果您对安全有疑问或担忧，您可以通过正常的支持渠道、通过support.mongodb.com或通过电子邮件[email protected]联系我们。
3. MongoDB Atlas安全控制。
- https://aws.amazon.com/security/
- https://www.microsoft.com/en-us/trustcenter/security/azure-security
- https://cloud.google.com/security/
3.1. 数据中心和物理存储。 MongoDB Atlas在AWS、Azure和GCP上运行，您控制用于部署MongoDB Atlas集群的云服务提供商。每个云服务提供商负责其数据中心的安全，这些数据中心符合云服务提供商网站上的许多详细的物理安全和信息安全标准
至少每年两次，我们的云服务提供商将受到MongoDB或第三方审计师的尽职调查，包括获取和审查安全合规性认证。
除了选择要使用的云提供商外，您还可以控制MongoDB Atlas集群部署的区域。这使您可以灵活地决定客户数据物理存储的位置，您可以选择在特定的地理区域内部署客户数据（例如，仅在欧洲联盟内或仅在美国境内）。
3.2. 加密。
3.2.1. 传输过程中的加密。 所有MongoDB Atlas的网络流量都通过传输层安全性（TLS）进行保护，默认情况下已启用，无法禁用。您传输到MongoDB Atlas的客户数据，以及MongoDB Atlas集群节点之间传输的客户数据，都使用TLS进行传输加密。您可以选择为您的MongoDB Atlas集群使用哪个TLS版本，TLS 1.2是推荐的默认版本，最小密钥长度为128位。
3.2.1.1. 传输过程中加密的密钥管理程序。 所有传输加密都通过使用OpenSSL FIPS对象模块来实现。我们维护了文档化的加密和密钥管理指南，以确保客户数据的安全传输，并据此配置我们的TLS加密密钥协议和参数。MongoDB的密钥管理程序包括：（i）使用批准的密钥长度生成密钥；（ii）安全分发、激活和存储、恢复和替换、更新密钥；（iii）恢复丢失、损坏或过期的密钥；（iv）备份/存档密钥；（v）维护密钥历史；（vi）分配定义的密钥激活和停用日期；（vii）限制密钥访问权限仅限于授权人员；（viii）符合法律和监管要求。当密钥受到损害时，将吊销、停用并替换该密钥，以防止进一步使用（除非对已受损密钥进行有限的使用，以删除或验证保护）。密钥通过加密进行存储，并单独存储在加密数据之外。TLS证书从一家主要、广受信任的第三方公共证书机构获取。在标准TLS密钥协商过程中，为活动会话生成临时会话密钥，这些密钥永远不会持久化到磁盘，符合TLS协议的设计。
3.2.2. 静态存储加密。 在创建MongoDB Atlas集群时，默认情况下，客户数据使用AES-256加密以保护所有卷（磁盘）数据。该过程通过所选云提供商的透明磁盘加密自动化，云提供商完全管理加密密钥。您还可以选择通过WiredTiger加密存储引擎（使用AES-256）启用数据库级别的加密，以及通过AWS密钥管理服务（KMS）、GCP KMS或Azure密钥保管库（KV）携带自己的加密密钥。
3.2.3. 使用过程中的加密。 MongoDB Atlas还支持在将客户数据发送到MongoDB Atlas之前自动加密单个数据字段。如果您为所选数据字段启用了此客户端字段级加密功能，则内置到MongoDB驱动程序中的应用程序组件将加密客户数据的该字段，在离开驱动程序并发送到MongoDB Atlas之前，并且仅在驱动程序内部返回到应用程序时解密。对于您为客户端字段级加密启用的客户数据，MongoDB Atlas永远不会看到您的未加密客户数据，您可以控制加密密钥，您可以使用任何KMIP兼容的密钥管理服务来安全地存储这些密钥。
3.3. 网络连接选项。
3.3.1. 网络隔离。 您可以选择在专用虚拟环境或共享的多租户系统中部署您的MongoDB Atlas集群。专用MongoDB Atlas集群部署在VPC（适用于AWS和GCP）或VNet（适用于Azure）中，完全隔离您的客户数据，并配置为防止来自互联网的入站网络访问。每个此类MongoDB Atlas VPC或VNet都使用安全组，充当您的专用MongoDB Atlas集群的虚拟防火墙。
3.3.2. Atlas IP 访问列表。 为了允许您的 MongoDB Atlas VPC 或 VNet 进行入站网络访问，您必须配置 Atlas IP 访问列表，以使特定的网络能够连接到 MongoDB Atlas 项目中的 MongoDB Atlas 集群。除非 MongoDB Atlas 项目的 Atlas IP 访问列表中包含特定网络的 IP 地址，否则将阻止网络流量访问该 MongoDB Atlas 项目中的 MongoDB Atlas 集群。
3.3.3. 虚拟私有云对等连接。 您可以启用与您选择的云提供商（VPC 或 VNet）的专用应用程序层虚拟专用网络的 MongoDB Atlas VPC 或 VNet 之间的对等连接。对等连接允许您在您的 MongoDB Atlas VPC 或 VNet 和您的专用应用程序层 VPC 或 VNet 之间私有地路由加密流量，而不是穿越公共互联网。根据您选择的云提供商的功能，您还可以选择在跨区域之间将您的 MongoDB Atlas VPC 或 VNet 对等连接到您的应用程序层 VPC 或 VNet。
3.3.4. 私有端点。 MongoDB Atlas 还支持 AWS 上的 AWS PrivateLink 功能和 Azure 上的 Azure Private Link 功能。如果您为任何 MongoDB Atlas 集群启用此功能，则该 MongoDB Atlas 集群将仅允许从您的 AWS VPC 或 Azure VNet 到 MongoDB Atlas 集群的单向连接，并且该 MongoDB Atlas 集群不能启动回您的 AWS VPC 或 Azure VNet 的连接。私有端点还允许您通过其他应用程序层 AWS VPC 和 Azure VNet（您已与私有端点对等连接）的网络或通过您自己的自行管理的虚拟专用网络（包括 AWS DirectConnect 和 Azure ExpressRoute）间接访问您的 MongoDB Atlas 集群。
3.4. 配置管理。 MongoDB Atlas 环境，包括我们的生产环境和您的 MongoDB Atlas 集群，利用配置管理系统来完全自动化配置，基于一次性决策，并将这些决策安全地应用于新环境和现有环境，以确保每次的一致性。我们的生产环境和您的 MongoDB Atlas 集群使用内部构建的机器映像，通过行业标准的自动化软件应用安全配置管理，包括加固步骤。
4. 访问控制。
4.1. 客户访问。 MongoDB Atlas 支持多种身份验证和授权选项和方法，以给您提供灵活性，以满足您的个性化需求和需求。您负责了解您可用的安全配置选项以及您选择的配置对您的 MongoDB Atlas 环境的影响，该环境包括一个网络应用程序管理界面（“MongoDB Atlas UI”）和您部署的任何 MongoDB Atlas 集群。MongoDB Atlas 为 MongoDB Atlas UI 和您的 MongoDB Atlas 集群提供可配置的身份验证和授权选项。
4.1.1. MongoDB Atlas UI 身份验证和授权。 MongoDB Atlas UI 的用户凭据使用行业标准和审计的单向哈希存储。MongoDB Atlas UI 支持多因素身份验证（MFA），包括安全密钥/生物识别选项，允许您使用硬件安全密钥或内置的身份验证器。MongoDB Atlas UI 还支持利用安全断言标记语言（SAML）的单点登录（SSO）的联合身份验证功能。
4.1.2. MongoDB Atlas 集群身份验证和授权。 默认情况下，MongoDB Atlas 集群启用了盐值挑战响应身份验证机制 (SCRAM) 的身份验证控制。您可以选择使用自行管理的 X.509 证书或通过 AWS IAM 用户或角色来管理用户身份验证。MongoDB Atlas 允许您为单个用户或应用程序定义权限，以限制在查询中可访问的客户数据。此外，您还可以为每个用户分配 MongoDB Atlas 项目特定的角色，这授权用户在 MongoDB Atlas 项目内的 MongoDB Atlas 集群上执行特定操作。MongoDB Atlas UI 允许您通过为特定用户组合多个角色和权限来定制您的访问控制。您可以在任何时候审查、限制和撤销对您的 MongoDB Atlas 集群的用户访问。MongoDB Atlas 还提供了使用您的自己的轻量级目录访问协议 (LDAP) 服务器通过 TLS 管理用户身份验证和授权的能力。单个 LDAP 通过 TLS (LDAPS) 配置适用于 MongoDB Atlas 项目中的所有 MongoDB Atlas 集群。
4.1.3. 凭据要求。 作为配置选项的一部分，您可以在通过 SAML 将身份验证联邦化到 MongoDB Atlas UI 以及通过 LDAPS 到 MongoDB Atlas 集群后，通过您的身份提供者建立最低密码要求（例如，长度、复杂性）。
4.1.4. 客户数据库审计。 MongoDB Atlas 提供了细粒度审计，可监控您的 MongoDB Atlas 环境中的操作，旨在防止和检测对客户数据的任何未授权访问，包括创建、读取、更新和删除（CRUD）操作、加密密钥管理以及基于角色的访问控制。您负责启用数据库审计并选择您希望审计的用户、角色、组和事件操作。
4.2. MongoDB 人员访问 MongoDB Atlas 集群。
4.2.1. 特权用户访问。 一般而言，MongoDB 人员没有访问您的 MongoDB Atlas 集群的授权。只有在极少数需要调查和恢复关键服务的情况下，一小部分特权用户才被授权访问您的 MongoDB Atlas 集群。MongoDB 对这些特权用户遵循“最小权限”原则，并且任何访问都限于修复关键问题的必要最短时间和范围。特权用户只能通过一个门控过程访问您的 MongoDB Atlas 集群，该过程使用堡垒主机，要求在登录我们的 MongoDB 系统以及通过堡垒主机建立安全外壳连接（SSH）时进行双因素认证，并要求 MongoDB 高级管理层的批准。
4.2.2. 限制 MongoDB 人员访问。 MongoDB Atlas 为您提供了完全限制所有 MongoDB 人员（包括特权用户）访问您的 MongoDB Atlas 集群的选择。如果您选择限制此类访问，并且 MongoDB 确定访问对于解决特定支持问题是必要的，MongoDB 必须首先请求您的许可，然后您可以选择是否临时恢复特权用户访问，最多 24 小时。您可以在任何时候撤销 24 小时的临时访问授权。启用此限制可能会导致支持问题和解决时间的增加，从而可能对您的 MongoDB Atlas 集群的可用性产生负面影响。如果您启用了客户端字段级加密，即使特权用户也无法访问您的 MongoDB Atlas 集群中的明文客户数据，除非您向 MongoDB 提供加密密钥。
4.2.3. 凭证要求。 特权用户账户仅可用于特权活动，并且特权用户必须使用单独的账户进行非特权活动。特权用户账户不得使用共享凭证。第4.3.3节中描述的密码要求也适用于特权用户账户。
4.2.4. 访问审查和审计。 MongoDB 每季度审查一次特权用户访问授权。此外，当特权用户不再需要时，我们将撤销其访问权限，包括在特权用户更改角色或离开公司后的24小时内。我们还记录MongoDB人员对您的MongoDB Atlas集群的任何访问。审计日志至少保留6年，包括时间戳、行为者、操作和输出。MongoDB利用自动化和人工审查的组合来扫描这些审计日志。
4.3. MongoDB人员对MongoDB系统的访问。
4.3.1. 一般。 MongoDB关于访问MongoDB系统的政策和程序遵循基于角色的访问控制（RBAC）、最小权限和职责分离的原则。根据这些原则，就MongoDB Atlas而言，MongoDB开发人员只能访问我们的开发环境，而访问我们的生产环境仅限于获得适当授权的特权用户。我们每季度审查MongoDB系统的访问授权，并立即审查特权用户授权的任何变更。作为员工离职流程的一部分，在员工离职后的24小时内撤销对MongoDB系统的访问权限。
4.3.2. 对MongoDB Atlas生产环境的访问。 运行MongoDB Atlas的后端生产环境仅对获得高级管理层批准的特权用户组开放。特权用户只能通过堡垒主机访问我们的后端生产环境，并且这样做需要多因素认证（MFA）来登录和通过堡垒主机建立SSH连接。
4.3.3. 凭证要求。 所有MongoDB人员的密码必须符合行业标准复杂性规则。此外，所有MongoDB人员都必须强制执行多因素认证（MFA），并且不能禁用。
4.4. MongoDB办公室的物理控制。 如第3.1节所述，客户数据部署在您选择的云提供商的数据中心，而不是MongoDB拥有或运营的设施。在MongoDB办公室，我们遵循行业最佳实践，采用适当的物理安全控制措施，以应对存储信息的风险级别和我们在办公室的业务性质。在我们的办公室，我们：（i）通过正式的配置和审批流程向所有人员发放访问卡；（ii）限制对受限区域的访问，仅限于需要访问这些区域以执行其工作职能的人员；（iii）要求访客登记、签署保密协议，并在所有非公共区域由专人陪同；（iv）使用监控系统监控从公共场所的入口点的活动；（v）在终止后的12小时内撤销人员访问权限。
4.5. 客户数据的 securely 删除。 如果您终止 MongoDB Atlas 集群，它将立即无法使用，并且与该 MongoDB Atlas 集群相关的任何云备份也将终止。MongoDB 可能会保留在终止的 MongoDB Atlas 集群中存储的客户数据副本，最长可达 5 天。如果您终止云备份，所有快照将立即无法使用，并且客户数据在快照中的不可恢复可能需要长达 24 小时。当您终止 MongoDB Atlas 项目时，用于加密客户数据的主密钥将安全擦除，使所有客户数据实际上不可恢复。如果您选择使用 MongoDB Atlas 在线存档，您可以删除整个存档，或者预先定义 MongoDB Atlas 在线存档中不同数据部分的自动删除日期，以帮助自动化适用的保留限制或策略。
5. MongoDB 系统安全。
5.1. 生产环境与非生产环境的分离。 MongoDB Atlas 在生产环境与非生产环境之间有严格的分离。我们的 MongoDB Atlas 生产环境、您的 MongoDB Atlas 集群以及您的客户数据永远不会用于非生产目的。我们的非生产环境用于开发、测试和预演。MongoDB 还维护防火墙，以实现 MongoDB Atlas 生产环境与 MongoDB 内部网络的严格分离。
5.2. 软件开发生命周期。 MongoDB 拥有一个专门的安全团队，向首席信息安全官汇报，负责软件开发生命周期（SDLC）中的安全倡议。我们使用行业标准方法，包括定义的安全验收标准，以及与 NIST 和 OWASP 指导原则保持一致的多阶段过程来开发新产品和功能。SDLC 包括定期的代码审查、跟踪和管理我们代码所有更改的记录政策和工作流程、源代码提交的持续集成、代码版本控制、静态和动态代码分析、漏洞管理、威胁建模和漏洞搜索，以及自动化和手动源代码分析。
5.3. 监控和警报。 MongoDB 在不访问您的 MongoDB Atlas 集群的情况下监控 MongoDB Atlas 的健康和性能。MongoDB 维护一个集中日志管理系统，用于收集、存储和分析 MongoDB Atlas 生产环境和您的 MongoDB Atlas 集群的日志数据。我们使用这些信息进行健康监控、故障排除和安全性目的，包括入侵检测。我们至少保留我们的日志数据 6 年，并使用自动化扫描、自动化警报和人工审查的组合来监控数据。
5.4. 漏洞管理。
5.4.1. MongoDB Atlas 漏洞扫描。 MongoDB 维护一个记录的漏洞枚举和管理计划，该计划确定可互联网访问的公司资产，扫描已知漏洞，评估风险，并跟踪问题修复。我们对 MongoDB Atlas 部署的底层系统和集成到我们产品中的所有第三方代码进行季度扫描。MongoDB 的漏洞管理政策要求各个工程团队识别系统组件中的已知漏洞，并根据已识别问题的严重程度制定相应的修复时间表。我们还利用自动化工具，结合相关软件和库的监控安全公告，并在发现安全问题时实施补丁。
5.4.2. 漏洞修复。 MongoDB 使用一个中央公司范围内的票务系统来跟踪所有安全问题，直到修复。我们根据通用漏洞评分系统（CVSS）确定的需要更新的基础上实施操作系统和应用程序的补丁。我们也是一个 Mitre CVE 编号机构（CNA）。所有补丁、错误修复和新功能的开发任务都定义为特定目标版本的 issue，并且在完成包括质量保证测试、分阶段部署和管理审查在内的必要检查点后，才部署到生产环境中。
5.5. 渗透测试和内部风险评估。 MongoDB Atlas 经常接受内部和外部安全团队的审查。
5.5.1. 外部测试。 我们的MongoDB Atlas生产环境至少每年接受一次由国内知名安全公司进行的外部渗透测试。应您要求，我们将向您提供一份包含发现的高、中、低问题数量的参与总结信函，但由于测试过程中收集的信息敏感性，我们不允许客户对我们生产平台进行测试。应用层安全测试采用标准的应用评估方法（例如，OWASP）。此外，与安全顾问的外部合作可能包括社会工程学和钓鱼测试。
5.5.2. 内部测试。 在内部，MongoDB Atlas定期进行风险评估，包括技术漏洞发现和分析业务风险和关注点。MongoDB安全团队也定期参与源代码审查、架构审查、代码提交同行评审和威胁建模。
6. 应急计划。
6.1. 高可用性和故障转移。 每个MongoDB Atlas集群都作为自修复副本集部署，在发生故障时提供自动故障转移。MongoDB Atlas在区域内多个可用区自动提供副本集成员，提供对局部站点故障的弹性。所有副本集成员都是完整的数据承载节点，确保在单个节点故障的情况下进行大多数写入，并在恢复期间具有更高的弹性。副本集之间的并发写入是实时发生的。MongoDB Atlas还提供多区域和多云部署选项。
6.2. 备份。 MongoDB Atlas提供云备份，它使用您所选云提供商的本地快照功能来备份您的客户数据。您可以在创建或修改MongoDB Atlas集群时启用云备份，并控制云备份的捕获频率和云备份保留的时长。云备份快照存储在您的MongoDB Atlas集群的主要区域中您所选的云提供商处。所有云备份都是静态加密的，您可以选择使用与WiredTiger加密存储引擎配合使用的自管理密钥。您还可以选择性地启用连续云备份，将时间点恢复存储在我们的加密S3桶中。
6.3. 业务连续性和灾难恢复。 MongoDB维护一个符合ISO/IEC 22301:2019的业务连续性和灾难恢复（“BCDR”）计划。我们的BCDR计划包括：（i）明确定义的角色和责任；（ii）客户服务的可用性要求，包括恢复点目标（RPO）和恢复时间目标（RTO）；以及（iii）备份和恢复程序。我们至少每年审查、更新和测试我们的BCDR计划。在触发BCDR计划的事件发生时，RPO将取决于您受影响的MongoDB Atlas集群和备份配置。您可以使用MongoDB Atlas UI或API在任何时候测试您的应用程序如何处理副本集故障转移。
7. 事件响应和沟通。
7.1. 安全事件响应计划。 作为信息安全计划的一部分，MongoDB维护了一个符合NIST和ISO/IEC 27001:2013的安全事件响应计划。在MongoDB意识到数据泄露或其他安全事件的情况下，MongoDB将遵循安全事件响应计划，该计划包括：（i）明确定义的角色和责任，包括指定安全事件任务组；（ii）报告机制；（iii）评估、分类、隔离、消除和从安全事件中恢复的程序；（iv）向相关机构和客户发送必要通知的程序和时限；（v）调查和保存事件和系统日志数据的程序；（vi）一个旨在防止未来类似事件的后事件和解决方案分析流程。安全事件响应计划每年审查、更新和测试一次，包括每年至少一次的安全桌面演练。
7.2. 安全事件跟踪。 MongoDB 维护一个符合 ISO/IEC 27001:2013 标准和文档的安全事件跟踪系统，记录以下内容：（i）事件类型和疑似原因；（ii）是否存在未经授权或非法访问、披露、丢失、更改或破坏数据的情况；（iii）如果是，受事件影响的数据类别，包括个人信息的类别；（iv）事件发生或疑似发生的时间；（v）采取的补救措施。
7.3. 客户沟通。 如果我们得知任何数据泄露事件，我们将及时通知您。根据我们可获得的信息，此类通知将包括数据泄露的性质和原因以及预期解决时间。在可能的情况下，我们将随后向您提供有关根本原因评估、潜在影响、采取的补救措施以及预防未来类似事件计划的信息。
8. 审计报告。
8.1. 第三方认证和审计报告。 根据协议中规定的保密义务，应您的要求，我们将以第三方认证和审计报告的形式向您（或您的独立第三方审计师）提供有关 MongoDB 符合这些安全措施中规定的安全义务的信息。
8.2. 安全问卷调查。 每年不超过一次，我们将完成您提供的关于这些安全措施中概述的控制的书面安全问卷调查。