Web lists-archives.com

Re: can I just encrypt tables? what about the app?






Am 29.02.2016 um 20:30 schrieb shawn l.green:
Hi Reindl,

On 2/29/2016 2:16 PM, Reindl Harald wrote:


Am 29.02.2016 um 20:07 schrieb Jesper Wisborg Krogh:
Hi Lejeczek,

On 1/03/2016 00:31, lejeczek wrote:
hi everybody

a novice type of question - having a php + mysql, can one just encrypt
(internally in mysql) tables and php will be fine?
If not, would it be easy to re-code php to work with this new,
internal encryption?

Starting with MysQL 5.7.11, there is transparent data encryption (TDE)
for InnoDB tables. If you use that, it is as the name suggest
transparent for PHP. See also:
https://dev.mysql.com/doc/refman/5.7/en/innodb-tablespace-encryption.html


i still don't grok a usecase for such encryption because when a
webserver got compromised you have the same access as before, just
solwer with more overhead in general

what is the purpose of encryption on that layer?

Some process requirements state that some data should never be stored on
disk in plain text. This is one way to meet those requirements.

cryptsetup/luks can achieve that way better

Some data has been compromised not by cracking the primary database but
by breaking into a server containing backups of the data. This new
feature allows file-level backups (like those generated by MySQL
Enterprise Backup) to be secure.

well, somewhere must be the key to decrypt the data anyways, otherwise mysqld couldn't operate with the data - how do you protect that one without run in a chicken-egg problem

in the worst case it introduces the risk that some clueless guys become more careless "because my data is encrypted" somewhere else and don't grok what and what not is safe

What that feature achieves is that the data will be encrypted at rest,
not just in flight (using SSL).

see above

Clearly, this does not defeat an attacker who is able to compromise or
become an authenticated client who is normally allowed to read that
data. To fix that problem, you must employ application-level encryption
which encodes the data actually stored on the table. Clearly this last
type of encryption breaks the database server's ability to index the
data as the server would have no key to decrypt the content of the
fields to build any normal (clear-content) indexes on it. It would only
be able to index the encrypted (opaque) data. The clients would need to
code their queries with WHERE clauses looking for the exact encrypted
values they wanted to find

and even there you have the same problem: as long your application works with however encrypted data it needs to have they key somewhere and when i compromise your server i can read that key too

Attachment: signature.asc
Description: OpenPGP digital signature