SPN とは何か。また Active Directory とセキュリティにおける役割は何か

サービス プリンシパル ネーム（Service Principal Names、SPNs）は Active Directory 上の一意の識別子であり、Kerberos 認証のためにサービス インスタンスをサービス アカウントへ対応付ける用途に使われます。この記事では、SPN の構造、登録方法、一意性の要件、ツール（例：setspn）、およびセキュリティ上の影響を説明します。Kerberoasting のような攻撃、ベスト プラクティス、検出方法、ハイブリッド環境・クラウド環境・コンテナ環境における高度なユースケースも扱います。

サービス プリンシパル ネーム（Service Principal Names、SPNs）の紹介

SPN（Service Principal Name）とは何でしょうか？Active Directory をある程度経験している Windows 管理者であっても、Service Principal Names がドメイン環境で果たす役割を知らないことがあります。セキュリティ プリンシパル名（security principal name、SPN）とは、特定のサービス インスタンスを、そのサービスを実行しているアカウントに関連付ける一意の識別子です。これにより、クライアントは Active Directory（AD）内の正しいサービスに対して認証し、接続できるようになります。これは、同一サービスの複数のインスタンスが異なるサーバー上で動作する可能性がある大規模なエンタープライズ環境で、特に重要です。この記事では、Active Directory の SPN とは何か、そのセキュリティへの貢献、そして今日のモダンなネットワークにおいてその利用がどのように拡大し続けているのかを説明します。

Kerberos 認証における SPN の役割

飛行機に乗る、映画館に入るにはチケットが必要であるのと同様に、Active Directory（AD）内のリソースにアクセスするためにもチケットが必要です。クライアントが AD 上でホストされているサービスへのアクセスを要求すると、プロセスは次のように進みます：

1. クライアントがそのサービスを利用しようとすると、そのサービスの SPN を作成します
2. クライアントは、その SPN を使ってチケットをドメイン コントローラーに要求します
3. ドメイン コントローラーが、その SPN を Active Directory で検索します
4. 見つかると、ドメイン コントローラーがサービス チケットを発行します
5. クライアントはこのチケットを使って、パスワードなしでサービスに認証します

基本を分解して理解する

SPN の構成要素

SPN は複数のコンポーネントで構成されており、それらを組み合わせることで特定のサービスに対する完全な識別情報を提供します:

1. サービス クラス：これはサービス インスタンスの名前です。たとえば、Microsoft SQL Server では “MSSQLSvc”、Web サービスでは “www” などです。
2. ホスト名：サービスが実行されているサーバーまたはホストを指定します。Windows マシンの NetBIOS 名（例: “FilerServer”）である場合もあれば、“fileserver.company.com” のような完全修飾ドメイン名である場合もあります。
3. アカウント：サービスに関連付けられた Active Directory アカウント。これは SPN 文字列自体の一部ではなく、サービス プリンシパル名が登録されるアカウントです。
4. ポート （任意）：サービスが標準以外のポートで動作している場合は、SPN にそのポートを指定できます。

Active Directory でよく使われる一般的な SPN の例

• Web サービス – HTTP/webserver.netwrix.com
• SQL Server – MSSQLSvc/myhost.redmond.microsoft.com:1433
• ファイル共有 – CIFS/fileserver.contoso.com
• リモート デスクトップ サービス – TERMSRV/rdserver.abcdomain.com
• LDAP 認証 – LDAP/domaincontroller.fabricam.com

SPN と Active Directory：そのつながり

SPN が Active Directory オブジェクトと連携する仕組み

SPN は、ユーザー アカウント、サービス アカウント、コンピューター オブジェクトなどの AD オブジェクトに関連付けられた属性です。SPN は、どのアカウントの下でどのサービスが実行されるかを示すラベルとして機能します。この仕組みにより、コンピューターはネットワーク上にパスワードを送信せずに、Kerberos を使って安全に認証を行えます。サービスをインストールまたは構成すると、そのサービスは Kerberos が認証要求を正しいアカウントに対応付けられるよう、SPN を登録します。SPN が適切に構成されていない場合、Kerberos の認証は失敗し、認証エラーやサービスの中断につながる可能性があります。

servicePrincipalName 属性における SPN の格納

