Archivi categoria: Cybersecurity

Utilizzare certificati gratuiti di Let’s Encrypt in una Azure Web App

Facebooktwittergoogle_plusredditlinkedin

Da quando è nata, il 12 aprile 2016, abbiamo avuto modo di parlare in diversi articoli della Certification Authority gratuita Let’s Encrypt. In questo articolo voglio far vedere come ottenere un certificato digitale gratuito generato da Let’s Encrypt da utilizzare con una Web App di Azure.

È infatti disponibile nelle Azure Web App un’estensione, creata da Simon J.K. Pedersen, che permette di ottenere e di rinnovare i certificati digitali da utilizzare con i Custom Domains delle Azure Web App.

Darò per scontato che abbiate già creato una Azure Web App e vi farò vedere come attivare l’estensione per Let’s Encrypt.

Creazione del Service Principal (Registered App)

La prima operazione che faremo sarà quella di creare un Service Principal in Azure AD. Si tratta fondamentalmente di un service account che viene utilizzato per ottenere un accesso alle risorse di Azure e che ci permetterà di richiedere e rinnovare il certificato digitale di Let’s Encrypt senza che sia necessario alcun intervento manuale. La creazione del Service Principal può essere effettuata dal portale di Azure selezionando la directory dentro la quale lo volete creare, scegliendo il nodo App Registrations e cliccando su + New application registration, come mostrato in figura:

Figure 1: Creazione di un nuovo Service Principal in Azure AD

Nel blade che si aprirà digitate il nome che volete dare al Service Principal (io ho scelto nicferr) e l’url della Web App, come mostrato in figura:

Figure 2: configurazione di un nuovo Service Principal in Azure AD

Una volta che avrete creato la Registered App sarà necessario creare una Secret Key (password). Infatti, per le autenticazioni utilizzeremo la combinazione Application ID e Secret Key per permettere all’estensione di Let’S Encrypt di potersi autenticare ed effettuare le operazioni di richiesta e rinnovo del certificato. Cliccate quindi su Settings e scegliete il nodo Keys. Creare una nuova password semplicemente scrivendo la description e la data di scadenza, come mostrato in figura. Quando cliccherete su Save la chiave verrà generata automaticamente.

Figure 3: Creazione di una nuova chiave di accesso per la Registered App

Dopo il salvataggio sarà possibile copiare la chiave generata automaticamente. Ricordatevi di salvarla perché non sarà successivamente visibile, come avrà modo di suggerirvi il banner mostrato in figura:

Figure 4: Generazione della chiave completata

Terminata la creazione del Service Principal (Registered App) sarà necessario assegnargli i giusti permessi per poter eseguire l’estensione. Andate nel Resource Group che ospita la vostra Web App e dal nodo Access Control (IAM), cliccate su Add e date il ruolo di Contributor alla Registered App che avete creato. La Registered App non sarà visibile nell’elenco, ma vi basterà scriverla nel campo Select e sarà subito trovata, come mostrato in figura

Figure 5: Aggiunta dei privilegi al Service Principal (Registered App)

ATTENZIONE: Se la Web App e l’App Service Plan si trovano in due Resource Group differenti, sarà necessario dare il permesso di Contributor ad ENTRAMBI

Installazione dell’estensione Let’s Encrypt

Terminata la fase preparatoria, siamo pronti per installare le due estensioni necessarie a far funzionare Let’S Encrypt con una Azure Web App. Dal portale di Azure, selezionate la Web App e dal nodo Extensions cliccate su Add per aggiungere l’estensione, come mostrato in figura:

Figure 6: Aggiunta di una estensione alla Web App di Azure

Scegliete l’estensione Azure Let’s Encrypt dalla lista delle estensioni disponibili e procedete all’installazione

Figure 7: Scelta dell’estensione Azure LEt’s Encrypt

Questa estensione NON è supportata da Microsoft. È bene tenerne conto nel caso ci siano malfunzionamenti, perché l’autore non da garanzie, come esplicitamente dichiarato nei termini legali.

Figure 8: Accettazione dei termini legali di utilizzo

L’estensione sarà subito visibile tra quelle installate

Figure 9: Installazione dell’estensione completata

Aggiungete anche l’estensione Azure Let’s Encrypt (no Web Jobs)

Figure 10: Aggiunta dell’estensione Azure Let’s Encrypt (no Web Jobs)

Se vi spostate nel modo WebJobs della vostra Web App potrete notare che sarà stata installato un nuovo webjobs, che servirà a rinnovare il certificato prima della scadenza.

Figure 11: Creazione del WebJob nella Web App

Configurazione dell’estensione di Azure Let’s Encrypt

Siamo ora pronti per configurare l’estensione. Cliccate sul tasto Browse dell’estensione Azure Let’s Encrypt per aprire la pagina di configurazione, come mostrato in figura:

Figure 12: Configurazione dell’estensione

Nella nuova pagina del browser vi apparirà la possibilità di configurare in maniera completamente automatica la richiesta e il rinnovo del certificato. Completate tutti i campi come richiesto. Maggiori dettagli su quello che deve essere inserito nei diversi campi sono anche disponibili alla pagina https://github.com/sjkp/letsencrypt-siteextension/wiki/How-to-install

Figure 13: inserimento delle informazioni necessarie per configurare l’estensione

Cliccando su Next si avvierà il processo di richiesta del certificato. Se non avete aggiunto dei Custom Domain alla vostra Web App vi apparirà l’errore mostrato in figura 15:

Figure 14: Prima richiesta del certificato

Figure 15: Errore relativo alla mancanza di un Custom Domain per cui richiedere il certificato

Aggiunta di un host name per il Custom Domain

Aggiungere un Custom Domain alla Web App richiede pochi semplici passaggi, ben descritti nell’esercitazione Eseguire il mapping di un nome DNS personalizzato esistente ad una Web App di Azure

Figure 16: Aggiunta di un host name personalizzato alla Web App

Una volta che avrete aggiunto il Custom Domain, rilanciando la configurazione dell’estensione di Let’s Encrypt, vedrete che il wizard potrà proseguire e vi chiederà per quale hostname volete generare il certificato, come mostrato in figura:

Figure 17: Il wizard ha riconosciuto gli hostname personalizzati

Figure 18: Scelta del nome host per cui richiedereil certificato

Dopo qualche secondo, il certificato sarà stato creato e associato (binding) all’hostname che avete scelto nel wizard.

Figure 19: Creazione del certificato completata

