Section 5 – Design security for infrastructure – Design a strategy for securing server and client endpoints

Wednesday is here and time for the next post to my SC-100 exam cram.

NOTE: includes hybrid and multi-cloud

• Specify security baselines for server and client endpoints
• Specify security requirements for servers, including multiple platforms and operating systems
• Specify security requirements for mobile devices and clients, including endpoint protection, hardening, and configuration
• Specify requirements to secure Active Directory Domain Services
• Design a strategy to manage secrets, keys, and certificates
• Design a strategy for secure remote access

Specify security baselines for server and client endpoints

Microsoft has a baseline settings for Windows with Azure Policy that could be followed.

But also for Linux machines.

Servers

SCT

One option is to use Microsoft SCT. With it you can evaluate even the on-premises environments.

ARC

Or you can use Azure ARC and Defender for Cloud to see the state your servers are, even for On-premises servers

Client endpoints

Microsoft has security baselines for clients inside endpoint.microsoft.com

From here you can make your own baseline also.

All the baseline settings for Windows 10/11 are defined here.

Specify security requirements for servers, including multiple platforms and operating systems

Protect VMs by using authentication and access control

For the topics of identity and access, we discussed using strong authentication and authorization to
protect data and resources. The first step in protecting your VMs is to ensure that only authorized
users can set up new VMs and access VMs.

Note: To improve the security of Linux VMs on Azure, you can integrate with Azure AD
authentication. When you use Azure AD authentication for Linux VMs, you centrally control and
enforce policies that allow or deny access to the VMs.

Best practice	Solution
Control VM access.	Use Azure policies to establish conventions for resources in your organization and create customized policies. Apply these policies to resources, such as resource groups. VMs that belong to a resource group inherit its policies. If your organization has many subscriptions, you might need a way to efficiently manage access, policies, and compliance for those subscriptions. Azure management groups provide a level of scope above subscriptions. You organize subscriptions into management groups (containers) and apply your governance conditions to those groups. All subscriptions within a management group automatically inherit the conditions applied to the group. Management groups give you enterprise-grade management at a large scale no matter what type of subscriptions you might have.
Reduce variability in your setup and deployment of VMs.	Use Azure Resource Manager templates to strengthen your deployment choices and make it easier to understand and inventory the VMs in your environment.
Secure privileged access.	Use a least privilege approach and built-in Azure roles to enable users to access and set up VMs: Virtual Machine Contributor: Can manage VMs, but not the virtual network or storage account to which they are connected. Classic Virtual Machine Contributor: Can manage VMs created by using the classic deployment model, but not the virtual network or storage account to which the VMs are connected. Security Manager: Can manage security components, security policies, and VMs. DevTest Labs User: Can view everything and connect, start, restart, and shut down VMs. Note: Your subscription admins and co-admins can change this setting, making them administrators of all the VMs in a subscription. Be sure that you trust all of your subscription admins and co-admins to log in to any of your machines.

Keep your servers updated

Automanage

Automanage can be used for Windows and Linux virtual machines and it includes the following components.

Updates

There is Update management center which is still in preview that you could use.

Use Service tags

Do You know about Azure Service tags?

With Service tags Microsoft defines services and their addresses, no more manually adding addresses to multiple services thanks to Service tags. What tags are currently supported? Bare in mind that…

Secure privileged access

Use a least privilege approach and built-in Azure roles to enable users to access and set up VMs:

• Virtual Machine Contributor: Can manage VMs, but not the virtual network or storage account to which they are connected.
• Classic Virtual Machine Contributor: Can manage VMs created by using the classic deployment model, but not the virtual network or storage account to which the VMs are connected.
• Security Admin: In Defender for Cloud only: Can view security policies, view security states, edit security policies, view alerts and recommendations, dismiss alerts and recommendations.
• DevTest Labs User: Can view everything and connect, start, restart, and shut down VMs.

Enable encryption on VMs

Azure Disk Encryption helps you encrypt your Windows and Linux IaaS virtual machine disks. Azure Disk Encryption uses the industry-standard BitLocker feature of Windows and the DM-Crypt feature of Linux to provide volume encryption for the OS and the data disks.

Azure Disk Encryption generates and writes the encryption keys to your key vault. Managing encryption keys in your key vault requires Azure AD authentication. Create an Azure AD application for this purpose. For authentication purposes, you can use either client secret-based authentication or client certificate-based Azure AD authentication.

Use key encryption key (KEK)

Use the Add-AzKeyVaultKey cmdlet to create a key encryption key in the key vault. You can also import a KEK from your on-premises hardware security module (HSM) for key management. For more information, see the Key Vault documentation. When a key encryption key is specified, Azure Disk Encryption uses that key to wrap the encryption secrets before writing to Key Vault. Keeping an escrow copy of this key in an on-premises key management HSM offers additional protection against accidental deletion of keys.

Restrict direct internet connectivity

Use Microsoft Defender for Cloud

Defender for Cloud will recommend that you restrict access through internet-facing endpoints if any of your network security groups has one or more inbound rules that allow access from “any” source IP address. Defender for Cloud will recommend that you edit these inbound rules to restrict access to source IP addresses that actually need access.

Restrict management ports (RDP, SSH)

Just-in-time (JIT) VM access can be used to lock down inbound traffic to your Azure VMs, reducing exposure to attacks while providing easy access to connect to VMs when needed. When JIT is enabled, Defender for Cloud locks down inbound traffic to your Azure VMs by creating a network security group rule. You select the ports on the VM to which inbound traffic will be locked down. These ports are controlled by the JIT solution.

Specify security requirements for mobile devices and clients, including endpoint protection, hardening, and configuration

Enroll your devices to Intune

Device limit restrictions can be configured two ways:

• Intune enrollment
• Azure Active Directory (AD) joined or Azure AD registered

Settings applied based on user affinity

If you have both Intune and Azure device limit restrictions set, the following table shows you what is applied based on your user affinity setting.

