Space is now critical infrastructure, but we're not securing it like it is

太空已成为关键基础设施，但我们尚未像对待它那样加以保护 | Elastic Blog

太空已成为关键基础设施，但我们尚未像对待它那样加以保护

作者：

Marcial Villegas

2026年7月14日

• 在Twitter上分享 [在Twitter上分享]

• 在LinkedIn上分享 [在LinkedIn上分享]

• 在Facebook上分享 [在Facebook上分享]

• 通过电子邮件分享 [通过电子邮件分享]

• 打印本页 [打印本页]

2022年2月24日凌晨——就在俄罗斯坦克进入乌克兰的同一天——一种名为AcidRain的恶意软件已经开始运行。当人们意识到发生的事情时，欧洲各地已有5800个卫星调制解调器被永久损坏。风电场失去了远程管理能力，应急服务陷入瘫痪，乌克兰军队在入侵初期的关键时刻失去了协调能力。

这次攻击的惊人之处在于它没有采取某些行动。它不需要接近卫星，没有干扰信号，也没有将任何物体从轨道上击落。它利用了卫星地面站，这些地面站使用的是大多数企业IT团队每天管理的相同防火墙、VPN和身份系统；从那里，它伸展触角，使整个卫星星座陷入沉默。

在操作中心监控情况的防御者对此一无所知，因为他们的工具根本无法识别这种攻击。

一种新型基础设施，一个旧问题

太空已悄然成为承重基础设施。金融系统依赖于每秒十亿分之一精度的GPS定时信号。农业传感器通过低地轨道星座传输作物数据。当陆地网络失效时，应急响应人员通过卫星链路进行协调。目前，多个国家已将太空列为与陆地、海洋、空中和网络并列的作战领域。

然而，保护这一基础设施的网络安全态势并未跟上其重要性。

根据BryceTech于2026年5月发布的《卫星行业协会第29届年度卫星行业报告》，截至2020年底，地球轨道上运行的卫星数量约为3400颗。到2025年底，这一数字已超过14000颗，五年内增长了四倍。这些卫星并非单一用途的专门航天器。现代航天任务是软件定义的，通过API连接，并与云平台和企业身份系统深度集成。它们通过空中更新接收软件更新，并使用与贵公司企业VPN相同的身份提供商对操作员进行身份验证。

换句话说，太空领域继承了现代企业IT的所有攻击面，并在此基础上叠加了一个全新的攻击面——几乎没有任何安全工具能够识别这一攻击面。

• 空间段：航天器，持续生成来自其电源系统、热控系统、姿态确定和推进系统的遥测数据流

攻击者无需控制所有四个层级就能造成破坏，只要找到一个入口点即可。Viasat攻击事件展示了这些互联层级的脆弱性：攻击并未触及任何卫星，而是完全通过地面段和用户段实施，利用配置错误的VPN设备和可信凭证，从熟悉的IT企业环境找到了通往专用卫星控制基础设施的路径。从那里开始，不到一天的时间就使整个大陆的设备瘫痪。

在这个多层级、多领域的环境中，异常检测变得异常复杂，需要超越单一层级的单一异常检测。团队需要快速在四个层级之间检测并关联微弱信号，以在命令洪流攻击完成前、未经授权的固件上传被接受前、以及在轨道窗口期间恶意地面站建立联系前，阻止物理影响的发生。

隐藏在明处的盲区

令人特别担忧的是：检测这些攻击所需的数据往往已经存在。问题在于没有任何安全平台能够读取这些数据。

当AcidRain攻击发生时，出现了包括固件擦除序列、网络异常、卫星指令流变化和射频链路退化等信号。但同时也存在无法回答的问题：信号中断是攻击、系统故障还是计划维护窗口？异常指令是合法的还是被注入的？射频退化是来自干扰还是太阳天气事件？

回答这些问题需要同时跨四个层级关联数据。这些数据可以包括航天器的结构化遥测数据、指令通道的加密认证记录、地面接收器的射频信号质量指标、天线控制日志、NOAA提供的空间天气数据，以及存放在某个工单系统中的维护记录。

传统安全平台能清晰看到IT侧的画面，但一旦数据进入射频链路和航天器，就完全失效了。这与其说是工具的失败，不如说是“地图”的失败。空间遥测使用了包括国际标准如空间数据系统咨询委员会（CCSDS）、空间数据链路安全（SDLS）和数据包利用标准（PUS）在内的协议，这些协议虽然定义严谨，却从未被转换为安全监控平台能理解的格式。没有人构建翻译层，因此数据流进来后被存储，却完全无法产生任何可操作的信号。

想象一下雷达只覆盖天空东部的空中交通管制系统。你可以对看到的一切发出警告，但对另一侧可能发生的情况却一无所知，直到它已经穿越而来。

缺失的关键要素：上下文

还有一个更安静但同样重要的问题。

即使你能发现异常，也需要知道它的含义。比特错误率的激增可能是射频干扰，也可能是航天器处于低仰角位置，此时大气干扰是预期现象。异常的推进器点火可能是未经授权的机动，也可能是某人忘记记录的计划轨道避让燃烧。

