翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AWS インフラストラクチャをデプロイする前に、一元化されたカスタム Checkov スキャンを実装してポリシーを適用する
Benjamin Morris (Amazon Web Services)
概要
このパターンは、1 つのリポジトリ内にカスタム Checkov ポリシーを作成し、このポリシーを GitHub 組織全体で再利用するための GitHub Actions フレームワークを提供します。このパターンに従うことにより、情報セキュリティチームは会社の要件に基づいてカスタムポリシーを記述、追加、維持できます。カスタムポリシーは、GitHub 組織内のすべてのパイプラインに自動的にプルされます。このアプローチを使用して、リソースをデプロイする前に、リソースに関する会社の標準を適用できます。
前提条件と制限事項
前提条件
アクティブな AWS アカウント
GitHub Actions を使用する GitHub 組織
AWS HashiCorp Terraform または AWS CloudFormation
制限事項
このパターンは GitHub Actions 用に記述されています。ただし、GitLab など、同様の継続的インテグレーションおよび継続的デリバリー (CI/CD) フレームワークにも適応できます。GitHub の特定の有料バージョンは必要ありません。
一部の AWS のサービス は では使用できません AWS リージョン。リージョンの可用性については、 AWS ドキュメントの「サービスエンドポイントとクォータ」を参照して、サービスのリンクを選択します。
アーキテクチャ
このパターンは、再利用可能な GitHub ワークフローとカスタム Checkov ポリシーを含む GitHub リポジトリとしてデプロイされるように設計されています。再利用可能なワークフローは、Terraform と CloudFormation のどちらの Infrastructure as Code (IaC) リポジトリでもスキャンできます。
次の図では、再利用可能な GitHub ワークフローリポジトリとカスタム Checkov ポリシーリポジトリを、それぞれ別のアイコンとして示しています。ただし、これらのリポジトリは個別のリポジトリとしても、単一のリポジトリとしても実装できます。サンプルコードでは 1 つのリポジトリを使用し、ワークフロー用のファイル (.github/workflows) とカスタムポリシー用のファイル (custom_policies フォルダと .checkov.yml 設定ファイル) を同一リポジトリ内に含めています。
この図表は、次のワークフローを示しています。
ユーザーが GitHub リポジトリにプルリクエストを作成します。
再利用可能な Checkov ワークフローへの参照を含むパイプラインワークフローが GitHub Actions で開始されます。
パイプラインワークフローは、参照された再利用可能な Checkov ワークフローを外部リポジトリからダウンロードし、GitHub Actions を使用してこの Checkov ワークフローを実行します。
再利用可能な Checkov ワークフローは、外部リポジトリからカスタムポリシーをダウンロードします。
再利用可能な Checkov ワークフローは、組み込みの Checkov ポリシーとカスタム Checkov ポリシーの両方に照合して GitHub リポジトリの IaC を評価します。再利用可能な Checkov ワークフローは、セキュリティの問題が見つかったかどうかに基づいて合格または不合格になります。
自動化とスケール
このパターンにより Checkov 設定を一元管理できるため、ポリシーの更新を 1 か所に適用するだけで済みます。ただし、このパターンでは、中央の再利用可能なワークフローへの参照を含むワークフローを、全リポジトリが使用する必要があります。この参照を手動で追加することも、スクリプトを使用して各リポジトリの .github/workflows フォルダにファイルをプッシュすることもできます。
ツール
AWS のサービス
CloudFormation は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および リージョン全体のライフサイクルを通じてリソースを管理するのに役立ちます。Checkov は CloudFormation をスキャンできます。
その他のツール
Checkov
は、IaC のセキュリティとコンプライアンスの設定ミスをチェックする静的コード分析ツールです。 GitHub Actions
は GitHub プラットフォームに統合されており、GitHub リポジトリ内のワークフローの作成、共有、実行に役立ちます。GitHub Actions を使用して、コードの構築、テスト、デプロイなどのタスクを自動化できます。 Terraform
は HashiCorp の IaC ツールであり、クラウドおよびオンプレミスのリソースの作成と管理を支援します。Checkov は Terraform をスキャンできます。
コードリポジトリ
このパターンのコードは、GitHub の centralized-custom-checkov-sast
ベストプラクティス
一貫したセキュリティ体制を維持するには、会社のセキュリティポリシーと Checkov ポリシーの整合性を確保します。
Checkov カスタムポリシーの実装の初期段階では、セキュリティ問題のある IaC もマージされるように、Checkov スキャンにソフトフェイルオプションを使用することもできます。プロセスが成熟したら、ソフトフェイルオプションからハードフェイルオプションに切り替えます。
エピック
| タスク | 説明 | 必要なスキル |
|---|---|---|
中央の Checkov リポジトリを作成 | 組織内で使用されるカスタム Checkov ポリシーを保存するためのリポジトリを作成します。 クイックスタートとして、このパターンの GitHub centralized-custom-checkov-sast | DevOps エンジニア |
再利用可能なワークフロー用のリポジトリを作成 | 再利用可能なワークフロー用のリポジトリが既に存在する場合、またはカスタム Checkov ポリシーと同じリポジトリに再利用可能なワークフローファイルを保存する場合は、このステップをスキップできます。 再利用可能なワークフローを保持する GitHub リポジトリを作成します。このリポジトリは、他のリポジトリのパイプラインから参照されます。 | DevOps エンジニア |
| タスク | 説明 | 必要なスキル |
|---|---|---|
再利用可能な Checkov ワークフローを追加する | 再利用可能なワークフローリポジトリ内に、再利用可能な Checkov GitHub Actions ワークフロー (YAML ファイル) を作成します。この再利用可能なワークフローは、このパターンで提供されているワークフローファイルを基に作成できます。 変更の例として、ソフトフェイルオプションを使用するように再利用可能なワークフローを変更することが挙げられます。 | DevOps エンジニア |
ワークフローの例を追加する |
サンプル Checkov ワークフローの記述方法の詳細については、「追加情報」を参照してください。 | DevOps エンジニア |
| タスク | 説明 | 必要なスキル |
|---|---|---|
Checkov によって適用可能なポリシーを決定する |
Checkov カスタムポリシーの作成方法の詳細については、Checkov ドキュメントの「Custom Policies Overview | セキュリティおよびコンプライアンス |
Checkov カスタムポリシーを追加する | 特定した企業ポリシーを、中央リポジトリのカスタム Checkov ポリシーに変換します。Python または YAML を使用して、シンプルな Checkov ポリシーを記述できます。 | セキュリティ |
| タスク | 説明 | 必要なスキル |
|---|---|---|
Checkov の再利用可能なワークフローをすべてのリポジトリに追加する | この時点で、再利用可能なワークフローを参照するサンプル Checkov ワークフローが必要となります。再利用可能なワークフローを参照するサンプル Checkov ワークフローを、これを必要とする各リポジトリにコピーします。 | DevOps エンジニア |
マージ前に Checkov が実行されるようにメカニズムを作成する | プルリクエストごとに Checkov ワークフローが実行されるようにするには、Checkov ワークフローが成功した場合にのみプルリクエストをマージするためのステータスチェック | DevOps エンジニア |
組織全体の PAT を作成し、シークレットとして共有する | GitHub 組織が公開されている場合は、このステップをスキップできます。 このパターンでは、Checkov ワークフローが、GitHub 組織のカスタムポリシーリポジトリからカスタムポリシーをダウンロードできる必要があります。Checkov ワークフローがこれらのリポジトリにアクセスできるように、必要なアクセス許可を付与する必要があります。 これには、組織リポジトリを読み取るアクセス許可を持つ個人用アクセストークン (PAT) を作成 | DevOps エンジニア |
(オプション) Checkov ワークフローファイルを変更から保護する | Checkov ワークフローファイルを不要な変更から保護するには、 例えば、
Checkov ワークフローファイルの保護の詳細については、「追加情報」を参照してください。 | DevOps エンジニア |
関連リソース
追加情報
Checkov ワークフローファイルの記述
checkov-scan.yaml を記述する場合は、このファイルをいつ実行するかを検討してください。最上位の on キーは、ワークフローの実行時を決定します。サンプルリポジトリでは、main ブランチをターゲットとするプルリクエストがあった場合 (およびプルリクエストのソースブランチが変更された場合) に、ワークフローが実行されます。ワークフローは、workflow_dispatch キーによって必要とされる時点で実行することもできます。
ワークフローのトリガー条件は、ワークフローを実行する頻度に応じて変更できます。例えば、pull_request を push に置き換えて branches キーを削除することにより、いずれかのブランチにコードがプッシュされるたびにワークフローが実行されるように変更できます。
個々のリポジトリ内で作成したサンプルワークフローファイルを変更できます。例えば、リポジトリが production ブランチを中心に構造化されている場合は、ターゲットブランチの名前を main から production に変更して調整できます。
Checkov ワークフローファイルの保護
Checkov スキャンを実行することにより、潜在的なセキュリティ設定ミスに関する有用な情報が得られます。しかし、デベロッパーによってはこのスキャンが生産性の障壁のように感じられ、スキャンワークフローを削除または無効にしようとする場合があります。
この問題にはいくつかの対処方法が考えられます。例えば、セキュリティスキャンの長期的な価値を伝える的確なメッセージを発信したり、安全なインフラストラクチャのデプロイ方法を明確に規定するドキュメントを整備したりします。こうした方法は、DevSecOps コラボレーションに対する重要な「ソフト」アプローチであり、この問題の根本原因の解決策とみなすことができます。ただし、デベロッパーを適切な方向に誘導するためのガードレールとして、CODEOWNERS ファイルなどの技術的な制御を使用することもできます。
サンドボックスでのパターンのテスト
サンドボックス環境でこのパターンをテストするには、次の手順に従います。
新しい GitHub 組織を作成します。組織内のすべてのリポジトリに対する読み取り専用アクセス権を持つトークンを作成します。このトークンは有料環境ではなくサンドボックス環境用であるため、このトークンを組織全体のシークレットに保存することはできません。
Checkov 設定を保持する
checkovリポジトリと、再利用可能なワークフロー設定を保持するgithub-workflowsリポジトリを作成します。各リポジトリに、サンプルリポジトリの内容を入力します。アプリケーションリポジトリを作成し、
checkov-scan.yamlワークフローをコピーして、その.github/workflowsフォルダに貼り付けます。組織の読み取り専用アクセス用に作成した PAT を含むシークレットをリポジトリに追加します。デフォルトのシークレットはORG_PATです。Terraform または CloudFormation コードをアプリケーションリポジトリに追加するプルリクエストを作成します。Checkov スキャンを実行し、その結果が返される必要があります。
