Kontextbasierte Zugriffskontrolle

Diese Seite bietet eine Übersicht über die kontextbasierte Zugangskontrolle. Informationen zur serverlosen Ausgangssteuerung finden Sie unter Was ist serverloses Ausgangssteuerelement?.

Informationen zum Konfigurieren von Eingangsrichtlinien finden Sie unter Verwalten kontextbasierter Eingangsrichtlinien.

Übersicht über kontextbasierte Zugangskontrolle

Die kontextbasierte Steuerung eingehender Zugriffe arbeitet zusammen mit IP-Zugriffslisten und der privaten Frontend-Konnektivität, damit Kontoadministratoren Regeln zum Zulassen und Verweigern festlegen können, die kombinieren, wer zugreift, von wo aus zugegriffen wird und worauf in Azure Databricks zugegriffen werden kann. Dadurch wird sichergestellt, dass nur vertrauenswürdige Kombinationen aus Identität, Anforderungstyp und Netzwerkquelle Ihren Arbeitsbereich erreichen können. Die kontextbasierte Zugriffskontrolle wird auf der Kontoebene konfiguriert. Eine einzelne Richtlinie kann mehrere Arbeitsbereiche steuern.

Mit kontextbasiertem Eingangs können Sie:

• Beenden Sie den Zugriff von nicht vertrauenswürdigen Netzwerken, indem Sie zusätzlich zu den Anmeldeinformationen einen zweiten Faktor, eine vertrauenswürdige Netzwerkquelle, benötigen.
• Ermöglichen Sie SaaS-Clients ohne feste Egress-IPs den Zugriff, indem Sie die Identität statt IP-Adressbereichen als Grundlage verwenden.
• Beschränken Sie den Zugriff, indem Sie weniger vertrauenswürdigen Quellen erlauben, nur bestimmte Berechtigungsbereiche wie Azure-Databricks-APIs oder die Arbeitsbereichs-UI zu verwenden.
• Schützen Sie die privilegierte Automatisierung: Beschränken Sie besonders schützenswerte Service Principals ausschließlich auf hochvertrauenswürdige Netzwerke.
• Effektive Überwachung: Erfassen Sie detaillierte Denialprotokolle in Unity Catalog-Systemtabellen, um blockierte Anforderungen zu überwachen.

Kontextbasierte Eingangssteuerungskernkonzepte

Netzwerkquellen

Eine Netzwerkquelle definiert den Ursprung von Anforderungen. Unter anderem unterstützte Typen:

Richtlinie für den öffentlichen Zugriff:

• Alle öffentlichen IPs: alle öffentlichen Internetquellen.
• Ausgewählte IPs: Bestimmte IPv4-Adressen oder CIDR-Bereiche.
• Partnerplattformen (Beta): IPs, die Drittanbieter-Apps (Power BI,Tableau Cloud und dbt-Plattform) verwenden, um sich mit Azure Databricks zu verbinden. Azure Databricks verwaltet und aktualisiert diese IP-Listen automatisch.

Richtlinie für den privaten Zugriff:

• Alle registrierten privaten Endpunkte: Jeder registrierte private Endpunkt im Konto.
• Ausgewählte private Endpunkte: Bestimmte registrierte private Endpunkte im Konto.

• Azure Workspace Private Link: In der Workspace-Richtlinie nur Ablehnungsregeln. Verweigert den Zugriff auf alle databricks_ui_api Endpunkte.
• Jeglicher privater Zugriff: Nur in den Verweigerungsregeln der Workspace-Richtlinie. Verweigert den Zugriff auf alle databricks_ui_api und registrierten Endpunkte.

Zugriffstypen

Regeln gelten für unterschiedliche Bereiche eingehender Anforderungen. Jeder Bereich stellt eine Kategorie eingehender Anforderungen dar, die Sie zulassen oder verweigern können:

Zugriffstypen für Richtlinien auf Ebene des Arbeitsbereichs:

• Arbeitsbereichs-UI: Browserzugriff auf den Arbeitsbereich.
• API: Programmatischer Zugriff über die Azure Databricks-APIs, einschließlich SQL-Endpunkten (JDBC / ODBC). Sie können auf alle APIs oder einen bestimmten API-Bereich abzielen, z. B. Apps, Dashboard oder Modellbereitstellung.
• Apps-Laufzeit: Zulassen oder Verweigern des Zugriffs auf Databricks Apps-Bereitstellungen. Siehe Databricks-Apps. Nur die Identitätsoption "Alle Benutzer" und "Dienstprinzipale" wird für diesen Zugriffstyp unterstützt.

• Lakebase-Laufzeit: Verbindungen mit Lakebase-Datenbankinstanzen. Siehe Lakebase. Nur die Identitätsoption "Alle Benutzer" und "Dienstprinzipale" wird für diesen Zugriffstyp unterstützt.

Zugriffstypen für Richtlinien auf Kontoebene:

• Konto-Benutzeroberfläche: Browserzugriff auf Ressourcen auf Kontoebene (z. B. die Kontokonsole und Genie One auf Kontoebene).
• Konto-API: Programmgesteuerter Zugriff über Azure Databricks Konto-APIs.

