EXERCISE 90分

ストーリー

田中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システムで管理が必要なすべてのシークレットを棚卸しし、分類してください。

  1. 全シークレットの一覧を作成する(最低15件)
  2. 各シークレットの機密度レベル(Critical/High/Medium/Low)を判定する
  3. 各シークレットの推奨保管場所ローテーション頻度を決定する
解答例

シークレット棚卸し表

IDシークレット種類機密度現在の保管場所推奨保管場所ローテーション頻度
S-001Stripe APIキー(本番)APIキーCriticalECS環境変数Vault KV90日
S-002PostgreSQL接続情報(本番)DB認証情報CriticalECS環境変数Vault Database(動的)動的(TTL: 1h)
S-003JWT署名鍵暗号鍵CriticalECS環境変数Vault Transit90日
S-004カード情報暗号鍵暗号鍵Criticalなし(未暗号化)Vault Transit年1回
S-005RedisパスワードDB認証情報HighECS環境変数Vault KV90日
S-006AWS IAMアクセスキー(CI/CD)IAMキーCriticalGitHub SecretsOIDC連携(キーレス)不要(動的)
S-007DockerレジストリトークントークンHighGitHub SecretsGitHub Secrets(維持)90日
S-008本番DB rootパスワードDB認証情報CriticalConfluenceVault KV90日
S-009Stripe WebhookシークレットAPIキーHighECS環境変数Vault KV90日
S-010S3暗号化キー暗号鍵HighAWS KMSAWS KMS(維持)年1回
S-011PayPayパートナーキーAPIキーCriticalECS環境変数Vault KV90日
S-012メール送信APIキーAPIキーMediumECS環境変数Vault KV90日
S-013Slack Webhook URLWebhookLowECS環境変数Vault KV年1回
S-014本番サーバーSSH鍵SSH鍵Critical個人管理Vault SSH(動的)動的(TTL: 4h)
S-015TLS証明書秘密鍵証明書HighACMACM(維持)自動(ACM)

Mission 2: Vaultアーキテクチャの設計

要件

PayConnectシステム向けのVaultアーキテクチャを設計してください。

  1. Vault のデプロイ構成(HA構成、バックエンド選定)を設計する
  2. Secret Engineの構成(パス設計含む)を定義する
  3. ポリシー設計(各サービス/チームのアクセス権限)を定義する
  4. 認証方法の選定と設定を定義する
解答例

デプロイ構成

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/DatabasePostgreSQL動的シークレット
transit/keys/payconnect-piiTransitPII暗号化
transit/keys/payconnect-jwtTransitJWT署名
ssh/roles/payconnect-adminSSH動的SSH証明書

ポリシー設計

ポリシー名対象アクセス権限
payconnect-apiPayConnect 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 AuthECS/EKS上のサービスServiceAccountによる自動認証
AppRoleCI/CDパイプラインRole ID + Secret ID
OIDC開発者(手動アクセス)GitHub OIDC連携
AWS IAMAWS Lambda等IAMロールによる認証

Mission 3: 移行計画の策定

要件

現在の環境変数ベースのシークレット管理からVaultベースへの移行計画を策定してください。

  1. 3フェーズの移行計画を策定する(各フェーズ2-4週間)
  2. 各フェーズのリスクと対策を明記する
  3. ロールバック手順を定義する
解答例

移行計画

フェーズ期間内容対象シークレット
Phase 1Week 1-2Vaultインフラ構築 + 非Criticalシークレット移行S-012, S-013
Phase 2Week 3-6Criticalシークレットの移行 + 動的シークレット導入S-001〜S-005, S-008〜S-011
Phase 3Week 7-10CI/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分