Device platform	User affinity	Azure applies	Intune applies
Android Enterprise personally-owned work profile	Yes	Yes	Yes
Android Enterprise dedicated device	No	No	No
Android Enterprise fully managed	Yes	Yes	Yes
Android Enterprise corporate-owned work profile	Yes	Yes	Yes
Android device administrator	Yes	Yes	Yes
Android device administrator DEM	No		No
iOS/macOS BYOD	Yes	Yes	Yes
iOS/macOS Automated Device Enrollment (ADE)	Yes	Yes	Yes
Windows BYOD	Yes	Yes	Yes
Windows MD-only		Yes	Yes
Windows Azure AD joined	Yes	Yes	No
Windows Autopilot	Yes	Yes	No
Windows hybrid Azure AD joined	No	No	Yes
Windows co-management	No	Yes	No
Windows DEM	No	Yes	No
Windows bulk enrollment	No	Yes	No

What happens when enrolled?

At the time of enrollment, Intune automatically assigns corporate-owned status to devices that are:

• Enrolled with a device enrollment manager account (all platforms)
• Enrolled by using Google Zero Touch
• Enrolled by using Knox Mobile Enrollment
• Enrolled with the Apple Device Enrollment Program, Apple School Manager, or Apple Configurator (iOS/iPadOS only)
• Identified as corporate-owned before enrollment with an international mobile equipment identifier (IMEI) numbers (all platforms with IMEI numbers) or serial number (iOS/iPadOS and Android)
• Enrolled as Android Enterprise corporate-owned devices with work profile
• Enrolled as Android Enterprise fully managed devices
• Enrolled as Android Enterprise dedicated devices
• Joined to Azure Active Directory with work or school credentials. Devices that are Azure Active Directory registered will be marked as personal.
• Set as corporate in the device’s properties list

After enrollment, you can change the ownership setting between Personal and Corporate.

Device security and configuration

Capability	Details	More information
Configuration policies Custom policies	Lets you manage many settings and features on mobile devices in your organization. For example, you can require a password, limit the number of failed attempts, limit the amount of time before the screen locks, set password expiration, and prevent previously used passwords. You can also control the use of hardware and software features such as the device camera or the web browser. Use custom policies when configuration policies do not contain the settings that you require. For iOS/iPadOS devices, you can import settings that you exported from the Apple Configurator tool. For other devices, you can use Open Mobile Alliance Uniform Resource Identifier (OMA-URI) settings to configure settings and features on the device.	Manage settings and features on your devices with Microsoft Intune policies
Remote Wipe, Remote Lock, and Passcode Reset	Erases sensitive data when a device is lost or stolen. For example, you can remotely lock the device, restore it to factory settings, or wipe only corporate data. You can reset passcodes if users lose access to their device, lock missing or stolen devices, or even wipe data off of missing or stolen devices.	Help protect your devices with remote lock and passcode reset
Kiosk mode	Lets you lock down certain features of mobile devices such as screen captures and power switches. Also lets you restrict devices to run a single app that you specify.	iOS configuration policy settings in Microsoft Intune
Autopilot Reset	Sends a task to the device to start the reset process remotely, avoiding the need for IT staff or other administrators to visit each machine to start the process. When Autopilot reset is used on a device, the device’s primary user will be removed. The next user who signs in after the reset will be set as the primary user.	Remote Windows Autopilot Reset

App management

Capability	Details	More information
App deployment and management	Provides a range of tools to help you manage mobile apps through their lifecycle, including app deployment from installation files and app stores, detailed monitoring of app status, and app removal.	Deploy apps in Microsoft Intune
Compliant and noncompliant apps	Lets you specify lists of compliant apps (that users are allowed to install) and noncompliant apps (that users aren’t allowed to install).	iOS policy settings in Microsoft Intune
Mobile application management	Configures restrictions for apps by using mobile application management for all devices that are both managed with Intune and not managed with Intune. You can increase the security of your company data by restricting operations such as copy and paste, external backup of data, and the transfer of data between apps.	Configure and deploy mobile application management policies in the Microsoft Intune console
iOS mobile app configuration	Uses mobile app configuration policies to supply settings for iOS/iPadOS apps that might be required when the user runs the app. For example, an app might require the user to specify a port number or logon information. You can streamline app configuration and reduce the number of support calls.	Configure iOS/iPadOS apps with mobile app configuration policies in Microsoft Intune
iOS/iPadOS mobile app provisioning profiles	Helps you deploy provisioning profiles to iOS/iPadOS apps that are nearing expiration.	Use iOS/iPadOS mobile provisioning profile policies to prevent your apps from expiring
Managed browser	Configures managed browser policies to control the websites that device users can visit. In addition, you can also apply mobile application management policies to the managed browser.	Manage Internet access using managed browser policies with Microsoft Intune
Windows Hello for Business	Lets you integrate with Windows Hello for Business, which is an alternative sign-in method for Windows 10 that uses on-premises Active Directory or Azure Active Directory to replace passwords, smart cards, or virtual smart cards.	Control Windows Hello for Business settings on devices with Microsoft Intune
Volume purchased apps	Helps you manage apps that you purchased through a volume-purchase program by importing the license information from the app store, tracking how many of the licenses you have used, and preventing you from installing more copies of the app than you own.	Manage volume-purchased apps using Microsoft Intune

Company resource access

Capability	Details	More information
Certificate profiles	Creates and deploys trusted certificate profiles and Simple Certificate Enrollment Protocol (SCEP) certificates, which can be used to secure and authenticate Wi-Fi, VPN, and email profiles.	Secure resource access with certificate profiles in Microsoft Intune
Wi-Fi profiles	Deploys wireless network settings to your users. By deploying these settings, you minimize the user effort that’s required to connect to the corporate network.	Wi-Fi connections in Microsoft Intune
Email profiles	Creates and deploys email settings to devices so that users can access corporate email on their personal devices without any required setup on their part.	Configure access to corporate email using email profiles with Microsoft Intune
VPN profiles	Deploys VPN settings to users and devices in your organization. By deploying these settings, you minimize the user effort that’s required to connect to resources on the company network.	VPN connections in Microsoft Intune
Conditional Access policies	Manages access to Microsoft Exchange email and SharePoint Online from devices that are not managed by Intune.	Restrict access to email and SharePoint with Microsoft Intune

