Udostępnij przez

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

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.

Strażnik

Zasady

  • Domyślnie Ranger używa Odmów jako polityki.

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

    • Wtyczka autoryzująca Ranger jest wywoływana w kontekście żą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ą zgodność 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 Ranger dotyczące 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 Ranger wykonał 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 do systemu plików, które działa, to rola Storage Data XXXX platformy Azure, która ma zostać przypisana do użytkownika bezpośrednio w portalu Azure.

Domyślne uprawnienia systemu plików HDFS

  • Domyślnie użytkownicy nie mają dostępu do folderu / w HDFS (muszą mieć rolę właściciela blob magazynu, aby uzyskanie dostępu się powiodło).
  • Dla katalogu przejściowego dla mapreduce i innych jest tworzony katalog specyficzny dla użytkownika, a następnie przyznawane są mu odpowiednie 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 polityki.

Zarządzanie dziennikami inspekcji Ranger

Aby zapobiec używaniu zbyt dużej ilości miejsca na dysku przez dzienniki audytowe Ranger na głównym węźle hn0, można zmienić liczbę dni, przez które są one przechowywane.

  1. Zaloguj się do interfejsu użytkownika systemu Ambari.
  2. Przejdź do 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, używając portalu Azure, menedżera zasobów Azure, interfejsu wiersza polecenia platformy Azure itp.

Ustaw synchronizację użytkownika Ranger do codziennego uruchamiania

Klastry HDInsight ESP są skonfigurowane dla platformy Ranger do automatycznego synchronizowania użytkowników AD co godzinę. Synchronizacja Ranger to synchronizacja użytkowników i może spowodować dodatkowe obciążenie instancji 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 Usługi>Ranger>Konfiguracje>Zaawansowane>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.

Polityki

  • 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 zewnętrznej usługi do uwierzytelniania wieloskładnikowego (innego niż Microsoft Entra ID), polityka oparta na adresie IP nie będzie 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.

Wybierz prawidłową jednostkę SKU dla 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ć instancji usług Microsoft Entra Domain Services na potrzeby żądań uwierzytelniania, określa, który wariant SKU jest odpowiedni dla Twojej organizacji. Jeśli zauważysz wysokie zużycie CPU w domenie zarządzanej lub na przykład wymagania biznesowe zmieniają się, możesz uaktualnić SKU.

Instancja 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 peered sieci wirtualnej do wdrażania klastrów (to będzie pomocne, gdy masz wiele zespołów wdrażających klastry HDInsight ESP). Dzięki temu nie trzeba otwierać portów (NSG) w sieci wirtualnej z kontrolerem domeny.
  • Skonfiguruj DNS dla sieci wirtualnej prawidłowo (nazwa domeny usługi Microsoft Entra Domain Services powinna być rozpoznawana bez żadnych wpisów w pliku hosts).
  • Jeśli ograniczasz ruch wychodzący, upewnij się, że przeczytałeś o obsłudze 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. Wdrożenie tych 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 o ograniczonym 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 ograniczona zakresem" w celu uzyskania najlepszej wydajności.

Synchronizację o określonym zakresie można modyfikować przy użyciu różnych wyborów grup lub, jeśli to konieczne, przekształcać na (opcja "Wszyscy") użytkowników i grupy. Nie można zmienić typu synchronizacji z "All" na "Scoped", chyba że usuniesz i utworzysz ponownie instancję 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ą wejść w konflikt i zostać przemianowane. Zwróć uwagę na mapowanie właściwości od Microsoft Entra ID do 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 hashowania 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 środowisko z Microsoft Entra ID musi być włączone za pośrednictwem 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 instancji 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 cron.daily: sudo mv /etc/cron.hourly/ambarildapsync /etc/cron.daily/ambarildapsync
  3. Zastosuj zmianę w zadaniu crontab: sudo service cron reload
  4. Użyj SSH, aby połączyć się z hn1 i powtórz kroki 1–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 przydzielony w jednostkę organizacyjną. 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.
  • NSG (Sieciowe grupy zabezpieczeń) są zbyt restrykcyjne, co uniemożliwia dołączenie do domeny.
  • Tożsamość zarządzana nie ma wystarczających uprawnień.
  • Nazwa klastra nie jest unikatowa dla pierwszych sześciu znaków (z innym aktywnym klastrem lub z usuniętym klastrem).

Ustawienie 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 e-mail 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).

Wygenerować pliki keytab użytkownika domeny

Wszystkie keytaby 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ć keytab dla nazwy użytkownika domeny.

Użyj narzędzia ktutil na jednej z maszyn wirtualnych klastra, aby utworzyć keytab systemu 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 pliku kluczowego 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 ADLS Gen2 i klastrów Microsoft Entra Domain Services, obie powinny mieć przypisane role Właściciel danych obiektów blob 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

  • Last updated on