ADDF にあらかじめ組み込まれたセキュリティ機能 - AWS 規範ガイダンス
ADDF モジュールコードの最小特権Infrastructure as CodeIaC の自動セキュリティチェックAWS CDK デプロイロールのカスタムの最小特権ポリシーモジュールの deployspec ファイルの最小特権ポリシーデータ暗号化Secrets Manager を使用した認証情報ストレージSeedFarmer と CodeSeeder のセキュリティ検査CodeSeeder の AWS CodeBuild ロールのための、アクセス許可の境界サポートAWS マルチアカウントアーキテクチャマルチアカウントデプロイの最小特権のアクセス許可

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ADDF にあらかじめ組み込まれたセキュリティ機能

Autonomous Driving Data Framework (ADDF) には、さまざまなセキュリティ機能が組み込まれています。通常、これらの機能は、安全なフレームワークを構築して、組織が企業向けの一般的なセキュリティ要件を満たせるように設計されています。

以下が、あらかじめ組み込まれているセキュリティ機能です。

ADDF モジュールコードの最小特権

最小特権は、タスクを実行するために最低限必要な権限を付与する際の、セキュリティのベストプラクティスです。詳細については、「最小特権アクセス許可を適用する」を参照してください。ADDF が提供するモジュールは、コードとデプロイ済みのリソースにおける最小特権の原則に、以下のとおり厳密に従います。

  • ADDF モジュール用に生成されたすべての AWS Identity and Access Management (IAM) ポリシーには、ユースケースに対する必要最小限のアクセス許可のみ付与されます。 

  • AWS のサービス は、最小特権の原則に従って設定されデプロイされます。ADDF が提供するモジュールは、特定のユースケースに必要なサービスとサービスの機能のみを使用します。

Infrastructure as Code

ADDF は、フレームワークとして、ADDF モジュールを Infrastructure as Code (IaC) としてデプロイするように設計されています。IaC は、手動のデプロイプロセスをなくし、手動のプロセスで起きやすいエラーや設定のミスを防止します。 

ADDF は、一般的な IaC フレームワークを使ってモジュールをオーケストレーションし、デプロイするように設計されています。これには以下が含まれますが、これらに限定されません。 

異なる IaC フレームワークを使用すると異なるモジュールを作成できます。次に、ADDF を使ってそれらをデプロイします。

ADDF モジュールで使用されるデフォルトの IaC フレームワークは AWS CDK です。AWS CDK は、AWS リソースを強制的に定義するときに使用できる、ハイレベルなオブジェクト指向の抽象化です。AWS CDK ではすでに、さまざまなサービスやシナリオに対してデフォルトでセキュリティのベストプラクティスが適用されています。AWS CDK を使用することで、セキュリティの設定ミスによるリスクを防ぎます。

IaC の自動セキュリティチェック

ADDF には、オープンソースの cdk-nag ユーティリティ (GitHub) が組み込まれています。このユーティリティは、AWS CDK に基づく ADDF モジュールが一般的なベストプラクティスとセキュリティ上のベストプラクティスを順守しているかどうかを自動でチェックします。cdk-nag ユーティリティは、ルールとルールパックを使用して、ベストプラクティスに違反しているコードを検出し、報告します。これらのルールと包括的なリストの詳細については、cdk-nag rules (GitHub) を参照してください。

AWS CDK デプロイロールのカスタムの最小特権ポリシー

ADDF は、AWS CDK v2 を幅広く活用します。ユーザーは、すべての ADDF AWS アカウント を AWS CDK にブートストラップする必要があります。詳細については「Bootstrapping」(AWS CDK ドキュメント) を参照してください。

デフォルトでは、AWS CDK は、寛容な AdministratorAccess AWS マネージドポリシーを、ブートストラップしたアカウントで作成された AWS CDK デプロイロールに割り当てます。このロールの完全な名前は cdk-[CDK_QUALIFIER]-cfn-exec-role-[AWS_ACCOUNT_ID]-[REGION] です。AWS CDK は、AWS CDK デプロイプロセスの一環として、このロールを使ってブートストラップした AWS アカウント にリソースをデプロイします。

組織のセキュリティ要件によっては、AdministratorAccess ポリシーの許容性が過剰になる場合があります。ポリシーとアクセス許可は、AWS CDK ブートストラッププロセスの最中に必要に応じてカスタマイズできます。このポリシーは、--cloudformation-execution-policies パラメータを使って、ポリシーが新たに定義されたアカウントを再度ブートストラップすることで変更できます。詳細については「Customizing bootstrapping」(AWS CDK ドキュメント) を参照してください。

注記

