AWS CodeBuildパイプラインのための多層防御セキュリティの実装

本記事は米国時間 7月 31 日に公開された「Implementing Defense-in-Depth Security for AWS CodeBuild Pipelines」を翻訳したものです。

最近のセキュリティ研究により、AWS Security Bulletin AWS-2025-016 で文書化されているように、 CI/CD パイプライン設定の重要性が注目されています。この投稿では、既存のガイダンスと推奨事項を一つのガイドにまとめます。

継続的インテグレーションと継続的デプロイメント（ CI/CD ）の実践は、開発チームが効率的かつ確実にソフトウェアを提供するのに役立ちます。 AWS CodeBuild は、GitHub、GitLab、その他のソースコード管理（ SCM ）システムなどのソースコードリポジトリと統合するマネージドビルドサービスを提供します。このガイドでは GitHub の例を使用していますが、セキュリティの原則と Webhook 設定のアプローチは、サポートしている他のソースコード管理システムにも適用できます。

ただし、特定の設定には注意深い配慮が必要です。適切なセキュリティ制御と脅威モデルの明確な理解なしに、信頼できないリポジトリのコントリビューターからの自動プルリクエストビルドを使用しないことを強く推奨します。この設定により、信頼できないコードがリポジトリの認証情報や環境変数にアクセスできる状態でビルド環境内で実行される可能性があります。Webhook 設定は、どのリポジトリイベントがビルドをトリガーし、ビルドプロセス中にどのコードが実行されるかを決定します。 CI/CD を価値あるものにする自動化の利点を維持しながら、適切なセキュリティ境界を維持するためには、これらの設定を理解することが不可欠です。

セキュリティチームと DevOps エンジニアは、これらの実用的なアプローチを使用して、開発速度を維持しながらセキュリティ目標を満たすように AWS CodeBuild を設定できます。脅威モデルの評価、最小権限アクセス、パイプライン設定の継続的な監視を重視した、 Webhook 設定、信頼境界、実装戦略について説明します。

パイプラインのセキュリティに関する考察

責任共有モデルでは、 AWS が基盤となる AWS CodeBuild インフラストラクチャのセキュリティを管理する一方で、お客様はパイプラインの設定、アクセス制御、およびビルド環境内で実行されるコードのセキュリティに責任を負います。このような共有の責任は、パイプライン自体のセキュリティを考える上で重要です。

AWS CodeBuild がプルリクエストを自動的に処理する際には、リポジトリの認証情報、環境変数、機密性の高い可能性のある情報にアクセスできる環境でコードをビルドします。これにより、パイプラインのセキュリティに関する特定の考慮事項が生じます：

リポジトリアクセス: AWS CodeBuild プロジェクトは、ソースコードの読み取りと Webhook の作成のためにリポジトリの認証情報を必要とします。これらの認証情報は、設定に基づいて異なる特定の権限を提供します。
ビルドの実行: ビルドプロセスでは、取得したソースコードを実行します。これには、ビルドスクリプト、依存関係の定義、プルリクエストからのテストファイルなどが含まれる場合があります。
ビルド環境: AWS CodeBuild 環境は、ビルドプロセスに必要な環境変数、AWS 認証情報、またはその他の設定データにアクセスできる場合があります。

信頼境界の確立

効果的なパイプラインのセキュリティは、さまざまなタイプのコードのコントリビューションに対する信頼境界を明確に定義することから始まります：

内部のコントリビューター: 組織のアクセス管理プロセスを通じて検証された、リポジトリへの書き込みアクセス権を持つチームメンバー。
外部のコントリビューター: フォークされたリポジトリからプルリクエストを送信する、組織外のコントリビューター。
自動処理: ビルドプロセスの一部として手動レビューなしで実行されるコード。

