Azure Log Analytics ワークスペースや Microsoft Sentinel で、ログデータに対して細かくアクセス制御したい

データアクセス制御が強化されました

先日、Azure Monitor Log Analytics 向けのきめ細かいロールベースのアクセス制御 (Granular RBAC) のパブリックプレビューが発表されました。この機能により、組織は Log Analytics ワークスペース内のログデータに対して、行レベルでのアクセス制御が可能になります。

なにが問題だったのか

これまでは、管理者がアクセス制御を管理できるのはワークスペースかテーブル レベルに限られていました。そのため、複数の部門やチームで 1 つの Log Analytics ワークスペースを使用するケースでは、より細かな制御が行えない限り、特定データへのアクセス制限や最小権限の原則の徹底、さらにはデータガバナンスやプライバシーの要件を満たすことが難しい状況でした。

Azure Monitor ログでのきめ細かい RBAC (Granular RBAC) とは

Azure Monitor Log Analytics では、これまでのワークスペースおよびテーブル レベルでのアクセス制御に加え、Azure ロール割り当ての一環として Azure 属性ベースのアクセス制御 (ABAC) を利用することにより、すべてのデータを 1 つの Log Analytics ワークスペースで集中管理しつつ、任意の粒度で最小限の権限に基づくアクセスを実現できるようになりました。

この機能により、あらかじめ設定した条件に基づいて、ユーザーごとに表示やクエリ可能なデータを制限することが可能になります。つまり、ビジネス要件やセキュリティポリシーに応じて、各ユーザーがアクセスできるテーブルや行を柔軟に制御できるようになったということです。

Azure Monitor ログでのきめ細かい RBAC を構成する手順

Azure Monitor Log Analytics でのきめ細かい RBAC を構成するには、以下の手順で行います。

1. 必要なアクションが含まれるカスタムロールを作成する
2. 対象のリソースにカスタムロールを適用する
3. ユーザーまたはグループにカスタムロールを割り当てる
4. ユーザーまたはグループにカスタムロールを割り当てる際に、アクセス制御を調整する条件を構成する

3 番目までは通常のロールの割り当てと同じですが、きめ細かい RBAC を構成するには 4 番目の作業も必要となります。
また、アクセス制御を計画・設計する際は、次の 2 つの方法に基づいて行うと良いでしょう。

方法	条件に 合致する ログデータ	条件に 合致しない ログデータ	別名 (わかりやすく)
アクセス許可する条件で構成する	アクセス可	アクセス不可	ホワイトリスト
アクセス許可しない条件で構成する	アクセス不可	アクセス可	ブラックリスト

なお、次からの実践では「ホワイトリスト」でアクセス制御を構成します。

使ってみた

この記事では、次のシナリオで実践してみます。

シナリオ
テスト太郎さんが参照できるログデータは、以下の自部署のメンバーのログデータのみとし、これら以外のログデータにはアクセスさせない。

テーブル	条件 (アクセス許可)
IdentityInfo	Department 列の値が "DX推進部" で始まるレコード
SigninLogs	UserPrincipalName 列の値が自部署のメンバーの UPN と一致するレコード

カスタムロールを作成

まず、Log Analytics ワークスペース リソースが属するリソース グループ、またはサブスクリプションで、次のアクションとデータアクション (ログデータを参照するのに必要な最小限のアクセス許可) を含むカスタムロールを作成します。

タイプ	アクション	説明
Actions	Microsoft.OperationalInsights/workspaces/read (Get Workspace)	ワークスペースが読み取れる ※Log Analytics ワークスペース リソースへのアクセスを許可
Actions	Microsoft.OperationalInsights/workspaces/query/read (Query Data in Workspace)	ワークスペース内のデータに対してクエリを実行できる ※ただし、このアクションだけではデータへのアクセスは許可されていない
Data Actions	Microsoft.OperationalInsights/workspaces/tables/data/read (Read workspace data)	データが読み取れる ※割り当てられたスコープ内のすべてのデータへのアクセスを許可

ここでは、カスタムロールの名前を「ログ閲覧者ミニマム」とします。

ロールの割り当てを追加

対象リソースにロールの割り当てを追加します。

ロールを選択

先ほど作成した「ログ閲覧者ミニマム」ロールを選びます。

ロールの割り当て条件を設定

Azure ABAC に対応したロールでは [条件] タブが活性され、アクセス制限の条件を設定することができます。[条件を追加する] をクリックして、アクセス制限の条件を設定します。

アクションを選択

先ほど選択したロールに含まれるアクションのうち、アクセス条件を設定したいものを選択します。今回は、データアクションの「Read workspace data」を選択します。

