Oltre il perimetro: implementazione dell’IAM Zero-Trust in ambienti cloud ibridi ed eCloud

Gli ambienti moderni si basano su piattaforme cloud, applicazioni SaaS e infrastrutture ibride, rendendo obsoleti i confini di rete. L’identità rappresenta il punto di controllo più coerente trasversalmente a tutti i servizi, le applicazioni e gli ambienti. 

La “proliferazione delle identità” si verifica quando account, credenziali e autorizzazioni sono distribuiti su piattaforme scollegate tra loro, creando punti ciechi e una governance carente. 

Le identità delle macchine crescono più rapidamente di quelle umane e spesso non sono soggette a gestione del ciclo di vita, rotazione e monitoraggio, rendendo difficile proteggerle manualmente. 

Unificando i sistemi di identità, imponendo un’autenticazione forte, verificando continuamente gli accessi ed eliminando la fiducia implicita tra i sistemi. 

Effettuare un inventario di tutte le identità, consolidare le piattaforme, applicare l’autenticazione a più fattori (MFA), automatizzare la governance, segmentare gli accessi e applicare politiche di verifica continua.

Per la trascrizione con indicazione dei tempi, guarda il video qui

Ciao a tutti, benvenuti a “Beyond the Perimeter”.

Penso che il titolo di questa sessione sia fantastico.

Sarebbe perfetto per un film, ma… ehm… in questa sessione non parleremo di
nulla che abbia a che fare con i film.

Parleremo del vostro sistema IAM e di come l’approccio Zero Trust possa aiutarvi a
proteggere i vostri sistemi IAM e a rendere le vostre reti più sicure.

Ecco alcuni degli obiettivi chiave che tratteremo durante questa presentazione.

Parleremo del motivo per cui l’identità rappresenta ora il nuovo perimetro di sicurezza.

Affronteremo anche i principi fondamentali dell’IAM Zero Trust che riteniamo più importanti per
il vostro sistema di gestione delle identità e degli accessi.

E parleremo di alcune strategie che possiamo implementare per unificare, rafforzare
e verificare gli accessi nel vostro sistema di gestione delle identità e degli accessi.

Inoltre, alla fine, vi presenterò una roadmap che potrete utilizzare e che, spero, vi
fornirà consigli pratici e passi concreti da compiere per implementare lo Zero Trust nel vostro

sistema IAM e che vi aiuti davvero a muovere i primi passi e a ottenere risultati positivi fin da subito, magari già dalla prossima
settimana, mentre riflettete sui vostri progetti Zero Trust.

Mi chiamo Ron Robbins e sono Senior Product Manager qui in Commvault; lavoro nel settore
della resilienza delle identità e mi occupo di aiutare i clienti

a risolvere le sfide relative alla resilienza delle identità all’interno delle loro organizzazioni.

Andiamo avanti ed entriamo nel vivo dell’argomento.

La cosa che credo di aver imparato più di ogni altra nel prepararmi per questa presentazione,
e che ritengo sia la più importante da ricordare, è che

l’identità è il nuovo perimetro.

Un tempo la nostra sicurezza era limitata al firewall, giusto?

Eravamo abituati ai modelli di rete tradizionali in cui

configuravamo firewall e VPN, e consideravamo la nostra rete o il nostro data center
protetti da quei firewall e da quelle VPN.

Ora non è più così.

Sai, abbiamo aggiunto nuovi carichi di lavoro e nuove applicazioni SaaS.

Abbiamo aggiunto nuove piattaforme cloud al nostro ambiente.

E così, come ha affermato John Hawley in un articolo della rivista CSO Magazine del 2012, i nostri data
center stanno diventando altamente frammentati.

Si stanno espandendo oltre il comodo perimetro di sicurezza dei firewall e delle VPN, il che, a mio
avviso, è un’immagine perfetta su cui riflettere e per comprendere la situazione in cui ci troviamo tutti

oggi, in cui non disponiamo più di quella rete tradizionale on-premise in cui siamo
protetti da firewall e VPN.

Ma ci siamo spinti ben oltre.

