Archivi categoria: Security

Azure Security Center: l’export di alert e raccomandazioni verso altre soluzioni

In Azure Security è stata introdotta una interessante funzionalità che permette di inviare le informazioni di security generate dal proprio ambiente verso altre soluzioni. Il tutto avviene tramite un meccanismo di esportazione continua degli alert e delle raccomandazioni verso Azure Event Hubs oppure verso workspace di Azure Monitor Log Analytics. Con questa funzionalità si aprono così nuovi scenari di integrazione per Azure Security Center. In questo articolo viene riportato come utilizzare questa funzionalità e vengono approfondite le sue caratteristiche.

Azure Security Center (ASC) effettua un assessment continuo dell’ambiente ed è in grado di fornire delle raccomandazioni relative alla sicurezza dell’ambiente. Come descritto in questo articolo è possibile personalizzare la soluzione per soddisfare i propri requisiti di sicurezza e le raccomandazioni che vengono generate. Nel tier standard queste raccomandazioni possono non essere limitate al solo ambiente Azure, ma sarà possibile contemplare anche ambienti ibridi e le risorse on-premises.

Security Center standard genera anche degli alert nel momento in cui vengono rilevate potenziali minacce di sicurezza sulle risorse presenti nel proprio ambiente. ASC stabilisce le priorità, elenca gli alert, fornisce le informazioni necessarie per esaminare rapidamente i problemi e riporta consigli su come risolvere eventuali attacchi.

Azure Event Hubs è una piattaforma di streaming di big data e un servizio per l’ingestion di eventi. Può ricevere ed elaborare milioni di eventi al secondo. I dati inviati a un Event Hub possono essere trasformati e archiviati utilizzando qualsiasi provider di analisi in tempo reale oppure adattatori batch o di archiviazione.

La nuova funzionalità che è stata introdotta in Azure Security Center si chiama Continuos Export, supporta scenari enterprise e consente di effettuare quanto segue:

  • Export verso Azure Event Hubs per ottenere una integrazione con SIEMs di terze parti ed Azure Data Explorer.
  • Export verso un workspace Log Analytics per avere una integrazione con Azure Monitor, utile per analizzare meglio i dati, utilizzare Alert rule, Microsoft Power BI e dashboards personalizzate.
  • Export in un file CSV, per singole esportazioni di dati (one shot).

La configurazione è semplice e la si può effettuare tramite la seguente procedura.

In Azure Security Center si seleziona la subscription per la quale si vuole configurare l’esportazione dei dati e nella sidebar delle impostazioni si seleziona Continuos Export:

Figura 1 – Continuous Export nei settings di ASC della subscription

In questo caso si è scelto di configurare l’esportazione verso un workspace di Log Analytics. Si possono selezionare quali raccomandazioni esportare ed il relativo livello di severity. Anche per gli alert di security si può scegliere per quale livello farne l’esportazione. L’export crea un oggetto, pertanto è opportuno specificare in quale resource group posizionarlo. Sarà infine necessario selezionare il workspace target di Log Analytics.

Figura 2 – Configurazione dei parametri per fare il Continuous Export

Selezionando il link per l’integrazione con Azure Monitor c’è la possibilità di creare in modo automatico delle Alert rule già preimpostate.

Figura 3 – Creazione automatica di alert rule in Azure Monitor

Di default queste alert rule non configurano degli Action Group, pertanto è consigliabile modificarle per scatenare un trigger in base alle proprie esigenze.

Queste le due alert rule create di default:

Figura 4 – Alert rule di Azure Monitor create di default

In alternativa, dopo aver fatto confluire le raccomandazioni e gli alert di ASC in un workspace, è possibile configurare in Azure Monitor delle Alert rule personalizzate basate su query di Log Analytics.

Gli alert di security e le raccomandazioni di ASC vengono memorizzate nelle tabelle SecurityAlert e SecurityRecommendations del workspace. Il nome della solution di Log Analytics contenente queste tabelle è in relazione al tier di ASC, che può essere quindi Security and Audit (tier standard) oppure SecurityCenterFree (tier free).

Figura 4 – Tabelle in Log Analytics

La configurazione di Continuos Export verso Event Hubs è del tutto simile e risulta essere la metodologia migliore per integrare le raccomandazioni e gli alerts di Azure Security Center con soluzioni SIEM di terze parti. In seguito, vengono riportati i connettori per le principali soluzioni SIEM di terze parti:

In Azure Sentinel è invece disponibile il Data connector nativo per contemplare gli alerts di Azure Security Center.

Per configurare l’export verso Azure Data Explorer è possibile usare la procedura riportata in questa documentazione Microsoft.

Conclusioni

Grazie a questa nuova funzionalità introdotta in Azure Security Center è possibile consolidare tutti gli alert e le raccomandazioni generati dalla soluzione verso altri strumenti, aprendo così nuovi possibili scenari di integrazione anche con soluzioni di terze parti. Il tutto è reso possibile tramite un meccanismo facilmente configurabile, che consente di essere immediatamente notificati e di intraprendere rapidamente le azioni necessarie. Questi aspetti sono fondamentali quando si trattano informazioni relative alla sicurezza.

Azure Security Center: come personalizzare la soluzione per soddisfare i propri requisiti di sicurezza

Azure Security Center è una soluzione nel cloud che consente di prevenire, rilevare e rispondere alle minacce di sicurezza che interessano sia le risorse in ambiente Azure che workloads in ambienti ibridi. Tramite l’assegnazione di un punteggio globale al proprio ambiente permette di valutare il profilo di rischio e di agire per intraprendere delle azioni di remediation al fine di migliorare le security posture. La soluzione si basa su delle raccomandazioni generiche, ma in alcuni casi è opportuno personalizzarla per contemplare al meglio le proprie politiche di sicurezza. In questo articolo viene riportato come è possibile introdurre questo livello di personalizzazione al fine di aumentare il valore fornito da Azure Security Center.

Utilizzo delle custom security policy

Le raccomandazioni di default presenti nella soluzione sono derivanti da best practices generiche del settore e da specifici standard normativi.

Figura 1 – Punteggio e raccomandazioni standard presenti in Azure Security Center

Recentemente è stata introdotta la possibilità di aggiungere le proprie initiatives personalizzate, al fine di ricevere delle raccomandazioni qualora non siano rispettate le policy di sicurezza stabilite in modo specifico per il proprio ambiente. Le iniziative personalizzate che vengono create sono totalmente integrate nella soluzione e saranno contemplate sia nel Secure Score che nelle dashboard di compliance.

Per creare una initiative personalizzata è possibile seguire la procedura in seguito riportata:

Figura 2 – Avvio del processo di creazione di una custom initiative

All’interno delle initiatives è possibile includere delle Azure Policy integrate nella soluzione oppure le proprie policy personalizzate.

Nell’esempio sotto riportato l’initiative include le seguenti due policy:

  • Una custom che impedisce la creazione di peering verso una rete di Hub che si trova in un determinato resource group.
  • Una bult-in che verifica che siano applicati i Network Security Group a tutte le subnet.

Figura 3 – Creazione di una custom initiative

In seguito, è necessario procedere con l’assegnazione dell’initiative custom:

Figura 4 – Avvio del processo di assegnazione

 

Figura 5 – Assegnazione della custom initiative

 

Figura 6 – Visualizzazione della custom initiative assegnata

La visualizzazione delle raccomandazioni presenti all’interno di Security Center non è immediata, ma attualmente richiede circa 1 ora e la si può consultare nella seguente sezione:

Figura 7 – Custom initiative nella sezione Regulatory compliance

 

Disabilitazione di security policy di default