Reporting

You can also get reports from the failed devices.

Specify requirements to secure Active Directory Domain Services

Tier model

Securing AD DS, well that’s a legacy subject but let’s how well you know the basics of secure deployments.

You should always keep in mind that AD DS should be treated as TIER 0, which means it shouldn’t be in contact with internet and you should by any means keep it safe as possible.

Designing security

Elevation of Privilege in Active Directory forests

Users, services, or applications accounts that are granted permanent administrative privileges to Windows Server Active Directory (AD) forests introduce a significant amount of risk to the organization’s mission and business. These accounts are often targeted by attackers because if they are compromised, the attacker has rights to connect to other servers or applications in the domain.

The tier model creates divisions between administrators based on what resources they manage. Admins with control over user workstations are separated from those that control applications, or manage enterprise identities.

Restricting credential exposure with logon restrictions

Reducing credential theft risk for administrative accounts typically requires reshaping administrative practices to limit exposure to attackers. As a first step, organizations are advised to:

• Limit the number of hosts on which administrative credentials are exposed.
• Limit role privileges to the minimum required.
• Ensure administrative tasks are not performed on hosts used for standard user activities (for example, email and web browsing).

The next step is to implement logon restrictions and enable processes and practices to adhere to the tier model requirements. Ideally, credential exposure should also be reduced to the least privilege required for the role within each tier.

Logon restrictions should be enforced to ensure that highly privileged accounts do not have access to less secure resources. For example:

• Domain admins (tier 0) cannot log on to enterprise servers (tier 1) and standard user workstations (tier 2).
• Server administrators (tier 1) cannot log on to standard user workstations (tier 2).

Logon restrictions can be enforced with:

• Group Policy Logon Rights Restrictions, including:
  • Deny access to this computer from the network
  • Deny logon as a batch job
  • Deny logon as a service
  • Deny logon locally
  • Deny logon through Remote Desktop settings
• Authentication policies and silos, if using Windows Server 2012 or later
• Selective authentication, if the account is in a dedicated admin forest

Consider the following for your PAW

• Verify all media in the build as clean to mitigate against malware installed in a master image or injected into an installation file during download or storage.
• Security Baselines should be used as starting configurations. The Microsoft Security Compliance Manager (SCM) can help configure the baselines on administrative hosts.
• Secure Boot to mitigate against attackers or malware attempting to load unsigned code into the boot process.
• Software restriction to ensure that only authorized administrative software is executed on the administrative hosts. Customers can use AppLocker for this task with an approved list of authorized applications, to help prevent malicious software and unsupported applications from executing.
• Full volume encryption to mitigate against physical loss of computers, such as administrative laptops used remotely.
• USB restrictions to protect against physical infection.
• Network isolation to protect against network attacks and inadvertent admin actions. Host firewalls should block all incoming connections except those connections explicitly required, and block all unneeded outbound Internet access.
• Antimalware to protect against known threats and malware.
• Exploit mitigations to mitigate against unknown threats and exploits, including the Enhanced Mitigation Experience Toolkit (EMET).
• Attack surface analysis to prevent introduction of new attack vectors to Windows during installation of new software. Tools such as the Attack Surface Analyzer (ASA) help assess configuration settings on a host and identify attack vectors introduced by software or configuration changes.
• Administrative privileges should not be given to users on their local computer.
• RestrictedAdmin mode for outgoing RDP sessions, except when required by the role. See What’s New in Remote Desktop Services in Windows Server for more information.

Best practices

You can gain a deeper understanding of Microsoft’s security best practices by comprehending the tiered model. An illustration of a Tier 0 asset is a Privileged Access Workstation (PAW) used by a domain administrator. To handle additional Tier 0 assets, such as domain controllers, a Tier 0 administrator must utilize a Tier 0 PAW because the account will be a part of a highly-privileged domain or forest group.

Implementing the tiered administrative paradigm is simple. It does call for extra resources, such as PAWs, and some preparation on how to limit access between the levels. It is attainable for the majority of enterprises and helps a great deal with putting in place efficient access controls that prevent hackers from jeopardizing key systems.

NIST references for hardening

Use NIST GPO security templates to apply security. Below for Server 2019

Defender for Identity

Microsoft Defender for Identity (MDI) monitors your domain controllers by capturing and parsing network traffic and using Windows events directly from your domain controllers, then analyzes the data for attacks and threats. Utilizing profiling, deterministic detection, machine learning, and behavioral algorithms Defender for Identity learns about your network, enables detection of anomalies, and warns you of suspicious activities. The image below shows the core architecture of Defender for Identity:

Once you install the Defender for Identity sensor directly on your domain controller or AD FS server, it accesses the event logs it requires directly from each server. After the logs and network traffic are parsed by the sensor, Defender for Identity sends only the parsed information to the Defender for Identity cloud service (only a percentage of the logs are sent).

Design a strategy to manage secrets, keys, and certificates

Azure Key Vault is a centralized cloud service for storing application secrets such as encryption keys, certificates, and server-side tokens. Key Vault helps you control your applications’ secrets by keeping them in a single central location and providing secure access, permissions control, and access logging. There are three primary concepts used in an Azure Key Vault: vaults, keys, and secrets.

Best practices

Best practice	Solution
Grant access to users, groups, and applications at a specific scope.	Use RBAC’s predefined roles. For example, to grant access to a user to manage key vaults, you would assign the predefined role Key Vault Contributor to this user at a specific scope. The scope, in this case, would be a subscription, a resource group, or just a specific key vault. If the predefined roles don’t fit your needs, you can define your own roles.
Control what users have access to.	Access to a key vault is controlled through two separate interfaces: management plane, and data plane. The management plane and data plane access controls work independently. Use RBAC to control what users have access to. For example, if you want to grant an application the rights to use keys in a key vault, you only need to grant data plane access permissions using key vault access policies. No management plane access is needed for this application. Conversely, if you want a user to be able to read vault properties and tags but not have any access to keys, secrets, or certificates, by using RBAC, you can grant read access to the management plane. No access to the data plane is required.
Store certificates in your key vault.	Azure Resource Manager can securely deploy certificates stored in Azure Key Vault to Azure VMs when the VMs are deployed. By setting appropriate access policies for the key vault, you also control who gets access to your certificate. Another benefit’s that you manage all your certificates in one place in Azure Key Vault.
Ensure that you can recover a deletion of key vaults or key vault objects.	Deletion of key vaults or key vault objects can be either inadvertent or malicious. Enable the soft delete and purge protection features of Key Vault, particularly for keys that are used to encrypt data at rest. Deletion of these keys is equivalent to data loss, so you can recover deleted vaults and vault objects if needed. Practice Key Vault recovery operations regularly.

