Mastering Windows Security and Hardening
上QQ阅读APP看书,第一时间看更新

Using Azure services to manage Windows servers

As discussed in the Understanding Windows Server management tools section, Windows Admin Center exposes Azure cloud services that can provide additional benefits for managing Windows servers. It is recommended that you start moving workloads to the cloud not only as part of your digital transformation, but also as a security initiative. Azure Active Directory roles and role-based access control (RBAC) allow for a fine-grained level of access provisioning over the management plane. In the next section, you will learn about the Azure services that are available for managing Windows servers for both IaaS and on-premises deployments. We will cover the following topics:

  • The Azure portal and Marketplace
  • RBAC
  • Azure Resource Manager
  • Azure Backup
  • Azure Update Management
  • Azure Site Recovery

The Azure portal and Marketplace

Simply put, the Azure portal is the user interface that's used to manage resources in the Azure cloud. Most operations can be performed directly through the Azure portal, but some advanced configurations will require the Azure Command-Line Interface (CLI), Azure PowerShell, or direct calls to the Graph API. Microsoft is doing a great job of adding many operations only supported by these command-line tools directly to the user interface in the portal. Follow these steps to access the portal:

  1. Open a browser and navigate to https://portal.azure.com.
  2. Sign in with your Azure account username and password.
  3. If you don’t have an Azure account, click Create one! to set one up.

To view and access your virtual servers within the Azure portal, simply click on Virtual Machines. You will be provided with the Virtual machines management page:

Fig 3.13 – Microsoft Azure portal Virtual machines page

We won't be going into detail around navigating the Azure portal, but we do want to call it out as an important tool for not only managing Windows servers, but also all cloud resources. For detailed instructions on customizing its look and feel, as well as creating custom dashboards and setting favorites, you can visit https://docs.microsoft.com/en-us/azure/azure-portal/azure-portal-overview.

Using the Azure Marketplace

The Azure Marketplace is the storefront in Azure where you purchase resources and solutions and deploy them directly to your tenant. There are many offerings available, from custom VM images, to databases, networking solutions, IoT, DevOps, and more. It can be accessed from the Azure portal or by going to https://azuremarketplace.microsoft.com/en-us/marketplace/.

In respect to Windows Server, the marketplace is useful for deploying pre-built images, which can be done in just a few clicks directly from the portal. You can use the Azure Marketplace to customize and create a Windows Server instance and then capture the customizations in a JSON template. By using this JSON, multiple servers can now be deployed at scale with all your custom configurations:

Figure 3.14 – Windows Server purchasing option from the Azure Marketplace in the Azure portal

With Azure Active Directory roles and role-based access controls, resource creation is typically locked down for Global Administrators or roles with contributor rights.

Next, we'll look at how to lock down access to Azure resources by implementing RBAC. We will also learn how to create a custom role using PowerShell and JSON.

Implementing role-based access control

RBAC in Azure is used to authorize access to resources through role assignments. A role assignment consists of a user, group, or service principal that has a set of permissions assigned. Those permissions are then scoped to a subscription, resource group, or resource. Permissions are inherited from parent scopes, so if a role assignment is set on the resource group level, all resources nested under that resource group will be in scope of the role assignment. When assigning permissions, RBAC takes an additive model. If the user is assigned to multiple roles, the least restrictive role won't take effect and will be assigned any additional rights for each additional role. Explicit Deny assignments must be applied to determine which set of actions are not allowed; otherwise, access is granted.

There are four main roles in Azure RBAC, and these are the standard levels of roles that can be applied to a scope. These are owner, contributor, user access administrator, and reader. Only the owner and user access administrator roles have permission to grant access rights for other users. Each role has the concept of action types such as Actions, NotActions, DataActions, and NotDataActions. When building a role definition, Actions refers to the management operations of the resource and controls things such as access, where DataActions refers to the underlying data operations such as read blobs in a container. Azure offers over 70 additional built-in RBAC roles that are preconfigured for specific use cases as they pertain to certain resources. Using JSON, you can export a built-in RBAC role and build custom roles to fit your needs. For more information regarding the role definition structure, go to https://docs.microsoft.com/en-us/azure/role-based-access-control/role-definitions.