Ad esempio, la maggior parte di noi si trova in questa situazione ibrida in cui disponiamo di una soluzione in sede

e utilizziamo anche molte piattaforme cloud.

Ehm… Le nostre implementazioni di messaggistica istantanea sono davvero messe alla prova da questo e Geoff Cairns ne parla in un
articolo che ha scritto annunciando il Forrester Wave™.

Egli afferma che le implementazioni di messaggistica istantanea odierne sono caratterizzate da una proliferazione delle identità, da account utente
multipli e credenziali distribuite tra sistemi isolati, e che il risultato è una gestione inadeguata delle identità

risultato.

Ed è davvero qualcosa che dobbiamo tenere sotto controllo, perché è un fenomeno che
cresce di giorno in giorno.

Inoltre, se si aggiunge all’equazione il problema di un’IA genetica, si assiste a questa esplosione
di ciò che chiamiamo identità non umana o NHI.

CyberArk, nel 2025, in uno studio di panorama del settore, ha rilevato che le identità delle macchine dei propri clienti oggetto dell’indagine

superano ormai quelle umane con un rapporto sbalorditivo di 82 a uno, il che è incredibile se
ci si pensa.

Il numero di agenti che utilizzano tali identità e il numero di account di servizio che le utilizzano
.

Un tempo avevamo questa idea di una rete in cui a ogni persona corrispondeva un’unica identità.

E gestivamo solo quel piccolo numero di identità.

Ora invece abbiamo migliaia e migliaia di account di servizio che dobbiamo
gestire

con nomi come “account di servizio 01”, “account di servizio 02”, e questo diventa davvero un problema enorme
per noi: un problema davvero enorme gestire quell’esplosione di identità e garantire

l’igiene in tutto l’ambiente.

Quindi ora più che mai, penso davvero che abbiamo bisogno di una sorta di strategia “zero trust” per
il nostro ambiente IAM.

Cerchiamo quindi di definire un po’ meglio in cosa consiste
la sfida dell’ambiente ibrido e multi-cloud.

Mi chiedo: quanti di voi hanno una strategia multi-cloud?

Se utilizzaste solo AWS, le notizie recenti potrebbero avervi fatto capire che una strategia
multi-cloud è qualcosa che potreste dover adottare, in cui è necessario che le applicazioni siano distribuite

su più piattaforme, su più cloud o, se possibile, disporre almeno di un failover tra
i cloud.

Quindi aggiungiamo queste piattaforme cloud alla nostra organizzazione per garantire la resilienza.

E poi abbiamo scoperto che ciascuna di queste piattaforme cloud di cui la nostra organizzazione
doveva disporre ha i propri sistemi IAM.

E ciascuno di questi sistemi IAM ha un proprio linguaggio.

Ad esempio, se si considera Active Directory e si pensa all’aggiunta di un ruolo in
Active Directory, è completamente diverso dall’aggiungere un ruolo in AWS IAM.

Voglio dire, ci sono alcuni concetti simili, giusto?

Ma il linguaggio e la procedura che si seguono in Active Directory e quella che si seguono in
AWS IAM

sono due cose completamente diverse.

Voglio dire, AWS IAM è più simile a un linguaggio di scripting per accedere a un ruolo o aggiungerne uno che ad
Active Directory.

E quindi, se si va oltre l’interfaccia utente, la questione è molto più complessa e non è coerente
tra i vari sistemi IAM.

Questo crea non pochi problemi quando vogliamo far rispettare le regole e applicare
politiche coerenti tra le piattaforme e le applicazioni.

Inoltre, le fusioni e le acquisizioni contribuiscono al problema.

Abbiamo costantemente fusioni e acquisizioni o nuove aziende che entrano a far parte della nostra
organizzazione, che potrebbero avere i propri account e le proprie

che dobbiamo gestire.

E potrebbero portare con sé problemi di “igiene delle identità” che prima non avevamo nemmeno preso
in considerazione.

Lavoravo per un’organizzazione e, tra l’altro, non farò nomi per
garantire la tutela dei responsabili.

Ma lavoravo per un’organizzazione che era molto attiva nel campo delle fusioni e acquisizioni.

