開発・ステージング・本番環境のシークレットと設定管理

私たちが解決する問題

シークレットと設定管理は、機密値が誤ってコピー、キャッシュ、共有される場所から除外することです。

シークレットは API キー、データベースのパスワード、SMTP ログイン、Webhook の署名シークレットなど、アクセスを許可したり本人性を証明したりする値です。通常の**設定（config）**はフィーチャーフラグ名、タイムアウト、公開サイトのベース URL のように公開されても害がない値です。

dev、staging、prod では目的が異なるため値も異なる必要があります。dev は素早い試行と安全なテストのため、staging は本番に似せつつ分離を維持、prod はロックダウンされ監査可能で安定している必要があります。同じシークレットをすべてで使うと、dev の漏洩が prod の侵害につながります。

「ビルドに漏れる」とは、シークレットがコンパイル済みのバックエンドバイナリ、モバイルアプリバンドル、フロントエンドバンドルなど、パッケージされて共有されるものの一部になることを指します。一度ビルド成果物に入ると、制御できない場所へ広がる可能性があります。

事故的な漏洩は通常、いくつかの予測可能な経路で発生します。

• ソースコード、サンプル、コメントにシークレットをハードコードする
• ローカルの .env ファイルや設定のエクスポートをリポジトリにコミットする
• フロントエンドやモバイルのビルドにシークレットを焼き込む
• ログ、クラッシュレポート、ビルド出力にシークレットを出力する
• 「ちょっとだけテストのために」本番値をステージングにコピーする

簡単な例：開発者が「メールを動かすため」に SMTP パスワードを設定ファイルに書き、それがコミットまたはリリースビルドに含まれる。後でパスワードをローテーションしても、古いビルドは CI キャッシュやアプリストアのアップロード、誰かのダウンロードフォルダに残るかもしれません。

目標は明快です：シークレットをコードやビルド成果物から外し、環境ごとに実行時や安全なデプロイ手順で正しい値を注入すること。

ほとんどの漏洩を防ぐ基本原則

安全性の大部分は毎回守る習慣から生まれます。

シークレットをコードやビルド出力から遠ざける。 コードは広がります。コピーされ、レビューされ、ログに残り、キャッシュされ、アップロードされます。ビルドも同様で、アーティファクトは CI ログやアプリバンドル、コンテナレジストリ、共有フォルダに残り得ます。コミットやコンパイルされるものは公開物と見なしてください。

環境ごとに資格情報を分ける（最小権限）。 dev 用キーは dev でしか動作せず、できることも限定してください。ラップトップやテストサーバからキーが漏れても被害が局所化されます。SMTP ユーザ、DB パスワード、Webhook 署名シークレットにも同じ考え方を適用します。

回転を当たり前にする。 シークレットは回転すると仮定して設計してください。値を置き換えるのにコード編集やすべてのアプリ再ビルドが不要なようにします。多くのシステムではランタイムでシークレットを読み（環境変数やシークレットストアから）、移行中に複数の有効なシークレットを許容することが有効です。

アクセスを制限し、ログを残す。 シークレットはそれを必要とするサービスだけが読み取れるようにし、実行環境を限定します。人的アクセスは稀に、時間限定で、監査可能にします。

短いルールセットとしては次の通りです：

• シークレットをコミットしたりチケット、チャット、スクリーンショットに貼らない
• dev、staging、prod 用に別々の資格情報を使う
• 値をイメージやモバイルビルドに焼き込むよりランタイム設定を優先する
• 予定表と露出後の回転を行う
• 誰が何を読めるかを制限し、アクセスログを取り続ける

これらの原則は従来のコードスタックでも、AppMaster のようなノーコードプラットフォームでも同じです。安全な道筋は同様です：シークレットをビルドの外に置き、使用箇所に厳密に限定すること。

シークレットが最も漏れやすい場所

ほとんどの漏洩は「ハッキング」ではなく、日常作業で起こります：ちょっとしたテスト、便利なスクリーンショット、出力が過剰なビルドなど。始めるべきはそのような小さな穴がどこにあるかを知ることです。

ソース管理は古典的な原因です。誰かが「今だけ」と API キーを設定ファイルに貼り、コミットし、それがブランチやプルリク、コードレビューコメントを通じて広がることがあります。後で削除しても履歴やパッチのコピーに残り続けることがあります。

ユーザーに配布するものも大きな漏洩源です。フロントエンドバンドルやモバイルバイナリは解析が容易です。シークレットが JavaScript、iOS/Android アプリ、あるいは焼き込まれた設定に含まれていると仮定してください。クライアントアプリは公開識別子は持てますが、秘密鍵は持てません。

