TECHTARGET

Come mitigare le sfide di sicurezza del low-code/no-code

Senza nulla togliere alla comodità tipica degli approcci di sviluppo di applicazioni low-code/no-code, è necessario restare in allerta, lato sicurezza. Ciò non deve portarci a far rallentare l’innovazione, si tratta solo di considerare alcune importanti best practice, per mitigare e prevenire i loro rischi di sicurezza intrinseci

Pubblicato il 04 Mag 2023

low code no code

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.

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.

Valuta la qualità di questo articolo

La tua opinione è importante per noi!

Articoli correlati

Articolo 1 di 4