Archivi categoria: Microsoft Azure

Azure IaaS and Azure Stack: announcements and updates (January 2019 – Weeks: 01 and 02)

This series of blog posts includes the most important announcements and major updates regarding Azure infrastructure as a service (IaaS) and Azure Stack, officialized by Microsoft in the last two weeks.

Azure

Azure Migrate is available in Azure Government and Azure Asia

Azure Migrate now supports Azure Government and Azure Asia as a migration project location. This means that you can store your discovered metadata in an Azure Government region (US Gov Virginia) and in Asia region (Southeast Asia).

Note that the project geography does not restrict you from planning your migration for a different target location. Azure Migrate supports more than 30 regions as assessment target locations. The project geography is only used to store the discovered VM metadata.

General availability of Azure Data Box Disk

Azure Data Box Disk, an SSD-based solution for offline data transfer to Azure is now available in the US, EU, Canada, and Australia, with more country/regions to be added over time. Microsoft also is launching the public preview of Azure Data Box Blob Storage. When enabled, this feature will allow you to copy data to Blob Storage on Data Box using blob service REST APIs.

Azure Networking: panoramica dei servizi di protezione

Nell’era moderna del cloud computing, la tendenza è di spostare sempre più frequentemente i propri workload nel cloud pubblico e di utilizzare cloud ibridi. La sicurezza è spesso percepita come un elemento inibitore per l’utilizzo di ambienti cloud. Si può estendere il proprio datacenter nel cloud mantenendo un elevato livello di sicurezza della rete? Come garantire un accesso sicuro ai servizi presenti nel cloud e con quali strumenti? Una delle principali ragioni per utilizzare Azure, per le proprie applicazioni e i propri servizi, è proprio la possibilità di poter usufruire di un ampio set di funzionalità e di strumenti di sicurezza integrati nella platform. In questo articolo verrà fatta una panoramica dei servizi di protezione in ambito network nel mondo Azure, riportando le linee guida e gli accorgimenti utili per utilizzare al meglio le potenzialità presenti nella piattaforma, al fine di strutturare il network in Azure rispettando tutti i principi di sicurezza.

In ambito Azure Networking sono disponibili diversi servizi che consentono di abilitare la connettività verso ambienti distinti, secondo modalità differenti, di attivare la protezione della rete e di configurare il delivery delle applicazioni. Tutti questi servizi si integrano con i sistemi di monitor offerti dalla piattaforma Azure, andando a creare un ecosistema completo per l’erogazione dei servizi di rete.

Figura 1 – Azure Networking Services

Per poter configurare la protezione della rete in Azure troviamo i seguenti servizi, disponibili in modo nativo nella platform.

Network Security Group (NSG)

I Network Security Groups (NSGs) sono lo strumento principale per controllare il traffico di rete in Azure. Tramite delle regole di deny e permit è possibile filtrare le comunicazioni tra differenti workload attestati su una virtual network di Azure. Inoltre, è possibile applicare filtri sulle comunicazioni con sistemi che risiedono nell’ambiente on-premises, connesso alla VNet Azure, oppure per le comunicazioni da e verso Internet. I Network Security Groups (NSGs) possono essere applicati su una determinata subnet di una VNet Azure oppure direttamente sulle singole schede di rete delle macchine virtuali Azure. Il consiglio è di applicarli se possibile direttamente sulle subnet, per avere un controllo globale e più flessibile delle ACLs. I NSGs possono contenere regole con dei Service Tags, che consentono di raggruppare con dei nomi predefiniti delle categorie di indirizzi IP, incluse quelle assegnate a determinati servizi Azure (es. AzureMonitor, AppService, Storage, etc.).

Nelle regole dei Network Security Groups possono essere referenziati anche gli Application Security Groups (ASGs). Si tratta di gruppi che contengono schede di rete di macchine virtuali presenti su Azure. Gli ASGs consentono di raggruppare con nomi mnemonici più server, utili in particolare per workload dinamici. Gli Application Security Groups consentono inoltre di non dover più gestire nelle regole degli NSGs gli indirizzi IP delle macchine virtuali Azure, purché questi IP siano relativi a VMs attestate sulla stessa VNet.

Figura 2 – Esempio di regola di un NSG che contiene un Service Tag e un ASG

Figura 3 – Visualizzazione grafica della segregazione del traffico di rete tramite NSG

Service Endpoints

Tramite i Virtual Network (VNet) service endpoints è possibile aumentare il livello di sicurezza degli Azure Services, prevenendo accessi non autorizzati.  I vNet Service Endpoints consentono di isolare maggiormente i servizi Azure, permettendo l’accesso ad essi solamente da una o più subnet definite nelle proprie Virtual Network. Questa funzionalità garantisce inoltre che tutto il traffico generato dalle proprie vNet verso i servizi Azure rimanga sempre all’interno della rete di backbone di Azure. Per ottenere i servizi supportati ed avere maggiori dettagli a riguardo è possibile consultare la documentazione Microsoft.

Figura 4 – Schema di sintesi dei Sevice Endpoints

Azure Firewall

L’Azure Firewall è un firewall, totalmente integrato nel cloud pubblico di Microsoft, di tipologia stateful, grazie al quale è possibile controllare in modo centralizzato, attraverso delle policy, i flussi di comunicazione di rete, il tutto in modo cross subscription e per differenti virtual network. Azure Firewall consente anche di filtrare il traffico tra le virtual network di Azure e le reti on-premises, interagendo sia con connettività che avvengono tramite Azure VPN Gateway che con Express Route Gateway. Per maggiori dettagli a riguardo è possibile consultare l’articolo Introduzione ad Azure Firewall.

Figura 5 – Posizionamento di Azure Firewall

 

Web Application Firewall