SPNは、オブジェクトの servicePrincipalName 属性の一部として Active Directory に保存されます。この属性は、コンピューター アカウントとサービス アカウントの両方に存在します。以下のスクリーンショットに示すように、Active Directory Users and Computers を使用してオブジェクトの詳細プロパティからこの属性を確認できます。

この属性には、そのオブジェクトに割り当てられた SPN の一覧が格納されています。各 SPN エントリは、サービス種別、ホスト、および（任意の）ポート番号を含む構造化された形式に従います。

次のコマンドを使用すると、AD オブジェクトの SPN を確認できます：setspn –L hostname。以下の例では、このコマンドを使って ABCDomain.com というドメインに対し、ドメイン コントローラーが生成した SPN の一覧を表示しています。

AD フォレストにおける SPN の一意性の重要性

各サービス プリンシパル名（service principal name）は、Active Directory フォレスト全体にわたって一意である必要があります。この一意性により、Kerberos がサービス要求を適切なアカウントに正しくルーティングできるようになります。異なるアカウントに同じ SPN が重複していると認証の競合が発生し、予測できない動作や、場合によっては認証の完全な失敗につながります。

SPN の設定：ステップバイステップガイド

SPN 設定に必要なツール

SPN の設定における主なツールは、Windows Server オペレーティング システムに組み込まれている setspn.exe です。このコマンドライン ツールにより、管理者は Active Directory のサービス アカウントに対するサービス プリンシパル名を読み取り、変更し、削除できます。

以前の例では、setspn -L を使ってコンピューター オブジェクトの SPN を表示しました。SPN を追加するには、setspn -S も使用できます。たとえば、webserver1 というコンピューターに HTTP SPN を追加するには、次のコマンドを実行します:

setspn -S HTTP/webserver1.abcdomain.com abcdomain\serviceaccount

setspn -S コマンドは、新しい SPN を作成する前に、既存の同一 SPN があるかどうかを自動的に確認して、重複したエントリを防ぎます。

SPN を削除するには、setspn -D コマンドを使用します。SPN については、PowerShell でも複数の方法で対応できます。たとえば、次の PowerShell cmdlet は Active Directory に登録されているすべての SPN を見つけます：

Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName | Select-Object Name, servicePrincipalName

これは重複しているすべての SPN を検出します。

$SPNs = Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName |

Select-Object -ExpandProperty servicePrincipalName

SPN 登録のベストプラクティス

• SPN 登録のためのサービス アカウントには、必要最小限の権限だけを付与する
• 新しい SPN を登録する前に、PowerShell で重複を確認する：
• SPN を定期的に監査し、不必要または古くなったエントリを特定して削除する
• SPN を追加するときは、標準化された SPN 命名形式を使用します

一般的な SPN 問題のトラブルシューティング

重複した SPN は認証の失敗を引き起こす可能性があるため、必ず解決する必要があります。SPN の競合を示している場合があるため、ユーザーから断続的なアクセスの問題が報告されていないか注意してください。下のスクリーンショットに示すように、setspn -x コマンドを使用すると、単一ドメイン内の重複を見つけられます。

setspn -F コマンドを使用して、フォレスト全体を検索します。重複した SPN を解決するには：

1. 重複した SPN を保持しているアカウントを特定します。
2. どのアカウントが正当に SPN を保持すべきかを判断します。
3. setspn -D <SPN> <AccountName> を使用して、誤ったアカウントから SPN を削除します8。
4. setspn -S <SPN> <AccountName> を使用して、正しいアカウントに SPN を追加します

重複に加えて、その他のよくある SPN の誤設定には次のようなものがあります。

• サービス用の SPN が欠落している
• 誤ったアカウントに登録された SPN
• サーバー名変更後に残る古い SPN

（すでに取り上げた同じツールを、ここであらためて再掲する必要はありません）

高度な SPN の概念

複数サービスおよび複数ホスト環境における SPN の役割

サービスアカウントは、Windows Server 上で動作するサービスのために作成された専用のユーザーアカウントです。これにより、Internet Information Services (IIS) のような重要なアプリケーションにおいて、ドメイン アカウントを分離して保護するのに役立ちます。複雑な環境では、複数のサービスが同じマシン上で動作することがよくあり、それぞれが適切な認証のために異なる Service Principal Names (SPNs) を必要とします。

