When large organizations adopt cloud services they may evaluate the cloud service in depth, along with all other cloud services that must or may be adopted as dependencies of the primary service being planned for use. An example is that when adopting Azure Key Vault a customer will be required to adopt Azure Active Directory if not already adopted, and therefore adopting Key Vault will necessitate an in-depth security assessment of Azure AD in addition to Key Vault.

Currently Microsoft does not list dependencies of any kind on the product web pages of all the many Azure services. This obliges the customer to go on a fact-finding mission to uncover these dependency relationships and therefore costs time on the part of both the customer and Microsoft. This might include account team members, CxE, and product teams. This would be unnecessary if all dependencies (both mandatory and optional) were clearly stated on the product pages of every Microsoft service.

As an application developer, I have had a number of situations where HMAC signing has been a key part of application security, such as:

• Signing “local” session tokens (JWT, cookies, etc)


• Third-party integrations (API authentication)


• Integrity of data at rest

In many of these scenarios, ECC signing is either too heavy or not possible due to third-party dependencies. For scenarios where the same Key Vault can do the signing and verification, it would be ideal for us to be able to either generate or import a symmetric key in Key Vault for use with HMAC.

This would allow us to ensure the key is protected since it is unable to be exported. All signing and verification of HMAC signatures would then be performed through Key Vault itself, and audited through Azure Storage or Azure Monitor as per normal.

As per documentation: "When creating a private endpoint, a read-only network interface is also created for the lifecycle of the resource. The interface is assigned dynamically private IP addresses from the subnet that maps to the private link resource. The value of the private IP address remains unchanged for the entire lifecycle of the private endpoint."
However now the system lets you go into the NIC, go into the IP cofig and toggle the IP settings from dynamic to static. This is not allowed by the system and results in an error when saving. Please remove this option from here since it is not supported.

When using the BYOK procedure, after uploading your HSM-generated key to the Key Vault there is zero traceability to confirm that what was uploaded in the cloud is actually what you have originally generated with your nCipher HSM.
The solution is very simple - nCipher HSMs already generate hashes for the generated keys in the security world metadata, AKV should store / display the hash after successful upload so you can verify your keys at any time.

Otherwise the following attack scenario is possible (if unlikely):

Prerequisites:
* Knowledge of the attack target's subscription ID (not particularly confidential information at large corporations using dozens of services under one subscription)
* Knowledge of the attack target's Azure region
* 1 compromised person in the BYOK-procedure chain
* Attacker's subscription in the appropriate region
* Attacker's own nCipher HSM

Attack procedure:
1. Generate key with attacker's HSM
2. Sign transfer package with target's subscription ID
3. Encrypt transfer package with appropriate Azure region key exchange keys
4. During the BYOK procedure (the key transfer packages are usually carried from the offline PAW to the online PAW on some kind of medium like a USB-stick) the compromised person or the attacker him- / herself swaps the target's transfer package with the attacker's transfer package (remember, it's signed for the target's subscription ID)
5. Key is uploaded to AKV with no positive traceability info and henceforth the attacker's key is used by the target to encrypt "whatever" without the target's having any possibility of knowing this

In my opinion this could be especially bad if a large company relied on AKV with BYOK in conjunction with Azure Information Protection to protect ALL their sensitive Mails and Documents.

TLDR: I want the possibility to overwrite already existing secrets with the Restore-AzKeyVaultSecret/Key/Certificate to allow for replication in the customers control.

According to the Key Vault documentation Azure Key Vault provides a 99.9% availability percentage and a replication to the pair region takes place to ensure customers can continue using their Key Vaults after a failover in read-only.

However this is a situation a customer does not and can not control. This means that a customer has to wait until Microsoft declares a disaster and fails over the vaults to the pair region. I would like it if we would be able to take more control of this process.

This can be made possible by being able to backup and restore secrets on a more continuous basis to another Key Vault which resides in the pair region. It is currently impossible to overwrite an already existing secret with a backup file if it already exists by name even though the backup has a newer version of the secret than the one already residing in the target Key Vault.

It should be possible to select "Allow Azure services and resources to access this key vault" in Networking.

As of today, you can only select:
Option 1) ”Allow trusted Microsoft services to bypass this firewall”
Option 2) "IPv4 address"
Option 3) "Virtual networks"

A scenario is, you have a “Azure WebApp”, and Identity is set to off.
Then the WebApp is not a “trusted Microsoft services”, therefore option 1 is not useable.

Option 2, the IP address solution, is not useable when you have many WebApps, and many key vaults, in our case we should then manually handle over 1000 IP address.

Option 3, if you don´t use "Virtual networks", then is should not be necessary to add this, for using key vault, in our case it complicates the azure setup, and we don’t want to use “Virtual networks”.

Therefore, an option 4; “Allow Azure services and resources to access this Key Vault” is needed.
This option is already possible in SQL service for example.

I would like to see the security worldpackage information for the Key Vault in the Kyeey Vault information so that it is easier to deduce the package to us. This must be made available in AzPs, CLI, SDK and via the REST APIs

Get-AzureRmKeyVault -VaultName Bxxxxxxxp

VaultUri : https://bxxxxxxxp.vault.azure.net/
TenantId : 0b98xxxx-xxxx-xxxx-xxxx-xxxxxxxxf102
TenantName : 0b98xxxx-xxxx-xxxx-xxxx-xxxxxxxxf102
Sku : Premium
EnabledForDeployment : False
EnabledForTemplateDeployment : False
EnabledForDiskEncryption : False
EnableSoftDelete :
OriginalVault : Microsoft.Azure.Management.KeyVault.Models.Vault
ResourceId : /subscriptions/2ed3xxxx-xxxx-xxxx-xxxx-xxxxxxxxf1f7/resourceGroups/Bxxxxxxxp/providers/Microsoft.KeyVault/vaults/Bxxxxxxxp
VaultName : Bxxxxxxxp
ResourceGroupName : Bxxxxxxxp
Location : westeurope
Tags : {}
TagsTable :
SecurityWorldRegion : Europe | France | Germany etc.

> Name of the security world package that will wrap BYOK keys for this key vault