In the following example, we will edit the Virtual Machine Contributor role and make a custom RBAC that contains all the VM contributor role permissions, including DataAction, to administratively log in to virtual machines. Let's get started:

  1. Open PowerShell as an Administrator and install the Azure module. Choose [A] Yes to All when asked to install from an untrusted repository. Then, connect to Azure using the Connect-AzAccount cmdlet and retrieve your subscription ID. Take a note of the subscription ID; you will need this later:

    Install-Module -Name Az

    Connect-AzAccount

    Get-AzSubscription | Select ID

  2. Enter your credentials at the password prompt and perform MFA to connect to your Azure tenant.
  3. The first step is to export the built-in Virtual Machine Contributor role as the JSON template to build the custom role. We will export the role definition as JSON using the Get-AzRoleDefinition cmdlet:

    Get-AzRoleDefinition -Name “Virtual Machine Contributor” | ConvertTo-Json | Out-File “C:\MyFolder\VMContributor.json”

  4. Open the VMContributor.json file we exported previously using a code editor of your choice, such as Notepad++, Code Writer, or even basic Notepad. We will need to make some modifications and save the file as a JSON, ready to be reimported.
  5. On line 2, change the value of “Name” to Administrative Virtual Machine Contributor:

    “Name”: “Administrative Virtual Machine Contributor”

  6. On line 4, change the value of “IsCustom” to true:

    “IsCustom”: true,

  7. Modify “Description” on line 5 so that it reads as follows:

    “Description”: Lets you manage virtual machines, but not access to them, and not to the virtual network or storage account they are connected to.  Allow administrator login.”,

  8. To allow administrative login, we will need to add the ARM resource provider operation called Microsoft.AAD for the DataAction action type and the Microsoft.Compute/virtualMachines/login/action and Microsoft.Compute/virtualMachines/loginAsAdmin/action operations.
  9. On line 50 in the JSON, add these two lines:

    “Microsoft.Compute/virtualMachines/login/action”,

    “Microsoft.Compute/virtualMachines/loginAsAdmin/action”

  10. Next, we need to populate the “AssignableScopes” section. If you exported the built-in role, the / root value will be prepopulated, but this is only applicable to built-in roles. Assignable scopes can be scoped to multiple subscriptions, management groups, resource groups, or resources. In this example, we are going to use the subscription ID of our tenant. The subscription ID can be found using the PowerShell cmdlet, as we saw earlier, or through the Azure portal UI and typing “subscriptions” in the search field. Modify line 57 so that it includes the subscription ID:

    “AssignableScopes”: [

    “/subscriptions/8c24xxxa2-xxxx-47xx-3d-8929345de830”

    ]

  11. Finally, save the edited JSON file. We will now import it using the New-AzRoleDefinition cmdlet:

    New-AzRoleDefinition -InputFile “C:\MyFolder\VMContributor.Json”

If its creation was successful, the custom role will be seen from the Access control (IAM) blade in your Azure subscription:

Figure 3.15 – Successful creation of the Administrative Virtual Machine Contributor role in the Azure portal

For more information about the resource provider operations that are available, visit this link: https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations.

For more information about JSON, visit this link: https://www.w3schools.com/whatis/whatis_json.asp.

Next, we'll take a look at the current management plane for Azure resources, which is called Azure Resource Manager.

Azure Resource Manager

It is important to be aware of Azure Resource Manager if you're working with Azure cloud to deploy Windows servers and other infrastructure. Currently, Azure Resource Manager is defined as a highly resilient management plane for all services that run in Azure. Any controls used that directly affect the management and security of resources is done through Azure Resource Manager. Azure Resource Manager, or ARM for short, can be manipulated directly using the Azure portal, Azure PowerShell, Azure CLI, or through APIs and custom tools developed with a software development kit (SDK). Custom templates written in JSON can be created and declaratively deploy resources repeatedly, at scale, and tracked directly in the Azure portal. More information about creating Azure Resource Manager templates, including the sections that make up the JSON, can be found at https://docs.microsoft.com/en-us/azure/azure-resource-manager/template-deployment-overview.

