次の方法で共有

Azure Monitor で詳細な RBAC (プレビュー) を構成する

きめ細かいロールベースのアクセス制御 (RBAC) は、きめ細かいデータ アクセス制御を実装する Azure Monitor Log Analytics の機能です。

ロール、部門、地理的な場所に基づいてログへのアクセスを制御する方法について説明します。 これには、人事担当者を従業員データに制限したり、国または部門別にログへのアクセスを制限したりするシナリオが含まれます。

この例のシナリオでは、よく知られている Log Analytics のテーブルとフィールドを使用して、行レベルのアクセスを強制します。 データは、デバイスの種類やユーザー プリンシパル名 (UPN) などの属性に基づいて分離されます。

詳細な RBAC の概念の詳細については、 Azure Monitor でのロールベースのアクセス制御 (RBAC) に関するページを参照してください。

[前提条件]

このシナリオを完了するには、次の前提条件が必要です。

  • テーブルを含む Azure Monitor Log Analytics ワークスペース
  • カスタム ロールを構成し、ロール ベースのアクセス制御管理者 やユーザー アクセス管理者などの条件を持つユーザーまたはグループに割り当てるアクセス許可を付与する、アカウントに割り当てられたロール。

シナリオを定義する

このシナリオでは、行レベルのアクセス制御が、CommonSecurityLog に対しては制限の厳しい方法で、SigninLogs テーブルと DnsEvents テーブルに対しては許可的な方法で実装され、Logs Analytics ワークスペース内でそれぞれ制御されます。 演算子のグループの条件は、次のように設定されます。

  1. DeviceVendor 名がネットワーク ファイアウォールと一致する CommonSecurityLog テーブルにのみアクセスするように、ネットワーク チームのグループ アクセスを設定します。 この構成では 、許可される方法を除き、データへのアクセスなしを 使用します。
  2. 階層 1 のセキュリティ アナリスト チームにすべてのテーブルへのアクセス権を付与しますが、CEO の UPN またはコンピューター名を含むレコードにアクセスできないように、 SigninLogs テーブルと DnsEvents テーブルを制限します。 この構成では 、許可されていない方法を除き、すべてのデータへのアクセス が使用されます。

カスタム ロールを作成する

定義されたシナリオのカスタム ロールを設定します。 1 つはネットワーク チーム用、もう 1 つはセキュリティ チーム用に作成します。 ロールの割り当ては追加的であるため、詳細な RBAC 条件よりも多くの特権を与える読み取りアクセス権を割り当てるロールをすべて削除してください。 詳細については、「 詳細な RBAC ロールの作成を構成する」を参照してください。

  1. 前提条件の Log Analytics ワークスペースを含むリソース グループから、 アクセス制御 (IAM) を選択します。
  2. [カスタム ロールの追加] を選択します。
  3. リソース グループ レベルで次のアクションとデータ アクションを使用して、一般的なデータ アクセス ロールを作成します。
カスタム ロール定義 ディテール
アクション Microsoft.OperationalInsights/workspaces/read
Microsoft.OperationalInsights/workspaces/query/read
データ アクション Microsoft.OperationalInsights/workspaces/tables/data/read

