Rilevamento degli attacchi basati su credenziali su Databricks

In Databricks, sappiamo che i tuoi dati sono il tuo bene più prezioso. Databricks ha lavorato con migliaia di clienti per distribuire in modo sicuro la Databricks Data + AI Platform con le funzionalità appropriate per soddisfare i loro requisiti di sicurezza, privacy e conformità.

Il cyberattacco moderno non inizia sempre con un perimetro violato; inizia con un login valido. Una volta che un utente malintenzionato acquisisce un cookie di sessione trafugato, un personal access token (PAT) o le credenziali di un service-principal, la violazione iniziale è già completa. Da quel momento in poi, il loro unico obiettivo è mimetizzarsi e operare sotto le spoglie del tuo utente o servizio compromesso.

Ma avere una chiave non significa conoscere l'edificio. Immagina un intruso che striscia un badge per entrare in un ufficio sicuro. Può aver superato le porte girevoli, ma deve comunque affrontare la guardia di sicurezza, indovinare a quali piani ha accesso e capire dove si trova il caveau. Poù un attaccante non possiede il contesto profondo e localizzato dei tuoi veri dipendenti, il suo comportamento finirà per tradirlo. Individuare queste irregolarità à il modo in cui li catturi.

In questo post, esaminiamo come si svolge un attacco basato sulle credenziali sulla piattaforma Databricks, come rilevare il cambiamento nel comportamento di un'identità utilizzando i log di audit dettagliati di Databricks e Genie, come rispondere una volta confermata una compromissione e quali controlli limitano ciò che una credenziale rubata può fare in primo luogo.

Un modello per seguire gli attacchi guidati dalle credenziali

Quando stabiliscono l'accesso tramite credenziali legittime, gli attaccanti, proprio come gli esperti di sicurezza, comprendono anche che il loro accesso può essere revocato in qualsiasi momento se si discostano troppo dal comportamento previsto per l'identità. Gli attaccanti si affidano a sequenze di attacco non lineari, come la validazione di un set di credenziali per mappare il tuo ambiente, per poi recuperare un set di credenziali diverso per rientrare attraverso una nuova identità o workspace che non presenta attività di ricognizione associate. Inoltre, gli attaccanti possono raccogliere informazioni senza stabilire una persistenza o trovare il modo di rientrare nella tua piattaforma Databricks prima di concludere i loro obiettivi.

Come appare nella pratica

Considera un data engineer il cui personal access token viene copiato da un log di integrazione e distribuzione continua (CI/CD) configurato male. Nel giro di pochi minuti, il token viene utilizzato da un nuovo IP per elencare ambiti di segreti (secret scopes), cataloghi e repository in tutto il workspace, un'operazione che questo engineer non ha mai fatto. Viene letto un segreto contenente le credenziali di un service-principal. Un'ora dopo, quel service-principal, e non l'engineer, crea una funzione, si aggiunge a un gruppo di amministratori ed esporta una manciata di script di inizializzazione. Ognuno di questi eventi potrebbe passare per un normale utilizzo della piattaforma, ma presi insieme mostrano un'intrusione che si muove lungo la catena di attacco.

In Databricks, ci aspettiamo una sequenza di eventi non lineare in relazione agli attacchi basati sulle credenziali e utilizziamo questo modello per collegare i singoli eventi in un'unica indagine anziché considerarli eventi non correlati.

Le sei fasi di un attacco basato sulle credenziali

Quando gli attaccanti sfruttano credenziali compromesse in un ambiente Platform-as-a-Service (PaaS), come Databricks, la loro attività può essere raggruppata in sei fasi, sebbene raramente procedano in linea retta. Ciascuna fase descrive ciò che l'attaccante sta cercando di fare e cosa cercare nelle tabelle dei log di audit di Databricks. Considera questa guida come un punto di partenza e adattala all'automazione normale del tuo ambiente.

Nota: Gli eventi sono scritti come service_name.action_name, ad esempio secrets.getSecret.

1. L'attaccante ottiene l'accesso con credenziali valide

Il login in sé raramente appare insolito. Poù la credenziale è reale, l'autenticazione ha successo esattamente come farebbe per il proprietario legittimo. Tuttavia, ciò che l'identità fa nei minuti successivi all'accesso appare spesso molto diverso dalla sua normale attività, ed è proprio questo cambiamento che chi risponde può rilevare. Nell'esempio del data engineer, il token rubato si autentica con successo e l'unica differenza al momento del login è un IP di origine che l'engineer non ha mai utilizzato. L'attività che segue è ciò che risalta.

