AWS CodeBuildのセキュリティ基本設定 - 初心者向け安全な運用ガイド ​

CodeBuildを安全に使うためには、適切なセキュリティ設定が重要です。初心者向けに、基本的な権限設定から機密情報の保護まで、安全な運用に必要な知識をわかりやすく解説します。

セキュリティの基本概念 ​

なぜセキュリティが重要なのか ​

CodeBuildは本番環境のコードを扱うため、以下のリスクがあります：

セキュリティの3つの基本原則 ​

  1. 最小権限の原則: 必要最小限の権限のみを付与
  2. 機密情報の分離: パスワードなどを安全に管理
  3. 監視とログ: 何が実行されたかを記録

権限設定の基本 ​

IAMロールとは何か ​

IAMロールは、「CodeBuildが他のAWSサービスにアクセスするための許可証」のようなものです。

基本的な権限設定 ​

最小限の権限例 ​

CodeBuildで一般的に必要な基本権限：

  1. CloudWatch Logs: ビルドログを出力する権限
  2. S3: ビルド結果を保存する権限
  3. ECR: Dockerイメージを取得する権限（必要な場合）

AWSコンソールでの権限設定 ​

CodeBuildプロジェクト作成時の権限設定：

  1. サービスロールの選択: 「新しいサービスロールを作成」を選択
  2. 自動権限付与: AWSが必要な基本権限を自動設定
  3. 追加権限: 必要に応じて後から追加

機密情報の安全な管理 ​

パスワードやAPIキーの問題 ​

建设spec.ymlに直接パスワードを書くのは危険です。

AWS Secrets Managerの使用 ​

1. シークレットの作成 ​

AWSコンソールで機密情報を安全に保存：

  1. Secrets Managerサービスにアクセス
  2. 新しいシークレットを作成
  3. キーと値を設定（例: database_password: mypassword123）
  4. 名前を設定（例: my-app-secrets）

2. buildspec.ymlでの使用 ​

yaml
version: 0.2

env:
  secrets-manager:
    DB_PASSWORD: my-app-secrets:database_password
    API_KEY: my-app-secrets:api_key

phases:
  pre_build:
    commands:
      - echo "機密情報を安全に取得しました"
      # パスワードは表示されないが、環境変数として使用可能
      
  build:
    commands:
      - npm install
      - npm run build

Parameter Storeの使用 ​

機密性が低い設定値（URLやデフォルト値など）に使用します。

基本的な使用例 ​

yaml
env:
  parameter-store:
    API_URL: /myapp/api/url
    DATABASE_HOST: /myapp/database/host
    TIMEOUT_SECONDS: /myapp/config/timeout

phases:
  build:
    commands:
      - echo "設定値を取得しました"
      - npm run build

ネットワークセキュリティの基本 ​

プライベートネットワークでの実行 ​

大切なデータベースや内部システムにアクセスする場合は、プライベートネットワーク（VPC）内でCodeBuildを実行できます。

VPC設定の基本考え方 ​

いつVPCが必要か:

  • 社内データベースにアクセスする場合
  • 内部APIやシステムを使用する場合
  • 特別なセキュリティ要件がある場合

設定方法の概要:

  1. VPCとサブネットの指定
  2. セキュリティグループの設定
  3. 必要な権限の追加

安全なプロジェクト設定の実例 ​

Webサイトプロジェクトの安全設定 ​

プロジェクトの概要： 企業のコーポレートサイトで、外部APIとの連携やコンタクトフォーム機能があるケース。

セキュリティ設定のポイント：

  • 環境変数の適切な分類: NODE_ENVなどの一般的な設定はvariablesセクションで直接指定
  • APIキーの安全管理: 外部サービスのAPIキーはSecrets Managerで管理
  • URLのパラメータ化: APIのURLはParameter Storeで管理し、環境別の切り替えを容易に
  • エラーハンドリング: 機密情報が取得できない場合の適切なエラー処理