回答这些问题并不一定需要更多遥测数据；通常只需了解上下文即可，例如交接班时前一操作团队留下的交接记录、显示计划机动的航任务规划文档、该轨道窗口的空间天气报告，以及这颗特定航天器及其子系统的数十年异常历史。这些上下文信息确实存在，但分散在维基、工单系统、邮件线程和共享驱动器中，几乎从未与安全工作流程关联。当分析师在实时处理事件时，他们需要手动查阅六个不同的系统，而时间正在流逝。

在航天运营中，这个时间流逝速度比大多数人意识到的要快得多。一颗卫星可能每绕地球一圈仅在特定地面站上空停留约10分钟，这意味着如果攻击窗口以分钟计算，事件处理窗口则以秒计算。分析师手动交叉核对四个独立系统时，每次都会损失这些宝贵的秒数。

任务上下文崩溃是指单一事件同时跨越身份系统、射频退化、轨道异常和航天器健康状态。传统安全工具在此情境下失效，因为它们是为发生在单一操作域内的攻击而设计的。航天攻击并不尊重这些边界。

解决方案的形态

前进的道路描述起来并不复杂，尽管迄今为止执行起来颇具挑战。

在基础层面，航天网络安全需要一个通用的数据模式：一种标准化表示航天任务数据的方式，安全工具可以实际读取。这不应是针对单一任务的定制化方案，而是一个任何运营商、星座、政府项目或商业企业都可以采用并贡献的开放标准。如果每个运营商都在孤立地解决相同的基础问题，航天网络安全作为一门学科将无法成熟发展。

用于记录攻击面的框架已经存在。空间攻击研究与战术分析（SPARTA）框架就像空间领域中的MITRE ATT&CK框架。该框架由DHS资助，由航空航天公司开发，记录了涵盖航天任务所有环节的260种攻击技术，包括射频干扰、命令注入、固件损坏、通过恶意地面站的未经授权上行链路以及加密密钥窃取。这是一项严谨且维护良好的工作成果，但在今年之前，这260种技术中没有任何一种拥有可导入并实际运行的检测规则。这就是威胁框架与操作安全之间的差距：一个被广泛引用且受人尊敬的目录，但实际使用中却因地图未能覆盖实际领域而毫无用处。

一旦建立通用数据模式，检测规则即可共享，威胁情报也能实现可移植性。当一个运营商发现如何检测新型命令注入技术并使用SPARTA模式进行描述时，该检测规则即可被所有使用相同模式的运营商直接使用，从而使社区构建集体防御体系，而非反复孤立地解决相同问题。

一门正在确立的学科

空间网络安全是一门新兴的学科，却在解决一个古老的问题，即如何保障那些最初设计时并未考虑安全性的基础设施。支撑空间通信的协议并未以潜在对手为设计对象，而控制航天器的地面系统也是由工程师们为实现任务目标而构建，而非为阻止他人干扰而设计。

这并非批评，而是对当前学科现状的描述，也指明了其未来的发展方向。原本缺失的架构正在被构建，原本不存在的检测规则正在被制定，那些仅能列举威胁却无法实现检测的框架正在被实际应用，空间网络安全也逐渐从一个事后补救的措施，转变为与关键基础设施需求相匹配的严肃工程学科。

空间领域是最新被认定的关键基础设施领域，尽管对手已经意识到这一点，但防御方正在迎头赶上。

这正是Elastic发挥作用的地方。Elastic的平台专为大规模统一碎片化数据而构建，而空间安全本质上是一个数据统一问题：航天器的遥测数据、地面系统的日志、天线控制器的射频指标，以及操作员笔记和任务文件中的非结构化信息，都需要由负责保障任务安全的人员在实时状态下进行统一检索。

通过将Elastic通用模式扩展至空间领域，并将开放检测内容映射到SPARTA框架，Elastic为这些信号建立了统一的语言。这样，原本分散在四个不同领域的微弱信号便能被视作一幅完整的图景，而非四个相互割裂的片段。这种通用模式是所有其他构建的基础，它使得检测规则可共享、威胁情报可移植，并且相关性分析的速度足以在轨道窗口期内产生实际价值。正是这种统一的模式，使得一个具备自主能力的安全运营中心（SOC）——正如Elastic安全事业部总经理Mike Nichols在《网络安全领域的人工智能军备竞赛：为什么你的SOC现在必须进化》中所描述的那样——能够以机器速度对这些相关信号做出响应。模式的统一是首要前提，其他一切，包括响应速度，都建立在这一基础之上。

这系列文章的第一篇将探讨如何实际应用SPARTA框架并保障空间基础设施安全。后续内容敬请期待。

了解更多关于Elastic和网络安全的信息

若想了解公共部门组织如何制定其网络安全战略，请下载《公共部门网络安全指南》。

本文中描述的任何功能或功能的发布时间和时间安排均由Elastic单独决定。任何目前尚未提供的功能可能无法按时或根本不会交付。

分享