条件式を作成

ここから条件式をいくつか追加していきますが、個々の式を追加する際は [式の追加] をクリックします。

次から、シナリオに沿ってアクセス制限の条件を設定していきます。

• IdentityInfo テーブルに対するアクセス制限の条件を設定

IdentityInfo テーブルに対して、次のようなアクセス制限を施します。

テーブル	条件 (アクセス許可)
IdentityInfo	Department 列の値が "DX推進部" で始まるレコード

まず、1 つ目の式を追加し、テーブルを指定する条件式を以下のように作成します。

項目	設定値
属性リソース	「リソース」を選択
属性	「テーブル名」を選択
演算子	「StringEquals」を選択 ※[属性 (テーブル名)] が [値] と等しい
値	「IdentityInfo」を入力

次に、2 つ目の式を追加し、1 つ目の条件式とは「AND」でつなぎます。ここでは、行レベルでアクセス許可する条件式を以下のように作成します。

項目	設定値
属性ソース	「リソース」を選択
属性	「列の値 (キーは列名)」を選択
キー	「Department」を入力
演算子	「StringStartsWith」を選択 ※[キー (列)] が [値] から始まる
値	「DX推進部」を入力

そしてに、1 つ目と 2 つ目の条件式を選択して「グループ化」します (「グループ #1」となる)。

• SigninLogs テーブルに対するアクセス制限の条件を設定

SigninLogs テーブルに対して、次のようなアクセス制限を施します。

テーブル	条件 (アクセス許可)
SigninLogs	UserPrincipalName 列の値が自部署のメンバーの UPN と一致するレコード

先ほどのつづきで、3 つ目の式を追加し、「グループ #1」とは「OR」でつなぎます。ここでは、テーブルを指定する条件式を以下のように作成します。

項目	設定値
属性ソース	「リソース」を選択
属性	「テーブル名」を選択
演算子	「StringEquals」を選択 ※[属性 (テーブル名)] が [値] と等しい
値	「SigninLogs」を入力

次に、4 つ目の式を追加し、3 つ目の条件式とは「AND」でつなぎます。ここでは、行レベルでアクセス許可する条件式を以下のように作成します。

項目	設定値
属性ソース	「リソース」を選択
属性	「列の値 (キーは列名)」を選択
キー	「UserPrincipalName」を入力
演算子	「ForAllOfAnyValues:StringEquals」を選択 ※[キー (列)] が [値] のいずれかと等しい
値	「メンバーの UPN (複数個)」を入力

そしてに、3 つ目と 4 つ目の条件式を選択して「グループ化」します (「グループ #2」となる)。

• グループ #1: IdentityInfo テーブルに対するアクセス制限
• グループ #2: SigninLogs テーブルに対するアクセス制限

以上のように構成することで、アクセスできるテーブルや行を柔軟に制御できます。¹

動作確認

テスト太郎さんのアカウントで、各ログデータを参照してみます。

• IdentityInfo テーブルを参照

IdentityInfo テーブルを参照する KQL クエリを実行すると、下図のように Department 列が "DX推進部" から始まるログデータしか表示されていないことが確認できました。

• SigninLogs テーブルを参照

SigninLogs テーブルを参照する KQL クエリを実行すると、下図のように UserPrincipalName 列が条件式で指定した UPN しか表示されていないことが確認できました。

• 上記以外のテーブルを参照

アクセス制限を施したテーブル以外のテーブルにアクセスする場合はどうなるでしょうか？想定では、何もヒット (表示) されないはずです。ここでは、EmailEvents を参照してみましょう。

筆者 (「所有者」ロールが割り当たっている) の場合はたくさんヒットするので、多くのログが格納されていることが分かります。

いっぽう、テスト太郎さんの場合では、下図のようにエラーとならず 1 件もヒットしませんでした。(正常終了)

これで、シナリオどおりにアクセス制限されたことが確認できました。

まとめ

この新機能により、Azure Monitor Log Analytics では、次のレベルでアクセス制御を行えるようになりました。また、この機能では、テーブルと行レベルでアクセス制御を施すことができます。

• ワークスペース
• テーブル レベル
• 行 レベル

これで、複数の部門やチームで 1 つの Log Analytics ワークスペースを共有しても、あらかじめ設定した条件に基づいて、ユーザーまたはグループごとに特定データへのアクセス制御ができるようになります。

最後までお読みいただき、ありがとうございます。この情報がみなさまのお仕事に少しでも役立てばうれしいです。

1. ロールの割り当てが反映されるまでに最大 15 分かかります。※通常のものと同様 ↩