Kontextbaserad ingresskontroll

Denna sida ger en översikt över kontextbaserad ingresskontroll, inklusive dess kärnkoncept, tillsynsmetoder, granskning och hur den interagerar med andra nätverkskontroller. För att konfigurera policyer, se Hantera kontextbaserade ingångspolicys. Information om serverlös utgående kontroll finns i Vad är serverlös utgående kontroll?.

Översikt över kontextbaserad ingresskontroll

Kontextbaserad ingresskontroll fungerar tillsammans med IP-åtkomstlistor och privata klientdelsanslutningar så att kontoadministratörer kan ange tillåtna och neka regler som kombinerar who anropar, från var de anropar och vad de kan nå i Azure Databricks. Detta säkerställer att endast betrodda kombinationer av identitet, typ av begäran och nätverkskälla kan nå din arbetsyta. Kontextbaserad ingresskontroll konfigureras på kontonivå. En enskild princip kan styra flera arbetsytor.

Med hjälp av kontextbaserad ingress kan du:

• Stoppa åtkomsten från ej betrodda nätverk genom att kräva en andra faktor, en betrodd nätverkskälla, utöver autentiseringsuppgifter.
• Tillåt åtkomst för SaaS-klienter utan stabila utgående IP-adresser genom att ange identitet i stället för IP-intervall.
• Begränsa åtkomsten genom att tillåta mindre betrodda källor att endast använda vissa omfång som Azure Databricks API:er eller arbetsytans användargränssnitt.
• Skydda privilegierad automatisering: Begränsa värdefulla tjänsthuvudnamn till endast betrodda nätverk.
• Granska effektivt: Samla detaljerade loggar över nekade begäranden i Unity Catalogs systemtabeller för att övervaka blockerade förfrågningar.

Policyer på arbetsytenivå jämfört med policys på kontonivå

Kontextbaserad ingångskontroll använder två typer av policyer. Arbetsytsnivåpolicyer styr åtkomsten till arbetsytor. Kontonivåpolicyer styr åtkomst till kontonivåresurser, såsom kontokonsolen och kontonivåns Genie One.

Kontonivåpolicyer är i beta. För att komma igång, aktivera Context-Based Ingress: Account Policy.

Grundläggande begrepp för kontextbaserad ingresskontroll

Nätverkskällor

En nätverkskälla definierar ursprunget för begäranden. Exempel på typer som stöds är:

Offentlig åtkomstprincip:

• Alla offentliga IP-adresser: Alla offentliga Internetkällor.
• Valda IP-adresser: Specifika IPv4-adresser eller CIDR-intervall.
• Partnerplattformar (Beta): IP-adresser som tredjepartsappar (Power BI,Tableau Cloud och dbt-plattformen) använder för att ansluta till Azure Databricks. Azure Databricks hanterar och uppdaterar dessa IP-listor automatiskt.

Privat åtkomstpolicy (Beta):

• Alla registrerade privata slutpunkter: Alla registrerade privata slutpunkter i kontot.
• Valda privata slutpunkter: Specifika registrerade privata slutpunkter i kontot.

• Azure workspace Private Link: Endast regler för neka i arbetsområdets policy. Nekar tillgång till alla databricks_ui_api slutpunkter.
• All privat åtkomst: Endast i neka-regler för arbetsytepolicy. Nekar åtkomst till alla databricks_ui_api och registrerade ändpunkter.

Åtkomst mellan arbetsytor (Beta): Styr vilka källarbetsytor som kan nå den här arbetsytan via serverlös trafik, med samma identiteter och tillåtelse- och nekanderegler som andra nätverkskällor.

• Utvalda arbetsytor: Endast de arbetsytor vars ID du listar.

Du kan också låta denna policy vara i kompatibilitetsläge, i vilket fall den inte styr ingång mellan arbetsområden och arbetsytans redan existerande nätverkskontroller gäller. För att konfigurera åtkomst över arbetsytor på både ingångs- och utgångssidan, samt för att granska dess begränsningar, se åtkomst över arbetsytan.

Åtkomsttyper

Regler gäller för olika omfång för inkommande begäranden. Varje omfång representerar en kategori av inkommande begäranden som du kan tillåta eller neka:

Principåtkomsttyper på arbetsytenivå:

• Användargränssnitt för arbetsyta: Webbläsaråtkomst till arbetsytan.
• API: Programmatisk åtkomst via Azure Databricks API:er, inklusive SQL-slutpunkter (JDBC/ODBC). Du kan rikta in dig på något av följande:
  • Alla API:er.
  • Ett specifikt API-omfång, med hjälp av IN. Till exempel kan du specificera appar, instrumentpanel eller modellservering.
  • Alla API-omfattningar utom de valda, med NOT IN.
• Appkörning: Tillåt eller neka åtkomst till Databricks-appdriftsättningar. Se Databricks-appar. Endast alternativet Alla användare och tjänstens huvudnamnsidentitet stöds för den här åtkomsttypen.

• Lakebase-körningsmiljö: Anslutningar till Lakebase-databasinstanser. Se Lakebase. Endast alternativet Alla användare och tjänstens huvudnamnsidentitet stöds för den här åtkomsttypen.

Kontonivåpolicyåtkomsttyper (Beta):

• Kontogränssnitt: Webbläsaråtkomst till resurser på kontonivå (till exempel kontokonsolen och Genie One på kontonivå).
• Konto-API: Programmatisk åtkomst via Azure Databricks konto-API:er.

