翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ADDF にあらかじめ組み込まれたセキュリティ機能
Autonomous Driving Data Framework (ADDF) には、さまざまなセキュリティ機能が組み込まれています。通常、これらの機能は、安全なフレームワークを構築して、組織が企業向けの一般的なセキュリティ要件を満たせるように設計されています。
以下が、あらかじめ組み込まれているセキュリティ機能です。
+ [ADDF モジュールコードの最小特権](#least-privilege-for-addf-module-code)
+ [Infrastructure as Code](#infrastructure-as-code)
+ [IaC の自動セキュリティチェック](#automated-security-checks-for-iac)
+ [AWS CDK デプロイロールのカスタム最小特権ポリシー](#custom-least-privilege-policy-for-the-aws-cdk-deployment-role)
+ [モジュールの deployspec ファイルの最小特権ポリシー](#least-privilege-policy-for-the-module-deployspec-file)
+ [データ暗号化](#data-encryption)
+ [Secrets Manager を使用した認証情報ストレージ](#credential-storage-using-secrets-manager)
+ [SeedFarmer と CodeSeeder のセキュリティ検査](#security-reviews-of-seed-farmer-and-code-seeder)
+ [CodeSeeder の AWS CodeBuild ロールに対するアクセス許可の境界のサポート](#permissions-boundary-support-for-the-aws-codebuild-role-for-code-seeder)
+ [AWS マルチアカウントアーキテクチャ](#aws-multi-account-architecture)
+ [マルチアカウントデプロイの最小特権のアクセス許可](#least-privilege-permissions-for-multi-account-deployments)
## ADDF モジュールコードの最小特権
最小特権は、タスクを実行するために最低限必要な権限を付与する際の、セキュリティのベストプラクティスです。詳細については、「[最小特権アクセス許可を適用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)」を参照してください。ADDF が提供するモジュールは、コードとデプロイ済みのリソースにおける最小特権の原則に、以下のとおり厳密に従います。
+ ADDF モジュール用に生成されたすべての AWS Identity and Access Management (IAM) ポリシーには、ユースケースに必要な最小限のアクセス許可があります。
+ AWS のサービス は、最小特権の原則に従って設定およびデプロイされます。ADDF が提供するモジュールは、特定のユースケースに必要なサービスとサービスの機能のみを使用します。
## Infrastructure as Code
ADDF は、フレームワークとして、ADDF モジュールを Infrastructure as Code (IaC) としてデプロイするように設計されています。IaC は、手動のデプロイプロセスをなくし、手動のプロセスで起きやすいエラーや設定のミスを防止します。
ADDF は、一般的な IaC フレームワークを使ってモジュールをオーケストレーションし、デプロイするように設計されています。これには以下が含まれますが、これらに限定されません。
+ [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html)
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [Hashicorp Terraform](https://www.terraform.io/)
異なる IaC フレームワークを使用すると異なるモジュールを作成できます。次に、ADDF を使ってそれらをデプロイします。
ADDF モジュールで使用されるデフォルトの IaC フレームワークは です AWS CDK。 AWS CDK は、 AWS リソースを必須に定義するために使用できるオブジェクト指向の高レベルの抽象化です。 AWS CDK は、さまざまなサービスやシナリオに対して、デフォルトでセキュリティのベストプラクティスを適用しています。を使用すると AWS CDK、セキュリティの設定ミスのリスクが軽減されます。
## IaC の自動セキュリティチェック
ADDF には、オープンソースの [cdk-nag](https://github.com/cdklabs/cdk-nag/blob/main/README.md) ユーティリティ (GitHub) が組み込まれています。このユーティリティは、 に基づく ADDF モジュール AWS CDK が一般およびセキュリティのベストプラクティスに準拠しているかどうかを自動的にチェックします。cdk-nag ユーティリティは、ルールとルールパックを使用して、ベストプラクティスに違反しているコードを検出し、報告します。これらのルールと包括的なリストの詳細については、[cdk-nag rules](https://github.com/cdklabs/cdk-nag/blob/main/RULES.md#awssolutions) (GitHub) を参照してください。
## AWS CDK デプロイロールのカスタム最小特権ポリシー
ADDF は v2 AWS CDK を幅広く活用しています。すべての ADDF AWS アカウント をブートストラップする必要があります AWS CDK。詳細については「[Bootstrapping](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)」(AWS CDK ドキュメント) を参照してください。
デフォルトでは、 は、ブートストラップされたアカウントで作成された AWS CDK デプロイロールに、許可された [AdministratorAccess](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator) AWS 管理ポリシーを AWS CDK 割り当てます。このロールの完全な名前は です`cdk-[CDK_QUALIFIER]-cfn-exec-role-[AWS_ACCOUNT_ID]-[REGION]`。 はこのロール AWS CDK を使用して、デプロイプロセス AWS アカウント の一環としてブートストラップされた にリソースをデプロイします AWS CDK 。
組織のセキュリティ要件によっては、`AdministratorAccess` ポリシーの許容性が過剰になる場合があります。ポリシーとアクセス許可は、 AWS CDK ブートストラッププロセスの最中に必要に応じてカスタマイズできます。このポリシーは、`--cloudformation-execution-policies` パラメータを使って、ポリシーが新たに定義されたアカウントを再度ブートストラップすることで変更できます。詳細については、[「ブートストラップのカスタマイズ (ドキュメント)](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-customizing)」を参照してください。AWS CDK
**注記**
このセキュリティ機能は ADDF に固有の機能ではありませんが、ADDF のデプロイの全体的なセキュリティを高めることにつながるため、こちらのセクションに記載されています。
## モジュールの deployspec ファイルの最小特権ポリシー
各モジュールには、**deployspec.yaml** というデプロイ仕様のファイルが含まれています。このファイルは、モジュールのデプロイ手順を定義します。CodeSeeder はこれを使用して、 を使用して定義されたモジュールをターゲットアカウントにデプロイします AWS CodeBuild。CodeSeeder は、デプロイ仕様ファイルの指示に従ってデフォルトのサービスロールを CodeBuild に割り当てて、リソースをデプロイします。このサービスロールは最小特権の原則に従って設計されています。ADDF が提供するモジュールはすべて AWS CDK アプリケーションとして作成されるため、 AWS CDK アプリケーションのデプロイに必要なすべてのアクセス許可が含まれています。
ただし、 の外部でステージコマンドを実行する必要がある場合は AWS CDK、CodeBuild のデフォルトのサービスロールを使用する代わりに、カスタム IAM ポリシーを作成する必要があります。たとえば、Terraform AWS CDKなどの IaC デプロイフレームワーク以外の を使用している場合は、その特定のフレームワークが機能するための十分なアクセス許可を付与する IAM ポリシーを作成する必要があります。専用 IAM ポリシーを必要とするもう 1 つのシナリオは、、`install`、、`build`または `post_build`ステージコマンド AWS のサービス に他の への direct AWS Command Line Interface (AWS CLI) `pre_build`呼び出しを含める場合です。例えば、モジュールに、ファイルを S3 バケットにアップロードするための Amazon Simple Storage Service (Amazon S3) コマンドが含まれる場合、カスタムポリシーが必要です。カスタム IAM ポリシーは、 AWS CDK デプロイ外の AWS コマンドをきめ細かく制御します。ADDF モジュール用にカスタム IAM ポリシーを作成するときは、必ず最小特権のアクセス許可を適用します。
## データ暗号化
ADDF は、機密である可能性の高いデータを保存して処理します。このデータを保護するために、SeedFarmer、CodeSeeder、ADDF が提供するモジュールは、使用中のすべての保管中および転送中のデータを暗号化します AWS のサービス ( `demo-only`フォルダ内のモジュールに特に明記されていない限り）。
## Secrets Manager を使用した認証情報ストレージ
ADDFは、Docker Hub、JupyterHub、[Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/getting-started.html) など、さまざまなサービスのさまざまなシークレットを処理します。ADDF 関連のシークレットを保管するときは [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) を使用します。これによりユーザーは、機密データをソースコードから削除することができます。
Secrets Manager のシークレットは、ターゲットアカウントが正常に機能するために必要になるものであるため、ターゲットアカウントにのみ保管されます。ツールチェーンアカウントには、通常はいずれのシークレットも含まれません。
## SeedFarmer と CodeSeeder のセキュリティ検査
[SeedFarmer](https://github.com/awslabs/seed-farmer) と [CodeSeeder](https://github.com/awslabs/aws-codeseeder) (GitHub リポジトリ) は、ADDF とその ADDF モジュールをデプロイするときに使用します。これらのオープンソースプロジェクトは、「」で説明されているように、ADDF と同じ定期的な AWS 内部セキュリティレビュープロセスを実行します[ADDF のセキュリティ検査プロセス](addf-security-review-process.md)。
## CodeSeeder の AWS CodeBuild ロールに対するアクセス許可の境界のサポート
IAM のアクセス許可の境界は、ID ベースのポリシーが IAM エンティティに付与できるアクセス許可の上限を定義する、一般的なセキュリティメカニズムです。SeedFarmer と CodeSeeder は、各ターゲットアカウントの、IAM アクセス許可の境界のアタッチメントをサポートしています。アクセス許可の境界は、CodeSeeder がモジュールをデプロイする際に CodeBuild が使用する、サービスロールのアクセス許可の上限数を設定します。IAM のアクセス許可の境界は、セキュリティチームが ADDF の外部で作成する必要があります。IAM のアクセス許可の境界におけるポリシーのアタッチメントは、ADDF デプロイのマニフェストファイルである **deployment.yaml** で属性として受け取られます。詳細については、[「アクセス許可の境界](https://seed-farmer.readthedocs.io/en/latest/concepts/multi-account/#permissions-boundaries)」(SeedFarmer ドキュメント) を参照してください。
ワークフローは次のとおりです。
1. セキュリティチームが自社のセキュリティ要件に従って IAM のアクセス許可の境界を定義し、作成します。IAM アクセス許可の境界は、ADDF ごとに個別に作成する必要があります AWS アカウント。出力は、アクセス許可の境界ポリシーの Amazon リソースネーム (ARN) リストです。
1. セキュリティチームが、ポリシー ARN リストを 自社の ADDF デベロッパーチームと共有します。
1. ADDF デベロッパーチームが、ポリシー ARN リストをマニフェストファイルに統合します。この統合の例については、[「sample-permissionboundary.yaml](https://github.com/awslabs/autonomous-driving-data-framework/blob/d98e02f1a89d0029b35a56b93dd56c18c5cb2aa1/resources/sample-permissionboundary.yaml) (GitHub)」を参照してください。
1. デプロイが完了すると、アクセス許可の境界が、CodeBuild がモジュールをデプロイするときに使用するすべてのサービスロールにアタッチされます。
1. セキュリティチームは、必要に応じて、アクセス許可の境界が適用されていることをモニタリングします。
## AWS マルチアカウントアーキテクチャ
AWS Well-Architected フレームワークのセキュリティの柱で定義されているように、組織の要件 AWS アカウントに基づいてリソースとワークロードを複数の に分割することがベストプラクティスと見なされます。これは、 が分離境界 AWS アカウント として機能するためです。詳細については、「[AWS アカウント の管理と分離](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/aws-account-management-and-separation.html)」を参照してください。この概念を実現したのが、マルチアカウントアーキテクチャと呼ばれるものです。単一アカウントアーキテクチャと比較すると、適切に設計された AWS マルチアカウントアーキテクチャではワークロードを分類できるため、セキュリティ侵害が発生した場合の影響範囲が小さくなります。
ADDF は AWS 、マルチアカウントアーキテクチャをネイティブにサポートします。ADDF モジュールは、組織のセキュリティとseparation-of-dutiesの要件に必要な数 AWS アカウント だけ分散できます。ADDF は、1 つの AWS アカウントにデプロイし、ツールチェーンとターゲットアカウントの機能を組み合わせることが可能です。あるいは、ADDF モジュールまたはモジュールグループ用に、個別のターゲットアカウントを作成することもできます。
考慮すべき唯一の制限は、ADDF モジュールがそれぞれのデプロイの最小単位を表すことです AWS アカウント。
本番環境では、ツールチェーンアカウントと、1 つ以上のターゲットアカウントから構成されるマルチアカウントアーキテクチャを使用することが推奨されます。詳細については、「[ADDF アーキテクチャ](addf-architecture-terminology.md#addf-architecture)」を参照してください。
## マルチアカウントデプロイの最小特権のアクセス許可
マルチアカウントアーキテクチャを使用する場合、SeedFarmer では、ターゲットアカウントにアクセスし、次の 3 つのアクションを実行する必要があります。
1. ADDF モジュールのメタデータをツールチェーンアカウントとターゲットアカウントに書き込む。
1. 使用中の ADDF モジュールのメタデータをツールチェーンアカウントとターゲットアカウントから読み取る。
1. モジュールをデプロイまたは更新するために、ターゲットアカウントで AWS CodeBuild ジョブを開始します。
次の図は、ADDF 固有の AWS Identity and Access Management (IAM) ロールを引き受けるオペレーションを含む、クロスアカウント関係を示しています。
![\[ツールチェーンアカウントとターゲットアカウントを持つ AWS マルチアカウントアーキテクチャの IAM ロール。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/addf-security-and-operations/images/addf-cross-account-arch.png)
このようなクロスアカウントアクションは、明確に定義された assume-role オペレーションを使用することで実現できます。
+ ADDF ツールチェーン IAM ロールは、ツールチェーンアカウントにデプロイされます。このロールは SeedFarmer が引き受けます。このロールは、`iam:AssumeRole` を実行するアクセス許可を持っており、ADDF デプロイ IAM ロールを各ターゲットアカウントで引き受けることができます。さらに、ADDF ツールチェーン IAM ロールはローカル Parameter Store AWS Systems Manager オペレーションを実行できます。
+ ADDF デプロイ IAM ロールは、各ターゲットアカウントにデプロイされます。このロールは、ADDF ツールチェーン IAM ロールを使用して、ツールチェーンアカウントからのみ引き受けることができます。このロールには、ローカル AWS Systems Manager の Parameter Store オペレーションを実行するアクセス許可があり、CodeSeeder を介して CodeBuild ジョブを開始および記述する AWS CodeBuild アクションを実行するアクセス許可があります。
これら ADDF に固有の IAM ロールは、ADDF ブートストラッピングプロセスの一環で作成されます。詳細については、[ADDF デプロイガイド](https://github.com/awslabs/autonomous-driving-data-framework/blob/main/docs/deployment_guide.md) * AWS アカウント(GitHub) の「ブートストラップ (複数可*)」を参照してください。 GitHub
クロスアカウントのアクセス許可はすべて、最小特権の原則に従って設定されます。一方のターゲットアカウントが侵害されても、もう一方の ADDF AWS アカウントは影響が最小限か、まったく受けずに済みます。
ADDF のシングルアカウントアーキテクチャの場合でも、ロールの関係は変わりません。分解されて 1 つの AWS アカウントになるだけです。