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 的数据驻留服务。阅读我们的文档，了解有关数据驻留和相关范围内产品数据的更多信息。此外，您还可以关注我们的路线图，了解数据驻留的最新信息，包括对新产品、地区和数据类型的扩展。

数据备份

We operate a comprehensive backup program at Atlassian. This includes our internal systems, where our backup measures are designed in line with system recovery requirements. With respect to our cloud apps, and specifically referring to you and your application data, we also have extensive backup measures in place. We use the snapshot feature of Amazon RDS (Relational database service) to create automated daily backups of each RDS instance.

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

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

We don’t use these backups to revert customer-initiated destructive changes, such as fields overwritten using scripts, or deleted work items, projects, or sites. To avoid data loss, we recommend making regular backups. Learn more about creating backups in the support documentation for your product.

数据中心安全

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

分布式服务架构

With this AWS architecture, we host a number of platform and product services that are used across our solutions. This includes platform capabilities that are shared and consumed across multiple Atlassian products, such as Media, Identity, and Commerce, experiences such as our Editor, and product-specific capabilities, like Jira Work Item service and Confluence Analytics.

多租户架构

On top of our cloud infrastructure, we built and operate a multi-tenant micro-service architecture along with a shared platform that supports our products. In a multi-tenant architecture, a single service serves multiple customers, including databases and compute instances required to run our cloud apps. Each shard (essentially a container – see figure 3 below) contains the data for multiple tenants, but each tenant's data is isolated and inaccessible to other tenants. It is important to note that we do not offer a single tenant architecture.

租户调配和生命周期

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

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

租户事件

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

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

产品事件

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

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

租户分离

While our customers share a common cloud-based infrastructure when using our cloud apps, we have measures in place to ensure they are logically separated so that the actions of one customer cannot compromise the data or service of other customers.

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

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

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

Atlassian 边缘

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

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

服务授权和身份验证

Our platform uses a least privilege model for accessing data. This means that all data is restricted to only the service responsible for saving, processing, or retrieving it. For example, the media services, which allows you to have a consistent file upload and download experience across our cloud apps, have dedicated storage provisioned that no other services at Atlassian can access. Any service that requires access to the media content needs to interact with the media services API. As a result, strong authentication and authorization at the service layer also enforces strong separation of duties and least privilege access to data.

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

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

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

租户上下文服务

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

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

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

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

数据加密

Customer data in Atlassian cloud apps is encrypted during transmission utilizing TLS 1.2 or higher, incorporating perfect forward secrecy (PFS) to safeguard against unauthorized information disclosure and data modification. We adhere to NIST-recommended TLS 1.2+ protocols, which enforce the use of strong ciphers and key lengths as supported by the browser.

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

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

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