La pubblicazione applicativa può essere fatta utilizzando l’Azure Application Gateway, un servizio gestito dalla piattaforma Azure, con funzionalità intrinseche di alta disponibilità e scalabilità. L’Application Gateway è un load balancer applicativo (OSI layer 7) per il traffico web, che consente di governare il traffico HTTP e HTTPS delle applicazioni (URL path, host based, round robin, session affinity, redirection). L’Application Gateway è in grado di gestire in modo centralizzato i certificati per la pubblicazione applicativa, tramite policy SSL ed effettuando SSL offload quando necessario. L’Application Gateway può avere assegnato un indirizzo IP Privato oppure un indirizzo IP Pubblico, se la ripubblicazione applicativa deve avvenire verso Internet. In particolare, in quest’ultimo caso, è consigliato attivare la funzionalità di Web Application Firewall (WAF), che consente di ottenere una protezione applicativa, basandosi su regole OWASP core rule sets. Il WAF protegge l’applicativo da vulnerabilità e da attacchi comuni, come ad esempio attacchi X-Site Scripting e SQL Injection.

Figura 6 – Schema di overview dell’Application Gateway con WAF

DDoS protection

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

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.

Per maggiori dettagli a riguardo è possibile consultare l’articolo La protezione da attacchi DDoS in Azure.

Sinergie e raccomandazioni per l’utilizzo dei vari servizi di protezione

Al fine di ottenere una protezione di rete efficace ed indirizzarvi nell’utilizzo dei vari componenti si riportano le principali raccomandazioni che è consigliato tenere in considerazione:

  • I Network Security Groups (NSGs) e l’Azure Firewall sono tra di loro complementari e utilizzandoli in modo congiunto si ottiene un grado di difesa elevato. I NSGs è consigliato utilizzarli per filtrare il traffico tra le risorse che risiedono all’interno di una VNet, mentre l’Azure Firewall è utile per fornire una protezione di rete e applicativa tra differenti Virtual Network.
  • Per aumentare la sicurezza dei servizi Azure PaaS è consigliato utilizzare i Service endpoints, i quali possono essere utilizzati in concomitanza ad Azure Firewall per consolidare e centralizzare i log degli accessi. Per farlo è possibile abilitare i service endpoint dalla subnet dell’Azure Firewall, disabilitandoli dalle subnet presenti nelle VNet di Spoke.
  • Azure Firewall fornisce un livello di protezione di rete Layer 3 per tutte le porte ed i protocolli, inoltre garantisce un livello di protezione applicativa (Layer 7) per il traffico HTTP/S in uscita. Per questa ragione nel caso si voglia effettuare una pubblicazione applicativa protetta (HTTP/S in inbound) è opportuno utilizzare il Web Application Firewall presente nell’Application Gateway, affiancandolo quindi ad Azure Firewall.
  • Azure Firewall può essere affiancato anche da soluzioni WAF/DDoS di terze parti.

Tutti questi servizi di protezione, opportunamente configurati in una architettura di rete di tipologia Hub-Spoke consentono di effettuare una segregazione del traffico di rete, ottenendo un elevato livello di controllo e sicurezza.

Figura 7 – Servizi di sicurezza in una architettura Hub-Spoke

Conclusioni

Azure mette a disposizione una vasta gamma di servizi che consentono di ottenere elevati livelli di sicurezza, agendo su differenti fronti. Il modello di sicurezza che si decide adottare è possibile ridimensionarlo e adattarlo in modo flessibile, in base alla tipologia dei workload applicativi da proteggere. Una strategia vincente la si può ottenere applicando un mix-and-match dei differenti servizi di sicurezza di rete, per ottenere una protezione su più livelli.

La protezione da attacchi DDoS in Azure

Un attacco informatico di tipologia denial-of-service distribuito (attacco DDoS – Distributed Denial of Service) è rivolto 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 questo articolo saranno riportate le caratteristiche della protezione che è possibile avere in Azure per questa tipologia di attacchi, in modo da proteggere al meglio le applicazioni presenti sul cloud e garantire la loro disponibilità a fronte di attacchi DDoS.

Gli attacchi DDoS sono sempre più diffusi e sofisticati, al punto da poter raggiungere dimensioni, in termini di larghezza di banda, sempre più importanti, che ne rendono difficoltosa la protezione e aumentano le possibilità di apportare un downtime ai servizi pubblicati, con un impatto diretto sul business aziendale.

Figura 1 – DDoS Attack Trends

Spesso questa tipologia di attacchi viene inoltre utilizzata dagli hackers per distrarre le aziende e mascherare altre tipologie di attacchi informatici (cyber Smokescreen).

 

Caratteristiche della soluzione

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

Figura 2 – 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. Questa protezione non si applica agli App Service Environments.

Figura 3 – Panoramica dell’Azure DDoS Protection Standard

L’Azure DDoS Protection di tipologia Standard è in grado di far fronte ai seguenti attacchi:

  • Volumetric attacks: l’obiettivo di questi attacchi è di inondare la rete con una quantità considerevole di traffico apparentemente legittimo (UDP floods, amplification floods, e altri spoofed-packet floods).
  • Protocol attacks: questi attacchi puntano a rendere inaccessibile una specifica destinazione, sfruttando un punto debole che viene individuato nel layer 3 e nel layer 4 dello stack (ad esempio SYN flood attacks e reflection attacks).
  • Resource (application) layer attacks: questi attacchi hanno come obiettivo i pacchetti delle Web application, al fine di interrompere la trasmissione di dati tra i sistemi. Gli attacchi di questo tipo includono: violazioni del protocollo HTTP, SQL injection, cross-site scripting e altri attacchi di livello 7. Per proteggersi da attacchi di questa tipologia non è sufficiente la protezione DDoS standard, ma è necessario utilizzarla in concomitanza con il modulo Web Application Firewall (WAF) disponibile nell’Azure Application Gateway, oppure con soluzione web application firewall di terze parti, disponibili nel marketplace di Azure.

 