Se provate a caricare la vostra Web App infatti vedrete che starà utilizzando un certificato emesso da Let’s Encrypt, come mostrato in figura:

Figure 20: La Web App utilizza il certificato emesso da Let’s Encrypt

Conclusioni

Sono decisamente notevoli I vantaggi offerti da Let’s Encrypt, che ci permette di avere certificati digitali gratuiti ed automaticamente rinnovati. Poterli integrare con le Azure Web App ed avere la possibilità di utilizzare il protocollo HTTPS anche per gli hostname personalizzati garantisce i migliori livelli di sicurezza per la navigazione web.

Implementare Azure AD password protection per Windows Server Active Directory

Facebooktwittergoogle_plusredditlinkedin

Una delle problematiche relative alla sicurezza più evidenti nelle aziende è l’utilizzo di password troppo facili da parte degli utenti. Problemi legati alla memorizzazione, alla troppa lunghezza della password imposta a livello di dominio e alla complessità richiesta fanno si che gli utenti spesso si servano di password facilmente individuabili.

Abbiamo già avuto modo di parlare della modifica delle password policies In Active Directory nell’articolo Active Directory Password Policies: facciamo un po’ di chiarezza, soprattutto perché le aziende si sono dovute adeguare all’entrata in vigore delle sanzioni previste dal GDPR in merito alla sicurezza dei sistemi.

In questo articolo ci occuperemo invece di implementare Azure AD password protection per Windows Server Active Directory, sfruttando una funzionalità del Cloud per proteggere i nostri sistemi dall’utilizzo di password troppo semplici. Andremo cioè a migliorare le password policies previste on-premises sfruttando una funzionalità che è già presente in Azure AD, che ci permetterà di effettuare un controllo delle password sia on-premises che nel Cloud.

Azure AD password protection

Azure AD password protection è una funzionalità disponibile in Azure se avete sottoscritto il piano Azure AD P1 Premium, che vi permette di evitare che i vostri utenti utilizzino password prese da una lista di più di 500 password comunemente utilizzate ed oltre un milione di variazioni delle stesse password che utilizzano la sostituzione di alcuni caratteri. Un esempio eclatante è Pa$$w0rd1!, in cui la parola “password” viene resa più “difficile” da indovinare utilizzando maiuscole, minuscole, caratteri speciali e numeri. In realtà molte di queste password sono facilmente individuabili.

Quindi Azure AD password protection non è altro che un sistema che “banna” le password nel momento in cui gli utenti cercano di cambiarla (perché l’hanno dimenticata oppure perché è scaduta) e può essere anche personalizzato (immaginate quante persone in questo momento stanno utilizzando la password “Luglio2018!” ) 😊

Una volta che avete acquistato il piano Azure AD Premium 1 potete personalizzare la lista delle password “bannate” semplicemente andando in Azure Active Directory à Authentication Methods (attualmente ancora in Preview) dal portale di Azure, come mostrato in figura:

Figura 1: Personalizzazione delle configurazioni di Azure AD Password Protection

Dal portale sarà possibile inserire una lista di password che volete “bannare” e come si può vedere è abilitata di default la voce Enable password protection on Windows Server Active Directory. In maniera predefinita la funzionalità è in modalità Audit, per permettervi di testarla. Una volta terminate tutte le configurazioni potrete metterla in modalità Enforced ed iniziare ad utilizzarla.

Nella stessa finestra è anche possibile personalizzare Smart Lockout. Smart Lockout è una funzionalità abilitata di default per tutti gli utenti di Azure AD (è gratuita e non richiede un piano aggiuntivo) che utilizza l’intelligenza artificiale per bloccare tutti i tentativi di accesso malevoli ai nostri account di Azure AD. Ci sono circa 10 milioni di tentativi giornalieri registrati da Microsoft da parte di malintenzionati che usano combinazioni di username e password per indovinare l’accesso degli utenti. Con Smart Lockout è possibile riconoscere se l’accesso proviene da un utente valido (che magari in quel momento non ricorda la password) oppure proviene da una sorgete sconosciuta (ad esempio un indirizzo IP che generalmente non utilizziamo per connetterci).

Utilizzare Azure AD password protection in Windows Server Active Directory

È possibile utilizzare la funzionalità appena descritta anche per proteggere gli utenti di dominio dall’utilizzo di password troppo facili. Per poter controllare quindi che anche on-premises non vengano utilizzate le password “bannate” o le password troppo “riconoscibili” è necessario installare on-premises due componenti software diversi:

  1. Azure AD password protection proxy service, che serve ad inoltrare le richieste dal domain controller ad Azure AD
  2. Azure AD password protection DC agent service, che riceve le richieste di validazione delle password, le processa utilizzando le password policy scaricate localmente (ogni ora) da Azure AD password protection e accetta/rifiuta la password scelta dall’utente

Figura 2: Processo di validazione delle password utilizzando la password policy scaricata da Azure AD Password Protection

Nessuna connessione Internet è richiesta dai Domain Controller. L’unica macchina che si connetterà ad Internet sarà quella in cui avete installato Azure AD password protection proxy service. Non verranno apportate modifiche allo Schema di Active Directory né tantomeno è richiesto un livello minimo funzionale di foresta e/o di dominio per l’utilizzo di Azure AD password protection con Windows Server Active Directory. Non verrà creato nessun utente locale.

Installazione del software

Al link Azure AD password protection for Windows Server Active Directory (preview) troverete i due installer per i due componenti software già citati. Installate il componente AzureADPasswordProtectionProxy.msi su una macchina joinata al dominio locale di Active Directory, che abbia l’accesso ad Internet, mentre installate il componente AzureADPasswordDCAgent.msi su tutti i domain controller della vostra infrastruttura. Attenzione perché il componente AzureADPasswordDCAgent richiede il riavvio del domain controller.

Figura 3: Download dei due software richiesti per l’abilitazione di Azure AD password protection for Windows Server Active Directory

Procedete all’installazione, su tutti i Domain Controller della vostra infrastruttura di Active Directory on-premises, dell’ Azure AD Password Protection DC Agent

Figura 4: Azure AD password protection DC Agent – License Agreement

Figura 5: Azure AD password protection DC Agent – Installazione del servizio

Figura 6: Azure AD password protection DC Agent – Installazione completata

Figura 7: Azure AD password protection DC Agent – Riavvio del domain controller necessario

Procedete all’installazione, in una macchina joinata al dominio e connessa ad Internet, dell’ Azure AD Password Protection proxy

Figura 8: Azure AD password protection proxy – License Agreement

