SSO与JWT保护云原生C2

使用SSO和JWT保护云原生C2架构

摘要

本文描述了一个现代基于云的指挥与控制系统的安全架构。该设计可轻松扩展到地面系统的其他方面，如任务规划、任务数据处理和地面终端，但将首先在COSMOS C2产品中实施。
地面系统的安全设计需要能够抵御内部和外部威胁，同时保持高性能和可扩展性，以适应规模不断增长的卫星集群。以下设计采用混合信任方法，为内部连接提供一定程度的零信任，同时也为外部连接提供强大的安全保障。
使用明确定义的标准对于实现强大的安全机制至关重要。本设计侧重于使用在RFC7519中建立的开放标准JSON Web令牌（JWT）。JWT令牌通过由OpenID基金会维护的OpenID Connect协议进行分发。由单点登录提供商托管的OpenID Connect允许通过一次登录访问多个微服务。
最后，可以通过定义严格的软件通信规则来进一步保护基础设施。任何预期不会连接到微服务的软件/服务都可以通过明确定义哪些组件可以与哪些组件通信的规则而被明确拒绝访问。Istio 是一种用于强制执行这些规则的技术，本文对此进行了讨论。

1. 引言

巴尔航天公司的COSMOS指挥与控制系统一直是一组独立的桌面应用程序
自2006年首次内部发布以来，作为一款数据全部本地存储的桌面应用程序，COSMOS的安全重点一直放在防止对运行COSMOS的计算机本身的访问上。这通常通过防火墙规则、访问控制列表以及对机器的本地授权来实现。
桌面应用程序对于大型企业系统有许多限制。它们必须在每个需要访问的用户计算机上单独安装和配置，且这些不同的安装必须保持同步。在不造成显著停机时间的情况下进行新部署非常困难。访问控制通常仅限于对安装软件的机器的访问。远程管理难以实现或根本无法实现。
随着现代网页前端用户界面框架的发展、处理能力的提升，以及将指挥与控制功能迁移至云中的需求，COSMOS 5.0 设计了一种新的软件架构。该架构为指挥与控制系统带来了全新的安全理念，同时也可应用于地面系统的其他部分，如任务规划和任务数据处理。
服务器支持的架构在安全方面需要采取与本地桌面应用程序截然不同的立场。服务器本质上必须接受外部连接才能发挥作用，因此必须制定安全标准，以确保只有授权用户才能访问服务器提供的服务。然而，需要设置不同级别的访问权限，以便于允许安全操作（例如查看遥测数据），同时将潜在风险较高的操作（例如发送指令或运行脚本）限制为仅特定用户可执行。
能够登录到运行网页浏览器的机器不足以作为访问远程指挥与控制系统的身份验证。单点登录提供商为登录分布式基于云的地面系统提供了理想的解决方案。
本文介绍了为即将推出的COSMOS企业版所做出的各类与安全相关的决策及其背后的理由，COSMOS是一种由服务器支持、具备现代网页前端的架构。

2. 总体架构

要定义应用于该架构的安全控制措施，首先需要讨论架构本身。COSMOS企业版的架构由在Kubernetes [1] 集群中运行的容器组成，每个容器包含一个特定的微服务。
每个微服务承担系统中的重要功能。微服务需要访问网络上的特定资源，但在几乎所有情况下，无需直接访问其他微服务。大多数微服务之间的通信通过Redis [2] 进行，Redis是一种高性能的键值存储、发布/订阅消息总线和流消息服务器。

图1. 安全视角下的整体架构