Abilitazione della protezione DDoS Standard

La protezione DDoS Standard viene attivata a livello di virtual network ed è contemplata per tutte le risorse che risiedono al suo interno. L’attivazione dell’Azure DDoS Protection Standard richiede di creare un DDoS Protection Plan che raccoglie le virtual network con la protezione DDoS Standard attiva, cross subscription.

Figura 4 – Creazione di un DDoS Protection Plan

Il protection Plan viene creato in una determinata subscription, alla quale saranno associati i costi della soluzione.

Figura 5 – Abilitazione della protezione DDoS Standard su una Virtual Network esistente

Il tier Standard fornisce una telemetria in tempo reale che è consultabile tramite viste in Azure Monitor.

Figura 6 – Metriche DDoS disponibili in Azure Monitor

Qualsiasi metrica relativa alla protezione DDoS può essere utilizzata per generare degli alert. Utilizzando la metrica “Under DDoS attack” si può essere avvisati nel momento in cui viene rilevato un attacco DDoS e viene applicata una azione di mitigation.

La protezione DDoS Standard applica tre auto-tuned mitigation policies (TCP SYN, TCP & UDP) per ogni IP Pubblico associato a una risorsa protetta, che risiede quindi su una virtual network con il servizio DDoS standard attivo.

Figura 7 – Metriche di mitigation disponibili in Azure Monitor

Per effettuare la generazione di report, riguardanti le azioni svolte per mitigare gli attacchi DDoS, è necessario configurare le impostazioni di diagnostica.

Figura 8 – Diagnostics Settings in Azure Monitor

Figura 9 – Abilitazione diagnostica su IP Pubblico per collezionare i log DDoSMitigationReports

Nelle impostazioni di diagnostica c’è la possibilità di collezionare anche altri log relativi alle attività di mitigation e alle notifiche. Per maggiori informazioni a riguardo è possibile consultare la sezione Configure DDoS attack analytics della documentazione Microsoft. Le metriche per la protezione DDoS Standard vengono mantenute in Azure Moniotr per 30 giorni.

Figura 10 – Attack flow logs in Azure Log Analytics

Come testare l’efficacia della soluzione

Microsoft ha instaurato una partnership con BreakingPoint Cloud che, grazie a una interfaccia molto intuitiva, consente di generare del traffico, verso gli IP Pubblici di Azure, per simulare un attacco DDoS. In questo modo è possibile:

  • Validare l’effettiva efficacia della soluzione.
  • Simulare ed ottimizzare le risposte a fronte di incident relativi ad attacchi DDoS.
  • Documentare il livello di compliance per attacchi di questa tipologia.
  • Formare il network security team.

Costi della soluzione

Il tier Basic non prevede nessun costo, mentre l’abilitazione della protezione DDoS Standard prevede un prezzo mensile fisso (non trascurabile) e un addebito per i dati che vengono elaborati. Il prezzo mensile fisso include la protezione per 100 risorse, superate le quali è previsto un costo unitario aggiuntivo per ogni risorsa protetta. Per maggiori dettagli sui costi di Azure DDoS Protection Standard è possibile consultare la pagina ufficiale Microsoft.

Conclusioni

La protezione da attacchi DDoS in Azure ci consente di avere sempre attiva una protezione di base per far fronte ad attacchi di questo tipo. A seconda della criticità applicative si può valutare l’abilitazione della protezione Standard, che in concomitanza con una soluzione di web application firewall, consente di avere funzionalità complete per mitigare attacchi distribuiti di denial-of-service.

Azure IaaS and Azure Stack: announcements and updates (December 2018 – Weeks: 50 and 51)

This series of blog posts includes the most important announcements and major updates regarding Azure infrastructure as a service (IaaS) and Azure Stack, officialized by Microsoft in the last two weeks.

Azure

Update rollup for Azure File Sync Agent: December 2018

An update rollup for the Azure File Sync agent was released this month which addresses the following issues:

  • A Stop error 0x3B or Stop error 0x1E may occur when a VSS snapshot is created.
  • A memory leak may occur when cloud tiering is enabled

More information about this update rollup:

  • This update is available for Windows Server 2012 R2, Windows Server 2016, and Windows Server 2019 installations that have Azure File Sync agent version 3.1.0.0 or a later version installed.
  • The agent version of this update rollup is 4.2.0.0.
  • A restart may be required if files are in use during the update rollup installation.
  • Installation instructions are documented in KB4459990.

Automate Always On availability group deployments with SQL Virtual Machine resource provider

A new automated way to configure high availability solutions for SQL Server on Azure Virtual Machines (VMs) is now available using SQL VM resource provider.

Virtual Network Service Endpoints for serverless messaging and big data

Azure Event Hubs, a highly reliable and easily scalable data streaming service, and Azure Service Bus, which provides enterprise messaging, are the new set of serverless offerings joining the growing list of Azure services that have enabled Virtual Network Service Endpoints.

Azure Stack

Azure Stack 1811 update

The 1811 update package includes fixes, improvements, and new features for Azure Stack. This update package is only for Azure Stack integrated systems. Do not apply this update package to the Azure Stack Development Kit.

Azure Monitor: introduzione al servizio di monitor delle macchine virtuali

In Azure Monitor è stato introdotto un nuovo servizio che consente di effettuare il monitor delle macchine virtuali, chiamato Azure Monitor for VMs. Questo servizio analizza i dati di performance e lo stato delle macchine virtuali, effettua il monitor dei processi installati e ne esamina le relative dipendenze. In questo articolo sono riportate le caratteristiche della soluzione ed descritta la procedura da seguire per effettuarne l’attivazione.

Caratteristiche della soluzione

