Toegangsbeheer op basis van context

Deze pagina geeft een overzicht van contextgebaseerde ingress control, inclusief de kernconcepten, handhavingsmodi, auditing en hoe het samenwerkt met andere netwerkbesturingssystemen. Om beleidsregels te configureren, raadpleegt u Contextgebaseerde toegangsbeleidsregels beheren. Zie Wat is serverloos uitgaand verkeer?

Overzicht van toegangsbeheer op basis van context

Contextafhankelijke controle van inkomend verkeer werkt samen met IP-toegangslijsten en front-endprivéconnectiviteit om accountbeheerders in staat te stellen toestaan- en weigerregels in te stellen waarin wordt gecombineerd wie er aanroept, van waaruit dat gebeurt en wat ze kunnen bereiken in Azure Databricks. Dit zorgt ervoor dat alleen vertrouwde combinaties van identiteit, aanvraagtype en netwerkbron uw werkruimte kunnen bereiken. Het beheer voor inkomend verkeer op basis van context wordt geconfigureerd op accountniveau. Eén beleid kan meerdere werkruimten beheren.

Met behulp van context-gebaseerde toegang kunt u het volgende doen:

• Stop de toegang vanaf niet-vertrouwde netwerken door een tweede factor, een vertrouwde netwerkbron, naast referenties te vereisen.
• Sta SaaS-clients zonder vaste uitgaande IP-adressen toegang toe door dit op identiteit te baseren in plaats van op IP-bereiken.
• Beperk de toegang door minder vertrouwde bronnen alleen bepaalde machtigingen toe te staan, zoals Azure Databricks API’s of de gebruikersinterface van de werkruimte.
• Beschermde automatisering beveiligen: alleen service-principals met hoge waarde beperken tot netwerken met hoge vertrouwensrelatie.
• Effectief controleren: gedetailleerde denial-logboeken vastleggen in systeemtabellen van Unity Catalog om geblokkeerde aanvragen te bewaken.

Beleidsregels op werkruimteniveau versus accountniveau

Contextgebaseerde ingress control gebruikt twee soorten beleidsmaatregelen. Beleidsregels op werkruimteniveau regelen de toegang tot werkruimtes. Beleidsregels op accountniveau bepalen de toegang tot resources op accountniveau, zoals de accountconsole en Genie One op accountniveau.

Accountniveau-beleidsregels zijn in bèta. Om te beginnen, schakel Context-Based Ingress: Account Policy in.

Basisconcepten voor context-based toegangscontrole

Netwerkbronnen

Een netwerkbron definieert de oorsprong van aanvragen. Ondersteunde typen zijn onder andere:

Beleid voor openbare toegang:

• Alle openbare IP-adressen: elke openbare internetbron.
• Geselecteerde IP-adressen: specifieke IPv4-adressen of CIDR-bereiken.
• Partnerplatforms (Bèta): IP's die apps van derden (Power BI, Tableau Cloud en dbt-platform) gebruiken om verbinding te maken met Azure Databricks. Azure Databricks beheert en werkt deze IP-lijsten automatisch bij.

Beleid voor privétoegang:

• Alle geregistreerde privé-eindpunten: elk geregistreerd privé-eindpunt in het account.
• Geselecteerde privé-eindpunten: specifieke geregistreerde privé-eindpunten in het account.

• Azure workspace Private Link: Alleen in weigeringsregels van het werkruimtebeleid. Weigert toegang tot alle databricks_ui_api eindpunten.
• Alle privétoegang: Alleen in weigeringsregels van het workspacebeleid. Weigert toegang tot alle databricks_ui_api en geregistreerde eindpunten.

Toegang tussen werkruimten (Beta): Bepaalt welke bronwerkruimten deze werkruimte via serverloos verkeer kunnen bereiken, met dezelfde identiteiten en toelatings- en weigeringsregels als andere netwerkbronnen.

