Un piano per l'architettura Zero Trust

Un piano per l'architettura Zero Trust

Guida pratica all'implementazione, a cura di Charlie Gero, Chief Technology Officer di Akamai

SINTESI ESECUTIV A WHITE P APER

akamai.com | 2

Sommario

Architetti di rete, tecnici della sicurezza, CTO, CISO e altri responsabili IT e decisionali possono trarne vantaggio.

Il piano fornirà ai responsabili di definizione dell'ambito, configurazione, distribuzione, implementazione e gestione di tale sistema Zero Trust una metodologia a più livelli per l'adozione e l'esecuzione.

I leader troveranno indicazioni e punti di discussione che li aiuteranno a posizionare meglio il modello Zero Trust internamente e a realizzare in modo più efficiente un'architettura Zero Trust.

A chi è destinata questa guida?

Una breve storia dell'architettura di rete 3

L'ascesa del cloud 4

Un'architettura di sicurezza Zero Trust 5 Servizi per la sicurezza sull'edge di Akamai 6 Confronto tra l'accesso alle applicazioni

e alla rete 8

Pianificazione del modello Zero Trust 12

Stato finale desiderato 13

Accesso alle applicazioni 13

Protezione dalle minacce 14

Visualizzazione dell'architettura 14

Come realizzare i risultati prefissati 15 Presupposti per la pre-installazione 16 Raggruppamento degli utenti 17 Metodologia di raggruppamento degli

utenti 18 Fasi dell'implementazione dell'applicazione 18

1. Fase della verifica preliminare

dell'applicazione 19 2. Fase della preparazione del proxy di

accesso 20 3. Fase di registrazione del laboratorio

di test 21

4. Fase di aggiornamento della sicurezza 22 5. Fase di incremento delle performance 24 6. Fase di registrazione degli utenti esterni 25 7. Fase di registrazione degli utenti interni 26 8. Fasi di migrazione della VLAN 27 Operazioni post-installazione 28 Riepilogo e passaggi successivi 28

Tra tutti i cambiamenti che si sono verificati negli ultimi anni, un solo aspetto è rimasto ostinatamente costante: la basilare architettura di rete hub e spoke utilizzata dalla maggior parte delle aziende.

Questa architettura una volta aveva un senso. Tanto tempo fa, prima che Internet diventasse un vivace luogo di attività commerciali e un'infrastruttura centrale, le aziende affidavano i loro carichi di lavoro ai data center. Tali data center ospitavano l'infrastruttura di importanza critica e le applicazioni.

Mano a mano che anche le filiali, i punti vendita al dettaglio e le sedi satellite passarono sul web, anch'esse avevano bisogno di accedere alle applicazioni centralizzate. Le aziende costruirono le loro reti in modo da rispecchiare tale esigenza, affidando tutto il backhauling di rete ai loro data center principali. Dopo tutto, il data center era la sede centrale in cui si svolgevano tutte le attività aziendali.

Con il passare del tempo, Internet iniziò a emergere come effettivo elemento di disturbo delle attività commerciali. Naturalmente, le aziende e gli operatori che si erano occupati della creazione di reti globali private complesse cercarono di soddisfare queste richieste facendo ciò che sapevano fare meglio:

implementare tali servizi aziendali e consumer

negli stessi data center su cui erano ospitate le loro applicazioni interne e acquistare i collegamenti Internet necessari per fornire un percorso verso di essi. Ciò servì casualmente a un duplice scopo: gli utenti esterni potevano entrare e i dipendenti interni dislocati in una miriade di filiali potevano uscire.

In quel momento, la rete hub e spoke era ancora la regina delle architetture di rete.

Nel corso del tempo, gli autori delle minacce iniziarono a trarre vantaggio da questa architettura dando il via a un settore completamente nuovo: lo stack di sicurezza dei data center. Dal momento che l'architettura hub e spoke incanalava il traffico Internet nei data center, si iniziarono a sviluppare grandi e potenti "scatole" per proteggere queste linee ad alta capacità. I firewall, i rilevatori delle intrusioni e i sistemi di prevenzione regolavano il traffico in entrata, mentre i gateway web sicuri (SWG) applicavano le policy di utilizzo in uscita.

La proliferazione di questi sistemi di sicurezza impiegati in punti di ingorgo centralizzati

cementò ulteriormente la rete hub e spoke come l'architettura di rete dominante. Per un certo periodo di tempo, l'approccio alla sicurezza che vedeva l'organizzazione come un castello da difendere attraverso la costruzione di mura e fossati sembrava valido e il concetto di una rete perimetrale in cui coloro che sono all'esterno sono cattivi e quelli all'interno sono buoni è rimasto dominante.

Ma il cloud ha cambiato tutto questo. Le misure di sicurezza devono ora soddisfare gli utenti e le applicazioni dove si trovano, al di fuori del perimetro.

Una breve storia

dell'architettura di rete

akamai.com | 4

Fig. 1: Con la sicurezza del perimetro tradizionale, un malintenzionato può sfruttare un punto debole del perimetro e, una volta all'interno, spostarsi lateralmente per accedere alle risorse

Gateway e-mail

Applicazioni Secure Web

Gateway

Firewall Rete privata

virtuale

Perdita di dati e prevenzione

Sistema di rilevamento

delle intrusioni

Sistema di prevenzione

delle intrusioni Utenti

Database

Server Dispositivi

Sicurezza del perimetro tradizionale

In poche parole, le applicazioni sono in movimento.

Ma non sono le sole. La forza lavoro e il posto di lavoro odierni sono cambiati: il luogo, l'orario e il modo in cui le persone lavorano vanno ben oltre le quattro mura di un ufficio.

Di conseguenza, il perimetro della rete non esiste più, perlomeno non in forma riconoscibile. Gli utenti e le applicazioni si trovano molto spesso al di là del fossato e non al suo interno. Inoltre, con minacce persistenti e avanzate, è molto probabile che si possa far entrare inavvertitamente utenti malintenzionati all'interno del perimetro e che essi abbiano accesso completo alle risorse più preziose.

Nell'attuale mondo moderno, utilizzare un approccio alla sicurezza e all'accesso adatto 20 anni fa è

nel migliore dei casi un approccio disallineato e nel peggiore dei casi pericoloso. Come afferma Forrester Research:

L'ascesa del cloud

"L'economia dei dati rende inutile l'attuale sicurezza basata sul perimetro della rete. Man mano che le aziende monetizzano le informazioni e gli approfondimenti in un complesso ecosistema aziendale, l'idea di un perimetro aziendale diventa pittoresca, perfino pericolosa."

— Forrester, Come rendere le aziende digitali a prova di futuro con la sicurezza Zero Trust

Architettura di sicurezza tradizionale

Realtà moderna

Fig. 2: Non esiste più un interno affidabile e un esterno non affidabile

Utenti Applicazioni Dispositivi

Sedi delle filiali

