Как можно шифровать данные в базе данных MySQL?

Question

[Илья]

Мне необходимо обезопасить хранения данных в MySQL. Какими лучше способами или средствами всё это сделать. Какие-то способы шифрования данных или иные методы?

Comments

[Chupaka]

В первую очередь необходимо понять, от кого или от чего защищаемся. Шифрование ради шифрования смысла не имеет. Обезопасить от чего?

Answer 1

[mefutu]

Присоединяюсь к предыдущим ответам. Даже если вы и решите данные шифровать, то прежде всего подумайте, как сильно просядет ваша производительность, ведь шифровка/дешифровка- операции совсем не бесплатные. И смысл весь теряется в этом, если отправлять вы их будете в открытом виде. Лучше подумайте, как защитить канал передачи.
Используйте api промежуточный сервер с разделенными ролями, а сам сервер с бд спрячьте за этой прослойкой, в таком случае вам и шифровать ничего не прийдется.

Comments

[Илья]

пока что я скрыл доступ из вне для базы, только локальный. Подключение осуществляется через туннель по ssh, который прокидывает порт до базы.

[xmoonlight]

Илья, и права подрежьте для юзера БД (см. мой ответ, п.3) иначе ssh может не помочь, если доберутся до веб-сервера.

[Илья]

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

[xmoonlight]

Илья, вывод списка таблиц и работу со схемой БД - запретите минимум!

Answer 2

[Rsa97]

Шифровать данные смысла нет. По шифрованным данным не будет нормально работать индексация. К тому же, если кто-то сольёт всю базу, то, скорее всего, он получит и ваши скрипты, которые шифруют/дешифруют данные при работе.

Comments

[Илья]

нет скрипты, точнее логика вся, в отдельной программе.

[Rsa97]

Илья, И что? Если мне удалось базу слить, то что помешает слить программу и выдернуть из неё алгоритм и ключ шифрования?

[hOtRush]

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

[Евгений Иванов]

И все таки Rsa97 не совсем прав.
Пример Enpass, БД которого часто хранится на облачном диске, в зашифрованном виде. Часто.
И никто, в своей массе, ничего не украл. Т.к. общепринято, что алгоритм шифрования известен злоумышленнику, а вот секретный ключ нет. Секретный ключ - пароль.
Нет пароля - нет данных. А вот кража пароля уже другой разговор.
Всё уже придумано до нас.

[Rsa97]

Евгений Иванов, Согласен, могут быть специфические БД, с небольшим объёмом данных и очень редкими запросами. Такие базы можно зашифровать безболезненно для скорости работы. Но и то, при полной шифрации данных даже простой поиск придётся делать получением всех строк, и их дешифровкой на клиенте.

[Евгений Иванов]

Rsa97, вопрос интересный. Существует шифрование на лету. Да и много ещё вариантов.
Например, truecrypt.
Вы можете зашифровать хоть террабайт информации и один раз смонтировав том получать доступ к дешифрованной информации почти без потери скорости. Ну, по крайней мере, сильной её потери я не заметил. Вопрос рациональности и безопасности такого решения остается открытым, но возможность есть.

В конечном итоге мы постоянно обмениваемся зашифрованными данными (HTTPS ) и это уже стало нормой.

[Rsa97]

Евгений Иванов, В любом случае, шифрование не увеличивает скорость доступа. К тому же, вы получите не базу данных, содержащую зашифрованные данные, а базу, лежащую на зашифрованном диске или записанную в зашифрованный файл. То есть, если я получу доступ к серверу MySQL, то он вернёт мне расшифрованные данные, так как они дешифруются до него.

Answer 3

[xmoonlight]

1. Родное шифрование всей БД (с рабочим индексированием) есть начиная с mysql 5.7 - статейка
2. Можно использовать раздельное хранение скриптов и базы. Например, на разных хостингах с авторизацией по ключам через промежуточный REST-интерфейс.
3. Ограничить права пользователя БД, указанного в web-скриптах только на определённые операции.
4. Использовать обфускацию серверных скриптов, работающих с БД.
5. Использовать встроенные функции шифрования, ключи/пароли для расшифровки - хранить в "разорванном" виде (из нескольких частей), разбросанных по нескольким скрипт-файлам и/или своим REST-сервисам: чтобы его можно было получить только собрав все компоненты вместе.

Comments

[Дмитрий]

А если такая ситуация:
я завел отдельный хостинг под сервер mysql для хранения БД.
Как мне

3. Ограничить права пользователя БД, указанного в web-скриптах только на определённые операции.

Ведь создавая пользователя для базы данных там есть только несколько типов прав:
CREATE
SELECT
INSERT
UPDATE
DELETE
DROP

Допустим я разрешу только select, insert и update
Но злоумышленник, получив доступ к хостингу с приложением, может легко выполнить запрос:
select * from users
и получит весь список пользователей и их личных данных
Как вот с таким бороться?

[xmoonlight]

Дмитрий, это на мой блог...

Answer 4

[Anubis]

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

Comments

[Илья]

не пароли. Это-то да, разумеется так и сделаю. А сами данные в базе хранить в чистом виде или шифровать ?

[Anubis]

Илья, зачем что-то шифровать? Обезопасить доступ к бд, а не сами данные.

Answer 5

[Владимир Скибин]

Для шифрования в своей практике использовал шифрование и расшифровку именно на уровне приложения (правда было приложение на nodejs). В базе хранились шифрованные данные и передавались по каналу связи аналогично шифрованные данные. Их расшифровкой и проверкой целостности занималось как раз приложение. Ключ для расшифровки указывался один раз при запуске приложения. Это лишало возможности автономного перезапуска приложения, но как раз давало возможность не хранить ключ в явном виде (в файлах). При "скачивании" зачастую редко делается "дамп" оперативной памяти, на что и была сделана собственно ставка плюс к этому были подключены дополнительные системы мониторинга для ограничения доступа, контроля целостности. Таким образом базу данных можно было хранить хоть в открытом источнике (недовенренном датацентре), а пароль для запуска приложения был составным.
Быстродействие приложения конечно немного просела, но того требовали условия его использования. И да, шифровались только те данные, которые не участвовали в поиске / индексации.

Answer 6

[catanfa]

Если с помощью шифрования вы хотитите защитить секреты (пароли к базе, ключи доступа к сторонним api, и т.д.), то существуют сервисы, специально для этого предназначенные, которые обеспечивают наивысший уровень безопасности (при аккуратном использовании)

• AWS Secrets Manager
  
• vault
  

Comments

[xmoonlight]

Сторонние сервисы никогда не могут обеспечить наивысший уровень безопасности для ваших данных.
Про AWS в частности (цитата отсюда):

При извлечении конфиденциальных данных Secrets Manager дешифрует их и передает по безопасному соединению TLS в локальную среду пользователя.