Microsoft Sentinelでプレイブックを作成できたのに、自動化ルールから選択できない、または実行できない場合は、プレイブックの処理内容より先に権限を実行主体ごとに分けて確認します。
重要なのは、プレイブックを作成・編集する利用者の権限と、Microsoft Sentinelが自動化ルールからプレイブックを実行するための権限は別であることです。自動実行には、プレイブックが配置されているリソースグループに対して、Microsoft Sentinelのサービスアカウントへ「Microsoft Sentinel Automation Contributor」ロールが必要です。([Microsoft Learn][1])
Sentinelのプレイブックを実行できないときの権限の分け方
「Logic Appsでプレイブックを作成できた」という事実だけでは、自動化ルールから実行できることは保証されません。
Microsoft Sentinelのプレイブックには、主に次の権限が関係します。
| 操作 | 主な実行主体 | 確認する代表的なロール |
|---|---|---|
| Logic Appsを閲覧・編集する | サインイン中の利用者 | Logic App Contributorなど |
| 自動化ルールにプレイブックを設定する | サインイン中の利用者 | Microsoft Sentinel Contributor |
| インシデントから手動実行する | 利用者とSentinelサービスアカウント | Microsoft Sentinel Playbook Operator、Microsoft Sentinel Automation Contributor |
| 自動化ルールから実行する | Sentinelサービスアカウント | Microsoft Sentinel Automation Contributor |
| プレイブックへのアクセス権を付与する | 権限管理担当者 | OwnerまたはUser Access Administrator |
ConsumptionのLogic Appsでは、編集・管理に「Logic App Contributor」、読み取りや有効化・無効化には「Logic App Operator」が使われます。Standardでは「Logic Apps Standard Operator」「Logic Apps Standard Developer」「Logic Apps Standard Contributor」など、操作内容に応じたロールを確認します。([Microsoft Learn][1])
つまり、次の状態は矛盾ではありません。
- 利用者はLogic Appsを作成・編集できる
- プレイブック単体のテストもできる
- しかし自動化ルールではプレイブックがグレー表示になる
- または自動化ルールから呼び出せない
この場合、利用者側ではなく、Microsoft Sentinel側の実行権限が不足している可能性があります。
最初にプレイブックの配置情報を記録する
権限を確認する前に、対象プレイブックの情報を整理します。似た名前のプレイブックや別サブスクリプションのリソースを確認してしまうと、正しいロール割り当てを見落としやすくなります。
最低限、次の項目を記録してください。
| 確認項目 | 確認する理由 |
|---|---|
| プレイブック名 | 同名・類似名の取り違えを防ぐ |
| サブスクリプション | Sentinelワークスペースと別サブスクリプションか確認する |
| リソースグループ | Automation Contributorを付与する対象範囲を特定する |
| Logic Appsの種類 | ConsumptionとStandardで利用者側のロールが異なる |
| トリガーの種類 | インシデント、アラート、エンティティのどれかを確認する |
| 発生している症状 | 非表示、グレー表示、実行失敗を切り分ける |
| 発生時刻 | Logic Appsの実行履歴と照合する |
特に重要なのは、Microsoft Sentinelのワークスペースがあるリソースグループではなく、プレイブックが実際に配置されているリソースグループを確認することです。
プレイブックが起動できない箇所を切り分ける
権限を追加する前に、どの段階で止まっているかを確認します。失敗箇所によって、確認すべき権限や設定が異なります。
| 症状 | 優先して確認する項目 |
|---|---|
| Logic Apps自体を開けない | 利用者のLogic Apps閲覧権限 |
| プレイブックを編集できない | Logic App Contributor、Standard Developerなど |
| 自動化ルールを編集できない | Microsoft Sentinel Contributorなど |
| プレイブックが一覧に出ない | トリガーの種類、対象サブスクリプション、リソースグループ権限 |
| プレイブックがグレー表示される | SentinelサービスアカウントのAutomation Contributor |
| Logic Appsの実行履歴が作られない | Sentinelからの起動権限、ルールの条件、トリガー |
| 実行履歴はあるが途中で失敗する | コネクター認証、接続先APIの権限、入力値 |
| 手動テストだけ成功する | 手動テストとSentinel経由で実行主体が異ならないか |
Microsoft Learnでは、自動化ルールの「Run playbook」でプレイブックがグレー表示される場合、Microsoft Sentinelがそのプレイブックのリソースグループに対する権限を持っていない状態と説明されています。([Microsoft Learn][2])
トリガーの種類も確認する
自動化ルールに表示されるのは、ルールと互換性のあるトリガーで開始するプレイブックです。
たとえば、自動化ルールがインシデントを対象としている場合、通常はMicrosoft Sentinelのインシデントトリガーから始まるプレイブックを選択します。アラート用トリガーやエンティティ用トリガーで作成したプレイブックは、対象となる操作によっては一覧に表示されません。
Microsoft Learnでも、自動化ルールのトリガーと同じ種類のトリガーから始まるプレイブックだけが候補に表示されると説明されています。([Microsoft Learn][2])
権限を追加しても一覧に出ない場合は、プレイブックの先頭にあるMicrosoft Sentinelトリガーを確認してください。
利用者側のLogic Apps権限を確認する
次に、プレイブックを操作している利用者の権限を確認します。
Consumptionの場合
代表的なロールは次のとおりです。
| ロール | 主な用途 |
|---|---|
| Logic App Contributor | Logic Appsの編集、管理、実行 |
| Logic App Operator | 読み取り、有効化、無効化 |
プレイブックの設計変更が必要なのにLogic App Operatorしかない場合、内容を確認できても編集できないことがあります。
Standardの場合
代表的なロールは次のとおりです。
| ロール | 主な用途 |
|---|---|
| Logic Apps Standard Operator | ワークフローの有効化、無効化、再送信 |
| Logic Apps Standard Developer | ワークフローの作成、編集 |
| Logic Apps Standard Contributor | Logic Apps全体の管理 |
Standardのプレイブックに対して、Consumption用のロールだけを確認しても十分ではありません。最初に記録したLogic Appsの種類に合わせて確認します。([Microsoft Learn][1])
自動化ルールへ設定できる権限も別に確認する
Logic Appsを編集できても、Microsoft Sentinelの自動化ルールを編集できるとは限りません。
Microsoft Learnでは、「Microsoft Sentinel Contributor」がプレイブックを分析ルールや自動化ルールへ関連付けるためのロールとして示されています。([Microsoft Learn][1])
したがって、次の2つを分けて確認します。
- Logic Apps側でプレイブックを編集できるか
- Sentinel側で自動化ルールにプレイブックを設定できるか
両方を一つの「プレイブック権限」と考えると、原因を特定しにくくなります。
Sentinelサービスアカウントの実行権限を確認する
利用者側の権限に問題がなくても、自動化ルールから実行するには、Microsoft Sentinel自身に権限が必要です。
確認する条件は次のとおりです。
- 対象：Microsoft Sentinelがプレイブック実行時に使用するサービスアカウント
- ロール：Microsoft Sentinel Automation Contributor
- スコープ：プレイブックが配置されているリソースグループ
Microsoft Sentinelは、このサービスアカウントを使用してインシデントに対するプレイブックを実行します。対象リソースグループにAutomation Contributorが付与されると、Sentinelはそのリソースグループ内のプレイブックを実行できるようになります。([Microsoft Learn][1])
Sentinelの権限管理画面から確認する
自動化ルールを作成または編集し、「Run playbook」のアクションを追加したときにプレイブックがグレー表示される場合は、「Manage playbook permissions」に相当する権限管理機能を確認します。
基本的な確認の流れは次のとおりです。
- Microsoft Sentinelの対象ワークスペースを開く
- 自動化ルールの作成または編集画面を開く
- プレイブックを実行するアクションを追加する
- 対象プレイブックがグレー表示されていないか確認する
- プレイブックの権限管理を開く
- プレイブックが配置されているリソースグループを選択する
- 承認された権限管理手順に従って適用する
ポータルやワークスペースの状態によって画面構成や表記が異なる場合がありますが、確認対象は一貫して「プレイブックがあるリソースグループ」です。Microsoft Learnでも、権限管理画面で対象リソースグループを選択し、Microsoft Sentinelへ必要な権限を付与する手順が示されています。([Microsoft Learn][2])
権限を付与する担当者にも必要な権限がある
Microsoft Sentinel Automation Contributorを追加しようとしても、操作している利用者にロール割り当て権限がなければ変更できません。
Microsoft Learnでは、Sentinelへ必要な権限を付与するには、対象リソースグループで次のいずれかが必要とされています。
- Owner
- User Access Administrator
また、プレイブックを手動実行する利用者には、状況に応じてMicrosoft Sentinel Playbook Operatorが必要です。([Microsoft Learn][1])
権限変更ができない場合は、Ownerを自分や関係者全員へ追加するのではなく、既存の権限管理者へ次の情報を添えて依頼します。
対象プレイブック：
対象サブスクリプション：
対象リソースグループ：
必要なロール：Microsoft Sentinel Automation Contributor
付与対象：Microsoft Sentinelのサービスアカウント
目的：自動化ルールから対象プレイブックを実行するため依頼時にリソースグループ名を明記すると、Sentinelワークスペース側へ誤って付与されるのを防ぎやすくなります。
Ownerを全員へ付ける解決策は避ける
権限エラーを早く解消するために、利用者やサービスアカウントへOwnerを付与する方法は推奨できません。
Ownerはリソースの管理だけでなく、他の利用者へのアクセス付与も可能な強いロールです。一方、Microsoft Sentinel Automation Contributorは、自動化ルールからプレイブックを実行する目的で用意されたロールです。([Microsoft Learn][1])
基本的には、次の考え方で付与範囲を決めます。
- 利用者には、担当業務に必要な操作権限だけを付与する
- SentinelにはMicrosoft Sentinel Automation Contributorを付与する
- スコープは原則としてプレイブックがあるリソースグループに限定する
- 一時的な調査目的だけでOwnerを常設しない
- 権限変更は組織の承認手順と記録方法に従う
リソースグループ単位の付与は他のプレイブックにも影響する
Microsoft Sentinel Automation Contributorをリソースグループへ付与すると、Microsoft Sentinelはそのリソースグループ内にある他のプレイブックも実行できる状態になります。([Microsoft Learn][1])
そのため、プレイブックを配置するリソースグループの設計も重要です。
たとえば、次のようなプレイブックを同じリソースグループへ無条件にまとめると、権限範囲が広くなります。
- 通知だけを行う低リスクなプレイブック
- ユーザーアカウントを無効化するプレイブック
- 端末をネットワークから隔離するプレイブック
- IPアドレスやドメインをブロックするプレイブック
- 外部システムへチケットを登録するプレイブック
権限や運用担当が異なる場合は、用途やリスクに応じてリソースグループを分ける方法も検討します。
コネクターの認証失敗と起動権限不足を混同しない
Sentinelの起動権限と、プレイブック内部で使うコネクターの認証は別の問題です。
たとえば、次のような接続先があります。
- Microsoft Teams
- Outlook
- Microsoft Entra ID
- Microsoft Defender
- ServiceNowなどの外部サービス
- HTTPで呼び出す外部API
Microsoft Sentinel Automation Contributorが正しく付与されていても、各コネクターの接続情報が失効していれば、プレイブックは途中で失敗します。
実行履歴の有無で切り分ける
判断の目安は、Logic Appsに実行履歴が作成されているかどうかです。
| 状態 | 考えられる原因 |
|---|---|
| 実行履歴がない | Sentinelから起動されていない、条件不一致、トリガー不一致、起動権限不足 |
| 実行履歴があり開始直後に失敗 | トリガー入力、接続、初期アクションの問題 |
| 特定のアクションだけ失敗 | コネクター認証、接続先の権限、APIの入力値 |
| 最後まで成功している | SentinelからLogic Appsへの起動自体は成功している |
実行履歴が存在し、途中のコネクターで失敗している場合、Microsoft Sentinel Automation Contributorを追加しても解決しない可能性があります。
反対に、自動化ルールの実行時刻に対応するLogic Appsの実行履歴がまったく作られていない場合は、Sentinelからプレイブックへ到達する前の段階を優先して確認します。
Logic Appsでの手動テスト成功だけでは判断しない
プレイブックのデザイナーから直接テストして成功しても、自動化ルールから実行できるとは限りません。
Logic Apps上のテストでは、利用者が設定した接続やマネージドIDを使って処理が進みます。一方、自動化ルールからの呼び出しでは、Microsoft Sentinelがサービスアカウントを使ってプレイブックを起動します。([Microsoft Learn][1])
したがって、テスト結果は次のように区別します。
- Logic Appsから直接実行できる
プレイブック内部の処理やコネクターが動作する可能性は高い - Sentinelの自動化ルールから実行できる
Sentinelの起動権限、トリガー、ルール条件を含めて動作している - Sentinelのインシデント画面から手動実行できる
Sentinel経由の実行権限を確認する材料になる
「Logic Appsで成功したから権限に問題はない」と判断せず、実際に使用する起動経路で確認してください。
権限変更後は副作用のない対象でテストする
権限を修正した直後に、本番インシデントや実在する利用者、端末を対象として再実行するのは危険です。
プレイブックによっては、次のような副作用が発生します。
- メールやチャットを重複送信する
- 外部システムへ重複チケットを作成する
- ユーザーアカウントを無効化する
- 端末をネットワークから隔離する
- IPアドレスをブロックする
- インシデントの状態や担当者を変更する
再テスト前に、次の項目を確認します。
| 確認項目 | 具体的な対応例 |
|---|---|
| テスト対象 | テスト用インシデントや検証用アカウントを使用する |
| 外部通知 | 宛先を検証用チャネルへ変更する |
| 端末操作 | 実端末の隔離や停止処理を一時的に無効化する |
| 重複実行 | 同じチケットや通知が複数作成されないか確認する |
| 条件分岐 | テストモード用の条件を設ける |
| 実行結果 | Logic Appsの実行履歴で各アクションを確認する |
テスト用の対象を用意できない場合は、破壊的なアクションを一時的に無効化し、通知先や出力先を検証用へ変更してから実行します。
よくある確認漏れ
Sentinelワークスペース側のリソースグループだけを見ている
Automation Contributorを確認する対象は、原則としてプレイブックが配置されているリソースグループです。
Sentinelワークスペースとプレイブックが別のリソースグループにある構成では、確認場所を間違えやすくなります。
利用者のOwner権限だけを確認している
利用者がOwnerでも、Microsoft SentinelのサービスアカウントにAutomation Contributorが割り当てられていなければ、自動化ルールから実行できない場合があります。
確認対象は「自分の権限」だけではありません。
ConsumptionとStandardを区別していない
Logic Appsの種類によって、利用者側で確認するロールが異なります。
プレイブックの概要情報から種類を確認してから、該当するLogic Appsロールを調べます。
トリガーが自動化ルールと一致していない
インシデント用の自動化ルールから、アラート用またはエンティティ用のプレイブックを探しても、候補に表示されないことがあります。
権限変更の前に、プレイブックの先頭トリガーを確認します。
コネクターの再認証を権限追加で直そうとしている
実行履歴が作られた後にコネクターで失敗している場合は、接続情報や接続先権限の問題です。
Sentinelの起動権限と、プレイブック内部の認証を分けて調査します。
自動化ルールから起動できないときの確認順序
調査は、次の順序で進めると原因を絞り込みやすくなります。
- プレイブックのサブスクリプション、リソースグループ、種類を記録する
- インシデント、アラート、エンティティのトリガーを確認する
- 利用者がLogic Appsを閲覧・編集できるか確認する
- 利用者が自動化ルールを編集できるか確認する
- プレイブックが非表示か、グレー表示かを確認する
- プレイブックのリソースグループに対するSentinelの権限を確認する
- Microsoft Sentinel Automation Contributorが不足していれば、権限管理者へ依頼する
- テスト用対象で自動化ルールを実行する
- Logic Appsの実行履歴を確認する
- 実行開始後の失敗なら、コネクター認証や接続先権限を調べる
最初に行うべき作業は、プレイブックのリソースグループを特定し、その範囲でMicrosoft Sentinelのサービスアカウントに「Microsoft Sentinel Automation Contributor」が付与されているか確認することです。
ただし、権限を広く付ければよいわけではありません。対象リソースグループ内の他のプレイブックへの影響を確認し、承認された範囲で必要最小限の権限を設定したうえで、副作用のないテスト対象を使って再実行してください。
[1]: https://learn.microsoft.com/en-us/azure/sentinel/automation/automate-responses-with-playbooks “Automate Threat Response with Playbooks in Microsoft Sentinel | Microsoft Learn”
[2]: https://learn.microsoft.com/en-us/azure/sentinel/automation/run-playbooks “Automate and run Microsoft Sentinel playbooks | Microsoft Learn”
コメント