よくある例として、Web アプリケーションをホスティングするサーバーでは SQL Server と IIS の両方が動作することがあります。各サービスには、正しい Kerberos 認証を行うためにそれぞれ固有の SPN が必要です。:

• IIS の場合: HTTP/servername.domain.com
• SQL Server の場合: MSSQLSvc/servername.domain.com:1433

マルチホスト環境では、サービスがロードバランシングやフェイルオーバーのために複数のサーバーにまたがって稼働するため、SPN の設定はより複雑になります。たとえば、共有 DNS 名のもとで複数のサーバー（Web01、Web02、Web03）にまたがって Web アプリケーションがホスティングされているケースを考えてください。このシナリオでは、すべてのホスト間でシームレスな認証を可能にするために、SPN は 1 台のサービス アカウントに登録する必要があります。:

特殊なケース：HOST SPN とその固有の動作

HOST SPN は、Active Directory のコンピューター オブジェクトに自動的に登録される SPN の特別な種類です。これらは、マシンのローカル システムまたはネットワーク サービス アカウントの下で実行されるサービスに対するキャッチオール識別子として機能します。これにより、多くの標準的な Windows サービスの管理が簡単になり、手動での SPN 設定の必要性が減ります。

次の図で、HOST SPN と Custom SPN の使い分けの目安をまとめます：

ヒント：HOST SPN は AD によって管理されるため、手動で変更してはいけません。

SPN とセキュリティ上の影響

AD 環境において SPN を保護することが重要な理由

SPN に対するセキュリティが重要である理由は単純です。サービスアカウントは、多くの場合、昇格した権限を持ちます。さらに、ネットワーク内の重要なシステムに継続的にアクセスでき、作成された後は忘れられがちです。これらすべてにより、攻撃者にとって高価値の標的になります。SPN を侵害すると、重要なサービスへの不正アクセスにつながり、攻撃者がネットワーク内で横方向に移動して、権限を昇格できる可能性があります

脆弱な SPN はどのように悪用されるか

SPN が弱い設定になっている場合、Kerberoasting のような攻撃によって悪用される可能性があります。攻撃者がこのような攻撃を実行する手順は次のとおりです:

• ドメイン権限が最小の攻撃者でも、任意の SPN に対してサービスチケットを要求できます。Requests service tickets for these SPNs
• サービスアカウントのパスワードハッシュで暗号化されたサービスチケットは抽出でき、オフラインで解読（クラック）するために持ち出すことが可能です。
• これらに対してオフラインでパスワードのクラックを行います。パスワードが弱い場合、攻撃者はそれをクラックしてサービスアカウントにアクセスできる可能性があり、多くの場合、権限が昇格された状態になります。

攻撃者がサービスアカウントのパスワードをクラックし、そのアカウントが高い権限を持っている場合、ネットワーク内で横方向に移動したり、アクセス権限をエスカレーションしたりできます。

SPN とサービスアカウントを保護するためのベストプラクティス

SPN に関連するセキュリティリスクを軽減するためのベストプラクティスの一覧は以下のとおりです：

• SPN を持つアカウントには長く複雑なパスワードを使用し、定期的にローテーション（変更）してください
• Domain Admins などの高権限アカウントに SPN を割り当てないようにしてください
• サービスアカウントには、その機能を実行するために必要な権限のみに制限してください
• サービスアカウントの対話型ログオンを無効にしてください
• PowerShell で SPN 関連コマンドが想定外に使用されていないか監視してください。
• ドメイン認証を持つすべてのユーザーは SPN を検索できるため、Active Directory の権限を変更して、これらのクエリを実行できる対象を制限する必要があります。

SPN の悪用を検知し、軽減する

SPN 関連の活動を監視し、監査する

AD 環境を継続的に監視し、Kerberos 関連イベントを監査することは、SPN の悪用を防ぐうえで非常に有効である可能性があります。検知すべきものには、次のようなものがあります。

• 攻撃者がLDAPツールを使用してADに対してSPNを照会する可能性があるため、異常なSPN列挙リクエスト。
• サービスチケット要求が急に急増すると攻撃が進行中であることを示す可能性があるため、頻繁なKerberosチケット要求。
• 通常の指定された場所ではなく、想定外の場所からのサービスアカウントのログイン。
• 認証の失敗が繰り返される場合、password spraying やブルートフォースの試行が示唆されるため、認証失敗の試行。