In determinate circostanze può risultare opportuno disabilitare determinati controlli presenti di default nella soluzione Azure Security Center, in quanto non si ritengono adeguati al proprio ambiente e non si vogliono generare inutilmente delle segnalazioni. Per farlo è possibile effettuare gli step seguenti:

Figura 8 – Accesso alle default policy di Security Center

 

Figura 9 – Selezione dell’assegnazione delle default policy di Security Center

 

Figura 10 – Disabilitazione di una specifica policy presente di default

 

Conclusioni

Azure Security Center mette a disposizione in modo nativo una serie di controlli per verificare costantemente la presenza di condizioni ritenute anomale e che possono avere un impatto diretto sulla sicurezza dell’ambiente. La possibilità di introdurre un livello di personalizzazione nella soluzione, la rende più flessibile e permette di verificare e applicare su larga scala dei criteri di compliance in ambito sicurezza specifici per il proprio ambiente. Per migliorare le security posture è fondamentale valutare l’adozione di questa soluzione e applicando un buon livello di personalizzazione se ne aumenta notevolmente il suo valore.

Microsoft Always On VPN: l’accesso trasparente alla rete aziendale adatto in scenari di smart working

La tecnologia può svolgere un ruolo importante nel ridurre l’impatto di COVID-19 sulle persone e sulle realtà aziendali, aiutando il personale a rimanere produttivo quando non è in grado di essere fisicamente presso il proprio posto di lavoro. In questi giorni di emergenza le aziende sono state costrette ad adottare in tempi rapidi soluzioni efficaci per consentire ai propri dipendenti di lavorare da remoto senza sacrificare la collaborazione, la produttività e la sicurezza. Le soluzioni che è possibile adottare in questo ambito sono differenti, ciascuna con le proprie caratteristiche e peculiarità, in grado di rispondere a differenti esigenze. In questo articolo vengono riportate le principali caratteristiche della tecnologia Microsoft Always On VPN, per valutarne i vantaggi e quali sono i principali casi d’uso della soluzione.

Caratteristiche principali di Always On VPN

A partire da Windows Server 2016 e versioni successive Microsoft ha introdotto una nuova tecnologia di accesso remoto degli endpoint denominata Always On VPN che permette un accesso trasparente alla rete aziendale, rendendola particolarmente adatta in scenari di smart working.  Si tratta dell’evoluzione della tecnologia DirectAccess che, per quanto efficace, presentava delle limitazioni che ne rendevano difficile l’adozione.

Come dice il nome, la VPN è “sempre attiva”, infatti una connessione sicura alla rete aziendale viene stabilita automaticamente ogni volta che un client autorizzato ha connettività Internet, il tutto senza richiedere all’utente input oppure interazione, a meno che non sia abilitato un meccanismo di autenticazione a più fattori. Gli utenti remoti accedono ai dati e alle applicazioni aziendali allo stesso modo, proprio come se fossero sul posto di lavoro.

Le connessioni Always On VPN includono le seguenti tipologie di tunnel:

  • Device Tunnel: il dispositivo si collega ai server VPN prima che gli utenti accedano al dispositivo stesso.
  • User Tunnel: si attiva solo dopo che gli utenti hanno effettuato l’accesso al dispositivo.

Utilizzando Always On VPN è infatti possibile avere una connessione utente, del dispositivo, oppure una combinazione di entrambe. Sia il Device Tunnel che lo User Tunnel funzionano infatti in modo indipendente e possono utilizzare diversi metodi di autenticazione. Risulta pertanto possibile abilitare l’autenticazione del dispositivo per gestirlo remotamente tramite il Device Tunnel, ed abilitare l’autenticazione utente per la connettività alle risorse interne all’azienda attraverso lo User Tunnel. Lo User Tunnel supporta SSTP e IKEv2, mentre il Device Tunnel supporta solamente IKEv2.

Scenari supportati

La tecnologia Always On VPN è una soluzione solo per sistemi Windows 10. Tuttavia, a differenza di DirectAccess, i dispositivi client non devono necessariamente eseguire l’edizione Enterprise, ma tutte le versioni di Windows 10 supportano questa tecnologia, adottando la tipologia di tunnel definita User Tunnel. In questo scenario i dispositivi possono essere membri di un dominio Active Directory, ma ciò non è strettamente necessario. I client Always On VPN possono essere nondomain-joined (workgroup), pertanto anche di proprietà personale dell’utente. Per sfruttare determinate funzionalità avanzate, i client possono essere in join ad Azure Active Directory. Solamente per utilizzare il Device Tunnel è richiesto che i sistemi siano in join a un dominio e devono necessariamente avere Windows 10 Enterprise oppure Education. In questo scenario è consigliata la versione 1809 o successiva.

Requisiti di infrastruttura

Per poter implementare una architettura Always On VPN è necessaria la presenza dei seguenti componenti di infrastruttura, molti dei quali sono tipicamente già attivi nelle realtà aziendali:

  • Domain Controllers
  • DNS Servers
  • Network Policy Server (NPS)
  • Certificate Authority Server (CA)
  • Routing and Remote Access Server (RRAS)

Figura 1 – Panoramica della tecnologia VPN Always On

In questo contesto è opportuno specificare che Always On VPN è indipendente dall’infrastruttura e può essere attivata utilizzando il ruolo Windows Routing and Remote Access (RRAS) oppure adottando un qualsiasi dispositivo VPN di terze parti. Anche l’autenticazione può essere fornita dal ruolo Windows Network Policy Server (NPS) oppure da una qualsiasi piattaforma RADIUS di terze parti.

Per maggiori dettagli sui requisiti necessari è possibile fare riferimento alla documentazione ufficiale Microsoft.

Always On VPN in ambiente Azure?

In generale, è consigliabile far stabilire agli endpoint le connessioni VPN il più vicino possibile alle risorse a cui devono accedere. Per le realtà con ambienti ibridi, esistono diverse opzioni per posizionare l’architettura Always On VPN. Il deployment del ruolo Remote Access su una macchina virtuale in ambiente Azure non è supportato, tuttavia è possibile utilizzare gli Azure VPN Gateway con Windows 10 Always On, per stabilire tunnel sia di tipologia Device Tunnel che User Tunnel. A questo proposito è bene precisare che è opportuno fare le corrette valutazioni sulla tipologia e sulla SKU dell’Azure VPN Gateway da implementare.

Tipologie di deployment

Per Always On VPN sono previsti due scenari di deployment:

Il deployment di Always On VPN può prevedere opzionalmente, per i client Windows 10 in join al dominio, di configurare l’accesso condizionato per regolare le modalità in cui gli utenti VPN accedono alle risorse aziendali.

Figura 2 – Workflow per il deployment di Always On VPN per Windows 10 client domain-joined

Il client Always On VPN può infatti integrarsi con la piattaforma Azure Contitional Access per forzare l’autenticazione a più fattori (MFA), la conformità dei dispositivi oppure una combinazione di questi due aspetti. Se conforme ai criteri di Contitional Access, Azure Active Directory (Azure AD) emette un certificato di autenticazione IPsec di breve durata che può essere usato per autenticarsi sul gateway VPN. La conformità del dispositivo utilizza i criteri di conformità di Microsoft Endpoint Manager (Configuration Manager / Intune), che possono includere lo stato di attestazione dell’integrità del dispositivo, come parte del controllo di conformità per la connessione.

Figura 3 – Workflow per la connessione lato client

Per maggiori dettagli su questa metodologia di deployment è possibile fare riferimento a questa documentazione Microsoft.

