Fai attenzione alla rappresentazione dell'utente nelle app con codice basso/senza codice

Il mese scorso ho scritto un articolo sul modo in cui le piattaforme low-code/no-code offrono la condivisione delle credenziali come servizio, perché lo stanno facendo e come appare il punto di vista di un attaccante. In questo articolo mi concentrerò sulle implicazioni di tale compromesso e sul modo in cui influisce oggi sulle imprese.

Ecco perché condividere le proprie credenziali aziendali con qualcun altro è una cattiva pratica. Supponiamo che io voglia passare le mie credenziali a un collega per interrogare i log di produzione per un'analisi una tantum del comportamento degli utenti. In un'azienda tipica, concedere a qualcuno le autorizzazioni per eseguire query su una nuova origine dati potrebbe significare un lungo processo di revisione degli accessi, soprattutto quando si tratta di dati sensibili o di produzione. Il mio collega potrebbe facilmente sentirsi frustrato. "Tutto quello che volevo era fare questa piccola domanda una tantum, e sto già aspettando da un mese!" potrebbero dire. Potrei semplicemente eseguire la query per loro, ma sono sommerso dalle mie attività quotidiane e le query una tantum tendono a diventare complicate.

Mi resta una soluzione rapida: potrei semplicemente condividere il mio nome utente/password con il mio collega. Se riceveranno una sfida da parte dell'AMF, la approverò volentieri. Non devo perdere tempo a eseguire la query e il mio collega viene sbloccato. Tutti vincono! Giusto?

Bene, avresti ragione nella tua analisi, ma ti perdi il quadro più ampio. Sebbene sia importante per l'azienda che il tuo collega effettui l'analisi del comportamento degli utenti, è altrettanto, se non di più, importante che la tua azienda rimanga conforme a tutta una serie di standard di privacy e sicurezza e mantenga la fiducia dei clienti mantenendo l'impegno dell'azienda nei confronti della sicurezza. .

Se gli obiettivi aziendali di alto livello non ti convincono, prendi in considerazione i team di gestione centrale nell'IT o nella sicurezza. Questi team basano le loro operazioni e strategie di sicurezza sul fatto che ogni utente ha la propria identità univoca. I team IT stanno impostando criteri di rete e di accesso che presuppongono che ogni utente abbia effettuato l'accesso da un IP aziendale o da un laptop aziendale alla volta; i team di sicurezza stanno correlando gli eventi in base all'ID utente; i team finanziari potrebbero aggregare i report sui costi per utente e il loro ambiente cloud personale. La condivisione delle credenziali mina tutti questi presupposti, tra gli altri. Elimina il significato di base di un'identità online.

Un esempio del mondo reale

Passiamo al mondo del low-code/no-code ed esaminiamo uno scenario reale. In una grande azienda, Jane, una dipendente ispirata del team di assistenza clienti, si è resa conto che quando i dipendenti di tutta l'organizzazione prendono parte a un caso di cliente, di solito perdono informazioni chiave sul cliente, come la cronologia del caso di supporto e gli ultimi acquisti. Ciò peggiora l'esperienza del cliente, poiché deve spiegare il problema ancora e ancora mentre il caso viene indirizzato al dipendente giusto che può affrontare il problema.

Per migliorare questa situazione, Jane ha creato un'app che consente ai dipendenti dell'azienda di visualizzare queste informazioni chiave sui clienti quando tali dipendenti fanno parte del team responsabile della gestione del caso di supporto del cliente. Innanzitutto, prendiamoci un momento per riconoscere il potere del low-code/no-code, che consente a Jane di identificare un'esigenza e affrontarla da sola, senza chiedere un budget o attendere l'allocazione delle risorse IT.

Durante la creazione dell'applicazione, Jane ha dovuto risolvere diversi problemi, il più importante dei quali erano le autorizzazioni. I dipendenti dell'organizzazione non hanno accesso diretto per interrogare il database dei clienti per ottenere le informazioni di cui hanno bisogno. Se lo facessero, Jane non dovrebbe creare questa applicazione. Per superare questo problema, Jane ha effettuato l'accesso al database e ha incorporato la sua sessione autenticata direttamente nell'applicazione. Quando l'applicazione riceve una richiesta da un utente, utilizzerà l'identità di Jane per eseguire la query e quindi restituire i risultati all'utente. Questa funzionalità di incorporamento delle credenziali, come abbiamo esplorato il mese scorso, è una caratteristica fondamentale delle piattaforme low-code/no-code. Jane si è assicurata di impostare il controllo degli accessi basato sui ruoli (RBAC) nell'applicazione in modo che ogni utente possa accedere solo ai casi dei clienti a cui è assegnato.

L'applicazione ha risolto un importante problema aziendale e quindi ha rapidamente ottenuto l'adozione da parte degli utenti in tutta l'azienda. Le persone erano felici di poter fornire un servizio migliore ai propri clienti avendo il giusto contesto per la conversazione. Anche i clienti erano contenti. Un mese dopo che Jane ha creato l'applicazione, era già utilizzata da centinaia di utenti in tutta l'organizzazione, con tassi di soddisfazione dei clienti in aumento.

