Controllo di ingresso basato sul contesto

Questa pagina offre una panoramica del controllo di ingresso basato sul contesto, inclusi i suoi concetti fondamentali, le modalità di applicazione, l'audit e come interagisce con altri controlli di rete. Per configurare le policy, vedi Gestire le policy di ingresso basate sul contesto. Per il controllo in uscita serverless, vedere Che cos'è il controllo in uscita serverless?.

Panoramica del controllo di accesso basato sul contesto

Il controllo dell'ingresso basato sul contesto funziona insieme agli elenchi di accesso IP e alla connettività privata front-end per consentire agli amministratori dell'account di impostare regole di autorizzazione e negazione che combinano chi effettua la chiamata, da dove la effettua e che cosa può raggiungere in Azure Databricks. Ciò garantisce che solo le combinazioni attendibili di identità, tipo di richiesta e origine di rete possano raggiungere l'area di lavoro. Il controllo di ingresso basato sul contesto viene configurato a livello di account. Un singolo criterio può gestire più aree di lavoro.

Usando l'ingresso basato sul contesto, è possibile:

• Arrestare l'accesso da reti non attendibili richiedendo un secondo fattore, un'origine di rete attendibile, oltre alle credenziali.
• Consentire l'accesso ai client SaaS senza IP di uscita stabili basandosi sull'identità anziché sugli intervalli IP.
• Limitare l'accesso consentendo a origini meno attendibili di usare solo determinati ambiti, ad esempio le API Azure Databricks o l'interfaccia utente dell'area di lavoro.
• Proteggere l'automazione con privilegi: vincolare le entità servizio di alto valore solo alle reti ad alta attendibilità.
• Controlla in modo efficace: acquisire log di rifiuto dettagliati nelle tabelle di sistema del catalogo Unity per monitorare le richieste bloccate.

Policy a livello di spazio di lavoro rispetto a quelle a livello di account

Il controllo di ingresso basato sul contesto utilizza due tipi di politiche. Le policy a livello di spazio di lavoro regolano l'accesso agli spazi di lavoro. Le policy a livello di account regolano l'accesso alle risorse a livello di account, come la console dell'account e il Genie One a livello di account.

Le politiche a livello di account sono in Beta. Per iniziare, abilita Context-Based Ingress: Account Policy.

Concetti di base relativi al controllo dell'ingresso basato sul contesto

Origini di rete

Un'origine di rete definisce l'origine delle richieste. I tipi supportati includono:

Criteri di accesso pubblico:

• Tutti gli INDIRIZZI IP pubblici: qualsiasi origine Internet pubblica.
• Indirizzi IP selezionati: indirizzi IPv4 specifici o intervalli CIDR.
• Piattaforme partner (Beta): IP che le app di terze parti (Power BI, Tableau Cloud e piattaforma dbt) utilizzano per connettersi ad Azure Databricks. Azure Databricks gestisce e aggiorna automaticamente questi elenchi IP.

Criteri di accesso privato:

• Tutti gli endpoint privati registrati: qualsiasi endpoint privato registrato nell'account.
• Endpoint privati selezionati: endpoint privati registrati specifici nell'account.

• Azure workspace collegamento privato: Nello spazio di lavoro la policy nega solo le regole. Nega l'accesso a tutti databricks_ui_api gli endpoint.
• Accesso privato: nella politica dello spazio di lavoro nega solo le regole. Nega l'accesso a tutti i databricks_ui_api e agli endpoint registrati.

Per utilizzare politiche di ingresso basate sul contesto per la connettività privata in entrata, un amministratore dell'account deve attivare Context-Based Ingress: Workspace Private Access Policies dalla pagina delle anteprime della console account. Vedi Gestire le anteprime a livello di account.

Accesso tra workspace (Beta): Controlla quali workspace di origine possono raggiungere questo spazio di lavoro attraverso il traffico serverless, utilizzando le stesse identità e regole di autorizzazione e negazione previste per le altre fonti di rete.

• Spazi di lavoro selezionati: Solo gli spazi di lavoro di cui indichi ID.

Puoi anche lasciare questo criterio in modalità di compatibilità, nel qual caso non regola il traffico in ingresso tra aree di lavoro e si applicano i controlli di rete preesistenti dell'area di lavoro. Per configurare l'accesso tra aree di lavoro sia sul lato in entrata che su quello in uscita e per consultarne le limitazioni, vedi Accesso tra aree di lavoro.

Tipi di accesso

Le regole si applicano a ambiti di richiesta in ingresso diversi. Ogni ambito rappresenta una categoria di richieste in ingresso che è possibile consentire o negare:

Tipi di accesso ai criteri a livello di spazio di lavoro:

• Interfaccia utente dell'area di lavoro: accesso browser all'area di lavoro.
• API: accesso a livello di codice tramite API Azure Databricks, inclusi gli endpoint SQL (JDBC/ODBC). Puoi puntare a uno qualsiasi dei seguenti elementi:
  • Tutte le API.
  • Un ambito API specifico, usando IN. Ad esempio, puoi specificare applicazioni, dashboard o distribuzione di modelli.
  • Tutti gli ambiti API tranne quelli selezionati, usando NOT IN.
• Runtime delle app: consente o nega l'accesso alle distribuzioni di Databricks Apps. Vedere App di Databricks. Per questo tipo di accesso è supportata solo l'opzione Tutti gli utenti e i principali del servizio.

• Runtime di Lakebase: connessioni alle istanze del database Lakebase. Vedere Lakebase. Per questo tipo di accesso è supportata solo l'opzione Tutti gli utenti e i principali del servizio.