Provisioning della soluzione sui client
Always On VPN è progettato per essere implementato e gestito utilizzando una piattaforma di gestione dei dispositivi mobile come ad esempio Microsoft Endpoint Manager, ma è possibile utilizzare anche soluzioni di Mobile Device Management (MDM) di terze parti. Per Always On VPN non è presente alcun supporto per la configurazione e la gestione tramite Group Policy di Active Directory, ma qualora non si disponga di una soluzione MDM è possibile procedere con un deploy della configurazione in modo manuale tramite PowerShell.

Integrazione con altre soluzioni Microsoft

Oltre a quanto riportato nei paragrafi precedenti, la tecnologia Always On VPN si può integrare con le seguenti tecnologie Microsoft:

  • Azure Multifactor Authentication (MFA): se combinata con i servizi RADIUS (Remote Authentication Dial-In User Service) e l’estensione NPS (Network Policy Server) per Azure MFA, l’autenticazione VPN può sfruttare meccanismi di autenticazione a più fattori.
  • Windows Information Protection (WIP): grazie a questa integrazione è consentita l’applicazione dei criteri di rete per determinare se il traffico è autorizzato a passare attraverso il tunnel VPN.
  • Windows Hello for Business: in Windows 10, questa tecnologia sostituisce le password, fornendo meccanismo di autenticazione a due fattori forte. Questa autenticazione consiste in una tipologia di credenziali utente legate a un dispositivo e utilizza un PIN (Personal Identification Number) biometrico o personale.

Conclusioni

Preparare la propria infrastruttura per consentire agli endpoint di accedere alla rete aziendale tramite la tecnologia Always On VPN non richiede nessun costo aggiuntivo per licenze software e gli investimenti necessari sia in termini di effort che di risorse sono minimi. Grazie a questa metodologia di connettività si riesce a garantire una esperienza utente ottimale anche in mobilità, fornendo un accesso trasparente e automatico alla rete aziendale pur mantenendo un elevato livello di sicurezza. Per gli aspetti sopra elencati la tecnologia Always On VPN non è adatta a tutti gli scenari d’uso, ma è sicuramente da tenere in considerazione in presenza di sistemi Windows 10 che devono accedere remotamente alle risorse aziendali.

Azure Security: Best Practices per migliorare la security posture

La tendenza ad avere sempre più frequentemente soluzioni nel cloud e architetture ibride impone di adottare elevati standard di sicurezza per il proprio ambiente. Ma come è possibile ottenere un’efficace sicurezza del cloud per Azure e quali best practice è opportuno seguire? In questo articolo vengono riportate in modo sintetico le principali pratiche che è opportuno adottare in Azure per garantire un elevato livello di sicurezza e migliorare le security posture.

Attivazione MFA e restrizioni per gli accessi amministrativi

Per le utenze con diritti amministrativi è opportuno attivare l’autenticazione tramite meccanismi di Multi-factor Authentication (MFA). A questo proposito è molto interessante valutare meccanismi di autenticazione passwordless che prevedono che la password sia sostituita con qualcosa che si possiede più qualcosa che si è o che si conosce.

Microsoft attualmente offre tre distinti scenari di autenticazione passwordless:

Azure Active Directory offre la possibilità di attivare meccanismi di MFA, compresa l’autenticazione passwordless. Meccanismi di MFA basati sui messaggi di testo sono più facilmente aggirabili, quindi è bene indirizzarsi su meccanismi di Multi-factor Authentication differenti oppure passwordless.

Ridurre al minimo il numero di persone e il relativo periodo temporale, per l’accesso amministrativo alle risorse Azure, è una pratica da adottare perché riduce la possibilità che un attore malintenzionato ottenga un accesso amministrativo oppure che un utente autorizzato influisca inavvertitamente su una specifica risorsa. Per consentire l’esecuzione di azioni amministrative agli utenti autorizzati si può offrire un accesso privilegiato just-in-time (JIT) alle risorse Azure ed Azure AD. A questo scopo l’adozione del servizio Azure Active Directory (Azure AD) Privileged Identity Management (PIM) che consente di gestire, controllare e monitorare gli accessi alle risorse aziendali è una buona pratica da adottare.

Un altro aspetto chiave da considerare è l’utilizzo di postazioni di lavoro sicure e isolate per i ruoli sensibili. In questo documento ufficiale Microsoft è possibile ottenere maggiori dettagli a riguardo.

Segmentazione e adozione del modello Zero Trust

Il modello di sicurezza, definito Zero trust e in contrasto con i modelli convenzionali basati sulla sicurezza perimetrale, prevede l’adozione di un approccio legato alla micro-segmentazione e alla definizione di perimetri granulari nella propria architettura di rete. Per contenere i rischi di sicurezza è bene adottare una strategia di segmentazione chiara e semplice, che permette alle parti interessate una chiara comprensione, per agevolare un monitor e una gestione efficace. Sarà poi utile assegnare le autorizzazioni necessarie e gli opportuni controlli di rete.

A questo proposito si riporta un design di riferimento per quanto riguarda il modello amministrativo di Azure:

Figura 1 – Reference Design – Azure Administration Model

Nella figura seguente viene mostrato il modello tipico di rete Hub-Spoke, dove l’Hub è una rete virtuale in Azure che funge da punto di connettività verso la rete on-premises e gli Spoke sono le reti virtuali che eseguono il peering con l’Hub e possono essere usate per isolare i carichi di lavoro.

Figura 2 – Reference Enterprise Design – Azure Network Security

Adozione di una opportuna “Firewall Strategy”

L’adozione di una soluzione firewall in ambiente Azure per proteggere e segregare al meglio i flussi di rete è ormai obbligata.

La scelta può prevedere l’adozione di:

  • Soluzioni Microsoft totalmente integrate nella piattaforma, come Azure Firewall, affiancato dal Web App Firewall (WAF) dell’Application Gateway, un load balancer applicativo (OSI layer 7) per il traffico web, che consente di governare il traffico HTTP e HTTPS delle applicazioni. Il modulo Web Application Firewall (WAF) per le pubblicazioni web consente di ottenere una protezione applicativa, basandosi su regole OWASP core rule sets. Il WAF protegge gli applicativi da vulnerabilità e da attacchi comuni, come ad esempio attacchi X-Site Scripting e SQL Injection. Tali soluzioni sono idonee per la maggior parte degli scenari e offrono funzionalità intrinseche di alta disponibilità e scalabilità oltre che una semplice configurazione e gestione centralizzata.
  • Soluzioni fornite da vendor di terze parti e disponibili nel marketplace di Azure. Le Network Virtual Appliances (NVAs) sono numerose, possono offrire funzionalità avanzate e consentono di dare una continuità nell’esperienza d’uso rispetto alle soluzioni già attive nell’ambiente on-premises. Tipicamente la configurazione di queste soluzioni è più articolata e il costo è tendenzialmente più elevato rispetto alle soluzioni Microsoft.

Scelta di una soluzione di DDoS Mitigation per gli applicativi critici

Molto importante è la protezione di tutti gli applicativi critici da attacchi informatici di tipologia denial-of-service distribuiti (attacchi DDoS – Distributed Denial of Service). Questi attacchi sono rivolti a far esaurire deliberatamente le risorse di un determinato sistema che eroga un servizio ai client, come ad esempio un sito web ospitato su dei web server, al punto da renderlo non più in grado di erogare il servizio a coloro che lo richiedono in modo legittimo.

In Azure la protezione da attacchi DDoS è disponibile in due differenti tiers: Basic oppure Standard.

Figura 3 – Comparativa delle funzionalità dei tiers disponibili per la protezione DDoS

