安全实践

我们的团队

尽管大多数公司都会这样说，但我们对自己的安全团队尤其感到自豪。我们相信，我们组建的团队招募到了业内最优秀、最聪明的人才。我们的安全团队由在旧金山办公的 CISO 领衔，包含来自悉尼、阿姆斯特丹、班加罗尔、奥斯汀、山景城、旧金山和纽约办事处的 100 多位成员，以及一些远程团队成员。鉴于 Atlassian 对安全性的重视，此团队仍在不断壮大。我们设有多个子团队，具体包括：

• 产品安全 – 负责我们产品和平台的安全
• 生态系统安全 – 负责我们 Marketplace 和加载项的安全
• 检测和响应 – 负责检测和应对安全事件
• 红队 - 负责模拟对手并演练检测和响应
• 安全架构 – 负责制定我们产品和平台的安全要求
• 企业安全 – 负责与我们公司网络和应用程序相关的内部安全
• 信任 - 负责跟踪和响应客户的期望，并为我们的流程和实践提供透明度
• 开发和 SRE – 负责开发和运行安全团队需要的工具
• 意识和培训 - 负责确保我们的员工和合作伙伴清楚如何安全地开展工作

在安全团队不断扩大的同时，Atlassian 的每一个人都是我们提升安全性这一使命的一分子，所有员工在我们公司任职期间都清楚这一点。我们力求做到在云安全领域引领同行，满足所有客户的云安全需求，超越所有行业安全标准和认证要求，并且自信地发布有关我们如何保护客户数据的详细信息。所有员工在 Atlassian 任职期间都清楚我们的目标和愿景。

我们用来支持安全的其他计划

在关注安全性基本要素的同时，我们也制定了一系列计划，确保我们的安全方法不但触及面广，而且具有前摄性。其中包括：

持续改进我们的安全计划

我们致力于确保我们的安全计划立足于前沿并领先于同行。我们知道，想要做到这一点，需要通过不断评估目前的安全方法（包括与业内同行比较）来确定有待改进的地方。

为此，我们邀请独立安全咨询公司对我们的安全计划进行成熟度评估，此类评估已多次进行，且会持续开展。2020 年，我们还对整体信任与安全计划进行了同行评估。我们通过这些过程来吸收养分，包括重要的建议，利用它们来填补缺口和改进提高。

我们还在各种安全领域（如产品安全以及检测和响应）中定义了一系列计划，以指导我们的内部改进。我们定义了支持每个计划的指标，并通过我们的安全管理团队进行审查。我们利用这些指标来确定并锁定每项核心能力中需要改进的领域。

更多信息

本文提供了我们安全性方法的综合概览。有关更多安全计划相关信息，请访问 Atlassian Trust Center。另外，我们还有一系列专门的网页和白皮书从不同方面详细介绍了我们的安全计划，其中包括：

• Atlassian 如何管理客户数据
• 我们的外部安全测试方法
• 我们的安全漏洞管理方法
• 我们的漏洞管理方法
• 云安全性共同责任
• Atlassian Trust Management System
• Atlassian 安全与技术政策

通过零信任保护对我们网络的访问

为保护对公司网络、内部应用程序和云环境的访问，Atlassian 贯彻一种被称为“零信任”的理念。简单地说，零信任的核心原则是“从不信任，始终验证”。

零信任摒弃了传统的网络安全性方法，此类方法仅依赖用户身份验证来确定用户能否访问我们网络上的资源。它会产生一种风险：不受信任和不安全的设备可能会危害安全性。因此，许多组织已开始转向只有受信任设备才能访问其网络的模式，采取的方法包括利用移动设备管理技术，或在网络层面通过已知设备列表实现访问权限限制。

这些方法尽管有用，但在精细程度上有所欠缺。Atlassian 的零信任方法能有效确保，在决定用户能否访问我们网络上的资源和服务时，不仅以其身份验证凭据为基础，而且还涉及动态策略决策，后者考虑一系列因素来基于用户设备安全状况（不论其位置如何）在各个资源级别上允许或拒绝访问。

简而言之，我们在网络上围绕零信任运作创建了三个资源层（基于其相对重要性和敏感度）：

