IT用語集 2023/10/27

NTLMとは？わかりやすく10分で解説

コラム

NTLM（NT LAN Manager）は、主にWindows環境で長く使われてきた認証方式です。チャレンジ・レスポンス方式により、パスワードそのものをネットワーク上に送らずに本人確認を行える一方、現代の脅威（リレー攻撃やパス・ザ・ハッシュなど）を前提にすると注意すべき点も多く、可能であればKerberosなどへの移行が推奨されます。本記事では、NTLMの概要、認証の流れ、NTLMv1とNTLMv2の違い、代表的なリスクと対策を整理します。

はじめに

NTLM認証プロトコルは、Windowsベースのネットワークで広く利用されてきました。このプロトコルは、ユーザーがネットワークリソースへアクセスする際の認証を担います。

NTLMとは？

NTLMは、Windows環境で利用されてきた認証プロトコルです。基本はチャレンジ・レスポンス方式で、サーバーがクライアントに一意のチャレンジ（ランダム値）を送り、クライアントはそのチャレンジと資格情報（パスワードそのものではなく、パスワードから導かれる値）を用いて計算したレスポンスを返します。これにより、パスワードをそのままネットワーク上で送らずに認証できます。

ただし、NTLMは設計が古く、現在のActive Directory環境ではKerberosが優先されるのが一般的です。一方で、互換性などの理由からNTLMが残っている環境もあります。

NTLMの歴史

NTLMは、Microsoftによって開発され、初期のWindowsネットワークで利用されてきました。その後も互換性維持のために長く残り、NTLMv1からNTLMv2への改良が行われています。ただし、現在は標準的な認証基盤という位置づけではなく、「段階的な移行が求められるレガシー方式」として扱われる場面が増えています。

NTLMの認証プロセス

NTLMは、ユーザーの秘密情報を直接やり取りせずに正当性を確認するため、チャレンジ・レスポンス方式を用います。ここでは、その流れと関連する保護機能の考え方を整理します。

チャレンジ・レスポンス方式

チャレンジ・レスポンス方式は、NTLM認証の中心となる仕組みです。サーバーがクライアントへチャレンジ（ランダム値）を送り、クライアントはそれを用いてレスポンスを生成して返します。サーバーはそのレスポンスを検証し、正当なユーザーかどうかを判断します。

ここで重要なのは、NTLMが平文のパスワードを送らない点です。一方で、ネットワーク上を流れるのはレスポンスであり、設計上の制約から、攻撃者が環境内で横方向の展開を狙える余地が残る場合があります（後述するリレー攻撃やパス・ザ・ハッシュなど）。

セッションセキュリティ

NTLMには、認証後の通信を保護する仕組みとして、メッセージ署名（改ざん検知）や、条件によっては暗号化（シーリング）を行う機能があります。ただし、これは常に自動で暗号化されるという意味ではなく、プロトコルや設定、利用するアプリケーションの実装に依存します。

そのため、「NTLMを使っているから通信が必ず暗号化される」とは考えず、必要に応じてTLSの利用やSMB署名などの設定と組み合わせ、通信経路の保護を設計することが重要です。

NTLMのバージョン

NTLMには複数のバージョンがあります。ここでは、NTLMv1とNTLMv2の違いを中心に整理します。

NTLMv1

NTLMv1は初期のバージョンで、基本的なチャレンジ・レスポンスを提供します。ただし、現在の基準では暗号学的に弱い点が多く、推測や解析、再利用といった攻撃に対して不利になりやすいことから、可能な限り利用を避け、無効化を検討するのが一般的です。

NTLMv2

NTLMv2は、NTLMv1の弱点を改善する目的で導入されたバージョンです。レスポンス生成の仕組みが強化され、NTLMv1と比べると安全性は向上しています。

ただし、NTLMv2であっても、NTLM自体が持つ構造的な課題（認証の中継を悪用するリレー攻撃など）を完全に解消するものではありません。実運用では、Kerberosの利用を優先し、NTLMは必要最小限にとどめる考え方が現実的です。