Abbiamo effettuato un audit “zero trust” e abbiamo scoperto che c’erano molti account cloud
che semplicemente non venivano gestiti, di cui non tenevamo conto a causa del numero

di acquisizioni avvenute nell’ultimo anno.

Abbiamo scoperto di avere 12 account cloud di cui non conoscevamo nemmeno l’esistenza.

E all’interno di ciascuno di quei 12 account cloud, c’erano account amministrativi univoci

per un singolo utente.

Quindi un singolo utente poteva avere 12 diversi account amministrativi su tutte queste 12
piattaforme cloud.

E questo ha creato un bel problema per noi.

Inoltre, quando questi utenti se ne andavano, si creavano molti account orfani.

C’erano quindi account amministrativi orfani, cosa che davvero non si vorrebbe avere nella
propria organizzazione.

Pertanto, la gestione delle identità diventa un problema piuttosto serio quando si inizia a considerare

il numero di piattaforme cloud e di applicazioni SaaS
che si aggiungono all’equazione.

Quindi, ora più che mai, abbiamo bisogno di una strategia per i nostri sistemi di gestione delle identità.

E penso che ci siano alcuni principi del modello Zero Trust che possiamo applicare ai nostri sistemi IAM
per rendere le cose più sicure.

Il primo è: non fidarsi mai e verificare sempre.

Ogni singolo utente, ogni singolo dispositivo,

ogni singola entità che accede alla rete deve dimostrare la propria identità.

Dovete assicurarvi che dimostri la propria identità e che sia un elemento
affidabile in grado di accedere ed eseguire funzioni all’interno della vostra rete.

Inoltre, è necessario applicare il principio del “privilegio minimo” alle identità.

Pertanto, agli utenti dovrebbe essere concesso solo l’accesso necessario per svolgere un’attività o le proprie mansioni lavorative e
nient’altro.

Pertanto, se hanno accesso a qualcosa che esula dalle loro mansioni lavorative,

si tratta di un account con privilegi eccessivi.

Immaginate cosa potrebbe accadere se un malintenzionato entrasse in possesso di quell’account e fosse in grado di accedervi
ed eseguire operazioni che non dovrebbe compiere all’interno della vostra organizzazione.

Inoltre, è necessario disporre di un’autenticazione forte e dell’autenticazione a più fattori (MFA) ovunque, se non ne siete già in possesso.

L’autenticazione si basa su tre elementi.

Si basa su qualcosa che si conosce, qualcosa che si possiede e qualcosa che si è.

È quindi importante che l’autenticazione forte includa tutte e tre queste cose o almeno
due di esse, se al momento non è possibile applicarle tutte e tre nella vostra rete.

È molto importante.

Le decisioni relative all’accesso devono basarsi sul contesto e sullo stato di sicurezza.

Cosa significa?

Supponiamo che una persona acceda alla rete con un laptop e abbia
effettuato l’accesso da qualche parte nel New Jersey.

Ha quindi iniziato a svolgere alcune attività sulla rete e, all’improvviso, cinque minuti dopo,

l’indirizzo IP del suo computer cambia in uno che forse si trova
in California, e inizia a compiere azioni sulla rete dalla California.

Beh, è impossibile che quella persona abbia attraversato il Paese in cinque
minuti.

È un viaggio impossibile.

E se ciò viene rilevato durante quella sessione, o si vorrà terminare
la sessione stessa oppure si vorrà richiedere una nuova autenticazione per assicurarsi che sia ancora la persona

che ha dichiarato di essere al momento dell’autenticazione.

Pertanto, verificare lo stato del dispositivo

e il contesto è estremamente importante.

A ciò si affianca poi la verifica continua.

Assicurarsi che la persona che hai autenticato una volta continui a dimostrare affidabilità
durante l’intera sessione.

Pertanto, se inizia ad adottare comportamenti rischiosi, se inizia ad accedere ad account per i quali non
è autorizzata, se inizia a cancellare o a compiere azioni distruttive, è necessario

verificarla nuovamente o

interrompere la sessione se si tratta di qualcosa che comporta un rischio.

