Udostępnij za pośrednictwem

Ogólne informacje i wytyczne dotyczące zabezpieczeń przedsiębiorstwa w usłudze Azure HDInsight

  • Artykuł

Podczas wdrażania bezpiecznego klastra usługi HDInsight istnieją pewne najlepsze rozwiązania, które powinny ułatwić wdrażanie i zarządzanie klastrem. Poniżej omówiono niektóre ogólne informacje i wytyczne.

Korzystanie z bezpiecznego klastra

  • Klaster będzie używany przez wielu użytkowników w tym samym czasie.
  • Użytkownicy mają różne poziomy dostępu do tych samych danych.

Nie jest to konieczne

  • Uruchamiasz tylko automatyczne zadania (na przykład konto pojedynczego użytkownika), standardowy klaster jest wystarczająco dobry.
  • Importowanie danych można wykonać przy użyciu klastra standardowego i użyć tego samego konta magazynu w innym bezpiecznym klastrze, w którym użytkownicy mogą uruchamiać zadania analizy.

Korzystanie z konta lokalnego

  • Jeśli używasz konta użytkownika udostępnionego lub konta lokalnego, trudno będzie zidentyfikować, kto użył konta do zmiany konfiguracji lub usługi.
  • Korzystanie z kont lokalnych jest problematyczne, gdy użytkownicy nie są już częścią organizacji.

Ranger

Zasady

  • Domyślnie ranger używa opcji Odmów jako zasady.

  • Po uzyskaniu dostępu do danych za pośrednictwem usługi, w której włączono autoryzację:

    • Wtyczka autoryzacji platformy Ranger jest wywoływana i ma kontekst żądania.
    • Ranger stosuje zasady skonfigurowane dla usługi. Jeśli zasady platformy Ranger kończą się niepowodzeniem, sprawdzanie dostępu zostanie odroczone do systemu plików. Niektóre usługi, takie jak MapReduce, sprawdzają tylko, czy plik/folder jest własnością tego samego użytkownika, który przesyła żądanie. Usługi, takie jak Hive, sprawdzają dopasowanie własności lub odpowiednie uprawnienia systemu plików (rwx).

  • W przypadku programu Hive oprócz uprawnień do tworzenia/aktualizowania/usuwania użytkownik powinien mieć rwxuprawnienia do katalogu w magazynie i we wszystkich katalogach podrzędnych.

  • Zasady można stosować do grup (najlepiej) zamiast osób.

  • Autoryzator ranger oceni wszystkie zasady platformy Ranger dla tej usługi dla każdego żądania. Ta ocena może mieć wpływ na czas akceptowania zadania lub zapytania.

Dostęp do magazynu

  • Jeśli typ magazynu to WASB, nie jest zaangażowany żaden token OAuth.
  • Jeśli usługa Ranger wykonała autoryzację, dostęp do magazynu odbywa się przy użyciu tożsamości zarządzanej.
  • Jeśli usługa Ranger nie wykonała żadnej autoryzacji, dostęp do magazynu odbywa się przy użyciu tokenu OAuth użytkownika.

Hierarchiczna przestrzeń nazw

Gdy hierarchiczna przestrzeń nazw nie jest włączona:

  • Nie ma odziedziczonych uprawnień.
  • Tylko uprawnienie systemu plików, które działa, to rola usługi Storage Data XXXX platformy Azure, która ma zostać przypisana do użytkownika bezpośrednio w witrynie Azure Portal.

Domyślne uprawnienia systemu plików HDFS

  • Domyślnie użytkownicy nie mają dostępu do / folderu w systemie plików HDFS (muszą być w roli właściciela obiektu blob magazynu, aby uzyskać dostęp do powodzenia).
  • Dla katalogu przejściowego mapreduce i innych jest tworzony katalog specyficzny dla użytkownika i zapewniane sticky _wx uprawnienia. Użytkownicy mogą tworzyć pliki i foldery pod spodem, ale nie mogą patrzeć na inne elementy.

Uwierzytelnianie adresu URL

