ENISA：欧洲网络与信息安全局

欧洲网络与信息安全局 (ENISA) 是网络和信息专业知识的中心。该组织与欧盟成员国和私有部门密切合作，就开展良好网络安全实践提供建议。ENISA 还协助制定和实施与国家信息安全有关的欧盟政策和法律。

ENISA 云计算信息保障框架 (IAF) 由一组保障标准组成，组织可以与云服务提供商 (CSP) 共同进行审查，以确保他们为客户数据提供足够的保护。IAF 旨在评估采用云的风险并减轻 CSP 的保障负担。

Atlassian 通过遵守云安全联盟 (CSA) 云控制矩阵 (CCM) 与 IAF 保持一致，该矩阵包含 CCM 域和控制与 IAF 保障标准的映射以及与针对 ISO 27001 的认证的映射。

Atlassian 继续提供以下基于 CCM 的保障：

• CSA Star 1 级自我评估

以下指南提供了可帮助组织选择云服务提供商的保障标准。如果您对具体细节有任何疑问，请访问以下网址联系我们的企业销售团队：https://www.atlassian.com/enterprise/contact?formType=product-features。

6.01

与人员相关的大多数问题将与您向自己的 IT 人员或向其他与 IT 打交道的人员提出的问题类似。与大多数评估一样，风险和成本之间存在着平衡。

6.01. (a)

在雇用 IT 管理员或其他具有系统访问权限的人员时，您实施了哪些政策和程序？其中应包括：

• 雇前调查（身份、国籍或社会地位、工作经历和推荐人、刑事定罪和审查 [适用于担任高权限职务的高级人员]）。

根据居住地法律，Atlassian 新员工必须完成背景调查。根据居住地法律，因收购而新雇用的员工将在收购日期之后进行背景调查。对所有新员工和独立承包商进行刑事调查—如果角色或职位级别要求进行教育背景查证、职业背景查证或信用核查，则需增加此类调查。我们会对高级管理人员和会计职位进行全面的背景调查。

6.01. (b)

是否根据数据的存储位置或应用的运行位置制定了不同的政策？

• 例如，一个地区的招聘政策可能与另一个地区的招聘政策不同。
• 各区域的做法需要保持一致。
• 敏感数据可能存储在一个特定的区域，由适当的人员保管。

Atlassian 以最低权限为基础，对需要访问我们系统、应用和基础架构以履行其工作角色和职责的人员实行限制，这是通过我们的身份验证流程强制执行的。所有访问均通过经过身份验证的会话进行，并基于既定权限。

所有 1 级系统均通过 Atlassian 集中式单一登录 (SSO) 和目录解决方案进行管理。我们会根据这些个人资料，按照我们的人力资源管理系统的工作流程，为用户提供适当的访问权限。Atlassian 利用 MFA 来访问所有的 1 级系统。我们对虚拟机管理程序管理控制台和 AWS API 启用了双因素身份验证，并对虚拟机管理程序管理功能的所有访问启用了每日审计报告。我们会每季度对虚拟机管理程序管理控制台和 AWS API 的访问列表进行一次审查。我们还在人力资源系统和身份存储之间保持八小时的同步。

更广泛地说，访问管理政策涵盖了与访问控制相关的控制措施，可从以下位置访问该政策的摘录：https://www.atlassian.com/trust

6.01. (c)

您针对所有员工开展了什么安全培训计划？

Atlassian 会为新员工提供信息安全培训，作为其入职培训（“第 1 天”）的一部分，并为所有员工持续提供此类培训。

除了此类常规信息安全培训外，还为我们的开发人员提供更有针对性的安全编码相关培训，并由我们的嵌入式安全工程师计划提供支持。

我们还提供与恶意软件、网络钓鱼和其他安全问题相关的持续主题培训。有关更多信息，请访问：https://www.atlassian.com/trust/security/security-practices#security-awareness-training

我们会保留完成内部员工培训的正式记录。员工必须认可《行为准则》，并每年重申一次。本政策适用于所有员工。我们会在新员工第一天培训中提出安全意识、保密和隐私要求，这些要求适用于 Confluence 中的所有员工。

6.01. (d)

有持续评估的流程吗？

• 多久进行一次？
• 其他访谈。
• 安全访问和权限审查。
• 政策和程序审查。

Atlassian 的云服务已获得 SOC2、ISO27001 和 ISO27018 认证。我们每年至少进行一次内部/就绪情况审计和外部审计。Atlassian 的许多产品都获得了 ISO 认证，这需要定期进行风险评估和数据实践审查。

有关更多信息，请访问：https://www.atlassian.com/trust/compliance。客户应定期从此站点下载和查看我们的合规证书和报告的更新。

Atlassian 具有一个成文的政策框架，它以我们的安全政策为主要政策。我们已确立了政策管理计划 (PMP)，该计划包括所有权、可用性和审查周期，并概述了我们的总体目标。我们的政策每年至少会审查一次，并由高管层批准。有关我们的 PMP 的更多信息，请访问：https://www.atlassian.com/trust/security/security-management-program

我们还发布了每项高级政策的摘录（政策篇幅太长，可看摘录），可以访问以下网址进行查看：https://www.atlassian.com/trust/security/ismp-policies

所有系统和项目都要接受与个人身份信息相关的影响评估。

我们的 Atlassian 第三方协议包括适用的安全和隐私条款。Atlassian 的新供应商必须同意我们合同中的隐私和安全政策。我们的法律和采购团队会审查合同、SLA 和供应商内部政策，以管理与安全性、可用性和机密性相关的风险。Atlassian 的企业风险管理 (ERM) 计划会执行年度风险评估，该评估纳入了所有风险类别的可能性和影响，并与 COSO 风险模型保持一致。我们还会根据需要基于风险概况进行功能风险评估。若政策更新以及与供应商的关系发生重大变化时，我们都会重新进行风险评估。

6.02.

如果云提供商将某些对运营安全至关重要的业务分包给第三方（例如，SaaS 提供商将底层平台外包给第三方提供商、云提供商将安全服务外包给托管安全服务提供商、利用外部提供商进行操作系统的身份管理等），则以下问题适用。如果第三方具有云提供商基础设施的物理或远程访问权限，则也将包括在内。此处假设整份问卷可以递归地应用于第三方（或第 n 方）云服务提供商。

6.02. (a)

定义服务交付供应链中对您的运营安全性（包括可用性）至关重要的外包服务或分包服务。

Atlassian 与第三方分包商合作，提供网站、应用开发、托管、维护、备份、存储、虚拟基础设施、支付处理、分析和其他服务。目前由 Atlassian 聘请并经客户授权的辅助处理者列表列于 https://www.atlassian.com/legal/sub-processors。

6.02. (b)

详细说明用于向访问您的基础设施（物理和/或逻辑）的第三方提供保障的程序。

• 你们是否对外包商和分包商进行审计？多久进行一次？

我们的法律和采购团队会审查合同、SLA 和供应商内部政策，以管理与安全性、可用性和机密性相关的风险。我们还会根据需要基于风险概况进行功能风险评估。若政策更新以及与供应商的关系发生重大变化，我们都会重新进行风险评估。我们的“供应商和第三方数据管理政策”介绍了此流程，其摘录可在以下网址找到：https://www.atlassian.com/trust/security/ismp-policies

6.02. (c)

是否有任何由外包商提供担保的 SLA 条款在级别上低于您向客户提供的 SLA？如果没有，你们是否建立了供应商冗余机制？

根据许可证安排，应在续订月度订阅或年度订阅时审查我们的客户云条款。我们的法律和采购团队会审查合同、SLA 和供应商内部政策，以管理与安全性、可用性和机密性相关的风险。Atlassian 的企业风险管理 (ERM) 计划会执行年度风险评估，该评估包含了所有风险类别的可能性和影响，并与 COSO 风险模型保持一致。我们还会根据需要基于风险概况进行功能风险评估。若政策更新以及与供应商的关系发生重大变化，我们都会重新进行风险评估。

6.02. (d)

采取了哪些措施来确保达到并保持第三方服务级别？

我们的法律和采购团队会审查合同、SLA 和供应商内部政策，以管理与安全性、可用性和机密性相关的风险。我们还会根据需要基于风险概况进行功能风险评估。若政策更新以及与供应商的关系发生重大变化，我们都会重新进行风险评估。我们的“供应商和第三方数据管理政策”介绍了此流程，其摘录可在以下网址找到：https://www.atlassian.com/trust/security/ismp-policies

6.02. (e)

云提供商能否确认安全政策和控制措施按合同应用于其第三方提供商？

所有系统和项目都要接受与 PII 相关的影响评估。我们的 Atlassian 第三方协议包括适用的安全和隐私条款。Atlassian 的新供应商必须同意我们合同中的隐私和安全政策。

我们的法律和采购团队会审查合同、SLA 和供应商内部政策，以管理与安全性、可用性和机密性相关的风险。Atlassian 的企业风险管理 (ERM) 计划会执行年度风险评估，该评估包含了所有风险类别的可能性和影响，并与 COSO 风险模型保持一致。我们还会根据需要基于风险概况进行功能风险评估。若政策更新以及与供应商的关系发生重大变化，我们都会重新进行风险评估。

6.03.

与外部提供商达成的任何商业协议预计都将列明所有网络服务的服务级别。但是，除已定义的协议外，最终客户还应确保提供商采用适当的控制措施来减少未经授权的信息披露。

6.03. (a)

详细说明您的变更控制程序和政策。这也应包括以下用途的流程：重新评估变更导致的风险，并阐明产出是否可供最终客户使用。

Atlassian 的企业风险管理 (ERM) 计划与 COSO 风险模型和 ISO 31000 保持一致。ERM 计划会在 Atlassian 中实施风险管理框架和方法，进行年度风险评估和定期的产品环境特定风险评估，还会根据需要基于风险概况进行功能风险评估。

特别是，Atlassian 的风险管理框架为完成风险评估活动提供了标准、流程、角色和责任、可接受的风险容忍度和指令。我们的风险管理流程和实践可推动完成风险评估，这些评估是可重复的，并产生有效、一致和可比较的结果。Atlassian 进行的风险评估包含所有风险类别的可能性和影响，以及根据我们内部设定的风险偏好对任何及所有风险的处理。在 ERM 计划的所有阶段，风险和合规团队与相关的利益相关者沟通，并与相应的主题专家 (SME) 进行协商。

在 Atlassian 风险管理流程中担任角色的人员充分了解自己的职责，并接受过履行职责方面的培训。所有风险均使用我们自己的 Jira 工具进行跟踪和管理，并由管理层通过相关的处理计划和项目来负责处理。有关更多信息，请参阅：https://www.atlassian.com/trust/security/security-management-program 或 https://www.atlassian.com/trust/compliance/risk-management-program

我们的 Atlassian 变更管理流程与传统变更流程略有不同。无论是代码、应用还是基础设施变更，我们都依靠“同行审查和绿色构建”(PRGB) 流程来控制所有变更。“同行审查”在我们的 CD 工具中配置，在该工具中，必须指定关键分支，以便为每个拉取请求配备多名审查者。审查者通常是两名开发人员和一名团队负责人。控制流程的“绿色构建”部分意味着 CI 阶段的集成必须通过所有已开发的集成、功能、安全和其他测试。如果这些测试失败（红色构建），则代码将不会予以合并，而且必须重新审查代码并解决失败问题。绿色构建成功后，将对二进制文件进行加密签名，并且我们的生产环境仅运行使用我们的密钥签名的二进制文件。我们的测试流程包含自动和手动评估组成部分。我们喜欢在博客中介绍我们擅长的事情。我们对使用“质量援助”（而不是传统的“质量保证”）的方法积极提供支持：https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance

6.03. (b)

定义远程访问政策。

远程访问要求在访问管理政策和相关标准中定义。出于支持或迁移目的，可以将客户数据复制到员工工作站上，并附上有效的客户支持工作单。我们实施严格的防火墙规则，从而限制用户只能通过我们的 VPN 网络和授权系统访问生产环境。访问我们的 VPN 需要接受多重身份验证。

Atlassian 员工使用的所有可访问任何 Atlassian 工具的设备（Atlassian 拥有或员工自带）均通过 MDM 软件安全配置文件和安全态势检查在设备管理功能中注册。Atlassian 对所有 Atlassian 设备都使用零信任安全模型。更多信息请访问：https://www.atlassian.com/trust/compliance/resources/eba/eba-guidance

6.03. (c)

提供商是否会维护记录在册的信息系统操作程序？

Atlassian 的运营安全基本原则包括编制标准操作程序文档。我们还发布了每项高级政策的摘录（政策篇幅太长，可查看摘录），可以访问以下网址进行查看：https://www.atlassian.com/trust/security/ismp-policies

6.03. (d)

是否存在可以降低风险的暂存环境（例如开发、测试和运营环境）？它们是否是分开的？

Atlassian 制定了信息安全政策，禁止在非生产环境中使用生产数据，而且会通过变更管理流程识别任何尝试在环境之间迁移数据的行为。代码通过集中式构建系统移动，首先进行单元测试，然后进行功能分支验证（接受额外的测试自动化处理），并由 PM、开发、QA 部门进行关口审查。最后，进行 UAT、安全性和性能验证。开发人员无法直接将代码推至生产环境中。有关更多详细信息，请访问 https://www.atlassian.com/trust/security/security-practices#managing-changes-in-our-environment

我们使生产和非生产（开发）环境保持逻辑和物理隔离，并采用一些方法来隔离这些环境。

我们的暂存环境在逻辑上是隔离的（但在物理上不是分开的），并按照生产级的变更控制和访问流程进行管理。有关我们的代码安全实践的更多信息，请参阅：https://www.atlassian.com/trust/security/security-in-development。

6.03. (e)

定义用于对托管最终客户应用和信息的系统进行保护的主机与网络控制措施。它们应包含依据外部标准（例如 ISO 27001/2）进行认证的详细信息。

Atlassian 网络工程部门使用内置于我们的云和办公室防火墙中的 IPS 技术，并且 Atlassian 已经在办公环境中实施了 IDS 技术。网络威胁防护由 AWS 执行，包括 DDoS 防护和一些 Web 应用防火墙功能。我们服务的所有数据在传输过程中均使用 TLS 进行加密，以保护其免遭未经授权的泄露或修改，无论是通过 HTTPS 还是 SMTPS。

