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

# AWS インフラストラクチャをデプロイする前に、一元化されたカスタム Checkov スキャンを実装してポリシーを適用する
<a name="centralized-custom-checkov-scanning"></a>

*Benjamin Morris (Amazon Web Services)*

## 概要
<a name="centralized-custom-checkov-scanning-summary"></a>

このパターンは、1 つのリポジトリ内にカスタム Checkov ポリシーを作成し、このポリシーを GitHub 組織全体で再利用するための GitHub Actions フレームワークを提供します。このパターンに従うことにより、情報セキュリティチームは会社の要件に基づいてカスタムポリシーを記述、追加、維持できます。カスタムポリシーは、GitHub 組織内のすべてのパイプラインに自動的にプルされます。このアプローチを使用して、リソースをデプロイする前に、リソースに関する会社の標準を適用できます。

## 前提条件と制限事項
<a name="centralized-custom-checkov-scanning-prereqs"></a>

**前提条件**
+ アクティブな AWS アカウント
+ GitHub Actions を使用する GitHub 組織
+ AWS HashiCorp Terraform または AWS CloudFormation

**制限事項**
+ このパターンは GitHub Actions 用に記述されています。ただし、GitLab など、同様の継続的インテグレーションおよび継続的デリバリー (CI/CD) フレームワークにも適応できます。GitHub の特定の有料バージョンは必要ありません。
+ 一部の AWS のサービス は では使用できません AWS リージョン。リージョンの可用性については、 AWS ドキュメントの[「サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」を参照して、サービスのリンクを選択します。

## アーキテクチャ
<a name="centralized-custom-checkov-scanning-architecture"></a>

このパターンは、再利用可能な GitHub ワークフローとカスタム Checkov ポリシーを含む GitHub リポジトリとしてデプロイされるように設計されています。再利用可能なワークフローは、Terraform と CloudFormation のどちらの Infrastructure as Code (IaC) リポジトリでもスキャンできます。

次の図では、**再利用可能な GitHub ワークフローリポジトリ**と**カスタム Checkov ポリシーリポジトリ**を、それぞれ別のアイコンとして示しています。ただし、これらのリポジトリは個別のリポジトリとしても、単一のリポジトリとしても実装できます。サンプルコードでは 1 つのリポジトリを使用し、ワークフロー用のファイル (`.github/workflows`) とカスタムポリシー用のファイル (`custom_policies` フォルダと `.checkov.yml` 設定ファイル) を同一リポジトリ内に含めています。

![\[GitHub Actions は、再利用可能な GitHub ワークフローとカスタム Checkov ポリシーを使用して IaC を評価します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/6c0c941f-14f9-4569-92da-9f81ab3e525c/images/a1539ce5-0ee6-4af1-bd01-cafad0f71708.png)


この図表は、次のワークフローを示しています。

1. ユーザーが GitHub リポジトリにプルリクエストを作成します。

1. 再利用可能な Checkov ワークフローへの参照を含むパイプラインワークフローが GitHub Actions で開始されます。

1. パイプラインワークフローは、参照された再利用可能な Checkov ワークフローを外部リポジトリからダウンロードし、GitHub Actions を使用してこの Checkov ワークフローを実行します。

1. 再利用可能な Checkov ワークフローは、外部リポジトリからカスタムポリシーをダウンロードします。

1. 再利用可能な Checkov ワークフローは、組み込みの Checkov ポリシーとカスタム Checkov ポリシーの両方に照合して GitHub リポジトリの IaC を評価します。再利用可能な Checkov ワークフローは、セキュリティの問題が見つかったかどうかに基づいて合格または不合格になります。

**自動化とスケール**

このパターンにより Checkov 設定を一元管理できるため、ポリシーの更新を 1 か所に適用するだけで済みます。ただし、このパターンでは、中央の再利用可能なワークフローへの参照を含むワークフローを、全リポジトリが使用する必要があります。この参照を手動で追加することも、スクリプトを使用して各リポジトリの `.github/workflows` フォルダにファイルをプッシュすることもできます。

## ツール
<a name="centralized-custom-checkov-scanning-tools"></a>

**AWS のサービス**
+ [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および リージョン全体のライフサイクルを通じてリソースを管理するのに役立ちます。Checkov は CloudFormation をスキャンできます。

**その他のツール**
+ [Checkov](https://www.checkov.io/) は、IaC のセキュリティとコンプライアンスの設定ミスをチェックする静的コード分析ツールです。
+ [GitHub Actions](https://github.com/features/actions) は GitHub プラットフォームに統合されており、GitHub リポジトリ内のワークフローの作成、共有、実行に役立ちます。GitHub Actions を使用して、コードの構築、テスト、デプロイなどのタスクを自動化できます。
+ [Terraform](https://www.terraform.io/) は HashiCorp の IaC ツールであり、クラウドおよびオンプレミスのリソースの作成と管理を支援します。Checkov は Terraform をスキャンできます。

**コードリポジトリ**

このパターンのコードは、GitHub の [centralized-custom-checkov-sast](https://github.com/aws-samples/centralized-custom-checkov-sast) リポジトリから入手できます。

## ベストプラクティス
<a name="centralized-custom-checkov-scanning-best-practices"></a>
+ 一貫したセキュリティ体制を維持するには、会社のセキュリティポリシーと Checkov ポリシーの整合性を確保します。
+ Checkov カスタムポリシーの実装の初期段階では、セキュリティ問題のある IaC もマージされるように、Checkov スキャンにソフトフェイルオプションを使用することもできます。プロセスが成熟したら、ソフトフェイルオプションからハードフェイルオプションに切り替えます。

## エピック
<a name="centralized-custom-checkov-scanning-epics"></a>

### カスタムポリシー用の中央 Checkov リポジトリを作成する
<a name="create-a-central-checkov-repository-for-custom-policies"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| 中央の Checkov リポジトリを作成 | 組織内で使用されるカスタム Checkov ポリシーを保存するためのリポジトリを作成します。クイックスタートとして、このパターンの GitHub [centralized-custom-checkov-sast ](https://github.com/aws-samples/centralized-custom-checkov-sast)リポジトリの内容を、中央の Checkov リポジトリにコピーできます。 | DevOps エンジニア | 
| 再利用可能なワークフロー用のリポジトリを作成 | 再利用可能なワークフロー用のリポジトリが既に存在する場合、またはカスタム Checkov ポリシーと同じリポジトリに再利用可能なワークフローファイルを保存する場合は、このステップをスキップできます。再利用可能なワークフローを保持する GitHub リポジトリを作成します。このリポジトリは、他のリポジトリのパイプラインから参照されます。 | DevOps エンジニア | 

### 再利用可能なサンプル Checkov ワークフローを作成する
<a name="create-reusable-and-example-checkov-workflows"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| 再利用可能な Checkov ワークフローを追加する | 再利用可能なワークフローリポジトリ内に、再利用可能な Checkov GitHub Actions ワークフロー (YAML ファイル) を作成します。この再利用可能なワークフローは、このパターンで提供されているワークフローファイルを基に作成できます。変更の例として、ソフトフェイルオプションを使用するように再利用可能なワークフローを変更することが挙げられます。`soft-fail` を `true` に設定すると、Checkov スキャンが失敗した場合でもジョブを正常に完了できます。手順については、Checkov ドキュメントの「[Hard and soft fail](https://www.checkov.io/2.Basics/Hard%20and%20soft%20fail.html)」を参照してください。 | DevOps エンジニア | 
| ワークフローの例を追加する | `reusable` ワークフローを参照するサンプル Checkov ワークフローを追加します。これにより、`reusable` ワークフローを再利用するためのテンプレートが提供されます。サンプルリポジトリでは、`checkov-source.yaml` は再利用可能なワークフローであり、`checkov-scan.yaml` は `checkov-source` を利用するサンプルです。サンプル Checkov ワークフローの記述方法の詳細については、「[追加情報](#centralized-custom-checkov-scanning-additional)」を参照してください。 | DevOps エンジニア | 

### 企業ポリシーを Checkov カスタムポリシーに関連付ける
<a name="associate-company-policies-to-checkov-custom-policies"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| Checkov によって適用可能なポリシーを決定する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralized-custom-checkov-scanning.html)Checkov カスタムポリシーの作成方法の詳細については、Checkov ドキュメントの「[Custom Policies Overview](https://www.checkov.io/3.Custom%20Policies/Custom%20Policies%20Overview.html)」を参照してください。 | セキュリティおよびコンプライアンス | 
| Checkov カスタムポリシーを追加する | 特定した企業ポリシーを、中央リポジトリのカスタム Checkov ポリシーに変換します。Python または YAML を使用して、シンプルな Checkov ポリシーを記述できます。 | セキュリティ | 

### 一元化された Checkov カスタムポリシーを実装する
<a name="implement-centralized-checkov-custom-policies"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| Checkov の再利用可能なワークフローをすべてのリポジトリに追加する | この時点で、再利用可能なワークフローを参照するサンプル Checkov ワークフローが必要となります。再利用可能なワークフローを参照するサンプル Checkov ワークフローを、これを必要とする各リポジトリにコピーします。 | DevOps エンジニア | 
| マージ前に Checkov が実行されるようにメカニズムを作成する | プルリクエストごとに Checkov ワークフローが実行されるようにするには、Checkov ワークフローが成功した場合にのみプルリクエストをマージするための[ステータスチェック](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks)を作成します。GitHub では、プルリクエストをマージする前に特定のワークフローが実行されるように指定できます。 | DevOps エンジニア | 
| 組織全体の PAT を作成し、シークレットとして共有する | GitHub 組織が公開されている場合は、このステップをスキップできます。このパターンでは、Checkov ワークフローが、GitHub 組織のカスタムポリシーリポジトリからカスタムポリシーをダウンロードできる必要があります。Checkov ワークフローがこれらのリポジトリにアクセスできるように、必要なアクセス許可を付与する必要があります。これには、組織リポジトリを読み取るアクセス許可を持つ[個人用アクセストークン (PAT) を作成](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-fine-grained-personal-access-token)します。この PAT を、組織全体のシークレット (有料プランの場合) または各リポジトリのシークレット (無料版の場合) として、各リポジトリと共有します。サンプルコードでは、シークレットのデフォルト名は `ORG_PAT` です。 | DevOps エンジニア | 
| (オプション) Checkov ワークフローファイルを変更から保護する | Checkov ワークフローファイルを不要な変更から保護するには、`CODEOWNERS` ファイルを使用します。`CODEOWNERS` ファイルは通常、ディレクトリのルートにデプロイされます。例えば、`checkov-scan.yaml` ファイルの変更時に GitHub 組織の `secEng` グループからの承認が必要となるように設定するには、リポジトリの `CODEOWNERS` ファイルに以下を追加します。<pre>[Checkov]<br />.github/workflows/checkov-scan.yaml @myOrg/secEng</pre>`CODEOWNERS` ファイルは、ファイルが存在するリポジトリに固有です。リポジトリで使用される Checkov ワークフローを保護するには、各リポジトリに `CODEOWNERS` ファイルを追加 (または更新) する必要があります。Checkov ワークフローファイルの保護の詳細については、「[追加情報](#centralized-custom-checkov-scanning-additional)」を参照してください。`CODEOWNERS` ファイルの詳細については、CI/CD プロバイダー ([GitHub](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) など) の公式ドキュメントを参照してください。 | DevOps エンジニア | 

## 関連リソース
<a name="centralized-custom-checkov-scanning-resources"></a>
+ [Checkov Custom Policies Overview](https://www.checkov.io/3.Custom%20Policies/Custom%20Policies%20Overview.html)
+ [CloudFormation Configuration Scanning](https://www.checkov.io/7.Scan%20Examples/Cloudformation.html)
+ [GitHub Actions Reusable Workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows)

## 追加情報
<a name="centralized-custom-checkov-scanning-additional"></a>

**Checkov ワークフローファイルの記述**

`checkov-scan.yaml` を記述する場合は、このファイルをいつ実行するかを検討してください。最上位の `on` キーは、ワークフローの実行時を決定します。サンプルリポジトリでは、`main` ブランチをターゲットとするプルリクエストがあった場合 (およびプルリクエストのソースブランチが変更された場合) に、ワークフローが実行されます。ワークフローは、`workflow_dispatch` キーによって必要とされる時点で実行することもできます。

ワークフローのトリガー条件は、ワークフローを実行する頻度に応じて変更できます。例えば、`pull_request` を `push` に置き換えて `branches` キーを削除することにより、いずれかのブランチにコードがプッシュされるたびにワークフローが実行されるように変更できます。

個々のリポジトリ内で作成したサンプルワークフローファイルを変更できます。例えば、リポジトリが `production` ブランチを中心に構造化されている場合は、ターゲットブランチの名前を `main` から `production` に変更して調整できます。

**Checkov ワークフローファイルの保護**

Checkov スキャンを実行することにより、潜在的なセキュリティ設定ミスに関する有用な情報が得られます。しかし、デベロッパーによってはこのスキャンが生産性の障壁のように感じられ、スキャンワークフローを削除または無効にしようとする場合があります。

この問題にはいくつかの対処方法が考えられます。例えば、セキュリティスキャンの長期的な価値を伝える的確なメッセージを発信したり、安全なインフラストラクチャのデプロイ方法を明確に規定するドキュメントを整備したりします。こうした方法は、DevSecOps コラボレーションに対する重要な「ソフト」アプローチであり、この問題の根本原因の解決策とみなすことができます。ただし、デベロッパーを適切な方向に誘導するためのガードレールとして、`CODEOWNERS` ファイルなどの技術的な制御を使用することもできます。

**サンドボックスでのパターンのテスト**

サンドボックス環境でこのパターンをテストするには、次の手順に従います。

1. 新しい GitHub 組織を作成します。組織内のすべてのリポジトリに対する読み取り専用アクセス権を持つトークンを作成します。このトークンは有料環境ではなくサンドボックス環境用であるため、このトークンを組織全体のシークレットに保存することはできません。

1. Checkov 設定を保持する `checkov` リポジトリと、再利用可能なワークフロー設定を保持する `github-workflows` リポジトリを作成します。各リポジトリに、サンプルリポジトリの内容を入力します。

1. アプリケーションリポジトリを作成し、`checkov-scan.yaml` ワークフローをコピーして、その `.github/workflows` フォルダに貼り付けます。組織の読み取り専用アクセス用に作成した PAT を含むシークレットをリポジトリに追加します。デフォルトのシークレットは `ORG_PAT` です。

1. Terraform または CloudFormation コードをアプリケーションリポジトリに追加するプルリクエストを作成します。Checkov スキャンを実行し、その結果が返される必要があります。