Archivi categoria: Microsoft Azure

Azure IaaS and Azure Stack: announcements and updates (October 2018 – Weeks: 40 and 41)

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

Advanced Threat Protection for Azure Storage (public preview)

Advanced Threat Protection for Azure Storage, available in public preview, detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit storage accounts. This feature helps customers detect and respond to potential threats on their storage account as they occur.

 

Ephemeral OS Disk (limited preview)

Limited preview of Ephemeral OS Disk, a new type of OS disk created directly on the host node, providing local disk performance and faster boot/reset time. Ephemeral OS Disk is supported for all virtual machines (VM) and virtual machine scale sets (VMSS). Ephemeral OS Disk is ideal for stateless workloads that require consistent read/write latency to OS disk, as well as frequent reimage operations to reset the VM(s) to the original state. This includes workloads such as website applications, game server hosting services, VM pools, computation, jobs and more. Ephemeral OS Disk also works well for workloads that are leveraging low-priority VM scale sets.

Azure confidential computing (public preview)

Azure confidential computing protects your data while it’s in use. It is the final piece to enable data protection through its lifecycle whether at rest, in transit, or in use. It is the cornerstone of Microsoft ‘Confidential Cloud’ vision, which aims to make data and code opaque to the cloud provider. DC-series of virtual machines in US East and Europe West are in public preview. While these virtual machines may ‘look and feel’ like standard VM sizes from the control plane, they are backed by hardware-based Trusted Execution Environments (TEEs), specifically the latest generation of Intel Xeon Processors with Intel SGX technology. You can now build, deploy, and run applications that protect data confidentiality and integrity in the cloud. The DC-series of VMs are the first set of Generation 2 virtual machines. As such, Microsoft has specially configured operating images that are required with these virtual machines (Generation 2 support for Ubuntu Server 16.04 and Windows Server 2016 Datacenter). These images are automatically used when deploying through the portal. Custom images are not yet supported. DC-series VMs will not show up in the size selector for arbitrary marketplace images, as not all images have been updated yet.

Azure IaaS and Azure Stack: announcements and updates (September 2018 – Weeks: 38 and 39)

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

Virtual machine serial console

The Azure virtual machine serial console is now generally available in all public regions. New features include magic SysRq keys, non-maskable interrupts, and subscription-wide enable/disable. More details are available in the documentation for Windows and Linux.

 

Immutable storage for Azure Storage Blobs

Financial services organizations regulated by SEC, CFTC, FINRA, IIROC, FCA, etc., are required to retain business-related communications in a Write-Once-Read-Many (WORM) or immutable state to ensure that they’re non-erasable and non-modifiable for a specific retention interval. The immutable storage requirement is not limited to financial organizations. It also applies to industries such as healthcare, insurance, media, public safety, and legal services.

To address this requirement, immutable storage for Azure Blob storage is now generally available in all Azure public regions. Through configurable policies, users can keep Azure Blob storage data in an immutable state where blobs can be created and read, but not modified or deleted.

For more details on the feature, see the Microsoft Azure blog.

 

Azure Premium Blob Storage (preview)

Azure Blob Storage introduces a new performance tier—Premium Blog Storage, complimenting the existing hot, cool, and archive tiers. Data in Premium Blob Storage is stored on solid-state drives, which are known for lower latency and higher transactional rates compared to traditional hard drives. Premium Blob Storage is ideal for workloads that require very fast access times. This includes most scenarios with a human in the loop, such as interactive video editing, static web content, and online transactions. It also works well for workloads that perform many transactions that are relatively small, such as capturing telemetry data, message passing, and data transformation.

 

Azure Availability Zones in West US 2 and North Europe

Azure Availability Zones, a high-availability solution for mission-critical applications, is now generally available in West US 2 and North Europe.

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

Availability Zones are generally available in select regions.

 

Public IP prefix (preview)

A Public IP prefix is a reserved range of static IP addresses that can be assigned to your subscription. You can use a prefix to simplify IP address management in Azure. Knowledge of the range ahead of time eliminates the need to change firewall rules as you assign IP addresses to new resources. This predictability significantly reduces management overhead when scaling in Azure.

For more information about Public IP prefixes in Azure and how to use them, see Public IP Prefix.

 

Virtual network peering across Azure Active Directory tenants

Virtual network peering enables direct VM-to-VM connectivity across virtual machines deployed in different virtual networks using the Microsoft backbone. Virtual network peering is now available for virtual networks that belong to subscriptions in different Azure Active Directory tenants.

 

Azure Load Balancer: Outbound Rules for Standard Load Balance GA

This new ability allows you to declare which public IP or public IP prefix should be used for outbound connectivity from your virtual network, and how outbound network address translations should be scaled and tuned.

 

Azure Load Balancer TCP resets on idle (preview)

Azure Load Balancer supports sending of bidirectional TCP resets on idle timeout for load balancing rules, inbound NAT rules, and outbound rules.  For more information, including pricing details, please visit the Azure Load Balancer TCP reset page.

 

ExpressRoute Direct 100Gbps connectivity

ExpressRoute Direct provides 100G connectivity for customers with extreme bandwidth needs. This is 10x faster than other clouds. With ExpressRoute Direct you can send 100 Gbps of network traffic to Azure services such as Azure Storage and Azure Virtual Networks. All your traffic can be on a single 100G ExpressRoute Circuit or you subdivide 100G among your business units in any combination of 40G, 10G, 5G, 2G, and 1G ExpressRoute circuits.

 

ExpressRoute Global Reach

ExpressRoute Global Reach allows you to connect two ExpressRoute circuits together. Your sites that are already connected to ExpressRoute can now privately exchange data via their ExpressRoute circuits. ExpressRoute Global Reach can be enabled on both ExpressRoute Standard and ExpressRoute Premium circuits. ExpressRoute Global Reach is available in the following locations: Hong Kong, Ireland, Japan, Netherlands, United Kingdom, and United States with Korea and Singapore coming soon. More locations will be available later this year.

 

Zone-Redundant VPN and ExpressRoute Virtual Network Gateways

To improve the resiliency, scalability and availability of gateways, Zone Redundant VPN and ExpressRoute Gateways bring support for Azure Availability Zones. With these new Zone-Redundant/Zonal Gateways, you will be able to deploy Azure VPN and Azure ExpressRoute gateways in Azure Availability Zones, thus making them physically and logically separate within a region to protect your on-premises network connectivity to Azure from zone-level failures.

 

Azure Firewall: General availability and new capabilities

Azure Firewall, now GA, offers fully stateful network and application level traffic filtering for VNet resources, with built-in high availability and cloud scalability delivered as a service. For more information, please refer to Azure Firewall documentation.

 

