I have Azure VM's which use encryption. Is it possible to make use of Availability Zones to be Datacenter resilient. Where do i need to store my Enterprise vault server keys, what about ipsec and bitlocker encryption.
If this isn't supported yet by MS just let me know, I will look to other solutions
Availabilty Zones are still in preview so you would need to sign up to be part of it
https://learn.microsoft.com/en-us/azure/availability-zones/az-overview
But to answer your question, Azure Encryption should have no issue with using Availability Zones. It is essentially the same thing as an Availability set just across data centers. So storing your Vault Keys would be no different if you were using any kind of availability set or not.
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
I have been tasked with building a PoC in Azure to "simulate" a future global deployment where data transfer time is important factor. The actual deployment will be using fully on-prem resources. So, as odd as it sounds, I am looking for the worse performance possible between the two options.
Architecture A (single tenant):
Create a single Azure tenant in the US region
Create a Resource Group with a US-based location
Create another Resource Group with an EU-based location
Architecture B (dual tenant):
Create an Azure tenant in the US region with a US-based RG
Create an entirely separate Azure tenant in an EU region with a EU-based RG
Would the dual-tenant structure above make any measurable difference one way or the other from the single-tenant (assuming all vNetwork, VMs, etc are identical)? I am thinking the single-tenant setup would be faster since (presumably) the traffic never leaves the Azure Service Fabric. But that's just speculation.
Here is what I got back from a colleague. She is (obviously) far more versed in Azure IaaS than I am. Answer #3 below indicates that the closest analog to the client MPLS connection is via VPN/ER. Not really worth the cost but still good to know.
Can a single subscription be used to provision US and European region located resources? Yes
Can resources in US and European located regions be managed from a US based portal? Yes
When allowing resources in US and European located regions communicate with one another what are our options? A couple primary ways...
Intra-regional (tenant to tenant:region to region)
Communications can be provisioned to travel across the Microsoft Azure
backbone. It never hits the open Internet.
VPN or Express Route:
Travels either the open internet or a private in TLS like route from
one region to another. However express route, the mpls like option,
does require advanced routing (BGP) and dedicated circuits at I other
point from different connectivity providers. Also, expensive.
For a new web application that is going to be built in Azure we are thinking of storing sensitive personal documents (scans of passports, educational transcripts, etc) in Azure blob.
Is this a secure enough approach or is there a better way of doing this? Thanks for your input.
Storage service encryption is enabled by default for all storage accounts. You have the option to use your own encryption keys if you wish.
https://learn.microsoft.com/en-us/azure/storage/common/storage-service-encryption
If you wish to create custom keys managed by Azure Key Vault, you can follow instructions here: https://learn.microsoft.com/en-us/azure/storage/common/storage-service-encryption-customer-managed-keys
However, if you worry about the data as it is being transferred to Azure blob, you will need to use client-side encryption as well. Here is the link for that: https://learn.microsoft.com/en-us/azure/storage/common/storage-client-side-encryption?toc=%2fazure%2fstorage%2fqueues%2ftoc.json
Like many things in Azure, it can be secure, but takes effort to do so.
1) As of last year, all storage accounts are encrypted at rest using Microsoft-managed keys using AES-256. You can also bring your own key, as mentioned here.
2) Employ client side encryption - that way, if the account was compromised, the attacker can't read the data; they also need the key to decrypt the data. This does influence performance, but is often acceptable for most scenarios.
3) Use the storage account's firewall to permit only the addresses that require access to the storage account.
Side note: If you're accessing Storage from an App Service, the outbound IP addresses will not change unless you scale the App Service Plan up or down. Auto-scaling your app service horizontally does not change the outbound IP addresses.
4) Integrate the storage account with Azure KeyVault to automatically rotate the keys and generate SAS tokens, as documented here. I wish this could be done via the portal, as most people aren't aware that this exists.
5) Do not use the storage account keys - generate and hand out short lived SAS tokens. KeyVault integration can help with this.
6) Enable storage diagnostics metrics and logging. While not a defensive measure by itself, it can be helpful after the fact.
7) Enable soft delete; this may reduce the impact of certain attacks if a breach were to occur.
8) Enable the 'secure transfer required' setting, to permit traffic only over HTTPS.
Is there any automatic replication of CryptoKey in different locations. If not, can I create myself replications by creating multiple KeyRings in different locations ? Will Google Cloud services support this kind of manual replication ?
I could't find the answer in the documentation.
Key material is backed up for redundancy in multiple locations in case of failover, and provides an SLA on availability of this material: https://cloud.google.com/kms/sla
You cannot currently duplicate the same key in multiple regions, with the same key material.
We want to enable Geo-Replication in Azure SQL Database. However for compliance reasons, we want to be sure that replication to secondary region happens over a secure encrypted channel.
Is there any documentation available to confirm that data in-transit during geo-replication goes over a secure encrypted channel?
I have looked into Microsoft Azure Trust center and there is a brief mention about using standard protocols for in-transit data. However I could not find information related to which protocols are used and how security of in-transit data is ensured.
Thank you for this question. Yes, the geo-replication uses a secure channel. If you are using V11 servers the SSL certificates are global and regularly rotated. If you are using V12 servers the certificates are scoped to the individual logical servers. This provides secure channel isolation not only between different customers but also between different applications. Based on this post I have filed a work time to reflect this in the documentation as well.