Tip

Additional information, including key terminology, benefits, and a descriptive understanding of the scope of the management plane, can be found at https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview.

In the next section, we will talk about using Azure Backup for creating backups of our servers.

Understanding Azure Backup

Azure Backup is a cloud service that can be used to replace an on-premises backup solution or used as an automatic storage management tool for hybrid scenarios where data is stored both on-premises and in the cloud. It requires zero infrastructure, has unlimited scaling capabilities, provides application-consistent backups, and data is encrypted both in transit and at rest. Azure Backup offers unlimited data transfers ingress and egress from Azure at no additional cost. There are locally redundant (LRS) and geo-redundant (GRS) storage options available, depending on your high availability needs. There is no time limit regarding data retention, and you can store up to 9,999 recovery points.

Important Note

For additional information on the Azure Backup service, go to https://docs.microsoft.com/bs-latn-ba/azure/backup/backup-overview.

In Windows Admin Center. you can take advantage of the built-in management and monitoring tools all from within the Backup dashboard.

Azure Backup's requirements include the following:

  • A valid subscription
  • Resource Group
  • Recovery Services Vault
  • Agent Deployment

Azure Backup includes Application- and Crash-consistent backups:

  • Application-Consistent Backup: Use Windows VSS writers to create the backup and capture memory content and pending I/O operations. When recovering a VM using an app-consistent snapshot, there is no data loss.
  • Crash-Consistent Backup: This occurs if an Azure VM shuts down during the time of a backup. Only disk data at the time of the backup is captured and a recovery doesn’t guarantee data consistency.

These two options can be seen in the following screenshot:

Fig 3.16 – Restore points of a Windows Azure VM with Application-Consistent restore points

Securing Azure Backup

For on-premises backups, encryption is done using a customer-specified passphrase. Once in transit, data is encrypted using AES256 and sent over HTTPS to Azure. For Azure VMs, data at rest is encrypted using Storage Service Encryption (SSE) and protected by HTTPS in transit while never leaving Azure. Azure Backup can also back up VMs that are encrypted using Azure Disk Encryption.

Tip

For customer specified passphrases, DO NOT lose the encryption passphrase. It is required to restore backups. Microsoft CANNOT recover this for you.

Backup data contains highly critical information and needs to be properly secured from unauthorized access. Access can be managed using Azure RBAC. Authentication also takes place through Azure Active Directory and monitoring is supported using Log Analytics. Let's highlight the built-in RBAC roles for Azure Backup:

  • Backup Contributor has permissions to create and manage backups but cannot grant access or delete Recovery Services vaults.
  • Backup Operator has similar permissions to the contributor except for removing backups and changing policies.
  • Backup Reader can view all backup operations for monitoring purposes only.

For hybrid scenarios, additional security features are available, such as configuring retention periods, notifications for changes, and the ability to create security pins.

Another security feature for backups is soft delete. Soft delete is a feature that retains backups for 14 days after a deletion action and allows recovery without data loss at no additional cost. While this feature is enabled by default, you can permanently delete soft deleted backup items immediately or disable the feature altogether.

Important note

More information about Azure Backup RBAC can be found at https://docs.microsoft.com/en-us/azure/backup/backup-rbac-rs-vault.

In the next section, we will discuss using Azure Update Management to deploy updates to our servers.

Introducing Azure Update Management

As described earlier in Using Windows Server Update Services , Update Management is the Azure cloud-based solution to managing system updates for Windows. Update Management is available for the cloud and on-premises deployments.

The requirements to deploy Azure Update Management are as follows:

  • Azure Subscription
  • New or existing resource group
  • Log Analytics workspace
  • Azure Automation account
  • Deployment of the Microsoft Monitoring Agent (MMA)
  • Microsoft Update or WSUS configured on your systems

Update Management can be deployed using Windows Admin Center by following the onboarding steps directly in the portal. For information about onboarding multiple VMs from the Azure portal, go to https://docs.microsoft.com/en-us/azure/automation/automation-onboard-solutions-from-browse. The following is a screenshot of Update Management from the Azure portal automation account:

Figure 3.17 – Update Management dashboard, which shows the update compliance of inpidual Windows servers