Non si tratta meramente di una teoria. Ciò risulta evidente dall'enorme quantità di violazioni dei dati a cui abbiamo assistito negli ultimi cinque anni, la maggior parte delle quali si è verificata in seguito ad un abuso di fiducia all'interno del perimetro di rete.

Per accrescere ulteriormente il problema, applicazioni che sono state progettate per un utilizzo all'interno di un perimetro di rete spesso dispongono dei peggiori profili di sicurezza. Dopo tutto, se 10 anni fa uno sviluppatore presupponeva che solo i dipendenti autorizzati e in buona fede potessero accedere al sistema, sarebbe stato prudente come un codificatore di oggi, conscio del fatto che vasti eserciti di hacker cercheranno di sfruttare la vulnerabilità della sua applicazione basata su Internet?

Quindi, cosa si può fare?

John Kindervag, uno dei principali leader del settore e analista di Forrester, propose una soluzione

denominata "Zero Trust". Il principio alla base è piuttosto semplice, ma molto potente: l'attendibilità non è un attributo che dipende dalla posizione.

Non ci si dovrebbe fidare di qualcosa semplicemente perché si trova dietro al firewall aziendale. Al contrario, si dovrebbe adottare una visione molto pessimistica riguardo alla sicurezza, considerando ogni computer, utente e server non attendibili fino a prova contraria.

Il metodo per provare l'attendibilità di questi componenti è basato su un potente sistema di autenticazione e autorizzazione e sul divieto di trasferire i dati finché non viene stabilita tale attendibilità. Inoltre, andrebbero eseguite operazioni di analisi, filtraggio e registrazione per verificare la correttezza dei comportamenti e si dovrebbe rimanere sempre vigili riguardo a eventuali segnali che indicano compromessi di qualsiasi tipo.

Questo fondamentale cambio mette fine a una cospicua quantità di compromessi a cui abbiamo assistito nell'ultimo decennio. Gli utenti malintenzionati non possono più sfruttare i punti deboli del vostro perimetro e quindi accedere alle applicazioni e ai dati sensibili, perché sono riusciti a superare il fossato. Ora non esiste più alcun fossato. Esistono solo le applicazioni e gli utenti, ciascuno dei quali deve autenticarsi reciprocamente e verificare l'autorizzazione

Un'architettura di sicurezza Zero Trust

Dati SEDE

CENTRALE

akamai.com | 6 La rete viene

sempre considerata ostile

Le minacce esterne e interne sono sempre presenti sulla rete

La posizione di rete non è sufficiente per decidere l'affidabilità di una rete

Ogni dispositivo, utente e flusso di rete viene autenticato e autorizzato

Le policy devono essere dinamiche e calcolate da quante più origini dati possibile

Come raggiungere questo scopo?

Esistono diverse metodologie per distribuire un'architettura Zero Trust. Una strategia comune è un'architettura proxy di accesso eseguita interamente all'interno della propria DMZ. Ma questo limita la capacità del cloud di assorbire gli attacchi, di fornire una larghezza di banda illimitata per la memorizzazione nella cache e di scalare automaticamente le risorse in base alle necessità.

SaaS

Client di Enterprise Application Access Connettore di Enterprise Application Access

Non basato su client

IaaS

In sede Salesforce Microsoft

365

AWS, Azure, Google Cloud Platform Akamai Intelligent Edge Platform

Basato su client

Akamai IdP

MFA / SSO Comportamento / Rischio*

Motore di policy Accesso al proxy

IdP di terze parti

Web Exchange

SSH RDP

*Client necessario

Servizi per la sicurezza sull'edge di Akamai

Fig. 3: La soluzione ZTNA basata su cloud di Akamai applica in modo continuo e dinamico le decisioni di accesso

I principi del modello Zero Trust

Akamai è un'azienda che si è basata sul cloud e ha lavorato sull'edge sin dalla sua fondazione, più di 20 anni fa. Abbiamo progettato una tecnologia ZTNA (Zero Trust Network Access), un proxy basato sulle identità, ma che risiede nel cloud, scala on demand, esegue risorse ad utilizzo intensivo della CPU sulla nostra piattaforma invece che sui vostri dispositivi, assorbe gli attacchi e fornisce i contenuti memorizzati nella cache più vicino agli utenti mediante metodologie basate o meno su client, a seconda del tipo di applicazione. Questo processo è denominato Enterprise Application Access e presenta questo aspetto:

normale autenticazione, l'autenticazione multifattore (MFA) e il Single Sign-On (SSO) e quindi vengono eseguite le funzioni di identità dei dispositivi. Inoltre, su questo POP (Point of Presence) Akamai, il più vicino possibile all'utente, Akamai può applicare servizi aggiuntivi quali WAF (Web Application Firewall), rilevamento bot, analisi comportamentale e memorizzazione nella cache. Ciò è progettato per fornire le migliori performance, nonché la possibilità di tenere potenziali vettori di minacce il più lontano possibile dalle vostre posizioni fisiche, applicazioni e dati.

Dopo che l'utente e il computer vengono autorizzati, la connessione da parte del client viene unita alla connessione in uscita dal connettore di Enterprise Application Access. Il traffico dalla sessione utente scorre attraverso questa connessione proxy basata sulle identità fino al connettore di Enterprise Application Access, che quindi si collega all'applicazione o al servizio richiesti. A questo punto, viene stabilito un percorso dati completo e tutte le decisioni relative all'accesso vengono applicate continuamente e dinamicamente in base alle identità, ai dispositivi e al contesto dell'utente.

Controllo dei flussi di rete tra tutte le risorse

Concessione delle identità e dell'accesso al cloud

Autenticazione e autorizzazione

Confronto tra l'accesso alle applicazioni e alla rete

Accessi utente basati sul principio del privilegio minimo a tutte le applicazioni (IaaS, SaaS e in sede)

Eliminazione delle VPN

Inserimento dei servizi

Sicurezza sull'edge

Miglioramento delle performance delle applicazioni

Protezione migliorata contro minacce avanzate In questa architettura, viene fornito l'accesso alle

applicazioni e non all'intera rete aziendale. Tuttavia, invece di posizionare il proxy di accesso nella DMZ, si esegue una piccola macchina virtuale denominata connettore di Akamai Enterprise Application Access dietro il firewall. Non è necessario, né obbligatorio, che si trovi all'interno della DMZ. Il suo indirizzo deve trovarsi su uno spazio IP privato e non deve essere direttamente raggiungibile da Internet.

In effetti, dovrebbe essere molto simile a qualsiasi altra applicazione situata dietro il firewall.

All'avvio, il connettore di Enterprise Application Access stabilisce immediatamente una connessione criptata con la piattaforma Akamai. Una volta effettuata la connessione con Akamai, esegue il download della sua configurazione dai server Akamai per prepararsi alle connessioni del servizio.

Quando un utente delle applicazioni interne tenta di accedere a un servizio, viene indirizzato ad Akamai tramite un DNS CNAME e collegato all'Akamai Intelligent Edge Platform. Supponendo che l'utente finale e il relativo dispositivo superino tutti i controlli, vengono quindi instradati per l'esecuzione della

