优先处理攻击者真正能访问的 AWS 资源。
OpenWiz 计划把外部发现和 AWS 上下文关联起来，让一个公网服务成为可解释的暴露问题，而不是又一条孤立的云告警。
OpenWiz 仍在开发中。一次性支付的 $10 包含正式上线后的第一个月，不会立即开始自动续费。
先从公网看，再深入云端
AWS 资产清单并不等于暴露上下文。
一项资源可以存在于 AWS 中，却完全无法从公网访问；一个被遗忘的主机名也可能悄悄指向生产工作负载。暴露管理把两种视角结合起来：先从攻击者能看到的端点出发，识别拥有它的 AWS 资源，再利用云端上下文判断应该多快修复。
先发现公网路径，再给资源打优先级
计划中的工作流从根域名开始，跟随子域名和公网服务，并保留每项结果背后的网络证据。这样可以避免把所有 AWS 资源都当成同等暴露，也为团队提供一个可以人工验证的明确起点。
- 把域名和子域名映射到公网端点
- 记录可访问的服务和端口
- 区分外部证据与账户资产清单
把端点关联到 EC2 和资源归属
发现公网端点后，OpenWiz 计划把它匹配到背后的 AWS 计算资源和环境。Cloudflare 配置可以补齐 DNS 与代理上下文，帮助判断端点是直连、已代理、符合预期，还是早已被遗忘。
- 把公网端点关联到云资源 ID
- 展示环境和资源归属
- 把 Cloudflare DNS 与代理状态放在 AWS 资产旁边
按照关联影响排列修复顺序
有价值的输出不是一份完整资产导出，而是一份能解释为什么某个公网工作负载比另一个更重要的修复清单。可达性、生产环境和高影响关系可以被合并成一条问题，并附上资源负责人能验证的证据。
- 把关联信号合并成一条 Exposure Issue
- 解释优先级背后的理由
- 让首个 MVP 保持为一份简短可执行的清单
为谁设计
规模不大，但仍然需要上下文的 AWS 环境
创始套餐覆盖 1 个根域名和最多 100 个计算实例，有意面向创业公司和小型基础设施团队。
- AWS 工作负载通过公网域名提供服务
- 云资源归属清楚，但外部可见性不清楚
- 团队需要优先级，而不是一次大型 CNAPP 上线
计划范围
只做暴露管理，不包装成所有 AWS 安全控制
首个 MVP 会始终聚焦公网暴露及其云端上下文。
- MVP 交付前没有可用的生产 AWS 连接器
- 不声称覆盖完整 AWS 合规、漏洞、数据或运行时防护
- 预订阶段不会收集 AWS 凭证
- 未来连接流程必须采用最小权限并获得明确授权
常见问题
AWS 暴露管理常见问题
OpenWiz 今天需要 AWS 凭证吗？
不需要。预订只收集付款邮箱、根域名和实例规模，不会要求云凭证。
如何计算实例数量？
创始版按云资源 ID 计算云计算实例，最多包含 100 个。
OpenWiz 会替代 AWS Security Hub 吗？
不会。计划中的 MVP 聚焦把公网暴露关联到 AWS 上下文，并不把自己描述成 AWS 原生安全服务的替代品。
帮助 OpenWiz 决定先做什么。
第一笔成功的真实预订会启动 30 天 MVP 交付周期。如果没有按期交付，全部创始预订款都会被主动全额退还。
预订创始版 — $10