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

Table of Contents

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.



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


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

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
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 can be used for Windows and Linux virtual machines and it includes the following components.


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 platformUser affinityAzure appliesIntune applies
Android Enterprise personally-owned work profileYesYesYes
Android Enterprise dedicated deviceNoNoNo
Android Enterprise fully managedYesYesYes
Android Enterprise corporate-owned work profileYesYesYes
Android device administratorYesYesYes
Android device administrator DEMNoNo
iOS/macOS BYODYesYesYes
iOS/macOS Automated Device Enrollment (ADE)YesYesYes
Windows BYODYesYesYes
Windows MD-onlyYesYes
Windows Azure AD joinedYesYesNo
Windows AutopilotYesYesNo
Windows hybrid Azure AD joinedNoNoYes
Windows co-managementNoYesNo
Windows DEMNoYesNo
Windows bulk enrollmentNoYesNo

What happens when enrolled?

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

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

Device security and configuration

CapabilityDetailsMore 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 ResetErases 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 modeLets 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 ResetSends 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

CapabilityDetailsMore information
App deployment and managementProvides 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 appsLets 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 managementConfigures 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 configurationUses 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 profilesHelps 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 browserConfigures 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 BusinessLets 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 appsHelps 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

CapabilityDetailsMore information
Certificate profilesCreates 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 profilesDeploys 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 profilesCreates 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 profilesDeploys 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 policiesManages 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


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:

Diagram that shows 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 practiceSolution
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


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 typeRegionDescriptionEstimated monthly costEstimated upfront cost
Key VaultNorth EuropeVault: 1 operations, 1 advanced operations, 1 renewals
1 protected keys, 1 advanced protected keys
Managed HSM Pools: 1 Standard B1 HSM Pool(s) x 31 Days2 263,66€
Total2 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.


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


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 serviceSupported usage scenarios
Azure Virtual Machines deployment serviceDeploy certificates to VMs from customer-managed Key Vault.
Azure Resource Manager template deployment servicePass secure values during deployment.
Azure Disk Encryption volume encryption serviceAllow 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 BackupAllow backup and restore of relevant keys and secrets during Azure Virtual Machines backup, by using Azure Backup.
Exchange Online & SharePoint OnlineAllow access to customer key for Azure Storage Service Encryption with Customer Key.
Azure Information ProtectionAllow access to tenant key for Azure Information Protection.
Azure App ServiceApp 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 DatabaseTransparent Data Encryption with Bring Your Own Key support for Azure SQL Database and Azure Synapse Analytics.
Azure Database for MySQLData encryption for Azure Database for MySQL
Azure Database for PostgreSQL Single serverData encryption for Azure Database for PostgreSQL Single server
Azure StorageStorage Service Encryption using customer-managed keys in Azure Key Vault.
Azure Data Lake StoreEncryption of data in Azure Data Lake Store with a customer-managed key.
Azure Synapse AnalyticsEncryption of data using customer-managed keys in Azure Key Vault
Azure DatabricksFast, easy, and collaborative Apache Spark–based analytics service
Azure API ManagementDeploy certificates for Custom Domain from Key Vault using MSI
Azure Data FactoryFetch data store credentials in Key Vault from Data Factory
Azure Event HubsAllow access to a key vault for customer-managed keys scenario
Azure Service BusAllow access to a key vault for customer-managed keys scenario
Azure Import/ExportUse customer-managed keys in Azure Key Vault for Import/Export service
Azure Container RegistryRegistry encryption using customer-managed keys
Azure Application GatewayUsing Key Vault certificates for HTTPS-enabled listeners
Azure Front DoorUsing Key Vault certificates for HTTPS
Microsoft PurviewUsing credentials for source authentication in Microsoft Purview
Azure Machine LearningSecure 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 ‘’ 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.


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.

  • user security principal identifies an individual who has a profile in Azure Active Directory.
  • 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.
  • 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
