背景
nuxt.config.ts の runtimeConfig(databaseUrl / stripeSecretKey)で秘密情報を受けるが、本番/検証の環境分離、Stripe の test/live 分離、鍵の権限範囲・ローテーションは未決。#23 は起動時の存在検証までを扱う。
なぜ今決めるか
Stripe のオブジェクト ID は test/live で非互換なので、テストモードでデータを投入した DB を live に流用できず、環境ごとに DB を分ける前提が要る。ここを曖昧にすると本番 DB にテストデータが混入する不可逆事故や、鍵とモードの不一致による署名検証の恒久的失敗を招く。混ざった後の分離は極めて高くつく。
論点・選択肢
- 環境分離: 本番/検証で (API キー, webhook シークレット, DATABASE_URL) を 1 セットとして分ける。live 鍵が dev/CI に混入しないガード。
- 鍵の権限: フルアクセスの secret key ではなく、必要リソース(invoices, customers, prices, products, webhooks)に絞った restricted key にするか。漏洩時の被害範囲を狭める。
- ローテーション: 鍵・webhook シークレットを無停止で回せる構造(旧新 2 本の並行受理)を前提にするか。
- 配置: NeoShowcase の secret 機構への配置と、
runtimeConfig が環境ごとに注入される前提の明文化。
受け入れ条件
- 環境分離・test/live 分離・鍵の権限範囲・ローテーション方針が決まっている。
- 運用基盤の機能に依存する具体(配置手順等)は情報不足なら暫定とし、分離の要件は今確定する。
関連
#23(起動時シークレット検証)の拡張。#17(webhook シークレット)と接続する。
背景
nuxt.config.tsのruntimeConfig(databaseUrl/stripeSecretKey)で秘密情報を受けるが、本番/検証の環境分離、Stripe の test/live 分離、鍵の権限範囲・ローテーションは未決。#23 は起動時の存在検証までを扱う。なぜ今決めるか
Stripe のオブジェクト ID は test/live で非互換なので、テストモードでデータを投入した DB を live に流用できず、環境ごとに DB を分ける前提が要る。ここを曖昧にすると本番 DB にテストデータが混入する不可逆事故や、鍵とモードの不一致による署名検証の恒久的失敗を招く。混ざった後の分離は極めて高くつく。
論点・選択肢
runtimeConfigが環境ごとに注入される前提の明文化。受け入れ条件
関連
#23(起動時シークレット検証)の拡張。#17(webhook シークレット)と接続する。