buildspec.ymlの基本構造： 安全な設定では、envセクションで情報の種類ごとに適切な取得方法を指定し、phasesでは機密情報を表示せずに存在確認のみ行います。

APIアプリケーションの安全設定 ​

プロジェクトの概要： バックエンドAPIアプリケーションで、データベースや外部サービスとの連携が必要なケース。

セキュリティ設定の重要ポイント：

  • データベース認証: パスワード、JWTシークレットなどは必ずSecrets Managerで管理
  • 接続確認: パスワードを表示せずに、接続テストで認証情報の有効性を確認
  • タイムアウト設定: 長時間の接続待ちでビルドが停止しないよう適切なタイムアウトを設定
  • エラーハンドリング: データベース接続失敗時の適切なエラー処理

実践的なセキュリティ設定 ​

良い例（安全） ​

yaml
version: 0.2

env:
  secrets-manager:
    DB_PASSWORD: my-app-secrets:password  # 機密情報は安全に取得
  parameter-store:
    DB_HOST: /myapp/database/host  # 設定値はParameter Store
  variables:
    NODE_ENV: production  # 公開しても良い設定値

phases:
  pre_build:
    commands:
      - echo "設定確認中"  # パスワードは表示しない
      
  build:
    commands:
      - npm install
      - npm run build

避けるべき例（危険） ​

yaml
# ❌ このような書き方は避ける
env:
  variables:
    DB_PASSWORD: "mypassword123"  # 危険：パスワードが見える
    API_KEY: "secret-key-123"     # 危険：APIキーが見える

権限の段階的設定 ​

初心者は、まず基本的な権限から始めましょう。

よくあるセキュリティ問題と対策 ​

Q1: buildspec.ymlにパスワードを書いてしまった ​

危険度: 高（すぐに対処が必要）

対処方法:

  1. Gitの履歴からパスワードを削除
  2. パスワードを変更
  3. Secrets Managerに正しく設定

Q2: 他の人がビルドを実行できてしまう ​

原因: CodeBuildプロジェクトの権限設定が広すぎる

対処方法:

  1. プロジェクトへのアクセス権限を制限
  2. 必要な人のみにアクセス許可

Q3: ビルドログに機密情報が表示される ​

原因: echoコマンドで機密情報を出力している

対処方法: 機密情報は表示せず、存在確認のみ行う

yaml
phases:
  pre_build:
    commands:
      # ❌ 危険：パスワードが表示される
      # echo "Password: $DB_PASSWORD"
      
      # ✅ 安全：存在確認のみ
      - |
        if [ -n "$DB_PASSWORD" ]; then
          echo "データベースパスワードが設定されています"
        else
          echo "エラー: データベースパスワードが設定されていません"
        fi

チーム開発でのセキュリティ ​

役割分担の基本 ​

安全なチーム運用のコツ ​

1. 機密情報の共有方法 ​

2. コードレビューでのチェックポイント ​

  • buildspec.ymlに機密情報が含まれていないか
  • 必要以上の権限を要求していないか
  • セキュリティ上問題のある処理がないか

実際の安全な設定例 ​

セキュリティ設定のベストプラクティス ​

機密情報管理の階層化 ​

初心者が陥りやすい問題として、すべての設定情報を同じように管理してしまうことがあります。適切なセキュリティ設定では、情報の機密レベルに応じて管理方法を使い分けることが重要です。

管理方法の使い分け指針：

  1. 公開設定（variables）: ソースコードに含めても問題ない情報

    • 環境名（production、staging）
    • アプリケーションのバージョン番号
    • パブリックなライブラリの設定値

  2. 設定情報（parameter-store）: 機密性は低いが環境ごとに異なる設定

    • APIエンドポイントのURL
    • データベースのホスト名
    • タイムアウト値やサイズ制限

  3. 機密情報（secrets-manager）: 絶対に外部に漏れてはいけない認証情報

    • データベースのパスワード
    • 第三者サービスのAPIキー
    • 暗号化に使用するシークレットキー

AWSコンソールでの設定手順 ​

