I sostenitori della Robotic Process Automation, o RPA, delineano scenari lavorativi in cui i compiti più noiosi e ripetitivi sono svolti da automi software, mentre il personale umano può dedicarsi ad altre operazioni più a valore aggiunto. Questi scenari di collaborazione tra bot software - oggi meglio detti digital worker - e persone si sono già concretizzati, e con un certo successo. Hanno però posto un problema all'attenzione di chi si occupa di sicurezza: quanto e come va limitata l'automazione della RPA?

Il presupposto della RPA è che i bot sono limitati e fatti in modo da non poter sbagliare. Ma man mano che l'automazione amplia il suo raggio d'azione, un digital worker si può trovare a svolgere compiti anche complessi. E per questo ad accedere a diverse risorse aziendali. E spesso a maneggiare dati sensibili. Ad esempio, il settore bancario sta adottando molte soluzioni di RPA per velocizzare operazioni ripetitive. In questo scenario, i bot RPA di una banca possono trovarsi a gestire dati critici come le transazioni delle carte di credito. O lo stato dei conti correnti dei clienti di una banca.

Si capisce quindi perché ci si sta ponendo il problema della affidabilità dei digital worker. Che un bot software gestisca informazioni e procedure sensibili senza alcun controllo, fidandosi solo della qualità del suo codice, non è più scontato. Ma non è nemmeno una questione immediata da risolvere. Perché un digital worker non è una entità ben precisa, come lo è invece una persona. È un insieme di funzioni, codificate potenzialmente anche in moduli distinti, creato per svolgere determinati task. Solo i bot più semplici sono "monodimensionali", svolgono. cioè una unica funzione poco complessa.
Il primo passo da compiere è quindi identificare precisamente un digital worker, inteso come insieme di funzioni che svolgono compiti legati a una determinata procedura lavorativa. Cosa che a volte è immediata, altre volte meno. Anche perché il "lavoratore digitale" è di norma collaborativo: molte funzioni le svolge da solo, ma in molte altre è solo di supporto ad un operatore umano che deve completarle. Lato sicurezza, in questi casi, va esaminato non solo il lavoro del (o dei) bot che "fanno" un digital worker ma anche le interazioni con la controparte umana.

Accessi controllati

Determinato che un certo digital worker svolge certi compiti, per la sicurezza bisogna trattarlo come un qualsiasi dipendente. Deve cioè avere accesso solo alle risorse IT e ai dati di cui ha effettivamente bisogno per il suo lavoro. E i suoi accessi devono essere verificati e controllati. Concettualmente non c'è nulla di nuovo, in questo. All'atto pratico però va considerato che un digital worker è meno "affidabile" - e non per colpa sua - di un operatore umano.

Sul tema della protezione delle identità digitali e degli accessi privilegiati, ImpresaCity ha predisposto un webinar insieme a One Identity e Par-Tec: clicca qui per conoscerne i dettagli ed iscriverti all'evento

Un dipendente umano può commettere errori o decidere di comportarsi in maniera impropria o illecita. Ad esempio rubando informazioni confidenziali per trarne profitto. Un digital worker non è meno a rischio perché è un (s)oggetto software con un comportamento teoricamente prefissato. Può comunque sbagliare, perché mal programmato. E può essere violato da hacker ostili, i quali conquistano a quel punto i suoi privilegi di accesso. Oppure il suo codice può essere modificato ad hoc, magari da un dipendente umano, per svolgere operazioni improprie. Le vulnerabilità potenziali non mancano.
Il metodo più logico per evitare che un digital worker faccia danni è seguire il buon vecchio - e sempre trascurato, per comodità - principio dei privilegi minimi. Al digital worker si associa un account utente che accede al minimo possibile di sistemi, dati e risorse. Per la natura collaborativa stessa dei digital worker, poi, bisogna anche fare in modo che il personale che opera con un bot software non possa, volontariamente o per errore, abusare delle sue funzioni. Ad esempio, un bot può - e di solito deve - completare le sue operazioni anche in funzione di ciò che gli viene indicato dal suo collega umano. Ma questi non deve poter indurre il bot a comportamenti anomali.

In molto casi è opportuno abilitare anche funzioni di controllo e auditing delle operazioni dei bot. Queste cioè non devono essere considerate corrette di default. Perché potrebbero non esserlo: un bot è comunque un modulo software, con i suoi potenziali errori di programmazione. E come tutti i software, anche il codice dei bot dovrebbe essere valutato non solo per la sua correttezza logica e formale ma anche dal punto di vista della cyber security e della compliance normativa.