Для защиты конфиденциальных данных в MySQL 5.7 появилась возможность шифрования данных с помощью движка InnoDB . В этой статье я объясню принципы шифрования баз данных, используя конкретные примеры.
Шифрование на уровне базы данных
Шифрование всей системы может быть неоправданно дорогим, когда нужно защитить лишь часть данных. Также не всегда возможно изменить код и разработать механизм шифрования на уровне приложения. В таких случаях важно использовать шифрование на уровне базы.
Шифрование данных в MySQL 5,7 имеет следующие преимущества:
- Надежное шифрование AES-256 для таблиц InnoDB ;
- Прозрачное для приложений. Отсутствие кода для приложения, схемы. Нет необходимости изменять тип данных;
- Прозрачное для администраторов баз данных. Ключи не управляются администраторами баз данных;
- Управление ключами. Ключи можно безопасно хранить отдельно от данных, а смена ключей является простой.
MySQL 5.7 свойственно шифрование только таблиц InnoDB , при этом остаются открытыми следующие файлы: binlogs , redo logs , relay logs , slow log , error log , general log , и audit log .
Еще один заслуживающий внимания фактор — защита главного ключа внутри ключевого файла. Если главный ключ является составным, то механизм безопасности данных открыт для утечек. Решить проблему можно поместив файл ключа в раздел, который может быть отключен при запуске MySQL ( каталог, подключаемый только во время запуска базы данных ). Важно не потерять ключевой файл вместе с главным ключом, так как не будут осуществлено шифрование базы данных MySQL .
Начнем с того, что разрешим шифрование MySQL , добавив следующие параметры в файл конфигурации my.cnf .
Следующим шагом является запуск службы и проверка активности плагина.
Мы также можем проверить настройки шифрования баз данных.
Чтобы зашифровать таблицы в InnoDB, следует убедиться в том, что параметр innodb_file_per_table включен ( ON ).
Если этот параметр выключен ( OFF ), нужно добавить следующие параметры для файла конфигурации my.cnf , и перезапустить службу.
Рассмотрим шифрование базы данных MySQL в действии. Создадим таблицу для хранения конфиденциальных данных.
Добавляем строку к таблице.
Используем команду strings , чтобы извлечь каждую строку символов в двоичном файле, который относится к таблице sensitive_data_tb .
Также можно проверить, что ключевой файл пуст ( нет главного ключа ).
Чтобы использовать шифрование баз данных в таблице sensitive_data_tb , нужно сменить таблицу.
Если мы попытаемся вывести таблицу sensitive_data_tb , то увидим, что теперь данные зашифрованы, и их невозможно увидеть из файловой системы.
Хотя мы не можем видеть данные из файловой системы, их можно увидеть из MySQL , используя традиционный оператор SQL .
Также можно проверить, что главный ключ генерируется в MySQL .
Можно сменить главный ключ шифрования базы данных MySQL , выполнив инструкцию alter instance .
Можно верифицировать смены ключа, проверив временную отметку ключевого файла.
Просмотреть список зашифрованных таблиц, можно выполнив запрос.
Заключение
В этой статье я объяснил принципы шифрования данных на уровне базы в новой версии MySQL . Также я продемонстрировал их на реальных примерах. Теперь вы можете применять эти принципы и приведенные примеры для защиты конфиденциальной информации.
Данная публикация представляет собой перевод статьи « Data Encryption at Rest in MySQL 5.7 » , подготовленной дружной командой проекта Интернет-технологии.ру
В MySQL есть несколько встроенных функций шифрования, подробное описание на dev.mysql.com. Рассмотрим основные на примерах c использованием PHP PDO.
Пароли и ключи переданные в запросах SQL отправляются сервер MySQL в открытом виде, если не используется SSL-соединение. Кроме того, такие значения будут отображаться в логах. Чтобы этого избежать рекомендуется шифровать значения на стороне клиента или использовать хранимые процедуры.
Хранение данных в БД
Функции шифрования возвращают зашифрованный текст в виде двоичных данных, поэтому хранить их нужно в полях с типом BLOB:
Алгоритм DES
DES_ENCRYPT(str, key) – шифрует строку с использованием алгоритма Triple-DES.
DES_DECRYPT(crypt_str, key) – расшифровывает строку, если возникает ошибка, эта функция возвращается NULL.
Алгоритм AES
AES, также известный как Rijndael – симметричный алгоритм блочного шифрования, рекомендуется использовать в место DES.
AES_ENCRYPT(str, key) – шифрует строку str ключом key.
AES_DECRYPT(crypt_str, key) – расшифровывает строку.
Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.
Если приложение не очень секретное, то защищать имеет смысл только небольшую часть информации, например, сведения о паролях. Пароли ни в коем случае не следует хранить в открытом виде, поэтому обычно они шифруются. Однако вместо шифрования можно взять за образец принятую в большинстве UNIX-систем да и в самом MySQL практику: применить к паролю алгоритм хеширования и сохранить в таблице получившийся результат (свертку).
В отличие от традиционного шифрования, которое можно обратить, хорошая функция хеширования необратима. Единственный способ узнать пароль, по которому была сгенерирована свертка, – применить требующий огромных вычислительных ресурсов полный перебор (то есть, испробовать все возможные варианты входных данных).
В MySQL есть три функции для хеширования паролей: ENCRYPT(), SHA1 () и MD5Q 1 . Чтобы посмотреть, что они возвращают, проще всего приме-
нить каждую из них к одному и тому же входному тексту. Давайте сделаем это на примере строки p4ssword:
mysql> SELECT MD5(‘p4ssword’), ENCRYPT(‘p4ssword’), SHA1(‘p4ssword’)G
MD5(‘p4ssword’): 93863810133ebebe6e4c6bbc2a6ce1e7 ENCRYPT(‘p4ssword’): dDCjeBzIycENk
Все три функции возвращают строку букв и цифр фиксированной длины, которую можно сохранить в столбце типа CHAR. Поскольку ENCRYPT () может возвращать буквы в разных регистрах, то лучше указать для столбца тип CHAR BINARY.
Никогда не используйте в приложениях внутреннюю функцию MySQL PAS SWO R D (). Возвращаемые ей результаты зависят от версии MySQL.
Для сохранения свертки данных достаточно такой команды:
mysql> INSERT INTO user_table (user, pass) VALUES (‘user’, MD5(‘p4ssword’) );
Чтобы проверить пароль пользователя user, можно выполнить запрос SELECT и проверить совпадает ли свертка указанного переданного пароля с тем, что хранится в базе. На языке Perl это можно сделать следующим образом:
my $sth = $dbh->prepare(‘SELECT * FROM user_table ‘
. ‘WHERE user = ? AND pass = MD5(?)’);
Хеширование паролей – простой и относительно безопасный способ хранить пароли в базе данных, не опасаясь взлома. Чтобы усложнить атаку по словарю, можно хешировать комбинацию имени и пароля пользователя, так что результат зависит от большего числа переменных:
my $sth = $dbh->prepare(‘SELECT * FROM user_table ‘
. ‘WHERE user = ? AND pass = SHA1(CONCAT(?, ?))’); $sth->execute($username, $username, $password):
Единственная проблема – это риск, сопряженный с тем, что серверу пароли отправляются в открытом виде; он может быть записан в виде обычного текста в журнал на диске и виден в дампе памяти процесса. Чтобы немного снизить этот риск, можно хранить пароль в пользовательской переменной или вообще переместить хеширование на уровень приложения, чтобы устранить проблему на корню. Для большинства языков программирования имеются функции или библиотеки шифрования. Чуть ниже мы рассмотрим вопрос о шифровании на уровне приложения.