Microsoft Azure enables you to create different workloads and host them in the cloud. These workloads are virtual machines, databases, NSG, load balancers, and many others. They are stored within resource groups (logical boundaries). Ingress and egress traffic is something that is continuously cycling, and they need to be properly protected.

Microsoft does everything it can to protect cloud workloads against malicious security activities. They provide us with controls such as ACLs and network security services such as DDoS protection, NSG (Network Security Groups), WAP (Web Application Firewall), and Azure Firewall. All these security controls had their own dashboard to visualize the existing security statuses.

That is the exact challenge many IT professionals are facing. Several security controls are visualized in several different dashboards. This was not convenient. IT administrators needed a single user interface (UI) that visualizes everything in one place, so Microsoft released Azure Security Center.

Azure Security Center and Azure Defender are now called Microsoft Defender for Cloud. Microsoft also renamed Azure Defender plans to Microsoft Defender plans. You can learn more about affected renaming on this Protect your business with Microsoft Security’s comprehensive protection.

What does Microsoft Defender for Cloud Include?

It covers three parts: continuously assess, secure, and defend. Continuous assessment helps you understand your security posture, Secure to harden connected resources and services and Defend to detect and resolve threats to cloud workloads.

Defender for Cloud fills three vital needs

Microsoft Defender for Cloud protects Azure native services, hybrid, and multi-cloud protection. That includes protection for Azure PaaS (Azure App Services, Azure SQL, Azure Storage Accounts, Azure activity log, and many more), Azure data services (automatically classify your data in Azure SQL), and Networks (protection against brute force attacks).

That is not all. You can extend protection from the cloud to on-premises workloads. In order to do it, you will need to deploy Azure Arc.

How to Deploy a Workbook

As Microsoft Defender for Cloud is a native Azure service, the installation does not take long. Firstly, you need a subscription to Microsoft Azure, if you don’t have it, you can get a trial subscription.

What are the minimal permissions to load the workbook? Azure requires read permissions on the subscription from which you want to read data from.

Secondly, you need to know that the free Microsoft Defender plan is already enabled on all your Azure subscriptions. If you want to extend it to more advanced protection that includes more features, you must enable it. There is a 30 days trial that comes at no cost.

Microsoft Defender for Cloud plans

Microsoft provides you with a pricing calculator to estimate how much does it cost to protect your multi-cloud and hybrid environments with Defender for Cloud. You can access it here Microsoft Defender for Cloud pricing.

The deployment procedure of the workbook itself is quite straightforward, and it takes up to a minute. You can install one of two options and deploy the workbook either to the commercial or the Azure government cloud. You can click directly on one of the buttons below to make an installation or navigate to Network Security Dashboard for Microsoft Defender for Cloud Github repository.

Once you choose the deployment option, you need to specify the subscription, resource group, region, and workgroup name, type, source ID, and ID. You will also need to agree to the terms of service to create the resource successfully.

Create Azure workbook

Once you deploy it, open Microsoft Defender for Cloud (search for it) and navigate to Workbook on the left side within the Azure device tree. That will open the workbooks you have. You can open the one you created by clicking on Recently modified workbooks. In my case, that is “Network Security Dashboard” for resource group “prod-infra-EU.”

Choose your workbook

What does the Microsoft Defender for Cloud cover?

Upon activation, Microsoft Defender for Cloud will be enabled for resources within your resource group including servers, app service, SQL, MySQL, MariaDB, storage, containers, Kubernetes, ARM, DNS, Key Vault, and others.

Some of the Azure resources covered by Microsoft Defender for Cloud

The new dashboard provides a unified view of your Azure subscription’s network configuration and security. It is based on Azure Resource Graphs (ARG) queries. Using these queries Azure can retrieve real-time metrics and visualize them accordingly. The workbook comes predefined, but you can customize it based on your needs.

Microsoft: The Network Security Dashboard is free to use for all customers and does not require you to be a paid customer of Defender for Cloud.

Once you open it will provide you with several tabs and options including an Overview, Public IPs & Exposed Ports, Network Security Services, Internal Networking, Gateway/VPN services, Traffic Manager, Security Recommendations. All these options include several sub-options which you can see if you navigate to a certain tab.

Network Security Dashboard for Microsoft Defender for Cloud

You can also contribute to the community with your customized queries. If you want to learn more please check Azure Workbooks for Microsoft Defender for Cloud.

Does Microsoft plan any enhancements?

According to Microsoft, Application Security Group (ASG) and Outbound rules on Azure Firewall will be added in the future.

Did you know that Altaro Backup supports backing up virtual machines from your Hyper-V or VMware to Azure storage? Indeed, it does. Firstly, you need to create an Azure storage account within your Azure resource group. After that, by using the Altaro VM Backup console, you need to create and configure offsite copies from on-premise to Azure cloud storage.

Here is quite an interesting real-world scenario: Altaro VM backup backs up virtual machines to the onsite location to Synology and offsite backup to Azure Cloud storage. You can read more details on how to do it in this article: Backup Hyper-V VMs to Synology and Azure Cloud Storage.

Conclusion

This free workbook we’ve covered is a handy way to visualize your security posture in a single pane of glass. I hope you enjoyed reading this article. Feel free to connect with me and check out the latest content on my blog TechwithJasmin.com.

The post Quick Guide to Microsoft Defender for Cloud Security Workbooks appeared first on Altaro DOJO | Hyper-V.

One of the security features IT Pros were missing in the first three versions of Hyper-V Server was securing virtual machines against potential host compromise. The idea behind this feature request was to protect virtual machines from malicious Hyper-V Admins and malware attacks in both public and private clouds. In simple language, if someone could export or copy your VHD disk and try to access it offline in Disk Management or run it on a non-genuine Hyper-V host, the new security feature shouldn’t allow it.

Microsoft accepted this challenge and implemented this security feature request in Windows Server 2016 / Hyper-V Server 2016. It is known as a Shielded Virtual machine. In this article, we will explain what a shielded VM looks like, and how and when to use them. Let’s get into it!

Malicious Hyper-V Admin exported and attached VHD to Disk Management. All data are fully accessible to perform brute-force attacks on user accounts on the Active Directory server.

Today in Windows Server 2019 and Windows Server 2022, it still exists and you can use it to protect the integrity of your virtual machines and hosted data and services (e.g. AD, SQL, File Server, DNS, etc). This article is about shielded virtual machines, installation requirements, and improvements in Windows Server 2019 and Windows Server 2022.

What is a Shielded Virtual Machine?

A shielded virtual machine is a generation 2 VM (Hyper-V supports generation 1 and generation 2 VMs), it has a virtual TPM (Trusted Platform Module), is encrypted with BitLocker (AES 256 encryption) and it can run only on healthy and trusted Hyper-V Server/s. If you protect your VMs using guarded fabric, malicious Hyper-V Admins will not be able to access the data residing within the virtual machine. That is a layer of security that doesn’t come natively with regular VMs.

Malicious Hyper-V admin is not able to power shielded virtual machine on untrusted Hyper-V host

Infrastructure Requirements for Shielded VMs

The shielded virtual machines are dependent and work together with two other components, Host Guardian Service (HGS) which is typically a cluster of three nodes, and one or more guarded hosts. Each host and each shielded virtual machine that is created on guarded fabric is protected by Host Guardian Service. In addition to that, guarded fabrics consist of four components including code integrity (measure if there are any changes in the code, e.g. malware injection), virtual secure mode (isolated user mode where keys are kept away from the malware), TPM (physical and synthetic protection), and Host Guardian Service.

The HGS protects hosts and shielded virtual machines by providing two services, attestation service, and key protection service. The task of the attestation service is to ensure that only trusted and genuine Hyper-V hosts can run shielded virtual machines and the Key Protection service takes care of providing necessary keys to power virtual machines on and to perform live migration to other guarded hosts. The diagram below explains it.

Source: Guarded fabric and shielded VMs overview

What Windows Server Editions Support Shielded Virtual Machines?

In order to deploy shielded virtual machines, you must be running Windows Server 2019 Datacenter or Windows Server 2022 Datacenter. Windows Server 2019 and 2022 Standard edition supports Hyper-V Server and creating regular virtual machines, but it does not support creating shielded virtual machines.

The guest operating system should be running Windows Server 2012, Windows 8 and later, or Linux (as of Windows Server 2019).

Shielded VM Improvements in Windows Server 2019 and Windows Server 2022

There are a few improvements in Windows Server 2019 and Hyper-V 2019 compared to the previous version. However, there are no changes in Windows Server 2022 since Microsoft focuses on Azure Stack HCI. Microsoft will continue to provide support for shielded virtual machines in Windows Server 2022, but there are no further developments. On the client version of Windows RSAT (Remote Server Administration Tools), the shielded VM tools feature will be removed.

So, what’s new in a Windows Server 2019/Hyper-V Server 2019 that is also available in Windows Server 2022/Hyper-V 2022 Windows role?

First. Microsoft stopped developing Host Guardian Service Active Directory attestation mode and created a new, simpler attestation mode called Host Key Attestation. The host key attestation provides equivalent functionality and is not dependent on TPM 2.0 devices. It uses key pairs to authenticate hosts with HGS, and the hosts are no longer dependent on Active Directory. Windows Server 2019 supports the V2 Attestation Version. This means that a fresh install of HGS on Windows Server 2019 will use the v2 attestation. If you do an in-place upgrade from Windows Server 2016 to Windows Server 2019, you will need to manually enable the v2 attestation version on your Windows Server 2019.

Second. It now supports creating Linux shielded virtual machines. However, please keep in mind that Microsoft doesn’t support each Linux distribution, but Ubuntu 16.04 LTS with the 4.4 kernel and later, Red Hat Enterprise Linux 7.3 and later, and SUSE Linux Enterprise Server 12 Service Pack 2 and later.

Third. You can run shielded-protected virtual machines in offline mode even if HGS is not reachable. This is not configured by default, and you need to enable it by running the following command on all HGS hosts.

Set-HgsKeyProtectionConfiguration – AllowKeyMaterialCaching

Fourth. Microsoft also implemented the option to easily integrate a backup for the HGS URL. If the primary HGS server goes down, the Hyper-V protected hosts provide shielded VM with no downtime. You need to execute the following command on your HGS hosts. You should replace https://HGS.Primary.com and https://HGS.Backup.com with their own domain names and protocols.

Set-HgsClientConfiguration-KeyProtectionServerUrl ‘ https://HGS.Primary.com/KeyProtection ‘-AttestationServerUrl ‘ https://HGS.Primary.com/Attestation ‘-FallbackKeyProtectionServerUrl ‘ https://HGS.Backup.com/KeyProtection ‘- FallbackAttestationServerUrl “https://HGS.Backup.com/Attestation”

Fifth. Use TPM and bind shielded virtual machine to specific Hyper-V host. This is mostly used for the privileged access machines and branch offices.

Sixth. You can use now VMConnect Enhanced Session Mode and PowerShell Direct to troubleshoot if you lost connection to shielded virtual machines.

How do I Deploy Shielded Virtual Machines in my Network?

We already covered shielded virtual machines in Hyper-V Server 2016 on standalone hosts. The procedure is equally applicable to Windows Server 2019 and Windows Server 2022.

Microsoft classifies the deployment steps into four parts, which includes planning, deployment, management, and troubleshooting.

Planning. Two critical factors are mandatory to have a successfully guarded environment. The first one is about hosters and the second one is about tenants. You need to plan the strength of trust (TPM and Host key attestation) that you want to achieve in your guarded fabric.

