ADDF 安全设置和操作

自动驾驶数据框架（ADDF）应被视为一款自定义的软件，需要组织中专门的 DevOps 和安全团队持续维护和管理。本节介绍了与安全相关的常见任务，这些任务可帮助您在 ADDF 的整个生命周期中设置和操作 ADDF。

本节包含以下任务：

• 定义您的 ADDF 架构

• 初始设置

• 自定义 ADDF 部署框架代码

• 在 ADDF 中编写自定义模块

• 重复部署 ADDF

• 重复进行安全审计

• ADDF 更新

• 停用

定义您的 ADDF 架构

ADDF 实例的安全性取决于其部署的 AWS 账户 环境。这个 AWS 账户 环境的设计必须满足特定用例的安全和操作需求。例如，在概念验证（PoC）环境中设置 ADDF 实例的安全和操作相关任务和注意事项与在生产环境中设置 ADDF 的任务和注意事项不同。

在 PoC 环境中运行 ADDF

如果您要在 PoC 环境中使用 ADDF，我们建议您为 ADDF 创建一个不包含任何其他工作负载的专用 AWS 账户 环境。这有助于在您探索 ADDF 及其功能时确保您的账户安全。这种方法的优点如下： 

• 如果出现严重的 ADDF 配置错误，不会对其他工作负载产生不利影响。

• 不存在任何其他可能对 ADDF 设置产生不利影响的工作负载配置错误的风险。

即使对于 PoC 环境，我们仍然建议您尽可能遵循 在生产环境中运行 ADDF 中列出的最佳实践。

在生产环境中运行 ADDF

如果您要在企业生产环境中使用 ADDF，我们强烈建议您考虑组织的安全最佳实践，并相应地实施 ADDF。除了组织的安全最佳实践外，我们还建议您实施以下措施：

• 组建一支长期、专注的 ADDF DevOps 团队 - ADDF 应被视为一款自定义的软件。它需要一个专门的 DevOps 团队持续维护和管理。在开始在生产环境中运行 ADDF 之前，应确定一个具有足够规模和能力的 DevOps 团队，并投入全部资源，直到 ADDF 部署的生命周期结束。

• 使用多账户架构 - 每个 ADDF 实例都应部署在自己专用的 AWS 多账户环境中，没有任何其他不相关的工作负载。正如 AWS 账户管理和分离（AWS Well-Architected Framework）中所定义的那样，最佳做法是根据组织的要求将资源和工作负载分成多个 AWS 账户。这是因为 AWS 账户 充当隔离边界。与单账户架构相比，设计合理的 AWS 多账户架构可提供工作负载分类，在发生安全漏洞时减小影响范围。使用多账户架构还有助于您的账户保持在 AWS 服务 限额内。根据组织的安全和职责分离要求，将您的 ADDF 模块分发到多个 AWS 账户 中。

• 部署多个 ADDF 实例 - 根据需要设置任意数量的单独 ADDF 实例，以便根据组织的软件开发流程正确开发、测试和部署 ADDF 模块。在设置多个 ADDF 实例时，可使用以下方法之一：

  • 不同 AWS 多账户环境中的多个 ADDF 实例 - 您可以使用单独的 AWS 账户 来隔离不同的 ADDF 实例。例如，如果您的组织有专门的开发、测试和生产阶段，则可以为每个阶段创建单独的 ADDF 实例和专用账户。这样做有很多好处，比如降低错误跨阶段传播的风险，帮助您实施审批流程，以及限制用户只能访问某些环境。下图显示了在单独的多账户环境中部署的两个 ADDF 实例。

    

  • 同一 AWS 多账户环境中的多个 ADDF 实例 – 您可以创建共享同一 AWS 多账户环境的多个 ADDF 实例。这实际上是在同一 AWS 账户 中创建独立的分支。例如，如果不同的开发人员并行工作，则开发人员可以在同一 AWS 账户 中创建专用的 ADDF 实例。这有助于开发人员在独立的分支中进行开发和测试。如果使用这种方法，对于每个 ADDF 实例，ADDF 资源必须具有唯一的资源名称。默认情况下，ADDF 预提供的模块支持此功能。只要不超过 AWS 服务 限额，就可以使用这种方法。下图显示了在共享的多账户环境中部署的两个 ADDF 实例。

    

  • 同一 AWS 单账户环境中的多个 ADDF 实例 – 此架构与前面的示例非常相似。不同之处在于，多个 ADDF 实例部署在单账户环境中，而不是多账户环境中。此架构适合非常简单的 ADDF 用例，这些用例的范围非常有限，而且多个开发人员同时在不同的分支上工作。

    

  由于 SeedFarmer 是控制 ADDF 实例部署的单一工具，因此您可以构建适合贵组织部署策略和 CI/CD 流程的任何环境和账户架构。

• 根据组织的安全要求自定义 AWS Cloud Development Kit (AWS CDK) 引导过程 – 默认情况下，AWS CDK 在引导过程中分配 AdministratorAccess AWS 托管策略。此策略授予完全管理权限。如果此策略对于贵组织的安全要求而言过于宽松，您可以自定义应用哪些策略。有关更多信息，请参阅 AWS CDK 部署角色的自定义最低权限策略。

