ключи для подключения к базе mysql

Не слышал о таком. Не думаю что это поддерживается.

Нельзя.

Понятно, спасибо.

Ещё такой вопрос - шифрует ли mysql свои файлы? Можно ли вынуть информацию из файлов базы, например если завладел файлами базы но не файлом базы где хранятся пользователи и пароли. Подкинул файлы базы к себе в базу, подконектился к ней под своим пользователем и смотри........

Таблицы (файлы) не шифруются. К тому же, хранить пароли в plain text - моветон, пароли вообще не должны сохраняться в базе, только отпечатки (как минимум).

Не шифрует. Как правило если злоумышленник завладел файлами баз данных то у него есть доступ и к базе данных пользователей и прочей служебки (служебная база данных, называется mysql).

СУБД шифрующая БД должна иметь доступ и к файлам базы, и к секрету которым они шифруются. Больше никому доступ к дому и другому не нужен. Следовательно что-бы украсть файлы базы злоумышленнику нужно получить права пользователя от которого работает СУБД (или рута), а тогда у него будет доступ и к файлам и к секрету которым они зашифрованы.
Получаются бессмысленная трата ресурсов на шифровку-дешифровку.

Если очень хочется поласкать паранойю, шифруй данные до записи в БД, правда тогда о многих полезных фишках SQL базы придётся забыть, или реализовывать их костылями.

Если очень хочется поласкать паранойю, шифруй данные до записи в БД

а как это можно осуществить в автомате, и в автомате осуществить это в обратном порядке что бы подсоединившись к базе смотреть данные в нормальном виде.

Проблема вот ещё какая.

Зашёл под анонимом с локального компьютера в локальную базу - по умолчанию вроде как полные права у него. Создал пользователя командой:

grant ALL PRIVILEGES on *.* to user@127.0.0.1 IDENTIFIED BY 'password' WITH GRANT OPTION;

В таблице user базы mysql такой пользователь появился, но войти:

mysql -u user -ppassword

ERROR 1045 (28000): Access denied for user 'user'@'localhost' (using password: YES)

Не помогло прописывание следующих опций в файле /etc/my.cnf

bind-address=127.0.0.1
connect-string="nodeid=2;host=127.0.0.1:1186"
connect-string="host=127.0.0.1:1186"

А вот если создать пользователя:

grant ALL PRIVILEGES on *.* to user@localhost IDENTIFIED BY 'password' WITH GRANT OPTION;

то есть вместо 127.0.0.1 написать localhost

то тогда захожу нормально.

и ещё такой момент по команде:

show databases;

выдаёт базы:

information_schema
mysql
test

файлы баз mysql и test есть в /var/lib/mysql а вот файлов базы information_schema нет в /var/lib/mysql хотя в my.cnf прописано datadir=/var/lib/mysql и база information_schema не пустая. Где могут быть её файлы?

Клиент по умолчанию (если явно не указано иное) подключается к mysql используя unix-сокет (а не сеть). Следовательно подключается он не с IP 127.0.0.1, IP в процессе вообще не участвует. Попробуй для проверки подключиться к мускулю коммандой mysql -uuser -pqwerty -H 127.0.0.1
Вообще обычно создают нескольких пользователей с разными значениями колонки Host, например user@127.0.0.1 и user@localhost с одинаковыми правами.

Под каким-это ты анонимом подключился к мускулю?

information_schema — виртуальная база, содержит информацию о состоянии mysql. На диске, естественно, не хранится.

Можешь написать проксю которая будет пропускать через себя запросы к БД и шифровать/дешифровать их, но логичнее встроить такую проксю непосредственно в ПО работающее с БД. Как правило (если ПО спроектировано не совсем безрукими личностями) работа с БД вынесена в отдельные классы/функции/модули и к ним можно привелосипедить шифрование/дешифрование. Но не стоит рассчитывать на то что подобное пройдёт совершенно прозрачно для приложения. Например как ты себе представляешь полнотекстовые поиск по шифрованному тексту.

Давай определимся: ты пытаешься уменьшить какую-то конкретную угрозу, или просто тешишь свою паранойю?

Положи базу на диск зашифрованный в DMCRYPT и будет щастье.

Всем спасибо за помощь.

С localhost и 127.0.0.1 разобрался.

Если пользователь user@localhost то подключаясь под таким пользователем к базе мы подключаемся через сокеты. В таком случае можно подключиться если в конфиге стоит параметр: skip-networking который запрещает серверу mysql слушать сеть.

Если пользователь user@127.0.0.1 то подключаясь под таким пользователем к базе мы подключаемся через сеть, хоть и на внутренний ip, поэтому в конфиге параметра skip-networking не должно быть. Если стоит параметр: bind-address=127.0.0.1 то сервер будет слушать только 127.0.0.1 адрес, если этого параметра нет то сервер будет слушать все адреса.

Теперь по поводу шифрования.

Пытаюсь сделать так - если стырят файлы базы то что бы не смогли их прочесть.

Положи базу на диск зашифрованный в DMCRYPT и будет щастье.

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

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

Вроде того, только шифровать будет не ФС, а уровнем ниже, подсистема dm-crypt

https://wiki.archlinux.org/index.php/Dm-crypt_with_LUKS

Пока СУБД работает диск примонтирован и расшифрован, файлы базы можно с него невозбранно скопировать так-же как с незашифрованного диска.
Прок есть только если кто-то получит доступ к выключенному серверу или включенному, но с остановленной СУБД (и отмонтированным разделом).
К тому-же в таком варианте автоматический запуск СУБД невозможен, админу придётся при каждом запуске подключаться к серверу и вводить пароль для расшифровки диска. Злоумышленник получивший рутовый доступ к системе (или доступ к учётке админа из под которой он монтирует шифрораздел) может перехватить вводимый админом пароль например заменив утилиту запрашивающую его на свою проксю.

Про то как отразится шифрование на производительность СУБД я промолчу.

Про то как отразится шифрование на производительность СУБД я промолчу.

На современных процессорах с AES-NI практически никак. Я гонял тесты fio на dm-zero устройствах, одно просто, поверх другого - dm-crypt. Разница в иопсах примерно раза в 1.5, и это при работе с бэкендом, который пишут в /dev/null, а читает из /dev/zero :)

Так что на реальных устройствах вряд-ли упрёшься в это.

В хард и так всё упирается, да и СУБД проц всё-таки грузит до кучи к шифрованию (хоть и не фатально).
Но производительность это не основной аргумент против. Это так, вишенка на торте.

Ну, всё зависит от целей шифрования. У нас его юзают на SAN-хранилищах, где лежат VM, на случай всяких маски-шоу и т.п.