Funzionalità: Zero Trust Network Access

akamai.com | 8 I lettori potrebbero essere inclini a considerare

questo metodo di accesso come una VPN, ma si farebbero un danno da soli. Le VPN forniscono l'accesso al livello della rete. Akamai Enterprise Application Access elimina la necessità per un utente di accedere alla rete per ottenere l'accesso a un'applicazione.

Se scegliete una configurazione VPN semplice, probabilmente farete ciò che fanno la maggior parte delle aziende: consentirete agli utenti che hanno effettuato il login di disporre di un accesso di livello IP all'intera rete. Sappiamo quanto ciò possa essere pericoloso. Perché i dipendenti dei call center hanno un accesso IP agli archivi dei codici sorgente? Oppure perché un appaltatore che usa il vostro sistema di fatturazione dovrebbe avere accesso ai terminali di elaborazione delle carte di credito? L'accesso dovrebbe essere concesso solo agli elementi necessari per svolgere un determinato ruolo.

Per risolvere il problema, è possibile avviare la partizione delle applicazioni in segmenti separati dietro a un firewall tramite le VLAN e applicare le arcaiche regole basate sugli intervalli IP per utenti singoli o gruppi in corrispondenza dell'aggregatore di VPN. Tuttavia, questa operazione è precaria e decisamente soggetta ad errori. Magari qualcuno sta effettuando la manutenzione dei computer e li sta spostando in un nuovo rack oppure deve spostare nuovamente gli IP su un nuovo intervallo.

All'improvviso, tutti gli utenti vengono bloccati e iniziano ad arrivare telefonate di assistenza a raffica. O forse l'architettura di un'applicazione cambia durante un aggiornamento del software e gli utenti vengono reindirizzati su un altro computer come parte del workflow, ma quel computer è inaccessibile per determinati utenti o gruppi perché le regole del firewall non sono state aggiornate.

Questa architettura è estremamente complessa e richiede che tutte le modifiche abbiano un livello molto elevato di comunicazione tra proprietari delle applicazioni, amministratori di rete e gruppi di sicurezza per assicurare che non vi siano tempi di inattività.

Questo metodo di accesso presenta vantaggi distintivi e significativi. Le attività che dipendono maggiormente dalle performance e dalla sicurezza vengono svolte in prossimità dell'edge, più vicino all'utente finale, in cui Akamai dispone di più di 4.100 POP distribuiti in tutto il mondo. Inoltre, il percorso di ingresso sensibile all'applicazione avviene su un tunnel di applicazioni inverso, il che rimuove efficacemente la visibilità IP del perimetro e riduce il rischio di attacchi volumetrici.

La percentuale di CISO che non sono sicuri o non sono certi della capacità di valutazione della cyber sicurezza dei propri dipendenti

Gartner, Protezione della forza lavoro completamente remota

88 ^%

Confronto tra l'accesso alle

applicazioni e alla rete

Storicamente, abbiamo prove significative di ciò che accade quando il suddetto coordinamento non riesce. Gli amministratori desiderano seguire le procedure ottimali, ma, in casi disperati, viene aggiunta la temuta regola IP ANY/ANY ALLOW come correzione rapida per consentire agli utenti interessati di accedere a tutto, finché il problema sottostante non viene diagnosticato e risolto.

Ma spesso non c'è tempo per tornare indietro e correggere le falle del passato. Ancora una volta, per superare gli inconvenienti di sicurezza del libero accesso orizzontale, è necessario introdurre un livello significativo di complessità e costi fissi operativi se si utilizza una VPN, ma questa complessità spesso dà origine a falle e correzioni rapide, che peggiorano lo stato della sicurezza nel tempo.

Lo stesso compromesso si verifica riguardo alle performance. Nella forma più semplice di una VPN, tutto il traffico viene reindirizzato verso

l'infrastruttura del data center. Ciò può determinare un accesso estremamente lento alle proprietà di Internet e ai SaaS a causa dell'effetto a tornante, nonché una maggiore congestione sugli uplink di Internet all'interno del data center per il traffico non aziendale, come Facebook e YouTube. Perché eseguire il backhaul del normale accesso a Internet per un utente che si trova già fuori sede?

"Le architetture di sicurezza della rete che pongono il data center aziendale al centro dei requisiti di connettività rappresentano un ostacolo ai requisiti di accesso dinamico dell'azienda digitale."

— Gartner, Il futuro della sicurezza di rete è nel cloud

3,92 milioni di dollari

Costo medio di una violazione dei dati per le aziende

25.575

Numero medio di record in una violazione

150 dollari a livello globale/

242 dollari negli Stati Uniti

Costo medio di ciascun record

Fonte: IBM Security/Ponemon Institute, Studio 2019 sul costo di una violazione di dati

Le conseguenze di una violazione

akamai.com | 10 Per superare questo impatto sulle performance, gli

amministratori spesso implementano degli "split tunnel", contrassegnando gli intervalli IP che devono attraversare la VPN e quelli che devono uscire direttamente in Internet. Si tratta di un'operazione molto efficace e semplice se si dispone di un solo perimetro interno. Tuttavia, inizia a diventare molto più complessa se si aggiungono più data center e cloud privati virtuali (VPC) ai provider IaaS. Gli amministratori devono quindi determinare se installare gli aggregatori di VPN in ogni data center e come gestire in modo efficace gli split tunnel multipunto.

Ancora una volta, tutte queste soluzioni sono teoricamente possibili. Probabilmente state già utilizzando una loro combinazione. Il problema è che le attività necessarie per eseguirle bene, gestirle e fornire la sicurezza e le performance adeguate durante il ciclo di vita della loro implementazione sono spesso troppo complesse dal punto di vista operativo per essere sempre corrette. In molti casi, le aziende si convincono che il semplice fatto che i dipendenti riescano ad accedere alle loro applicazioni voglia dire che tutto funziona in modo ottimale. Poi vengono presi alla sprovvista quando una delle suddette correzioni rapide provoca una grave violazione o un peggioramento delle performance, con conseguente interruzione delle attività o una notevole riduzione della produttività dei dipendenti.

akamai.com | 10

Ciò non significa che le VPN non siano un valore.

Tutto il contrario. L'accesso site-to-site per

l'infrastruttura di più data center è uno dei casi in cui brillano. È vero però che l'accesso a livello di rete non è il paradigma corretto da utilizzare quando si discute di utenti che accedono alle applicazioni.

Ciò è dovuto al fatto che l'accesso a livello di rete impone un innaturale compromesso tra la semplicità da una parte e la sicurezza e le performance

dall'altra.

Ciò che rende così interessanti gli approcci basati su proxy, come Akamai Enterprise Application Access, è che offrono un accesso a livello di applicazione.

Con l'accesso a livello di applicazione, le performance e la sicurezza vengono svincolate dalla complessità.

