次の方法で共有

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

  • [アーティクル]

グループ管理サービス アカウント (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 を検出する

Managed Service Accounts コンテナー

効率的な動作のためには、gMSA が Active Directory ユーザーとコンピューターの管理サービス アカウント コンテナーに含まれている必要があります。

この一覧にないサービス 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 に移動するには、次の手順に従います。

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

次のステップ

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