ストーリー
田
田中VPoE
シークレット管理の理論を一通り学んだ。ここからはPayConnectシステムに対して、シークレット管理基盤の全体設計を行ってもらう
あなた
Vault、ローテーション、ゼロスタンディング権限を全部統合する設計ですね
あ
田
田中VPoE
そうだ。現状のPayConnectシステムでは、シークレットが環境変数にハードコードされている。これを段階的にVaultに移行する計画を含めた設計書を作成してくれ
あなた
移行計画まで含めるんですね。既存システムへの影響を最小化しながら移行する方法を考えます
あ
ミッション概要
| 項目 | 内容 |
|---|
| 演習タイトル | シークレット管理基盤の設計 |
| 想定時間 | 90分 |
| 成果物 | シークレット管理設計書(アーキテクチャ + ローテーション + 移行計画) |
| 対象システム | PayConnect(決済連携マイクロサービス) |
前提条件
現在のシークレット管理状況
現在のシークレット管理状態(PayConnect):
1. GitHub Actions シークレット(CI/CD用)
- AWS_ACCESS_KEY_ID(長期キー、3年間未ローテーション)
- AWS_SECRET_ACCESS_KEY
- DOCKER_REGISTRY_TOKEN
2. ECS タスク定義の環境変数(本番環境)
- DATABASE_URL=postgres://app:P@ssw0rd123@prod-db:5432/payconnect
- STRIPE_SECRET_KEY=sk_live_xxxx
- JWT_SIGNING_KEY=my-super-secret-key
- REDIS_PASSWORD=redis123
3. 設定ファイル(ソースコード内)
- config/production.ts に一部の設定値がハードコード
- .env.example にデフォルト値として本番に近い値が記載
4. 手動管理されているシークレット
- 本番DBのrootパスワード: Confluenceページに記載
- Stripeのダッシュボードパスワード: チームリーダーのみ知る
- SSH鍵: 各エンジニアが個人管理
問題点:
- ローテーションが一度も行われていないシークレットがある
- 誰がどのシークレットにアクセスしたかの監査ログがない
- 退職者のアクセス権が残っている可能性がある
- PCI-DSS 3.6.4(暗号鍵のローテーション)に非準拠
Mission 1: シークレットの棚卸しと分類
要件
PayConnectシステムで管理が必要なすべてのシークレットを棚卸しし、分類してください。
- 全シークレットの一覧を作成する(最低15件)
- 各シークレットの機密度レベル(Critical/High/Medium/Low)を判定する
- 各シークレットの推奨保管場所とローテーション頻度を決定する
解答例
シークレット棚卸し表
| ID | シークレット | 種類 | 機密度 | 現在の保管場所 | 推奨保管場所 | ローテーション頻度 |
|---|
| S-001 | Stripe APIキー(本番) | APIキー | Critical | ECS環境変数 | Vault KV | 90日 |
| S-002 | PostgreSQL接続情報(本番) | DB認証情報 | Critical | ECS環境変数 | Vault Database(動的) | 動的(TTL: 1h) |
| S-003 | JWT署名鍵 | 暗号鍵 | Critical | ECS環境変数 | Vault Transit | 90日 |
| S-004 | カード情報暗号鍵 | 暗号鍵 | Critical | なし(未暗号化) | Vault Transit | 年1回 |
| S-005 | Redisパスワード | DB認証情報 | High | ECS環境変数 | Vault KV | 90日 |
| S-006 | AWS IAMアクセスキー(CI/CD) | IAMキー | Critical | GitHub Secrets | OIDC連携(キーレス) | 不要(動的) |
| S-007 | Dockerレジストリトークン | トークン | High | GitHub Secrets | GitHub Secrets(維持) | 90日 |
| S-008 | 本番DB rootパスワード | DB認証情報 | Critical | Confluence | Vault KV | 90日 |
| S-009 | Stripe Webhookシークレット | APIキー | High | ECS環境変数 | Vault KV | 90日 |
| S-010 | S3暗号化キー | 暗号鍵 | High | AWS KMS | AWS KMS(維持) | 年1回 |
| S-011 | PayPayパートナーキー | APIキー | Critical | ECS環境変数 | Vault KV | 90日 |
| S-012 | メール送信APIキー | APIキー | Medium | ECS環境変数 | Vault KV | 90日 |
| S-013 | Slack Webhook URL | Webhook | Low | ECS環境変数 | Vault KV | 年1回 |
| S-014 | 本番サーバーSSH鍵 | SSH鍵 | Critical | 個人管理 | Vault SSH(動的) | 動的(TTL: 4h) |
| S-015 | TLS証明書秘密鍵 | 証明書 | High | ACM | ACM(維持) | 自動(ACM) |
Mission 2: Vaultアーキテクチャの設計
要件
PayConnectシステム向けのVaultアーキテクチャを設計してください。
- Vault のデプロイ構成(HA構成、バックエンド選定)を設計する
- Secret Engineの構成(パス設計含む)を定義する
- ポリシー設計(各サービス/チームのアクセス権限)を定義する
- 認証方法の選定と設定を定義する
解答例
デプロイ構成
Vault HA 構成:
[Route 53] ──→ [NLB]
│
┌───────┼───────┐
│ │ │
[Vault 1] [Vault 2] [Vault 3]
(Active) (Standby) (Standby)
│ │ │
└───────┼───────┘
│
[Raft Storage](内蔵)
デプロイ先: ECS Fargate(専用VPC)
ストレージ: Raft(内蔵統合型)
Auto Unseal: AWS KMS
監査ログ: CloudWatch Logs
バックアップ: S3(暗号化、日次)
Secret Engine 構成
| パス | Engine | 用途 |
|---|
| secret/data/production/payconnect/ | KV v2 | 本番静的シークレット |
| secret/data/staging/payconnect/ | KV v2 | ステージング静的シークレット |
| database/payconnect/ | Database | PostgreSQL動的シークレット |
| transit/keys/payconnect-pii | Transit | PII暗号化 |
| transit/keys/payconnect-jwt | Transit | JWT署名 |
| ssh/roles/payconnect-admin | SSH | 動的SSH証明書 |
ポリシー設計
| ポリシー名 | 対象 | アクセス権限 |
|---|
| payconnect-api | PayConnect APIサービス | secret/production/payconnect/* (read), database/creds/readonly (read), transit/encrypt/payconnect-pii (update) |
| payconnect-worker | バックグラウンドワーカー | secret/production/payconnect/stripe-* (read), database/creds/readwrite (read) |
| payconnect-dev | 開発チーム | secret/staging/* (read, list), database/creds/staging-* (read) |
| security-admin | セキュリティチーム | sys/policy/* (read, list), sys/audit/* (read), identity/* (read) |
認証方法
| 認証方法 | 対象 | 設定 |
|---|
| Kubernetes Auth | ECS/EKS上のサービス | ServiceAccountによる自動認証 |
| AppRole | CI/CDパイプライン | Role ID + Secret ID |
| OIDC | 開発者(手動アクセス) | GitHub OIDC連携 |
| AWS IAM | AWS Lambda等 | IAMロールによる認証 |
Mission 3: 移行計画の策定
要件
現在の環境変数ベースのシークレット管理からVaultベースへの移行計画を策定してください。
- 3フェーズの移行計画を策定する(各フェーズ2-4週間)
- 各フェーズのリスクと対策を明記する
- ロールバック手順を定義する
解答例
移行計画
| フェーズ | 期間 | 内容 | 対象シークレット |
|---|
| Phase 1 | Week 1-2 | Vaultインフラ構築 + 非Criticalシークレット移行 | S-012, S-013 |
| Phase 2 | Week 3-6 | Criticalシークレットの移行 + 動的シークレット導入 | S-001〜S-005, S-008〜S-011 |
| Phase 3 | Week 7-10 | CI/CDのOIDC化 + JITアクセス導入 | S-006, S-014 |
Phase 1 詳細(Week 1-2)
Week 1: インフラ構築
├── Vault HA クラスター構築(Terraform)
├── Auto Unseal 設定(AWS KMS)
├── 監査ログ設定(CloudWatch Logs)
├── バックアップ設定(S3)
└── 基本ポリシー作成
Week 2: 非Criticalシークレット移行
├── メール送信APIキー(S-012)をVault KVに移行
├── Slack Webhook URL(S-013)をVault KVに移行
├── アプリケーション側の読み取りをVault SDKに変更
├── 動作確認(ステージング→本番)
└── 旧環境変数の削除
リスクと対策
| リスク | 影響 | 対策 |
|---|
| Vaultダウン時にシークレット取得不能 | 全サービス停止 | Vault Agent のキャッシュ + HA構成 |
| 移行中のシークレット二重管理 | 管理の複雑化 | 移行チェックリストで追跡、フェーズごとに旧環境変数を削除 |
| Vault認証の設定ミス | サービス起動不能 | ステージングで事前検証、段階的ロールアウト |
ロールバック手順
ロールバック手順(各フェーズ共通):
1. 問題検出
└── Vault からのシークレット取得エラーが閾値超過
2. 判断
└── エンジニア2名以上で合意
3. 実行
├── ECS タスク定義を旧バージョンに更新
│ (Vault SDK → 環境変数の読み取りに戻す)
├── 旧環境変数(バックアップ保持済み)を復元
└── サービス再起動
4. 検証
└── 全エンドポイントのヘルスチェック確認
推定ロールバック時間: 15分以内
達成度チェック
| 観点 | 達成基準 |
|---|
| シークレット棚卸し | 15件以上のシークレットを特定し、機密度と推奨保管場所を分類している |
| Vaultアーキテクチャ | HA構成、Secret Engine、ポリシー、認証方法が設計されている |
| パス設計 | 環境別・サービス別のパス構造が論理的に整理されている |
| 移行計画 | フェーズ分けされ、リスク対策とロールバック手順が定義されている |
| 実用性 | PCI-DSS要件を満たし、運用可能なレベルの設計になっている |
推定所要時間: 90分