ほとんどの人がシークレット検出ツールを試すとき、最初に行うことはこれです。
AWS_SECRET_KEY = "FAKEAWSSECRETKEY123456"
PASSWORD = "password123"スキャンを実行しても何もフラグ付けされず、即座の反応は次のようなものになります。
「なんて役に立たないツールだ。私の犬でも見つけられただろうに。」
それはあまりにも明白に感じられます。シークレットの発見はセキュリティで最も簡単な部分ですよね？password=を検索し、いくつかの正規表現を適用すれば終わりです。どれほど難しいことでしょうか？
ある意味、その通りです。シークレットのように見える文字列を見つけるのは簡単です。誤検知に埋もれることなく、真のシークレットを見つけることが難しいのです。
テストが見た目よりも難しい理由、最悪のソリューションがしばしば最良に見える理由、そしてこれらのツールを実際にどのように評価すべきかについて詳しく見ていきましょう。
シークレット検出の仕組み
シークレットを検出するための主なアプローチは2つあります。ルールベースのパターンマッチングとエントロピー統計です。
ルールベースの検出は、定義された構造を持つシークレットを特定するために正規表現に依存します。AWSキーが典型的な例です。これらは常に同じプレフィックスで始まり、固定長であるため、このような正規表現で検出できます。
AKIA[0-9A-Z]{16}
コード内でキーがフラグ付けされているのを見ると、強力だと感じます。それがキーのように見えるすべてのプレースホルダーもフラグ付けしていることに気づくまでは。
AWS_ACCESS_KEY_ID="AKIA1234567890123456"
1つのキーであればそれほど問題ありませんが、何千ものルールを導入すると、すぐに非常にノイズが多くなります。正規表現は便利ですが、実際のキーとダミーのキーを区別できず、その結果、脆弱でノイズの多い混乱が生じます。
シークレット検証によるフィルタリング
誤検知を減らす最善の方法の一つは、検出後にシークレットを検証することです。これは通常、安全なAPIコールを行うことを意味します。例えば、AWSキーは以下のようにテストできます。
aws sts get-caller-identity --access-key <KEY> --secret-key <SECRET>
呼び出しが成功した場合、ライブキーを持っています。失敗した場合は、安全にアラートの優先度を下げることができます。
これは、非常に広範囲に網を張り、後で絞り込むことが可能であるため、素晴らしいことです。しかし、ここに落とし穴があります。ツールをテストする際、実際のAWSキーがGitHubにプッシュされるわけではありません。 偽のキーが使用されます。キーを検証するツールは、それらを無効として破棄し、結果はゼロと表示されます。一方、すべてにフラグを立てる「怠惰な」ツールの方が、より優れたパフォーマンスを発揮しているように見えます。
エントロピー統計によるフィルタリング
ここでエントロピーが何を意味するかを簡単に説明する必要があります。高エントロピー文字列とは、大量のランダム性を持つ文字列を指します。ランダム性が高いほど、エントロピーも高くなります。
ほとんどのシークレットは検証できないため、ツールはノイズを減らすために他の方法に依存します。エントロピー統計は最も効果的な方法の一つです。
考え方はシンプルです。実際のシークレットはランダムに見えます。プレースホルダーはそうではありません。この偽のStripeキーを考えてみてください。
StripeKey = "SK_123456789"
正規表現には一致しますが、本物であるにはランダム性が十分ではありません。本物のキーははるかに高いエントロピーを持ち、人間が偽造するのは非常に困難です。
英単語のフィルタリングも役立ちます。実際のAPIキーには、読み取り可能な単語がほとんど含まれていません。次のようなものを見つけた場合:
TEST823hufb934
それはプレースホルダーまたはテスト用の認証情報であると、かなり確信できます。優れたツールは、高いエントロピーとTEST、PASSWORD、DEMOのような明白な辞書語が混在する文字列のランクを下げるか、無視します。これはテストで問題を引き起こすことがよくあります。なぜなら、エントロピーを偽装することは人間にとって非常に難しく、意識していなくても入力時には自然とパターンに従ってしまうからです。
残念ながら、APIキーはエントロピーの高い文字列ですが、常にこれほど単純ではありません。UUID、ハッシュ、ファイル名もエントロピーの高い文字列であり、シークレットではありません。そのため、シークレットの周囲にコンテキストを導入することも重要です。最良のソリューションは、エントロピー、コンテキスト、および単語フィルタリングを組み合わせます。ただし、これはテストで問題を引き起こします。なぜなら、内容に合わない偽の認証情報を追加した場合、それらも無視されるからです。
最悪のツールが最高に見える理由
これがパラドックスです。最悪のソリューション、つまり疑わしい文字列すべてに警告を発するようなものは、簡単なテストでは輝いて見えます。それらはダミーのキーやパスワードを喜んで検出します。よりスマートなツールは、偽のものを静かに無視するため、壊れているように見えます。
現実的なデータでテストしない限り、誤検知の多いツールを称賛し、本番環境で実際に役立つツールを軽視することになります。
シークレット検出を適切にテストする方法
公平な評価を望むなら、より良いテストデータが必要です。
1つの選択肢はハニートークンです。CanaryTokensのようなサービスを利用すると、無害だが現実的な認証情報を生成できます。優れたツールであれば、これらを即座に検出するはずです。
別のアプローチは、権限のない実際のキーを作成し、テストを実行し、その後それらを無効にすることです。これにより、検証ロジックをトリガーする安全かつ有効な入力が得られます。
しかし、最良の方法は、実際のコードベースでツールを実行することです。リポジトリ、特にコミット履歴の奥深くには、シークレットがよく存在します。実際のプロジェクトをスキャンすることで、ツールが現実的な条件下でどのように動作するかが明らかになり、信頼できるベンチマークが得られます。
優れたシークレット検出ツールとは何か
強力なシークレット検出ツールは、次のすべてを行うべきです。
- 可能な限りシークレットを検証
プロバイダーが許可する場合、安全なAPIコールで実際のシークレットを確認します。 - 特定のシークレットパターンをサポート
AWS、Stripe、Twilioなどの構造化されたキーを正規表現またはパターンルールを使用して検出します。 - エントロピーとコンテキストで汎用的なシークレットを処理
ランダム性スコアリングと周辺コード分析を組み合わせて、固定パターンを持たないシークレットを検出します。 - 偽またはテスト用の認証情報を除外する
TESTやPASSWORDのような明白な辞書語を含むキーのランクを下げます。 - 幅広いシークレットタイプをカバー
APIキーだけでなく、証明書、SSHキー、データベースパスワードなども含まれます。 - 漏洩を未然に防ぎます
プリコミットフックまたはIDE統合を提供し、シークレットがバージョン管理システムに決して入らないようにします。 - リポジトリとパイプライン全体で規模を拡大
CI/CD、履歴全体、およびエンタープライズ規模で効果的に機能します。
まとめ
シークレット検出は単純に見えますが、そのテストは決して単純ではありません。すべての偽のシークレットをフラグ付けするノイズの多いツールは印象的に見えるかもしれませんが、検証とフィルタリングを行うよりスマートなツールは、あまり機能していないように見えることがあります。
適切にテストしたい場合は、ハニートークン、限定アクセスキー、または実際のリポジトリを使用してください。そして評価する際には、本番環境で重要な品質、すなわち検証、パターン検出、エントロピー分析、辞書フィルタリング、広範なカバレッジ、そして何よりもコミット前の防止に注目してください。
テスト用に仕込んだ偽のAWSキーは危険ではありません。目に見える形で隠されている本物のキーが危険なのです。