Shared Image Gallery (public preview)

Shared Image Gallery provides an Azure-based solution to make the custom management of virtual machine (VM) images easier in Azure. Shared Image Gallery provides a simple way to share your applications with others in your organization, within or across regions, enabling you to expedite regional expansion or DevOps processes, simplify your cross-region HA/DR setup and more. Shared Image Gallery also enables you to quickly deploy thousands of VMs concurrently from a custom image.

 

Automatic OS image upgrade in virtual machine scale sets is now generally available.

After you enable this feature for your scale sets, when a new OS image is published with the latest features, security patches, and performance improvements, your scale sets and Azure Service Fabric clusters can receive these updates automatically. The new image will roll out to the VMs in your scale sets in batches based on preconfigured health probes to check for application issues. You can monitor the status of upgrades programmatically or through an out-of-the-box experience in the Azure portal. To learn more about this capability and to start enabling it for your VMs in VM scale sets, see this documentation.

 

Azure Virtual Machine Image Builder available in private preview

Azure Virtual Machine (VM) Image Builder, now available in private preview, allows you to migrate your image building pipeline to Azure. Submit a template describing your VM source image and customizations, indicate where to distribute a bootable image, and then start building your VM images.

 

Ultra SSD, a new Azure Managed Disks offering (preview)

Ultra SSD, a new Azure Managed Disks offering for your most demanding data-intensive workloads, is now available in preview. Ultra SSDs can deliver unprecedented and extremely scalable performance with sub-millisecond latency:

  • Choose a disk size from 4 GiB up to 64 TiB.
  • Achieve the optimal performance you need per disk even at low storage capacities.
  • Scale performance up to 160,000* IOPS and 2 GB/s per disk with zero downtime.

 

Azure Stack

Service Fabric now available on Azure Stack

Azure Service Fabric is now available on Azure Stack. Service Fabric is a distributed systems platform that makes it easy to package, deploy, and manage scalable and reliable microservices and containers.

 

Red Hat OpenShift and Microsoft Azure Stack together for hybrid enterprise solutions

OpenShift and Azure Stack present exciting new options for customers who use Microsoft and Red Hat technologies and offer the greatest possible flexibility and consistency where these solutions are run and managed – whether its in the public cloud or on-premises with Azure Stack. OpenShift and Azure Stack enable a consistent application experience across Azure, Azure Stack, bare-metal, Windows and RHEL bringing together Microsoft’s and Red Hat’s developer frameworks and partner ecosystems.

Azure Networking: caratteristiche del Global VNet peering

Le Virtual Network in ambiente Azure sono per loro natura logicamente isolate, per consentire di connettere in modo sicuro differenti risorse Azure. Il Global VNet peering in ambito Azure fornisce la possibilità di mettere in comunicazione virtual network che risiedono su differenti region di Azure. In questo articolo verranno approfonditi i benefici e le attuali costrizioni imposte dal Global VNet peering. Sarà inoltre mostrata la procedura da seguire per l’attivazione di un Global VNet peering.

Figura 1 – Esempio di connessione di VNet di Azure in region differenti

Nel momento in cui viene configurato il peering tra due virtual network che risiedono in region di Azure diverse, si espande il confine logico e le macchine virtuali attestate su queste VNet possono comunicare tra di loro con i propri indirizzi IP privati, senza dover utilizzare gateway e indirizzi IP pubblici. Inoltre, è possibile adottare il modello di rete hub-spoke, per condividere le risorse quali firewall oppure virtual appliance, mettendo in comunicazione anche virtual network in differenti region di Azure, attraverso il Global VNet peering.

Benefici del Global VNet peering

I principali benefici che si possono ottenere utilizzando il Global VNet peering per mettere in comunicazione le virtual network sono:

Figura 2 – Rete di backbone di Microsoft

  • Si può usufruire di una connettività a bassa latenza e con un bandwidth elevato.
  • La configurazione è semplice e non richiede la presenza di gateway per istaurare tunnel VPN tra le differenti network.

 

Attuali costrizioni del Global VNet peering

Attualmente ci sono alcune costrizioni che è opportuno tenere in considerazione quando si effettua un Global VNet peering:

  • In presenza di un Global VNet peering non è possibile utilizzare i gateway remoti (opzione “use remote gateways”) oppure consentire il transito del gateway (opzione “allow gateway transit”) sulle virtual network. Queste opzioni sono attualmente utilizzabili solo quando si effettua un peering di virtual network che risiedono nella stessa region di Azure. Ne consegue quindi che i Global VNet peering non sono transitivi, quindi le VNet di downstream in una region non possono dialogare, utilizzando questa metodologia, con le VNet in un’altra region. Ad esempio, ipotizzando uno scenario dove tra la vNet1 e la vNet2 è presente un Global VNet peering e tra la vNet2 e la vNet3 è presente un altro Global VNet peering. In questo caso non ci sarà comunicazione tra la vNet1 e la vNet3. Se si ha la necessità, è possibile creare un ulteriore Global vNet peering per metterle in comunicazione.
  • Per una risorsa che risiede su una virtual network, non è consentito comunicare utilizzando l’indirizzo IP di un Azure internal load balancer che risiede sulla virtual network in peer. Questo tipo di comunicazione è consentita solo se il source IP e l’indirizzo IP del Load Balancer sono nella stessa VNet.
  • Il Global VNet peering si può creare in tutte le Azure public regions, ma non con VNet che risiedono negli Azure national clouds.
  • La creazione del Global VNet peering è consentita anche tra VNet che risiedono in subscription differenti, purché siano associate allo stesso tenant di Active Directory.
  • Le virtual network possono essere messe in peering solo se non è presente overlapping nei relativi address space. Inoltre, in seguito alla creazione del peering, se si ha la necessità di modificare gli address space è necessario a priori rimuovere il peering.

 

Configurazione del Global VNet peering

La configurazione del Global VNet peering è estremamente semplice. Nelle immagini seguenti vengono documentati gli step per mettere in comunicazione due virtual network create in region differenti, nel caso specifico West Europe e Australia Southeast.

Figura 3 – Aggiunta del peering dalle impostazioni della VNet

Figura 4 – Configurazione dei parametri del peering

Selezionando l’opzione “Allow virtual network access”, viene consentita la comunicazione tra le due virtual network. Tale impostazione consente che l’address space della VNet in peer sia aggiunto al tag Virtual_Network.

Figura 5 – Peering aggiunto, in stato Initiated

Le stesse operazioni, documentate nella figura 3 e nella figura 4, è necessario ripeterle anche sulla Virtual Network che risiede nell’altra region e con la quale si vuole configurare il Global VNet peering. La comunicazione sarà attivata nel momento in cui lo stato del peering sarà “Connected” su entrambe le VNet.