Ciò è intrinsecamente ovvio e semplice da spiegare.

È sufficiente prendere tutte le applicazioni che si trovano vicine ad un'altra (ad esempio, ospitate nello stesso data center o sullo stesso VPC), inserirle in uno spazio IP di una rete privata o su una VLAN limitata, posizionare un proxy di accesso in quel micro-perimetro e il gioco è fatto.

I proprietari delle applicazioni impostano le loro proprie policy di sicurezza sul proxy di accesso (in riferimento a chi può accedere e perché) e, cosa ancora più interessante, gli utenti possono trovarsi ovunque. Non esiste più alcuna differenza tra gli utenti in sede e fuori sede perché non vi è alcun perimetro di rete che include gli utenti finali. Un dipendente che lavora da remoto o in una caffetteria è equivalente a un dipendente che si trova in ufficio.

L'unico aspetto che conta è se l'utente è autorizzato e se il computer è sicuro.

Con l'accesso a livello di applicazione, le

performance sono migliori, nonostante la semplicità di implementazione e utilizzo. Gli utenti devono semplicemente utilizzare Internet per accedere direttamente alle applicazioni, indipendentemente dalle posizioni in cui sono ospitate le applicazioni o in cui si trova l'utente, consentendo ad Internet di instradare i pacchetti verso la loro destinazione senza dover passare per aggregatori o intermediari che non si trovano sul percorso.

In realtà, con l'accesso a livello di applicazione, le reti interne spesso si dissolvono in semplici Wi-Fi guest. Occorre ricordare che, affinché la rete Zero Trust sia davvero efficace, non bisogna trattare gli utenti interni in modo diverso da quelli esterni.

Tutti devono essere considerati non attendibili per impostazione predefinita.

Con l'accesso a livello di

applicazione, le performance e la sicurezza vengono svincolate dalla complessità. E un dipendente che lavora da remoto o in una

caffetteria è equivalente a un dipendente che si trova in ufficio.

L'unico aspetto che conta è

se l'utente è autorizzato e se il

computer è sicuro.

akamai.com | 12

Quali difficoltà state riscontrando?

Quali sono i fattori di successo chiave?

Cosa sperate di risolvere?

Cosa prendere in considerazione:

Proteggere i vostri utenti.

Impedire al malware di infettare gli utenti.

Proteggere le vostre risorse.

Autenticare/autorizzare tutte le transazioni.

Conoscere i propri utenti.

Non fidarsi di nessuno di loro.

Pianificazione del modello Zero Trust

Riesame degli obiettivi principali

Accesso alle applicazioni

In una moderna implementazione Zero Trust, tutte le applicazioni devono essere segmentate nei propri micro-perimetri in base alla posizione e allo scopo.

Questi micro-perimetri devono trovarsi su VLAN private con uno spazio IP privato e devono essere direttamente accessibili solo dal proxy di accesso che si trova di fronte ad essi.

È discrezione di ogni azienda determinare se desidera fornire un'ulteriore micro-segmentazione all'interno dei micro-perimetri per interrompere l'escalation e il movimento orizzontale nel caso in cui un'applicazione venga compromessa. In questi esercizi, possiamo vedere il valore teorico, ma, in pratica, il livello di complessità necessario per mantenere corretti tali segmenti è spesso troppo elevato per giustificare una loro maggiore sicurezza.

Chiunque abbia tentato di sciogliere i punti di contatto che si nascondono dietro al perimetro di un'applicazione complessa può testimoniare quanto possa essere precario segmentare le applicazioni tra loro. Tuttavia, se il vostro ambiente permette tutto questo in modo semplice e gestibile ne incoraggiamo l'adozione.

Tutti gli utenti, indipendentemente dal fatto che siano in sede o fuori sede, dovrebbero essere obbligati ad accedere a tutte le applicazioni tramite i proxy di accesso basati sulle identità, come ad esempio Enterprise Application Access di Akamai, che eseguono non solo l'autenticazione standard, ma anche quella MFA. Inoltre, dovrebbero essere disponibili funzionalità affidabili per il comportamento dei dispositivi che richiedano criteri del dispositivo per fornire l'accesso a determinate applicazioni.

Inoltre, siamo convinti che l'approccio Zero Trust non termina con l'autenticazione e l'autorizzazione.

Uno stack moderno richiede anche un certo livello di ispezione e analisi del traffico che passa attraverso il proxy di accesso. Ciò aiuterà a proteggere dalle minacce persistenti avanzate e dagli utenti finali deliberatamente dannosi.

Un sistema di sicurezza fondamentale sul quale dovrebbero fare affidamento i vostri proxy di accesso è un WAF per garantire che i vostri utenti finali non sferrino (intenzionalmente o inavvertitamente) attacchi alle vostre applicazioni interne. È possibile sfruttare altri sistemi avanzati, come ad esempio il rilevamento di utenti umani/bot per i siti non API per garantire che nessun malware si nasconda dietro validi endpoint.

Man mano che rendete disponibili online e accessibili le vostre applicazioni tramite i proxy di accesso, la prevenzione DDOS diventa ancora più importante. Dovete allinearvi con provider che possono assorbire gli attacchi contro i vostri micro-perimetri e proxy di accesso, consentendo un funzionamento continuo con carichi di lavoro elevati.

Gli endpoint non sono più "vostri".

Il BYOD e la forza lavoro sempre più mobile hanno eliminato il controllo che l'IT aveva sugli

endpoint che si collegano alle reti aziendali e accedono ai dati.

— Forrester, Una guida pratica

all'implementazione di un modello Zero Trust

Stato finale desiderato

akamai.com | 14 Infine, per garantire che le performance delle

applicazioni siano di livello eccellente e che gli utenti non solo accettino questo cambiamento di accesso, ma lo promuovano, i vostri proxy di accesso devono essere in grado di offrire vantaggi in termini di performance. In particolare, i CDN e le sovrapposizioni di instradamento Internet usati dovrebbero essere parte del vostro arsenale, non solo per rendere disponibile l'accesso, ma per renderlo più performante rispetto alle precedenti metodologie.

Protezione dalle minacce

Soluzioni come Akamai Enterprise Application Access possono proteggere le vostre applicazioni da utenti malintenzionati. Ma come fare a impedire che gli utenti diventino inavvertitamente i vettori della compromissione: un dispositivo infettato da malware o credenziali rubate tramite un collegamento di phishing e una pagina di destinazione? È qui che la prevenzione e il rilevamento diventano cruciali per il traffico web.

Un approccio consiste nell'implementazione di una soluzione Secure Web Gateway basata su cloud come Akamai Enterprise Threat Protector.

Tale soluzione ispeziona ogni richiesta web degli utenti e applica l'intelligence sulle minacce in tempo reale e tecniche di analisi del malware avanzate per garantire che venga distribuito solo contenuto sicuro. Le richieste e i contenuti dannosi vengono bloccati in modo proattivo. E per fornire una protezione costante ovunque gli utenti si connettano, potete installare un agente leggero sui laptop.

