ストーリー

シークレットとは

シークレットの種類

シークレット漏洩の統計

シークレット管理のアンチパターン

避けるべきパターン

危険なパターン:

// ハードコード（最悪）
const apiKey = "sk-live-abc123def456";

// .env ファイル（git管理外でも危険）
// .env
DATABASE_URL=postgres://user:password@host:5432/db

// CI/CD の環境変数（改善の余地あり）
env:
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  # → プロセス環境変数として全サブプロセスに公開

// 推奨パターン
// アプリケーション起動時にVaultから動的取得
const dbPassword = await vault.read("secret/data/myapp/database");

シークレット管理のアーキテクチャ

理想的なアーキテクチャ

シークレット管理の階層:

Layer 1: シークレットストア（Source of Truth）
├── HashiCorp Vault
├── AWS Secrets Manager
├── Azure Key Vault
└── Google Secret Manager

Layer 2: シークレット配布
├── Kubernetes Secrets（Vault Agent Injector経由）
├── AWS Parameter Store（Systems Manager）
├── 環境変数（Vault Agent経由で動的設定）
└── ファイルマウント（tmpfs経由、一時的）

Layer 3: アプリケーション統合
├── SDK/ライブラリ（Vault SDK, AWS SDK）
├── Sidecar/Init Container（Vault Agent）
├── CSI Driver（Secret Store CSI Driver）
└── 外部シークレット同期（External Secrets Operator）

Layer 4: 監査と監視
├── アクセスログ（誰が何のシークレットを読んだか）
├── 異常検出（通常と異なるアクセスパターン）
├── アラート（高感度シークレットへのアクセス通知）
└── コンプライアンスレポート

クラウド別のシークレット管理サービス比較

「マルチクラウドや複雑な認証要件がある場合はVault、AWSに閉じるならSecrets Managerが現実的だ。重要なのは、どのサービスを選ぶかより、シークレットを一元管理する仕組みを作ることだ」 — 田中VPoE

シークレット管理の基本原則

まとめ

チェックリスト

• シークレットの種類とそれぞれのリスクを理解した
• シークレット管理のアンチパターンを列挙できる
• シークレット管理の4層アーキテクチャを説明できる
• クラウド別のシークレット管理サービスを比較できる

次のステップへ

次は「Vault設計パターン」を学びます。HashiCorp Vaultを中心に、エンタープライズ向けのシークレット管理基盤の設計方法を身につけましょう。

推定読了時間: 30分