この画像は、[カスタム ロールの 追加] ページにカスタム ロール アクションとデータ アクションがどのように表示されるかを示しています。 カスタム ロール アクションとデータ アクションがどのように表示されるかを示すスクリーンショット。

  1. カスタム ロールの名前を入力します (例: Log Analytics Network Device team
  2. Log Analytics Security Analysts tier 1カスタム ロールに対して手順 2 から 4 を繰り返します。 [ ロールの複製 ] オプションを使用し、ベースとして Log Analytics Network Device team ロールを選択します。

カスタム ロールを割り当てる

ユーザーまたはグループにカスタム ロールを割り当てます。 詳細については、「 詳細な RBAC ロールを割り当てる」を参照してください。

  1. Log Analytics ワークスペースから、 アクセス制御 (IAM) を選択します。
  2. [ロールの割り当ての追加] を選択します。
  3. 作成した Log Analytics Network Device team カスタム ロールを選択し、[ 次へ] を選択します。
  4. ロールを割り当てるユーザーまたはグループを選択し、[ 次へ] を選択します。 この例では、ネットワーク チーム セキュリティ グループにロールを割り当てます。
  5. 条件の選択>条件の追加>アクションの追加。
  6. [ワークスペース データの読み取り] データ アクションを選択します >[選択]。

完了すると、アクション部分がどのように表示されるかを次に示します。

[条件の追加] ページの [アクションの追加] 部分を示すスクリーンショット。

制限の厳しい条件を構築する

最初のカスタム ロールでは、許可された場合を除き、データへのアクセス権がないという戦略が使用されます。 このユース ケースでは、ネットワーク チームは CommonSecurityLog テーブルへのアクセスのみを必要とし、DeviceVendor がファイアウォール ソリューションと一致するレコード ( Check Point または SonicWall) に対してのみ必要です。

  1. [ ビルド式 ] セクションで、[ 式の追加] を選択します。
  2. [属性ソース] ドロップダウンから [リソース] を選択します。
  3. [属性] ドロップダウンから [テーブル名] を選択します。
  4. 演算子 ドロップダウンから StringEquals を選択します。
  5. CommonSecurityLog] フィールドに「」と入力します。
  6. [ 式の追加] を選択し、[ And ] を選択して別の式を追加します。
  7. [属性ソース] ドロップダウンから [リソース] を選択します。
  8. [属性] ドロップダウンから [列の値] を選択します。
  9. DeviceVendorにを入力する。
  10. ForAnyOfAnyValues:StringLikeIgnoreCase を 演算子 ドロップダウンから選択します。
  11. [ 値 ] フィールドに「 Check Point と SonicWall」と入力します。
  12. 式 1 と 2 を選択し、> ラジオ ボタンが選択された状態で グループ を選択します。
  13. 保存 を選択します。

完了すると、制限条件がどのように表示されるかを次に示します。

制限条件の式を示すスクリーンショット。

コード形式での制限条件の外観を次に示します。

(
 (
  !(ActionMatches{'Microsoft.OperationalInsights/workspaces/tables/data/read'})
 )
 OR 
(
  (
   @Resource[Microsoft.OperationalInsights/workspaces/tables:name] StringEquals 'CommonSecurityLog'
   AND
   @Resource[Microsoft.OperationalInsights/workspaces/tables/record:DeviceVendor<$key_case_sensitive$>] ForAnyOfAnyValues:StringLikeIgnoreCase {'Check Point', 'SonicWall'}
  )
 )
)

条件を使用してロールを割り当てるプログラムによる方法の詳細については、「 ABAC 条件の追加または編集」を参照してください。

有効なアクセス許可を有効にするには、最大 15 分かかります。

制限の緩い条件を構築する

2 番目のカスタム ロールでは 許可されていないものを除いて、すべてのデータへのアクセス 戦略が使用されます。 このユース ケースでは、階層 1 のセキュリティ アナリスト チームはすべてのテーブルにアクセスする必要がありますが、CEO の UPN またはコンピューター名のレコードにアクセスできないように、 SigninLogs テーブルと DnsEvents テーブルへのアクセスを制限します。

  1. 新しいロールの割り当てを追加し、許容される式を作成します。 Log Analytics ワークスペースから、 アクセス制御 (IAM) を選択します。
  2. [ロールの割り当ての追加] を選択します。
  3. 作成した Log Analytics Security Analysts tier 1 カスタム ロールを選択し、[ 次へ] を選択します。
  4. ロールを割り当てるユーザーまたはグループを選択し、[ 次へ] を選択します。 この例では、階層 1 のアナリスト セキュリティ グループにロールを割り当てます。
  5. 条件の選択>条件の追加>アクションの追加。
  6. [ワークスペース データの読み取り] データ アクションを選択します >[選択]。

式 1

  1. [ビルド式] セクションで、[式の追加] を選択します。
  2. [属性ソース] ドロップダウンから [リソース] を選択します。
  3. [属性] ドロップダウンから [テーブル名] を選択します。
  4. 演算子 ドロップダウンから ForAnyOfAllValues:StringNotEquals を選択します。
  5. SigninLogs] フィールドに「DnsEventsと」と入力します。
  6. 式 1 の後に Or 演算子が選択されていることを確認します。