Deployment. Before you can create a shielded virtual machine, you need to create a guarded fabric. The procedure consists of 15 steps from verifying HGS prerequisites, configuring the clustered HGS nodes to creating a shielded virtual machine. The complete installation procedure is documented here.

Management. This part consists of creating and assigning the proper access permissions and roles to HGS. HGS ships with Just Enough Administration (JEA) roles that let you assign delegated permissions.

Troubleshooting. The usual question is, what if something goes wrong? You might experience different problems in your enterprise environments, from HGS certification issues, permissions level problems, attestation failures, and others. Microsoft developed a tool called Guarded Fabric Diagnostic Tool. It can identify and remediate common failures within the guarded fabric infrastructure, including HGS, guarded hosts, and services such as Active Directory and DNS. In addition to that, you can also analyze event log files. This diagnostic tool is helpful, but it is not a replacement for strong monitoring and incident response platform, which we recommend you use.

How Can You Manage Shielded Virtual Machines?

You can use System Center Virtual Machine Manager (VMM) to deploy shielded virtual machines in a couple of ways. One is to convert an existing virtual machine into a shielded virtual machine, and the second way is to create a new virtual machine as a shielded virtual machine. Here is a nice video that shows the procedure of creating shielded VM using VMM.

You can also use Hyper-V Manager to create and configure shielded virtual machines. Other than connecting to your Windows Server > Hyper-V Manager, you can also install Hyper-V client on your Windows 10 and Windows 11 and do your work from there.

Virtual Machines Backup and Restore Strategy

That is where Altaro Software comes into play. Altaro provides you with the backup of your workloads hosted on virtual machines on Hyper-V Server 2019 and 2022 (older versions are also supported). You can backup your virtual machines to onsite and offline on-premise and cloud locations. Altaro supports augmented inline deduplication which dramatically reduces storage requirements for your backup repository by creating the smallest backup size. Run your free trial today!

Other relevant articles/pages worth sharing:

Hyper-V 2016 Shielded Virtual Machines on Stand-Alone Hosts

Virtualized Domain Controllers: 4 Myths and 12 Best Practices

Hyper-V Infrastructure & Troubleshooting – a comprehensive forum resource for common Hyper-V problems

I hope you enjoyed reading this article. I welcome you to visit my own blog TechwithJasmin.com, and I’m looking forward to connecting with you via LinkedIn.

Note: To be able to create this article, I run my workloads on a powerful mini PC – Intel NUC powered with the CPU i7, the latest generation, 64 GB RAM DDR4, 256 M.2 SSD. Intel® NUC Mini PCs are fully complete and ready to work out of the box. You can learn more here Intel® NUC Products.

The post Should all my Virtual Machines be Shielded VMs? appeared first on Altaro DOJO | Hyper-V.

Each release of the Windows Server operating system represents a milestone of new technologies, capabilities, and features that help organizations solve the present technology challenges facing businesses. Windows Server 2022 is a milestone release of Windows Server. It combines powerful features across the board to allow companies to implement both on-premises technologies and easily extend their infrastructure with a hybrid configuration, with resources housed in Azure.

Arguably, one of the most critical challenges facing most businesses today is security. Windows Server 2022 represents the most advanced Windows Server operating system in terms of security features and advancements. This overview will look at the Windows Server 2022 security features and enhancements that help advance your organization’s security to the next level.

Overview of Windows Server 2022 Security Features

There are many great new Windows Server 2022 security features to note. Windows Server 2022 introduces new concepts and features, building on previous improvements with Windows Server 2019 hybrid features and security innovations. Note the following overview of new security features:

1. 1. Secured-core server
   2. Simplified configuration tools
   3. Secure connectivity
   4. Hybrid management tools
   5. Windows Server 2022 Azure Edition hotpatching

Let’s examine each of these enhancements with Windows Server 2022 and see how they bring security features forward to help meet the current threat landscape and help businesses seamlessly control and secure both on-premises and cloud resources.

Secured-core server

Microsoft first started the secured-core offering to the world of PC. However, with the apparent benefits from the client-side, this technology has been brought to Windows Server. So what is the Secured-Core technology now included in Windows Server 2022?

Secured-Core security technology is built upon three different pillars that Microsoft uses to make up the Secured-Core platform. These include:

• • Simplified security

• • Advanced protection

• • Preventative defense

What does Secured-Core mean from the Windows Server 2022 perspective?

Simplified Security

MICROSOFT requires certain OEM specifications and capabilities for validation as a Secured-Core offering. What does this include? It includes a validated set of hardware, firmware, and drivers that satisfy the security requirements. Therefore, when organizations purchase a Windows Server 2022 server certified as a Secured-Core offering, they can be confident it is certified using the standards outlined by Microsoft regarding the included components and software.

Advanced protection

Modern threats include very advanced attack techniques. Secured-Core includes advanced protection that is made up of both hardware and software solutions to counterattack these threats. These include:

• • Hardware Trusted Platform Module 2.0 – provides a secure hardware store for storing sensitive information such as cryptographic keys and data. It also holds a “fingerprint” of sorts for the boot components. If the fingerprint of the boot components changes, it can identify if this is tampering. It also bolsters the protection provided by BitLocker.

• • Protected Firmware – Firmware has become increasingly vulnerable to malware and ransomware. Secured-Core provides capabilities such as Dynamic Root of Trust of Measurement technology (DRTM) and DMA protection

• • Virtualization-based Security (VBS) – Secured-Core supports the implementation of VBS and hypervisor-assisted code integrity checks (HVCI). Using VBS, customers can also use new technologies such as Credential Guard, which helps protect against stolen credentials.

Preventative defense

Today’s security solutions must be proactive and not reactive to stay ahead of modern threats and techniques used by hackers. The capabilities provided by the Secured-Core offering in Windows Server 2022 dramatically increase the tools IT admins and SecOps have to defend against the modern threat landscape.

Windows Server Secured-Core checks scan for the following specific features enabled with a fully implemented Secured-Core deployment in Windows Server 2022. If you use Windows Admin Center to view Secured-Core components (as we will see below), it shows the following checks in Secured-Core deployment:

• • HVCI

• • Boot DMA Protection

• • System Guard

• • Secure Boot

• • VBS

• • TPM 2.0

Let’s consider these in more detail.

HVCI

Hypervisor Enforced Code Integrity (HVCI) works in tandem with Virtualization Based Security (VBS) to protect Windows Server and client operating systems from drivers that are bad, malicious, or otherwise insecure as well as malicious system files. Specifically, it helps prevent tampering with Control Flow Guard (CFG) and ensures valid certificates for security-related processes such as Credential Guard.

Boot DMA Protection

Boot DMA Protection helps to protect Windows Server and client operating systems from drive-by Direct-Memory Access attacks. These attacks can occur using PCI hotplug devices connected to externally accessible PCIe ports and internal PCIe ports.

A successful drive-by DMA attack can lead to sensitive information being disclosed or even malware injection leading to bypassing the lock screen or remote controlling the node. With the Boot DMA Protection enabled, Windows can block external peripherals from staring and performing DMA unless the drivers support memory isolation.

System Guard

System Guard is part of the Microsoft Windows Defender solution. As the name implies, System Guard guards the system and maintains the integrity of the system during the boot process. In addition, it works to validate that system integrity has not changed through local and remote attestation.

System Guard helps to defend end-user PCs against the types of rootkits and bootkits that commonly affected Windows 7 systems. With Windows 7, malicious software could start before Windows starts, which allowed it to run with the highest privileges. With modern hardware and operating systems such as Windows Server 2022, System Guard protects against these kinds of bootkits and prevents any unauthorized firmware or software from launching before the Windows bootloader.

Windows Defender System Guard Overview

Secure Boot

Secure Boot is not a Microsoft solution or technology. Instead, the PC industry developed it to help make sure a device boots with software validated and trusted by the OEM hardware vendor. By checking each boot software signature, including UEFI firmware drivers, Secure Boot makes sure the signatures are valid and authorized. It helps to validate the software has not been tampered with by an attacker.

Virtualization-based Security (VBS)

As part of the Secured-Core components, Windows Server 2022 contains Virtualization-based Security (VBS). With Virtualization-based Security (VBS), hardware virtualization is used to create a specialized secure region of memory isolated from the operating system. Windows can access the secure virtual mode for security-related tasks. It includes increasing OS protection from vulnerabilities and preventing malicious code that attempts to defeat protective mechanisms.

As mentioned earlier, HVCI makes use of VBS to strengthen code integrity enforcement. VBS makes use of the Windows Hyper-V hypervisor for the virtual secure mode used to enforce restrictions to protect crucial system and OS resources. An example includes authenticated user credentials by way of the Credential Guard solution that makes use of VBS.

TPM 2.0

The Trusted Platform Module is a hardware technology designed for security-related functions. The TPM chip contains a crypto-processor that allows generating, storing, and limiting the use of cryptographic keys. These generally include features that help to ensure it is tamper-resistant so that malicious software cannot tamper with the security-enabled functions of the TPM chip. TPM 2.0 contains many new hash algorithms and security features compared to the TPM 1.2 standard. Windows Server 2022 can take full advantage of the features and capabilities found in the TPM 2.0 module.

Simplified Configuration Tools

Microsoft has been feverishly working on a new tool since Windows Server 2019 for server configuration and management. This new tool is Windows Admin Center which is the new way forward for managing Microsoft Windows Server. It replaces the old Server Management console, even though the Server Management tool is still in Windows Server 2022.

A tough challenge with security is ensuring that configurations are implemented correctly and consistently. When configuration tooling is challenging to use or includes many different tools and dashboards required to implement various configuration parts, it can lead to implementation gaps. Any gap in security or insecure configuration leading to vulnerabilities is a serious issue.

Windows Admin Center provides a single-pane-of-glass interface that businesses can use to implement Windows Server configurations across the board, including the Security dashboard. This capability has been missing in legacy tools, and consoles such as Server Manager found in Windows Server 2019. In addition, the new Windows Admin Center compliments the implementation of Secured-Core security configurations by giving visibility to this in the Windows Admin Center UI.

As a note, the Secured-Core dashboard in Windows Server 2022 is still in Preview release at the time of this writing. To access the Secured-Core functionality in Windows Admin Center, you need to enable the Insider Preview “feed” in Windows Admin Center. To add the Insiders Preview feed so you can get the latest Insider Preview extensions available in Windows Admin Center, navigate to Settings using the settings cog in the upper right-hand corner. Click the Extensions > Feeds tab. Navigate to the Add button and click. Enter the feed URL: https://aka.ms/wac-insiders-feed

Adding the Insider Preview feed for Windows Admin Center

After adding the Insider Preview feed in Windows Admin Center, you will see a new, higher versioned, Security extension. At the time of writing, the version installed was 0.23.0.

Installing the Insider Preview Security Extension

After installing the Insider Preview Security extension, IT admins will have access to a new tab that displays on the Security dashboard, called Secured-Core.

It provides strong visual cues on which features are enabled or not configured or supported.

Viewing Secured-Core configuration using Windows Admin Center

Microsoft has built-in the capability to enable and disable the Secured-Core features from the Windows Admin Center dashboard. This feature makes controlling the Secured-Core features easy to configure and audit. Notice below. The HVCI feature has been enabled from the Windows Admin Center dashboard. The Windows Server 2022 server is now prompting a reboot.

Enabling and Disabling Secured-Core features from Windows Admin Center

The Security dashboard also gives visibility to and allows configuration of the Virus & threat protection configuration and scans leveraging Windows Defender. You can also view Protection history for events and default actions.

Configuring Virus & threat protection with Windows Admin Center

Secure Connectivity

An area that has been dramatically improved with Windows Server 2022 is secure connectivity. What improvements have been made in terms of connectivity with Windows Server 2022? Let’s consider the following:

