本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# ADDF 安全设置和操作
<a name="secure-setup-and-operation"></a>

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

本节包含以下任务：
+ [定义您的 ADDF 架构](#defining-your-addf-architecture)
+ [初始 设置](#initial-setup)
+ [自定义 ADDF 部署框架代码](#customizing-the-addf-deployment-framework-code)
+ [在 ADDF 中编写自定义模块](#writing-custom-modules-in-addf)
+ [重复部署 ADDF](#reoccurring-addf-deployments)
+ [重复进行安全审计](#reoccurring-security-audits)
+ [ADDF 更新](#addf-updates)
+ [停用](#decommissioning)

## 定义您的 ADDF 架构
<a name="defining-your-addf-architecture"></a>

ADDF 实例的安全性取决于它所部署的 AWS 账户 环境。此 AWS 账户 环境的设计必须满足您的特定用例的安全和操作需求。例如，在 proof-of-concept (PoC) 环境中设置 ADDF 实例时与安全和操作相关的任务和注意事项与在生产环境中设置 ADDF 的任务和注意事项不同。

### 在 PoC 环境中运行 ADDF
<a name="running-addf-in-a-poc-environment"></a>

如果您打算在 PoC 环境中使用 ADDF，我们建议您创建一个不包含任何其他 AWS 账户 工作负载的 ADDF 专用。这有助于在您探索 ADDF 及其功能时确保您的账户安全。这种方法的优点如下： 
+ 如果出现严重的 ADDF 配置错误，不会对其他工作负载产生不利影响。
+ 不存在任何其他可能对 ADDF 设置产生不利影响的工作负载配置错误的风险。

即使对于 PoC 环境，我们仍然建议您尽可能遵循 [在生产环境中运行 ADDF](#running-addf-in-a-production-environment) 中列出的最佳实践。

### 在生产环境中运行 ADDF
<a name="running-addf-in-a-production-environment"></a>

如果您要在企业生产环境中使用 ADDF，我们强烈建议您考虑组织的安全最佳实践，并相应地实施 ADDF。除了组织的安全最佳实践外，我们还建议您实施以下措施：
+ **创建一支长期的、敬业的 ADDF DevOps 团队** ——ADDF 需要被视为一款定制软件。它需要由专门的 DevOps团队进行持续的维护和保养。在开始在生产环境中运行 ADDF 之前，应定义一 DevOps支具有足够规模和能力的团队，并投入全部资源，直到 ADDF 部署为止。 end-of-life
+ **使用多账户架构** - 每个 ADDF 实例都应部署在自己专用的 AWS 多账户环境中，没有任何其他不相关的工作负载。根据[AWS 客户管理和分离](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/aws-account-management-and-separation.html)（AWS Well-Architected Framework）中的定义，根据组织的要求将资源和工作负载分成 AWS 账户多个被认为是最佳实践。这是因为 AWS 账户 充当隔离边界。与单账户架构相比，设计合理的 AWS 多账户架构可提供工作负载分类，在发生安全漏洞时减小影响范围。使用多账户架构还有助于您的账户保持在 [AWS 服务 限额](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)内。根据需要分发 ADDF 模块，以满足组织的安全性和 separation-of-duties要求。 AWS 账户 
+ **部署多个 ADDF 实例** - 根据需要设置任意数量的单独 ADDF 实例，以便根据组织的软件开发流程正确开发、测试和部署 ADDF 模块。在设置多个 ADDF 实例时，可使用以下方法之一：
  + **不同多 AWS 账户环境中的多个 ADDF 实例** — 您可以单独使用 AWS 账户 来隔离不同的 ADDF 实例。例如，如果您的组织有专门的开发、测试和生产阶段，则可以为每个阶段创建单独的 ADDF 实例和专用账户。这样做有很多好处，比如降低错误跨阶段传播的风险，帮助您实施审批流程，以及限制用户只能访问某些环境。下图显示了在单独的多账户环境中部署的两个 ADDF 实例。  
![位于具有多账户架构的不同 AWS 环境中的两个 ADDF 实例](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/addf-security-and-operations/images/A_multi-addf-multi-account.png)
  + **同一多账户环境中的 AWS 多个 ADDF 实例-您可以创建共享相同多账户环境**的多个 ADDF 实例。 AWS 这实际上是在同一 AWS 账户中创建独立的分支。例如，如果不同的开发人员并行工作，则开发人员可以在同一 AWS 账户中创建专用的 ADDF 实例。这有助于开发人员在独立的分支中进行开发和测试。如果使用这种方法，对于每个 ADDF 实例，ADDF 资源必须具有唯一的资源名称。默认情况下，ADDF 预提供的模块支持此功能。只要不超过 [AWS 服务 限额](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)，就可以使用这种方法。下图显示了在共享的多账户环境中部署的两个 ADDF 实例。  
![在同一 AWS 多账户环境中部署两个 ADDF 实例。](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/addf-security-and-operations/images/C_multi-instance-multi-account-shared.png)
  + **同一 AWS 单账户环境中的多个 ADDF 实例** – 此架构与前面的示例非常相似。不同之处在于，多个 ADDF 实例部署在单账户环境中，而不是多账户环境中。此架构适合非常简单的 ADDF 用例，这些用例的范围非常有限，而且多个开发人员同时在不同的分支上工作。  
![在同一 AWS 单账户环境中部署两个 ADDF 实例。](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/addf-security-and-operations/images/B_multi-addf-single-account.png)

  由于 SeedFarmer 是控制 ADDF 实例部署的单一工具，因此您可以构建适合组织部署策略和 CI/CD 流程的任何环境和账户架构。
+ **根据组织的安全要求自定义 AWS Cloud Development Kit (AWS CDK) 引导流程**-默认情况下，在引导过程中 AWS CDK 分配[AdministratorAccess](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator) AWS 托管策略。此策略授予完全管理权限。如果此策略对于贵组织的安全要求而言过于宽松，您可以自定义应用哪些策略。有关更多信息，请参阅 [部署角色的自定义最低权限策略 AWS CDK](built-in-security-features.md#custom-least-privilege-policy-for-the-aws-cdk-deployment-role)。
+ **在 IAM 中设置访问权限时遵循最佳实践** — 建立允许用户访问 ADDF AWS 账户的结构化 AWS Identity and Access Management (IAM) 访问解决方案。ADDF 框架的设计遵循最低权限原则。您的 IAM 访问模式还应遵循最低权限原则，应符合贵组织的要求，并遵守 [IAM 安全最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)（IAM 文档）。
+ **根据组织的最佳实践设置网络** - ADDF 包含一个可选的网络 AWS CloudFormation 堆栈，用于创建基本的公有或私有虚拟私有云（VPC）。根据组织的配置，此 VPC 可能会将资源直接公开到互联网。我们建议您遵循组织的最佳网络实践，创建一个自定义的安全加固网络模块。
+ **在 AWS 账户 级别部署安全预防、检测和缓解措施** —— AWS 提供各种安全服务，例如 Amazon、 GuardDuty AWS Security Hub CSPM、Amazon Detective 和 AWS Config。在 ADDF 中启用这些服务， AWS 账户 并集成组织的安全预防、检测、缓解和事件处理流程。我们建议您遵循[安全、身份和合规性最佳实践](https://aws.amazon.com/architecture/security-identity-compliance/)（AWS 架构中心）以及该服务文档中包含的任何特定于服务的建议。有关更多信息，请参阅 [AWS Security Documentation](https://docs.aws.amazon.com/security/)。

ADDF 未涉及这些主题，因为实施和配置细节在很大程度上取决于贵组织的具体要求和流程。这些主题主要由贵组织负责阐述。通常，管理 [AWS 登录区](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/understanding-landing-zones.html)的团队会帮助您规划和实施 ADDF 环境。

## 初始 设置
<a name="initial-setup"></a>

根据 ADDF [部署指南 () GitHub 设置 ADDF](https://github.com/awslabs/autonomous-driving-data-framework/blob/main/docs/deployment_guide.md)。任何部署的起点都是 [autonomous-driving-data-framework](https://github.com/awslabs/autonomous-driving-data-framework)Git Hub 存储库中的`/manifest`文件夹。`/manifest/example-dev` 文件夹包含一个用于演示的示例部署。以本示例为起点，设计您自己的部署。在该目录中，有一个名为 **deployment.yaml** 的 ADDF 部署清单文件。它包含用于 SeedFarmer 管理、部署或删除 ADDF 及其资源的所有信息。 AWS Cloud您可以在专用文件中创建 ADDF 模块组。**core-modules.yaml** 是核心模块组的一个示例，它包含 ADDF 提供的所有核心模块。总之，**deployment.yaml** 文件包含对将部署到其目标账户的组和模块的所有引用，并指定部署顺序。

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

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

## 自定义 ADDF 部署框架代码
<a name="customizing-the-addf-deployment-framework-code"></a>

ADDF 部署框架及其编排和部署逻辑可以完全自定义，以满足任何要求。但是，出于以下原因，我们建议您不要自定义或尽量减少更改：
+ **保持上游兼容性** - 上游兼容性使更新 ADDF 以获取最新功能和安全更新变得更容易。更改框架会破坏与 SeedFarmer CodeSeeder、和任何 ADDF 核心模块的原生向后兼容性。
+ **安全后果** - 更改 ADDF 部署框架可能是一项复杂的任务，会带来意想不到的安全后果。在最坏的情况下，框架更改可能会产生安全漏洞。

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

**注意**  
如果您认为 ADDF 部署框架的特定部分需要改进或进一步加强安全性，请通过拉取请求将您的更改提交到 ADDF 存储库。有关更多信息，请参阅 [开源安全审查和贡献](addf-security-review-process.md#open-source-sec-reviews)。

## 在 ADDF 中编写自定义模块
<a name="writing-custom-modules-in-addf"></a>

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

## 重复部署 ADDF
<a name="reoccurring-addf-deployments"></a>

按照 ADDF 部署[指南 () GitHub 中所述部署 ADDF](https://github.com/awslabs/autonomous-driving-data-framework/blob/main/docs/deployment_guide.md) 及其模块。为了支持在目标账户中添加、更新或移除资源的重复进行 ADDF 部署，请 SeedFarmer 使用存储在工具链和目标账户的 Parameter Store 中的 MD5哈希值将当前部署的基础架构与本地代码库清单文件中定义的基础架构进行比较。

这种方法遵循的 GitOps 范式是，您的源存储库（您操作的本地代码库 SeedFarmer）是真实来源，而在其中明确声明的基础架构是部署的预期结果。有关的更多信息 GitOps，请参阅[什么是 GitOps](https://about.gitlab.com/topics/gitops/)（GitLab 网站）。

## 重复进行安全审计
<a name="reoccurring-security-audits"></a>

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

## ADDF 更新
<a name="addf-updates"></a>

作为其持续开发工作的一部分，ADDF会定期收到更新。这包括功能更新以及与安全相关的改进和修复。我们建议您定期检查新的框架版本，并及时应用更新。有关更多信息，请参阅 [Steps to update ADDF](https://github.com/awslabs/autonomous-driving-data-framework/blob/main/docs/deployment_guide.md#steps-to-update-addf-deployment-when-there-is-a-new-change-from-addf-team-if-a-new-release-is-published)（ADDF 文档）。

## 停用
<a name="decommissioning"></a>

如果不再需要 ADDF，从您的 AWS 账户中删除 ADDF 及其所有相关资源。任何无人值守和未使用的基础设施都会产生不必要的成本，带来潜在的安全风险。有关更多信息，请参阅 [Steps to destroy ADDF](https://github.com/awslabs/autonomous-driving-data-framework/blob/main/docs/deployment_guide.md#steps-to-destroy-addf)（ADDF 文档）。