• Geselecteerde werkruimtes: Alleen de werkruimtes waarvan je de ID's vermeldt.

Je kunt dit beleid ook in compatibiliteitsmodus laten, in dat geval regelt het niet de ingang tussen werkruimtes en gelden de reeds bestaande netwerkcontroles van de werkruimte. Als u toegang tussen werkruimten voor zowel inkomende als uitgaande toegang wilt configureren en de beperkingen ervan wilt raadplegen, raadpleegt u Cross-workspace access.

Toegangstypen

Regels zijn van toepassing op verschillende binnenkomende aanvraagbereiken. Elk bereik vertegenwoordigt een categorie binnenkomende aanvragen die u kunt toestaan of weigeren:

Toegangstypen voor beleid op werkruimteniveau:

• Werkruimte-ui: browsertoegang tot de werkruimte.
• API: Programmatische toegang via Azure Databricks API's, waaronder SQL-eindpunten (JDBC/ODBC). Je kunt je richten op een van de volgende factoren:
  • Alle API's.
  • Een specifieke API-scope, met gebruik van IN. Je kunt bijvoorbeeld apps, een dashboard of modelimplementatie opgeven.
  • Alle API-scopes behalve geselecteerde, met NOT IN.
• Apps-runtime: Toegang tot Databricks Apps-implementaties toestaan of weigeren. Zie Databricks-apps. Alleen de identiteitsoptie Alle gebruikers en service-principals wordt ondersteund voor dit toegangstype.
• Lakebase-runtime: Verbindingen met Lakebase-database-exemplaren. Zie Lakebase. Alleen de identiteitsoptie Alle gebruikers en service-principals wordt ondersteund voor dit toegangstype.

Toegangstypen voor beleid op accountniveau (Beta):

• Accountinterface: Toegang via de browser tot bronnen op accountniveau (bijvoorbeeld de accountconsole en Genie One op accountniveau).
• Account-API: Programmatische toegang via Azure Databricks account-API's.

Identiteiten

Regels kunnen zich richten op verschillende identiteitstypen. Voor de toegangstypen Apps-runtime en Lakebase-runtime is de enige ondersteunde optie Alle gebruikers en service-principals.

In het beleid op accountniveau is de enige ondersteunde optie Alle gebruikers en service-principals.

• Alle gebruikers en service-principals: zowel menselijke gebruikers als automatisering.
• Alle gebruikers: alleen menselijke gebruikers.
• Alle service-principals: alleen Automation-identiteiten.
• Geselecteerde identiteiten: specifieke gebruikers of service-principals.

Evaluatie van regels

• Standaard weigeren: in de beperkte modus wordt de toegang geweigerd, tenzij dit expliciet is toegestaan.
• Weigeren voordat toestaan: met regels voor weigeren kunt u uitzonderingen voor uw regels voor toestaan definiëren.
• Standaardbeleid op werkruimteniveau: elk account heeft een standaardbeleid voor inkomend verkeer op werkruimteniveau toegepast op alle in aanmerking komende werkruimten zonder expliciete beleidstoewijzing.

Handhavingsmodi

Met contextgebaseerd ingangsbeleid zijn twee modi mogelijk:

• Afgedwongen voor alle producten: Azure Databricks past actief regels toe en blokkeert aanvragen die in strijd zijn met deze regels.
• Dry-uitvoeringsmodus voor alle producten: Azure Databricks registreert schendingen, maar blokkeert geen aanvragen. Gebruik deze modus om beleidsimpact te evalueren voordat u deze afdwingt.

Databricks raadt aan om te beginnen in de dry run-modus om de impact van het beleid te observeren voordat het wordt overgezet naar 'gehandhaafd'.

Auditing

Geweigerde of drooguitvoeringsaanvragen worden vastgelegd in de system.access.inbound_network systeemtabel. Als u geen toegang hebt tot systeemtabellen, kan een metastore-beheerder u machtigingen verlenen. Zie Verleen toegang tot systeemtabellen.