Figura 9: Azure AD password protection proxy – Avvio servizi

Figura 10: Azure AD password protection proxy – Installazione completata

Terminata la procedura di installazione dei due software è necessario registrare la foresta di Active Directory ed il Password Protection Proxy con Azure AD. Posizionatevi sul server dovete avete installato il Password Protection Proxy, lanciate un prompt di PowerShell con le credenziali di Domain Admin e lanciate le due cmdlet Register-AzureADPasswordProtectionForest e Register-AzureADPasswordProtectionProxy . Autenticatevi con i permessi di un Global Admininistrator della vostra istanza di Azure AD, ma accertatevi che non usi la Multi-Factor Authentication perché nella Preview non può essere utilizzata (MFA potrà essere utilizzata nella versione finale).

Figura 11: Registrazione della foresta e del proxy di Azure AD Password protection

Verifica della funzionalità di Azure AD Password protection

Se volete forzare l’utilizzo di Azure AD Password protection e quindi impedire l’uso di password comuni o che avete deciso di “bannare” è necessario mettere a Enforced la Password protection for Windows Server Active Directory.

Figura 12: Modalità Enforced per la Password protection for Windows Server Active Directory

Se un amministratore tenta di resettare la password dell’utente ed utilizza una password “bannata” oppure non rispetta i prerequisiti dettati dalla password policy di Azure AD Passsword protection riceverà un errore come quello in figura:

Figura 13: Reset della password utente da parte dell’amministratore

Se un utente tenta, al momento di cambiare la password, di immettere una password non consentita riceverà un messaggio di errore tipico in cui lo si avvisa che non sta rispettando i requisiti di cronologia, di lunghezza o di complessità della password

Figura 14: All’utente viene chiesto di cambiare la password

Figura 15: Inserimento di una password non consentita dalla policy di Aure AD Password Protection

Figura 16: Messaggio di errore ricevuto dall’utente che ha cercato di usare una password “bannata”

Nel Domain Controller on-premises utilizzato per l’autenticazione sarà anche possibile verificare che la richiesta di cambiamento password dell’utente è stata rifiutata perché non soddisfa i requisiti imposti dalla Azure AD Password Policy (che come abbiamo detto viene scaricata ogni ora) andando nel registro Eventi nel ramo Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Admin.

Figura 17: Evento di errore relativo al rifiuto del cambiamento della password dell’utente perché non soddisfa la Azure password policy

Con la cmdlet di PowerShell Get-AzureADPasswordProtectionSummaryReport è anche possibile ottenere un report minimale

Figura 18: Reportistica tramite PowerShell

Per ulteriori informazioni sul logging e sul troubleshooting vi invito a leggere l’articolo Azure AD password protection monitoring, reporting, and troubleshooting

Conclusioni

Azure AD password protection per Windows Server Active Directory ci aiuta, grazie al Cloud, ad evitare che gli utenti utilizzino delle password troppo semplici o, anche se complesse, troppo comuni e facilmente indovinabili. Sicuramente una funzionalità utilissima per combattere le password prevedibili, oppure per impedire i Password Spray Attack, grazie ad un copioso database (abbiamo parlato di circa 500 password ed 1 milione di varianti) e all’Intelligenza Artificiale che il Cloud ci mette a disposizione.

Pubblicare applicazioni aziendali con Azure Active Directory Application Proxy

Facebooktwittergoogle_plusredditlinkedin

La necessità di rendere utilizzabili al di fuori del perimetro aziendale le applicazioni interne è un’esigenza ormai quotidiana, ma la disponibilità esterna di queste risorse costringe necessariamente chi amministra l’infrastruttura ad “aprire le porte” verso Internet, con tutte le implicazioni dal punto di vista della sicurezza che questo comporta.

Sono state e sono tutt’ora utilizzate una serie di tecniche di mitigazione, ad esempio l’impiego di proxy a reverse con l’utilizzo di sistemi di re-writing degli URL, che consentono una separazione netta delle connessioni in ingresso e forniscono una certa sicurezza sulle risorse esposte.

Questa architettura permette la collocazione in DMZ di sole macchine con il compito di gestire le richieste in ingresso e ridirigerle poi, con alcune regole di controllo all’interno. In questo modo le infrastrutture sensibili non hanno contatto diretto con l’esterno.

Contestualmente a questi accorgimenti l’adozione di sistemi IDS/IPS “garantiscono” un accettabile livello di sicurezza.

In ogni caso questo approccio ha richiesto e richiede che il firewall perimetrale consenta la connessione ed “apra” almeno una porta verso l’interno, richiede anche che i vari apparati posti a controllo del perimetro siano costantemente aggiornati e verificati

Azure Active Directory Application Proxy

In Microsoft Azure è disponibile un servizio che si lega in modo stretto con Azure Active Directory e che in maniera concettualmente del tutto nuova permette in modo semplice la fruizione delle applicazioni ad utenti esterni all’azienda.

Questo servizio è Azure Active Directory Application Proxy, disponibile con la versione BASIC o PEMIUM di Azure Active Directory.

Per poter utilizzare la funzione di Application Proxy, dal portale di Azure è sufficiente, selezionata la Directory di riferimento, attivare la funzionalità in prova valida per 30 giorni e successivamente terminata la fase di test, effettuarne l’acquisto.

Figura 1: Abilitazione servizi AAD Premium

Figura 2: Attivazione di Azure AD Premium P2 Trial

Attivata la funzionalità di Azure AD Premium è necessario installare il componente Application Proxy Connector. La scelta più corretta è quella di dedicare un sistema server a questa funzione, scelta che permette una migliore scalabilità delle risorse e di gestione.

Figura 3 Download componente Connector

Per configurare correttamente regole di uscita dell’Application Proxy è utile la lettura del documento Attività iniziali del proxy di applicazione e installazione del connettore

Mentre per un controllo diretto ed una verifica puntuale della configurazione è disponibile il tool Azure Active Directory Application Proxy Connector Ports Test Tool

È anche possibile permettere che il Connector interno utilizzi per collegarsi ad Azure un Web Proxy , questo qualora non fosse possibile agire direttamente sul Firewall per definire regole puntuali di uscita.

In questo caso è bene considerare che un possibile malfunzionamento del Web Proxy stesso si ripercuoterebbe necessariamente sulla raggiungibilità delle applicazioni.

L’aspetto interessante, relativo alla sicurezza del sistema, è che NON è richiesto che in ingresso venga definita alcuna regola sul Firewall.

