Il tassello mancante rispetto alle puntate precedenti è rivolto a quelle realtà che sono già migrate totalmente verso il cloud o ibride che con molta probabilità hanno mantenuto una zampetta nel loro vecchio Data Center.
Eccoci qui per l’epilogo del nostro percorso volto a meglio far comprendere come il vecchio proxy debba necessariamente evolvere..
Il tassello mancante rispetto alle puntate precedenti è rivolto a quelle realtà che sono già migrate totalmente verso il cloud o ibride che con molta probabilità hanno mantenuto una zampetta nel loro vecchio Data Center. Per queste casistiche i vecchi paradigmi sono inutili, con soli svantaggi. Bisogna abbracciare il modello SASE di cui il Proxy è solo un piccolo componente.
Ci sono varie definizioni per Il SASE (Secure Access Service Edge). Quella che più mi piace è dire che trattasi un framework che fa convergere molte soluzioni di sicurezza in una piattaforma distribuita cloud che connette in modo sicuro utenti, sistemi, endpoint e reti remoti ad app e risorse.
Oggi si sta assistendo a un’unificazione di tre segmenti di mercato differenti: i secure web gateway tradizionali per la navigazione (SWG, possibilmente con capability di RBI di cui abbiamo discusso nei precedenti articoli), i CASB e vendor che offrono modelli di Zero Trust. I tre segmenti si stanno fondendo nel cosiddetto modello SSE (Security Service Edge). Per le realtà quindi in cloud è assolutamente indispensabile eliminare i proxy on prem, gli accessi VPN on prem ed anche altri strati la cui location naturale diventa il cloud e la cui presenza on prem perde di un qualsiasi razionale.
In questo strato di autenticazione di Security Service Edge ci si può autenticare e applicare logiche di Risk Analysis prima di autorizzare il vero e proprio accesso. Intendiamo motori in grado di analizzare il comportamento dell’utente, la rilevazione di connessione da IP malevoli, da reti TOR , da differenti location molto distanti fra loro impossibili da giustificare con un viaggio – Geo Velocity -(a meno di non avere la USS Enterprise del Capitano Kirk), l’utilizzo di un device ma rilevato prima.
Il motore intelligente quindi concederà l’accesso immediatamente o proporrà un challenge all’utente chiedendo qualcosa che so lui ha (e.g. Push notification /altro), o bloccherà l’accesso se non sono soddisfatti i challenge e le analisi effettuate real time.
Queste cabapility , e molte altre ancora, diventarenno la new normality quando parliamo di autenticazione e sono assolutamente già disponibili in tutti i motori di rischio che utilizzano il machine learning e policy configurabili dagli amministratori per analizare l’identità dell’utente e rilevare potenziali minacce.
Senza saperlo stiamo praticamente applicando un tassello del modello Zero Trust Network Access , acronimo molto utilizzato negli ultimi 2 anni che si basa su un concetto molto semplice ideato dal ricercatore John Kindervag nel 2009-2010 e cioè ‘never trust always verify’.
Esso si basa su tre principi: tutte le entità sono ‘untrusted’, assegnazione del privilegio minimo agli utenti e agli account tecnici e, infine, monitoring continuo.
La tecnologia ci aiuta nella cosìdetta “frictionless user experience”. Una volta autenticati ed autorizzati si apriranno le porte alle applicazioni aziendali (che a questo punto potrebbero essere ovunque) ed alla navigazione sicura con tutte le feature che abbiamo visto prima. Tecnologie che utilizzano agent a bordo permettono controlli di sicurezza elevatissime e migliorando la user experience sebbene siano un onere in termini di gestione operativa.
Mi preme sottolineare che molte piattaforme SASE promettono lo Zero Trust ma è bene andare nel dettaglio per capire se agiscono da Service Provider o da Identity Provider.
Nel caso agiscano da Service Provider il livello di granularità è inferiore poiché è all’Identity Provider che vengono richiesti tutti i controlli che citavo prima ed il Service Provider SASE accetterà , trsutando, tutto quello che gli arriva dall’Idenity Provider almeno per quanto concerne l’autenticazione.
Un altro vantaggio del modello SASE è quello di poter pubblicare applicazioni legacy che magari risiedono ancora nel Data Center on Prem.
Vien da sé che così come il vecchio Proxy è morto, possiamo dichiarare un paradigma analogo per la VPN. In un moderno business digitale incentrato sul cloud, gli utenti, i dispositivi e le funzionalità di rete richiedono un accesso sicuro “anywhere and anytime”.
Il modello VPN on prem mostra sempre più i suoi limiti ai paradgmi di digital transformation e sempre più si richiede abilità specifiche e contorsioni da ginnasti per instradare il traffico da e verso il data center aziendale. Andremo ad impattare la produttività dell’utente, la sua user experience, in taluni casi restringendo l’utilizzo delle piattaforme Software as a Service solo se l’utente è all’interno della Lan o connesso alla “vecchia VPN” richiedendo una serie di agent a seconda delle necessità.
In altri casi, nelle branch non ha senso istradare il traffico verso il data center quando l’utente deve accedere a servizi nativamente Cloud aumentando la latenza e il costo associato ai circuiti MPLS delle sedi locali.
Terminerei questa trilogia con una semplice conclusione: scegliete l’architettura target alla quale evolvere a seconda del Business dell’azienda e delle sue esigenze, dalla tipologia di dati trattati e da un’analisi del rischio.
English (US)