本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
ADDF 内置安全功能
自动驾驶数据框架（ADDF）具有各种内置安全功能。默认情况下，这些功能旨在帮助您建立安全框架，并帮助贵组织满足常见的企业安全要求。
以下是内置安全功能：
ADDF 模块代码的最低权限
最低权限是授予执行任务所需的最低权限的安全最佳实践。有关更多信息，请参阅应用最低权限许可。ADDF 提供的模块在其代码和部署的资源中严格遵循最低权限原则，如下所示：
-
为 ADDF 模块生成的所有 AWS Identity and Access Management（IAM）policy 都具有用例所需的最低权限。
-
AWS 服务 是根据最低权限原则配置和部署的。ADDF 提供的模块仅使用特定用例所需的服务和服务功能。
基础设施即代码
ADDF 作为一个框架，用于将 ADDF 模块部署为基础设施即代码（IaC）。IaC 消除了手动部署过程，有助于防止手动过程可能导致的错误和配置错误。
ADDF 旨在使用任何常见的 IaC 框架来编排和部署模块。这包括但不限于：
您可以使用不同的 IaC 框架来编写不同的模块，然后使用 ADDF 来部署它们。
ADDF 模块使用的默认 IaC 框架是 AWS CDK。AWS CDK 是一种面向对象的高级抽象，可以用它来强制性定义 AWS 资源。默认情况下，AWS CDK 已针对各种服务和场景强制执行安全最佳实践。使用 AWS CDK 降低了安全配置错误的风险。
IaC 自动安全检查
开源 cdk-nag
AWS CDK 部署角色的自定义最低权限策略
ADDF 广泛使用 AWS CDK v2。您需要将所有 ADDF AWS 账户 引导至 AWS CDK。有关更多信息，请参阅引导程序（AWS CDK 文档）。
默认情况下，AWS CDK 将宽松的 AdministratorAccess AWS 管理策略分配给在引导账户中创建的 AWS CDK 部署角色。该角色的完整名称是 cdk-[CDK_QUALIFIER]-cfn-exec-role-[AWS_ACCOUNT_ID]-[REGION]。AWS CDK 使用该角色将资源部署到引导的 AWS 账户 中，作为 AWS CDK 部署过程的一部分。
根据贵组织的安全需求，AdministratorAccess 策略可能过于宽松。作为 AWS CDK 引导过程的一部分，您可以根据需要自定义策略和权限。您可以使用 --cloudformation-execution-policies 参数通过新定义的策略重新引导账户，来更改策略。有关更多信息，请参阅自定义引导程序（AWS CDK 文档）。
注意
此安全功能并非 ADDF 所特有，但在本节中列出它是因为其可以提高 ADDF 部署的整体安全性。
模块部署规范文件的最低权限策略
每个模块都包含一个名为 deployspec.yaml 的部署规范文件。该文件定义了模块的部署说明。CodeSeeder 通过 AWS CodeBuild 用它在目标账户中部署定义的模块。CodeSeeder 按照部署规范文件中的说明，为 CodeBuild 分配一个默认服务角色来部署资源。该服务角色是根据最低权限原则设计的。它包括部署 AWS CDK 应用程序所需的所有权限，因为所有 ADDF 提供的模块都是作为 AWS CDK 应用程序创建的。
但是，如果需要在 AWS CDK 外部运行任何 stage 命令，则需要创建自定义 IAM policy，而非使用 CodeBuild 的默认服务角色。例如，如果您使用的是 AWS CDK 以外的 IaC 部署框架（如 Terraform），则需要创建一个 IAM policy，为特定框架运行授予足够的权限。另一个需要专用 IAM policy 的场景是，在 install、pre_build、build 或 post_build stage 命令中包含对其他 AWS 服务 的直接 AWS Command Line Interface（AWS CLI）调用时。例如，如果您的模块包含用于将文件上传到 S3 存储桶的 Amazon Simple Storage Service（Amazon S3）命令，则需要自定义策略。自定义 IAM policy 为 AWS CDK 部署以外的任何 AWS 命令提供精细控制。有关自定义 IAM policy 的示例，请参阅 ModuleStack
数据加密
ADDF 会存储和处理潜在的敏感数据。为了保护这些数据，SeedFarmer、CodeSeeder 和 ADDF 提供的模块会对所有使用的 AWS 服务 进行静态数据和传输中数据加密（除非 demo-only 文件夹中的模块另有明确说明）。
使用 Secrets Manager 存储凭证
ADDF 会处理不同服务的各种密钥，例如 Docker Hub、JupyterHub 和 Amazon Redshift。ADDF 使用 AWS Secrets Manager 存储任何 ADDF 相关的密钥。这可以帮助您从源代码中删除敏感数据。
Secrets Manager 密钥仅存储在目标账户中，以满足该账户正常运行的需要。默认情况下，工具链账户不包含任何密钥。
SeedFarmer 和 CodeSeeder 的安全审查
SeedFarmer
针对 CodeSeeder AWS CodeBuild 角色的权限边界支持
IAM 权限边界是一种常见的安全机制，它定义了基于身份的策略可授予 IAM 实体的最大权限。SeedFarmer 和 CodeSeeder 支持每个目标账户的 IAM 权限边界附件。当 CodeSeeder 部署模块时，权限边界会限制 CodeBuild 使用的任何服务角色的最大权限。IAM 权限边界必须由安全团队在 ADDF 外部创建。IAM 权限边界策略附件作为 ADDF 部署清单文件 deployment.yaml 中的一个属性被接受。有关更多信息，请参阅 权限边界支持
工作流程如下所示：
-
您的安全团队根据您的安全需求定义和创建 IAM 权限边界。IAM 权限边界必须在每个 ADDF AWS 账户 中单独创建 输出是权限边界策略 Amazon 资源名称（ARN）列表。
-
安全团队与您的 ADDF 开发团队共享策略 ARN 列表。
-
ADDF 开发人员团队将策略 ARN 列表集成到清单文件中。有关此集成的示例，请参阅 sample-permissionboundary.yaml
（GitHub）和部署清单 （SeedFarmer 文档）。 -
成功部署后，权限边界将附加到 CodeBuild 用于部署模块的所有服务角色。
-
安全团队会根据需要监控是否应用权限边界。
AWS 多账户架构
正如 AWS Well-Architected Framework 的安全支柱中所定义的那样，最佳做法是根据组织的需求将资源和工作负载分成多个 AWS 账户。这是因为 AWS 账户 充当隔离边界。有关更多信息，请参阅 AWS 账户 管理和分离。这一概念的实现称为多账户架构。与单账户架构相比，设计合理的 AWS 多账户架构可提供工作负载分类，在发生安全漏洞时减小影响范围。
ADDF 原生支持 AWS 多账户架构。您可以根据组织的安全和职责分离要求，将您的 ADDF 模块分发到多个 AWS 账户 中。您可以将 ADDF 部署到单个 AWS 账户，并结合工具链和目标账户功能。或者，您可以为 ADDF 模块或模块组创建单独的目标账户。
您需要考虑的唯一限制是，ADDF 模块代表每个 AWS 账户 的最小部署单元。
对于生产环境，建议您使用由一个工具链账户和至少一个目标账户组成的多账户架构。有关更多信息，请参阅 ADDF 架构。
多账户部署的最低权限许可
如果您使用多账户架构，SeedFarmer 需要访问目标账户才能执行以下三个操作：
-
将 ADDF 模块元数据写入工具链账户和目标账户。
-
从工具链账户和目标账户读取当前的 ADDF 模块元数据。
-
在目标账户中启动 AWS CodeBuild 作业，以便部署或更新模块。
下图显示了跨账户关系，包括承担特定于 ADDF 的 AWS Identity and Access Management（IAM）角色的操作。
这些跨账户操作是使用明确定义的 assume-role 操作实现的。
-
ADDF 工具链 IAM 角色部署在工具链账户中。SeedFarmer 承担了这一角色。该角色具有执行
iam:AssumeRole操作的权限，并且可以在每个目标账户中承担 ADDF 部署 IAM 角色。此外，ADDF 工具链 IAM 角色还可以执行本地 AWS Systems Manager Parameter Store 操作。 -
ADDF 部署 IAM 角色部署在每个目标账户中。只能使用 ADDF 工具链 IAM 角色从工具链账户承担此角色。该角色拥有运行本地 AWS Systems Manager Parameter Store 操作的权限，以及通过 CodeSeeder 运行启动和描述 CodeBuild 作业的 AWS CodeBuild 操作的权限。
这些特定于 ADDF 的 IAM 角色是作为 ADDF 引导过程的一部分创建的。有关更多信息，请参阅 ADDF 部署指南
所有跨账户权限都是根据最低权限原则设置的。如果一个目标账户遭到入侵，对另一个 ADDF AWS 账户 的影响很小或没有影响。
对于 ADDF 的单账户架构，角色关系保持不变。只是折叠成一个 AWS 账户。