卫星地面终端（包含天线、调制解调器及其他相关硬件）提供一个接口，用于接收命令并通过前端处理器（FEP）输出遥测数据。Kubernetes集群内的接口微服务通过 TCP/IP连接与FEP通信，使COSMOS能够向航天器发送命令并接收来自航天器的遥测数据。该接口微服务从 Redis流中接收待发送的命令。此外，所有从航天器接收到的遥测数据都会被放入一个Redis遥测流中，供其他内部微服务进一步处理（图中未显示）。接口微服务接收到的所有数据均会被记录到存储于S3的文件中。
兼容的服务器称为 Minio [3] （如果在 AWS 云中运行，则为 S3）。
ElasticSearch [4]被用作所有容器的通用日志记录目标， Prometheus [5]用于收集每个容器的健康和状态指标。
Kubernetes集群本身暴露了Kubernetes API，该API 可以通过名为kubectl [6]的工具从集群外部访问。
希望与COSMOS C2系统交互的用户[7]打开网络浏览器，从内部Web服务器获取基于JavaScript的应用程序。该应用程序通过访问COSMOS API端点来发送命令、查看遥测数据以及执行脚本。所需文件可通过访问Minio获取。
用户身份验证通过名为Keycloak [8]的单点登录（SSO）提供商完成。COSMOS前端将用户重定向到 Keycloak进行登录。成功登录后，会返回一个JWT令牌，前端应用可使用该令牌对API请求进行身份验证。
使用容器使得系统中的每个微服务都可以在 Kubernetes集群的不同服务器上独立运行。如果某个特定的微服务发生故障，其余系统仍可正常运行，同时该单一微服务进行恢复。
总之，该架构使用了以下技术，这些技术将在本文档的后续部分进行更详细的讨论：Kubernetes、Docker、容器、Istio、JWT、OpenID Connect、Keycloak、ElasticSearch、 Prometheus、Redis 和 Minio。

3. 集群内部安全

概述

集群内部安全是指COSMOS Kubernetes集群内运行的软件在更受信任区域内的安全。内部安全至关重要，可在内部系统的任何部分遭到破坏时防止在集群内的横向移动。该架构通过容器化、零信任网络及其相关规则以及限制出口流量来实现集群内部安全。

容器化

为了提高可扩展性和部署的便捷性，新的COSMOS架构采用了容器化[9], ，并使用了Docker和Kubernetes。
从安全角度来看，单个容器的攻击面通常比完整的虚拟机 (VM) 更小。每个容器仅暴露提供其特定服务所需的极少端口（通常为一个甚至没有）。此外，容器内通常只运行一个进程，而普通虚拟机中可能运行数百个进程。
较少的进程数量意味着运行的代码更少，从而降低了存在漏洞的风险。
然而，由于服务器上的所有容器共享同一个内核 [10]，因此从容器发起成功的内核攻击所造成的后果可能比虚拟机更严重。此外，由于每个容器可以基于不同的 Linux 发行版，因此在不同容器中安装的开源软件包种类可能更加多样。
使用容器的明显替代方案是使用虚拟机。下表比较了这些选项。

特性	容器	虚拟机器
配置管理 获胜者：容器	定义整个使用容器小型纯文本 Dockerfile	必须存储 大型二进制文件 虚拟机的 虚拟机 – 难以确定配置
安全补丁 获胜者：平局	更少数量的操作系统所需包每个容器。	更少的虚拟机器需要补丁包含多个每个服务 虚机拟
部署 获胜者：平局	部署容器新镜像	部署虚拟机新镜像
启动/重启 Time 获胜者：容器	非常快	较慢

选择容器用于此设计，主要是为了简化基于容器的 Kubernetes集群的配置管理和部署。

零信任网络

零信任网络主要涉及采取这样一种立场：即假设您的网络已被攻破，并且应认为网络中同时存在友好和非友好的行为者。基于这一立场，所有网络访问都必须经过验证，所有数据传输都应加密，以防止非友好行为者窃听。
COSMOS 利用 Istio [11] Kubernetes 插件来提供基础级别的零信任网络。Istio 会向每个 Kubernetes Pod 注入一个代理边车容器，从而在无需修改受保护应用程序的情况下提供网络级安全。一旦安装了 Istio，所有容器之间的网络通信都将使用双向TLS（mTLS）进行加密。
mTLS 是一种比连接到你的银行网站时所使用的常规 TLS更强大的TLS形式。在常规TLS中，只有一方的身份被固有地验证为声称的身份（在此示例中为银行）。用户仍需提供用户名/密码，并理想情况下还需提供某种形式的多因素认证，银行才会信任该用户的身份。由于银行提供了TLS证书，用户可以确信她访问的网站确实是真正的银行网站。而在mTLS中，所使用的证书是双向验证的。因此，每个微服务都可以验证它正在与之通信的确实是预期的另一个微服务，反之亦然。双方都可以通过检查证书直接确认对方的身份。

图2. 零信任网络