Identitäten

Regeln können auf unterschiedliche Identitätstypen abzielen. Für die Zugriffstypen "Apps-Runtime " und " Lakebase runtime " ist die einzige unterstützte Option "Alle Benutzer und Dienstprinzipale".

In der Richtlinie auf Kontoebene ist die einzige unterstützte Option Alle Benutzer und Dienstprinzipale.

• Alle Benutzer und Dienstprinzipale: Sowohl menschliche Benutzer als auch Automatisierung.
• Alle Benutzer: Nur menschliche Benutzer.
• Alle Dienstprinzipale: Nur Automatisierungsidentitäten.
• Ausgewählte Identitäten: Bestimmte Benutzer oder Dienstprinzipale.

Regelauswertung

• Standardverweigerung: Im eingeschränkten Modus wird der Zugriff verweigert, es sei denn, der Zugriff ist explizit zulässig.
• Vor der Zulassung verweigern: Mit Verweigerungsregeln können Sie Ausnahmen für Ihre Zulassungsregeln definieren.
• Standardrichtlinie auf Arbeitsbereichsebene: Für jedes Konto wird eine Standard-Ingress-Richtlinie auf Arbeitsbereichsebene auf alle infrage kommenden Arbeitsbereiche angewendet, denen keine explizite Richtlinie zugewiesen ist.

Durchsetzungsmodi

Kontextbasierte Eingangsrichtlinien ermöglichen zwei Modi:

• Erzwungen für alle Produkte: Azure Databricks setzt Regeln aktiv durch und blockiert Anfragen, die dagegen verstoßen.
• Testlaufmodus für alle Produkte: Azure Databricks protokolliert Verstöße, blockiert jedoch keine Anfragen. Verwenden Sie diesen Modus, um die Auswirkungen der Richtlinie vor der Erzwingung auszuwerten.

Überwachung

Abgelehnte oder Testlaufanforderungen werden in der Systemtabelle system.access.inbound_network protokolliert. Wenn Sie keinen Zugriff auf Systemtabellen haben, kann ein Metastore-Administrator Ihnen Berechtigungen erteilen. Siehe Gewähren des Zugriffs auf Systemtabellen.

Jeder Protokolleintrag umfasst:

• Ereigniszeit
• Arbeitsbereichs-ID
• Regelbezeichnung (der Regel, die die Anforderung verweigert hat)
• Anforderungstyp
• Identität
• Netzwerkquelle
• Zugriffstyp (VERWEIGERT oder DRY_RUN_DENIAL)

Fragen Sie diese Protokolle ab, um zu überprüfen, ob Ihre Regeln wie erwartet funktionieren, und um unerwartete Zugriffsversuche abzufangen.

Beziehung zu anderen Steuerelementen

• IP-Zugriffslisten für Arbeitsbereiche: Diese werden zusammen mit der kontextbasierten Eingangsrichtlinie unter Verwendung eines logischen UND-Operators ausgewertet, wobei keine strikte Sequenz zwischen den beiden besteht. Eine Anforderung ist nur zulässig, wenn sowohl die IP-Zugriffsliste als auch die Eingangsrichtlinie sie zulassen. Arbeitsbereich-IP-Zugriffslisten können den Zugriff weiter einschränken, aber nicht verbreitern.
• Serverlose Ausgangssteuerung: Ergänzt Eingangsrichtlinien durch die Steuerung des ausgehenden Netzwerkverkehrs von serverlosem Compute. Siehe "Verwalten von Netzwerkrichtlinien".

• Private Front-End-Konnektivität: Für Workspace-Richtlinien und einen bestimmten registrierten Endpunkt sind Endpunkte zulässig, die entweder im kontextbasierten Ingress oder im databricks_ui_api privaten Endpunkt zulässig sind. Wenn jedoch die kontextbasierte Ingress-Policy des Arbeitsbereichs eine Ablehnungsregel hat, die alle databricks_ui_api Endpunkte ablehnt, kann kein databricks_ui_api Endpunkt auf Azure Databricks zugreifen. Siehe Eingehenden private Verbindung für Arbeitsbereiche konfigurieren.
• Umschalter „Zugriff über öffentliches Netzwerk zulassen“: Wenn Zugriff über öffentliches Netzwerk zulassen auf Aktiviert gesetzt ist, werden IP-Zugriffslisten für Arbeitsbereiche ausgewertet. Andernfalls wird aller öffentliche eingehende Zugriff blockiert, und die Richtlinien für den öffentlichen eingehenden Zugriff des Arbeitsbereichs werden nicht ausgewertet.

Bewährte Methoden

• Beginnen Sie mit dem Trockenlaufmodus, um Auswirkungen zu beobachten, ohne den Zugriff zu unterbrechen.
• Verwenden Sie identitätsbasierte Regeln, sofern möglich, für SaaS-Clients, die IPs drehen.
• Wenden Sie Verweigerungsregeln zuerst auf privilegierte Dienstprinzipale an, um den betroffenen Bereich einzuschränken.
• Achten Sie darauf, dass Richtliniennamen klar und konsistent sind.