グループ管理サービスアカウントをセキュリティで保護する

[アーティクル]
10/25/2023

グループ管理サービスアカウント (gMSA) は、サービスのセキュリティ保護のためのドメインアカウントです。 gMSA は、1 台のサーバー上、またはサーバーファーム (ネットワーク負荷分散やインターネットインフォメーションサービス (IIS) サーバーの背後にあるシステムなど) で実行できます。 gMSA プリンシパルを使用するようにサービスを構成すると、アカウントのパスワード管理は Windows オペレーティングシステム (OS) によって処理されます。

gMSA の利点

gMSA は、管理オーバーヘッドを削減するのに役立つ、セキュリティが強化された ID ソリューションです。

強力なパスワードの設定 - ランダムに生成される 240 バイトのパスワード: 長くて複雑な gMSA パスワードより、ブルートフォース攻撃や辞書攻撃による侵害の可能性を最小限に抑えます。
パスワードの定期的な循環 - パスワード管理は Windows OS に移行し、30 日ごとにパスワードが変更されます。サービス管理者とドメイン管理者が、パスワードの変更をスケジュールしたり、サービス停止を管理したりする必要はありません。
サーバーファームへのデプロイのサポート - gMSA を複数のサーバーにデプロイして、複数のホストで同じサービスが実行される負荷分散ソリューションをサポートします。
簡略化されたサービスプリンシパル名 (SPN) 管理のサポート - アカウントの作成時に PowerShell を使用して SPN を設定します。
- また、gMSA のアクセス許可が正しく設定されていれば、自動 SPN 登録がサポートされているサービスでは、gMSA に対してそれを行うことができます。

gMSA の使用

フェールオーバークラスタリングなどのサービスでサポートされていない場合を除き、gMSA はオンプレミスサービスのアカウントの種類として使用します。

重要

運用環境に移行する前に、gMSA を使用してサービスをテストします。アプリケーションが gMSA を使用し、リソースにアクセスするように、テスト環境を設定します。詳細については、「グループ管理サービスアカウントのサポート」を参照してください。

サービスで gMSA の使用がサポートされていない場合は、スタンドアロン管理サービスアカウント (sMSA) を使用できます。 sMSA にも同じ機能がありますが、単一サーバーでのデプロイを対象としています。

サービスによってサポートされている gMSA または sMSA を使用できない場合、標準ユーザーアカウントとして実行するようにサービスを構成します。アカウントのセキュリティを維持するために、サービスとドメインの管理者は強力なパスワード管理プロセスを監視する必要があります。

gMSA セキュリティ体制を評価する

gMSA は、継続的なパスワード管理を必要とする標準ユーザーアカウントよりも安全性が高くなります。ただし、セキュリティ体制に関連して、gMSA のアクセススコープを検討してください。 gMSA を使用する場合の潜在的なセキュリティ問題とその軽減策を次の表に示します。

セキュリティ上の問題	対応策
gMSA が特権グループのメンバーである	- グループメンバーシップを確認します。グループメンバーシップを列挙する PowerShell スクリプトを作成します。 gMSA ファイルの名前で結果の CSV ファイルをフィルター処理します - 特権グループから gMSA を削除します - サービスの実行に必要な gMSA 権限とアクセス許可を付与します。サービスベンダーに問い合わせてください。
gMSA に、機密リソースへの読み取りおよび書き込みアクセス権がある	- 機密性の高いリソースへのアクセスを監査します - 監査ログを Azure Log Analytics や Microsoft Sentinel などの SIEM にアーカイブして分析します - 不要なアクセスレベルがある場合は、不要なリソース許可を削除します

セキュリティ上の問題

対応策

gMSA が特権グループのメンバーである

- グループメンバーシップを確認します。グループメンバーシップを列挙する PowerShell スクリプトを作成します。 gMSA ファイルの名前で結果の CSV ファイルをフィルター処理します
- 特権グループから gMSA を削除します
- サービスの実行に必要な gMSA 権限とアクセス許可を付与します。サービスベンダーに問い合わせてください。

gMSA に、機密リソースへの読み取りおよび書き込みアクセス権がある

- 機密性の高いリソースへのアクセスを監査します
- 監査ログを Azure Log Analytics や Microsoft Sentinel などの SIEM にアーカイブして分析します
- 不要なアクセスレベルがある場合は、不要なリソース許可を削除します

gMSA を検出する

組織が gMSA をお持ちの場合があります。これらのアカウントを取得するには、次の PowerShell コマンドレットを実行します。

Get-ADServiceAccount 
Install-ADServiceAccount 
New-ADServiceAccount 
Remove-ADServiceAccount 
Set-ADServiceAccount 
Test-ADServiceAccount 
Uninstall-ADServiceAccount

Managed Service Accounts コンテナー

gMSA が効果的に動作するには、管理サービスアカウントコンテナーに含まれている必要があります。

Screenshot of a gMSA in the Managed Service Accounts container.

この一覧にないサービス MSA を見つけるには、次のコマンドを実行します。


Get-ADServiceAccount -Filter *

# This PowerShell cmdlet returns managed service accounts (gMSAs and sMSAs). Differentiate by examining the ObjectClass attribute on returned accounts.

# For gMSA accounts, ObjectClass = msDS-GroupManagedServiceAccount

# For sMSA accounts, ObjectClass = msDS-ManagedServiceAccount

# To filter results to only gMSAs:

Get-ADServiceAccount –Filter * | where-object {$_.ObjectClass -eq "msDS-GroupManagedServiceAccount"}

gMSA を管理する

gMSA を管理するには、次の Active Directory PowerShell コマンドレットを使用します。

Get-ADServiceAccount

Install-ADServiceAccount

New-ADServiceAccount

Remove-ADServiceAccount

Set-ADServiceAccount

Test-ADServiceAccount

Uninstall-ADServiceAccount

注意

Windows Server 2012 以降のバージョンでは、*-ADServiceAccount コマンドレットは gMSA と連携します。詳細情報: グループ管理サービスアカウントの概要。

gMSA に移動する

gMSA は、オンプレミス用のセキュリティで保護されたサービスアカウントの種類です。可能であれば、gMSA を使用することをお勧めします。さらに、お使いのサービスを Azure に移動し、お使いのサービスアカウントを Microsoft Entra ID に移動することもご検討ください。

Note

gMSA を使用するようにサービスを構成する前に、「グループ管理サービスアカウントの概要」を参照してください。

gMSA に移動するには、次の手順に従います。

キー配布サービス (KDS) のルートキーがフォレストにデプロイされていることを確認します。これは 1 回限りの操作です。「キー配布サービス KDS ルートキーの作成」を参照してください。
新しい gMSA を作成します。「グループの管理されたサービスアカウントの使用開始」を参照してください。
サービスを実行するホストに新しい gMSA をインストールします。
サービス ID を gMSA に変更します。
空のパスワードを指定します。
お使いのサービスが新しい gMSA ID で動作していることを確認します。
古いサービスアカウント ID を削除します。

次のステップ

サービスアカウントのセキュリティ保護の詳細については、次の記事をご覧ください。

グループ管理サービス アカウントをセキュリティで保護する