Visualizzazione dell'architettura

Ad uno sguardo d'insieme, ci aspettiamo che i vostri utenti e le vostre applicazioni abbiamo un aspetto simile al seguente in un mondo Zero Trust completamente realizzato:

1 | Titolo presentazione qui | © 2018 Akamai | Informazioni riservate

Panorami

SSIICCUURREEZZZZAA ZZEERRO O TTRRUUSSTT

PPrrootteezziioonnee

ddaallllee mmiinnaaccccee AApppp

aazziieennddaallii D

Daattaa cceenntteerr

FFoorrnniittoorree ddii sseerrvviizzii IIaaaaSS XX

FFoorrnniittoorree ddii sseerrvviizzii

SSaaaaSS YY AAuuttoorree

ddeellll''aattttaaccccoo

PRODOTTI PRINCIPALI

Protezione dalle minacce ► Enterprise Threat Protector DDoS/WAF ► Kona Site Defender o Web Application Protector Accesso a identità e applicazioni ► Enterprise Application Access

W Weebb

PANORAM ICA

IIddeennttiittàà AAcccceessssoo

aallllee aapppp

66

D DDDooSS//

W WAAFF BBrroowwssee

rr CClliieenntt

AAuuttoorree ddeellll''aattttaaccccoo

11

EEDDGGEE PPLLAATTFFOORRMM

G Geessttiioonnee

22 33 44 55

Fig. 4: Un'architettura Zero Trust prevede, inoltre, che solo gli utenti e i dispositivi autenticati e autorizzati possano accedere alle Fig. 4: Un'architettura Zero Trust prevede, inoltre, che solo gli utenti e i dispositivi autenticati e autorizzati possano accedere alle applicazioni e ai dati, proteggendo, al contempo, le applicazioni stesse e gli utenti da avanzate minacce su Internet.

applicazioni e ai dati, proteggendo, al contempo, le applicazioni stesse e gli utenti da avanzate minacce su Internet.

Finora, abbiamo analizzato in modo abbastanza completo dell'approccio Zero Trust, incluso l'aspetto che dovrebbe avere un'azienda basata completamente sull'approccio Zero Trust. Tuttavia, esattamente come la sicurezza è migliore se è semplice, anche l'implementazione di nuove architetture deve essere semplice e suddivisibile in fasi. Nessuna azienda, indipendentemente dalle dimensioni, sarebbe in grado di convertire, di punto in bianco, tutta la sua infrastruttura a questa visione.

Dal momento che l'approccio Zero Trust è di per sé una strategia, lo è anche la sua implementazione.

Siamo convinti che l'approccio migliore per raggiungere una completa architettura Zero Trust sia quello di iniziare la transizione delle applicazioni verso un modello di accesso di accesso Zero Trust in piccoli lotti gestibili. La dimensione dei lotti varia in base alla quantità di risorse da poter dedicare, in quanto alcune aziende sono solo in grado di usarne una alla volta. Indipendentemente da ciò, ogni applicazione sottoposta a transizione passa attraverso diverse fasi per arrivare ad un completo approccio Zero Trust. In ciascuna fase, verificherete che l'applicazione funzioni correttamente e che l'autorizzazione venga applicata nel modo previsto.

Enterprise Application Access supporta applicazioni HTTP(S), VNC, RDP e SSH senza la necessità di installare un client. Sono anche disponibili la valutazione del comportamento dei dispositivi e i protocolli aggiuntivi tramite l'uso di un client.

Le decisioni di accesso possono essere prese in base all'intelligence di segnalazione delle minacce di terze parti, ad esempio se un dispositivo è stato compromesso o è conforme alle policy di sicurezza degli endpoint.

Per farlo correttamente, dovete:

Spiegare chiaramente che il modello Zero Trust è ciò che alla fine vi consentirà di ottenere la fiducia dei clienti. Zero Trust è un concetto di architettura progettato per proteggere le vostre risorse più preziose e pertanto di proteggere dipendenti, clienti e società.

Tradurre le esigenze tecnologiche in vantaggi aziendali. Dimostrate in che modo la vostra iniziativa Zero Trust consenta di attuare iniziative aziendali come la trasformazione digitale, la migrazione al cloud e l'abilitazione di una forza lavoro remota.

— Forrester, Una guida pratica all'implementazione di un modello Zero Trust

Come realizzare i risultati prefissati

Portate la vostra strategia e roadmap per il modello Zero Trust

direttamente al consiglio di amministrazione

akamai.com | 16 Presupposti per la pre-installazione

I seguenti presupposti si riferiscono allo stato di pre- installazione della vostra rete:

• Le applicazioni e gli utenti all'interno del perimetro attuale possono raggiungersi tra loro direttamente tramite il protocollo IP.

• È necessario aver installato un connettore di Akamai Enterprise Application Access nel proprio perimetro attuale.

• È necessario aver creato una VLAN chiusa per un eventuale posizionamento di applicazioni aziendali.

• È necessario aver installato un connettore di Akamai Enterprise Application Access nella propria VLAN chiusa.

• Gli utenti aziendali fuori sede continueranno ad avere una VPN installata durante il phasing, al fine di raggiungere tali applicazioni non ancora sottoposte a transizione.

Se questi prerequisiti sono soddisfatti, possiamo iniziare ad analizzare le fasi attraverso le quali passerà ciascuna applicazione nel suo cammino verso la transizione. Tali fasi sono state ideate per riflettere il più alto livello di granularità e, pertanto, potreste combinare alcune di esse mano a mano che vi abituate al processo.

Questi utenti saranno responsabili della verifica dell'integrità funzionale dell'applicazione quando verrà resa accessibile per la prima volta tramite Enterprise Application Access.

Questi utenti devono avere una sufficiente familiarità con la semantica operativa dell'applicazione per eseguire il test del comportamento standard e dei casi limite.

Mentre alcune funzioni di sicurezza e performance aggiuntive vengono disposte su più livelli, questi utenti dovrebbero avere anche il background necessario per verificare che la sicurezza si comporti nel modo previsto e che si ottengano effettivamente dei miglioramenti in termini di performance.

Incoraggiamo le organizzazioni con un ampio numero di applicazioni a prendere in considerazione l'investimento in strumenti che consentiranno l'esecuzione regolare di funzioni standard non specifiche per l'applicazione, come ad esempio i test di performance generici, e di determinati controlli di sicurezza, senza la necessità di una notevole

supervisione umana. È necessario eseguire specifici controlli di sicurezza con strumenti quali SQL injection, cross-site scripting e command injection.

Questo sarà il primo gruppo di utenti di produzione al quale verrà distribuito Enterprise Application Access e comprende tutti gli utenti validi che accederanno all'applicazione dall'esterno del perimetro di rete. Questo gruppo funzionerà in modo dinamico. In altre parole, a mano a mano che gli utenti si recano fuori sede, saranno inseriti dinamicamente in questo gruppo e, man mano che ritornano nel perimetro di rete, usciranno in modo dinamico.

