Omówienie kontroli dostępu

Usługa Azure Data Explorer kontrola dostępu jest oparta na uwierzytelnianiu i autoryzacji. Każde zapytanie i polecenie w zasobie usługi Azure Data Explorer, takim jak klaster lub baza danych, musi przejść testy uwierzytelniania i autoryzacji.

• Uwierzytelnianie: Weryfikowanie tożsamości podmiotu zabezpieczeń wysyłającego żądanie
• Autoryzacja: Weryfikuje podmiot zabezpieczeń wysyłający żądanie może wysłać to żądanie do zasobu docelowego

Authentication

Aby programowo uwierzytelnić się w klastrze, klient musi komunikować się z Tożsamość Microsoft Entra i zażądać tokenu dostępu specyficznego dla usługi Azure Data Explorer. Następnie klient może użyć uzyskanego tokenu dostępu jako dowodu tożsamości podczas wydawania żądań do klastra.

Główne scenariusze uwierzytelniania są następujące:

• Uwierzytelnianie użytkowników: służy do weryfikowania tożsamości użytkowników.
• Uwierzytelnianie aplikacji: służy do weryfikowania tożsamości aplikacji, która musi uzyskiwać dostęp do zasobów bez interwencji człowieka przy użyciu skonfigurowanych poświadczeń.
• Uwierzytelnianie w imieniu (OBO): umożliwia aplikacji wymianę tokenu dla danej aplikacji przy użyciu tokenu w celu uzyskania dostępu do usługi Kusto. Ten przepływ należy zaimplementować za pomocą biblioteki MSAL.
• Uwierzytelnianie aplikacji jednostronicowej (SPA): umożliwia aplikacjom internetowym SPA po stronie klienta logowanie użytkowników i uzyskiwanie tokenów dostępu do klastra. Ten przepływ należy zaimplementować za pomocą biblioteki MSAL.

Uwaga

W przypadku uwierzytelniania użytkowników i aplikacji zalecamy używanie bibliotek klienckich usługi Kusto. Jeśli wymagane jest uwierzytelnianie on-behalf-of (OBO) lub Single-Page Application (SPA), należy użyć biblioteki MSAL bezpośrednio, ponieważ te przepływy nie są obsługiwane przez biblioteki klienckie. Aby uzyskać więcej informacji, zobacz Uwierzytelnianie za pomocą biblioteki Microsoft Authentication Library (MSAL).

Uwierzytelnianie użytkowników

Uwierzytelnianie użytkownika odbywa się, gdy użytkownik przedstawia poświadczenia Tożsamość Microsoft Entra lub dostawcy tożsamości, który sfederuje się z Tożsamość Microsoft Entra, takimi jak Active Directory Federation Services. Użytkownik otrzymuje token zabezpieczający, który można przedstawić usłudze Azure Data Explorer. Usługa Azure Data Explorer określa, czy token jest prawidłowy, czy token jest wystawiany przez zaufanego wystawcę oraz jakie oświadczenia zabezpieczeń zawiera token.

Usługa Azure Data Explorer obsługuje następujące metody uwierzytelniania użytkowników, w tym za pośrednictwem bibliotek klienckich usługi Kusto:

• Interaktywne uwierzytelnianie użytkownika przy użyciu logowania za pośrednictwem interfejsu użytkownika.
• Uwierzytelnianie użytkowników przy użyciu tokenu Microsoft Entra wystawionego dla usługi Azure Data Explorer.
• Uwierzytelnianie użytkownika przy użyciu tokenu Microsoft Entra wystawionego dla innego zasobu, który można wymienić na token usługi Azure Data Explorer przy użyciu uwierzytelniania on-behalf-of (OBO).

Uwierzytelnianie aplikacji

Uwierzytelnianie aplikacji jest wymagane, gdy żądania nie są skojarzone z określonym użytkownikiem lub gdy żaden użytkownik nie jest dostępny do podania poświadczeń. W takim przypadku aplikacja uwierzytelnia się w Tożsamość Microsoft Entra lub federacyjnym dostawcy tożsamości przez przedstawienie informacji tajnych.

