Forum Widgets
Latest Discussions
Plan Deploying Azure Managed HSM
What is Azure Managed HSM Azure Key Vault Managed HSM (Hardware Security Module) is a fully managed, highly available, single-tenant, standards-compliant cloud service that enables you to safeguard cryptographic keys for your cloud applications, usingFIPS 140-2 Level 3validated HSMs. It is one of severalkey management solutions in Azure. Highly secure physical hardware The Managed HSM service runs inside a trusted execution environment that's built on Intel Software Guard Extensions (Intel SGX). Intel SGX offers enhanced protection from internal and external attackers by using hardware isolation in enclaves that protect data in use. Microsoft do regular Red Team/Blue Team exercises (attack simulation). Each instance is deployed in a different rack to ensure redundancy. Each server has aFIPS 140-2 Level 3 validated Marvell Liquid Security HSM Adapter with multiple cryptographic cores. The cores are used to create fully isolated HSM partitions,including fullyisolatedcredentials, data storage, and access control. What is Security Domain To operate, a managed HSM must have a security domain. The security domain is an encrypted blob file that contains artifacts like the HSM backup, user credentials, the signing key, and the data encryption key that's unique to the managed HSM Without the security domain, disaster recovery isn't possible. Microsoft has no way to recover the security domain, and Microsoft can't access your keys without the security domain. Protecting the security domain is therefore of the utmost importance for your business continuity, and to ensure that you aren't cryptographically locked out. The managed HSM initializes the security domain and encrypts it with the public keys that you provide by using Shamir's Secret Sharing Algorithm After the security domain is downloaded, the managed HSM moves into an activated state and is ready for consumption. Managed HSM Deployment workflow Deployment options: CLI, PowerShell, ARM template Deployment workflow Optional deployments Purge Protection and Soft Delete Following Diagram shows the difference between Soft delete and Purger projection option. Please note that managed HSM doesn't allow you to disable soft delete option. You can choose whether you want to enable or disable purge protection. Purge Protection Disabled Purge Protection Enabled Plan What is the Motive? There are Three use cases can be considered while using managed HSM Encryption at rest for Azure Managed Services Storing keys that used to encrypt/ decrypt the parameters/object in self-developed application (SDKs are available) TLS offload for F5 and nginx (TLS offload libraries are available) Which is the Primary Region Whether Secondary Region is required Plan for secondary region if Multi region Replication is required. Managed HSM will be deployed in three physically separated racks and azure is providing 99.9% SLA. Please consider Multi region replication if you are planning for zero down time. Plan for RSA key pair to secure HSM Security Domain (Max 3, Min 10) Plan methods to secure Security Domain downloaded and Private Keys Follow best practices such as offline encrypted storage/offline HSM, multi-person control, and geo-separation, Internet isolation while safeguarding the private key. Microsoft cannot assist in the event of key loss as Microsoft doesn’t have access to private keys. Plan for Backup and restore You can store back to Azure blob storage; with the help of security domain and private keys you can restore it. Plan for disaster recovery Which users, groups or service principal need to be assigned for azure RBAC and local RBAC Whether Purge protection is Required Logging is required or not? Needed to be integrated with Azure policy or not? Private connectivity is required or not? Do you need to use SSL off load feature for F5 and nginx? Do you need to configure Key rotation? Pricing Aspects Managed HSM pool cost per hour Optional Back up storage cost Log storage cost Multi Region Replication costs
Remote Attestation Attack on AMD SEV-SNP CVM in Azure
Following the 1st scenario ("request in separate workload") on this page (https://learn.microsoft.com/en-us/azure/confidential-computing/guest-attestation-confidential-vms ), after step 2, is it not possible for a malicious guest OS to replace a valid attestation report with another attestation report (from a SEV machine with a good OS) to mask its presence from a relying party? How is this mitigated?
