Azure Monitor でのきめ細かい RBAC (プレビュー)

2025-05-19

Azure Monitor Log Analytics のきめ細かなロールベースのアクセス制御 (RBAC) を使用すると、ビジネスとセキュリティのニーズに合わせて指定した条件に基づいて、各ユーザーが表示またはクエリできるワークスペースデータをフィルター処理できます。このアクセス制御の利点は次のとおりです。

行レベルのアクセス
テーブルレベルのアクセス
制御プレーンとデータプレーンの分離

Log Analytics アーキテクチャに、データの分離、プライバシー、またはコンプライアンスに対応するための複数のワークスペースが含まれている場合は、必要なワークスペースの数を減らすことで、きめ細かい RBAC を簡素化できます。

概要ビデオ

[前提条件]

アクション	アクセス許可が必要
新しいカスタムロールを作成する	`Microsoft.Authorization/roleDefinitions/write` 割り当て可能なスコープにおける権限。たとえば、特権組み込みロールによって提供されるユーザーアクセス管理者などです。
条件の追加または更新	`Microsoft.Authorization/roleAssignments/write` および `Microsoft.Authorization/roleAssignments/delete` の権限を Log Analytics ワークスペースに付与します。たとえば、特権組み込みロールとして提供されているです。

きめ細かい RBAC はどのような場合に使用しますか。

きめ細かい RBAC は、次のシナリオを実現するのに役立ちます。

データの分離 - 異なるユニット、チーム、地理的な場所のデータを同じワークスペース内から分離し、各ユーザーが自分のグループに関連するデータにのみアクセスできるようにします。アクセス条件では、カスタムログフィールドを使用して、ファイアウォール、デバイスの種類、サブスクリプション ID、その他の識別子などの属性によって分離された行レベルのアクセスを適用します。
データプライバシー - 個人情報、健康記録、金融取引などの機密データや機密データを保護し、承認されたユーザーにのみアクセスを許可します。
データコンプライアンス - 細かい RBAC をツールとして使用して、業界または地域の規制または法的要件を満たすのに役立ちます。データアクセスと使用状況に対して適切なポリシーと制御を適用します。

きめ細かい RBAC では、データの表示やクエリなどのデータアクセスを制御します。データアクセス、ワークスペース管理、変換、データエクスポートのアクセス許可の設定など、コントロールプレーンアクションには対応していません。

詳細な RBAC を構成する

ステップバイステップのきめ細かい RBAC の例を使用して、きめ細かい RBAC を開始しましょう。

次のセクションでは、詳細な RBAC の構成に関連する主要な概念と手順の概要について説明します。

ロールの作成
条件と式
式の演算子

ロールの作成

詳細な RBAC を構成するには、必要な アクション を使用してカスタムロールを作成し、条件を持つカスタムロールを割り当てる必要があります。カスタムロールの詳細については、「Azure カスタムロール」を参照してください。

カスタムロールアクションとデータアクションに必要な最小限のアクセス許可は次のとおりです。

カスタムロール定義	権限	説明
コントロールプレーンアクション (アクション)。	`Microsoft.OperationalInsights/workspaces/query/read`	Log Analytics でクエリを実行し、メタデータを表示します。このアクセス許可では、データへのアクセスは許可されません。
データプレーンアクション (DataActions)	`Microsoft.OperationalInsights/workspaces/tables/data/read`	データへのアクセス。ロールの割り当て条件で選択された `dataaction` です。条件が設定されていない場合、このアクセス許可は、割り当てられたスコープ内のすべてのデータへのアクセスを許可します。

必要に応じて、 Microsoft.OperationalInsights/workspaces/read 制御アクションを追加して、Azure portal からのアクセスを含めます。詳細については、 Azure RBAC の制御とデータアクションに関するページを参照してください。

注

きめ細かい RBAC は、Azure RBAC と同じように加算方式のモデルです。有効な権限は、ロールの割り当ての合計です。詳細な RBAC 条件を有効にするには、より高いアクセス特権を持つロールの割り当てを削除する必要があります。

たとえば、同じスコープに 2 つのロールの割り当てがあり、1 つは */read アクションで設定され、もう 1 つは特定のレコードへのアクセスを制限する条件を持つ場合、結果のアクセス許可はスコープ内のすべてのログへのアクセスを許可する */read アクションです。明示的なアクションとしての拒否は存在せず、拒否の割り当てのみが存在します。

条件と式

通常のロールの割り当てと同様に、作成されたカスタムロールをユーザーまたはグループに割り当てる必要があります。違いは、ロールの割り当て中に、アクセス制御を細かく調整するように条件が構成されていることです。