これらの信頼境界は、特定の環境の脅威モデリングの基礎となります。内部および信頼できる環境では、コントリビューターのフィルタリングと最小権限制御を使用して、自動化により多く依存することができます。パブリックおよびオープンソースプロジェクトでは、信頼できないコントリビューションを処理する固有のリスクがあるため、より厳格な制御が必要です。これらの環境では、より厳格なWebhookフィルタリング、包括的な承認プロセス、または後で説明するセルフホスト GitHub Actions ランナーのアプローチが有効です。

重要な原則は、特定のリスクプロファイルとコントリビューターの信頼レベルに基づいて、セキュリティ制御と開発速度の間の適切なバランスを見つけることです。これらの考慮事項を念頭に置いて、現在の AWS CodeBuild Webhook 設定を評価および設定する方法を見ていきましょう。

セキュアな Webhook の設定

Webhook は、外部イベントが AWS CodeBuild プロセスをトリガーする際に推奨されるメカニズムです。適切に設定されると、Webhook はリポジトリの変更に応答してビルドプロセスを自動化する強力で効率的な方法を提供します。ただし、不適切な Webhook 設定は、信頼できないコードが特権環境で実行されることを許可してしまい、セキュリティの脆弱性が生じる可能性があります。 Webhook 設定のセキュリティは、どのイベントがビルドをトリガーするか、それらのビルドがどのレベルのアクセス権を持つか、ビルドプロセス中にどのコードが実行されるかをどれだけ正確に理解しているかにかかっています。このセクションでは、セキュアな Webhook 設定の作成、評価、設定、および維持に対する包括的なアプローチを提供します。

現在の Webhook の設定の評価

既存の AWS CodeBuild プロジェクトを確認して、現在の Webhook 設定を理解することから始めましょう。以下の AWS CLI コマンドを使用すると、この情報を体系的に収集することができます。：

# リージョン内のすべてのCodeBuild プロジェクトを一覧表示
aws codebuild list-projects --region us-west-2

# 詳細な設定情報を取得して分析
aws codebuild batch-get-projects --region us-west-2 \
  --names $(aws codebuild list-projects --region us-west-2 \
  --query 'projects[*]' --output text | tr '\n' ' ')

これらのコマンドを実行する際は、出力のwebhookセクションに特に注意してください。このセクションには、どのリポジトリイベントがビルドをトリガーするかを正確に決定するfilterGroups設定が含まれています。

現在の設定を確認する方法を理解したところで、一般的な設定パターンとそのセキュリティへの影響を見ていきましょう。

Webhook 設定パターン

一般的な Webhook の設定パターンを理解することで、潜在的なセキュリティ上の懸念点を素早く特定し、適切な改善を実装できるようになります。以下のパターンは、 Webhook の設定に対するさまざまなアプローチを表し、それぞれに特定のセキュリティへの考慮事項があります。

注: これらのパターンを利用することは推奨されません。注意が必要な設定を特定するための参考として紹介しています。

見直しが必要な設定 – プルリクエストの自動処理

{
  "webhook": {
    "payloadUrl": "https://codebuild.us-west-2.amazonaws.com/webhooks",
    "filterGroups": [
      [
        {
          "type": "EVENT",
          "pattern": "PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED,PULL_REQUEST_REOPENED",
          "excludeMatchedPattern": false
        }
      ]
    ]
  }
}

この設定により、プルリクエストを作成できるコントリビューターがビルド環境でのコード実行をトリガーできるようになります。信頼できないリポジトリのコントリビューターからのプルリクエストの自動ビルドは利用しないことを強く推奨します。

即座に確認が必要な設定 – イベントフィルタリングなし

{
  "webhook": {
    "payloadUrl": "https://codebuild.us-west-2.amazonaws.com/webhooks",
    "filterGroups": []
  }
}

フィルタリングを行わないので、この設定では幅広いリポジトリイベントでビルドがトリガーされる可能性があります。

推奨されるセキュアな Webhook 設定

以下の設定は、自動化の利点と適切なセキュリティ制御のバランスを取るセキュリティのベストプラクティスを表しています。これらのパターンは、CI/CD の価値である開発速度を維持しながら、セキュリティリスクを軽減するのに役立ちます。