Figura 6 – Peering in stato Connected

Selezionando una macchina virtuale, attestata su una virtual network con configurato il global vNet Peering, si vedrà una rotta specifica per la VNet associata, come mostrato nella figura seguente:

Figura 7 – Effective route della VNet in Global Peering

Il Global VNet peering prevede dei costi per il traffico di rete in ingresso e in uscita che transitano dal peering e il costo varia a seconda delle zone contemplate. Per maggiori dettagli è possibile fare riferimento alla pagina ufficiale dei costi.

 

Conclusioni

Il Global VNet peering consente di avere un’ottima flessibilità nel gestire in modo semplice ed efficace come i vari workload possono connettersi tra di loro, consentendo di espandere i possibili scenari di implementazione in Azure, senza dover considerare i confini geografici come un limite. Importanti benefici possono essere ottenuti in particolare in architetture di replica del dato e di disaster recovery.

Azure IaaS and Azure Stack: announcements and updates (September 2018 – Weeks: 36 and 37)

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

Virtual network service endpoints for Azure Key Vault

Virtual network service endpoints are generally available for Azure Key Vault in all public Azure regions.

 

Configure just-in-time virtual machine access from the VM blade

Just-in-time virtual machine access can now be configured from the virtual machine blade (in preview) to make it even easier for you to reduce your exposure to threats.

 

Filter VM sizes by current or previous generation

With a recent update to the virtual machine size picker, the default filter set will show current-generation virtual machine sizes only.

 

Announcing the Public Preview for Azure Active Directory Integration with Azure Files

Azure Files offers fully managed file shares in the cloud that are accessible via the industry standard SMB protocol. Integration with AAD enables SMB access to Azure file shares using AAD credentials from AAD DS domain joined Windows VMs.

 

 

Azure Stack

Managed Disks in Azure Stack

Azure Managed Disks simplifies disk management for Azure VMs by managing the storage accounts associated with the VM disks. You only have to specify the type (Premium or Standard) and the size of disk you need, and Azure creates and manages the disk for you. This work will bring more options and simplicity to Azure Stack users when working with VMs. This update applies primarily to Azure Stack users.

 

Ability to incrementally add capacity to Azure Stack

Azure Stack operators can now add a node to an existing Azure Stack scale unit within the supported scale unit limits. This enables Azure Stack operators to increase the capacity of a single Azure Stack, and specifics should be discussed with hardware partners.

 

Azure Stack support for Azure Backup

Azure Stack operators can now backup and recover guest OS, data disks, and volumes using Azure Backup. This new ability gives operators more options when developing a backup strategy for Azure Stack.

 

Azure Government cloud integration for Azure Stack

Azure Stack is now integrated with the Azure Government cloud, enabling connections to Azure Government identity, subscription, registration, billing, backup/DR, and Azure Marketplace. Azure Stack unlocks a wide range of hybrid cloud use cases for government customers, such as tactical edge and regulatory scenarios.

Azure Security Center: introduzione alla soluzione

Azure Security Center è una soluzione nel cloud che consente di prevenire, rilevare e rispondere alle minacce di sicurezza che interessano le risorse Azure e workloads in ambienti ibridi. In questo articolo vengono riportate le caratteristiche principali e le diverse funzionalità, per indirizzare casi di utilizzo e per comprendere le potenzialità dello strumento.

Funzionalità e caratteristiche principali di Azure Security Center

  • Gestisce delle policy di sicurezza in modo centralizzato. Garantisce la conformità rispetto ai requisiti di sicurezza che si intende imporre a livello aziendale e normativo. Il tutto viene gestito in modo centralizzato tramite delle policy di sicurezza che si potranno applicare ai differenti workloads.

Figura 1 – Policy & compliance Overview

Figura 2 – Policy management

  • Effettua un Security Assessment. In modo continuativo viene monitorata la situazione in termini di sicurezza di macchine, reti, storage e applicazioni, al fine di individuare potenziali problemi security.
  • Fornisce delle raccomandazioni che è possibile attuare. Vengono riportate delle indicazioni che è consigliato attuare per risolvere delle vulnerabilità di sicurezza che interessano il proprio ambiente, prima che queste possano essere sfruttate in potenziali attacchi informatici.

Figura 3 – Elenco raccomandazioni

  • Assegna delle priorità agli avvisi e ad eventuali incidenti di sicurezza. Grazie a questa prioritarizzazione è possibile focalizzarsi prima sulle minacce di sicurezza che possono impattare maggiormente sulla propria infrastruttura.

Figura 4 – Assegnazione severity per ogni segnalazione

Figura 5 – Assegnazione severity per ogni potenziale incident di security rilevato

  • Consente di configurare l’ambiente cloud per proteggerlo efficacemente. Viene messo a disposizione un metodo semplice, rapido e sicuro per consentire l’accesso just in time alle porte di gestione dei sistemi e alle applicazioni in esecuzione sulle VM, applicando controlli adattivi.

Figura 6 – Abilitazione Just in time VM access

  • Fornisce una soluzione di sicurezza completamente integrata. Consente di collezionare, ricercare e analizzare i dati di security provenienti da sorgenti differenti, comprendendo la possibilità di integrazione con soluzione di terze parti.

Figura 7 – Integrazioni con altre soluzioni di security

 

Costo della soluzione

Security Center viene offerto in due possibili tiers:

  • Free tier. In questo tier Azure Security Center è totalmente gratuito e fornisce visibilità sullo stato di sicurezza delle sole risorse che risiedono in Azure. Tra le funzionalità offerte troviamo: basic security policy, raccomandazioni di sicurezza e integrazione con i prodotti e i servizi di sicurezza di terze parti.
  • Standard tier. Rispetto al tier free aggiunge funzionalità avanzate di rilevamento delle minacce (tra cui threat intelligence), analisi comportamentale, rilevamento delle anomalie e di incidenti di sicurezza e report di attribuzione delle minacce. Lo standard tier estende la visibilità sulla security delle risorse che risiedono on-premises e a workloads ibridi. Attraverso tecniche di machine learning e avendo la possibilità di creare delle whitelist consente di bloccare malware e applicazioni non desiderate.

Figura 8 – Confronto di funzionalità tra i pricing tiers disponibili

 

Il tier Standard è possibile provarlo gratuitamente per 60 giorni dopodiché, se si desidera continuare ad utilizzare la soluzione, si ha un costo mensile per singolo nodo. Per maggiori informazioni sui costi della soluzione è possibile accedere alla pagina ufficiale dei costi.

Figura 9 – Schermata di upgrade al tier Standard