The compliance comparison for the servers listed in the Update Management page will be compared to your WSUS server or directly to Windows Update services. Machines can be added by clicking on Add Azure VMs at the top of the page. For Non-Azure servers, the Microsoft Monitoring Agent can be deployed and configured to use the Update Management Log Analytics workspace during setup or when onboarded with Windows Admin Center. The following screenshot shows the missing updates tab, which lists all missing updates from your systems and includes columns that display details about the update name, classification, machines missing updates, operating system, and a KB information hyperlink:

Figure 3.18 – Overview of available updates and the machines missing each update

Update deployments using update groups can be scheduled using the Schedule Update Deployment option at the top of the toolbar. Update groups can be created by using dynamic queries based on resource groups, locations, and tags, or you can explicitly select the machines you wish to include. There is a dropdown to scope which classification of update to deploy, as well as options to include or exclude specific KBs. The schedule settings allow you to set a one-time or recurring deployment. Additional options include setting a maintenance window time and several options for reboot behaviors.

The deployment status can be monitored with alerts using Azure Monitor. Action groups allow notifications via email/SMS/push/voice and can even trigger a webhook or Azure Automation runbook.

For additional information about the Update Management solution in Azure, go to https://docs.microsoft.com/en-us/azure/automation/automation-update-management.

The following are the Windows operating systems supported by Azure Update Management:

  • Windows Server 2019
  • Windows Server 2016
  • Windows Server 2012 and R2
  • Windows Server 2008 R2

    Tip

    Windows Clients and Windows 2016 Nano Server are not supported at this time.

We will cover how to set up and configure Azure Update Management in more detail in Chapter 10, Keeping Your Windows Server Secure.

Next, we'll look at Azure Site Recovery (ASR). Azure Site Recovery can be used as a disaster recovery scenario or as a tool to move systems in Azure.

Leveraging Azure Site Recovery

Azure Site Recovery is a business continuity and disaster recovery solution built into Azure for all types of workloads. The solution covers both Azure and on-premises Windows servers and VMs. Azure Site Recovery (ASR) consists of two major components:

  • Site Recovery Services: Used for the replication of virtual machines and workloads from a primary to a secondary region in Azure.
  • Backup Services: Azure Backup service for data backup and recovery.

For more information on Azure Site Recovery, visit this link:

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-overview

When building a business continuity (BC) and disaster recovery (DR) strategy, most organizations outline recovery time objectives (RTOs) and recovery point objectives (RPOs) for business-critical services and applications. By using the Azure Site Recovery service, these workloads and virtual machines are replicated from primary to secondary sites. If a regional outage occurs in Azure, you can initiate a failover to the secondary region to meet the RTO/RPO objectives of the business continuity plan. Let's take a look at these in more detail:

  • Recovery Time Objective (RTO): The established duration of time for each business process in which services must be restored to meet SLAs.
  • Recovery Point Objective (RPO): The maximum amount of data that could be lost during a major outage. For example, if the RPO is 24 hours and the last backup was completed 6 hours ago at the time of an outage, there is 18 hours of time until the business will suffer a significant volume of data loss, as defined by the business objective’s RPO.

ASR supports building customized recovery plans that allow you to strategically plan what services, VMs, and critical infrastructure fail over and when. Using PowerShell and Azure Automation, many tasks during the failover/recovery process can be automated. ASR also supports testing the failover through recovery plans. Using the overview dashboard, organizations can monitor the site recovery and backup of resources that are scoped for the Azure Site Recovery service:

Figure 3.19 - Site Recovery dashboard view, which shows an overview of configured recovery services

Tip

Azure Site Recovery is a great solution for migrating on-premises machines to Azure using the same steps that were defined for disaster recovery, but without the failback! For more information, go to https://docs.microsoft.com/en-us/azure/site-recovery/migrate-tutorial-on-premises-azure.

There is an overwhelming number of tools and services available in Azure that support the management of your Windows infrastructure and Azure environment. Unfortunately, we won't be able to cover them all in this book, but you can view a comprehensive list of all Azure resources here: https://azure.microsoft.com/en-us/services/.