3

I have sensitive data in my application, just because encryption is not available with the Azure Table Storage, I can't store the sensitive data into it.

tRuEsAtM
  • 3,517
  • 6
  • 43
  • 83
  • Are you mean that you have multiple records, each record has 200 properties and some properties have sensitive data, so you need to encryption them? Or you just store some configuration settings which have some sensitive data? – Bruce Chen Jan 25 '17 at 10:02
  • @Bruce-MSFT Yeah, I have multiple records, each record has around 200 properties, and some properties have sensitive data. – tRuEsAtM Jan 25 '17 at 17:12

3 Answers3

6

As of 31 August 2017 the Azure storage service encrypts all data at rest using 256 bit AES for blobs, files, tables and queues as per this post Announcing Default Encryption for Azure Blobs, Files, Table and Queue Storage. This has also been applied to any storage accounts created before this date.

This is automatic and cannot be disabled but you can choose to use your own encryption keys instead of the Microsoft managed ones. It applies to both standard and premium performance tiers and Azure Resource Manager and classic deployment models.

Docs here Azure Storage Service Encryption for Data at Rest

Aquila Sands
  • 1,471
  • 1
  • 20
  • 28
  • Would this mean that it is now safe to store such things as API Keys/Access tokens in Azure Table Storage? – M0rty Apr 29 '19 at 06:30
  • 1
    @M0rty You may want to ask that over on https://security.stackexchange.com as safe is a relative term and a lot depends on the use cases for the keys/tokens as well as the infrastructure setup and access policies. That being said technically it should be ok but if you can you will probably be better off using Key Vault as it is designed specifically for this https://learn.microsoft.com/en-us/azure/key-vault/key-vault-overview – Aquila Sands May 08 '19 at 09:22
3

If you have secure data then it's better to encrypt, you can encrypt with Azure Key Vault one more link

Basically, in your entity, you will mark properties with attribute

[EncryptProperty]
public string EncryptedProperty1 { get; set; }

The benefit would be that you will always communicate with encrypted data, even if somebody, somehow get access to storage he will not be able to extract data.

tRuEsAtM
  • 3,517
  • 6
  • 43
  • 83
Vova Bilyachat
  • 18,765
  • 4
  • 55
  • 80
  • If I need to fetch the property, how to decrypt the property? – tRuEsAtM Jan 25 '17 at 17:15
  • I need to encrypt a dictionary object consisting of string keys and string values. I used the attribute [EncryptionProperty] but I am getting an error in the overridden WriteEntity() method. OperationContext is null. – tRuEsAtM Jan 25 '17 at 23:04
  • @Sameer Please update your entity classes so will see. – Vova Bilyachat Jan 26 '17 at 00:56
  • @Sameer is your table entity inherited from TableEntity class? – Vova Bilyachat Jan 26 '17 at 00:57
  • I was able to encrypt the entities. Having an issue in decrypting them. [http://stackoverflow.com/questions/41862839/getting-an-error-message-error-occurred-while-decoding-oaep-padding-while-tryi] – tRuEsAtM Jan 26 '17 at 01:16
0

I guess that depends on how you're managing your data. If only parts of your data need to be encrypted and the rest can remain clear then you could potentially encrypt those sensitive fields in your app before storing them in Table Storage. You'd have to implement the encryption yourself, of course, but you should be able to find plenty of libraries to help with that.

If you had to encrypt everything before storing I don't think it would work well. Table Storage is key:value pairs and all your values would be encrypted, rendering Table Storage useless for any kind of lookup. You'd have to read in all your data, sort and index it in your app, then get on with your regular work.

Jim Armstrong
  • 1
  • 1
  • How does encrypting table storage content render table storage *useless*? The only possible index is on partition key + row key; all other content, combined, is essentially the "value" (and any lookup on those properties requires a partition- or row-scan anyway). So, as long as you have searchable keys, there should be no impact to searching if encrypting values. – David Makogon Jan 25 '17 at 02:24
  • Specifically, if all values are encrypted (as opposed to only select values) then what, exactly, would you look for in your tables? Take a simple example with 20k records with names & SSNs stored and both the name values and SSN values are encrypted. Remember that Table Storage doesn't do encryption therefore the values all have to be encrypted programmatically. So what would table storage do for you? All the values are encrypted and therefore meaningless outside the context of the program – Jim Armstrong Jan 25 '17 at 02:33
  • As long as you're searching within partition+rowkey, it doesn't matter. The idea is that, with table storage, you retrieve a group of entities, based on the pk+rk search. My point is that encryption does not render table storage useless (unless you encrypt pk or rk but that makes no sense). And yes, the OP would need to encrypt/decrypt the 'value' portion - I don't see why that's any different from any other storage system not providing built-in encryption services. – David Makogon Jan 25 '17 at 02:37
  • Also: there's no need to break up values into individual properties - quite simple to store an entire entity as a single property (e.g. JSON), which makes decrypt/encrypt very straightforward, vs per-property operation. – David Makogon Jan 25 '17 at 02:38
  • @DavidMakogon One place where I would think the document needs to be broken up is when the size of the document (encrypted) goes beyond 32KB. Since each attribute can be of a maximum 64 KB in size and Azure Tables use 2 bytes to store each character, you only get 32KB per attribute. But other than this, I would agree with you. An alternative could be to use Blob Storage as it supports both client side encryption and encryption at REST and store blob URL in table. – Gaurav Mantri Jan 25 '17 at 03:29
  • @GauravMantri I don't have data, ideal for the blob storage like images or videos. I have around 200 properties to store into Azure Storage. Do you think Blob storage makes sense in this scenario? – tRuEsAtM Jan 25 '17 at 04:10
  • Sameer, the max size of an entity can be 1MB and each attribute in that entity can be of 64KB max size. 200 properties should be fine as you are allowed 256 properties per entity (253 user-defined + 3 system properties). As long as you are under these limits, you should be good to go. – Gaurav Mantri Jan 25 '17 at 05:54