Per poter usufruire di tutte le funzionalità di Security Center è necessario applicare il tier Standard alla sottoscrizione o al gruppo di risorse contenente le macchine virtuali. La configurazione del tier Standard non abilita automaticamente tutte le funzionalità, ma alcune di queste richiedono configurazioni specifiche, come ad esempio VM just in time, i controlli adattivi delle applicazioni e la network detection per le risorse Azure.

 

Principi fondamentali di funzionamento

La raccolta dei dati di security dai sistemi, indipendentemente dalla loro locazione, avviene tramite il Microsoft Monitoring Agent, che ne provvede al relativo invio verso un workspace di Log Analytics. Security Center necessita quindi sempre di un workspace sul quale sarà abilitata la seguente solution in base al tier scelto:

  • Free tier: il Security Center abilita la solution SecurityCenterFree.
  • Standard tier: il Security Center abilita la solution Security. Se nel workspace è già installata la solution Security & Auditviene utilizzata quella e non viene installato nulla di aggiuntivo.

Per salvare i dati collezionati dal Security Center è possibile utilizzarne un workspace di Log Analytics creato di default oppure selezionarne uno specifico associato alla relativa subscription Azure.

Figura 10 – Configurazione del workspace di Log Analytics dove collezionare i dati raccolti

Conclusioni

Azure Security Center risulta una soluzione idonea, matura e strutturata per far fronte alle esigenze di sicurezza per ambienti cloud, on-premises oppure ibridi. Grazie alle diverse funzionalità contemplate mette a disposizione la conoscenza che Microsoft ha maturato nella gestione dei propri servizi, coniugandola con nuove e potenti tecnologie, come machine learning e big data, per trattare e gestire in modo consapevole ed efficace il tema della sicurezza.

Azure Site Recovery: la protezione di macchine Hyper-V tramite Windows Admin Center

Tra le varie funzionalità che è possibile gestire tramite Windows Admin Center, esiste la possibilità di pilotare in modo semplice la protezione di macchine virtuali, presenti in ambiente Hyper-V, con Azure Site Recovery (ASR). In questo articolo vengono riportati gli step necessari da seguire e le possibilità offerte dall’Admin Center in questo ambito.

Windows Admin Center, conosciuto in passato anche con il nome di Project Honolulu, consente tramite una console web, di gestire la propria infrastruttura in modo centralizzato. Grazie a questo strumento Microsoft ha avviato un processo di centralizzazione in un unico portale di tutte le console di amministrazione, consentendo di gestire e configurare la propria infrastruttura con una esperienza utente moderna, semplice, integrata e sicura.

Windows Admin Center non richiede nessuna dipendenza con il cloud per poter funzionare e può esserne fatto il deploy localmente per ottenere il controllo di diversi aspetti della propria infrastruttura server locale. Oltre al componente Web Server, che consente di accedere tramite browser allo strumento, il Windows Admin Center è costituito da un componente gateway, grazie al quale è possibile gestire i server tramite Remote PowerShell e WMI over WinRM.

Figura 1 – Schema di base dell’architettura di Windows Admin Center

 

Connessione del Windows Admin Center gateway ad Azure

Windows Admin Center offre anche la possibilità di integrarsi con diversi servizi di Azure, tra i quali Azure Site Recovery. Per poter consentire al Windows Admin Center gateway di comunicare con Azure è necessario procedere con il relativo processo di registrazione, seguendo gli step in seguito documentati. La procedura guidata, al momento disponibile nella versione in preview del Windows Admin Center, effettua la creazione di una Azure AD app nella propria directory, la quale consente la comunicazione del Windows Admin Center con Azure.

Figura 2 – Avvio del processo di registrazione dalle impostazioni dell’Admin Center

Figura 3 – Generazione del codice necessario per il login

Figura 4 – Inserimento del codice nella pagina di Device Login

Figura 5 – Avvio del processo di autenticazione di Azure

Figura 6 – Conferma di avvenuto Sign-in

Figura 7 – Selezione del Tenant dove registrare l’Azure AD app

Figura 8 – Indicazioni per fornire i permessi all’Azure AD app

Figura 9 – Assegnazione dei permessi, dal portale Azure, all’app registrata

Figura 10 – Configurazione dell’integrazione con Azure completata

 

Configurazione ambiente ASR per la protezione delle VMs Hyper-V

Dopo aver configurato la connessione del Windows Admin Center con Azure è possibile, selezionando il sistema Hyper-V che detiene le macchine virtuali da replicare verso Azure, procedere con l’intera configurazione del Recovery Services vault, direttamente dalla console web del Windows Admin Center. Gli step sotto riportati documentano la semplicità di attivazione.

Figura 11 – Avvio della configurazione necessaria per la protezione delle VMs

Dall’Admin Center vengono richieste le informazioni di base per la configurazione dell’ambiente di ASR e viene fornita la possibilità di creare un nuovo Recovery Service vault oppure di selezionarne uno esistente.

Figura 12 – Configurazione dell’host Hyper-V in Azure Site Recovery

Nel form proposto dal Windows Admin Center vengono proposti solamente alcuni valori, pertanto consiglio di procedere prima alla creazione del Recovery Service vault e, nella schermata precedente, di selezionarne uno esistente, creato con tutti i parametri di configurazione a piacimento e in base alle proprie esigenze.

Questo step effettua le seguenti azioni:

  • Installa l’agente di ASR sul sistema Hyper-V oppure su tutti i nodi nel caso di un ambiente cluster.
  • Se si seleziona di creare un nuovo vault procede alla relativa creazione nella region scelta e lo posiziona in un nuovo Resource Group (assegnandogli un nome di default).
  • Effettua la registrazione del sistema Hyper-V con ASR e configura una policy di replica di default.

Figura 13 – Site Recovery Jobs generati dalla configurazione

 

Configurazione della protezione delle macchine virtuali

Completate le attività di configurazione precedentemente riportate è possibile attivare la protezione delle macchine virtuali.

Figura 14 – Attivazione del processo di protezione della VM

Figura 15 – Selezione dello storage account e avvio della protezione

Al termine del processo di replica è possibile validare il processo di replica azionando la procedura di test failover dal portale Azure.

 

Conclusioni

Poter interagire con determinati servizi di Azure direttamente da Windows Admin Center può facilitare e velocizzare l’amministrazione del proprio datacenter ibrido. Al momento le possibilità offerte di integrazione con Azure Site Recovery sono minimali e idonee per scenari non complessi. Tuttavia, Windows Admin Center è in costante evoluzione e sarà sempre di più arricchito di nuove funzionalità per poter interagire al meglio anche con i servizi Azure.

OMS e System Center: novità di Agosto 2018

