攻击流量上升时，临时放行规则可能救急，也可能让异常请求绕过防护。制定攻击期间业务白名单制定和动态更新流程，重点不是尽可能多地放行，而是明确“哪些请求、因何放行、由谁批准、何时撤销”。以下方法适用于不同类型的线上业务，可按现有防火墙、负载均衡器、应用网关或主机访问控制能力调整。
先按业务影响划分，不按部门名称划分
白名单应对应可验证的业务功能，而不是笼统地把某个团队或整段网络列为可信。可先按中断后果分为三级：核心交易或身份验证等中断会直接阻断关键操作；重要查询、客户支持等短时降级仍有替代方式；非关键报表、批量导出等可在攻击期间限流或暂停。实际分级应由业务负责人和安全值班人员共同确认。
每项业务至少登记入口地址、协议与端口、必要的来源、调用身份、负责人、依赖服务、允许的请求类型，以及规则失效时间。来源如果是固定办公出口或已登记的合作方地址，可以考虑按 IP 限定；来源会随网络切换变化时，单靠 IP 白名单容易误拦，应优先核验账号、客户端证书或应用身份，并配合速率限制。不要因为一个接口需要放行，就把整台主机或整个网段设为可信。
把规则写到最小范围
规则应尽可能限定目标、来源和动作。例如，只允许指定合作系统访问某个 HTTPS 回调路径，并限制请求方法；不要直接放开所有端口或所有 URL。防火墙通常适合约束网络地址和端口，应用网关则更适合按路径、请求特征和身份设置条件。两层规则可以互相补充，但要记录实际生效位置，避免重复配置后难以判断误拦截来源。
维护攻击期间业务白名单制定和动态更新流程时，可以用一张变更记录表串起业务、技术和审批信息：规则编号、申请理由、影响范围、验证结果、批准人、执行时间和到期时间。所有时间注明时区；临时规则建议设置自动过期，具体时长根据攻击持续时间、值班能力和业务验证周期决定，不应永久保留。
动态更新：小步发布，边看边验证
- 核实需求。由业务负责人提供受影响功能、真实调用方和失败表现；运维人员对照网关日志、访问日志或身份认证记录核验来源。无法确认来源的请求，不因“可能是客户”就直接放行。
- 拟定最小规则。写清协议、目标、来源、身份或路径条件、速率上限和失效时间。若只能按 IP 控制，应确认地址归属和变更方式，并避免使用过宽的地址范围。
- 先在低风险范围验证。条件允许时先对单个实例、少量流量或指定测试身份启用，检查正常请求是否恢复、异常请求是否仍被拦截。没有灰度能力时，应选择低影响时段并安排即时回退。
- 观察关键指标。对比规则前后的允许与拒绝日志、错误率、请求速率、认证失败和资源使用情况。观察窗口应覆盖业务调用周期；周期较短的接口可更快判断，定时任务则要等到一次实际运行后再评估。
- 复核并续期或撤销。攻击特征、合作方地址或业务状态变化时重新验证，不把旧规则直接复制到新场景。规则到期前由负责人确认是否仍有必要。
回滚要能执行，而不只是写在预案里
每次变更前保存当前配置或可恢复版本，并记录规则差异。出现正常用户集中失败、核心操作错误率明显上升、误放流量增加，或负责人无法确认规则用途时，应立即停止继续扩展；先撤销最近一条变更，再验证业务与防护恢复情况。若撤销后影响仍在，应检查关联的路由、缓存或应用配置，不要连续叠加新白名单掩盖问题。
变更可采用双人复核：一人提出并说明业务依据，另一人核对范围、风险和回退方式。紧急情况下可按预先授权由值班人员执行，但事后补齐记录，并在交接时明确待复核规则。攻击结束后逐条清理临时放行项，确认无依赖后撤销；保留变更记录和误拦截、误放行原因，供下一次调整分级标准。
常见问题
白名单应优先按 IP 还是按身份设置？
来源地址稳定且可核实时，IP 限定简单直接；地址变化频繁时，身份、证书或应用层校验通常更可靠。条件允许时可组合使用。
业务负责人暂时联系不上，能否先放行？
仅按预案授权处理可明确验证的核心请求，并限制范围、设置短时到期和安排复核。来源及用途都不明确时，不应扩大放行范围。
攻击结束后是否保留常用规则？
只有经过长期需求确认、正式审批并纳入常规配置管理的规则才适合保留。为应急临时增加的规则应复核后撤销。
如何避免更新造成新的中断？
优先小范围验证，监控正常请求与异常流量，提前保存配置，并确保值班人员知道撤销哪条规则、在哪里操作。这样才能让攻击期间业务白名单制定和动态更新流程既能应急，也能安全收尾。
