Sempre più organizzazioni stanno adottando paradigmi di sviluppo di applicazioni low-code e no-code. I vantaggi sono evidenti: creano contenuti in tempi rapidi, sono facili da implementare e garantiscono una buona efficienza. Proprio questo essere agili e semplici, li rende particolarmente esposti a un’ampia gamma di potenziali rischi per la sicurezza. Le conseguenze le conosciamo tutti: possono portare all’esposizione dei dati, alla compromissione del sistema e/o degli account e ad altri problemi più significativi.
Per affrontare le sfide dello sviluppo di applicazioni low-code/no-code e prevenire i rischi si possono seguire le seguenti best practice.
Indice degli argomenti
Scegliere il giusto service provider
Una delle principali preoccupazioni riguarda la sicurezza dell’ambiente operativo in cui le applicazioni vengono sviluppate e potenzialmente eseguite. È fondamentale avvalersi di fornitori di servizi no-code e low-code validi da questo punto di vista. Ciò significa che devono offrire controlli e garanzie di sicurezza all’interno del proprio ambiente. Alcuni propongono per esempio la crittografia, la identity federation e il logging, mentre altri offrono poco o niente, lato sicurezza.
Limitare e proteggere le credenziali
Gli approcci low-code/no-code sono soggetti all’uso improprio delle credenziali e allo sfruttamento dei privilegi. Ciò accade soprattutto se il codice è associato a un account di sviluppatore con ampi privilegi nell’ambiente di sviluppo o con connessioni a database e ad altri componenti importanti.
Per mitigare questo genere di rischio, è necessario assicurarsi che i team di sicurezza e di identity vengano coinvolti nel processo di progettazione dell’applicazione, laddove possibile. Meglio anche monitorare le piattaforme low-code/no-code, e tutte le loro connessioni, per verificare l’uso eccessivo o illecito dei privilegi. In molti casi, i log delle connessioni ad altri sistemi e database possono aiutare a identificarli. Ove possibile, si dovrebbe anche implementare account e connessioni con privilegi inferiori.
Prevenire l’esposizione e la perdita di dati
Un altro problema tipico delle applicazioni low-code/no-code è l’esposizione dei dati. Possono andare anche persi in caso di una gestione impropria e di una inadeguata logica applicativa nell’interagire con lo storage.
Visto che la maggior parte dei data provider non offre controlli di sicurezza come la crittografia o il data masking, è importante limitare il più possibile l’esposizione ad ampio spettro delle app low-code/no-code. Si può agire posizionando le app dietro un sistema di intermediazione della sicurezza, come una rete di distribuzione dei contenuti (CDN) o un broker di sicurezza per l’accesso al cloud, che offra sia il monitoraggio dei dati che i controlli di protezione in transito.
Se il primo è disponibile, i team di sicurezza e operativi dovrebbero attivarlo, per controllare al meglio i possibili flussi di dati e le connessioni.
Eseguire test di sicurezza delle applicazioni e richiedere gli SBOM
Una delle maggiori aree di rischio degli ambienti low-code/no-code è il codice stesso, nonché i componenti, i pacchetti back-end e le funzioni utilizzate nello sviluppo. Negli ambienti di sviluppo tradizionali, le organizzazioni più attente agli aspetti di cybersecurity eseguono test sulla codifica e sui pacchetti delle applicazioni, utilizzando rispettivamente il test della sicurezza delle applicazioni statico (SAST) e quello dinamico (DAST).
Questi strumenti, però, non sono sempre facilmente disponibili per lo sviluppo e le distribuzioni low-code/no-code. La cosa migliore da fare è richiedere i risultati di SAST e DAST sui loro componenti back-end e sul codice utilizzato nelle distribuzioni.
Un’altra strategia più diffusa è quella di richiedere, o addirittura esigere, una software bill of materials (SBOM). In questo caso si ottiene un elenco di tutto il codice e dei pacchetti utilizzati nell’ambiente del provider, oltre ad alcune attestazioni di monitoraggio continuo delle minacce e di gestione delle vulnerabilità. Sia la tattica dei SAST e DAST, sia questa, non hanno un successo assicurato.
Migliorare la visibilità
Molti team di sicurezza ritengono di avere poca o nessuna visibilità sulle applicazioni e sugli ambienti low-code/no-code. Idealmente, non si dovrebbero utilizzare piattaforme che non offrono alcun tipo di registrazione o monitoraggio. Non sempre è così nella pratica, però. Come minimo, quindi, si devono attivare i registri di accesso degli utenti e i registri di audit della piattaforma, se disponibili. In alternativa, si potrebbe implementare una strategia di accesso intermediato tramite CDN (Content Delivery Network) che supporti la registrazione e il monitoraggio di tutti gli accessi alle applicazioni e/o ai fornitori di piattaforme, che sono principalmente SaaS.
Educare i dipendenti
Oltre alle tattiche di mitigazione dei rischi, vale la pena ricordare che la formazione e la sensibilizzazione sulla sicurezza, per chiunque sviluppi utilizzando strumenti low-code/no-code, sono fondamentali. Data la disponibilità relativamente scarsa di controlli e funzionalità di sicurezza integrati in questi ambienti, meglio che tutta la workforce comprenda i rischi potenziali e lavori per ridurli o evitarli. Se, quando e dove possibile.