Nel mese di agosto sono state annunciate, da parte di Microsoft, un numero considerevole di novità riguardanti Operations Management Suite (OMS) e System Center. La nostra community rilascia mensilmente questo riepilogo che consente di 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 eventuali approfondimenti.

Operations Management Suite (OMS)

Azure Log Analytics

Come già annunciato nell’articolo La gestione di Log Analytics dal portale Azure Microsoft ha scelto di abbandonare il portale OMS, a favore del portale Azure. La data annunciata per il ritiro definitivo del portale OMS è il 15 gennaio 2019. Come conseguenza di questa scelta anche la creazione di nuovi workspace di Azure Log Analytics potrà essere effettuata solamente dal portale Azure. Tentando di creare un nuovo workspace dal vecchio portale OMS si verrà ridiretti al portale Azure per completare l’operazione. Non sono invece state apportate modifiche alle REST API e a PowerShell per la creazione dei workspace.

Anche il portale Advanced Analytics viene inglobato nel portale Azure. Al momento risulta possibile accedere a questo portale accedendo alla sezione Logs (preview) disponibile nel workspace di Log Analytics.

Figura 1 – Advanced Analytics disponibile nella sezione Logs (preview) dal portale Azure

 

Azure Automation

La gestione degli aggiornamenti tramite Azure Automation Update Management vede l’aggiunta di una nuova opzione per il deployment degli update. In fase di creazione o di modifica di un update deployment è ora presente l’opzione Reboot, che consente di controllare se e quando effettuare il riavvio dei sistemi. Per maggiori informazioni in merito è possibile consultare la documentazione tecnica ufficiale.

Figura 2 – Reboot option disponibile nell’update deployment

Nella funzionalità di Change Traking sono stati apportati i seguenti cambiamenti:

  • Per rilevare le modifiche ed effettuare l’inventory dei file in ambiente Windows è ora possibile utilizzare: ricorsione, wildcards, e variabili d’ambiente. In Linux è già presente da tempo il supporto per la ricorsione e i wildcards.
  • Per quanto riguarda le modifiche che avvengo nei file, sia in ambiente Windows che in ambiente Linux, è stata introdotta la possibilità di visualizzare il contenuto delle modifiche apportate.
  • Introdotta la possibilità di ridurre la frequenza con la quale vengono collezionati i servizi di Windows (la frequenza è espressa in secondi e va da un minimo di 10 secondi a un massimo di 30 minuti).

Agente

Questo mese la nuova versione dell’agente OMS per sistemi Linux risolve alcuni bug e introduce una versione aggiornata per diversi componenti core, che ne aumentano la stabilità, la sicurezza e migliorano il processo di installazione. Tra le varie novità viene introdotto il supporto per Ubuntu 18.04. Per ottenere la versione aggiornata dell’agente OMS è possibile accedere alla pagina ufficiale GitHub OMS Agent for Linux Patch v1.6.0-163. Nel caso l’agente OMS per sistemi Linux sia stato installato utilizzando l’Azure Extension e se è attivo il relativo update automatico, questo aggiornamento sarà installato in autonomia.

Figura 3 – Elenco Bug Fix e novità del nuovo agente OMS per Linux

 

Azure Site Recovery

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

  • Microsoft Azure Site Recovery Unified Setup/Mobility agent (versione 9.18.4946.1): utilizzato per scenari di replica da VMware verso Azure.
  • Microsoft Azure Site Recovery Provider (versione 5.1.3550.0): utilizzato per scenari di replica da Hyper-V verso Azure oppure verso un secondary site.
  • Microsoft Azure Recovery Services agent (versione 2.0.9125.0): utilizzato per scenari di replica da Hyper-V verso Azure.

L’installazione di questo update rollup è consigliata in deployments dove sono presenti i componenti e le rispettive versioni in seguito riportate:

  • Unified Setup/Mobility agent versione 9.14.0000.0 o successiva.
  • Site Recovery Provider (with System Center VMM): version 3.3.x.x o successiva.
  • Site Recovery Provider (for replication without VMM): version 5.1.3100.0 o successiva.
  • Site Recovery Hyper-V Provider: version 4.6.x.x o successiva.

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 4055712.

 

In Azure Site Recovery è stato introdotto il supporto per abilitare scenari di disaster recovery Cross-subscription, per macchine virtuali IaaS, purché appartenenti allo stesso tenant Azure Active Directory. Questa funzionalità è molto utile perché spesso si hanno ambienti che utilizzano subscription Azure differenti, create principalmente per avere avere un maggior controllo dei costi. Grazie a questo nuovo supporto si possono raggiungere più facilmente i requisiti di business continuity creando piani di disaster recovery senza alterare la topologia delle subscription del proprio ambiente Azure.

Figura 4 – Configurazione replica VM verso una subscription target differente

 

Azure Site Recovery ora può integrarsi con Veritas Backup Exec Instant Cloud Recovery (ICR) con la versione di Backup Exec 20.2. Utilizzando ICR, gli utenti di Backup Exec sono in grado di configurare la replica delle VMs on-premises verso Azure e di azionare facilmente il proprio paino di DR in caso di necessità, riducendo il Recovery Point Objective (RPO) e il Recovery Time Objective (RTO). Instant Cloud Recovery richiede la presenza di una subscription Azure e supporta macchine virtuali VMware ed Hyper-V. Per ulteriori dettagli e riferimenti è possibile consultare l’annuncio specifico.

Azure Backup

In questo interessante articolo viene riportata la procedura per monitorare tutti i workloads protetti da Azure Backup utilizzando Log Analytics.

System Center

System Center Configuration Manager

Rilasciata la versione 1806 per il Current Branch (CB) di System Center Configuration Manager che introduce nuove funzionalità e importanti miglioramenti nel prodotto.

Tra le principali novità di questo aggiornamento emerge la nuova funzionalità chiamata CMPivot. Si tratta di una nuova utility disponibile nella console di Configuration Manager in grado di fornire informazioni in tempo reale riguardanti i dispositivi connessi nel proprio ambiente. Su queste informazioni è possibile applicare dei filtri e dei raggruppamenti, per poi svolgere determinate azioni.

Figura 5 – Caratteristiche e benefici della funzionalità CMPivot

Per l’elenco completo delle nuove funzionalità introdotte in questa versione di Configuration Manager è possibile consultare l’annuncio ufficiale.

 

Rilasciata la versione 1808 per il branch Technical Preview di System Center Configuration Manager. Questo aggiornamento introduce la possibilità di effettuare un rilascio graduale dei software update in modo automatico. Il pulsante che consente di configurare questa operazione è riportato nella figura seguente e si trova nei nodi della console All Software Updates, All Windows 10 Updates, e Office 365 Updates.

