本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
ADDF 内置安全功能
自动驾驶数据框架（ADDF）具有各种内置安全功能。默认情况下，这些功能旨在帮助您建立安全框架，并帮助贵组织满足常见的企业安全要求。
以下是内置安全功能：
ADDF 模块代码的最低权限
最低权限是授予执行任务所需的最低权限的安全最佳实践。有关更多信息，请参阅 Apply least-privilege permissions。ADDF 提供的模块在其代码和部署的资源中严格遵循最低权限原则，如下所示：
-
为 ADDF 模块生成的所有 AWS Identity and Access Management (IAM) 策略都具有该用例所需的最低权限。
-
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有关更多信息，请参阅 Bootstrapping（AWS CDK 文档）。
默认情况下，将许可AdministratorAccess AWS 托管策略 AWS CDK 分配给在引导账户中创建的 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，则需要创建自定义 IAM 策略，而不是使用默认的服务角色 CodeBuild。例如，如果您使用的是 IaC 部署框架以外的 IaC 部署框架 AWS CDK，例如 Terraform，则需要创建一个 IAM 策略，为该特定框架提供足够的权限才能正常运行。另一种需要专用 IAM 策略的场景是，在install、pre_buildbuild、或post_build暂存命令 AWS 服务 中包含对其他人的直接 AWS Command Line Interface (AWS CLI) 调用。例如，如果您的模块包含用于将文件上传到 S3 存储桶的 Amazon Simple Storage Service（Amazon S3）命令，则需要自定义策略。自定义 IAM 策略为部署之外的任何 AWS 命令提供精细控制。 AWS CDK 有关自定义 IAM 策略的示例，请参阅 ModuleStack
数据加密
ADDF 会存储和处理潜在的敏感数据。为了帮助保护这些数据， SeedFarmer CodeSeeder、和 AddF 提供的模块会对所有使用的静态和传输中的数据进行加密 AWS 服务 （除非demo-only文件夹中的模块另有明确说明）。
使用 Secrets Manager 存储凭证
ADDF 处理不同服务的各种机密，例如 Docker Hub 和 Amazon Red JupyterHub sh ift。ADDF 使用 AWS Secrets Manager 存储任何 ADDF 相关的密钥。这可以帮助您从源代码中删除敏感数据。
Secrets Manager 密钥仅存储在目标账户中，以满足该账户正常运行的需要。默认情况下，工具链账户不包含任何密钥。
SeedFarmer 和的安全审查 CodeSeeder
SeedFarmer
对 AWS CodeBuild 角色的权限边界支持 CodeSeeder
IAM 权限边界是一种常见的安全机制，用于定义基于身份的策略可以向 IAM 实体授予的最大权限。 SeedFarmer 并 CodeSeeder 支持每个目标账户的 IAM 权限边界附件。权限边界限制了 CodeSeeder 部署模块 CodeBuild 时使用的任何服务角色的最大权限。IAM 权限边界必须由安全团队在 ADDF 外部创建。IAM 权限边界策略附件作为 ADDF 部署清单文件 deployment.yaml 中的一个属性被接受。有关更多信息，请参阅权限边界支持
工作流程如下所示：
-
您的安全团队根据您的安全需求定义和创建 IAM 权限边界。必须在每个 ADDF AWS 账户中单独创建 IAM 权限边界。输出是权限边界策略 Amazon 资源名称（ARN）列表。
-
安全团队与您的 ADDF 开发团队共享策略 ARN 列表。
-
ADDF 开发人员团队将策略 ARN 列表集成到清单文件中。有关此集成的示例，请参阅 sample-permissionboundary.yaml () 和部署清单（文档
）GitHub。 SeedFarmer -
成功部署后，权限边界将附加到 CodeBuild 用于部署模块的所有服务角色。
-
安全团队会根据需要监控是否应用权限边界。
AWS 多账户架构
正如Well-Architecte AWS d Framework的安全支柱所定义的那样，根据组织的要求将资源和工作负载分成 AWS 账户多个资源和工作负载被认为是最佳实践。这是因为 AWS 账户 充当隔离边界。有关更多信息，请参阅 AWS 账户 management and separation。这一概念的实现称为多账户架构。与单账户架构相比，设计合理的 AWS 多账户架构可提供工作负载分类，在发生安全漏洞时减小影响范围。
ADDF 原生支持 AWS 多账户架构。为了组织的安全和 separation-of-duties要求，您可以根据需要将 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 参数存储操作。 -
ADDF 部署 IAM 角色部署在每个目标账户中。只能使用 ADDF 工具链 IAM 角色从工具链账户承担此角色。此角色有权运行本地 P AWS Systems Manager arameter Store AWS CodeBuild 操作，并有权运行启动和描述 CodeBuild 任务的操作 CodeSeeder。
这些特定于 ADDF 的 IAM 角色是作为 ADDF 引导过程的一部分创建的。有关更多信息，请参阅《ADDF 部署指南》 AWS 账户
所有跨账户权限都是根据最低权限原则设置的。如果一个目标账户遭到入侵，对另一个 ADDF AWS 账户的影响很小或没有影响。
对于 ADDF 的单账户架构，角色关系保持不变。只是折叠成一个 AWS 账户。
