Backstage威胁模型

威胁模型为操作员、开发人员和安全研究人员概述了 Backstage 的主要安全考虑因素。 这是一份动态文件，将随着 Backstage 项目的发展而不断发展和扩充。

参见安全政策和建议在 Backstage GitHub 存储库中查看有关报告安全漏洞和已修复安全漏洞公告的详细信息。

信任模式

Backstage 信任模型分为三组，信任度各不相同。

一个内部用户是经过验证的用户，一般属于特定 Backstage 部署的组织。 这些用户受信任的程度是不会危及 Backstage 的可用性，但不会危及数据的Secret性或完整性。

一个集成商是负责配置和维护Backstage实例的用户。 集成者是完全受信任的，因为他们操作系统和数据库，因此拥有对主机系统的根访问权限。 Backstage的采用者可以采取其他措施来限制或观察该组用户的访问权限，但这不属于Backstage的当前范围。

另一个事实上的集成者群体是内部和外部的代码贡献者。 在安装Backstage插件时，您应该像其他来自外部的软件包一样对其进行审查。 虽然可以通过将部署拆分为使用不同插件的独立服务来限制供应链攻击等的影响，但Backstage项目本身并不旨在防止此类攻击，也不以任何其他方式沙箱或限制插件的访问。

一个外部用户是指不属于其他两组的用户，例如组织外部的恶意行为者。 Backstage的安全模型目前假定该组没有任何直接访问Backstage的权限，每个采用Backstage的用户都有责任确保这一点。

集成商职责

作为 Backstage 的集成商，您自己有责任保护您的 Backstage 安装免受外部和未经授权的访问。 Backstage 中的登录系统并不是为了限制访问而存在的，只是为了告知系统用户的身份。 有些插件可以通过权限系统进行更精细的访问控制，但该系统的主要目的是限制内部用户对资源的访问，而不是限制整个 Backstage 的访问。 保护 Backstage 部署免受未经授权的访问的常用和推荐方法是将其部署在一个身份验证代理(如 AWS 的 ALB、GCP 的 IAP 或 Cloudflare Access)后面。

其他责任还包括保护配置文件的完整性，否则就有可能引入易受攻击的配置，以及与Backstage相关的配置Secret的保密性，因为这些Secret通常包括第三方系统的验证细节。

集成者最终负责审核内部和外部插件的使用情况，因为这些插件在主机系统上运行，可以访问配置和Secret。 从 NPM 等来源安装插件时，应像审核从该来源安装的任何其他软件包一样审核这些插件。

集成商还负责维护其 Backstage 项目中已解决的 NPM 依赖关系。 这包括确保yarn.lock接收存在漏洞的软件包的更新版本，当这些修复版本与Backstage软件包在各自的package.json这通常是通过使用自动工具来实现的，例如依赖机器人,Snyk和/或翻新当存在的固定版本是不是在 Backstage 软件包要求的范围内，或者当需要进行较大的操作(如将整个依赖关系换成另一个依赖关系)时，维护者会与贡献者合作，尽快在主项目中解决这些依赖关系声明。

共通后端配置

有许多公共设施都是集中配置的，所有Backstage后端插件都可以使用。 例如，有一个DatabaseManager可访问 SQL 数据库、TaskScheduler用于调度长期运行的任务、Logger作为一般伐木设施，以及UrlReader这些都可以直接在代码中配置，或在backend需要注意的是，要确保任何Secret都是保密的，也不能注入恶意配置。

在典型的 Backstage 设置中，运行在同一主机上的插件之间没有界限。 同样，共享相同数据库访问权限的插件之间也没有界限。 运行在主机上的任何插件，如果可以访问任何其他插件的逻辑数据库，则应被视为可以完全访问该其他插件。 例如，即使您部署了auth和catalog在不同的主机上使用不同的配置和凭据来运行插件。catalog插件仍然被认为可以完全访问auth插件，只要catalog插件可以访问auth要在两个插件之间建立边界，唯一的办法是在部署时避免它们访问对方的数据库。 这适用于数据库设施和任何其他共享资源，如缓存。

