スタンドアロン管理サービス アカウントをセキュリティで保護する
スタンドアロン管理サービス アカウント (sMSA) は、サーバーで実行されているサービスをセキュリティで保護するための、マネージド ドメイン アカウントです。 複数のサーバーにわたって再利用することはできません。 sMSA には、パスワードの自動管理、簡略化されたサービス プリンシパル名 (SPN) の管理、および管理者に管理を委任する機能があります。
Active Directory (AD) では、sMSA は、サービスを実行するサーバーに関連付けられています。 アカウントは、Microsoft 管理コンソールの [Active Directory ユーザーとコンピューター] スナップインにあります。
Note
管理サービス アカウントは、Windows Server 2008 R2 Active Directory スキーマで導入されたものであり、Windows Server 2008 R2 以降のバージョンが必要です。
sMSA の利点
sMSA は、サービス アカウントとして使用されるユーザー アカウントよりも高度なセキュリティを提供します。 管理オーバーヘッドの削減に役立ちます。
- 強力なパスワードの設定 - sMSA では、240 バイトのランダムに生成された複雑なパスワードが使用されます
- この複雑さにより、ブルート フォースや辞書攻撃による侵害の可能性が最小限に抑えられます
- パスワードの定期的な循環 - Windows によって、sMSA パスワードが 30 日ごとに変更されます。
- サービス管理者とドメイン管理者が、パスワードの変更をスケジュールしたり、関連するダウンタイムを管理したりする必要はありません
- SPN 管理の簡素化 - ドメインの機能レベル (DFL) が Windows Server 2008 R2 の場合、SPN は更新されます。 SPN は、次の場合に更新されます。
- ホスト コンピューター アカウントを変更する
- ホスト コンピューターのドメイン ネーム サーバー (DNS) 名を変更する
- PowerShell を使用して、他の sam-accountname パラメーターまたは dns-hostname パラメーターを追加または削除する
- 「Set-ADServiceAccount」を参照してください
sMSA の使用
sMSA を使用すると、管理タスクとセキュリティ タスクを簡単に実行できます。 sMSA は、サービスがサーバーにデプロイされていて、グループ管理サービス アカウント (gMSA) を使用できない場合に役立ちます。
注意
複数のサービスに対して sMSA を使用できますが、監査のために、各サービスには監査用の ID を設定することをお勧めします。
アプリケーションが MSA を使用しているかどうかをソフトウェア作成者が確認できない場合は、アプリケーションをテストします。 テスト環境を作成し、必要なリソースにアクセスできることを確認します。
詳細情報: 管理されたサービス アカウント: 理解、実装、ベスト プラクティス、およびトラブルシューティング
sMSA セキュリティ体制を評価する
セキュリティ体制の一部として、アクセスの sMSA スコープを検討してください。 潜在的なセキュリティの問題を軽減するには、次の表を参照してください。
| セキュリティ上の問題 | 対応策 |
|---|---|
| sMSA は特権グループのメンバーです。 | - 昇格された特権グループ (Domain Admins など) から sMSA を削除します - 最小特権モデルを使用します - サービスを実行するための sMSA の権利とアクセス許可を付与します - アクセス許可がわからない場合は、サービス作成者に問い合わせてください |
| sMSA には、機密リソースへの読み取りおよび書き込みアクセス権があります | - 機密リソースへのアクセスを監査します - 監査ログを Azure Log Analytics や Microsoft Sentinel などのセキュリティ情報およびイベント管理 (SIEM) プログラムにアーカイブします - 望ましくないアクセスが検出された場合は、リソースのアクセス許可を修正します |
| 既定では、sMSA パスワード ロールオーバーの頻度は 30 日です | グループ ポリシーを使用して、企業のセキュリティ要件に応じて期限を調整します。 パスワードの有効期限を設定するには、次の手順に進みます。 コンピューターの構成>ポリシー>Windows の設定>セキュリティ設定>セキュリティ オプション。 ドメイン メンバーの場合は、 [マシン アカウントのパスワード変更の最大有効期間] を使用します。 |
sMSA の課題
次の表を使用して、課題を軽減策に関連付けます。
| 課題 | 対応策 |
|---|---|
| sMSA は単一サーバー上にあります | 複数のサーバーにわたってアカウントを使用する場合は、gMSA を使用します |
| sMSA は複数のドメイン間では使用できません | 複数のドメインにわたってアカウントを使用する場合は、gMSA を使用します |
| すべてのアプリケーションで sMSA がサポートされるわけではありません | 可能な場合は gMSA を使用します。 可能でない場合は、作成者が勧める標準のユーザー アカウントまたはコンピューター アカウントを使用します |
sMSA の検索
ドメイン コントローラーで、DSA.msc を実行してから、管理サービス アカウントのコンテナーを展開して、すべての sMSA を表示します。
Active Directory ドメイン内のすべての sMSA と gMSA を返すには、次の PowerShell コマンドを実行します。
Get-ADServiceAccount -Filter *
Active Directory ドメイン内の sMSA を返すには、次のコマンドを実行します。
Get-ADServiceAccount -Filter * | where { $_.objectClass -eq "msDS-ManagedServiceAccount" }
sMSA の管理
sMSA を管理するには、次の AD PowerShell コマンドレットを使用できます。
Get-ADServiceAccount
Install-ADServiceAccount
New-ADServiceAccount
Remove-ADServiceAccount
Set-ADServiceAccount
Test-ADServiceAccount
Uninstall-ADServiceAccount
sMSA への移行
アプリケーション サービスで sMSA はサポートされているが gMSA がサポートされておらず、現在、セキュリティ コンテキストにユーザー アカウントまたはコンピューター アカウントを使用している場合は、「
管理されたサービス アカウント: 理解、実装、ベスト プラクティス、およびトラブルシューティング」を参照してください。
可能な場合は、Azure にリソースを移動し、Azure のマネージド ID またはサービス プリンシパルを使用します。
次のステップ
サービス アカウントのセキュリティ保護の詳細を確認する場合、次を参照してください。