Questo sarà il gruppo finale di utenti di produzione al quale verrà distribuito

Enterprise Application Access, completando il processo di migrazione a tutti gli utenti dell'applicazione. Questo gruppo è costituito da tutti gli utenti validi all'interno del perimetro di rete che accederanno a questa applicazione. Come il gruppo degli utenti esterni, l'adesione a questo gruppo è dinamica. Gli utenti verranno iscritti automaticamente a questo gruppo immettendo il perimetro della loro rete interna e faranno parte del gruppo degli utenti esterni all'uscita.

Parte del nostro processo di installazione delle applicazioni includerà una lenta eliminazione di questa funzione per selezionare gruppi di utenti.

Proponiamo di disporre di tre gruppi di utenti generali definiti per ciascuna applicazione:

Laboratorio di test

Utenti esterni

Utenti interni

Raggruppamento degli utenti

akamai.com | 18 Metodologia di raggruppamento degli utenti

Nel nostro esempio di phasing, utilizzeremo il prodotto Akamai Enterprise Application Access proxy di accesso. Akamai supporta applicazioni integrate nella sua rete distribuita attraverso l'uso di DNS: i nomi host delle applicazioni sono impostati sul CNAME verso Akamai per instradare gli utenti alla piattaforma.

Pertanto, gli utenti che effettuano ricerche del nome host che risultino nella catena CNAME verso Akamai saranno instradati verso la rete globale Akamai. Gli utenti le cui ricerche daranno come risultato la restituzione del record A interno originale continueranno ad accedere all'applicazione

utilizzando il metodo obsoleto del perimetro.

Sfrutteremo questa architettura come un modo per frazionare i diversi gruppi di utenti su Enterprise Application Access per ciascuna applicazione, controllando quali gruppi seguono la catena CNAME e quali utenti ricevono il record A interno.

Riusciremo in questo intento tramite l'utilizzo delle viste DNS, note anche come DNS ad orizzonte diviso, per definire i tre gruppi di utenti suddetti.

Una vista DNS è un metodo grazie al quale due o più utenti che effettuano una query esattamente per lo stesso nome possono ricevere risposte completamente diverse a seconda di quali sono i loro IP di origine. Un utente in Cina, ad esempio, che effettua una query per www.foo.asp, potrebbe ricevere un IP distinto, mentre un utente nel Regno Unito potrebbe ricevere un IP completamente diverso, anche se in realtà effettua una query per lo stesso nome host.

Utilizzeremo questo metodo organizzando i nostri diversi gruppi di utenti tramite i loro blocchi CIDR di origine. Tutti gli utenti del gruppo del laboratorio di test risiederanno in un unico blocco CIDR, il gruppo degli utenti interni sarà all'interno del blocco CIDR che definisce l'intera rete interna, mentre il gruppo degli utenti esterni si originerà da tutti gli IP che non corrispondono ai primi due gruppi.

Oggi tutti i server DNS comuni che le aziende implementano negli ambienti moderni supportano questa funzione. Una volta appreso come eseguire la partizione dei vari gruppi di utenti, possiamo iniziare a prendere in esame le fasi dell'effettiva implementazione dell'applicazione.

Le pagine seguenti descrivono le otto fasi di una corretta implementazione dell'applicazione, insieme ai fattori da considerare in ciascuna fase.

In caso di domande sui requisiti o sulla metodologia di migrazione di un'applicazione specifica in

qualsiasi momento, contattate l'Account Executive di Akamai o i nostri esperti di sicurezza qui.

Questa metodologia di

raggruppamento degli utenti è supportata da tutti i server DNS comuni implementati negli ambienti moderni dalle aziende odierne.

Fasi dell'implementazione

dell'applicazione

1. Fase della verifica preliminare dell'applicazione

In questa fase, si verifica se l'applicazione

soddisfa i requisiti del proxy di accesso che avete implementato. Nel caso di Akamai Enterprise Application Access, dovete accertarvi che l'applicazione sia un protocollo supportato.

Cosa prendere in considerazione:

Quali applicazioni presentano il maggiore problema per l'accesso remoto?

Quali gruppi di utenti utilizzano questa applicazione?

Dove vengono ospitate le applicazioni?

Quale ambiente virtuale viene utilizzato?

Quale sarebbe un risultato positivo durante un modello di verifica (POC)?

I protocolli non basati su client includono HTTP, HTTP(S), RDP o SSH. Le applicazioni TCP e UDP sono supportate con un client.

akamai.com | 20

2. Fase della preparazione del proxy di accesso

Successivamente, dovrete configurare il proxy di accesso in modo che riconosca l'applicazione, nonché la sua sicurezza e i suoi specifici diritti di accesso. Nel caso di Akamai Enterprise Application Access, dovrete configurare tutto ciò nel cloud.

Cosa prendere in considerazione:

Sono presenti proxy in uscita?

Quali origini di directory vengono utilizzate per l'autenticazione degli utenti?

Avete l'MFA associata alle applicazioni?

State cercando di estendere l'SSO per le vostre applicazioni in sede, cloud e pubbliche?

La configurazione verrà inviata immediatamente a tutti i connettori di Akamai Enterprise Application Access e all'intera piattaforma Akamai, in modo tale che tutti i POP Akamai possano fornire i servizi agli utenti finali.

3. Fase di registrazione del laboratorio di test

Ora che il proxy di accesso è in grado di

riconoscere l'applicazione in questione, è possibile iniziare l'onboarding degli utenti. In questa fase, supponendo che stiate utilizzando il proxy Akamai Enterprise Application Access, si procederà a modificare le viste DNS come indicato sopra, in modo che i membri del laboratorio di test vengano impostati sul CNAME verso Akamai per il nome host specifico dell'applicazione durante la ricerca.

Subito dopo questa operazione, i membri del laboratorio di test verranno indirizzati alla rete globale di Akamai ogni volta che tentano di accedere a una determinata applicazione.

Durante questo arco di tempo, i membri del laboratorio di test devono verificare che l'autenticazione funzioni correttamente, che l'MFA sia opportunamente configurata e che l'SSO sia compatibile con tutte le altre applicazioni integrate in precedenza. Aspetto ancora più importante, in questa fase devono essere condotti test approfonditi sulla corretta funzionalità

dell'applicazione.

Cosa prendere in considerazione:

Come accedono attualmente gli utenti a queste applicazioni?

Quali gruppi di utenti verranno testati?

Come verrà determinato il buon esito del processo?

Quanto tempo verrà concesso agli utenti per eseguire il test?

akamai.com | 22 Fasi dell'implementazione dell'applicazione

4. Fase di aggiornamento della sicurezza