Create and configure Key Vault

Basics

When you create a Key vault, you will the following options and Vault name must only contain alphanumeric characters and dashes and cannot start with a number.

You have Standard and Premium pricing tiers, in example the monthly pricing with one Managed HSM pool will the following and you will only pay for what you use

Service type	Region	Description	Estimated monthly cost	Estimated upfront cost
Key Vault	North Europe	Vault: 1 operations, 1 advanced operations, 1 renewals 1 protected keys, 1 advanced protected keys	8,72€	0,00€
		Managed HSM Pools: 1 Standard B1 HSM Pool(s) x 31 Days	2 263,66€
		Support	0,00€	0,00€
		Total	2 272,38€	0,00€

Soft delete protection will automatically be enabled on this key vault. This feature allows you to recover or permanently delete a key vault and secrets for the duration of the retention period. This protection applies to the key vault and the secrets stored within the key vault.

To enforce a mandatory retention period and prevent the permanent deletion of key vaults or secrets prior to the retention period elapsing, you can turn on purge protection. When purge protection is enabled, secrets cannot be purged by users or by Microsoft.

The ability to turn off soft delete via the Azure Portal has been deprecated. You can create a new key vault with soft delete off for a limited time using CLI / PowerShell / REST API. The ability to create a key vault with soft delete disabled will be fully deprecated by the end of the year.

Days to retain can be configured to between 7 to 90 days. Once it has been set, it cannot be changed or removed.

Enabling “purge protection” on a key vault is an irreversible action. Once the purge protection property has been set to “true”, it cannot be changed or removed.

Access policy

Virtual machine for deployment specifies whether Azure Virtual Machines are permitted to retrieve certificates stored as secrets from the key vault.

ARM template specifies whether Azure Resource Manager is permitted to retrieve secrets from the key vault.
Azure Disk Encryption permits Disk encryption to retrieve secrets from the vault and unwrap keys.

When you are adding access policy, you will the following options

Access policy permissions

Key vault supports up to 1024 access policy entries, with each entry granting a distinct set of permissions to a particular security principal.

Authorized application settings performs the specified permissions on the User’s or Group’s behalf.

RBAC

But when you enable RBAC you won’t see any options, I will go thru this on the next section.

Networking

Selected networks

You can select Select network in the connectivity methods and add existing Vnet’s and allow Microsoft trusted services to bypass the the firewall

What are Microsoft trusted services?

Trusted service	Supported usage scenarios
Azure Virtual Machines deployment service	Deploy certificates to VMs from customer-managed Key Vault.
Azure Resource Manager template deployment service	Pass secure values during deployment.
Azure Disk Encryption volume encryption service	Allow access to BitLocker Key (Windows VM) or DM Passphrase (Linux VM), and Key Encryption Key, during virtual machine deployment. This enables Azure Disk Encryption.
Azure Backup	Allow backup and restore of relevant keys and secrets during Azure Virtual Machines backup, by using Azure Backup.
Exchange Online & SharePoint Online	Allow access to customer key for Azure Storage Service Encryption with Customer Key.
Azure Information Protection	Allow access to tenant key for Azure Information Protection.
Azure App Service	App Service is trusted only for Deploying Azure Web App Certificate through Key Vault, for individual app itself, the outbound IPs can be added in Key Vault's IP-based rules
Azure SQL Database	Transparent Data Encryption with Bring Your Own Key support for Azure SQL Database and Azure Synapse Analytics.
Azure Database for MySQL	Data encryption for Azure Database for MySQL
Azure Database for PostgreSQL Single server	Data encryption for Azure Database for PostgreSQL Single server
Azure Storage	Storage Service Encryption using customer-managed keys in Azure Key Vault.
Azure Data Lake Store	Encryption of data in Azure Data Lake Store with a customer-managed key.
Azure Synapse Analytics	Encryption of data using customer-managed keys in Azure Key Vault
Azure Databricks	Fast, easy, and collaborative Apache Spark–based analytics service
Azure API Management	Deploy certificates for Custom Domain from Key Vault using MSI
Azure Data Factory	Fetch data store credentials in Key Vault from Data Factory
Azure Event Hubs	Allow access to a key vault for customer-managed keys scenario
Azure Service Bus	Allow access to a key vault for customer-managed keys scenario
Azure Import/Export	Use customer-managed keys in Azure Key Vault for Import/Export service
Azure Container Registry	Registry encryption using customer-managed keys
Azure Application Gateway	Using Key Vault certificates for HTTPS-enabled listeners
Azure Front Door	Using Key Vault certificates for HTTPS
Microsoft Purview	Using credentials for source authentication in Microsoft Purview
Azure Machine Learning	Secure Azure Machine Learning in a virtual network

Private endpoints

When you start creating a Private endpoint, you will choose a location, name and Target Sub-resource, in this case it will be Vault. Microsoft is using service tags for these. They will allow you to access service under tag and you don’t specify any IP-addresses.

Then you will specify Vnet, subnet and Private DNS. Private DNS will allow the usage with a private DNS name.

If you don’t integrate your endpoint with a DNS zone, you’ll need to create records on either your own DNS server or via host file updates on each virtual machine.

Only private DNS zones in the currently selected subscription with name ‘privatelink.vaultcore.azure.net’ will be shown. Using a private DNS zone in the same resource group as the virtual network is recommended, and if there are no existing zones that meet this criteria, one will be created.

Template

Once you are ready to deploy, you can see the template and easily learn how ARM-templates work. You could also deploy directly from the template page

Or go with manual option

Configure access to Key Vault

