Atlassian Cloud
Atlassian Cloud 架构和运营实践
详细了解 Atlassian Cloud 架构以及我们采用的运营实践
简介
Atlassian Cloud 产品和数据托管在业界领先的云提供商 Amazon Web Services (AWS) 中。我们的产品在一个平台即服务 (PaaS) 环境中运行,该环境分为两组主要的基础架构,我们称之为 Micros 和非 Micros。Jira、Confluence、Statuspage、Access 和 Bitbucket 在 Micros 平台上运行,而 Opsgenie 和 Trello 在非 Micros 平台上运行。
云基础架构:
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 的数据位于美国东部地区,美国西部地区则用于进行灾难恢复。
数据备份
Atlassian 执行全面的备份计划。其中包括我们的内部系统,其备份措施符合系统恢复要求。对于我们的云产品,尤其是与您和您的应用相关的数据,我们也有全面的备份措施。Atlassian 采用 Amazon RDS(关系数据库服务)的快照功能为每个 RDS 实例自动创建每日备份。
Amazon RDS 快照会保留 30 天并支持时间点恢复,同时使用 AES-256 加密技术进行加密。备份数据并非异地存储,而是复制到特定 AWS 区域内的多个数据中心。我们每个季度都会对备份进行测试。
Bitbucket 中的数据会复制到不同的 AWS 区域,并且每个区域每天都在进行独立备份。
我们不会使用这些备份来还原客户做出的破坏性变更,例如使用脚本来覆盖的字段,或是已删除的事务、项目或站点。为避免数据丢失,我们建议定期进行备份。参阅产品的支持文档,了解有关创建备份的更多信息。
数据中心安全
AWS 拥有多项认证以保护其数据中心。这些认证涉及物理和环境安全、系统可用性、网络和 IP 主干网访问、客户调配和问题管理。进入数据中心仅限获得授权的人员,并通过生物识别身份验证措施加以核验。物理安全措施包括:内部保安人员、闭路视频监控、诱捕系统和其他入侵防护措施。
Bitbucket 使用 NetApp CVS (Cloud Volumes Service) 对存储库的文件进行存储。CVS 是由 NetApp 管理且在 NetApp 数据中心托管的文件系统。NetApp 遵循全球数据安全法律的要求,这些法律要求采取合理的安全措施来存储、传输和处理数据。此外,NetApp 还利用自我评估和第三方审计员来确保符合法规遵从性要求。有关更多信息,请参阅 NetApps 安全实践和合规性认证。
云平台架构
分布式服务架构
借助此 AWS 架构,我们对我们解决方案中使用的很多平台和产品服务都进行了托管。其中包括跨多个 Atlassian 产品共享和使用的平台功能,如媒体、身份、商务、我们的编辑器等体验,以及某些特定于产品的功能,如 Jira 事务服务和 Confluence 分析。
图 1
Atlassian 开发人员通过内部开发的名为 Micros 的平台即服务 (PaaS) 来调配这些服务,该 PaaS 可自动协调共享服务、基础架构、数据存储及其管理功能的部署,其中包括安全性和合规性控制要求(见上图 1)。通常,Atlassian 产品由多个“容器化”服务组成,这些服务通过 Micros 部署在 AWS 上。Atlassian 产品使用的核心平台功能(见下图 2)包括请求路由、二进制对象存储、身份验证/授权、事务性用户生成内容 (UGC) 和实体关系存储、数据湖、通用日志记录、请求跟踪、可观察性和分析服务。这些微服务通过经批准的平台级标准化技术堆栈而构建:
图 2
多租户架构
基于我们的云基础架构,我们构建并运行了一个多租户微服务架构,并带有一个支持我们产品的共享平台。在多租户架构中,单个服务可服务多个客户,包括运行我们的云产品所需的数据库和计算实例。每个分片(本质上是一个容器 - 见下图 3)均包含多个租户的数据,但每个租户的数据均相互隔离,对其他租户不可见。请务必注意,我们不提供单一租户架构。
图 3
我们的微服务在构建时考虑了最低权限,旨在最大限度地缩小零日漏洞入侵的范围,并降低在我们的云环境中发生内网渗透的可能性。每个微服务都有自己的数据存储,且由于只能使用该特定服务的身份验证协议来访问该数据存储,因而任何其他服务均无该 API 的读写访问权限。
我们专注于隔离微服务和数据,而不是提供专门的每租户基础架构,以避免缩小众多客户对单个系统的狭窄数据访问范围。由于逻辑已经解耦,且数据授权和身份验证在应用层进行,因此在向这些服务发送请求时,数据授权和身份验证可以充当额外的安全检查。因此,如果微服务遭到破坏,只会导致特定服务所需数据的访问受限。
租户调配和生命周期
调配新客户后,很多事件都会触发分布式服务的编排和数据存储的调配。这些事件通常可映射到生命周期中的七个步骤之一:
1. 商务系统会立即更新相应客户的最新元数据和访问控制信息,然后调配编排系统会通过各种租户和产品事件让“已调配资源的状态”与许可状态保持一致。
租户事件
这些事件会影响到整个租户,具体影响可能是:
- 创建:创建租户并用于全新站点
- 销毁:删除整个租户
产品事件
- 激活:激活许可产品或第三方应用后
- 停用:停用特定产品或应用后
- 暂停:在暂停给定的现有产品后,从而禁用其对所拥有站点的访问权限
- 取消暂停:在取消暂停给定的现有产品后,从而授予其对所拥有站点的访问权限
- 许可更新:包含关于给定产品许可席位数及其状态(活动/非活动)的信息
2. 创建客户站点并为客户激活正确的产品集。站点的概念是指许可给特定客户的多种产品的容器。(例如:面向 <site-name>.atlassian.net 的 Confluence 和 Jira Software)。
图 4
3. 在指定区域的客户站点内调配产品。
调配产品后,其大部分内容都将托管到靠近用户访问地的位置。为了优化产品性能,我们不会限制在全球托管的数据的移动,但我们可能会根据需要在各区域之间移动数据。
对于我们的某些产品,我们还会提供数据驻留功能。通过数据驻留功能,客户可以选择将产品数据分布到全球,或者保存在我们指定的地理区域。
4. 创建并存储客户站点和产品核心元数据和配置。
5. 创建和存储站点和产品标识数据,如用户、群组、权限等。
6. 在站点内调配产品数据库,例如:Jira 系列产品,Confluence、Compass、Atlas。
7. 调配产品许可应用。
图 5
上图 5 展示了客户站点在我们的分布式架构中(而不仅仅是在单个数据库或存储中)的部署方式。其中包括存储元数据、配置数据、产品数据、平台数据和其他相关站点信息的多个物理和逻辑位置。
租户分离
虽然我们的客户在使用我们的云产品时共享一个基于云的通用基础设施,但我们采取了相关措施来确保逻辑上的分离,以确保某一客户的行为不会损害其他客户的数据或服务。
Atlassian 实现此目标的方法视具体应用而异。对于 Jira 和 Confluence Cloud,我们使用称为“租户上下文”的概念来实现逻辑上的客户隔离。它既会在应用代码中实施,也会通过我们开发的租户上下文服务 (TCS) 进行管理。这一概念可确保:
- 每一客户的数据在静止时与其他租户在逻辑上隔离
- 由 Jira 或 Confluence 处理的任何请求都具有“特定于租户的”视图,因而不会影响到其他租户
从宏观而言,TCS 通过为各个客户租户存储一个“上下文”来运作。每一租户的上下文都与 TCS 集中存储的唯一 ID 相关联,其中包括与该租户关联的一系列元数据(例如租户所在的数据库、租户拥有的许可证、他们可以访问的功能,以及各种其他配置信息)。当客户访问 Jira 或 Confluence Cloud 时,TCS 会使用租户 ID 对该元数据进行校对,然后将元数据与租户在整个会话期间在应用中执行的所有操作关联起来。
Atlassian 边缘
我们还将通过一种称为“边缘”的措施来保护您的数据,所谓边缘就是围绕我们的软件所构建的虚拟墙。收到的请求会被发送到最近的边缘。通过一系列验证,请求要么被放行,要么被拒绝。
- 请求会到达距离用户最近的 Atlassian 边缘。边缘将通过您的身份系统验证用户的会话和身份。
- 边缘会根据 TCS 信息中的数据确定您的产品数据所在的位置。
- 随后,边缘会将请求转发到目标地区,然后到达某一计算节点。
- 节点使用租户配置系统来对信息进行确认,例如许可证和数据库位置,并调用其他各种数据存储和服务(例如托管图像和附件的媒体平台)来检索为请求提供服务所需的信息。
- 原始用户请求包含先前调用其他服务时收集的信息。
安全控制
由于我们的云产品采用多租户架构,因此我们可以将其他安全控制措施分层到解耦后的应用逻辑中。租户单体式应用通常不会引入进一步授权检查或速率限制,例如,在执行大量查询或导出时。随着服务范围的缩小,单一零日漏洞的影响将大大降低。
此外,我们还在完全托管于 Atlassian 平台的产品中构建额外的预防性控制措施。主要的预防性控制措施包括:
- 服务授权和身份验证
- 租户上下文服务
- 密钥管理
- 数据加密
服务授权和身份验证
我们的平台使用最低权限模型来访问数据。这意味着所有数据仅限用于保存、处理或检索数据的服务。例如,媒体服务可让您在我们的云产品中获得一致的文件上传和下载体验,它们配有专用的存储空间,而 Atlassian 的其他服务则无法访问。凡需要访问媒体内容的服务均需与媒体服务 API 进行交互。因此,服务层的强大身份验证和授权还强制实现了严格的职责分离以及对数据的最低权限访问。
我们使用 JSON Web 令牌(简称 JWT)确保应用外的签名授权,从而实现双重身份验证,因此我们的身份系统和租户上下文将作为数据源。令牌无法用于授权范围以外的任何其他用途。当您或团队中的某人调用微服务或分片时,您的身份系统将收到令牌以作为验证手段。此过程可确保令牌在共享相应数据之前处于最新状态并已签名。结合使用所需的身份验证和授权访问这些微服务时,如果服务受到攻击,其服务范围将受到限制。
然而,有时身份系统也可能会遭到攻击。为降低此风险,我们使用了两种机制。首先,TCS 和身份代理是高度重复的。我们为几乎所有微服务都配备一个 TCS Sidecar,并使用分支到身份认证的代理 Sidecar,从而确保始终有数千个此类服务处于运行状态。如果一个或多个此类服务存在异常行为,我们便可以快速找到该服务并纠正事务。
此外,我们不会坐等别人在我们的产品或平台中发现漏洞。我们会积极主动排查漏洞,尽可能减少对您的影响,同时运行大量安全计划来识别、检测和应对安全威胁。
租户上下文服务
我们将确保对任何微服务的请求都包含关于请求访问的客户(或租户)的相关元数据。我们将其称为租户上下文服务。该服务直接通过我们的配置系统进行填充。启动请求时,将读取上下文并内嵌至运行的服务代码(用于授权用户)中。Jira 和 Confluence 中的所有服务访问以及数据访问都需要此租户上下文,否则请求将被拒绝。
我们将通过 Atlassian 服务授权协议 (ASAP) 来实现服务身份验证和授权。我们将提供一份明确的允许列表,确定哪些服务可以通信,而授权详细信息则指定了哪些命令和路径可用。此举可限制受损服务横向移动的可能性。
服务身份验证和授权以及出口都由一组专用代理控制。这样可避免应用代码漏洞影响这些控制措施。远程代码不仅要具备修改应用逻辑的能力,还需要破坏底层主机并绕过 Docker 容器边界才能执行。相反,我们的主机级入侵检测功能会标记差异。
这些代理会根据服务的预期行为来限制出口行为。对于无需发出 webhook 或是与其他微服务进行通信的服务,我们已禁止此类服务如此运作。
数据加密
Atlassian 云产品中存储的客户数据在通过公共网络传输时,均会使用具有完全向前保密性 (PFS) 的 TLS 1.2+ 进行加密,避免客户数据遭受未经授权的披露或修改。在实施 TLS 时,我们强制使用浏览器支持的强密码和密钥长度。
服务器上存储有 Jira Software Cloud、Jira Service Management Cloud、Jira Work Management、Bitbucket Cloud、Confluence Cloud、Statuspage、Opsgenie 和 Trello 中客户数据和附件的数据驱动器使用行业标准 AES-256 对全磁盘静止数据进行加密。
对于使用数据传输网络传输的个人身份信息,它们会受到相应的控制,以确保数据到达预定目的地。Atlassian 的内部密码和加密政策规定了 Atlassian 实施加密和密码机制的通用原则,以降低存储和通过网络传输 PII 所涉及的风险。用于加密 PII 的算法类型必须根据 Atlassian 的内部数据安全和信息生命周期管理,将 PII 的分类级别纳入考虑。请参阅我们的隐私页面,详细了解我们如何收集、共享和使用客户数据。
请参阅我们的 Cloud 路线图,了解最新的其他数据加密功能。
密钥管理
在 Atlassian,我们使用 AWS Key Management Service (KMS) 进行密钥管理。为了进一步保护数据的隐私,KMS 将充当这些密钥的发送方和机密存储位置。AWS 定期对加密、解密和密钥管理流程进行内部检查和验证,以作为其现有内部验证流程的一部分。每个密钥都会分配负责人,负责确保对密钥实施适当级别的安全控制。Atlassian 管理的密钥会在角色或雇佣状态发生相关变化时轮换。
我们还利用信封加密。AWS 拥有我们永远无法查看的主密钥,任何密钥加密或解密请求均需具备正确的 AWS 角色和权限。并且,当我们使用信封加密为单个客户构建或生成密钥时,通过数据存储,我们可为不同类型的数据提供不同的数据密钥。此外,我们对内部应用层采用加密方法,可在其他 AWS 地区提供备份数据密钥。密钥每年会自动轮换,同一数据密钥不会用于超过 100,000 个数据元素。
自带密钥 (BYOK) 加密即将推出,从而帮助您在 AWS KMS 中使用自行管理的密钥来加密云产品数据。借助 BYOK,您可以完全控制管理密钥,并可随时授予或撤消针对您的最终用户和 Atlassian 系统的访问权限。
AWS KMS 可与您 AWS 帐户中的 AWS CloudTrail 集成,以便为您提供所有密钥使用情况的日志。该解决方案支持在整个应用的不同层级对数据进行加密,例如数据库、文件存储以及我们的内部缓存和事件队列。在整个过程中,均不会对产品可用性产生影响。