Obiettivo dell'attaccante: Accedere al workspace con credenziali valide, che si tratti di una sessione del browser trafugata, di un PAT riutilizzato o delle credenziali di un service-principal, e mimetizzarsi nell'attività che i controlli sono progettati per consentire.

Cosa cercare:

• Usa l'evento di autenticazione come punto di partenza per la tua timeline. Un semplice login raramente basta per generare un avviso, ma il suo user_identity, source_ip_address, user_agent, sessionId, request_id e workspace_id ti permettono di seguire cosa fa successivamente la credenziale.
• Segnala gli eventi accounts.tokenLogin che arrivano in rapida successione da un client sconosciuto e sono seguiti dall'uso dello stesso token da un IP di origine diverso. Questo pattern può indicare che qualcuno sta testando un token rubato, e requestParams.tokenId ti consente di collegare tali eventi allo stesso token.
• Segnala i token OAuth dei service-principal generati dalla rete prevista ma con uno user agent inatteso, specialmente quando l'attività da un nuovo IP di origine segue entro un minuto.

2. L'attaccante mappa l'ambiente

Successivamente, l'attaccante deve scoprire cosa può raggiungere la credenziale prima che l'accesso venga revocato. Di conseguenza, un'identità compromessa può passare dalla sua normale attività all'elenco di dati, segreti, codice e controlli di rete in pochi secondi. Questa ricognizione di solito copre diversi servizi contemporaneamente e si muove più velocemente di una persona che naviga nell'interfaccia utente. Nel nostro scenario, questa fase è la raffica di chiamate che elencano ambiti di segreti, cataloghi e repository pochi minuti dopo l'utilizzo del token, un'attività che l'engineer non ha mai eseguito prima.

Obiettivo dell'attaccante: Costruire una mappa dei dati accessibili, delle credenziali, dei repository e dei blocchi di sicurezza per pianificare un percorso più profondo nell'ambiente prima che l'accesso venga revocato.

Cosa cercare:

• Cerca una singola identità che effettui rapide chiamate di elenco sui piani del workspace e dell'account, come secrets.listScopes / listSecrets, unityCatalog.listMetastores / listCatalogs / listSchemas / listExternalLocations / listStorageCredentials, repos.listRepos e accountsManager.listWorkspaceConfigurations / listNetworkConfigurations / listStorageConfigurations a livello di account. Ad esempio, cinque o più API di individuazione distinte chiamate in un solo minuto difficilmente appartengono a una persona che naviga sulla piattaforma.
• Confronta l'attività con la baseline dell'identità. La prima enumerazione di segreti mai effettuata da un'identità consolidata, o una sessione SQL che passa da query di business a SHOW TABLES contro schemi di controllo degli accessi e di configurazione, è più significativa di un alto volume di chiamate. Quando la registrazione di audit dettagliata à abilitata, commandSubmit preserva la query in commandText.
• Includi le richieste fallite nella tua ricerca. Analizza la prima IpAccessDenied di un'identità, soprattutto quando segue accounts.oidcTokenAuthorization o si ripete tra i workspace. In quel caso, l'autorizzazione ha avuto successo ma la richiesta proveniva da una rete bloccata, che è spesso la prima registrazione di una credenziale riutilizzata da una posizione non attendibile.

3. L'attaccante raccoglie altre credenziali

La raccolta delle credenziali richiede solitamente diversi passaggi. L'attaccante elenca gli ambiti di segreti, elenca i segreti al loro interno e quindi legge quelli che sembrano utili. Il valore che recupera consente loro di ritornare come un'identità diversa, spesso con più privilegi. Per questo motivo, ogni segreto letto da un'identità sospetta merita di essere approfondito. Nell'esempio del data engineer, l'attaccante legge un segreto che contiene le credenziali di un service-principal. Da quel momento in poi, l'indagine deve seguire due identità: l'engineer e il service-principal.

Obiettivo dell'attaccante: Recuperare un token, una chiave API o un segreto di un service-principal che trasforma il punto d'appoggio iniziale in un accesso esteso all'intero ambiente sotto una nuova identità.

Cosa cercare:

