★ FEATURED ARTICLE 接到汽车服务平台出海项目时我列的第一张表不是功能清单而是“主机安全现状自查”。那时候团队对AWS上的防护更多停留在安全组和WAF层面真正到了青藤万相这类主机侧Agent工具要接入的环节才发现漏洞、基线、入侵检测这些能力还悬在空中。这篇博文想把我们这次在海外业务场景落地的全过程记录下来包括为什么选这套组合、上线踩过哪些坑、日常怎么运营。如果你是运维、安全工程师或者正在做云上主机安全体系选型应该可以从中找到对标的思路。1. 出海场景下主机安全为什么成了“卡脖子”的环节1.1 汽车服务平台的数据价值决定了它必然被盯上汽车服务平台和普通网站不一样它既有用户手机号、电子钱包、车辆识别码、维修记录、实时位置这类高价值个人数据又有大量对外开放的查询和交易接口。这类平台一旦出海通常会在新的Region开一个独立VPC重新部署一套应用集群。业务扩容速度快基础设施的部署节奏也快安全建设如果跟不上基本上就是“业务先跑安全后补”的状态。但出海业务还有一个特点客户和合作方会反过来倒逼你。很多海外合作方在商务洽谈阶段就会发来安全问卷问题往往很具体——你的主机有没有做漏洞管理是不是有检测响应类能力SSH登录有没有审计有没有证据链能做攻击溯源这些都不是云服务商能帮你回答的光靠AWS控制台和安全组拿不出一份像样的答卷。我们内部复盘时把这笔账算得很清楚主机安全不是合规部门要的一张纸它直接决定平台在海外的合作门槛和事故响应速度。一出事如果连哪台机器、哪个进程、哪个文件导致的都说不清合作方的信任也很难重建。1.2 责任共担模型下云帮不了你的那一半AWS的安全责任模型分得很清楚AWS负责底层物理设施、虚拟化、托管服务的安全租户负责自己部署的操作系统、应用、数据、访问策略。放到主机安全里理解就是安全组可以帮你挡住一部分外部流量但不保证你的主机里已经跑着的进程是不是恶意程序CloudTrail可以记录API调用但不代表攻击者通过Web漏洞拿下Shell之后的操作都被完整记录下来。主机侧安全必须有一个Agent视角直接观察文件、进程、网络连接、登录行为。这也是当初选型时我们优先考虑主机安全Agent类产品而不是只靠ACL和WAF堆一层的原因。如果你开始做出海业务的第一天就理解这条边界后面很多工作都会顺不少。当时我和团队说得挺直白云平台负责把地基打牢但屋里进没进贼得自己装监控。青藤万相这类主机安全工具就是那个监控。1.3 上线前的“体检清单”查完别吓一跳在引入青藤万相之前我按经验列了一张主机安全体检清单让团队逐项自查。这张表我至今还留着也建议准备做同类建设的同学先跑一遍检查项是否覆盖备注海外新Region资产的统一台账部分覆盖依赖各环境手工维护已公开漏洞的聚合视图否各账号分开无法汇总主机登录行为审计SSH/RDP否仅靠系统日志分散基线合规核查部分覆盖仅部分核心主机WebShell/反弹Shell/暴力破解检测否只关注了云上告警攻击链路的进程级溯源否缺少证据链工具查完结果其实不意外主机侧基本都是半空白状态。这反而让决策变得简单——第一步不是继续讨论而是先把主机安全能力落地。2. 青藤万相与AWS到底谁做哪一部分2.1 主机侧Agent解决的是“最后一公里”的问题很多刚接触主机安全的人会问AWS不是有GuardDuty吗已经是成熟的威胁检测服务了为什么还要额外部署主机安全Agent我的理解是GuardDuty更擅长从云平台视角发现异常比如某个EC2的DNS请求指向了威胁情报库里的恶意域名、某个IAM凭证出现了异常使用模式、EBS快照被导出等。这些属于云侧信号。但如果攻击者是利用Web漏洞打进Nginx然后下载脚本、反弹Shell、横向移动到数据库主机这些行为发生在操作系统内部云侧日志往往只是冰山一角。主机侧才是完整的现场记录。青藤万相这种Agent类工具核心价值有三块。一块是资产指纹装完之后自动清点系统上有什么软件、什么服务、什么开放端口哪些补丁没打第二块是行为检测监控文件读写、进程启动、网络外联、登录行为发现WebShell落地、反弹Shell、权限提升这类危险动作会告警第三块是证据链把进程父子关系、文件操作时间线串起来方便定位攻击全路径。这些是主机级别的“最后一公里”能力。2.2 AWS在方案里的角色底座、上下文与审计来源AWS在整套体系里也不是纯粹被动的。我们有三个实践交叉使用第一个是AWS Systems Manager尤其是Session Manager。通过SSM登录主机可以完全不开公网SSH端口配合IAM做身份认证和会话审计从根源上减少一类攻击入口。第二个是VPC Flow Logs和CloudTrail。这两类日志在应急时非常有用。比如主机Agent报了某个异常外联我需要知道这个流量对应安全组的哪条规则、是哪个实例发起的VPC Flow Logs就能补上网络层面的记录CloudTrail则能回答这个实例的IAM角色有没有被冒用、有没有创建过新的凭证。第三个是Amazon GuardDuty和Security Hub。GuardDuty可以在云侧提供独立的威胁情报维度即便主机被绕过DNS异常、API调用异常也能形成第二双眼睛。Security Hub可以把多个账号的安全状态聚合到一个地方配合自定义的合规规则便于管理层统一看板。2.3 一张分工表快速跟团队对齐职责落地前我们画了一张分工表帮助团队快速理解两种工具的边界和协作方式。这里也分享出来能力维度青藤万相主机侧AWS原生服务云侧资产清点操作系统内部资产进程、软件、端口资源清单与标签EC2/Security Group/ELB漏洞管理通过Agent采集系统与应用漏洞Amazon Inspector做部分托管实例扫描威胁检测文件、进程、登录、外联行为检测GuardDutyDNS/API/网络异常日志审计主机内部命令、文件操作证据CloudTrail VPC Flow Logs合规基线系统配置基线核查与修复AWS Config云资源合规检查统一运营主机侧告警、漏洞、基线聚合运营Security Hub多账号安全聚合这张表对团队帮助很大。造轮子和重复投入往往是因为没讲清楚边界。有了分工运维知道该管AWS侧的资源与网络配置安全侧重管主机侧的行为与漏洞修复配合起来而不是抢着干活。3. 落地前必须做透的一件事资产台账与暴露面收敛3.1 用组织视角建立资产台账而不是各环境各查各的出海业务最怕的就是环境多了之后账号之间形成信息孤岛。AWS账号多起来之后哪台EC2属于哪个业务单元、哪个Region有哪套集群光靠表格记录迟早维护不下去。我们做的第一件事是决定用标签体系强制治理资源。具体做法是所有EC2在创建时必须打上至少三个标签Environmentprod/staging/dev、ServiceName用户端API/车联网接入/订单中心等、Owner负责人团队。然后把这些标签作为唯一可信源同步给主机安全平台做分组和命名。引入青藤万相后第一周团队的目标不是看告警而是把各账号下的资产清点结果和运维台账两相对照找出“有主机但没人登记”和“登记了但主机已下线”的资产。清点结果很有意思我们找到了一批开发环境因为误配了弹性IP暴露到公网还有两台长期运行的跳板机没有打补丁更有一个闲置账户里残留着旧的API密钥。这些属于上线前就必须处理掉的风险项。3.2 安全组暴露面收敛少一条公网规则敌人就少一扇门暴露面收敛是主机安全之外、但影响主机安全的头号因素。几乎所有入侵链路的起点都是某个不该暴露的服务暴露到了公网。安全组的调整要主动做而不是只等告警。我们制定了一个简单规则也推给了团队默认拒绝所有入站公网流量仅在需要时按最小化开白名单。管理端口22/3389一律不对公网开放运维走SSM Session Manager只有面向用户的Web服务端口才放通到0.0.0.0/0并且前面必须有负载均衡和WAF。这里放一条我们常用安全组的示意描述实际值按环境替换SecurityGroup: web-sg-env Ingress: - Port: 443 Source: 0.0.0.0/0 (仅建议前面加ALB/WAF不直接挂到EC2) - Port: 80 Source: 0.0.0.0/0 (用于跳转/公告页) Egress: - Port: 443 to: 公司内部代理或API网关 - Port: 8443 to: 业务内网网段原则很简单不起作用的规则就是风险能删就删。Egress方向也别大撒网很多入侵后的数据外泄都是从主机主动外连开始的。配合主机安全Agent的网络连接审计我们还可以周期性拉取允许外联的端口清单做二次核对。3.3 从全开演变为动态把“信任”建立在元数据上早期不少团队管理安全靠“之前就是这么开的”要收敛就要动大家的习惯。AWS里比较有效的方式是利用实例元数据和IAM结合来做动态授权。比如主机Agent需要调用S3同步检测策略不要给全局S3权限而是用S3 VPC Endpoint加Bucket Policy限定到特定前缀Web服务访问数据库也不要配置0.0.0.0/0的数据库安全组而是用EC2的私网IP和安全组ID做来源限制。这一步的收益在后续的攻防模拟里很快体现出来一个普通Web节点被攻破之后它的IAM角色只能访问提前声明的资源横向移动的路基本被切断了。4. 部署Agent的坑比想象中多三个关键细节4.1 第一个坑把AccessKey写进了启动脚本这是我们内部复查时发现的最典型问题。刚开始有同事图方便把AWS的AccessKey放进EC2的User Data里让Agent启动时读取密钥做上报和调用API。我立刻叫停了这个做法。密钥一旦出现在启动脚本、镜像或应用日志里只要一台机器被渗透攻击者就能把它拖出来反复使用这类密钥还特别难清理因为不知道传递到了哪些地方。我们最终采用的是Instance Profile。在IAM里创建一个角色只授予Agent运行时需要的权限比如从特定的S3桶读取升级包和策略、向指定的日志端点写日志、从Systems Manager参数仓库读取配置。然后让EC2直接绑定该角色。Agent运行过程里SDK会自动从实例元数据获取临时凭证不需要任何明文密钥。这也是云厂商官方一直在强调的规范做法。用一句话提醒团队创建角色权限时宁可先给最小权限再逐步放开也不要一步到位给一个近乎管理员的权利。4.2 第二个坑主机跑起来才补装Agent出海环境扩容快经常用镜像批量拉起实例。如果Agent不是预制在镜像里而是等实例起来之后手动补装就会出现三类问题漏装率一定不低补装期间主机处于无保护状态各批实例Agent版本五花八门后续升级要追着修。我们的做法是把Agent安装放进镜像构建阶段。现在普遍流行用Packer这类工具做镜像流水线在构建脚本里调用Agent安装命令并在镜像发布前做一次“压测验证”——启动一台新实例确认Agent进程存活、心跳正常、资产上报完整再放行到生产。验证命令各家Agent可能不一样但常规思路是确认进程存在再确认上报地址和心跳# 检查Agent进程是否运行 ps -ef | grep agent进程名 | grep -v grep # 检查Agent与云端连接状态以通用主机安全工具为例 agent安装目录/bin/status # 应有在线/正常运行类状态输出 # 确认Agent版本避免多个实例版本混乱 agent安装目录/bin/version把这个验证脚本放在镜像流水线的最后一个步骤里起到的作用是杜绝“上线了才发现没装成功”的晚发现。4.3 第三个坑检测数据回传路径暴露在公网上主机安全Agent会产生检测数据、心跳、文件Hash等需要回传到安全平台的服务端。很多团队图省事让Agent直连公网域名上报恰好给了攻击者一条可能的探测和干扰路径。我们这次采用的方法是全部走VPC内网传输在VPC里配置对应的终端节点不回公网。这里不展开太多控制台细节因为不同区域的实现有差异核心思路是让Agent的上报目标解析为VPC内的私有地址并单独为它开通安全组策略保证只有特定主机可以访问对应端口。同时开启TLS加密传输避免检测流量被中间人窥探。如果Agent本身支持代理模式也可以走已有的内网代理。关键是事先确认好上报链路的网络路径不要在扩容之后才意识到“海外区域的Agent一直没和云端服务端通信上”。我们吃过一次这样的亏发生在某个新Region上线首日——监控面板上全是灰色最后排查是路由表没有加对应的回程路由。5. 日常运营漏洞、基线、入侵三条线怎么协同5.1 漏洞管理别只盯CVSS分数要按暴露程度排主机安全平台会给出漏洞列表和CVSS评分但直接按分数排序去修是偷懒做法。一个8.9分的漏洞如果只在公网不可达的内网管理机上其实风险并不高一个5.6分的中危漏洞如果挂在公网API入口上反而要优先处理。我们当时定了一个漏洞优先级公式简单但有效变量包括三个该主机是否可从公网访问、主机承载业务的敏感度、漏洞是否存在可利用的公开POC。只有三项都满足才会被标记为P0并在24小时内安排修复不满足则进入常规补丁周期。具体落实到主机安全平台后台我们按资产分组过滤出“公网暴露”“对客API”“数据库主机”三个分组每个分组单独看漏洞列表再结合是否有POC决定修复节奏。这种方式比单纯看CVSS列表要高效得多。运维同事问得最多的一个问题补丁打了会不会影响业务我们的答案是先在预发环境跑一遍验证脚本再轮转补丁别在高峰时段补别只补一半就下线。补丁管理要有批次、有回滚预案。5.2 基线检查别只做一次要做成周期动作基线核查的价值在于发现“漂移”这个月安全加固做完了下个月某个运维为了方便调试改了一个SSH配置高危端口又开出来了。AWS Config在云资源层面能检查部分合规项但系统内部的基线比如SSH PermitRootLogin、密码策略、FTP服务是否开启就得靠主机安全基线能力来盯。我们设定的节奏是生产环境每周跑一次基线核查每月做一次全量核查发现漂移项后按之前定好的例外机制处理——允许有例外但例外必须写明原因、责任人、复查时间不能默默压掉。加白名单这块最容易产生黑洞。我给团队的规则是白名单必须成对出现每一项都有“允许触发的原因”和“过期时间”到了时间自动回流到检查列表。否则半年之后白名单比告警还长基线检查就流于形式。5.3 入侵检测从告警到攻击链路入侵检测是主机安全里最核心的运营动作。告警不可避免会有噪音但如果因为噪音就关掉检测那就是自己做鸵鸟。更合理的做法是分等级处理。常规运营中我会把入侵告警分成三级P1严重主机被植入WebShell并被执行、反弹Shell、rootkit类行为、异常高权限进程拉起。需要立即处置同时主机隔离和证据保全并行。P2高危暴破成功迹象、异常登录时段、异常外联到陌生IP、可疑的定时任务新增。需要确认活、判断是否影响面扩大。P3中危单点登录失败次数多、某个文件被修改但看不出恶意、触发规则但上下文缺失。进入事件池如果短时间重复出现再升级处理。最关键的一点是别单看一条告警。攻击链路通常是一串动作组合Web日志出现可疑上传、脚本文件落地、进程被拉起、外联回连。主机安全平台的任务是把这些动作通过进程树和时间线串在一起。处理告警时我会先看进程的父进程和历史命令再确认文件来源最后去Web层和网络层交叉验证。这个思路在本项目的一次真实应急里得到了验证下一节就是一个完整的复盘。6. 一次从告警到处置的应急复盘6.1 凌晨的告警一台API节点出现异常外联有一次凌晨两点夜里值班的同事在群里发了一条消息主机安全平台抛出一个P2级告警某海外API节点检测到异常外联目标IP不在这台机器正常外联名单里且进程名为一个不常见的脚本解释器调用。按我们当时定下的响应步骤先确认活再处置拉出告警详情里的进程树确认是什么父进程拉起了这个脚本解释器给这台实例打上“疑似入侵”标签并保留现场同步开始收集证据。同时运维侧通过安全组先把该实例的出站流量收紧到只允许到必要的内网服务避免进一步外连。当然这不是说立刻断网而是先做一个快速止血动作同时不影响主机继续接受安全平台的证据采集。6.2 双向溯源主机侧和云侧日志拼出完整攻击链路主机侧调出该实例的进程树后场景慢慢清晰了一个可疑文件被上传到了Web目录紧接着被脚本解释器执行执行后又从外部地址拉取了一段程序代码并运行最终建立了外联。问题的根因初步指向Web应用某接口的上传校验不严。云侧也没闲着。CloudTrail显示该实例没有被赋予新的IAM权限没有新增密钥安全组规则也没有被改动说明攻击者暂时没有尝试云上横向VPC Flow Logs则进一步确认了外联流量的会话信息和包大小和主机侧看到的时间点完全对得上。两条线索一对攻击链路的结论就出来了Web漏洞利用上传WebShell→脚本执行→外联回连。到此可以做处置了而不是只杀一个进程了事。6.3 止血、加固与闭环复查处置动作按四条线铺开隔离将该实例移出负载均衡并收紧安全组阻断与外网的连接通过快照保留完整取证现场。清除与修复删除Web目录中的恶意文件升级存在漏洞的组件修复上传接口的校验逻辑修改该主机上所有相关的口令和密钥。排查扩散按时间窗口和同版本组件作为条件扫描同批次上线的其他主机确认没有同类残留。验证与复盘修复后重新触发一次主机安全Agent的全量扫描和基线核查确认该恶意文件指纹已消失、外联告警不再出现。然后把这次的攻击路径整理成一条新的检测规则加进后续上线检查清单。整件事从告警到闭环用了两个多小时。事后团队复盘时最深的感受是如果没有主机侧的进程树证据单纯靠云上日志很难在这么短时间里还原完整链路反过来如果没有云侧日志也很难判断攻击者是否已经动过IAM和网络配置。这次项目跑完之后我对主机安全这件事有了更实在的体会。工具当然重要但更关键的是把运营动作养成习惯资产台账要一直准确暴露面要反复收敛基线检查要做成周期告警处置要形成SOP。青藤万相和AWS的组合恰好覆盖了主机侧和云侧两半拼图真正解决问题的是团队把这些能力串成了闭环。如果你也在做类似的海外部署或云上主机安全建设希望这篇复盘能帮你少走一点弯路。就我个人来说最值得投入时间的那件事仍然是在攻击发生之前把自己想象成攻击者亲手过一遍你的暴露面清单。
阅读完成 · 觉得有帮助？
