Atlassian Cloud 架构和运营实践

Atlassian Cloud 托管架构

我们使用 Amazon Web Services (AWS) 作为云服务提供商，并在全球多个地区使用其高可用性数据中心设施。每个 AWS 区域都是一个独立的地理位置，并且分为多个相互隔离、地理位置上相互分开的数据中心组（也称可用区域 (AZ)）。

我们利用 AWS 的计算、存储、网络和数据服务来构建我们的产品和平台组件，因而能够利用 AWS 提供的冗余功能，如可用区域和区域。

可用区域

每个可用区域都旨在与其他区域的故障相隔离，并为同一地区的其他可用区提供低成本、短延迟的网络连接。这种多区高可用性是地理和环境风险的第一道防线，它意味着在多可用区部署中运行的服务应能抵御可用区故障。

Jira 和 Confluence 使用 Amazon RDS（Amazon 关系数据库服务）的多可用区部署模式。在多可用区部署中，Amazon RDS 在同一地区的不同可用区中调配和维护同步备用副本，以提供冗余和故障转移功能。可用区故障转移是自动执行的，通常需要 60-120 秒，因此数据库操作可以在无需管理员干预的前提下尽快恢复。Opsgenie、Statuspage、Trello 和 Jira Align 使用类似的部署策略，但在副本时间和故障转移时间上稍有差异。

数据位置

Jira 和 Confluence 数据将保存在与您的大多数用户注册时所在区域最近的地区。Bitbucket 的数据存储在美国东部地区的两个不同的可用区。

不过，我们理解有些用户可能要求将数据保留在特定位置，因此我们提供数据驻留选项。目前，美国、欧盟、英国、澳大利亚、加拿大、德国、印度、日本、新加坡、韩国和瑞士等 11 个地区均提供针对 Jira、Jira Service Management、Jira Product Discovery 和 Confluence 的数据驻留服务。阅读我们的文档，了解有关数据驻留和相关范围内产品数据的更多信息。此外，您还可以关注我们的路线图，了解数据驻留的最新信息，包括对新产品、地区和数据类型的扩展。

数据备份

Atlassian 执行全面的备份计划。这包括我们的内部系统，其备份措施符合系统恢复要求。针对我们的云应用（具体而言，涉及您本人及您的应用数据），我们同样部署了完善的备份措施。我们采用 Amazon RDS（关系数据库服务）的快照功能为每个 RDS 实例自动创建每日备份。

Amazon RDS 快照会保留 30 天，同时支持时间点恢复，并使用 AES-256 加密技术进行加密。备份数据并非异地存储，而是复制到特定 AWS 区域内的多个数据中心。我们每个季度都会对备份进行测试。

对于 Bitbucket，存储快照保留 7 天，且支持时间点恢复。

我们不会使用这些备份来还原客户发起的破坏性变更，例如使用脚本覆盖的字段，或是已删除的工作项、项目或站点。为避免数据丢失，我们建议定期进行备份。参阅产品的支持文档，了解有关创建备份的更多信息。

数据中心安全

AWS 拥有多项认证以保护其数据中心。这些认证涉及物理和环境安全、系统可用性、网络和 IP 主干网访问、客户调配和问题管理。只有获得授权的人员才能进入数据中心，并要通过生物识别身份验证措施加以核验。物理安全措施包括：内部保安人员、闭路视频监控、诱捕系统和其他入侵防护措施。

分布式服务架构

借助此 AWS 架构，我们部署了多项跨解决方案通用的平台与产品服务。其中包括跨多个 Atlassian 产品共享和使用的平台功能（如媒体、身份、商务）、体验功能（如我们的编辑器）及产品专属功能（如 Jira 工作项服务和 Confluence 分析）。

多租户架构

基于我们的云基础架构，我们构建并运行了一个多租户微服务架构，同时搭建了一个支持我们产品的共享平台。在多租户架构中，单个服务可服务于多个客户，包括运行我们的云应用所需的数据库和计算实例。每个分片（本质上是一个容器，参见下图 3）均包含多个租户的数据，但每个租户的数据均相互隔离，其他租户无法访问。请务必注意，我们不提供单租户架构。

租户调配和生命周期

调配新客户后，很多事件都会触发分布式服务的编排和数据存储的调配。这些事件通常可映射到生命周期中的七个步骤之一：

1. 商务系统会立即更新相应客户的最新元数据和访问控制信息，然后调配编排系统会通过各种租户和产品事件让“已调配资源的状态”与许可状态保持一致。

租户事件

这些事件会影响到整个租户，具体影响可能是：

• 创建：创建租户并用于全新站点
• 销毁：删除整个租户
  

产品事件

• 激活：激活许可产品或第三方应用后
• 停用：停用特定产品或应用后
• 暂停：在暂停给定的现有产品后，从而禁用其对所拥有站点的访问权限
• 取消暂停：在取消暂停给定的现有产品后，从而授予其对所拥有站点的访问权限
• 许可更新：包含关于给定产品许可席位数及其状态（活动/非活动）的信息

2. 创建客户站点并为客户激活正确的产品集。站点的概念是指许可给特定客户的多种产品的容器。（例如：面向 ＜site-name＞.atlassian.net 的 Confluence 和 Jira Software）。

租户分离

虽然我们的客户在使用我们的云应用时会共享一个基于云的通用基础架构，但我们已部署相应措施确保客户间实现逻辑隔离，以便一个客户的操作不会影响其他客户的数据安全或服务可用性。

Atlassian 实现此目标的方法视具体应用而异。对于 Jira 和 Confluence Cloud，我们使用称为“租户上下文”的概念来实现逻辑上的客户隔离。它既会在应用代码中实施，也会通过我们开发的租户上下文服务 (TCS) 进行管理。这一概念可确保：