• Attiva un avviso sulla progressione delle chiamate. secrets.listScopes da solo è comune e genera rumore. Tuttavia, listScopes seguito da listSecrets e poi da getSecret, ripetuto su più scope in rapida successione, indica un'attività di raccolta (harvesting). listSecrets registra lo scope e getSecret registra sia lo scope che la chiave.
• Metti in correlazione le letture negate con quelle riuscite in un secondo momento. Un getSecret negato su uno scope strettamente controllato, seguito da una lettura riuscita della stessa chiave o di una chiave correlata in uno scope meno ristretto, suggerisce che l'identità sta cercando una copia a cui può accedere.
• Monitora l'accesso lato compute oltre alle API dei segreti. Quando la registrazione di audit dettagliata è abilitata, gli eventi del notebook submitCommand e di Databricks SQL commandSubmit possono mostrare codice che richiama utilità di gestione dei segreti o esegue read_files() su percorsi che contengono credenziali. Tieni presente che il testo inviato mostra ciò che è stato eseguito, ma non conferma che sia stato restituito un valore.
• Collega ogni lettura di segreto a ciò che accade dopo, come un nuovo accounts.tokenLogin, un'attività di un service principal mai vista prima, un IP o uno user agent modificati, o chiamate generateTemporaryTableCredential / generateTemporaryVolumeCredential. Durante la risposta, ruota ogni credenziale che l'identità potrebbe aver raggiunto e verifica dove è stata usata ciascuna di esse, oltre a dove è stata archiviata.

4. L'avversario trova un percorso di esecuzione utilizzabile

Una volta stabilito l'accesso, gli avversari cercano un modo per eseguire il proprio codice. Su Databricks, questo avviene tipicamente tramite funzioni definite dall'utente (UDF) e processi (job). Una funzione può racchiudere un payload in un codice dall'aspetto ordinario che può essere richiamato ripetutamente, e un processo può eseguire quel codice secondo una pianificazione su risorse di calcolo diverse. Pertanto, la domanda chiave per il rilevamento è se un'identità ha iniziato a eseguire azioni che non aveva mai compiuto prima. Tornando al data engineer, un'ora dopo la lettura del segreto, il service principal crea una funzione. Poiché questa azione viene eseguita dal service principal anziché dall'engineer, una ricerca limitata esclusivamente all'attività dell'engineer non la rileverebbe.

Obiettivo dell'avversario: Stabilire un modo affidabile e riutilizzabile per eseguire payload, con un percorso alternativo nel caso in cui una via di calcolo venga bloccata.

Cosa cercare:

• Dai priorità agli eventi createFunction provenienti da un'identità, un IP o un catalogo senza uno storico di creazione di funzioni, specialmente quando ne compaiono diversi in un breve periodo. Laddove le definizioni di funzione siano disponibili, segnala il codice che esegue processi, valuta codice in modo dinamico, accede ai metadati delle istanze, apre connessioni di rete in uscita o scrive su cloud storage. Traccia inoltre i riferimenti tra le funzioni, poiché un wrapper apparentemente innocuo potrebbe chiamare una UDF a rischio più elevato. Nota che function_info in system.access.audit è mascherato tranne che per gli amministratori dell'account e databricks_pii_access, quindi abbina i dati di audit agli inventari delle funzioni.
• Traccia il percorso dei job per identità, IP e ID del job o dell'esecuzione. Una sequenza tipica è importNotebook, seguita da changeJobAcl, Jobs create, runNow e getRunOutput. Questi eventi preservano raramente il corpo del notebook, quindi mantieni le versioni dei notebook e le configurazioni dei job insieme ad essi. Un'attività ripetuta di importazione ed esecuzione da una singola origine costituisce un segnale più forte rispetto a ciascuna delle due azioni prese singolarmente.
• Cerca un'identità che cambia risorse di calcolo dopo un errore. Ad esempio, la creazione di un cluster non riuscita o submitRun seguita a breve da startWarehouse, o da un nuovo job su risorse di calcolo diverse, potrebbe indicare un avversario che sta aggirando un percorso bloccato. I codici di risposta e il breve intervallo tra gli eventi sono ciò che separa questa sequenza dagli errori di routine. Le risorse di calcolo serverless sono un'alternativa comune.

5. L'avversario stabilisce la persistenza

