We have migrated our Azure Classic storage accounts to Azure Resource Manager storage accounts. We migrated just under a week ago and data which wasn't encrypted before is still not encrypted.
We were under the impression that after migrating there would be a background task which would go through and encrypt any data in the storage account which was not already encrypted.
Is this true?
Yes, it is true. Data stored in the storage account prior to enabling the Storage Service Encryption will retroactively get encrypted. The data may not be immediately encrypted but the system background encryption process will encrypt the data, and it may take months for the process to encrypt the data.
Related
I have a compliance activity to encrypt my Azure Service Bus premium to encrypt using a customer-managed key. However, Microsoft documentation states that the namespace must be devoid of queues, topics, and data. My ASB has data, up and running. I cannot afford to downtime to delete queues, enable encryption, and then continue. Are there any other options?
If you check this Configure customer-managed keys for encrypting Azure Service Bus document then you will find that -
Azure Service Bus Premium provides encryption of data at rest with Azure Storage Service Encryption. Service Bus Premium uses Azure Storage to store the data. All the data that's stored with Azure Storage is encrypted using Microsoft-managed keys.
And it also has a limitation as you mentioned int the question that the encryption can only be enabled for new or empty namespaces. If the namespace contains any queues or topics, then the encryption operation will fail. There is no other option.
So we have the two type of encryption as follows -
Encryption at Rest -
Azure ensures the disks used in persisting the messages are encrypted either with Microsoft Managed Keys (which is the default) or customers managed keys to encrypt the disks.
Encryption in Transit -
This is basically protecting the medium which is used to transmit the data from point-to-point. A classic of this would be TLS/SSL encryption in Azure being used to encrypt the data transmitted.
For more information read the best practices in Securing Azure Service Bus and Encrypt Azure Service Bus Data at REST using User Keys documents.
My issue
I try to understand how VM Disk Encryption work on Azure VM.
I have a Key Vault and a Disk Encryption set configured
What I did - 1
I create a VM with a disk selecting Encryption type = Encryption at rest with a custom managed key.
I select my Key Encryption set.
Portal confirms by displaying SSE with CMK in VM/Disks.
But:
Get-AzVMDiskEncryptionStatus says OS volume and DataVolumes are NotEncrypted.
What I did - 2
I create another VM, but this time I go to VM/Disks/Additional Settings and select Disk to encrypt.
This time the only option is a Key Vault, not a Disk Encryption Set.
I select OS and Data Disks.
Portal says:
This time, Get-AzVMDiskEncryptionStatus says:
My questions
What is the difference between the two methods?
Why Get-AzVMDiskEncryptionStatus return so un expected results?
To answer your questions:
There are Server-side encryption and Azure disk encryption. The first one of what you did is the Server-side encryption and the second one is Azure Disk encryption.
Most Azure managed disks are encrypted with Azure Storage encryption, which uses server-side encryption (SSE) to protect your data. Azure Storage Encryption automatically encrypts your data stored on Azure managed disks (OS and data disks) at rest by default when persisting it to the cloud. Disks with encryption at host enabled, however, are not encrypted through Azure Storage. When you enable encryption at the host, that encryption starts on the VM host itself, the Azure server that your VM is allocated to. After enabling encryption at the host, all this data is encrypted at rest and flows encrypted to the Storage service, where it is persisted. Essentially, encryption at the host encrypts your data from end-to-end.
Azure Disk Encryption leverages either the DM-Crypt feature of Linux or the BitLocker feature of Windows to encrypt managed disks with customer-managed keys within the guest VM. Server-side encryption with customer-managed keys improves on ADE by enabling you to use any OS types and images for your VMs by encrypting data in the Storage service.
For more information, read here.
It's expected. The Get-AzureRmVMDiskEncryptionStatus cmdlet gets the encryption status of the virtual machine. It displays the encryption status of the operating system and data volumes. This does not get server-side encrytion status.
There is old, unencrypted data that has to be encrypted. I enabled encryption for future data but want to make sure all data across storage accounts is encrypted at rest.
I know that I can use AZCopy to move data, but is there a way to keep the current storage accounts but encrypt the data inside?
Currently there is no other way to encrypt existing data.
SSE only encrypts newly created data after the encryption is enabled. If for example you create a new Resource Manager storage account but don't turn on encryption, and then you upload blobs or archived VHDs to that storage account and then turn on SSE, those blobs will not be encrypted unless they are rewritten or copied.
Only option to encrypt the data within the same Storage Account is to copy the data to another container.
https://learn.microsoft.com/en-us/azure/storage/common/storage-service-encryption
Is Azure Cloud Service Local Storage encrypted?
I would like to utilize Local Storage for my worker role as a scratch disk for image manipulation. I'm currently using an encrypted Azure file share, but the performance isn't great. I'm concerned that if I start using Local Storage my data may not be encrypted at rest. I haven't been able to find definitive information about encryption and Local Storage.
Microsoft clearly allows blob and file services to encrypt data using Storage Service Encryption (SSE) and its trivial to enable this via the Azure Portal.
When configuring local storage in the cloud service definition I don't see any options related to encryption. There's also no mention of Local Storage in the Azure data at rest white paper.
It looks like Azure Disk Encryption supports encrypting both OS and data drives, but again, I didn't see any mention of Local Storage or PaaS in the Azure Disk Encryption page.
I am developing a site that stores text in Azure Blob Storage. The text may be sensitive (not necessarily passwords, but personal information). I am trying to decide whether or not I should encrypt the text before I store it in Azure Blob Storage. My understanding is that this could mitigate a risk of exposing the data should the Azure key and account name get out and a malicious user download the blob. My questions are:
Are Azure Blobs already being encrypted when they land on disk at Microsoft? Is the account key used as an encryption key, or just an access token?
IF I were to do this in Azure Websites by using the .NET AES algorithm, where should I store the encryption key(s) or passphrase/salt used to generate a key? (ie is web.config an ok place for this?)
Blob content is not encrypted; that step would be completely up to you. Blob access is strictly controlled by access key (and there are two keys: primary and secondary, both working equally). Here are my thoughts on this:
If Storage access is exclusive to your app tier (that is, the key is never exposed outside of your app), risk is fairly low (vs. embedding the key in a desktop or mobile app, or using it with online storage browser services). Someone would need to steal the key from you somehow (like stealing source / config files). You mentioned using Websites, which doesn't provide RDP access, further protecting your running code.
If, somehow, your key were compromised, you can invalidate the key by generating a new one. This immediately cuts off access to anyone holding the old key. As a general pattern, when I use external tools (such as the Cerebrata tool), I always use my secondary key, reserving my primary key for my app. That way, I can always invalidate my secondary key as often as I like, preventing these tools from accessing my storage but not interfering with my running apps.
If you need to expose specific blobs to your customers, you have two ways to do it. First, you can download the blob to your web server, and then stream content down. Second: You can generate a Shared Access Signature (SAS) for the specific blob, and then give that resultant URI to the user (e.g. as the href of of an <a> tag). By using SAS, you permit access to a private blob for a given amount of time, like 10-20 minutes. Even if someone took an SAS URL and posted it on the Internet, it would only be valid for the time window you specified (it's hashed, preventing modification).
Consider multiple storage accounts for multiple apps (or even per app). This way, if there were a security breach, damage is limited to the specific compromised storage account.
EDIT April 2016
Azure Storage Service encryption for data at rest, just announced, is now in preview and available for any storage account created via the Azure Resource Manager (ARM). It is not available for "Classic" storage accounts (the rest of my answer, above, still applies). You can enable/disable encryption via the portal, for your storage account:
The service is available for blobs in both standard and premium storage accounts. More details are in this post.
David's answer is spot-on, but for people looking to actually implement the encryption the poster asked about, I've put together some samples and libraries at Azure Encryption Extensions.