安全实践
我们相信所有团队都能取得惊人的成就。我们的使命是激发每个团队的潜力,不论其规模和行业,并且借助软件的力量推动人类事业的发展。
我们知道,您与我们一样看重自己的使命,而信息是我们所有业务和生活的中流砥柱。正因为如此,我们将赢得客户信任视为工作核心,将安全列为首要任务。我们的每一项安全计划都公开透明,让您掌握充分的信息,放心使用我们的产品与服务。
阅读有关我们安全性方法的更多信息,了解客户如何发挥自己的作用。
除非另行说明,否则本页上的信息适用于 Atlassian Cloud 产品:Jira、Confluence 和 Bitbucket。
我们的安全性方法
本节讨论 Atlassian 的安全性方法,内容涵盖我们在许多安全领域采取的关键举措和控制措施,包括保护我们自己的环境(包括基于云的平台),以及为了确保为客户和用户创建尽可能安全的产品而制定的流程。
我们的安全理念
我们的安全方法基于以下几个核心主题:
- 力求在云和产品安全领域引领同行
- 满足客户对云安全的所有要求,并超越行业安全标准和认证的要求
- 对我们的计划、流程与指标保持开放和透明。这包括分享我们的旅程并鼓励其他云提供商仿效,以及为客户设定新的标准
本节重点介绍为实现这些关键主题所涵盖的理念而采取的一系列措施和举措。
令我们自豪的是,我们的许多旗舰产品支撑并构成了 Atlassian 内部日常流程和工作流的关键组成部分。例如,Jira 和 Confluence 应用程序构成了事件管理和漏洞管理计划方法的关键支柱。这意味着我们在保护自己的产品上投入了巨大力量,不仅因为“不忽悠客户”是我们的一个重要价值观,还因为我们自己也会使用这些产品。
我们的团队
尽管大多数公司都会这样说,但我们对自己的安全团队尤其感到自豪。我们相信,我们组建的团队招募到了业内最优秀、最聪明的人才。我们的安全团队由在旧金山办公的 CISO 领衔,包含来自悉尼、阿姆斯特丹、班加罗尔、奥斯汀、山景城、旧金山和纽约办事处的 100 多位成员,以及一些远程团队成员。鉴于 Atlassian 对安全性的重视,此团队仍在不断壮大。我们设有多个子团队,具体包括:
- 产品安全 – 负责我们产品和平台的安全
- 生态系统安全 – 负责我们 Marketplace 和加载项的安全
- 安全情报 – 负责检测和响应安全事件
- 红色团队 - 负责对手模拟和运用安全情报
- 安全架构 – 负责制定我们产品和平台的安全要求
- 企业安全 – 负责与我们公司网络和应用程序相关的内部安全
- 信任 - 负责跟踪和响应客户的期望,并为我们的流程和实践提供透明度
- 开发和 SRE – 负责开发和运行安全团队需要的工具
- 意识和培训 - 负责确保我们的员工和合作伙伴清楚如何安全地开展工作
在安全团队不断扩大的同时,Atlassian 的每一个人都是我们提升安全性这一使命的一分子,所有员工在我们公司任职期间都清楚这一点。我们力求做到在云安全领域引领同行,满足所有客户的云安全需求,超越所有行业安全标准和认证要求,并且自信地发布有关我们如何保护客户数据的详细信息。所有员工在 Atlassian 任职期间都清楚我们的目标和愿景。
我们用来支持安全的其他计划
在关注安全性基本要素的同时,我们也制定了一系列计划,确保我们的安全方法不但触及面广,而且具有前摄性。其中包括:
安全检测计划
我们的安全检测计划是对 Atlassian 事件响应流程的补充。在标准事件管理流程中,我们嵌入了一项单独计划来主动创建搜索和警报,它不仅面向当前遇到的事件类型,也包括未来威胁趋势中会面临的那些事件类型。
缺陷赏金计划
我们的缺陷赏金计划一直享有业内最佳的美誉。借助这项计划,我们能够利用由数万名研究人员组成的可信社区,持续测试我们的产品并报告发现的所有漏洞。
持续改进我们的安全计划
我们致力于确保我们的安全计划立足于前沿并领先于同行。我们知道,想要做到这一点,需要通过不断评估目前的安全方法(包括与业内同行比较)来确定有待改进的地方。
为此,我们邀请独立安全咨询公司对我们的安全计划进行成熟度评估,此类评估已多次进行,且会持续开展。2020 年,我们还对整体信任与安全计划进行了同行评估。我们通过这些过程来吸收养分,包括重要的建议,利用它们来填补缺口和改进提高。
此外,我们在各个安全领域制定了一系列计划,例如产品安全和安全情报等,以指导我们的内部改进。我们建立了各项指标来支持这些计划,并通过安全管理团队进行审查。这些指标可用于确定和瞄准每个核心功能需要改进的地方。
更多信息
本文提供了我们安全性方法的综合概览。有关更多安全计划相关信息,请访问 Atlassian Trust Center。另外,我们还有一系列专门的网页和白皮书从不同方面详细介绍了我们的安全计划,其中包括:
保护我们的内部环境
有效的安全性方法始于做好内务,特别是确保自己内部环境的安全。我们采取了若干举措来实现这一目标。
在网络架构中内建安全性
Atlassian 采取一种分层式方法确保我们网络的安全。在云环境的每个层面上实施控制措施,按照区域、环境和服务划分我们的基础设施。我们设立了区域限制,包括对办公室/员工、客户数据、CI/CD 和 DMZ 网络流量施加限制。另外还进行了环境分割,以限制生产环境与非生产环境之间的连接,使生产数据不会被复制到生产环境之外。只有在处于同样的网络时,才能访问生产网络和服务。例如,惟有生产服务方可访问其他生产服务。
服务必须经过明确授权,以借助身份验证允许列表与其他服务进行通信。我们使用虚拟私有云 (VPC) 路由、防火墙规则和软件定义网络来控制对敏感网络的访问,并对这些网络的所有连接进行加密。我们还在办公室和生产网络中实施了入侵检测,以检测潜在的数据泄露。
通过零信任保护对我们网络的访问
为保护对公司网络、内部应用程序和云环境的访问,Atlassian 贯彻一种被称为“零信任”的理念。简单地说,零信任的核心原则是“从不信任,始终验证”。
零信任摒弃了传统的网络安全性方法,此类方法仅依赖用户身份验证来确定用户能否访问我们网络上的资源。它会产生一种风险:不受信任和不安全的设备可能会危害安全性。因此,许多组织已开始转向只有受信任设备才能访问其网络的模式,采取的方法包括利用移动设备管理技术,或在网络层面通过已知设备列表实现访问权限限制。
这些方法尽管有用,但在精细程度上有所欠缺。Atlassian 的零信任方法能有效确保,在决定用户能否访问我们网络上的资源和服务时,不仅以其身份验证凭据为基础,而且还涉及动态策略决策,后者考虑一系列因素来基于用户设备安全状况(不论其位置如何)在各个资源级别上允许或拒绝访问。
简而言之,我们在网络上围绕零信任运作创建了三个资源层(基于其相对重要性和敏感度):
- 开放层 – 任何成功通过身份验证进入我们网络的企业用户都能访问这些服务
- 低层 – 经过身份验证的企业用户只有在从受信任的公司设备(Atlassian 拥有和管理的设备)或受管理 BYOD(已在 Atlassian MDM 计划中登记的个人设备)访问我们网络时,才能访问这些资源
- 高层 – 经过身份验证的企业用户只有从 Atlassian 发放的公司设备访问时,才能访问这些资源。只有使用高层设备并通过 SAML 身份验证,才能从我们的公司网络访问我们的生产服务
Atlassian 的零信任实施利用一系列自动化流程、服务和组件来运作。从高层来看:
- 我们的 Trust Engine 服务向使用公司或受管理 BYOD 设备并经过身份验证的用户颁发证书。证书含有标记其适用于 BYOD 或公司设备的元数据,利用我们的端点管理解决方案部署到设备上,并定期重新颁发(或撤销)
- 用户进行身份验证时,会请求其提供证书并出示给我们的基础设施。证书中的信息用于验证用户的帐户是否有效,核验其所拥有设备的类型。基于这些信息,用户被推送到我们的低层网络中,并在网络和应用程序访问上受到一定限制,或者被授予访问我们高层网络的权限。连接到 Atlassian 网络的设备每小时轮询一次,并与我们的端点管理解决方案交叉引用,以确定所有权、设备安全性和状态信息。这包括确保设备符合最低要求,例如反恶意软件、加密、操作系统版本等方面的要求
- 利用有关用户设备合规性的信息更新一个中央数据库。这用于确定要允许还是拒绝用户访问我们网络上的资源。标记为不合规的设备将被终止与我们网络的连接。
Atlassian 撰写了一份单独的文件来说明我们的零信任架构理念和实施。
安全地管理对我们系统和服务的访问
Atlassian 制定了一套完善的流程,用来调配(分配或撤销)所有系统和服务的用户访问权限。我们建立了一套工作流程(8 小时同步),将人力资源管理系统与访问调配系统相关联。我们以预定义的用户个人资料为基础,使用基于角色的访问控制来确保员工仅拥有与其工作岗位相称的访问权限。所有用户帐户必须获得管理层批准后,才能访问数据、应用程序、基础设施或网络组件。
为支持我们的零信任架构,我们利用单一登录平台控制对公司应用程序的访问。员工若要访问我们的任意应用程序,均需通过此平台进行身份验证,其中包括使用第二重身份验证。用户需要使用 U2F 密钥或配置给 Atlassian 员工的移动应用程序身份验证器进行身份验证。我们已剔除不太安全的身份验证方法,例如基于短信和电话的 OTP。Atlassian 采用这种方法来确保身份验证过程能有效抵御基于网络钓鱼的攻击和中间人攻击,而任何以短信形式发送代码的系统都有可能受到熟练攻击者的破坏。
保护我们的端点设备
Atlassian 使用一套端点管理解决方案,将更新和修补程序部署到整个端点群的操作系统和关键应用程序。我们还实施了多种端点保护解决方案,以防范恶意软件等威胁。
作为我们零信任方案的一部分,Atlassian 员工需要在我们的移动设备管理 (MDM) 计划中登记后,才能通过自己的个人移动设备访问我们的大多数服务。这样可以确保所有连接到我们网络的移动设备都符合我们的最低安全要求,包括加密、设备锁定、反恶意软件和操作系统版本等方面的要求。
所有符合条件的员工只要进行登记并保持遵守我们的 MDM 计划,就能获得 Atlassian 针对参与此计划而发放的每月津贴。
若有任何设备被确定为不合规,相关员工将收到不合规行为告知电子邮件。员工可以在 24 小时宽限期内改正不合规行为,否则会被撤销其设备的访问权限。
我们的日常运营安全
我们奋力将安全性纳入日常运营流程的所有方面。我们希望安全性成为我们行事方式的固有组成部分,以最大限度降低事后“改造”或“加装”安全性的必要。
跟踪我们的信息资产
我们的生产系统位于通过云服务提供商获得的基础设施内。出于服务性质,我们不会在硬件层面上跟踪这些系统。支撑我们产品运行的底层微服务在定制的“服务”数据库中进行跟踪。该数据库会在部署服务时自动更新。
我们的工作场所技术团队使用我们自己的 Jira 软件来维护所有端点的资产清单,从而满足跟踪需求。
管理我们环境中的变更
我们的变更管理流程与传统的流程略有不同。传统的变更管理流程依赖于金字塔式变更控制层次结构。换言之,有人想要进行更改时,必须提交到董事会进行最终审批。
我们采用一种开源风格的方法,它被称为“同行审查,绿色构建”(PRGB)。与传统变更管理流程不同,PRGB 方法要求每项变更(不论是代码更改还是基础设施变化)均需由一名或多名同事进行审查,以确定变更可能造成的所有问题。我们根据变更的关键程度或受变更影响的系统的重要程度来增加审查者人数,同时相信我们的工程师能够识别问题,并在变更完成之前标出这些问题。此流程有效提供了一种动态且适应性强的方式,来管理我们环境中的变更。控制措施的绿色构建部分是指在 CI/CD 中利用所含的新变更进行成功或纯净的构建。如果变更引入的组件未通过任何集成、功能、单元或安全测试,则会拒绝此构建并返回到原始变更请求以解决所有问题。
管理我们系统中的配置
只有少数工程师和架构师被允许在我们的生产环境中安装软件。在大多数情况下,无法进行软件安装。在生产环境中,我们利用配置管理工具来管理服务器的配置和更改。如果直接更改这些系统,产生的变更会被通过这些配置管理工具推送的已核准配置覆盖,从而确保一致性。我们使用标准的 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 产品和数据由业界领先的云托管提供商 Amazon Web Services (AWS) 托管。我们在全球利用冗余和故障转移选项来优化性能。我们利用 AWS 多个不同地理位置的区域(美东和美西、欧盟以及亚太地区),以及每个区域内的多个可用区,确保任何单一数据中心的故障不会影响我们产品或客户数据的可用性。有关更多信息,请参阅关于 Atlassian 如何管理客户数据的专题文章和云托管基础设施页面。
进入存储有客户数据的数据中心仅限获得授权的人员,并使用生物识别措施验证访问权限。我们数据中心的物理安全措施包括内部保安人员、闭路视频监控、诱捕系统和其他入侵防护措施。
数据加密
Atlassian 云产品中存储的所有客户数据在通过公共网络传输时,均会使用具有完全向前保密性 (PFS) 的 TLS 1.2+ 进行加密,避免客户数据遭受未经授权的披露或修改。在实施 TLS 时,我们强制使用浏览器支持的强密码和密钥长度。
Jira Software Cloud、Jira Service Management Cloud、Jira, Bitbucket Cloud、Confluence Cloud、Statuspage、Opsgenie 和 Trello 中保存客户数据和附件的服务器上的数据驱动器使用全磁盘行业标准 AES-256 静态加密。请参阅 Atlassian Trust 路线图,及时了解我们的平台更新。
密钥管理
Atlassian 利用 AWS Key Management Service (KMS) 进行密钥管理。AWS 定期对加密、解密和密钥管理流程进行内部检查和验证,以作为其现有内部验证流程的一部分。每个密钥都会分配负责人,负责确保对密钥实施适当级别的安全控制。
租户分离
虽然我们的客户在使用 Atlassian 产品时共享一个基于云的通用 IT 基础设施,但我们采取了相关措施来确保逻辑上的分离,以确保某一客户的行为不会损害其他客户的数据或服务。
Atlassian 实现此目标的方法视具体应用程序而异。对于 Jira 和 Confluence Cloud,我们使用称为“租户上下文”的概念来实现逻辑上的客户隔离。它既会在应用程序代码中实施,也会通过我们开发的名为“租户上下文服务”(TCS) 的服务进行管理。这一概念可确保:
- 每一客户的数据在静止时与其他租户在逻辑上隔离
- 由 Jira 或 Confluence 处理的任何请求都具有“特定于租户的”视图,因而不会影响到其他租户
从宏观而言,TCS 通过为各个客户租户存储一个“上下文”来运作。每一租户的上下文都与 TCS 集中存储的唯一 ID 相关联,其中包括与该租户关联的一系列元数据(例如租户所在的数据库、租户拥有的许可证、他们可以访问的功能,以及各种其他配置信息)。当客户访问 Jira 或 Confluence Cloud 时,TCS 会使用租户 ID 对该元数据进行校对,然后将元数据与租户在整个会话期间在应用程序中执行的所有操作关联起来。
TCS 提供的上下文有效充当了与客户数据进行所有交互的“镜头”,而这个镜头始终限定于一个特定租户。如此一来,便可确保一个客户租户不会访问其他租户的数据,也使得一个租户的行为不会影响到其他租户的服务。
我们的云支持资源提供了有关我们云架构的更多信息。
共同承担客户数据管理责任
Atlassian 负责为我们提供的应用程序、运行这些应用程序的系统和托管这些系统的环境保障安全性、可用性和性能。但是,安全性是 Atlassian 和客户共同的责任,尤其是以下四个方面:
政策和合规
确保系统满足客户的业务需求, 并且其运行遵守行业、监管 和法定的合规义务。
用户
用户帐户的创建和管理。
信息
客户存储在 Confluence Cloud、Jira Cloud、Trello 或 Bitbucket Cloud 中的内容。
Marketplace 应用
与 Atlassian 产品集成的第三方服务。
尽管 Atlassian 采取了所有必要措施来保护客户数据的安全,但现实情况是,客户就如何设置我们产品做出的决策也会对安全性的实施方式产生重大影响。客户在使用我们的产品时需要注意以下重要事项:
- 域验证和集中管理用户帐户 – 客户组织的管理员可以验证一个或多个网域,以证明其所有权。借助域验证,管理员能够集中管理所有员工的 Atlassian 帐户,并应用身份验证策略(包括密码要求和 SAML)。这一步非常重要,我们强烈建议所有客户执行此步骤,以便协助保护其帐户访问和相关数据的安全。
- 访问权限 – 虽然我们的产品本质上是为实现协作而设计,但客户在向组织内用户授予数据访问权限时确实需要谨慎行事。在某些情况下,客户还可能允许公众访问数据 – Atlassian 无力掌控此类行为,也无法在此类情况下阻止复制或进一步分发此类数据。
- 集中访问 – 强烈建议客户利用 Atlassian Guard 集中管理使用的所有 Atlassian 产品并增强安全性(包括使用强制双重身份验证和单一登录)
有关更多信息,请参阅我们关于云安全共同责任的文章。
控制对客户数据的访问
我们在敏感度上对所有客户数据一视同仁,而且实施了严格的控制措施来监管这些数据。我们的内部员工和承包商会在新人培训过程中接受意识培训,内容涵盖处理客户数据的重要性和最佳实践。
在 Atlassian,只有获得授权的 Atlassian 员工才能访问存储在我们应用程序中的客户数据。身份验证通过各个用密码保护的公钥来完成,服务器只接受从 Atlassian 和内部数据中心位置传入的 SSH 连接。所有访问仅限于特权组,除非另外请求并经过审核,而且还要通过额外的双重身份验证。
借助严格的身份验证和授权控制,我们的全球支持团队为维护和支持流程提供协助。为了满足应用程序运行状况监控和系统或应用程序维护的需要,我们会访问托管的应用程序和数据,或在收到客户通过我们的支持系统所提出的请求时访问这些数据。客户也有相应的选项,可通过同意控制检查器就哪些支持工程师适合访问其数据做出明确许可。
未经授权或不当访问客户数据将被视为安全事件,并通过我们的事件管理流程进行管理。此流程包括在发现违反政策的行为时通知受影响客户的相关操作说明。
保留和删除数据
我们制定了相关规定,以便响应用户删除个人信息的请求。此外,我们还帮助拥有 Atlassian 帐户的最终用户删除其个人信息。另外,我们提供导入和导出工具,以便客户使用 Atlassian 的工具访问、导入和导出数据。
客户的站点会在其当前订阅期结束 15 天后停用。客户当前订阅期结束后,Atlassian 会将已停用站点的数据保留 15 天(评估性站点)或 60 天(付费订阅站点)。请注意,对于 Jira,只有当您取消订阅之前订阅的所有 Jira 产品后,数据才会被删除。
有关更多信息,请参阅我们的安全实践页面或数据存储常见问题解答。
保护员工安全
我们致力于确保所有员工都清楚如何安全开展工作,并且有能力采取相应的措施。深入的安全思维处于 Atlassian 文化的最前沿,并可帮助提升我们抵御潜在网络攻击的整体弹性。
安全意识培训
我们确保所有员工在新人培训期间接受安全意识培训,再不断加以巩固,以便使安全意识成为一种“本能思维”。我们知道,我们团队面临的许多威胁同样也是与我们合作的承包商和其他合作伙伴所面临的,因此我们还将安全意识培训延伸到这些承包商和合作伙伴。安全意识培训计划涉及的主题包括当下的威胁和诈骗、安全工作实践、造成安全风险的潜在危险行为,以及合规和监管问题。
除了常规信息安全培训外,我们的开发人员还会获得更有针对性的安全编程培训。开发团队还有其他方面的支持,例如在这些团队中派驻安全工程师,以协助完成与安全相关的操作任务。
另外,我们还通过即时消息通道、博客文章、常见问题解答等,在员工和安全团队之间保持一个开放的沟通渠道,从而尽可能让所有 Atlassian 员工都能与安全团队交流。
Atlassian Security 在 10 月份面向所有员工和合作伙伴举办了安全意识月,以此庆祝每个人在保护我们公司安全方面取得的成就,并通过趣味游戏和内部会谈来加强具有重要意义的安全教育。
安全冠军计划
我们的安全冠军计划包括每个产品和服务团队中忠实的安全推广人员。这位专属安全领头人负责在团队成员之间推广重要的安全实践,并与我们的中央安全团队协同处理安全问题,以促进改善沟通流程。
我们的安全冠军还有高级应用安全培训,帮助他们识别漏洞、了解安全开发实践,以及编写安全代码。
Atlassian 的安全冠军会定期碰头,围绕面临的最新安全问题和挑战分享各种工具和知识,为所有团队造福。该计划充当了一种跳板,让安全成为我们文化更加不可分割的组成部分。
背景调查
我们期待优秀人才的加入,继续积极塑造我们建立的安全为本文化。在当地法律允许的情况下,我们会对所有新进员工进行背景调查,从而协助推动此过程。根据职位的不同,背景调查可能包括犯罪记录检查、教育背景核查、就业情况核查和信用检查。
保护产品安全
Atlassian 致力于确保安全性成为我们产品生命周期中所有阶段的关键组成部分。我们运用了多种方法来实现此目标。
安全记分卡
我们致力于确保整个产品套件都以安全为先,以安全为本。为此,我们采用了一个被称为“产品安全记分卡”的问责与监控系统,以衡量 Atlassian 所有产品的安全状况。这是 Atlassian 开发的一个自动化流程,使用一系列以安全为中心的标准(例如当前的漏洞、培训覆盖范围和最近的安全事件),为我们的每款产品提供总体安全评分。
借助此评分流程,每个产品团队都能客观地了解需要关注哪些安全领域,并确定需要填补的现有缺口以及应采取的措施。安全记分卡流程还使 Atlassian 安全团队能够轻松地从安全角度追踪所有产品在不同时间的表现,尤其是在我们产品套件的规模不断扩大的时候。
安全合作伙伴
我们的产品安全团队在运行一项安全合作伙伴计划,为产品团队提供指导,并确保将安全流程整合到开发生命周期中。我们大部分的安全关键产品都通过该计划获得支持,或者是专门的安全合作伙伴,或者是面向其他团队轮转的工程师。安全合作伙伴提供安全咨询支持,还帮助团队监控、解释和快速响应通过记分卡系统确定的发现结果。
定向安全保障
产品安全团队还运行一项安全审查流程,为各个软件项目提供安全保障。使用基于风险的流程来排定重点保障活动的优先顺序,并确定需要采取哪些行动来降低项目风险。根据确定的风险级别,保障活动包括以下各项的组合:
- 威胁建模
- 设计审查
- 代码审查(手动和工具辅助)
- 安全测试
- 独立保障(借助第三方专家研究人员和顾问)
正如我们在本文其他章节所述,我们还设立了一项行业领先的“缺陷赏金计划”,借助值得信赖的众包安全研究人员小组来提供持续的安全保障。
通过威胁建模确保安全设计
在我们产品的规划和设计阶段进行威胁建模,以便在项目面临复杂威胁或涉及安全关键功能开发时更好地了解安全风险。这包括在我们的工程师、安全工程师、架构师和产品经理之间举行桌面/头脑风暴会议,以识别相关威胁并确定其优先顺序。这些信息将馈入设计过程,并确保实施适当的控制措施。它还有助于在开发的后期阶段进行定向审查和测试。
代码分析
我们建立了一个自动化代码分析平台(称为“安全助手”),涵盖 Atlassian 的所有代码存储库。此平台运行各种静态分析工具(并不断增添和改进),以协助确保我们代码的整体安全性。无论何时在存储库中提出拉取请求,该平台都会:
- 查找并确定可能引发漏洞的过时代码依赖项(下文阐述漏洞管理方法时会深入讨论)
- 识别代码存储库中任何意外或无意泄露机密的情况(例如,身份验证令牌或加密密钥)
- 进行分析,以确定任何可能在代码中引发漏洞的可疑编码模式
安全知识库
为确保我们打造出尽可能安全的产品,我们保证开发人员都能获得所需的支持,不断地在应知晓的相关安全问题和威胁方面积累知识。为此,我们在内部维护了一个应用安全知识库,供开发人员随时访问。
如何识别、防范和应对安全威胁
安全测试
我们的安全测试方法是围绕“持续保障”概念构建的,它不仅利用了有针对性的时间点渗透测试,而且还有使用众包缺陷赏金计划的持续测试模型。我们相信,这种多管齐下的方法能最大限度增加我们发现漏洞的机会,并为客户提供尽可能安全的产品。有关更多信息,请参阅我们关于外部安全测试方法的专题文章;同时,下方也提供了我们测试措施的摘要:
- Atlassian 安全审查 — 如上所述,我们的产品安全团队运行一项安全审查计划,其中包括以定期活动形式进行安全测试。测试包括代码审查和应用安全测试,并专门针对风险评估中突出的薄弱区域
- 第三方安全测试 — 我们邀请专业安全咨询公司对高风险产品和基础架构(无论是云环境、新产品还是基础体系结构重建)进行白盒、代码辅助和基于威胁的渗透测试
- Atlassian 红色团队 – 我们在内部设立一个红色团队,负责模拟试图识别和利用我们系统、流程和环境中漏洞的对手,确保尽快识别和解决这些漏洞
- 缺陷赏金计划 - 我们还利用 Bugcrowd 的可信安全研究人员社区来运行备受赞誉的缺陷赏金计划,从而持续识别产品中的漏洞,并最终让不良分子发现和利用这些漏洞的代价随着时间推移而不断提高。我们的缺陷赏金计划已多次被评为业界最佳。缺陷赏金计划涵盖了我们 25 种以上的产品或环境,涉及服务器产品、移动应用和云产品等。
以下报告中发现的任何安全漏洞都会在我们的内部 Jira 中进行跟踪,它们通过缺陷赏金计划的引入流程进入我们系统,而且来自缺陷赏金计划的任何发现都将根据我们的安全漏洞服务级别目标 (SLO) 进行分类和跟踪。
- 下载最新的 Atlassian 缺陷赏金报告 (2024-07)
- 下载最新的 Halp 缺陷赏金报告 (2024-07)
- 下载最新的 Jira Align 缺陷赏金报告 (2024-07)
- 下载最新的 Opsgenie 缺陷赏金报告 (2024-07)
- 下载最新的 Statuspage 缺陷赏金报告 (2024-07)
- 下载最新的 Trello 缺陷赏金报告 (2024-07)
漏洞管理
Atlassian 一直致力于降低我们产品、服务和基础设施中漏洞的严重程度和发生频率,同时确保已识别的漏洞尽快得到修复。为此,我们采用了一种多管齐下且不断改进的漏洞管理方法,同时将自动化和手动流程用于识别、跟踪和修复我们产品和基础设施中的漏洞。
我们可通过各种不同的来源识别安全漏洞,例如:自动扫描程序、内部安全审查、客户报告和公开缺陷赏金计划。一旦识别漏洞,就会在我们专门构建的全公司漏洞跟踪 Jira 项目中记录一张工作单,并将其分配给相关系统所有者或工程团队。通过采用集中化方法,我们能够利用 Automation 实现主动通知、自动上报和企业通报,从而确保及时修复漏洞。
有关更多信息,请参阅我们专门就 Atlassian 漏洞管理方法撰写的文章。
基础设施
我们使用一系列漏洞检测工具,在我们的基础设施中定期运行来自动扫描和识别漏洞。具体包括:
- 网络扫描 – 识别我们环境中活跃的服务、开放的端口和运行的应用程序,以及网络级别的所有漏洞
- 持续资产发现 – 在外部网络边界进行持续的资产发现和安全分析。另外还有在内部开发的资产清点和发现机制
- AWS 配置监控 – 根据建立的配置基准来监控我们 AWS 环境的配置
我们不断地审核可用的最新工具,如果认为它们能增强我们的漏洞检测能力,就会将其添加到我们使用的套件中。
产品
在我们的开发流程中,除了前文提到的缺陷赏金计划,我们还使用了一系列工具,尽力在客户和用户访问我们产品之前,更多地识别出产品中的漏洞和缺陷并加以防范。我们借助一个平台将这些工具部署到我们的代码存储库。具体包括如下内容:
- Atlassian 的大部分服务是使用 Docker 容器镜像来部署的。这些镜像提供了一个封装的独立环境,包含相关的系统库、工具、配置设置和任何其他所需的依赖项,可以让我们的产品在运行时无视具体的机器配置参数。我们将完整的容器安全扫描流程集成到 CI/CD 管道中,面向所有部署到我们开发、暂存或生产环境中的容器
- 我们的产品和服务依赖于众多开源库。我们搭配使用各种内部构建、开源和商业工具,来扫描和识别依赖项,并将其与已知安全漏洞数据库进行比对
此外,如果有用户在正常使用产品期间发现漏洞,我们欢迎其告知我们,并就提交的任何漏洞迅速做出响应。在调查和回应问题时,我们也会向提交者通报最新消息。
正如前文所述,我们采用了一个称为“同行审查,绿色构建”(PRGB) 的流程;这意味着,对产品的任何代码更改都会由一名或多名同事进行审查,以识别这项变更可能导致的所有问题。
我们有正式成文的缺陷修复政策来规定解决产品中安全问题的时限,具体取决于缺陷的严重程度。
此处提供了有关我们缺陷修复政策的更多信息。另外,还可以访问我们对外公开的缺陷跟踪器,了解最近修复的缺陷以及我们正在为各种产品解决的缺陷。
事件响应
Atlassian 采取一种全面的方法来处理安全事件。在我们看来,安全事件是对客户数据、Atlassian 数据或 Atlassian 服务的机密性、完整性或可用性造成负面影响的任何情形。
我们有一个界定明确的内部框架,内含针对不同事件类型编写的行动手册。该框架囊括了我们在事件响应的所有阶段上需要采取的步骤,以确保我们的流程保持一致、可以重复并且效率突出。其中包括事件检测与分析、事件分类、遏制、消除和恢复。我们在事件响应流程中使用自己的产品来支持这种一致性,例如 Confluence、Jira 和 Bitbucket 等:
- Confluence 可用于在一个集中位置创建、记录和更新我们的响应流程
- Jira 可用于创建工作单,以全程跟踪(潜在和实际的)安全事件的响应流程进度
- Bitbucket 可用于开发基于代码的解决方案,以响应某些事件引起的特定极端问题
对我们的产品和基础设施进行全面、集中的日志记录与监控,以确保在协调高效响应方面经验丰富的高素质待命事件经理的支持下,能快速检测潜在的事件。我们还与一批外部专家建立关系,协助我们尽可能高效地开展调查并做出响应。
如果已确认的事件涉及客户的数据,我们会根据流程告知相关客户。我们也有可靠的事后审查流程,帮助我们从事件中汲取经验教训,以改进我们的实践方法,并让恶意行为者以后更难得逞。有关更多信息,请参阅我们 Atlassian Trust Center 中关于安全事件管理方法的专题文章。
安全检测计划
由于威胁格局日益复杂,我们需要进一步深化事件管理方法,因此 Atlassian 推出了我们口中的“安全检测计划”。这种检测是根据计划定期主动搜索 Atlassian 的安全事件和事件管理平台,从而侦测以 Atlassian 及其客户为目标的恶意活动。
我们的安全情报团队专注于定期创建新的检测,调整并改进现有的检测,以及自动响应检测结果。他们的工作覆盖多个维度,包括产品、攻击类型和日志源等,从而确保我们的检测范围尽可能有效并且全面。
这项计划旨在确保我们从容应对目前面临的威胁,同时充分预测并准备好应对未来的威胁局面。我们的安全情报团队还开发了一款工具来标准化我们创建的检测,确保执行的检测具有高水准的一致性和质量。据我们所知,这一做法属于业内首创。
有关我们的安全检测计划的更多信息,请访问此页面。
Red Team 计划
Atlassian Red Team 的使命是不断提高 Atlassian 抵御复杂攻击的能力。他们从敌对的角度出发,发现我们在技术、物理和社会方面的漏洞,从而挑战我们团队在真实条件下的反应能力。此方法可让我们为 Atlassian 开发并推动有效的安全改进措施。我们的方法可帮助 Atlassian 评估威胁、保护我们的资产并对真实攻击做出适当响应。
Atlassian 的 Red Team 专注于全方位对抗性仿真。我们会模拟最有可能针对公司的攻击者,并尽力渗透和破坏关键系统。之后,我们会通知所有相关人员,并共同实施长期且可持续的解决方案来解决所发现的安全漏洞。
- 衡量并提高“安全情报”计划的有效性
- 在 Atlassian 安全态势和能力方面产生重大的积极变化
- 加深对我们自身的弱点以及应对现实世界攻击的能力的了解
保护生态系统和供应链合作伙伴
供应商风险管理
在 Atlassian 与任何第三方供应商(包括承包商和云服务提供商)合作时,我们致力于确保这些合作不会以任何方式危害我们的客户或其数据。为此,法务和采购团队会对任何拟议的第三方供应商合约进行审核。对于认定为有较高或重大风险的任意合作项目,我们的安全、风险和合规团队都将进一步进行审查。此后,我们还会进行持续的尽职调查,具体根据合作的风险等级在合约续签之时或每年进行审查。
此外,Atlassian 要求供应商在与我们合作过程中遵守最低安全要求。相关要求会通过纳入到我们的供应商合约来实施。具体要求取决于合作的风险等级,包括:
- 与 Atlassian 的单一登录平台进行 SMAL 集成
- 使用未淘汰的算法对传输中和静止时的数据进行加密
- 建立充分的日志记录机制,为 Atlassian 提供与潜在安全事件相关的信息
Atlassian Marketplace
Atlassian Marketplace 是一个可供产品用户购买各种应用的平台,这些应用或是能为 Atlassian 产品添加功能,或是能使我们的产品与第三方工具连接。尽管 Marketplace 上的大多数应用是由第三方开发人员发布,但 Atlassian 采取了诸多措施来确保安全性依然是 Marketplace 生态系统的核心组成部分。其中包括:
Marketplace 缺陷赏金计划 — Atlassian 设立了一流的 Marketplace 缺陷赏金计划,旨在提高所有 Marketplace 应用的安全性和信任度。参与的 Marketplace 合作伙伴通过激励安全研究人员找出漏洞,从而主动对抗安全风险,防患于未然。应用必须参与此计划才能获得 Cloud Fortified 或 Cloud Security Participant 徽章。了解更多
Ecoscanner - Atlassian 的 Ecoscanner 平台会持续对所有 Marketplace Cloud 应用执行安全检查。借助 Ecoscanner,Atlassian 会持续监控所有 Marketplace Cloud 应用是否存在常见安全漏洞,从而确保我们生态系统的安全性。了解更多
漏洞披露计划 - 漏洞披露计划为客户或安全研究人员提供了另一个向 Atlassian 和 Marketplace 合作伙伴报告 Cloud 应用漏洞的渠道。Atlassian 负责运行此计划并定义相关参数,以便 所有 Cloud 应用都能降低安全风险。了解更多
Cloud 应用安全要求 - Atlassian 定义了一系列最低安全要求,且所有 Marketplace 应用均须遵守。这些强制性要求旨在确保所有应用都执行安全最佳实践。了解更多
安全缺陷修复政策 - 为了确保 Atlassian 生态系统中所有应用的安全性,所有 Marketplace 合作伙伴均须遵守适用于 Atlassian Marketplace 上列出的所有应用的安全缺陷修复 SLA。如果检测到漏洞,合作伙伴需及时修复漏洞。了解更多
安全自行评估计划 - Marketplace 自行评估计划是在 Atlassian 和应用合作伙伴之间开设的一项协作,旨在改进 Cloud 应用的安全实践。计划参与者需完成由 Atlassian 审核和批准的年度安全评估。应用必须参与此计划才能获得 Cloud Fortified 徽章。了解更多
Atlassian Marketplace Trust Center提供了有关 Marketplace 中安全性方法的更多信息。
合规与风险管理
政策与风险管理计划
Atlassian 以 ISO 27001 信息安全管理系统标准为基础,制定了信任管理计划 (TMP)。该计划纳入了客户的安全需求,形成了 Atlassian 独有的一系列安全要求,同时兼顾了各种国际安全标准中列出的控制措施。
接着,我们会思考这些控制措施是否适合我们特定的环境和公司,并寻找最适合的方式来实施这些控制措施。我们的 TMP 有多个支柱:
- 我们的政策管理计划 (PMP) – PMP 构成了我们 TMP 的基石。它由一系列安全策略构成,涵盖 ISO 27001 标准和云安全联盟的云控制矩阵 (CCM) 中所列各项领域。我们将创建的安全策略提供给内部的所有团队,确保他们了解在安全方面应达到的标准。这些政策每年都会更新,尤其是当我们发现需对安全性方法进行修改的新威胁和风险时。您可在此处查看我们技术策略的摘录。
- 我们的风险管理计划 (RMP) – 我们对环境和产品进行持续的风险评估以衡量当前面临的风险,并确保现有控制措施能有效管控这些风险。风险评估的执行方式视评估的环境/产品而异。例如,对于我们的产品,通常是技术风险评估或代码审查。不过,我们也会考虑并设法揭示更高级别的业务风险。我们通过开展年度风险评估来支持我们的企业风险管理计划,且至少每个季度都会实施各种项目来缓解已发现的风险。如需有关我们企业风险管理方法的更多信息,请访问 Atlassian Trust Center。
我们的 TMP 包括每周合规性状况审查和其他会议,并在内部做相应记录,以确保其继续有效执行。
遵守法律、法规和标准
我们的安全计划是按照许多行业标准制定和运行的。遵守众所周知的行业标准,是我们安全性方法不可或缺的一个部分,因为我们清楚这些标准能向客户提供独立的保证,确保 Atlassian 的安全计划符合安全控制的基准。
以下是我们遵守的部分重要标准:
ISO 27001 | ISO 27001 的中心思想是开发和实施信息安全管理系统 (ISMS),然后通过借助 ISMS 来实施和管理“ISO 27001:附件 A”中所述的一系列控制措施。
ISO/IEC 27018 是一套实践准则,为适用的 ISO/IEC 27002 控制措施提供了额外的实施指导,以保护云环境中的个人身份信息 (PII)。 |
PCI-DSS | 当您使用信用卡购买 Atlassian 产品或服务时,您可以放心,我们妥善处理交易,确保用卡安全。Atlassian 是符合 PCI-DSS 标准的商家。 |
CSA CCM/STAR | CSA 的“安全、信任与保障注册表”(STAR) 是一个可公开访问的免费注册表,记录了由各种云计算产品提供的安全控制措施。您可以从云安全联盟的 STAR 注册表下载 Atlassian 的 CSA STAR 1 级问卷。 |
SOC2 和 SOC3 | 这些报告可帮助我们的客户及其审计人员了解 Atlassian 为支持运营和合规性而确立的控制措施。Atlassian 的许多产品已获得 SOC2 认证。 |
GDPR | 我们理解,客户需要满足《全球数据保护条例》(GDPR) 规定的要求,而这直接受到他们使用 Atlassian 产品和服务的影响。因此,我们投入了大量资源来帮助客户达到 GDPR 规定的要求。 要深入了解我们如何实现 GDPR 合规性,请访问 Atlassian GDPR 合规性页面。 |
FedRAMP | 联邦风险和授权管理计划 (FedRAMP) 是覆盖整个美国联邦政府的一项计划,它可为云产品与服务的安全评估、授权和持续监控提供标准化方案。 在 FedRAMP Marketplace 中查看以下 Atlassian 产品的状态:
|
除了上述内容之外,我们的合规性计划页面上完整列出了我们遵守的各种行业标准。
Atlassian 的隐私保护
Atlassian 有一套全面的隐私计划,以确保我们满足全球数据隐私保护的最高标准。我们的数据管理工具和流程也旨在帮助您履行隐私义务。我们在 Trust Center 和隐私策略中分享了有关采取了哪些步骤来符合全球各类隐私法律(其中包括欧洲和加利福尼亚的法律)的信息,并总结了我们如何帮助您遵守隐私法律。示例包括:
- 从设计着手保护隐私:我们从设计入手,在我们的产品中集成了隐私保护,如“隐私原则”页面所述
- 详细分析:我们致力于进行数据保护影响评估,以确保妥善处理数据,并酌情与监管机构协商
- 访问控制和培训:访问和处理 Atlassian 客户个人数据的 Atlassian 员工均接受了有关如何处理这些数据的培训,并且一定会保持其机密性和安全性
- 用户个人资料和隐私工具:用户能够自定义其个人资料设置,如我们的面向用户的隐私页面所述
- 管理员隐私工具:我们为客户提供有关我们如何处理客户数据的信息,以及面向管理员的隐私页面以概述相关的自定义项和设置
- 新闻和最新动态:我们在“数据处理附录”页面上分享全球隐私法律的最新进展(您可以订阅我们的 RSS 源,随时了解任何变更)
Atlassian Trust Center 提供了更多信息。
内部和外部审计
在年度合规性审计(例如 SOX、SOC2)过程中,我们会进行全面的安全评估,同时还会由外部审计公司进行独立评估。此外,我们还会在被视为高风险的领域进行内部运营审计,其中包括各种安全主题。这些审计的结果将报告给我们董事会的审计委员会,并纳入一个持续改进周期,从而帮助我们不断完善整体安全计划。
执法部门和政府的数据请求
作为赢得和维护您信任的承诺的一部分,我们会在每年发布 Atlassian 透明度报告,内含有关政府的数据请求(无论是索取用户数据还是要求删除内容/暂停用户帐户)的信息。Atlassian 将仔细审查每个请求的法律效力,如果必须要满足,我们会在尽可能最小的范围内回应具体请求。
Atlassian 的价值观奠定了我们如何响应执法机构对客户数据的请求的基础。为保护客户的数据隐私和权利,我们只有在合理认为有相关法律要求并经过全面法律审查后,才会向执法机构提供客户信息。要从 Atlassian 获取客户信息,执法人员须提供适合所寻求信息类型的法律手续,例如传票、法院命令或搜查令。Atlassian 执法请求准则提供了有关处理执法请求的详细准则。
其他问题和查询
尽管我们的安全性实践提供了我们安全性方法的综合概述,但这是一个原本就很复杂的领域,Atlassian 也在此领域内做了大量工作,因而此处无法详述其中的每一点。
有关更多信息,请访问我们的 Atlassian Trust Center。如果仍需涉及 Atlassian 安全性的任意主题的深入阐述,您也可以通过支持门户联系 Atlassian Trust 团队,或在 Atlassian Trust 与安全社区提问。