在COSMOS Kubernetes集群内实现强大的零信任网络只需再完成一个步骤。Istio可以配置规则，以强制规定哪些微服务之间可以通信。一旦配置了这些规则，COSMOS内部基础设施的每个部分都只能按照系统预期和允许的方式被访问。下图2展示了这些概念。
关于零信任网络的更全面和通用的讨论，可参见 NIST 特别出版物 800‐ 207[12]。
主要的替代服务网格实现是一种名为linkerd [13]的产品。
Istio被视为Kubernetes服务网格的行业标准[14] ，因此本架构将其作为基准。如果使用Istio时出现任何问题，将评估linkerd作为下一个选项。

限制出口

在内部集群中，只有少数微服务需要与外部世界建立连接。
因此，可以配置Istio仅允许这些微服务进行出口流量。在 COSMOS指挥与控制架构中，唯一需要建立外部连接的微服务是连接到外部目标（如前端处理器（FEPs））的接口微服务，以及可能需要打开TCP/IP连接以将数据转发到外部软件的路由器微服务。
通过将出口流量限制在集群内极少部分容器上，任何被引入且无法访问出口流量的容器中的恶意代码都将无法与外部世界通信，既无法接收指令，也无法外传数据。这可以防止多种攻击形式以及外部命令与控制能力。

4. 集群外部安全

概述

集群外部安全是指防范在Kubernetes集群外部运行的恶意用户和恶意软件的安全措施。外部安全性对于防止未经授权访问系统以及缓解攻击至关重要。该架构通过强健的基于令牌的身份验证、采用最小权限原则进行授权，以及限制对系统的入口来实现外部安全性。

身份验证

身份验证是验证用户身份的能力，对于区分与系统交互的不同操作者以及记录“谁做了什么”至关重要。在卫星指挥与控制系统应用中，能够将每个操作追溯到其发起者尤为重要，因为某些卫星资产的价值可达数十亿美元。
该架构使用 Keycloak 平台作为身份验证和授权提供者。
Keycloak 被配置为单点登录（SSO）解决方案，可将用户账户集中存储在一个位置，并使其身份能够应用于广泛的地面系统软件中。使用单点登录简化了应用开发，因为各个独立的应用程序无需存储用户名和密码等敏感用户信息，也无需单独确保这些信息的机密性。
COSMOS 的身份验证通过 OpenID Connect 协议和 JSON Web 令牌 (JWT)[15] 实现。OpenID Connect 是基于成熟的 OAuth 2.0[16] 标准构建的完整身份验证框架。根据此协议，当用户希望登录地面系统时，需点击登录链接，并被重定向到 Keycloak 服务器上的 COSMOS 品牌登录页面。成功登录后，用户将被重定向回 COSMOS 应用，同时两个令牌会被传递给该应用。
这两个令牌被称为访问令牌和刷新令牌。访问令牌被传递给API，以提供身份和其他信息，而刷新令牌则用于获取新的访问令牌。
在许多认证系统中，访问令牌只是一些长的唯一编号，可通过查询数据库来关联用户。而 OpenID Connect 使用的 JSON Web 令牌与众不同，它们不仅仅是大的唯一数字。每个令牌都是一个签名的 JSON 对象，为应用程序提供有关用户的丰富信息。其中包含的重要信息有：令牌创建时间、令牌过期时间、用户名、名字、姓氏以及系统中的授权角色（下文将讨论）。由于访问令牌是经过签名的，因此可以对其进行密码学验证，以确保其未被篡改且由 Keycloak 系统生成。使用 JWT 可以将所有用户信息存储在应用程序之外的 Keycloak 中。
使用 OpenID Connect 与 JWT 令牌时，一个重要的细节是，在基本实现中，访问令牌是不可撤销的。这意味着在当前时间达到令牌中的过期时间之前，该令牌始终被视为有效，并可在系统内成功执行 API 操作。
这种设计的主要优势在于，API 可以直接信任令牌的有效性并立即使用，而无需通过外部网络通信来验证令牌的有效性。与必须查询数据库以检查令牌并查找用户身份的方式相比，这可以带来显著的性能提升。
这种架构明显的缺点是，一旦令牌被泄露，恶意行为者就可以一直使用该令牌直至其过期。解决此问题的标准方法是赋予访问令牌较短的生命周期（通常为15分钟），并配合使用撤销刷新令牌，以防止在发现漏洞后用户获取新的访问令牌。然而，这仍然存在一个时间窗口（最长可达15分钟），恶意用户可在此期间使用该令牌执行操作。
COSMOS在架构上采取了折中方案：对于检索系统遥测等“安全”操作，隐式信任令牌；而对于发送指令或启动脚本等更危险的操作，则额外检查用户是否已注销（应使访问无效）。这种方式在更常见且耗时较多的遥测操作中利用JWT获得了性能优势，同时为较少发生但更重要的指令/脚本操作提供了额外的安全保障。
上述功能的实现得益于单点注销概念。用户在Keycloak处注销后，将自动从所有应用程序中退出。Keycloak通过使用户的会话过期并阻止后续续订访问令牌的尝试来实现此功能，直到用户重新登录为止。此外，COSMOS也会收到注销通知，以便将其令牌的创建时间与用户最近的注销时间进行比对。如果令牌的创建时间早于最近的注销时间，则该API请求将被拒绝，视为未授权。
使用OpenID Connect的主要替代方案是一种称为 SAML的技术。SAML是一种较老的技术，使用XML消息和SOAP协议进行通信。对于基于API的架构而言，SAML更难实现，因为它需要更多的服务器交互、更复杂的协议以及传递大型XML文档[17]。

