漏洩した認証情報とは? シークレットがどう流出し、どう対応するか

漏洩した認証情報とは、決してあるべきでない場所 - 公開リポジトリ、build ログ、スクリーンショット、あるいは攻撃者の手 - に行き着いたあらゆるシークレットです。

認証情報は絶えず、たいてい偶然に漏洩します。キーが commit され、ログに出力され、チャットに貼り付けられ、あるいは container イメージに焼き込まれます。それぞれの漏洩は常設の招待状です。認証情報がローテーションされるまで、それを見つけた者はあなたとして振る舞えます。一般的な漏洩経路を知ることが、それを塞ぐ第一歩です。

一般的な漏洩経路

リポジトリ、特に公開リポジトリに commit されたハードコードされたシークレット。
CI の build ログに echo されたシークレット。
container イメージレイヤーに焼き込まれた認証情報。
チャット、チケット、スクリーンショットで共有されたキー。

なぜ CI がホットスポットなのか

pipeline は多くのシークレットを扱い、多くのログを生成します。環境変数の 1 回の echo、あるいは config を出力する冗長なツールが、多くの人が読めるログにシークレットをこぼす可能性があります。ログのマスキングは役立ちますが、プラットフォームがシークレットだと知っている値についてのみです。

漏洩がどう見つかるか

攻撃者は公開リポジトリ、paste サイト、露出したバケットに対して自動スキャナーを走らせます。公開 GitHub リポジトリに push された認証情報は数分以内に、しばしば人間が気づくより速く、拾われて悪用されうるのです。

漏洩への対応

対応は常に同じ順序です。まず認証情報をローテーションして漏れたコピーを無効にし、次にスコープと影響を調査します。履歴やログから漏洩を消すのはローテーションの後です。値がすでにコピーされているかもしれないからです。

事前に被害を限定する

最小権限のスコープ制限は、漏れたトークンができることを減らします。短命な認証情報は、それが素早く失効することを意味します。ephemeral で isolation されたランナーは、シークレットが次のジョブに読まれるためにホスト上に残ることがないことを意味します。これらを合わせることで、漏洩の可能性とコストの両方が縮まります。

重要なポイント

漏洩した認証情報とは、あるべきでない場所に露出したシークレットである。
CI ログ、公開リポジトリ、イメージレイヤーが最も一般的な漏洩経路である。
常にまずローテーションし、次に調査する。スコープ制限と短命さが被害を限定する。