Archivi categoria: Microsoft Azure

Azure storage: Disaster Recovery e funzionalità di failover

Microsoft ha recentemente annunciato una nuova funzionalità che consente, per gli Azure storage account geo-ridondati, di effettuare in modo pilotato il failover. Tale caratteristica aumenta le capacità di controllo su questa tipologia di storage account, consentendo di avere una maggiore flessibilità in scenari di Disaster Recovery. In questo articolo viene mostrato il principio di funzionamento e la procedura da seguire per utilizzare questa nuova funzionalità.

Tipologie di storage account

In Azure sono presenti diverse tipologie di storage account con caratteristiche di replica distinte, per ottenere differenti livelli di ridondanza. Nel caso si voglia mantenere il dato presente sugli storage account disponibile anche a fronte di malfunzionamenti di una intera region di Azure è necessario adottare gli storage account di tipologia geo-ridondati, tra i quali se ne distinguono due differenti tipologie:

  • Geo-redundant storage (GRS): il dato viene replicato in modo asincrono in due region geografiche di Azure, distanti centinaia di miglia tra di loro.
  • Read-access geo-redundant storage (RA-GRS): segue lo stesso principio di replica precedentemente descritto, ma con la caratteristica che l’endpoint secondario può essere acceduto per leggere i dati replicati.

Utilizzando queste tipologie di storage account vengono mantenute tre copie del dato nella region primaria di Azure, selezionata in fase di configurazione, e ulteriori tre copie asincrone del dato in un’altra region di Azure, seguendo il principio delle Azure Paired Regions.

Figura 1 – Normale funzionamento dello storage di tipologia GRS/RA-GRS

Per maggiori informazioni sulle differenti tipologie di storage account e le relative caratteristiche di ridondanza è possibile consultare la documentazione ufficiale Microsoft.

Caratteristiche del processo di failover dello storage account

Grazie a questa nuova funzionalità, l’amministratore ha la possibilità di avviare il processo di account failover deliberatamente, nel momento in cui lo ritiene opportuno. Il processo di failover effettua un aggiornamento del record DNS pubblico dello storage account, in questo modo le richieste vengono indirizzate verso l’endpoint dello storage account presente nella region secondaria.

Figura 2 – Processo di failover per uno storage di tipologia GRS/RA-GRS

Al termine del processo di failover lo storage account è configurato per essere di tipologia Locally redundant storage (LRS) ed è necessario procedere con la relativa configurazione per renderlo nuovamente geo-ridondato.

Un aspetto importante da tenere in considerazione, quando si decide di intraprendere un failover dello storage account, è che tale operazione può comportare una perdita di dati, in quanto la replica tra le due region di Azure avviene in modalità asincrona. A causa di questo aspetto, in caso di indisponibilità della region primaria, potrebbero non essere stati replicate verso la region secondaria tutte le modifiche. Per verificare questa condizione è possibile fare riferimento alla proprietà Last Sync Time che indica il momento nel quale viene garantito che il dato è stato correttamente replicato verso la region secondaria.

Procedura di failover dello storage account dal portale Azure

In seguito, viene riportata la procedura per effettuare il failover di uno storage account direttamente dal portale Azure.

Figura 3 – Avvio del processo di failover dello Storage account

Figura 4 – Conferma del processo di failover dello Storage account

La procedura per avviare il failover di uno storage account può essere svolta non solo dal portale Azure, ma anche tramite PowerShell, Azure CLI, oppure utilizzando le API delle risorse Azure Storage.

Come individuare le problematiche sugli storage account

Microsoft raccomanda che gli applicativi che utilizzano gli storage account siano progettati per sostenere possibili errori in fase di scrittura. In questo modo l’applicativo dovrebbe esporre eventuali fallimenti riscontrati nella scrittura, in modo da essere allertati sulla possibile indisponibilità nell’accedere allo storage in una determinata region. Questo consentirebbe di intraprendere le dovute azioni correttive, come ad esempio il failover dello storage account in modalità GRSRA-GRS.

In modo nativo la piattaforma, tramite il servizio Azure Service Health, fornisce indicazioni dettagliate nel caso dovessero verificarsi condizioni che influenzano il funzionamento dei propri servizi presenti in Azure, compreso lo storage. Grazie alla completa integrazione di Service Health in Azure Monitor, il quale detiene il motore di alerting di Azure, è possibile configurare degli Alerts specifici qualora ci siano problemi lato Azure, che impattano sul funzionamento delle risorse presenti sulle proprie subscription.

Figura 5 – Creazione Health alert nel servizio Service Health

Figura 6 – Rule di notifica di problemi sullo storage

La notifica avviene tramite Action Groups, in seguito alla quale è possibile valutare la reale esigenza di intraprendere il processo di failover dello storage account.

Conclusioni

Prima del rilascio di questa funzionalità, in presenza di storage account di tipologia GRS/RA-GRS, il failover doveva comunque essere pilotato dal personale Microsoft a fronte di un fault che impattasse lo storage di una intera region Azure. Grazie a questa funzionalità viene fornito all’amministratore la possibilità di pilotare a piacimento il failover, garantendo così un maggiore controllo sugli storage account. Al momento questa funzionalità è disponibile in preview e solamente per gli storage account creati in determinate region Azure. Come accade per diverse funzionalità Azure in preview è bene attendere il rilascio ufficiale prima di utilizzarla per workload in ambiente di produzione.

Azure management services e System Center: novità di Febbraio 2019

