Oltre il perimetro: implementazione dell’IAM Zero-Trust inCloud ibridi 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. 

Si parla di “proliferazione delle identità” quando account, credenziali e autorizzazioni sono distribuiti su piattaforme non interconnesse, 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, il che rende difficile proteggerle manualmente. 

Unificando i sistemi di gestione delle identità, applicando un’autenticazione forte, verificando costantemente gli accessi eeliminando la fiducia implicita tra i sistemi. 

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

Per la trascrizione con l’indicazione dei tempi, guarda il videoqui

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
niente che abbia a che fare con i film.

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

Ecco alcuni degli obiettivi principali che tratteremo nel corso di questa presentazione.

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

Tratteremo inoltre i principi fondamentali dell’approccio 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 mettere in atto per unificare, rafforzare
e controllare 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 passaggi concreti da seguire per implementare il modello Zero Trust nella vostra

sistema IAM 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

affrontare 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 quella che ritengo sia la cosa più importante da ricordare è che

L’identità è il nuovo confine.

Un tempo la nostra sicurezza si limitava 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 pubblicato sulla rivista CSO Magazine nel 2012, i nostri dati
I mercati stanno diventando sempre più 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 in loco in cui ci troviamo
protetti da un firewall e da una VPN.

Ma siamo andati ben oltre.

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

e utilizziamo anche molte piattaforme cloud.

Ehm… Le nostre soluzioni di messaggistica istantanea sono davvero messe a dura prova da questo problema e Geoff Cairns ne parla in un
articolo che ha scritto per presentare il Forrester Wave™.

Egli sostiene che le attuali piattaforme di messaggistica istantanea siano caratterizzate da una proliferazione delle identità e degli account utente
credenziali multiple distribuite su sistemi isolati, con conseguente gestione inadeguata delle identità

.

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

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

CyberArk, nel 2025, in uno studio di analisi del panorama del settore, ha rilevato che le identità delle macchine da loro
analizzate presso i clienti

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 corrispondesse 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: è davvero un problema 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 dimostrato che una strategia
Il multi-cloud è una soluzione 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
iCloud.

Aggiungiamo quindi 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 dei propri sistemi IAM.

E ciascuno di questi sistemi IAM ha un proprio linguaggio.

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

Insomma, ci sono alcuni concetti simili, no?

Ma il linguaggio e la procedura utilizzati in Active Directory e quelli utilizzati 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 a
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 su tutte le piattaforme e in tutte le applicazioni.

Inoltre, le fusioni e le acquisizioni contribuiscono al problema.

Abbiamo quindi 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 comportare problemi di “igiene delle identità” a cui prima non avevamo nemmeno pensato
in considerazione.

Lavoravo per un’organizzazione e, tra l’altro, non farò nomi per
assicurarmi che i colpevoli siano protetti.

Ma lavoravo per un’organizzazione molto attiva nel settore delle fusioni e delle acquisizioni.

Abbiamo condotto 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

relative alle 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 ci ha creato un bel problema.

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

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

Pertanto, la gestione delle identità diventa una questione non da poco 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 garantire una maggiore sicurezza.

Il primo è: non fidarsi mai e verificare sempre.

Ogni singolo utente, ogni singolo dispositivo,

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

Dovete assicurarvi che dimostri la propria identità e che sia un soggetto
affidabile, in grado di accedere alla vostra rete e di eseguire operazioni al suo interno.

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

Pertanto, agli utenti dovrebbe essere concesso solo l’accesso necessario per svolgere un compito o la propria mansione lavorativa 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 comprenda tutti e tre questi elementi o almeno
due di queste, se al momento non è possibile applicarle tutte e tre nella vostra rete.

È molto importante.

Le decisioni relative all’accesso devono basarsi sul contesto e sulla situazione di sicurezza.

Cosa significa?

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

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

l’indirizzo IP del suo computer cambia in uno che potrebbe trovarsi
in California, e inizia a svolgere attività online 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 si tratti ancora della stessa persona

che ha dichiarato di trovarsi al momento dell’autenticazione.

Pertanto, verificare lo stato del dispositivo

e il contesto è estremamente importante.

A ciò si aggiunge poi la verifica continua.