• • Secure protocols by default

• • Secure DNS

• • Server Message Block (SMB) improvements

Secure protocols by default

When it comes to connectivity protocols, some protocols are more secure than others. Therefore, when hardening for security, insecure protocols need to be disabled, and businesses must make sure they are using the latest and most secure protocols for network transmissions.

Windows Server 2022 takes the heavy lifting out of this effort. It contains the most secure version of HTTPS enabled by default, TSL 1.3. It helps protect clients’ data connecting to the server and eliminates obsolete and insecure cryptographic algorithms. In addition, Windows Server 2022, using the latest standards, encrypts as much of the handshake as possible.

Secure DNS

Windows Server 2022 improves DNS security by implementing what is known as DNS-over-HTTPS (DoH). DNS-over-HTTPS encrypts DNS queries made over the HTTPS protocol. It dramatically enhances DNS security by keeping DNS queries private. In addition, it helps to prevent malicious eavesdropping of traffic and DNS data manipulation.

Server Message Block (SMB) improvements

Server Message Block (SMB) is at the heart of Windows Server file copies. Windows Server 2022 provides the latest and most significant improvements to the SMB protocol. Windows Server 2022 now supports encrypting SMB traffic with the latest cryptographic suites, including AES-256-GCM and AES-256-CCM. In addition, Windows Server 2022 will automatically negotiate the highest possible encryption suite when clients support the higher level of encrypted communications. These settings can also be configured using Group Policy.

Another interesting security improvement with SMB encryption is SMB East-West encryption of storage communications for Cluster Shared Volumes (CSVs). Using Storage Spaces Direct (S2D), you can encrypt or sign east-west intra-cluster communications for security purposes.

A new feature is SMB over QUIC, an enhancement of SMB 3.1.1 in Windows Server 2022 Datacenter: Azure Edition. It allows using the QUIC protocol instead of TCP. In addition, using SMB over QUIC with TLS 1.3 eliminates the need for VPN to access file servers over SMB when using Windows.

Hybrid Management Tools

Microsoft has built a solid set of hybrid features into the Windows Server platform, starting with Windows Server 2016 and moving forward. Windows Server 2019 greatly improved on the native hybrid features built into the operating system. Windows Server 2022 takes to the next level of hybrid capabilities. Why is hybrid management crucial for today’s businesses and, particularly, their security initiatives.

Most businesses today are using infrastructure that is housed both on-premises and in the cloud. This infrastructure layout is known as a hybrid configuration. As many organizations are required to keep a subset of infrastructure locally housed in their own physical on-premises data centers for compliance and other reasons, the hybrid world of infrastructure is no doubt here to stay for the foreseeable future.

As infrastructure spans between on-premises data centers and cloud environments such as Microsoft Azure, it becomes even more critical for businesses to focus on security between the two. Historically, it has been challenging to standardize security and management tools between on-premises and cloud environments as each has its specific tooling, processes, dashboards, configuration possibilities, etc.

With Microsoft Azure and modern Windows Server operating systems such as Windows Server 2022, Microsoft has created a solution to help remedy management disparities between the cloud and on-premises Windows Server instances. Azure Arc is a Microsoft Azure solution that allows the onboarding of on-premises Windows Servers into the management plane of your Microsoft Azure account, bringing on-premises resources under the purview of Azure Resource Manager (ARM).

Specifically, Azure Arc provides simplified management across many environments maintained by many organizations today, including Windows, Linux SQL, and even Kubernetes clusters across data centers and geographic locations. So what can you do with Azure Arc?

• • Provide centralized management of resources, both in Azure and on-premises

• • Gain centralized visibility in the Azure portal of both Azure and on-premises resources

• • Apply compliance and governance standards across all environments in a standardized way

• • Provide access delegation to resources using the role-based access control (RBAC) features in Azure

• • Gain organization and inventory benefits as you can house objects from Azure or on-premises locations into management groups, subscriptions, resource groups, in addition to using tagging

Azure Arc dashboard in the Azure portal

Azure Security Center is another offering from Microsoft, centred around security, that helps unify infrastructure security management and provide a consistent set of tools and security policies, regardless of whether resources exist in Azure or on-premises. It is built seamlessly into Windows Admin Center. In addition, you can sign in to Azure and onboard into the service directly from the tool.

Launching the Azure Security Center dashboard from Windows Admin Center

It helps businesses carry out the following Windows Server 2022 security-related tasks:

• • Manage organization security policy and compliance

• • Perform continuous assessments

• • Build network maps

• • Configure best practices and recommended controls

• • Protect against threats

Azure Security Center provides a consistent view of the security of on-premises and cloud workloads

Another great feature extended to Windows Server 2022 is the Azure hybrid center available directly from Windows Admin Center. With Azure hybrid services, IT admins can:

• • Protect virtual machines

• • Extend on-premises storage capacity and compute resources in Azure

• • Simplify network connectivity

• • Centralize monitoring, governance, configuration, and security

Available hybrid services with Windows Server 2022 and Microsoft Azure

Connecting your on-premises Windows Server 2022 server to the Azure hybrid center is as easy as registering your Windows Admin Center gateway server and signing in to your Azure portal.

Azure hybrid center available from Windows Admin Center

Windows Server 2022 Azure Edition Hotpatching

Microsoft has introduced a new patching technology that is part of the Azure Automanage platform in Microsoft Azure. It works with the “Azure Edition” of Windows Server products. Hotpatch is supported in Windows Server 2022: Azure Edition and is a new way of installing Windows updates in Windows Server Azure Edition virtual machines that do not require a reboot after installation.

The hotpatching feature drastically reduces maintenance windows and the downtime associated with the typical installation of Windows Updates in Windows Server. Hotpatch first establishes a baseline of the Windows Update Latest Cumulative Update. Hotpatches are then periodically released and contain updates that don’t require a reboot. Planned baselines are released on a regular cadence interval with hotpatch releases in between. In addition, unplanned baselines are released in case of emergency security patches and if the patch can’t be released in a hotpatch.

Customers making use of Windows Server 2022: Azure Edition in their Azure environment can take advantage of the latest enhancements and implementations of the hotpatch feature using Azure Automanage.

The Future of Windows Server Security

There are a large number of new features contained in Windows Server 2022. It represents the latest capabilities and features provided by Microsoft for the Windows Server platform. In addition, many enhancements are security-related and help customers with their cybersecurity posture, both on-premises and in the cloud.

As shown, Microsoft has worked hard to provide better tools for managing Windows Server 2022. For example, Windows Admin Center provides a single-pane-of-glass tool that perfectly compliments the new features and capabilities in Windows Server 2022. While many of the dashboards are still in preview, it helps to see the direction Microsoft is headed with an all-inclusive solution to standardize management of both on-premises and cloud resources seamlessly.

The Secured-Core functionality made possible by Windows Server 2022 and the Windows Admin Center management console allows customers to easily provide the core security fundamentals to their Windows Server environment powered by Windows Server 2022. Windows Server 2022 also provides the latest standards and implementations of secure protocols such as TLS 1.3 and SMB encryption.

In addition, using Windows Admin Center provides the gateway to integrating on-premises Windows Server installations with Azure. There are strong hybrid integration capabilities found in Windows Admin Center. It allows integrating your on-premises Windows Server 2022 installations into Azure with only a few clicks and signing in to your Azure account. All of these features make Windows Server 2022 the most secure Windows Server operating system released to date.

The post Windows Server 2022 has Very Interesting Security Features appeared first on Altaro DOJO | Hyper-V.

Security is becoming increasingly important and considering the attacks on Solarwinds and Kaysea that have shaken the IT industry, there has never been a better time to reassess your own security measures and there is no better place to start than with your Microsoft 365 tenant.

The questions answered in this article were asked during a webinar we hosted which was presented by Truesec enterprise security experts Fabio Viggiani and Hasain Alshakarti. If you weren’t able to attend the webinar you can watch the full recording for free right here on the DOJO. It covers the most critical vulnerabilities in the Microsoft 365 suite, and how they would go about fixing or preventing them. As always in webinars such as this, we’re given a number of questions from attendees. Below you’ll find a list of the questions and associated answers from this webinar series, starting with a 30-minute follow-up video featuring Hasain and myself!

Resources

View mail flow reports in the Reports dashboard in Security & Compliance Center
Troubleshoot using the What If tool in Conditional Access
Top 10 ways to secure Microsoft 365 for business plans
Microsoft Secure Score
What’s inside Microsoft Security Best Practices? – (Security Compass)

Your M365 Security Questions

Are there any recommended conditional access policies that should be applied to ALL tenants?

Yes: at a minimum, policies should be put in place that blocks legacy authentication mechanisms along with requiring MFA for all users if possible (admins at a minimum). Also if you’ve got employees logging in from only a handful of countries go ahead and set up geofencing as well. Finally, don’t forget to set up your “break glass” accounts!

Are there any recommended tools to help test passwords against known breaches?

There are features in the Identity Protections features in M365 that can help with this. Additionally, a plugin can be installed on your on-prem DCs to have local passwords checked as well.

If I’m an SMB or some organization that has one of the lower licensing SKUs, what are my options for stopping Phishing?

At a minimum, you can set up MFA, which is included even in the lower licensing tiers. User awareness training and careful log monitoring can be useful at this size of organization as well.

Are Hardware-Based MFA Devices More Secure?

Not necessarily, the threat-actor is still going to wait for the end-user to do what they need to do to log in. The threat actor’s session token is still the target and can be compromised after a successful authentication with things like malicious OAuth applications…etc.

What are your recommendations for MFA in situations where you may have a shared global admin account across multiple team members?

Security best practices say don’t do this for a number of reasons. Ideally, each administrator requiring this level of access will have their own global admin account and leverage features such as just-in-time access.

Is it advantageous from a security perspective to have all endpoints accessing M365 managed by InTune?

Every situation is different of course, but anything that can increase the overall trust of a device (like being managed by InTune if that works for your organization) is generally beneficial

How much effort should organizations put towards end-user training?

This is certainly an area that organizations should focus on with consistent regular training. That said, this needs to be paired with technical solutions that are able to identify and take action against a threat because the human element WILL fail at some point despite best-laid plans

Isn’t Conditional Access Deprecated?

Not at all! It could be you’re thinking of Conditional Access Baseline Policies, which never made it out of preview, but was instead replaced by Security Defaults. That said Conditional Access itself remains a highly potent tool for Security in M365.  

Is there a list of Microsoft Default Enterprise Apps and App Registrations for Reference Purposes?

I’m not aware of one myself. To a degree, the list will partially be dictated by the licenses that are active in your M365 tenant. For example, if you only have Exchange Online Plan 1 and nothing else it may look odd to see Teams and SharePoint in that list…etc…etc. Even with defaults, the list should be reviewed by a human on a regular basis. That said, if we stumble across one at some point, I’ll be sure to update this list with a link to it! 

Does the Outlook Client Application still work if MAPI Legacy Authentication is disabled?

I suspect this question comes from my discussions around MAPI being a legacy authentication protocol and should have mentioned that the advice there is specific to MAPI via HTTP, which is only used via Outlook 2010 and older clients. Newer Outlook clients can take full advantage of Modern Authentication and still work with no issue as it doesn’t leverage a legacy MAPI protocol. 

Seems like a lot of these recommendations require specific M365 licenses. Is there a recommended license or combo of licenses for different-sized organizations? 