• 开放层 – 任何成功通过身份验证进入我们网络的企业用户都能访问这些服务
• 低层 – 经过身份验证的企业用户只有在从受信任的公司设备（Atlassian 拥有和管理的设备）或受管理 BYOD（已在 Atlassian MDM 计划中登记的个人设备）访问我们网络时，才能访问这些资源
• 高层 – 经过身份验证的企业用户只有从 Atlassian 发放的公司设备访问时，才能访问这些资源。只有使用高层设备并通过 SAML 身份验证，才能从我们的公司网络访问我们的生产服务

安全地管理对我们系统和服务的访问

Atlassian 制定了一套完善的流程，用于为所有系统和服务调配（分配或撤销）用户访问权限。我们有一套既定的工作流，将我们的人力资源管理系统与我们的访问调配系统联系起来。我们根据预定义的用户个人资料使用基于角色的访问控制，以确保员工只能拥有与其工作角色相称的访问权限。所有用户帐户必须获得管理层批准后，才能访问数据、应用、基础架构或网络组件。

为支持我们的零信任架构，我们利用单一登录平台控制对公司应用的访问。员工若要访问我们的任意应用，均需通过此平台进行身份验证，包括使用第二因素身份验证。根据应用的不同，员工需要使用 FIDO2 密钥或通过调配给 Atlassian 员工的移动应用身份验证器进行身份验证，不支持 SMS 和基于电话的 OTP 等安全性较低的身份验证方法。Atlassian 采用这种方法是为了确保我们的身份验证流程能够有效抵御基于网络钓鱼的攻击和中间人攻击—任何通过短信发送代码的系统都可能被熟练的攻击者入侵。

保护我们的端点设备

公司笔记本电脑

组成 Atlassian 公司机群的设备都经过配置，以保护我们的数据并降低端点被入侵的风险。根据我们的零信任计划，不符合我们批准的标准的设备会自动被禁止访问 Atlassian 系统。

在 Atlassian 公司设备上实施的控制措施包括：

• 中央设备管理 - 我们的 MDM（移动设备管理）解决方案负责执行安全配置（包括 CIS 基准），并为所有 Atlassian 拥有的设备部署软件/更新。
• 应用控制 - 应用控制可防止运行特定类型的合法软件（如远程访问解决方案），这些软件可能会危及我们设备的安全状况。
• 端点防火墙 - 防止本地服务暴露于网络。
• 防病毒/终端检测和响应 (EDR) - 检测和阻止恶意软件，收集日志数据，使我们的安全运营中心能够快速响应安全事件。
• 安全浏览环境 - 对员工使用的所有浏览器进行配置，以防止安装或使用恶意扩展程序，并阻止已知的钓鱼网站或传播恶意软件的网站。
• 磁盘加密/屏幕锁 - 所有设备均已完全加密，并设置为在一段时间不活动后锁定。

移动/BYOD 设备

Atlassian 对于希望使用个人 iOS 或 Android 移动设备访问公司系统的员工实施 BYOD（自带设备）计划。所有移动设备必须：

• 登记到我们的 MDM（移动设备管理）解决方案
• 启用全磁盘加密/屏幕锁
• 运行最新的 Android/iOS 操作系统

在 BYOD 计划下运行的移动设备只能对 Atlassian 系统进行有限访问，不能访问客户数据。

管理我们系统中的配置

只有少数工程师和架构师被允许在我们的生产环境中安装软件。在大多数情况下，无法进行软件安装。在生产环境中，我们利用配置管理工具来管理服务器的配置和更改。如果直接更改这些系统，产生的变更会被通过这些配置管理工具推送的已核准配置覆盖，从而确保一致性。我们使用标准的 Amazon Machine Image (AMI)，对 AMI 或操作系统的所有更改都必须通过我们的标准变更管理流程来进行。我们会跟踪和报告异常配置，而且实施了资源隔离，使得与服务相关的问题不会影响到其他服务。我们还依靠“同行审查/绿色构建”(PRGB) 流程来确保多名审查者对通过配置管理工具推送的配置更改进行审查。所有构建都会经过加密签名，且只有签名的构建才允许在我们的生产环境中运行。