プッシュベースのビルド（ほとんどのユースケースで推奨）

プッシュベースのビルドは、リポジトリへの書き込みアクセス権を持つユーザーのみがビルドをトリガーできることを確実にします。これは、コントリビューターがリポジトリのアクセス制御メカニズムを通じてすでに検査されていることを意味します。

{
  "webhook": {
    "payloadUrl": "https://codebuild.us-west-2.amazonaws.com/webhooks",
    "filterGroups": [
      [
        {
          "type": "EVENT",
          "pattern": "PUSH",
          "excludeMatchedPattern": false
        }
      ]
    ]
  }
}

外部からのオープンソースコントリビューションに大きく依存している組織では、このアプローチは制限が厳しすぎる場合があります。例えば、外部のコントリビューターから毎日数十件のプルリクエストを受け取る人気のオープンソースプロジェクトでは、ビルドが実行される前に各コントリビューションを手動でマージする必要があり、コントリビューションのレビュープロセスが大幅に遅くなってしまいます。そのような場合、コントリビューターでフィルタリングされたビルドや、セルフホスト型の GitHub Actions ランナーのアプローチがより適切かもしれません。

コントリビューターによるビルドのフィルタリング（信頼できるコントリビューターのみ推奨）

{
  "webhook": {
    "payloadUrl": "https://codebuild.us-west-2.amazonaws.com/webhooks",
    "filterGroups": [
      [
        {
          "type": "EVENT",
          "pattern": "PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED",
          "excludeMatchedPattern": false
        },
        {
          "type": "GITHUB_ACTOR_ACCOUNT_ID",
          "pattern": "^(12345678|87654321|11223344)$",
          "excludeMatchedPattern": false
        }
      ]
    ]
  }
}

この設定により、特定の信頼できるコントリビューターからのプルリクエストのビルドが可能になります。

重要: フィルタリングは GitHub のアカウント ID に適用され、リポジトリの所有権には適用されません。フォークされたリポジトリから作業するコントリビューターは、ビルド環境で実行される信頼できないコードを引き続き持ち込める可能性があります。

環境でこれらの設定を実装する前に、スムーズな移行を促進するのに役立つ以下の重要な要素を検討してください。

Webhook 設定の実装手順

以下のWebhook セキュリティ対策を実装する際は、次のようなより広範なプラクティスを考慮してください：

脅威モデリング: アプローチを選択する前に、特定のリスクプロファイルを評価します。
Infrastructure as Code : 本番環境の実装には Infrastructure as Code（IaC）ツールを使用します。
段階的な実装: 観察期間を設けて変更を段階的に実装します。
テストとロールバック: 非本番環境で最初に変更を検証します。

以下の実装アプローチは、最も制限的なものからより自動化された設定へと移行します。組織のリスク許容度と運用要件に最も適したアプローチを選択してください。
この3段階のプロセスは、セキュリティコントロールを維持しながら最も制限的なアプローチからより自動化された設定へと移行します。各ステップは前のステップに基づいて構築され、パイプラインを保護するための多層的なセキュリティ対策を作成します。

注: 以下の例は、 AWS CLI を使用して説明します。同様の設定手順は、 AWS CodeBuild のプロジェクト設定から AWS マネジメントコンソールを使用して実行することも可能です。

ステップ1: プッシュのみのビルドを設定

プッシュベースのビルドは、検証されたコントビューターのみがビルドをトリガーできることを確実にします。このアプローチは、コントリビューターがコードをプッシュする前に、リポジトリのアクセス制御メカニズムを通じてすでに検査されている必要があるため、より安全です。
プッシュイベントでのみトリガーされるように Webhook を設定します：

aws codebuild update-webhook \
  --project-name your-project-name \
  --filter-groups '[
    [
      {
        "type": "EVENT",
        "pattern": "PUSH",
        "excludeMatchedPattern": false
      }
    ]
  ]'