Admittedly, you almost need a PhD in order to wrap your head around M365 licensing.In short, the 3 potential “addons” you’re looking for are Azure AD Premium Plan 1 or Plan 2, or one of the EMS E3 or E5 options, which include varying levels of AAD Premium. Any of these can be tacked on to various M365 packages for the extra security functionality, and some packages come with them. For example, Business Premium comes with AAD Premium plan 1 which will net you the basic conditional access features. I suggest reviewing the AAD Pricing page, and EMS comparison page. Then it becomes a pricing exercise of which option works best for your customer’s specific needs.  

Andy Mentioned an eBook that covers M365. Can you share the URL for that again?

Sure thing! The eBook can be found here! 

To use Conditional Access do we need Azure AD Plan 1?

Correct. AAD Premium Plan 1 will get you access to basic conditional access functionality that will cover many use-cases for many different organizations. If you need all the bells and whistles such as Risky sign-in protection, risky user detection….etc..etc, then you’ll need AAD Premium Plan 2. See the AAD Pricing Page for some comparisons.  

Can I have Azure AD Connect in more than one DC?

Without additional context, I’m assuming you need to sync multiple AD Forests into Azure AD? If that’s the case I suggest reviewing the Azure AD Connect topologies Documentation here for more information on that use case.  

How can Intune help with security?

This is a fairly broad question. I would suggest reviewing this entry from the Microsoft Docs documentation for more information on Intune and the device protections it can provide.  

Is the Microsoft Authenticator App the way to go in terms of providing the code for MFA?

It’s ONE potential way to go, and it works quite well in most cases. That said, if you’re part of an organization that has more specific security requirements there are other options such as hardware MFA keys, as an example.  

More on M365 Security and Vulnerabilities

We have a number of articles centered around security, but below are some of the articles that most closely go along with the topic of this webinar!

How the SolarWinds Hack Could Change Data Security Forever
M365 Records Management Guide
How Conditional Access Makes MFA Easy for Your Company
Why you Should Be Using Azure Security Benchmark
How to Secure Your Apps and Data with Azure Active Directory
Managing Identities and Passwords in Azure Active Directory
How to Boost your Azure Secure Score
The Actual Performance Impact of Spectre/Meltdown Hyper-V Updates

And just a reminder, if you haven’t watched the full webinar – what are you waiting for? Your 5 Most Critical M365 Vulnerabilities Revealed and How to Fix Them is free to watch right now!

Thanks for reading and for submitting your questions if you were one of our attendees for the webinar! Again, if you asked a question that you don’t see listed here or in the video, be sure to use the comments form below and we’ll get back to you with an answer!

As always, thanks for reading!

The post Your Microsoft 365 Vulnerabilities Questions Answered appeared first on Altaro DOJO | Hyper-V.

As I was tinkering with a few things in Azure virtual WAN, I thought it would be a great idea to write a short guide on how to connect Site 2 Site VPN Device to virtual WAN which is not a managed CPE Partner.

After a conversation with Andy Syrewicze, we decided to show you how to perform the configuration using a Ubiquiti Dream Machine Pro. This guide also applies to the below Ubiquiti Products, but it also gives you a framework that is applicable to other vendors such as Sophos or LanCom:

• Ubiquiti Dream Machine
• Ubiquiti Security Gateway 3P
• Ubiquiti Security Gateway 4P Pro

There are two reasons why we decided on the Ubiquiti. First, the devices are kind of tricky when it comes to VPN to Azure, and second, we both are Ubiquiti Fans and have huge installations at home. You can see my installation in the screenshot below:

Prepare Azure Virtual WAN

Let us first prepare our Virtual WAN to function as a VPN endpoint. To do so, you need to deploy a virtual WAN Hub with a VPN Gateway in it.

To deploy the Hub, I followed standard Microsoft deployment guides provided below.

• Tutorial: Use Azure Virtual WAN to Create Site-to-Site connections | Microsoft Docs

After I configured the hub, I started to configure the VPN Site for my location.

In my case, I left BGP disabled because the UDN Pro does not support Border Gateways Protocol. If you use a Ubiquiti Edge, BGP enabled VPN Device like von Juniper or are ok with using a Ubiquiti Security Gateway CLI configuration, you can enable BGP.

• EdgeRouter – Border Gateway Protocol (BGP) – Ubiquiti Support and Help Center
• Connect Ubiquiti USG to Azure VWAN Gateway using BGP | Crazy Cloud Ideas (sameeraman.github.io)

I left the Connect to Hubs option empty because it would use the default VPN configuration. In our case, we will use a custom and more stable configuration later on.

Now I configured the WAN Links. In a classic Azure Gateway configuration, that would be the local gateway IP.

In my example configuration, I made two changes to a traditional setup. The first change is that I use two WAN links, I currently have two Internet Service Providers (ISPs) for internet redundancy and connectivity to Azure. So it makes sense to configure both of them to link to my virtual WAN Gateway. The other change is that I use the Frequently Asked Domain Name (FQDN). That gives me the option to use dynamic DNS (DDNS) Services or a self-made DDNS.

In my case, I use a self-made one and host the DNS entries for my VPN in Azure DNS.

For the DDNS Service, I leveraged the code provided by cirrius tech. Create your own Dynamic DNS service using Azure DNS – part 1 (cirriustech.co.uk)

After your configuration of the links is done, Azure virtual WAN will run a validation of your configuration.

As soon as you passed the validation, you can create the new VPN Site.

After the VPN Site is deployed, we can start configuring the Hub connection and VPN IPSec Policies.

Configure Hub and IPSec

Now we navigate to the hub where we want to connect the VPN Site to and click on VPN Site.

You will not see your VPN Site in the first place because virtual WAN has a pretty annoying default filter, The filter only shows connected sites. Just remove the filter.

After you removed the filter, the VPN Site will show up.

Now let’s connect our site to the hub. To do so, please select the site and click connect.

The configuration blade will show up. I used a custom configuration which wors well with the Ubiquiti devices. You can also use the default configuration but then you need to change the DH Group in the Ubiquiti from 2 to 24 and you only use lower encryption standards. That is why I prefer my custom configuration.

After a successful configuration, you should see the connection status as succeeded and the connectivity status as updating.

Within the next step, we will prepare the Ubiquiti VPN Device and configuration.

Prepare Ubiquiti VPN Device

Before we start the configuration, we need to collect some information from Azure to add them later to you Ubiquiti tunnel configuration.

First, we need public IPs from the Azure Gateways. There are different options to do that.

The classic one is to download the VPN configuration file.

Here you will find all the necessary information for the configuration.

[
  {"configurationVersion":{"LastUpdatedTime":"2021-01-27T13:39:28.0925596Z","Version":"eb76d019-4242-443a-a1d9-d56a346972b9"},"vpnSiteConfiguration":{"Name":"GBG01","IPAddress":"","LinkName":"WAN01","Office365Policy":{"BreakOutCategories":{"Optimize":false,"Allow":false,"Default":false}}},"vpnSiteConnections":[{"hubConfiguration":{"AddressSpace":"172.20.220.0/24","Region":"Germany West Central","ConnectedSubnets":["10.0.0.0/24","10.0.1.0/24","192.168.155.0/24","192.168.22.0/24"]},"gatewayConfiguration":{"IpAddresses":{"Instance0":"","Instance1":""}},"connectionConfiguration":{"IsBgpEnabled":false,"PSK":"","IPsecParameters":{"SADataSizeInKilobytes":102400000,"SALifeTimeInSeconds":3600}}}]},
  {"configurationVersion":{"LastUpdatedTime":"2021-01-27T13:39:28.0925596Z","Version":"4d0dabe5-d5b1-4fc2-8a77-68fc7cdff159"},"vpnSiteConfiguration":{"Name":"MD01","IPAddress":"","LinkName":"WAN02","Office365Policy":{"BreakOutCategories":{"Optimize":false,"Allow":false,"Default":false}}},"vpnSiteConnections":[{"hubConfiguration":{"AddressSpace":"172.20.220.0/24","Region":"Germany West Central","ConnectedSubnets":["10.0.0.0/24","10.0.1.0/24","192.168.155.0/24","192.168.22.0/24"]},"gatewayConfiguration":{"IpAddresses":{"Instance0":"","Instance1":""}},"connectionConfiguration":{"IsBgpEnabled":false,"PSK":"","IPsecParameters":{"IpsecEncryption":"AES256","IpsecIntegrity":"SHA256","IkeEncryption":"AES256","IkeIntegrity":"SHA256","PfsGroup":"None","DhGroup":"DHGroup24","SADataSizeInKilobytes":102400000,"SALifeTimeInSeconds":27000}}}]},
  {"configurationVersion":{"LastUpdatedTime":"2021-01-27T13:39:28.0925596Z","Version":"b3819f84-df07-4577-b657-6bf5efebcede"},"vpnSiteConfiguration":{"Name":"MD01","IPAddress":"","LinkName":"WAN01","Office365Policy":{"BreakOutCategories":{"Optimize":false,"Allow":false,"Default":false}}},"vpnSiteConnections":[{"hubConfiguration":{"AddressSpace":"172.20.220.0/24","Region":"Germany West Central","ConnectedSubnets":["10.0.0.0/24","10.0.1.0/24","192.168.155.0/24","192.168.22.0/24"]},"gatewayConfiguration":{"IpAddresses":{"Instance0":"","Instance1":""}},"connectionConfiguration":{"IsBgpEnabled":false,"PSK":"","IPsecParameters":{"IpsecEncryption":"AES256","IpsecIntegrity":"SHA256","IkeEncryption":"AES256","IkeIntegrity":"SHA256","PfsGroup":"None","DhGroup":"DHGroup24","SADataSizeInKilobytes":102400000,"SALifeTimeInSeconds":27000}}}]},
  {"configurationVersion":{"LastUpdatedTime":"2021-01-27T13:39:28.0925596Z","Version":"7b6a0635-7229-451e-82e1-532ae86a109a"},"vpnSiteConfiguration":{"Name":"GBG02","IPAddress":"","LinkName":"WAN01","Office365Policy":{"BreakOutCategories":{"Optimize":false,"Allow":false,"Default":false}}},"vpnSiteConnections":[{"hubConfiguration":{"AddressSpace":"172.20.220.0/24","Region":"Germany West Central","ConnectedSubnets":["10.0.0.0/24","10.0.1.0/24","192.168.155.0/24","192.168.22.0/24"]},"gatewayConfiguration":{"IpAddresses":{"Instance0":"","Instance1":""}},"connectionConfiguration":{"IsBgpEnabled":false,"PSK":"","IPsecParameters":{"SADataSizeInKilobytes":102400000,"SALifeTimeInSeconds":3600}}}]}
]

The important points in that file are.

