When creating a shared access policy or registering a device in Azure IoT hub, there will be a Primary key and Secondary key pair generated. And I noticed I can connect a device to IoT hub using either Primary key or Secondary key.
So, what's the purpose of having Primary/Secondary keys? How should I design the use of both keys?
The goal of primary and secondary key is two-fold.
First of all it would allow you to keep using your service when you want to replace your key. Say you connect all your services using the primary and you want to refresh it. You could use the secondary temporarily in your services and then change your primary without having downtime. After you do the change you can configure your services to use the new Primary key.
The second possibility would be that you give partners your secondary key and you use your primary if one of your partners would abuse the key you could replace it without having downtime in your own services.
Related
Does Azure Key Vault supports Geo-Replication between the regions? I don't see any options?
https://learn.microsoft.com/en-us/azure/key-vault/general/disaster-recovery-guidance
"The contents of your key vault are replicated within the region and
to a secondary region at least 150 miles away but within the same
geography to maintain high durability of your keys and secrets. See
the Azure paired regions document for details on specific region
pairs."
From #Karthikeyan Vijayakumar comment above:
However I have the application deployed on both West US (primary) and East US(secondary) and I want to sync between the regions.
You don't need to replicate your Key Vault instance to make it available to your applications in both regions.
Simply call the URL (https://<vault-instance-name>.vault.azure.net), Azure DNS will dynamically resolve to the active region. By default, the active region is the region where you created the instance. In the event this region is unavailable, the DNS will resolve to the geo-replica, hosted in the corresponding paired region.
The problem with this approach is that you still on the mercy of Microsoft, as the service will be reestablished only if they decide to failover the region.
Short story long: There is no user managed geo replication of Azure Key vault like Azure SQL for example. In your case, you need to build a workflow that replicates the values between your primary and secondary key vaults.
Backup and Restore : https://learn.microsoft.com/en-us/azure/key-vault/general/backup?tabs=azure-cli
You can use these capabilities to build your workflow.
You can use the changelog to track changes to your key vault, and trigger a backup/Restore or you can schedule it like once a day.
A change tracking is better as you can only replicate changes and not the entire key vault.
Regards
Various microservices will need access to various Azure resources, each of which has various connection string/authentication key requirements.
I'm thinking that Azure Key Vault is the best way to store the connection information for each resource, with the microservices authenticating themselves in order to gain access to the connection information they need.
Is this a best-practice approach?
Yes, I think so. You can secure access to your key vaults by allowing only authorized applications and users. As you need access to various Azure resources, I think it is very convenient to use Azure key vault.
Besides, Azure Key Vault uses Hardware Security Modules (HSMs) by Thales. Special about HSMs is that they do not give you keys. You create or import a key into an HSM. Later on you give data to the HSM and the HSM is executing cryptographic operations on that data. E.g. encrypting, decrypting, hashing ect. By the way, those hardware devices are really expensive. With Azure Key Vault you are able to use this protection for a small price. That's one benefit using Azure Key Vault.
Reference:
Best practices to use Key Vault
What is encoded in an Azure Expressroute Service key ? is there a security concern if exposed to a 3rd party, can it be used by another person or on another Azure subscription where it was not created? how can a customer protect this key, is it a one-time use.
The service key is not a secret by the virtue of its content. There is 1:1 mapping between the Azure Expressroute circuit (for a subscription) and the service key.
This means that for every new Azure ER circuit you launch within a single subscription (limit of 10 ER's), there will be a new service key.
The subject says it all...
Why there are two keys for Azure DocumentDB (primary and secondary)?
This is so that you can expire a key without having any system downtime. Say you want to replace your primary key. The procedure is
Configure your service to use the secondary key - if you use the service config you can do this without downtime.
Regenerate the primary key
(Optional) reconfigure your service to use the new primary key
If there was only one key at a time, your service would be down while you did the key replacement.
Good practise is to replace your keys on a regular basis (e.g every 6 months or whatever is appropriate based on the sensitivity of your data). You should also replace keys when anyone who has access to the keys leaves your business or team. Finally, you should obviously replace them if you think they have been compromised in some way. E.g. accidentally written to a log or posted to a public GitHub repo - it happens...
https://securosis.com/blog/my-500-cloud-security-screwup
Both the primary and secondary keys can be regenerated in the Azure portal (note: at the time of writing this is the preview portal). Select your DocumentDB then the Keys pane. There are two buttons at the top of the pane:
From the Azure Portal, on the Configure Tab for a notification hub I am able to generate a primary key and secondary key. I understand these are required to gain programmatic access to the Azure API - allowing my client app to create registrations and send messages.
Could anyone please explain:
Why are there two keys (primary and secondary)?
Do the keys generated from this UI expire and if so how long do they live before expiry?
They don't expire. The reason there are two is because it's recommended that you regenerate the keys periodically for security reasons. For example, suppose your application is using the primary key today. If you regenerated the primary key, then your application would be broken until you could update it and resulting in downtime. Instead, you can change your application to use the secondary key with basically little or no downtime. Then, after your application has been updated, you can regenerate the primary key. Next month (or whatever schedule you like), you can repeat the process, switching back to the primary key and regenerating the secondary key.
This is not unique to Notification Hubs. You will see primary and secondary keys in other services such as Storage and Media Services. The idea is the same.