Atlassian 的云服务已获得 SOC2、ISO27001 和 ISO27018 认证。我们每年至少进行一次内部/就绪情况审计和外部审计。

有关更多信息，请参阅：https://www.atlassian.com/trust/compliance。客户应定期从此站点下载并查看我们的合规证书和报告的更新。

6.03. (f)

详细说明用于防范恶意代码的控制措施。

Atlassian 已实施 Crowdstrike Falcon (https://www.crowdstrike.com/falcon-platform/)，以全面保护我们的 Windows 和 Mac 机群。在 Linux 计算机上，我们不使用反恶意软件。我们的漏洞管理政策中包含反恶意软件。

我们会维护威胁和漏洞管理政策。我们已确立政策管理计划 (PMP)，该计划列明了所有权、可用性和审查周期，并概述了我们的总体目标。我们的政策至少每年审查一次，并由高管层批准。有关我们的 PMP 的更多信息，请访问：https://www.atlassian.com/trust/security/security-management-program

我们还发布了每项高级政策的摘录（政策篇幅太长，可查看摘录），可以访问以下网址进行查看：https://www.atlassian.com/trust/security/ismp-policies

6.03. (g)

是否部署了安全配置，以仅允许执行经过授权的移动代码和功能（例如，仅执行特定命令）？

所有服务器均使用我们的集中式 Puppet 配置系统配置为标准操作环境，包括从默认映像和关键软件包更新中移除部分软件包。所有服务器角色均默认拒绝所有传入的网络请求，同时让部分端口仅对需要访问该端口的其他服务器角色开放，以使用相关功能。

我们的公司网络与生产网络相隔离，我们的计算机映像经过强化处理，仅允许必要的端口和协议访问。当前，所有生产系统都托管在我们云提供商的美国区域内。在经过强化的虚拟私有云网络 (VPC) 之外传输的所有数据均通过行业标准通道进行加密。

此外，所有生产服务器上都安装了 IDS 系统，其中包括对生产系统文件或配置的任何更改以及异常安全事件进行实时监控和发出警报。

我们还实施了集中式系统管理解决方案 (https://www.jamf.com/lp/apple-mobile-device-management-mdm-jamf/)，以便管理我们的 Mac 笔记本电脑机群。我们在笔记本电脑上使用了全磁盘加密技术。我们还为智能手机实施了移动设备管理解决方案 (https://www.vmware.com/products/workspace-one.html)。所有设备必须经过注册才能访问内部系统和应用。如果移动设备未注册，则其无法访问任何内部资源，而且会被置于只能访问互联网的访客网络上。我们通过基于角色的访问控制功能来管理访问权限，以确保只有需要访问客户/租户数据的用户才能获得访问权限。

6.03. (h)

详细说明备份的政策和程序。这应包括可移动媒体的管理程序以及安全销毁不再需要的媒体的方法。（根据业务需求，客户可能希望制定独立的备份策略。在需要对备份进行时间紧迫的访问的情况下，这一点尤其重要。）

Atlassian 执行全面的备份计划。其中包括我们的内部系统，其备份措施符合系统恢复要求。对于我们的云产品，尤其是与您和您的应用相关的数据，我们也有全面的备份措施。Atlassian 采用 Amazon RDS（关系数据库服务）的快照功能为每个 RDS 实例自动创建每日备份。Amazon RDS 快照会保留 30 天，同时支持时间点恢复，并使用 AES-256 加密技术进行加密。备份数据并非异地存储，而是复制到特定 AWS 区域内的多个数据中心。我们每个季度都会对备份进行测试。Bitbucket 中的数据会复制到不同的 AWS 区域，并且每个区域每天都在进行独立备份。

我们不会使用这些备份来还原客户做出的破坏性变更，例如使用脚本来覆盖的字段，或是已删除的事务、项目或站点。为避免数据丢失，我们建议定期进行备份。参阅产品的支持文档，了解有关创建备份的更多信息。客户还应自行进行定期备份，以便能够回滚客户发起的更改。有关更多信息，请访问：https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/#Can-Atlassian%E2%80%99s-RDS-backups-be-used-to-roll-back-changes。

Atlassian 会维护数据保留和销毁标准，该标准规定了我们需要多长时间来维护不同类型的数据。我们会根据《Atlassian 数据安全和信息生命周期政策》对数据进行分类，并在此基础上实施相应的控制措施。对于客户数据，在 Atlassian 合同终止后，属于客户团队的数据将从实时生产数据库中移除，直接上传到 Atlassian 的所有文件附件将在 14 天内移除。团队的数据将保留在加密备份中，直到这些备份超出 90 天的备份保留期并根据我们的 Atlassian 数据保留政策被销毁。如果需要在请求删除数据后的 90 天内恢复数据库，运营团队将在实时生产系统完全还原后尽快重新删除数据。有关更多信息，请访问：https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

在出现需要调查的事件以及进行故障排除时，需使用审核日志。出于这些目的，最终客户需要确保提供此类信息。

6.03. (i)

提供商能否详细说明审核日志中记录了哪些信息？

• 这些数据会保留多长时间？
• 是否有可能对审核日志中的数据进行细分，以便在不影响其他客户的情况下向最终客户和/或执法部门提供这些数据，并确保这些数据仍可作为呈堂证供？
• 采用了哪些控制措施来保护日志免遭未经授权的访问或篡改？
• 使用何种方法来检查和保护审核日志的完整性？

关键系统日志从每个系统转发到集中式日志平台，在该平台上，日志为只读模式。Atlassian 安全团队在安全分析平台 (Splunk) 上创建警报，并监控数据泄露指标。我们的 SRE 团队使用此平台监控可用性或性能问题。日志在热备份中保留 30 天，在冷备份中则保留 365 天。

Atlassian 规定，只有已获授权的人员才能在我们的集中式日志记录平台上查看和读取审核日志。

Atlassian 会维护数据保留和销毁标准，该标准规定了我们需要多长时间来维护不同类型的数据。我们会根据《Atlassian 数据安全和信息生命周期政策》对数据进行分类，并在此基础上实施相应的控制措施。对于客户数据，在 Atlassian 合同终止后，属于客户团队的数据将从实时生产数据库中移除，直接上传到 Atlassian 的所有文件附件将在 14 天内移除。团队的数据将保留在加密备份中，直到这些备份超出 90 天的备份保留期并根据我们的 Atlassian 数据保留政策被销毁。如果需要在请求删除数据后的 90 天内恢复数据库，运营团队将在实时生产系统完全还原后尽快重新删除数据。有关更多信息，请访问：https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

6.03. (j)

如何对审核日志进行审查？哪些记录在册的事件会导致采取行动？

关键系统日志从每个系统转发到集中式日志平台，在该平台上，日志为只读模式。Atlassian 安全团队在安全分析平台 (Splunk) 上创建警报，并监控数据泄露指标。我们的 SRE 团队使用此平台监控可用性或性能问题。日志在热备份中保留 30 天，在冷备份中则保留 365 天。

Atlassian 规定，只有已获授权的人员才能在我们的集中式日志记录平台上查看和读取审核日志。

6.03. (k)

使用什么时间源来同步系统并提供准确的审核日志时间戳？

Atlassian Cloud 对所有已部署的实例使用 AWS Time Sync。

6.03.01. (a)

定义用于保护操作系统和所用应用软件完整性的控制措施。其中包括遵循的所有标准，例如 OWASP、SANS 清单、SAFECode。

在开发周期中，我们的安全工程师团队会不断对产品中的所有源代码进行滚动审查。在此过程中，我们会同时采用自动化技术和人工技术。我们还采用强制性的双重同行审查流程，即多名资深或首席开发人员对向主分支的所有提交进行评审。借助敏捷开发工作流，我们能够快速识别和修复任何漏洞，对于我们的云服务而言，此项优势更为明显。

Atlassian 安全代码审查流程包括自动扫描（即软件组合分析），以查找已知漏洞，包括在现实世界的攻击中被利用的漏洞。此外，我们的漏洞管理程序还会使用 Snyk 扫描主机和容器映像，以查找已知漏洞。有关更多信息，请访问：https://www.atlassian.com/trust/security/vulnerability-management。

我们与 BugCrowd 合作，维护缺陷赏金计划，以对我们公开提供的应用和服务进行持续的漏洞评估；该计划的网址为：https://bugcrowd.com/atlassian。我们会在以下网址分享缺陷赏金计划中持续进行的笔试的结果：https://www.atlassian.com/trust/security/security-testing。

6.03.01. (b)

你们如何验证新版本是否符合目的或不存在风险（后门程序、特洛伊木马等）？使用前是否对这些方面进行了审查？

我们的 Atlassian 变更管理流程与传统变更流程略有不同。无论是代码、应用还是基础设施变更，我们都依靠“同行审查和绿色构建”(PRGB) 流程来控制所有变更。“同行审查”在我们的 CD 工具中配置，在该工具中，必须指定关键分支，以便为每个拉取请求配备多名审查者。审查者通常是两名开发人员和一名团队负责人。控制流程的“绿色构建”部分意味着 CI 阶段的集成必须通过所有已开发的集成、功能、安全和其他测试。如果这些测试失败（红色构建），则代码将不会予以合并，而且必须重新审查代码并解决失败问题。绿色构建成功后，将对二进制文件进行加密签名，并且我们的生产环境仅运行使用我们的密钥签名的二进制文件。我们的测试流程包含自动和手动评估组成部分。我们喜欢在博客中介绍我们擅长的事情。我们对使用“质量援助”（而不是传统的“质量保证”）的方法积极提供支持：https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance。

部署后，我们将采用定期的自动漏洞扫描和业界领先的缺陷赏金计划 (https://bugcrowd.com/atlassian)，为我们的应用提供持续保障。系统配置变更由包括审查在内的自动化流程进行管理。

Atlassian 安全代码审查流程包括自动扫描（即软件组合分析），以查找已知漏洞，包括在现实世界的攻击中被利用的漏洞。此外，我们的漏洞管理程序还会使用 Snyk 扫描主机和容器映像，以查找已知漏洞。有关更多信息，请访问：https://www.atlassian.com/trust/security/vulnerability-management。

6.03.01. (c)

遵循哪些实践来确保应用安全？

我们的应用需要经过同行审查和绿色构建 (PRGB) 流程，之后应用的工件会进行加密签名，并由我们的 CI/CD 管道自动部署，只有经过 Atlassian 签名的应用才能在生产环境中运行。

Atlassian 会在开发生命周期的所有阶段执行安全开发实践。有关更多信息，请访问：https://www.atlassian.com/trust/security/security-in-development。

在设计阶段，具体实践包括威胁建模、设计审查以及我们定期更新的安全标准库，以确保将安全要求纳入考虑。在开发过程中，我们依赖强制性的同行审查流程作为安全审查的第一道防线。此操作由自动静态分析检查 (SAST) 和手动安全测试（由内部团队和第三方专家根据我们的风险评估流程来确定）提供支持。开发也由应用安全培训计划和安全团队维护的安全知识库提供支持。然后，正式的运营就绪和变更控制流程可确保仅将已批准的变更部署到生产环境中。部署后，我们将采用定期的自动漏洞扫描和业界领先的缺陷赏金计划 (https://bugcrowd.com/atlassian)，为我们的应用提供持续保障。系统配置变更由自动流程管理，其中包括在部署到生产环境之前对所有变更进行审查。一旦发现重大风险，Atlassian 服务运营部门可立即部署补丁。我们有用于确定所有补丁实施速度的内部标准，并且可以在 12 小时内为所有计算机应用补丁。此外，我们还建立了一个 IDS 系统，其中包括对系统配置文件的监控。

6.03.01. (d)

是否会对发布的软件进行渗透测试，以确保其不包含漏洞？如果发现漏洞，有什么相应的补救流程？

Atlassian 会在开发生命周期的所有阶段执行安全开发实践。有关更多信息，请访问：https://www.atlassian.com/trust/security/security-in-development。

在开发过程中，我们依赖强制性的同行审查流程作为安全审查的第一道防线。此操作由自动静态分析检查 (SAST) 和手动安全测试（由内部团队和第三方专家根据我们的风险评估流程来确定）提供支持。开发由应用安全培训计划和安全团队维护的安全知识库提供支持。

然后，正式的运营就绪和变更控制流程可确保仅将已批准的变更部署到生产环境中。部署后，我们将采用定期的自动漏洞扫描和业界领先的缺陷赏金计划 (https://bugcrowd.com/atlassian)，为我们的应用提供持续保障。

6.03.02. (a)

是否提供所遵循的补丁管理程序的详细信息？

我们会维护威胁和漏洞管理政策。我们已确立政策管理计划 (PMP)，该计划列明了所有权、可用性和审查周期，并概述了我们的总体目标。我们的政策至少每年审查一次，并由高管层批准。有关我们的 PMP 的更多信息，请访问：https://www.atlassian.com/trust/security/security-management-program

我们还发布了每项高级政策的摘录（政策篇幅太长，可查看摘录），可以访问以下网址进行查看：https://www.atlassian.com/trust/security/ismp-policies

Atlassian 使用一套端点管理解决方案，将更新和补丁部署到整个端点群的操作系统和关键应用。我们还实施了多种端点保护解决方案，以防范恶意软件等威胁。有关更多详细信息，请访问：https://www.atlassian.com/trust/security/security-practices#keeping-track-of-information-assets

6.03.02. (b)

你们能否确保补丁管理流程覆盖云交付技术的所有层面，即网络（基础设施组件、路由器和交换机等）、服务器操作系统、虚拟化软件、应用和安全子系统（防火墙、防病毒网关、入侵检测系统等）？

系统配置变更由自动流程管理，其中包括在部署到生产环境之前对所有变更进行审查。一旦发现重大风险，Atlassian 服务运营部门可立即部署补丁。我们有用于确定所有补丁实施速度的内部标准，并且可以在 12 小时内为所有计算机应用补丁。我们还建立了一个 IDS 系统，其中包括对系统配置文件的监控。

Atlassian Cloud 产品可以按需快速更新到最新 AMI。我们的 SaaS 应用每周更新多次。我们拥有快速、可控的部署机制来更新代码和系统配置。Atlassian 积极利用变更控制来处理计划外变更和紧急变更。

6.03.03. (a)

定义用于缓解 DDoS（分布式拒绝服务）攻击的控制措施。

• 深度防御（深度数据包分析、流量限制、数据包阻挡等）。
• 你们是否有针对“内部”（源自云提供商网络）攻击和外部（源自互联网或客户网络）攻击的防御措施？
<

我们在《通信安全政策》中定义了网络安全要求，每年会根据我们的政策管理计划 (PMP) 审查该项政策。有关我们的 PMP 的更多信息，请访问：https://www.atlassian.com/trust/security/security-management-program

我们的 Atlassian Cloud 平台几乎没有通过防火墙暴露的攻击面。我们会定期审查防火墙规则。我们已经在办公场所和云托管环境中部署了 IDS。对于 Atlassian Cloud 平台，日志转发与安全分析平台集成。在 Cloud 平台容器级别，由于实例不可修改，因此可以保持文件完整性。Atlassian 网络工程部门使用内置于我们防火墙中的 IPS 技术，并且我们已经在办公室和云环境中实施了 IDS 技术。DDoS 功能由我们的互联网服务提供商/运营商提供。

我们还通过漏洞评估 (https://www.atlassian.com/trust/security/vulnerability-management) 和渗透测试 (https://www.atlassian.com/trust/security/security-testing) 计划定期评估我们防火墙的性能。

6.03.03. (b)

使用什么级别的隔离？

• 对于虚拟机、物理机、网络、存储（例如存储区域网络）、管理网络和管理支持系统等。
<

Atlassian 是一种多租户 SaaS 应用。多租户是 Atlassian Cloud 的一项关键功能，可让多个客户共享 Jira 或 Confluence 应用层的一个实例，同时隔离每个客户租户的应用数据。Atlassian Cloud 通过租户上下文服务 (TCS) 做到这一点。每个用户 ID 仅与一个租户关联，该 ID 随后用于访问 Atlassian Cloud 应用。有关更多信息，请访问：https://www.atlassian.com/trust/security/security-practices#tenant-isolation

我们使生产和非生产（开发）环境保持逻辑和物理隔离，并采用一些方法来隔离这些环境。

我们的暂存环境在逻辑上是隔离的（但在物理上不是分开的），并按照生产级的变更控制和访问流程进行管理。

6.03.03. (c)

当公司与服务提供商相隔离时，体系结构是否支持从云继续运营，反之亦然（例如，是否存在对客户 LDAP 系统的关键依赖项）？

业务连续性和灾难恢复政策以及业务连续性和灾难恢复计划已经制定，并且每年由业务连续性/灾难恢复指导委员会进行审查。有关更多信息，请访问：https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e 和 https://www.atlassian.com/trust/security/data-management。

Atlassian 在全球多个地区利用 AWS 的高可用数据中心设施来确保持续运营。有关更多信息，请访问：https://www.atlassian.com/trust/security/data-management。

6.03.03. (d)

云提供商使用的虚拟网络基础架构（采用 PVLAN 和 VLAN 标记 802.1q 体系结构）是否根据特定于供应商和/或最佳实践的标准受到了保护（例如，是否可以通过特定的安全配置防止 MAC 欺骗、ARP 毒化攻击等）？

我们在《通信安全政策》中定义了网络安全要求，每年会根据我们的政策管理计划 (PMP) 审核该项政策。有关我们的 PMP 的更多信息，请访问：https://www.atlassian.com/trust/security/security-management-program

我们的 Atlassian Cloud 平台几乎没有通过防火墙暴露的攻击面。我们会定期审查防火墙规则。我们已经在办公场所和云托管环境中部署了 IDS。对于 Atlassian Cloud 平台，日志转发与安全分析平台集成。在 Cloud 平台容器级别，由于实例不可修改，因此可以保持文件完整性。Atlassian 网络工程部门使用内置于我们防火墙中的 IPS 技术，并且我们已经在办公室和云环境中实施了 IDS 技术。DDoS 功能由我们的互联网服务提供商/运营商提供。

我们还通过漏洞评估 (https://www.atlassian.com/trust/security/vulnerability-management) 和渗透测试 (https://www.atlassian.com/trust/security/security-testing) 计划定期评估我们防火墙的性能。

此外，在 Atlassian，我们还根据建立的配置基准监视我们的 AWS 环境的配置。

6.03.04. (a)

提供商是否确保虚拟映像在默认情况下经过强化？

所有服务器均使用我们的集中式 Puppet 配置系统配置为符合标准操作环境，包括从默认映像和关键软件包更新中删除部分软件包。所有服务器角色默认可以拒绝所有传入的网络请求，同时让部分端口仅对需要访问该端口的其他服务器角色开放以使用相关功能。

我们的公司网络与生产网络相隔离，我们的计算机映像经过强化处理，仅允许必要的端口和协议访问。目前，所有生产系统都托管在我们云提供商的美国地区。在经过强化的虚拟私有云网络 (VPC) 之外传输的所有数据均通过行业标准通道进行加密。

此外，所有生产服务器上都安装了 IDS 系统，其中包括对生产系统文件或配置的任何更改以及异常安全事件进行实时监控和警报。

在 Atlassian Cloud 平台中，单个容器没有映像，当容器启动时，会从标准存储库中选取一个映像。我们会持续审核每个映像，并在必要时通过我们的配置工具重新应用映像。因此，我们不会对虚拟机映像进行更改。

AWS Linux AMI 基础操作系统映像内部版本的端口、协议和服务有限。我们会将我们的内部版本与当前 AMI 版本进行比较，以确保采用合适的设置。

我们的 Docker 映像在严格控制的变更环境中进行管理，以确保对所有变更进行适当的审查和批准。

6.03.04. (b)

经过强化的虚拟映像是否可以防止未经授权的访问？

所有服务器均使用我们的集中式 Puppet 配置系统配置为符合标准操作环境，包括从默认映像和关键软件包更新中删除部分软件包。所有服务器角色默认可以拒绝所有传入的网络请求，同时让部分端口仅对需要访问该端口的其他服务器角色开放以使用相关功能。

我们的公司网络与生产网络相隔离，我们的计算机映像经过强化处理，仅允许必要的端口和协议访问。目前，所有生产系统都托管在我们云提供商的美国地区。在经过强化的虚拟私有云网络 (VPC) 之外传输的所有数据均通过行业标准通道进行加密。

此外，所有生产服务器上都安装了 IDS 系统，其中包括对生产系统文件或配置的任何更改以及异常安全事件进行实时监控和警报。

在 Atlassian Cloud 平台中，单个容器没有映像，当容器启动时，会从标准存储库中选取一个映像。我们会持续审核每个映像，并在必要时通过我们的配置工具重新应用映像。因此，我们不会对虚拟机映像进行更改。

AWS Linux AMI 基础操作系统映像内部版本的端口、协议和服务有限。我们会将我们的内部版本与当前 AMI 版本进行比较，以确保采用合适的设置。

我们的 Docker 镜像在严格控制的变更环境中进行管理，以确保对所有变更进行适当的审查和批准。

我们的全球支持团队在所有托管系统和应用上都有一个用于维护和支持的帐户。该支持团队会仅出于应用运行状况监视、执行系统或应用维护的目的，以及根据客户通过我们的支持系统提出的请求访问托管应用和数据。

6.03.04. (c)

提供商能否确认虚拟化映像不包含身份验证凭据？

所有服务器均使用我们的集中式 Puppet 配置系统配置为符合标准操作环境，包括从默认映像和关键软件包更新中删除部分软件包。所有服务器角色默认可以拒绝所有传入的网络请求，同时让部分端口仅对需要访问该端口的其他服务器角色开放以使用相关功能。

我们的公司网络与生产网络相隔离，我们的计算机映像经过强化处理，仅允许必要的端口和协议访问。目前，所有生产系统都托管在我们云提供商的美国地区。在经过强化的虚拟私有云网络 (VPC) 之外传输的所有数据均通过行业标准通道进行加密。

此外，所有生产服务器上都安装了 IDS 系统，其中包括对生产系统文件或配置的任何更改以及异常安全事件进行实时监控和警报。

在 Atlassian Cloud 平台中，单个容器没有映像，当容器启动时，会从标准存储库中选取一个映像。我们会持续审核每个映像，并在必要时通过我们的配置工具重新应用映像。因此，我们不会对虚拟机映像进行更改。

AWS Linux AMI 基础操作系统映像内部版本的端口、协议和服务有限。我们会将我们的内部版本与当前 AMI 版本进行比较，以确保采用合适的设置。

我们的 Docker 镜像在严格控制的变更环境中进行管理，以确保对所有变更进行适当的审查和批准。

我们的全球支持团队在所有托管系统和应用上都有一个用于维护和支持的帐户。该支持团队会仅出于应用运行状况监视、执行系统或应用维护的目的，以及根据客户通过我们的支持系统提出的请求访问托管应用和数据。

6.03.04. (d)

主机防火墙是否仅使用支持虚拟实例内的服务所必需的最少数量的端口运行？

所有服务器均使用我们的集中式 Puppet 配置系统配置为符合标准操作环境，包括从默认映像和关键软件包更新中删除部分软件包。所有服务器角色默认可以拒绝所有传入的网络请求，同时让部分端口仅对需要访问该端口的其他服务器角色开放以使用相关功能。

我们的公司网络与生产网络相隔离，我们的计算机映像经过强化处理，仅允许必要的端口和协议访问。目前，所有生产系统都托管在我们云提供商的美国地区。在经过强化的虚拟私有云网络 (VPC) 之外传输的所有数据均通过行业标准通道进行加密。

我们的 Atlassian Cloud 平台几乎没有通过防火墙暴露的攻击面。我们会定期审查防火墙规则。我们已经在办公场所和云托管环境中部署了 IDS。对于 Atlassian Cloud 平台，日志转发与安全分析平台集成。在 Cloud 平台容器级别，由于实例不可修改，因此可以保持文件完整性。Atlassian 网络工程部门使用内置于我们防火墙中的 IPS 技术，并且我们已经在办公室和云环境中实施了 IDS 技术。DDoS 功能由我们的互联网服务提供商/运营商提供。

我们还通过漏洞评估 (https://www.atlassian.com/trust/security/vulnerability-management) 和渗透测试 (https://www.atlassian.com/trust/security/security-testing) 计划定期评估我们防火墙的性能。

6.03.04. (e)

基于主机的入侵防御服务 (IPS) 是否可以在虚拟实例中运行？

这不适用，因为 Atlassian 采用软件即服务 (SaaS) 模式。

6.03.05.

一般而言，PaaS 服务提供商负责平台软件堆栈的安全性，本文档中的建议为确保 PaaS 提供商在设计和管理 PaaS 平台时考虑安全原则奠定了良好的基础。通常很难从 PaaS 提供商那里获得有关他们如何保护其平台的详细信息，但是以下问题以及本文档中的其他部分应该有助于评估他们的产品。

6.03.05.(a)

请求有关多租户应用如何相互隔离的信息—需要从更高层面对控制措施和隔离措施进行描述。

这不适用，因为 Atlassian 采用软件即服务 (SaaS) 模式。

6.03.05.(b)

PaaS 提供商可以提供什么保障，从而使对数据的访问仅限于您的企业用户以及您所拥有的应用？

这不适用，因为 Atlassian 采用软件即服务 (SaaS) 模式。

6.03.05.(c)

平台体系结构应该是经典的“沙盒”—提供商是否确保监控 PaaS 平台沙盒中是否存在新的缺陷和漏洞？

这不适用，因为 Atlassian 采用软件即服务 (SaaS) 模式。

6.03.05.(d)

PaaS 提供商应该能够提供一组安全功能（可在客户中重复使用）—这些功能是否包括用户身份验证、单一登录、授权（权限管理）和 SSL/TLS（通过 API 提供）？

这不适用，因为 Atlassian 采用软件即服务 (SaaS) 模式。

6.03.06.

SaaS 模式要求提供商管理交付给最终用户的整套应用。因此，SaaS 提供商主要负责保护这些应用。客户通常负责操作方面的安全流程（用户和访问管理）。但是，以下问题以及本文档中的其他部分应该有助于评估他们的产品：

6.03.06. (a)

提供了哪些管理控件，这些控制是否可以用来向其他用户分配读取和写入权限？

使用我们 Enterprise 和 Premium Cloud 产品的客户可以访问集中管理控制面板。贵组织的管理员可以管理所有产品实例的用户访问和权限。有关我们的博客文章，请访问：https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls。

如果 Atlassian 支持，Atlassian 客户可以使用他们选择的第三方身份提供程序。Atlassian 支持页面详细介绍了这些功能以及如何连接您选择的身份提供程序，请访问：https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.03.06. (b)

SaaS 访问控制是否精细，能否根据贵组织的政策进行自定义？

使用我们 Enterprise 和 Premium Cloud 产品的客户可以访问集中管理控制面板。贵组织的管理员可以管理所有产品实例的用户访问和权限。有关我们的博客文章，请访问：https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls。

如果 Atlassian 支持，Atlassian 客户可以使用他们选择的第三方身份提供程序。Atlassian 支持页面详细介绍了这些功能以及如何连接您选择的身份提供程序，请访问：https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.03.07. (a)

如果资源过载（处理、内存、存储、网络），该怎么办？

• 如果调配失败，会提供哪些关于分配给我的请求的相对优先级的信息？
• 在服务级别和需求变更方面是否有提前期？
<

Atlassian 会提前 6 至 12 个月规划产能，高级战略规划将提前 36 个月进行。

Atlassian 会持续对 Cloud AWS 和 Azure 纵向扩展和横向扩展体系结构进行分析，并使用这些数据进行设计以应对 Atlassian 产品增长。但是，这些数据目前不提供给客户。

6.03.07. (b)

您能扩展多大规模？提供商是否提供在最短期限内有最多可用资源的保证？

Atlassian 会提前 6 至 12 个月规划产能，高级战略规划将提前 36 个月进行。

Atlassian 会持续对 Cloud AWS 和 Azure 纵向扩展和横向扩展体系结构进行分析，并使用这些数据进行设计以应对 Atlassian 产品增长。但是，这些数据目前不提供给客户。

6.03.07. (c)

您能以多快的速度扩展规模？提供商是否提供在最短期限内有补充资源可用的保证？

Atlassian 会提前 6 至 12 个月规划产能，高级战略规划将提前 36 个月进行。

Atlassian 会持续对 Cloud AWS 和 Azure 纵向扩展和横向扩展体系结构进行分析，并使用这些数据进行设计以应对 Atlassian 产品增长。但是，这些数据目前不提供给客户。

6.03.07. (d)

实施了哪些流程来应对资源使用的大规模趋势（例如季节性影响）？

Atlassian 会提前 6 至 12 个月规划产能，高级战略规划将提前 36 个月进行。

Atlassian 会持续对 Cloud AWS 和 Azure 纵向扩展和横向扩展体系结构进行分析，并使用这些数据进行设计以应对 Atlassian 产品增长。但是，这些数据目前不提供给客户。

6.04.01.

以下控制措施适用于云提供商的身份和访问管理系统（这些系统由他们自己控制）。

6.04.01. (a)

是否有任何帐户对整个云系统具有全系统权限，如果有，可以执行哪些操作（读取/写入/删除）？

我们的全球支持团队在所有托管系统和应用上都有一个用于维护和支持的帐户。该支持团队会仅出于应用运行状况监视、执行系统或应用维护的目的，以及根据客户通过我们的支持系统提出的请求访问托管应用和数据。

6.04.01. (b)

如何对具有最高权限级别的帐户进行身份验证和管理？

Atlassian 对需要这种访问权限才能履行工作角色和职责的人员保持限制。所有 1 级系统均通过 Atlassian 集中式单一登录 (SSO) 和目录解决方案进行管理。我们会根据这些个人资料，按照我们的人力资源管理系统的工作流程，为用户提供适当的访问权限。Atlassian 利用 MFA 来访问所有的 1 级系统。我们对虚拟机管理程序管理控制台和 AWS API 启用了双因素身份验证，并对虚拟机管理程序管理功能的所有访问启用了每日审计报告。我们会每季度对虚拟机管理程序管理控制台和 AWS API 的访问列表进行一次审查。我们还在人力资源系统和身份存储之间保持八小时的同步。

6.04.01. (c)

如何授权（单因素还是双因素身份验证，以及由组织内的哪些角色授权）最关键的决策（例如，同时取消大型资源块的调配）？

Atlassian 对需要这种访问权限才能履行工作角色和职责的人员保持限制。所有 1 级系统均通过 Atlassian 集中式单一登录 (SSO) 和目录解决方案进行管理。我们会根据这些个人资料，按照我们的人力资源管理系统的工作流程，为用户提供适当的访问权限。Atlassian 利用 MFA 来访问所有的 1 级系统。我们对虚拟机管理程序管理控制台和 AWS API 启用了双因素身份验证，并对虚拟机管理程序管理功能的所有访问启用了每日审计报告。我们会每季度对虚拟机管理程序管理控制台和 AWS API 的访问列表进行一次审查。我们还在人力资源系统和身份存储之间保持八小时的同步。

我们的核心产品已实行职责分离控制，包括但不限于：

• 访问控制审查
• 人力资源应用托管安全群组
• 变更批准/同行评审/实施 (PRGB)
• 工作流程控制

6.04.01. (d)

是否为同一个人分配了任何高权限角色？此分配是否会打破职责分离或最低权限规则？

Atlassian 对需要这种访问权限才能履行工作角色和职责的人员保持限制。所有 1 级系统均通过 Atlassian 集中式单一登录 (SSO) 和目录解决方案进行管理。我们会根据这些个人资料，按照我们的人力资源管理系统的工作流程，为用户提供适当的访问权限。Atlassian 利用 MFA 来访问所有的 1 级系统。我们对虚拟机管理程序管理控制台和 AWS API 启用了双因素身份验证，并对虚拟机管理程序管理功能的所有访问启用了每日审计报告。我们会每季度对虚拟机管理程序管理控制台和 AWS API 的访问列表进行一次审查。我们还在人力资源系统和身份存储之间保持八小时的同步。

我们的核心产品已实行职责分离控制，包括但不限于：

• 访问控制审查
• 人力资源应用托管安全群组
• 变更批准/同行评审/实施 (PRGB)
• 工作流程控制

6.04.01. (e)

您是否使用基于角色的访问控制 (RBAC)？是否遵循了最低权限原则？

Atlassian 有一套既定的工作流程，将我们的人力资源管理系统与我们的访问调配系统关联起来。我们根据预定义的用户个人资料使用基于角色的访问控制。所有用户帐户必须获得管理层批准后，才能访问数据、应用、基础架构或网络组件。

Atlassian 以最低权限为基础，对需要访问我们系统、应用和基础架构以履行其工作角色和职责的人员实行限制，这是通过我们的身份验证流程强制执行的。

6.04.01. (f)

对管理员权限和角色进行了哪些更改（如果有），以允许在紧急情况下进行非寻常访问？

我们的全球支持团队在所有托管系统和应用上都有一个用于维护和支持的帐户。该支持团队会仅出于应用运行状况监视、执行系统或应用维护的目的，以及根据客户通过我们的支持系统提出的请求访问托管应用和数据。

6.04.01. (g)

客户有“管理员”角色吗？例如，客户管理员是否有权添加新用户（但不允许他更改底层存储！）？

Atlassian 会为客户提供“组织管理员”角色，负责管理客户产品的用户和群组。有关更多信息，请访问：https://support.atlassian.com/user-management/docs/give-users-admin-permissions/

6.04.02. (a)

注册时会对用户帐户的身份进行哪些检查？是否遵循任何标准？例如，电子政务互操作性框架？

• 根据所需资源，是否有不同级别的身份检查？

全球新 Atlassian 员工需要完成背景调查。收购后新雇用的员工将在收购日期后进行背景调查。对所有新员工和独立承包商进行刑事调查—如果角色或职位级别要求进行教育背景查证、职业背景查证或信用核查，则需增加此类调查。我们会对高级管理人员和会计职位进行全面的背景调查。

Atlassian 有一套既定的工作流程，将我们的人力资源管理系统与我们的访问调配系统关联起来。我们根据预定义的用户个人资料使用基于角色的访问控制。所有用户帐户必须获得管理层批准后，才能访问数据、应用程序、基础设施或网络组件。

6.04.02. (b)

取消调配凭据有哪些流程？

我们的取消调配流程目前包括终止雇用、合同或协议。内部调动的用户通常会保留其访问权限，以实现持续的互动和支持。为了提供反应迅速、灵活且以客户为中心的团队，根据我们公司的价值观，我们的重点是对访问权限的未授权使用进行限制，而不是限制访问，否则可能会减慢我们的响应速度。

6.04.02. (c)

是否在整个云系统中同时调配和取消调配凭据，或者在多个地域分布广阔的位置取消调配凭据是否存在风险？

Atlassian 有一套既定的工作流程，将我们的人力资源管理系统与我们的访问调配系统关联起来。我们根据预定义的用户个人资料使用基于角色的访问控制。所有用户帐户必须获得管理层批准后，才能访问数据、应用、基础架构或网络组件。

我们的人力资源应用每 8 小时与我们的内部身份存储同步一次，删除不再被雇用的员工或承包商的所有帐户。

6.04.03. (a)

有哪些数据存储和保护控制措施适用于用户目录（例如 AD、LDAP）及用户目录访问？

我们会根据我们的《信息生命周期和数据安全政策》对数据进行分类和处理，并在此基础上实施相应的控制措施。有关更多信息，请访问：https://www.atlassian.com/trust/security/security-practices

所有系统和项目都要接受与 PII 相关的影响评估。我们的 Atlassian 第三方协议包括适用的安全和隐私条款。Atlassian 的新供应商必须同意我们合同中的隐私和安全政策。

Atlassian 的许多产品都获得了 ISO 认证，这需要定期进行风险评估和数据实践审查。

我们的“数据传输影响评估”可在以下位置找到：https://www.atlassian.com/legal/data-transfer-impact-assessment

Atlassian 会维护数据保留和销毁标准，该标准规定了我们需要多长时间来维护不同类型的数据。我们会根据我们的《Atlassian 数据安全和信息生命周期政策》对数据进行分类，并在此基础上实施相应的控制措施。

对于客户数据，在 Atlassian 合同终止后，属于客户团队的数据将从实时生产数据库中删除，直接上传到 Atlassian 的所有文件附件将在 14 天内删除。团队的数据将保留在加密备份中，直到这些备份超出 90 天的备份保留期并根据我们的 Atlassian 数据保留政策被销毁。如果需要在请求删除数据后的 90 天内恢复数据库，运营团队将在实时生产系统完全还原后尽快重新删除数据。有关更多信息，请访问：https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

6.04.03. (b)

用户目录数据是否能以可互操作的格式导出？

管理员可以从管理员面板导出用户目录。相关指南可在 Atlassian 的以下支持站点找到：https://support.atlassian.com/organization-administration/docs/export-users-from-a-site/

6.04.03. (c)

对云提供商内部客户数据的访问是以需要知道为依据吗？

Atlassian 对需要这种访问权限才能履行工作角色和职责的人员保持限制。所有 1 级系统均通过 Atlassian 集中式单一登录 (SSO) 和目录解决方案进行管理。我们会根据这些个人资料，按照我们的人力资源管理系统的工作流程，为用户提供适当的访问权限。Atlassian 利用 MFA 来访问所有的 1 级系统。我们对虚拟机管理程序管理控制台和 AWS API 启用了双因素身份验证，并对虚拟机管理程序管理功能的所有访问启用了每日审计报告。我们会每季度对虚拟机管理程序管理控制台和 AWS API 的访问列表进行一次审查。我们还在人力资源系统和身份存储之间保持八小时的同步。

我们的核心产品已实行职责分离控制，包括但不限于：

• 访问控制审查
• 人力资源应用托管安全群组
• 变更批准/同行评审/实施 (PRGB)
• 工作流程控制

6.04.04.

对于云提供商控制下的密钥：

6.04.04. (a)

是否已实施读取和写入这些密钥的安全控制措施？例如，强密码策略、存储在单独系统中的密钥、根证书密钥的硬件安全模块 (HSM)、基于智能卡的身份验证、直接屏蔽存储访问、缩短密钥生存期等。

Atlassian 会维护加密与密码政策和实施准则。我们会根据政策管理计划 (PMP)，每年对本政策进行审查和更新。有关更多信息，请访问：https://www.atlassian.com/trust/security/security-management-program。

Atlassian 会为我们的云基础架构维护记录在案的密钥管理程序。Amazon 附件的加密密钥存储在 S3 中，由 Amazon KMS 管理。作为 Amazon 现有审计流程的一部分，Amazon 会定期对加密、密钥管理和解密过程进行内部检查和验证。Atlassian 管理的密钥会在角色或雇用状态发生相关变化时轮换。AWS KMS 服务符合 SOC 1、SOC 2、SOC 3。有关更多信息，请访问：https://aws.amazon.com/kms/

6.04.04. (b)

对于使用这些密钥进行签名和数据加密，是否实施了相应的安全控制措施？

Atlassian 会为我们的云基础架构维护记录在案的密钥管理程序。Amazon 附件的加密密钥存储在 S3 中，由 Amazon KMS 管理。作为 Amazon 现有审计流程的一部分，Amazon 会定期对加密、密钥管理和解密过程进行内部检查和验证。KMS 中的主密钥在创建时即会启用自动轮换，每 365 天（每年）生成一次主密钥材料。

6.04.04. (c)

是否制定了相应的程序来应对密钥泄露情况？例如，密钥撤消列表。

Atlassian 会为我们的 Cloud 基础设施维护记录在册的密钥管理程序。Amazon 附件的加密密钥存储在 S3 中，由 Amazon KMS 管理。作为 Amazon 现有审计流程的一部分，Amazon 会定期对加密、密钥管理和解密流程进行内部检查和验证。Atlassian 管理的密钥会在角色或雇用状态发生相关变化时轮换。AWS KMS 服务符合 SOC 1、SOC 2、SOC 3。有关更多信息，请访问：https://aws.amazon.com/kms/

6.04.04. (c)

是否制定了相应的程序来应对密钥泄露情况？例如，密钥撤消列表。

Atlassian 会为我们的 Cloud 基础设施维护记录在册的密钥管理程序。Amazon 附件的加密密钥存储在 S3 中，由 Amazon KMS 管理。作为 Amazon 现有审计流程的一部分，Amazon 会定期对加密、密钥管理和解密流程进行内部检查和验证。Atlassian 管理的密钥会在角色或雇用状态发生相关变化时轮换。AWS KMS 服务符合 SOC 1、SOC 2、SOC 3。有关更多信息，请访问：https://aws.amazon.com/kms/

6.04.04. (d)

密钥撤消能否处理多个站点同时发生的问题？

Atlassian 会为我们的 Cloud 基础设施维护记录在册的密钥管理程序。Amazon 附件的加密密钥存储在 S3 中，由 Amazon KMS 管理。作为 Amazon 现有审计流程的一部分，Amazon 会定期对加密、密钥管理和解密流程进行内部检查和验证。Atlassian 管理的密钥会在角色或雇用状态发生相关变化时轮换。AWS KMS 服务符合 SOC 1、SOC 2、SOC 3。有关更多信息，请访问：https://aws.amazon.com/kms/

6.04.04. (e)

客户系统映像是否受到保护或加密？

Atlassian 使用行业标准的传输层安全（“TLS”）版本 1.2，以使用 256 ­位高级加密标准（“AES”）加密创建安全连接。保存用户数据的服务器将使用全磁盘、行业标准的 AES 加密。租户数据在 AWS RDS 或 RDS 备份中加密，在长期存储 (S3) 和所有附件中也经过加密。有关更多信息，请访问：https://www.atlassian.com/trust/security/security-practices#encryption-and-key-management

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

Jira Software Cloud、Jira Service Desk Cloud、Jira Core Cloud、Bitbucket Cloud、Confluence Cloud、Statuspage、Opsgenie 和 Trello 中服务器上存储客户数据和附件的数据驱动器在静止状态下会使用全磁盘行业标准 AES-256 进行加密。

对于静态加密，具体而言，我们会加密存储在磁盘上的客户数据，例如 Jira 事务数据（详细信息、评论、附件）或 Confluence 页面数据（页面内容、评论、附件）。静态数据加密有助于防止未经授权的访问，并确保只有经授权的角色和服务才能访问数据，且其对加密密钥的访问权限必须经过审查。

6.04.05. (a)

加密可在多个位置使用，具体可以在哪里使用？

• 传输中的数据？
• 静态数据？
• 处理器或内存中的数据？

Atlassian 会维护加密与密码政策和实施准则。我们会根据政策管理计划 (PMP)，每年对本政策进行审查和更新。有关更多信息，请访问：https://www.atlassian.com/trust/security/security-management-program。

Atlassian 会为我们的 Cloud 基础设施维护记录在册的密钥管理程序。Amazon 附件的加密密钥存储在 S3 中，由 Amazon KMS 管理。作为 Amazon 现有审计流程的一部分，Amazon 会定期对加密、密钥管理和解密流程进行内部检查和验证。Atlassian 管理的密钥会在角色或雇用状态发生相关变化时轮换。

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

Jira Software Cloud、Jira Service Desk Cloud、Jira Core Cloud、Bitbucket Cloud、Confluence Cloud、Statuspage、Opsgenie 和 Trello 中服务器上存储客户数据和附件的数据驱动器在静止状态下会使用全磁盘行业标准 AES-256 进行加密。

对于静态加密，具体而言，我们会加密存储在磁盘上的客户数据，例如 Jira 事务数据（详细信息、评论、附件）或 Confluence 页面数据（页面内容、评论、附件）。静态数据加密有助于防止未经授权的访问，并确保只有经授权的角色和服务才能访问数据，且其对加密密钥的访问权限必须经过审查。

6.04.05. (b)

是否有明确的政策，规定哪些内容应该加密，哪些内容不应该加密？

Atlassian 会维护加密与密码政策和实施准则。我们会根据政策管理计划 (PMP)，每年对本政策进行审查和更新。有关更多信息，请访问：https://www.atlassian.com/trust/security/security-management-program。

Atlassian 会为我们的 Cloud 基础设施维护记录在册的密钥管理程序。Amazon 附件的加密密钥存储在 S3 中，由 Amazon KMS 管理。作为 Amazon 现有审计流程的一部分，Amazon 会定期对加密、密钥管理和解密流程进行内部检查和验证。Atlassian 管理的密钥会在角色或雇用状态发生相关变化时轮换。

6.04.05. (d)

谁持有访问密钥？

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

6.04.05. (e)

如何保护这些密钥？

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

6.04.06. (a)

对于需要高度保证的操作，使用何种形式的身份验证？这可能包括登录管理界面、创建密钥、访问多用户帐户、防火墙配置、远程访问等等。

• 是否使用双重身份验证来管理基础设施内的关键组件（如防火墙等）？

我们遵循 NIST 特别出版物 800-63B 中概述的准则。请访问：https://pages.nist.gov/800-63-3/sp800-63b.html

Atlassian 密码策略中介绍了密码分配流程。除发送一次性初始密码的情况外，不会以电子方式发送新密码。在这些情况下，用户在首次使用时将不得不更改一次性密码。

更广泛地说，访问管理政策中介绍了与访问控制相关的控制措施，可从以下位置访问该政策的摘录：https://www.atlassian.com/trust/security/ismp-policies

Atlassian 基于最低权限，对需要访问我们的系统、应用和基础设施以履行其工作角色和职责的人员实行限制，这是通过我们的身份验证流程强制执行的。所有访问均通过经过身份验证的会话进行，并基于既定权限。

Atlassian 对需要这种访问权限才能履行工作角色和职责的人员保持限制。所有 1 级系统均通过 Atlassian 集中式单一登录 (SSO) 和目录解决方案进行管理。我们会根据这些个人资料，按照我们的人力资源管理系统的工作流程，为用户提供适当的访问权限。Atlassian 利用 MFA 来访问所有的 1 级系统。我们对虚拟机管理程序管理控制台和 AWS API 启用了双重身份验证，并对虚拟机管理程序管理功能的所有访问启用了每日审计报告。我们会每季度对虚拟机管理程序管理控制台和 AWS API 的访问列表进行一次审查。我们还在人力资源系统和身份存储之间保持八小时的同步。

6.04.07. (a)

你们是否提供异常检测（发现异常和潜在恶意 IP 流量以及用户或支持团队行为的能力）？例如，对失败和成功的登录、一天中的不寻常时间以及多次登录等情况进行分析。

我们的 Atlassian Cloud 平台几乎没有通过防火墙暴露的攻击面。我们会定期审查防火墙规则。我们已经在办公场所和云托管环境中部署了 IDS。对于 Atlassian Cloud 平台，日志转发与安全分析平台集成。在 Cloud 平台容器级别，由于实例不可修改，因此可以保持文件完整性。Atlassian 网络工程部门使用内置于我们防火墙中的 IPS 技术，并且我们已经在办公室和云环境中实施了 IDS 技术。DDoS 功能由我们的互联网服务提供商/运营商提供。

关键系统日志从每个系统转发到集中式日志平台，在该平台上，日志为只读模式。Atlassian 安全团队在安全分析平台 (Splunk) 上创建警报，并监控数据泄露指标。我们的 SRE 团队使用此平台监控可用性或性能问题。日志在热备份中保留 30 天，在冷备份中则保留 365 天。

6.04.07. (b)

对于客户凭据被盗的情况，有哪些规定（检测、撤消、行动证据）？

就 Atlassian Cloud 服务而言，客户可能要负责对其控制下的服务用户进行部分或全部访问管理。

因此，Atlassian 通过如下方式帮助我们的客户管理由服务客户控制的服务用户的访问：提供管理或终止访问的管理权限。Atlassian 还会根据泄露的凭据数据库检查客户的凭据，并强制要求用户更新密码。

Atlassian 不会直接在 Cloud 部署过程中提供数据丢失防护 (DLP) 功能。不过，Atlassian Marketplace 中有一些供应商（例如 Nightfall），Atlassian 会向需要这种 DLP 功能的客户推荐这些供应商。点击以下链接可访问 Nightfall 的 Marketplace 产品页面：https://marketplace.atlassian.com/vendors/1217783/nightfall。Nightfall 支持自动扫描敏感信息，包括凭据、密钥和 API 密钥。

Atlassian 已推出 Beacon，Beacon 目前处于测试阶段，并增加了 DLP 功能。在 Beacon 结束测试之前，Atlassian 仍推荐使用 Nightfall。要了解有关 Atlassian Beacon 的更多信息，请访问：https://www.atlassian.com/software/beacon。

我们具有记录在册的安全事件响应政策和计划，其关键原则包括：

• 预测安全事件并为事件响应做好准备
• 遏制、消除事件，并从事件中恢复
• 投资我们的员工、流程和技术，以确保我们有能力在安全事件发生时进行检测和分析
• 发生安全事件时，将保护个人数据和客户数据作为重中之重
• 定期执行安全事件响应流程
• 汲取教训并改进安全事件管理功能
• 向 Atlassian 领导层传达重大安全事件

6.04.08.

以下问题适用于云提供商提供给云客户使用和控制的身份和访问管理系统。

6.04.08.01. (a)

该系统是否允许联合 IDM 基础设施在高度保证（必要时采用 OTP 系统）和低度保证（例如用户名和密码）方面实现互操作？

Atlassian Access 支持在各种 Atlassian 产品（Confluence、Jira、Jira Align、Bitbucket 等）中使用身份联合标准。Atlassian Access 可使用 Okta、Azure AD 或 OneLogin 自动将您的 Active Directory 同步到 Atlassian。有关更多信息，请访问：https://www.atlassian.com/enterprise/cloud/access。特定产品的 SSO 设置（通用 SAML v2.0、Google、Okta、OneLogin、PingIdentity、ADFS）：

• Opsgenie 支持多个 SSO 提供程序。有关更多信息，请访问：https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/
• Trello 支持多个 SSO 提供程序。有关更多信息，请访问：https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization
• Statuspage 支持多个 SSO 提供程序。有关更多信息，请访问：https://help.statuspage.io/knowledge_base/categories/single-sign-on-2

6.04.08.01. (b)

云提供商能否与第三方身份提供程序互操作？

如果 Atlassian 支持，Atlassian 客户可以使用他们选择的第三方身份提供程序。Atlassian 支持页面详细介绍了这些功能以及如何连接您选择的身份提供程序，请访问：https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.04.08.01. (c)

能否整合单一登录功能？

对于 Atlassian 的大多数产品，Atlassian 支持使用 Google、Microsoft 和 Apple 的身份进行身份验证。我们还通过 Atlassian Access 使 Atlassian Cloud 服务支持 SAML。请访问：https://www.atlassian.com/enterprise/cloud/access。

6.04.08.02. (a)

客户凭据系统是否允许角色和职责分离以及多个网域的分离（或一个密钥用于多个网域、角色和职责）？

Atlassian 是一种多租户 SaaS 应用。多租户是 Atlassian Cloud 的一项关键功能，可让多个客户共享 Jira 或 Confluence 应用层的一个实例，同时隔离每个客户租户的应用数据。Atlassian Cloud 通过租户上下文服务 (TCS) 做到这一点。每个用户 ID 仅与一个租户关联，该 ID 随后用于访问 Atlassian Cloud 应用。有关更多信息，请访问：https://www.atlassian.com/trust/security/security-practices#tenant-isolation

使用我们 Enterprise 和 Premium Cloud 产品的客户可以访问集中式管理控制面板。贵组织的管理员可以管理所有产品实例的用户访问和权限。有关我们的博客文章，请访问：https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls。

Atlassian 会为客户提供“组织管理员”角色，负责管理客户产品的用户和群组。有关更多信息，请访问：https://support.atlassian.com/user-management/docs/give-users-admin-permissions/

6.04.08.02. (b)

你们如何管理对客户系统镜像的访问，并确保这些镜像未包含身份验证密钥和加密密钥？

我们的全球支持团队在所有托管系统和应用上都有一个用于维护和支持的帐户。该支持团队会仅出于应用运行状况监视、执行系统或应用维护的目的，以及根据客户通过我们的支持系统提出的请求访问托管应用和数据。

6.04.08.03. (a)

云提供商如何向客户表明自己的身份（即，是否存在相互身份验证）？

• 客户何时发送 API 命令？
• 客户何时登录管理界面？

Atlassian 利用相互身份验证向客户表明自己的身份。Atlassian API 文档可在以下网址找到：https://developer.atlassian.com/cloud/。Atlassian 服务身份验证协议 (ASAP) 是一种服务到服务身份验证协议。ASAP 使用访问令牌，该令牌使用 JSON Web 令牌 (JWT) 来实现，并使用来自 Atlassian 可信机构的 RSA 密钥进行签名。要了解详情，请参阅 Atlassian 服务身份验证协议。我们不使用“服务帐户”的传统概念，而是依赖服务到服务的身份验证和授权。

6.04.08.03. (b)

你们是否支持联合身份验证机制？

Atlassian Access 支持在各种 Atlassian 产品（Confluence、Jira、Jira Align、Bitbucket 等）中使用身份联合标准。Atlassian Access 可使用 Okta、Azure AD 或 OneLogin 自动将您的 Active Directory 同步到 Atlassian。有关更多信息，请访问：https://www.atlassian.com/enterprise/cloud/access。特定产品的 SSO 设置（通用 SAML v2.0、Google、Okta、OneLogin、PingIdentity、ADFS）：

• Opsgenie 支持多个 SSO 提供程序。有关更多信息，请访问：https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/
• Trello 支持多个 SSO 提供程序。有关更多信息，请访问：https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization
• Statuspage 支持多个 SSO 提供程序。有关更多信息，请访问：https://help.statuspage.io/knowledge_base/categories/single-sign-on-2

6.05.

务必确保提供商维护好在云提供商控制下的硬件和软件（应用）资产的最新清单此举可以检查所有系统是否都采用了恰当的控制措施，以及系统是否无法用作基础设施的后门。

6.05. (a)

提供商是否有自动清点所有资产的手段，以便进行恰当的管理？

我们的生产系统位于通过云服务提供商获得的基础设施内。出于服务的本质，我们不会在硬件层面上跟踪这些系统。支撑我们产品运行的底层微服务在定制的“服务”数据库中进行跟踪。该数据库会在部署服务时自动更新。

我们的工作场所技术团队使用我们自己的 Jira 软件来维护所有端点的资产清单，从而满足跟踪需求。

6.05. (b)

是否有清单列出客户在特定时间段内使用的资产？

Atlassian 是一种多租户 SaaS 应用。多租户是 Atlassian Cloud 的一项关键功能，可让多个客户共享 Jira 或 Confluence 应用层的一个实例，同时隔离每个客户租户的应用数据。Atlassian Cloud 通过租户上下文服务 (TCS) 来实现这一点。每个用户 ID 仅与一个租户关联，该 ID 随后用于访问 Atlassian Cloud 应用。有关更多信息，请参阅：https://www.atlassian.com/trust/security/security-practices#tenant-isolation

如果最终客户要部署需要额外保护的（即被视为敏感）的数据，则使用以下问题。

6.05. (c)

资产是否按敏感程度和重要程度进行了分类？

• 如果是，提供商是否在属于不同分类的系统之间，以及为具有多个属于不同安全分类的系统的单个客户进行了适当的隔离？

Atlassian 对资产和服务采用 4 级评级制，每一级均指定了正常运行时间、服务级别和连续性要求。有关更多信息，请参阅：https://www.atlassian.com/trust/security/data-management。

6.06.

为了了解与供应商锁定相关的风险，应考虑以下一组问题。

6.06. (a)

是否有任何记录在册的程序和 API 用于从云导出数据？

客户数据可通过 Web 应用和 API 获取。特定产品的详细信息如下。

• Confluence、Jira 和 Jira Align：有关我们 Atlassian API 的详细信息，请访问以下网址：https://developer.atlassian.com/cloud/jira/platform/rest/v3/
• Trello：面板成员可通过 Trello REST API 导出 JSON 格式的面板数据。可以使用文件的唯一超链接直接从 Amazon S3 中单独检索文件附件。Trello Business Class 和 Enterprise 版本提供了简化的数据导出流程，适用于所有组织的数据和附件。每个 Business Class 和 Enterprise 组织都包含一键导出组织内所有面板的功能。也可以将直接上传到 Trello 的文件附件包含在导出文件中。在导出文件内，每个面板的数据都是以 JSON 和逗号分隔值（“CSV”）格式存在的。
• Opsgenie：API 可在以下网址中找到：https://docs.opsgenie.com/docs/api-overview
• Statuspage：API 可在以下网址中找到：https://doers.statuspage.io/api/v1/
• Bitbucket：出于互操作性目的，可从 Bitbucket 下载或导出任何源代码或代码存储库。请参阅：https://confluence.atlassian.com/bitbucket/does-bitbucket-backup-my-repositories-288658413.html
• Halp：具有 CSV 导出功能。您可访问以下网址，阅读更多文档：https://plz.halp.com/article/5790zlyrun-export-to-csv

6.06. (b)

供应商是否提供适用于在云中存储的所有数据的可互操作导出格式？

如果客户数据在 Atlassian 产品上托管，Atlassian 可以在客户提出请求时帮助导出数据。我们提供可靠的数据便携性和数据管理工具，用于导出产品数据和用户数据。有关 Atlassian Cloud 数据导出的更多信息，请访问以下网址，以查看我们的导入和导出文档：https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/。

此外，有关将数据导出为 CSV、HTML 和 XML 等常见格式的详细信息，请参阅：https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/。

6.06. (c)

就 SaaS 而言，使用的 API 接口是否已标准化？

有关 Atlassian Cloud API 的详细信息，请访问：https://developer.atlassian.com/explore-the-apis/

特定产品 API 详细信息：

• Trello：API 文档可在以下网址中找到：https://developer.atlassian.com/cloud/trello
• Jira Align：API 可在以下网址中找到：https://help.jiraalign.com/hc/en-us/articles/360045371954-Getting-started-with-the-REST-API-2-0
• Statuspage：API 可在以下网址中找到：https://doers.statuspage.io/api/v1
• Opsgenie：API 可在以下网址中找到：https://docs.opsgenie.com/docs/api-overview
• Halp：目前没有公共 API。

6.06. (d)

在以标准格式导出用户创建的应用方面，是否存在任何规定？

这不适用，因为 Atlassian 采用软件即服务 (SaaS) 模式。

6.06. (e)

如果出现客户希望更换供应商等情况，是否有流程对可以导出到其他云供应商的数据进行测试？

如果客户数据在 Atlassian 产品上托管，Atlassian 可以在客户提出请求时帮助导出数据。我们提供可靠的数据便携性和数据管理工具，用于导出产品数据和用户数据。有关 Atlassian Cloud 数据导出的更多信息，请访问以下网址，以查看我们的导入和导出文档：https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/。

此外，有关将数据导出为 CSV、HTML 和 XML 等常见格式的详细信息，请参阅：https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/。

6.06. (f)

客户能否自行提取数据，以验证格式是否通用并且能够迁移到其他云提供商？

如果客户数据在 Atlassian 产品上托管，Atlassian 可以在客户提出请求时帮助导出数据。我们提供可靠的数据便携性和数据管理工具，用于导出产品数据和用户数据。有关 Atlassian Cloud 数据导出的更多信息，请访问以下网址，以查看我们的导入和导出文档：https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/。

此外，有关将数据导出为 CSV、HTML 和 XML 等常见格式的详细信息，请参阅：https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/。

6.07.

提供连续性对组织很重要。尽管可以设置服务级别协议以详细说明系统的最短可用时间，但仍有许多其他注意事项。

6.07. (a)

提供商是否一直采用记录在册的方法来详细说明中断的影响？

• 服务的 RPO（恢复点目标）和 RTO（恢复时间目标）是什么？请根据服务的重要程度进行详细说明。
• 恢复过程中是否会妥善处理信息安全活动？
• 发生中断时，通过什么渠道与最终客户进行沟通？
• 处理中断时，是否明确确定了团队的角色和职责？

已经实施业务连续性和灾难恢复政策以及业务连续性和灾难恢复计划，并且业务连续性/灾难恢复指导委员会每年都会进行审查。有关更多信息（包括与通过使用可用区域实现的 RPO、RTO 和弹性相关的信息），请参阅：https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management 和 https://www.atlassian.com/trust/security/data-management。

我们的合作伙伴数据中心拥有多项合规认证。这些认证涉及物理安全、系统可用性、网络和 IP 主干网访问、客户调配和问题管理。只有获得授权的人员才能进入数据中心，并要通过生物识别身份验证措施加以核验。物理安全措施包括：内部保安人员、闭路视频监控、诱捕系统和其他入侵防护措施。如需了解 AWS 物理保护保障信息，请访问：http://aws.amazon.com/compliance/

6.07. (b)

提供商是否对恢复优先级进行了分类？我们的相对恢复优先级（最终客户）是什么？注意：这可能是一个类别（高/中/低）。

所有任务关键型系统、流程或服务负责人，都要确保实现适当的业务连续性和/或灾难恢复，使其符合灾难中断的承受能力。BCDR 计划每季度测试一次，发现的所有问题都会得到解决。有关更多信息，请参阅：https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management 和 https://www.atlassian.com/trust/security/data-management。

6.07. (c)

存在哪些与恢复过程相关的依赖关系？包括供应商和外包合作伙伴在内。

Atlassian 具有数据恢复工作程序和日志。从高层次来说，这包含在我们内部的备份标准以及业务连续性和灾难恢复政策中。但是，对于每项 Atlassian 服务，我们都有各种内部文档，包括客户启动的恢复与 Atlassian 启动的恢复的运行手册、时间表和程序。

6.07. (d)

如果主站点不可用，最近的辅助站点位置相隔多远？

我们的合作伙伴数据中心拥有多项合规认证。这些认证涉及物理安全、系统可用性、网络和 IP 主干网访问、客户调配和问题管理。进入数据中心仅限获得授权的人员，并通过生物识别身份验证措施加以核验。物理安全措施包括：内部保安人员、闭路视频监控、诱捕系统和其他入侵防护措施。 AWS 物理保护保证信息可在以下网址找到：http://aws.amazon.com/compliance/

6.07.01.

事件管理和响应是业务连续性管理的一部分。此流程的目标是将意外和潜在中断性事件的影响控制在组织可以接受的程度。要评估组织在最大限度降低信息安全事件发生概率或减少其负面影响方面的能力，应向云提供商提出以下问题：

6.07.01. (a)

提供商是否实施了有关检测、识别、分析和应对事件的正式流程？

我们具有记录在册的安全事件响应政策和计划，其关键原则包括：

• 预测安全事件并为事件响应做好准备
• 遏制、消除事件，并从事件中恢复
• 投资我们的员工、流程和技术，以确保我们有能力在安全事件发生时进行检测和分析
• 发生安全事件时，将保护个人数据和客户数据作为重中之重
• 定期执行安全事件响应流程
• 汲取教训并改进安全事件管理功能
• 向 Atlassian 领导层传达重大安全事件


根据该政策，Atlassian 实施了安全事件响应计划。有关我们的安全事件响应流程的更多信息，请参阅：https://www.atlassian.com/trust/security/security-incident-management

关键系统日志从每个系统转发到集中式日志平台，在该平台上，日志为只读模式。Atlassian 安全团队在安全分析平台 (Splunk) 上创建警报，并监控数据泄露指标。SRE 团队使用此平台监控可用性或性能问题。日志在热备份中保留 30 天，在冷备份中则保留 365 天。

有关我们检测计划的更多信息，请参阅：https://www.atlassian.com/trust/security/detections-program

6.07.01. (b)

此流程是否经过演练，以检查事件处理流程的有效性？在演练期间，提供商是否还能确保云提供商支持组织中的每个人都知道该流程，以及他们在事件处理期间（包括事件发生期间和事件后分析期间）扮演的角色？

对于我们的 Atlassian Cloud 服务，业务连续性和灾难恢复计划至少每季度测试一次。多个区域的可用性受到实时监控。每周会在预生产环境中执行自动区域故障转移测试。每天会在生产环境中执行自动配置数据恢复测试。所有 Atlassian 服务每季度都会在预生产环境中执行可用区域弹性测试。有关我们的业务连续性计划的更多信息，请参阅：https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e

作为合规计划的一部分，我们的灾难恢复计划均经过外部审计师的测试和验证，请参阅：https://www.atlassian.com/trust/compliance/resources

我们已通过实时事件活动执行了我们的安全事件响应计划。我们采用持续改进的方法来优化我们的响应能力。

在严重性高达 1 或 2 的事件得到解决后，我们会关闭原始事件工作单，并启动事件后审查 (PIR) 流程。对于高严重性事件，安全团队会执行根本原因分析，并对系统和/或问题的处理提出可能的改进建议。

6.07.01. (c)

如何构建检测功能？

• 云客户如何向提供商报告异常和安全事件？
• 提供商允许哪些设施使用客户选择的第三方 RTSM 服务来干预其系统（在适用情况下）或与云提供商一起协调事件响应功能？
• 是否实施了实时安全监控 (RTSM) 服务？服务是否外包？会监控哪类参数和服务？
• 您是否会（根据请求）提供有关安全事件的定期报告（例如，根据 ITIL 的定义）？
• 安全日志会保留多长时间？这些日志是否会被安全存储？谁有权访问这些日志？
• 客户是否可以在虚拟机映像中构建 HIPS/HIDS？是否可以将客户的入侵检测和防御系统收集的信息集成到云提供商或第三方的 RTSM 服务中？

我们的 Atlassian Cloud 平台几乎没有通过防火墙暴露的攻击面。我们会定期审查防火墙规则。我们已经在办公场所和云托管环境中部署了 IDS。对于 Atlassian Cloud 平台，日志转发与安全分析平台集成。在 Cloud 平台容器级别，由于实例不可修改，因此可以保持文件完整性。Atlassian 网络工程部门使用内置于我们防火墙中的 IPS 技术，并且我们已经在办公室和云环境中实施了 IDS 技术。DDoS 功能由我们的互联网服务提供商/运营商提供。

有关我们检测计划的更多信息，请访问：https://www.atlassian.com/trust/security/detections-program关键系统日志从每个系统转发到集中式日志平台，在该平台上，日志为只读模式。Atlassian 安全团队在安全分析平台 (Splunk) 上创建警报，并监控数据泄露指标。我们的 SRE 团队使用此平台监控可用性或性能问题。日志在热备份中保留 30 天，在冷备份中则保留 365 天。Atlassian 仅限已获授权的人员能够在我们的集中式日志记录平台上查看和读取审核日志。Atlassian 还维护外部报告渠道，通过这些渠道我们可以发现漏洞或事件，包括通过我们的缺陷赏金计划、我们的客户支持门户以及定义的安全电子邮件收件箱和电话号码。Atlassian 鼓励客户举报任何未获授权的访问或恶意行为。有关更多信息，请访问：https://www.atlassian.com/trust/security/security-incident-management 和 https://www.atlassian.com/trust/security/security-incident-responsibilities。

6.07.01. (d)

如何定义严重性级别？

Atlassian 使用通用漏洞评分系统 (CVSS) 作为评估安全风险和确定每个所发现漏洞优先级的方法。使用的安全级别基于 Atlassian 自行计算的 CVSS 分数，包括：

• 严重，
• 高，
• 中等，以及
• 低。


有关更多详细信息，包括确定严重性的分数范围，请访问：https://www.atlassian.com/trust/security/security-severity-levels。

6.07.01. (e)

如何定义上报程序？云客户何时（如果有的话）参与其中？

我们具有记录在册的安全事件响应政策和计划，其关键原则包括：

• 预测安全事件并为事件响应做好准备
• 遏制、消除事件，并从事件中恢复
• 投资我们的员工、流程和技术，以确保我们有能力在安全事件发生时进行检测和分析
• 发生安全事件时，将保护个人数据和客户数据作为重中之重
• 定期执行安全事件响应流程
• 汲取教训并改进安全事件管理功能
• 向 Atlassian 领导层传达重大安全事件


根据该政策，Atlassian 实施了安全事件响应计划。有关我们的安全事件响应流程的更多信息，请访问：https://www.atlassian.com/trust/security/security-incident-management

Atlassian 了解及时收到任何数据泄露的通知对您来说有多重要。正因为如此，Atlassian 建立了庞大的跨职能团队和流程来处理安全事件，如以下位置中所述：https://www.atlassian.com/trust/security/security-incident-management

Atlassian 在及时主动通知事件以及与客户合作采取任何必要缓解措施方面成绩斐然。

由于 Atlassian 的安全事件响应团队必须在事件开始显现时立即集中精力分类鉴别和缓解事件，因此我们不能同意以 72 小时为时间线。不过，我们会“毫无拖延”地为客户提供通知，这符合 GDPR 对数据处理者的法律要求，也满足我们大多数客户的法律需求。

事件可能非常简单，也可能异常复杂，因此，尽管我们可以提供法律规定的必要措施，但不能同意按照“一刀切”的时间线来执行。

6.07.01. (f)

如何记录事件和收集证据？

Jira 请求单是为跟踪和修复目的而创建的，到期时间是按照漏洞的严重性和来源根据我们的 SLO 分配的。我们有一个持续的流程，向系统负责人发出已识别漏洞的请求单，我们的安全管理团队会审查所有报告的漏洞并确保对其采取措施。

在严重性高达 1 级或 2 级的事件得到解决后，我们会关闭原始事件请求单，并启动事件后审查 (PIR) 流程。对于高严重性事件，安全团队会执行根本原因分析，并对系统和/或问题的处理提出可能的改进建议。

6.07.01. (g)

除了身份验证、会计和审计外，还有哪些其他控制措施用于防止内部人员恶意活动（或最大限度地减少内部人员恶意活动的影响）？

Atlassian 已经在我们的办公场所和云托管环境中部署了 IDS。日志转发与 Atlassian Cloud 平台的安全分析平台相集成。关键系统日志从每个系统转发到集中式日志平台，在该平台上，日志为只读模式。Atlassian 安全团队在安全分析平台 (Splunk) 上创建警报，并监控数据泄露指标。有关我们检测计划的更多信息，请访问：https://www.atlassian.com/trust/security/detections-program

6.07.01. (h)

提供商是否会收集事件指标（即每月检测到或报告的事件数量、云提供商的分包商造成的事件数量以及此类事件的总数、响应和解决事件的平均时间等）？

• 提供商会公开发布哪些数据（请注意，并非所有事件报告数据都可以公开，因为这可能会损害客户机密性并泄露关键安全信息）？

目前，我们不会公开内部指标，但我们确实会在 Statuspage 上分享"严重性 0 级或严重性 1 级运营事件的事件后措施“，请访问：https://status.atlassian.com/。

6.07.01. (j)

提供商多久测试一次灾难恢复和业务连续性计划？

对于我们的 Atlassian Cloud 服务，我们会每季度至少测试一次业务连续性和灾难恢复计划。实时监控多个区域的可用性。每周会在预生产环境中执行自动区域故障转移测试。每天会在生产环境中执行自动配置数据恢复测试。所有 Atlassian 服务每季度都会在预生产环境中执行可用区域弹性测试。有关我们的业务连续性计划的更多信息，请访问：https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e

作为合规计划的一部分，我们的外部审计人员会测试和验证我们的灾难恢复计划，请访问：https://www.atlassian.com/trust/compliance/resources

6.07.01. (k)

提供商是否会根据 SLA 收集有关满意度级别的数据？

我们会监控所有 Cloud 实例的性能和可用性，但目前我们不提供正式的应用可用性 SLA。我们的支持团队会提供初始响应时间 SLA，虽然我们没有正式的支持解决 SLA，但我们的内部目标是在 48 小时内解决所有分配的案例。Atlassian 会在以下位置显示我们最新 Cloud 系统状态的统计数据：https:status.atlassian.com。

如果您选择使用我们的 Premium 或 Enterprise 产品，我们会提供 SLA 保障。

6.07.01. (l)

提供商是否会执行帮助台测试？例如：

• 模拟测试（在电话那端请求重置密码的人真的就是他们所说的那个人吗？）或所谓的“社会工程”攻击。

Atlassian 会为新员工提供信息安全培训，作为其入职培训（“第 1 天”）的一部分，并为所有员工持续提供此类培训。

除了此类常规信息安全培训外，还为我们的开发人员提供更有针对性的安全编码相关培训，并由我们的嵌入式安全工程师计划提供支持。

我们还提供与恶意软件、网络钓鱼和其他安全问题相关的持续主题培训。https://www.atlassian.com/trust/security/security-practices#security-awareness-training

我们会保留完成内部员工培训的正式记录。员工必须认可《行为准则》，并每年重申一次。本政策适用于所有员工。我们会在新员工第一天培训中提出安全意识、保密和隐私要求，这些要求适用于 Confluence 中的所有员工。

6.07.01. (m)

提供商是否会执行渗透测试？多久一次？渗透测试期间实际会测试什么—例如，他们是否会测试每个映像的安全隔离，以确保无法从一个映像“逃离”到另一个映像中，也无法获取主机基础架构的访问权限？此类测试还应检查是否可以通过虚拟映像获取云提供商管理和支持系统（例如，调配和管理员访问控制系统）的访问权限。

我们有一个内部 Red Team，负责对我们所有的基础架构、云服务和人员进行持续的渗透测试操作。

我们聘请第三方咨询公司对面向外部的应用进行年度渗透测试。我们的内部安全测试团队也会进行小规模的持续安全测试活动，以补充这些测试。有关这些渗透测试的评估报告以及有关我们的测试流程和外部安全测试方法的更多信息，请访问：https://www.atlassian.com/trust/security/security-testing。

6.07.01. (n)

提供商是否会执行漏洞测试？多久一次？

我们的 Atlassian 安全团队会使用行业认可的漏洞扫描程序持续对内部和外部基础架构进行网络漏洞扫描。有关我们的漏洞管理计划的更多信息，请访问：https://www.atlassian.com/trust/security/vulnerability-management。

6.07.01. (o)

修复漏洞（修补程序、重新配置、升级到软件的更高版本等）的流程是什么？

Jira 请求单是为跟踪和修复目的而创建的，到期时间是按照漏洞的严重性和来源根据我们的 SLO 分配的。我们有一个持续的流程，向系统负责人发出已识别漏洞的请求单，我们的安全管理团队会审查所有报告的漏洞并确保对其采取措施。

有关我们的漏洞管理计划的详细信息，请访问：https://www.atlassian.com/trust/security/vulnerability-management。

6.08.

与人员安全一样，许多潜在问题的出现是因为 IT 基础架构在第三方控制之下，就像传统外包一样，物理安全漏洞的影响可能会波及多个客户（组织）。

6.08. (a)

对于地点的物理安全，您会为客户提供哪些保障？请提供示例，以及遵守的任何标准，例如ISO 27001/2 的第 9 节。

办公室物理安全控制以我们的物理和环境安全政策为指导，确保在我们的本地和云端环境中实施强有力的物理安全举措。

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

6.08. (a) (i)

除了获得授权的 IT 人员之外，还有谁可以在无人陪同的情况下（物理）访问 IT 基础架构？

• 例如，清洁工、经理、“人身安全”员工、承包商、顾问、供应商等。

我们的 Atlassian 办公室以我们内部的物理和环境安全政策为指导，包括监控物理入口和出口点。我们在以下位置发布了所有内部技术运营和安全政策的摘录：https://www.atlassian.com/trust/security/ismp-policies

Atlassian 办公室采取了措施来控制人员进出（包括胸牌读取器和监控摄像头），而且根据需要只允许人员在特定时间/日期进出。办公楼的进出日志由大楼管理团队维护，并且可供工作场所体验团队用于调查目的。

我们的合作伙伴数据中心拥有多项合规认证。这些认证涉及物理安全、系统可用性、网络和 IP 主干网访问、客户调配和问题管理。只有获得授权的人员才能进入数据中心，并要通过生物识别身份验证措施加以核验。物理安全措施包括：内部保安人员、闭路视频监控、诱捕系统和其他入侵防护措施。如需了解 AWS 物理保护保障信息，请访问：http://aws.amazon.com/compliance

6.08. (a) (ii)

多久审查一次访问权限？

• 撤消访问权限的速度有多快？

Atlassian 使用合适的指标来评估其 ISMS 的效果和有效性。我们通过内部和外部审计审查来监控 Atlassian Trust Management System (ATMS) 和相关控制措施的效果。Atlassian 合规团队既管理内部/内部就绪情况审计时间表，也管理外部审计时间表（在内部记录于“审计路线图”页面上）。内部审计重点关注 Atlassian 的高风险领域，并根据预先确定的时间表和企业审计时间表（由风险与合规团队以及内部审计团队双方商定）定期进行。目前，我们未公开内部指标。ATMS 每年由独立第三方进行评估，而且在发生任何重大变化后也会接受评估。Atlassian 的各项主要云服务均已获得 SOC 2、ISO27001 和 ISO7018 认证。Atlassian 还通过定期举行运营审查会议来监控 ATMS 的每个支柱（包括按照每个支柱的具体指标进行监控）。监控工作包括每周审查 ATMS 的合规状况，以及举行其他审查会议，审查结果在内部记录于我们的“ATMS：合规状况审查”页面和“ATMS 会议记录”页面上。有关更多信息，请参阅 https://www.atlassian.com/trust/compliance。

我们制定了正式的安全管理计划，并且每年都会审查我们的信息安全管理计划 (ISMP)。有关我们的安全管理计划的更多信息，请参阅：https://www.atlassian.com/trust/security/security-management-program

6.08. (a) (iii)

你们是否定期评估安全风险和边界？

• 多久评估一次？

Atlassian 使用合适的指标来评估其 ISMS 的效果和有效性。我们通过内部和外部审计审查来监控 Atlassian Trust Management System (ATMS) 和相关控制措施的效果。Atlassian 合规团队既管理内部/内部就绪情况审计时间表，也管理外部审计时间表（在内部记录于“审计路线图”页面上）。内部审计重点关注 Atlassian 的高风险领域，并根据预先确定的时间表和企业审计时间表（由风险与合规团队以及内部审计团队双方商定）定期进行。目前，我们未公开内部指标。ATMS 每年由独立第三方进行评估，而且在发生任何重大变化后也会接受评估。Atlassian 的各项主要云服务均已获得 SOC 2、ISO27001 和 ISO7018 认证。Atlassian 还通过定期举行运营审查会议来监控 ATMS 的每个支柱（包括按照每个支柱的具体指标进行监控）。监控工作包括每周审查 ATMS 的合规状况，以及举行其他审查会议，审查结果在内部记录于我们的“ATMS：合规状况审查”页面和“ATMS 会议记录”页面上。有关更多信息，请参阅 https://www.atlassian.com/trust/compliance。

我们制定了正式的安全管理计划，并且每年都会审查我们的信息安全管理计划 (ISMP)。有关我们的安全管理计划的更多信息，请参阅：https://www.atlassian.com/trust/security/security-management-program

6.08. (a) (iv)

你们是否定期进行风险评估（包括评估邻近建筑物之类的对象）？

Atlassian 使用合适的指标来评估其 ISMS 的效果和有效性。我们通过内部和外部审计审查来监控 Atlassian Trust Management System (ATMS) 和相关控制措施的效果。Atlassian 合规团队既管理内部/内部就绪情况审计时间表，也管理外部审计时间表（在内部记录于“审计路线图”页面上）。内部审计重点关注 Atlassian 的高风险领域，并根据预先确定的时间表和企业审计时间表（由风险与合规团队以及内部审计团队双方商定）定期进行。目前，我们未公开内部指标。ATMS 每年由独立第三方进行评估，而且在发生任何重大变化后也会接受评估。Atlassian 的各项主要云服务均已获得 SOC 2、ISO27001 和 ISO7018 认证。Atlassian 还通过定期举行运营审查会议来监控 ATMS 的每个支柱（包括按照每个支柱的具体指标进行监控）。监控工作包括每周审查 ATMS 的合规状况，以及举行其他审查会议，审查结果在内部记录于我们的“ATMS：合规状况审查”页面和“ATMS 会议记录”页面上。有关更多信息，请参阅 https://www.atlassian.com/trust/compliance。

我们制定了正式的安全管理计划，并且每年都会审查我们的信息安全管理计划 (ISMP)。有关我们的安全管理计划的更多信息，请参阅：https://www.atlassian.com/trust/security/security-management-program

6.08. (a) (v)

你们是否控制或监控进出安全区域的人员（包括第三方）？

我们的 Atlassian 办公室以我们内部的物理和环境安全政策为指导，包括监控物理入口和出口点。我们已经发布了所有内部技术运营和安全政策的摘录，网址为：https://www.atlassian.com/trust/security/ismp-policies

Atlassian 办公室采取了措施来控制进出（包括胸牌读取器和监控摄像头），而且必要时能只允许人员在特定时间/日期进出。办公楼的进出日志由大楼管理团队维护，并且可供工作场所体验团队用于调查目的。

我们的合作伙伴数据中心拥有多项合规认证。这些认证涉及物理安全、系统可用性、网络和 IP 主干网访问、客户调配和问题管理。只有获得授权的人员才能进入数据中心，并要通过生物识别身份验证措施加以核验。物理安全措施包括：内部保安人员、闭路视频监控、诱捕系统和其他入侵防护措施。如需了解 AWS 物理保护保障信息，请访问：http://aws.amazon.com/compliance

6.08. (a) (vi)

你们在装载、卸载和安装设备方面制定了哪些政策或程序？

在 Atlassian 办公设施中，装载区与工作区隔离，并由闭路电视和楼宇工作人员时刻监控。我们的数据中心托管合作伙伴会管理物理安全，我们依靠他们的合规认证来验证控制措施是否有效。

6.08. (a) (vii)

安装前是否会检查交付物有无风险？

在 Atlassian 办公设施中，装载区与工作区隔离，并由闭路电视和楼宇工作人员时刻监控。我们的数据中心托管合作伙伴会管理物理安全，我们依靠他们的合规认证来验证控制措施是否有效。

6.08. (a) (viii)

是否有数据中心内部物品的最新实物清单？

我们的资产管理政策的摘录可在以下网址找到：https://www.atlassian.com/trust/security/ismp-policies。Atlassian 维护所有生产资产以及资产所有者的清单。我们的所有系统都位于基于 AWS 的数据中心内。出于服务的本质，我们不会在硬件层面上跟踪这些 AWS 系统。

所有微服务都在专门定制的服务数据库中进行跟踪，该数据库会在有任意服务部署时进行更新。Atlassian 工作场所技术 (WPT) 团队使用我们自己的 Jira 软件来维护所有端点的资产清单，从而满足跟踪需求。

所有微服务都按层级进行分类，每个层级都有相关联的正常运行时间、可用性、RTO 和 RPO 期望值。有关示例，请参阅：https://www.atlassian.com/trust/security/data-management

6.08. (a) (ix)

网络电缆是否穿过公共通道区域？

• 你们是否使用铠装电缆或导管？

我们的 Atlassian 办公室以我们内部的物理和环境安全政策为指导，包括监控物理入口和出口点。我们已经发布了所有内部技术运营和安全政策的摘录，网址为：https://www.atlassian.com/trust/security/ismp-policies

Atlassian 办公室采取了措施来控制进出（包括胸牌读取器和监控摄像头），而且必要时能只允许人员在特定时间/日期进出。办公楼的进出日志由大楼管理团队维护，并且可供工作场所体验团队用于调查目的。

6.08. (a) (x)

你们是否会定期检查工作场地，查找有无未经授权的设备？

我们的资产管理政策的摘录可在以下网址找到：https://www.atlassian.com/trust/security/ismp-policies。Atlassian 维护所有生产资产以及资产所有者的清单。我们的所有系统都位于基于 AWS 的数据中心内。出于服务的本质，我们不会在硬件层面上跟踪这些 AWS 系统。

所有微服务都在专门定制的服务数据库中进行跟踪，该数据库会在有任意服务部署时进行更新。Atlassian 工作场所技术 (WPT) 团队使用我们自己的 Jira 软件来维护所有端点的资产清单，从而满足跟踪需求。

6.08. (a) (xi)

是否有任何场外设备？

• 如何保护这些设备？

我们的资产管理政策的摘录可在以下网址找到：https://www.atlassian.com/trust/security/ismp-policies。Atlassian 维护所有生产资产以及资产所有者的清单。我们的所有系统都位于基于 AWS 的数据中心内。出于服务的本质，我们不会在硬件层面上跟踪这些 AWS 系统。

所有微服务都在专门定制的服务数据库中进行跟踪，该数据库会在有任意服务部署时进行更新。Atlassian 工作场所技术 (WPT) 团队使用我们自己的 Jira 软件来维护所有端点的资产清单，从而满足跟踪需求。

6.08. (a) (xii)

你们的人员是否使用可以访问数据中心的便携式设备（例如笔记本电脑、智能手机）？

• 如何保护这些设备？

我们的合作伙伴数据中心拥有多项合规认证。这些认证涉及物理安全、系统可用性、网络和 IP 主干网访问、客户调配和问题管理。只有获得授权的人员才能进入数据中心，并要通过生物识别身份验证措施加以核验。物理安全措施包括：内部保安人员、闭路视频监控、诱捕系统和其他入侵防护措施。如需了解 AWS 物理保护保障信息，请访问：http://aws.amazon.com/compliance/

Atlassian 工程团队中经过背景调查和培训并获得授权的成员使用唯一的强密码与基于 TOTP 的双重身份验证向 VPN 进行身份验证，并且只能使用受密码保护的个人 RSA 证书通过 SSH 终端连接来访问生产环境。所有生产服务器上都安装了 IDS 系统，其中包括实时监控生产系统文件或配置的所有更改以及异常安全事件，并就此发出警报。对于经过培训并获得授权且有权访问生产系统的运营团队成员，任何运行 Windows 或 OS X 且用于通过 SSH 终端访问生产环境的工作站都必须运行最新的有效防病毒软件。客户数据不会复制到员工的工作站或移动设备上。

6.08. (a) (xiii)

采取了哪些措施来控制门禁卡？

我们的 Atlassian 办公室以我们内部的物理和环境安全政策为指导，包括监控物理入口和出口点。我们已经发布了所有内部技术运营和安全政策的摘录，网址为：https://www.atlassian.com/trust/security/ismp-policies

Atlassian 办公室采取了措施来控制进出（包括胸牌读取器和监控摄像头），而且必要时能只允许人员在特定时间/日期进出。办公楼的进出日志由大楼管理团队维护，并且可供工作场所体验团队用于调查目的。

6.08. (a) (xiv)

如果需要，你们会采取哪些流程或程序来销毁陈旧的媒体或系统？

• 进行数据覆盖？
• 进行物理销毁？

工作场所技术团队负责处理此过程，以适当的方式清理和删除设备中的数据。Atlassian 并不管理任何支持我们的云产品和服务的物理媒体。

6.08. (a) (xv)

制定了哪些与在站点之间移动设备有关的授权流程？

• 你们如何识别有权这样做的员工（或承包商）？

Atlassian 的数据中心托管合作伙伴 (AWS) 会管理物理安全，而且我们使用其 SOC2 来验证控制措施是否有效。

Atlassian Cloud 产品不会实际移动客户数据。在包含客户数据的硬盘离开我们安全的 AWS 数据中心之前，我们会将其销毁或清理其中的数据。对于在 AWS 中托管的系统，数据可能会在冗余场景下在区域之间移动，但仍保留在 AWS 内。有关我们的 AWS 区域的更多信息，请参阅：https://www.atlassian.com/trust/reliability/infrastructure。

6.08. (a) (xvi)

多久进行一次设备审计，以监控是否存在未经授权便拆除设备的现象？

Atlassian 的数据中心托管合作伙伴 (AWS) 会管理物理安全，而且我们使用其 SOC2 来验证控制措施是否有效。

Atlassian Cloud 产品不会实际移动客户数据。在包含客户数据的硬盘离开我们安全的 AWS 数据中心之前，我们会将其销毁或清理其中的数据。对于在 AWS 中托管的系统，数据可能会在冗余场景下在区域之间移动，但仍保留在 AWS 内。有关我们的 AWS 区域的更多信息，请参阅：https://www.atlassian.com/trust/reliability/infrastructure。

6.08. (a) (xvii)

多久进行一次检查，以确保场所环境遵守了适当的法律和监管要求？

我们的 Atlassian 法律团队与合规团队负责监督我们的监管义务。请访问 https://www.atlassian.com/legal/，以了解我们的法律计划。有关我们的合规计划的更多信息，请访问：https://www.atlassian.com/trust/compliance。

6.09. (a)

制定了哪些程序或政策来确保环境问题不会导致服务中断？

我们的 Atlassian 办公室以我们内部的物理和环境安全政策为指导，包括监控物理入口和出口点。

我们的合作伙伴数据中心拥有多项合规认证。这些认证涉及物理安全、系统可用性、网络和 IP 主干网访问、客户调配和问题管理。只有获得授权的人员才能进入数据中心，并要通过生物识别身份验证措施加以核验。物理安全措施包括：内部保安人员、闭路视频监控、诱捕系统和其他入侵防护措施。如需了解 AWS 物理保护保障信息，请访问：http://aws.amazon.com/compliance/

已经实施业务连续性和灾难恢复政策以及业务连续性和灾难恢复计划，并且业务连续性/灾难恢复指导委员会每年都会相应进行审查。所有任务关键型系统、流程或服务负责人，都要确保实现适当的业务连续性和/或灾难恢复，使其符合灾难中断的承受能力。BCDR 计划每季度测试一次，发现的所有问题都会得到解决。有关更多信息，请参阅：https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management 和 https://www.atlassian.com/trust/security/data-management。

6.09. (b)

你们使用哪些方法来防止火灾、洪水、地震等造成的损害？

• 发生灾难时，你们会采取哪些额外的安全措施来保护物理访问
• （包括主站点和辅助站点）？

Atlassian 依靠我们的数据托管合作伙伴来验证其数据中心安全性和环境控制措施。有关 AWS 的信息，请参阅 https://aws.amazon.com/compliance/programs。

6.09. (c)

你们是否监测数据中心的温度和湿度？

• 是否考虑空调因素或监测空调？

Atlassian 依靠我们的数据托管合作伙伴来验证其数据中心安全性和环境控制措施。有关 AWS 的信息，请参阅 https://aws.amazon.com/compliance/programs。

6.09. (d)

你们的建筑是否有防雷击措施？

• 是否将电气和通信线路包括在内？

Atlassian 依靠我们的数据托管合作伙伴来验证其数据中心安全性和环境控制措施。有关 AWS 的信息，请参阅 https://aws.amazon.com/compliance/programs。

6.09. (e)

如果停电，你们是否有独立的发电机？

• 它们能运行多长时间？
• 是否有足够的燃料供应？
• 是否有故障转移发电机？
• 你们多久检查一次 UPS 设备？
• 你们多久检查一次发电机？
• 你们是否有多个电力供应商？

Atlassian 依靠我们的数据托管合作伙伴来验证其数据中心安全性和环境控制措施。有关 AWS 的信息，请参阅 https://aws.amazon.com/compliance/programs。

6.09. (f)

所有公用事业服务（电、水等）是否都能够为你们的环境提供支持？

• 多久对此重新评估和测试一次？

Atlassian 依靠我们的数据托管合作伙伴来验证其数据中心安全性和环境控制措施。有关 AWS 的信息，请参阅 https://aws.amazon.com/compliance/programs。

6.09. (g)

你们的空调能否为你们的环境提供支持？

• 多久测试一次空调？

Atlassian 依靠我们的数据托管合作伙伴来验证其数据中心安全性和环境控制措施。有关 AWS 的信息，请参阅 https://aws.amazon.com/compliance/programs。

6.09. (h)

你们是否遵循制造商建议的维护时间表？

Atlassian 依靠我们的数据托管合作伙伴来验证其数据中心安全性和环境控制措施。有关 AWS 的信息，请参阅 https://aws.amazon.com/compliance/programs。

6.09. (i)

您是否只允许已获授权的维护或维修人员进入现场？

• 您如何核查他们的身份？

我们通过电子通行证、在营业时间接待处强制要求访客做好登记以及在所有楼宇的出入口安装闭路电视来保障出入办公设施的安全性。装货点由闭路电视和楼宇工作人员时刻监控。我们的数据中心托管合作伙伴会管理物理安全，我们依靠他们的合规认证来验证控制措施是否有效。

6.09. (j)

当设备被送去维修时，是否会先清除设备上的数据？

• 这是怎么做的？

工作场所技术团队负责处理此过程，以适当的方式清理和删除设备中的数据。Atlassian 并不管理任何支持我们的云产品和服务的物理媒体。

6.10.

云提供商服务的客户和潜在客户应考虑各自在遵守监管框架方面的国家和超国家义务，并确保任何此类义务得到适当履行。

客户应向云提供商询问以下关键法律问题：

6.10. (a)

云提供商位于哪个国家/地区？

Atlassian 在 8 个国家/地区设有 12 个办事处，包括悉尼、阿姆斯特丹、安卡拉、波士顿、班加罗尔、旧金山、山景城、德克萨斯州奥斯汀、纽约、马尼拉、格但斯克和日本。有关更多信息，请访问：https://www.atlassian.com/company/contact。

6.10. (b)

云提供商的基础架构是位于同一个国家/地区还是位于不同的国家/地区？

对于 Atlassian Cloud，我们目前托管在冗余的 AWS 可用区域内。有关特定区域的信息，请访问：https://www.atlassian.com/trust/reliability/infrastructure。

6.10. (c)

云提供商是否会使用其基础架构位于云提供商公司之外的其他公司？

Atlassian Cloud 产品和数据托管在业界领先的云提供商 Amazon Web Services (AWS) 中。我们的产品在平台即服务 (PaaS) 环境中运行，该环境分为两组主要的基础架构，我们称之为 Micros 和非 Micros。Jira、Confluence、Statuspage、Access 和 Bitbucket 在 Micros 平台上运行，而 Opsgenie 和 Trello 在非 Micros 平台上运行。

6.10. (d)

数据的物理存储位置位于哪里？

Atlassian 在美国东部、美国西部、爱尔兰、法兰克福、新加坡和悉尼地区（Confluence 和 Jira）使用 Amazon Web Services (AWS)。

特定产品详细信息如下所述：

• Trello：在 AWS 美国东部（俄亥俄州）地区可用。
• Jira Align：客户数据的物理位置可以通过支持请求单申请来申请获取。请访问：https://support.atlassian.com/jira-align/。
• Statuspage：在 AWS 美国西部（俄勒冈州、加利福尼亚州）、美国东部（俄亥俄州）地区可用。
• Opsgenie：在美国和欧洲都有 AWS 帐户。客户应在注册时选择 AWS 美国（俄勒冈州、加利福尼亚州）或欧盟（法兰克福）。
• Halp：托管在美国东部（俄亥俄州）和美国西部（俄勒冈州）地区的 AWS。
• Bitbucket：存储库与核心应用功能由美国东部和美国西部地区的 AWS 托管。


有关数据驻留的更多信息，请访问：https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/。

6.10. (e)

是否会对合同条款和数据的管辖权进行划分？

Atlassian 客户合同的默认适用法律是加利福尼亚州的法律。请联系我们的企业销售团队，了解更多详情。

6.10. (f)

是否会分包云提供商的任何服务？

Atlassian 与第三方分包商合作，提供网站、应用开发、托管、维护、备份、存储、虚拟基础架构、支付处理、分析和其他服务。这些服务提供商可能会以向我们提供这些服务为目的来访问或处理 PII。

Atlassian 在处理之前会通过通知向其相关客户披露可能会用于处理其 PII 的任何分包商。我们在“Atlassian 辅助处理商”页面 (https://www.atlassian.com/legal/sub-processors) 上提供了与 Atlassian 合作的外部分包商列表。在该页面上，会邀请访客订阅 RSS 源，以便在我们添加新 Atlassian 辅助处理商时接收通知。

6.10. (g)

是否会外包云提供商的任何服务？

在 Atlassian 与任何第三方供应商合作时，我们致力于确保这些合作不会以任何方式危害我们的客户或其数据。Atlassian 法律和采购部门会审查合同、SLA 和供应商内部政策，以确定供应商是否符合安全性、可用性和机密性要求。有关更多信息，请访问：https://www.atlassian.com/trust/security/security-practices#supplier-risk-management。

6.10. (h)

我们会如何收集、处理和传输客户以及客户的客户提供的数据？

Atlassian 会按照信息收集之目的或个人后来授权的用途来处理信息，尤其是会遵守 Atlassian 外部隐私政策。

在 Atlassian，我们十分重视用户隐私，同样也重视对我们收集、使用和共享用户信息的方式保持透明。有关更多信息，请参阅我们在 Atlassian Trust Center 中的“Atlassian 隐私”页面 (https://www.atlassian.com/trust/privacy) 以及我们的隐私政策 (https://www.atlassian.com/legal/privacy-policy)。

6.10. (i)

合同终止后，会如何处理发送给云提供商的数据？

Atlassian 会维护数据保留和销毁标准，该标准规定了我们需要多长时间来维护不同类型的数据。我们会根据我们的《Atlassian 数据安全和信息生命周期政策》对数据进行分类，并在此基础上实施相应的控制措施。

对于客户数据，在 Atlassian 合同终止后，属于客户团队的数据将从实时生产数据库中删除，直接上传到 Atlassian 的所有文件附件将在 14 天内删除。团队的数据将保留在加密备份中，直到这些备份超出 90 天的备份保留期并根据我们的 Atlassian 数据保留政策被销毁。如果需要在请求删除数据后的 90 天内恢复数据库，运营团队将在实时生产系统完全还原后尽快重新删除数据。有关更多信息，请访问：https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/