ステップ2: ブランチベースのフィルタリングを実装

ブランチベースのフィルタリングは、特定のブランチへの変更に対してのみビルドがトリガーされることを確実にすることで、さらにセキュリティの層を追加します。このアプローチは、リポジトリ内のすべてのブランチが同じセキュリティ要件やリスクプロファイルを持つわけではないことを考慮しています。

例えば、 main や本番ブランチへの変更は、通常、フィーチャーブランチや開発ブランチへの変更よりも厳格なセキュリティ制御を必要とします。ブランチベースのフィルタリングを実装することで、各ブランチの重要性や公開範囲に基づいて、適切なセキュリティ対策を適用できます。

特定のブランチに対するフィルタリングを設定します：

aws codebuild update-webhook \
  --project-name your-project-name \
  --filter-groups '[
    [
      {
        "type": "EVENT",
        "pattern": "PUSH"
      },
      {
        "type": "HEAD_REF",
        "pattern": "^refs/heads/(main|develop|release/.*)$"
      }
    ]
  ]'

ステップ3: コントリビューターのフィルタリングを設定

コントリビューターフィルタリングは、信頼できるコントリビューターに対しては自動化を許可し、その他のコントリビューターに対しては手動レビューを要求することで、プルリクエストのビルドを管理できます。このアプローチは、コントリビューターごとにリスクプロファイルが異なることを考慮し、それに応じた対応を行うものです。

コントリビューターフィルタリングを実装する最初のステップは、信頼できるコントリビューターの GitHub のユーザー ID を特定することです。

信頼できるコントリビューターの GitHub ユーザー ID を取得します：

curl -H "Authorization: token YOUR_GITHUB_TOKEN" \
https://api.github.com/users/trusted-username

信頼できるコントリビューターのユーザー ID を取得したら、これらのコントリビューターに対してのみ自動ビルドを許可するように Webhook のフィルタリングを設定できます：

aws codebuild update-webhook \
  --project-name your-project-name \
  --filter-groups '[
    [
      {
        "type": "EVENT",
        "pattern": "PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED"
      },
      {
        "type": "GITHUB_ACTOR_ACCOUNT_ID",
        "pattern": "^(1234567|2345678|3456789)$"
      }
    ]
  ]'

重要: コントリビューターの許可リストは、チームメンバーの変更に応じて継続的なメンテナンスが必要です。バージョン管理で Webhook の設定とコントリビューターリストを管理するために、 CloudFormation の例のような Infrastructure as Code テンプレートの使用を検討してください。

Webhook フィルタリングは、どのイベントがビルドをトリガーするかを制御することで、最初のセキュリティレイヤーを提供します。ただし、包括的なパイプラインセキュリティには、ビルドが実行時に利用可能な権限と認証情報に関する追加の制御が必要です。次のセクションでは、適切なアクセス制御と認証情報管理を通じて多層的なセキュリティを実装する方法について説明します。

アクセス制御と認証情報管理

このセクションでは、ビルドプロセスで利用可能な権限を制限し、リポジトリアクセストークンに適切に権限範囲を設定し、潜在的なセキュリティ問題を封じ込めるための分離環境を作成する具体的なアプローチについて説明します。これらのプラクティスは、自動化された CI/CD ワークフローの運用上のメリットを維持しながら、多層的なセキュリティ対策を実装するために連携して機能します。

最小権限アクセスの実装

AWS CodeBuild プロジェクトは、ビルドプロセス中に AWS リソースにアクセスするために IAM サービスロールが必要です。最小権限の原則では、各ロールは意図された機能を実行するために必要な最小限の権限のみを持つべきです。異なるタイプのビルドに対して、目的に応じた個別の IAM ロールを作成することで、ビルド環境への不正アクセスの潜在的な影響を軽減できます。