式 2

  1. [ 式の追加] を選択する
  2. [属性ソース] ドロップダウンから [リソース] を選択します。
  3. [属性] ドロップダウンから [テーブル名] を選択します。
  4. 演算子 ドロップダウンから StringEquals を選択します。
  5. [ 値 ] フィールドに「 SigninLogs」と入力します。

式 3

  1. [ 式の追加] を選択する
  2. [属性ソース] ドロップダウンから [リソース] を選択します。
  3. [属性] ドロップダウンから [列の値] を選択します。
  4. UserPrincipalNameにを入力する。
  5. [演算子] ドロップダウンから StringNotEquals を選択します。
  6. CEO@contoso.com] フィールドに「」と入力します。
  7. 2 と 3 の式を選択し、[>] ラジオボタンが選択された状態で [グループ] を選択します。

式 4

  1. [ 式の追加] を選択する
  2. [属性ソース] ドロップダウンから [リソース] を選択します。
  3. [属性] ドロップダウンから [テーブル名] を選択します。
  4. 演算子 ドロップダウンから StringEquals を選択します。
  5. [ 値 ] フィールドに「 DnsEvents」と入力します。

式 5 - ビジュアル エディターの制限は 5 ですが、コード エディターではさらに式を追加できます。

  1. [ 式の追加] を選択する
  2. [属性ソース] ドロップダウンから [リソース] を選択します。
  3. [属性] ドロップダウンから [列の値] を選択します。
  4. ComputerNameにを入力する。
  5. [演算子] ドロップダウンから StringNotEquals を選択します。
  6. CEOlaptop] フィールドに「」と入力します。
  7. 式 4 と 5> を選択し、And ラジオ ボタンが選択されている状態で グループ を選択します。
  8. 保存 を選択します。

完了時の制限の緩やかな条件は次のとおりです - [式の追加] ボタンが無効になっていることに注意してください。 この動作は、式の最大数に達したことが原因です。

制限の緩い 2 番目の式を示すスクリーンショット。

制限の緩い条件がコード形式でどのように表示されるかを次に示します。

(
 (
  !(ActionMatches{'Microsoft.OperationalInsights/workspaces/tables/data/read'})
 )
 OR 
 (
  @Resource[Microsoft.OperationalInsights/workspaces/tables:name] ForAnyOfAllValues:StringNotEquals {'SigninLogs', 'DnsEvents'}
  OR
  (
   @Resource[Microsoft.OperationalInsights/workspaces/tables:name] StringEquals 'SigninLogs'
   AND
   @Resource[Microsoft.OperationalInsights/workspaces/tables/record:UserPrincipalName<$key_case_sensitive$>] StringNotEquals 'CEO@contoso.com'
  )
  OR
  (
   @Resource[Microsoft.OperationalInsights/workspaces/tables:name] StringEquals 'DnsEvents'
   AND
   @Resource[Microsoft.OperationalInsights/workspaces/tables/record:Computer<$key_case_sensitive$>] StringNotEquals 'CEOlaptop1'
  )
 )
)

有効なアクセス許可を有効にするには、最大 15 分かかります。

トラブルシューティングと監視

一般的な ABAC のトラブルシューティングについては、「 Azure ロールの割り当て条件のトラブルシューティング」を参照してください。

  • ロールの割り当ての変更は、Azure アクティビティ ログに記録されます。

  • LAQueryLogs テーブルは、ユーザー クエリが該当する ABAC 条件で実行されたかどうかを ConditionalDataAccess 列に記録します。 詳細については、 LAQueryLogs テーブル リファレンスを参照してください。

    SigninLogs テーブルに対して構成された条件をトリガーした、階層 1 のセキュリティ アナリストによって実行される監査クエリの例を次に示します。

    監査対象のクエリに適用された条件を示すスクリーンショット。

  • テーブル名と列の値に使用される値では、大文字と小文字が区別されます。 テーブル名または値が正しく指定されていない場合、条件が失敗したり、予期しない動作が発生したり、要求されたデータへのアクセスが拒否されたりする可能性があります。

  • ロジック エラーの原因となる無効な条件により、影響を受けるすべてのユーザーに対して "400 Bad Request" エラー メッセージがトリガーされます。 管理者は条件を変更する必要があります。 たとえば、テーブルに存在しない列を含むワークスペース レベルで条件を設定します。

関連コンテンツ