Quando un’integrazione apre più di una porta

I sistemi moderni raramente funzionano in modo isolato. Una piattaforma può essere collegata alla posta elettronica, a un database, a un sistema di gestione documentale, a un servizio cloud o a un’applicazione esterna.

Queste integrazioni eliminano molti processi manuali e consentono ai sistemi di operare come un unico ecosistema. Ma ogni connessione crea anche una relazione di fiducia: il Sistema A ottiene il diritto di eseguire determinate operazioni all’interno del Sistema B.

Questo cambia il modo in cui deve essere concepita la sicurezza. Non basta chiedersi se ogni sistema sia protetto singolarmente. È necessario capire anche fin dove un sistema può arrivare attraverso le connessioni che ha con gli altri.

Un’integrazione non trasferisce soltanto dati

Prendiamo il caso di una piattaforma collegata a un sistema di gestione documentale.

L’integrazione può avere l’autorizzazione a leggere documenti, crearne di nuovi o modificare informazioni esistenti. Un’altra integrazione può comunicare con la posta elettronica, mentre un’altra ancora può collegarsi a un database o a una piattaforma finanziaria.

In ciascuno di questi casi, la connessione rappresenta molto più di un semplice canale di comunicazione. Comporta anche un determinato livello di accesso.

È proprio qui che emerge una domanda importante nella progettazione di un sistema: se uno dei suoi componenti venisse compromesso, fin dove potrebbe arrivare un attaccante utilizzando gli accessi che il sistema gli ha legittimamente concesso?

Non si tratta soltanto di uno scenario teorico. Microsoft documenta come le applicazioni cloud possano utilizzare connector che conservano autorizzazioni per accedere a e-mail, applicazioni SaaS, database e altri servizi. Se un attaccante ottiene il controllo della risorsa che gestisce un connector, può potenzialmente sfruttare quell’accesso per raggiungere il servizio collegato, senza dover necessariamente ottenere le credenziali originali.

Un sistema considerato affidabile può diventare una via di accesso a un altro sistema

Questa situazione crea uno scenario particolare.

Il Sistema B può essere configurato correttamente. Le credenziali degli utenti possono essere protette. L’autenticazione può funzionare esattamente come previsto.

Tuttavia, se il Sistema A dispone già di una connessione autorizzata con il Sistema B, la compromissione del Sistema A può cambiare completamente lo scenario di sicurezza.

Nella cloud security, questo fenomeno è legato al concetto di lateral movement: un punto di ingresso viene utilizzato per raggiungere altre risorse collegate. Microsoft evidenzia come gli attack path nelle applicazioni cloud possano estendersi dal codice dell’applicazione alle identità, ai connector, ai database e ad altri servizi cloud.

L’architettura di sicurezza deve quindi considerare non soltanto i singoli componenti, ma anche i percorsi che si creano tra di essi.

Il problema non è l’integrazione. È fin dove si estende l’accesso

Un’integrazione ha bisogno di determinati privilegi per poter funzionare. Ma non c’è motivo di concederle più accesso di quanto sia necessario per svolgere la propria funzione.

Se un processo deve soltanto leggere una determinata categoria di documenti, consentirgli di accedere all’intero repository aumenta inutilmente la superficie di esposizione. Se un servizio deve soltanto inviare informazioni, permettergli anche di modificarle o eliminarle introduce privilegi di cui il processo non ha bisogno.

È qui che il principio del least privilege diventa parte integrante della progettazione dell’integrazione: ogni connessione riceve esclusivamente le autorizzazioni necessarie per svolgere la funzione prevista.

Questo controllo diventa sempre più importante man mano che gli ecosistemi software si collegano a un numero crescente di applicazioni e servizi. Microsoft, ad esempio, mette a disposizione l’attack-path mapping per le applicazioni OAuth, con l’obiettivo di individuare in che modo un’applicazione connessa possa creare percorsi verso servizi e dati sensibili.

Le connessioni devono essere progettate con la stessa attenzione dei sistemi

Quando si realizza una piattaforma integrata, le domande relative alla sicurezza devono andare oltre il semplice: “A quale sistema ci stiamo collegando?”.

Quali autorizzazioni possiede questa connessione? A quali dati può accedere? Cosa può modificare? La stessa autorizzazione può essere utilizzata da un altro componente? Cosa accade quando l’integrazione non è più necessaria? E soprattutto, quale altro sistema può essere raggiunto attraverso questa connessione?

Queste domande aiutano a evitare che un’integrazione si trasformi involontariamente in un ponte verso altre parti dell’ecosistema.

Casi reali degli ultimi anni hanno dimostrato proprio questo effetto. Microsoft ha documentato incidenti in cui token OAuth e integrazioni SaaS considerate affidabili sono stati utilizzati per mantenere l’accesso a sistemi CRM e, in alcuni casi, per estendere tale accesso ad altre piattaforme collegate.

La sicurezza di un ecosistema dipende anche dalle connessioni al suo interno

In ALSoft, l’integrazione non viene considerata semplicemente come uno scambio di dati tra due applicazioni. Il modo in cui i sistemi si autenticano, i privilegi che ricevono e la portata di ogni connessione fanno parte dell’architettura stessa dell’integrazione.

Come afferma Ermal Beqiri, fondatore di ALSoft:

«Quando colleghiamo due sistemi, non creiamo soltanto un percorso per i dati. Creiamo anche una relazione di fiducia. L’architettura deve definire chiaramente fino a che punto si estende questa fiducia e cosa può fare ciascuna connessione.»

Più i sistemi collaborano tra loro, più le connessioni che li uniscono diventano parte della superficie che deve essere protetta.

Perché un’integrazione ben progettata non stabilisce soltanto come si apre una porta, ma anche fin dove è possibile arrivare una volta che quella porta è stata aperta.