• 每一客户的数据在静止时与其他租户在逻辑上隔离
• 由 Jira 或 Confluence 处理的任何请求都具有“特定于租户的”视图，因而不会影响到其他租户

从宏观而言，TCS 通过为各个客户租户存储一个“上下文”来运作。每一租户的上下文都与 TCS 集中存储的唯一 ID 相关联，其中包括与该租户关联的一系列元数据（例如租户所在的数据库、租户拥有的许可证、他们可以访问的功能，以及各种其他配置信息）。当客户访问 Jira 或 Confluence Cloud 时，TCS 会使用租户 ID 对该元数据进行校对，然后将元数据与租户在整个会话期间在应用中执行的所有操作关联起来。

Atlassian 边缘

我们还将通过一种称为“边缘”的措施来保护您的数据，所谓边缘就是围绕我们的软件所构建的虚拟墙。收到的请求会被发送到最近的边缘。通过一系列验证，请求要么被放行，要么被拒绝。

• 请求会到达距离用户最近的 Atlassian 边缘。边缘将通过您的身份系统验证用户的会话和身份。
• 边缘会根据 TCS 信息中的数据确定您的产品数据所在的位置。
• 随后，边缘会将请求转发到目标地区，然后到达某一计算节点。
• 节点使用租户配置系统来对信息进行确认，例如许可证和数据库位置，并调用其他各种数据存储和服务（例如托管图像和附件的媒体平台）来检索为请求提供服务所需的信息。
• 原始用户请求包含先前调用其他服务时收集的信息。

服务授权和身份验证

我们的平台在数据访问方面采用最小权限原则。这意味着所有数据均仅限负责其存储、处理或检索的服务进行访问。例如，媒体服务（该服务能让您在我们的云应用中获得一致的文件上传与下载体验）配置有专属的存储空间，Atlassian 的其他任何服务均无法访问这些空间。凡需要访问媒体内容的服务均需与媒体服务 API 进行交互。因此，服务层的强大身份验证和授权还强制实现了严格的职责分离以及数据访问的最小权限原则。

我们使用 JSON Web 令牌（简称 JWT）确保应用外的签名授权，从而实现双重身份验证，因此我们的身份系统和租户上下文将作为数据源。令牌无法用于授权范围以外的任何其他用途。当您或团队中的某人调用微服务或分片时，您的身份系统将收到令牌以作为验证手段。此过程可确保令牌在共享相应数据之前处于最新状态并已签名。结合使用所需的身份验证和授权访问这些微服务时，如果服务受到攻击，其服务范围将受到限制。

然而，有时身份系统也可能会遭到攻击。为降低此风险，我们使用了两种机制。首先，TCS 和身份代理是高度重复的。我们为几乎所有微服务都配备一个 TCS Sidecar，并使用分支到身份认证的代理 Sidecar，从而确保始终有数千个此类服务处于运行状态。如果一个或多个此类服务存在异常行为，我们便可以快速找到该服务并纠正事务。

此外，我们不会坐等别人在我们的产品或平台中发现漏洞。我们会积极主动排查漏洞，尽可能减少对您的影响，同时运行大量安全计划来识别、检测和应对安全威胁。

租户上下文服务

我们将确保对任何微服务的请求都包含关于请求访问的客户（或租户）的相关元数据。我们将其称为租户上下文服务。该服务直接通过我们的配置系统进行填充。启动请求时，将读取上下文并内嵌至运行的服务代码（用于授权用户）中。Jira 和 Confluence 中的所有服务访问以及数据访问都需要此租户上下文，否则请求将被拒绝。

我们将通过 Atlassian 服务授权协议 (ASAP) 来实现服务身份验证和授权。我们将提供一份明确的允许列表，确定哪些服务可以通信，而授权详细信息则指定了哪些命令和路径可用。此举可限制受损服务横向移动的可能性。

服务身份验证和授权以及出口都由一组专用代理控制。这样可避免应用代码漏洞影响这些控制措施。远程代码不仅要具备修改应用逻辑的能力，还需要破坏底层主机并绕过 Docker 容器边界才能执行。相反，我们的主机级入侵检测功能会标记差异。

这些代理会根据服务的预期行为来限制出口行为。对于无需发出 webhook 或是与其他微服务进行通信的服务，我们已禁止此类服务如此运作。

数据加密

Atlassian Cloud 应用中的客户数据在传输过程中使用 TLS 1.2 或更高版本进行加密，并采用完美前向保密性 (PFS)，以防止未经授权的信息披露和数据修改。我们遵守 NIST 建议的 TLS 1.2+ 协议，强制使用浏览器支持的强密码和密钥长度。

存储在 Jira Software Cloud、Jira Service Management Cloud、Jira、Bitbucket Cloud、Confluence Cloud、Statuspage、Opsgenie 和 Trello 等云服务上的客户数据（包括附件）使用行业标准 AES-256 静态加密技术进行保护。

个人身份信息 (PII) 传输通过加密和强大的数据访问控制进行保护，旨在确保数据安全地传输到预定目的地。Atlassian 的密码和加密政策概述了实施加密和密码技术的原则，以降低与存储和传输 PII 相关的风险。根据 Atlassian 内部数据安全和信息生命周期管理政策的规定，用于保护 PII 的加密算法与 PII 的分类级别相一致。这可确保敏感数据根据其分类得到充分保护。请参阅我们的隐私页面，详细了解我们如何收集、共享和使用客户数据。

请参阅我们的 Cloud 路线图，了解最新的其他数据加密功能。