Uwierzytelnianie na potrzeby analizy w skali chmury na platformie Azure

Uwierzytelnianie to proces weryfikowania tożsamości użytkownika lub aplikacji. Preferowany jest jeden źródłowy dostawca tożsamości, który obsługuje zarządzanie tożsamościami i uwierzytelnianie. Ten dostawca jest znany jako usługa katalogowa. Udostępnia metody przechowywania danych katalogu i udostępniania tych danych użytkownikom sieci i administratorom.

Każde rozwiązanie data lake powinno używać i integrować się z usługą katalogową, która jest już używana. W przypadku większości organizacji usługa Active Directory jest usługą katalogową dla wszystkich usług związanych z tożsamościami. Jest to podstawowa i scentralizowana baza danych dla wszystkich kont usług i użytkowników.

W chmurze identyfikator Entra firmy Microsoft jest scentralizowanym dostawcą tożsamości i preferowanym źródłem zarządzania tożsamościami. Delegowanie uwierzytelniania i autoryzacji do identyfikatora Entra firmy Microsoft umożliwia scenariusze, takie jak zasady dostępu warunkowego, które wymagają od użytkownika bycia w określonej lokalizacji. Obsługuje uwierzytelnianie wieloskładnikowe w celu zwiększenia poziomu zabezpieczeń dostępu. Skonfiguruj usługi data lake data store przy użyciu integracji firmy Microsoft Entra, jeśli jest to możliwe.

W przypadku usług danych, które nie obsługują identyfikatora Entra firmy Microsoft, użyj klucza dostępu lub tokenu do uwierzytelniania. Klient powinien przechowywać klucz dostępu w magazynie zarządzania kluczami, takim jak usługa Azure Key Vault.

Scenariusze uwierzytelniania dla analizy w skali chmury to:

  • Uwierzytelnianie użytkownika
  • Uwierzytelnianie aplikacji i usługi do usługi

Uwierzytelnianie użytkownika

Użytkownicy, którzy łączą się z usługą danych lub zasobem, muszą przedstawić poświadczenia. To poświadczenie potwierdza, że użytkownicy są tym, którzy twierdzą. Następnie mogą uzyskać dostęp do usługi lub zasobu. Uwierzytelnianie umożliwia również usłudze poznanie tożsamości użytkowników. Usługa decyduje, co użytkownik może zobaczyć i zrobić po zweryfikowaniu tożsamości.

Usługa Azure Data Lake Storage Gen2, Azure SQL Database i Azure Synapse obsługują integrację z firmą Microsoft Entra. Tryb uwierzytelniania interakcyjnego użytkownika wymaga od użytkowników podania poświadczeń w oknie dialogowym.

Ważne

Nie umieszczaj twardych poświadczeń użytkownika w aplikacji w celu uwierzytelniania.

Uwierzytelnianie aplikacji i usługi do usługi

Te żądania nie są skojarzone z określonym użytkownikiem lub nie ma żadnego użytkownika dostępnego do wprowadzenia poświadczeń.

Uwierzytelnianie między usługami

Nawet jeśli usługa uzyskuje dostęp do innej usługi bez interakcji człowieka, usługa musi przedstawić prawidłową tożsamość. Ta tożsamość potwierdza, że usługa jest prawdziwa. Dostępna usługa może użyć tożsamości, aby zdecydować, co może zrobić usługa.

W przypadku uwierzytelniania między usługami preferowana metoda uwierzytelniania usług platformy Azure to tożsamości zarządzane. Tożsamości zarządzane dla zasobów platformy Azure umożliwiają uwierzytelnianie w dowolnej usłudze obsługującej uwierzytelnianie firmy Microsoft Entra bez żadnych jawnych poświadczeń. Aby uzyskać więcej informacji, zobacz Co to są tożsamości zarządzane dla zasobów platformy Azure.

Tożsamości zarządzane to jednostki usługi, których można używać tylko z zasobami platformy Azure. Na przykład tożsamość zarządzana można utworzyć bezpośrednio dla wystąpienia usługi Azure Data Factory. Ta tożsamość zarządzana jest obiektem zarejestrowanym w usłudze Microsoft Entra ID. Reprezentuje to wystąpienie usługi Data Factory. Ta tożsamość może następnie służyć do uwierzytelniania w dowolnej usłudze, takiej jak Data Lake Storage, bez żadnych poświadczeń w kodzie. Platforma Azure zajmuje się poświadczeniami używanymi przez wystąpienie usługi. Tożsamość może udzielić autoryzacji do zasobów usługi platformy Azure, takich jak folder w usłudze Azure Data Lake Storage. Po usunięciu tego wystąpienia usługi Data Factory platforma Azure czyści tożsamość w identyfikatorze Entra firmy Microsoft.

Zalety korzystania z tożsamości zarządzanych

Tożsamości zarządzane powinny służyć do uwierzytelniania usługi platformy Azure w innej usłudze lub zasobie platformy Azure. Zapewniają one następujące korzyści:

  • Tożsamość zarządzana reprezentuje usługę, dla której została utworzona. Nie reprezentuje użytkownika interakcyjnego.
  • Poświadczenia tożsamości zarządzanej są przechowywane, zarządzane i przechowywane w identyfikatorze Entra firmy Microsoft. Nie ma hasła do przechowywania przez użytkownika.
  • W przypadku tożsamości zarządzanych usługi klienckie nie używają haseł.
  • Tożsamość zarządzana przypisana przez system jest usuwana po usunięciu wystąpienia usługi.