このセキュリティ機能は ADDF に固有の機能ではありませんが、ADDF のデプロイの全体的なセキュリティを高めることにつながるため、こちらのセクションに記載されています。

モジュールの deployspec ファイルの最小特権ポリシー

各モジュールには、deployspec.yaml というデプロイ仕様のファイルが含まれています。このファイルは、モジュールのデプロイ手順を定義します。CodeSeeder は、AWS CodeBuild を使用して定義済みのモジュールをターゲットアカウントにデプロイする際に、こちらを使用します。CodeSeeder は、デプロイ仕様ファイルの指示に従ってデフォルトのサービスロールを CodeBuild に割り当てて、リソースをデプロイします。このサービスロールは最小特権の原則に従って設計されています。このロールには AWS CDK アプリケーションをデプロイする際に必要になるすべてのアクセス許可が含まれています。ADDF が提供するモジュールは、すべて AWS CDK アプリケーションと同様に作成されるためです。

ただし、AWS CDK の外部でステージコマンドを実行する必要がある場合は、CodeBuild のデフォルトのサービスロールを使用するのではなく、カスタム IAM ポリシーを作成する必要があります。例えば、Terraform など、AWS CDK 以外の IaC デプロイフレームワークを使用している場合、そのフレームワークが機能するには、そのための十分なアクセス許可を付与する IAM ポリシーを作成することが必要になります。専用の IAM ポリシーが必要になるもう 1 つのシナリオが、install、pre_build、build、post_build のいずれかのステージコマンドに、他の AWS のサービス サービスへのダイレクトな AWS Command Line Interface (AWS CLI) 呼び出しを含める場合です。例えば、モジュールに、ファイルを S3 バケットにアップロードするための Amazon Simple Storage Service (Amazon S3) コマンドが含まれる場合、カスタムポリシーが必要です。カスタム IAM ポリシーを使用すると、AWS CDK デプロイ以外の AWS コマンドを詳細にコントロールできます。カスタム IAM ポリシーの例については、「ModuleStack」(SeedFarmer ドキュメント) を参照してください。ADDF モジュール用にカスタム IAM ポリシーを作成するときは、必ず最小特権のアクセス許可を適用します。

データ暗号化

ADDF は、機密である可能性の高いデータを保存して処理します。こうしたデータを保護するため、SeedFarmer、CodeSeeder、ADDF が提供するモジュールは (demo-only フォルダのモジュールに関しては別段の明記がない限り)、使用したすべての AWS のサービス の、保管中のデータと転送中のデータを暗号化します。

Secrets Manager を使用した認証情報ストレージ

ADDFは、Docker Hub、JupyterHub、Amazon Redshift など、さまざまなサービスのさまざまなシークレットを処理します。ADDF 関連のシークレットを保管するときは AWS Secrets Manager を使用します。これによりユーザーは、機密データをソースコードから削除することができます。

Secrets Manager のシークレットは、ターゲットアカウントが正常に機能するために必要になるものであるため、ターゲットアカウントにのみ保管されます。ツールチェーンアカウントには、通常はいずれのシークレットも含まれません。

SeedFarmer と CodeSeeder のセキュリティ検査

SeedFarmer と CodeSeeder (GitHub リポジトリ) は、ADDF とその ADDF モジュールをデプロイするときに使用します。これらのオープンソースのプロジェクトは、ADDF のセキュリティ検査プロセス にあるとおり、ADDF と同じ、AWS の内部セキュリティ検査を定期的に受けています。

CodeSeeder の AWS CodeBuild ロールのための、アクセス許可の境界サポート

IAM のアクセス許可の境界は、ID ベースのポリシーが IAM エンティティに付与できるアクセス許可の上限を定義する、一般的なセキュリティメカニズムです。SeedFarmer と CodeSeeder は、各ターゲットアカウントの、IAM アクセス許可の境界のアタッチメントをサポートしています。アクセス許可の境界は、CodeSeeder がモジュールをデプロイする際に CodeBuild が使用する、サービスロールのアクセス許可の上限数を設定します。IAM のアクセス許可の境界は、セキュリティチームが ADDF の外部で作成する必要があります。IAM のアクセス許可の境界におけるポリシーのアタッチメントは、ADDF デプロイのマニフェストファイルである deployment.yaml で属性として受け取られます。詳細については、「Permissions boundary support」(SeedFarmer ドキュメント) を参照してください。

