Procedure consigliate per le applicazioni Databricks

Questa pagina elenca le procedure consigliate importanti per lo sviluppo e l'esecuzione di App Databricks. Queste linee guida riguardano i requisiti di sicurezza, prestazioni e piattaforma.

Procedure consigliate generali

• Usare le funzionalità native di Azure Databricks per l'elaborazione dei dati. Il calcolo delle app è ottimizzato per il rendering dell'interfaccia utente. Utilizzare Databricks SQL per query e set di dati, Processi Lakeflow per l'elaborazione batch e Model Serving per carichi di lavoro di inferenza per l'intelligenza artificiale. Scaricare un'elaborazione intensiva di dati su questi servizi per evitare problemi di prestazioni. Testare l'app in condizioni di carico previste per verificare che soddisfi i requisiti.

• Implementare la gestione elegante dell'arresto. L'app deve essere arrestata entro 15 secondi dopo che riceve un SIGTERM segnale o termina forzatamente con SIGKILL.

• Evitare operazioni con privilegi. Le applicazioni vengono eseguite come utenti senza privilegi e non possono eseguire azioni che richiedono autorizzazioni elevate, ad esempio l'accesso root. Non è possibile installare pacchetti a livello di sistema usando gestioni pacchetti come apt-get, yumo apk. Usare invece pacchetti Python da PyPI o pacchetti Node.js da npm per gestire le dipendenze dell'app.

• Informazioni sulla rete gestita dalla piattaforma. Le richieste vengono inoltrate tramite un proxy inverso, quindi l'app non può dipendere dall'origine delle richieste. Azure Databricks gestisce la terminazione TLS e richiede che le app supportino il testo non crittografato HTTP/2 (H2C). Non implementare la gestione TLS personalizzata.

• Effettuare il binding all'host e alla porta corretti. L'app deve ascoltare su 0.0.0.0 e usare la porta specificata nella variabile d'ambiente DATABRICKS_APP_PORT. Per informazioni dettagliate, vedere variabili di ambiente .

• Ridurre al minimo il tempo di avvio del contenitore. Mantenere la logica di inizializzazione leggera per ridurre la latenza di avvio a freddo. Evitare operazioni di blocco come le installazioni di dipendenze di grandi dimensioni o le chiamate API esterne durante l'avvio. Caricare risorse pesanti solo quando necessario.

• Accedere a stdout e stderr. Azure Databricks acquisisce i log dai flussi di output e di errore standard. Usare questi elementi per tutte le registrazioni per assicurarsi che i log siano visibili nell'interfaccia utente di Azure Databricks. Evitare di scrivere log nei file locali.

• Gestire correttamente gli errori imprevisti. Implementare la gestione globale delle eccezioni per evitare crash causati da errori non gestiti. Restituire risposte di errore HTTP appropriate senza esporre tracce dello stack o dati sensibili.

• Aggiungere le versioni delle dipendenze. Usare numeri di versione esatti nel requirements.txt file per garantire ambienti coerenti tra le compilazioni. Evitare di usare versioni non bloccate o più recenti dei pacchetti.

• Convalidare e sanificare l'input dell'utente. Convalidare sempre i dati in ingresso e sanitizzarli per evitare attacchi di tipo injection o input in formato non valido, anche nelle applicazioni interne.

• Usare la memorizzazione nella cache in memoria per operazioni costose. Memorizzare nella cache i dati usati di frequente, ad esempio i risultati delle query o le risposte api, per ridurre la latenza ed evitare l'elaborazione ridondante. Usare functools.lru_cache, cachetools o librerie simili e gestire attentamente l'uso delle cache nelle app multiutente.

• Usare i modelli di richiesta asincroni per le operazioni a esecuzione prolungata. Evitare richieste sincrone che attendono il completamento delle operazioni, che possono andare in timeout. Eseguire invece una richiesta iniziale per avviare l'operazione, quindi interrogare periodicamente lo stato della risorsa o l'endpoint per controllare lo stato di completamento.

Procedure consigliate per la sicurezza

• Seguire il principio dei privilegi minimi. Concedere solo le autorizzazioni necessarie per ogni utente o gruppo. Usare CAN USE invece di CAN MANAGE a meno che non sia necessario il controllo completo. Vedere Procedure consigliate per le autorizzazioni.

• Scegliere con attenzione i metodi di autenticazione. Usare i principali di servizio quando l'accesso ai dati e alle risorse è lo stesso per tutti gli utenti dell'app. Implementare l'autenticazione utente solo nelle aree di lavoro che includono autori di app attendibili e codice dell'app sottoposto a revisione tra pari, quando è necessario che l'app rispetti i permessi dell'utente che la richiama.

• Usare entità servizio dedicate per ogni app. Non condividere le credenziali dell'entità servizio tra app o utenti. Concedere solo le autorizzazioni minime necessarie, ad esempio CAN USE o CAN QUERY. Aggiornare le credenziali del principale del servizio quando gli sviluppatori di app lasciano l'organizzazione. Vedere Gestire l'accesso delle app alle risorse.

• Isolare gli ambienti dell'app. Usare aree di lavoro diverse per separare le app di sviluppo, gestione temporanea e produzione. In questo modo si impedisce l'accesso accidentale ai dati di produzione durante lo sviluppo e il test.

• Accedere ai dati tramite il calcolo appropriato. Non configurare l'app per accedere o elaborare direttamente i dati. Usare i warehouse SQL per le query, la gestione dei modelli per l'inferenza di intelligenza artificiale e i processi Lakeflow per l'elaborazione batch.

• Gestire i segreti. Non esporre mai i valori segreti grezzi nelle variabili di ambiente. Usare valueFrom nella configurazione dell'app e ruotare regolarmente i segreti, soprattutto quando i ruoli del team cambiano. Vedere Procedure consigliate.

• Ridurre al minimo gli ambiti e registrare le azioni dell'utente. Quando si usa l'autorizzazione utente, richiedere solo gli ambiti necessari all'app e registrare tutte le azioni utente con record di controllo strutturati. Vedere Procedure consigliate per l'autorizzazione utente.

• Limitare l'accesso alla rete in uscita. Consenti solo i domini necessari per l'app, ad esempio repository di pacchetti e API esterne. Usare la modalità dry-run e i log denial per convalidare la configurazione. Vedere Procedure consigliate per la configurazione dei criteri di rete.

• Seguire le procedure di codifica sicure. Parametrizzare le query SQL per evitare attacchi injection e applicare linee guida generali per lo sviluppo sicuro, ad esempio la convalida dell'input e la gestione degli errori. Vedere API di esecuzione delle istruzioni: eseguire SQL nei warehouse.

• Monitorare l'attività sospetta. Esaminare regolarmente i log di controllo per individuare modelli di accesso insoliti o azioni non autorizzate. Configurare gli avvisi per gli eventi di sicurezza critici.