Un altro grande vantaggio dello zero trust è che si dovrebbe sempre presumere una violazione o adottare questa
mentalità di “violazione presunta”, giusto?

Dovreste progettare la vostra rete come se al suo interno ci fossero già malintenzionati.

E penso che un esercizio stimolante, o forse divertente per alcuni di voi
a cui piace giocare a fare gli investigatori, sia quello di partire dal presupposto che qualcuno abbia già violato

la vostra rete ogni giorno.

Andate a controllare le sessioni, osservate le azioni degli utenti, cercate di

scoprire se qualcuno sta compiendo azioni dannose nella vostra rete ogni giorno e cercate di cogliere
i malintenzionati in flagrante.

Se partite sempre dal presupposto che ci sia stata una violazione, sarete sempre cauti, adotterete
sempre le dovute precauzioni e monitorerete costantemente ciò che accade nella vostra rete

e nei vostri sistemi di gestione delle identità.

Quali sono quindi alcune strategie che possiamo utilizzare per implementare alcune di queste politiche Zero Trust?

Beh, la prima cosa che penso si possa fare è unificare identità, autenticazione e
accesso.

E cosa intendo dire con questo?

Beh, ehm

con tutte queste piattaforme cloud, con tutte queste applicazioni SaaS che abbiamo implementato,
ci ritroviamo con questi silos di identità.

Mi piace chiamarle “isole di identità”, proprio queste isole di identità che esistono là fuori.

E la cosa più semplice da fare per tenerle tutte sotto controllo è abbattere i silos o
le barriere tra tutte queste “isole di identità” e riunirle tutte insieme.

Stabilite un’unica fonte di verità per la vostra identità.

A volte, nella maggior parte delle organizzazioni, questa può essere un sistema delle risorse umane: quando le
persone vengono assunte e inseriscono i propri dati nel sistema delle risorse umane.

Quella potrebbe essere l’unica fonte di verità e potrebbe costituire il punto di partenza per la creazione degli account.

Potrebbe anche trattarsi di un sistema di identità come servizio, come ad esempio Entra AD, Ping o Octa
, o qualcosa di simile.

Il punto fondamentale qui è arrivare a un’unica identità per utente.

È molto più semplice gestire gli utenti e le identità se si dispone di un’unica identità per utente.

Inoltre, è più semplice federare quell’identità su più sistemi e
servizi se si dispone di un’unica identità per utente.

E questo è il passo successivo.

Quello che dovete fare è federare quell’identità.

Ho un buon esempio tratto da un’organizzazione con cui ho lavorato in passato.

Vi assicuro che non si tratta della stessa organizzazione, ma, ribadisco, è un’organizzazione anonima.

Abbiamo implementato un servizio FTP.

Quel servizio FTP non poteva essere federato

con la nostra tipica strategia di federazione.

Pertanto, disponeva di un proprio archivio delle identità.

Aveva anche un proprio componente MFA.

All’epoca non avevamo ancora molta esperienza nella gestione della federazione tra il nostro ambiente
aziendale e quello cloud.

Pertanto, una persona che volesse accedere a questo servizio FTP cloud doveva prima effettuare l’accesso alla
VPN aziendale utilizzando un account utente e un nome utente, e poi superare una verifica MFA.

Successivamente doveva accedere alla nostra piattaforma cloud

utilizzando un account utente aziendale, un nome utente, una password e un’autenticazione MFA.

E poi avrebbe dovuto accedere al servizio FTP utilizzando un nome utente, una password e un’autenticazione
MFA.

E tutte queste entità avevano lo stesso nome.

Pertanto, ogni volta che chiamavano l’help desk e avevano un
problema con la propria identità o con uno dei propri account MFA, non riuscivamo a capire di quale si trattasse.

In pratica,

dovevamo indovinare e capire con quale avessero problemi, e loro non erano in grado di
spiegarci facilmente di quale si trattasse.

Quindi a volte i loro problemi venivano risolti, altre volte no, e non
avevamo davvero idea di dove si trovassero i problemi di identità in quel particolare sistema.