Ora che i membri del laboratorio di test sono in grado di accedere in modo sicuro all'applicazione tramite Enterprise Application Access, dovreste prendere in considerazione l'attivazione di funzionalità di sicurezza avanzate che sarebbero altrimenti inimmaginabili nel tradizionale modello di perimetro. In questa sezione, faremo riferimento a prodotti per la sicurezza Akamai specifici che funzionano bene con, e sono abilitati per, il proxy Akamai Enterprise Application Access.

Tuttavia, sia che utilizziate o meno questi prodotti specifici, le raccomandazioni generali e la fase di implementazione restano valide.

Per ottenere la funzionalità WAF, si consiglia di abilitare almeno il prodotto Akamai Kona Site Defender. A questo punto, i membri del laboratorio di test devono verificare che gli attacchi di tipo SQL injection, cross-site scripting e command injection sferrati contro l'applicazione vengano respinti dalla piattaforma WAF.

È in questa fase che i proprietari delle applicazioni devono prendere in considerazione anche il rilevamento dei bot rispetto agli utenti umani come un'aggiunta semplice, ma incredibilmente potente, alla sicurezza. Se l'applicazione in questione non è un server API e non vi si deve mai accedere in modo programmatico, è possibile abilitare questa funzione tramite Akamai Bot Manager. È possibile ordinare alla piattaforma di rifiutare le connessioni nel caso in cui non sia possibile stabilire con un elevato grado di certezza, tramite analisi avanzate, se hanno un'origine umana. Tutto ciò costituisce un ottimo strumento per arrestare i malware e altre minacce persistenti avanzate che si mascherano dietro valide sessioni di utenti.

È in questa fase che si stabilisce se una determinata applicazione deve essere limitata solo ai dispositivi gestiti. In tal caso, se distribuite certificati ai

dispositivi finali, potete caricare il vostro certificato dell'autorità di certificazione pubblica su Akamai Enterprise Application Access, affinché possa rifiutare tutte le connessioni che derivano da unità non gestite.

Infine, è possibile abilitare anche restrizioni basate sull'area geografica e sull'IP. Se disponete di elenchi di elementi consentiti e non consentiti specifici basati sui CIDR da usare o se dovete negare l'accesso a determinate regioni geografiche, tali restrizioni possono essere attivate e verificate in questa fase.

Dopo aver protetto le vostre applicazioni, vi suggeriamo di prendere in considerazione le applicazioni non proprietarie, in particolare quelle disponibili su Internet. Come state proteggendo il traffico che accede a tali applicazioni aziendali basate sul web come G Suite o Dropbox?

Consigliamo di abilitare Akamai Enterprise Threat Protector, un SWG (Secure Web Gateway) basato su cloud che analizza e ispeziona tutto il traffico Internet tramite proxy.

Indipendentemente dalle funzioni abilitate, è durante questa fase che il laboratorio di test deve verificare che le opzioni di sicurezza non solo funzionino correttamente, ma anche che non ostacolino il corretto funzionamento dell'applicazione.

Cosa prendere in considerazione:

Sono necessarie restrizioni geografiche?

Come viene fornito il DNS agli utenti?

Che tipo di soluzione di gestione dei dispositivi mobili (MDM) è stata

adottata?

akamai.com | 24

5. Fase di incremento delle performance

Una volta configurata l'applicazione e implementata la sicurezza, il passo successivo è quello di considerare se le performance sono insufficienti. Nel tradizionale approccio all'accesso e alla sicurezza basato sul perimetro, le performance delle aziende sono spesso limitate a causa delle sedi dei data center e dei collegamenti associati all'azienda tra le sedi delle filiali.

A volte, è possibile implementare funzioni quali la memorizzazione nella cache in sede per ridurre l'impatto di questi problemi, ma queste funzioni sono insufficienti quando i dipendenti escono dalla sede, in quanto la memorizzazione nella cache assicura i massimi miglioramenti in termini di performance quanto più l'operazione avviene vicino all'utente finale.

In questa fase, valuterete se le vostre applicazioni necessitano di un incremento delle performance e, in tal caso, se utilizzare la memorizzazione nella cache o altre tecniche disponibili. Se state utilizzando Akamai Enterprise Application Access, un ovvio aggiornamento sarebbe rappresentato dall'utilizzo della CDN di Akamai tramite il nostro prodotto Ion. Ciò consente la memorizzazione nella

cache dei 250.000 server Akamai sparsi in tutto il mondo, garantendo agli utenti finali performance eccellenti, indipendentemente dalla loro posizione.

Inoltre, in questo modo potrete accedere alla rete di Akamai, in cui la correzione degli errori di trasmissione (FEC), l'ottimizzazione dei percorsi e la replica dei pacchetti assicurano un livello di perdita di pacchetti prossimo allo zero e l'instradamento basato sulle performance.

È importante notare che questa fase può essere facoltativamente ritardata fino alla fase della

registrazione degli utenti esterni seguente, in quanto questi ultimi possono essere posizionati meglio per valutare l'incremento relativo delle performance dall'esterno del perimetro di rete.

In entrambi i casi, è consigliabile utilizzare strumenti per le performance in questa fase e prima della registrazione dell'applicazione, al fine di valutare con precisione l'incremento delle performance.

Ciò può essere eseguito tramite l'utilizzo di plug-in del browser, grafici a cascata o servizi di monitoraggio delle performance di terze parti.

Cosa prendere in considerazione:

Dove si trovano i vostri utenti?

Dove si trovano le applicazioni?

Nel momento in cui raggiungerete questa fase, l'applicazione sarà stata ormai integrata e resa accessibile tramite Akamai Enterprise Application Access, aggiornata in termini di sicurezza in modo significativo, facoltativamente resa più performante e verificata da un laboratorio di test interno per ottenere la certezza che funzioni nel modo previsto.

È giunto il momento di effettuarne la distribuzione a un pubblico più ampio. A questo punto, è consigliabile effettuare il phasing agli utenti esterni. Sono quelli per i quali questo stile di accesso porterà alla rimozione della VPN. Inoltre, sono gli utenti più spesso interessati da problemi di performance e si trovano negli ambienti più ostili, in cui la loro stessa posizione mette a rischio applicazioni e dati. È proprio nell'utilizzo di un miglior livello di performance e sicurezza con questo

gruppo di utenti che saranno immediatamente visibili i vantaggi di Akamai Enterprise Application Access.

Prima di iniziare questa fase tramite la modifica della vista DNS, si consiglia di inviare una notifica a tali utenti, in modo che non vengano presi alla sprovvista dalla transizione. Se tutto è stato configurato in modo appropriato fino a questo punto, la transizione dovrebbe essere quasi invisibile per loro, ad eccezione dell'incremento delle performance. Tuttavia, il preavviso informerà gli utenti di tenere particolarmente d'occhio la correttezza del funzionamento in modo che, se qualcosa va storto, sapranno il motivo e saranno pronti a contattare l'amministratore appropriato.

Cosa prendere in considerazione:

Ci sono terze parti che attualmente accedono alla vostra rete?

Come viene fornito l'accesso remoto?

Quali sono le difficoltà di questo modello esistente?

