简介面向高性能计算HPC运维者、科研机构IT管理员及网络安全从业者的专题报告聚焦HPC系统共享计算与海量科研数据场景下的安全挑战。报告围绕资源访问控制、网络分区隔离、漏洞管理及异常行为监测展开提出以零信任架构为核心的分层防护策略并给出保障科研数据完整性、机密性的具体措施。压缩包内含1份PDF报告大小约1.99MB文件精炼、便于研读。目前已有122人学习下载。读者可借此系统了解HPC安全策略的制定思路包括身份认证体系设计、数据加密传输方案、威胁检测响应流程以及漏洞修复优先级划分等内容为搭建高安全等级的科研计算平台提供可落地的参考框架。1. HPC集群安全为什么不能照搬办公网那套HPC集群的运维里最让人紧张的往往不是“被攻破”那一下而是“发现时已经晚了”。一个登录节点被塞进挖矿程序、一个共享账号被拿去批量读取课题数据、一次误清理毁掉几个月的算例结果——这些才是高性能计算环境里真正的高频事故。传统办公网的安全策略习惯于“边界封死终端管控”但HPC天然是多用户共享、高信任协作的环境多个课题组共用登录节点、作业调度系统和并行存储边界在哪里本来就模糊。这个标题要解决的问题恰恰是这种“高信任共享环境”下的数据安全性和完整性。安全性指科研数据不被未授权访问和窃取完整性指数据不被篡改、计算过程不被人为干扰、结果仍然可信。要做到这一点不能只靠防火墙和杀毒软件得把策略拆成威胁模型、身份认证、数据隔离、加密传输、监控审计和定期体检六个层面每一层都有可操作的配置和真实会遇到的问题。这篇内容面向的是HPC集群管理员、科研数据平台负责人以及准备为超算环境做安全规划的安全工程师。新手可以照步骤落地有经验的人可以重点看第4章的排查场景和第6章的自动化体检这些都是日常最花时间的地方。2. 先认清威胁再画边界HPC安全框架与信任分级2.1 “内网可信”是最大的安全盲区很多机构对办公网已经不再默认“内网绝对安全”但HPC集群仍然长期被当作“科研特区”默认只有内部人能登录、内部人都是合作关系于是账号共享、离职未回收、节点间无访问控制都成了常态。可现实是HPC集群里的数据价值极高一个课题的算例结果往往需要数月计算成本一旦被外部拿到或被人为篡改损失远超普通业务系统。更麻烦的是HPC的架构天然放大了风险。登录节点是所有用户的入口计算节点通常无人值守存储节点保存着全部课题数据。攻击者只要拿到一个有效账号就能从登录节点横向移动到存储节点这种移动在默认配置下往往没有任何障碍。安全策略首先要承认这个现实不能假设进来的每个账号都是好人也不能假设内部网络是干净的。要假设每个节点都有被突破的可能然后通过分区和分级让单点失陷不扩散成全局事故。2.2 四类高频威胁从账号接管到数据完整性破坏HPC环境里的安全威胁不能只盯着“外部攻击”内部风险和运维失误同样致命。下面这张表是梳理威胁模型时最常用的分类方式按破坏面和优先级排列做安全规划时建议直接拿它当底稿。威胁类别典型场景主要破坏面优先级账号失陷用户口令在外部泄漏被用来批量读取课题数据、提交恶意作业数据泄漏、计算资源被滥用P0内部越权课题组成员读取他人目录、复制未公开数据或越权访问其他组的共享目录科研数据泄漏P0恶意作业与资源滥用通过调度系统提交异常计算任务、在计算节点植入常驻进程、挖矿程序计算节点被占用、计算结果不可信P1数据完整性事故清理脚本误删、误覆盖临时目录快照策略失效导致数据无法恢复数据丢失、重算成本极高P0账号失陷排在第一位原因是HPC里口令登录的残余太多了。很多集群虽然已经启用密钥认证但备用口令通道仍然开着或者某个老用户还在用口令登录这就等于给横向移动留了后门。内部越权则几乎都是权限配置问题——一组课题目录被设成777任何登录用户都能读取数据管理部门事后根本查不到访问痕迹。恶意作业和资源滥用是HPC特有的风险普通企业安全方案里没有这个维度。攻击者不需要破坏系统只需要通过调度系统提交一堆计算任务就能把GPU节点全部占满甚至通过节点漏洞植入常驻进程。数据完整性事故则最容易被忽视但它恰恰是这个标题里“完整性”三个字的核心指向。2.3 信任边界到底怎么画节点分级、网络分层、数据分区画信任边界是HPC安全策略里最关键的步骤不是画网络拓扑图而是给每一类资源定一个安全属性和保护等级。常见做法是把集群分成四个逻辑区登录区、计算区、存储区、管理区。登录区是面向用户的入口安全等级要最高计算区节点可以互相通信但对外不开放端口存储区只对登录节点和计算节点提供服务不直接暴露给用户管理区只允许运维人员访问。网络层面至少要做三层分离业务网承载用户SSH和作业提交作业网承载调度系统节点间通信存储网承载并行文件系统的数据读写。很多老旧集群把这三类流量混在一起结果就是登录节点被攻破后可以直接探测存储节点的所有端口作业网和业务网不分也让调度系统完全暴露在用户流量下。数据分区同样要按价值分级。常见的做法是把存储拆成三类home目录放个人配置和小文件保护等级中等project目录放课题共享数据和算例结果保护等级最高scratch目录放临时文件和中间结果保护等级最低允许被清理。这个分级的价值在于安全投入不必均匀铺开把最强的加密和审计放在project区把性能和灵活性留给scratch区既保障安全又不拖垮I/O。2.4 两个常见的错误做法全盘加密和彻底隔离过度设计的翻车案例比不做安全更多。最常见的是“全盘加密”管理员把整个并行文件系统都做了加密结果所有作业的读写性能明显下降用户开始抱怨计算变慢最后只能关掉加密重建存储数据和密钥迁移来回折腾了大半个月。加密是有代价的静态加密尤其不适合高频读写的临时数据区正确做法是只对project区或归档区加密scratch区保持明文以换取性能。另一个错误做法是“彻底隔离”所有节点之间禁止互相访问每个课题组一套独立环境。这种做法在技术上行得通但操作成本极高——调度系统需要跨子网调度、用户需要维护多套登录凭据、课题之间的数据交换变得极为繁琐。更实际的做法是差分保护临时数据低保护、课题共享数据中保护、不可再生数据高保护用一套策略而不是多套物理隔离来解决问题。3. 策略落到配置身份认证、数据隔离与加密的实战操作3.1 身份认证把SSH密钥收进集中管理身份认证是HPC安全的第一道闸门。登录节点是所有用户进入集群的必经之路密钥管理做不好后面所有安全投入都白费。我经手过的集群里最典型的隐患是用户各管各的密钥、离职账号不及时回收、还有人为了省事在脚本里直接写口令。sshd_config里建议先收紧下面这几项# /etc/ssh/sshd_config 中与最小安全基线直接相关的几项 PermitRootLogin no # 禁止root直接登录运维通过sudo完成 PasswordAuthentication no # 生产集群关闭口令登录只保留密钥 PubkeyAuthentication yes # 明确开启公钥认证 MaxAuthTries 3 # 单次连接最多尝试3次认证防暴力枚举 AllowUsers admin1 admin2 user_a # 登录节点只放行明确名单换人时在此处调整这里每一项都有明确目的PermitRootLogin关闭后即使root密钥泄漏攻击者也少了一条直达路径PasswordAuthentication关闭后口令猜测和撞库基本失效MaxAuthTries限制认证次数配合fail2ban类的工具可以显著提高爆破成本。改完后一定要用sshd -t校验语法再重启否则整个登录节点直接失联。密钥本身建议统一用ed25519生成替代旧的RSA 2048# 生成ed25519密钥-a 100把KDF迭代设到较高档-C备注用户身份便于审计 ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519 -C hpc-user-2024 # 把公钥投放登录节点登录后即可正常使用 ssh-copy-id -i ~/.ssh/id_ed25519.pub user_alogin-nodeed25519比RSA密钥更短、生成更快而且安全性在当前算力下足够。参数-a 100把私钥文件的暴力破解成本大幅提高即使有人拿到私钥文件也不容易离线猜出内容。C后面的备注写清楚用户名以后审计日志里能直接看出是哪把密钥在登录。3.2 数据权限巡检777目录与组共享的最小授权科研用户普遍没有权限管理经验最常干的事就是把目录chmod 777方便同组人拷贝数据。HPC数据权限的落地方式不是教育用户而是定期巡检加默认ACL约束。巡检用一条find命令扫出所有过宽目录# 找出 /home 和 /data/project 下“其他用户”可读写执行的目录maxdepth限制扫描层级 find /home /data/project -type d -perm -0007 -maxdepth 3 2/dev/null这条命令的-pem -0007含义是“其他用户位有任意权限”命中即代表该目录对集群内所有用户开放。扫描结果通常有两种处理方式确认是临时共享的就改为组权限确认是误设的就立即收紧。常见做法是对课题共享目录使用ACL保持组协作能力的同时限制其他人访问# 删除目录上多余的默认ACL再显式收紧其他用户权限 setfacl -R -m g::rwx /data/project/groupA setfacl -R -m o::--- /data/project/groupA # 查看现有ACL确认权限是否符合预期 getfacl /data/project/groupA | head -30setfacl的好处是权限模型比chmod更细致可以在同一目录上给不同用户组不同权限不必为了协作而直接开777。这里有一个边界要提醒setfacl的量级对海量小文件目录会偏慢建议在数据迁移或新建目录时设置默认ACL而不是等目录大了再批量改。3.3 传输与通信加密SSH、SFTP与作业调度认证数据在集群内部的传输以及集群与外部之间的交换都需要加密。用户侧最常见的要求是“怎么把结果安全拷回自己电脑”这里统一建议SFTP或SCP禁止部署FTP之类明文传输服务。不需要额外开服务OpenSSH本身就带SFTP能力用户端用FileZilla、WinSCP这类工具连接登录节点就能直接传输。节点之间的通信加密则常被忽略。作业调度系统的节点间认证依赖MUNGE密钥所有计算节点和管理节点共享同一个key文件。这块的加固重点是保护密钥文件本身# 检查MUNGE密钥文件的权限收窄到只有munge用户和root可读 ls -l /etc/munge/munge.key # 如果权限过宽立即收紧 chown root:munge /etc/munge/munge.key chmod 640 /etc/munge/munge.keyMUNGE密钥一旦泄漏任何能读取该文件的人都可以伪造节点身份向调度系统提交恶意指令。密钥的分发应该走配置管理工具统一推送而不是手工拷贝避免在某个节点上留下副本。计算节点上的密钥文件还要定期检查是否被意外修改可以用只读挂载或配置管理工具做持续校正。3.4 作业控制把访问权限细化到调度系统一层调度系统是HPC安全里最有特色的控制点。传统服务器安全只管“谁能登录”HPC还要管“谁能提交作业、能用多少资源、作业跑在哪里”。作业调度系统本身支持按账户和QOS做资源隔离这是策略真正执行的地方。以常见的调度系统为例按课题分配账户是最基础的规范# 按课题创建关联账户并限制可使用的分区 sacctmgr -i add account groupA,groupB sacctmgr -i add user user_a,user_b accountgroupA sacctmgr -i modify account groupA set GrpTRESgres/gpu4,grpcpus128第一行创建两个课题账户第二行把用户归入课题账户第三行限制该课题最多使用的GPU和CPU总量。这样即使一个账号被攻破攻击者能占用的资源也限定在这一课题的配额内不会波及整个集群。GrpTRES的值要根据集群实际规模调设太小会影响课题进度设太大则失去隔离意义。调度系统还提供作业审计能力管理员可以定期查看用户作业历史和资源消耗# 查询指定用户近期作业的执行情况包括状态、运行时长和退出码 sacct -S 2024-01-01 -E now -u user_a \ --formatUser,JobID,JobName,Partition,Start,Elapsed,State,ExitCode这条命令会列出该用户在新年后提交的所有作业。管理员重点关注两类记录频繁CANCELLED且每次运行很短大概率是用户在试探节点能力FAILED且重试次数极多可能是恶意作业在扫描漏洞。调度系统里的ExitCode是判断作业是否被外部干预的重要依据正常算例的退出码应该是稳定的出现大量非预期退出码就要盯紧。4. 安全加固避坑5个HPC集群的典型翻车现场与排查4.1 加固SSH过猛登录节点直接失联现象管理员在sshd_config里同时关闭了密码登录和root登录还在AllowUsers里写错了用户名结果所有用户都登录不上运维自己也被拒之门外。原因没有保留一条应急通道就修改了认证规则。AllowUsers写错一个字符、sshd_config语法有误、或者密钥认证尚未在所有用户端生效任何一点都会导致登录节点不可用。解决修改sshd_config之前先开一个持久会话不要断开改完用sshd -t做语法检查再graceful重启。生产集群建议保留至少一个带外管理渠道比如IPMI或串口控制台确保万一SSH失效还有物理手段能进场。4.2 共享目录权限777用户密钥被批量读取现象安全巡检时发现某课题组的home目录是777权限里面还放着密钥备份文件任何登录用户都能直接读取下载。原因用户在初始化课题环境时为了方便组内成员互拷文件直接把整个目录chmod 777。密钥备份是之前为了换电脑临时放的忘在了这个目录里。解决先立即收紧目录权限然后重置受影响的密钥对。这类踩坑很典型说明权限巡检不能只扫顶层目录还要对home和project区内的敏感文件做针对性检查。建议把备份密钥统一收进运维侧的加密归档区不让用户自行管理密钥副本。4.3 节点重装后SSH指纹变化告警刷屏现象一台计算节点因故障重装系统恢复后集群里所有节点日志开始持续报告SSH主机密钥不匹配自动化脚本全部连接失败。原因重装系统时生成了新的SSH主机密钥而集群里其他节点和运维脚本还在用旧密钥做主机身份校验。这个问题在计算节点数量大的集群里尤其突出手工逐台更新known_hosts根本忙不过来。解决把SSH主机密钥纳入配置管理工具统一生成和分发。节点安装后由配置管理工具下发标准密钥或者用证书认证替代known_hosts管理。这样节点重建后只要配置管理运行正常密钥自动恢复不需要人工介入。4.4 一刀切冻结账号正式课题中断现象运维人员收到安全告警怀疑某账号异常登录直接在调度系统里把这个账号及其所有作业全部删除结果该账号正在运行一个为期数周的正式课题数据全部丢失且无法重算。原因应急响应时过于激进没有先确认账号归属和任务性质。冻结账号本身是正确操作但删除作业和用户数据这一步不可逆造成的损失可能比原始安全事件更大。解决账号异常时的标准动作是先冻结登录权限和作业提交权限保留已有进程和数据然后通知课题负责人确认身份和任务。确认是误报或失窃后再决定是否恢复切不可把“冻结”和“删除”混在一起做。4.5 防火墙加固顺序不对科研服务端口被断现象管理员按照安全基线文档在计算节点上启用防火墙结果中断了调度系统、共享存储挂载等关键服务端口整个集群作业批量失败。原因加固前没有盘点服务依赖端口。HPC节点之间的通信非常复杂除了SSH还有调度系统通信、存储客户端挂载、监控采集等多个端口一通封闭必然出事。解决加固前先用ss -tunlp全量盘点节点监听端口对照调度系统和存储厂商的端口清单逐一标注用途再按“先封无关端口、再验证核心服务、最后缩小管理端口范围”的顺序执行。每改一批规则就做一次作业提交验证确认集群正常工作后再继续。5. 监控与审计让异常行为在造成损失前暴露5.1 日志是第一现场集中收集与轮转安全事件发生后第一件事就是查日志。如果日志分散在各个计算节点、没有集中收集、也没有轮转策略排查会变成灾难现场。HPC集群至少要把三类日志集中起来登录日志、调度系统日志、存储访问日志。# /etc/rsyslog.d/hpc-audit.conf 片段 # 把本机认证日志和调度日志转发到集中日志服务器 authpriv.* 10.10.1.10:514 # 认证日志走TCP传输避免UDP丢包 local0.* 10.10.1.10:514 # 调度系统日志通常走local0按实际配置调整日志服务器建议只开放必要的接收端口禁止普通用户登录保存周期至少90天。科研数据的敏感性决定了日志本身也是敏感信息集中存储后要对日志目录做权限限制普通用户无权读取。日志轮转配置里保留周期设置好之后还要定期做恢复演练确认真的出了问题能从备份里把日志捞出来。5.2 调度系统自带审计sacct找出异常作业调度系统的审计日志比系统日志更贴近HPC业务因为它记录了每一个作业的提交者、运行时间和资源消耗。反常的作业模式往往是安全事件的前兆。# 统计某时间段内所有失败和被取消的作业按用户汇总 sacct -S 2024-01-01 -E now --stateFAILED,CANCELLED -X \ --formatUser,JobID,JobName,Elapsed,State -X | sort | uniq -c | sort -rn | head -20这条命令把失败或取消的作业按用户归并数量明显偏多的用户就是排查重点。特别留意两件事一是作业运行时长极短但次数极多可能是攻击者在探测节点二是作业的申请资源与实际消耗严重不匹配可能是恶意代码在耗CPU。调度系统还可以配置作业启动前的脚本钩子在作业启动时做一次简单的安全检查拦截可疑镜像或可执行文件。5.3 异常登录与资源突刺的快速排查命令HPC安全事件里异常登录和资源异常是最容易先暴露的征兆。几个基础命令组合起来就能完成初步排查# 查看最近登录记录留意异常时间和来源IP last -n 50 # 查看登录失败记录定位暴力破解来源 grep Failed password /var/log/auth.log | tail -20 # 查看当前对外监听端口发现非预期服务 ss -tunlp | grep -v 127.0.0.1排查时有个习惯值得养成先看登录时间是否在正常计算时段之外再看来源IP是否属于合作单位已知网段最后看端口列表是否出现了新的监听项。计算节点上出现异常进程时配合top和ps -eo pid,user,cmd能快速定位启动异常的进程。确认异常后先摘除节点调度再保留现场日志做取证不要第一时间重启节点把痕迹清掉。5.4 文件完整性给关键数据目录加一个看门狗数据完整性是HPC安全里最难自动化的部分但至少可以对核心数据目录做访问审计。Linux自带的auditd完全可以胜任这个角色# 监控project区记录写操作和属性变更k参数打标签便于检索 auditctl -w /data/project -p wa -k hpc_data_guard # 查询今天所有触发的访问记录 ausearch -k hpc_data_guard -ts today | less-p wa的含义是记录写操作和属性变更不记录读操作因为读操作调用量大、查起来噪声极高。如果课题数据涉及保密需求再加read记录但要做好日志量翻倍的准备。审计规则不要覆盖整个文件系统只覆盖project区等核心目录否则I/O损耗和日志量都会失控。每季度做一次“基线比对”——统计project区文件数量、总大小和最近修改时间与上一季度对比偏差过大就要人工核实。6. 进阶把安全检查变成每周一次的自动体检6.1 一个检查脚本五分钟跑完HPC安全基线安全策略不能只靠人肉巡检。HPC集群节点多、用户多、配置差异大用脚本把高频检查项自动化是最实用的做法。下面这个脚本涵盖了五个最常出问题的位置#!/bin/bash # HPC安全基线体检脚本 # 输出到日志文件由管理员每周定期查看一次 OUT/var/log/hpc_security_check.$(date %F).log echo HPC Security Check $(date) $OUT # 1. 找出所有权限过宽的目录其他用户可读写执行 find /home /data/project -type d -perm -0007 -maxdepth 3 \ 2/dev/null $OUT # 2. 找出空密码账号正常系统不应存在 awk -F: ($2){print $1} /etc/shadow $OUT # 3. 找出最近7天新增或修改的authorized_keys find /home/*/.ssh -name authorized_keys -mtime -7 \ 2/dev/null $OUT # 4. 列出对外监听的非回环端口 ss -tunlp | grep -v 127.0.0.1\|::1 $OUT # 5. 统计登录失败次数最高的5个来源IP grep Failed password /var/log/auth.log 2/dev/null \ | grep -oP from \K[0-9.] | sort | uniq -c | sort -rn | head -5 $OUT脚本第3条的逻辑是authorized_keys被动修改往往意味着有人往别的用户目录里塞了自己的公钥这是HPC环境里常见的横向持久化手段平时用户自己不会频繁动这个文件。第4条用于发现计算节点上悄悄开启的新服务。第5条的-greoP提取了登录失败来源IP连续数周出现在前几名又不在白名单内的IP基本可以判定为外部扫描。6.2 怎么解读输出、怎么处理误报输出文件每周生成一个管理员不需要逐条看完整日志只需要扫三个关键信号权限过宽目录是否新增、authorized_keys是否有非本人修改记录、非回环端口列表是否出现未知端口。空密码账号一旦出现就是严重问题正常集群里这条应该永远为空。误报是难免的。比如intranet里合法的监控端口会被第4条标记某些课题组确实需要临时共享目录会被第1条标记。处理误报的正确方式不是改脚本参数而是建一个例外清单文件把经过确认的业务端口和共享目录写进去脚本里加一个过滤步骤。这样后续每次体检的噪声越来越少。我习惯把每周的安全体检和每月的数据完整性核查放在同一天做形成固定的运维节律。安全检查不需要每次都查出大问题更多是确认一切正常让自己对集群的状态心里有数。HPC安全策略这件事说到底就是把“出了事再救”变成“平时就看着”把不可控的黑匣子尽量变成透明可见的日常操作。数据清理之前先在别处留一份副本可能是我做运维以来唯一买得到后悔药的地方——安全投入不一定马上见效但真出事那天之前做过的每一步检查都算数。希望帮到你。本文还有配套的精品资源点击获取