Pertanto è molto importante arrivare in qualche modo a quell’unica identità per utente.

Inoltre, avere un’unica identità rende molto più semplice unificare le politiche e i modelli di accesso basati sui ruoli tra
le diverse piattaforme.

E poi, quando si arriva ad automatizzare il provisioning del ciclo di vita e la governance degli utenti
, è molto, molto più facile con un’unica identità e un panorama delle identità consolidato.

Parliamo ora di come rafforzare la sicurezza degli accessi privilegiati.

Anche questo è molto importante.

Una delle cose che dovete fare è considerare i vostri amministratori come le identità
a più alto rischio all’interno della vostra organizzazione.

Sono gli account più pericolosi e sono quelli a cui si ricorre maggiormente

vengono presi di mira in caso di violazione.

Sono quelli che hanno più valore per i malintenzionati, giusto?

Nessuno all’interno della vostra organizzazione dovrebbe disporre di autorizzazioni elevate in ogni momento.

Nessun amministratore dovrebbe avere permessi elevati in ogni momento.

Semplicemente non ne hanno bisogno.

Non ne hanno bisogno per navigare sul web o per leggere le notizie su ciò che accade nel mondo.

È necessario imporre un sistema di elevazione dei privilegi “just-in-time”

in cui gli amministratori ricevano account con privilegi elevati solo per il periodo di tempo necessario a
eseguire l’azione che desiderano compiere.

Se si combina questo approccio con il principio dello zero trust, si otterrà un
account amministratore che avrà accesso solo per il tempo necessario a svolgere il proprio compito.

E avrà accesso solo per eseguire quella specifica funzione che gli abbiamo consentito
di svolgere.

In questo modo i vostri account amministrativi risulteranno molto più sicuri.

Dovreste inoltre definire una sorta di account di emergenza monitorati.

Ho una storia fantastica a riguardo.

Mi chiedo, provate a chiedervi: quanti di voi là fuori hanno un Bob nel proprio ambiente?

Insomma, lo conoscete, sapete chi è Bob.

Bob è quel tipo che è l’unica persona in grado di accedere a quel server impolverato e
riposto in un vecchio armadio di cablaggio da qualche parte nella sede della vostra organizzazione

ed è l’unico in grado di accedervi.

E se Bob dovesse mai lasciare l’organizzazione o se, Dio non voglia, dovesse morire, perdereste
l’accesso a quel server.

Non potreste più accedervi.

Non potreste più eseguire backup e ripristini.

Non potreste più aggiornarlo.

E Bob lo sa, e Bob sa di essere molto prezioso.

Quindi devi assicurarti di eliminare i “Bob” dal tuo ambiente.

Volete disporre di account di emergenza che possiate implementare, a cui ricorrere quando
necessario, qualora dovesse verificarsi l’impensabile, qualora dovesse verificarsi un disastro, e account che siano

sessioni monitorate e controllate, account che puoi prelevare e riconsegnare per eseguire
le azioni di più alto livello, come ad esempio l’accesso come root in un account cloud di tua proprietà.

Un altro aspetto importante per rendere rigoroso l’accesso ai privilegi è richiedere una doppia approvazione per le azioni ad alto
impatto.

Cosa intendo dire?

Supponiamo che abbiate un amministratore che debba effettuare l’accesso e modificare 50 account.

Di solito non lo fa mai, ma, come sapete, si tratta di un’azione dall’impatto molto elevato.

Sarebbe un’azione molto dannosa se, gestendo 50 account contemporaneamente
, apportasse una modifica che avesse un impatto negativo sulla vostra organizzazione.

Vorreste poter disporre di un meccanismo che richieda una doppia autenticazione o
una doppia approvazione per quell’azione specifica, in modo che quando Bob apporta quella modifica,

debba ottenere l’approvazione da qualcun altro, magari una figura di livello superiore nell’organizzazione
dovrebbe approvare quell’azione.

E questo è molto importante.

Se un malintenzionato entrasse in possesso dell’account di Bob o di chiunque altro – sentite, sto solo
prendendo Bob come esempio – avrebbe bisogno di un secondo account per poter eseguire quelle

