個人開発の秘密情報を安全に管理する
APIキー、データベース接続情報、署名鍵は、機能を動かす設定であると同時に権限そのものです。小さなプロジェクトでも、一度公開リポジトリやブラウザへ出ると、削除するだけでは回収できません。保存場所、利用者、失効方法を最初から分けます。
秘密情報と公開設定を分ける
公開してよいURLや表示名と、権限を持つ値を同じ設定ファイルへ入れないようにします。秘密情報には次のようなものがあります。
ブラウザへ送る環境変数は利用者から読める前提にします。名前に PUBLIC が付くかではなく、最終的に配信されるJavaScriptやHTMLへ含まれるかで判断します。
環境ごとに別の権限を使う
開発、プレビュー、本番で同じ鍵を共有すると、開発中の誤操作が本番データへ届きます。環境ごとに資格情報を分け、必要な操作だけを許可します。
OWASPのSecrets Management Cheat Sheetは、CI/CDを含む利用者ごとに必要最小限の権限へ絞ることを勧めています。読み取りだけの処理へ書き込み権限を渡さず、対象サービスや保存先も限定します。
コードとログへ残さない
ローカルでは、リポジトリ外またはGit管理対象外の環境ファイルを使います。サンプルファイルには変数名だけを書き、実値を置きません。
エラー処理にも注意します。リクエストヘッダー、接続文字列、環境変数全体をログへ出さず、管理画面やチャットへ貼り付ける前に値を伏せます。過去のコミットに入った場合は、履歴から隠す作業だけでなく、鍵を失効して再発行します。
失効と棚卸しを先に決める
秘密情報ごとに次を一行で記録します。
何の権限を持つか
どの環境で使うか
どこに保存するか
漏えい時にどこで失効するか
最後に確認した日
使っていない鍵を削除し、担当サービスをやめたときにも失効します。複雑な仕組みを先に導入するより、「誰が何へアクセスできるか」を説明できる状態を保つことが出発点です。
漏えいに気づいたら削除より先に失効する
公開リポジトリから値を消しても、履歴、複製、ログ、通知に残っている可能性があります。事故時は次の順で対応します。
対象の鍵を提供元で失効する
必要なら権限を絞った新しい鍵を発行する
本番、プレビュー、開発の利用先を更新する
不正利用の記録と費用を確認する
リポジトリ、ログ、チャット、成果物に残る範囲を調べる
混入経路を塞ぎ、再発確認を行う
サービスを止めずに鍵を交換する必要がある場合は、新旧二つを短時間だけ有効にできるかを事前に確認します。失効手順を事故後に初めて探す状態を避けます。
公開前の秘密情報チェック
[ ] ブラウザへ配信されるコードに秘密値がない
[ ] Git管理対象ファイルと履歴に秘密値がない
[ ] ログがヘッダーや環境変数全体を出力しない
[ ] 開発・プレビュー・本番で鍵が分かれている
[ ] 各鍵の権限と対象環境を説明できる
[ ] 失効場所と連絡先が分かる
[ ] 使っていない鍵を削除した自動スキャンは有効ですが、すべての形式を発見できる保証はありません。ファイル名、設定、ビルド成果物、ブラウザの通信内容も人が確認します。