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 数据将保存在与您的大多数用户注册时所在区域最近的地区。但是，我们知道部分客户可能有将数据保留在特定位置的需求，因此我们提供了数据驻留服务。目前，我们在美国和欧盟地区以及澳大利亚提供数据驻留服务，并计划在其他区域增添相关支持。若需有关信息以及注册以获取更新，请参阅我们的数据驻留页面。

Data for Bitbucket is located in two different availability zones in the US-East region.

数据备份

Atlassian 执行全面的备份计划。其中包括我们的内部系统，其备份措施符合系统恢复要求。对于我们的云产品，尤其是与您和您的应用相关的数据，我们也有全面的备份措施。Atlassian 采用 Amazon RDS（关系数据库服务）的快照功能为每个 RDS 实例自动创建每日备份。

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

For Bitbucket, storage snapshots are retained for 7 days with support for point-in-time recovery.

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

数据中心安全

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 云产品中存储的客户数据在通过公共网络传输时，均会使用具有完全向前保密性 (PFS) 的 TLS 1.2+ 进行加密，避免客户数据遭受未经授权的披露或修改。在实施 TLS 时，我们强制使用浏览器支持的强密码和密钥长度。

Jira Cloud、Jira Service Management Cloud、Bitbucket Cloud、Confluence Cloud、Jira Product Discovery、Statuspage、Opsgenie 和 Trello 中保存客户数据和附件的服务器上的数据驱动器使用全磁盘行业标准 AES-256 静态加密。

PII transmitted using a data-transmission network are subject to appropriate controls designed to ensure that data reaches its intended destination. Atlassian's internal Cryptography & Encryption Policy sets out the general principles for Atlassian's implementation of encryption & cryptography mechanisms to mitigate the risks involved in storing PII and transmitting it over networks. The type of encryption algorithm used to encrypt PII must take into account the classification level of the PII in accordance with Atlassian's internal Data Security & Information Lifecycle Management. To learn more about how we collect, share, and use customer data, refer to our privacy page.

To keep up to date on additional data encryption capabilities, see our cloud roadmap.

密钥管理

在 Atlassian，我们使用 AWS Key Management Service (KMS) 进行密钥管理。为了进一步保护数据的隐私，KMS 将充当这些密钥的发送方和机密存储位置。作为 AWS 现有内部验证流程的一部分，AWS 会定期对加密、解密和密钥管理流程进行内部检查和验证。每个密钥都会分配负责人，负责确保对密钥实施适当级别的安全控制。Atlassian 管理的密钥会在角色或雇佣状态发生相关变化时轮换。

我们还利用信封加密。AWS 拥有我们永远无法查看的主密钥，任何密钥加密或解密请求均需具备正确的 AWS 角色和权限。并且，当我们使用信封加密为单个客户构建或生成密钥时，通过数据存储，我们可为不同类型的数据提供不同的数据密钥。此外，我们对内部应用层采用加密方法，可在其他 AWS 地区提供备份数据密钥。密钥每年会自动轮换，同一数据密钥不会用于超过 100,000 个数据元素。

自带密钥 (BYOK) 加密即将推出，从而帮助您在 AWS KMS 中使用自行管理的密钥来加密云产品数据。借助 BYOK，您可以完全控制管理密钥，并可随时授予或撤消针对您的最终用户和 Atlassian 系统的访问权限。

AWS KMS 可与您 AWS 帐户中的 AWS CloudTrail 集成，以便为您提供所有密钥使用情况的日志。该解决方案支持在整个应用的不同层级对数据进行加密，例如数据库、文件存储以及我们的内部缓存和事件队列。在整个过程中，均不会对产品可用性产生影响。