NTLMのセキュリティ面での課題

NTLMは、パスワードを平文で送らない点では一定の意味がありますが、現代の攻撃手法を前提にすると注意すべきリスクがいくつか存在します。

パスワードハッシュの悪用（パス・ザ・ハッシュ）

NTLMでは、パスワードそのものではなく、パスワードから生成される情報をもとに認証が行われます。攻撃者が端末やサーバーから資格情報（ハッシュやそれに類する情報）を取得できた場合、パスワードを知らなくても認証に悪用できるケースがあります。これが、いわゆるパス・ザ・ハッシュの代表的なリスクです。

単純に「ネットワーク盗聴でハッシュが流れる」という話ではなく、侵害後の横方向の展開で問題になりやすい点として理解するのが実態に近いでしょう。

リレー攻撃（中継）

NTLMの代表的な脅威として、認証のやり取りを攻撃者が中継（リレー）し、別のサーバーに対して本人になりすましてアクセスを成立させる攻撃が知られています。これは、過去のレスポンスをそのまま再利用する単純なリプレイ攻撃とは異なり、リアルタイムで中継されることで成立します。

その結果、機密情報の閲覧や、権限によっては設定変更などにつながる可能性があります。

NTLMのセキュリティ強化

NTLMを完全に排除できない環境であっても、設定や設計を見直すことでリスクを下げることは可能です。ここでは考え方を整理します。

セキュリティのベストプラクティス

実務上の基本的な方針は次の通りです。

可能な限りKerberosを優先し、NTLMは必要最小限にとどめる
NTLMv1の利用は避け、許容する場合でもNTLMv2に限定する
通信経路はTLSなどで保護し、「NTLMだから安全」と考えない
管理者権限の分離、端末防御、ログ監視を含めて横方向の展開を抑える

一般的なセキュリティ課題と対策

代表的な課題（パス・ザ・ハッシュ、リレー攻撃など）への対策としては、環境に応じて次のような項目が検討対象になります。

NTLMの利用制限（利用状況の可視化と段階的な縮小）
SMB署名の有効化など、プロトコル側の保護機能の活用
不要なサービスの停止や、不要な到達経路の削減
特権アカウントの利用ルール強化（端末分離、最小権限）

重要なのは、「NTLMを安全に使う」ことよりも、NTLMに依存しない構成へ移行しつつ、残る部分を堅くするという考え方です。

NTLMと他の認証プロトコル

認証方式は用途に応じて複数存在します。ここでは、NTLMと混同されやすいKerberos、および現代のWeb系プロトコルについて整理します。

Kerberos認証プロトコルとの比較

Active Directory環境で一般に優先されるのがKerberosです。Kerberosはチケットベースで認証を行い、スケールさせやすく、設計としてもNTLMより現代的です。

一方、NTLMは互換性や構成上の理由から残る場合があります。ただし、セキュリティと運用の観点では、可能な限りKerberosへ寄せるのが基本方針になります。

現代の認証プロトコル

クラウドやWebアプリケーションでは、OAuthやOpenID Connect（OIDC）などが一般的です。これらはAPI連携やシングルサインオンを前提に設計されており、用途もNTLMとは異なります。

社内のWindows認証と、Webやクラウドの認証では前提条件が異なるため、NTLMを現代的なプロトコルで置き換えられるかどうかは、アプリケーション構成や要件に依存します。まずは用途を切り分けて考えることが重要です。

まとめ

NTLMは、Windows環境で長く使われてきた認証方式で、チャレンジ・レスポンスによりパスワードを平文で送らずに本人確認を行えます。一方で、リレー攻撃やパス・ザ・ハッシュといった現代の攻撃手法を前提にすると課題も多く、可能であればKerberosの利用を優先し、NTLMは段階的に縮小するのが現実的です。

NTLMを残す場合でも、NTLMv1を避ける、通信経路を保護する、利用範囲を制限する、特権運用を見直すといった対策を組み合わせることで、リスクを下げることができます。