Usługa Azure Data Explorer obsługuje następujące metody uwierzytelniania aplikacji, w tym za pośrednictwem bibliotek klienckich usługi Kusto:

• Uwierzytelnianie aplikacji przy użyciu tożsamości zarządzanej platformy Azure.
• Uwierzytelnianie aplikacji z zainstalowanym lokalnie certyfikatem X.509v2.
• Uwierzytelnianie aplikacji przy użyciu certyfikatu X.509v2 przekazanego bibliotece klienta jako strumień bajtów.
• Uwierzytelnianie aplikacji przy użyciu identyfikatora aplikacji Microsoft Entra i klucza aplikacji Microsoft Entra. Identyfikator aplikacji i klucz aplikacji są podobne do nazwy użytkownika i hasła.
• Uwierzytelnianie aplikacji przy użyciu wcześniej uzyskanego prawidłowego tokenu Microsoft Entra wystawionego dla usługi Azure Data Explorer.
• Uwierzytelnianie aplikacji przy użyciu tokenu Microsoft Entra wystawionego dla innego zasobu, który można wymienić na token usługi Azure Data Explorer przy użyciu uwierzytelniania on-behalf-of (OBO).

Autoryzacja

Przed wykonaniem akcji w zasobie usługi Azure Data Explorer wszyscy uwierzytelnieni użytkownicy muszą przejść kontrolę autoryzacji. Usługa Azure Data Explorer używa modelu kontroli dostępu opartej na rolach Kusto, w którym podmioty zabezpieczeń są przypisywane do co najmniej jednej roli zabezpieczeń. Autoryzacja jest udzielana tak długo, jak jedna z ról przypisanych do użytkownika umożliwia im wykonanie określonej akcji. Na przykład rola Użytkownik bazy danych przyznaje podmiotom zabezpieczeń prawo do odczytywania danych określonej bazy danych, tworzenia tabel w bazie danych i nie tylko.

Skojarzenie podmiotów zabezpieczeń z rolami zabezpieczeń można zdefiniować indywidualnie lub przy użyciu grup zabezpieczeń zdefiniowanych w Tożsamość Microsoft Entra. Aby uzyskać więcej informacji na temat przypisywania ról zabezpieczeń, zobacz Omówienie ról zabezpieczeń.

Autoryzacja grupy

Autoryzację można udzielić Tożsamość Microsoft Entra grupom, przypisując do grupy co najmniej jedną rolę.

Po sprawdzeniu autoryzacji użytkownika lub podmiotu zabezpieczeń aplikacji system najpierw sprawdza jawne przypisanie roli zezwalające na określoną akcję. Jeśli takie przypisanie roli nie istnieje, system analizuje członkostwo podmiotu zabezpieczeń we wszystkich grupach, które mogłyby potencjalnie autoryzować akcję. Jeśli podmiot zabezpieczeń jest potwierdzony jako członek dowolnej z tych grup, żądana akcja jest autoryzowana. W przeciwnym razie, jeśli podmiot zabezpieczeń nie jest członkiem żadnych takich grup, akcja nie przejdzie kontroli autoryzacji i akcja nie jest dozwolona.

Uwaga

Sprawdzanie członkostwa w grupach może być intensywnie korzystające z zasobów. Ponieważ członkostwo w grupach nie zmienia się często, wyniki testów członkostwa są buforowane. Czas trwania buforowania różni się i ma wpływ na czynniki, takie jak wynik członkostwa (bez względu na to, czy podmiot zabezpieczeń jest członkiem, czy nie), typ podmiotu zabezpieczeń (użytkownik lub aplikacja), między innymi. Maksymalny czas trwania buforowania może wydłużyć się do trzech godzin, a minimalny czas trwania wynosi 30 minut.

Zawartość pokrewna

• Omówienie kontroli dostępu opartej na rolach w usłudze Kusto.
• W przypadku uwierzytelniania użytkowników lub aplikacji użyj bibliotek klienckich usługi Kusto.
• Aby uzyskać informacje na temat uwierzytelniania OBO lub SPA, zobacz Jak uwierzytelniać się za pomocą biblioteki Microsoft Authentication Library (MSAL).