UrlReader对于安全的 Backstage 配置来说，该设施尤其重要。backend.reading.allow配置列出了您信任后端能够代表用户读取内容的主机。 该列表不允许访问云提供商的实例元数据端点或 Backstage 实例可能访问的包含敏感信息的其他端点，这一点极为重要。 一般来说，建议将列表保持在最小范围，只允许从所需端点读取内容。UrlReader接口，如果需要通过代码来实现这些功能。

请注意UrlReader系统是在服务上下文中运行的，并没有与Backstage权限系统或其他外部访问控制机制集成。 这意味着Backstage实例的用户可能可以读取个人本不应该访问的外部内容。 例如，Backstage的$text中的catalog-info.yaml可用于读取用户无法直接访问的 GitHub 仓库等来源的内容。 如果担心出现这种情况，建议禁用或替换目录占位符处理器中的解析器以及其他插件中的类似功能。

验证

Backstage 通过以下方式对用户进行身份验证auth该插件主要充当不同 OAuth 2.0 提供商集成的授权服务器。 这些集成既可用于将用户登录到 Backstage，也可提供对外部资源的委托访问，并且都需要考虑实施安全 OAuth 2.0 授权服务器的共同问题。 所有授权提供商集成默认情况下都是禁用的，需要通过配置启用才能使用。 对于每个 Backstage 安装，建议只启用该实例正在使用的最少一组提供商。

这不属于auth后端，以防止未经授权的访问。集成商职责部分获取更多信息。

要使用认证提供程序将用户登录到Backstage，需要配置一个身份解析器，这是用代码实现的自定义回调。 身份解析器是配置 Backstage 的一个敏感部分，重要的是它要始终根据身份验证提供商提供的信息正确解析用户身份。 有许多内置身份解析器可以简化配置，重要的是无论如何使用，这些解析器都要以安全的方式解析用户。

作为使用身份解析器登录的一部分，Backstage令牌包含已解析的用户身份。 令牌是非对称签名的 JSON Web 令牌，任何希望验证令牌的服务都可以使用公钥。 签名密钥会不断轮换，并且对Backstage的每个安装都是唯一的，这意味着Backstage令牌不会在不同安装之间共享。 令牌包含用户身份声明和所有权信息，可用于确定该用户或组拥有哪些Backstage资源。 重要的是，该令牌不能在Backstage之外被伪造。auth对于安全性较高的部署，可使用auth因此，后端应部署在一个单独的服务中，并有自己的数据库。

令牌用于在 Backstage 系统内证明用户身份，并在整个 Backstage 插件中用于控制访问。 重要的是，整个 Backstage 生态系统的所有权解析逻辑必须保持一致，不存在曲解所有权信息的可能性。

对于跨后端(back-backend)通信，通常会转发Backstage令牌，或者在没有用户方的严格后端与后端(back-end-to-backend)通信中，后端(back-end)本身会根据预先共享的Secret发布一个服务令牌，然后在接收端进行验证。 目前，这些令牌还没有绑定唯一的服务身份，这意味着令牌可以在Backstage(backstage)安装的所有服务中使用。 这是我们未来要改进的地方。

Backstage 还支持通过代理进行身份验证，即从代理发出的传入请求中读取用户身份，该请求已由一个身份验证反向代理(如：Backstage)装饰过。AWS ALB以下代理验证提供程序会验证传入请求的签名，因此可安全部署，用户可直接访问：awsAlb,cfAccess和gcpIap.提供商如oauth2Proxy不会验证传入的请求，因此会被恶意内部用户欺骗，以提供auth因此，强烈建议限制使用伪造的身份信息访问后端。oauth2Proxy端点，或使用不同的提供商。

目录

集成商应配置目录规则来限制用户可以定义的实体种类。 一般来说，最好限制用户、组和模板实体的定义，这样内部用户就不能注册更多的实体。 模板实体定义了在后端主机上执行的操作，虽然我们的目标是确保这些操作的安全，而不考虑输入的内容，但它仍然是一个比较敏感的环境，因此建议您使用额外的检查来保护它。 如果您在目录中摄取并依赖用户和组实体作为组织数据，那么不允许注册这些实体是非常重要的。 否则，就有可能出现冒充用户和混淆组成员信息的情况。 您应该始终使用静态配置的目录位置或从可信源读取的实体提供程序来摄取组织数据。 实体提供程序直接生成的实体始终是可信的，不会对它们应用规则，但在链的后端生成的任何实体仍然要受到