La protezione Basic è abilitata di default nella piattaforma Azure, la quale effettua costantemente il monitor del traffico e applica in tempo reale delle mitigazioni agli attacchi di rete più comuni. Questo tier fornisce lo stesso livello di protezione adottato e collaudato dai servizi online di Microsoft ed è attiva per gli indirizzi IP Pubblici di Azure (Pv4 e IPv6). Non è richiesta alcun tipo di configurazione per il tier Basic.

L’Azure DDoS Protection di tipologia Standard fornisce delle funzionalità di mitigation aggiuntive rispetto al tier Basic, che sono ottimizzate in modo specifico per le risorse dislocate nelle virtual network di Azure. Le policy di protezione sono auto-configurate e vengono ottimizzate effettuando un monitoraggio specifico del traffico di rete e applicando degli algoritmi di machine learning, che consentono di profilare nel modo più opportuno e flessibile il proprio applicativo studiando il traffico generato. Nel momento in cui vengono superate le soglie impostate nella policy di DDoS, viene in automatico avviato il processo di DDoS mitigation, il quale viene sospeso nel momento in cui si scende al di sotto delle soglie di traffico stabilite. Queste policy vengono applicate a tutti gli IP pubblici Azure (IPv4) associati alle risorse presenti nelle virtual network, come: macchine virtuali, Azure Load Balancer, Azure Application Gateway, Azure Firewall, VPN Gateway e istanze Azure Service Fabric.

Adozione di Azure Security Center

Azure Security Center è una soluzione nel cloud che consente di prevenire, rilevare e rispondere alle minacce di sicurezza che interessano le risorse Azure e workloads in ambienti ibridi. Per migliorare le security posture del proprio ambiente Azure è fondamentale valutare l’adozione di questa soluzione che viene offerta in due possibili tiers:

  • Free tier. In questo tier Azure Security Center è totalmente gratuito ed effettua un assessment continuo, fornendo delle raccomandazioni relative alla sicurezza dell’ambiente Azure.
  • Standard tier. Rispetto al tier free aggiunge funzionalità avanzate di rilevamento delle minacce, utilizzando l’analisi comportamentale e l’apprendimento automatico per identificare attacchi e exploit zero-day. Attraverso tecniche di machine learning e tramite la creazione di whitelist è possibile controllare l’esecuzione delle applicazioni per ridurre l’esposizione agli attacchi di rete e ai malware. Inoltre, il livello standard aggiunge la possibilità di effettuare in modo integrato un Vulnerability Assessment per le macchine virtuali in Azure. Lo standard Security Center Standard supporta diverse risorse Azure tra cui: VMs, Virtual machine scale sets, App Service, SQL servers, e Storage accounts.

Figura 4 – Confronto tra i tiers di Azure Security Center

Azure Security Center assegna un punteggio al proprio ambiente, utile per monitorare il profilo di rischio e cercare di migliorare costantemente le security posture, applicando delle azioni di remediation. Buona norma è verificare con cadenza regolare (almeno mensile) il security score fornito da Azure Security Center e programmare le iniziative finalizzate a migliorare specifici ambiti. Inoltre, è consigliato verificare attentamente gli alert che Security Center nel tier standard genera quando rileva potenziali minacce di sicurezza sulle proprie risorse. Security Center stabilisce le priorità, elenca gli alert, fornisce le informazioni necessarie per esaminare rapidamente i problemi e fornisce consigli su come risolvere eventuali attacchi.

Introdurre la sicurezza durante nelle fasi di sviluppo e rilascio

L’adozione di modelli DevOps per implementare applicazioni e servizi in Azure consentono, oltre che fornire la massima agilità, di ottenere benefici in termini di sicurezza. Nei modelli DevOps è possibile coinvolgere nelle fasi di sviluppo e gestione i team dedicati al controllo della qualità e della sicurezza durante tutto il ciclo di vita dell’applicazione. Utilizzando processi di Infrastructure-as-Code (IaC) è infatti possibile definire e monitorare la conformità su larga scala.

Non utilizzare tecnologie legacy

In ambiente Azure non è consigliata l’adozione delle classiche soluzioni Network Intrusion Detection System (NIDS) e Network Intrusion Prevention Systems (NIPS) in quanto la piattaforma è in grado di filtrare nativamente i pacchetti malformati. Le soluzioni NIDS / NIPS classiche si basano in genere su approcci obsoleti basati sulla firma che possono essere facilmente elusi durante tentativi di attacco e in genere producono un alto tasso di falsi positivi.

Conclusioni

Raggiungere un elevato livello di sicurezza degli ambienti Azure è una sfida importante che deve necessariamente essere vinta e prevede un costante lavoro di controllo, revisione e aggiornamento delle security posture. In questo articolo sono state riportate quelle che sono ritenute le principali best practice di sicurezza date da una diretta esperienza sul campo, che è sempre bene arricchirle adottando ulteriori accorgimenti.

Azure Security: come effettuare un Vulnerability Assessment tramite Azure Security Center

Azure Security Center, la soluzione cloud che consente di prevenire, rilevare e rispondere alle minacce di sicurezza che interessano le risorse Azure e i workloads in ambienti ibridi, è stata recentemente arricchita con la possibilità di effettuare in modo integrato un Vulnerability Assessment per le macchine virtuali in Azure. In questo articolo viene riportato come è possibile portare a termine un processo di valutazione delle vulnerabilità tramite Azure Security Center, esaminando le caratteristiche della soluzione.

La scansione delle vulnerabilità inclusa in Azure Security Center (ASC) viene effettuata tramite la soluzione Qualys, il quale risulta essere riconosciuto come strumento leader per identificare in tempo reale eventuali vulnerabilità presenti sui sistemi. Per poter utilizzare questa funzionalità è necessario aderire al tier standard di Security Center e nel caso specifico non sarà necessario prevedere costi aggiuntivi di licensing. Il tier Standard aggiunge anche funzionalità avanzate di rilevamento delle minacce (tra cui threat intelligence), analisi comportamentale, rilevamento delle anomalie e di incidenti di sicurezza e report di attribuzione delle minacce.

Qualora si voglia mantenere il tier Free di ASC è comunque possibile effettuate il deploy di soluzioni per effettuare una valutazione delle vulnerabilità, quali Qualys e Rapid7, ma è necessario prevedere la gestione dei costi di licensing, la distribuzione e la configurazione. Per maggiori dettagli in merito al costo di Azure Security Center e per un confronto tra il tier Free e quello Standard si rimanda alla documentazione ufficiale Microsoft.

La metodologia più rapida e immediata per effettuare una scansione delle vulnerabilità in Azure è utilizzare la soluzione Qualys integrata nel Standard Tier di Azure Security Center. Per abilitarla è sufficiente accedere alle Recommendations di ASC e selezionare “Enable the built-in vulnerability assessment solution on virtual machines (powered by Qualys)“, come mostrato dall’immagine seguente:

Figura 1 – Recommendation di Azure Security Center per abilitare la solution di vulnerability assessment

Selezionando questa opzione le macchine virtuali Azure vengono suddivise nelle seguenti categorie:

  • Healthy resources: sistemi dove è stato effettuato il deploy dell’estensione per portare a termine una scansione delle vulnerabilità.
  • Unhealthy resources: machine dove è possibile abilitare l’estensione per eseguire una scansione delle vulnerabilità.
  • Not applicable resources: sistemi dove non è presente l’estensione e che non è possibile l’abilitazione in quanto appartengono al tier free di ASC oppure perché il sistema operativo rientra tra quelli non supportati. Tra I sistemi operative supportati troviamo: RHEL 6.7/7.6, Ubuntu 14.04/18.04, Centos 6.10/7/7.6, Oracle Linux 6.8/7.6, SUSE 12/15, e Debian 7/8.

