アクセス制御の概要

適用対象: ✅Microsoft Fabric✅Azure Data Explorer

アクセス制御は、認証と承認に基づいています。 データベースなどの Fabric リソースの各クエリとコマンドは、認証と承認の両方のチェックに合格する必要があります。

• 認証: 要求を行うセキュリティ プリンシパルの ID を検証します
• 承認: 要求を行うセキュリティ プリンシパルがターゲット リソースでその要求を行うことを許可されていることを検証します

認証

プログラムで認証するには、クライアントが Microsoft Entra ID 通信し、Kusto サービスに固有のアクセス トークンを要求する必要があります。 その後、クライアントは、データベースに要求を発行するときに、取得したアクセス トークンを ID の証明として使用できます。

認証の主なシナリオは次のとおりです。

• ユーザー認証: 人間のユーザーの身元を確認するために使用されます。
• アプリケーション認証: 構成された資格情報を使用して、人の介入なしにリソースにアクセスする必要があるアプリケーションの ID を検証するために使用されます。
• On-behalf-of (OBO) 認証: アプリケーションが、Kusto サービスにアクセスするためのトークンを使用して、そのアプリケーションのトークンを交換できるようにします。 このフローは MSAL で実装する必要があります。
• シングル ページ アプリケーション (SPA) 認証: クライアント側の SPA Web アプリケーションがユーザーをサインインさせ、データベースにアクセスするためのトークンを取得できるようにします。 このフローは MSAL で実装する必要があります。

手記

ユーザーとアプリケーションの認証には、Kusto クライアント ライブラリを使用することをお勧めします。 On-behalf-of (OBO) または Single-Page Application (SPA) 認証が必要な場合は、クライアント ライブラリがこれらのフローをサポートしないため、MSAL を直接使用する必要があります。 詳細については、「Microsoft Authentication Library (MSAL)を使用した認証」を参照してください。

ユーザー認証

ユーザー認証は、ユーザーが Microsoft Entra ID または Active Directory フェデレーション サービスなどの Microsoft Entra ID とフェデレーションする ID プロバイダーに資格情報を提示したときに発生します。 ユーザーは、Azure Data Explorer サービスに提示できるセキュリティ トークンを取得します。 Azure Data Explorer では、トークンが有効かどうか、トークンが信頼された発行者によって発行されているかどうか、およびトークンに含まれるセキュリティ要求が決定されます。

アプリケーション認証

アプリケーション認証は、要求が特定のユーザーに関連付けられていない場合、または資格情報を提供できるユーザーがいない場合に必要です。 この場合、アプリケーションはシークレット情報を提示することによって、Microsoft Entra ID またはフェデレーション IdP に対して認証を行います。

認可

リソースに対してアクションを実行する前に、認証されたすべてのユーザーが承認チェックに合格する必要があります。 Kusto ロールベースのアクセス制御 モデルが使用されます。このモデルでは、プリンシパルが 1 つ以上のセキュリティ ロールに登録されます。 承認は、ユーザーに割り当てられたロールの 1 つで、指定されたアクションの実行が許可されている限り付与されます。 たとえば、データベース ユーザー ロールは、特定のデータベースのデータの読み取り、データベース内のテーブルの作成などを行う権限をセキュリティ プリンシパルに付与します。

セキュリティ プリンシパルとセキュリティ ロールの関連付けは、個別に定義することも、Microsoft Entra ID で定義されているセキュリティ グループを使用して定義することもできます。 セキュリティ ロールを割り当てる方法の詳細については、「セキュリティ ロールの概要」を参照してください。

グループの承認

1 つ以上のロールをグループに割り当てることで、Microsoft Entra ID グループに承認を付与できます。

ユーザーまたはアプリケーション プリンシパルの承認を確認する場合、システムは最初に、特定のアクションを許可する明示的なロールの割り当てを探します。 ロールの割り当てが存在しない場合、システムは、アクションを承認できるすべてのグループでプリンシパルのメンバーシップを確認します。

プリンシパルが適切なアクセス許可を持つグループのメンバーである場合、要求されたアクションが承認されます。 それ以外の場合、アクションは承認チェックに合格せず、許可されません。

手記

グループ メンバーシップの確認は、リソースを大量に消費する可能性があります。 グループ メンバーシップは頻繁に変更されないため、メンバーシップ チェックの結果がキャッシュされます。 キャッシュ期間は異なり、グループ メンバーシップの変更が更新される速度が決まります。 グループにユーザーを追加すると、反映されるまでに最大 30 分かかることがあります。 グループからユーザーを削除するには、最大 3 時間かかることがあります。

グループ メンバーシップの更新を強制する

プリンシパルは、グループ メンバーシップ情報の更新を強制できます。 この機能は、Microsoft Entra Privileged Identity Management (PIM) などの Just-In-Time (JIT) 特権アクセス サービスを使用してリソースに対する高い特権を取得するシナリオで役立ちます。

特定のグループの更新

プリンシパルは、特定のグループ のグループ メンバーシップの更新を強制できます。 ただし、次の制限が適用されます。

• 更新は、プリンシパルごとに 1 時間あたり最大 10 回要求できます。
• 要求元プリンシパルは、要求時にグループのメンバーである必要があります。

これらの条件のいずれかが満たされていない場合、要求によってエラーが発生します。

グループの現在のプリンシパルのメンバーシップを再評価するには、次のコマンドを実行します。

.clear cluster cache groupmembership with (group='<GroupFQN>')

グループの完全修飾名 (FQN) を使用します。 詳細については、「Microsoft Entra プリンシパルとグループのの参照」を参照してください。

他のプリンシパルの更新

特権プリンシパルは、他のプリンシパル の更新を要求できます。 要求元プリンシパルには、ターゲット サービス AllDatabaseMonitor アクセス権が必要です。 特権プリンシパルは、制限なしで前のコマンドを実行することもできます。

別のプリンシパルのグループ メンバーシップを更新するには、次のコマンドを実行します。

次のコマンドでは、<PrincipalFQN> を独自のプリンシパル完全修飾名 (FQN) に置き換え、<GroupFQN> を独自のグループ FQN に置き換えます。 詳細については、「Microsoft Entra プリンシパルとグループのの参照」を参照してください。

.clear cluster cache groupmembership with (principal='<PrincipalFQN>', group='<GroupFQN>')

関連コンテンツ

• Kusto のロールベースのアクセス制御 について説明します。
• ユーザーまたはアプリケーションの認証には、Kusto クライアント ライブラリを使用します。
• OBO または SPA 認証については、「Microsoft Authentication Library (MSAL)で認証する方法」を参照してください。
• プリンシパルとグループの参照については、「Microsoft Entra プリンシパルとグループのの参照」を参照してください。