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

# ADDF の安全なセットアップと運用
<a name="secure-setup-and-operation"></a>

Autonomous Driving Data Framework (ADDF) は、組織内の専任の DevOps チームとセキュリティチームによる継続的なメンテナンスとケアが必要となるカスタムソフトウェアとして扱う必要があります。このセクションでは、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 アカウント 環境は、特定のユースケースのセキュリティと運用のニーズを満たすように設計する必要があります。例えば、PoC (概念実証) 環境で ADDF インスタンスを設定する場合のセキュリティや、運用関連のタスクと考慮事項は、本番稼働用の ADDF 環境を設定する場合とは異なります。

### PoC (概念実証) 環境で ADDF を実行する
<a name="running-addf-in-a-poc-environment"></a>

PoC 環境で ADDF を使用する場合は、他のワークロードを含まない ADDF AWS アカウント 専用の を作成することをお勧めします。これにより、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 の実行を開始する前に、ADDF デプロイの耐用年数が終了するまでの間、十分な規模と能力を備えた DevOps チームを定義し、十分なリソースを投入する必要があります。
+ **マルチアカウントアーキテクチャを使用する** – 各 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 モジュールを必要な数の AWS アカウント に分散します。
+ **複数の ADDF インスタンスをデプロイする** — 組織のソフトウェア開発プロセスに従って ADDF モジュールを適切に開発、テスト、デプロイするために、必要な数だけ個別の ADDF インスタンスをセットアップします。複数の ADDF インスタンスを設定する場合は、次のいずれかの方法を使用できます。
  + **異なる AWS マルチアカウント環境の複数の ADDF インスタンス **– 個別の ADDF インスタンスを分離 AWS アカウント するために使用できます。例えば、組織に専用の開発、テスト、本番稼働のステージがある場合、ステージごとに個別の ADDF インスタンスと専用アカウントを作成できます。これにより、エラーがステージ全体に広がるリスクを軽減したり、承認プロセスを実装しやすくしたり、ユーザーアクセスを特定の環境のみに制限したりするなど、多くの利点が得られます。次のイメージは、別々のマルチアカウント環境にデプロイされた 2 つの ADDF インスタンスを示しています。  
