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

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

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

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

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


mysql encryption php security key
person Chris Kloberdanz    schedule 24.10.2008    source источник
comment
Какова цель шифрования столбца? Конечно, было бы разумно зашифровать конфиденциальные данные строки через ваше приложение и сохранить соль вместе со строкой, чтобы ее было сложнее расшифровать.   -  person Aupajo    schedule 24.10.2008
comment
Думаю, я имел в виду зашифровать определенное поле в каждой строке, используя AES_ENCRYPT. Таким образом, шифрование и дешифрование приложения лучше, чем функции MySQL, или вы просто говорите, что у меня должен быть уникальный соленый ключ для каждой строки при вызове функций MySQL.   -  person Chris Kloberdanz    schedule 24.10.2008

Ответы (3)


arrow_upward
8
arrow_downward

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

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

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

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

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

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

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

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

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

person Jacco    schedule 02.05.2009

arrow_upward
4
arrow_downward

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

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

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

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

person Bob Somers    schedule 24.10.2008

arrow_upward
1
arrow_downward

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

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

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

person Chris    schedule 24.10.2008