SEC04-BP04 启动对不合规资源的修复
您的检测性控制措施可能会对不符合配置要求的资源发出警报。您可以手动或自动启动以编程方式定义的修复措施，用于修复这些资源并尽可能减少潜在影响。通过以编程方式定义的修复措施，您可以迅速采取一致的行动。
虽然利用自动化功能可以增强安全修复操作，但您应谨慎地实施和管理自动化功能。 您需要建立适当的监督和控制机制，确保自动化响应有效、准确且符合组织的策略和风险偏好。
期望结果：您定义了资源配置标准，以及在检测到资源不合规情况时应采取的修复措施。您尽可能以编程方式定义修复措施，以便手动或者自动启动这些措施。实施了检测系统，用于识别不合规的资源，并将警报发布到由您的安全人员监控的集中式工具。这些工具支持手动或自动运行您的程序化修复措施。采取了相应的监督和控制机制来管控自动修复措施的使用。
常见反面模式：
-
您实施了自动化功能，但没有全面测试和验证修复措施。这可能会导致意外的后果，例如中断合法的业务运营或导致系统不稳定。
-
您利用自动化功能来改善响应时间和流程，但没有采取适当的监控和机制，以便在需要时进行人工干预和判断。
-
您完全依赖修复措施，而不是将修复措施作为一部分，融入到更全面的事件响应和恢复计划中。
建立此最佳实践的好处：面对错误配置，自动修复的响应速度比手动流程更快，这让您可以尽量减少潜在的业务影响，并减少出现意外使用情况的机会。 以编程方式定义修复措施后，可以始终如一地应用这些措施，从而降低人为错误的风险。自动化功能还可以同时处理更大量的警报，这在大规模运行的环境中尤其重要。
在未建立这种最佳实践的情况下暴露的风险等级：中等
实施指导
如 SEC01-BP03 识别并验证控制目标中所述，AWS Config
一些不合规资源的情况会非常独特，需要人工判断才能修复，不过其它情况可以采取以编程方式定义的标准响应。例如，对于 VPC 安全组的配置错误，标准响应可以是删除不允许的规则并通知负责人。您可以在 AWS Lambda
在定义了所需的修复措施之后，您就可以确定启动修复措施的首选方式。AWS Config 可以为您启动修复。如果您使用 Security Hub，则可以通过自定义操作来执行这个过程，自定义操作会将调查发现信息发布到 Amazon EventBridge
对于程序化的修复措施，我们建议您全面记录所采取的行动及其结果，并进行审计。 查看和分析这些日志，以评测自动化流程的有效性，并确定需要改进的地方。将 Amazon CloudWatch Logs 中的日志和修复结果作为调查发现备注收集到 Security Hub 中。
首先，您可以考虑 AWS 上的自动化安全响应
实施步骤
-
分析警报并确定其优先级。
-
将来自各种 AWS 服务的安全警报整合到 Security Hub 中，以便在集中位置进行查看、划分优先级和执行修复措施。
-
-
制定修复措施。
-
使用 Systems Manager 和 AWS Lambda 等服务来运行程序化的修复措施。
-
-
配置启动修复的方式。
-
使用 Systems Manager，定义将调查发现发布到 EventBridge 的自定义操作。将这些操作配置为手动或自动启动。
-
如果需要，您还可以使用 Amazon Simple Notification Service（SNS）
向相应的利益相关者（例如安全团队或事件响应团队）发送通知和警报，以便进行手动干预或上报。
-
-
查看和分析修复日志，了解有效性并发现改进的机会。
-
将日志输出发送到 CloudWatch Logs。在 Security Hub 中将结果收集为调查发现备注。
-
资源
相关最佳实践：
相关文档：
相关示例：
相关工具：
