シークレット露出対策 - クラウドでのシークレット値露出対策
AWS Secrets Manager / Azure Key Vault / GCP Secret Manager の使い分け、環境変数・.env ファイル・ハードコードの危険性、CI/CD パイプラインでの漏洩パターン、GitGuardian 等のシークレットスキャン、Parameter Store vs Secrets Manager の選択基準。
概念図
攻撃シナリオ
.env ファイルの誤コミットによるクレデンシャル漏洩
bash
# .env ファイルがそのまま Git に push された例
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
DATABASE_URL=postgres://admin:P@ssw0rd@prod-db.example.com:5432/mainCI/CD ログへのシークレット露出
bash
# GitHub Actions のログにシークレットが露出するパターン
steps:
- run: echo "Deploying with key ${{ secrets.AWS_SECRET_KEY }}"
# ログマスキングが効かないケース:
- run: printenv | base64Docker イメージレイヤーへのシークレット埋め込み
bash
# Docker イメージのレイヤーにシークレットが残る例
FROM node:20
ENV DB_PASSWORD=SuperSecret123
RUN npm install
# docker history で ENV レイヤーからパスワードが復元可能シークレット管理の危険パターンと安全なアプローチ
クラウド環境でのシークレット（API キー、DB パスワード、証明書、トークン等）の扱い方を誤ると、単一のミスが全環境の侵害に直結する。
まず「やってはいけないこと」を明確にし、次に安全な代替手段を示す。
| 危険パターン | リスク | 発生頻度 | 安全な代替手段 |
|---|---|---|---|
| ソースコードへのハードコード | Git 履歴に永続的に残り、リポジトリ公開時に即座に漏洩 | 非常に高い | シークレットマネージャーからランタイムで取得 |
| .env ファイルの Git コミット | .gitignore 漏れで push → 自動クローラーが数分で悪用 | 高い | .gitignore 必須 + pre-commit フックでブロック |
| 環境変数への直接設定 | プロセス一覧・クラッシュダンプ・ログ出力で露出するリスク | 中程度 | シークレットマネージャーの参照 ARN/URI を環境変数に設定し、アプリ起動時に resolve |
| CI/CD の Secret 変数 | ログマスキング不備・printenv・デバッグモードで露出 | 中程度 | OIDC フェデレーションで一時クレデンシャル化。長期シークレットは Vault 経由で取得 |
| Docker イメージへの埋め込み | docker history / レイヤー展開でシークレットが復元可能 | 中程度 | マルチステージビルド + BuildKit --mount=type=secret |
| Terraform state へのシークレット混入 | state ファイルに平文でパスワードが記録される | 高い | state の暗号化バックエンド必須 + sensitive = true 指定 |
GitHub には毎日数千件規模でシークレットが誤コミットされており、GitGuardian の 2024 年レポートによれば、パブリックリポジトリへのシークレット漏洩は前年比 28% 増加している。
3 大クラウドのシークレットマネージャー比較
AWS・Azure・GCP はそれぞれ専用のシークレット管理サービスを提供しており、用途に応じて使い分ける。
| 比較項目 | AWS Secrets Manager | AWS Systems Manager Parameter Store | Azure Key Vault | GCP Secret Manager |
|---|---|---|---|---|
| 主な用途 | DB クレデンシャル、API キー、OAuth トークン | 設定値、フィーチャーフラグ、非機密パラメータ | シークレット、鍵、証明書の統合管理 | シークレット値の保管・バージョン管理 |
| 自動ローテーション | Lambda ベースの自動ローテーション（RDS/Redshift/DocumentDB はネイティブ対応） | なし（Lambda で自作は可能） | 証明書の自動ローテーション対応。シークレットは Event Grid + Function で自作 | なし（Cloud Functions で自作は可能） |
| 暗号化 | AWS KMS（CMK 指定可） | AWS KMS（SecureString タイプ） | Azure Key Vault HSM / ソフトウェアキー | Google Cloud KMS（CMEK 対応） |
| バージョン管理 | 自動バージョニング | バージョン履歴あり | バージョン管理あり | バージョン管理あり |
| アクセス制御 | IAM ポリシー + リソースポリシー | IAM ポリシー + パラメータ階層パス | Azure RBAC + Key Vault アクセスポリシー | IAM ポリシー（Secret 単位） |
| 料金 | $0.40/シークレット/月 + API 呼び出し課金 | Standard 無料、Advanced $0.05/パラメータ/月 | トランザクション課金（シークレット操作 $0.03/10,000 件） | $0.06/バージョン/月 + API 呼び出し課金 |
| 監査 | CloudTrail | CloudTrail | Azure Monitor / Diagnostic Logs | Cloud Audit Logs |
AWS での Parameter Store vs Secrets Manager の選択基準:
| 判断基準 | Parameter Store（Standard） | Secrets Manager |
|---|---|---|
| 自動ローテーションが必要 | 不可（自作 Lambda は可能） | ネイティブ対応 |
| RDS のパスワード管理 | 手動管理 | RDS との統合ローテーション |
| コスト重視 | 無料（Standard） | 有料（$0.40/シークレット/月） |
| 設定値とシークレットの混在 | 階層パスで整理可能 | シークレット専用 |
| クロスアカウント共有 | リソースポリシー非対応 | リソースポリシーで共有可能 |
実務では「設定値・フィーチャーフラグは Parameter Store、DB パスワード・API キーは Secrets Manager」という使い分けが一般的である。
CI/CD パイプラインでの漏洩パターンと対策
CI/CD はシークレットが集中する最もリスクの高いポイントの一つである。
ビルドログ・アーティファクト・一時ファイルからの漏洩を構造的に防ぐ必要がある。
| 漏洩パターン | 具体例 | 対策 |
|---|---|---|
| ビルドログへの出力 | echo $SECRET や printenv でログに平文出力 |
CI プラットフォームのシークレットマスキング機能を有効化。set +x でコマンドエコー抑制 |
| デバッグモードの有効化 | GitHub Actions の ACTIONS_STEP_DEBUG=true でマスキングが無効化される |
デバッグモードは一時的かつ限定的に使用。本番パイプラインでは禁止 |
| フォーク PR からのシークレット読み取り | フォーク元の PR でシークレットにアクセスできる設定 | pull_request_target の使用を厳格に制限。フォーク PR にはシークレットを渡さない |
| アーティファクトへの混入 | ビルド成果物にシークレットを含むファイルが紛れ込む | .dockerignore / artifact-ignore で除外。ビルド後にシークレットファイルを削除 |
| 長期アクセスキーの Secret 登録 | AWS Access Key を GitHub Secrets に保存 | OIDC フェデレーションで一時クレデンシャル化（GitHub Actions → aws-actions/configure-aws-credentials） |
OIDC フェデレーションによる脱・長期シークレット:
| CI/CD プラットフォーム | AWS | Azure | GCP |
|---|---|---|---|
| GitHub Actions | aws-actions/configure-aws-credentials + OIDC Provider |
azure/login + Federated Credential |
google-github-actions/auth + Workload Identity Federation |
| GitLab CI | CI/CD Variables + OIDC Token | OIDC Token + Federated Credential | OIDC Token + Workload Identity Federation |
| CircleCI | OIDC Token + AssumeRoleWithWebIdentity | OIDC Token | OIDC Token + Workload Identity Federation |
各プラットフォームとも OIDC フェデレーションに対応しており、リポジトリ・ブランチ単位で信頼ポリシーを絞ることで、CI/CD 環境に長期シークレットを一切置かない構成が実現できる。
シークレットスキャンツールの導入
シークレットの漏洩を「事前に防ぐ」ためのスキャンツールを開発フローに組み込む。
Git の pre-commit フック、CI パイプライン、リポジトリの push 保護の 3 層で多重防御する。
| ツール | 種別 | 特徴 | 対応パターン数 |
|---|---|---|---|
| GitHub Secret Scanning | リポジトリスキャン（GitHub ネイティブ） | push protection で push 前にブロック可能。パートナーパターン連携で自動無効化 | 200+ |
| GitGuardian | SaaS / CLI | リアルタイム検知 + 修復ワークフロー。GitHub / GitLab / Bitbucket 対応。無料プランあり | 400+ |
| gitleaks | CLI / pre-commit / CI | 軽量な OSS ツール。正規表現ベースのカスタムルール追加が容易 | 150+ |
| truffleHog | CLI / CI | エントロピー分析 + 正規表現。Git 履歴全体のスキャンに強い | 800+ |
| detect-secrets | CLI / pre-commit | Yelp 製 OSS。ベースラインファイルで既知のシークレットを管理 | 20+ |
推奨する多層防御構成:
- pre-commit フック（gitleaks / detect-secrets）: 開発者のローカルで即座にブロック
- CI パイプライン（truffleHog / gitleaks）: PR マージ前に全コミットをスキャン
- リポジトリ push 保護（GitHub Secret Scanning / GitGuardian）: push 時にサーバー側でブロック
この 3 層を重ねることで、仮に 1 層を突破しても次の層で検知・ブロックできる。
関連トピック
クラウドセキュリティの考え方- クラウド（AWS/Azure/GCP）のセキュリティを設計するうえで必須となる責任共有モデル・ゼロトラスト・ガードレール・最小権限・多層防御の基本原則。 シークレット管理- API キー、パスワード、証明書などの機密情報を安全に保管・配布・ローテーションする仕組み。ハードコーディングの防止が基本。 AWS IAM ベストプラクティス- ルートユーザー保護・IAM Identity Center による SSO 集約・ロール中心設計・最小権限・MFA 強制など、AWS IAM の設計と運用における推奨設定を整理。 AWS でよくある設定ミス・ヌケモレ- S3 の公開、Security Group の 0.0.0.0/0、IMDSv1、認証情報のハードコード、ログ未取得など、AWS で繰り返し発生する典型的な設定ミスと検知・修正のチェックリスト。 クラウドへのセキュアなアクセス- AWS SSO / SSM Session Manager / IAM Identity Center など、ゼロトラストを意識したクラウドインフラへの接続方式。SSH 鍵の直接管理や踏み台サーバーに頼らない運用を実現する。