Il mese di Febbraio è stato ricco di novità e diversi sono gli aggiornamenti che hanno interessato gli Azure management services e System Center. In questo articolo vengono riepilogati per avere una panoramica complessiva delle principali novità del mese, in modo da rimanere sempre aggiornati su questi argomenti ed avere i riferimenti necessari per condurre ulteriori approfondimenti.

Azure Monitor

Multi-resource support per metric alerts

Grazie a questa nuova funzionalità è possibile configurare una singola metric alert rule per monitorare:

  • Una lista di macchine virtuali in una region Azure.
  • Tutte le macchine virtuali in uno o più resource groups in una region Azure.
  • Tutte le macchine virtuali di una subscription, presenti in una determinata region Azure.

Azure Automation

Il runbook Update Azure Modules è open source

Azure Automation consente di aggiornare i moduli Azure Powershell importati in un automation account con le ultime versioni disponibili presenti nella PowerShell Gallery. Tale possibilità viene fornita tramite l’action Update Azure Modules presente nella pagina Modules dell’Automation Account, ed è implementata tramite un runbook nascosto. Al fine di migliorare le attività di diagnostica e troubleshooting e di fornire la possibilità di personalizzazione del modulo, questo è stato reso open source.

Supporto per il modulo Azure PowerShell Az

In Azure Automation è stato introdotto il supporto per il modulo PowerShell Az, grazie al quale è possibile utilizzare i moduli Azure aggiornati all’interno dei runbook, per gestire i vari servizi Azure.

Azure Log Analytics

Nuova versione dell’agente per Linux

Questo mese la nuova versione dell’agente OMS per sistemi Linux risolve un bug specifico in fase di installazione. Per ottenere la versione aggiornata dell’agente OMS è possibile accedere alla pagina ufficiale GitHub.

Disponibilità in nuove region di Azure

Risulta possibile attivare un workspace di Log Analytics anche nelle region Azure di West US 2, Australia East e Australia Central. In questo modo i dati vengono mantenuti e processati in queste region.

Azure Site Recovery

Nuovo Update Rollup

Per Azure Site Recovery è stato rilasciato l’Update Rollup 33 che introduce nuove versioni per i seguenti componenti:

  • Microsoft Azure Site Recovery Unified Setup (versione 9.22.5109.1): utilizzato per scenari di replica da VMware verso Azure.
  • Microsoft Azure Site Recovery Provider (versione 5.1.3900.0): utilizzato per scenari di replica da Hyper-V verso Azure oppure verso un secondary site.
  • Microsoft Azure Recovery Services Agent (versione 2.0.9155.0): utilizzato per scenari di replica da Hyper-V verso Azure.

L’installazione di questo update rollup è possibile su tutti i sistemi con installato Microsoft Azure Site Recovery Service Provider, includendo:

  • Microsoft Azure Site Recovery Provider per System Center Virtual Machine Manager (3.3.x.x).
  • Microsoft Azure Site Recovery Hyper-V Provider (4.6.x.x).
  • Microsoft Azure Site Recovery Provider (5.1.3500.0) e versioni successive.

L’Update Rollup 33 per Microsoft Azure Site Recovery Unified Setup si applica a tutti i sistemi che hanno installato la versione 9.17.4860.1 o successive.

Per ottenere maggiori informazioni sulle problematiche risolte, sugli improvements dati da questo Update Rollup e per ottenere la procedura da seguire per la relativa installazione è possibile consultare la KB specifica 4489582.

Protezione di cluster Storage Space Direct

In Azure Site Recovery (ASR) è stato introdotto, con l’Update Rollup 33, anche il supporto per la protezione di cluster Storage Space Direct, utilizzati per realizzare Guest Cluster in ambiente Azure.

Azure Backup

In Azure Backup è stata rilasciata la funzionalità di Instant Restore per le macchine virtuali presenti su Azure, che consente di effettuare il recovery di VMs utilizzando le snapshots archiviate. Inoltre viene data la possibilità all’amministratore di configurare i tempi di retention delle snapshot nelle policy di backup (da uno a cinque giorni, il default è due giorni). Questo consente di aumentare il controllo sulla protezione delle proprie risorse, adattandola su specifiche esigenze e in base alla criticità delle stesse.

Figura 1 – Periodo di retention delle snapshot

System Center Configuration Manager

Rilasciate le versioni 1902 e 1902.2 per il Technical Preview Branch

Tra le principali novità di queste release troviamo la possibilità di gestire in modo più efficace le notifiche di riavvio sui sistemi gestiti da Configuration Manager.

Per tutti i dettagli riguardanti le novità incluse in queste release è possibile consultare questo documento. Si ricorda che i rilasci nel Technical Preview Branch consentono di valutare in anteprima le nuove funzionalità di SCCM ed è consigliato applicare questi aggiornamenti solo in ambienti di test.

System Center Operations Manager

Management Packs

In seguito, si riportano le novità riguardanti i seguenti Management Pack di SCOM:

  • Microsoft System Center 2016 Management Pack per Microsoft Azure version 1.6.0.7
  • Microsoft System Center Management Pack per SQL Server 2017+ Reporting Services version 7.0.12.0
  • Log Analytics Management Pack per SCOM 1801 versione 7.3.13288.0 e SCOM 2016 versione 7.2.12074.0
  • System Center Management Pack per Windows Server DNS versione 10.0.9.3

Valutazione di Azure e System Center

Per testare e valutare in modo gratuito i servizio offerti da Azure è possibile accedere a questa pagina, mentre per provare i vari componenti di System Center è necessario accedere all’Evaluation Center e, dopo essersi registrati, è possibile avviare il periodo di trial.

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.