Какой лучший способ использовать / хранить ключи шифрования в MySQL

Question

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

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

Я выглядела до тошноты, но никто, кажется, не имеет пуленепробиваемого ответа.

Является ли это одной из тех проблем, когда вы должны довольствоваться достаточно хорошо? Учитывая, что я использую MySQL и PHP (возможно, Python), есть ли лучший способ подойти к этому?

Answer 1

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

Пакет PHP M_CRYPT считается довольно хорошим и дает вам гибкость в выборе алгоритма, который лучше всего подходит для ваших нужд.

Хранение вашего ключа на другом сервере имеет одно большое преимущество: ключ находится не на том же компьютере, что и зашифрованные данные ^*) . Поэтому, пока злоумышленник не имеет достаточного контроля над взломанным компьютером, он не может получить ключ.
Если злоумышленник получит полный контроль над машиной, на которой хранятся данные, он, скорее всего, сможет запросить ключ у веб-службы.

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

^*) Другой вариант - вводить пароль при запуске веб-сервера и хранить его только в памяти.

Возможное решение
Если вы видели решение, которое использовало следующий метод для шифрования файлов для пользователей с веб-доступом (я не уверен в вашей среде, но это может быть полезно):

• После создания пользователя длинный случайный ключ назначается новому пользователю.
• Этот случайный ключ хранится в зашифрованном столбце в пользовательской записи.
  ( только этот столбец зашифрован, чтобы не влиять на производительность остальной части записи! )
• Шифрование столбца с произвольным ключом выполняется с помощью 1 мастер-пароля, хранящегося в файле или в памяти.
  ( Лучше всего ввести пароль при запуске веб-сервера и сохранить его только в памяти. )
  ( Другой подход заключается в том, чтобы позволить пользователю ввести пароль и использовать его для шифрования / дешифрования столбца с произвольным ключом, но я не уверен, повысит ли это или уменьшит безопасность )
• Каждый документ, который должен быть зашифрован, шифруется случайным ключом для этого пользователя и затем сохраняется на диске.
• Документы хранятся с минимальными правами доступа в файловой системе.

Преимущества этого подхода:
1. Случайный ключ зашифрован в базе данных. Таким образом, у вас все еще есть дополнительная безопасность сервера базы данных в сочетании с зашифрованным столбцом. 2. Документы хранятся с разными ключами. Если злоумышленник завладеет ключом, скомпрометирована только часть документов.

Тем не менее:
Если злоумышленник завладеет главным паролем и получит доступ на чтение к таблице пользователей, вся система снова будет взломана.

Answer 2

Я бы, вероятно, сохранил его в файле, который находится в недоступном для Интернета каталоге и максимально заблокирован с разрешениями файловой системы.

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

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

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

Answer 3

Похоже, вы рассматриваете возможность использования «специфичного для столбца» ключа для использования с «AES_ENCRYPT» и «AES_DECRYPT». Как сказал комментатор, это плохая идея, потому что любое вторжение будет иметь доступ ко всем данным.

Если вы используете пароль, предоставленный пользователем, с солью или без нее, вы станете намного более безопасным.

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