Il servizio Azure Monitor for VMs è suddiviso secondo tre differenti prospettive:

  • Health: i componenti logici presenti a bordo delle macchine virtuali vengono valutati secondo specifici criteri pre-configurati, generando alert quando si verificano determinate condizioni. Tale funzionalità, al momento, è presente solo per sistemi che risiedono in Azure.
  • Performance: vengono riportati i dati principali di performance, provenienti dal sistema operativo guest.
  • Map: viene generata una mappa con le interconnessioni presenti tra vari componenti che risiedono su sistemi differenti.

Tale soluzione può essere utilizzata su macchine virtuali Windows e Linux, indipendentemente dall’ambiente in cui esse risiedono (Azure, on-premises oppure presso altri cloud provider).

Azure Monitor for VMs richiede la presenza di un workspace di Log Analytics. Trattandosi di una funzionalità al momento in preview, sono supportati i workspace presenti in queste regions: West Central US, East US, West Europe e Southeast Asia. L’abilitazione di un workspace di Log Analytics può avvenire secondo queste modalità:

Per individuare i sistemi operativi supportati da questa soluzione è possibile consultare la relativa documentazione ufficiale Microsoft.

 

Come abilitare Azure Monitor for VMs

Per abilitare la soluzione per una singola macchina virtuale, dal portale Azure, è possibile procedere accedendo alla sezione Insights della macchina virtuale:

Figura 1 – Abilitazione di Azure Monitor for VMs su una singola VM

Abilitando la soluzione su una singola macchina virtuale è possibile scegliere quale workspace Log Analytics utilizzare ed eventualmente crearne uno nuovo. Il consiglio è di precedere a priori con la creazione del workspace, in modo da potergli assegnare un nome significativo in fase di creazione. Il workspace di Log Analytics deve essere configurato come segue:

  • Deve aver installato le solution ServiceMap e InfrastructureInsights. L’installazione di queste solution può essere fatta tramite dei template JSON, secondo le modalità riportate in questo documento.

Figura 2 – Presenza delle solution ServiceMap e InfrastructureInsights

Figura 3 – Raccolta dei performance counters abilitata sul workspace di Log Analytics

Azure Monitor for VMs richiede la presenza dell’agent di Log Analytics sulle macchine virtuali, inoltre la funzionalità di Map richiede l’installazione del Microsoft Dependency agent. Si tratta di un agente aggiuntivo il quale si affida all’agente di Log Analytics per la connessione al workspace.

Nel caso si voglia abilitare la soluzione per sistemi presenti in Azure è possibile attivare il Dependency agent utilizzando l’apposita extension, che ne effettua l’installazione. Per le macchine virtuali che non risiedono su Azure è necessario effettuarne l’installazione manualmente oppure tramite una soluzione che consente di automatizzare il deployment (ad esempio System Center Configuration Manager).

Per abilitare questa funzionalità in modo automatico sulle nuove macchine virtuali create in ambiente Azure ed ottenere un livello elevato di compliance si possono anche utilizzare le Azure Policy. Tramite le Azure Policy è possibile:

  • Effettuare il deployment dell’agente di Log Analytics e del Dependency agent.
  • Avere un report sullo stato di compliance
  • Avviare delle azioni di remediation per le VMs non compliant.

Figura 4 – Aggiunta di un Assignment

Figura 5 – Initiative definition di esempio per abilitare Azure Monitor for VMs

Figura 6 – Consultazione dello stato di compliance della Policy

 

Consultazione dei dati raccolti dalla soluzione

Per analizzare e identificare eventi critici del sistema operativo, rilevare prestazioni non ottimali e problematiche di rete, è possibile consultare i dati forniti dalla solution direttamente dalla singola VM oppure utilizzando Azure Monitor, nel caso si voglia avere una vista aggregata delle varie macchine virtuali. Il tutto consente di rilevare e identificare se determinati problemi sono relativi a specifiche dipendenze con altri servizi.

Figura 7 – Stato di Health di una singola macchina virtuale

Figura 8 – Performance raccolte da più VMs, consultabili da Azure Monitor

Figura 9 – Mappa delle dipendenze dei vari servizi presenti sulle VMs, consultabili da Azure Monitor

Per maggiori informazioni sull’utilizzo della funzionalità di Health è possibile consultare questa documentazione Microsoft, mentre l’articolo View Azure Monitor for VMs Map mostra come individuare e analizzare le dipendenze rilevate dalla soluzione.

Costi della soluzione

Attivando la solution Azure Monitor for VMs, i dati collezionati dalle macchine virtuali vengono inviati e mantenuti in Azure Monitor e possono dipendere da diversi fattori, come ad esempio il numero dei logical disks e delle schede di rete. I costi sono quelli relativi ad Azure Monitor, il quale prevede delle spese sulla base dei seguenti elementi:

  • Dati inseriti e collezionati.
  • Numero di criteri di health monitorati.
  • Alert rule create.
  • Notifiche inviate.

 

Conclusioni

Il servizio Azure Monitor for VMs consente di avere uno strumento totalmente integrato in Azure per monitorare le macchine virtuali ed ottenere un controllo completo dei sistemi, indipendentemente da dove risiedono. Questa soluzione risulta anche particolarmente utile per condurre operazioni di troubleshooting in modo semplice ed immediato. Tale servizio, nonostante sia attualmente in preview, è comunque già sufficientemente completa ed è sicuramente destinata ad arricchirsi presto con nuove funzionalità.

Azure IaaS and Azure Stack: announcements and updates (December 2018 – Weeks: 48 and 49)

This series of blog posts includes the most important announcements and major updates regarding Azure infrastructure as a service (IaaS) and Azure Stack, officialized by Microsoft in the last two weeks.

Azure

Azure Dedicated Hardware Security Module (HSM)

The Microsoft Azure Dedicated Hardware Security Module (HSM) service provides cryptographic key storage in Azure and meets the most stringent customer security and compliance requirements. This service is the ideal solution for customers requiring FIPS 140-2 Level 3 validated devices with complete and exclusive control of the HSM appliance. Azure Dedicated HSM addresses a unique set of customer needs for secure key storage scenarios in Azure.