Elke logboekvermelding omvat:

• Gebeurtenistijd
• Werkruimte-id
• Regellabel (van de regel die de aanvraag heeft geweigerd)
• Aanvraagtype
• Identiteit
• Netwerkbron
• Toegangstype (GEWEIGERD of DRY_RUN_DENIAL)

Weigeringen van het accountniveaubeleid worden geregistreerd wanneer workspace_id is ingesteld op 0.

Voer een query uit op deze logboeken om te controleren of uw regels werken zoals verwacht en om onverwachte toegangspogingen te ondervangen.

Relatie met andere controles

• Ip-toegangslijsten voor werkruimten: geëvalueerd samen met het contextgebaseerde toegangsbeleid voor inkomend verkeer met behulp van een logische AND, zonder strikte reeks tussen de twee. Een aanvraag is alleen toegestaan als zowel de IP-toegangslijst als het toegangsbeleid voor inkomend verkeer dit toestaat. IP-toegangslijsten voor werkruimten kunnen de toegang verder beperken, maar kunnen deze niet breder maken.
• Serverloze egress-controle: vormt een aanvulling op binnenkomende beleidsmaatregelen door het uitgaande netwerkverkeer van serverloze computing te beheren. Zie Netwerkbeleid beheren.
• Toegang tussen werkruimten: Bepaalt welke bronwerkruimten toegang hebben tot een werkruimte via serverless-verkeer, naast de controles voor netwerkbronnen en identiteit op deze pagina. Zie Toegang tussen werkruimten.
• IP-toegangslijsten voor OpenSharing-ontvangers: Contextgebaseerd inkomend verkeer is niet van toepassing op IP-toegangslijsten voor OpenSharing-ontvangers. Dit zijn aparte controles voor open ontvangers die aanbieders per ontvanger configureren. Zie Toegang voor Open Sharing-ontvangers beperken met IP-toegangslijsten (Databricks-naar-Open Sharing).

• Front-end privéconnectiviteit: Voor werkruimtebeleid en een bepaald geregistreerd eindpunt zijn eindpunten toegestaan in zowel contextgebaseerd inkomend verkeer als het databricks_ui_api privé-eindpunt. Als het contextgebaseerde ingangsbeleid van de werkruimte echter een weigerregel heeft die alle databricks_ui_api eindpunten weigert, dan kan geen enkel databricks_ui_api eindpunt toegang krijgen tot Azure Databricks. Zie Configureer inbound Private Link voor werkruimtes.
• Schakeloptie Voor openbare netwerktoegang toestaan: wanneer openbare netwerktoegang is ingeschakeld, worden IP-toegangslijsten voor werkruimten geëvalueerd. Anders wordt al het openbare inkomende verkeer geblokkeerd en worden de beleidsregels voor openbaar inkomend verkeer van de werkruimte niet geëvalueerd.

Beheer op context gebaseerd ingressbeleid

Configureer en voeg beleidsregels toe op het niveau dat overeenkomt met de resource die je wilt beschermen:

Om openbare en privéregels te configureren in het beleid op accountniveau dat resources op accountniveau beschermt, raadpleegt u Contextgebaseerde ingress-beleidsregels voor accounts beheren.

API en Terraform

Naast de accountconsole kun je contextgebaseerde ingress-beleidsregels programmatisch beheren:

• REST API: Gebruik de Azure Databricks REST API om netwerkbeleid te beheren.
• Terraform: Gebruik de Azure Databricks Terraform-provider om ingress-beleidsregels als infrastructuur als code te beheren.

Beste praktijken

• Begin met de droogloopmodus om gevolgen te observeren zonder de toegang te verbreken.
• Gebruik waar mogelijk identiteitsgebaseerde regels voor SaaS-clients die van IP-adres wisselen.
• Pas eerst regels voor weigeren toe op bevoegde service-principals om het betrokken gebied te beperken.
• Houd beleidsnamen helder en consistent.

Availability