Figura 6 – Pulsante di creazione del Phased Deployment

Per maggiori informazioni sulla configurazione dei Phased Deployments in Configuration Manager è possibile consultare la relativa documentazione tecnica Microsoft.

Vi ricordo 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

Rilasciata la versione aggiornata del Microsoft System Center 2016 Management Pack per Microsoft Azure (versione 1.5.20.18).

Si segnalano inoltre le seguenti novità:

 

Valutazione di OMS e System Center

Si ricorda che per testare e valutare in modo gratuito Operations Management Suite (OMS) è possibile accedere a questa pagina e selezionare la modalità che si ritiene più idonea per le proprie esigenze.

Per provare i vari componenti di System Center è necessario accedere all’Evaluation Center e dopo essersi registrati è possibile avviare il periodo di trial.

Azure Networking: introduzione al modello Hub-Spoke

Una topologia di rete sempre più adottata dai clienti che autilizzano Microsoft Azure è la topologia di rete definita Hub-Spoke. In questo articolo sono riportate le caratteristiche principali di questa architettura di rete, vengono esaminati i più comuni casi di utilizzo, e si evidenziano i principali vantaggi che si ottengono grazie a questa architettura.

La topologia Hub-Spoke

Nell’architettura di rete di tipologia Hub-Spoke, l’Hub è una rete virtuale in Azure che funge da punto di connettività verso la rete on-premises. Tale connettività può avvenire tramite VPN Site to site oppure tramite ExpressRoute. Gli Spoke sono le reti virtuali che eseguono il peering con l’Hub e possono essere usate per isolare i carichi di lavoro.

Questo uno schema di base dell’architettura:

Figura 1 – Architettura network Hub-Spoke di base

Questa architettura è pensata anche per posizionare nella rete di Hub una network virtual appliance (NVA) per controllare i flussi del traffico di rete in modo centralizzato.

Figura 2 – Possibile architettura della vNet di Hub in presenza di NVA

A questo proposito è opportuno evidenziare che Microsoft ha recentemente annunciato la disponibilità dell’Azure Firewall, un nuovo servizio gestito e totalmente integrato nel cloud pubblico di Microsoft, che consente di mettere in sicurezza le risorse presenti sulle Virtual Network di Azure. Al momento il servizio è in preview, ma presto sarà possibile valutare l’adozione dell’Azure Firewall per controllare in modo centralizzato, attraverso delle policy, i flussi di comunicazione di rete, il tutto in modo cross subscription e per differenti virtual network. Questo servizio, in presenza di architetture di rete di tipologia Hub-Spoke, si presta per essere posizionato nella rete di Hub, in modo da ottenere un controllo completo del traffico di rete.

Figura 3 – Posizionamento dell’Azure Firewall nella rete di Hub

Per maggiori dettagli sull’Azure Firewall è possibile consultare l’articolo Introduzione ad Azure Firewall.

Quando utilizzare la topolgia Hub-Spoke

L’architettura di rete Hub-Spoke è tipicamente utilizzata in scenari dove sono richieste queste caratteristiche in termini di connettività:

  • In presenza di workload deployati in ambienti differenti (sviluppo, test e produzione) i quali devono accedere ai servizi condivisi come ad esempio DNS, IDS, Active Directory Domain Services (AD DS). I servizi condivisi saranno posizionati nella virtual network di Hub, mentre i vari ambienti (sviluppo, test e produzione) saranno deployati nelle reti di Spoke per mantenere un elevato livello di isolamento.
  • Quando determinati workloads non devono comunicare con tutti gli altri workloads, ma solamente con i servizi condivisi.
  • In presenza di realtà che richiedono un elevato livello di controllo sugli aspetti legati alla sicurezza di rete e che necessitano di effettuare una segregazione del traffico di rete.

Figura 4 – Disegno dell’architettura Hub-Spoke con i relativi componenti

I vantaggi della topologia Hub-Spoke

I vantaggi di questa topologia di rete Azure possono essere così sintetizzati:

  • Risparmio sui costi, dati dal fatto che si possono centralizzare in un’unica posizione i servizi condivisi da più carichi di lavoro, come ad esempio i server DNS ed eventuali appliance virtuali. Si riducono inoltre i VPN Gateway necessari per fornire connettività verso l’ambiente on-premises, con un risparmi sui costi Azure.
  • Possibilità di separazione granulare dei compiti tra IT (SecOps, InfraOps) e workloads (DevOps).
  • Maggiore flessibilità in termine di gestione e sicurezza dell’ambiente Azure.

Riferimenti utili per approfondimenti

Si riportano i riferimenti alla documentazione tecnica Microsoft utili per indirizzare ulteriori approfondimenti su questa tematica:

Conclusioni

Uno dei primi aspetti da tenere in considerazione quando si decide di implementare soluzioni nel cloud è l’architettura di rete da adottare. Stabilire fin dall’inizio la topologia di rete più opportuna consente di avere una strategia vincente ed evita di trovarsi nella condizione di dover migrare in seguito dei workloads, per adottare architetture di rete differenti, con tutte le complicazioni che ne conseguono.

Ogni implementazione richiede una attenta analisi al fine di tenere in considerazione tutti gli aspetti e di effettuare le opportune valutazioni. Non è quindi possibile affermare che l’architettura di rete Hub-Spoke sia idonea per tutti gli scenari, ma introduce certamente diversi benefici che la rendono efficace per ottenere determinate caratteristiche ed avere un elevato livello di flessibilità.

OMS e System Center: novità di Luglio 2018

Microsoft annuncia in modo costante novità riguardanti Operations Management Suite (OMS) e System Center. Come di consueto la nostra community rilascia questo riepilogo mensile che consente di 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.

Operations Management Suite (OMS)

Azure Log Analytics

La possibile integrazione di Azure Data Factory (ADF) con Azure Monitor consente di inviare le metriche di utilizzo verso Operations Management Suite (OMS). La nuova solution Azure Data Factory Analytics, disponibile nell’Azure marketplace, può fornire una panoramica sullo stato di salute del proprio Data Factory, consentendo di andare nel dettaglio delle informazioni raccolte. Questo può risultare molto utile in particolare per operazioni di troubleshooting. Risulta inoltre possibile collezionare le metriche provenienti da diverse data factories verso lo stesso workspace di OMS Log Analytics. Per i dettagli sulla configurazione necessaria per utilizzare questa solution, è possibile consultare la documentazione ufficiale.

Figura 1 – Overview della nuova solution Azure Data Factory Analytics

Nell’esecuzione delle query di Log Analytics è stata introdotta la possibilità di selezionare facilmente il workspace sul quale eseguire le interrogazioni:

Figura 2 – Selezione del workspace su cui effettuare le query di Log Analytics

La stessa possibilità è stata introdotta anche in Azure Application Insights Analytics. Tale funzionalità risulta utile in quanto in ogni query tab è possibile selezionare il workspace specifico, evitando di dover aprire Log Analytics in tab differenti del browser.

Nel caso vengano collezionati custom logs in Azure Log Analytics, è stata creata una categoria separata denominata “Custom Logs”, dove vengono raggruppati.

Figura 3 – Raggruppamento dei custom logs nella categoria specifica

Per i workspace di Log Analytics presenti nelle region di West Europe, East US, e West Central è stata annunciata la disponibilità in public preview dei Metric Alerts per i logs. I Metric alerts per i logs consentono di utilizzare i dati provenienti da Log Analytics come metriche di Azure Monitor. La tipologia dei log supportati è stata estesa e la lista completa è disponibile a questo indirizzo. Per ulteriori informazioni in merito è possibile consultare la documentazione ufficiale.

Azure Backup

In Azure Pricing Calculator, lo strumento ufficiale Microsoft per stimare i costi dei servizi Azure, è stata introdotta la possibilità di ottenere una stima più accurata dei costi di Azure Backup, consentendo di specificare il range di retention dei vari Recovery Point.

Figura 4 – Nuovi parametri per effettuare una stima più accurata dei costi di Azure Backup

 

Azure Site Recovery

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

  • Microsoft Azure Site Recovery Unified Setup/Mobility agent (versione 9.17.4897.1): utilizzato per scenari di replica da VMware verso Azure.
  • Microsoft Azure Site Recovery Provider (versione 5.1.3400.0): utilizzato per scenari di replica da Hyper-V verso Azure oppure verso un secondary site.
  • Microsoft Azure Recovery Services agent (versione 2.0.9122.0): utilizzato per scenari di replica da Hyper-V verso Azure.

L’installazione di questo update rollup è consigliata in deployments dove sono presenti i componenti e le rispettive versioni in seguito riportate:

  • Unified Setup/Mobility agent versione 9.13.000.1 o successiva.
  • Site Recovery Provider versione 5.1.3000 o successiva.
  • Hyper-V Recovery Manager 3.4.486 o successiva.
  • Site Recovery Hyper-V Provider 4.6.660 o successiva.

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 4344054.

Azure Automation

Per quanto riguarda Azure Automation è stata introdotta la possibilità di configurare gli Hybrid Runbook Workers in modo che possano eseguire solamente runbook digitalmente firmati (l’esecuzione di runbook unsigned non andrà a buon fine). La procedura da seguire è riportata in questa sezione dell’articolo Microsoft.

System Center

In seguito al primo annuncio della Semi-Annual Channel release di System Center, avvenuto nel mese di febbraio con la versione 1801, questo mese è stata rilasciata la nuova update release, System Center 1807.

L’update release 1807 introduce nuove funzionalità per Virtual Machine Manager e Operations Manager, mentre per Data Protection Manager, Orchestrator e Service Manager contiene fix per problemi noti (includendo i bug fixes presenti nell’UR5 di System Center 2016, rilasciata in aprile).

Novità introdotte in Virtual Machine Manager 1807
  • Supports selection of CSV for placing a new VHD
  • Display of LLDP information for networking devices
  • Convert SET switch to logical switch
  • VMware host management: VMM 1807 supports VMware ESXi v6.5 servers in VMM fabric
  • Support for S2D cluster update
  • Support for SQL 2017
Novità introdotte in Operations Manager 1807
  • Configure APM component during agent install or repair
  • Linux log rotation
  • HTML5 Web console enhancements
  • Support for SQL Server 2017
  • Operations Manager and Service Manager console coexistence

Per maggiori informazioni a riguardo è possibile consultare la documentazione ufficiale Microsoft:

System Center 1807 è possibile scaricarlo dal System Center Evaluation Center.

Per tutti i prodotti System Center (DPM, SCORCH, SM, VMM e SCOM) è ora possibile aggiornare i deployment esistenti passando da SQL server 2016 a SQL server 2017.

Si ricorda infine che le release appartenenti al Semi-Annual Channel hanno un periodo di supporto di 18 mesi.

System Center Configuration Manager

Rilasciata la versione 1807 per il branch Technical Preview di System Center Configuration Manager. La novità principale presente in questo rilascio è l’introduzione del nuovo community hub, attraverso il quale è possibile condividere scripts, reports, configuration items ed altro, relativamente a Configuration Manager. Attraverso il community hub, accessibile dalla console di SCCM, è possibile introdurre nel proprio ambiente soluzioni messe a disposizione dalla community.

Tra le novità introdotte in questo rilascio troviamo inoltre:

  • Improvements to third-party software updates
  • Co-managed device activity sync from Intune
  • Approve application requests via email
  • Repair applications
  • Admin defined offline operating system image servicing drive
  • Improvements to run scripts

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

Per poter configurare la connessione tra Operations Management Suite (OMS) e System center Operations Manager è necessario importare i seguenti nuovi management packs, specifici per versione:

Questa modifica ai MPs è stata resa necessaria per consentire la corretta comunicazione con le nuove APIs di OMS Log Analytics, introdotte in seguito allo spostamento verso il portale Azure di Log Analytics.

Figura 5 – Wizard di SCOM per l’onboarding di OMS

Si riporta la nuova wave dei management packs di System Center Operations Manager rilasciati per SQL Server, ora allineati alla versione 7.0.7.0:

Nel mese di Luglio sono inoltre stati rilasciati i seguenti Management Packs per software Open Source, versione 7.7.1129.0, che comprendono le seguenti novità:

Apache HTTP Server

  • Supports Apache HTTP Server version 2.2 and 2.4
  • Provides monitoring of busy and idle workers
  • Provides monitoring of resource usage – memory and CPU
  • Provides statistics for virtual hosts such as “Requests per Minute” and “Errors per Minute”
  • Provides alerting for SSL Certificate expiration

MySQL Server

  • Supports MySQL Server version 5.0, 5.1, 5.5, 5.6, and 5.7
  • Supports MariaDB Server version 5.5, and 10.0
  • Provides monitoring of databases
  • Provides monitoring of disk space usage for server and databases
  • Provides statistics for Key Cache, Query Cache, and Table Cache
  • Provides alerting for slow queries, failed connections, and full table scans

Sono stati inoltre rilasciati da parte di Microsoft i seguenti nuovi MPs:

  • MP per Active Directory Federation Services versione 0.2.0
  • MP per Active Directory Federation Services 2012 R2 versione 1.10172.1
  • MP per Microsoft Azure versione 5.20.18