The Dedicated HSM service is available in eight Azure regions, namely East US, West US, South Central US, East US 2, Southeast Asia, East Asia, West Europe, and North Europe

Improving Azure Virtual Machine resiliency with predictive ML and live migration

Since early 2018, Azure has been using live migration in response to a variety of failure scenarios such as hardware faults, as well as regular fleet operations like rack maintenance and software/BIOS updates. The use of live migration to handle failures gracefully allowed us to reduce the impact of failures on availability by 50 percent. Using the deep fleet telemetry, Microsoft enabled machine learning (ML)-based failure predictions and tied them to automatic live migration for several hardware failure cases, including disk failures, IO latency, and CPU frequency anomalies. Azure team partnered with Microsoft Research (MSR) on building the ML models that predict failures with a high degree of accuracy before they occur. As a result, Microsoft is able to live migrate workloads off “at-risk” machines before they ever show any signs of failing. This means VMs running on Azure can be more reliable than the underlying hardware.

Update rollup for Azure File Sync Agent: December 2018

An update rollup for the Azure File Sync agent was released which addresses the following issues:

  • A Stop error 0x3B or Stop error 0x1E may occur when a VSS snapshot is created.
  • The server may become unresponsive because of a cloud-tiering memory leak.
  • Agent installation fails with the following error: Error 1921. Service ‘Storage Sync Agent’ (FileSyncSvc) could not be stopped. Verify that you have sufficient privileges to stop system services.
  • The Storage Sync Agent (FileSyncSvc) service may crash when memory usage is high.
  • Miscellaneous reliability improvements for cloud tiering and sync.

More information about this update rollup:

  • This update is available for Windows Server 2012 R2, Windows Server 2016, and Windows Server 2019 installations that have Azure File Sync agent version 3.1.0.0 or a later version installed.
  • The agent version of this update rollup is 4.1.0.0.
  • A restart may be required if files are in use during the update rollup installation.

Installation instructions are documented in KB4459988.

Virtual network service endpoints for Azure Database for MariaDB (preview)

Virtual network service endpoints for Azure Database for MariaDB are accessible in preview in all available regions. Virtual network service endpoints allow you to isolate connectivity to your logical server from only a given subnet or set of subnets within your virtual network. Traffic to Azure Database for MariaDB from the virtual network service endpoints stays within the Azure network, preferring this direct route over any specific routes that take internet traffic through virtual appliances or on-premises.

Come ridurre i costi del cloud con Microsoft Azure

L’evoluzione del data center ci porta ad avere soluzioni completamente nel cloud pubblico oppure scenari ibridi dove, la scelta di utilizzare risorse nel cloud, oltre che da fattori funzionali, deve necessariamente essere fatta tenendo in considerazione l’aspetto fondamentale dei costi. In questo articolo vengono riportate delle indicazioni che è possibile seguire per ottenere un risparmio sui costi, dati dal mantenere i propri workload applicativi in Azure.

Azure Reservations

Il costo dei vari servizi Azure è calcolato sulla base dell’utilizzo delle risorse ed è possibile effettuare una stima dei costi utilizzando lo strumento Azure pricing calculator.

Se, delle risorse in ambiente Azure, ne viene fatto un uso continuativo è possibile valutare l’attivazione delle Azure Reservations.

Le Azure Reservation consentono di ottenere una riduzione dei costi fino al 72% rispetto al prezzo pay-as-you-go, semplicemente prepagando anticipatamente per uno oppure tre anni l’utilizzo delle risorse Azure. Al momento le risorse Azure che consentono di ottenere questi sconti sono: macchine virtuali, Azure SQL Database, Azure Cosmos DB e SUSE Linux. L’acquisto di queste reservation può essere fatto direttamente dal portale Azure ed è fattibile per i clienti che dispongono delle seguenti tipologie di subscription:

  • Enterprise agreement: in questo ambito non sono contemplate le risorse che risiedono in subscription Dev/Test. Risulta possibile attingere all’Azure Monetary Commitment per l’acquisto delle Azure Reservation.
  • Pay-As-You-Go.
  • Cloud Solution Provider (CSP): in questo caso l’acquisto è fattibile anche dal Partner Center.

Tra le Azure reservation troviamo:

  • Reserved Virtual Machine Instance: la reservation contempla solamente i costi computazionali della macchina virtuale, e non copre i costi aggiuntivi dati dal software installato a bordo della VM, dal networking, oppure dall’utilizzo dello storage.
  • SQL Database reserved vCore: anche in questo caso sono compresi solamente i costi computazionali, mentre le licenze vengono fatturate in modo separato.
  • Azure Cosmos DB reserved capacity: la reservation copre il throughput effettivo della risorsa, ma non contempla i costi previsti per lo storage e per il networking.
  • SUSE Linux: consente di risparmiare sui costi di licenza di SUSE Linux Enterprise.

Procedura per acquistare le Azure Reservations dal portale Azure

Per acquistare delle Reservations dal portale Azure è possibile seguire la procedura in seguito riportata.

Figura 1 – Aggiunta Azure Reservation dal portale e selezione della tipologia

Figura 2 – Configurazione dei parametri richiesti per le Reserved Virtual Machine Instances

Figura 3 – Riepilogo delle Azure Reservations acquistate

Per maggiori approfondimenti in merito a come le Reservation influiscono sul calcolo dei costi Azure, è possibile consultare i seguenti documenti Microsoft:

Hybrid Benefit

Un’altra possibilità da tenere in considerazione per la riduzione dei costi Azure è l’utilizzo dell’Azure Hybrid Benefit, che consente di risparmiare fino al 40% sul costo delle macchine virtuali Windows Server che vengono implementate su Azure. Il risparmio è dato dal fatto che Microsoft consente di pagare solamente i costi di infrastruttura Azure, mentre il licensing per Windows Server viene coperto dal contratto di Software Assurance. Questo benefit è applicabile sia alla versione Standard che Datacenter ed è usufruibile per Windows Server 200 R2 o successivi.

