2 ms·

How on earth is SlackHQ's response reasonable? Let me count the ways it's not. There are plenty of database systems (MySQL enterprise, Postgres, Oracle, SQL Se

How on earth is SlackHQ's response reasonable? Let me count the ways it's not. There are plenty of database systems (MySQL enterprise, Postgres, Oracle, SQL Server) that support encrypted data-at-rest and there are even more ways to run a DBMS on top of encrypted disks and volumes (dm-crypt, Bitlocker). Running in the cloud? Amazon AWS provides EBS encryption (and likely more) and Microsoft Azure provides data at rest encryption for all storage types (tables, queues, page and block (disk) blobs) and transparent encryption for Azure SQL Database. Want more control over the encryption in the cloud? Amazon and Azure both provide HSMs, called CloudHSM and Azure Key Vault, respectively. Azure supports additional encryption at the VM level integrating with Bitlocker and/or DM-Crypt. There's really no excuse for not having figured out data encryption for customer data and secrets at this point. Edit: It appears Slack has since updated their security docs and they now use encryption at rest. Good! It's inexplicable to me that anyone would believe that a database index would be incompatible with encryption.

zapu 10y ago
I don't understand how any encryption like this helps, unless it's end-to-end. When somebody breaks in, they just get the encryption keys as well, no? Can anyone point out what am I missing here? Thank you.
- mynegation 10y ago
  There were quite a number of data breaches attributed to a theft of a back up tape from the storage.
- AaronFriel 10y ago
  When "somebody" breaks in, what level of access do they have? In a larger business, access should be compartmentalized and enforced not just with policies but with encryption where possible. Virtual machine or cloud service administrators shouldn't have the ability to read customer data, they should just see binary blobs. A devops/sysadmin employee might have access to the machines running the database, but even if they log in they shouldn't necessarily have read access to the database files, and even if they should, again, customer data should be encrypted blobs to them. This means that even if you phish the CEO of the company, you still have to obtain additional access to read customer data. If using AWS or Azure encryption properly, it may even require obtaining credentials for multiple users. This isn't even the full extent of the encryption possible, keys can be placed in silos per tenant, and decrypted only once a user logs in. Then even if you are a developer, you wouldn't have access without intercepting client communications.

zapu 10y ago

I don't understand how any encryption like this helps, unless it's end-to-end. When somebody breaks in, they just get the encryption keys as well, no? Can anyone point out what am I missing here? Thank you.

mynegation 10y ago
There were quite a number of data breaches attributed to a theft of a back up tape from the storage.
AaronFriel 10y ago
When "somebody" breaks in, what level of access do they have? In a larger business, access should be compartmentalized and enforced not just with policies but with encryption where possible. Virtual machine or cloud service administrators shouldn't have the ability to read customer data, they should just see binary blobs. A devops/sysadmin employee might have access to the machines running the database, but even if they log in they shouldn't necessarily have read access to the database files, and even if they should, again, customer data should be encrypted blobs to them. This means that even if you phish the CEO of the company, you still have to obtain additional access to read customer data. If using AWS or Azure encryption properly, it may even require obtaining credentials for multiple users. This isn't even the full extent of the encryption possible, keys can be placed in silos per tenant, and decrypted only once a user logs in. Then even if you are a developer, you wouldn't have access without intercepting client communications.