自動化やサポートの「親切なノイズ」からも漏れます。例として、CI ログが環境変数をエコーする、SMTP 資格情報を含むデバッグ出力、設定やアウトバウンドリクエストを含むクラッシュレポート、.env を誤って保存したコンテナイメージやビルドキャッシュ、ログやスクリーンショットをそのまま貼ったサポートチケットなどがあります。

よくあるパターンは一度ビルドパイプラインに入ったシークレットがコピーされ回り、コンテナレイヤ、キャッシュアーティファクト、ログ、チケットへと広がることです。対策はひとつのツールだけでなく習慣です：シークレットをコードやビルド、チャットに貼らない習慣をつけること。

よくあるシークレットの種類とリスク

扱っているシークレットの種類、その漏洩時に何ができるか、どこに絶対に出してはいけないかを知ると助けになります。

API キー（Stripe、地図、解析など）はしばしば「プロジェクトレベル」の資格情報です。アプリを識別し、課金や利用状況の読み取りなど特定の操作を許可します。ユーザートークンとは異なり、多くの API キーは自動で期限切れにならないため、漏洩のダメージが大きくなりがちです。

SMTP 資格情報は通常ユーザ名とパスワードです。これが漏れると攻撃者が自社ドメインからスパムを送信し、配信性が損なわれます。API ベースのメールプロバイダは生の SMTP パスワードの代わりにスコープされた API キーを使えることが多く安全性が向上しますが、送信権限のあるキーは依然としてリスクが高いです。

Webhook シークレット（署名シークレットや検証キー）は受信リクエストを保護します。署名シークレットが漏れると「支払い成功」や「サブスクリプション解約」イベントを偽造され、業務ロジックが偽のイベントで実行される危険があります。

その他の高影響シークレットにはデータベース URL（パスワード埋め込み型）、サービスアカウント資格情報、暗号化キーなどがあります。データベース URL が漏れるとデータ全盗難につながることがあり、暗号化キーが漏れると過去と将来のデータが読み取られる可能性があり、回転が厄介です。

影響の考え方の目安：

• 金銭を使ったり操作を引き起こせるもの： 決済キー、管理者 API キー、Webhook 署名シークレット
• なりすましができるもの： SMTP パスワード、メール送信用キー、メッセージングボットトークン
• 全データをさらすもの： データベース資格情報、クラウドサービスアカウント
• プライバシーを恒久的に壊すもの： 暗号化キー、署名キー
• 公開しても概ね安全なもの： ブラウザ向けの公開可能キー（ドメイン／アプリ制限は必要）

クライアントアプリ（Web、iOS、Android）に以下を絶対に入れないでください：秘密の API キー、SMTP 資格情報、データベースパスワード、サービスアカウント、プライベート暗号鍵、Webhook 署名シークレット。クライアントがサードパーティ API を呼ぶ必要があるなら、バックエンド経由にしてシークレットはサーバ側に置くべきです。

ビルドにシークレットを入れずに保存するパターン

安全なデフォルトは簡単です：コンパイル、エクスポート、共有されるものにシークレットを焼き込まないでください。ビルドはチーム内でも公開物として扱ってください。

環境ごとに適切な保管先を選ぶ

ローカル開発では設定ファイルが許容されますが、バージョン管理に入れず差し替えが容易であることが重要です（例：ローカル専用の .env スタイルファイル）。ステージングや本番ではクラウドプロバイダのシークレットマネージャ、専用 Vault、プラットフォームの保護された環境設定を使うことを推奨します。

環境変数はランタイム注入が容易でコードベースと分離できるため良いデフォルトです。重要なのはタイミング：ビルド時注入よりランタイム注入の方が安全で、シークレットがビルド成果物に入らないからです。

多くのチームで機能する実用的な分け方：

• ローカル開発： ローカルの env 変数かローカルのシークレットファイル（開発者マシンごとに固有）
• ステージング： ステージング専用にスコープしたシークレットマネージャや保護された環境設定
• 本番： 監査ログ、厳しいアクセス制御、回転ルールを備えたシークレットマネージャ

名前付けと境界を一貫させる

アプリの挙動を変えないために環境間で同じキー名を使ってください：SMTP_HOST、SMTP_USER、SMTP_PASS、STRIPE_SECRET_KEY、WEBHOOK_SIGNING_SECRET。値だけが変わります。