Figura 4 – Struttura dei costi per una VM Windows

L’Azure Hybrid Benefit può essere utilizzato in concomitanza con le Azure Reserved VM Instance, consentendo di avere risparmi complessivi che possono raggiungere l’80% (nel caso di acquisto di Azure Reserved Instance per 3 anni).

Figura 5 – Percentuali di possibili risparmi adottando RIs ed Azure Hybrid Benefit

Nel caso non ci si trovi nelle condizioni per usufruire dell’Azure Hybrid Benefit, il costo della licenza di Windows Server viene calcolato in base all’utilizzo orario della macchina virtuale e secondo il numero di core configurati.

L’Azure Hybrid Benefit può essere utilizzato anche per Azure SQL Database e per i SQL Server installati su macchine virtuali Azure. Questi vantaggi facilitano la migrazione verso soluzioni nel cloud e aiutano a massimizzare gli investimenti già effettuati in termini di licenze SQL Server. Per maggiori informazioni su come è possibile utilizzare l’Azure Hybrid Benefit per SQL Server è possibile consultare le FAQ di questo documento.

I risparmi sui costi, garantiti dall’utilizzo dell’Azure Hybrid Benefits, sono stimabili utilizzando lo strumento Azure Hybrid Benefit Savings Calculator.

Recentemente Microsoft ha effettuato degli studi sui costi da sostenere per attivare Windows Server e SQL Server in ambiente cloud che evidenziano come, grazie all’utilizzo delle Azure Reservations e di Azure Hybrid Benefit, AWS risulti fino a 5 volte più costoso rispetto ad Azure. La comparativa tra i costi Azure e quelli di AWS è possibile valutarla facilmente adottando lo strumento Azure vs. AWS Cost Comparison.

Conclusioni

Azure risulta sicuramente la scelta più economicamente vantaggiosa per ospitare in particolare i workload Microsoft, potendo avere dei costi ridotti dati dai vantaggi forniti dalle Azure Reservation e dall’Azure Hybrid Benefit. Inoltre, grazie allo strumento Azure cost management, messo a disposizione in modo gratuito a tutti i clienti Azure, si ha la possibilità di monitorare ed ottimizzare le spese dei vari servizi Azure.

Azure IaaS and Azure Stack: announcements and updates (November 2018 – Weeks: 46 and 47)

This series of blog posts includes the most important announcements and major updates regarding Azure infrastructure as a service (IaaS) and Azure Stack, officialized by Microsoft in the last two weeks.

Azure

Azure Network Watcher enabled by default for subscriptions that contain virtual networks

Azure Network Watcher provides tools to monitor, diagnose, view metrics, and enable or disable logs for resources in an Azure virtual network.

Network Watcher is now enabled by default for subscriptions that contain a virtual network. There is no impact to your resources or associated charge for automatically enabling Network Watcher. This will simplify and improve your network troubleshooting experience.

To learn more about Network Watcher features, or for information about how to opt out, see the product documentation. You can also get information about pricing.

 

Azure Availability Zones in Southeast Asia

Azure Availability Zones, a high-availability solution for mission-critical applications, is now generally available in Southeast Asia.

Availability Zones are physically separate locations within an Azure region. Each Availability Zone consists of one or more datacenters equipped with independent power, cooling, and networking. With the introduction of Availability Zones, we now offer a service-level agreement (SLA) of 99.99% for uptime of virtual machines.

Availability Zones are generally available in select regions.

 

Microsoft Azure is now certified to host sensitive health data in France

Microsoft Azure, Microsoft Office 365, and Microsoft Dynamics have been granted a Health Data Hosting (HDS) certification. This makes Microsoft the first major cloud provider capable of meeting the strict standards of storing and processing health data for data centers located in France, and under the new certification process that began in June 2018. This validates the very high level of safety and protection that Microsoft can offer to French healthcare entities, who will be able to rely on the Microsoft cloud to deploy the applications and health services of tomorrow. These applications and health services will also be in compliance with the current regulations on data protection and privacy.

 

Announced the Azure File Sync v4 release

Improvements and issues that are fixed:

  • Adds support for Windows Server 2019.
  • Adds a new date-based cloud tiering policy setting. This policy setting is used to specify files that should be cached if accessed in a specified number of days. To learn more, see Cloud Tiering Overview.
  • Fixes an issue in which cloud tiering can take up to 24 hours to tier files.
  • Improvement when adding a new server to an existing sync group. Files are now downloaded based on the recently Created\Modified date from other servers in the sync group.
  • Improves interop with antivirus and other solutions so that tiered files can now use the FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS attribute.
  • Fixes an issue in which servers are unable to communicate with the Storage Sync Service when app-specific proxy settings are used.
  • Fixes an issue in which deleting a server endpoint will no longer cause tiered files to become unusable as long as the cloud endpoint was not deleted and the server endpoint is recreated within 30 days.
  • Improves unattended agent installations by enabling including an answer file.
  • Adds support for a volume-level restore option on servers which have cloud tiering disabled.
  • Improves sync so that it now supports bidirectional control characters.
  • Adds miscellaneous performance and reliability improvements for sync and cloud tiering.

 

New H-series Azure VMs for HPC workloads

Two new H-series (HB and HC) Azure Virtual Machines for high-performance computing (HPC) workloads are now available in preview. These are optimized for HPC applications driven by intensive computation, such as implicit finite element analysis, reservoir simulation, and computational chemistry. More information in this blog.

Azure Stack

Azure App Service on Azure Stack 1.4 (Update 4) 

Released the fourth update to Azure App Service on Azure Stack. These release notes describe the improvements and fixes in Azure App Service on Azure Stack Update 4 and any known issues.