L’applicazione che è utilizzata esternamente sarà disponibile tramite il portale Azure e sarà la componente Application Proxy che si occuperà di renderla accessibile e di “dialogare” con il Connector interno, che è la sola componente ad avere contatti con l’applicazione in rete locale.

Per analogia con il sistema tradizionale a Reverse Proxy il Connector è un Reverse Proxy, con la sola ma importante differenza che questo, come detto sopra, non ha contatti con l’esterno ma riceve e reindirizza le richieste dalla componente cloud.

Figura 4: Principio di funzionamento di Azure Active Directory Application Proxy

A questo punto è evidente che l’infrastruttura di sicurezza Aziendale può essere “alleggerita” in quanto come già detto non è richiesto che siano attivate porte in ascolto, questo compito è demandato ad Azure.

Pubblicazione di una applicazione interna tramite Azure AD Application Proxy

Dal portale di Azure selezionare la directory in cui si è abilitata la funzione e successivamente selezionare Configura un’app

Figura 5: Aggiunta dell’applicazione on-premises da esporre

Nella maschera successiva scegliere “Add your own on-premises application”

Verrà così proposta una ulteriore videata con le specifiche proprie dell’applicazione che si intende pubblicare

  • Nome serve ad identificare l’applicazione all’interno del portale di accesso e di configurazione
  • URL interno è l’effettivo URL che il connettore installato on premise contatterà (di norma l’Url dell’applicazione interna)
  • URL Esterno è il riferimento
    pubblico per la raggiungibilità dell’applicazione interna, nel caso si usi un dominio Custom, questo è selezionabile dalla casella
  • Metodo di Autenticazione Preliminare è effettivamente la modalità con cui gli utenti accederanno all’autenticazione dell’applicazione.

Con la modalità Azure AD l’utente verrà effettivamente autenticato con i servizi di Azure e quindi beneficiando anche di quelle che sono le prerogative di questi utenti: gestione Self-Service della password, possibilità di definire criteri di sblocco personalizzati, accesso da dispositivi con determinate caratteristiche etc.

Con la modalità Passtrough invece, all’utente viene proposto direttamente (se previsto) il login dell’applicazione interna.

Nel caso in cui sia impostata la modalità Azure AD e l’applicazione (tipicamente legacy) non sia in grado di utilizzare di questa modalità, verrà richiesta una seconda autenticazione.

A questo punto è possibile accedere all’applicazione, è da notare che di default tutto il traffico è in HTTPS e viene utilizzato un certificato generato per il nome host definito.

Tuttavia, siccome si possono anche gestire URL esposti in Azure con FQDN del proprio dominio pubblico è possibile effettuare l’upload di un certificato aziendale.

Controllo delle funzionalità del Connector Gateway

Questo oggetto non ha particolari opzioni di configurazione, all’atto dell’installazione, viene richiesto un account amministratore globale della directory e con questo il gateway si registra ed autentica sulla directory stessa.

È possibile all’interno del registro eventi rilevare eventuali errori o anomalie archiviate in AadApplicationProxy (fig.6)

Sono anche disponibili, al fine di valutare le performance di questo servizio alcuni Performance Counters (fig.7)

Figura 6: Contatori disponibili per la verifica delle performance del servizio

Figura 7: Aggiunta dei contatori

Considerazioni relative agli aspetti di sicurezza

Controllo tramite NMAP delle informazioni deducibili tramite un port SCAN

Al di là delle considerazioni espresse in precedenza, un piccolo e sicuramente approssimativo test relativo agli aspetti legati alla sicurezza è stato condotto utilizzando NMAP.

Tramite questo tool si è cercato di identificare il sistema operativo sul quale l’applicazione è installata.

Sono stati effettuati due TEST distinti, il primo verso una applicazione esposta in modo tradizionale FWàRev-ProxyàApplicazione

Figura 8: Scansione verso l’esposizione con Reverse Proxy tradizionale

Nmap seppure con una certa approssimazione ha rilevato un host Linux fig. sopra

Ed il secondo sempre verso la stessa applicazione ma esposta tramite AZURE con la struttura descritta sopra

Figura 9 Scansione verso l’esposizione con Azure Application Proxy

Nmap non è riuscito ad identificare il sistema verso il quale ha fatto la scansione.

Conclusioni

Partendo dall’assunto che non esiste LA soluzione perfetta, sicura e garantita e vista anche la velocità di implementazione e il discreto grado di sicurezza by-default dell’infrastruttura, la soluzione di Azure Application Proxy può essere un valido aiuto alle realtà che necessitano di rendere fruibili le proprie applicazioni all’esterno del perimetro aziendale.

Riferimenti:

Azure Application Proxy Connector

Azure Application Proxy Connector – connessione tramite proxy interno

Risoluzione dei problemi relativi alla pubblicazione di applicazioni tramite Azure

Sicurezza

Configurare il disaster recovery delle Azure VM in una regione secondaria di Azure

Facebooktwittergoogle_plusredditlinkedin

Azure Site Recovery è un servizio che permettere di poter replicare in Microsoft Azure le nostre macchine fisiche on-premises e le nostre macchine virtuali Hyper-V oppure VMware, per poterle avviare nel momento in cui si verifica un disastro. Ho già avuto modo di affrontare in diversi articoli come proteggere macchine virtuali VMware e come proteggere e migrare server fisici con Azure Site Recovery. Per chi volesse sapere cosa offre e come funziona Azure Site Recovery consiglio la lettura del documento Informazioni su Site Recovery.

In questo articolo vi voglio parlare di come effettuare il Disaster Recovery (DR) di una macchina virtuale ospitata in Microsoft Azure.

Il servizio, disponibile solo da pochi giorni, permette di replicare una macchina virtuale da una Region di Azure verso un’altra Region, in modo tale che se il sito primario non sia disponibile (per un disastro, per problemi di connettività, ecc..) la macchina virtuale possa essere accesa nel sito secondario e sia già pronta per poter eseguire le applicazioni.

Creazione del Recovery Service Vault

Prima di procedere all’abilitazione della replica della nostra Azure VM è necessario creare un Backup and Site Recovery Vault. Collegatevi al portale di Azure e dopo esservi autenticati create un nuovo Recovery Services Vault, come mostrato in figura. Quando create il Recovery Services Vault considerate sempre due fattori:

  • Il Recovery Services Vault non si deve trovare nella Region di Azure dove si trovano le Azure VM da proteggere
  • Il Resource Group in cui inserite il Recovery Services Vault non deve essere nella Region delle VM da proteggere