![\[マルチアカウントアーキテクチャを持つ個別の AWS 環境の 2 つの ADDF インスタンス\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/addf-security-and-operations/images/A_multi-addf-multi-account.png)
  + **同じ AWS マルチアカウント環境内の複数の ADDF インスタンス **– 同じ AWS マルチアカウント環境を共有する複数の ADDF インスタンスを作成できます。これにより、同じ AWS アカウント内に独立したブランチが効果的に作成されます。例えば、異なるデベロッパーが並行して作業している場合、デベロッパーは同じ AWS アカウントに専用の ADDF インスタンスを作成することができます。これにより、デベロッパーは独立したブランチで、開発やテストの作業を行うことができます。この方法を使用する場合、ADDF インスタンスごとに ADDF リソースに一意のリソース名を付ける必要があります。これは ADDF が事前に提供しているモジュールでデフォルトでサポートされています。この方法は、[AWS のサービス クォータ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)の範囲内で使用できます。以下のイメージは、共有のマルチアカウント環境にデプロイされた 2 つの ADDF インスタンスを示しています。  
![\[同じ AWS マルチアカウント環境にデプロイされた 2 つの ADDF インスタンス\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/addf-security-and-operations/images/C_multi-instance-multi-account-shared.png)
  + **同じ AWS 単一アカウント環境における複数の ADDF インスタンス** — このアーキテクチャは前の例と非常に似ています。違いは、複数の ADDF インスタンスがマルチアカウント環境ではなく単一アカウント環境にデプロイされる点です。このアーキテクチャは、非常に限られた範囲内で、複数のデベロッパーが異なるブランチで同時に作業するごく単純な ADDF のユースケースに適しています。  
![\[同じ AWS 単一アカウント環境にデプロイされた 2 つの ADDF インスタンス\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/addf-security-and-operations/images/B_multi-addf-single-account.png)

  SeedFarmer は ADDF インスタンスのデプロイを制御する単一のツールであるため、組織のデプロイ戦略と CI/CD プロセスに適合する環境とアカウントアーキテクチャを構築できます。
+ **組織のセキュリティ要件に従って AWS Cloud Development Kit (AWS CDK) ブートストラッププロセスをカスタマイズする** – デフォルトでは、 はブートストラッププロセス中に [AdministratorAccess](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator) AWS 管理ポリシーを AWS CDK 割り当てます。このポリシーは完全な管理権限を付与します。このポリシーが組織のセキュリティ要件に対して寛容すぎる場合は、適用するポリシーをカスタマイズすることができます。詳細については、「[AWS CDK デプロイロールのカスタム最小特権ポリシー](built-in-security-features.md#custom-least-privilege-policy-for-the-aws-cdk-deployment-role)」を参照してください。
+ **IAM でアクセスを設定する際のベストプラクティスに従う** – ユーザーが ADDF にアクセスできるようにする構造化 AWS Identity and Access Management (IAM) アクセスソリューションを確立します AWS アカウント。ADDF のフレームワークは、範囲を最小特権の原則に従うように設計されています。IAM のアクセスパターンも最小特権の原則に従い、組織の要件に準拠し、「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」(IAM ドキュメント) を遵守する必要があります。
+ **組織のベストプラクティスに従ってネットワークを設定する** — ADDF には、基本的なパブリックまたはプライベート仮想プライベートクラウド (VPC) を作成するネットワーク AWS CloudFormation スタックがオプションで含まれています。組織の設定によっては、この 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 セキュリティドキュメント](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 Deployment Guide](https://github.com/awslabs/autonomous-driving-data-framework/blob/main/docs/deployment_guide.md)」(GitHub) に従って ADDF を設定します。デプロイの開始点は、[autonomous-driving-data-framework](https://github.com/awslabs/autonomous-driving-data-framework) Git Hub リポジトリ内の `/manifest` フォルダです。`/manifest/example-dev` フォルダにはデモ用のサンプルデプロイが含まれています。このサンプルを独自のデプロイを設計するための開始点として使用してください。そのディレクトリには、**deployment.yaml** という名前の ADDF デプロイマニフェストファイルがあります。このファイルには、SeedFarmer が AWS クラウド内で ADDF とそのリソースを管理、デプロイ、または削除するためのすべての情報が含まれています。ADDF モジュールのグループを専用ファイルに作成することができます。**core-modules.yaml** はコアモジュールグループの一例で、ADDF が提供するすべてのコアモジュールが含まれています。つまり、**deployment.yaml** ファイルには、ターゲットアカウントにデプロイされるグループとモジュールへのすべての参照が含まれ、デプロイの順序も指定されています。

安全かつコンプライアンスに準拠した設定を行うために、特に PoC (概念実証) を目的としていない環境では、デプロイする各モジュールのソースコードを確認することをお勧めします。セキュリティ強化のベストプラクティスに従って、目的のユースケースに必要なモジュールだけをデプロイするようにしてください。

**注記**  
`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 Deployment Guide](https://github.com/awslabs/autonomous-driving-data-framework/blob/main/docs/deployment_guide.md)」(GitHub) の説明に従って、ADDF とそのモジュールをデプロイします。ターゲットアカウントのリソースを追加、更新、削除する ADDF の反復的なデプロイをサポートするために、SeedFarmer はツールチェーンとターゲットアカウントのパラメータストアに保存されている MD5 ハッシュを使用して、現在デプロイされているインフラストラクチャをローカルコードベースのマニフェストファイルで定義されているインフラストラクチャと比較します。

この方法は、ソースリポジトリ (SeedFarmer を操作するローカルコードベース) が信頼できる情報源であり、その中で明示的に宣言されたインフラストラクチャがデプロイの望ましい結果であるという GitOps パラダイムに従っています。GitOps の詳細については、「[What is 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 が不要になったら、ADDF とそれに関連するすべてのリソースを AWS アカウントから削除します。インフラストラクチャが無人で使用されていない場合、不要なコストが発生し、セキュリティリスクが発生する可能性があります。詳細については、「[Steps to destroy ADDF](https://github.com/awslabs/autonomous-driving-data-framework/blob/main/docs/deployment_guide.md#steps-to-destroy-addf)」(ADDF ドキュメント) を参照してください。