Una volta ottenuto un modo per eseguire il codice, gli avversari cercano di assicurarsi di poter tornare anche dopo la revoca della credenziale originale. I metodi di persistenza più comuni includono concessioni di accesso, token appena creati, modifiche all'appartenenza a gruppi e workspace e modifiche al piano di controllo. Il segnale più utile è una modifica sensibile effettuata da un'identità o da un contesto di esecuzione non familiari. Ad esempio, una modifica dei permessi effettuata dall'interno di un job merita più attenzione rispetto alla stessa modifica fatta da un amministratore nella console. Proseguendo nello scenario, il service principal si aggiunge a un gruppo di amministratori. Anche se il token dell'engineer viene revocato, quell'appartenenza al gruppo mantiene attivo l'accesso dell'avversario.

Obiettivo dell'avversario: Creare percorsi di accesso duraturi e indipendenti che sopravvivano alla revoca della credenziale compromessa.

Cosa cercare:

• Attiva avvisi su concessioni di permessi e identità provenienti da contesti inattesi, come putAcl su uno scope di segreti, updatePermissionAssignment, addPrincipalToGroup o setAdmin. Presta particolare attenzione quando un service principal concede l'accesso a un'altra identità, o quando si verificano più assegnazioni in un breve periodo.
• Tratta i tentativi di modifica dei controlli di sicurezza come ad alta gravità, anche quando falliscono. Questo include setSetting / deleteSetting, modifiche alle liste di accesso IP e createPrivateAccessSettings. Esamina la modifica richiesta, la risposta e l'origine prima di concludere se un controllo sia stato effettivamente bypassato. Esamina anche le modifiche ai gruppi SCIM provenienti da qualsiasi fonte diversa dall'IdP previsto.
• Segnala le chiamate generateDbToken provenienti da un'origine sconosciuta o effettuate durante l'esecuzione di un job. Ciascun token risultante è una credenziale separata che dovrà essere revocata.
• Fai attenzione ai carichi di lavoro che continuano autonomamente. Metti in correlazione gli eventi del piano di controllo con run_by, run_as e la finestra di esecuzione prevista. Se un job continua a modificare gruppi, permessi o impostazioni dopo che l'attività interattiva dell'avversario si è fermata, potrebbe mantenere l'accesso da solo. Conserva la definizione del job e gli artefatti prima di terminarlo.

6. L'avversario raccoglie i dati e ripulisce gli accessi

La raccolta di dati può limitarsi a poche esportazioni mirate e la pulizia può comportare molto più della semplice eliminazione di file. Fai attenzione a esportazioni mirate, richieste di credenziali temporanee, rimozione di strumenti di breve durata e comandi offuscati che rendono più difficile ricostruire l'attività. Ognuno di questi eventi può sembrare di routine, quindi la sequenza in cui avvengono conta più della singola esportazione o eliminazione. Infine, il service principal del nostro scenario esporta una manciata di script di inizializzazione. Da solo, si tratta di un'esportazione di modesta entità. Tuttavia, poiché segue una lettura di segreti e una nuova funzione dallo stesso service principal, dovrebbe essere investigata come parte della stessa intrusione.

Obiettivo dell'avversario: Prender i dati importanti ed eliminare gli strumenti più evidenti, lasciando attivi accessi più silenziosi.

Cosa cercare:

• Analizza il contesto di ogni esportazione anziché il numero di esportazioni. workspaceExport registra il percorso, il formato e se si è trattato di un download diretto. Dai priorità alle esportazioni effettuate da identità sconosciute, verso percorsi insoliti o in formati insoliti, provenienti da reti mai viste prima o che seguono l'accesso a segreti o una nuova esecuzione. Una piccola esportazione mirata di script di inizializzazione può divulgare più dati di un dump SOURCE massiccio.
• Conserva i record di oggetti di breve durata. Un createFunction seguito da un deleteFunction per la stessa funzione in una sessione, oppure un ciclo ripetuto di creazione, eliminazione e nuova creazione, potrebbe indicare un tentativo di rimuovere le prove. Conserva le definizioni e la tempistica prima di ripristinare qualsiasi cosa. Gli oggetti che sopravvivono ricevono spesso nomi più plausibili rispetto a quelli eliminati.
• Collega i picchi di credenziali temporanee e di lettura dei dati (generateTemporaryTableCredential, generateTemporaryVolumeCredential, Delta Sharing, letture da cloud storage) alla ricognizione precedente. I comandi codificati o scritti tramite script sono troppo comuni per generare un avviso da soli, quindi correlali con un user agent sconosciuto, una tempistica simile a quella di un'automazione, un accesso segreto o nuove funzioni.

Analisi di attacchi basati su credenziali con Genie