Authentication options

• Application-only: The application represents a service principal or managed identity. This identity is the most common scenario for applications that periodically need to access certificates, keys, or secrets from the key vault. For this scenario to work, the objectId of the application must be specified in the access policy and the applicationId must not be specified or must be null.
• User-only: The user accesses the key vault from any application registered in the tenant. Examples of this type of access include Azure PowerShell and the Azure portal. For this scenario to work, the objectId of the user must be specified in the access policy and the applicationId must not be specified or must be null.
• Application-plus-user (sometimes referred as compound identity): The user is required to access the key vault from a specific application and the application must use the on-behalf-of authentication (OBO) flow to impersonate the user. For this scenario to work, both applicationId and objectId must be specified in the access policy. The applicationId identifies the required application and the objectId identifies the user. Currently, this option isn’t available for data plane Azure RBAC.

Security principal

A security principal is an object that represents a user, group, service, or application that’s requesting access to Azure resources. Azure assigns a unique object ID to every security principal.

• A user security principal identifies an individual who has a profile in Azure Active Directory.
• A group security principal identifies a set of users created in Azure Active Directory. Any roles or permissions assigned to the group are granted to all of the users within the group.
• A service principal is a type of security principal that identifies an application or service, which is to say, a piece of code rather than a user or group. A service principal’s object ID is known as its client ID and acts like its username. The service principal’s client secret acts like its password.

For applications, there are two ways to obtain a service principal:

• Recommended: enable a system-assigned managed identity for the application.With managed identity, Azure internally manages the application’s service principal and automatically authenticates the application with other Azure services. Managed identity is available for applications deployed to a variety of services.For more information, see the Managed identity overview. Also see Azure services that support managed identity, which links to articles that describe how to enable managed identity for specific services (such as App Service, Azure Functions, Virtual Machines, etc.).
• If you cannot use managed identity, you instead register the application with your Azure AD tenant

How to?

When you open the deployed Key vault you and Access policies, you will see the following

And this is because we have RBAC enabled, so let’s dig to RBAC first

RBAC

You have and options see view Your own access, access for users, groups or Service principals and managed identities.

But also grant access to Key vault ja view all access and what is denied

From View my access you will see the default access your accounts has. My account example has Owner that is Inherited from subscription level and because I have PIM Enabled, there is also User Access Administrator permissions

Different roles

Contributor means Inherited or direct permissions but also Key Vault contributor permissions have this right.

Inherited contributor

Key Vault contributor

And here are the different roles specific to Key vault

Built-in role	Description	ID
Key Vault Administrator	Perform all data plane operations on a key vault and all objects in it, including certificates, keys, and secrets. Cannot manage key vault resources or manage role assignments. Only works for key vaults that use the ‘Azure role-based access control’ permission model.	00482a5a-887f-4fb3-b363-3b7fe8e74483
Key Vault Certificates Officer	Perform any action on the certificates of a key vault, except manage permissions. Only works for key vaults that use the ‘Azure role-based access control’ permission model.	a4417e6f-fecd-4de8-b567-7b0420556985
Key Vault Crypto Officer	Perform any action on the keys of a key vault, except manage permissions. Only works for key vaults that use the ‘Azure role-based access control’ permission model.	14b46e9e-c2b7-41b4-b07b-48a6ebf60603
Key Vault Crypto Service Encryption User	Read metadata of keys and perform wrap/unwrap operations. Only works for key vaults that use the ‘Azure role-based access control’ permission model.	e147488a-f6f5-4113-8e2d-b22465e65bf6
Key Vault Crypto User	Perform cryptographic operations using keys. Only works for key vaults that use the ‘Azure role-based access control’ permission model.	12338af0-0e69-4776-bea7-57ae8d297424
Key Vault Reader	Read metadata of key vaults and its certificates, keys, and secrets. Cannot read sensitive values such as secret contents or key material. Only works for key vaults that use the ‘Azure role-based access control’ permission model.	21090545-7ca7-4776-b22c-e363652d74d2
Key Vault Secrets Officer	Perform any action on the secrets of a key vault, except manage permissions. Only works for key vaults that use the ‘Azure role-based access control’ permission model.	b86a8fe4-44ce-4948-aee5-eccb2c155cd7
Key Vault Secrets User	Read secret contents. Only works for key vaults that use the ‘Azure role-based access control’ permission model.	4633458b-17de-408a-b874-0445c86b69e6

From RBAC your can add user, groups, Service principals and Managed identities

And you can check the access from role assignments

Access policies

Switching to access policies is relatively easy, just go to Access policies and dip the switch. You will get a warning stating that entities will loose access

But note this before changing

If you need to use or just trying out, you will see the following permissions available, you can set different permissions for Keys, Secret or certificate inside the Key vault as long as you remember that granularity isn’t supported, you have to define the access policies to the Key vault at top level.

With RBAC you have possibility to define access for item level.

And Microsoft also suggests you to use RBAC based permissions model instead of policies

Access policy templates to Azure roles mapping

Access policy template	Operations	Azure role
Key, Secret, Certificate Management	Keys: all operations Certificates: all operations Secrets: all operations	Key Vault Administrator
Key & Secret Management	Keys: all operations Secrets: all operations	Key Vault Crypto Officer Key Vault Secrets Officer
Secret & Certificate Management	Certificates: all operations Secrets: all operations	Key Vault Certificates Officer Key Vault Secrets Officer
Key Management	Keys: all operations	Key Vault Crypto Officer
Secret Management	Secrets: all operations	Key Vault Secrets Officer
Certificate Management	Certificates: all operations	Key Vault Certificates Officer
SQL Server Connector	Keys: get, list, wrap key, unwrap key	Key Vault Crypto Service Encryption User
Azure Data Lake Storage or Azure Storage	Keys: get, list, unwrap key	N/A Custom role required
Azure Backup	Keys: get, list, backup Secrets: get, list, backup	N/A Custom role required
Exchange Online Customer Key	Keys: get, list, wrap key, unwrap key	Key Vault Crypto Service Encryption User
Exchange Online Customer Key	Keys: get, list, wrap key, unwrap key	Key Vault Crypto Service Encryption User
Azure Information BYOK	Keys: get, decrypt, sign	N/A Custom role required

