如果你手上同时管着Web门户、移动App和一批IoT设备那么AWS云环境的安全运营往往不是“有没有安全工具”的问题而是“工具散落一地、告警互相打架、出了事不知道先看哪块”的问题。最近我帮一家客户从0到1搭了一套覆盖Web/APP/IoT全场景的AWS安全运营体系从账号基线到自动化处置用了不到两周时间把日均告警量从上千条降到了几十条而且真正遇到攻击时能直接联动封禁不用人肉翻日志。这篇文章就把整个搭建过程、选型逻辑和踩过的坑完整写出来适合正在做云上安全建设的运维、安全工程师和架构师参考。这个体系不是什么天价商业方案全部基于AWS托管服务搭建。我会按“底层逻辑 - 服务选型 - 账号基线 - 三类场景落地 - 运营闭环”的顺序来讲每一步都给可落地的配置思路和关键参数也会穿插一些我们实测中踩过的坑。尤其是告警降噪和成本控制这两块很多人一开始根本不会注意到但它们恰恰决定了一套安全运营体系能走多远。1. 安全运营的底层逻辑为什么零散工具救不了云环境1.1 从一次凌晨的告警风暴说起我接手这个项目前客户的AWS环境已经不是什么都没做的状态。他们有CloudTrail开了GuardDuty也买了WAF看起来该有的都有。但拿到权限一看GuardDuty在6个region里只开了2个S3的访问日志没有开对象级写入CloudTrail的日志全部落在单账户的默认桶里最糟的是SNS里根本没有任何告警订阅——也就是说就算GuardDuty发现了问题也没有人会收到通知。真实情况比这更戏剧化。客户把Web应用的前端放在一台绑了公网EIP的EC2上安全组对全互联网开放了22端口而且有一把长期的access key被开发顺手提交到了开源代码仓库。华为云有人用这个key扫了一整夜客户第二天看到账单飙升才反应过来。整个排查过程花了将近一天因为没有任何集中日志只能在各个控制台之间来回切。这件事让我意识到零散启用几个AWS安全服务跟“运营”完全不是一回事。安全运营的底层不是某几个工具而是一条从“识别 - 检测 - 响应 - 修复”的闭环链路。少了任何一环前面的检测能力都等于摆设。1.2 Web/APP/IoT三类场景威胁模型完全不同做体系设计之前必须先把三类业务场景掰开来看。很多人上来就配WAF和GuardDuty配完之后发现APP场景的威胁根本没覆盖到IoT设备的行为异常也检测不出来。我习惯先用一张表把三类场景的差异列清楚再决定在每个场景上投入什么资源维度Web场景APP场景IoT场景主要入口域名、浏览器API、移动客户端设备接入、消息通信核心资产Web应用、数据库、存储桶用户身份、业务API设备证书、固件、遥测数据高频威胁漏洞扫描、SQL注入、DDoS、恶意爬虫撞库、接口滥用、越权调用、逆向抓包设备仿冒、固件后门、异常流量、越权订阅关键防线WAF、主机漏洞扫描、访问日志审计API网关限流、身份认证、行为风控设备证书策略、行为基线、失陷隔离日志特征Web日志、ALB访问日志、OS日志API Gateway日志、Cognito登录日志IoT Core消息日志、设备影子、连接事件Web场景的防护重点在“边界”App场景的重心在“身份”IoT场景则在“设备信任”。如果你只靠一套WAF和Security Hub就想覆盖所有场景那大概率只能覆盖Web那部分APP和IoT仍然处于裸奔状态。所以体系设计的第一步不是选工具而是画清楚你的资产和威胁面。1.3 用事件时间线反推体系设计我设计安全运营体系时有个习惯先假设一个“攻击者正在打你”的事件时间线反推每一步需要什么数据源和响应动作。比如一个典型的Web入侵过程攻击者扫描公网IP发现暴露的管理后台端口对后台发起暴力破解成功拿到弱口令登录后台上传webshell横向扫描内网拖走数据库植入挖矿程序绑定定时任务确认持久化。现在反推第一步需要外部扫描感知能力可以用GuardDuty的Recon、VPC Flow Logs异常检测第二步需要安全组收敛和失败登录告警第三步需要CloudTrail和可疑进程检测第四步需要S3数据访问审计和实例资源监控。有了这条完整的事件时间线再看应该接哪些数据、配哪些告警整个架构就会清晰很多。这套思路放到APP和IoT场景也一样只要把攻击者当作用户来模拟一遍你自然就知道该在哪个环节布防了。2. 选型清单AWS 安全服务怎么挑、怎么搭才不重叠2.1 十一个核心服务各管一段AWS这家公司的问题从来不是能力不够而是服务太多太碎很容易让人陷入“选择困难症”。我的经验是只保留一套最小可用集避免多个服务做同一件事。服务职责类比CloudTrail记录所有API调用行为监控摄像头记“谁在什么时候做了什么”GuardDuty持续威胁检测找异常保安巡逻基于威胁情报和异常行为报警Security Hub聚合各类安全发现和合规检查中控台把所有报警汇总到一块大屏幕AWS WAF拦截Web/API层的应用攻击大门口的安检机ShieldDDoS防护减轻网络层攻击防暴盾牌Amazon Inspector扫描EC2和镜像漏洞定期给主机做体检AWS Config记录资源配置变更并做规则评估记账本查“现在家里东西摆得合不合规矩”IAM Access Analyzer找过度授权的权限和外泄风险审计员专门挑“不该给的权限”Macie发现S3里的敏感数据情报员发现哪些地方放了不该放的数据Systems Manager批量打补丁、执行命令后勤维修队EventBridge Lambda把安全事件变成自动化动作自动化总控报警后直接出手处理这套组合里真正24小时需要盯着的是GuardDuty、Security Hub、CloudTrail和Config其他服务属于“定期用”或者“出事才翻”的类型。理解了各自的分工后面的配置才不会乱。2.2 为什么我不建议自己搭一套开源SIEM很多人一聊安全运营就想着自己搭ELK或者Graylog把VPC Flow Logs、CloudTrail、WAF日志全部灌进去再写一堆告警规则。这个方案在只有单账户、几十台实例的场景下还能凑合一旦账户规模超过三五个或者有多个region日志采集agent的维护、索引优化和告警规则调试就会吃掉大量时间。我的观点很直接开源自建SIEM适合做数据分析平台的团队不适合大多数中小型云上业务团队。AWS托管方案的天花板虽然不如定制SIEM高但它赢在“零维护、默认越权少、跟IAM和Organization深度集成”。GuardDuty和Security Hub能自动获取多账户多region的检测结果自己的ELK想做到这个程度至少要花两周时间做权限模型和跨账户日志汇聚。当然如果监管要求你必须保留超过一年的日志分析或者业务有自己的威胁情报模型那就把S3里的CloudTrail、ALB、VPC Flow Logs作为原始数据源用Athena按需查询而不是再起一套永远在烧钱的日志集群。这个方案我后面会具体演示。2.3 托管服务的分工边界还有一个很常见的坑GuardDuty和Security Hub长得有点像很多人以为开了Security Hub就自动有了威胁检测能力。实际上完全不是一回事。GuardDuty负责“检测”它通过分析DNS、VPC Flow Logs、CloudTrail找到异常事件Security Hub负责“聚合和合规”它把GuardDuty、Inspector、Config、Macie等发现都收进来做统一展示和打分。换句话说GuardDuty是传感器Security Hub是中控台两者是上下游关系不是替代关系。在我这套体系里它们的边界非常清楚检测层GuardDuty Inspector Macie Config聚合层Security Hub响应层EventBridge SNS Lambda展示层Security Hub 告警通道。配置的时候不要贪多一个账号一个region一个角色按这条链路走完再复制到其他region最后在Organization层面做统一管理。3. 从0到1先把账号、日志、告警这条地基打通3.1 组织级CloudTrail日志不落S3等于白开CloudTrail是整个体系的“摄像头”它记录API调用行为IAM用户登录、Lambda执行、S3删除、EC2启动等全部有迹可循。但很多人的CloudTrail只开在默认region、默认桶而且没有开启数据事件记录结果日志形同虚设。我的建议是在Organization的Root账户里启用组织级CloudTrail一条trail覆盖所有成员账户日志统一投递到一个集中日志账户的S3桶。这个桶必须设置严格的Bucket Policy只允许CloudTrail写入并且开启版本控制和MFA Delete防止攻击者删除日志。关键配置点管理事件勾选read write全部开启数据事件S3对象级写入和Lambda执行建议开启但要注意日志量会明显增加启用Insights事件用来检测API调用中的异常模式比如某个IAM用户发生突变式的调用量。日志文件前缀建议按STS格式分区方便后续用Athena按时间范围查询。如果预算紧张至少要把write事件和S3对象级删除事件打开。read事件太多日志量大但对安全排查也有价值可以根据自己业务权衡。但write事件绝对不能省。3.2 GuardDuty和Security Hub检测与聚合要同时启用GuardDuty是个多region服务每个region都要启用否则攻击者在未启用region的流量和API行为就变成了盲区。我一般直接用AWS Organizations批量启用这样新加入的账户会自动被保护。GuardDuty启用后它会自动分析CloudTrail事件、VPC Flow Logs和DNS日志。不需要你做额外采集这也是我优先推荐它的原因之一。Security Hub则负责把GuardDuty的安全发现聚合到一起并和CIS AWS Foundations Benchmark做合规检查。这里有几个容易漏的细节Security Hub也要在每个region分别启用但可以通过聚合配置把发现集中到主regionGuardDuty的发现默认保留90天建议设置S3自动归档规则方便后续审计Security Hub和GuardDuty都建议使用中央管理员账户模式否则每个子账户各看各的运营效率起不来。兜底的做法是给Security Hub创建一个自定义的 insight把“Critical和High级别的GuardDuty发现”固定成一个视图安全运营同事每天只需看这个列表即可。3.3 告警通路EventBridge SNS Lambda的轻量编排检测做完了最关键的“告警通路”才刚上桌。很多团队开通GuardDuty后就没下文了直到安全事故复盘才发现“根本没有通知”。这一步我一般是这么搭的创建三个SNS Topic一个给Critical一个给High一个给Medium/Low在EventBridge里创建规则监听GuardDuty的Finding事件按严重级别发送到对应Topic用Lambda接收SNS消息做格式化后推到企业内部的钉钉/企微/邮件Critical事件额外触发一条自动化Playbook比如自动隔离异常实例。EventBridge规则的JSON大致长这样{ source: [aws.guardduty], detail-type: [GuardDuty Finding], detail: { severity: [8, 9, 10] } }Lambda里没必要写太复杂的逻辑格式化消息、丢到指定webhook即可。真正复杂的自动化动作放在后面的Playbook里。这套链路我跑了半年最稳定也不需要额外买商业告警平台。还有一个容易被忽略的点SNS推送失败时要有兜底。我习惯在SNS Topic里同时加一个邮箱订阅或者用CloudWatch Alarm监控SNS投递失败率。告警链路自身挂了比没告警还危险。4. Web场景落地入口防护、主机漏洞、日志分析三线并行4.1 CloudFront WAF Shield把攻击挡在边缘Web场景最容易看见效果的地方在入口。我的常规配置是CloudFront做CDN和加速WAF挂在CloudFront前面Shield Standard自动开启再叠加Shield Advanced如果有DDoS合规要求。这套组合能过滤掉绝大部分扫描流量和Web层攻击。WAF的规则组我一般是这么开的AWS托管规则组里的SQL注入规则和XSS规则直接关联Core Rule Set全部启用应用层协议异常、恶意UA、畸形请求都会被拦截自定义Rate-based rule比如同一个IP 5分钟内超过200次请求就封禁对登录接口单独加一条“失败次数超过阈值自动Block”的规则。实际落地时要注意误报问题。WAF拦截后用户会看到类似“Your last request has been blocked for security purposes”的提示页如果业务有正常的请求模式比如API接口有高频率轮询很容易误伤。所以WAF上线后第一周一定要开“Challenge”或“Count”模式观察云监控里的拦截样本再把规则从Count切到Block。4.2 Inspector定时扫主机别等被攻破才知道有漏洞主机侧的漏洞扫描Amazon Inspector是AWS原生方案里最省心的。它可以定时扫描EC2实例上的操作系统和应用程序漏洞并且能结合网络可达性给风险打分。这个服务的底层扫描引擎不需要装agent其实是Amazon自有探针对生产环境侵入性很低。我的建议配置是对生产环境EC2启用持续扫描模式每24小时扫一次对部署用的AMI镜像做“构建时扫描”也就是在流水线里跑Inspector扫描扫描过了再推送到生产把Inspector发现推送回Security Hub统一看漏洞趋势。很多人会问Inspector和第三方漏洞扫描器有什么区别。最大的区别是Inspector知道你的实例是否暴露在公网它能调出“这台机器根本没绑公网IP虽然漏洞严重但不可达”这样的结果优先级自然不同。所以我把Inspector的“网络可达性”作为排序第一维再结合CVSS评分优先修复那些“又严重又暴露”的主机。4.3 从ALB日志到Athena用SQL查异常流量光有WAF拦截还不够安全运营需要能自己查历史流量。ALB的访问日志默认不开启开之后会写进S3再通过Athena建表就能用SQL查了。我分享一条我们最常用的查询统计被WAF拦截的Top IP和路径SELECT request_ip, count(*) AS requests FROM alb_logs WHERE elb_status_code 403 AND date current_date - interval 7 day GROUP BY request_ip ORDER BY requests DESC LIMIT 20;这个查询能快速定位谁在反复触犯WAF规则、有没有集中的扫描源。另外还有一些非常值得关注的特征请求路径里带../../、select、waitfor、script的大概率是自动化扫描器在试探。把这些现象沉淀成Athena的常用查询模板下次排障会快非常多。4.4 一个SQL注入攻击的处置复盘有一次客户线上环境大量用户反馈“网页卡死”打开WAF的Sampled Requests发现某个源IP对商品搜索接口发起了大量带UNION SELECT的请求。我们的漏斗是这样转的WAF规则命中自动把这个IP加入了封禁列表用户侧立刻看到了block页面EventBridge触发Lambda自动把该IP写入WAF的IP Set并同时发通知给运维群GuardDuty这边显示同一次攻击中还有大量端口扫描行为Security Hub把发现合并成一条Critical事件我们通过CloudTrail检查该请求对应的API权限确认没有利用到数据库层业务无数据泄露。整个处置过程从发现到封禁大约3分钟没有人工介入。这个Playbook是我在Web场景里第一个做的也是收益最明显的。关键是事先把WAF规则、EventBridge、Lambda之间的链路测通别等攻击来了才临时写函数。5. APP场景落地API网关、身份池与客户端风控的消息闭环5.1 API Gateway 做唯一入口绑定WAF和限流APP场景和Web最大的区别在于流量不经过浏览器直接打到API。如果业务方把API直接暴露在公网安全组和传统WAF很难做细粒度的身份识别。所以我在APP场景里的核心思路是所有API必须统一走Amazon API Gateway然后让API Gateway绑定WAF和Usage Plan。API Gateway有几个安全相关的能力一定要开开启TLS强制禁用HTTP明文访问绑定WAF Web ACL特别是针对API路径的SQL注入、恶意IP封禁规则开启Usage Plan给每个App客户端一个限流配额防止单个用户把后端拖垮开启CloudWatch Logs记录每次请求的API key、来源IP、响应码。实际上很多所谓的“App安全事件”比如爆破登录、爬接口数据、薅羊毛都源于API没有统一网关直接暴露在公网。加了API Gateway这层“旋转门”之后至少你能知道谁在什么地方用什么身份频繁访问接口这是后续风控的基础。5.2 Cognito 身份池与最小权限 IAMAPP场景的身份体系我默认用Amazon Cognito。用户池负责注册、登录、找回密码身份池负责给登录后的用户颁发临时AWS凭证。这里的权限模型是关键Cognito不是一个万能保险箱如果身份池的IAM角色配得过大用户一旦逆向客户端拿到临时凭证就能调一大堆不该调的API。我见过最典型的问题Cognito身份池的Unauthenticated Role被分配了S3:*或DynamoDB:*权限导致未登录用户也能遍历整个存储桶。这个问题的根源不是Cognito而是开发者图省事把角色权限开成了通配符。正确的做法是所有Cognito角色都遵循最小权限只给业务需要的API动作用条件键aws:SourceIp限制Cognito临时凭证只能在APP使用的出口IP网段内生效定期用IAM Access Analyzer扫描身份池角色找出“未使用但已赋权”的策略对Cognito用户池开启Advanced Security Features它自带检测被撞库的凭证、异常登录并返回Block或者Challenge结果可以联动后续风控逻辑。5.3 用 Lambda Authorizer 做设备维度的风控如果只是账密登录Cognito够用。但APP场景里经常出现“同一个账号在几十台设备上同时登录”“一台设备短期注册了大量账号”这类要基于设备维度的风控需求。API Gateway的Lambda Authorizer很适合干这个事。思路是客户端请求时带上用户JWT和设备指纹Lambda Authorizer校验JWT合法之后再调用DynamoDB查这个设备指纹有没有被标记异常最后生成一个允许或拒绝的IAM Policy返回给API Gateway。整个过程对业务无感但每次请求都被“过了一道风控”。我给客户落地时设备指纹用了最简单的方案取设备型号、系统版本、IDFV等拼接后做哈希存进DynamoDB。后续如果某台设备指纹关联了3个以上账号定义为可疑设备下次请求直接Deny。这个方案用不到第三方风控SDK成本低且能挡住大部分撞库和批量注册。5.4 一次撞库攻击的自动封禁实战有一次客户APP上线大促运营数据没异常但Cognito的“登录失败次数”曲线突然陡增。我们在Lambda Authorizer里加了缓存逻辑并在WAF里针对/login这个路径加了一条Rate-based Rule比如5分钟内同一个IP超过30次登录请求就自动封禁24小时。因为撞库通常是用脚本更换大量账号所以短时间内的失败登录会非常密集。这个方案上线后第一次遭遇撞库时效果很有意思WAF封禁了几十个IP但攻击者很快换了一批IP继续打。后来我们又在Lambda Authorizer里增加逻辑把“同一个设备指纹更换超过5个账号”判定为异常直接拒绝。两层一起生效后攻击者的成本就很高了因为他们必须同时换IP和换设备指纹才能继续试。这里要提醒一句光靠IP封禁在APP场景根本不够移动网络下IP经常被NAT攻击者换IP的代价极低。设备指纹才是APP场景比Web场景多出来的那一层防线。6. IoT场景落地设备身份、证书策略与失陷后的快速隔离6.1 先认清IoT的信任边界证书即身份IoT场景和Web/APP最大的区别在于设备不是人它没有账密也没有浏览器指纹。AWS IoT Core采用“证书即身份”的模型每台设备发一个X.509证书证书绑定固定的IoT Policy决定它能发布和订阅哪些Topic。这里的核心安全原则是一台设备只能做它该做的事。比如一台温湿度传感器它的策略应该只能发布device/001/telemetry这个Topic没有权限订阅控制指令更没有权限调用IoT Shadow的List或Delete接口。现实中很多团队图省事给同型号所有设备发同一个全权限策略结果一台设备被攻破后攻击者可以伪装成任意设备控制整个车间。我的IoT设备证书策略习惯在创建时就用模板生成每台设备的Topic路径都包含唯一Thing Name并在策略的Resource字段里限定{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [iot:Publish], Resource: arn:aws:iot:region:account:topic/device/${iot:ThingName}/telemetry }, { Effect: Deny, Action: iot:*, Resource: * } ] }这样即使证书泄露攻击者也只能模拟这台设备上报消息无法横向控制其他设备。6.2 Device Defender 定义设备行为基线IoT设备不像服务器可以随时打补丁很多设备固件一两年都不更新所以对“行为异常”的检测比对CVE漏洞的检测更重要。AWS IoT Device Defender就是干这个的它通过Security Profiles定义设备的行为基线比如设备每隔多久发一次消息消息频率不能超过某个阈值设备正常情况下只和哪些IP通信设备连接次数、断开次数是否有异常设备发送的payload大小是否符合业务预期。我给客户做过一个案例某工厂的设备每天早上8点到晚上10点正常上报数据夜间处于低功耗状态。Device Defender设置晚上10点后消息频率为0的基线某天凌晨3点突然出现连续消息Security Hub里立刻冒出一条高风险告警。后来排查发现设备被植入了一个脚本在偷偷尝试用设备证书连接外部地址。这种“低慢”型攻击Web层的扫描器根本看不见只有基于设备正常行为的基线检测才能捕捉到。IoT场景的安全运营核心不是防DDoS而是防仿冒和防被利用。6.3 设备被薅羊毛或中招后怎么隔离才干净设备失陷后处置动作必须能快速执行而且要“断得干净”。AWS IoT Core里我常用的隔离方案有三级禁用证书在IoT Core控制台或API把设备的证书状态从ACTIVE改成INACTIVE这是最快的方式几秒内设备就失去所有权限更新IoT Policy如果只是怀疑这台设备的某个功能被滥用可以把它的Policy临时收紧只保留下线通知类Topic的权限移除Thing与证书的映射关系这是最彻底的方案相当于注销设备身份即使证书还在也无法通过认证。利用EventBridge可以监听设备失陷告警比如Device Defender发现异常行为时自动触发Lambda调用UpdateCertificate把证书设为INACTIVE同时发通知给现场运维。这样从检测到隔离可以做到分钟级。6.4 一次异常心跳的排查过程某客户部署了一批共享单车锁设备每30秒上报一次GPS和电量。一个月后Device Defender告警说其中有台车的心跳频率变成了每2秒一次流量翻了15倍。我们一开始以为是设备固件bug后来用IoT Core的日志定位到该设备Topic出现了多个不正常的clientId而且这些连接使用的证书属于两台不同的设备。进一步追查发现攻击者通过网络攻击拿下了某台设备提取了证书然后在一个模拟器里伪造了大量连接想蹭运营商的流量套餐做跳板。处置时我们直接吊销了那台失陷设备的证书并给IoT Core加上“单证书最大并发连接数限制”把类似风险一次性堵住。IoT场景排查跟Web完全不同关键证据基本都在IoT Core的连接事件和消息记录里。所以这套体系的日志归集也要把IoT Core的CloudWatch Logs纳入进来不要只顾着传统Web日志。7. 运营闭环告警降噪、编排响应与成本控制7.1 告警分级不是每条告警都值得半夜爬起来体系跑起来之后最大的问题变成了告警疲劳。GuardDuty哪怕在静默网络里每天都会产生大量Low级别的发现如果不做分级处置运营人员很快就会麻木真正的严重告警反而没人理。我落地时的分级策略是Critical可能已经在被入侵比如UnauthorizedAccess:EC2/SSHBruteForce、CryptoCurrency:Runtime/BitcoinTool要求15分钟内响应High有明显恶意行为比如Recon:EC2/PortProbe、S3公开读策略变更要求2小时内核查Medium需要人工判断比如某个IAM用户在新设备登录、GuardDuty检测到可疑DNS请求要求24小时内核查Low进入周报汇总不实时打扰比如Config的某个合规项漂移。Security Hub里可以用自定义Insight来分组再把每个级别的发现对应到不同的SNS Topic。配合上一套PlaybookCritical级别的告警能做到自动处理真正需要人肉的告警只剩一小部分。7.2 三个可以照抄的Playbook自动化Playbook我建议先从三个最常见的场景做起足够覆盖80%的应急处置需求。第一个是“隔离异常EC2实例”。当GuardDuty发现某台实例正在对外扫描或连接矿池Lambda会把实例的Security Group替换为隔离组并停止它绑定的EIP同时给运维群发消息。注意隔离组一定要定义成“拒绝所有入站和出站”的安全组否则隔离不彻底。第二个是“吊销泄露的IAM凭证”。CloudTrail如果发现某个AccessKey从陌生IP段调用API并且该Key有高权限策略EventBridge触发Lambda调用DeleteAccessKey并禁用对应的IAM用户登录。这个动作很激进所以我在Lambda里加了条件只处理从未在历史中见过的IP来源并且在执行前发一条等待审批的企微消息。第三个是“封禁恶意IP”。这个是WAF场景最常用的把GuardDuty或WAF发现的恶意IP自动写入某个WAF IP Set全局封禁24小时。注意设置IP Set的过期清理机制可以用EventBridge定时触发Lambda把超过24小时的IP条目移除避免误伤正常用户。7.3 成本控制经验ASG归零不等于不扣费很多人建安全体系时忽略了成本结果月度账单比预期高出两三倍。这里我想重点说一个热搜问题ASG的desired设为0以后还会扣费吗答案是要分两部分看。desired为0之后Auto Scaling会终止所有由它管理的EC2实例实例本身的计算费用确实停了。但如果没有同时处理下面这些资源账单还是会继续走实例绑定的弹性公网IP只要是“已分配但未绑定实例”的状态按小时收费NAT网关按小时和流量计费跟EC2是否运行无关负载均衡器ALB/NLB也是按小时计费实例停了它还在跑EBS快照按存储空间收费而且快照不支持增量覆盖删除实例不代表快照被清CloudTrail和Config的记录和规则评估也有费用尤其配置了数据事件后日志量很大。所以我的习惯是在安全运营的成本控制里加一条“基建清单”自动化每天定时检查是否有未关联的EIP、闲置的NAT网关、以及超过30天的EBS快照发现就直接发告警到成本群。安全体系不能成为账单炸弹否则老板第二天就让你拆了它。7.4 我日常的巡检习惯最后分享几个我一直在用的日常巡检动作算是这套体系的“保养指南”。每天早上的第一件事我只看Security Hub的Critical和High发现数量超过5条才会翻细节。重点看那些带有CryptoCurrency或UnauthorizedAccess关键词的告警这两个类型一出现基本是正在进行的入侵。每周会做一次Config的合规快照导出看看哪些资源漂移了比如有人手动改掉了安全组或者删除了CloudTrail的Bucket Policy。绝大多数的配置漂移其实是开发自己图方便但必须及时纠正不然安全基线形同虚设。每月用Athena跑一遍CloudTrail日志梳理出所有root用户和长期AccessKey的使用情况把超过90天没使用的key直接轮换。这个动作能明确定期清理“永久凭证”是防止下次出现access key泄露最有效的一招。这套体系完整跑下来之后我最深的体感是安全运营不是买工具而是把“检测、通知、响应、修复、复盘”每个环节都用AWS原生的Lambda和EventBridge串起来让工具之间自动协作而不是让运维的同事每天给工具当搬运工。你也不需要一次把所有场景全部建成先打通一条最核心的闭环再逐步扩展到Web/APP/IoT全场景完全来得及。