SPNベースの攻撃に対する緩和策の実装

組織が Windows Active Directory 環境で運用している場合は、SPN の悪用や Kerberoasting 攻撃のリスクを最小限に抑えるために、次の予防的なセキュリティ対策を検討してください。

• サービス アカウントには長く複雑なパスワードを使用してください（絶対最低 14 文字）
• 異なるアカウント間でパスワードを使い回さず、パスワードを定期的にローテーションしてください
• 最小権限の原則 を適用して、アカウント権限を制限してください。
• 攻撃の猶予期間を最小化するために、Kerberos チケットの有効期間を短く強制してください
• 定期的にSPNを見直し、古くなった、または不要なSPNを削除します
• 強力なサービスアカウント管理、洗練された監視、定期的なトレーニングプログラムを組み合わせた多層防御戦略を採用してください。

グループ管理サービスアカウントと強力な暗号化方式の使用

自動化されたパスワード管理の利点を得るために、グループ管理サービスアカウント（Group Managed Service Accounts, gMSAs）を導入します。グループ管理サービスアカウント（Group Managed Service Accounts, gMSAs）は、従来のサービスアカウントと比べて強化されたセキュリティ機能を提供する、Active Directory の専用サービスアカウントです。これらは、SQL Server、IIS Web アプリケーション、スケジュールされたタスクなどのサービスを実行するドメイン参加サーバー、または特定の権限を持つセキュリティコンテキストで実行する必要があるその他のサービスに特に有効です。gMSAs を利用すると、手動でのパスワード割り当てが不要になり、資格情報の窃取リスクを低減できます。暗号化に関しては、Active Directory でより弱い DES と RC4 の暗号化タイプを無効化しつつ、強力な AES128/AES256 Kerberos 暗号化を適用してください。

実践的な適用例とユースケース

先述のとおり、SPN は Web アプリケーションやデータベースの Kerberos 認証に使用されます。IIS は「HTTP/ServerName」という形式の SPN を使用し、アプリケーション プールを実行するドメイン アカウントにマッピングされます。一方、「MSSQLSvc/host.domain.com:1433」は SQL サービス アカウントの例です。ただし、企業がますますハイブリッド ネットワーク アーキテクチャを採用するようになったことで、Service Principal Names (SPNs) の役割は従来の用途を超えて進化しています。現在では、SPN によりオンプレミスのリソースとクラウド ネイティブ アプリケーション間の安全な認証が可能になるケースも見られます。その他の例には次のようなものがあります:

• SPN は、コンテナ化された環境内に配置されたコンテナ化アプリケーションおよびサービスに対するアイデンティティとアクセスを管理するために使用されています。
• エッジ環境では、エッジ デバイスと集中管理されたクラウド リソース間の安全な通信を促進するために SPN が使用されます。
• Azure AD Connect は、オンプレミスの AD と Azure AD の間で同期サービスを行うために SPN を使用します。

今日では、企業環境内での SPN の利用も増えています。たとえば、セキュリティ チームは SPN の使用ログを監視して、不正なアクセス試行や Kerberos の失敗を検出しています。その他の例には次のようなものがあります:

• シングル サインオン（Single Sign-On、SSO）：SPN により、複数のアプリケーションやサービスにわたって Kerberos ベースの SSO を実現できます。
• アプリケーション統合：SPN は、異なるエンタープライズ アプリケーションやサービス間の安全な通信を促進します。
• 委任認証：SPN により、複数層のアプリケーションにおいてサービスがユーザーの代わりに認証を行えます。

結論

サービス プリンシパル名（Service Principal Names、SPN）は、Active Directory の登場以来ずっと Kerberos 認証の基盤を担ってきました。ネットワーク ユーザーが依存する多くの代表的なサービスにおいて、SPN は定番として利用されており、多数のバックグラウンド サービスにわたって安全かつシームレスな運用を実現するうえで重要な役割を果たします。組織が継続的に拡大・進化するにつれて、SPN の用途はクラウド統合や IoT といった分野にも広がっています。今日の企業ではセキュリティへの重要性が高まっているため、SPN は新しい技術や、拡大し続けるデジタル環境におけるセキュリティ課題に適応しながら、より大きな役割を担う可能性が高いでしょう。