以下の例は、異なるビルドシナリオに対する最小限の IAM ロールを構造化する方法を示しています。これらの例は、特定の要件に基づいてカスタマイズし、ビルドが実際に必要とする権限のみを追加する出発点として機能します。

サービスロール設定

特定のビルドタイプに必要な権限のみを提供する最小限の IAM ロールを作成します：

テスト/検証ビルドロール

{
    "Version": "2012-10-17",
    "Statement": [
    {
        "Effect": "Allow",
        "Action": [
            "logs:CreateLogGroup",
            "logs:CreateLogStream",
            "logs:PutLogEvents"
        ],
        "Resource": "arn:aws:logs:*:*:log-group:/aws/codebuild/test-*"
    },
    {
    "Effect": "Allow",
    "Action": [
        "s3:GetObject"
    ],
    "Resource": "arn:aws:s3:::your-test-artifacts-bucket/*"
  }
 ]
}

リリースビルドロール（テスト用とは別に作成）

{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
            "s3:PutObject",
            "s3:GetObject"
        ],
        "Resource": "arn:aws:s3:::your-production-artifacts-bucket/*"
      },
      {
        "Effect": "Allow",
        "Action": [
            "ecr:BatchCheckLayerAvailability",
            "ecr:GetDownloadUrlForLayer",
            "ecr:BatchGetImage",
            "ecr:PutImage"
        ],
        "Resource": "arn:aws:ecr:*:*:repository/your-production-repo"
      }
    ]
}

CodeBuild セキュリティのための IAM Access Analyzer の活用

AWS IAM Access Analyzer は、ビルド実行時の実際の CloudTrail アクティビティに基づいて、 AWS CodeBuild サービスロールの最小権限ポリシーを生成できます。これはビルドが行う特定のAWS API呼び出しを分析することで、必要な権限を予測するための推測で行う作業を排除します。

CodeBuild プロジェクトを一定期間実行した後、 Access Analyzer のポリシー生成機能を使用して最適化されたポリシーを作成します。このアプローチは、必要な権限がすぐにはわからない複雑なビルドプロセスに特に価値があります。

詳細な実装手順については、 IAM Access Analyzer のドキュメントを参照してください。

認証情報の権限範囲と送信元認証

外部からのコントリビューションを処理する際、リポジトリアクセストークンに対する最小権限の原則が重要になります。不正なユーザーが信頼できないビルドを通じてトークンにアクセスした場合、トークンが適切に権限範囲設定されていれば、ビルドプロセスに必要な権限のみに潜在的な影響を制限できます。

このリスクを軽減するために、最小限の権限で GitHub のFine-grained Personal Access Token を設定します。不適切にアクセスされた場合でも、適切な権限範囲を持つトークンは、ソースコード（プルリクエストを通じてすでにアクセス可能）の読み取りとステータスメッセージの書き込みのみが可能です。コードのプッシュ、リポジトリ設定の変更、または他のリポジトリへのアクセスはできません。

以下の権限は、外部からのプルリクエストを処理するために必要な最小限のアクセスを表し、トークンの権限範囲を必須の操作のみに制限する方法を示しています：

contents:read – リポジトリソースコードへの読み取り専用アクセス（プルリクエストを通じてすでにアクセス可能）
statuses:write – コミットステータスメッセージの書き込みのみ（コードや設定の変更は不可）
metadata:read – 基本的なリポジトリ情報（名前、説明、公開ステータス）へのアクセス

重要: 対象リポジトリのみに制限された Fine-grained Personal Access Token を使用してください。そうしないと、ビルドプロセスに必要な範囲を超えて他のリポジトリへのアクセスを許可してしまう可能性があります。

この権限範囲を設定するアプローチにより、トークンが不適切にアクセスされた場合でも、その潜在的な影響は、すでにアクセス可能な情報の読み取りとステータスメッセージの書き込みに限定されます。このトークンは、コードのプッシュ、リポジトリ設定の変更、Webhookの作成、または他のリポジトリへのアクセスはできません。