授权

授权是根据用户的身份为其提供特定的访问权限。该架构实现了一种称为基于角色的访问控制（RBAC）的授权形式。RBAC 在用户和权限之间增加了一个称为角色的中间层。角色被分配给用户，权限被分配给角色。这样可以实现非常细粒度的权限控制，且每种角色的权限只需定义一次即可。
COSMOS 架构定义了以下权限类型：

Name	详细信息
管理员	可以访问管理接口，安装插件，添加/删除目标，添加/删除工具等。
cmd	可以发送命令
命令信息_	可以获取关于系统中定义的命令
cmd raw_	可以通过接口发送原始数据 接口
tlm	可以查看遥测
tlm set_	可设置与 遥测相关的设置，例如限制
系统	可查看 接口/路由器/日志记录 信息
系统_设置	可以与以下内容交互 接口/路由器/日志记录 设置
脚本_查看	可以查看已有的脚本 加载到系统中
脚本_编辑	可以编辑和创建新脚本 到系统中
脚本_运行	可以运行已 加载到系统中

每个权限都可以限制到非常具体的级别，例如仅能查看一个遥测数据包。默认情况下，大多数权限将允许访问特定类型的所有功能。
系统为以下默认角色进行了定义：

Name	详细信息
超级管理员	具有创建和删除作用域的权限。作用域是显示命名空间的唯一的数据集并提供将多租户功能添加到COSMOS 企业
作用域 管理员_	具有管理关联的作用域，安装插件，以及添加/删除目标、接口等的权限
作用域_Operator	具有发送所有命令，查看所有遥测并运行所有脚本关联的作用域的权限
作用域_查看者	仅有查看权限 所有相关联的遥测数据 作用域

还可以通过管理界面创建自定义角色，以提供对角色权限的任意级别定制。例如，可以将自定义角色配置为仅能查看特定硬件的遥测数据，或仅能向特定硬件发送命令。对于大型组织而言，这对于定义仅能管理特定子系统的角色非常有用，但不像提供的默认操作员角色那样拥有对系统的完全控制权。
对于简单项目而言，默认角色应该已经完全够用。
Keycloak 提供了一个管理界面，用于定义角色名称并将这些角色分配给用户。每个用户被分配的角色列表随后会包含在传递给 API 的 JWT 访问令牌中。API 可以据此检查是否存在执行请求操作所需的角色。

有限入口

外部安全性的最后一个方面是，仅允许最终用户从其个人工作站访问系统时所需的服务进入集群。下表列出了最终用户和系统管理所需的进入集群的有限接口列表。
这些接口也在图1中显示。

Name	详细信息
Kubernetes API	允许管理 Kubernetes集群
COSMOS Web服务器	提供网页前端服务，该前端用于访问COSMOS
COSMOS API	网页前端与此交互 使用此功能的 COSMOS 系统 API
Minio/S3	提供对对象中文件的访问 存储
Keycloak	用于身份验证