Extension Host is coming with the next update 1811

Extension Host will be enabled by the next Azure Stack update, 1811. This capability further enhances security and simplifies network integration for Azure Stack.

Come monitorare Office 365 con Azure Log Analytics

In Azure Log Analytics è disponibile una solution specifica che consente di consolidare all’interno del workspace di Log Analytics differenti informazioni provenienti dall’ambiente Office 365, rendendo semplice e intuitiva la consultazione dei dati. In questo articolo saranno esaminate le caratteristiche di questa soluzione e verranno illustrati gli step da seguire per la relativa attivazione.

Caratteristiche dalla soluzione

La solution consente di utilizzare Log Analytics per effettuare le seguenti operazioni relative ad Office 365:

  • Monitorare le attività svolte dagli amministratori, al fine di tenere traccia delle modifiche apportate alle configurazioni e delle operazioni che richiedono privilegi elevati.
  • Analizzare le attività degli account Office 365 al fine di identificare le tendenze comportamentali e controllare l’utilizzo delle risorse. Si possono ad esempio esaminare quali file vengono condivisi all’esterno dell’organizzazione oppure controllare i siti di SharePoint più utilizzati.
  • Fornire supporto nelle attività di audit e compliance. Risulta possibile ad esempio controllare l’accesso a specifici file ritenuti confidenziali.
  • Identificare eventuali comportamenti non desiderati che vengono svolti degli utenti, sulla base di specifiche esigenze organizzative.
  • Svolgere con maggiore semplicità operazioni di troubleshooting che si rendono necessarie nel proprio ambiente Office 365.

Per poter attivare questa solution è necessario disporre di un account con il ruolo Global Administrator. Ad un singolo workspace Log Analytics è possibile connettere più sottoscrizioni Office 365. Nel caso si voglia far confluire nel workspace di Log Analytics anche gli eventi di Audit di Office 365 è necessario abilitare l’auditing sulla subscription Office 365, seguendo la procedura riportata in questa documentazione.

Figura 1 – Abilitazione Office 365 audit

Attivazione della soluzione

Per attivare l’Office 365 Management solution è necessario seguire questa procedura. La solution colleziona i dati direttamente da Office 365, senza l’iterazione di alcun agente di Log Analytics.

Figura 2 – Accesso al Workspace summary dal portale Azure e aggiunta solution

Figura 3 – Selezione della solution di Office 365

Figura 4 – Selezione del workspace da utilizzare

La solution richiede la presenza di una applicazione Azure Active Directory, configurata secondo quanto riportato in seguito, la quale viene utilizzata per accedere ai dati di Office 365.

Figura 5 – Aggiunta di una nuova App registration in Azure AD

Figura 6 – Creazione dell’App registration necessaria per la solution

Figura 7 – Attivazione dell’impostazione Multi-tenanted

Figura 8 – Aggiunta API Access per Office 365 Management APIs

Figura 9 – Selezione dei permessi necessari per Office 365 Management APIs

Figura 10 – Assegnazione dei permessi

Per poter configurare la solution è richiesta una chiave per l’applicazione Azure Active Directory creata.

Figura 11 – Generazione di una chiave per l’applicazione

Giunti a questo punto è necessario eseguire lo script PowerShell office365_consent.ps1 che abilita l’accesso amministrativo. Tale script è disponibile a questo indirizzo.

Figura 12 – Command line di esempio per l’esecuzione dello script office365_consent.ps1

Figura 13 – Richiesta del consenso amministrativo

L’ultimo step necessario per completare l’attivazione è l’esecuzione dello script PowerShell office365_subscription.ps1, anch’esso disponibile a questo indirizzo, il quale sottoscrive l’applicazione Azure AD creata al workspace Log Analytics.

Figura 14 – Command line di esempio per l’esecuzione dello script office365_subscription.ps1

In seguito alla configurazione inziale possono essere necessari diversi minuti prima di visualizzare i dati di provenienti da Office 365 in Log Analytics. Tutti i record creati da questa solution in Log Analytics hanno valorizzato il Type in OfficeActivity. Il valore contenuto nella proprietà OfficeWorkload determina a quale Servizio di Office 365 si riferisce: Exchange, Azure Active Directory, SharePoint, oppure OneDrive. Nella proprietà RecordType viene invece riportata la tipologia di operazione svolta.

La solution aggiunge nella dashboard il seguente tile:

Figura 15 – Tile di Office 365

Selezionandolo si viene rimandati nella dashboard specifica, la quale suddivide per servizi le varie attività collezionate di Office 365.

Figura 16 – Dashboard di Office 365

Ovviamente è possibile eseguire anche delle query specifiche in base alle proprie esigenze:

Figura 17 – Esempi di query di riportare specifici record collezionati dalla solution

 

Conclusioni

La raccolta in Log Analytics delle attività svolte in Office 365 consente di avere un controllo capillare dell’ambiente, al fine di poter ottemperare al meglio e con un unico strumento alle normative riguardanti l’auditing e la compliance.

Azure File Sync: panoramica della soluzione

Il servizio Azure File Sync (AFS) permette di centralizzare le cartelle di rete della propria infrastruttura in Azure Files, consentendo di mantenere le caratteristiche tipiche di un file server on-premises, in termini di performance, compatibilità e flessibilità e allo stesso tempo di beneficiare delle potenzialità offerte dal cloud. In questo articolo verranno riportate le caratteristiche principali del servizio Azure File Sync e le procedure da seguire per effettuarne il deployment.

Figura 1 – Schema di overview di Azure File Sync

Azure File Sync è in grado di trasformare Windows Server in una “cache” per accedere rapidamente ai contenuti presenti su una determinata Azure file share. L’accesso locale ai propri dati può avvenire con qualsiasi protocollo disponibile in Windows Server, come SMB, NFS, e FTPS. Si ha la possibilità inoltre di disporre di più server “cache” dislocati in location geografiche differenti.