支払いやメール、Webhook の領域で環境が重要になる場合は、可能なら環境ごとに別プロジェクトやクラウドアカウントを使ってください。例えば staging 用の Stripe キーや webhook シークレットをステージング専用ストアに置けば、ステージングのミスが本番に影響するのを防げます。

AppMaster のようなプラットフォームでデプロイする場合は、バックエンドサービスのランタイム環境設定を使ってサーバー側にシークレットを保持し、生成されたコードやクライアントアプリに埋め込まれないようにするのが良いです。

dev、staging、prod にまたがるステップバイステップの設定

誤用しにくくする仕組みをつくりましょう。

1. 何がどこで使われているかを棚卸する。 API キー、SMTP ユーザ名・パスワード、Webhook 署名シークレット、データベースパスワード、JWT 署名キー、サードパーティトークンを含めます。各シークレットについて所有者（チームやベンダ）、それを読むコンポーネント（バックエンド、ワーカー、モバイル、Web）、現実的な回転頻度を記録します。

2. dev、staging、prod 用に別々の値と権限を作る。 dev シークレットはラップトップやローカルコンテナで使っても安全なものにします。staging は本番に似せますが本番の資格情報やアカウントは共有しません。prod は実行時の識別（runtime identity）だけが読み取れるようにし、人がデフォルトで読めないようにします。

3. シークレットをビルド時ではなくランタイム設定へ移動する。 ビルド時にシークレットが存在すると、ビルドログ、Docker レイヤ、クライアントバンドル、クラッシュレポートに残る可能性があります。シンプルなルール：ビルド成果物は安全にコピーできるものにし、シークレットはアプリ起動時に注入します。

4. 一貫したデプロイフローを使う。 チームをトラブルから遠ざける一案：

• 環境ごとに1つのシークレットストア（または明確な名前空間）を作る
• アプリのランタイム識別だけに自分の環境のシークレットを読む権限を与える
• 起動時に環境変数やマウントされたファイルでシークレットを注入し、イメージやフロントエンドバンドルに入れない
• すべてのシークレットに回転ルール（有効期限、オーナー、リマインダー）を追加する
• ステージングが本番シークレットを読むと失敗するようなハードテストを追加する

ロックダウンは主に誰と何がシークレットを読めるかを減らすことです。共有アカウントを避け、長期トークンを可能な限り避け、読み取り権限は書き込みより狭くします。

AppMaster のようなノーコードプラットフォームを使う場合も同様です：サードパーティ資格情報は環境別のランタイム設定に置き、生成されるビルド成果物をチーム内で公開物と扱えば多くの事故を防げます。

API キーと SMTP 資格情報の実用的パターン

多くの漏洩は「何かを送る必要がある」ときに起きます。最速の修正は資格情報をクライアントや設定ファイルに貼ることです。良いデフォルトルールは簡単：Web とモバイルクライアントに SMTP ユーザ名、SMTP パスワード、送信可能なプロバイダキーを絶対に持たせないこと。

メールは可能なら SMTP の生パスワードよりもメールプロバイダの API キーを使ってください。API ベースの送信は送信だけに権限を限定しやすく、回転や監視も楽です。SMTP を使わざるを得ない場合はバックエンドに限定し、バックエンドのみがメールサーバと話す地点にします。

安全を保つ実用的なセットアップ：

• メール送信はバックエンドのエンドポイント（例：「パスワードリセットを送る」「請求書を送る」）で行う
• API キーや SMTP パスワードはバックエンドの環境シークレットとして保存し、ソースコードや UI 設定に入れない
• dev、staging、prod で別々の資格情報（理想的には別アカウントと送信ドメイン）を使う
• ステージング送信先を許可リストにして承認済みアドレスのみ受け取れるようにする
• 配信結果（メッセージ ID、プロバイダの応答、受信ドメイン）はログに残すが、資格情報や全文はログに出さない

ステージングと本番を分けることは思ったより重要です。ステージングが同じ送信ルールや送信先を使っていると、本番の顧客に誤ってスパムを送ってしまう可能性があります。シンプルな対策は、ステージングでは受信者を許可リスト以外ブロックすることです（例：チームのアドレスのみ許可）。

例：AppMaster で顧客ポータルを作ったとします。モバイルアプリが「ログインコードをメールで送って」と呼ぶと、アプリはバックエンドを叩き、バックエンドが prod または staging のメールシークレットを環境から読み取って送信します。テスターがステージングを使う場合は許可リストが実際の顧客宛送信を防ぎ、ログには送信成功の情報は残るがキーは露出しません。

Webhook シークレット：署名、検証、回転