除了上述内容外，管理员有时还需要访问其他网页界面，例如下一节中讨论的监控与入侵检测相关界面。为了方便起见，或者在拥有大量具有不同权限管理员的大型系统中，可将这些界面添加到上述列表中。对于小型项目，可以在需要时使用Kubernetes的“kubectl端口转发”命令，为具有管理Kubernetes集群权限的特定管理员临时提供对这些界面的访问。对于大型项目，更实用的做法可能是将这些系统对外部开放，使更多用户能够访问，同时减少具有Kubernetes特定管理权限的管理员数量。

5. 监控与入侵检测

该架构提供了两种不同的工具，用于常规的健康监控、调试和报告，这些工具也可用于入侵检测等安全目的。
首先是ElasticSearch，它为系统的每个部分（包括Kubernetes本身，直至每个独立的应用程序）提供统一的日志记录端点。系统的每个组件都配置为通过一个名为Fluentd的程序传输其日志消息，Fluentd负责数据的缓冲、格式化和路由，最终发送至ElasticSearch。ElasticSearch以JSON格式接收日志消息，并提供查询功能，以便从日志中搜索和发现信息。
通过配置ElasticSearch报告异常活动，可以快速发现系统中的错误和入侵行为。
可以从日志消息中提取并监控的数据示例包括：每秒HTTP请求数、每秒HTTP 500错误数、每秒日志消息总数、任何严重性为ERROR或WARNING的消息，或包含“Unauthorized”等特定字符串的任何消息。

第二个工具是Prometheus，它是一个统一的指标收集和报告系统。Prometheus是一种开源云原生解决方案，可直接集成到Kubernetes中而无需任何更改，并且能够直接监控Kubernetes。Prometheus被配置为轮询基础设施中每个容器的“/metrics”端点，并为每个容器提供具体的指标。
Prometheus 监控的典型指标包括 CPU利用率、内存利用率和磁盘利用率。Istio 还支持轻松监控带宽利用率，并检测任意两个容器之间或容器与集群外部之间的带宽异常激增。此外，还可以为每个应用程序添加自定义指标，供 Prometheus 进行监控。

6. 总体评估与经验教训

在撰写本文时（2020年12月），该架构已基本实现。剩余工作包括引入Prometheus进行指标收集，以及完成Istio通信规则集的配置。
在实施过程中，我们发现了一个有助于设置本地 Kubernetes 开发环境的有用工具，称为基于Docker的Kubernetes (KIND)[18]。这使我们能够创建具有多个节点的更真实的集群环境，并直接模拟节点故障。标准的 Kubernetes 开发系统 MiniKube 仅模拟单节点集群。
我们最初的实现使用 Apache Kafka 作为流式消息总线，而不是 Redis流。然而，Kafka 使用起来较为繁琐，且我们需要的功能（例如检索流中的第一条和最后一条消息）在 Kafka 中实现起来要困难得多。此外，Kafka 基于分区的并行机制对我们的用例没有任何益处。Redis流使用起来非常顺畅，并且由于我们已经在使用 Redis 作为键值服务器，因此能够移除 Kafka，从而从架构中消除一个依赖项。
在业务开发活动中，我们发现 COSMOS 可能需要添加一组额外的权限/角色以支持审批概念。对于某些系统，部分命令可能需要比通用指挥权限更高层级的批准。该领域还需要进行更多研究。
Istio 已被证明易于安装和配置，但我们尚未进行高带宽测试，以评估 Istio 带来的总体开销是否是一个显著的性能驱动因素。我们预计这对于标准的指挥与控制命令/遥测数据速率不会成为问题，但有时 COSMOS 还需要支持传输较大的科学数据载荷。我们需要收集有关加密所有内部通信的开销以及 Istio 代理服务器开销的相关指标。
Keycloak 已被证明非常易于安装和使用。在实施过程中，我们发现其内置用户界面可用于定义和分配 COSMOS 所需的角色，并将其包含在生成的 JWT 令牌中。这提供了一个良好的内置系统来分配角色，而无需进行任何额外的 COSMOS 管理界面开发。

7. 总结

本文讨论了下一代COSMOS指挥与控制系统的安全架构。
该架构可轻松地被完整地面系统的其他部分共享，例如任务规划、任务数据处理和地面终端。共享该架构将提供共享的监控与入侵检测基础设施、集群管理与硬件，以及认证/授权服务。强烈鼓励系统架构师在此架构基础上构建其任务所需的完整地面系统。