← ジャーナル

シークレットを危険に晒さずに受け渡す

"APIキー、データベースのアクセス情報、証明書。チーム・委託先・顧客の間でシークレットを受け渡し、3年後の履歴から発見されないための実践。"

セキュリティシークレット管理チームプラクティスコンプライアンス

最良の受け渡しは、受け渡さないこと

どのプロジェクトも同じ儀式で始まります。「アクセス情報を送ってもらえますか?」。そして各チームはその場しのぎの、たいてい間違った答えを出します。メールに書かれたパスワード、Slack チャンネルに貼られた API キー、添付ファイルの .env。その瞬間、シークレットはあらゆる管理の境界を、永久に離れました。

より良いチャネルを探す前に、本質的な問いを立てましょう。そのシークレットは、その形で存在する必要があるのか? フェデレーテッドアイデンティティの仕組み(CI とクラウド間の OIDC、IAM ロール、ワークロードアイデンティティ)は、静的なシークレットを短命の身元証明に置き換えます。渡す鍵も、漏れる鍵も、ローテーションする鍵もありません。この選択肢があるなら、常にそれが勝ちます。本稿の残りは、本当に人と人の間を移動しなければならないシークレットだけを扱います。

最初から失格のチャネル

いくつかのチャネルは、議論の余地なく失格です。

  • メール。誰も管理していないサーバーに複製され、インデックスされ、アーカイブされ、転送される。
  • チームチャット。履歴は管理者が読め、移行時にエクスポートされ、メンバーの退職後も長く残る。
  • チケットや共有ドキュメント。プロジェクトより長生きし、3年後の全文検索で再浮上する。
  • SMS と個人のメッセンジャー。私的な領域と業務の領域を混ぜてしまう。

共通点は、管理されない永続性です。受け渡しに使えるチャネルはその正反対、つまりエンドツーエンド暗号化と消滅を保証します。

機能する方法。シンプルなものから本格的なものへ

一度きりの受け渡しなら、監査可能なツールが生成する、一回限りで短命のリンクで足ります。受信者が開けば、シークレットは消えます。受領は別のチャネル(電話やメッセージ)で確認し、正しい相手がリンクを使ったことも同時に確かめます。

継続的な協働では、単発の受け渡しでは足りません。共有の置き場が必要です。境界ごとに保管庫を分けたチーム用パスワードマネージャーが最も導入しやすく、インフラが正当化するなら、アクセスログとロールベースのポリシーを備えた集中型シークレットマネージャーが妥当になります。選定基準はどちらも同じです。誰が何にアクセスしたか分かるか、そしてアクセスを一操作で取り消せるか?

受け手共有保管庫送り手受け手共有保管庫送り手メンバー離脱時は一操作で失効プロジェクトの保管庫にシークレットを格納アクセスを記録別チャネルで通知(メッセージにシークレットは含めない)認証してシークレットを読むアクセスを記録

繰り返す価値があります。通知メッセージには決してシークレットを含めない。どこで取得できるかだけを伝え、受け手は自分の権限で取りに行きます。

最小権限は疑心暗鬼ではなく、予算である

渡したシークレットはすべて負債です。誰かが覚えておき、ローテーションし、失効させなければなりません。この負債は源流で減らします。

  • 環境ごとのシークレット。ステージングと本番で同じトークンを使わない。
  • 人・サービスごとのシークレット。誰のものか分からない共有「team」アカウントを作らない。
  • 最小のスコープ。読み取り専用の用途には読み取り専用のキーを。
  • デフォルトで短い有効期限。期限切れは最良のローテーションです。

Git の履歴は決して忘れない

最も頻繁な漏洩は、どの受け渡しチャネルも通りません。コミットされるのです。「一時的に」追加された .env、設定ファイルの接続 URL、テストの中のキー。履歴は永遠の分散メモリで、すべてのクローンがコピーを持ち去ります。

防御は多層です。環境ファイルに対する厳格な .gitignore。公開前にブロックする pre-commit と CI のシークレットスキャナー。そして、それでもシークレットが履歴に到達した日の絶対のルール。削除では決して足りず、シークレットは侵害されたものとみなし、直ちにローテーションする。履歴の書き換えは今後の露出を減らすだけで、漏洩を取り消すことはできません。

出口も受け渡しの一部

シークレット受け渡しのプロセスは、オフボーディングで評価されます。メンバーの離脱、契約の終了、委託の解消は、同じ手順を起動します。個人のアクセスを失効させ、その人が読めた共有シークレットをローテーションし、ログを確認する。このリストの作成が苦痛なら、シークレットは棚卸しされないまま配られていたということです。そしてその棚卸しこそ、保管庫が無償で提供するものです。

私たちが適用するチェックリスト

  • このシークレットは短命の身元証明で置き換えられるか? できるなら置き換える。
  • メール・チャット・チケット・ドキュメントに平文のシークレットを置かない。
  • 単発の受け渡しは一回限りのリンクと別チャネルの通知で。
  • 継続的な協働は共有保管庫、ロールベースのアクセス、ログで。
  • 環境ごと・人ごとに一つ、スコープと有効期限は最小に。
  • pre-commit と CI にシークレットスキャナーを。
  • 履歴に入ったシークレット = 侵害されたシークレット。即時ローテーション。
  • 台本化されたオフボーディング。失効、ローテーション、ログ確認。

どれも高くつきません。高くつくのは、プロジェクト終了から2年後もまだ本番にアクセスできる、Slack に置き忘れられたトークンの方です。