開発者ツール · UUID ジェネレーター
名前ベースの UUID (v3 および v5): 名前空間からの決定的な ID
· 背景
uuid 暗号化 ブラウザ API
同じ外部レコードが常に同じ識別子を取得する必要がある場合、ランダムな UUID では対応できません。バージョン 3 および 5 の UUID は、名前空間と名前を安定した ID にハッシュします。この投稿では、それらをいつどのように使用するかを説明します。
同じ顧客を 2 回再インポートする - 決定的 ID が解決する重複の問題
データ インポート パイプラインは、システム内で安定した外部 ID を持つ外部システムから顧客レコードを受け取ります。インポート実行ごとに新しいランダムな UUID を生成する場合、同じ顧客を 2 回インポートすると、2 つの異なる識別子と重複したレコードが生成されます。この重複は下流のレポート、請求、サポート システムに流れます。顧客の外部 ID とインポート ソースを表す安定した名前空間から UUID を派生すると、インポートごとに同じ顧客に対して同じ UUID が生成され、既存のレコードを識別して更新できるようになります。この決定性は、v3 および v5 の UUID の特徴です。UUID は独立して生成されるのではなく、入力から導出され、同じ入力から常に同一の UUID が生成されます。
名前空間と名前 — 入力がどのように連結およびハッシュされるか、および名前空間が異なるソース間の衝突を防ぐ理由
v3 または v5 UUID は、名前空間 UUID (通常は事前定義)、名前 (任意のバイト文字列)、およびハッシュ アルゴリズム (v3 の場合は MD5、v5 の場合は SHA-1) の 3 つのコンポーネントから派生します。名前空間 UUID の 16 バイトと名前の UTF-8 バイトを連結し、連結をハッシュし、ハッシュ出力の最初の 16 バイトを取得し、それらのバイトをバージョン ニブルが 3 に設定された UUID として解釈します。 5。名前空間は ID 空間を分割します。DNS 名前空間の v5 UUID が URL 名前空間の v5 UUID と衝突することはありません。 RFC 9562 では、DNS 名、URL、OID、X.500 識別名という 4 つの事前定義された名前空間が定義されています。組織は、v4 UUID を生成することで、独自の名前空間を作成できます。
MD5 および v5 の SHA-1 — ID はセキュリティ制御ではないため、ここで弱められたハッシュが許容される理由
バージョン 3 は MD5 を使用し、バージョン 5 は SHA-1 を使用します。選択は仕様の日付と利用可能な実装に遡ります。名前ベースの UUID の場合、ハッシュ関数はセキュリティ境界または暗号化制御ではないため、この区別は重要ではありません。 UUID は信頼性や完全性を証明していません。これは、可変長文字列を固定の 128 ビット値に変換するだけです。 UUID は証明やセキュリティ制御としてではなく、不透明な値として保存および比較されるため、攻撃モデルは無関係です。新しい実装では、v3 (MD5) ではなく v5 (SHA-1) を使用する必要があります。これは、やむを得ないセキュリティ上の理由からではなく、v5 が最新の標準であり、広く利用可能であるためです。
事前定義された名前空間 — DNS、URL、OID、X.500、および独自の名前空間をいつ作成するか
RFC 9562 は、特定のバイト表現を持つ 4 つの事前定義された名前空間 UUID を指定します。DNS の場合は 6ba7b810-9dad-11d1-80b4-00c04fd430c8、URL の場合は 6ba7b811-9dad-11d1-80b4-00c04fd430c8、 OID の場合は 6ba7b812-9dad-11d1-80b4-00c04fd430c8、X.500 識別名の場合は 6ba7b814-9dad-11d1-80b4-00c04fd430c8。 DNS 名前空間から派生した v5 UUID と www.example.com という名前は常に同一であり、URL 名前空間からの v5 UUID と衝突することはありません。事前定義された名前空間を使用すると、相互運用性が確保されます。複数のチームが DNS 名前空間で v5 を個別に使用する場合、同じ DNS 名に対して同一の UUID が生成されます。名前空間の選択または作成は、スキーマ設計の一部です。
実用的な例 — URL 名前空間とレコード URL から概念的に v5 UUID を段階的に導出する
URL 名前空間と名前 https://example.com/api/users/42. から概念的に v5 UUID を派生します。 16 バイトとしての名前空間 UUID は 6b a7 b8 11 9d ad 11 d1 80 b4 00 c0 4f d4 30 c8.名前は UTF-8 文字列 https://example.com/api/users/42, (30 バイト) です。名前空間バイト (16) と名前バイト (30) を連結して、合計 46 バイトを取得します。 SHA-1 ハッシュを計算し、20 バイトのハッシュを生成します。最初の 16 バイトを取得し、バージョン ニブルが 5 に設定され、バリアント ビットが RFC 標準に設定された UUID として解釈します。同一の入力を使用して再度計算すると、同一の結果が得られます。ほとんどの開発者は、言語 UUID ライブラリを使用して v5 を計算します。
パターンが崩れる場所 — 名前が変更された場合、名前空間がチーム間で一貫していない場合、および入力が機密である場合
名前ベースの UUID は、名前がシステム間およびインポート実行間で安定していて一貫していることを前提としています。同じ外部レコードが異なるシステムで異なる名前を持つ場合、それぞれの名前から v5 を生成すると異なる UUID が生成され、同一人物を識別できなくなります。名前空間がチーム間で合意されていない場合 (各チームが実際には同じソースに対して独自の名前空間を作成している場合)、異なる UUID が生成され、レコードの照合に失敗します。入力が機密データの場合、v5 UUID が生成されるということは、UUID が公開の決定論的な値であり、入力を知っていれば誰でも検索できることを意味します。入力が変更されたり、名前空間の定義が矛盾したりすると、決定論が崩れます。
これで説明されないこと — ToolAcre ジェネレーターは CSPRNG から取得するため、名前ベースの ID には言語の UUID ライブラリが必要です
ToolAcre は、独立性を確保するためにブラウザーの暗号的に安全なジェネレーターから抽出された v4 UUID のみを生成します。名前ベースの UUID 派生には、言語の UUID ライブラリ、または SHA-1 を計算して結果を正しくフォーマットする実装が必要です。この投稿では、概念と使用例について説明します。 v5 生成の実装は、標準の暗号化ライブラリにアクセスできれば、どの言語でも簡単に実行できます。 v5 派生の仕組みは単純です。課題は、名前空間が安定し、名前に一貫性があり、アプローチがチーム向けに十分に文書化されているシステム スキーマにそれを統合することです。開発チームは名前空間の選択を文書化する必要があります。
要点: 必要な場合は決定的、そうでない場合はランダム — 安定したマッピングには v5 を使用し、推測不可能であるべきすべてのものには ToolAcre ジェネレーターを使用してください
外部識別子と内部レコード間の安定したマッピングには v5 を使用してください。決定論により重複インポートが防止され、システム間でのレコードの照合が簡単かつ信頼できるものになります。名前ベースの UUID は、推測不可能である必要がある識別子や、強力な機密性や秘密が必要なシナリオには使用しないでください。 ToolAcre は、予測可能性を持たずに独立して区別する必要がある識別子に対してランダムな v4 UUID を生成します。入力を固定識別子にマップする決定論的な ID がシステムで必要な場合、言語の UUID ライブラリでそれらを計算できます。決定論は、入力を制御する場合の強力な機能です。