Figura 2 – Abilitazione della solution

Selezionando le macchine di interesse e premendo il pulsante Remediate verrà effettuato l’onboarding delle stesse nella soluzione built-in di Vulnerability Assessment. Ne consegue che sui sistemi sarà installata l’extension specifica e al termine dell’installazione sarà avviata in modo automatico la prima scansione. L’extesion si basa sull’Azure Virtual Machine agent e viene pertanto eseguita nel contesto Local Host sui sistemi Windows, e Root su quelli Linux.

Si riportano i nomi dell’extension che sarà presente sui sistemi abilitati, per le quali il provider sarà sempre Qualys:

  • Macchine Linux: “LinuxAgent.AzureSecurityCenter”
  • Macchine Windows: “WindowsAgent.AzureSecurityCenter”

Per quanto riguarda gli aggiornamenti dell’extension valgono le stesse regole che vengono applicate anche per altre extension e quindi le minor version dello scanner di Qualys saranno distribuite in modo automatico in seguito a una approfondita fase di test. In alcuni casi potrebbe essere necessarie delle azioni manuali per portare a termine l’aggiornamento.

Al termine della scansione eventuali vulnerabilità rilevate sui sistemi saranno riportate nelle Recommendations di ASC.

Figura 3 – Notifica di ASC che riporta la presenza di recommendations relative alle vulnerabilità intercettate

Selezionando la raccomandazione vengono riportati i dettagli di tutte le vulnerabilità rilevate, della severity e del relativo stato:

Figura 4 – Elenco delle vulnerabilità di security rilevate

Selezionando la singola vulnerabilità si possono consultare i dettagli, i potenziali impatti, le azioni per effettuare la remediation e i sistemi interessati.

Figura 5 – Informazioni riportate per ogni singola vulnerabilità rilevata

Conclusioni

Per rafforzare le security posture del proprio ambiente è sicuramente opportuno valutare l’adozione di Azure Security Center nel tier standard, che tra le varie funzionalità permette di controllare che siano applicati in modo rigoroso tutti i criteri di sicurezza e consente di monitorare costantemente i criteri di conformità. L’inclusione nella soluzione di uno strumento di valutazione delle vulnerabilità, fornito da Qualys, leader indiscusso del settore, aggiunge ulteriore valore alla soluzione, potendo attingere anche alla conoscenza maturata da questo vendor nella scoperta delle vulnerabilità.

[VIDEO] – Architecting and Implementing Azure Networking

Per implementare cloud ibridi in modo sicuro e allo stesso tempo funzionale è fondamentale una conoscenza approfondita dei vari aspetti legati al networking di Azure. Recentemente ho avuto il piacere di partecipare alla Cloud Conferenze Italia dove ho tenuto una sessione relativa al Networking di Azure. A questo proposito riporto il video della sessione dove vengono esplorati a 360° gli elementi chiave da tenere in considerazione per realizzare architetture di rete ibride, sfruttando al meglio i vari servizi offerti dalla piattaforma Azure, al fine di realizzare la miglior integrazione con l’ambiente on-premises, senza mai trascurare la sicurezza. Durante l’intervento sono stati approfonditi scenari avanzati di architetture di rete ibride, mostrando esempi reali, frutto di un’esperienza diretta sul campo.

L’encryption dei dati in Azure

Uno degli ambiti relativi al miglioramento delle Security Posture del sistema informativo aziendale è certamente la crittografia del dato che, tramite l’adozione di tecniche specifiche, permette di rendere leggibili i dati solamente a chi possiede la soluzione per decifrarli. In questo articolo viene fornita una panoramica di come l’encryption viene adottata in Azure e vengono riportati i riferimenti per effettuare ulteriori approfondimenti.

Per proteggere i dati nel cloud, è necessario prima di tutto prendere in considerazione i possibili stati in cui i dati possono trovarsi e valutare di conseguenza i relativi controlli che è possibile attuare. Le procedure consigliate per la sicurezza e la crittografia dei dati, in particolare in Azure, riguardano i seguenti stati:

  • At rest: include tutte le informazioni che risiedono in modo statico sui supporti storage fisici, sia magnetici che ottici.
  • In transito: quando i dati vengono trasferiti tra componenti, location oppure servizi, vengono definiti in transito. Ad esempio, il trasferimento di dati attraverso la rete, tramite un service bus oppure durante processi di input / output.

Encryption at Rest

L’Encryption at Rest è una tecnica fortemente raccomandata ed è un requisito prioritario per molte organizzazioni per adempiere a politiche di governance e di conformità dei dati. Differenti regolamenti specifici del settore e di governo, impongono la presenza di misure obbligatorie in materia di protezione e di crittografia dei dati. L’Encryption at Rest prevede quindi la crittografia del dato quando è persistente e viene utilizzata, oltre che per soddisfare i requisiti di conformità e normativi, anche per avere un elevato livello di protezione dei propri dai. La piattaforma Azure prevede nativamente l’adozione di avanzati meccanismi di sicurezza fisica, di controllo dell’accesso ai dati e di audit. Tuttavia, è importante adottare misure di sicurezza sovrapposte per far fronte a potenziali fallimenti, e l’Encryption at Rest è un’ottima soluzione per garantire la riservatezza, la conformità e la sovranità dei dati.

Modelli di crittografia dei dati lato server

I modelli di crittografia dei dati lato server si riferiscono alla crittografia eseguita dai servizi Azure. In questo modello è l’Azure Resource Provider che esegue le operazioni di crittografia e decrittografia. In Azure sono disponibili diversi modelli di Encryption at Rest lato server, ciascuno dei quali con caratteristiche differenti nella gestione delle chiavi, che possono essere applicati alle differenti risorse Azure:

  • Crittografia lato server mediante chiavi gestite dal servizio. In questo scenario le chiavi di crittografia vengono gestire da Microsoft e risulta essere una buona combinazione tra controllo e praticità.
  • Crittografia lato server usando chiavi gestite dal cliente in Azure Key Vault. Con questa modalità le chiavi di crittografia vengono controllate dal cliente tramite Azure Key Vault, ed è incluso il supporto per utilizzare le proprie chiavi (BYOK).
  • Crittografia lato server che utilizza chiavi gestite dal cliente su hardware controllato dal cliente. Questa metodologia permette al cliente di controllare le chiavi che risiedono su un repository controllato dal cliente, al di fuori del controllo Microsoft. Questa caratteristica è chiamata Host Your Own Key (HYOK). Tuttavia, la configurazione è articolata e al momento la maggior parte dei servizi di Azure non supporta questo modello.

Figura 1 – Server-side encryption model

Modelli di crittografia dei dati lato client

Il modello di crittografia dei dati lato client si riferisce alla crittografia eseguita all’esterno di Azure e viene effettuata direttamente dal servizio o dall’applicazione chiamante. Quando si adotta questo modello di crittografia, il Resource Provider in Azure riceve i dati crittografati senza la possibilità di decifrarli o di accedere alle chiavi di crittografia. In questo modello, la gestione delle chiavi viene eseguita dal servizio o dall’applicazione chiamante ed è oscura per il servizio Azure.

Figura 2 – Client-side encryption model

Encryption at Rest per i principali servizi Azure

Azure Storage