ワークフローは次のとおりです。

  1. セキュリティチームが自社のセキュリティ要件に従って IAM のアクセス許可の境界を定義し、作成します。IAM のアクセス許可の境界は、各 ADDF AWS アカウント で個別に作成する必要があります。。出力は、アクセス許可の境界ポリシーの Amazon リソースネーム (ARN) リストです。

  2. セキュリティチームが、ポリシー ARN リストを 自社の ADDF デベロッパーチームと共有します。

  3. ADDF デベロッパーチームが、ポリシー ARN リストをマニフェストファイルに統合します。統合の例については、sample-permissionboundary.yaml (GitHub) と 「Deployment manifest」(SeedFarmer ドキュメント) を参照してください。

  4. デプロイが完了すると、アクセス許可の境界が、CodeBuild がモジュールをデプロイするときに使用するすべてのサービスロールにアタッチされます。

  5. セキュリティチームは、必要に応じて、アクセス許可の境界が適用されていることをモニタリングします。

AWS マルチアカウントアーキテクチャ

AWS Well-Architected フレームワークのセキュリティの柱で定義されているとおり、リソースとワークロードは、組織の要件に基づいて複数の AWS アカウント に分割することがベストプラクティスとされています。これは、AWS アカウント が分離境界として機能するためです。詳細については、「AWS アカウント の管理と分離」を参照してください。この概念を実現したのが、マルチアカウントアーキテクチャと呼ばれるものです。単一アカウントアーキテクチャと比較すると、適切に設計された AWS マルチアカウントアーキテクチャではワークロードを分類できるため、セキュリティ侵害が発生した場合の影響範囲が小さくなります。

ADDF は、AWS マルチアカウントアーキテクチャをネイティブにサポートしています。お使いの ADDF モジュールは、組織のセキュリティと職務分掌の要件に応じて、必要な数の AWS アカウント に分散することができます。ADDF は、1 つの AWS アカウント にデプロイし、ツールチェーンとターゲットアカウントの機能を組み合わせることが可能です。あるいは、ADDF モジュールまたはモジュールグループ用に、個別のターゲットアカウントを作成することもできます。

留意すべき唯一の制限は、ADDF モジュールは各 AWS アカウント のデプロイにおいて最小の単位になるという点です。

本番環境では、ツールチェーンアカウントと、1 つ以上のターゲットアカウントから構成されるマルチアカウントアーキテクチャを使用することが推奨されます。詳細については、「ADDF アーキテクチャ」を参照してください。

マルチアカウントデプロイの最小特権のアクセス許可

マルチアカウントアーキテクチャを使用する場合、SeedFarmer では、ターゲットアカウントにアクセスし、次の 3 つのアクションを実行する必要があります。

  1. ADDF モジュールのメタデータをツールチェーンアカウントとターゲットアカウントに書き込む。

  2. 使用中の ADDF モジュールのメタデータをツールチェーンアカウントとターゲットアカウントから読み取る。

  3. モジュールをデプロイまたは更新するため、ターゲットアカウントで AWS CodeBuild ジョブを実行する。

以下は、ADDF に固有の AWS Identity and Access Management (IAM) ロールを想定したオペレーションを含む、クロスアカウントの関係を示した図です。

ツールチェーンアカウントとターゲットアカウントを含む AWS マルチアカウントアーキテクチャにおける IAM ロール。

このようなクロスアカウントアクションは、明確に定義された assume-role オペレーションを使用することで実現できます。

  • ADDF ツールチェーン IAM ロールは、ツールチェーンアカウントにデプロイされます。このロールは SeedFarmer が引き受けます。このロールは、iam:AssumeRole を実行するアクセス許可を持っており、ADDF デプロイ IAM ロールを各ターゲットアカウントで引き受けることができます。さらに、ADDF ツールチェーンの IAM ロールは、ローカルの AWS Systems Manager パラメータストアオペレーションで実行できます。

  • ADDF デプロイ IAM ロールは、各ターゲットアカウントにデプロイされます。このロールは、ADDF ツールチェーン IAM ロールを使用して、ツールチェーンアカウントからのみ引き受けることができます。このロールは、ローカルの AWS Systems Manager パラメータストアオペレーションと、CodeSeeder を使用して CodeBuild ジョブを開始および記述する AWS CodeBuild アクションを実行するためのアクセス許可を持っています。

これら ADDF に固有の IAM ロールは、ADDF ブートストラッピングプロセスの一環で作成されます。詳細については、「ADDF Deployment Guide」(GitHub) の「Bootstrap AWS アカウント」を参照してください。

クロスアカウントのアクセス許可はすべて、最小特権の原則に従って設定されます。一方のターゲットアカウントが侵害されても、もう一方の ADDF AWS アカウント は影響が最小限か、まったく受けずに済みます。

ADDF のシングルアカウントアーキテクチャの場合でも、ロールの関係は変わりません。分解されて 1 つの AWS アカウント になるだけです。