Merge pull request #267833 from msmbaldwin/ade-fips

FIPS 140 Level 2 -> FIPS 140 validated

Author: v-dirichards

articles/azure-government/documentation-government-overview-wwps.md

@@ -158,7 +158,7 @@ Data encryption provides isolation assurances that are tied directly to encrypti
 
 Proper protection and management of encryption keys is essential for data security. **[Azure Key Vault](../key-vault/index.yml) is a cloud service for securely storing and managing secrets.** The Key Vault service supports two resource types:
 
-- **[Vault](../key-vault/general/overview.md)** supports software-protected and hardware security module (HSM)-protected [secrets, keys, and certificates](../key-vault/general/about-keys-secrets-certificates.md). Vaults provide a multi-tenant, low-cost, easy to deploy, zone-resilient (where available), and highly available key management solution suitable for most common cloud application scenarios. The corresponding HSMs have [FIPS 140 Level 2](/azure/compliance/offerings/offering-fips-140-2) validation.
+- **[Vault](../key-vault/general/overview.md)** supports software-protected and hardware security module (HSM)-protected [secrets, keys, and certificates](../key-vault/general/about-keys-secrets-certificates.md). Vaults provide a multi-tenant, low-cost, easy to deploy, zone-resilient (where available), and highly available key management solution suitable for most common cloud application scenarios. The corresponding HSMs have [FIPS 140 validation](/azure/key-vault/keys/about-keys#compliance).
 - **[Managed HSM](../key-vault/managed-hsm/overview.md)** supports only HSM-protected cryptographic keys. It provides a single-tenant, fully managed, highly available, zone-resilient (where available) HSM as a service to store and manage your cryptographic keys. It's most suitable for applications and usage scenarios that handle high value keys. It also helps you meet the most stringent security, compliance, and regulatory requirements. Managed HSM uses [FIPS 140 Level 3](/azure/compliance/offerings/offering-fips-140-2) validated HSMs to protect your cryptographic keys.
 
 Key Vault enables you to store your encryption keys in hardware security modules (HSMs) that are FIPS 140 validated. With Azure Key Vault, you can import or generate encryption keys in HSMs, ensuring that keys never leave the HSM protection boundary to support *bring your own key* (BYOK) scenarios. **Keys generated inside the Azure Key Vault HSMs aren't exportable – there can be no clear-text version of the key outside the HSMs.** This binding is enforced by the underlying HSM.
@@ -385,7 +385,7 @@ Listed below are key enabling technologies and services that you may find helpfu
 
 - All recommended technologies used for Unclassified data, especially services such as [Virtual Network](../virtual-network/virtual-networks-overview.md) (VNet), [Microsoft Defender for Cloud](../defender-for-cloud/index.yml), and [Azure Monitor](../azure-monitor/index.yml).
 - Public IP addresses are disabled allowing only traffic through private connections, including [ExpressRoute](../expressroute/index.yml) and [Virtual Private Network](../vpn-gateway/index.yml) (VPN) gateway.
-- Data encryption is recommended with customer-managed keys (CMK) in [Azure Key Vault](../key-vault/index.yml) backed by multi-tenant hardware security modules (HSMs) that have FIPS 140 Level 2 validation.
+- Data encryption is recommended with customer-managed keys (CMK) in [Azure Key Vault](../key-vault/index.yml) backed by multi-tenant hardware security modules (HSMs) that have [FIPS 140 validation](/azure/key-vault/keys/about-keys#compliance).
 - Only services that support [VNet integration](../virtual-network/virtual-network-for-azure-services.md) options are enabled. Azure VNet enables you to place Azure resources in a non-internet routable network, which can then be connected to your on-premises network using VPN technologies. VNet integration gives web apps access to resources in the virtual network.
 - You can use [Azure Private Link](../private-link/index.yml) to access Azure PaaS services over a private endpoint in your VNet, ensuring that traffic between your VNet and the service travels across the Microsoft global backbone network, which eliminates the need to expose the service to the public Internet.
 - [Customer Lockbox](../security/fundamentals/customer-lockbox-overview.md) for Azure enables you to approve/deny elevated access requests for your data in support scenarios. It’s an extension of the Just-in-Time (JIT) workflow that comes with full audit logging enabled.

articles/cosmos-db/postgresql/concepts-customer-managed-keys.md

@@ -32,7 +32,7 @@ Data encryption with customer-managed keys for Azure Cosmos DB for PostgreSQL is
 | **Key encryption key (KEK)** | A key encryption key is an encryption key used to encrypt the DEKs. A KEK that never leaves a key vault allows the DEKs themselves to be encrypted and controlled. The entity that has access to the KEK might be different than the entity that requires the DEK. Since the KEK is required to decrypt the DEKs, the KEK is effectively a single point and deletion of the KEK effectively deletes the DEKs. |
 
 > [!NOTE]
-> Azure Key Vault is a cloud-based key management system. It's highly available and provides scalable, secure storage for RSA cryptographic keys, optionally backed by FIPS 140-2 Level 2 validated hardware security modules (**HSM**s). A key vault doesn't allow direct access to a stored key but provides encryption and decryption services to authorized entities. A key vault can generate the key, import it, or have it transferred from an on-premises HSM device.
+> Azure Key Vault is a cloud-based key management system. It's highly available and provides scalable, secure storage for RSA cryptographic keys, optionally backed by [FIPS 140 validated](/azure/key-vault/keys/about-keys#compliance) hardware security modules (**HSM**s). A key vault doesn't allow direct access to a stored key but provides encryption and decryption services to authorized entities. A key vault can generate the key, import it, or have it transferred from an on-premises HSM device.
 
 The DEKs, encrypted with the KEKs, are stored separately. Only an entity with access to the KEK can decrypt these DEKs. For more information, see [Security in encryption at rest.](../../security/fundamentals/encryption-atrest.md).
 

articles/key-vault/certificates/about-certificates.md

@@ -40,18 +40,7 @@ When a Key Vault certificate is created, it can be retrieved from the addressabl
 
 The addressable key becomes more relevant with non-exportable Key Vault certificates. The addressable Key Vault key's operations are mapped from the `keyusage` field of the Key Vault certificate policy that's used to create the Key Vault certificate.  
 
-The following table lists supported key types. 
-
-|Key type|About|Security|
-|--|--|--|
-|**RSA**| Software-protected RSA key|FIPS 140-2 Level 1|
-|**RSA-HSM**| HSM-protected RSA key (Premium SKU only)|FIPS 140-2 Level 2 HSM|
-|**EC**| Software-protected elliptic curve key|FIPS 140-2 Level 1|
-|**EC-HSM**| HSM-protected elliptic curve key (Premium SKU only)|FIPS 140-2 Level 2 HSM|
-|**oct**| Software-protected octet key| FIPS 140-2 Level 1|
-
-
-Exportable keys are allowed only with RSA and EC. HSM keys are non-exportable. For more information about key types, see [Create certificates](/rest/api/keyvault/certificates/create-certificate/create-certificate#jsonwebkeytype).
+For the full list of supported key types, see [About keys: Key types and protection methods](../keys/about-keys.md#key-types-and-protection-methods). Exportable keys are allowed only with RSA and EC. HSM keys are non-exportable.
 
 ## Certificate attributes and tags
 

articles/key-vault/general/basic-concepts.md

@@ -63,7 +63,7 @@ Use the following table to better understand how Key Vault can help to meet the
 | --- | --- | --- |
 | Developer for an Azure application |"I want to write an application for Azure that uses keys for signing and encryption. But I want these keys to be external from my application so that the solution is suitable for an application that's geographically distributed. <br/><br/>I want these keys and secrets to be protected, without having to write the code myself. I also want these keys and secrets to be easy for me to use from my applications, with optimal performance." |√ Keys are stored in a vault and invoked by URI when needed.<br/><br/> √ Keys are safeguarded by Azure, using industry-standard algorithms, key lengths, and hardware security modules.<br/><br/> √ Keys are processed in HSMs that reside in the same Azure datacenters as the applications. This method provides better reliability and reduced latency than keys that reside in a separate location, such as on-premises. |
 | Developer for software as a service (SaaS) |"I don't want the responsibility or potential liability for my customers' tenant keys and secrets. <br/><br/>I want customers to own and manage their keys so that I can concentrate on doing what I do best, which is providing the core software features." |√ Customers can import their own keys into Azure, and manage them. When a SaaS application needs to perform cryptographic operations by using customers' keys, Key Vault does these operations on behalf of the application. The application does not see the customers' keys. |
-| Chief security officer (CSO) |"I want to know that our applications comply with FIPS 140-2 Level 2 or FIPS 140-2 Level 3 HSMs for secure key management. <br/><br/>I want to make sure that my organization is in control of the key lifecycle and can monitor key usage. <br/><br/>And although we use multiple Azure services and resources, I want to manage the keys from a single location in Azure." |√ Choose **vaults** for FIPS 140-2 Level 2 validated HSMs.<br/>√ Choose **managed HSM pools** for FIPS 140-2 Level 3 validated HSMs.<br/><br/>√ Key Vault is designed so that Microsoft does not see or extract your keys.<br/>√ Key usage is logged in near real time.<br/><br/>√ The vault provides a single interface, regardless of how many vaults you have in Azure, which regions they support, and which applications use them. |
+| Chief security officer (CSO) |"I want to know that our applications comply with FIPS 140 Level 3 HSMs for secure key management. <br/><br/>I want to make sure that my organization is in control of the key lifecycle and can monitor key usage. <br/><br/>And although we use multiple Azure services and resources, I want to manage the keys from a single location in Azure." |√ Choose **vaults** or **managed HSMs** for [FIPS 140 validated HSMs](/azure/key-vault/keys/about-keys#compliance).<br/>√ Choose **managed HSM pools** for FIPS 140-2 Level 3 validated HSMs.<br/><br/>√ Key Vault is designed so that Microsoft does not see or extract your keys.<br/>√ Key usage is logged in near real time.<br/><br/>√ The vault provides a single interface, regardless of how many vaults you have in Azure, which regions they support, and which applications use them. |
 
 Anybody with an Azure subscription can create and use key vaults. Although Key Vault benefits developers and security administrators, it can be implemented and managed by an organization's administrator who manages other Azure services. For example, this administrator can sign in with an Azure subscription, create a vault for the organization in which to store keys, and then be responsible for operational tasks like these:
 

articles/key-vault/general/manage-with-cli2.md

@@ -241,7 +241,7 @@ az keyvault update --name "ContosoKeyVault" --resource-group "ContosoResourceGro
 
 ## Working with Hardware security modules (HSMs)
 
-For added assurance, you can import or generate keys from hardware security modules (HSMs) that never leave the HSM boundary. The HSMs are FIPS 140-2 Level 2 validated. If this requirement doesn't apply to you, skip this section and go to Delete the key vault and associated keys and secrets.
+For added assurance, you can import or generate keys from hardware security modules (HSMs) that never leave the HSM boundary. The HSMs are [FIPS 140 validated](/azure/key-vault/keys/about-keys#compliance). If this requirement doesn't apply to you, skip this section and go to Delete the key vault and associated keys and secrets.
 
 To create these HSM-protected keys, you must have a vault subscription that supports HSM-protected keys.
 

articles/key-vault/general/overview.md

@@ -41,7 +41,7 @@ Access to a key vault requires proper authentication and authorization before a
 
 Authentication is done via Microsoft Entra ID. Authorization may be done via Azure role-based access control (Azure RBAC) or Key Vault access policy. Azure RBAC can be used for both management of the vaults and to access data stored in a vault, while key vault access policy can only be used when attempting to access data stored in a vault.
 
-Azure Key Vaults may be either software-protected or, with the Azure Key Vault Premium tier, hardware-protected by hardware security modules (HSMs). Software-protected keys, secrets, and certificates are safeguarded by Azure, using industry-standard algorithms and key lengths.  For situations where you require added assurance, you can import or generate keys in HSMs that never leave the HSM boundary. Azure Key Vault uses nCipher HSMs, which are Federal Information Processing Standards (FIPS) 140-2 Level 2 validated. You can use nCipher tools to move a key from your HSM to Azure Key Vault.
+Azure Key Vaults may be either software-protected or, with the Azure Key Vault Premium tier, hardware-protected by hardware security modules (HSMs). Software-protected keys, secrets, and certificates are safeguarded by Azure, using industry-standard algorithms and key lengths.  For situations where you require added assurance, you can import or generate keys in HSMs that never leave the HSM boundary. Azure Key Vault uses nCipher HSMs, which are [Federal Information Processing Standards 140 validated](/azure/key-vault/keys/about-keys#compliance). You can use HSM vendor provided tools to move a key from your HSM to Azure Key Vault.
 
 Finally, Azure Key Vault is designed so that Microsoft doesn't see or extract your data.
 

articles/key-vault/keys/about-keys.md

@@ -30,17 +30,17 @@ Azure Key Vault provides two types of resources to store and manage cryptographi
 
 Cryptographic keys in Key Vault are represented as JSON Web Key [JWK] objects. The JavaScript Object Notation (JSON) and JavaScript Object Signing and Encryption (JOSE) specifications are:
 
--   [JSON Web Key (JWK)](https://tools.ietf.org/html/draft-ietf-jose-json-web-key)  
--   [JSON Web Encryption (JWE)](https://datatracker.ietf.org/doc/html/draft-jones-json-web-encryption)  
--   [JSON Web Algorithms (JWA)](https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-web-algorithms)  
--   [JSON Web Signature (JWS)](https://tools.ietf.org/html/draft-ietf-jose-json-web-signature) 
+- [JSON Web Key (JWK)](https://tools.ietf.org/html/draft-ietf-jose-json-web-key)  
+- [JSON Web Encryption (JWE)](https://datatracker.ietf.org/doc/html/draft-jones-json-web-encryption)  
+- [JSON Web Algorithms (JWA)](https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-web-algorithms)  
+- [JSON Web Signature (JWS)](https://tools.ietf.org/html/draft-ietf-jose-json-web-signature) 
 
 The base JWK/JWA specifications are also extended to enable key types unique to the Azure Key Vault and Managed HSM implementations. 
 
 HSM Keys in vaults are protected". The Software keys are not protected by HSMs.
 
-- Keys stored in vaults benefit from robust protection using **FIPS 140-2 HSMs**. There are two distinct HSM platforms available: 1, which protects key versions with **FIPS 140-2 Level 2**  and 2, which protects keys with **FIPS 140-2 Level 3** HSMs depending on when the key was created. All new keys and key versions are now created using platform 2 (except UK geo). To determine which HSM Platform is protecting a key version, get it's [hsmPlatform](about-keys-details.md#key-attributes). 
-- Managed HSM  uses **FIPS 140-2 Level 3** validated HSM modules to protect your keys. Each HSM pool is an isolated single-tenant instance with its own [security domain](../managed-hsm/security-domain.md) providing complete cryptographic isolation from all other HSMs sharing the same hardware infrastructure.
+- Keys stored in vaults benefit from robust protection using **[FIPS 140 validated HSM](/azure/key-vault/keys/about-keys#compliance)**. There are two distinct HSM platforms available: 1, which protects key versions with **FIPS 140-2 Level 2**, and 2, which protects keys with **FIPS 140-2 Level 3** HSMs depending on when the key was created. All new keys and key versions are now created using platform 2 (except UK geo). To determine which HSM Platform is protecting a key version, get it's [hsmPlatform](about-keys-details.md#key-attributes). 
+- Managed HSM uses **FIPS 140-2 Level 3** validated HSM modules to protect your keys. Each HSM pool is an isolated single-tenant instance with its own [security domain](../managed-hsm/security-domain.md) providing complete cryptographic isolation from all other HSMs sharing the same hardware infrastructure.
 
 These keys are protected in single-tenant HSM-pools. You can import an RSA, EC, and symmetric key, in soft form or by exporting from a supported HSM device. You can also generate keys in HSM pools. When you import HSM keys using the method described in the [BYOK (bring your own key) specification](../keys/byok-specification.md), it enables secure transportation key material into Managed HSM pools. 
 
@@ -71,10 +71,10 @@ Key Vault supports RSA and EC keys. Managed HSM supports RSA, EC, and symmetric
 
 |Key type and destination|Compliance|
 |---|---|
-|Software-protected (hsmPlatform 0) keys in vaults | FIPS 140-2 Level 1|
-|hsmPlatform 1 protected keys in vaults (Premium SKU)| FIPS 140-2 Level 2|
-|hsmPlatform 2 protected keys in vaults (Premium SKU)| FIPS 140-2 Level 3|
-|Keys in Managed HSM are always HSM protected|FIPS 140-2 Level 3|
+|Software-protected (hsmPlatform 0) keys in vaults | FIPS 140-2 Level 1 |
+|hsmPlatform 1 protected keys in vaults (Premium SKU)| FIPS 140-2 Level 2 |
+|hsmPlatform 2 protected keys in vaults (Premium SKU)| FIPS 140-2 Level 3 |
+|Keys in Managed HSM are always HSM protected | FIPS 140-2 Level 3 |
 |||
 
 See [Key types, algorithms, and operations](about-keys-details.md) for details about each key type, algorithms, operations, attributes, and tags.

articles/key-vault/keys/hsm-protected-keys-byok.md

@@ -15,7 +15,7 @@ ms.author: mbaldwin
 
 # Import HSM-protected keys to Key Vault (BYOK)
 
-For added assurance when you use Azure Key Vault, you can import or generate a key in a hardware security module (HSM); the key will  never leave the HSM boundary. This scenario often is referred to as *bring your own key* (BYOK). Key Vault uses the nCipher nShield family of HSMs (FIPS 140-2 Level 2 validated) to protect your keys.
+For added assurance when you use Azure Key Vault, you can import or generate a key in a hardware security module (HSM); the key will never leave the HSM boundary. This scenario often is referred to as *bring your own key* (BYOK). Key Vault uses [FIPS 140 validated HSMs](/azure/key-vault/keys/about-keys#compliance) to protect your keys.
 
 Use the information in this article to help you plan for, generate, and transfer your own HSM-protected keys to use with Azure Key Vault.
 

articles/key-vault/keys/hsm-protected-keys.md

@@ -15,7 +15,7 @@ ms.author: mbaldwin
 
 # Import HSM-protected keys to Key Vault
 
-For added assurance, when you use Azure Key Vault, you can import or generate keys in hardware security modules (HSMs) that never leave the HSM boundary. This scenario is often referred to as *bring your own key*, or BYOK. Azure Key Vault uses nCipher nShield family of HSMs (FIPS 140-2 Level 2 validated) to protect your keys.
+For added assurance, when you use Azure Key Vault, you can import or generate keys in hardware security modules (HSMs) that never leave the HSM boundary. This scenario is often referred to as *bring your own key*, or BYOK. Azure Key Vault uses [FIPS 140 validated HSMs](/azure/key-vault/keys/about-keys#compliance) to protect your keys.
 
 This functionality is not available for Microsoft Azure operated by 21Vianet.