Azure Storage provvede in automatico alla crittografa dei dati quando vengono resi persistenti nell’ambiente cloud. Infatti, tutti i servizi Azure Storage (Blob storage, Queue storage, Table storage, ed Azure Files) supportano la crittografia dei dati at rest lato server ed alcuni di questi supportano anche la crittografia dei dati lato client e le chiavi di encryption gestite dal cliente.

  • Server-side: tutti i servizi storage di Azure di default hanno abilitata l’encryption server-side mediante chiavi gestite dal servizio. Per gli Azure Blob storage e gli Azure Files è supportata anche la crittografia usando chiavi gestite dal cliente in Azure Key Vault. La tecnologia utilizzata è chiamata Azure Storage Service Encryption, in grado in automatico di crittografare i dati prima di essere memorizzati e di decodificarli quando vengono acceduti. Questo processo è completamente trasparente all’utente e prevede l’utilizzo della crittografia AES a 256 bit, una delle crittografie a blocchi più potenti attualmente disponibili. La crittografia di Azure Storage è simile alla crittografia BitLocker in ambiente Windows. L’ Azure Storage encryption è abilitata di default per tutti i nuovi storage account e non può essere disabilitata. Gli storage account sono crittografati indipendentemente dal livello di prestazioni (standard o premium) o dal modello di distribuzione (Azure Resource Manager o classico). Tutte le opzioni di ridondanza previste per gli storage account supportano la crittografia e tutte le copie di uno storage account sono sempre crittografate. La crittografia non influisce sulle prestazioni degli storage account e non prevede costi aggiuntivi.
  • Client-side: questa encryption è al momento supporta da Azure Blobs, Tables, e Queues. Quando utilizzata il dato viene crittografato dal cliente gestendo le proprie chiavi e ne viene fatto l’upload come blob criptato.

Macchine Virtuali

Tutti i Managed Disks, le Snapshots e le immagini delle macchine virtuali in Azure sono criptati utilizzando Storage Service Encryption tramite chiavi gestite dal servizio. Durante l’elaborazione dei dati su una macchina virtuale, i dati possono essere mantenuti nel file di paging di Windows o nel file di swap Linux, in un crash dump oppure in un application log. Per ottenere quindi una soluzione di Encryption at Rest più completa su macchine virtuali IaaS e per dischi virtuali, che garantisce che i dati non vengano mai mantenuti in forma non crittografata, è necessario utilizzare Azure Disk Encryption . Questa funzionalità consente di proteggere macchine virtuali Windows, utilizzando la tecnologia Windows BitLocker, e le macchine virtuali Linux tramite DM-Crypt. Affidandosi ad Azure Disk Encryption si ottiene una protezione completa dei dischi del sistema operativo e dei volumi dati. Le chiavi di Encryption e i secrets sono protette all’interno del proprio Azure Key Vault. La protezione di macchine virtuali encrypted è supportata dal servizio Azure Backup. Per maggiori informazioni in merito ad Azure Disk Encryption è possibile consultare la documentazione ufficiale Microsoft.

Azure SQL Database

Azure SQL Database attualmente supporta la crittografia at rest secondo le seguenti modalità:

  • Server-side: l’encryption lato server è garantita tramite una funzionalità di SQL chiamata Transparent Data Encryption (TDE) e può essere attivata sia a livello di server che di database. A partire da giugno 2017 questa funzionalità è attiva di default per tutti i nuovi database. TDE protegge i dati e i file di log di SQL, utilizzando algoritmi di crittografia AES e Triple Data Encryption Standard (3DES). La crittografia dei file dei database viene eseguita a livello di pagina, le quali vengono crittografate prima di essere scritte su disco e vengono de-crittografate quando vengono lette in memoria.
  • Client-side: la crittografia dei dati lato client per Azure SQL Database è supportata tramite la funzionalità Always Encrypted, che utilizza chiavi generate e memorizzate lato client. Adottando questa tecnologia è possibile crittografare i dati all’interno delle applicazioni client prima di archiviarli nell’Azure SQL database.

Così come per Azure Storage e per Azure SQL Database, anche per molti altri servizi Azure (Azure Cosmos DB, Azure Data Lake, etc.) l’encryption dei dati at rest avviene di default, ma per altri servizi può essere attivata opzionalmente.

Encryption in Transit in Azure

Anche la protezione dei dati in transito deve essere un elemento essenziale da tenere in considerazione nella propria strategia di protezione dei dati. In genere è consigliato proteggere lo spostamento e lo scambio dei dati utilizzando sempre i protocolli SSL / TLS. In determinate circostanze, potrebbe essere opportuno isolare l’intero canale di comunicazione tra l’ambiente on-premises e il cloud utilizzando una VPN. Microsoft utilizza il protocollo TLS (Transport Layer Security) per proteggere i dati quando viaggiano tra i servizi cloud e i clienti. Infatti, viene negoziata una connessione TLS tra i datacenter Microsoft e i sistemi client che si connettono ai servizi di Azure. Il protocollo TLS garantisce autenticazione avanzata, privacy dei messaggi e integrità (consente il rilevamento di manomissioni, intercettazione e falsificazione dei messaggi).

Conclusioni

Il tema della protezione tramite encryption dei dati archiviati in ambiente Azure è ritenuto di fondamentale importanza per coloro che decidono di affidarsi ai servizi nel cloud. Sapere che tutti i servizi Azure forniscono opzioni di crittografia at rest e che per i servizi di base la crittografia è abilitata di default, è sicuramente molto confortante. Alcuni servizi supportano anche il controllo delle chiavi di encryption da parte del cliente e la crittografia lato client per offrire un maggiore livello di controllo e flessibilità. Microsoft sta migliorando costantemente i propri servizi per garantire un maggiore controllo delle opzioni di crittografia at rest ed ha l’obiettivo di abilitare l’encryption at rest come impostazione predefinita per tutti i dati dei clienti.

Come controllare l’esecuzione delle applicazioni tramite Azure Security Center

Azure Security Center mette a disposizione diversi meccanismi per prevenire le minacce di sicurezza e per ridurre le superfici di attacco del proprio ambiente. Uno di questi meccanismi è l’Adaptive Application Controls, una soluzione in grado di controllare quali applicazioni vengono eseguite sui sistemi. Azure Security Center utilizza il motore di machine learning per analizzare le applicazioni in esecuzione sulle macchine virtuali e sfrutta l’intelligenza artificiale per mettere a disposizione una lista di applicazioni consentite. In questo articolo vengono riportati i benefici che si possono ottenere adottando questa soluzione e come effettuare la configurazione.

Adottando questa soluzione, disponibile utilizzando il tier Standard di Azure Security Center, è possibile effettuare le seguenti operazioni:

  • Essere avvisati a fronte di tentativi di esecuzione di applicazioni malevole, che potenzialmente potrebbero non essere individuate da soluzioni antimalware. Per i sistemi Windows presenti su Azure è possibile anche applicare dei blocchi di esecuzione.
  • Rispettare la compliance aziendale, permettendo l’esecuzione solo di software regolarmente licenziato.
  • Evitare l’utilizzo di software non voluto oppure obsoleto all’interno della propria infrastruttura.
  • Controllare l’accesso ai dati sensibili che avviene utilizzando specifiche applicazioni.

Figura 1 – Azure Security Center Free vs Standard tier

Adaptive application controls può essere utilizzato sui sistemi indipendentemente dalla loro location geografica. Al momento per i sistemi non dislocati in Azure e per le VMs Linux, è supportata solamente la modalità di audit.

Questa funzionalità può essere attivata direttamente dal portale Azure accedendo al Security Center.

Figura 2 – Adaptive application controls nella sezione “Advanced cloud defense” di Security Center

Security Center utilizza un algoritmo proprietario per la creazione automatica di gruppi di macchine con caratteristiche simili, per facilitare l’applicazione delle policy di Application Control.