Le due condizioni sono necessarie perché, in caso di disastro nella Region dove sono ospitate le VM, non sarebbero disponibili né Resource Group né Recovery Services Vault!


Figura 1: Creazione del Recovery Services Vault in una Region diversa da quella dove sono ospitate le Azure VM da proteggere

Protezione delle Azure VM

Terminata la creazione del Recovery Services Vault siamo pronti per proteggere le nostre Azure VM. Dal portale di Azure vi basterà selezionare la VM da proteggere e cliccare sul collegamento Disaster Recovery. Nel blade che si aprirà configurate la Region di destinazione della replica della vostra VM ed il Resource Group, la VNET, lo Storage Account e tutti gli altri parametri richiesti, come mostrato in figura:

Figura 2: Configurazione della Replica della VM e Replication settings

Attenzione: Per poter abilitare la replica della VM è necessario che nella macchina virtuale sia installato l’Azure VM agent. Nel caso non lo fosse o nel caso non rispondesse alle richieste del portale riceverete un messaggio come quello mostrato in figura:

Figura 3: Messaggio di errore nel caso l’Azure VM agent non sia installato o non funzioni

L’abilitazione della replica dura diversi minuti. Potete controllare lo stato della replica dalle notifiche, come mostrato in figura:

Figura 4: Notifiche sulla creazione degli oggetti necessari alla replica della VM

Selezionando la VM e cliccando su Disaster Recovery sarà possibile visualizzare il Site Recovery Job iniziale di abilitazione della replica, come mostrato in figura:

Figura 5: Informazioni sullo stato di replica della Azure VM

Figura 6: Job di abilitazione della replica

Dal blade del Disaster Recovery sarà sempre possibile tenere sotto controllo lo stato di replica della VM e sarà possibile modificare i parametri. Cliccate sul tasto Settings e modificate i parametri della VM replicata. Potete ad esempio decidere in quale Resource Group accenderla e a quale VNET collegarla, oltre ovviamente alla dimensione che deve avere.

Figura 7: Configurazioni della VM replicata

Test del Failover

È sempre buona norma testare periodicamente il failover e verificare che tutto funzioni nella VM che avete replicato. Per effettuare il test vi basta cliccare su Test Failover e seguire le istruzioni. Vi verrà chiesto il Recovery Point che volete testare e la Azure VNET a cui collegare la VM.

Figura 8: Failover Test della VM

Dopo qualche minuto, nel Resource Group dove avete deciso di avviare la macchina per testare il Failover, apparirà la VM e vi ci potrete collegare per poter verificare che tutto funzioni perfettamente.

Figura 9: Macchina virtuale di test per il Failover

Dopo le opportune verifiche potete cliccare su Cleanup test failover e cancellare la macchina virtuale di test, come mostrato in figura:

Figura 10: Cleanup test failover

Failover della Azure VM

Per poter eseguire il Failover della Azure VM è sufficiente cliccare sul pulsante Failover e dal blade scegliere quale Recovery Point applicare e se spegnere la macchina prima di iniziare il failover. Lo spegnimento della macchina ha senso ovviamente in un Failover programmato e non in caso di vero disastro 🙂

Figura 11: Failover della Azure VM nella seconda Region di Azure

Terminato il Fialover potete decidere anche di cambiare recovery point utilizzando il pulsante Change recovery point oppure confermare la scelta fatta utilizzando il pulsante Commit. Dopo aver effettuato il Commit però non sarà più possibile modificare il Recovery Point.

Figura 12: Commit della macchina virtuale e completamento del Failover

Terminato il disastro è possibile riproteggere la Azure VM utilizzando il pulsante Re-protect. La macchina verrà replicata nuovamente verso la Region di partenza, ma se volete potete cliccare sul pulsante Customize e modificare i parametri, scegliendo il Resource Group, la VNET, lo Storage Account e l’Availability Set della macchina di destinazione.

Figura 13: Re-protect della Azure VM

Conclusioni

Il Disaster Recovery è decisamente importante vista la nostra dipendenza dai sistemi IT. Nonostante tutti gli sforzi profusi, può capitare sempre che accada qualcosa di imprevisto che interrompa la possibilità di usufruire dei servizi. Nonostante il Cloud sia stato concepito per essere affidabile, è buona norma essere sempre preparati al peggio. La replica delle VM di Azure è sicuramente una funzionalità interessante per essere certi di poter gestire un disastro importante e per assicurare alle aziende che hanno anche degli obblighi contrattuali o delle esigenze molto stringenti in ambito di Disaster Recovery di poter usufruire delle VM ospitate in Azure ed essere compliant con le loro specifiche.

Per approfondimenti potete visitare la pagina Set up disaster recovery for Azure VMs to a secondary Azure region

Active Directory Password Policies: facciamo un po’ di chiarezza

Facebooktwittergoogle_plusredditlinkedin

Sempre più spesso mi capita, quando sono in azienda o durante i corsi, di riscontrare perplessità o inesattezze sulla corretta applicazione delle password policies da parte degli amministratori di dominio. Per questo motivo oggi voglio scrivere un articolo che faccia chiarezza sulla corretta applicazione delle policy e sull’esatto ordine con cui questa avviene.

Quante password policies posso applicare ad un singolo dominio?

Rispondere a questa domanda è semplice: una ed una sola!

  • Solo le policy applicate a livello di DOMINIO vengono considerate valide e verranno distribuite agli utenti. Le policy applicate a livello di OU (Organizational Unit), inclusa la OU dei Domain Controllers, vengono ignorate.
  • Se a livello di dominio ci sono più policy (ad esempio la Default Domain Policy ed una policy creata da voi) verranno considerati tutti i settaggi delle due policy (viene cioè fatto un merge), ma in caso di conflitto avrà la precedenza il settaggio della policy con la precedenza più alta (cioè la policy che ha un numero inferiore al quello della Default Domain Policy – Link Order più basso).
  • La password policy viene gestita dal domain controller che ha il ruolo FSMO di PDC Emulator.

Quindi, ci può essere solo una password policy per ogni account database e un dominio di Active Directory è considerato un singolo account database, come succede con i computer standalone.

Figura 1: in caso di più policy, vince quella con il LInk Order più basso

Quando viene applicata la password policy?

La password policy è sempre applicata alla macchina e non all’utente. Quindi quando avviene un aggiornamento della policy, questa viene applicata in background ogni 90 minuti di default (Background Refresh of Group Policy), all’avvio del computer oppure utilizzando il comando GPupdate.

Quando gli utenti vengono impattati?