azioni distruttive o di grande impatto.

Inoltre, ogni sessione con privilegi, ogni sessione amministrativa, deve
essere registrata.

Assicuratevi che siano tutte monitorate e sottoposte a verifica.

E poi fate sapere ai vostri collaboratori che tali attività vengono verificate e registrate.

Ho notato che gli amministratori sono molto più attenti se sanno che le loro azioni vengono monitorate.

Stanno molto più attenti a non commettere errori e a non adottare
comportamenti che non dovrebbero tenere, ehm, se sanno che le loro sessioni vengono

monitorate e sottoposte a verifica.

Pertanto, ritengo che questi siano aspetti importanti per rafforzare la sicurezza dell’accesso con privilegi.

Aggiungiamo poi la verifica continua.

La verifica continua è un po’ come lo zero trust, ma è uno zero trust in tempo reale.

Quello che facciamo è verificare continuamente gli utenti e se dispongano o meno dell’accesso
necessario per svolgere le operazioni richieste.

Sapete, è molto importante ricordare che il fatto che un utente sia
stato autenticato per la prima volta non significa che sia considerato affidabile per tutto il tempo in cui è

online o per tutta la durata della sua sessione.

I token di sessione

possono essere rubati e le sessioni possono essere dirottate; in tal caso, possono essere prese in carico da malintenzionati che compiono azioni
rischiose.

È quindi importante verificare costantemente ciò che l’utente sta facendo durante la propria sessione e controllare
lo stato del dispositivo.

Se il dispositivo che accede alla sessione è aziendale o se si tratta, per così dire, di un
dispositivo personale che potrebbe introdurre malware nella vostra

rete, è fondamentale tenerne traccia.

È necessario disporre di un qualche tipo di autenticazione rafforzata per le azioni rischiose.

Pertanto, se qualcuno accede e desidera elevare i propri permessi o creare un
account amministratore, dovrebbe essere richiesta una qualche forma di autenticazione a più livelli.

Un buon esempio è l’accesso al proprio servizio di online banking: quando si visita il
sito della banca e si effettua l’accesso con nome utente e password ed eventualmente con l’autenticazione a più fattori (MFA) se si utilizza una

buona banca, e si va semplicemente per controllare il proprio conto o per verificare le transazioni

ma poi si desidera trasferire una grossa somma di denaro su un altro conto, cosa che non
si fa mai.

La banca potrebbe richiederti un’autenticazione multifattoriale (MFA) aggiuntiva oppure potrebbe inviarti un’e-mail dicendoti: “Ehi,
inserisci il codice che ti abbiamo appena inviato via e-mail per confermare questa transazione”.

Questo è un esempio di autenticazione a più livelli.

È una misura facile da implementare nella vostra organizzazione e da applicare alle
azioni a rischio.

È necessario monitorare le sessioni per individuare eventuali anomalie.

Assicurati che, se si verificano anomalie in una sessione, l’utente venga sottoposto
a una nuova autenticazione.

Pertanto, se un utente che di solito non accede ai dati finanziari in SharePoint inizia a farlo
o a richiederne l’accesso, forse è il momento di richiedere una nuova autenticazione o di verificare quella

sessione e assicurarsi che sia ancora valida per l’utente.

Inoltre, dovreste adeguare il livello di rischio in modo dinamico in base al rischio

o in base a ciò che stanno facendo.

Prendiamo ad esempio il caso di cui abbiamo parlato prima, ovvero i viaggi impossibili.

Beh, supponiamo, ad esempio, che qualcuno durante la propria sessione inizi a compiere azioni rischiose alle 2
del mattino,

del mattino, quando il suo normale orario di lavoro va dalle nove alle cinque.

Beh, potreste voler assicurarvi che la sessione di quella persona non sia stata dirottata o
che il suo token non sia stato rubato e riutilizzato altrove da qualcuno all’estero o da qualcuno

che, ehm, stia cercando di compiere azioni dannose all’interno della vostra rete.

È necessario disporre di un metodo o di un modo per rilevare e interrompere immediatamente le sessioni
compromesse non appena si rileva la presenza di un rischio o si individua il coinvolgimento di