Utilizzando la catena di attacco basata su credenziali come guida, puoi indicare a Genie di gestire le fasi dell'attacco senza scrivere ogni query da zero. Ogni rilevamento in questo post si basa su dati di telemetria già disponibili. Databricks scrive l'attività del piano di controllo nella tabella di sistema system.access.audit.

Per iniziare, installa la Detection App, che aggiunge un agente Genie per la registrazione dei log di controllo di Databricks. Puoi utilizzarlo da Genie One in due modi:

• Fai domande con parole tue, ad esempio "Quali notebook ha esportato ieri user@example.com?" Genie scrive ed esegue il codice SQL per te.
• Usa i rilevamenti integrati. L'agente Genie della Detection App include oltre 30 rilevamenti, che vanno dall'uso improprio dei token alle assegnazioni di amministrazione. Chiedi "Chi ha creato i token di accesso personale la settimana scorsa?" e Genie eseguirà il rilevamento corrispondente invece di scrivere nuovo codice SQL. Assegna un obiettivo, come "Siamo stati compromessi negli ultimi 90 giorni?", e l'agente esaminerà i rilevamenti uno alla volta.

Tieni a mente due limiti. Innanzitutto, un risultato vuoto non significa che non sia successo nulla. L'evento potrebbe trovarsi al di fuori della finestra temporale oppure la registrazione dettagliata dei log di controllo potrebbe essere disattivata. In secondo luogo, i log di controllo registrano che qualcosa è cambiato e chi lo ha modificato, ma spesso non mostrano i valori precedenti o nuovi.

Dal rilevamento alla risposta

Una volta che un'analisi rileva un'identità che non rientra nel suo pattern normale, l'attenzione si sposta sui permessi di accesso che l'avversario possiede ancora. Poiché gli attacchi basati su credenziali non sono lineari, il primo accesso che trovi è raramente l'unico. Nell'esempio del data engineer, la revoca del token del professionista lascerebbe attive le credenziali del service principal, la sua appartenenza al gruppo di amministrazione e la funzione creata. Una risposta completa rimuove le credenziali originali e ogni percorso creato successivamente dall'avversario, inclusi grant, token, funzioni e job che continuano a essere eseguiti dopo che l'utente è stato disattivato.

In caso di sospetta compromissione del workspace, gli operatori della risposta dovrebbero:

1. Disattiva l'identità. Disattiva l'utente a livello di account, bloccando così tutti i workspace. Non esiste un'API per terminare le sessioni del browser di un utente, ma la disattivazione le blocca. Per un service principal, elimina i suoi secret OAuth e disattivalo con l'API SCIM dell'account. I token OAuth già in possesso del service principal rimangono validi fino a un'ora.
2. Revoca i token di accesso personale. La disattivazione di un utente non elimina i suoi token, i quali torneranno a funzionare se l'utente viene riattivato. Utilizza la Token Management API o il report sui token nella console dell'account.
3. Salva ciò che ti serve, quindi arresta il compute. Esporta prima le definizioni dei job e le versioni dei notebook. Dopodiché, annulla l'esecuzione dei job, termina i cluster e arresta i SQL warehouse. Su serverless, annulla l'esecuzione o l'istruzione. La disattivazione di un utente non arresta il compute già in esecuzione.
4. Ruota ogni segreto letto dall'attore. Modificalo alla fonte, quindi aggiorna il valore memorizzato. Ruota anche le credenziali utilizzate dall'avversario per l'accesso iniziale.
5. Annulla la persistenza creata dall'attore. Rimuovi le ACL degli ambiti dei segreti, le assegnazioni di workspace e le appartenenze ai gruppi. Elimina le funzioni e revoca i grant. Ripristina le tue politiche di traffico di ingresso basato sul contesto (e gli elenchi di accesso IP, se li usi ancora) dai tuoi record.
6. Controlla il codice che l'identità potrebbe aver modificato al di fuori di Databricks, come gli script di inizializzazione e il codice ETL nel cloud storage.
7. Conferma l'interruzione. Esegui una ricerca sulle attività svolte dall'attore. Se la registrazione dettagliata dei log di controllo era disattivata, attivala. Il testo dei comandi viene registrato solo mentre la funzione è attiva.

Prevenzione degli attacchi basati su credenziali