Se cambio la password policy e stabilisco che la lunghezza minima della password sia 8 invece che 6 caratteri, gli utenti non si accorgono della modifica fino a quando la password non scade o gli viene chiesto di cambiarla (perché un amministratore l’ha resettata).

Quindi la modifica non è così “impattante” come si penserebbe e non costringerebbe tutti gli utenti del dominio a cambiare la password lo stesso giorno, per essere compliant con la nuova lunghezza minima imposta.

Quando vengono distribuite le modifiche apportate ad una password policy?

Nel momento in cui modificate la password policy, i seguenti settaggi vengono distribuiti immediatamente:

  • Minimum password length
  • Password must meet complexity requirements
  • Reversible encryption

Mentre gli altri settaggi vengono distribuiti solo dopo un logon, logoff, reboot oppure un GPO refresh

  • Minimum password age
  • Maximum password age
  • Lockout duration
  • Lockout threshold
  • Observation window

Attenzione sempre a distinguere tra distribuzione della policy e applicazione dei nuovi settaggi, che avvengono in momenti distinti a seconda del settaggio stesso, come ho già sottolineato.

Cos’è la Fine-Grained Password Policy?

A partire da Windows Server 2008 (e solo se il livello funzionale del dominio è innalzato a Windows Server 2008) è possibile applicare una password policy direttamente agli utenti o ai gruppi di sicurezza globale (global security groups) di Active Directory. Questa funzionalità, chiamata Fine-Grained Password Policy, permette di definire configurazioni differenti per le password e le account lockout policy per differenti tipi di utenti all’interno del dominio.

Supponiate infatti che la password policy per gli amministratori di dominio o per gli utenti privilegiati richieda un numero minino di caratteri superiore a quelli di un utente limitato. Con la Fine-Grained Password Policy (FGPP) potete applicare la policy direttamente al gruppo di utenti interessato.

Non potete comunque applicare la policy alla singola Organizational Unit (OU). Potreste però creare uno Shadow Group, cioè un gruppo a cui vengono aggiunti tutti gli utenti di una determinata OU con uno script PowerShell automatico ed applicare la FGPP allo Shadow Group. Online trovate decine di esempi di script su come creare uno Shadow Group ed aggiungerci in maniera automatica gli utenti presenti nella OU.

Per creare una FGPP vi rimando alla lettura dell’articolo Step-by-Step: Enabling and Using Fine-Grained Password Policies in AD

Figura 2: Configurazione di una Fine-Grained Password Policy per il gruppo Domain Admins

All’atto pratico, la Fine-Grained Password Policy non modifica nessuna Group Policy, ma modifica un attributo dell’utente chiamato msDS-ResultantPSO. È importante applicare alla FGPP una precedenza, perché nel caso l’utente appartenga a gruppi diversi e a questi gruppi siano state applicate diverse FGPP, la precedenza diventa determinante perché vincerà la FGPP con il valore di precedenza più basso.

Figura 3: Verifica della corretta applicazione della FGPP ad un utente del gruppo a cui è stata applicata la policy

Conclusioni

Spero con questo articolo di aver dipanato alcuni dubbi in merito all’applicazione delle password policy, soprattutto per quanto riguarda le tempistiche di applicazione dopo che avete modificato alcuni parametri, e di avervi indicato il giusto modo per procedere ad una corretta configurazione delle stesse.

Buon lavoro!

Nic

Configurare l’accesso sicuro ad Azure AD utilizzando Privileged Identity Management

Facebooktwittergoogle_plusredditlinkedin

In qualsiasi realtà aziendale è necessario effettuare delle attività di amministrazione informatica che richiedono dei permessi amministrativi elevati ed è una buona pratica che gli utenti abbiano sempre i minori permessi amministrativi possibili, per assicurare un buon livello di sicurezza ed impedire che vengano effettuate delle operazioni senza consenso (volutamente o per sbaglio). È interessante anche limitare nel tempo eventuali permessi amministrativi, giusto il tempo necessario per effettuare l’operazione. Mi è capitato spesso di vedere account privilegiati assegnati ad un consulente esterno che poi non sono stati più rimossi e questo mette a forte rischio la sicurezza aziendale.

Ho avuto modo qualche tempo fa di mostrarvi una nuova funzionalità  introdotta in Windows Server 2016 che si basa sul principio dell’amministrazione Just In Time (JIT) nell’articolo Privileged Access Management e Temporary Group Membership in Windows Server 2016 AD e ho già affrontato il tema della Gestione dell’accesso alle macchine virtuali in Microsoft Azure con la funzionalità JIT (Just-in-Time)

In questo articolo voglio invece parlarvi di come rendere sicuro l’accesso ad Azure AD (e quindi a tutte le risorse che gestisce) utilizzando Privileged Identity Management, che permette di assegnare permessi amministrativi limitati nel tempo e che permette di monitorare e approvare questo tipo di accessi privilegiati.

Privileged Identity Management (PIM) richiede però che abbiate una sottoscrizione Azure AD Premium P2 oppure che abbiate Enterprise Mobility + Security E5. Per chi non conoscesse le differenze tra le diverse edizioni di Azure AD consiglio vivamente la lettura del documento Informazioni su Azure Active Directory, mentre per il pricing vi rimando al link Prezzi di Azure Active Directory

I vantaggi nell’uso di Azure AD Privileged Identity Management sono davvero notevoli e vi permettono di:

  • Vedere a quali utenti vengono assegnati i ruoli con privilegi per gestire le risorse di Azure
  • Abilitare l’accesso come amministratore JIT su richiesta ad Office 365 e alle risorse di Azure (sottoscrizioni, gruppi di risorse e alle singole risorse)
  • Visualizzare una cronologia dell’attivazione dell’amministratore, comprese le modifiche che gli amministratori hanno apportato alle risorse di Azure
  • Essere avvisati delle modifiche apportate nelle assegnazioni del ruolo di amministratore
  • Richiedere l’approvazione per attivare i ruoli di amministratore con privilegi di Azure AD
  • Esaminare l’appartenenza dei ruoli di amministratore e richiedere agli utenti di fornire una giustificazione per l’appartenenza continua ad un determinato ruolo

Abilitare Privileged Identity Management per la directory di Azure

Per cominciare è necessario che accediate al portale di gestione di Azure AD utilizzando i privilegi di un Global Administrator. Decidete di aggiungere una nuova risorsa e scegliete Azure AD Privileged Identity Management. Seguite le indicazioni presenti in console e fate clic su Create.