soggetti malintenzionati coinvolti.

Ok, ora che abbiamo chiarito la strategia, parliamo di alcune misure
pratiche che potreste adottare subito nella vostra organizzazione per implementare l’approccio zero trust nei vostri sistemi IAM.

So che questi consigli non saranno applicabili a ogni singola organizzazione.

Ho cercato di renderli di alto livello e pratici.

Ma questi sono alcuni spunti su cui potete riflettere e spero che vi diano idee su come
ottenere risultati positivi nella vostra organizzazione e implementare alcune delle politiche zero trust nella vostra

organizzazione.

Quindi, nei primi 30 giorni, penso che una delle cose migliori su cui concentrarsi sia l’applicazione dell’autenticazione a più fattori (MFA
) ovunque.

Se oggi non disponete dell’autenticazione a più fattori (MFA), questa è una soluzione che vi consentirà di ottenere risultati in tempi rapidissimi.

Se riuscite a implementare un sistema di autenticazione a più fattori (MFA) nella vostra organizzazione, qualcosa che richieda agli utenti un
codice di verifica, o se avete già l’autenticazione a più fattori ovunque, forse è il momento di

passare a un’autenticazione a più fattori resistente al phishing, ad esempio con lo standard FIDO2 o qualcosa
di simile.

Anche questa è un’ottima soluzione, facile da implementare nella vostra organizzazione e in grado
di rendere i vostri account molto più sicuri.

Iniziate anche a mappare i vostri silos di identità.

Individuate dove si trovano tutte le vostre identità, su quali “isole” sono collocate, dove
si trovano le vostre applicazioni cloud, quali piattaforme cloud state utilizzando e quali silos di identità si trovano

all’interno di queste.

Cercate di scoprire dove si trova tutto e fate un’analisi molto approfondita.

Successivamente, dovrete bloccare i vostri account amministrativi e quelli di servizio.

Si tratta di un’operazione che può essere effettuata fin dal primo giorno.

Rendili più sicuri, in qualunque modo tu lo faccia, anche se solo in misura minima.

Iniziate con piccoli passi incrementali per rendere più sicuri quegli account amministrativi e non consentire
a nessuno di avere privilegi permanenti per agire all’interno della vostra organizzazione.

Nei primi 30 giorni, è importante ottenere risultati concreti.

È importante giustificare

perché questo progetto Zero Trust sia importante.

Nei successivi 90 giorni, lavorate per garantire la coerenza.

Avviate il vostro piano di consolidamento delle identità.

Iniziate a mettere in atto il consolidamento delle identità.

Unire tutte le “isole” di identità, unire i silos.

Assicuratevi di arrivare a un’unica identità per persona.

Definite come sarà il vostro quadro normativo.

Anche se non lo implementate ancora, è importante iniziare a definirlo, insieme alla gestione del
ciclo di vita.

Come sarà il vostro processo relativo al ciclo di vita?

In che modo gli utenti vengono inseriti nella vostra organizzazione?

Come avviene la loro uscita dall’organizzazione?

Come gestisci le dimissioni che si verificano nella tua organizzazione?

Come cancellerete i loro account?

È importante definirlo fin dall’inizio, in modo che, man mano che la vostra organizzazione cresce, possiate implementare
l’automazione.

Inoltre, implementate il monitoraggio dello stato dei dispositivi.

Se non l’avete già fatto, è importante esaminare i vostri dispositivi per assicurarvi che
siano affidabili e che le persone che li utilizzano

dispongano di dispositivi affidabili, magari con un’immagine aziendale o conformi a uno
standard specifico dell’azienda, e contrassegnare come a rischio quei dispositivi che non soddisfano

tali standard.

E poi create quegli account di classe di interruzione.

Non vogliamo che Bob muoia, non vogliamo che Bob lasci l’organizzazione e non vogliamo
perdere l’accesso a quel server nell’armadio polveroso a cui solo Bob ha accesso.

Quindi assicuratevi di creare questi account di classe “break” il più rapidamente possibile.

E poi lavorate per raggiungere la maturità a lungo termine.