詳細な RBAC を使用すると、各レコードのデータに基づいて、テーブルと行レベルで条件を設定できます。次の 2 つの戦略に基づいて制限を計画します。

アクセス制御方法	例
許可されているデータを除き、データへのアクセスは許可されません	アプリケーションログへのアクセスを制限して、 `application id` 列がアクセスが許可されているアプリケーションのレコードのみを表示できるようにします。
許可されていないデータを除くすべてのデータへのアクセス	`userPrincipalName`列が CEO であるレコードを除き、すべてのサインインログへのアクセスを許可します。

条件は、ロールのデータアクションと式で構成されます。式は、 AttributeOperatorValue形式のロジックステートメントです。

値は、次の文字をサポートして制限されます。

英数字
特殊文字:@、 .、 -

Log Analytics の詳細な RBAC では、テーブル属性と列/値属性がサポートされます。

Attribute source (属性ソース)	表示される名前	タイプ	説明	属性名
リソース	テーブル名	糸	権限の付与/制限に使用されるテーブル名。	Microsoft.OperationalInsights/workspaces/tables:`<name>`
リソース	列の値 (キーは列名)	ディクショナリ (キー値)	列名と値。列名はキーです。列のデータ値は値です。	Microsoft.OperationalInsights/workspaces/tables/record:<key>

Azure portal を使用して構成された許可された部分のデータにのみアクセス可能となる方法を用いた、細かな RBAC ロール割り当て条件のスクリーンショットの例を次に示します。

条件を一致するように設定したスコープできめ細かい RBAC ロールの割り当てを構成することで、複雑さを軽減します。たとえば、カスタムロールがリソースグループスコープで割り当てられている場合、他のワークスペースに式にテーブルまたは列リソースが指定されていないため、条件が予期せず適用される可能性があります。

ただし、テーブルレベルでロールの割り当ての条件を設定する場合は、次のように 2 つのロールを作成する必要があります。

ロール1: テーブルのワークスペースに対するアクション: Microsoft.OperationalInsights/workspaces/query/read
ロール 2: このワークスペース内のテーブルに対する DataAction: Microsoft.OperationalInsights/workspaces/tables/data/read 。データアクションを使用してロールの条件を定義します。

2 つのロールを作成しないようにするには、ワークスペースでロールを割り当て、テーブルレベルを制御する条件を設定することで、最も簡単な方法を使用します。

詳細については、 Azure RBAC のスコープレベルに関するページを参照してください。

式の演算子

詳細な RBAC 式では、属性ベースのアクセス制御 (ABAC) 演算子のサブセットが使用されます。

テーブル名属性は、4 つの演算子をサポートします。これらの演算子を使用すると、条件を設定するときにテーブル名の値を柔軟に照合できます。

ABAC 演算子	説明
`StringEquals`	大文字と小文字が区別される照合。値は文字列と正確に一致している必要があります。
`StringNotEquals`	StringEquals の否定。
`ForAllOfAnyValues:StringEquals`	論理的には `in()`と同等です。左側のすべての値が右側の少なくとも 1 つの値との比較を満たす場合、式は true に評価されます。
`ForAllOfAllValues:StringNotEquals`	論理的には `!in()`と同等です。左側のすべての値が右側の少なくとも 1 つの値との比較を満たす場合、式は false に評価されます。

Log Analytics の列値に定義されている ABAC 条件は、その列のデータに基づいています。比較できるのは文字列データ型だけです。行レベルのアクセス属性の場合、キャストは KQL の動作のみに基づいています。

次の表に、サポートされている ABAC 式演算子を示します。わかりやすくするために、同等の Kusto 演算子が一覧表示されています。

ABAC 演算子	Kusto の同等の演算子	説明
`StringEquals` / `StringEqualsIgnoreCase`	`==` / `=~`	大文字と小文字を区別する (または大文字と小文字を区別しない) 一致。値は文字列と正確に一致している必要があります。
`StringNotEquals` / `StringNotEqualsIgnoreCase`	`!=` / `!~`	StringEquals (または StringEqualsIgnoreCase) の否定。
`StringLike` / `StringLikeIgnoreCase`	`has_cs` / `has`	大文字と小文字を区別する (または大文字と小文字を区別しない) 一致。演算子の右辺 (RHS) が左辺 (LHS) に 1 つの項として含まれる
`StringNotLike` / `StringNotLikeIgnoreCase`	`!has_cs` / `!has`	StringLike (または StringLikeIgnoreCase) 演算子の否定
`StringStartsWith` / `StringStartsWithIgnoreCase`	`startswith_cs`/ `startswith`	大文字と小文字を区別する (または大文字と小文字を区別しない) 一致。値は文字列で始まります。
`StringNotStartsWith` / `StringNotStartsWithIgnoreCase`	`!startswith_cs` / `!startswith`	StringStartsWith (または StringStartsWithIgnoreCase) 演算子の否定。
`ForAllOfAnyValues:StringEquals` / `ForAllOfAnyValues:StringEqualsIgnoreCase` `ForAllOfAllValues:StringNotEquals` / `ForAllOfAllValues:StringNotEqualsIgnoreCase` `ForAnyOfAnyValues:StringLikeIgnoreCase`	`In` / `In~` `!in` / `!in~` `has_any`	'ForAllOfAnyValues:<BooleanFunction>' は、複数の文字列と数値をサポートしています。左側のすべての値が右側の少なくとも 1 つの値との比較を満たす場合、式は true と評価されます。

