この記事は、以下の著者らによって共同執筆されました。 ザック・ライス と ジョー・レオンが共同執筆したもので、両者とも Aikido セキュリティに所属している。
要約：公開されることを意図した認証情報もあるにもかかわらず、シークレットスキャナーはそれらを依然として一般的な「シークレット」として検出してしまう。そこで、最も一般的なものに対して抑制ルールを作成し、誤検出率を約2%削減した。これらのルールは現在、Betterleaksにデフォルトで組み込まれている。
シークレット 正規表現に基づいて構築されています。各パターンは、AWSのシークレットアクセスキー、GitHubのPAT、Stripeのトークンなど、特定の認証情報タイプを対象としています。スキャナーが潜在的なシークレットを特定すると、例えばHTTPリクエストを送信して、その認証情報が有効かどうかを確認するなどして、有効性チェックを行います。
このワークフローは、シークレットスキャナーが「シークレット特定しようとすると機能しなくなります。シークレット 一意の署名や既知の署名API シークレット 。スキャナーは正規表現を使用してこれらを検出することはできますが、既知の認証情報形式との一致を探すのではなく、汎用的なパターンを用いて、シークレットである可能性のあるものをすべて網羅的に検出します。
シークレット ノイズ 低減と正規表現に関する問題
コード（やその他の場所）の中から「シークレット」のような文字列を抽出するための凝った正規表現を書くのは、それほど難しくありません。しかし、あらかじめ定義された有効性チェックがなければ、スキャナーは一般的なシークレットが実際に有効なシークレットであるかどうかを確実に判断することはできません。
このアプローチでは、ユーザーが誤検知を手作業で選別しなければなりません。しかし、それは面倒な作業です。そこで、今後数か月の間に、一連のノイズレイヤーを順次リリースしていく予定です：
- トークン効率フィルタリング（前回の投稿）
- 公開可能な認証情報の拒否リスト（この記事）
- パブリックシークレット
- 汎用ルールを「トークン」と「ユーザー名／パスワード」の2種類に分類する
- MLを活用したトリアージ
この特定の順序で処理を行うのは、できるだけ低コストで誤検知を最大限に排除し、残った曖昧なケースに対してのみコストのかかる機械学習処理を適用したいと考えているからです。完璧な結果になることは決してありませんが、汎用的なシークレット 、シークレット において最大の可能性を秘めていると私たちは考えています。 ここは、研究者が新たな発見を明らかにし、防御側が脅威アクターの一歩先を行くための最適な場です。本シリーズの目的は、Betterleaksのデフォルトルールを十分に優れたものにし、研究者やアナリストが汎用シークレットの検出結果を大規模に選別できるようにすることです。
なぜ一部の鍵は公開可能な（それほど秘密ではない）鍵と見なされるのか
多くのSaaSやクラウドプロバイダーは、公開を前提として設計されたユーザー用認証情報を発行しています。決済処理サービスのStripeは、ユーザーに「API を含む複数のキータイプを提供しています。これらのキーは、「フロントエンドのコードに組み込む」ことを想定して設計されています。
一般的なシークレット検出ルールであれば、これをシークレットの候補として検出する可能性が高いでしょう。エントロピーが高く、apiといったキーワードの近くに位置しており、一見すると認証情報のように見えるからです。しかし、これは実際のシークレットではありません。公開されることを意図したものであり、研究者やアナリストが手作業でレビューする時間を費やすべきものではありません。
そこで、Betterleakの汎用的なシークレット検索結果からこのキータイプを除外するための正規表現を作成しました。
しかし、Stripeは重要な認証情報の一種に過ぎません。このプロセスを大規模に展開する必要がありました。そこで、設計上公開されている最も一般的な認証情報の種類を調査し、それぞれについて手作業で検出シグネチャを作成しました。そうです、手作業です。この作業において、AIは意外にも役に立ちませんでした。
ジェネリック版「シークレット」における偽陽性率の低減
これらの式を手作業で何時間もかけて追加した後、その作業に価値があったかどうかを確認してみたかった。変化を測定するため、Common Crawlから100GBのデータをダウンロードし、Betterleaksで2回スキャンを行った。1回目は新しいシグネチャを使用し、2回目は使用しなかった。
新しい「公開可能な資格情報」の署名により、誤検知が2.37%減少しました。当社のデータセットでは、シークレット ,886件減少しました。
スキャン時間は約5％長くなりますが、それほど多くの誤検知を回避できるなら、それだけの価値は十分にあります。
削減率は、スキャンするデータによって異なります。Common Crawl は、公開可能な認証情報がまさに存在するフロントエンドの HTML や JavaScript に偏っているため、その結果、当社の結果が過大評価されている可能性があります。いずれにせよ、フィルタによって削除される公開可能なキーは、研究者やアナリストが選別作業を行う必要がなくなるものとなります。
「公共」だからといって、必ずしも安全とは限らない
このアプローチを採用する上での課題は、公開可能な認証情報が必ずしもリスクがないことを意味するわけではないという点です。各キーの種類について、SaaSプラットフォームのコンテキスト内で、キーの構造やそれに付与されたアクセス権限を手動で確認する必要があります。このリストを作成する過程で、特に追加項目のPRを提出しようと考えている方（ぜひご提案ください！）にとって検討に値する5つの事例が見つかりました。
ユニークな形：簡単
これらは簡単です。公開可能な認証情報には、一意で紛れもない形状があります。私たちは一意の正規表現を作成し、これにより、有効である可能性のある一般的なシークレット一切除外されないことを確信しています。
一意な形状ではない：文脈が必要
これらは、文字通りどこにでも出現しうる文字列です。UUIDである場合もあれば、単に32文字の16進数文字列である場合もあります。形式だけでは、この文字列が公開可能な認証情報タイプであると特定することはできません。このような場合、その文字列が特定のSaaSプラットフォームやクラウドプロバイダーに属していることを確認するために、その付近にあるキーワードを参考にします。
この手法は新しいものではありません。秘密の認証情報については、普段から常にこの方法を採用しています。
「秘密」と同じ形：有効性チェックが必要
これは厄介な問題です。一部のSaaSプロバイダーは、シークレットと公開可能な認証情報をまったく同じ形式で発行することを選択しています。正直なところ、こうした対応は避けてほしいところです。シークレットの検出が難しくなるだけでなく、ユーザーを混乱させてしまうからです。しかし、実際にこうした事例に数多く遭遇しました。
このような場合、処罰対象となるキータイプを安全に削除する唯一の方法は、その秘密認証情報に対する検出用署名（HTTP ライブネスチェックリクエストを含む）を追加することです。
公開鍵と秘密鍵は同じ形式であるため、秘密鍵の型検出署名は両方を検知し、生存性チェックを行った後、公開鍵が秘密鍵ではないと判断して、それを破棄します。
設定ミスがあれば脆弱になる：稼働確認が必要
SaaSやクラウドプロバイダーが発行するキーには、ユーザーが特定の権限を追加したかどうかによって、そのキーが機密性の高いものになるか、あるいはリスクのないものになるかといった種類があります。私はGoogleAPI 、それらがGeminiにアクセスできる機能についてかなり詳しく書いてきました。これはその一例です。しかし、Algoliaのキーなどでも同様のパターンが見られます。
このような状況では、公開鍵と秘密鍵の間で形式の不一致が見られる場合と同様の対処法が最適です。つまり、機密情報にアクセスできるかどうかを判断するために、稼働確認（liveness check）を送信します。
テスト用認証情報：手動による選別が必要
Stripe のような一部の SaaS プラットフォームでは、ユーザーにテスト環境やサンドボックス環境が提供されています。当初、私たちはこれらの結果を一般的なシークレット検出結果から一概に除外することを検討していました。
しかし、詳しく調べてみると、一部の組織では本番環境のデータをテスト環境に格納していることが明らかになりました。また、サンドボックス環境から漏洩したStripeキーだけでは、脅威アクターの口座に数千ドルを送金することはできないかもしれませんが、脅威アクターに顧客の個人識別情報（PII）やその他の重要な内部データへのアクセス権を与える可能性はあります。テスト用の認証情報で機密性の高い内部データにアクセスできるかどうかは判断できないため、これらの結果は調査結果として残し、手動による選別を行うことにしています。
汎用的な「シークレット 修正を段階的に進める
汎用的な秘密情報の検出はフィルタリングの問題であり、フィルタリングは、一連の小さな成功を積み重ねることで成果が得られるものです。まずは、確実だとわかっている要素を取り除くことから始めます。こうした小さな変更がいくつか積み重なることで、大規模かつ効果的な汎用的な秘密情報の検出が可能になることを期待しています。
Betterleaksの現在のリリースでは、デフォルトで一般的な検索結果から公開可能なキーがフィルタリングされます。ぜひ試してみてください！