Nel frattempo, al SOC, è stato attivato e assegnato ad Amy, un'analista esperta della sicurezza, un avviso di elevata gravità che mostrava un'attività anomala nel database dei clienti di produzione. L'indagine iniziale di Amy ha mostrato che un utente interno stava tentando di analizzare l'intero database, interrogando informazioni su più clienti da più indirizzi IP all'interno dell'organizzazione. Il modello di query era molto complesso; invece di un semplice modello di enumerazione che ti aspetteresti di vedere quando un database viene cancellato, i dati dello stesso cliente sono stati interrogati più volte, a volte tramite indirizzi IP diversi e in date diverse. Potrebbe trattarsi di un utente malintenzionato che cerca di confondere i sistemi di monitoraggio della sicurezza?

Dopo una rapida indagine, Amy ha scoperto un'informazione cruciale: tutte quelle query su tutti gli indirizzi IP e le date utilizzavano un'unica identità utente, qualcuno di nome Jane del team di assistenza clienti.

Amy ha contattato Jane per chiederle cosa sta succedendo. All'inizio Jane non lo sapeva. Le sono state rubate le credenziali? Ha fatto clic sul collegamento sbagliato o si è fidata dell'e-mail in arrivo sbagliata? Ma quando Jane racconta ad Amy dell'applicazione che ha creato di recente, entrambe si rendono conto che potrebbe esserci una connessione. Amy, l'analista del SOC, non aveva familiarità con il low-code/no-code, quindi hanno contattato il team di AppSec. Con l'aiuto di Jane, il team ha scoperto che nella domanda di Jane erano incorporate le credenziali di Jane. Dal punto di vista del database, non c'era alcuna applicazione: c'era solo Jane, che eseguiva un sacco di query.

Jane, Amy e il team di AppSec hanno deciso di chiudere l'applicazione fino a quando non è stata trovata una soluzione. Gli utenti dell'applicazione in tutta l'organizzazione erano frustrati poiché erano arrivati ​​​​a fare affidamento su di essa e anche i clienti lo sentivano.

Mentre Amy chiudeva il problema e documentava i risultati, il vicepresidente dell'assistenza clienti non era contento di vedere il calo del tasso di soddisfazione dei clienti, quindi hanno chiesto a Jane di cercare una soluzione permanente. Con l'aiuto della documentazione della piattaforma e del team del Centro di eccellenza dell'organizzazione, Jane ha rimosso la sua identità incorporata dall'applicazione, ha modificato l'app per utilizzare l'identità di ciascun utente per interrogare il database e ha assicurato che gli utenti ottenessero le autorizzazioni solo per i casi dei clienti a cui sono associati . Nella sua versione nuova e migliorata, l'applicazione utilizzava l'identità di ciascun utente per interrogare il database dei clienti. Jane e gli utenti dell'applicazione erano contenti che l'applicazione fosse tornata online, Amy e il team di AppSec erano contenti che l'identità di Jane non fosse più condivisa e l'azienda ha visto il tasso di soddisfazione dei clienti ricominciare a salire. Tutto andava bene.

Due settimane dopo, il SOC ha ricevuto un altro avviso relativo ad un accesso anomalo al database dei clienti della produzione. Sembrava sospettosamente simile all'avviso precedente sullo stesso database. Anche in questo caso, gli indirizzi IP di tutta l'organizzazione utilizzavano l'identità di un singolo utente per interrogare il database. Ancora una volta, quell'utente era Jane. Ma questa volta il team di sicurezza e Jane sapevano che l'app utilizza le identità dei suoi utenti. Cosa sta succedendo?

L'indagine ha rivelato che l'app originale aveva implicitamente condiviso Sessione di database autenticata di Jane con gli utenti dell'app. Condividendo l'app con un utente, quell'utente ha ottenuto l'accesso diretto a veloce, un wrapper attorno a una sessione di database autenticata fornita dalla piattaforma low-code/no-code. Utilizzando tale connessione, gli utenti potevano sfruttare direttamente la sessione autenticata: non dovevano più passare attraverso l'app. Si scopre che diversi utenti lo avevano scoperto e, pensando che questo fosse il comportamento previsto, stavano utilizzando la sessione del database autenticato di Jane per eseguire le loro query. Hanno apprezzato questa soluzione, poiché l'utilizzo della connessione diretta ha dato loro pieno accesso al database, non solo per i casi dei clienti a cui sono assegnati.

La connessione è stata eliminata e l'incidente è terminato. L'analista del SOC ha contattato gli utenti che avevano utilizzato la connessione di Jane per assicurarsi che eliminassero tutti i dati dei clienti archiviati.

Affrontare la sfida della sicurezza Low-Code/No-Code

La storia sopra è uno scenario di vita reale di una multinazionale B2C. Alcuni dettagli sono stati omessi o modificati per proteggere la privacy. Abbiamo visto come un dipendente ben intenzionato potrebbe condividere involontariamente la propria identità con altri utenti, causando tutta una serie di problemi a livello IT, sicurezza e azienda. Come abbiamo esplorato il mese scorso, la condivisione delle credenziali è una caratteristica chiave del low-code/no-code. È la norma, non l'eccezione.

As low-code/no-code continua a fiorire nell'azienda, consapevolmente o meno, è fondamentale che i team di sicurezza e IT si uniscano alla conversazione sullo sviluppo del business. Le app low-code/no-code sono dotate di a serie unica di sfide per la sicurezzae la loro natura prolifica fa sì che tali sfide diventino acute più velocemente che mai.