The Azure Key Vault authentication flow

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


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 roleDescriptionID
Key Vault AdministratorPerform 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 OfficerPerform 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 OfficerPerform 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 UserRead 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 UserPerform 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 ReaderRead 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 OfficerPerform 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 UserRead 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 templateOperationsAzure role
Key, Secret, Certificate ManagementKeys: all operations
Certificates: all operations
Secrets: all operations
Key Vault Administrator
Key & Secret ManagementKeys: all operations
Secrets: all operations
Key Vault Crypto Officer
Key Vault Secrets Officer
Secret & Certificate ManagementCertificates: all operations
Secrets: all operations
Key Vault Certificates Officer
Key Vault Secrets Officer
Key ManagementKeys: all operationsKey Vault Crypto Officer
Secret ManagementSecrets: all operationsKey Vault Secrets Officer
Certificate ManagementCertificates: all operationsKey Vault Certificates Officer
SQL Server ConnectorKeys: get, list, wrap key, unwrap keyKey Vault Crypto Service Encryption User
Azure Data Lake Storage or Azure StorageKeys: get, list, unwrap keyN/A
Custom role required
Azure BackupKeys: get, list, backup
Secrets: get, list, backup
Custom role required
Exchange Online Customer KeyKeys: get, list, wrap key, unwrap keyKey Vault Crypto Service Encryption User
Exchange Online Customer KeyKeys: get, list, wrap key, unwrap keyKey Vault Crypto Service Encryption User
Azure Information BYOKKeys: get, decrypt, signN/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


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.


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


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.

Configure Backup and recovery of certificates, secrets, and keys


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.


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


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

Or if You have an backup

And restore the backup


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 region1)

Key typeHSM key
HSM key
All other transactions
Software key
Software key
All other transactions
RSA 2,048-bit51,000102,000
RSA 3,072-bit525010500
RSA 4,096-bit512510250
ECC P-25651,000102,000
ECC P-38451,000102,000
ECC P-52151,000102,000
ECC SECP256K151,000102,000

Secrets, managed storage account keys, and vault transactions

Transactions typeMaximum transactions allowed in 10 seconds, per vault per region1
All transactions2,000

1 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 typeMaximum key vault object versions allowed
Backup individual key, secret, certfiicate500

Azure Private Link integration

Private endpoints per key vault64
Key vaults with private endpoints per subscription400

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 (getwrapKeyunwrapKey) 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!


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 typeKey protection methodsData-plane endpoint base URL


HSM-protected (with Premium SKU)
Managed HSMsHSM-protectedhttps://{hsm-name}

Pricing for Managed HSM

RSA 2048-bit keysN/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/AFirst 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

Azure Supported ServicesCloud Services and Virtual MachinesCloud Services and Virtual MachinesServices list
Typical BandwidthsBased on the gateway SKUTypically < 10 Gbps aggregate50 Mbps, 100 Mbps, 200 Mbps, 500 Mbps, 1 Gbps, 2 Gbps, 5 Gbps, 10 Gbps, 100 Gbps
Protocols SupportedSecure Sockets Tunneling Protocol (SSTP), OpenVPN and IPsecIPsecDirect connection over VLANs, NSP’s VPN technologies (MPLS, VPLS,…)
RoutingRouteBased (dynamic)We support PolicyBased (static routing) and RouteBased (dynamic routing VPN)BGP
Connection resiliencyactive-passiveactive-passive or active-activeactive-active
Typical use caseSecure access to Azure virtual networks for remote usersDev / test / lab scenarios and small to medium scale production workloads for cloud services and virtual machinesAccess to all Azure services (validated list), Enterprise-class and mission critical workloads, Backup, Big Data, Azure as a DR site
Technical DocumentationVPN GatewayVPN GatewayExpressRoute
FAQVPN Gateway FAQVPN Gateway FAQExpressRoute FAQ


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.


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.


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.

Application security groups

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

Routing between spokes using Azure Firewall

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.

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:

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

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

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
Private link service workflow
Private Link service 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

Author: Harri Jaakkonen

Leave a Reply

Your email address will not be published. Required fields are marked *