Identiteter

Regler kan rikta in sig på olika identitetstyper. För åtkomsttyperna Apps runtime och Lakebase runtime är det enda alternativ som stöds Alla användare och tjänsthuvudnamn.

I policyn på kontonivå är det enda alternativ som stöds Alla användare och tjänsthuvudnamn.

• Alla användare och tjänsthuvudprinciper: Både mänskliga användare och automatiserade processer.
• Alla användare: Endast mänskliga användare.
• Alla tjänstens huvudenheter: Endast Automatiseringsidentiteter.
• Valda identiteter: Specifika användare eller tjänstens huvudnamn.

Regelutvärdering

• Standardnekelse: I begränsat läge nekas åtkomst om det inte uttryckligen tillåts.
• Neka innan det tillåts: Neka regler gör att du kan definiera undantag till dina tillåtna regler.
• Standardprincip på arbetsytenivå: Varje konto har en standardprincip för ingress på arbetsytenivå som tillämpas på alla berättigade arbetsytor utan en explicit principtilldelning.

Verkställningslägen

Kontextbaserade ingressprinciper aktiverar två lägen:

• Tvingande för alla produkter: Azure Databricks tillämpar aktivt regler och blockerar begäranden som bryter mot dem.
• Dry-körningsläge för alla produkter: Azure Databricks loggar överträdelser men blockerar inte begäranden. Använd det här läget för att utvärdera princippåverkan innan du framtvingar detta.

Databricks rekommenderar att du börjar i testläge för att se vilken påverkan policyn har innan du byter den till tvingande läge.

Auditing

Begäranden om nekad eller torrkörning loggas i systemtabellen system.access.inbound_network . Om du inte har åtkomst till systemtabeller kan en metaarkivadministratör ge dig behörighet. Se Bevilja åtkomst till systemtabeller.

Varje loggpost innehåller:

• Händelsetid
• Arbetsplats-ID
• Regeletikett (för regeln som nekade begäran)
• Typ av begäran
• Identitet
• Nätverkskälla
• Åtkomsttyp (NEKAD eller DRY_RUN_DENIAL)

Sök i dessa loggar för att kontrollera att dina regler fungerar som förväntat och för att upptäcka oväntade åtkomstförsök.

Relation till andra kontroller

• IP-åtkomstlistor för arbetsytan: Utvärderas tillsammans med den kontextbaserade ingressprincipen med hjälp av en logisk AND, utan någon strikt sekvens mellan de två. En begäran tillåts endast om både IP-åtkomstlistan och ingressprincipen tillåter det. IP-åtkomstlistor för arbetsytan kan begränsa åtkomsten ytterligare men kan inte bredda den.
• Serverlös utgående kontroll: Kompletterar ingressprinciper genom att styra utgående nätverkstrafik från serverlös beräkning. Se Hantera nätverksprinciper.
• Åtkomst mellan arbetsytor: Styr vilka källarbetsytor som kan nå en arbetsyta via serverlös trafik, utöver kontrollerna för nätverkskällor och identitet på den här sidan. Se åtkomst mellan arbetsytor.
• OpenSharing mottagarens IP-åtkomstlistor: Kontextbaserad ingress gäller inte för OpenSharing mottagares IP-åtkomstlistor. Dessa är en separat kontroll för öppna mottagare som leverantörer konfigurerar per mottagare. Se Begränsa openSharing-mottagaråtkomst med hjälp av IP-åtkomstlistor (Databricks-till-Open-delning).

• Privat anslutning för klientdelen: För arbetsytepolicyer och en viss registrerad slutpunkt tillåts slutpunkter som är tillåtna antingen i kontextbaserad inkommande trafik eller i den databricks_ui_api privata slutpunkten. Men om arbetsområdets kontextbaserade ingångspolicy har en nekarregel som nekar alla databricks_ui_api endpoints, kan ingen databricks_ui_api endpoint komma åt Azure Databricks. Se Konfigurera inkommande Private Link för arbetsområden.
• Tillåt åtkomst till offentligt nätverk växlingsknappen: När Tillåt åtkomst till offentligt nätverk är aktiverat utvärderas arbetsytans IP-åtkomstlistor. Annars blockeras alla offentliga ingresser och offentliga ingressprinciper för arbetsytan utvärderas inte.

Hantera kontextbaserade ingångspolicys

Konfigurera och bifoga policyer på den nivå som matchar den resurs du vill skydda:

För att konfigurera publika och privata regler på kontonivåpolicyn som skyddar kontonivåresurser, se Hantera kontokontextbaserade ingresspolicys.

API och Terraform

Utöver kontokonsolen kan du hantera kontextbaserade ingångspolicys programmatiskt:

• REST API: Använd Azure Databricks REST API för att hantera nätverkspolicys.
• Terraform: Använd Azure Databricks Terraform-leverantör för att hantera ingresspolicys som infrastruktur som kod.

Metodtips

• Börja med torrt körningsläge för att observera påverkan utan att bryta åtkomsten.
• Använd identitetsbaserade regler där det är möjligt för SaaS-klienter som roterar IP-adresser.
• Tillämpa nekanderegler på privilegierade tjänsthuvudnamn först för att begränsa det område som påverkas.
• Håll principnamnen tydliga och konsekventa.

Tillgänglighet