API キー・トークン・メールアドレス・口座番号を、チケットやチャットに貼る前にマスクします。先頭と末尾の可視文字数、マスク文字、実長を隠すかどうかを選べます。
シークレットそのものではなく、その「かたち」だけを共有する。 トークン・キー・メールアドレス・口座番号を貼り付け、先頭と末尾を何文字残すか選びます。その間はマスク文字に置き換わるため、同僚はどの資格情報を指しているか確認できても、中身を見ることはありません。
マスキングは暗号化ではありません。すでに漏えいしたシークレットは、伏せ字にするのではなくローテーションしてください。
資格情報の中間を伏せることは、ごく狭い問題をうまく解決します。シークレットを送信せずに、それについて話せるようにすることです。サポートチケット、バグ報告、スクリーンショット、チャットのスレッドは日常的に資格情報を漏えいさせていますが、その動機はたいてい「どのキーを使っているか」を確認することであって、「キーの中身が何か」ではありません。sk_live_51H8...FgH と示せば、前者には完全に答えられ、後者には一切答えないことになります。
価値はそこに尽きるので、限界をはっきりさせておく価値があります。マスキングは人どうしのやり取りのために行う、一方向で不可逆な変換です。鍵も復元経路も想定していないので暗号化ではありません。何かに耐えるよう設計されていないのでハッシュでもありません。レシートがカード番号の下 4 桁だけを印字するのに近い発想です。識別には足り、使用には足りません。
可視文字が 1 つ増えるたびに、攻撃者が推測しなくてよい文字が 1 つ増えます。したがって、識別という目的を果たせる範囲で前後の露出はできるだけ短くします。長いランダムトークンなら両端 4 文字が妥当な既定値で、多くの事業者のダッシュボードもそう表示します。短い値ではさらに減らしてください。8 桁の PIN で 4 文字見せれば、ほとんど何も残りません。
構造を持つ値は、可視部分が見た目以上に情報を含むため注意が必要です。多くの API キーには意味のある接頭辞があり、sk_live_ と sk_test_ の区別こそ通常残したいものです。メールアドレスは逆の罠です。ドメインを残すのはたいてい問題ありませんが、ローカル部と小規模ドメインの組み合わせは個人を特定しうるため、マスクした文字列が再び個人情報に戻ってしまいます。
本ツールは先頭と末尾の窓が重なることを許しません。両方の設定が合わさって文字列全体を覆う場合は自動的に縮小します。重なったマスクの失敗結果は、元の値をそのまま全部出力してしまうことだからです。
長さを保つマスクは情報も保ちます。アスタリスクの数はシークレットの長さを正確に伝え、総当たりの探索範囲を狭めます。多くのキー形式は長さが固定なので、資格情報の種類がそのまま分かることもあります。とりわけパスワードでは、長さの公開は実質的な譲歩です。
固定幅オプションは、実際の長さに関係なく中間を一定数のマスク文字に置き換えます。どのマスク結果も同じ長さに見えるようになるため、チーム外の人が目にする出力では必ず有効にしてください。長さ自体が診断材料になる場合——たとえば環境変数の切り詰めを疑っているとき——は、長さを保つ既定の挙動のままにします。
最後に、これは整形の一手順であって、インシデント対応ではありません。有効なシークレットがすでにチケット・ログ・リポジトリに現れているなら、コピーを伏せ字にしても元の露出は何も変わりません。まず資格情報をローテーションし、それ以降に貼る内容へマスキングを使ってください。