Невозможно понять, как шифрование файлов ibd помогает защитить данные в MySql

Question

Я использую MySql 8.0.11 и использую плагин keyring_file, я зашифровал определенную таблицу, скажем, t1, в моей базе данных.

Когда я проверяю содержимое файла t1.ibd, я вижу, что содержимое зашифровано после успешного шифрования. Но я продолжаю видеть содержимое таблицы, используя запрос (выберите * из t1), даже если содержимое файла ibd зашифровано.

Итак, означает ли это, что шифрование работает только для файлов ibd (которые содержат данные и индексы), но я продолжу просматривать содержимое таблицы без каких-либо проблем, если у меня есть учетные данные базы данных?

UPDATE

Я прочитал пару комментариев и хотел бы добавить следующие вопросы, чтобы уточнить мой исходный запрос: После шифрования файлов ibd, если хакер взломает мою систему, на которой размещена база данных, хакер сможет увидеть фактические данные. Итак, как шифрование файлов ibd помогло мне защитить данные?

Answer 1

Файл .ibd содержит все данные и все индексы для таблицы. («Табличные пространства» могут содержать несколько таблиц; принципы одинаковы.)

С помощью плагина (и т. Д.), SELECT автоматически проходит расшифровку, делая шифрование «прозрачным». Тем не менее это реально. Вам нужно было что-то сделать, чтобы запустить программу, правильно? Именно тогда «ключ» был загружен в оперативную память для использования.

Шифрование файлов .ibd защищает вас от одной угрозы: кто-то захватывает (или копирует) ваш диск.

Но будьте осторожны. Существуют временные таблицы, журналы, другие журналы и т. Д., Которые могут быть или не быть зашифрованы. Они временно содержат некоторые данные. Ранние версии шифрования MySQL не смогли включить некоторые из них.

Функции AES позволяют вводить / дешифровать отдельные строки (например, один столбец в одной строке за раз). Но это позволяет вам защитить ключ en / decryption. Или, по крайней мере, никогда не иметь его на диске в виде открытого текста.

Прочитайте о «шифровании в покое» и «шифровании в полете». Шифрование файлов "в покое". Умный хакер атакует ваш код, чтобы он мог запустить SELECT после того, как учетные данные были загружены.

С шифрованием или без него «инъекция SQL» (qv) является хорошо зарекомендовавшим себя способом взлома данных и даже файловой системы. Защита для этого обеспечивается, например, проверкой / экранированием / etc данных, которые поступают из HTML <form>. Шифрование файлов не защищает от этого.

Я дал вам короткий список угроз для ваших данных. Реальный список намного длиннее. Вам нужно найти такой список и решить, какие из них вы хотите инвестировать в защиту. Безопасность не проста.