Secrets Managerの設定：

  1. AWSコンソールでSecrets Managerサービスにアクセス
  2. 「新しいシークレットを作成」を選択
  3. 機密情報をキー・バリュー形式で入力
  4. CodeBuildからアクセスできるよう適切な権限を設定

Parameter Storeの設定：

  1. Systems ManagerのParameter Storeにアクセス
  2. パラメータ名を階層構造で命名（例：/myapp/api/url）
  3. 環境ごとに異なる値を設定
  4. CodeBuildに必要な読み取り権限を付与

安全なbuildspec.yml作成のポイント ​

buildspec.ymlでは、機密情報を直接記述せず、適切なAWSサービスから取得するよう設定します。また、ログ出力時も機密情報が表示されないよう注意が必要です。特に重要なのは、機密情報の存在確認はするが値自体は表示しないということです。

監視とログの活用 ​

基本的な監視内容 ​

ログとモニタリングの実践方法 ​

AWSコンソールでのログ確認 ​

日常的なログチェックの手順：

  1. CodeBuild実行履歴の確認: AWSコンソールのCodeBuildサービスで、プロジェクトの「ビルド履歴」タブを選択
  2. 実行者の確認: 各ビルドの「開始者」欄で、誰がビルドを実行したかを確認
  3. CloudWatch Logsでの詳細確認: ビルドの詳細ログやエラー情報を確認
  4. パターン分析: 異常な実行パターンやエラーの傾向を特定

異常な状況の例：

  • 通常と異なる時間帯でのビルド実行
  • 未知のユーザーによるビルド実行
  • 短時間での連続ビルド実行
  • 特定のエラーメッセージの頻発

セキュリティログの出力方法 ​

セキュリティ目的のログ出力では、機密情報を表示せずに、ビルドの実行状況やアクセス情報のみを記録します。buildspec.ymlでは、AWSが提供する環境変数を活用して、実行者、ソースリポジトリ、ブランチなどの情報を安全にログ出力できます。

セキュリティログの目的：

  • ビルドのトレーサビリティ確保
  • 不正アクセスの早期発見
  • コンプライアンス要件への対応
  • 問題発生時の原因調査支援

セキュリティのベストプラクティス ​

日常的に気をつけること ​

セキュリティチェックリスト ​

プロジェクト作成時 ​

  • [ ] 必要最小限の権限のみ設定
  • [ ] 機密情報はSecrets Managerに保存
  • [ ] buildspec.ymlに機密情報を記述していない
  • [ ] 適切なタグを設定（管理用）

定期的な確認 ​

  • [ ] 不要になった権限の削除
  • [ ] 機密情報の定期更新
  • [ ] ビルドログの異常確認
  • [ ] アクセス権限の見直し

緊急時の対応 ​

機密情報が漏洩した場合 ​

対応手順 ​

  1. 即座の対応（5分以内）

    • 漏洩した機密情報の無効化
    • 新しい機密情報の生成

  2. 短期対応（1時間以内）

    • CodeBuildプロジェクトの設定更新
    • 影響範囲の確認

  3. 長期対応（1日以内）

    • 再発防止策の実施
    • チームへの教育・共有

まとめ ​

CodeBuildの安全な運用は、基本的なセキュリティ原則を守ることから始まります。

セキュリティの重要ポイント ​

  • 機密情報の適切な管理: パスワードやAPIキーは安全な場所に保存
  • 最小権限の原則: 必要最小限の権限のみ付与
  • 定期的な確認: 権限設定やログの定期チェック
  • チーム教育: メンバー全員のセキュリティ意識向上

始めるときの手順 ​

  1. 基本権限の設定: AWSが推奨する最小権限から開始
  2. 機密情報の移行: buildspec.ymlからSecrets Managerへ移行
  3. 監視の設定: CloudWatch Logsでビルド状況を確認
  4. 定期的な見直し: 月1回程度の権限とログ確認

適切なセキュリティ設定により、安心してCodeBuildを活用できる環境を構築しましょう。