Quale gruppo di utenti remoti ha la minore esigenza ma il maggior accesso?

6. Fase di registrazione degli

utenti esterni

akamai.com | 26 In questa fase, gli utenti esterni saranno stati

registrati da un po' di tempo e tutti i problemi di funzionamento saranno stati risolti. A questo punto, è possibile rimuovere tutti i riferimenti all'applicazione dalle configurazioni specifiche della vista DNS e aggiungerli come voce CNAME alla vista comune. Tutti gli utenti devono quindi iniziare immediatamente ad accedere a questa applicazione utilizzando il proxy Akamai Enterprise Application Access.

In questa fase, tutte le procedure utilizzate per avvisare gli utenti esterni devono essere applicate agli utenti interni. Si spera che nelle sei fasi precedenti, eventuali problemi o errori di configurazione siano stati individuati e risolti.

Presupponendo che tutto sia corretto, a questo punto la transizione operativa dell'applicazione ad Akamai Enterprise Application Access sarà stata effettuata correttamente e tutti gli utenti dovrebbero beneficiare dei vantaggi derivanti da un accesso più semplice, più veloce e più sicuro.

Cosa prendere in considerazione:

Quali altri gruppi necessitano dell'accesso a questa applicazione?

Come viene fornito l'accesso remoto attualmente?

Quali sono le difficoltà di questo modello esistente?

I gruppi, a parte questi particolari utenti, hanno accesso a questa applicazione?

7. Fase di registrazione degli

utenti interni

8. Fasi di migrazione della VLAN

Dopo un periodo di tempo appropriato trascorso nella fase di registrazione degli utenti interni, potete spostare finalmente l'applicazione nella VLAN chiusa. Prima che ciò si verifichi, anche se tutti gli utenti validi vengono indirizzati verso Akamai Enterprise Application Access tramite DNS, lo stesso server applicativo è ancora raggiungibile direttamente attraverso il suo indirizzo IP e, di conseguenza, è vulnerabile ai malware presenti all'interno del perimetro di rete.

Questa fase finale elimina totalmente la possibilità di effettuare un accesso IP diretto, rendendo l'applicazione accessibile esclusivamente tramite il proxy di accesso.

Dopo aver effettuato queste operazioni,

l'applicazione è ufficialmente e completamente trasferita su Akamai Enterprise Application Access.

Cosa prendere in considerazione:

Come vengono messi in atto i controlli di rete?

Che tipo di accesso a livello di rete esiste attualmente per queste applicazioni?

È possibile segmentare queste applicazioni?

Chi sono gli stakeholder della rete?

akamai.com | 28 Operazioni post-installazione

Una volta che tutte le applicazioni sono state trasferite su Enterprise Application Access, è possibile iniziare ad esaminare la rimozione completa dei client VPN dai sistemi degli utenti finali.

Inoltre, è possibile considerare la conversione della vostra rete di utenti interni in Wi-Fi guest, in quanto l'accesso a tutte le applicazioni è passato a un modello di accesso Zero Trust.

Infine, in questa fase dovreste prendere in

considerazione la protezione dei vostri data center da avanzati attacchi DDOS. Akamai Prolexic è una soluzione che può aiutarvi.

Riepilogo e passaggi successivi

Le tradizionali architetture di rete hub e spoke, insieme al perimetro di sicurezza basato su un modello che vedeva l'organizzazione come un castello da difendere attraverso la costruzione di mura e fossati, semplicemente non possono fornire in modo efficace performance o sicurezza nel mondo cloud e mobile di oggi. Questo è un problema che tutte le aziende devono iniziare ad affrontare al fine di evitare di rimanere indietro in una condizione di vulnerabilità. La mancata adozione di architetture di rete più sicure attualmente è la principale causa di violazioni delle reti aziendali e le cose possono solo peggiorare. Più semplicemente, non siete al sicuro dietro al perimetro perché il perimetro stesso non esiste più.

Come è possibile iniziare il passaggio a un'architettura Zero Trust?

I servizi di sicurezza cloud di Akamai possono essere combinati per creare un'architettura Zero Trust completa, consentendo non solo l'accesso sicuro alle applicazioni nel mondo nativo del cloud, ma anche l'utilizzo del cloud per rimuovere quasi completamente la necessità di reti aziendali interne.

Grazie alla nostra avanzata soluzione ZTNA distribuita, insieme alla potenza dell'Akamai Intelligent Edge Platform globale, potete passare finalmente a un mondo meno perimetrale in modo incredibilmente semplice, eseguendo il phasing delle applicazioni, azzerando quasi il profilo del rischio di migrazione e sfruttando la vasta esperienza di Akamai acquisita nei suoi 22 anni di storia, che vanta performance e soluzioni per la sicurezza di comprovata validità.

Mentre continuate il percorso verso un'architettura Zero Trust, potete essere certi che Akamai vi sarà accanto in ogni fase, aiutandovi con la

trasformazione della vostra rete verso un'architettura che non solo garantisce l'accesso alle vostre

applicazioni e ai vostri dati, ma lo fa in un modo facile da gestire, mantenendo i più alti livelli di sicurezza e performance.

Gli esperti di sicurezza di Akamai possono collaborare con voi per sviluppare un percorso graduale personalizzato verso il modello Zero Trust. Pianificate un workshop di 30 minuti per esaminare lo stato attuale, lo stato finale desiderato, le priorità aziendali, le vulnerabilità e le principali preoccupazioni. In alternativa, visitate akamai.com/zerotrust per ulteriori informazioni.

Informazioni sull'autore

Charlie Gero, Chief Technology Officer del gruppo di progetti aziendali e avanzati, Akamai

Charlie è cofondatore di Akamai Labs e dirige le attività di ricerca e sviluppo negli spazi di rete aziendale e cloud, con particolare attenzione alle performance, all'accesso e alla sicurezza.

Akamai garantisce experience digitali sicure per le più grandi aziende a livello mondiale. L'Akamai Intelligent Edge Platform permea ogni ambito, dalle aziende al cloud, permettendovi di lavorare con rapidità, efficacia e sicurezza. I migliori brand a livello globale si affidano ad Akamai per ottenere un vantaggio competitivo grazie a soluzioni agili in grado di estendere la potenza delle loro architetture multicloud.

Più di ogni altra azienda, Akamai avvicina agli utenti app, experience e processi decisionali, tenendo lontani attacchi e minacce. Il portfolio Akamai di soluzioni per l'edge security, le web e mobile performance, l'accesso aziendale e la delivery di contenuti video è affiancato da un servizio clienti di assoluta qualità e da un monitoraggio 24 ore su 24, 7 giorni su 7, 365 giorni all'anno. Per scoprire perché i principali brand mondiali si affidano ad Akamai, visitate il sito www.akamai.com o blogs.akamai.com e seguite @Akamai su Twitter. Le informazioni di contatto internazionali sono disponibili all'indirizzo www.akamai.com/locations. Data di pubblicazione: 02/21.