Te korzyści oznaczają, że poświadczenie jest lepiej chronione, a naruszenie zabezpieczeń jest mniej prawdopodobne.

Uwierzytelnianie aplikacji do usługi

Innym scenariuszem dostępu jest aplikacja, taka jak mobilna aplikacja internetowa, która uzyskuje dostęp do usługi platformy Azure. KtoTo zależności od tego, czy uzyskujesz dostęp do usługi platformy Azure, akcesorium musi podać swoją tożsamość i że tożsamość musi zostać zweryfikowana.

Jednostka usługi platformy Azure jest alternatywą dla aplikacji i usług, które nie obsługują tożsamości zarządzanych do uwierzytelniania w zasobach platformy Azure. Jednostka usługi platformy Azure to tożsamość przeznaczona do użycia z aplikacjami, usługami hostowanymi i zautomatyzowanymi narzędziami w celu uzyskiwania dostępu do zasobów platformy Azure. Ten dostęp jest ograniczony przez role przypisane do jednostki usługi. Ze względów bezpieczeństwa zalecamy używanie jednostek usługi z zautomatyzowanymi narzędziami lub aplikacjami, zamiast zezwalać im na logowanie się przy użyciu tożsamości użytkownika. Aby uzyskać więcej informacji, zobacz Application and service principal objects in Microsoft Entra ID (Obiekty aplikacji i jednostki usługi w usłudze Microsoft Entra ID).

Uwaga

Zarówno tożsamości zarządzane, jak i jednostki usługi są tworzone i obsługiwane tylko w identyfikatorze Entra firmy Microsoft.

Różnica między tożsamością zarządzaną a jednostką usługi

Jednostka usługi Tożsamość zarządzana
Tożsamość zabezpieczeń utworzona ręcznie w identyfikatorze Entra firmy Microsoft do użycia przez aplikacje, usługi i narzędzia w celu uzyskania dostępu do określonych zasobów platformy Azure. Specjalny typ jednostki usługi. Jest to automatyczna tożsamość tworzona podczas tworzenia usługi platformy Azure.
Może być używany przez dowolną aplikację lub usługę. Nie jest ona powiązana z określoną usługą platformy Azure. Reprezentuje samo wystąpienie usługi platformy Azure. Nie można jej użyć do reprezentowania innych usług platformy Azure.
Ma niezależny cykl życia. Należy je jawnie usunąć. Jest usuwany automatycznie po usunięciu wystąpienia usługi platformy Azure.
Uwierzytelnianie oparte na hasłach lub oparte na certyfikatach. Nie podano jawnego hasła do uwierzytelniania.

Uwierzytelnianie i uprawnienia bazy danych

Analiza w skali chmury prawdopodobnie zawiera magazyn wielolotowy. Przykłady to PostgreSQL, MySQL, Azure SQL Database, SQL Managed Instance i Azure Synapse Analytics.

Zalecamy używanie grup entra firmy Microsoft do zabezpieczania obiektów bazy danych zamiast pojedynczych kont użytkowników firmy Microsoft Entra. Użyj tych grup firmy Microsoft Entra, aby uwierzytelnić użytkowników i chronić obiekty bazy danych. Podobnie jak w przypadku wzorca usługi Data Lake, możesz użyć dołączania aplikacji danych, aby utworzyć te grupy.

Uwaga

Aplikacje danych mogą przechowywać poufne produkty danych w pulach usługi Azure SQL Database, SQL Managed Instance lub Azure Synapse Analytics. Aby uzyskać więcej informacji, zobacz Poufne dane.

Zabezpieczenia usługi Azure Data Lake w analizie w skali chmury

Aby kontrolować dostęp do danych w usłudze Data Lake, zalecamy używanie listy kontroli dostępu (ACL) na poziomie plików i folderów. Usługa Azure Data Lake przyjmuje również model listy kontroli dostępu przypominający model POSIX. POSIX (przenośny interfejs systemu operacyjnego) to rodzina standardów dla systemów operacyjnych. Jeden standard definiuje prostą, ale zaawansowaną strukturę uprawnień na potrzeby uzyskiwania dostępu do plików i folderów. System POSIX został powszechnie przyjęty dla sieciowych udziałów plików i komputerów z systemem Unix.

Podobnie jak w przypadku ogólnych praktyk kontroli dostępu opartej na rolach platformy Azure, następujące reguły powinny mieć zastosowanie do listy ACL:

  • Zarządzanie dostępem przy użyciu grup. Przypisz dostęp do grup firmy Microsoft Entra i zarządzaj członkostwem grup w celu ciągłego zarządzania dostępem. Zobacz Artykuł Kontrola dostępu i konfiguracje usługi Data Lake Storage w usłudze Azure Data Lake Storage.

  • Stosowanie najniższych uprawnień. W większości przypadków użytkownicy powinni mieć uprawnienia tylko do odczytu do folderów i plików, których potrzebują w usłudze Data Lake. Tożsamość zarządzana lub jednostka usługi, taka jak ta używana przez usługę Azure Data Factory, ma uprawnienia do odczytu, zapisu i wykonywania. Użytkownicy danych nie powinni mieć dostępu do kontenera konta magazynu.

  • Dopasowanie do schematu partycjonowania danych. Lista ACL i projekt partycji danych muszą być dostosowane, aby zapewnić skuteczną kontrolę dostępu do danych. Aby uzyskać więcej informacji, zobacz [Partycjonowanie usługi Data Lake].

Następne kroki

Zarządzanie danymi i kontrola dostępu oparta na rolach na potrzeby analizy w skali chmury na platformie Azure