发挥日志的作用

我们使用 SIEM 平台汇总来自各种来源的日志，并将监控规则应用于这些聚合的日志，然后标出所有可疑的活动。我们的内部流程规定了如何对这些警报进行分类、进行深入调查并相应上报。关键系统日志会从每个系统转发，日志在系统中为只读模式。Atlassian 安全团队在安全分析平台上创建警报，并监控数据泄露指标。SRE 团队使用此平台监控可用性或性能问题。日志在热备份中保留 30 天，在冷备份中则保留 365 天。

关键系统日志会被合并到内部日志分析系统和入侵检测系统中。

日志是我们整个事件检测和响应策略的关键组成部分，“如何识别、防范和应对安全威胁”一节对此进行了详细阐述。

业务持续性和灾难恢复管理

我们非常注重产品的弹性，尤其是因为 Atlassian 在内部也依赖于完全相同的产品。我们赞同服务中断难免会发生。因此，我们下决心制定了各种流程，对服务中断进行规划与处理，使中断确有发生时给客户造成的影响降至最低程度。我们的业务持续性 (BC) 和灾难恢复 (DR) 计划囊括了为实现这些目标而开展的各种活动。

领导层参与 BC 和 DR 规划活动，确保所有团队都能获得必要监督，以保证对弹性负责。我们的 BC 和 DR 规划活动通过分析服务的“恢复时间目标”(RTO) 和“恢复点目标”(RPO)，尽可能在成本、效益和风险之间实现相应的平衡。借助此分析，我们建立了一个简易 4 层系统，以根据各自的恢复要求来协助完成服务分组。有关此方法的详细信息，请查看 Atlassian 如何管理客户数据页面。

我们的 BC 和 DR 计划包括以下活动：

1. 内置冗余措施来满足弹性要求

2. 测试和验证这些冗余措施

3. 从测试中学习，以持续改进 BC 和 DR 措施

我们精心打造产品，以充分地利用云服务提供商提供的冗余功能，如可用区域和地区等。

我们持续监控各种各样的指标，以尽早发现潜在的问题。根据这些指标配置警报，在超过阈值时通知现场可靠性工程师 (SRE) 或相关产品工程团队，从而依据我们的事件响应流程迅速采取行动。SRE 还承担一项重要职责：识别 DR 计划中的缺口并通过与风险和合规团队合作来填补这些缺口。我们的每个团队中都有一名 DR 冠军，负责监督和协管与所属团队相关的灾难恢复工作。

我们的 DR 测试涵盖流程和技术方面，包括相关的流程文档。DR 测试的频率是根据每项服务的关键程度等级确定的；例如，面向客户的关键系统的备份与恢复流程每个季度会测试一次。我们对系统进行手动和临时故障转移测试。测试种类既有不太复杂的桌面模拟训练，也有比较复杂的可用区域或地区性故障转移测试。无论测试复杂性高低，我们都会努力采集和记录测试结果，分析和确定可能的进步或差距，然后在 Jira 工作单的帮助下加以完善，以确保整体流程的持续改进。

我们通过开展年度业务影响评估 (BIA) 来衡量与关键服务相关的风险。这些 BIA 的成果有助于推进 DR 和 BC 策略。因此，我们能够为关键服务制定有效的 DR 和 BC 计划。

服务可用性

除上述措施之外，我们还利用自有的 Statuspage 产品为客户实时发布我们的服务可用性状态。如果我们的任何产品出现任何问题，客户都会与我们一样同时获得消息。

备份

Atlassian 执行全面的备份计划。其中包括我们的内部系统，其备份措施符合系统恢复要求。针对 Atlassian Cloud 产品，特别是客户和应用程序数据，我们也制定了广泛的备份措施。Atlassian 采用 Amazon RDS（关系数据库服务）的快照功能为每个 RDS 实例自动创建每日备份。

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

Bitbucket 中的数据会复制到不同的 AWS 区域，并且每个区域每天都在进行独立备份。

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

物理安全

