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.htmli 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
signature.asc
Description: OpenPGP digital signature