Figura 1: Aggiunta della risorsa Azure AD Privileged Identity Management

Come accennato prima, per poter aggiungere questa funzionalità è necessario abilitare un piano di Azure AD Premium 2. Potete attivare anche una trial della durata di 30 giorni per testare tutte le funzionalità offerte dal piano.

Figura 2: Attivazione della trial di Azure AD Premium P2

Per poter attivare Privileged Identity Management è necessario che venga verificata l’identità del Global Administrator che la sta attivando. Seguite il wizard ed utilizzate la multi-factor authentication per poter assicurare l’attivazione, come mostrato in figura:

Figura 3: Richiesta della verifica dell’identità prima dell’attivazione di Privileged Identity Management

Figura 4: Completamento della verifica dell’identità con l’utilizzo della multi-factor authentication

Dopo aver effettuato la verifica, confermate l’attivazione facendo clic sul punsante Consent, come mostrato in figura:

Figura 5: Consenso all’attivazione di PIM

La procedura non è ancora terminata e l’ultimo passaggio richiede che effettuiate il Sign Up di Privileged Identity Management ai ruoli di Azure AD directory.

Figura 6: Sign Up di PIM ai ruoli di Azure AD directory

Adesso che avete completato tutti gli step per l’attivazione della funzionalità di Privileged Identity Mangement, potrete visualizzare tutti i ruoli che sono stati assegnati nella vostra directory di Azure AD.


Figura 7: Ruoli assegnati nella directory di Azure AD

Gestione dei ruoli e degli accessi privilegiati

In questa guida utilizzerò il mio tenant di Office 365 e la relativa Azure Directory. Nel tenant è presente un utente, che si chiama Murphy Law, che attualmente è un Exchange Administrator.

Figura 8: Utente con un ruolo permanente di Exchange Administrator

La verifica del ruolo può essere fatta anche dal portale di Azure AD.

Figura 9: Verifica del ruolo dal portale di Azure AD

Sicuramente molti di voi conosceranno la Legge di Murphy e penseranno che probabilmente non sia il caso di affidare la gestione di Exchange Online ad un utente con un nome simile, soprattutto di non farlo in maniera permanente. Io tra l’altro sono molto d’accordo con la Chiosa di O’Toole alla legge di Murphy: Murphy era un ottimista. Per questo motivo ho deciso di convertire il ruolo di Exchange Administrator all’utente Murphy Law da Permanente ad Eleggibile. Murphy potrà richiedere di diventare Exchange Administrator quando ne avrà bisogno, ma per il resto del tempo rimarrà un utente limitato.

Figura 10: Modifica del ruolo di Exchange Administrator da Permament ad Eligible

Figura 11: Verifica della conversione del ruolo

Dal portale amministrativo di Office 365 adesso risulterà che Murphy Law è un semplice utente, senza alcun ruolo amministrativo.

Figura 12: Murphy è diventato un utente senza privilegi amministrativi

Richiesta di appartenenza temporanea ad un ruolo amministrativo

Quando l’utente dovrà effettuare delle operazioni su Exchange Online e avrà bisogno dei privilegi corretti, potrà connettersi al portare di Azure AAD con le proprie credenziali e dal nodo di Privileged Identity Management potrà fare richiesta di attivazione di uno dei ruoli che sono per lui eleggibili, come mostrato in figura:

Figura 13: Richiesta di attivazione di uno dei ruoli per cui l’utente è eleggibile

Figura 14: Richiesta di conferma dell’identità tramite multi-factor authentication

Il ruolo potrà essere attivato per un certo numero di ore, che sono determinate dal “template” del ruolo e che posso essere modificate, e può essere attivato a partire da una certa data e ora invece che immediatamente.

Figura 15: Attivazione temporanea del ruolo con attivazione personalizzata del tempo di inizio

Nel portale amministrativo è possibile verificare l’attivazione del ruolo, la durata e la scadenza dello stesso.

Figura 16: Verifica dell’attivazione del ruolo dal portale di Azure AAD

Da questo momento in poi e per la durata di un’ora l’utente farà parte degli Exchange Administrator.

Gestione del processo di attivazione del ruolo

Come abbiamo visto, l’utente si è auto-attivato il ruolo. È però possibile fare in modo che, prima dell’attivazione, sia necessaria l’approvazione da parte di un utente ancora più privilegiato. Per poter usare l’approvazione è necessario modificare il comportamento del ruolo. Loggatevi in Azure AAD e selezionate Azure AD Privileged Identity Management. Dal nodo Azure Active Directory Roles scegliete Roles e poi selezionate il ruolo che volete modificare. Potete modificarne la durata, potete richiedere che venga mandata una mail agli amministratori ogni volta che il ruolo viene attivato ma soprattutto potete attivare l’approvazione, come mostrato in figura:

Figura 17: Modifica del ruolo di Exchange Administrator ed attivazione dell’approvazione

Terminata la procedura, ogni volta che verrà effettuata una richiesta per avere il ruolo di Exchange Administrator, l’Approver riceverà una mail con la richiesta e potrà decidere se concedere o rifiutare la richiesta.

Figura 18: Mail di richiesta per l’approvazione del ruolo

Figura 19: Approvazione o rifiuto della richiesta dal portare di Azure AD

Conclusioni

Azure AD Privileged Identity Management (PIM) è disponibile con il piano AAD Premium P2 e permette alle aziende di poter controllare meglio quando gli utenti utilizzano gli account privilegiati. Poter limitare nel tempo i privilegi ed utilizzare la Just in Time Administration è sicuramente vantaggioso in termini di sicurezza e permette di poter gestire nel cloud lo stesso principio del Least Administrative Privilege che “dovremmo” avere in azienda. Per approfondimenti sul tema vi rimando alla lettura dell’articolo Iniziare ad usare Azure AD Privileged Identity Management

Buon lavoro!

Nic

Impossibile connettersi via RDP a macchine on-premises o alle Azure Virtual Machine: Errore CredSSP Encryption Oracle Remediation

Facebooktwittergoogle_plusredditlinkedin

A partire dall’ 8 Maggio 2018, a seguito del rilascio da parte di Microsoft degli aggiornamenti mensili ed in particolar modo della KB4103727, diversi utenti stanno ricevendo una serie di errori nei collegamenti RDP dovuti alla CredSSP Encryption Oracle Remediation.

