AWS Inspector与AWS Config Rules的基础区别是什么

两个服务同属AWS安全合规类工具，但定位完全不重叠，核心差异可以从能力边界、运行逻辑、适用场景三个维度明确区分：

核心能力边界差异 #

• AWS Inspector
  定位是工作负载层的自动化漏洞扫描工具，扫描逻辑会深入到资源内部，不依赖AWS控制面的配置元数据：
  • 覆盖扫描对象：EC2实例操作系统的软件包CVE漏洞、不必要开放端口、恶意软件痕迹；ECR容器镜像的依赖漏洞、恶意文件；Lambda函数的代码漏洞、第三方依赖风险；还支持检测EC2实例内存储的敏感凭证泄露
  • 所有检测规则都围绕实际安全风险设计，比如检测是否存在Log4j等高危通用漏洞、SSH/RDP端口是否对公网全开放、实例是否安装了必要的安全代理
  • 扫描结果按风险严重等级（Critical/High/Medium/Low/Informational）分级，附带具体修复步骤
• AWS Config Rules
  定位是资源配置层的合规审计工具，仅基于AWS控制面记录的资源配置元数据做规则校验，不会访问资源内部：
  • 覆盖校验对象：几乎所有AWS资源类型，包括S3桶、IAM身份与策略、VPC网络配置、RDS数据库配置、CloudTrail审计日志配置、资源标签规范等
  • 所有校验规则围绕配置合规要求设计，比如检测S3桶是否开启公网访问阻止、RDS存储是否开启静态加密、IAM用户是否强制启用MFA、安全组是否允许0.0.0.0/0访问3389端口、生产资源是否按规范打标签
  • 校验结果只有合规/不合规/数据不足三类状态，会留存所有资源的配置变更全量历史，支持回溯任意时间点的资源配置状态

运行逻辑差异 #

• AWS Inspector
  • 触发方式：默认开启持续自动扫描，新EC2启动、新镜像推送到ECR、Lambda函数版本更新时会自动触发扫描，也支持手动按需发起扫描
  • 扫描依赖：扫描EC2实例需要实例上安装并运行SSM Agent，通过代理在实例内部执行检测逻辑
  • 响应能力：扫描发现的风险可以推送到EventBridge、Security Hub对接告警、工单流程，本身不内置自动修复能力
• AWS Config Rules
  • 触发方式：支持两种触发逻辑，一是配置变更触发——对应资源的配置发生修改时立刻执行规则校验；二是周期触发——按预设的固定时间间隔（比如1/3/6/12/24小时）执行全量资源校验
  • 运行依赖：不需要在资源内部安装任何代理，所有校验逻辑都在AWS控制面完成，只需要开启Config的资源配置记录功能即可
  • 响应能力：支持配置自动修复动作，比如检测到S3桶公网读开启时自动关闭公网权限、检测到未启用MFA的IAM用户时自动禁用其访问密钥，同时可以留存合规报告满足审计举证要求

计费逻辑差异 #

• AWS Inspector：按实际扫描的资源量计费，EC2按实例运行小时、ECR镜像按镜像大小、Lambda按扫描的函数数量收费，未被扫描的资源不产生费用
• AWS Config Rules：费用分为两部分，一是配置项记录费——按开启记录的资源配置项数量收取存储费用，和是否运行规则无关；二是规则评估费——每完成一次单资源的规则校验收取一次费用

选型参考 #

直接按业务需求选就行，两个服务不存在替代关系，绝大多数生产场景会搭配使用：

• 优先选AWS Inspector的场景：
  • 需要排查EC2、容器、Lambda内部的实际软件漏洞，比如应对突发高危CVE的全网排查
  • 需要评估工作负载的实际暴露面，检测实例内部的恶意软件、敏感凭证泄露风险
  • 不需要做合规举证，只需要发现运行层面的实际安全风险
• 优先选AWS Config Rules的场景：
  • 需要满足等保、PCI DSS、ISO27001等合规要求，留存资源配置审计证据、输出合规报告
  • 需要对资源配置做强制管控，违规配置出现时自动修复，避免人为配置错误导致的风险
  • 需要追溯资源配置变更历史，排查配置变更引发的故障或安全事件

搭配使用时可以把两个服务的检测结果统一汇总到AWS Security Hub做集中视图，避免多平台切换查看的成本。

内容的提问来源于stack exchange，提问作者crazy_stuff