Assignment scopes mapping

Azure RBAC for Key Vault allows roles assignment at following scopes:

• Management group
• Subscription
• Resource group
• Key Vault resource
• Individual key, secret, and certificate

Access policy to RBAC migration

There are many differences between Azure RBAC and vault access policy permission model. In order, to avoid outages during migration, below steps are recommended.

1. Identify and assign roles: identify built-in roles based on mapping table above and create custom roles when needed. Assign roles at scopes, based on scopes mapping guidance. For more information on how to assign roles to key vault, see Provide access to Key Vault with an Azure role-based access control
2. Validate roles assignment: role assignments in Azure RBAC can take several minutes to propagate. For guide how to check role assignments, see List roles assignments at scope
3. Configure monitoring and alerting on key vault: it’s important to enable logging and setup alerting for access denied exceptions. For more information, see Monitoring and alerting for Azure Key Vault
4. Set Azure role-based access control permission model on Key Vault: enabling Azure RBAC permission model will invalidate all existing access policies. If an error, permission model can be switched back with all existing access policies remaining untouched.

Manage certificates, secrets, and keys

Certificates

Key vault can be used to generate certificates or just store them for safe-keeping.

You an choose similar options than with your own Certification Authority. Validity period (Maximum 1200 months!) to key usage, it’s all there.

You can choose Integrated CAs which are managed by key vault, which include: DigiCert, GlobalSign

Lifetime action

You can see Certificate transparency, wondering what it is?

Key usage

Import a certificate

For a certificate import operation, Azure Key Vault accepts two certificate file formats: PEM and PFX. Although there are PEM files with only the public portion, Key Vault requires and accepts only a PEM or PFX file with a private key.

Secrets

When you create a secret, you will see the option to create a certificate but it isn’t available anymore, it has been moved to certificates page.

The Azure Portal currently only supports single-line secret values. Please use Azure PowerShell to set multi-line values.

From here you can also add Activate and Expiration date. Activation adds NBF and Expiration EXP property to the secret.

When you press create, you will get the following warning

We enabled the network security but didn’t add the Client IP to firewall (Microsoft please add the current client IP automatically to the column!)

Once done, success!

And lastly keys

Generate

Or import

For keys there is an excellent solution called Auto Key rotation which just came Globally available!

Configure (Auto) key rotation

I wrote a separate article on Key auto-rotation which is now globally available.

Key auto-rotation in Azure Key Vault now GA!

Configure Backup and recovery of certificates, secrets, and keys

Prerequisites

To back up a key vault object, you must have:

• Contributor-level or higher permissions on an Azure subscription.
• A primary key vault that contains the secrets you want to back up.
• A secondary key vault where secrets will be restored.

Certificates

Store it in a safe place

Deleting the certificate, ups

Open Deleted certificates

When you have the Soft-Delete enable, it’s easy

Or from backup

Secrets

Again if you have Soft-Delete enabled, it’s quite easy

Or if You have an backup

And restore the backup

Key

Again, similar process. If you have a backup, you can just restore it

And choose the file

and if you have Soft-Delete enabled, just restore it from there. Microsoft really made this easy and consistent, nice job!

Restoring the whole Key vault

Even restoring a deleted Key vault is possible, if you accidentally deleted a Key vault, it will stay in the recycle bin for 90 days!

What are the limitations for Key Vault?

Key transactions (maximum transactions allowed in 10 seconds, per vault per region¹)

Key type	HSM key CREATE key	HSM key All other transactions	Software key CREATE key	Software key All other transactions
RSA 2,048-bit	5	1,000	10	2,000
RSA 3,072-bit	5	250	10	500
RSA 4,096-bit	5	125	10	250
ECC P-256	5	1,000	10	2,000
ECC P-384	5	1,000	10	2,000
ECC P-521	5	1,000	10	2,000
ECC SECP256K1	5	1,000	10	2,000

Secrets, managed storage account keys, and vault transactions

Transactions type	Maximum transactions allowed in 10 seconds, per vault per region1
All transactions	2,000

¹ A subscription-wide limit for all transaction types is five times per key vault limit. For example, HSM-other transactions per subscription are limited to 5,000 transactions in 10 seconds per subscription.

Backup keys, secrets, certificates

Transactions type	Maximum key vault object versions allowed
Backup individual key, secret, certfiicate	500

Azure Private Link integration

Resource	Limit
Private endpoints per key vault	64
Key vaults with private endpoints per subscription	400

Possible use cases for Key vault

SSL certificates for Apps

You can use certificates from Key Vault, which is kinda neat feature.

Customer Managed TDE

How customer-managed TDE works?

For server to be able to use TDE protector stored in AKV for encryption of the DEK, key vault administrator needs to give the following access rights to the server using its unique Azure Active Directory (Azure AD) identity:

• get – for retrieving the public part and properties of the key in the Key Vault
• wrapKey – to be able to protect (encrypt) DEK
• unwrapKey – to be able to unprotect (decrypt) DEK

Requirements for configuring Azure Key Vault

• Key vault and SQL Database/managed instance must belong to the same Azure Active Directory tenant. Cross-tenant key vault and server interactions are not supported. To move resources afterwards, TDE with AKV will have to be reconfigured. Learn more about moving resources.

• Soft-delete and Purge protection features must be enabled on the key vault to protect from data loss due to accidental key (or key vault) deletion.
  • Soft-deleted resources are retained for 90 days, unless recovered or purged by the customer. The recover and purge actions have their own permissions associated in a key vault access policy. The Soft-delete feature can be enabled using the Azure portal, PowerShell or Azure CLI.
  • Purge protection can be turned on using Azure CLI or PowerShell. When purge protection is enabled, a vault or an object in the deleted state cannot be purged until the retention period has passed. The default retention period is 90 days, but is configurable from 7 to 90 days through the Azure portal.

