アクセス制御の概要

  • [アーティクル]

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

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

認証

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

メイン認証シナリオは次のとおりです。

  • ユーザー認証: 人間のユーザーの 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に資格情報を提示するか、Microsoft Entra IDとフェデレーションする ID プロバイダー (Active Directory フェデレーション サービス (AD FS) など) を提示したときに行われます。 ユーザーは、Azure Data Explorer サービスに提示できるセキュリティ トークンを取得します。 Azure Data Explorer により、トークンが有効かどうか、トークンが信頼された発行者によって発行されているかどうか、およびトークンに含まれるセキュリティ要求が判別されます。

Azure Data Explorer では、Kusto クライアント ライブラリを使用するなど、次のユーザー認証方法がサポートされています。

  • ユーザー インターフェイスを使用したサインインによる対話型ユーザー認証。
  • Azure Data Explorerに対して発行されたMicrosoft Entra トークンを使用したユーザー認証。
  • On-behalf-of (OBO) 認証を使用して Azure Data Explorer トークンと交換できる別のリソースに対して発行されたMicrosoft Entra トークンを使用したユーザー認証。

アプリケーション認証

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

Azure Data Explorer では、Kusto クライアント ライブラリを使用するなど、次のアプリケーション認証方法がサポートされています。

  • Azure マネージド ID を使用したアプリケーション認証。
  • X.509v2 証明書がローカルにインストールされたアプリケーション認証。
  • クライアント ライブラリにバイト ストリームとして指定された X.509v2 証明書を使用したアプリケーション認証。
  • Microsoft Entra アプリケーション ID とMicrosoft Entra アプリケーション キーを使用したアプリケーション認証。 アプリケーション ID とアプリケーション キーは、ユーザー名とパスワードに似ています。
  • Azure Data Explorerに発行された、以前に取得した有効なMicrosoft Entra トークンを使用したアプリケーション認証。
  • On-behalf-of (OBO) 認証を使用して Azure Data Explorer トークンと交換できる別のリソースに対して発行されたMicrosoft Entra トークンを使用したアプリケーション認証。

承認

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

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

グループの承認

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

ユーザーまたはアプリケーション プリンシパルの承認がチェックされると、システムは最初に特定のアクションを許可する明示的なロールの割り当てを確認します。 このようなロールの割り当てが存在しない場合、システムは、アクションを承認する可能性のあるすべてのグループのプリンシパルのメンバーシップを分析します。 プリンシパルがこれらのグループのいずれかのメンバーであることが確認された場合は、要求されたアクションが承認されます。 それ以外の場合、プリンシパルがそのようなグループのメンバーでない場合、アクションは承認チェックを渡せず、アクションは許可されません。

注意

グループ メンバーシップの確認は、リソースを集中的に消費する可能性があります。 グループ メンバーシップは頻繁に変更されないため、メンバーシップ チェックの結果はキャッシュされます。 キャッシュ期間はさまざまであり、メンバーシップの結果 (プリンシパルがメンバーかどうか)、プリンシパルの種類 (ユーザーまたはアプリケーション) などの要因によって影響を受けます。 最大キャッシュ期間は最大 3 時間まで延長できますが、最小期間は 30 分です。

関連コンテンツ