Queste le caratteristiche principali di Azure File Sync:

  • Multi-site sync: si ha la possibilità di effettuare la sincronizzazione tra differenti site, consentendo di accedere in scrittura agli stessi dati tra differenti Windows Servers ed Azure Files.
  • Cloud tiering: vengono mantenuti localmente solo i dati acceduti di recente.
  • Integrazione con Azure backup: viene a decadere la necessità di effettuare il backup dei dati on premises. La protezione dei contenuti è possibile farla tramite Azure Backup.
  • Disaster recovery: si ha la possibilità di effettuare in modo immediato il ripristino dei metadata dei file e di richiamare solamente i dati necessari, per velocizzare le operazioni di riattivazione del servizio in scenari di Disaster Recovery.
  • Accesso diretto all’ambiente cloud: è consentito accedere direttamente ai contenuti presenti sulla File Share da altre risorse Azure (IaaS e PaaS).

 

Requisiti

Per poter effettuare il deployment di Azure File Sync è necessario disporre dei seguenti requisiti:

Un Azure Storage Account, con una file share configurata in Azure Files, nella stessa region dove si vuole fare il deploy del servizio AFS. Per effettuare la creazione di uno storage account è possibile seguire l’articolo Create a storage account, mentre la procedura di creazione della file share è riportata in questo documento.

Un sistema Windows Server con sistema operativo Windows Server 2012 R2 o successivo, il quale dovrà avere:

  • PowerShell 5.1, che è incluso di default a partire da Windows Server 2016.
  • Moduli PowerShell AzureRM.
  • Agente Azure File Sync. Il setup di installazione dell’agente può essere scaricato a questo indirizzo. Nel caso si intenda utilizzare AFS in ambiente cluster è opportuno installare l’agente su tutti i nodi del cluster. A questo proposito è bene precisare che Windows Server Failover Clustering è supportato da Azure File Sync per deployment di tipologia “File Server for general use”. L’ambiente Failover Cluster non è invece supportato su “Scale-Out File Server for application data” (SOFS) oppure su Clustered Shared Volumes (CSVs).
  • Si consiglia di mantenere l’opzione “Internet Explorer Enhanced Security Configuration” disabilitata sia per gli Administrators che per gli Users.

 

Concetti e configurazione del servizio

Dopo aver verificato la presenza di questi requisiti l’attivazione di Azure File Sync richiede di procedere con la creazione del servizio Storage Sync:

Figura 2 – Creazione servizio Storage Sync

Si tratta della risorsa top-level per Azure File Sync, la quale funge da contenitore per le relazioni di sincronizzazione tra i differenti storage account e molteplici Sync Group. Il Sync Group definisce la topologia di sincronizzazione per un set di files. Gli endpoint che si trovano all’interno dello stesso Sync Group vengono mantenuti in sincronizzazione tra di loro.

Figura 3 – Creazione Sync Group

A questo punto è possibile procedere con la registrazione del server avviando l’agente Azure File Sync.

Figura 4 – Avvio del processo di Sign-in

Figura 5 – Selezione dei parametri di registrazione del server

Figura 6 – Conferma di registrazione dell’agente

Al termine della registrazione il server comparirà anche nella sezione “Registered servers” del portale Azure:

Figura 7 – Server registrati nel servizio Storage Sync

Conclusa la registrazione del server è opportuno inserire un Server Endpoint all’interno del Sync Group, il quale integra un volume oppure una folder specifica, con un Registered Server, creando una location per la sincronizzazione.

Figura 8 – Aggiunta di un Server Endpoint

Aggiungendo un Server Endpoint è possibile abilitare la funzionalità di Cloud tiering che consente di mantenere, localmente sulla cache della macchina Windows Server, i file acceduti più frequentemente, mentre tutti i restanti file vengono salvati in Azure sulla base di specifiche policy che è possibile configurare. Per maggiori informazioni relative alla funzionalità di Cloud Tiering è possibile consultare la documentazione ufficiale Microsoft. A questo proposito è opportuno specificare che al momento non c’è supporto tra Azure File Sync con abilitata la funzionalità di cloud tiering, e la deduplica del dato. Nel caso si desideri abilitare Windows Server Data Deduplication occorre mantenere disabilitata la funzionalità di cloud tiering.

Dopo aver aggiunto uno o più Server Endpoint è possibile consultare lo stato del Sync Group:

Figura 9 – Stato del Sync Group

 

Per ottenere dei deployment di successo di Azure File Sync è inoltre necessario verificare attentamente la compatibilità con le soluzioni antivirus e di backup che vengono utilizzate.

Azure File Sync e DFS Replication (DFS-R) sono due soluzioni per la replica del dato e possono funzionare anche in side-by-side purché siano rispettate queste condizioni:

  1. Azure File Sync cloud tiering deve essere disabilitato sui volumi con cartelle DFS-R replicate.
  2. I Server endpoints non devono essere configurati su cartelle DFS-R read-only.

Azure File Sync può essere un ottimo sostituto di DFS-R e per la migrazione è possibile seguire le indicazioni riportate in questo documento. Rimangono alcuni scenari specifici che possono richiedere l’utilizzo contemporaneo di entrambe le soluzioni di replica:

  • Non tutti i server on-premises che necessitano di una copia dei file possono essere connessi a Internet.
  • Quando i branch servers consolidano i dati in un singolo hub server, sul quale viene poi utilizzato Azure File Sync.
  • Durante la fase di migrazione di deployment di DFS-R verso Azure File Sync.

Conclusioni

Azure File Sync è una soluzione che consente di estendere il classico file server dislocato on-premises con nuove funzionalità di sincronizzazione dei contenuti, beneficando delle potenzialità del cloud pubblico di Microsoft in termini di scalabilità e flessibilità.