ABAC 条件は関数に直接設定されません。テーブルに条件を設定すると、それに依存するすべての関数に反映されます。演算子と用語の詳細については、「文字列演算子」を参照してください。

ヒント

変換を使用して、ABAC 式に合わせて、データの強化、データ型の変更、大文字と小文字の変更を行います。適用する条件がデータでサポートされていない場合は、変換もソリューションです。たとえば、IP 範囲などのカーディナリティの高いデータに条件を適用するには、変換を使用して、選択したサブネットに属する IP をサブネット名でグループ化します。

詳細については、「 Azure Monitor でのデータ収集変換」を参照してください。

考慮事項

Log Analytics で詳細な RBAC を使用する場合は、いくつかの考慮事項が適用されます。次のセクションでは、詳細について説明します。

きめ細かい RBAC は、パブリッククラウドでのみ使用できます。

Azure Monitor

検索ジョブと概要ルールは、詳細な RBAC サポートのために計画されていますが、データエクスポートは計画されていません。これらすべてのエクスペリエンスで、クエリ対象テーブルへのフルアクセスが存在しない場合、ユーザーは検索ジョブまたはルールを構成できず、エラーを受け取ります。
アラート: マネージド ID ベースのログアラートのみがサポートされます。
Application Insights: ワークスペースベースの Application Insights のみがサポートされています。

Microsoft Sentinel

ハンティング、ブックマーク、分析ルール、インシデントを使用して元のテーブルからデータをレプリケートする場合、レプリケートされたデータは ABAC 条件によって保護されません。

Azure ABAC と RBAC

通常の Azure RBAC と ABAC の制限が適用されます。たとえば、サブスクリプションあたりのロールの最大割り当てのしきい値は、RBAC の Azure サービスの制限です。 Azure ABAC では、条件ごとの式の数と条件の全体的なサイズが KB 単位で制限されます。詳細については、次の記事を参照してください。

監査と監視

ロールの割り当ての変更は、Azure アクティビティログに記録されます。 LAQueryLogs テーブルのユーザークエリは、クエリが該当する ABAC アクセス条件を使用して ConditionalDataAccess 列で実行されたかどうかを示します。 Log Analytics ワークスペースの診断設定を使用してログを有効にします。詳細については、 Azure Monitor ログの診断設定に関するページを参照してください。

よく寄せられる質問

リソースコンテキストを使用してログにアクセスしています。私の条件は強制できますか?
RBAC と ABAC はリソースコンテキストクエリに適用されますが、次の前提条件を満たすためにリソースログを含むワークスペースが必要です。

関連するすべてのワークスペースの アクセス制御モード を [ワークスペースの アクセス許可を要求する] に設定します。
[ リソースまたはワークスペースのアクセス許可を使用する] に設定されている場合、リソースに割り当てられた Azure 読み取りアクセス許可によって、すべてのログへのアクセスが提供されます。ワークスペースと ABAC のアクセス許可は無視されます。
関連するすべてのワークスペースに ABAC を設定します。

詳細については、 Log Analytics ワークスペースへのアクセスの管理、アクセスモードに関するページを参照してください。

テーブルがエクスポートされるときに、きめ細かい RBAC 条件は保持されますか?
詳細な RBAC 条件は、クエリにのみ適用されます。たとえば、ワークスペースデータエクスポート機能を使用して正常にエクスポートされたデータは、ターゲットテーブルのデータに対する ABAC 条件を維持しません。

データ分類に基づいてアクセスを構成する方法
Bell-LaPadula スタイルのアクセスモデルを実装するには、「読み取りダウン」などの原則に従うために、ABAC 条件を明示的に設定する必要があります。たとえば、トップシークレットのアクセス許可を持つユーザーは、上位の割り当てレベルよりも低いレベルのデータにアクセスできるように、シークレット、機密、未分類などの下位レベルに対して明示的に設定されたアクセス許可を持っている必要があります。