Webhook のセキュリティは一つのルールに帰着します：バックエンドにだけ残るシークレットで必ず各リクエストを検証すること。シークレットが Web やモバイルアプリに渡ると、それはもはやシークレットではありません。

署名と検証

Webhook は受信カード決済のように扱ってください：検証されるまで何も受け付けない。プロバイダはペイロードと共有シークレットから計算した署名ヘッダを送ります。サーバー側で期待される署名を再計算して比較します。

単純な検証フロー：

• 受信した生のリクエストボディをそのまま読み取る（再フォーマットしない）
• Webhook シークレットで期待署名を計算する
• 定数時間比較で比較する
• 欠落または無効な署名は 401 や 403 で拒否する
• その後で JSON を解析してイベントを処理する

dev、staging、prod で別々の webhook エンドポイントと別々のシークレットを使ってください。これによりテストシステムが本番アクションを引き起こすのを防ぎ、事故を局所化しやすくなります。AppMaster では通常、各デプロイ用に別の環境設定を用意し、Webhook シークレットはサーバー側変数として保持します。

リプレイ防止と回転

署名は改ざんを防ぎますが、リプレイ自体を自動で防ぐわけではありません。各リクエストを一度だけ有効にするか短い時間窓に限定するチェックを追加してください。一般的な手段はタイムスタンプヘッダと厳しい時間制限、ナンス、または重複処理を拒否するための idempotency キーの保存などです。

回転は必要になる前に計画してください。安全なパターンは短期間で二つの有効なシークレットを許容することです：プロバイダを更新する間はどちらのシークレットでも検証を受け入れ、移行後に古い方を廃止します。明確な切替時間を設け、古い署名のトラフィックを監視してください。

ログにも注意してください。Webhook ペイロードにはメールや住所、決済メタデータが含まれることがありえます。イベント ID、タイプ、検証結果はログに残しても、ヘッダやペイロード全文は出力しないでください。

避けるべき一般的なミスと罠

多くの漏洩は便利さから来る習慣の産物で、開発中に便利だったことがステージングや本番にコピーされてしまいます。

ローカルの .env を永遠に安全な場所だと思い込むのはよくある落とし穴。ラップトップでは問題ないかもしれませんが、リポジトリにコピーされたり共有 ZIP に入った瞬間に危険になります。.env を使うならバージョン管理で無視し、本番デプロイでは環境設定に置き換えてください。

全環境で同じ資格情報を使うのも頻繁な問題です。dev、staging、prod で同じ API キーを使うと、dev のミスが本番の事故につながります。鍵を分ければ回転や失効、監査が楽になります。

Web フロントエンドやモバイルアプリでビルド時にシークレットを注入するのは特に危険です。シークレットがコンパイル済みバンドルやアプリパッケージに入ると抽出可能だと仮定してください。フロントエンドには公開設定（API のベース URL など）だけを渡し、機密はサーバーに置くこと。

ログは静かな漏洩源です。一時的なデバッグ出力が何ヶ月も残り続けることがあります。値を確認する必要があるならマスクした形（例：末尾4文字だけ）でログを取り、不要になったらすぐに削除してください。

危険信号（レッドフラッグ）

• シークレットが Git 履歴に残っている
• すべての環境で一つのキーが使える
• モバイルアプリにベンダーキーや SMTP パスワードが含まれている
• サポートチケットにヘッダ付きのリクエストダンプがある
• 値が base64 や隠しフィールドで「隠されている」

エンコードは保護ではなく、隠しフィールドもユーザーに見えることが多いです。

AppMaster を使っているなら、環境ごとのランタイム設定に機密値を置き、クライアントアプリには非機密設定だけを渡すようにしてください。現実確認の一例として、ブラウザが見られるものはすべて公開と見なすチェックをしてください。

出荷前のクイックチェックリスト

「何が漏れるか」を意識した最終確認を行ってください。ほとんどの事故は些細なものです：キーをチケットに貼った、設定画面のスクリーンショット、ビルド成果物にシークレットが含まれていた等。

出荷前の基本確認：

• シークレットがリポジトリ履歴、課題、ドキュメント、スクリーンショット、チャットログにないこと。もし一度でも貼ったなら漏洩を前提に回転する。
• Web・モバイルビルドには公開設定（API ベース URL、フィーチャーフラグ）だけが含まれていること。秘密鍵、SMTP パスワード、Webhook 署名シークレットはサーバー側か環境別シークレットストアに置く。
• ステージングは本番と分離されていること。専用の API キー、SMTP アカウント、テスト用決済／Webhook エンドポイントを使う。ステージングが prod のデータベースや秘密ストアを読めないようにする。
• CI ログ、モニタリング、エラーレポートに敏感な値が出力されないこと。ビルド出力、クラッシュレポート、デバッグログを確認し、トークンはマスク、Authorization のようなヘッダは赤字化する。
• コード変更なしで素早く回転・取り消しできること。シークレットはデプロイ時に注入される（環境変数やシークレットマネージャ）ようにし、キー変更が設定更新で済むようにする。

