近年、システム全体のセキュリティポリシーにおける要件が厳格化するなかで、乱数生成機構の品質を確認する機会が増えています。とくに企業や公共機関では「NIST SP 800-90Aに準拠したDRBG（擬似乱数生成器）が使用されているか」を指摘されるケースも少なくありません。今回は、Windows ServerのログオンセッションIDであるLUIDに焦点を当て、その乱数部分がNIST SP 800-90Aに準拠しているのかどうか、現状の情報や対策を踏まえて詳しく解説していきます。
Windows ServerのLUIDと乱数生成の背景
Windows Serverを運用していると、ログオンセッションID（LUID: Locally Unique Identifier）という用語に触れる機会があるかもしれません。LUIDはシステム内でセキュリティ上の文脈を持つ「一意の識別子」であり、新規ログオンが行われるたびに生成されます。これはログファイルのトラッキングなどにも利用されるため、その重複が起こりにくさは非常に重要です。
一般的に、LUIDは64ビットの値をもち、そのうち前半32ビットが特定の情報で埋められ、後半32ビットがランダム値と見られています。ここで「乱数部分がどのように生成されているか」が、セキュリティポリシーを重視する組織では大きな論点となる場合があります。たとえば、暗号鍵などに使う乱数の場合は、暗号学的に強度のある乱数生成器（DRBG）によって生成されることが求められます。しかし、LUIDの用途はそもそも暗号学的な耐性を目的としていないことが多く、「重複が極めて起こりにくい」ことを重視しているのが一般的です。
ログオンセッションID（LUID）とは
Windowsオペレーティングシステムにおいて、ユーザのログオンごとにセキュリティコンテキストを識別するための一意のIDがLUIDです。このIDを利用することで、同一ユーザであっても別のログオンセッションであれば別の権限管理やイベントトラッキングが行えます。イベントビューアなどでセキュリティログを追跡するときにも、LUIDが役立ちます。
たとえば、LUIDの生成ロジックとして次のように考えられています。
- LUID上位32ビット: ある固定された値やシステム時刻、あるいは連続的なカウンタなど。
- LUID下位32ビット: システムが乱数生成器を用いてランダムに付与する部分。
しかし公式に公開されている情報は限られており、確実に「こういう仕組みだ」と言い切れる文書は見当たりません。Microsoftが提供しているドキュメントも、詳細な実装には踏み込んでいないのが現状です。
ログオンセッションIDの役割
ログオンセッションIDは、多数のユーザが同時にログオンする大規模環境において衝突を起こさず、かつシステムが一意にセッションを識別できるかどうかが最大のポイントです。暗号鍵の安全性のように「第三者が推測できない」ことよりも、「絶対に重ならない」ことの方がはるかに重要視されるケースが多いです。
そのため、実際には暗号学的な強度までは求められず、乱数生成といっても「連番をベースに少しばかりのランダム要素を加える」という程度の実装でも、要件が満たせていると考える運用者は少なくありません。
NIST SP 800-90Aへの準拠性の考察
NIST SP 800-90Aとは、アメリカ国立標準技術研究所（NIST）が公開している暗号学的擬似乱数生成器（DRBG: Deterministic Random Bit Generator）に関するガイドラインです。要件が厳しく、たとえば一定のエントロピーソースや内部状態の更新方法など、暗号学的安全性を確保するための細かい指針が定められています。
Windows Serverの乱数生成の一般的な仕組み
Windowsには、CryptGenRandomやBCryptGenRandomといったAPIが用意されており、これらは暗号学的に安全な乱数を生成するために設計されたものです。これらのAPIがどのように内部的にエントロピーソース（CPUの動作タイミング、ネットワークスタックの状態など）を取り込んでいるのか、詳しくは公開されていませんが、少なくとも暗号目的で使用しても問題ないレベルのセキュリティを確保していると謳われています。
一方で、LUIDに使われている下位32ビットの乱数部分が、これら暗号学的に安全なAPIに依拠しているのか、それとも別の仕組みで生成されているのか、Microsoftは公式には明らかにしていません。
BCryptGenRandomの存在
BCryptGenRandomは、Windows Vista以降に導入されたCNG（Cryptography Next Generation）APIの一部です。たとえば開発者がC言語やC++で次のように呼び出すことによって、安全な乱数を取得できます。
#include <Windows.h>
#include <bcrypt.h>
int main() {
NTSTATUS status;
unsigned char buffer[16];
status = BCryptGenRandom(NULL, buffer, sizeof(buffer), BCRYPT_USE_SYSTEM_PREFERRED_RNG);
if (status == 0) {
// bufferに乱数が格納
} else {
// エラー処理
}
return 0;
}このAPIは暗号用途のトークン生成にも使われるため、一定のレベルでNIST SP 800-90Aに準拠した動作を行っているとみなせます。しかし、LUID生成がこの仕組みを直接使っているかは依然として不明です。実際に「LUIDはBCryptGenRandomの出力を利用しています」という公式情報は公表されていません。
公開情報では不明な点
LUID生成プロセスにおいてNIST SP 800-90Aに準拠しているかどうかを判断するには、以下の情報が必要です。
- 乱数生成のAPIまたは関数の特定
- 内部状態（シードやカウンタなど）の取り扱い
- 出力をどのようにLUIDの一部に組み込んでいるか
しかし、Microsoftはこれらの詳細を一般に公開していません。公式ドキュメントでも、LUID生成アルゴリズムを詳細に説明する文書は見当たりません。「LUIDが一意になるよう配慮された値である」という程度の説明があるのみで、その乱数が暗号学的強度を持つかどうかを示す公式言及は今のところ見つかりません。
疑問の背景：コンプライアンス要件
セキュリティ監査などの場面で、「すべての乱数がNIST SP 800-90Aに準拠していなければならない」と厳格に定義される場合があります。これは主に機密性の非常に高い場面や厳格な政府認証（FIPS 140-2/3など）を必要とする場面でよく言及されます。
実際、ログインセッションIDにまでその要件を求めるかどうかはケースバイケースですが、顧客や監査機関がそこまで突っ込んでくると、プロジェクト担当者としては根拠となる資料を探さなければならない場面に直面するでしょう。
実際の運用上の影響と対応策
LUIDはセッションの重複回避を目的として設計されているため、基本的には暗号学的強度よりも一意性が重視されています。ここで「NIST SP 800-90A準拠が必要なのか？」という議論が起こる背景には、以下のような観点があると考えられます。
- 監査や顧客要件の厳格化
顧客や監査団体が、システム内のあらゆる乱数について「NIST SP 800-90Aの準拠確認」を求める可能性があります。厳密にはログオンセッションIDが暗号強度を要するものではなかったとしても、形式的に要件を満たすことが望まれる場合があります。 - 誤解による過剰要求
そもそもNIST SP 800-90Aは暗号用途の乱数生成に焦点を当てており、すべての乱数が同規格に準拠しなければならないわけではありません。しかしながら、セキュリティ要件策定時に「乱数」を一括りにしてしまい、結果としてLUIDのようなセッションIDにまで過剰な要求が及ぶケースが見受けられます。 - 別途の暗号トークン等との混同
シングルサインオン用トークンやセッション管理のCookieなどであれば、確かに暗号学的に安全な乱数を用いる必要性があります。これらとLUIDを混同し、同じ要求水準を当てはめようとしているケースもあります。
こうした背景から、もし自社あるいは顧客の要望として「LUIDの乱数部分はNIST SP 800-90Aに準拠したDRBGで生成されている必要がある」と言われた場合、最初に確認すべきは「本当にLUIDに暗号学的強度が必要なのか？」という点です。
Microsoftによる公式見解は？
現時点で、Microsoftは公式ドキュメントやTechNet、MSDN、Microsoft Docsなどで「LUIDがNIST SP 800-90Aに準拠した乱数生成器を用いている」と明言していません。サポート部門に問い合わせたとしても、内製の機密情報に踏み込む内容であれば、直接的な回答を得ることは難しい場合があります。
一方で、Microsoftが提供するFIPSモード（WindowsのFIPS準拠暗号化モード）では、暗号化関数やPRNG（BCryptGenRandom）などがFIPS承認済みとしての動作を行う設定が可能です。しかし、それがLUID生成にまで適用されているかどうかは、同様に明らかになっていません。もし「FIPSモードを有効にしていれば、すべての乱数がNIST SP 800-90A準拠になるのか？」と言われれば、そう単純でもないのが実情です。
NIST SP 800-90A準拠を確保するための代替案
システム要件としてどうしても「NIST SP 800-90Aに準拠した乱数生成器が必要」となった場合、LUIDの乱数部分がそれに合致するかどうかが不明瞭である以上、以下のような代替案を検討することが望まれます。
1. 独自の乱数生成とID付与
ログオンセッションに付与するIDが暗号学的強度を要すると監査などで判断された場合、WindowsのLUIDとは別途に、自前でNIST SP 800-90A準拠の乱数を生成して管理する方法があります。具体的には以下のようなステップが考えられます。
- 暗号用API（BCryptGenRandomなど）を利用した32ビット、あるいは64ビットのランダム値を生成する。
- 生成された値を、独自のセッション管理テーブルのキーやトークンとして使用する。
- WindowsのLUIDは内部処理に任せつつ、監査対象としてはあくまでも独自生成のトークンを参照するようにする。
このようにすれば、LUIDの挙動に依存せず、自社独自のIDがNIST SP 800-90A準拠の乱数で生成されることを保証できます。
2. 監査での説明資料の工夫
もし監査が「全乱数がNIST SP 800-90A準拠である必要がある」と主張してきた場合、そもそも「LUIDは暗号強度を必要とする用途ではなく、一意性を確保するためのIDである」ことを説明し、納得を得るというアプローチがあります。
具体的には、次のような資料を用意することが考えられます。
- LUIDの目的と役割を解説したドキュメント
- Microsoft公式ドキュメントからの引用（LUIDの重複回避やセキュリティコンテキスト管理に関する情報）
- 暗号用途とは区別される設計思想である旨の解説
監査側としても、用途が異なるIDにまで暗号学的強度を要求するのは過剰だと理解してくれる可能性があります。
3. Microsoftへの直接問い合わせ
大規模プロジェクトや公共事業など、どうしても監査要件が厳しい場合には、Microsoftのエンタープライズサポートを利用して直接問い合わせるのが最も確実なアプローチです。内部仕様まで開示されるかは不透明ですが、少なくとも「NIST SP 800-90A準拠かどうか」の公式見解をもらえる可能性がわずかながらあります。
まとめと今後の展望
ここまで見てきたように、Windows ServerのログオンセッションIDであるLUIDがNIST SP 800-90Aに準拠しているかどうかを、公開情報だけで判断することは現実的に困難です。Microsoftは公式ドキュメントでLUID生成アルゴリズムの詳細を明らかにしておらず、暗号強度よりも一意性を重視した設計である点を考慮すると、必ずしもNIST SP 800-90Aを前提としたDRBGを利用しているとは限りません。
一方で、暗号学的に安全な乱数を求めるのであれば、BCryptGenRandomのようにFIPS 140-2/3で承認された暗号モジュールと連携する機能を利用できます。監査や顧客要件でどうしても乱数の安全性を証明する必要がある場合は、LUIDとは別途、NIST SP 800-90Aに準拠した乱数生成器を導入してIDやトークンを生成する仕組みを構築し、監査側に示す方法が現実的です。
最終的には、LUIDを無理やり暗号用途として使おうとするのではなく、「LUIDはあくまでもセッション管理のための内部IDである」という点を正しく説明したうえで、暗号強度が必要な部分（パスワードハッシュやセッショントークンなど）は別の仕組みを活用していくのが望ましいといえます。今後、MicrosoftがWindowsの内部アーキテクチャに関してさらなる情報公開を行う可能性もありますが、現時点では不透明な部分が多いため、必要な要件がある場合は自社のシステム設計でカバーしていく姿勢が重要となるでしょう。
参考情報を踏まえた追加の実務ポイント
最後に、具体的な実務ポイントを整理しておきます。これは、システム監査の観点やセキュリティポリシー策定の段階で役立つはずです。
| 項目 | 概要 | 推奨アクション |
|---|---|---|
| LUIDの扱い | Windows内部で自動生成される一意のID。重複防止が主目的 | 他システム連携や監査の際は「あくまでもセッションID」という位置づけを強調 |
| 暗号学的強度 | NIST SP 800-90A準拠を満たすかは不透明 | 暗号用の乱数API（BCryptGenRandomなど）の利用を検討 |
| 監査対応 | 「すべての乱数＝NIST SP 800-90A準拠」という誤解が多い | 用途による違いを説明し、必要なら独自に安全な乱数生成器を導入 |
| Microsoft公式ドキュメント | 詳細実装は非公開。FIPSモードとも関連が不透明 | 正式な回答が必要ならMicrosoftのサポートに問い合わせ |
このように、LUIDの乱数部分に関しては「NIST SP 800-90A準拠が確実とは言えない」という結論になります。しかし、運用上はLUIDを暗号目的に使うことが想定されていないケースが多いため、大半のシステムでは問題になりません。顧客要件や監査要件でどうしてもNIST SP 800-90Aに準拠している証拠が必要ならば、独自の乱数生成プロセスを採用することがもっとも現実的です。
コメント