目录的默认设置并不旨在防止资源耗尽攻击。 如果需要防止内部用户注册大量实体，建议禁用实体注册，并使用不同的方法来发现实体。 减少资源耗尽攻击的一种方法是只允许目录从有审计跟踪的可信 SCM 源读取数据。 目录目前缺乏对实体层次深度和实体大小的限制，我们希望将来能解决这个问题。

默认情况下，允许所有内部用户创建和删除实体。 如果这不符合贵组织的需求，建议启用并配置准许系统来限制这些操作。

Scaffolder

默认情况下，Scaffolding 作业直接在主机上执行，包括模板中定义的任何操作。 由于 Scaffolder 模板被认为是一个更敏感的领域，因此建议将创建和更新模板的访问权限控制在受信任方的权限范围内。 无论输入情况如何，模板的执行都是安全的，但我们仍然建议采用这种额外的保护层。 字符串模板在一个节点虚拟机沙箱以减少远程代码执行攻击的可能性。

Scaffolder 通常拥有较高的权限，例如在 Github 组织中创建存储库。 因此，集成商应谨慎使用 Scaffolder 模板，例如删除或更新现有资源，因为用户输入通常是用户定义的，因此可能会恶意或错误地删除或修改资源。

有一种策略可以减少 Scaffolder 服务的访问权限，那就是在执行操作时依赖用户凭证。 例如，可以将 GitHub App 集成配置为只读权限，并使用单独的用户 OAuth 令牌来创建存储库。 这就要求用户首先拥有创建存储库的权限。

集成人员应像审核其他插件包一样审核已安装的脚手架操作。 验证已安装的操作是否符合自己的安全要求也很重要，因为有些操作可能适用于更宽松的环境。

默认情况下，允许所有内部用户执行脚手架中的模板。 如果这不符合贵组织的需要，建议启用并配置准许系统来限制这些操作。

TechDocs

TechDocs 的后端大致可以通过两种方式进行配置。 默认情况是当techdocs.builder设置为local在这种情况下，文档由 TechDocs 后端按需生成并存储在本地。 当techdocs.builder设置为external相反，文档被假定为由外部流程(如在 CI/CD 管道中)生成，并且只是从配置的外部存储提供商中读取。

当文档在本地生成时，集成商负责确保在生成资产的存储位置安全配置文件系统权限。 当文档从外部生成时，集成商负责在生成文档的外部流程、发布文档资产的存储提供商和 TechDocs 后端之间进行访问控制和权限设置。

无论后端配置如何，TechDocs 前端都不会信任任何文档网站生成的 HTML，因此在向用户呈现任何内容之前，都会采用严格的消毒程序。

默认情况下，所有 TechDocs 文档对所有 Backstage 用户都是可见的。 通过配置目录的查看权限，可以限制对 TechDocs 站点的访问。

代理

代理后端是前端插件访问远程服务的工具，这些服务可能无法直接从Backstage前端接收流量。 典型的原因是上游服务没有提供适当的 CORS 标头，或者没有通过 HTTPS 提供内容。

代理条目通过静态配置进行配置。 每个条目都有一个挂载路径和一个上游目标，还支持其他选项，如限制允许的方法或注入额外的标头。 建议避免为上游服务注入验证标头，因为这是一种用凭据装饰请求的危险方式。 任何可以访问你的Backstage部署的人都可以使用注入的凭据向上游服务发出请求。 建议你创建一个后端插件，以安全的方式将单个请求转发到上游服务。 如果你最终向上游请求注入了凭据，请确保你没有暴露任何敏感信息或操作。 你还应该尽可能限制访问，例如使用allowedMethods选项来限制可使用的方法，并使用最小授权范围的令牌。