AppMaster を使っている場合は、シークレットを各環境のデプロイ時設定として扱い、UI 画面やエクスポートビルドに焼き込まないようにしてください。最終チェックとして、コンパイル済み成果物やログで sk_live、Bearer 、SMTP ホスト名などのパターンを検索すると良いでしょう。

統合ごとに「キルスイッチ」を書き出しておくと便利です：どこでキーを無効化するか、誰が5分以内にできるかを明示すること。

例：決済、メール、Webhook のシナリオ

3人のチームが顧客ポータル（Web）、モバイルアプリ、領収書を送る小さなバックグラウンドジョブを運用しているとします。環境は dev（ラップトップ）、staging（QA）、prod（本番）。シークレット管理は日常作業を遅らせないことが望まれます。

ローカル開発ではサンドボックスの決済キーとテスト SMTP アカウントだけを使います。各開発者はローカルの環境変数（または追跡対象外のローカルファイルを環境変数に読み込む）にシークレットを保持し、リポジトリに入れません。Web、モバイル、バックグラウンドジョブは同じ変数名（例：PAYMENTS_KEY、SMTP_USER、WEBHOOK_SECRET）を読みますが、値は環境ごとに異なります。

ステージングでは CI がビルドをデプロイし、プラットフォームがランタイムでシークレットを注入します。ステージングは専用の決済アカウント、SMTP 資格情報、Webhook 署名シークレットを使い、QA は本番に触らずに実フローをテストできます。

本番では同じビルド成果物をデプロイしますが、シークレットは専用のシークレットストア（またはクラウドプロバイダのマネージドシークレット）から読み取られ、実行中のサービスでしか利用できません。さらにアクセス権を厳しくして、バックグラウンドジョブだけが SMTP 資格情報を読み、Webhook ハンドラだけが webhook シークレットを読むようにします。

キーが露出したら（例：スクリーンショットに API キーが映る）次の手順を踏みます：

• 露出したキーを即座に無効化し、関連シークレットを回転する
• 露出期間中の不審な利用をログで検索する
• 新しい値を拾うようにサービスを再デプロイする
• 起きたことを文書化し、プリコミットスキャンなどのガードレールを追加する

ローカル作業を楽にするために本番シークレットは決して共有しません。開発者はサンドボックスアカウントを使い、AppMaster のようなツールを使う場合は dev/staging/prod の環境値を分けて同じロジックを安全に実行できるようにします。

次のステップ：ワークフローに繰り返し組み込む

シークレット管理を衛生作業として扱いましょう。最初は面倒でも、慣れれば日常になります。

まず、誰でも更新できるような簡単なシークレットマップをプレーンな言葉で書き出してください：

• そのシークレットが何か（API キー、SMTP パスワード、Webhook シークレット）
• どこで使われているか（サービス、ジョブ、モバイル、ベンダのダッシュボード）
• 各環境でどこに保存されているか（dev、staging、prod）
• 誰がアクセスできるか（人、CI/CD、ランタイムのみ）
• どう回転するか（手順と監視ポイント）

次に、環境ごとに一つの保存パターンを選び、守り続けてください。一貫性は巧妙さに勝ります。例：開発者はローカルシークレットストア、ステージングは限定アクセスのマネージドシークレット、本番は同じマネージドシークレットに加えてより厳しい監査を行う。

回転スケジュールと実行可能なインシデントプランを追加します：

• リスクの高いキーはカレンダーに沿って回転し、スタッフ変更後は即時回転する
• 漏洩を前提に：無効化、置換、トラフィック回復の確認を行う
• 誰がいつ何を回したかをログに残す
• ブラスト半径のチェック（決済、メール送信、Webhook）を決める

AppMaster（appmaster.io）で構築する場合は、プライベートキーをサーバー側設定に保持し、環境ごとにデプロイしてクライアントビルドにシークレットが埋め込まれないようにしてください。まずステージングで一つのキーをエンドツーエンドで回転させて検証（ストア更新、再デプロイ、確認、古いキー無効化）すれば、その手順を他のシークレットにも繰り返せます。