Dall’interfaccia di gestione i gruppi sono divisi in tre tipologie:

  • Configured: lista i gruppi contenenti VMs dove è configurata questa funzionalità.
  • Recommended: sono presenti i gruppi di sistemi dove è raccomandata l’abilitazione del controllo applicativo. Security Center utilizza meccanismi di machine learning per identificare le VMs sulle quali vengono eseguiti regolarmente sempre gli stessi applicativi, e pertanto risultano delle buone candidate per abilitare il controllo applicativo.
  • Unconfigured: elenco dei gruppi che contengono le VMs per le quali non sono presenti raccomandazioni specifiche riguardanti il controllo applicativo. Per esempio, VMs che eseguono sistematicamente applicative differenti.

Figura 3 – Tipologie di gruppi

Cliccando sui gruppi di macchine virtuali sarà possibile gestire le Application control rules, che permetteranno di creare delle regole in grado di valutare l’esecuzione delle applicazioni.

Figura 4 – Configurazione delle Application control rules

Per ogni singola regola si selezionano le macchine sulle quali applicarla e le applicazioni che si intende consentire. Per ogni applicazione vengono riportate le informazioni di dettaglio, in particolare, nella colonna “Expoitable” viene indicato se si tratta di una applicazione che può potenzialmente essere utilizzata in modo malevolo per bypassare la lista delle applicazioni consentite. Per questa tipologia di applicazioni è opportuno prestare molta attenzione prima di consentirle.

Questa configurazione, per i sistemi Windows, comporta la creazione di specifiche regole di Applocker, tramite le quali viene governata l’esecuzione delle applicazioni.

Di default, Security Center abilita il controllo applicativo in modalità Audit, limitandosi a controllare l’attività nelle macchine virtuali protette senza applicare nessun blocco sull’esecuzione delle applicazioni. Per ogni singolo gruppo, dopo aver verificato che la configurazione effettuata non comporta malfunzionamenti sui workload presenti sui sistemi, è possibile portare il controllo applicativo in modalità Enforce, purché siano macchine virtuali Windows in ambiente Azure, per bloccare l’esecuzione delle applicazioni non espressamente consentite. Sempre dalla stessa interfaccia è possibile cambiare il nome del gruppo dei sistemi.

Figura 5 – Cambio del nome e della modalità di protezione

Al termine di questa configurazione saranno riportate, nel pannello principale di Security Center, le notifiche riguardanti potenziali violazioni nell’esecuzione delle applicazioni rispetto a quanto consentito.

Figura 6 – Notifiche di violazione dell’esecuzione delle applicazioni in Securiy Center

Figura 7 – Lista completa delle violazioni riscontrate

Figura 8 – Esempio di segnalazione

Conclusioni

La funzionalità di Adaptive application controls consente con pochi passaggi di abilitare in modo rapido un controllo approfondito sulle applicazioni che vengono eseguite sui propri sistemi. La configurazione risulta semplice e intuitiva, soprattutto grazie alla funzionalità che permette di raggruppare i sistemi che hanno caratteristiche simili per quanto riguarda l’esecuzione degli applicativi. Si tratta pertanto di un importante meccanismo che consente di prevenire potenziali minacce di sicurezza e di ridurre al minimo le superfici di attacco del proprio ambiente. Sommato alle ulteriori funzionalità, Adaptive application controls contribuisce a rendere Security Center una soluzione completa per la protezione dei propri workload.

Come accedere remotamente alle macchine virtuali in ambiente Azure

Poter accedere tramite RDP (Remote Desktop Protocol) oppure via SSH (Secure SHel) alle macchine virtuali presenti in Azure è un’esigenza fondamentale per gli amministratori di sistema. L’esposizione diretta di questi protocolli su Intenet è sicuramente una pratica da evitare in quanto comporta un elevato rischio di security. In questo articolo vengono riportate le differenti metodologie che è possibile adottare per accedere remotamente ai sistemi presenti su Azure e le caratteristiche di ciascuna di essa.

Anche recentemente Microsoft ha rilasciato un aggiornamento di sicurezza considerato critico e indirizzato alla risoluzione della vulnerabilità CVE-2019-0708 individuata sul servizio Remote Desktop per diversi sistemi operativi. Tale vulnerabilità permette l’esecuzione di codice tramite protocollo RDP consentendo così di prendere il controllo completo del sistema remoto. Questa vulnerabilità viene portata a titolo di esempio per evidenziare quanto sia effettivamente rischioso pubblicare in Internet questi protocolli di accesso. Per questa ragione è opportuno valutare l’adozione di una delle soluzioni in seguito riportate per avere una maggiore sicurezza.

Figura 1 – RDP/SSH attack

Accesso VPN

Per disporre di un semplice accesso amministrativo verso la Virtual Network di Azure è possibile attivare un VPN di tipologia Point-to-Site (P2S). Tramite le VPN P2S è possibile instaurare la connettività da una singola postazione verso l’ambiente Azure, in modo semplice e sicuro. Stabilita la connessione VPN si avrà la possibilità di accedere remotamente ai sistemi presenti in Azure. Per maggiori informazioni sulle VPN P2S vi invito a leggere l’articolo Azure Networking: l’accesso VPN Point-to-Site e le novità introdotte. Adottando questa metodologia è opportuno tenere in considerazioni il numero massimo di connessioni possibili per singolo Azure VPN Gateway.

Figura 2 – Protocolli disponibili per le VPN P2S

Just-in-Time VM Access

Si tratta di una funzionalità disponibile in Azure Security Center Standard Tier, che consente di applicare le configurazioni necessarie ai Network Security Group (NSG) e recentemente anche ad Azure Firewall per consentire un accesso amministrativo ai sistemi, opportunamente filtrato per IP sorgente e per un determinato periodo di tempo. Just-in-Time VM Access consente di effettuare le configurazioni necessarie per accedere remotamente ai sistemi in modo rapido, mirato e solo per un periodo temporale ben specifico. Senza l’utilizzo di questa funzionalità sarebbe necessario creare manualmente apposite regole all’interno dei NSG oppure in Azure Firewall (NAT Rule), ricordandosi di rimuoverle quando non più necessarie.

Figura 3 – Richiesta di accesso tramite Just-in-Time VM Access

Jumpbox

Uno scenario che viene in alcune situazioni utilizzato è la presenza di una macchina virtuale (Jumpbox) accessibile remotamente e dislocata in una subnet opportunamente isolata, che viene utilizzata per accedere a diversi altri sistemi in comunicazione con quella subnet. In una architettura di rete che rispecchia la topologia hub-spoke, tipicamente questo sistema viene posizionato nella rete di Hub, ma è comunque consigliato applicare dei filtri per fare in modo che tale sistema sia raggiungibile solo da determinati indirizzi IP pubblici, senza esporlo direttamente in Internet. In questo scenario è opportuno tenere in considerazione che si avranno a disposizione al massimo due connessioni remote contemporaneamente per singola Jumpbox.

Figura 4 – Posizionamento della Jumpbox in una architettura hub-spoke

Azure Bastion

Si tratta di un servizio PaaS, recentemente annunciato in preview da Microsoft, che offre un accesso RDP ed SSH sicuro e affidabile alle macchine virtuali, direttamente tramite il portale di Azure. Il provisioning del servizio Azure Bastion viene effettuato all’interno di una Virtual Network di Azure e supporta l’accesso a tutte le macchine virtuali su di essa attestate, senza dover esporre degli indirizzi IP pubblici.

Figura 5 – Architettura di Azure Bastion

Per maggiori dettagli a riguardo vi invito a leggere l’articolo Azure Bastion: un nuovo modello di sicurezza di Silvio Di Benedetto.

Azure Bastion è un servizio a pagamento, per ottenere i dettagli sui costi è possibile accedere alla pagina Azure Bastion pricing.