認証情報の保存とローテーション

以下の例は、AWS Secrets Manager を使用してこれらのトークンを安全に保存および参照する方法を示しています。AWS Secrets Manager は、自動ローテーション機能、保存時および転送時の暗号化、ビルドログや設定ファイルでトークンが公開されることを防ぐきめ細かなアクセス制御を提供します。このアプローチにより、トークンアクセスの監査証跡を維持しながら、複数の CodeBuild プロジェクト間での一元的なトークン管理も可能になります。

# Fine-grained トークンをAWS Secrets Managerに保存
aws secretsmanager create-secret \
--name "codebuild/github-pat-limited" \
--description "Limited GitHub PAT for external PR processing" \
--secret-string '{"token":"ghp_your_limited_token_here"}'

# 権限範囲が設定された認証情報で CodeBuild プロジェクトを作成
aws codebuild create-project \
--name external-pr-processor \
--source '{
"type": "GITHUB",
"location": "https://github.com/your-org/your-repo.git",
"sourceCredentialsOverride": {
"serverType": "GITHUB",
"authType": "PERSONAL_ACCESS_TOKEN",
"token": "{{resolve:secretsmanager:codebuild/github-pat-limited:SecretString:token}}"
},
"reportBuildStatus": false
}' \
--service-role arn:aws:iam::account:role/minimal-test-build-role

一元化されたストレージにより、認証情報のローテーションが可能になり、インフラストラクチャの更新が必要なハードコードされたトークンと比較して、露出期間を最小限に抑えることができます。

ビルド環境の分離

適切なビルド環境のセキュリティ管理を確立することで、パイプラインの完全性を維持できます。このアプローチの基礎となるのは、テストビルドとリリースビルドの分離を実装することです。これにより、認証情報の権限昇格を防ぎ、潜在的な不正アクセスの範囲を制限することができます。

ネットワーク分離は、もう一つの保護層です。外部コードを処理するビルド専用の VPC を、慎重に制限されたアウトバウンドアクセスを持つ専用のセキュリティグループを作成して設定します。これらのセキュリティグループは、正当な依存関係をダウンロードするための HTTPS トラフィックなど、必要な接続のみを許可し、信頼できないコードによって悪用される可能性がある不要なネットワークアクセスをブロックする必要があります。

AWS CodeBuild プロジェクトを更新し、指定されたサブネットと制限されたセキュリティグループを含む適切な VPC 設定を使い、このネットワーク分離を活用するようにします。

人によるレビューゲートを持つマルチステージパイプラインセキュリティ

複数のパイプラインステージにわたるセキュリティコントロールの実装は、特に外部からのコントリビューションを処理する際に、適切な検証と承認プロセスを提供するのに役立ちます。このアプローチは、自動スキャンと人による監視を組み合わせて、本番環境に到達する前に問題を特定します。

コード検査の統合

ビルドプロセス中に Automated Security Helper などのセキュリティツールを自動的に実行するようにビルド仕様を設定しましょう。これらのツールは、コードセキュリティ問題と依存関係の問題をスキャンし、レビュー用の詳細なレポートを生成します。

すべてのスキャンが完了できるように、問題が見つかった場合でもビルドを最後まで続行するように構成した上で、対応が必要なセキュリティ上の問題が含まれるビルドは自動的に失敗させるようにします。すべてのスキャンの成果物を保存して、セキュリティチームに承認判断のための詳細情報を提供します。

手動承認によるゲート

コードが自動セキュリティスキャンに合格した後、最終検証のために人間のレビュアーを関与させる手動承認ゲートを設定します。これにより、機密性の高い環境に進む前に適切な人間によるレビューを確保できます。

このセクションで解説されたアクセス制御と認証情報管理のプラクティスは、 AWS CodeBuild のパイプラインの多層防御セキュリティを実装するための具体的で実用的なアプローチを提供します。これらの制御は連携して複数の保護層を作成し、 CI/CD による自動化を価値あるものにする運用上の利点を維持します。