Assicurati che la persona che hai già autenticato in passato continui a dimostrare di essere affidabile
per tutta la durata della sessione.

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

di verificarne nuovamente l’identità oppure

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

Un altro grande vantaggio dell’approccio zero trust è che si dovrebbe sempre presumere che si sia verificata una violazione o tenere presente questa possibilità
una mentalità basata sulla “presunta violazione”, giusto?

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

E penso che sia 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

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

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

e nei vostri sistemi di gestione delle identità.

Quali sono quindi alcune strategie che possiamo adottare 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 il modo più semplice per tenerle tutte sotto controllo è abbattere i silos oppure
abbattere 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, può trattarsi di un sistema delle risorse umane: quando le
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
, qualcosa del genere.

Il punto fondamentale in questo caso è 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 integrare tale identità su più sistemi e su più
servizi, qualora sia prevista un’unica identità per utente.

E questo è il passo successivo.

Quello che dovete fare è consolidare quell’identità.

Ho un ottimo esempio tratto da un’organizzazione con cui ho collaborato in passato.

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

Abbiamo implementato un servizio FTP.

Quel servizio FTP non poteva essere federato

con la nostra strategia di federazione standard.

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
quello aziendale e quello cloud.

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

Dopodiché doveva effettuare l’accesso alla nostra piattaforma cloud

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

E infine doveva accedere al servizio FTP utilizzando un nome utente, una password e una
MFA.

E tutte queste credenziali avevano lo stesso nome.

Pertanto, ogni volta che chiamavano l’help desk e avevano un
Se qualcuno aveva 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 cosa avessero problemi, e loro non erano in grado di
spiegarci in modo semplice di cosa 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, disporre di un’unica identità semplifica notevolmente l’unificazione delle politiche e dei modelli di accesso basati sui ruoli tra
le diverse piattaforme.

E poi, quando si arriva ad automatizzare la gestione del ciclo di vita e la governance degli utenti
, è molto, molto più facile con un’unica identità e un quadro delle identità ben definito.

Passiamo ora al rafforzamento della sicurezza degli accessi privilegiati.

Anche questo è molto importante.

Una delle cose da fare è considerare gli amministratori come identità
a più alto rischio all’interno dell’organizzazione.

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

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 di alto livello in ogni momento.

Nessun amministratore dovrebbe disporre di privilegi elevati in ogni momento.

Semplicemente non ne hanno bisogno.

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

È necessario introdurre 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 intendono 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 svolgere quella specifica funzione che gli abbiamo consentito
da eseguire.

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

Dovreste inoltre creare una sorta di conto di emergenza da tenere sotto controllo.

Ho una storia fantastica a questo proposito.

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 per cavi 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 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 che gli account siano

sessioni monitorate e controllate, account che puoi “prelevare” e “riconsegnare” per eseguire
le operazioni di massimo livello, come ad esempio l’accesso con privilegi di root a 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 forte.

Sarebbe un’azione molto distruttiva se, ad esempio, gestisse 50
account contemporaneamente e apportasse una modifica che avesse un impatto significativo sulla vostra organizzazione.

Vorreste poter disporre di un meccanismo che richieda la doppia autenticazione oppure
la doppia approvazione per quella specifica azione, in modo che quando Bob apporta quella modifica,

debba ottenere l’approvazione da qualcun altro; magari una figura di livello superiore all’interno dell’organizzazione
dovrebbe approvare anche quell’iniziativa.

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 operazioni

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 queste operazioni vengono sottoposte a verifica e registrate.

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

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

monitorate e sottoposte a verifica.

Quindi penso che questi siano aspetti importanti per rafforzare la sicurezza degli accessi 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 costantemente gli utenti e se dispongano o meno dell’accesso
necessario per eseguire le operazioni richieste.

Sapete, è molto importante ricordare che il fatto che un utente sia
il fatto che 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 monitorare costantemente le azioni dell’utente durante la sua sessione e verificare
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 nel vostro

rete, è fondamentale tenerne traccia.

È necessario disporre di un sistema di autenticazione a più livelli per le operazioni che comportano rischi.

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

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

una buona banca, dove basta semplicemente controllare il proprio conto o visualizzare le transazioni