Tornando all'analogia dell'edificio per uffici: il traffico di ingresso basato sul contesto decide chi passa attraverso le porte girevoli, mentre il principio del minimo privilegio stabilisce quali piani il badge può aprire. Un rilevamento tempestivo offre tempo di risposta, ma i controlli preventivi limitano ciò che le credenziali rubate possono fare. I controlli sottostanti sono raggruppati in base a ciò che sottraggono all'avversario, indicativamente nell'ordine in cui interrompono la catena di attacco.

Impedisci l'accesso con credenziali rubate

Il controllo preventivo più efficace contro il riutilizzo delle credenziali è il controllo del traffico di ingresso basato sul contesto. Questo analizza chi sta effettuando una richiesta, da dove proviene e qual è il suo scopo, invece di affidarsi a un singolo perimetro di rete. Questo approccio è particolarmente utile man mano che un numero sempre maggiore di organizzazioni abbandona le VPN. Anche senza una rete aziendale di riferimento, è possibile limitare un token rubato ai contesti effettivamente utilizzati dal suo proprietario. Ad esempio, puoi limitare un service principal con privilegi elevati alle richieste API provenienti da reti fidate, applicando al contempo una politica diversa agli utenti umani.

• Applica le politiche sia alle richieste del workspace che a quelle dell'account. Le politiche del workspace non coprono la console dell'account o le API a livello di account.
• Inizia in modalità dry-run. Esamina i rifiuti e le violazioni del dry-run in system.access.inbound_network, proteggi prima i service principal privilegiati e applica le restrizioni dopo aver tenuto conto delle automazioni legittime e delle integrazioni dei partner.
• Testa i flussi di lavoro serverless e con connettività privata prima di un'implementazione su larga scala, poiché seguono regole di policy separate. Documenta eventuali eccezioni e monitorane l'utilizzo.
• Tratta gli elenchi di accesso IP come un livello aggiuntivo. Laddove si applicano entrambi, una richiesta deve superarli entrambi. Configura gli elenchi per il workspace e la console dell'account se li utilizzi ancora.

Riduci il valore delle credenziali trafugate

• Imposta requisiti di scadenza e rotazione per le credenziali dei service principal, le credenziali di integrazione e i token di accesso personale, e ritira le credenziali non più utilizzate. Le credenziali dormienti sono particolarmente attraenti per gli avversari perché una compromissione può passare inosservata per mesi.
• Applica il principio del minimo privilegio agli ambiti dei segreti. Evita di memorizzare copie di credenziali con privilegi elevati in ambiti con ACL differenti e verifica chi può elencare i contenuti dell'ambito oltre a chi può recuperare i valori.

Limita le operazioni eseguibili o modificabili da una credenziale

• Limita le operazioni ad alto impatto. Ridisponi la creazione di UDF, le modifiche alle ACL degli ambiti dei segreti, le modifiche alle autorizzazioni del workspace, l'amministrazione dei job e le modifiche alle politiche di ingresso solo a identità approvate e ad automazioni controllate.
• Separa i percorsi amministrativi da quelli di calcolo. I runtime dei job ordinari non devono essere in grado di modificare i controlli dell'account e della rete, e qualsiasi tentativo in tal senso deve generare un avviso.
• Proteggi gli ambienti di esecuzione sul cloud. Usa configurazioni del servizio di metadati protette dove applicabile e limita il traffico in uscita dal calcolo in modo che i carichi di lavoro non possano raggiungere liberamente gli endpoint delle credenziali o destinazioni non approvate.
• Limita quali identità possono gestire le identità dell'account, assegnare l'accesso ai workspace e creare job.

Conserva le prove

• Conserva dati di telemetria pronti per le indagini in caso di potenziali compromissioni della sicurezza.
• Conserva log di audit, cronologia delle versioni di notebook e job, definizioni e dipendenze UDF, cronologia delle modifiche ai permessi, eventi di scrittura su cloud storage e log di negazione dell'accesso basato sul contesto per il tempo necessario a ricostruire un attacco.

Ricorda, il raggio d'azione di una credenziale rubata è tanto dannoso quanto i privilegi ad essa assegnati. Riduci tale esposizione e preparati a cercare attività anomale seguendo questi passaggi:

• Consulta le best practice di sicurezza di Databricks per proteggere i tuoi workspace e il tuo account.
• Attiva la registrazione di audit dettagliata e configura il controllo dell'accesso basato sul contesto in modo che entrambi i piani siano coperti.
• Distribuisci la Detection App per iniziare le tue analisi e fai la tua prima domanda a Genie: "Siamo stati compromessi negli ultimi 90 giorni?"

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale