Archivi categoria: Microsoft Azure

Azure IaaS and Azure Stack: announcements and updates (February 2019 – Weeks: 07 and 08)

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

Serial console for Azure Virtual Machines (feature update)

The serial console for Azure Virtual Machines enables you to reboot your VM from within the console experience. This ability will help you if you want to reboot a stuck VM or enter the boot menu of your VM.

Azure File Sync v5 release

Improvements and issues that are fixed:

  • Support for Azure Government cloud
    • Added preview support for the Azure Government cloud. This requires a white-listed subscription and a special agent download from Microsoft.
  • Support for Data Deduplication
    • Data Deduplication is now fully supported with cloud tiering enabled on Windows Server 2016 and Windows Server 2019. Enabling deduplication on a volume with cloud tiering enabled lets you cache more files on-premises without provisioning more storage.
  • Support for offline data transfer (e.g. via Data Box)
    • Easily migrate large amounts of data into Azure File Sync via any means you choose. You can choose Azure Data Box, AzCopy and even third party migration services. No need to use massive amounts of bandwidth to get your data into Azure, in the case of Data Box.
  • Improved sync performance
    • Customers with multiple server endpoints on the same volume may have experienced slow sync performance prior to this release. Azure File Sync creates a temporary VSS snapshot once a day on the server to sync files that have open handles. Sync now supports multiple server endpoints syncing on a volume when a VSS sync session is active. No more waiting for a VSS sync session to complete so sync can resume on other server endpoints on the volume.
  • Improved monitoring in the portal
    • Charts have been added in the Storage Sync Service portal to view:
      • Number of files synced
      • Size of data transferred
      • Number of files not syncing
      • Size of data recalled
      • Agent connectivity status
  • Improved scalability and reliability
    • Maximum number of file system objects (directories and files) in a directory has increased to 1,000,000. Previous limit was 200,000.
    • Sync will try to resume data transfer rather than retransmitting when a transfer is interrupted for large files

Agent installation notes:

  • The Azure File Sync agent is supported on Windows Server 2012 R2, Windows Server 2016, and Windows Server 2019.
  • Azure File Sync agent version 4.0.1.0 or a later version is required to upgrade existing agent installations.
  • A restart may be required if files are in use during the installation.
  • The agent version for the v5 release is 5.0.2.0.

Installation instructions are documented in KB4459989.

Service tags are available in Azure Firewall network rules

A service tag represents a group of IP address prefixes to help minimize complexity for security rule creation. You cannot create your own service tag, nor specify which IP addresses are included within a tag. Microsoft manages the address prefixes encompassed by the service tag, and automatically updates the service tag as addresses change. Azure Firewall service tags can be used in the network rules destination field. You can use them in place of specific IP addresses. Service tags are fully supported in all public regions using PowerShell/REST/CLI by simply including the tag string in a network rule destination field. Portal support is being rolled out and will incrementally be available in all public regions in the near future.

Azure IaaS and Azure Stack: announcements and updates (February 2019 – Weeks: 05 and 06)

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

Standard Load Balancer and Standard Public IP are available in Azure Government 

Azure Standard Load Balancer and Standard Public IP are now generally available in Azure Government cloud regions. Standard Load Balancer offers resiliency and ease of use for all your virtual machine resources inside a virtual network. It supports inbound and outbound scenarios, provides low latency and high throughput, and scales up to millions of flows for all TCP and UDP applications. You can use load-balancing rules with TCP/HTTP/HTTPS health probes, HA port load-balancing rules for network virtual appliances, inbound NAT rules for port forwarding, and outbound rules to scale and tune your outbound connectivity.

Global VNet Peering in Azure China cloud

Global VNet Peering is generally available in all Azure China cloud regions. This means you can peer virtual networks across the China cloud regions. You cannot peer across Azure China and Azure public cloud regions.

General availability of the Lsv2-series Azure Virtual Machines (VMs)

The Lsv2-series is well suited for your high throughput and high IOPS workloads including big data applications, SQL and NoSQL databases, data warehousing, and large transactional databases. The Lsv2-series features high throughput, low latency, and directly mapped local NVMe storage. The Lsv2 VMs run on the AMD EPYCTM 7551 processor with an all core boost of 2.55GHz. The Lsv2-series VMs offer various configurations from 8 to 80 vCPUs with simultaneous multi-threading. Each VM features 8 GiB of memory and one 1.92TB NVMe SSD M.2 device per 8 vCPUs, with up to 19.2TB (10 x 1.92TB) available on the 80vCPU L80s v2.

M-series virtual machines (VMs) are available in Australia Central 2 region

Azure M-series VMs are now available in the Australia Central 2 region. M-series VMs offer configurations with memory from 192 GB to 3.8 TiB (4 TB) RAM and are certified for SAP HANA.

Account failover for Azure Storage (public preview)

The preview for account failover for customers with geo-redundant storage (GRS) enabled storage accounts is available. Customers using GRS or RA-GRS accounts can take advantage of this functionality to control when to failover from the primary region to the secondary region for their storage accounts. If the primary region for your geo-redundant storage account becomes unavailable for an extended period of time, you can force an account failover. When you perform a failover, all data in the storage account is failed over to the secondary region, and the secondary region becomes the new primary region. The DNS records for all storage service endpoints – blob, Azure Data Lake Storage Gen2, file, queue, and table – are updated to point to the new primary region. Once the failover is complete, clients can automatically begin writing data to the storage account using the service endpoints in the new primary region, without any code changes.

Reserved instances applicable to classic VMs, cloud services, and Dev/Test subscriptions

Classic VMs, Cloud Services users, Enterprise Dev/Test and Pay-As-You-Go Dev/Test subscriptions can now benefit from the RI discounts.

Resource group control for Azure DevTest Lab

As a lab owner, you now have the option to configure all your lab virtual machines (VMs) to be created in a single resource group. This helps prevent you from reaching resource group limits on your Microsoft Azure subscription. The feature will also help by enabling you to consolidate all your lab resources within a single resource group. In result this will simplify tracking those resources and applying policies to manage them at the resource group level.

Azure Stack

Azure Stack 1901 update

The update includes improvements, fixes, 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. The Azure Stack 1901 update build number is 1.1901.0.95.

Azure IaaS and Azure Stack: announcements and updates (January 2019 – Weeks: 03 and 04)

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 Guest OS Family 6 (Windows Server 2019)

Azure Guest OS Family 6, based on Windows Server 2019, is now generally available. Windows Server 2019 is the operating system that bridges on-premises environments with Azure, adding layers of security while helping you modernize your applications and infrastructure.

Azure Availability Zones in East US 2

Azure Availability Zones, a high-availability solution for mission-critical applications, is generally available in East US 2.

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, Microsoft offers a service-level agreement (SLA) of 99.99% for uptime of virtual machines.

Update rollup for Azure File Sync Agent: January 2019

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

  • Files are not tiered after upgrading the Azure File Sync agent to version 4.x.
  • AfsUpdater.exe is now supported on Windows Server 2019.
  • Miscellaneous reliability improvements for 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 4.0.1.0 or later installed.
  • The agent version of this update rollup is 4.3.0.0.
  • A restart may be required if files are in use during the update rollup installation.
  • Installation instructions are documented in KB4481059.

Azure Migrate is available in Asia and Europe

Azure Migrate now supports Asia and Europe as migration project locations. This means that you can now store your discovered metadata in Asia (Southeast Asia) and Europe (North Europe/West Europe) regions.

In addition to Asia and Europe, Azure Migrate also supports storing the metadata in United States and Azure Government geographies. Support for other Azure geographies is planned for the future.

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.

M-series virtual machines (VMs) are available in Australia Central region

Azure M-series VMs are  available in the Australia Central region. M-series VMs offer configurations with memory from 192 GB to 3.8 TiB (4 TB) RAM and are certified for SAP HANA.

Azure Governance: introduzione alle Azure Policy

L’IT governance è quel processo attraverso il quale è possibile garantire a un’organizzazione un utilizzo efficace ed efficiente delle risorse IT, al fine di poter raggiungere i propri obiettivi. Azure Policy è un servizio disponibile nel cloud pubblico di Microsoft che è possibile utilizzare per creare, assegnare e gestire dei criteri per controllare le risorse presenti in Azure. Le Azure Policy, integrate nativamente nella piattaforma, sono un elemento chiave per la governance dell’ambiente cloud. In questo articolo vengono riportati i principi di funzionamento e le caratteristiche della soluzione.

Negli ambienti Azure si possono trovare differenti subscription sulle quali sviluppano e operano diversi gruppi di operatori. L’esigenza comune è di standardizzare, e in alcuni casi imporre, come vengono configurate le risorse nel cloud. Tutto questo viene fatto per ottenere ambienti che rispettano specifiche normative di conformità, controllare la sicurezza, i costi delle risorse e uniformare il design di differenti architetture. Questi obiettivi si possono ottenere con un approccio tradizionale, che prevede un blocco degli operatori (Dev/Ops) nell’accesso diretto alle risorse cloud (tramite portale, api oppure cli). Questo approccio tradizionale risulta però poco flessibile, in quanto implica una perdita di agilità nel controllare il deployment delle risorse. Utilizzando invece il meccanismo che viene fornito in modo nativo dalla piattaforma Azure è possibile pilotare la governance per ottenere il controllo desiderato, senza impattare sulla velocità, elemento fondamentale nelle operations dell’IT moderno.

Figura 1 – Approccio tradizionale vs cloud-native governance

In ambito Azure Policy è possibile fare quanto in seguito riportato:

  • Attivare policy built-in o configurarle in base alle proprie esigenze.
  • Effettuare in tempo reale la valutazione dei criteri presenti nelle policy e forzarne l’esecuzione.
  • Valutare la compliance delle policy periodicamente oppure su richiesta.
  • Attivare dei criteri di controllo anche sull’ambiente guest delle macchine virtuali (VM In-Guest Policy).
  • Applicare Policy a dei Management Group al fine di ottenere un controllo sull’intera organizzazione.
  • Applicare contemporaneamente più criteri e aggregare i vari stati delle policy.
  • Configurare scope sui quali vengono applicate delle esclusioni.
  • Attivare operazioni per la remediation in tempo reale, anche per risorse già esistenti.

Tutto questo si traduce nella possibilità di applicare e forzare su larga scala dei criteri di compliance e le relative azioni di remediation.

Il meccanismo di funzionamento delle Azure Policy è semplice e integrato nella piattaforma.  Nel momento in cui viene fatta una richiesta di configurazione di una risorsa Azure tramite ARM, questa viene intercettata dal layer contenente il motore che effettua la valutazione delle policy. Tale engine effettua una valutazione sulla base delle policy Azure attive e stabilisce la legittimità della richiesta.

Figura 2 – Principio di funzionamento delle Azure Policy nella creazione di risorse

Lo stesso meccanismo viene poi ripetuto periodicamente oppure su specifica richiesta per valutare lo strato di compliance delle risorse esistenti.

Figura 3 – Principio di funzionamento delle Azure Policy nel controllo delle risorse

In Azure sono già presenti molte policy built-in pronte per essere applicate. Inoltre, in questo repository GitHub è possibile trovare diverse definizioni di Azure Policy, che possono essere utilizzate direttamente oppure modificate in base alle proprie esigenze. La definizione delle Azure Policy è fatta in JSON e segue una struttura ben precisa, descritta in questo documento Microsoft. Si ha inoltre la possibilità di creare delle Initiatives, che sono un insieme di più policy.

Figura 4 – Esempio di definizione di una Azure Policy

Nel momento in cui si possiede la definizione della policy desiderata, è possibile assegnarla a una subscription ed eventualmente in modo più circoscritto ad un Resource Group specifico. Si ha inoltre la possibilità di escludere determinate risorse dall’applicazione della policy.

Figura 5 – Processo di assegnazione di una Azure Policy

In seguito all’assegnazione è possibile valutare lo stato di compliance nel dettaglio e se lo si ritiene necessario applicare delle azioni di remediation.

Figura 6 – Stato di compliance

Figura 7 – Esempio di azione di remediation

 

Conclusioni

Grazie all’utilizzo delle Azure Policy si ha la possibilità di controllare totalmente il proprio ambiente Azure, in modo semplice ed efficace. Statistiche fornite da Microsoft citano che considerando i 100 top Azure Customers, 92 di questi utilizzano le Azure Policy per controllare il proprio ambiente. Questo perché aumentando la complessità e la quantità di servizi su Azure è indispensabile adottare degli strumenti, come Azure Policy, per avere delle politiche efficaci di governance.

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.