• Grant the server or managed instance access to the key vault (get, wrapKey, unwrapKey) using its Azure Active Directory identity. When using the Azure portal, the Azure AD identity gets automatically created when the server is created. When using PowerShell or Azure CLI, the Azure AD identity must be explicitly created and should be verified. See Configure TDE with BYOK and Configure TDE with BYOK for SQL Managed Instance for detailed step-by-step instructions when using PowerShell.
  • Depending on the permission model of the key vault (access policy or Azure RBAC), key vault access can be granted either by creating an access policy on the key vault, or by creating a new Azure RBAC role assignment with the role Key Vault Crypto Service Encryption User.

• When using firewall with AKV, you must enable option Allow trusted Microsoft services to bypass the firewall.

These are just couple of examples for your reference!

HSM

What is Hardware Security Module (HSM)

In order to understand Key Vault, we need to understand HSM.

HSM is a tamper proof hardware device which is specifically designed to securely store cryptographic keys. 

• Keys can be generated within HSM, or they can also be securely imported to HSM. 
• The keys which are generated or imported to HSM never come out of HSM boundary, and it is not possible to extract / decrypt those keys using any tool or program. Although those keys cannot be decrypted, but those keys can be used to encrypt and decrypt other keys and secrets which are stored within Key Vault.

You don’t find Manage HSM inside Azure portal, you can provisioning it with PowerShell, Azure CLI or ARM.

Azure Dedicated HSM is not a good fit for the following type of scenario:

Microsoft cloud services that support encryption with customer-managed keys , such as Azure Information Protection, Azure Disk Encryption, Azure Data Lake Store, Azure Storage, Azure SQL Database, and Customer Key for Office 365.

Microsoft has Azure dedicated HSM but that will be removed and the next generation version is.

Azure Key Vault Managed HSM

Azure SQL now supports using a RSA key stored in a Managed HSM as TDE Protector. Azure Key Vault Managed HSM is a fully managed, highly available, single-tenant, standards-compliant cloud service that enables you to safeguard cryptographic keys for your cloud applications, using FIPS 140-2 Level 3 validated HSMs. Managed HSMs use Marvell LiquidSecurity HSM adapters.

How to enable?

Just choose the premium pricing and your done.

Methods and endpoints

Resource type	Key protection methods	Data-plane endpoint base URL
Vaults	Software-protected and HSM-protected (with Premium SKU)	https://{vault-name}.vault.azure.net
Managed HSMs	HSM-protected	https://{hsm-name}.managedhsm.azure.net

Pricing for Managed HSM

	Standard	Premium
RSA 2048-bit keys	N/A	€0.863 per key per month1 + €0.026/10,000 transactions
Advanced key types1— RSA 3072-bit, RSA 4096-bit, and Elliptic-Curve Cryptography (ECC) keys	N/A	First 250 keys€4.312 per key per monthFrom 251 – 1500 keys€2.156 per key per monthFrom 1501 – 4000 keys€0.777 per key per month4001+ keys€0.345 per key per month+ €0.130/10,000 transactions

Here is an excellent article on Managed HSM by Nicholas Kondamudi

Design a strategy for secure remote access

Remote access to Azure

Point-to-Site	Site-to-Site	ExpressRoute
Azure Supported Services	Cloud Services and Virtual Machines	Cloud Services and Virtual Machines	Services list
Typical Bandwidths	Based on the gateway SKU	Typically < 10 Gbps aggregate	50 Mbps, 100 Mbps, 200 Mbps, 500 Mbps, 1 Gbps, 2 Gbps, 5 Gbps, 10 Gbps, 100 Gbps
Protocols Supported	Secure Sockets Tunneling Protocol (SSTP), OpenVPN and IPsec	IPsec	Direct connection over VLANs, NSP’s VPN technologies (MPLS, VPLS,…)
Routing	RouteBased (dynamic)	We support PolicyBased (static routing) and RouteBased (dynamic routing VPN)	BGP
Connection resiliency	active-passive	active-passive or active-active	active-active
Typical use case	Secure access to Azure virtual networks for remote users	Dev / test / lab scenarios and small to medium scale production workloads for cloud services and virtual machines	Access to all Azure services (validated list), Enterprise-class and mission critical workloads, Backup, Big Data, Azure as a DR site
SLA	SLA	SLA	SLA
Pricing	Pricing	Pricing	Pricing
Technical Documentation	VPN Gateway	VPN Gateway	ExpressRoute
FAQ	VPN Gateway FAQ	VPN Gateway FAQ	ExpressRoute FAQ

Point-to-Site

A Point-to-Site (P2S) VPN gateway connection lets you create a secure connection to your virtual network from an individual client computer. A P2S connection is established by starting it from the client computer.

Site-to-Site

A Site-to-Site (S2S) VPN gateway connection is a connection over IPsec/IKE (IKEv1 or IKEv2) VPN tunnel. S2S connections can be used for cross-premises and hybrid configurations. A S2S connection requires a VPN device located on-premises that has a public IP address assigned to it.

ExpressRoute

Connectivity can be from an any-to-any (IP VPN) network, a point-to-point Ethernet network, or a virtual cross-connection through a connectivity provider at a colocation facility. ExpressRoute connections don’t go over the public Internet. This allows ExpressRoute connections to offer more reliability, faster speeds, consistent latencies, and higher security than typical connections over the Internet.

There is a lot more than these but these are a good way to start securing Your networks.

Best practices

Build a Hub-spoke network topology

A hub-spoke network topology is a way to isolate workloads while sharing services such as identity and security. The hub is a virtual network (VNet) in Azure that acts as a central point of connectivity to your on-premises network. The spokes are VNets that peer with the hub. Shared services are deployed in the hub, while individual workloads are deployed as spokes.

Routing all on-premises user requests through Azure Firewall

The user-defined route in the gateway subnet blocks all user requests other than those received from on-premises. The route passes allowed requests to the firewall, and these requests are passed on to the application if they are allowed by the firewall rules. You can add other routes, but make sure they don’t inadvertently bypass the firewall or block administrative traffic intended for the management subnet.

Using NSGs to block/pass traffic between application tiers

Traffic between tiers is restricted by using NSGs. The business tier blocks all traffic that doesn’t originate in the web tier, and the data tier blocks all traffic that doesn’t originate in the business tier. If you have a requirement to expand the NSG rules to allow broader access to these tiers, weigh these requirements against the security risks. Each new inbound pathway represents an opportunity for accidental or purposeful data leakage or application damage.