Al momento è opportuno tenere in considerazione che Azure Bastion e Just-in-Time VM Access non possono essere utilizzati per accedere agli stessi sistemi.

SSL Gateway

Una soluzione molta valida in termini di sicurezza potrebbe essere quella di implementare in ambiente Azure una architettura Remote Desktop Services, che prevede l’utilizzo del ruolo Remote Desktop Gateway, appositamente pensato per essere direttamente esposto verso Internet (porta TCP 443). Grazie a questo componente è possibile incapsulare il traffico RDP in un tunnel HTTP over TLS/SSL. Il Remote Desktop Gateway supporta inoltre la Multi-Factor Authentication che consente di aumentare ulteriormente il livello di sicurezza per l’accesso remoto alle risorse. Una soluzione analoga è disponibile anche in ambiente Citrix. In questo ambito sarà necessario considerare, oltre ai costi legati ai componenti Azure, anche i costi di licenza.

Figura 6 – Possibile architettura Remote Desktop Services in ambiente Azure

Conclusioni

Diverse sono le possibilità per garantire un accesso remoto sicuro ai sistemi presenti in ambiente Azure. Il nuovo servizio Azure Bastion è un metodo sicuro e semplice, ma che necessita di essere ampliato con ulteriori funzionalità, tra le più importanti c’è sicuramente il supporto per Virtual Network in peering e per la multi-factor authentication. Tali funzionalità con molta probabilità saranno già disponibili nel momento dell’effettivo rilascio. In attesa di poter utilizzare Azure Bastion in ambiente di produzione è possibile adottare gli altri metodi riportati, evitando così di dover esporre i sistemi in modo non protetto verso internet.

Sicurezza nel cloud con la soluzione Azure Sentinel

Microsoft ha recentemente annunciato una nuova soluzione cloud chiamata Azure Sentinel. Si tratta di un servizio che intende ampliare le capacità e le potenzialità dei prodotti SIEM (Security Information and Event Management) tradizionali, andando ad utilizzare le potenzialità del cloud e l’intelligenza artificiale per poter identificare rapidamente e gestire le minacce di security che interessano la propria infrastruttura. In questo articolo vengono riportate le caratteristiche principali della soluzione.

Azure Sentinel è una soluzione che permette in tempo reale di analizzare eventi e informazioni di security generati all’interno della propria infrastruttura ibrida, provenienti da server, applicazioni, dispositivi e utenti. Si tratta di un servizio totalmente cloud-based, ne consegue che si può facilmente scalare ed avere elevate velocità nell’elaborazione delle informazioni, senza la necessità di dover implementare e gestire un’infrastruttura dedicata, per intercettare potenziali minacce di sicurezza.

Il servizio Azure Sentinel può essere attivato direttamente dal portale Azure:

Figura 1 – Creazione del servizio Azure Sentinel

Principi di funzionamento di Azure Sentinel

Raccogliere i dati all’interno dell’infrastruttura

Azure Sentinel si appoggia ad Azure Monitor che, utilizzando l’ormai collaudato e scalabile repository di Log Analytics, è in grado di ospitare una elevata mole di dati, i quali è possibile elaborarli efficacemente grazie a un motore che garantisce elevate performance.

Figura 2 – Aggiunta di Azure Sentinel a un workspace Log Analytics esistente

Con Azure Sentinel è possibile aggregare differenti dati di sicurezza provenienti da numerose fonti, utilizzando degli appositi connettori incorporati nella soluzione. Azure Sentinel è in grado di connettersi, oltre a differenti soluzioni della platform, anche alle soluzioni di rete più diffuse e popolari di vendor di terze parti, tra cui Palo Alto Networks, F5, Symantec, Fortinet e Check Point. Azure Sentinel dispone anche di una integrazione nativa con i log che rispettano i formati standard, come common event e syslog.

Figura 3 – Data Connectors

Utilizzando questa soluzione si ha inoltre la possibilità di importare facilmente i dati provenienti da Microsoft Office 365 e combinarli con altri dati di sicurezza, al fine di ottenere un’analisi dettagliata del proprio ambiente e avere visibilità sull’intera sequenza di un attacco.

Figura 4 – Office 365 Connector

Azure Sentinel si integra inoltre con l’API di Microsoft Graph Security, che consente di importare i propri feed di threat intelligence e di personalizzare le regole di rilevamento di potenziali incidenti di sicurezza e di notifica.

Analizzare e individuare rapidamente le minacce utilizzando l’intelligenza artificiale

Azure Sentinel utilizza algoritmi scalabili di apprendimento automatico, in grado di correlare una elevata quantità di dati di sicurezza, per presentare all’analista solo potenziali incidenti di sicurezza, il tutto con un elevato livello di affidabilità. Grazie a questo meccanismo Azure Sentinel si differenzia dalle altre soluzioni SIEM, che adottano motori di correlazione tradizionali, riducendo drasticamente il rumore e di conseguenza l’effort per le valutazioni necessarie nella rilevazione delle minacce.

Figura 5 – Azure Sentinel Overview

In seguito all’abilitazione dei Data Collector necessari, si inizieranno a ricevere i dati nel workspace di Log Analytics e configurando delle Alert Rules, è possibile generare dei Cases per segnalare delle potenziali minacce di sicurezza. Per maggiori dettagli su come rilevare dei threats con Azure Sentinel si rimanda alla documentazione ufficiale Microsoft.

Indagare attività di security sospette

I dati elaborati dalla soluzione sono consultabili utilizzando delle dashboard, personalizzabili in base alle proprie esigenze. Le dashboard consentono di condurre le indagini riducendo i tempi necessari per comprendere la portata di un attacco e il suo impatto.

Figura 6 – Dashboard disponibili in Azure Sentinel

Figura 7 – Azure Network Watcher dashboard

Nel caso vengano rilevate delle minacce di sicurezza, a fronte delle Alert Rule impostate, viene generato un Case, per il quale è possibile impostare la severity, lo status e la relativa assegnazione.

Figura 8 – Cases

Tramite la console è possibile procedere con l’investigation del case:

Figura 9 – Case Investigation

Nelle stesse dashboard è anche possibile compiere azioni. Le attività di ricerca proattiva di operazioni sospette sono un aspetto fondamentale per gli analisti della sicurezza, che con Azure Sentinel possono essere effettuate tramite due funzionalità specifiche che consentono di automatizzare l’analisi: query di ricerca (hunting queries) e Azure Notebooks (basati sui notebook Jupyter), che vengono costantemente aggiornati.

Figura 10 – Hunting queries

Figura 11 – Esempio di un Azure Notebook

Automatizzare le attività comuni e la risposta alle minacce

Azure Sentinel fornisce la possibilità di automatizzare e orchestrare le risposta ai problemi più comuni, in modo da non dover compiere manualmente attività ripetitive. Tramite dei playbooks predefiniti e personalizzabili è possibile rispondere rapidamente alle minacce di sicurezza.

Figura 12 – Alert playbooks

Figura 13 – Logic Apps Designer

Microsoft ha inoltre annunciato che saranno aumentati gli strumenti di difesa e investigazione integrati nella soluzione.

Conclusioni

Azure Sentinel è una soluzione completa che fornisce un SIEM nativo nel cloud e introduce importanti benefici rispetto alle soluzioni SIEM tradizionali, le quali richiedono di sostenere costi elevati per la manutenzione dell’infrastruttura e per l’elaborazione dei dati. Azure Sentinel consente ai clienti di semplificare le attività necessarie per mantenere elevata la sicurezza dell’infrastruttura e di scalare gradualmente in base alle proprie esigenze, mettendo a disposizione un’ampia integrazione con soluzioni di terze parti.