• “hubConfiguration”:{“AddressSpace”: – shows you the IP Subnet used for the hub
• “ConnectedSubnets” – shows you the IP Subnet of the connect virtual networks
• “IpAddresses”:{“Instance0″:””,”Instance1″:”” – shows you the public IP of the Azure Loabbalancers which are connected to the Azure Virtual WAN VPN Gateways

You can also collect this information manually by looking into the Gateway configuration, which came with a release in Q3 2020.

To collect the Hub IP Subnet you need to go back to the virtual WAN Hub overview screen.

To find the connected VNet IP spaces, you need to go to the connected VNet list in the main hub overview and then click on every single VNet to find the details.

As you can imagine, that is a very uncomfortable way to collect the information. So I would suggest staying with the VPN Config file. Now let us start with the configuration of our Ubiquiti VPN Device.

VPN Device configuration

To be honest, for my configuration and management, I use the new Ubiquiti Alpha UI. It has some feature available which are not enabled in the classic UI and it also has removed a bug with Azure VPN tunnels in regards to disabling dynamic routing and PFS. To switch to Alpha UI, you need to go to the System Menu of you controller and switch to beta features.

Navigate to Networks and create a new one.

Now you can add a Site 2 Site VPN and configure it as we did on the Azure Site.

The following points in VPN Settings are important to know:

• Interface: You need to choose the Interface where you want to connect your tunnel from. In my case, I will use my backup connection instead of my primary internet connection.
• Peer IP: here you add the public IP of virtual WAN Instance 0 or 1
• Local WAN IP: in case you have a static public IP, you should add that public IP here. If you use a dynamic IP or dynamic DNS, you add 0.0.0.0 as you local WAN IP
• IPSec Profile: set to dynamic routing

Now we need to configure the IPSec policy.

I prefer to run a static configuration to later change the routing and only allow some of my network to connect to Azure but a dynamic routing configuration also works pretty well.

As soon as you configured the VPN Settings on the Ubiquiti it should take around 5 minutes until the tunnel comes up.

Closing

Thank you for reading through the article. I hope it was helpful for all of you. If you need more details or have additional questions, please feel free to leave me a comment.

The post How to configure Azure virtual WAN VPN Site-2-Site with unmanaged VPN device appeared first on Altaro DOJO | Hyper-V.

Storing data is a “killer application” for the public cloud and it was one of the services adopted early by many businesses. For your unstructured data such as documents, video/audio files, and the like, Azure Blob storage is a very good solution.

In this article, we’ll look at what Blob Storage is, how it works, how to design resiliency and data protection based on your business scenarios, and how to recover from outages and disasters.

Azure Storage Overview

It all starts with a storage account, inside of which you can have one or more containers, each of which can store one or more blobs (Binary Large Objects). The names of accounts and containers need to be in lowercase and they’re reachable through a URL by default and thus need to be unique globally. Blobs can be Block blobs for text and binary data and each one can be up to 4.75 TiB, with the new limit of 190.7 TiB in preview. Append blobs are similar to block blobs but are optimized for append/logging operations. Page blobs are used to store random access files up to 8 TiB and are used for virtual hard drive (VHD) files for VMs. In this article, we’re focusing on block and append blobs.

Throughout this article and in Azure’s documentation Microsoft uses TebiByte (TiB), which is equivalent to 2⁴⁰ or 1,099,511,627,776 bytes, whereas a TeraByte (TB) is 10¹² bytes or 1,000,000,000,000 bytes. You know that fresh 4 TB drive that you just bought and formatted and only got 3.6 TB of usable storage from? This is why these newer names (kibi, mebi, gibi, pebi, exbi, zebibytes) are more accurate.

Storage accounts also provide Azure Files, think Platform as a Service managed file shares in the cloud, and Azure File Sync which lets you connect your on-premises file servers to Azure and keep only frequently used files locally and sync cold data to Azure. Both of these fantastic solutions are not the topic of this article.

There are two generations of storage accounts, general purpose V1 and V2. In most scenarios, V2 is preferred as it has many more features.

To get your data from on-premises to the cloud over the network you can use AzCopy, Azure Data Factory, Storage Explorer (an excellent free, cross-platform tool for managing Azure storage), and Blobfuse for Linux. For offline disk transfers, there is Azure Data Box, -Disk, and -Heavy, along with Azure Import/Export where you supply your own disks.

Azure Storage Explorer – manually setting access tier

Blob storage is hard-drive-based but there is an option for premium block blob storage accounts which is optimized for smaller, kilobyte-range objects and high transaction rates / low latency storage access.

Resilience

One of the best features of Azure Blob storage is that you won’t lose your data. When designing storage solutions for on-premises building high availability is challenging and requires good design, WAN or MAN replication and other costly technical solutions. In the cloud, it’s literally a few tick boxes. Picking the right level of data protection and recovery capabilities does require you to understand the options available to you and their cost implications.

Note that this article is looking at Blob storage for an application that you’re developing in-house, for VM resiliency look at this blog post on Azure Availability Sets and Zones, if you’re looking at using Blob storage for long term archiving of data look here and if you need a tutorial on setting up storage look here. You can also use Blob storage to serve images or documents directly in a browser, streaming video or audio, writing to log files, store backup, DR and archiving data or store data for Big Data analysis.

Creating Storage Account Replication options

The simplest level of data protection is Locally redundant storage (LRS) which keeps three copies of your data in a single region. Disk and network failures, as well as power outages, are transparently hidden from you and your data is available. However, a failure of a whole datacenter will render your stored data unreachable. Zone redundant storage (ZRS) will spread your three copies across different datacenters in the same region and all three copies have to be written for the write to be acknowledged. Since each datacenter has separate power, cooling, and network connections, your data is more resilient to failures. This is reflected in the guaranteed durability, LRS gives you 99.999999999% (11 nines) over a given year, whereas ZRS gives you 99.9999999999% (12 9’s). Not all regions support zones and ZRS yet. In the event of a large-scale natural disaster taking out all datacenters in an entire region however you need even better protection.

Geo-redundant storage (GRS) keeps three copies in your primary region and also copies them asynchronously to a single location in a secondary, paired region. In regions where zones are supported, you can use Geo-zone-redundant storage (GZRS) instead, which uses ZRS in your primary region and again copies it asynchronously to a single location in the secondary region. There’s no guaranteed SLA for the replication but “Azure Storage typically has an RPO of less than 15 minutes”. Both GRS and GZRS gives you 99.99999999999999% (16 9’s) durability of objects over a given year. This provides excellent protection against a region failing but what if you’d like to do something with the replicated data such as periodic backups, analysis, or reporting?

To be able to do this, you need to choose read-access geo-redundant storage (RA-GRS) or read-access geo-zone-redundant storage (RA-GZRS). This provides the same durability as GRS/GZRS with the addition of the ability to read the replicated data. Predictably the cost of storage increases as you pick more resilient options. Unless Microsoft declares a region outage you have to manually fail over a storage account, see below.

Providing Access

As mentioned, each storage account has a URL but data isn’t public and you need to set up authentication correctly to ensure that the right people have access to the appropriate data, and no one else. When you create a Storage account you can set up which networks it can be accessed from. You can pick from a public endpoint – all networks (suitable if you must provide access to users from the internet), public endpoint – selected networks (pick vNet(s) in your subscription that can access the account), or a private endpoint.

Each HTTPS request to a storage account must be authorized and there are several options for controlling access. You can use a Shared Key, each storage account has a primary and a secondary key, the problem with this approach is that the access is very broad and until you rotate the key, anyone with the key has access to the data. Another, older method, is Shared access signatures (SAS) which provides very specific access at the container or blob level, including time-limited access. The problem is again that someone else could obtain the SAS and use it to access data. The recommended method today is to use Azure Active Directory (AAD) to control access. For blob storage, you can also provide anonymous public read access which of course is only suitable for a few business scenarios.

Tiering

Blob storage accounts let you tier your data to match the lifecycle that most data go through. In most cases, data is accessed frequently when it’s just created and for some time after that, after which access decreases as it ages. Some data is just dumped in the cloud and rarely accessed, whereas other data is modified frequently over its entire lifetime.

These three tiers are hot, cool, and archive. The cool tier is the same hard disk-based storage as the hot tier, but you pay less for storing data at this tier, provided you don’t access it frequently. An example would be relatively recent backup data, you’re unlikely to access it unless you need to do a restore. The archive tier on the other hand is tape-based and rehydrating/retrieving the data can take up to 15 hours, but it is the cheapest storage tier.

Storage account lifecycle rule move to cool tier

You can set the tier of a blob programmatically in your application or you can use lifecycle management policies. This lets you do things such as transition blobs from hot to cool, hot to archive, or cool to archive based on when it was last accessed, delete blobs and versions/snapshots at the end of their lifecycle, and apply these rules at the container level or on a subset of blobs.

Data Protection

Now that we’ve looked at the basics of storage accounts, blobs, tiering, and geographical resilience, let’s look at the plethora of features available to manage data protection.

Blob versioning is a fairly new feature (for general purpose V2 only) that creates a new version of a blob whenever it’s modified or deleted. There’s also an older feature called Blob Snapshots that also creates read-only copies of the state of a blob when it’s modified. Both features are also billed in the same way and you can use tiering with versions or snapshots, for instance keeping current data on the hot tier and the older versions on the cool tier. The main difference between the two is that snapshots is a manual process that you have to build into your application, whereas versioning is automatic once you enable the feature. Another big difference is that if you delete a blob, its versions are not deleted automatically, with snapshots you have to delete them to be able to delete a blob. There’s no limit on the number of snapshots/versions you can have but Microsoft recommends less than 1000 to minimize the latency when listing them.

To protect you against users deleting the wrong document or blob by mistake you can enable soft delete for blobs and set the retention period between 1 and 365 days. Protecting entire containers against accidental deletion is also possible, currently, it’s in preview. Note that neither of these features helps if an entire storage account is deleted – but a built-in feature in Azure called Resource locks allows you to stop accidental deletions (or changes) to any resource, including a storage account.

To keep track of every change to your blobs and blob metadata, using the change feed feature. It stores an Apache Avro formatted ordered, guaranteed, durable, immutable and read-only changelog.

If you have Soft delete, Change feed and Blob versioning enabled you can use point-in-time restore for block blobs, which is useful for in accidental deletion, corruption or data testing scenarios.

Creating a Storage Account Data Protection Options

Also for block blobs only is the Object replication feature. This lets you asynchronously copy block blobs from one storage account to another. This could be for a geo-distributed application that needs low latency access to a local copy of the blobs, or data processing where you distribute just the results of the process to several regions. It requires that Change feed and Blob versioning are enabled. The difference between this and GRS / GZRS is that this is granular as you create rules to define exactly which blobs are replicated, whereas geo-replication always covers the entire storage account. If you’re using blob snapshots be aware that they’re not replicated to the destination account.

If you have any of the geo-replicated account options, you should investigate exactly what’s involved in a manual failover that you control and include it in your Disaster Recovery plan. If there’s a full region outage and Microsoft declares it as such, they’ll do the failover but there are many other situations that might warrant you failing over, which typically takes about an hour. Be aware that storage accounts with immutable storage (see below), premium block blobs, Azure File Sync, or ADLS Gen2 cannot be failed over.

All storage (after 20^th October 2017) in Azure is encrypted, you can check if you have data that’s older if it’s encrypted or not. If you have data from different sources in the same account, you can use the new Encryption scope (preview) feature to create secure boundaries between data using customer-managed encryption keys.

Creating a Storage Account Advanced Settings

If you have a regulatory need to provide Write Once, Read Many (WORM) or immutable storage you can create legal hold (until it’s lifted) or time based retention policies during which time no blobs can be deleted or changed, even if you have administrative privileges. It can be set at the container level and works across all access tiers (hot, cool, and archive).

It’s interesting to note that with all of these built-in data protection features for Disaster Recovery, including geographical replication, there’s no built-in backup solution for blob storage. Backup, as opposed to DR, comes into play when you have an application error for instance and data has been corrupted for some time and you need to “go back in time”. There are ways to work around this limitation.

Azure Blob Storage features

There are several other features that contribute to data protection and resiliency such as Network routing preference. Normally traffic to and from your clients on the internet are routed to the closest point of presence (POP) and then transfer on Microsoft’s global network to and from the storage account endpoint, maximizing network performance, at the cost of network traffic charges. Using this preview feature you can instead ensure that both inbound and outbound traffic is routed through the POP closest to the storage account (and not closest to the client), minimizing network transfer charges.

Creating a Storage Account Network Settings

If you have REALLY big files, blob storage now supports up to 190.7 TiB blobs.

To understand what data you have in your storage accounts use the new Blob inventory report preview feature to see total data size, age, encryption status, etc. Managing large amounts of blobs becomes easier with Blob index which lets you dynamically tag blobs using key-value pairs which you can then use when searching the data, or with lifecycle management to control the shifting of blobs between tiers.

Azure Data Lake Store Gen2

No conversation around Azure storage is complete without mentioning ADLS Gen2. Traditionally data lakes are optimized for big data analytics and unaware of features such as file system semantics / hierarchical namespaces and file level security. ADLS Gen2 builds on Azure Blob storage and provides these features, along with many others to provide a low cost, tier aware, highly resilient platform to build enterprise data lakes. There are some features available in Blob storage accounts that are not yet available for ADLS Gen2. To optimize your application to only retrieve exactly the required data use the new Query Acceleration feature for both Blob storage and ADLS Gen2.

Conclusion

Azure Blob storage provides a multitude of features to ensure the protection and recoverability of your data in one comprehensive platform. Good luck in designing optimized Azure Blob storage solutions for your business needs.

The post Azure Blob Storage: Data protection and Recovery capabilities appeared first on Altaro DOJO | Hyper-V.

If there’s one thing that’s a lot easier to achieve in the cloud than on-premises, it’s High Availability (HA). This might sound strange given that when you move to public cloud, you give up a lot of control over your infrastructure but as we’ll show in this article – Azure Availability Sets and Azure Availability Zones are part of a plethora of technologies you can use to ensure your applications stay up.

High Availability on Premises

There are some fundamental concepts that contribute to HA in computer systems. At the server level on-premises we have redundancy built-in (dual or triple power supplies in each server, RAID for disk storage, multiple NICs connected to separate switches). Networks can be built to be redundant with multiple paths, switches and routers, eliminating single points of failure. Once we bring virtualization into the picture, clustering multiple physical servers together becomes feasible, automatically restarting VMs on other hosts if a physical server fails. And if you have particularly business-critical applications, we look to stretched clusters where nodes in a cluster are separated by some kilometres of distance. As you can appreciate, cost and complexity increase as you implement more of these technologies, with the most critical applications reserved for the really expensive solutions. Also notice that we go from guarding against a single component in a server failing, to a whole server or network, to a whole site.

That’s HA, keeping an application available for users through eliminating single points of failure and storing data in a redundant fashion, which is separate to Disaster Recovery (DR) preparedness.

DR applies similar concepts, generally by replicating data from one location to another to make it possible to restore services should a whole site fail. The main difference between HA and DR is that the latter isn’t instantaneous, and some downtime is expected. It’s tempting to get caught up in technical solutions to HA and DR as you imagine scenarios of hurricanes and floods taking out your servers but as much as this is a technical issue, it’s a people and process problem. Nearly all outages are caused by people making mistakes or processes not being thought through, not by unexpected natural disasters.

If you outsource any part of the system described above, your provider generally offers a Service Level Agreement (SLA) where they will reduce your cost if they don’t provide the agreed uptime, described in availability, generally per month, for example, 99.9% uptime equates to 43.2 minutes of downtime in a month.

The good news is that an understanding of these concepts (which most IT Pros know off by heart) transfer very well to public cloud.

High Availability in Azure

The main difference between running your workloads on-premises and Azure when planning for HA is that you don’t have access to the underlying infrastructure which means less work as well as less control. We’ll start by looking at IaaS VMs, where a single VM running on Standard HDD Managed Disk has an SLA of 95%, Standard SSD Managed Disk gives you 99.5% and a VM running on Premium / Ultra SSD gives you 99.9%. These SLAs only apply if all disks (OS and data disks) are running on the required storage type.

So, if your business has a critical application that can only run in a single VM Azure can at most provide 99.9%. Obviously, this is downtime that Microsoft has responsibility for, if your application in the VM crashes or is attacked by malware or your network infrastructure or ISP has an outage those don’t count. If the SLA is breached, and you go through the work of proving to support that it was, you’ll get service credits, which is small comfort if your business application was down for hours or days.

Just as on-premises, a single VM really isn’t enough for a proper HA strategy. Hence you need to use Availability Sets, here’s a good primer. There are two new terms to cover here, Update Domains (UD) and Fault Domains (FD). The former means that if two VMs are spread across UDs, only one host will be restarted at a time when Microsoft updates their Hyper-V hosts. Be aware that Microsoft has put in a lot of work to limit the times that hosts actually need to be rebooted for updates, mostly they can apply updates to a running OS without a reboot. An FD is a rack which has separate power and networking connections and is the smallest fault isolation in Azure.

Fault and Update Domains in Azure (courtesy of Microsoft)

Take a canonical three-tier application with two web front end servers, two middle-tier application layer VMs and two backend database servers. When creating this in Azure you’d put each tier in an Azure Availability Set. This tells Azure to separate the two web VMs for instance in two distinct FDs, if a rack fails your second VM is still servicing clients as it’s running in a separate rack. Also, note that three copies of your managed disks for each VM are spread across storage infrastructure. When creating an Azure Availability Set the default number of FDs is 2 (max 3, depending on region) and UDs is 5 (max 20). VMs are spread across each FD and UD so that if you have seven VMs in an Azure Availability Set and five UDs, two of the UDs will have two VMs in it and one FD will have three VMs and the other one four. You cannot pick which VM goes in which UD or FD.

Creating an Azure Availability Set

Once you have your application deployed in one or more Azure Availability Sets, you get an SLA of 99.95% (21.6 minutes downtime). If your business has strict regulatory requirements and has opted for an Azure Dedicated Host they provide the same SLA as an Azure Availability Set.

Note that the concept of an Azure Availability Set lets Azure know that these VMs are “related” and needs to be kept separate, it’s up to you to make sure that the applications running in the VMs are using guest clustering appropriately. For instance, if you have two VMs running as Active Directory Domain Controllers (DCs) in the same domain they’ll automatically replicate and if one of them is on an FD that fails, the other DC will still be available for other VMs to authenticate against. If you have a SQL Server backend, you’ll need to set up database clustering in a guest cluster so that your application continues to be able to access data, even if one SQL VM is unavailable.

The opposite (sort of) to Azure Availability Sets is Proximity placement groups where you have a need to keep VMs very close to each other to support latency-sensitive applications.

Azure Availability Zones

In the ongoing “battle of worlds” between Azure and AWS, Microsoft proudly proclaims that they have more regions than AWS and GCP combined, whereas AWS claims more zones per region.

Currently, there are over 60 regions in Azure, spread across 140+ countries. Each region is one or more datacenters, and in each geography (apart from Brazil) there are two regions that are paired so that you can replicate data from one region to another whilst still complying with your country’s data residency laws. Each region is separated by at least 300 miles (typically) to reduce the likelihood that a natural disaster in one region affects the other region.

Azure Availability Zones and Regions

Within a region, there are multiple datacenters that have separate cooling, power and network infrastructure, providing isolation should an entire datacenter fail, these are known as Azure Availability Zones. For regions that provide Azure Availability Zones you can create VMs and distribute them across Azure Availability Zones which gives you a 99.99% SLA (4.3 minutes downtime per month).

At the time of writing 12 regions support Azure Availability Zones with four more coming soon.

Here I’m creating a VM in Australia East and picking zone 2 to house it.

Creating a virtual machine

If you need several VMs that can be created from a single image that has your application already installed spread automatically across zones use a VM Scale Set, that spans Azure Availability Zones.

You cannot create an Azure Availability Set that spans Azure Availability Zones. For Azure Availability Zones there are some services that are Zonal, meaning each instance is “pinned” to a specific Azure Availability Zone (VMs, public IP addresses or managed disks) or Zone-redundant where Azure takes care of spreading them across zones. An example is Zone Redundant Storage (ZRS) which automatically spreads copies of your data across three zones, giving you 99.9999999999% (12 9’s) SLA for the stored data. There are also non-regional services in Azure that do not have a dependency on a particular region, making them resilient to both zone and region-wide outages. These tables list Zonal and Zone-redundant service for each region.

When it comes to DR you can use Azure Site Replication (ASR) to replicate disk writes on VM disks in one region to disks in another region. This is asynchronous replication so the copy might be slightly out of date, here’s a table showing the latency between different Azure regions but you’ll get up to date data on latency from your location to each region on this site.

Azure Speed Test network latency results

You can also use ASR to replicate VMs from one Availability Zone to another. This has the distinct disadvantage that a natural disaster affecting several datacenters might take out all your zones but there are also benefits. Networking is much simpler as you can reuse the same virtual network, subnet, Network Security Groups (NSGs), private and public IP addresses and load balancer across zones. Latency will also be less but be aware that this feature is only available in five regions at the time of writing.

So far, we’ve been looking at IaaS VMs but ultimately, you’ll get the best cloud computing has to offer with PaaS services. Services such as Service Fabric, Data Lake, Firewall, Load Balancer, VPN Gateway, Cosmos DB, Event Hubs and Event Grid, Azure Kubernetes Services, and Azure Active Directory Domain Services all support zones today, giving you good building blocks for your HA architecture.

As you can see Azure offers many different options for building resilient applications and compared to managing multiple on-premises clusters or datacenters with redundant LAN and WAN infrastructure using what’s provided in the cloud is both easier and far more cost-effective.

Bringing Azure Availability Sets and Availability Zones together

Let’s make this real with an example application. A customer-facing, business-critical application needs to be moved to Azure and here’s an example architectural solution.

I’d pick a region to host the application, based on the lowest latency to the highest number of end-users, if this was a global application that needs to be distributed worldwide, we’d need to involve Azure Front Door and perhaps Cosmos DB but, in this scenario, let’s assume we’re looking at a single region.

If we need VMs for the front end we’d host multiple ones across each Availability Zone in a region and then use Azure Load Balancer to spread incoming traffic across each VM. As an alternative we might look to Azure App Environment (ASE, a PaaS version of web hosting) which lets us pin an ASE to a zone, we’d need at least two ASEs. Be aware that the Load Balancer as a PaaS is highly available as it’s zone aware, whilst also ensuring that the application VMs / resources are highly available.

For the application logic layer, we’d put one VM in each zone and use an Internal Load Balancer to manage the traffic coming from the web front end to this layer. Depending on the database layer used for the application today we may need to have multiple backend VMs with SQL server (again, spread across zones) in a guest cluster. Alternatively, if possible, switching to zone aware Azure SQL or Cosmos DB as PaaS database services would minimize infrastructure management.

This application is now resilient to host, networking hardware and storage failures, as well as an entire datacenter failing. To ensure timely recovery in the case of an entire region outage (DR), we’d use ASR to replicate the VMs to the paired region, and SQL or Cosmos DB to replicate the data to that region as well. In ASR we’d create (and test regularly) a Recovery Plan with all required steps to bring the application up quickly.

Conclusion

Most HA concepts that we’ve been using in IT for decades translate very well to public cloud, creating resilient applications doesn’t require relearning from scratch, rather just tweaking your thinking. Azure Availability Sets and Availability Zones give you great building blocks to lay a great foundation for your mission-critical applications.

The post Azure Availability Sets and Zones appeared first on Altaro DOJO | Hyper-V.

Making sure you have verified backups of your data and VMs in Azure is critical. But backup is more than just copying data, it’s part of a wider Disaster Recovery (DR) preparedness and as Azure becomes a platform for your business, your DR plan needs to be solid. In this article, we’ll look at how this can be best achieved, how to handle business-critical workloads, and the best way to use a new feature, Cross Region Restore (CRR).

A quick note – all Azure regions are made up of one or more datacenters, each datacenter has separate power, cooling and networking infrastructure. Each region also has a paired region in the same country / geographical area, ensuring that you can comply with data residency requirements whilst also providing optional replication in case of a region outage.

Azure Backup

Would you believe that in the early days of IaaS VMs becoming available in Azure, there was no platform backup system on offer? The recommendation was to run System Center Data Protection Manager (DPM) in a VM and back up your other VMs to it.

Times have definitely changed and Azure Backup is now a very capable enterprise data protection solution that safeguards much more than your Azure VMs. In fact, you can use Azure Backup to protect Linux and Windows Azure VMs, SQL server and SAP HANA VMs, Azure File shares and on-premises VMs using either the Microsoft Azure Recovery Services (MARS) agent or the Microsoft Azure Backup Server (MABS) option.

Production VMs protected in Azure Backup

Let’s start with Azure VMs, the first step is creating a vault to store backups. Each vault can hold up to 1000 VMs (a total of 2000 data sources) and you can back up each Azure VM once a day. Each region needs its own vault (if you have deployments globally) and VMs can only be backed up to a vault in its region. Each disk can be up to 32 TB in size and in total the disks for a VM can be up to 256 TB. Windows VM backups are application-aware, whereas Linux VMs are file consistent, unless you use custom scripts.

The first choice is which underlying type of Azure storage you’re going to use because once you’ve started protection this can’t be changed. You can pick from Locally Redundant Storage (LRS), three copies of your data in a single region, or Geo Redundant Storage (GRS), three copies in the local region and three additional copies in the paired region. Currently only UK South and South East Asia support the third option, Zone Redundant Storage (ZRS) for backup which spreads copies of your data across different datacenters in the same region. The default and recommended option is GRS.

Once you’ve created the vault, simply define one or more policies that specify when to backup and how long to keep the backups for. For SQL Server (in a VM) you can define log backups up to every 15 minutes.

SQL Server backup policy

When the time comes to restore (which is the point really, nobody wants backup for its own sake, what you want is the successful recovery of the VM or the data) you have several options. If you need to restore individual files, a recovery point (by default the latest one) will be mounted a local drive through a script that you download, allowing you to browse the file system and grab the files you need, as you can see here:

Script mounting drives for file recovery

When it comes time to restore a corrupted VM (or just testing your DR plan – something that you should do regularly) you can create a new VM, specifying the Resource Group (RG), virtual network (VNet) and storage account. This new VM must be created in the same region as the source (but see CRR below). You can also just restore a VMs disk(s), which will give you a template as well that you can customize and create a new VM based on the restored disks. A third option is to replace an existing VM, while the fourth option is CRR.

Backup jobs reporting in Azure Backup

If you have VMs on premises that you’d like to back up to the cloud you have three options, the MARS agent that lets you backup any Windows server, anywhere, to Azure. If you have a handful of servers this is definitely an easy option (essentially replacing Windows Server Backup with a similar tool, that includes support for Azure as a destination). MARS supports files, folders and system state and backs up twice a day but if you have more than a few servers, MABS is a better option.

MABS is a “free” version of System Center Data Protection Manager (DPM), which doesn’t support backing up to tape, nor protecting one DPM server with another. With MABS you don’t pay for the license of the server itself, instead, you pay for each protected instance. The beauty of MABS is that you first protect workloads on premises to local disk (as often as every 15 minutes if you need it) and it then synchronizes recovery points to Azure up to three times a day. This makes most recoveries much faster as data doesn’t have to be downloaded from Azure. The third option is to use DPM, with the addition of Azure as a secondary backup storage location (replacing tapes).

Note that restore operations from the cloud to on-premises are free. You don’t pay the normal data egress charges as data is downloaded.

Azure Site Recovery

Backup is essential and it’s what you need when everything else has failed. But recovering from a large-scale outage, either in the Azure platform or due to an attack such as ransomware by just restoring backups is a time-consuming proposal. There are business-critical workloads that require more than a mere backup, a full DR plan is required. This can be in the form of High Availability by spreading workloads across Availability Zones, using a load balancer to provide multi-server redundancy, distributing the data to multiple regions using Cosmos DB or putting Front Door in front of a global web application. Here, we’re going to look at Site Recovery (ASR). Symon looked at ASR in the context of on-premises, geo-distributed Hyper-V clusters in this blogpost.

Where Azure Backup is “copy your VM / data to a separate storage location on a regular cadence”, ASR is “replicating VM (and physical servers) disk changes on a continuous basis to a separate host” for very fast recovery. They’re not mutually exclusive, having tamper-proof historical backup recovery points is going to save your behind when ransomware strike or a super important document folder was deleted two weeks ago. But replication is what’s going to make you the hero when a region in Azure is down and you can bring up the replicated VMs in the paired region in minutes. Be aware that replication is continuous (with recovery points kept 24 hours by default and app consistent snapshots generated every 4 hours by default) so that if a file server VM is infected with ransomware, ASR will dutifully replicate the encrypted files to the target region almost instantaneously. This is why Azure Backup and ASR need to be used together.

ASR can replicate on-premises Hyper-V, VMware VMs or physical servers for DR and provides recovery plans to orchestrate complex applications (for example: bring up the DCs first, then the database servers, stop for a manual step to run a script to check database consistency, then start the front end servers), along with many other features. The other way to use ASR is to replicate from one Azure region to another.

You can group up to 16 VMs together into replication groups so that all VMs that make up an application also share application and crash-consistent recovery points. You can also use recovery plans, including adding automation runbooks to ensure that your VMs are started in the right order and recovery tasks are automated.

Whether for on-premises to Azure, or Azure to Azure DR, you don’t pay for VMs in the target location, just a per VM cost, plus storage costs. Only when you do a test failover or a real failover, which creates VMs do you pay VM running costs. And the first 31 days of each replicated VM is free.

Cross Region Restore

If you’re using Azure Backup to protect VMs in one region and you’ve configured the vault(s) to use GRS, you might assume that you could restore them in the secondary region at will. Not so, unless Microsoft declares a disaster in your primary region. Cross Region Restore (CRR), currently in preview, changes this dynamic and lets you decide when to restore a VM in the secondary, paired region, perhaps for testing purposes or because something’s happening to your resources in the primary region, but the problem isn’t large enough for Azure to declare an outage.

If you already have a Recovery Services vault that’s using GRS, you can enable CRR under Properties. This action cannot be undone, so you can’t turn a CRR enabled vault back to a GRS vault. Note that if you have a vault that’s using LRS and already has protected data in it you’ll need to perform some workarounds.

Enable Cross Region Restore for a vault

Conclusion

Currently, CRR supports Azure VMs (with disks smaller than 4 TB), SQL databases hosted on Azure VMs and SAP HANA databases in Azure VMs. Encrypted VM disks are supported for restore, including the built-in Storage Service Encryption (SSE) as well as Azure Disk Encryption (ADE).

CRR is based on customer feedback and it makes a lot of sense for Microsoft to provide more control for customers as to when, where and how they restore their workloads. There could be regulatory or audit reasons to test restores and CRR also obviates any waiting time for Microsoft to declare a disaster for the primary region.

Remember, just because it’s in the cloud doesn’t mean you can forget about backup and DR, your VMs are still your responsibility.

The post Cross Region Restore CRR for VMs appeared first on Altaro DOJO | Hyper-V.

In honour of the publication of The Backup Bible, I’ve extracted the top 10 most important messages from the book and compiled them into a handy reference.

The Backup Bible is a free eBook I wrote for Altaro that covers everything you need to know about planning, deploying and maintaining a secure and reliable backup and disaster recovery strategy. Download the Backup Bible Complete Edition now!

Plan for the Worst-Case Scenario

We have lots of innovative ways to protect our data. Using HCI or high-end SANs, we can create insanely fault-tolerant storage systems. We can drag files into a special folder on our computer and it will automatically create a copy in the cloud. Many document-based applications have integrated auto-saves and disk-backed temporary file mechanisms. All of these are wonderful technologies, but they can generate a false sense of security.

One specific theme drives all of my writing on backup: you must have complete, safe, separate duplicates. Nothing else counts. Many people think, “What if my hard drive fails?” and plan for that. That’s really one of your least concerns. Better questions:

• What if I make a mistake in my document and don’t figure it out for a few days?
• What if the nice lady in the next cubicle tries to delete her network files, but accidentally deletes mine?
• What if someone steals my stuff?
• What if my system has been sick but not dead for a while, and all my “saved” data got corrupted?
• What if I’m infected by ransomware?

Even the snazziest first-line defences cannot safeguard you from any of these things. Backups keep a historical record, so you can sift through your previous versions until you find one that didn’t have that mistake. They will also contain those things that should have never been removed. Backups can (and should) be taken offline where malicious villains can’t get to them.

Plan for the Worst Case-Scenario #Backup10Commandments #BackupBible – Tweet this

Use all Available Software Security and Encryption Options

Once upon a time, no one really thought about securing backups. The crooks realized that and started pilfering backup tapes. Worse, ransomware came along and figured out how to hijack backup programs to destroy that historical record as well.

Backup vendors now include security measures in their products. Put them to good use.

Use all Available Software Security and Encryption Options #Backup10Commandments #BackupBible – Tweet this

Understand the Overlap Between Active Data Systems and Backup Retention Policies

The longer you keep a backup, the taller the media stack gets. That means that you have to pay more for the products and the storage. You have to spend more time testing old media. You have to hold on to archaic tape drives and disk bus interfaces or periodically migrate a bunch of stale data. You might have ready access to a solution that can reduce all of that.

Your organization will establish various retention policies. In a nutshell, these define how long to keep data. For this discussion, let’s say that you have a mandate to retain a record of all financial transactions for a minimum of ten years. So, that means that you need to keep backup data until it’s ten years old, right? Not necessarily.

In many cases, the systems used to process data have their own storage mechanisms. If your accounting software retains information in its database and has an automatic process that keeps data for ten years and then purges it, then the backup that you captured last night has ten-year-old data in it.

Does that satisfy your retention policy? Perhaps, perhaps not. Your retention policy might specifically state that backups must be kept for ten years, which does not take the data into consideration. Maybe you can go to management and get the policy changed, but you might also find out that it is set by law or regulation. Even if you are not bound by such restrictions, you might still have good reason to continue keeping backups long-term. Since we’re talking about a financial database, what if someone with tech skills and a bit too much access deletes records intentionally? Instead of needing to hide their malfeasance for ten years, they only need to wait out whatever punctuated schedule you come up with. Maybe accounting isn’t the best place to try out this space-saving approach.

Understand the Overlap Between Active Data Systems and Backup Retention Policies #Backup10Commandments #BackupBible – Tweet this

High Availability is a Goal, Not a Technology

We talk a lot about our high availability tech and how this is HA and that is HA. Really, we need to remember that “high availability” is a metric. How about that old Linux box running that ancient inventory system that works perfectly well but no one can even find? If it didn’t reboot last year, then it had 100% uptime. That fits the definition of “highly available”.

You can use a lot of fault-tolerant and rapid recovery technologies to boost availability, but a well-implemented backup and disaster recovery plan also helps. All of the time that people spend scrounging for tapes and tape drive manuals counts against you. Set up a plan and stick to it, and you can keep your numbers reasonable even in adverse situations.

High Availability is a Goal, Not a Technology #Backup10Commandments #BackupBible – Tweet this

5. Backup and Disaster Recovery Strategies are Not the Same Thing

If your disaster recovery plan is, “Take backups every night,” then you do not have a disaster recovery plan.

Backup is a copy of data and the relevant technologies to capture, store, and retrieve it. That’s just one piece of disaster recovery. If something bad happens, you will start with whatever is leftover and try to return to some kind of normal state. That means people, buildings, and equipment as much as it means important data.

The Backup Bible goes into much more detail about these topics.

Backup and Disaster Recovery Strategies are Not the Same Thing #Backup10Commandments #BackupBible – Tweet this

Backup Applies to Everyone in an Organization, so Include Everyone

The servers and backup systems live in the IT department (or the cloud), but every department and division in the organization has a stake in its contents and quality. Keep them invested and involved in the state of your backup and disaster recovery systems.

Backup Applies to Everyone in an Organization, so Include Everyone #Backup10Commandments #BackupBible – Tweet this

One Backup is Never Enough

I said in the first commandment that for a proper backup, you must have complete, safe, separate duplicates. A single duplicate is a bare minimum, but it’s not enough. Backup data gets corrupted or stolen just as readily as anything else. You need multiple copies to have any real protection.

Whether you take full backups every week or every month, take them frequently. Keep them for a long time.

One Backup is Never Enough #Backup10Commandments #BackupBible – Tweet this

One Size Does Not Fit All

It would be nice if we could just say, “Computer, back up all my stuff and keep it safe.” Maybe someday soon we’ll be able to do that for our personal devices. It’s probably going to be a bit longer before we can use that at the enterprise scale. In the interim, we must do the work of figuring out all the minutiae. Until we have access to a know-it-all-program and a bottomless storage bucket, we need to make decisions about:

• Using different retention policies on different types of data
• Using different storage media and locations
• Overlapping different backup applications to get the most out of their strengths

As an example of the last one, I almost always configure Microsoft SQL to capture its own backups to a network location and then pull the .bak files with a fuller program. Nobody really backs up and restores Microsoft SQL as well as Microsoft, but just about everyone has better overall backup features. I don’t have to choose.

One Size Does Not Fit All #Backup10Commandments #BackupBible – Tweet this

Test It. Then Test again. And Again…

Your backup data is, at best, no better than it was the last time that you tested it. If you’ve never tested it, then it might just be a gob of disrupted magnetic soup. Make a habit of pulling out those old backups and trying to read from them. Your backup program probably has a way to make this less tedious. Set bi-annual or quarterly reminders to do this.

Test It. Then Test again. And Again… #Backup10Commandments #BackupBible – Tweet this

Backup and Disaster Recovery Planning is a Process, Not a One-Time Event

The most important and most often overlooked aspect of all backup and disaster recovery planning is employing a “set and forget” mentality. Did you set up a perfect backup and disaster recovery plan five years ago? Awesome! How much of the things that were true then are true now? If it’s less than 100%, your plan needs some updating. Make a scheduled recurring event to review and update the backup process. Remember the 6th commandment. Hint: If you feed them, they will come.

Backup and Disaster Recovery Planning is a Process, Not a One-Time Event #Backup10Commandments #BackupBible – Tweet this

Free eBook – The Backup Bible Complete Edition

I’d love to be able to tell you creating a backup and disaster recovery strategy is simple but I can’t. It takes time to figure out your unique backup requirements, business continuity needs, software considerations, operational restrictions, etc. and that’s just the start. I’ve been through the process many, many times and as such Altaro asked me to put together a comprehensive guide to help others create their own plan.

The Backup Bible Complete Edition features 200+ pages of actionable content divided into 3 core parts, including 11 customizable templates enabling you to create your own personalized backup strategy. It was a massive undertaking but hopefully, it will help a lot of people protect their data properly and ensure I hear fewer data-loss horror stories from the community!

Download your free copy

The post The Ten Commandments of Backup appeared first on Altaro DOJO | Hyper-V.

You start deploying new workloads into public cloud, then start migrating some workloads from on-premises, and all of a sudden what used to be a small part of your entire IT infrastructure is business-critical and hosted in the cloud. And your boss, and her boss, are asking you uncomfortable questions about security and control. Sound familiar?

Fear not – this article will lay out foundations for how to think about security in Azure, steps to take and how to think differently about security in the cloud.

Is the Cloud secure?

The short answer is yes, at least if you look at the major cloud providers. They spend significantly more resources than most enterprises, and definitely more than SMBs, on securing their clouds. After all, the whole premise of handing over parts of your IT environment to someone else to host requires trust. A major breach at any of the three big public clouds would set the whole industry back years and give ammunition to old-timers who hug the servers in their basement like it’s 2005.

But security in the cloud requires a shift in mindset and understanding the shared responsibility model. Parts of the security tasks fall on the cloud provider but parts of it are your duty.

The shared responsibility model (Courtesy of Microsoft)

This diagram from Microsoft’s documentation shows clearly that for all three cloud models (SaaS, PaaS and IaaS), the information and data, endpoint devices and accounts and identities are always your responsibility.

We’re going to focus on IaaS and PaaS in this article and for IaaS, the identity directory Azure Active Directory (AAD), which is possibly connected to your on-premises Active Directory (AD), is yours to manage. So too are the applications in your VMs, the network controls and firewalls around them and the OS running in those VMs. You have to patch them, back them up, protect them with anti-malware and other security solutions and monitor their performance and any security breaches.

In PaaS workloads, on the other hand, there’s more grey area and it varies between different services. For instance, if you run your code in containers in Azure Kubernetes Services (AKS), you’re responsible for the code you run in the containers, configuring the network controls accurately to provide access to the right people and applications and setting up Role Based Access Control (RBAC), using the Least Privilege principle for the people that should have access to the cluster.

The fact that Azure takes over more of the security tasks as you move to PaaS also means that as you look to modernize your applications and “how you do IT” in your business, look to these more modern platform services to provide you with some extra security that you don’t get with running traditional VMs.

Azure Security Benchmark

Microsoft has a comprehensive framework called Azure Security Benchmark (ASB) currently in Version 2. Together with the Cloud Adoption Framework (CAF) which provides strategic guidance; security best practices guides and a reference implementation; the Azure Well-Architected Framework assessments and Microsoft Security Best Practices, the ASB benchmarks builds on the Center for Internet Security (CIS) controls and focus on cloud centric security.

The ASB covers controls for Network, Identity, Privileged Access, Data Protection, Asset Management, Logging and Threat Detection, Incident Response, Posture and Vulnerability Management, Endpoint Security, Backup and Recovery and Governance and Strategy. In a bit, I’ll show you what’s included in the Network controls, but each of the links above leads to the individual controls for each domain. You can also download the entire benchmark as an Excel spreadsheet.

In case you’re not familiar with CIS they’re a not-for-profit that provides security benchmarks for Ubuntu, Windows, Cisco, Docker and many, many more platforms for free. Microsoft has worked closely with them to nail down the CIS 1.1.0 benchmark that surfaces in ASC, in this screenshot from a production deployment with specific guidance for which controls have failed audit and need to be remediated.

ASC Regulatory compliance – CIS

For example, the ASB Network Security control domain recommends implementing security for internal traffic (using NSGs and/or Firewall), using ExpressRoute or VPN to connect on-premises networks to Azure plus using Virtual network peering to connect Azure virtual networks together and Azure Private Link to isolate application traffic from the internet. The next network control stipulates protecting applications using DDoS protection, Azure Firewall and Azure WAF as part of Application Gateway, Azure Front Door or Azure CDN. Deploying intrusion detection (IDS) and intrusion prevention (IDPS) is provided by third-party services or Microsoft Defender for Endpoint. The next recommendation is to simplify network security rules using Application Security Groups (ASG) to group different tiers of your application together and to use service tags to route traffic to different PaaS services securely. The final recommendation is to secure your DNS infrastructure in Azure.

I urge you to read the ASB carefully and understand the concepts and features and why they should be used. But what you really need is actionable guidance for your particular resources, tracking as you continue to improve your security. This solution is called Azure Security Center.

Azure Security Center

Once the ASB is under your belt, start securing your Azure deployments with Azure Security Center (ASC). This central portal for all things security gives you an insight into your Cloud Security Posture and can be extended to your hybrid resources, both on-premises and in AWS and GCP.

Azure Security Center Overview blade

Using security policies (built on Azure Policy), ASC applies a default policy that audits current settings such as if RBAC used on Kubernetes Services, if Vulnerability Assessment is enabled on your SQL servers or if Windows Defender Exploit Guard is enabled in your Windows VMs, along with another 64 policies (at the time of writing).

Azure Security Center Recommendations

On top of that – under the Recommendations blade you’ll find Secure Score – a list of improvements you can make in your deployment ranked based on which step will advance your security posture the most. The challenge for most under-resourced IT departments isn’t the availability of security tools and configurations, it’s knowing where to start and what impact turning on security feature X will have. This is where Secure Score shines – giving you insight into exactly what configuration changes to make, which risks it will mitigate and the likely impact on your resources. Here’s an example of a production IaaS Windows Server 2016 SQL Server VM and it’s associated vulnerabilities.

ASC SQL Server vulnerability list

ASC also provides Security alerts for all monitored assets, an Inventory blade of all Azure deployed resources (if you don’t know what you have, you can’t protect it) and a Workflow automation blade to build Logic Apps, low or no-code apps that can be triggered from an ASC alert or recommendation to automatically remediate the issue.

Furthermore, if you have specific regulations that your cloud deployments must adhere to you can use the Regulatory compliance blade to take steps to comply with PCI DSS 3.2.1, ISO 27001, SOC TSP or Azure CIS 1.1.0.

As mentioned, there is also a Cloud connector blade where you can add an AWS and/or a GCP account, this is currently in preview. This uses Azure Arc to deploy the Log Analytics agent to the AWS or GCP instances and also connects to the AWS Security Hub or the GCP Security Command, so you are not only getting Azure’s recommendations but also alerts from the other platforms.

The free tier of ASC is a good place to start, but for production, deployments look to what used to be called ASC Standard tier and is now known as Azure Defender, pricing available in the official documentation.

Azure Security Best Practices

Providing comprehensive guidance on how to secure your Azure resources is beyond the scope of this article, and I don’t want to duplicate excellent official guidance, but here are my recommendations for you.

First of all, be prepared to change your mindset. Bringing your traditional, on-premises security lens to the cloud will not work. Read up on Zero Trust, understand the concept of identity being the new firewall, and see the possibilities that Azure brings to the table for securing your IT assets. Take micro-segmentation for instance, which is creating isolated networks for each application or service within your private network with limited communication with other parts. The idea is that when an attacker manages to get a foothold in your network, the blast radius is limited, and they have to work hard to move laterally to another part of the network. This is VERY hard to do on-premises but relatively easy in the cloud.

Make sure all your administrators are using MFA, there’s no excuse not to protect every privileged account with strong authentication (and no – a long password is not “strong authentication”). Using biometrics with Windows Hello for Business is better, and FIDO 2 hardware authentication is better yet.

For administration of your cloud resources, ensure that Windows VMs aren’t having the RDP port open to the internet, nor Linux servers publishing SSH, either use Just in Time (JIT) access or better still – use Azure Bastion.

Use the security monitoring provided by ASC and definitely connect your workload logs to a SIEM for in-depth visibility, if you don’t have a SIEM already, Azure Sentinel is an option that Microsoft is putting a lot of resources into.

Make sure you backup all your workloads and for business-critical services, have replication to a secondary region, in case of a major outage in one region. All Azure regions have another region as a pair in the same geography, so you can comply with any data residency regulations whilst still ensuring business continuity.

Conclusion

A question I sometimes get (as an IT Consultant) is whether AWS is more secure than Azure which reminds me of the debates from yesteryear about whether Linux or Windows (or Hyper-V vs VMware) is more secure. The answer is – if you configure it correctly and use the provided security features and measurements wisely – either AWS or Azure can be secure, neither platform is inherently more secure.

The post Why you should be using Azure Security Benchmark appeared first on Altaro DOJO | Hyper-V.