Ampliate il vostro consolidamento.

Assicuratevi di arrivare a quella “unica fonte di verità”, che si tratti del sistema ER o di
un sistema IDAS.

Passate a una forma di autenticazione più avanzata.

Per voi potrebbe trattarsi di un’autenticazione senza password basata su qualcosa come FIDO2.

Adoro davvero l’autenticazione.

Potrei parlarne per ben 30 minuti.

Ma l’autenticazione senza password è qualcosa che i vostri utenti apprezzeranno davvero e che
, a mio avviso, vi garantirà una sicurezza molto maggiore.

Le password semplicemente non sono un metodo sicuro per autenticare l’utente.

Assicuratevi di integrare il monitoraggio comportamentale nella vostra verifica o nel controllo continuo
.

Come ho già detto, si tratta di comportamenti come l’accesso alla rete alle 2 del mattino

quando normalmente si lavora dalle 9 alle 5.

Questo è un esempio di monitoraggio comportamentale che potete aggiungere alle vostre sessioni per aumentare
la sicurezza.

Aggiungete l’automazione alla governance del ciclo di vita e al

ciclo di vita delle identità.

In questo modo, quando un utente entra a far parte dell’organizzazione, gli viene immediatamente concesso l’accesso di cui ha bisogno.

E quando lascia l’organizzazione, perde completamente l’accesso di cui disponeva, in
modo da garantire che non vi siano account orfani e da proteggere la propria

rete.

Applicate poi le vostre politiche come codice per garantire un'applicazione coerente.

Trattate le vostre politiche come codice.

Disponete di un repository delle politiche, per così dire.

Assicuratevi di testare le vostre politiche di tanto in tanto.

Assicuratevi di disporre di un controllo delle versioni per le vostre politiche e che queste vengano trattate come codice, con
operazioni di check-in e check-out ogni volta che vengono modificate.

Spero quindi di avervi fornito informazioni sufficienti per capire come implementare una politica zero trust
per i vostri sistemi IAM e rendere davvero la vostra rete più sicura.

Ci sono un paio di cose che vorrei ricordaste di questa sessione.

Voglio che ricordiate che è importante migliorare la vostra “igiene delle identità”.

Le identità stanno aumentando a dismisura,

le identità nel New Perimeter, e assicuratevi di avere un piano che apporti
alcuni miglioramenti, che si tratti di consolidamento, di ripulire quei silos e quelle

o semplicemente l’applicazione di politiche e prassi coerenti in tutta la vostra
organizzazione.

Cercate sempre di implementare qualcosa che vi dia un vantaggio, nel caso in cui un malintenzionato
dovesse entrare in possesso di una delle vostre identità.

E una cosa davvero importante da ricordare di tutta questa presentazione è che

la fiducia non è qualcosa che si concede una sola volta quando l’utente effettua l’autenticazione.

È qualcosa che dovrebbe essere continuamente verificata in base alle azioni dell’utente e
a ciò che sta facendo all’interno della vostra organizzazione.

E quindi dovrebbe essere un aspetto monitorato costantemente.

Spero quindi che questo vi sia stato utile.

Se dovessi consigliarvi alcuni passi successivi da compiere, un paio di questi sarebbero
quelli di guardare un podcast on-demand.

Abbiamo un podcast o un webcast dedicato alla resilienza dell’identità in Active Directory.

È un ottimo webcast e vi consiglio vivamente di guardarlo.

Inoltre, potete approfondire il tema della cyber-resilienza e scoprire come Commvault contribuisce a migliorarla
iscrivendovi a un workshop sulla cyber-resilienza o seguendo un corso di preparazione alla cyber-resilienza

Readiness, e i link per accedervi sono proprio lì sullo schermo.

Vorrei ringraziarvi tantissimo per il tempo che mi avete dedicato oggi e per la vostra
attenzione.

Spero davvero che questo vi sia d’aiuto nel vostro percorso verso un modello “zero trust” per i vostri sistemi di messaggistica istantanea
in futuro.

Grazie mille per la vostra presenza oggi e grazie mille per aver partecipato.