Tipi di accesso alle policy a livello di account (Beta):

• Interfaccia utente dell'account: accesso del browser alle risorse a livello di account (ad esempio, la console dell'account e Genie One a livello di account).
• API dell'account: accesso programmatico tramite le API dell'account di Azure Databricks.

Identità

Le regole possono essere destinate a tipi di identità diversi. Per i tipi di accesso runtime Apps e runtime Lakebase, l'unica opzione supportata è Tutti gli utenti e le entità servizio.

Nel criterio a livello di account, l'unica opzione supportata è Tutti gli utenti e le entità di servizio.

• Tutti gli utenti e le entità servizio: utenti umani e automazione.
• Tutti gli utenti: solo utenti umani.
• Tutte le entità principale del servizio: solo per le identità di automazione.
• Identità selezionate: utenti specifici o entità servizio.

Valutazione delle regole

• Nega predefinita: in modalità con restrizioni, l'accesso viene negato a meno che non sia consentito in modo esplicito.
• Nega prima di consentire: le regole di negazione consentono di definire le eccezioni alle regole di autorizzazione.
• Criterio a livello di area di lavoro predefinito: ogni account ha un criterio di ingresso predefinito a livello di area di lavoro applicato a tutte le aree di lavoro idonee senza un'assegnazione esplicita dei criteri.

Modalità di imposizione

I criteri di ingresso basati sul contesto consentono due modalità:

• Applicato a tutti i prodotti: Azure Databricks applica attivamente le regole e blocca le richieste che violano tali regole.
• Modalità di prova per tutti i prodotti: Azure Databricks registra le violazioni, ma non blocca le richieste. Usare questa modalità per valutare l'impatto dei criteri prima dell'applicazione.

Databricks raccomanda di iniziare in modalità di simulazione per osservare l'impatto del criterio prima di impostarlo come applicato.

Auditing

Le richieste negate o di prova vengono registrate nella tabella di sistema system.access.inbound_network. Se non si ha accesso alle tabelle di sistema, un amministratore del metastore può concedere le autorizzazioni. Vedere Concedere l'accesso alle tabelle di sistema.

Ogni voce di log include:

• Orario evento
• ID area di lavoro
• Etichetta della regola (della regola che ha negato la richiesta)
• Tipo di richiesta
• Identità
• Origine di rete
• Tipo di accesso (NEGATO o DRY_RUN_DENIAL)

Eseguire query su questi log per verificare che le regole funzionino come previsto e rilevare tentativi di accesso imprevisti.

Relazione con altri controlli

• Elenchi di accesso IP dell'area di lavoro: valutati insieme ai criteri di ingresso basati sul contesto usando un AND logico, senza una sequenza rigorosa tra i due. Una richiesta è consentita solo se sia l'elenco di accesso IP che i criteri di ingresso lo consentono. Gli elenchi di accesso IP dell'area di lavoro possono limitare ulteriormente l'accesso, ma non possono estenderlo.
• Controllo in uscita serverless: integra i criteri di ingresso controllando il traffico di rete in uscita dal calcolo serverless. Vedere Gestire i criteri di rete.
• Accesso tra workspace: controlla quali workspace di origine possono raggiungere un workspace mediante traffico serverless, oltre ai controlli relativi all'origine della rete e all'identità presenti in questa pagina. Vedere Accesso tra aree di lavoro.
• Liste di accesso IP dei destinatari OpenSharing: L'ingresso basato sul contesto non si applica alle liste di accesso IP dei destinatari OpenSharing. Questi sono un controllo separato per i destinatari aperti che i fornitori configurano per ogni destinatario. Vedere Limitare l'accesso dei destinatari OpenSharing usando gli elenchi di accesso IP (condivisione da Databricks a Open).

• Connettività privata del front-end: per i criteri dell'area di lavoro e per uno specifico endpoint registrato, sono consentiti gli endpoint autorizzati nell'accesso in ingresso basato sul contesto o nell'endpoint privato databricks_ui_api. Tuttavia, se la policy di ingresso basata sul contesto dello spazio ha una regola di negazione che nega tutti databricks_ui_api gli endpoint, nessun databricks_ui_api endpoint può accedere ad Azure Databricks. Vedi Configura inbound collegamento privato per gli spazi di lavoro.
• Interruttore Consenti accesso alla rete pubblica: quando Consenti accesso alla rete pubblica è Abilitato, vengono valutati gli elenchi di accesso IP dell'area di lavoro. In caso contrario, tutto il traffico pubblico in ingresso viene bloccato e i criteri di accesso pubblico in ingresso dell'area di lavoro non vengono valutati.

Gestire le politiche di ingresso basate sul contesto

Configura e allega le policy al livello che corrisponde alla risorsa che vuoi proteggere:

Per configurare regole pubbliche e private sulla policy a livello di account che protegge le risorse a livello account, vedi Gestire le politiche di ingresso basate sul contesto dell'account.

API e Terraform

Oltre alla console dell'account, puoi gestire in modo programmativo le policy di ingresso basate sul contesto:

• API REST: Usa l'API REST di Azure Databricks per gestire le policy di rete.
• Terraform: Usa il provider Azure Databricks Terraform per gestire le politiche di ingresso come infrastruttura come codice.

Procedure consigliate

• Iniziare con la modalità di esecuzione secca per osservare gli impatti senza interrompere l'accesso.
• Usare le regole basate sull'identità, se possibile per i client SaaS che ruotano gli indirizzi IP.
• Applicare prima le regole di negazione alle entità servizio con privilegi per limitare l'area interessata.
• Mantenere i nomi dei criteri chiari e coerenti.

Availability