3 modi in cui gli sviluppatori senza codice possono spararsi ai piedi

C'era un tempo in cui le organizzazioni avverse al rischio potevano limitare fortemente la capacità dei propri utenti aziendali di commettere errori costosi. Con un know-how tecnico limitato, autorizzazioni rigorose e mancanza di vento favorevole, la cosa peggiore che un utente aziendale potesse fare era scaricare malware o cadere in una campagna di phishing. Quei giorni sono ormai passati.

Al giorno d'oggi, tutte le principali piattaforme software-as-a-service (SaaS) vengono fornite in bundle con funzionalità di automazione e creazione di applicazioni progettate e commercializzate direttamente per gli utenti aziendali. Piattaforme SaaS come Microsoft 365, Salesforce e ServiceNow stanno incorporando piattaforme no-code/low-code nelle loro offerte esistenti, mettendole direttamente nelle mani degli utenti aziendali senza chiedere l'approvazione aziendale. Funzionalità che una volta erano disponibili solo per i team IT e di sviluppo sono ora disponibili in tutta l'organizzazione.

Power Platform, la piattaforma low-code di Microsoft, è integrata in Office 365 ed è un ottimo esempio grazie alla forte presenza di Microsoft nell'azienda e alla velocità con cui viene adottata dagli utenti aziendali. Forse senza rendersene conto, le aziende stanno mettendo il potere a livello di sviluppatore nelle mani di più persone che mai, con molta meno sicurezza o esperienza tecnica. Che cosa potrebbe andare storto?

Un bel po', in realtà. Esaminiamo alcuni esempi del mondo reale dalla mia esperienza. Le informazioni sono state rese anonime e i processi specifici dell'azienda sono stati omessi.

Situazione 1: Nuovo fornitore? Fallo e basta

Il team dell'assistenza clienti di un'azienda multinazionale di vendita al dettaglio voleva arricchire i propri dati sui clienti con approfondimenti sui consumatori. In particolare, speravano di trovare maggiori informazioni sui nuovi clienti in modo da poterli servire meglio, anche durante il loro primo acquisto. Il team dell'assistenza clienti ha deciso un fornitore con cui vorrebbe lavorare. Il fornitore richiedeva l'invio di dati per l'arricchimento, che sarebbero poi stati ritirati dai loro servizi.

Normalmente, è qui che entra in gioco l'IT. L'IT dovrebbe creare una sorta di integrazione per ottenere i dati da e verso il fornitore. Ovviamente anche il team di sicurezza IT dovrebbe essere coinvolto, per garantire che questo fornitore possa essere considerato attendibile con i dati dei clienti e approvare l'acquisto. Anche gli appalti e il legale avrebbero avuto un ruolo chiave. In questo caso, però, le cose sono andate in un'altra direzione.

Questo particolare team di assistenza clienti era composto da esperti di Microsoft Power Platform. Invece di aspettare le risorse o l'approvazione, sono semplicemente andati avanti e hanno creato l'integrazione da soli: raccogliendo i dati dei clienti dai server SQL in produzione, inoltrandoli tutti a un server FTP fornito dal fornitore e recuperando i dati arricchiti dal server FTP a la banca dati di produzione L'intero processo veniva eseguito automaticamente ogni volta che un nuovo cliente veniva aggiunto al database. Tutto questo è stato fatto tramite interfacce drag-and-drop, ospitate su Office 365 e utilizzando i loro account personali. La licenza è stata pagata di tasca propria, il che ha tenuto gli appalti fuori dal giro.

Immagina la sorpresa del CISO quando ha scoperto che una serie di automazioni aziendali spostava i dati dei clienti su un indirizzo IP codificato su AWS. Essendo un cliente esclusivo di Azure, questo ha sollevato una gigantesca bandiera rossa. Inoltre, i dati venivano inviati e ricevuti con una connessione FTP non sicura, creando un rischio per la sicurezza e la conformità. Quando il team di sicurezza lo ha rilevato tramite uno strumento di sicurezza dedicato, i dati si spostavano dentro e fuori l'organizzazione da quasi un anno.

Situazione 2: Ohh, è sbagliato riscuotere carte di credito?

