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.
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
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.
|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 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 Automated Device Enrollment (ADE)||Yes||Yes||Yes|
|Windows Azure AD joined||Yes||Yes||No|
|Windows hybrid Azure AD joined||No||No||Yes|
|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
|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 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|
|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|
You can also get reports from the failed devices.
Specify requirements to secure Active Directory Domain Services
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.
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.
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.
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.
|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 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
|Managed HSM Pools: 1 Standard B1 HSM Pool(s) x 31 Days||2 263,66€|
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.
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.
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 Sparkbased 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|
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.
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
- 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
objectIdof the application must be specified in the access policy and the
applicationIdmust not be specified or must be
- 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
objectIdof the user must be specified in the access policy and the
applicationIdmust not be specified or must be
- 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
objectIdmust be specified in the access policy. The
applicationIdidentifies the required application and the
objectIdidentifies the user. Currently, this option isn’t available for data plane Azure RBAC.
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
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
Contributor means Inherited or direct permissions but also Key Vault contributor permissions have this right.
Key Vault contributor
And here are the different roles specific to Key vault
|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
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
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
- 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.
- 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
- 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
- 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
- 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
You can see Certificate transparency, wondering what it is?
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
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 type||HSM key|
All other transactions
All other transactions
Secrets, managed storage account keys, and vault transactions
|Transactions type||Maximum transactions allowed in 10 seconds, per vault per region1|
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 type||Maximum key vault object versions allowed|
|Backup individual key, secret, certfiicate||500|
Azure Private Link integration
|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!
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|
HSM-protected (with Premium SKU)
Pricing for Managed HSM
|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
|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|
|Technical Documentation||VPN Gateway||VPN Gateway||ExpressRoute|
|FAQ||VPN Gateway FAQ||VPN Gateway FAQ||ExpressRoute 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.
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.
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.
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.
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.
"value": "Deny private endpoints to resources outside of the aad tenant and subscription."
"description": "Enable or disable the execution of the policy"
"value": "[split(concat(first(field('Microsoft.Network/privateEndpoints/manualprivateLinkServiceConnections[*].privateLinkServiceId')), '//'), '/')]",
"value": "[split(concat(first(field('Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].privateLinkServiceId')), '//'), '/')]",
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
Use Private Links
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
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.