• 在 IAM 中设置访问权限时遵循最佳实践 – 建立结构化 AWS Identity and Access Management（IAM）访问解决方案，允许您的用户访问 ADDF AWS 账户。ADDF 框架的设计遵循最低权限原则。您的 IAM 访问模式还应遵循最低权限原则，应符合贵组织的要求，并遵守 IAM 安全最佳实践（IAM 文档）。

• 根据组织的最佳实践设置网络 - ADDF 包含一个可选的网络 AWS CloudFormation 堆栈，用于创建基本的公有或私有虚拟私有云（VPC）。根据组织的配置，此 VPC 可能会将资源直接公开到互联网。我们建议您遵循组织的最佳网络实践，创建一个自定义的安全加固网络模块。

• 在 AWS 账户 级别上部署安全预防、检测和缓解措施 - AWS 提供各种安全服务，如 Amazon GuardDuty、AWS Security Hub、Amazon Detective 和 AWS Config。在 ADDF AWS 账户 中启用这些服务，并集成组织的安全预防、检测、缓解和事件处理流程。我们建议您遵循安全、身份和合规性最佳实践（AWS 架构中心）以及该服务文档中包含的任何特定于服务的建议。有关更多信息，请参阅 AWS 安全性文档。

ADDF 未涉及这些主题，因为实施和配置细节在很大程度上取决于贵组织的具体要求和流程。这些主题主要由贵组织负责阐述。通常，管理 AWS 登录区的团队会帮助您规划和实施 ADDF 环境。

初始设置

根据 ADDF 部署指南（GitHub）设置 ADDF。任何部署的起点都是自动驾驶数据框架 Git Hub 存储库中的 /manifest 文件夹。/manifest/example-dev 文件夹包含一个用于演示的示例部署。以本示例为起点，设计您自己的部署。在该目录中，有一个名为 deployment.yaml 的 ADDF 部署清单文件。它包含 SeedFarmer 在 AWS Cloud 中管理、部署或删除 ADDF 及其资源的所有信息。您可以在专用文件中创建 ADDF 模块组。core-modules.yaml 是核心模块组的一个示例，它包含 ADDF 提供的所有核心模块。总之，deployment.yaml 文件包含对将部署到其目标账户的组和模块的所有引用，并指定部署顺序。

为了实现安全和合规的配置，尤其是在非概念验证环境中，我们建议您查看要部署的每个模块的源代码。根据安全加固最佳实践，您应该只部署预期用例所需的模块。

注意

modules/demo-only/ 文件夹中的 ADDF 模块未经过安全加固，不应部署在生产环境或任何包含敏感或受保护数据的环境中。包含这些模块是为了展示系统功能，您可以将它们作为创建自己的自定义安全加固模块的基础。

自定义 ADDF 部署框架代码

ADDF 部署框架及其编排和部署逻辑可以完全自定义，以满足任何要求。但是，出于以下原因，我们建议您不要自定义或尽量减少更改：

• 保持上游兼容性 - 上游兼容性使更新 ADDF 以获取最新功能和安全更新变得更容易。更改框架会破坏与 SeedFarmer、CodeSeeder 和任何 ADDF 核心模块的原生向后兼容性。

• 安全后果 - 更改 ADDF 部署框架可能是一项复杂的任务，会带来意想不到的安全后果。在最坏的情况下，框架更改可能会产生安全漏洞。

在可能的情况下，构建和自定义自己的模块代码，而不是修改 ADDF 部署框架和 ADDF 核心模块代码。

注意

如果您认为 ADDF 部署框架的特定部分需要改进或进一步加强安全性，请通过拉取请求将您的更改提交到 ADDF 存储库。有关更多信息，请参阅 开源安全审查和贡献。

在 ADDF 中编写自定义模块

创建新的 ADDF 模块或扩展现有模块是 ADDF 的核心概念。在创建或自定义模块时，我们建议您遵循一般 AWS 安全最佳实践和组织的安全编码最佳实践。此外，我们建议您根据组织的安全要求进行初步和定期的内部或外部技术安全审查，以进一步降低出现安全问题的风险。

重复部署 ADDF

按照 ADDF 部署指南（GitHub）中的说明部署 ADDF 及其模块。为了支持在目标账户中添加、更新或移除资源的重复 ADDF 部署，SeedFarmer 使用存储在工具链和目标账户 Parameter Store 中的 MD5 哈希值，将当前部署的基础设施与本地代码库清单文件中定义的基础设施进行比较。

这种方法遵循了 GitOps 范式，其中您的源存储库（操作 SeedFarmer 的本地代码库）是可信来源，而明确声明的基础设施是您的部署的预期结果。有关 GitOps 的更多信息，请参阅什么是 GitOps（GitLab 网站）。

重复进行安全审计

像组织中的任何其他软件一样，将 ADDF 和自定义 ADDF 模块代码集成到安全风险管理、安全审查和安全审计周期中。

ADDF 更新

作为其持续开发工作的一部分，ADDF会定期收到更新。这包括功能更新以及与安全相关的改进和修复。我们建议您定期检查新的框架版本，并及时应用更新。有关更多信息，请参阅更新 ADDF 的步骤（ADDF 文档）。

停用

如果不再需要 ADDF，从您的 AWS 账户 中删除 ADDF 及其所有相关资源。任何无人值守和未使用的基础设施都会产生不必要的成本，带来潜在的安全风险。有关更多信息，请参阅销毁 ADDF 的步骤（ADDF 文档）。