Ma poi si desidera trasferire una somma ingente di denaro su un altro conto, cosa che non
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, in caso di anomalie durante una sessione, l’utente venga sottoposto a
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 verificare 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.

Diciamo, ad esempio, che abbiamo parlato di, ehm, viaggi impossibili.

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

al 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, sta 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
vengono adottate misure 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 lo zero trust nei vostri sistemi IAM.

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

Ho cercato di renderli di alto livello e pratici.

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

organizzazione.

Quindi, nei primi 30 giorni, penso che alcuni degli aspetti più importanti su cui concentrarsi siano l’implementazione dell’autenticazione a più fattori (MFA
) ovunque.

Se al momento non disponete dell’autenticazione a più fattori (MFA), questa è una soluzione che vi garantirà risultati immediati.

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

potreste voler passare a un sistema di autenticazione a più fattori resistente al phishing, ad esempio basato sullo standard FIDO2 o qualcosa del genere
e simili.

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

Iniziate inoltre a mappare i vostri silos di identità.

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

all’interno di queste.

Cercate di capire dove si trova ogni cosa e fate un’analisi molto approfondita.

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

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

Rendili più sicuri, in qualunque modo tu lo faccia, anche se si tratta solo di misure minime.

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

Nei primi 30 giorni è importante ottenere risultati concreti.

È importante motivare

perché questo progetto Zero Trust sia importante.

Nei 90 giorni successivi, impegnatevi a garantire la coerenza.

Avvia il tuo piano di consolidamento delle identità.

Iniziate a mettere in atto il processo di consolidamento delle identità.

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

Assicuratevi che ogni persona abbia un unico identificativo.

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?

Come gestite le dimissioni che si verificano nella vostra organizzazione?

Come cancellerete i loro account?

È importante definirlo fin dall’inizio, in modo che, man mano che l’organizzazione matura, sia possibile 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

uno standard narrativo.

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 nel ripostiglio polveroso a cui solo Bob ha accesso.

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

E poi impegnatevi per raggiungere la maturità nel lungo periodo.

Ampliate il vostro consolidamento.

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

Passate a una modalità di autenticazione più avanzata.

Per voi potrebbe trattarsi di un’autenticazione senza password basata su uno standard simile a FIDO2.

Adoro davvero l’autenticazione.

Potrei parlare per ben 30 minuti solo di questo.

Ma l’autenticazione senza password è una funzionalità 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 accennato, si tratta di comportamenti come l’accesso a Internet alle 2 del mattino

quando di solito si lavora dalle 9 alle 5.

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

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

del 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
in modo da poter garantire che non vi siano account orfani e da poter proteggere la propria

rete.

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

Considerate le vostre politiche come se fossero codice.

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

Assicuratevi di verificare le vostre politiche di tanto in tanto.

Assicuratevi che le vostre politiche siano soggette a un sistema di controllo delle versioni e che vengano gestite come codice, con
le operazioni di check-in e check-out quando 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 che teneste a mente riguardo a questa sessione.

Voglio che teniate presente 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’adozione di politiche e prassi coerenti in tutta la vostra
organizzazione.

Cercate sempre di mettere in atto qualcosa che vi dia un vantaggio, nel caso in cui un malintenzionato
dovesse appropriarsi di una delle vostre identità.

E una cosa davvero importante da tenere a mente di tutta questa presentazione è che

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

È un aspetto che dovrebbe essere costantemente verificato in base alle azioni degli utenti e
a ciò che fanno all’interno della vostra organizzazione.

E quindi dovrebbe essere un aspetto da monitorare costantemente.

Spero quindi che questo vi sia stato utile.

Se ci sono dei passi successivi che potrei consigliarvi di compiere, un paio di questi sarebbero
quelli di guardare un podcast on demand.

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

È un ottimo webcast e vi consiglio vivamente di guardarlo.

Inoltre, potete approfondire il tema della cyber-resilienza e scoprire in che modo Commvault contribuisce a garantirla
iscrivendovi a un workshop sulla resilienza informatica o seguendo un corso di preparazione alla resilienza informatica

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

Vorrei ringraziarvi di cuore 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 aver partecipato oggi e grazie mille per essere stati con noi.