Jeśli włączono uwierzytelnianie adresu URL:

  • Konfiguracja będzie zawierać prefiksy omówione w uwierzytelnieniu adresu URL (na przykład adl://).
  • Jeśli dostęp dotyczy tego adresu URL, usługa Ranger sprawdzi, czy użytkownik znajduje się na liście dozwolonych.
  • Ranger nie będzie sprawdzać żadnej szczegółowej zasady.

Zarządzanie dziennikami inspekcji platformy Ranger

Aby zapobiec używaniu zbyt dużej ilości miejsca na dysku w węźle głównym platformy Ranger, można zmienić liczbę dni, aby zachować dzienniki.

  1. Zaloguj się do interfejsu użytkownika systemu Ambari.
  2. Przejdź do pozycji Services>Ranger>Configs>Advanced Advanced>ranger-solr-configuration.
  3. Zmień wartość "Maksymalna liczba dni przechowywania" na 7 dni lub mniej.
  4. Wybierz pozycję Zapisz i uruchom ponownie składniki, których dotyczy zmiana, aby zmiany zaczęły obowiązywać.

Używanie niestandardowej bazy danych Ranger

Zalecamy wdrożenie zewnętrznej bazy danych Ranger do użycia z klastrem ESP w celu zapewnienia wysokiej dostępności metadanych platformy Ranger, co gwarantuje, że zasady są dostępne nawet wtedy, gdy klaster jest niedostępny. Ponieważ zewnętrzna baza danych jest zarządzana przez klienta, możesz również dostroić rozmiar bazy danych i udostępnić bazę danych w wielu klastrach ESP. Zewnętrzną bazę danych ranger można określić podczas procesu tworzenia klastra ESP przy użyciu witryny Azure Portal, usługi Azure Resource Manager, interfejsu wiersza polecenia platformy Azure itp.

Ustawianie synchronizacji użytkownika platformy Ranger w celu codziennego uruchamiania

Klastry USŁUGI HDInsight ESP są konfigurowane dla platformy Ranger do automatycznego synchronizowania użytkowników usługi AD co godzinę. Synchronizacja platformy Ranger jest synchronizacją użytkownika i może spowodować dodatkowe obciążenie wystąpienia usługi AD. Z tego powodu zalecamy zmianę interwału synchronizacji użytkownika platformy Ranger na 24 godziny.

  1. Zaloguj się do interfejsu użytkownika systemu Ambari.
  2. Przejdź do pozycji Services>Ranger Configs>Advanced>ranger-ugsync-site>
  3. Ustaw właściwość ranger.usersync.sleeptimeinmillisbetweensynccycle na 86400000 (24h w milisekundach).
  4. Wybierz pozycję Zapisz i uruchom ponownie składniki, których dotyczy zmiana, aby zmiany zaczęły obowiązywać.

Grupy zasobów

Użyj nowej grupy zasobów dla każdego klastra, aby można było odróżnić zasoby klastra.

Sieciowe grupy zabezpieczeń, zapory i brama wewnętrzna

  • Użyj sieciowych grup zabezpieczeń, aby zablokować sieci wirtualne.
  • Użyj zapory do obsługi zasad dostępu wychodzącego.
  • Użyj bramy wewnętrznej, która nie jest otwarta dla publicznego Internetu.

Microsoft Entra ID

Microsoft Entra ID (Microsoft Entra ID ) to oparta na chmurze usługa zarządzania tożsamościami i dostępem firmy Microsoft.

Zasady

  • Wyłącz zasady dostępu warunkowego przy użyciu zasad opartych na adresach IP. Wymaga to włączenia punktów końcowych usługi w sieciach wirtualnych, w których są wdrażane klastry. Jeśli używasz usługi zewnętrznej dla uwierzytelniania wieloskładnikowego (innego niż Identyfikator entra firmy Microsoft), zasady oparte na adresach IP nie będą działać

  • AllowCloudPasswordValidation zasady są wymagane dla użytkowników federacyjnych. Ponieważ usługa HDInsight używa nazwy użytkownika/hasła bezpośrednio do pobierania tokenów z identyfikatora Entra firmy Microsoft, te zasady muszą być włączone dla wszystkich użytkowników federacyjnych.

  • Włącz punkty końcowe usługi, jeśli potrzebujesz obejścia dostępu warunkowego przy użyciu zaufanych adresów IP.

Grupy

  • Zawsze wdrażaj klastry z grupą.
  • Użyj identyfikatora Entra firmy Microsoft do zarządzania członkostwem w grupach (łatwiejsze niż zarządzanie poszczególnymi usługami w klastrze).

Konta użytkowników

  • Użyj unikatowego konta użytkownika dla każdego scenariusza. Na przykład użyj konta do importowania, użyj innego do wykonywania zapytań lub innych zadań przetwarzania.
  • Użyj zasad ranger opartych na grupach zamiast poszczególnych zasad.
  • Plan zarządzania użytkownikami, którzy nie powinni już mieć dostępu do klastrów.

Usługi domenowe Microsoft Entra

Microsoft Entra Domain Services udostępnia zarządzane usługi domenowe, takie jak przyłączenie do domeny, zasady grupy, uproszczony protokół dostępu do katalogu (LDAP) i uwierzytelnianie Kerberos / NTLM, które jest w pełni zgodne z usługą Active Directory systemu Windows Server.

Usługi Microsoft Entra Domain Services są wymagane, aby bezpieczne klastry przyłączyły się do domeny. Usługa HDInsight nie może zależeć od lokalnych kontrolerów domeny ani niestandardowych kontrolerów domeny, ponieważ wprowadza zbyt wiele punktów błędów, udostępnianie poświadczeń, uprawnienia DNS itd. Aby uzyskać więcej informacji, zobacz Microsoft Entra Domain Services — często zadawane pytania.

Wybieranie prawidłowej jednostki SKU usług Microsoft Entra Domain Services

Podczas tworzenia domeny zarządzanej można wybrać jedną z różnych jednostek SKU, które oferują różne poziomy wydajności i funkcji. Liczba klastrów ESP i innych aplikacji, które będą używać wystąpienia usług Microsoft Entra Domain Services na potrzeby żądań uwierzytelniania, określa, która jednostka SKU jest odpowiednia dla Twojej organizacji. Jeśli zauważysz, że wysokie użycie procesora CPU w domenie zarządzanej lub wymagania biznesowe ulegnie zmianie, możesz uaktualnić jednostkę SKU.

Wystąpienie usługi Microsoft Entra Domain Services

  • Utwórz wystąpienie za pomocą elementu .onmicrosoft.com domain. W ten sposób nie będzie wielu serwerów DNS obsługujących domenę.
  • Utwórz certyfikat z podpisem własnym dla protokołu LDAPS i przekaż go do usług Microsoft Entra Domain Services.
  • Użyj równorzędnej sieci wirtualnej do wdrażania klastrów (jeśli masz wiele zespołów wdrażających klastry USŁUGI HDInsight ESP, będzie to przydatne). Dzięki temu nie trzeba otwierać portów (NSG) w sieci wirtualnej z kontrolerem domeny.
  • Skonfiguruj system DNS dla sieci wirtualnej prawidłowo (nazwa domeny usługi Microsoft Entra Domain Services powinna być rozpoznawana bez żadnych wpisów plików hostów).
  • Jeśli ograniczasz ruch wychodzący, upewnij się, że zapoznasz się z obsługą zapory w usłudze HDInsight

Rozważmy zestawy replik usług Microsoft Entra Domain Services

Podczas tworzenia domeny zarządzanej usług Microsoft Entra Domain Services należy zdefiniować unikatową przestrzeń nazw, a dwa kontrolery domeny (DCs) są następnie wdrażane w wybranym regionie świadczenia usługi Azure. To wdrożenie kontrolerów domeny jest nazywane zestawem replik. Dodanie dodatkowych zestawów replik zapewni odporność i zapewni dostępność usług uwierzytelniania, co ma kluczowe znaczenie dla klastrów usługi Azure HDInsight.

Konfigurowanie synchronizacji użytkowników/grup w zakresie

Po włączeniu usług Microsoft Entra Domain Services dla klastra ESP można wybrać synchronizację wszystkich użytkowników i grup z identyfikatora Entra firmy Microsoft lub grup o określonym zakresie i ich członków. Zalecamy wybranie opcji "Synchronizacja w zakresie" w celu uzyskania najlepszej wydajności.

Synchronizację o określonym zakresie można modyfikować przy użyciu różnych wyborów grup lub w razie potrzeby konwertować na "Wszyscy" użytkowników i grupy. Nie można zmienić typu synchronizacji z "Wszystkie" na "Zakres", chyba że usuniesz i ponownie utworzysz wystąpienie usług Microsoft Entra Domain Services.

Właściwości zsynchronizowane z identyfikatora Entra firmy Microsoft z usługami Microsoft Entra Domain Services

  • Program Microsoft Entra Connect synchronizuje się ze środowiska lokalnego z identyfikatorem Entra firmy Microsoft.
  • Usługa Microsoft Entra Domain Services synchronizuje się z identyfikatorem Entra firmy Microsoft.

Usługa Microsoft Entra Domain Services okresowo synchronizuje obiekty z identyfikatora Entra firmy Microsoft. Blok Microsoft Entra Domain Services w witrynie Azure Portal wyświetla stan synchronizacji. Podczas każdego etapu synchronizacji unikatowe właściwości mogą powodować konflikt i zmieniać ich nazwy. Zwróć uwagę na mapowanie właściwości z identyfikatora Entra firmy Microsoft do usług Microsoft Entra Domain Services.

Aby uzyskać więcej informacji, zobacz Microsoft Entra UserPrincipalName population i How Microsoft Entra Domain Services synchronization works (Jak działa synchronizacja usług Microsoft Entra Domain Services).

Synchronizacja skrótów haseł

  • Hasła są synchronizowane inaczej niż inne typy obiektów. Tylko skróty haseł nieodwołalnych są synchronizowane w usługach Microsoft Entra ID i Microsoft Entra Domain Services
  • Lokalne z identyfikatorem Entra firmy Microsoft musi być włączone za pośrednictwem programu AD Connect
  • Synchronizacja usługi Microsoft Entra ID z usługą Microsoft Entra Domain Services jest automatyczna (opóźnienia są poniżej 20 minut).
  • Skróty haseł są synchronizowane tylko wtedy, gdy istnieje zmienione hasło. Po włączeniu synchronizacji skrótów haseł wszystkie istniejące hasła nie są synchronizowane automatycznie, ponieważ są one przechowywane nieodwracalnie. Po zmianie hasła skróty haseł są synchronizowane.

Ustawianie synchronizacji LDAP systemu Ambari do uruchamiania codziennie

Proces synchronizowania nowych użytkowników LDAP z systemem Ambari jest automatycznie konfigurowany do uruchamiania co godzinę. Uruchomienie tej funkcji co godzinę może spowodować nadmiarowe obciążenie węzłów głównych klastra i wystąpienia usługi AD. W celu zwiększenia wydajności zalecamy zmianę skryptu /opt/startup_scripts/start_ambari_ldap_sync.py, który uruchamia synchronizację LDAP systemu Ambari, aby był uruchamiany raz dziennie. Ten skrypt jest uruchamiany przez zadanie crontab i jest przechowywany w katalogu "/etc/cron.hourly/" w węzłach głównych klastra.

Aby uruchamiać je raz dziennie, wykonaj następujące kroki:

  1. Nawiąż połączenie ssh z węzłem głównym 0 (hn0)
  2. Przenieś skrypt do folderu codziennego cron: sudo mv /etc/cron.hourly/ambarildapsync /etc/cron.daily/ambarildapsync
  3. Zastosuj zmianę w zadaniu crontab: sudo service cron reload
  4. ssh do hn1 i powtórz kroki od 1 do 3

W razie potrzeby możesz użyć interfejsu API REST systemu Ambari, aby ręcznie zsynchronizować nowych użytkowników i grupy natychmiast.

Lokalizacja obiektów komputera

Każdy klaster jest skojarzony z jedną jednostką organizacyjną. Użytkownik wewnętrzny jest aprowizowany w jednostki organizacyjnej. Wszystkie węzły są przyłączone do tej samej jednostki organizacyjnej.

Narzędzia administracyjne usługi Active Directory

Aby uzyskać więcej informacji, zobacz Instalowanie narzędzi do zarządzania.

Rozwiązywanie problemów

Tworzenie klastra wielokrotnie kończy się niepowodzeniem

Najczęstsze przyczyny:

  • Konfiguracja DNS nie jest poprawna, dołączanie do domeny węzłów klastra kończy się niepowodzeniem.
  • Sieciowe grupy zabezpieczeń są zbyt restrykcyjne, co uniemożliwia przyłączenie do domeny.
  • Tożsamość zarządzana nie ma wystarczających uprawnień.
  • Nazwa klastra nie jest unikatowa w pierwszych sześciu znakach (z innym klastrem na żywo lub z usuniętym klastrem).

Konfiguracja i konfiguracja uwierzytelniania

Główna nazwa użytkownika (UPN)

  • Użyj małych liter dla wszystkich usług — nazwy UPN nie są uwzględniane w przypadku klastrów ESP, ale
  • Prefiks nazwy UPN powinien być zgodny z nazwą SAMAccountName w usługach Microsoft Entra Domain Services. Dopasowanie z polem poczty nie jest wymagane.

Właściwości LDAP w konfiguracji narzędzia Ambari

Aby uzyskać pełną listę właściwości systemu Ambari, które mają wpływ na konfigurację klastra usługi HDInsight, zobacz Ambari LDAP Authentication Setup (Konfiguracja uwierzytelniania LDAP systemu Ambari).

Generowanie kart klucza użytkownika domeny

Wszystkie tabki kluczy usługi są generowane automatycznie podczas procesu tworzenia klastra ESP. Aby włączyć bezpieczną komunikację między klastrem a innymi usługami i/lub zadaniami wymagającymi uwierzytelniania, możesz wygenerować kartę klucza dla nazwy użytkownika domeny.

Użyj narzędzia ktutil na jednej z maszyn wirtualnych klastra, aby utworzyć kartę klucza Protokołu Kerberos:


ktutil
ktutil: addent -password -p <username>@<DOMAIN.COM> -k 1 -e aes256-cts-hmac-sha1-96
Password for <username>@<DOMAIN.COM>: <password>
ktutil: wkt <username>.keytab
ktutil: q

Jeśli nazwa_dzierżawy i nazwa_domeny są inne, musisz dodać wartość SALT przy użyciu opcji -s. Sprawdź stronę często zadawanych pytań dotyczących usługi HDInsight, aby określić właściwą wartość SALT podczas tworzenia karty klucza Kerberos.

Odnawianie certyfikatu LDAP

Usługa HDInsight automatycznie odnowi certyfikaty dla tożsamości zarządzanych używanych w klastrach za pomocą pakietu Enterprise Security (ESP). Istnieje jednak ograniczenie, gdy różne tożsamości zarządzane są używane dla usług Microsoft Entra Domain Services i ADLS Gen2, które mogą spowodować niepowodzenie procesu odnawiania. Postępuj zgodnie z poniższymi 2 zaleceniami, aby upewnić się, że możemy pomyślnie odnowić certyfikaty:

  • Jeśli używasz różnych tożsamości zarządzanych dla klastrów usług ADLS Gen2 i Microsoft Entra Domain Services, oba te klastry powinny mieć przypisane role Właściciel danych obiektu blob usługi Storage i Współautor usług DOMENOWYCH HDInsight.
  • Klastry usługi HDInsight wymagają publicznych adresów IP na potrzeby aktualizacji certyfikatów i innej konserwacji, więc wszelkie zasady odmawiające publicznego adresu IP w klastrze powinny zostać usunięte.

Następne kroki