代替アプローチ – GitHub Actions のセルフホステッドランナー

AWS CodeBuild の GitHub Actions セルフホステッドランナー機能は、リポジトリ認証情報をビルド環境から分離し、 AWS CodeBuild Webhook 処理の代わりに GitHub Actions の実行フレームワークを使用することで、このガイドで説明した設定の問題に対処します。

外部からのコントリビューションを自動的に処理する必要がある組織では、適切なアクセス制御でランナーを設定し、永続的なアクセスを最小限に抑えるために一時的なランナーを使用し、ランナー管理の標準的なセキュリティ対策を適用してください。

設定の詳細は、AWS CodeBuild ドキュメントをご覧ください。追加の実装ガイダンスについては、AWS CodeBuild Managed Self-Hosted GitHub Action Runners のブログ投稿をご参照ください。

監視とコンプライアンス

前のセクションで説明したセキュリティコントロールは、ビルド時の保護を提供しますが、包括的な多層防御セキュリティには、パイプラインのアクティビティと設定変更への継続的な可視化が必要です。監視とコンプライアンスの追跡は、セキュリティフレームワークの最終層として機能し、設定の逸脱の検出、アクセスパターンの監査、長期的なセキュリティ体制の維持に役立ちます。

AWS CloudTrail は、AWS CodeBuild を含む AWS サービスに対して行われた API 呼び出しの詳細なログを提供します。CloudTrail ログを有効にすることで、環境内のすべてのビルド関連アクティビティの包括的な監査証跡を作成できます。

AWS Config は、AWS CodeBuild プロジェクトの構成を時系列で追跡し、プロジェクトのインベントリと設定変更の完全な履歴を提供します。これには、Webhook の変更、リソースの関係性、環境全体でのコンプライアンス追跡が含まれます。AWS Config を設定して、AWS CodeBuild プロジェクトを監視し、Webhook フィルターなどのセキュリティ上重要な設定が変更されたときに通知を受け取るようにすることができます。詳細については、AWS CodeBuild のドキュメントにあるAWS Config のサンプルをご参照ください。

結論

AWS CodeBuild パイプラインの多層防御のセキュリティ対策を実装するには、さまざまなセキュリティ考慮事項に対処する階層化された制御が必要です。最も効果的なアプローチは、Webhook フィルタリング、アクセス制御、認証情報管理、監視を組み合わせて包括的な保護を提供することです。このガイドで説明したこれらの多層的なプラクティスを実装することで、堅牢なパイプラインセキュリティを確立しながら開発速度を維持できます。
覚えておくべき重要な原則：

まず脅威モデルを評価する – 異なるプロジェクトには異なるセキュリティアプローチが必要です
異なるタイプのコントリビューター間で明確な信頼境界を確立する
Webhookフィルタリングを使用してビルドがトリガーされるタイミングを制御する
ビルド環境に最小権限アクセスを実装する
AWS Config とCloudTrail を使用して設定を定期的に監視および監査する
AWS Secrets Manager または SSM Parameter Store にシークレットを保存し、ローテーションを有効にする

AWS CodeBuild は、パイプラインを価値あるものにする運用上のメリットを維持しながら、これらのセキュリティ対策を実装する柔軟性を提供します。特定のリスクプロファイルと運用要件に基づいて、このガイドの設定と軽減策を適用してください。組織のニーズが進化する中でパイプラインのセキュリティを維持するために、定期的な設定の確認と更新が役立ちます。

CI/CDセキュリティベストプラクティスを実装するための追加の実用的なガイドにご期待ください。この投稿について質問やフィードバックがある場合、最も役立つトピックの提案を含めて、re:Post : Begimher で新しいスレッドを開始するか、AWS サポートにお問い合わせください。

翻訳は、ソリューションアーキテクトの金森が担当しました。原文はこちらです。

Amazon Web Services ブログ