Si segnala inoltre la nuova versione community (1807) del Management Pack di Azure, rilasciata da Daniele Grandini.

Valutazione di OMS e System Center

Si ricorda che per testare e valutare in modo gratuito Operations Management Suite (OMS) è possibile accedere a questa pagina e selezionare la modalità che si ritiene più idonea per le proprie esigenze.

Per provare i vari componenti di System Center è possibile accedere all’Evaluation Center e dopo essersi registrati è possibile avviare il periodo di trial.

Introduzione ad Azure Firewall

Microsoft ha recentemente annunciato la disponibilità di un servizio da tempo atteso e richiesto da coloro che utilizzano sistemi in ambiente Azure, si tratta dell’Azure Firewall. L’Azure Firewall è un nuovo servizio gestito e totalmente integrato nel cloud pubblico di Microsoft, che consente di mettere in sicurezza le risorse presenti sulle Virtual Network di Azure. In questo articolo verranno esaminate le caratteristiche principali di questo nuovo servizio, attualmente in preview, e sarà riportata la procedura da seguire per la relativa attivazione e configurazione.

Figura 1 – Posizionamento dell’Azure Firewall nell’architettura di rete

L’Azure Firewall è un firewall 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. Questo servizio, in presenza di architetture di rete di tipologia hub-spoke, si presta per essere posizionato nella rete di Hub, in modo da ottenere un controllo completo del traffico.

Le funzionalità dell’Azure Firewall, attualmente disponibili in questa fase di public preview, sono le seguenti:

  • High availability (HA) Built-in: l’alta disponibilità è integrata nel servizio e non sono richieste configurazioni specifiche o componenti aggiuntivi per renderla effettiva. Questo è sicuramente un elemento che lo distingue rispetto a soluzioni di terze parti che, per la configurazione delle Network Virtual Appliance (NVA) in HA, richiedono tipicamente la configurazione di load balancer aggiuntivi.
  • Unrestricted cloud scalability: Azure Firewall consente di scalare facilmente per adeguarsi ad eventuali cambi dei flussi di rete.
  • FQDN filtering: si ha la possibilità di limitare il traffico in uscita HTTP/S verso una specifica lista di fully qualified domain names (FQDN), con la possibilità di utilizzare caratteri wild card nella creazione delle regole.
  • Network traffic filtering rules: si possono creare regole di allow oppure di deny per filtrare il traffico di rete sulla base dei seguenti elementi: indirizzo IP sorgente, indirizzo IP di destinazione, porte e protocolli.
  • Outbound SNAT support: all’Azure Firewall viene assegnato un indirizzo IP Pubblico statico, il quale sarà utilizzato dal traffico in uscita (Source Network Address Translation), generato dalle risorse della virtual nertwork di Azure, consentendone una facile identificazione dalle destinazioni internet remote.
  • Azure Monitor logging: tutti gli eventi dell’Azure Firewall possono essere integrati in Azure Monitor. Nelle impostazioni della diagnostica è consentito abilitare l’archiviazione dei log in uno storage account, effettuare lo stream verso un Event Hub, oppure impostare l’invio verso un workspace di OMS Log Analytics.

Azure Firewall si trova al momento in una preview pubblica gestita, il che significa che per implementarlo è necessario effettuare in modo esplicito l’abilitazione tramite il comando PowerShell Register-AzureRmProviderFeature.

Figura 02 – Comandi PowerShell per l’abilitazione della public preview dell’Azure Firewall

La registrazione della feature può richiedere fino a 30 minuti ed è possibile monitorare lo stato di registrazione con i seguenti comandi PowerShell:

Figura 03 – Comandi PowerShell per verificare lo stato di abilitazione dell’Azure Firewall

Al termine della registrazione è necessario eseguire il seguente comando PowerShell:

Figura 04 – Comando di registrazione del Network Provider

Per effettuare il deployment dell’Azure Firewall su una determinata Virtual Network è necessaria la presenza di una subnet denominata AzureFirewallSubnet, che deve essere configurata con una sunbnet mask almeno /25.

Figura 05 – Creazione della subnet AzureFirewallSubnet

Per effettuare il deployment dell’Azure Firewall dal portale Azure è necessario selezionare Create a resource, Networking e successivamente See all:

Figura 06 – Ricerca dell’Azure Firewall nelle risorse Azure

Filtrando per Firewall comparirà anche la nuova risorsa Azure Firewall:

Figura 07 – Selezione della risorsa Microsoft Firewall

Avviando il processo di creazione comparirà la seguente schermata che richiede l’inserimento dei parametri necessari per effettuare il deployment:

Figura 08 – Inserimento dei parametri necessari per il deployment del Firewall

Figura 09 – Review dei parametri selezionati e conferma di creazione

Per fare in modo di far confluire il traffico in uscita di una determinata subnet verso il firewall è necessario creare una route table contenente una rotta con le seguenti caratteristiche:

Figura 10 – Creazione della regola di inoltro del traffico verso il servizio Firewall

Nonostante Azure Firewall sia un managed service è necessario specificare Virtual appliance come next hop. L’indirizzo del next hop sarà l’IP privato dell’Azure Firewall.

La route table sarà da associare alla virtual network che si desidera controllare tramite Azure Firewall.

Figura 11 – Associazione della route table alla subnet

A questo punto, per i sistemi attestati sulla subnet che inoltra il traffico verso il Firewall, non sarà consentito il traffico in uscita, fintanto che non verrà esplicitamente abilitato:

Figura 12 – Tentativo di accesso al sito web bloccato dall’Azure Firewall

Azure Firewall mette a disposizione le seguenti tipologie di regole per controllare il traffico in uscita.

Figura 13 – Tipologie di regole disponibili

  • Application rules: consentono di configurare l’accesso a determinati fully qualified domain names (FQDNs) da una determinata subnet.

 

Figura 14 – Creazione Application rule per consentire l’accesso ad un sito web specifico

  • Network rules: permettono la configurazione di regole che contengono l’indirizzo sorgente, il protocollo, l’indirizzo e la porta di destinazione.

Figura 15 – Creazione Network rule per consentire il traffico sulla porta 53 (DNS) verso uno specifico DNS Server

Conclusioni

Poter disporre di un firewall completamente integrato nella fabric di Azure è sicuramente un vantaggio importante che consente di arricchire le funzionalità offerte in modo nativo da Azure. Al momento sono configurabili operazioni di base, ma il set di funzionalità è sicuramente destinato ad arricchirsi in tempi brevi. Si ricorda che al momento si tratta di un servizio in preview, e come tale non viene garantito nessun service level agreement e non è consigliato utilizzarlo in ambienti di produzione.