開発者ツール · UUID ジェネレーター
シーケンシャル ID によるビジネス データの漏洩: パブリック API が UUID を公開する理由
· なぜそれが重要なのか
uuid 暗号化 ブラウザ API
自動インクリメント ID により、部外者に注文件数が通知され、すべてのレコードが列挙可能になります。この投稿では、UUID の公開によって何が修正されるのか、何が修正されないのか、そして移行せずに UUID を導入する方法について説明します。
請求書番号が競合他社にあなたの量を伝えている - /orders/10482 での情報漏洩
/orders/10482 を返す API エンドポイントは、注文の詳細そのもの以上のことを部外者に伝えます。数値識別子は、少なくとも 1 万件の注文を処理したことを示し、成長率に関する情報を暗示し、すべての注文を推測可能にします。連続番号による単純なループにより、認証や権限のチェックを行わずにすべてのレコードが取得されます。このパターンは、システムが単一のレコードを表示するために認証を必要とする場合でも、URL、データベース キー、請求書番号、トランザクション ID など、あらゆる場所に現れます。この問題は、レポート作成と分析においてさらに複雑になります。 /orders/1, /orders/2, を取得し、引き続き /orders/10482 を実行できる攻撃者は、注文履歴と傾向の包括的なビューを取得します。
列挙とスクレイピング — 連続 ID が 1 つの公開レコードをすべてのレコードに変換する方法
連続パターンにより、注文が到着する時期、言及される製品、および価格設定のパターンの傾向が明らかになります。観察者は、ビジネスの成長率または縮小率を学習します。 ID の列挙のみから得られるその情報は、競争戦略を知らせたり、ソーシャル エンジニアリングをガイドしたり、他の攻撃のタイミングを知らせたりすることができます。この暴露は発見するのに何の費用もかからず、URL、ブラウザ履歴、キャッシュされたページ、サーバー ログに現れます。これは理論上の話ではありません。競争力のあるインテリジェンス企業や好奇心旺盛なエンジニアは、公的に数えられる ID から日常的にビジネス指標を抽出しています。データを収集して基本的な分析を実行する意欲のある人であれば、注文番号のサンプルから生産率と総量が明らかになります。
ドイツ戦車の問題を 1 つの段落で説明 — 連続した番号のサンプルから合計を推定する
列挙は統計分析を適用して総量を推定し、時間的パターンを追跡します。最初の注文が既知の日に発生し、1 週間にまたがる 10 件の注文の証拠を取得した場合、平均間隔によって全体のレートが推定されます。競合他社、投資家、攻撃者は、ID 自体を超えて顧客データにアクセスすることなく、ベロシティを導き出すことができます。連続した識別子により、現在の番号より大きいすべての ID が将来の注文を予測することが保証されます。サンプル内の最小値より小さいすべての ID は、以前の操作が小さかったことを裏付けます。履歴データ ポイントにより成長のタイムラインが作成され、予測が可能になります。これと同じ原則が、金融取引、配送注文、医療記録、および連続 ID を公開するシステムなどの業界全体に当てはまります。
UUID の修正内容 — 推測不可能な参照と ID 自体の増加シグナルなし
ランダムに生成された UUID は、RFC 9562 がバージョン 4 に対して指定しているように、暗号的に安全なソースから生成された場合、122 ビットのエントロピーを含みます。識別子は推測や数えることができず、外部の観察者には成長率や量について何も明らかにしません。 /orders/9a1f4e2b-7c3e-4d1a-8a5f-1b2c3d4e5f60 を知っている攻撃者は、次の注文の UUID を予測したり、合理的な自信を持って過去の ID を遡ったりすることはできません。 UUID 自体は、一意ではあるが完全に不透明な参照になります。ランダムな分散とは、API を監視している外部の観察者に対して、複数のクエリによってパターン、進行状況、速度の情報が明らかにされないことを意味します。
UUID では修正できないもの — 推測不可能な ID は認証ではなく、不明瞭さの背後にあるアクセス チェックが依然として必要です
パブリック API でシーケンシャル ID を UUID に置き換えるのは操作が簡単で、システム間の複雑な調整は必要ありません。 UUID 列を注文テーブルに追加し、新しい注文ごとに 1 つ生成し、応答で UUID を公開し、数値キーを徐々に非推奨にします。内部システムは、パフォーマンスと簡素化のために整数の主キーを引き続き使用できます。パブリックインターフェイスのみが変更されます。古い連続 ID は、独自の参照または監査証跡のためにデータベースに残りますが、顧客およびサードパーティには UUID のみが表示されます。このデュアルキーのアプローチは、不透明な識別子を外部に公開しながら、既存のインデックスのパフォーマンスを維持するためのベスト プラクティスです。
実用的な例 — 内部整数キーの横にパブリック UUID 列を追加し、前者のみを公開する
UUID はパスワードではなく、隠蔽性はセキュリティ制御ではないため、このアプローチは実際の承認とは異なります。 /orders/{their-uuid} への正当なアクセス権を持つ顧客はそれを表示できるはずですが、/orders/{someone-elses-uuid} はアクセス チェックで拒否される必要があります。 UUID は、注文番号を偶発的な検査から隠し、列挙による統計分析を防ぎますが、認証および認可ロジックはアプリケーション コードの責任のままです。保護は階層化されており、UUID によって識別子自体の情報漏洩が阻止され、アクセス制御によってその識別子に対して誰が操作できるかが強制されます。
これでカバーされないもの — ランダム キーのインデックスとパフォーマンスのトレードオフについては、別の投稿で説明します
UUID は ID 自体の情報漏洩を修正しますが、アクセス制御メカニズムを置き換えるものではないため、運用境界は重要です。顧客が API キーと十分な権限を持っている場合は、システムにリクエストを送信できます。ユーザーがアクセスできる範囲は、ID 形式ではなく、権限モデルとロール定義によって決まります。 UUID の利点は純粋に、識別子がボリューム、シーケンス、および増加データを観察できる人にブロードキャストすることを停止することです。適切に設計されたシステムでは、UUID の不透明度と、API へのすべてのリクエストに対する明示的なアクセス制御チェックが組み合わされます。
要点: パブリック参照を内部キーから分離する — ToolAcre ジェネレーターは、パブリック側に CSPRNG でサポートされた UUID を提供します
実際の移行では、両方の形式を段階的にサポートすることで、危険日を回避します。エンドポイントをバージョン管理すると、v1 API は引き続き整数 ID を返し、v2 は UUID を返すことができます。クライアントは、調整された切り替えを必要とせずに、自分のペースで移行します。内部データベース クエリは変更されません。インデックスはその列に基づいて構築され、外部キーはその列を参照するため、整数 ID によってフィルタリングされます。クライアントに返されるデータのみが変更されます。 ToolAcre UUID ジェネレーターは、使用するバージョン 4 形式を生成します。各出力は正しい RFC 9562 UUID であり、ストレージ、展開、および段階的な移行シナリオに対応できます。