Le connessioni Desktop remoto (RDP) sono infatti soggette ad una vulnerabilità di “Remote Code Execution” che è stata descritta nella CVE-2018-0886. Già dal 18 Marzo 2018 Microsoft aveva rilasciato una patch per poter gestire questa vulnerabilità e aveva introdotto una Group Policy per mitigarne i rischi. Se volete conoscere l’evoluzione degli aggiornamenti per questa vulnerabilità potete leggere l’articolo CredSSP updates for CVE-2018-0886

Con le patch contenute nel Cumulative Update di Maggio 2018, la Group Policy è stata modificata ed il valore è passato da Vulnerable Mitigated. Il parametro lo trovate in Computer Configuration -> Administrative Templates -> System -> Credentials Delegation

Questa modifica al parametro della Group Policy obbliga la connessione RDP ad essere instaurata solo se dall’altra parte risponde una macchina che abbia ricevuto l’aggiornamento della KB4103727

Per maggiori informazioni sui diversi valori che il parametro può avere potete fare riferimento all’articolo https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018

Figura 1: Policy utilizzata per la gestione della vulnerabilità di CredSSP Encryption

Per verificare che abbiate installato la KB “incriminata” (KB4103727) potete lanciare un prompt di PowerShell con privilegi elevati ed eseguire il comando Get-Hotfix

Figura 2: Aggiornamenti installati sul sistema operativo client

Problema

Sul mio client Windows 10 ho installato la KB4103727 e quando ho tentato di connettermi ad una macchina dove la patch non era installata ho ricevuto il seguente messaggio di errore:

Figura 3: Impossibile collegarvi via RDP su una macchina non aggiornata

Anche controllando il Registro Eventi l’errore appare chiaro:

Figura 4: Errore nel Registro Eventi relativo al fallimento della negoziazione sicura della connessione

Il comportamento delle macchine può essere riassunto in questo modo:

  • se sia il client che la VM o il PC hanno la patch, la connessione avverrà in maniera sicura
  • se il client ha la patch ma la VM o il PC non ce l’hanno, apparirà un messaggio di errore e non sarà possibile connettersi
  • se il client non ha la patch ma la VM o il PC ce l’hanno, sarà possibile collegarsi via RDP ma la connessione non sarà sicura

Soluzione

Per ovviare al problema è possibile modificare la Policy che vi ho indicato prima (mettendo il valore su Vulnerable) o disinstallare la KB4103727 oppure modificare il registro utilizzando il comando

REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\ /v AllowEncryptionOracle /t REG_DWORD /d 2

Io sconsiglio queste soluzioni. La cosa migliore da fare è aggiornare tutte le VM ed i PC installando gli aggiornamenti di sicurezza consigliati. Per aggiornare un PC o una VM potete utilizzare Windows Update oppure un server WSUS.

Figura 5: Aggiornamenti di Maggio 2018 su Windows Server 2016

Figura 6: Aggiornamenti di Maggio 2018 su Windows 10

Connessione ad una VM in Microsoft Azure e installazione della patch mancante

Se tentate di connettervi ad una VM in Azure in cui non avete installato la patch KB4103727, allora ricevete l’errore descritto prima e sarà necessario aggiornarla o mitigare la vulnerabilità.

Nel mio caso però la VM non è in dominio e non ho la possibilità di accedervi in console. Per installare la patch mi sono servito della funzionalità di Azure Update Management, una soluzione che vi permette di eseguire gli aggiornamenti per le macchine Windows e per le macchine Linux direttamente dal portale di Azure e tramite un Automation Account.

Figura 7: Abilitazione della soluzione Azure Update Management

Il principio di funzionamento di Azure Update Management è molto semplice e può essere riassunto dal seguente diagramma:

Figura 8: Principio di funzionamento di Azure Update Management

Tipi di client supportati:

La tabella seguente elenca i sistemi operativi supportati:

Sistema operativo Note
Windows Server 2008, Windows Server 2008 R2 RTM Supporta solo le valutazioni degli aggiornamenti
Windows Server 2008 R2 SP1 e versioni successive Sono richiesti .NET Framework 4.5 e WMF 5.0 o versioni successive per Windows Server 2008 R2 SP1
CentOS 6 (x86/x64) e 7 (x64) Gli agenti Linux devono avere accesso a un repository degli aggiornamenti.
Red Hat Enterprise 6 (x86/x64) e 7 (x64) Gli agenti Linux devono avere accesso a un repository degli aggiornamenti.
SUSE Linux Enterprise Server 11 (x86/x64) e 12 (x64) Gli agenti Linux devono avere accesso a un repository degli aggiornamenti.
Ubuntu 12.04 LTS e versioni x86/x64 più recenti Gli agenti Linux devono avere accesso a un repository degli aggiornamenti.

Dopo pochissimi minuti dall’abilitazione della soluzione, la macchina verrà testata e verranno mostrati gli aggiornamenti mancanti. Come è possibile vedere dalla figura, manca il Security Update KB4103723

Figura 9: Aggiornamenti mancanti sulla VM

Fate clic sul pulsante Schedule update deployment che vi appare nel blade del portale di Azure e programmate quando volete effettuare l’aggiornamento. L’aggiornamento non è programmabile prima di 30 minuti e potete scegliere di eliminare alcune patch dall’installazione.

Figura 10: Programmazione dell’aggiornamento della VM

Una volta che avete schedulato l’aggiornamento non vi resta che attendere. La programmazione sarà visibile cliccando su Scheduled update deployment, come mostrato in figura:

Figura 11: Aggiornamenti programmati

Conclusioni

Avere le macchine sempre aggiornate e lavorare con sistemi operativi sicuri è un prerequisito importante per non essere soggetti alle vulnerabilità dei software e dei sistemi operativi e non perdere i propri dati. Prima di aggiornare però assicuratevi di fare dei test sulla vostra infrastruttura e verificate che tutto continui a funzionare prima di distribuire in maniera massiva gli aggiornamenti.

Buon lavoro!

Nic

Vinci un corso di Cybersecurity

Facebooktwittergoogle_plusredditlinkedin

Cisco organizza una lotteria per regalare 2 voucher del corso “Understanding Cisco Cybersecurity Fundamentals (SECFND) v1.0″ in modalità self-paced del valore di 1.500$ ognuno. Questo corso fa parte del percorso per la certificazione CCNA CyberSecurity Operations, composta da: Understanding Cisco Cybersecurity Fundamentals (SECFND) v1.0 Implementing Cisco Cybersecurity Operations (SECOPS) v1.0   I vincitori della lotteria […]

L’articolo Vinci un corso di Cybersecurity proviene da KISS Keep IT Simple Stupid.