办公室物理安全控制以我们的物理和环境安全政策为指导，确保在我们的内部和云端环境中实施强有力的物理安全举措。该政策涵盖诸多领域，例如确保工作区域安全、保护所有地点的 IT 设备，仅限适当人员进入大楼和办公室，以及对出入口进行监控等。物理安全措施包括工作时间内前台考勤、要求访客登记，以及凭工牌进入所有非公共区域等；此外，我们还与办公楼管理部门合作监控工作时间外人员进出和出入口视频录像（包括主要出入口和装卸货区域）。

我们的合作伙伴数据中心至少达到了 SOC-2 标准。这些认证涉及一系列安全控制措施，包括物理和环境安全与保护。进入数据中心仅限获得授权的人员，并通过生物识别身份验证措施加以核验。物理安全措施包括内部保安人员、闭路视频监控、诱捕系统和其他入侵防护措施。

数据加密

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

Jira Software Cloud、Jira Service Management Cloud、Jira, Bitbucket Cloud、Confluence Cloud、Statuspage、Opsgenie、Trello、Loom、Compass 和 Rovo 中保存客户数据和附件的服务器上的数据驱动器使用全磁盘行业标准 AES-256 静态加密。请参阅 Atlassian Trust 路线图，及时了解我们平台的最新更新。

密钥管理

Atlassian 利用 AWS Key Management Service (KMS) 进行密钥管理。作为 AWS 现有内部验证流程的一部分，AWS 会定期对加密、解密和密钥管理流程进行内部检查和验证。每个密钥都会分配负责人，负责确保对密钥实施适当级别的安全控制。

租户分离

虽然我们的客户在使用 Atlassian 产品时共享一个基于云的通用 IT 基础设施，但我们采取了相关措施来确保逻辑上的分离，以确保某一客户的行为不会损害其他客户的数据或服务。

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

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

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

TCS 提供的上下文有效充当了与客户数据进行所有交互的“镜头”，而这个镜头始终限定于一个特定租户。如此一来，便可确保一个客户租户不会访问其他租户的数据，也使得一个租户的行为不会影响到其他租户的服务。

我们的云支持资源提供了有关我们云架构的更多信息。

共同承担客户数据管理责任

Atlassian 负责为我们提供的应用程序、运行这些应用程序的系统和托管这些系统的环境保障安全性、可用性和性能。但是，安全性是 Atlassian 和客户共同的责任，尤其是以下四个方面：

控制对客户数据的访问

我们在敏感度上对所有客户数据一视同仁，而且实施了严格的控制措施来监管这些数据。我们的内部员工和承包商会在新人培训过程中接受意识培训，内容涵盖处理客户数据的重要性和最佳实践。

在 Atlassian，只有获得授权的 Atlassian 员工才能访问存储在我们应用中的客户数据。身份验证通过各个用密码保护的公钥来完成，服务器只接受从 Atlassian 和内部数据中心位置传入的 SSH 连接。所有访问仅限于特权组，除非另外请求并经过审核，而且还要通过额外的双重身份验证。

借助严格的身份验证和授权控制，我们的全球支持团队为维护和支持流程提供协助。为了满足应用运行状况监控和系统或应用维护的需要，我们会访问托管的应用和数据，或在收到客户通过我们的支持系统所提出的请求时访问这些数据。客户也有相应的选项，可通过同意控制检查器就哪些支持工程师适合访问其数据做出明确许可。

未经授权或不当访问客户数据将被视为安全事件，并通过我们的事件管理流程进行管理。此流程包括在发现违反政策的行为时通知受影响客户的相关操作说明。

保留和删除数据

我们制定了相关规定，以便响应用户删除个人信息的请求。此外，我们还帮助拥有 Atlassian 帐户的最终用户删除其个人信息。另外，我们提供导入和导出工具，以便客户使用 Atlassian 的工具访问、导入和导出数据。

客户的站点会在其当前订阅期结束 15 天后停用。客户当前订阅期结束后，Atlassian 会将已停用站点的数据保留 15 天（评估性站点）或 60 天（付费订阅站点）。请注意，对于 Jira，只有当您取消订阅之前订阅的所有 Jira 产品后，数据才会被删除。

有关更多信息，请参阅我们的安全实践页面或数据存储常见问题解答。