Using ASG

Application security groups enable you to configure network security as a natural extension of an application’s structure, allowing you to group virtual machines and define network security policies based on those groups. You can reuse your security policy at scale without manual maintenance of explicit IP addresses. The platform handles the complexity of explicit IP addresses and multiple rule sets, allowing you to focus on your business logic.

Peering Your virtual networks

Virtual network peering is a non-transitive relationship between two virtual networks. If you require spokes to connect to each other, consider adding a separate peering connection between those spokes.

Suppose you have several spokes that need to connect with each other. In that case, you’ll run out of possible peering connections quickly, because the number of virtual network peerings per virtual network is limited. (For more information, see Networking limits. In this scenario, consider using user-defined routes (UDRs) to force traffic destined to a spoke to be sent to Azure Firewall or a network virtual appliance acting as a router at the hub. This change will allow the spokes to connect to each other.

You can also configure spokes to use the hub gateway to communicate with remote networks. To allow gateway traffic to flow from spoke to hub and connect to remote networks, you must:

• Configure the peering connection in the hub to allow gateway transit.
• Configure the peering connection in each spoke to use remote gateways.
• Configure all peering connections to allow forwarded traffic.

For more information, see Create VNet peerings.

Spoke connectivity

You can also use a VPN gateway to route traffic between spokes, although this choice will impact latency and throughput. See Configure VPN gateway transit for virtual network peering for configuration details.

Consider what services are shared in the hub to ensure the hub scales for a larger number of spokes. For instance, if your hub provides firewall services, consider your firewall solution’s bandwidth limits when adding multiple spokes. You might want to move some of these shared services to a second level of hubs.

Block creation of Private Endpoint and Links to other tenants.

data-management-zone/params.policyDefinition.Deny-PrivateEndpoint-PrivateLinkServiceConnections.json at main · Azure/data-management-zone · GitHub

How to

Create Azure Private DNS Zones

The Domain Name System, or DNS, is responsible for translating (or resolving) a service name to an IP address. Azure DNS is a hosting service for domains and provides naming resolution using the Microsoft Azure infrastructure. Azure DNS not only supports internet-facing DNS domains, but it also supports private DNS zones.

Azure Private DNS provides the following benefits:

• Removes the need for custom DNS solutions. Previously, many customers created custom DNS solutions to manage DNS zones in their virtual network. You can now manage DNS zones using the native Azure infrastructure, which removes the burden of creating and managing custom DNS solutions.
• Use all common DNS records types. Azure DNS supports A, AAAA, CNAME, MX, PTR, SOA, SRV, and TXT records.
• Automatic hostname record management. Along with hosting your custom DNS records, Azure automatically maintains hostname records for the VMs in the specified virtual networks. In this scenario, you can optimize the domain names you use without needing to create custom DNS solutions or modify applications.
• Hostname resolution between virtual networks. Unlike Azure-provided host names, private DNS zones can be shared between virtual networks. This capability simplifies cross-network and service-discovery scenarios, such as virtual network peering.
• Familiar tools and user experience. To reduce the learning curve, this service uses well-established Azure DNS tools (Azure portal, Azure PowerShell, Azure CLI, Azure Resource Manager templates, and the REST API).
• Split-horizon DNS support. With Azure DNS, you can create zones with the same name that resolve to different answers from within a virtual network and from the public internet. A typical scenario for split-horizon DNS is to provide a dedicated version of a service for use inside your virtual network.
• Available in all Azure regions. The Azure DNS private zones feature is available in all Azure regions in the Azure public cloud.

Use Private Endpoints

To deploy a private endpoint a user must have assigned a built-in role such as:

• Owner
• Contributor
• Network contributor

When You enable Private Endpoints:

• When you enable Private Endpoints, you disable all public access.
• You can enable multiple Private Endpoints in others VNets and Subnets, including VNets in other regions.
• The IP address of the Private Endpoint NIC must be dynamic, but will remain the same until you delete the Private Endpoint.
• The NIC of the Private Endpoint cannot have an NSG associated.
• The Subnet that hosts the Private Endpoint can have an NSG associated, but you must disable the network policies enforcement for the Private Endpoint: see Disable network policies for private endpoints. As a result, you cannot filter by any NSG the access to your Private Endpoint.
• You can eliminate the data exfiltration risk from the VNet by removing all NSG rules where destination is tag Internet or Azure services

Use Private Links

To deploy a private link service a user must have assigned a built-in role such as:

• Owner
• Contributor
• Network contributor

Azure Private Link enables you to access Azure PaaS Services (for example, Azure Storage and SQL Database) and Azure hosted customer-owned/partner services over a private endpoint in your virtual network.

Traffic between your virtual network and the service travels the Microsoft backbone network. Exposing your service to the public internet is no longer necessary. You can create your own private link service in your virtual network and deliver it to your customers. Setup and consumption using Azure Private Link is consistent across Azure PaaS, customer-owned, and shared partner services.

Private Links DNS options:

• Azure VNET without custom DNS Servers (without Active Directory)
• On-premises and/or cloud workloads with own DNS servers and multiple internet routes
• On-premises and/or cloud workloads with own DNS servers and internet gateway forced in on-premises

Workflow

Things to remember

Establish baselines with SCT or ARC for servers and MDM baselines for Clients.

Keep servers up-to-date with Automanage or Automatic updates

Restrict access to resources and adopt Zero trust priciples.

Enroll client devices to Intune

Use the TIER model for all core components, DC, ADFS, AAD Connect etc. and harden your servers with templates.

Use RBAC roles for Key vault and private endpoints if possible.

Store secret, certificates and keys in Key vault, use Auto-rotation when possible!

Do an disaster recovery plan and rigorous testing to your Key vault.

Remote access type to Azure: P2S. S2S and ExpressRoute.

Secure your Azure infrastructure with NSG’s ASG’s and build a Hub and Spoke topology = Separate services to different segments and use VNet’s peering between segments.

Use Private links when possible.

Link to main post