Il team delle risorse umane di un grande fornitore IT si stava preparando per una campagna "Give Away" una volta all'anno, in cui i dipendenti sono incoraggiati a donare alla loro organizzazione di beneficenza preferita, con l'azienda che partecipa eguagliando ogni dollaro donato dai dipendenti. La campagna dell'anno precedente è stata un enorme successo, quindi le aspettative erano alle stelle. Per potenziare la campagna e alleviare i processi manuali, un dipendente creativo delle risorse umane ha utilizzato Power Platform di Microsoft per creare un'app che ha facilitato l'intero processo. Per registrarsi, un dipendente deve accedere all'applicazione con il proprio account aziendale, inviare l'importo della donazione, selezionare un ente di beneficenza e fornire i dettagli della propria carta di credito per il pagamento.

La campagna è stata un enorme successo, con una partecipazione da record da parte dei dipendenti e poco lavoro manuale richiesto ai dipendenti delle risorse umane. Per qualche ragione, però, il team di sicurezza non era contento di come sono andate le cose. Durante la registrazione alla campagna, un dipendente del team di sicurezza si è reso conto che le carte di credito venivano raccolte in un'app che non sembrava dovesse farlo. Dopo un'indagine, hanno scoperto che quei dettagli della carta di credito erano stati effettivamente gestiti in modo improprio. I dettagli della carta di credito sono stati archiviati nell'ambiente Power Platform predefinito, il che significa che erano disponibili per l'intero tenant di Azure AD, inclusi tutti i dipendenti, i fornitori e gli appaltatori. Inoltre, sono stati memorizzati come semplici campi stringa di testo in chiaro.

Fortunatamente, la violazione dell'elaborazione dei dati è stata scoperta dal team di sicurezza prima che i malintenzionati, o i revisori della conformità, la individuassero. Il database è stato ripulito e l'applicazione è stata aggiornata per gestire correttamente le informazioni finanziarie secondo la normativa.

Situazione 3: Perché non posso semplicemente usare Gmail?

Come utente, a nessuno piacciono i controlli di prevenzione della perdita di dati aziendali. Anche quando necessario, introducono fastidiosi attriti nelle operazioni quotidiane. Di conseguenza, gli utenti hanno sempre cercato di aggirarli. Un perenne tiro alla fune tra gli utenti aziendali creativi e il team di sicurezza è l'e-mail aziendale. Sincronizzare l'e-mail aziendale con un account e-mail personale o il calendario aziendale con un calendario personale: i team di sicurezza hanno una soluzione per questo. Vale a dire, hanno messo in atto soluzioni di sicurezza e-mail e DLP per bloccare l'inoltro di e-mail e garantire la governance dei dati. Questo risolve il problema, giusto?

Beh no. Una scoperta ripetuta in grandi e piccole imprese rileva che gli utenti stanno creando automazioni che aggirano i controlli della posta elettronica per inoltrare la posta elettronica aziendale e il calendario ai propri account personali. Invece di inoltrare le email, copiano e incollano i dati da un servizio all'altro. Accedendo a ciascun servizio con un'identità separata e automatizzando il processo di copia-incolla senza codice, gli utenti aziendali aggirano i controlli di sicurezza con facilità e senza che i team di sicurezza possano scoprirlo facilmente.

La community di Power Platform si è persino sviluppata modelli che qualsiasi utente di Office 365 può acquisire e utilizzare.

Con un grande potere viene una grande responsabilità

L'empowerment degli utenti aziendali è eccezionale. Le linee di business non dovrebbero aspettare l'IT o lottare per le risorse di sviluppo. Tuttavia, non possiamo semplicemente offrire agli utenti aziendali potere a livello di sviluppatore senza indicazioni o guardrail e aspettarci che tutto vada bene.

I team di sicurezza devono educare gli utenti aziendali e renderli consapevoli delle loro nuove responsabilità come sviluppatori di applicazioni, anche se tali applicazioni sono state create utilizzando "nessun codice". I team di sicurezza dovrebbero anche mettere in atto barriere di protezione e monitoraggio per garantire che quando gli utenti aziendali commettono un errore, come tutti noi, non si trasformi in fughe di dati in piena regola o incidenti di controllo della conformità.