云主机安全入门：责任共担模型与主机防护边界

核心要点（TL;DR）

云厂商负责物理设施与虚拟化层，操作系统以上安全由用户承担。
主机防护能防入侵与提权，但挡不住配置错误导致的暴露面。
安全组与SSH加固是云主机安全最低成本、最高收益的两步。
责任共担不是免责声明，而是需要逐项核对的落地清单。

很多运维和站长心里有个默认假设：主机跑在云上，安全就归云厂商管。直到某天收到一条「CPU 跑满、对外发起大量连接」的告警，登录上去发现 /tmp 里多了个陌生二进制，才意识到云主机安全这件事，云厂商只兜住了一半。本文围绕责任共担模型，讲清主机防护的作用边界，并给出可以直接复制执行的排查与加固步骤。

一、责任共担模型到底分的是什么

责任共担模型（Shared Responsibility Model）的核心是把云上安全切成两段：云厂商负责「云本身的安全」，用户负责「云里面的安全」。前者包括物理机房、硬件、虚拟化层与网络基础设施；后者从操作系统往上，全部归你。

层次	责任方	典型事项
物理设施与硬件	云厂商	机房门禁、供电、磁盘销毁
虚拟化与宿主机	云厂商	Hypervisor 隔离、热迁移
操作系统与中间件	用户	补丁、内核参数、服务配置
账号与访问控制	用户	SSH 密钥、安全组、最小权限
应用与数据	用户	代码漏洞、数据加密、备份

这张表不是免责声明，而是核对清单。边界一旦模糊，最容易出现「两边都以为对方在管」的空档，而攻击者恰恰专挑这种空档。

二、主机防护能做什么、不能做什么

主机防护（HIDS、防病毒、基线检测类工具）工作在操作系统内部，能力边界很清晰。

能做：检测异常进程、文件篡改、反弹 shell、暴力破解登录、提权行为，并做告警或阻断。
不能做：替你关掉对全网开放的 22 端口，替你打内核补丁，替你收回离职员工的密钥。

换句话说，主机防护是「系统层的摄像头和门禁」，而暴露面收敛是「先把大门关上」。安全组配错导致数据库端口对公网开放，主机防护只能事后告警，无法消除暴露面本身。这也是很多团队装了防护仍然被入侵的根本原因。

三、第一步：核查暴露面（安全组与监听端口）

先看网络层谁能进来，再看系统层开了什么。

# 查看本机监听端口与对应进程
ss -antp | grep LISTEN

# 查看防火墙规则（以 firewalld 为例）
firewall-cmd --list-all

# 云上还需在控制台核对安全组入站规则
# 重点关注 0.0.0.0/0 放行的 22、3306、6379、9200 等端口

检查清单：

22 端口是否只对固定办公 IP 或跳板机开放；
数据库、缓存、搜索类端口是否仅内网可达；
是否存在「临时开放忘了关」的规则；
高危端口是否全部禁止公网入站。

四、第二步：SSH 与账号基线加固

绝大多数云主机入侵从弱口令或密钥泄露开始。以下配置改完执行 sshd -t 校验，再 systemctl reload sshd 生效。

# /etc/ssh/sshd_config 关键项
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300

同时做三件事：

用 awk -F: '(==0){print }' /etc/passwd 确认 UID 为 0 的账号只有 root；
用 lastb | head -20 查看近期失败登录来源，异常 IP 直接加入安全组拒绝；
为运维账号配置 sudo 最小权限，避免全员 root。

五、第三步：补丁、日志与入侵排查

补丁滞后是最常见的中危项。Debian/Ubuntu 系执行 apt list --upgradable，RHEL 系执行 dnf check-update，重点跟进内核与 OpenSSH。建议开启自动安全更新，仅自动安装 security 源补丁。

怀疑已被入侵时，按顺序取证，不要急着重装：

last -a | head
ps auxf
crontab -l; ls -l /etc/cron.*
cat /etc/passwd | grep -v nologin
find /tmp /dev/shm -type f -mtime -3

发现异常进程先 kill -STOP 暂停而非直接杀掉，保留现场后再做快照。防护建议上，可在主机层叠加 AegisX 的入侵检测与基线核查能力，把登录异常、文件篡改、提权行为纳入统一告警，减少人工翻日志的成本。

六、落地清单与行动建议

把上面内容压缩成一张每周可执行的清单：

核对安全组，确认无 0.0.0.0/0 高危端口；
确认 SSH 禁密码、禁 root 直连；
确认安全补丁在一周内完成；
抽查 lastb 与异常进程；
确认备份可用且与主机隔离。

行动建议：今天就先做安全组收口和 SSH 加固这两步，成本最低、收益最高；再根据业务重要程度逐步引入主机防护与日志审计。责任共担模型的意义不在于划分责任，而在于提醒你——云厂商兜住的那一半之外，剩下的一半必须有人真正去核对。

常见问题（FAQ）

云主机安全是不是买了云厂商的安全产品就不用管了？

不是。责任共担模型下，云厂商只负责物理机房、硬件和虚拟化层安全，操作系统补丁、账号权限、应用配置、数据加密都由用户负责。云安全产品只是工具，配置与运营责任仍在用户侧。买了产品不等于转移了责任，仍需定期核查安全组、补丁和登录日志。

责任共担模型里用户到底要负责哪些部分？

通常包括：操作系统与中间件补丁、账号与密钥管理、安全组与防火墙规则、应用代码安全、数据分类与加密、日志审计与入侵检测。云厂商负责物理安全、宿主机与虚拟化隔离、网络基础设施和可用区冗余。边界以云服务商文档为准，但主机层以上基本归用户。

主机防护软件能替代安全组吗？

不能。安全组在网络层做准入控制，决定谁能连到哪些端口；主机防护在系统层做行为检测与阻断，两者层次不同。安全组配错导致22端口对全网开放，主机防护只能事后告警，无法消除暴露面。正确做法是先收紧安全组，再叠加主机层防护。

云主机被入侵后第一步应该做什么？

先隔离再取证。立即在安全组中封禁该实例的入站流量，保留内存与磁盘快照，再查看登录日志与进程。不要急着重装，重装会破坏证据。排查命令包括 last、lastb、ss -antp、ps auxf 和检查 /etc/passwd 与 crontab 的异常项。

中小团队如何低成本做好云主机安全？

优先做三件事：安全组只放行必要端口并限制源IP、禁用密码登录改用密钥并关闭root直连、开启自动安全更新并每周核查一次登录失败日志。这三步不需要额外采购，能消除大部分自动化扫描与弱口令爆破风险，再按需叠加主机防护。

资讯中心