Atlas 如何加密我的数据？
Atlas使用 TLS 保护传输中的客户数据。 TLS默认启用且无法禁用；它会对发送到Atlas 的数据以及Atlas 集群节点之间传输的数据进行加密。 Atlas还静态数据进行加密。使用高级加密标准 (AES)-256 始终启用静态加密。
Atlas Core：在Atlas Core集群上，云提供商自动执行此磁盘加密操作并管理加密密钥。您可以选择使用WiredTiger加密存储引擎启用数据库级加密，并通过 AWS KMS、 Google Cloud KMS或Azure Key Vault自带密钥。
Atlas Infinite: Atlas Infinite 目前提供公共预览版。在Atlas Infinite 中，计算和存储是独立的层。在客户数据离开计算层并到达由多个客户共享的存储层之前， Atlas Infinite 始终在数据库级别对其进行加密。此存储层没有加密密钥，因此无法解密客户数据。在公共预览版中，客户管理的密钥可通过 AWS KMS获取。
Atlas Infinite 如何将每个客户的数据与其他客户的数据分开？
MongoDB Atlas Infinite 集群部署在专用VPC中，在计算层完全隔离客户数据。 Atlas Infinite 通过两种方式将每个租户的数据在存储层保持独立：
集群向存储层发出的每个请求，因此仅返回您的数据。
哪些认证涵盖Atlas？
有关涵盖Atlas 的最新认证和证明列表，请参阅MongoDB Atlas责任共担模型。此外， Atlas Infinite 享受与Atlas Core 相同的认证和证明。
我可以使用Atlas Infinite 配置哪些控件？
您现在可以配置Atlas中提供的相同控件：
区域 | 控件 |
|---|---|
网络 | |
加密 | |
备份 | |
支持访问权限 | |
区域 | |
集群配置 |
我的数据可以在Atlas Infinite 中的什么位置进行处理或存储？我是否可以通过地区、司法管辖区或云来对此进行限制？
与Atlas Core 一致， Atlas Infinite 中的应用程序数据仅在集群所在的地区中处理。 Atlas使您能力选择哪个云提供商和集群所在的特定地区。
进行了哪些查看和分析来确认系统的安全？
Atlas会定期接受内部和外部安全团队的审核。 Atlas生产环境每年至少接受一次由行业认可的安全公司进行的外部渗透测试。在内部， Atlas会定期进行风险评估，包括发现技术漏洞以及对业务风险和问题进行分析。此外， MongoDB还会定期扫描部署Atlas 的根本的系统以及集成到其产品中的第三方代码。有关详细信息，请参阅技术和组织安全措施。
是否可以在部署中禁用 TLS？
No.
Atlas 支持哪些版本的 TLS？
Atlas 要求所有 Atlas 集群使用 TLS 连接。Atlas 支持 TLS 协议版本 1.2 和 1.3 。
重要：Atlas 不再支持 TLS 1.0或1.1。所有集群都拒绝使用 TLS 1.0 或 1.1 进行连接的尝试。将您的集群的最低 TLS 版本设置为 1.2 或更高版本。
您可以从支付卡行业 (PCI) 和美国国家标准与技术研究院 (NIST) 了解有关更改时间和原因的更多信息。
如果您对TLS支持有疑问或无法更新应用程序以支持TLS 1.3 ，请联系Atlas MongoDB支持部门。
要打开Atlas支持票证：
在 Atlas 中，转到 Support（项目设置）页面。
如果尚未显示，组织从导航栏中的Organizations菜单。
单击导航栏中的 Support 图标。
单击 View plan（连接）。
显示“支持”页面。
如何知道我的应用程序是否支持 TLS 1.3？
如果应用程序的根本的编程语言或安全库在 TLS 1.3 之前就已存在，则可能需要更新到最新版本以支持 TLS 1.3。您可能还需要更新应用程序托管操作系统以支持 TLS 1.3。
MongoDB 和 Atlas 不提供审核外部应用程序所支持的 TLS 版本的服务。第三方服务（如 howsmyssl.com）可提供相应的工具。MongoDB 不支持此服务，此处引用仅供参考。利用您组织的程序选择供应商或服务来审核应用程序。
如需更新集群以支持 TLS 1.3，我需要做些什么？
进行应用程序的 Atlas 审核，以确认是否支持 TLS 1.3。
更新技术堆栈中不支持 TLS 1.3 的所有组件。
修改集群配置以使用 TLS 1.3。
如果您有 自定义的 TLS 1.2 密码配置，则必须更新配置以包含 TLS 1.3 密码。
哪个证书颁发机构签署 MongoDB Atlas TLS 证书？
Atlas 集群节点的 TLS 证书由 Google Trust Services 或 Let's Encrypt 签名，以提高高可用性。Atlas 同时使用这两个证书权限机构。您必须将来自 Google Trust Services 的 GTS Root R1、GTS Root R2、GTS Root R3 和 GTS Root R4 根证书权限机构的 CA 证书添加到客户端的可信证书存储区，除此之外，还必须添加来自 Let's Encrypt 的 ISRG Root X1 根证书权限机构，以确保服务的跨实例和区域的横向扩展实现无缝连续性。
Atlas 使用 GTS Root R3 和 GTS Root R4 根 CA 证书来支持 TLS 1.3。
注意
大多数应用程序环境的受信任证书颁发机构列表中已包含 Let's Encrypt 和 Google Trust Services。
要下载证书颁发机构证书，请参阅 Google 信任服务存储库 和 ISRG 根 X1。
注意
Atlas会自动轮换证书。您无需运行rotateCertificates命令。仅当您想手动轮换证书时才使用 rotateCertificates 命令。
Atlas集群多久轮换一次 TLS 证书？
TLS 证书的有效期为 90 天，从颁发之日起计。证书会在证书到期日期前 42 天进行轮换。
使用以下命令检查节点的 TLS 证书是否过期：
echo | openssl s_client -showcerts -connect $HOSTNAME:$PORT 2> /dev/null | openssl x509 -noout -enddate硬编码“证书颁发机构”。
我们不建议对中间证书进行硬编码或固定，因为这会带来操作负担和可用性风险。如果 Let's Encrypt 或 Google Trust Services 轮换或替换固定的中间证书，您的应用程序可能无法连接，从而导致中断。
如果必须固定证书，请将其固定到证书颁发机构证书，而不是任何中间证书。
Java 用户
Let's Encrypt 的 ISRG 根证书和 Google Trust Services 根证书均可在 u 更新后Java版本7 7391的默认信任存储以及 u {Java}8 8381更新 。使用 18 7 月 2023 之后的Java发布。
确保 Java 客户端软件是最新的。使用最新的 Java 版本可以利用针对我们的 TLS 证书的改进（除了新的“证书颁发机构”的这些要求）。
如果您有自己的信任存储，请将 Let's Encrypt 和 Google Trust Services 证书添加到其中。 要学习；了解更多信息，请参阅哪个证书颁发机构签署MongoDB Atlas TLS 证书？
Windows Server 用户
默认下， Windows Server 中不包含 ISRG 根 X1、GTS 根R1 和 GTS 根R 2 根证书颁发机构，但可在Microsoft可信根计划中使用。
要配置Windows Server 以下载受信任的根证书，请参阅Windows文档。
Amazon Linux AMI 用户
某些版本的Amazon Linux AMI 可能不会同时具有 ISRG 根 X1 和 GTS 根R1 和R2 证书。请迁移到较新版本的Amazon Linux以获得所需的根证书。6 月2025之后，我们将要求Atlas支持ISRG 根 X1、GTS 根R1 和R 2 证书，以避免证书兼容性问题。
如果您必须使用较旧的Amazon Linux AMI，请手动安装 ISRG 根 X1、GTS 根R1 和R2 根证书颁发机构。
其他所有人
如果您使用的是最新的编程语言和操作系统版本， 则此更改不会对您造成影响。
为什么我的 TLS 配置更改失败？ UNSAFE_TLS_TRANSITION error?
Atlas 可防止 TLS 配置更改导致集群节点之间在滚动更新期间发生通信中断。
更新 TLS 设置时，Atlas 会一个节点一个节点地应用更改。在此过程中，运行旧配置的节点必须仍能连接到运行新配置的节点。如果您提出的更改删除所有共享 TLS 版本或密码套件，则节点无法通信，这会导致集群分区和潜在的停机。
为保护集群可用性，Atlas 会阻止这些不安全过渡并返回 UNSAFE_TLS_TRANSITION 错误。
UNSAFE_TLS_TRANSITION 错误原因
当前和建议的 TLS 配置之间没有重叠时，通常会在以下场景中发生此错误：
TLS 版本不匹配。
示例：直接从仅支持 TLS 1.2 切换为仅支持 TLS 1.3。
结果：使用 TLS 1.2 的节点无法连接到需要 TLS 1.3 的节点。
密码套件不匹配。
示例：将所有现有密码套件替换为完全不同的套件。
结果：节点没有共享密码来协商连接
UNSAFE_TLS_TRANSITION 错误解决方案
分阶段更改 TLS，并确保新旧设置之间存在重叠：
适用于 TLS 版本：
启用 TLS 1.2 和 TLS 1.3。
应用更改，并允许更新完成。
在后续更新中删除 TLS 1.2 (如有需)。
对于密码套件：
- 确保在过渡期间，当前配置与新配置之间至少共享一个密码套件。
UNSAFE_TLS_TRANSITION 错误要点
避免“一次性” TLS 变更。始终保持旧配置和新配置之间的临时兼容性，以确保安全的滚动更新。
Atlas 对 Community 和不支持的驱动程序的支持策略是什么？
Atlas 为官方支持的驱动程序、Community 驱动程序和不支持的配置提供不同级别的支持。
驱动程序分类
官方支持的驱动程序
MongoDB 开发和维护这些驱动程序，它们列在 mongodb.com/zh-cn/docs/drivers 上。MongoDB 的测试矩阵、发布过程和支持 SLA 涵盖这些驱动程序。
官方支持的驱动程序包括 C、C++、C#、Go、Java、Kotlin、Node.js、PHP、Python、Ruby、Rust、Scala 和 Swift。
Community 驱动程序
第三方开发者创建并维护这些驱动程序，它们实现 MongoDB 公布的规格或传输协议。示例包括 Zookzook (Elixir)、Mango (Dart)、mongolite (R)和 mgo (Go)。
不支持的配置
任何官方支持的或 Community 驱动程序使用的已结束生命周期版本。
支持级别
官方支持的驱动程序（当前版本）
Atlas SLA 涵盖这些驱动程序。MongoDB 提供标准的故障排除和解决方案，包括连接问题的调查和修复。
官方支持的驱动程序（EOL 版本）
MongoDB 提供最大努力支持。MongoDB 会调查问题，但可能会建议升级到当前版本。
Community 驱动程序
MongoDB 提供最大努力的仅诊断支持。支持可帮助您确定问题是源于平台还是驱动程序。对于驱动程序侧问题，MongoDB 提供可用的指导，并将您引导至驱动程序维护人。MongoDB 不调试或修补 Community 驱动程序代码。
职责
什么 |service| 做
Atlas 会对影响连接层的平台变更进行风险评估，包括 TLS 版本变更、证书轮换和身份验证机制更新。Atlas 会评估已知的脆弱模式，即使脆弱来源于客户端代码。
对于高风险平台变更，Atlas 将在发布说明和可行时的预维护通知中发布指导。
什么 |service| 不做
Atlas 不会：
测试、认证或保证 Community 驱动程序的正确性
测试所有配置中的所有 Community 驱动程序
承诺修补、查看或维护 Community 驱动程序
Community 驱动程序必须正确实现 TLS 协商、身份验证、传输协议和故障转移行为。MongoDB 对 Community 驱动程序的任何贡献都是自愿的，而非合同义务。
SLA 覆盖
Atlas SLA 仅涵盖当前版本中官方支持的 MongoDB 驱动程序。由 Community 驱动程序错误或不支持的驱动程序配置导致的服务中断不属于 SLA 范围。
使用当前版本的 官方支持的驱动程序，以获得完整的 SLA 覆盖和最佳支持体验。