Allgemeine Informationen und Richtlinien für die Unternehmenssicherheit in Azure HDInsight
Beim Bereitstellen eines sicheren HDInsight-Clusters gibt es einige bewährte Methoden, mit denen die Bereitstellung und Clusterverwaltung erleichtert wird. In diesem Artikel werden einige allgemeine Informationen und Richtlinien erläutert.
Verwendung eines sicheren Clusters
Empfohlen
- Der Cluster wird von mehreren Benutzern gleichzeitig verwendet.
- Die Benutzer haben verschiedene Zugriffsebenen für dieselben Daten.
Nicht erforderlich
- Sie planen, nur automatisierte Aufträge auszuführen (z. B. ein einzelnes Benutzerkonto), und ein Standardcluster ist ausreichend.
- Sie können den Datenimport mit einem Standardcluster durchführen und verwenden dasselbe Speicherkonto auf einem anderen sicheren Cluster, in dem die Benutzer Analyseaufträge ausführen können.
Verwendung eines lokalen Kontos
- Wenn Sie ein gemeinsam genutztes Benutzerkonto oder ein lokales Konto verwenden, ist es schwierig herauszufinden, wer das Konto zum Ändern der Konfiguration oder des Diensts verwendet hat.
- Die Verwendung lokaler Konten ist problematisch, wenn Benutzer nicht mehr der Organisation angehören.
Ranger
Richtlinien
Standardmäßig verwendet Ranger Ablehnen als Richtlinie.
Wenn der Datenzugriff über einen Dienst erfolgt, bei dem die Autorisierung aktiviert ist:
- Das Ranger-Autorisierungs-Plug-In wird aufgerufen und erhält den Kontext der Anforderung.
- Ranger wendet die für den Dienst konfigurierten Richtlinien an. Wenn bei den Ranger-Richtlinien ein Fehler auftritt, wird die Zugriffsüberprüfung auf das Dateisystem verschoben. Einige Dienste wie MapReduce überprüfen nur, ob sich die Datei bzw. der Ordner im Besitz desselben Benutzers befindet, der die Anforderung sendet. Dienste wie Hive überprüfen, ob entweder eine Übereinstimmung des Besitzers oder entsprechende Dateisystemberechtigungen (
rwx
) vorliegen.
Bei Hive sollte der Benutzer außer über die Berechtigungen zum Erstellen/Aktualisieren/Löschen auch über
rwx
-Berechtigungen für das Verzeichnis im Speicher und alle Unterverzeichnisse verfügen.Richtlinien können (vorzugsweise) auf Gruppen statt auf Einzelpersonen angewendet werden.
Der Ranger-Autorisierer wertet alle Ranger-Richtlinien für diesen Dienst für jede Anforderung aus. Diese Auswertung kann sich auf den Zeitraum auswirken, der für die Annahme des Auftrags oder der Abfrage benötigt wird.
Speicherzugriff
- Wenn der Speichertyp WASB lautet, ist kein OAuth-Token einbezogen.
- Wenn Ranger die Autorisierung durchgeführt hat, erfolgt der Speicherzugriff mithilfe der verwalteten Identität.
- Hat Ranger keine Autorisierung durchgeführt, erfolgt der Speicherzugriff über das OAuth-Token des Benutzers.
Hierarchischer Namespace
Wenn der hierarchische Namespace nicht aktiviert ist:
- Es gibt keine geerbten Berechtigungen.
- Die einzige Dateisystemberechtigung, die funktioniert, ist die Azure-Rolle Speicherdaten XXXX, die dem Benutzer direkt im Azure-Portal zugewiesen werden muss.
HDFS-Standardberechtigungen
- Standardmäßig haben Benutzer keinen Zugriff auf den Ordner / im HDFS (sie müssen der Rolle der Speicherblobbesitzer angehören, damit der Zugriff erfolgreich ist).
- Für das Stagingverzeichnis für MapReduce und andere wird ein benutzerspezifisches Verzeichnis erstellt und es werden
sticky _wx
-Berechtigungen bereitgestellt. Benutzer können darunter Dateien und Ordner erstellen, aber keine anderen Elemente anzeigen.
URL-Authentifizierung
Wenn die URL-Authentifizierung aktiviert ist:
- Die Konfiguration gibt an, welche Präfixe in der URL-Authentifizierung enthalten sind (z. B.
adl://
). - Wenn der Zugriff auf diese URL erfolgt, prüft Ranger, ob der Benutzer in der Zulassungsliste enthalten ist.
- Ranger überprüft keine der differenzierten Richtlinien.
Verwalten von Ranger-Überwachungsprotokollen
Um zu verhindern, dass Ranger-Überwachungsprotokolle zu viel Speicherplatz auf Ihrem hn0-Hauptknoten verbrauchen, können Sie die Anzahl der Tage ändern, die die Protokolle aufbewahrt werden sollen.
- Melden Sie sich bei der Ambari-Benutzeroberfläche an.
- Navigieren Sie zu Dienste>Ranger>Konfigurationen>Erweitert>Erweiterte Ranger-Solr-Konfiguration.
- Ändern Sie „Max. Aufbewahrungstage“ in 7 Tage oder weniger.
- Wählen Sie Speichern aus, und starten Sie die betroffenen Komponenten neu, damit die Änderung wirksam wird.
Verwenden einer benutzerdefinierten Ranger-Datenbank
Es wird empfohlen, eine externe Ranger-Datenbank für die Verwendung mit Ihrem ESP-Cluster bereitzustellen, um die Hochverfügbarkeit von Ranger-Metadaten zu gewährleisten. Dadurch wird sichergestellt, dass Richtlinien auch dann verfügbar sind, wenn der Cluster nicht verfügbar ist. Da eine externe Datenbank vom Kunden verwaltet wird, haben Sie auch die Möglichkeit, die Datenbankgröße zu optimieren und die Datenbank in mehreren ESP-Clustern freizugeben. Sie können Ihre externe Ranger-Datenbank während der Erstellung des ESP-Clusters mithilfe von Azure-Portal, Azure Resource Manager, Azure CLI usw. angeben.
Festlegen der Ranger-Benutzersynchronisierung zur täglichen Ausführung
HDInsight ESP-Cluster sind für Ranger so konfiguriert, dass AD-Benutzer stündlich automatisch synchronisiert werden. Die Ranger-Synchronisierung ist eine Benutzersynchronisierung und kann zusätzliche Last für die AD-Instanz verursachen. Aus diesem Grund wird empfohlen, das Ranger-Benutzersynchronisierungsintervall in 24 Stunden zu ändern.
- Melden Sie sich bei der Ambari-Benutzeroberfläche an.
- Navigieren Sie zu Dienste>Ranger>Konfigurationen>Erweitert>ranger-ugsync-site
- Legen Sie die Eigenschaft ranger.usersync.sleeptimeinmillisbetweensynccycle auf 86400000 (24 Stunden in Millisekunden) fest.
- Wählen Sie Speichern aus, und starten Sie die betroffenen Komponenten neu, damit die Änderung wirksam wird.
Ressourcengruppen
Verwenden Sie für jeden Cluster eine neue Ressourcengruppe, um zwischen Clusterressourcen unterscheiden zu können.
NSGs, Firewalls und internes Gateway
- Verwenden Sie Netzwerksicherheitsgruppen (NSGs), um virtuelle Netzwerke zu sperren.
- Verwenden Sie Firewalls für Richtlinien für den ausgehenden Zugriff.
- Verwenden Sie das interne Gateway, das nicht für das öffentliche Internet geöffnet ist.
Microsoft Entra ID
Microsoft Entra ID ist ein cloudbasierter Identitäts- und Zugriffsverwaltungsdienst von Microsoft.
Richtlinien
Deaktivieren Sie die Richtlinie für bedingten Zugriff mithilfe der auf IP-Adressen basierenden Richtlinie. Hierfür ist es erforderlich, dass Dienstendpunkte in den VNETs aktiviert werden, in denen die Cluster bereitgestellt werden. Wenn Sie einen externen Dienst für MFA verwenden (einen anderen als Microsoft Entra ID), funktioniert die auf IP-Adressen basierende Richtlinie nicht
Für Verbundbenutzer ist die Richtlinie
AllowCloudPasswordValidation
erforderlich. Da HDInsight den Benutzernamen/das Kennwort direkt zum Abrufen von Token aus Microsoft Entra ID verwendet, muss diese Richtlinie für alle Verbundbenutzer aktiviert werden.Aktivieren Sie Dienstendpunkte, wenn Sie eine Umgehung des bedingten Zugriffs mithilfe vertrauenswürdiger IP-Adressen benötigen.
Gruppen
- Stellen Sie Cluster immer mit einer Gruppe bereit.
- Verwenden Sie Microsoft Entra ID zum Verwalten von Gruppenmitgliedschaften (einfacher als die Verwaltung der einzelnen Dienste im Cluster).
Benutzerkonten
- Verwenden Sie für jedes Szenario ein eindeutiges Benutzerkonto. Verwenden Sie beispielsweise ein Konto für den Import, ein anderes für die Abfrage und wieder ein anderes für das Verarbeiten von Aufträgen.
- Verwenden Sie gruppenbasierte Ranger-Richtlinien anstelle von Einzelrichtlinien.
- Planen Sie die Verwaltung von Benutzern, die keinen Zugriff mehr auf Cluster haben sollen.
Microsoft Entra Domain Services
Microsoft Entra Domain Services stellt verwaltete Domänendienste bereit, z. B. Domänenbeitritt, Gruppenrichtlinie, LDAP (Lightweight Directory Access Protocol) und Kerberos-/NTLM-Authentifizierung, die mit Windows Server Active Directory vollständig kompatibel sind.
Microsoft Entra Domain Services ist erforderlich, damit sichere Cluster einer Domäne beitreten können. HDInsight kann nicht von lokalen Domänencontrollern oder benutzerdefinierten Domänencontrollern abhängig sein, da dies zu viele Fehlerpunkte, eine gemeinsame Verwendung von Anmeldeinformationen, DNS-Berechtigungen usw. nach sich zieht. Weitere Informationen finden Sie in derMicrosoft Entra Domain Services FAQ.
Wählen Sie die richtige Microsoft Entra Domain Services-SKU aus
Beim Erstellen Ihrer verwalteten Domäne können Sie aus verschiedenen SKUs wählen, die unterschiedliche Leistungsstufen und Features bieten. Die Anzahl von ESP-Clustern und anderen Anwendungen, welche die Microsoft Entra Domain Services-Instanz für Authentifizierungsanforderungen verwenden, bestimmt, welche SKU für Ihre Organisation geeignet ist. Wenn Sie eine hohe CPU-Auslastung in Ihrer verwalteten Domäne feststellen oder sich Ihre geschäftlichen Anforderungen ändern, können Sie ein Upgrade für Ihre SKU durchführen.
Erstellen von Microsoft Entra Domain Services-Instanzen
- Erstellen Sie die Instanz mit
.onmicrosoft.com domain
. Auf diese Weise sind nicht mehrere DNS-Server für die Domäne vorhanden. - Erstellen Sie ein selbstsigniertes Zertifikat für LDAPS, und laden Sie es in Microsoft Entra Domain Services hoch.
- Verwenden Sie für die Bereitstellung von Clustern ein virtuelles Netzwerk mit Peering (dies ist hilfreich, wenn Sie über mehrere Teams verfügen, die HDInsight ESP-Cluster bereitstellen). Dadurch wird sichergestellt, dass Sie keine Ports (NSGs) im virtuellen Netzwerk mit dem Domänencontroller öffnen müssen.
- Konfigurieren Sie das DNS für das virtuelle Netzwerk ordnungsgemäß (der Microsoft Entra Domain Services-Domänenname sollte ohne Hostdateieinträge aufgelöst werden).
- Wenn Sie den ausgehenden Datenverkehr einschränken, stellen Sie sicher, dass Sie sich über die Firewall-Unterstützung in HDInsight informiert haben.
Berücksichtigen Sie Replikatsgruppen für Microsoft Entra Domain Services
Wenn Sie eine verwaltete Microsoft Entra Domain Services-Domäne erstellen, definieren Sie einen eindeutigen Namespace, und zwei Domänencontroller (DCs) werden dann in Ihrer ausgewählten Azure-Region bereitgestellt. Diese Bereitstellung von Domänencontrollern wird als Replikatgruppe bezeichnet. Das Hinzufügen zusätzlicher Replikatgruppen sorgt für Resilienz und stellt die Verfügbarkeit von Authentifizierungsdiensten sicher, was für Azure HDInsight-Cluster von entscheidender Bedeutung ist.
Konfigurieren der bereichsbezogenen Benutzer-/Gruppensynchronisierung
Wenn Sie Microsoft Entra Domain Services für Ihren ESP-Cluster aktivieren, können Sie alle Benutzer und Gruppen aus Microsoft Entra ID oder bereichsbezogene Gruppen und deren Mitglieder synchronisieren. Es wird empfohlen, „Bereichsbezogene“ Synchronisierung auszuwählen, um die beste Leistung zu erzielen.
Die bereichsbezogene Synchronisierung kann mit einer unterschiedlichen Gruppenauswahl geändert oder bei Bedarf in „Alle“ Benutzer und Gruppen konvertiert werden. Der Synchronisierungstyp kann nicht von „Alle“ in „Bereichsbezogen“ geändert werden, es sei denn, die Microsoft Entra Domain Services-Instanz wird gelöscht und erneut erstellt.
Eigenschaften synchronisiert von Microsoft Entra ID zu Microsoft Entra Domain Services
- Microsoft Entra Connect synchronisiert von lokalen in Microsoft Entra ID.
- Microsoft Entra Domain Services von Microsoft Entra ID.
Microsoft Entra Domain Services synchronisiert regelmäßig Objekte von Microsoft Entra ID. Auf dem Blatt für Microsoft Entra Domain Services im Azure-Portal wird der Synchronisierungsstatus angezeigt. In jeder Phase der Synchronisierung können eindeutige Eigenschaften in Konflikt geraten und umbenannt werden. Achten Sie auf die Eigenschaftenzuordnung von Microsoft Entra ID zu Microsoft Entra Domain Services.
Weitere Informationen finden Sie unter Microsoft Entra UserPrincipalName-Population und Verwendung der Microsoft Entra Domain Services-Synchronisierung.
Kennworthashsynchronisierung
- Kennwörter werden anders als andere Objekttypen synchronisiert. Nur nicht umkehrbare Kennworthashes werden in Microsoft Entra ID und Microsoft Entra Domain Services synchronisiert
- Die Synchronisierung lokaler Einträge mit Microsoft Entra ID muss über AD Connect aktiviert werden
- Die Microsoft Entra ID zur Microsoft Entra Domain Services-Synchronisierung ist automatisch (Wartezeiten liegen unter 20 Minuten).
- Kennworthashes werden nur synchronisiert, wenn ein geändertes Kennwort vorliegt. Wenn Sie die Kennworthashsynchronisierung aktivieren, werden vorhandene Kennwörter nicht automatisch synchronisiert, da sie als nicht umkehrbar gespeichert sind. Wenn Sie das Kennwort ändern, werden die Kennworthashes synchronisiert.
Festlegen der Ambari-LDAP-Synchronisierung zur täglichen Ausführung
Der Prozess der Synchronisierung neuer LDAP-Benutzer mit Ambari wird automatisch so konfiguriert, dass er stündlich ausgeführt wird. Die stündliche Ausführung dieses Prozesses kann zu einer übermäßigen Belastung der Hauptknoten des Clusters und der AD-Instanz führen. Für eine verbesserte Leistung wird empfohlen, das Skript /opt/startup_scripts/start_ambari_ldap_sync.py, mit dem die Ambari-LDAP-Synchronisierung ausgeführt wird, so zu ändern, dass es einmal am Tag ausgeführt wird. Dieses Skript wird über einen crontab-Auftrag ausgeführt, und es wird im Verzeichnis „/etc/cron.hourly/“ auf den Clusterkopfknoten gespeichert.
Führen Sie die folgenden Schritte aus, damit es einmal täglich ausgeführt wird:
- SSH-Verbindung mit „hn0“
- Verschieben Sie das Skript in den täglichen Cron-Folder:
sudo mv /etc/cron.hourly/ambarildapsync /etc/cron.daily/ambarildapsync
- Wenden Sie die Änderung im crontab-Auftrag an:
sudo service cron reload
- ssh an hn1 und Schritte 1 - 3 wiederholen
Bei Bedarf können Sie die Ambari-REST-API verwenden, um neue Benutzer und Gruppen sofort manuell zu synchronisieren.
Speicherort von Computerobjekten
Jedem Cluster ist eine einzelne Organisationseinheit zugeordnet. Ein interner Benutzer wird in der Organisationseinheit bereitgestellt. Alle Knoten sind in derselben Organisationseinheit in die Domäne eingebunden.
Active Directory-Verwaltungstools
Weitere Informationen finden Sie unter Installationsverwaltungstools.
Problembehandlung
Bei der Clustererstellung tritt wiederholt ein Fehler auf
Häufigste Ursachen:
- Die DNS-Konfiguration ist nicht richtig, beim Domänenbeitritt von Clusterknoten tritt ein Fehler auf.
- NSGs sind zu restriktiv und verhindern einen Domänenbeitritt.
- Die verwaltete Identität besitzt keine ausreichenden Berechtigungen.
- Die ersten sechs Zeichen des Clusternamens sind nicht eindeutig (stimmen entweder mit einem anderen aktiven Cluster oder mit einem gelöschten Cluster überein).
Einrichtung und Konfiguration der Authentifizierung
Benutzerprinzipalname (User Principal Name, UPN)
- Verwenden Sie für alle Dienste Kleinbuchstaben. Bei UPNs wird die Groß-/Kleinschreibung in ESP-Clustern nicht beachtet. Allerdings gilt:
- Das UPN-Präfix muss beiden SAMAccountName-Werten in Microsoft Entra Domain Services entsprechen. Eine Übereinstimmung mit dem E-Mail-Feld ist nicht erforderlich.
LDAP-Eigenschaften in der Ambari-Konfiguration
Eine vollständige Liste der Ambari-Eigenschaften, die sich auf die Konfiguration Ihres HDInsight-Cluster auswirken, finden Sie unter Einrichtung der Ambari-LDAP-Authentifizierung.
Generieren von Domänenbenutzer-Schlüsseltabellen
Alle Dienstschlüsseltabellen werden während der Erstellung des ESP-Clusters automatisch für Sie generiert. Um eine sichere Kommunikation zwischen dem Cluster und anderen Diensten und/oder Aufträgen zu ermöglichen, die eine Authentifizierung erfordern, können Sie eine Schlüsseltabelle für Ihren Domänenbenutzernamen generieren.
Verwenden Sie ktutil auf einem der Cluster-VMs, um eine Kerberos-Schlüsseltabelle zu erstellen:
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
Wenn Ihr TenantName und DomainName unterschiedlich sind, müssen Sie mithilfe der Option „-s“ einen SALT-Wert hinzufügen. Schauen Sie auf der HDInsight-FAQ-Seite nach, um den richtigen SALT-Wert bei der Erstellung einer Kerberos-Schlüsseltabelle zu ermitteln.
LDAP-Zertifikatsverlängerung
HDInsight verlängert automatisch die Zertifikate für die verwalteten Identitäten, die Sie für Cluster mit dem Enterprise-Sicherheitspaket (ESP) verwenden. Es gibt jedoch eine Einschränkung, wenn unterschiedliche verwaltete Identitäten für Microsoft Entra Domain Services und ADLS Gen2 verwendet werden, die dazu führen kann, dass der Verlängerungsprozess fehlschlägt. Befolgen Sie die folgenden beiden Empfehlungen, um sicherzustellen, dass Ihre Zertifikate erfolgreich verlängert werden können:
- Wenn Sie unterschiedliche verwaltete Identitäten für ADLS Gen2 und Microsoft Entra Domain Services-Cluster verwenden, sollten beide über die Rollen Besitzer von Speicherblobdaten und Mitwirkender für die HDInsight-Domänendienste verfügen.
- HDInsight-Cluster erfordern öffentliche IP-Adressen für Zertifikatsaktualisierungen und andere Wartungen, daher sollten alle Richtlinien entfernt werden, die öffentliche IP-Adressen im Cluster verweigern.