MySQL Encryption и управление ключами
Я занимаюсь разработкой локальной системы интрасети на PHP/MySQL для управления данными наших клиентов. Похоже, что наилучшей практикой будет шифрование конфиденциальных данных на сервере MySQL во время их ввода.
Я не уверен, однако, о том, что было бы лучшим способом сделать это, оставаясь при этом доступными для данных.
Это кажется сложным вопросом: где хранятся ключи? Как лучше защитить ключ? Если ключ хранится на компьютере каждого пользователя, как его защитить, если компьютер эксплуатируется? Если ключ используется, как изменить ключ?
Если ключ хранится в БД, как его там защитить? Как бы пользователи получили к нему доступ?
3 ответа
На самом деле нет никаких встроенных функций MySQL для обработки сложных настроек зашифрованных ключей. Вам нужно будет реализовать большую часть логики шифрования в своем собственном коде PHP и / или на стороне браузера (javascript?).
Но ваши высказанные опасения немного странны: кажется, что ваши единственные настоящие опасения - это инъекция SQL или атака грубой силой (я полагаю, паролем) с удаленного клиентского рабочего стола / ноутбука. Это заставляет меня подозревать, что у вас уже запланированы некоторые другие, не упомянутые меры безопасности, и вы проанализировали возможные пути компромисса.
Во-первых, я предполагаю, что у вас есть правила брандмауэра, защищающие хост MySQL/PHP от любого доступа с неутвержденных IP-адресов удаленных клиентов. Если я прав, то имеет смысл, что вы беспокоитесь только об атаках с рабочих мест скомпрометированных пользователей.
Кроме того, я предполагаю, что вы понимаете, что если злоумышленник на удаленном клиентском хосте может перейти к привилегированным учетным записям root/Admin или напрямую скомпрометировать собственную учетную запись реального пользователя, то данные этого клиента имеют нулевую защиту независимо от шифрования или любых других защитных мер. (Злоумышленник может прочитать ключи оттуда, где они сохранены на диске, или отследить их, когда реальный пользователь вводит их при входе в систему, а ключи ведут к данным.)
Исходя из этих двух предположений, для нас имеет смысл сделать вывод, что единственными двумя соответствующими угрозами являются: A) угадывание паролей и B) попытки внедрения SQL:
- Если злоумышленник не завладеет ключом реального пользователя или хочет получить доступ не только к данным реального пользователя, он может попробовать грубые кредиты для входа в систему для реального пользователя или другой учетной записи. (Теоретически вы можете привязать каждую учетную запись к определенному IP-адресу удаленного клиента, что также поможет разделить риски на части.)
- Если злоумышленник действительно получает действительный ключ для реального пользователя, он проходит мимо экрана входа в систему (который, по-видимому, достаточно прост, чтобы быть безопасным), к мягкому недобрюшению потенциально ошибочного кода приложения. Успешная инъекция SQL из контекста реального пользователя может также дать ему доступ к данным других клиентов.
Теперь давайте поговорим о том, как шифрование на стороне сервера применяется в следующих ситуациях:
- Шифрование на стороне сервера определенно помогает против угрозы внедрения SQL. Если значения строк зашифрованы в таблицах БД, злоумышленник может видеть только зашифрованный зашифрованный текст данных, принадлежащих другим учетным записям. Угроза сдерживается, разделена.
- Тем не менее, грубое угадывание паролей не усложняет атакующему, сталкивающемуся с шифрованием на стороне сервера. Независимо от того, хранятся ли ключи пользователей на сервере или генерируются на месте из пароля, единственное, что имеет значение, - это наличие у вас правильного пароля. Либо сервер решает разрешить вам использовать действительный сохраненный ключ, потому что он проверяет, что ваш пароль правильный, или он вычисляет действительный ключ для вас, потому что ваш пароль является правильным вводом для генерации этого ключа.
С другой стороны, шифрование на стороне клиента фактически делает атаки с использованием перебора паролей неактуальными. Вы не можете грубо заставить правильно построенный ключ. Шифрование на стороне клиента в основном поддерживает тот же уровень защиты от внедрения SQL, что и шифрование на стороне сервера. Клиент может передать ключ на сервер при входе в систему, сохраняя копию в памяти до завершения сеанса, что увеличивает нагрузку на крипто-процессор на сервере. Или клиент может самостоятельно обрабатывать шифрование / дешифрование в браузере. Есть взлеты и падения к обеим методам:
- Передача его ключа на сервер намного проще для кодирования и управления, и, как правило, намного быстрее за счет более оптимизированного крипто-кода (вероятно, скомпилированного C).
- Чистый подход на стороне клиента обеспечивает дополнительную безопасность, потому что даже если злоумышленник получит root на сервере, он все равно не сможет прочитать зашифрованные данные и никогда не сможет их прочитать. Единственный возможный вектор атаки - это скомпрометировать удаленную рабочую станцию клиента.
Наконец, я хочу отметить, что существуют некоторые серьезные недостатки в шифровании данных в базе данных. Поскольку зашифрованные представления данных являются в основном случайными образцами, базовые функции базы данных, такие как индексация, объединения и т. Д., Работать не будут. Клиент берет на себя огромную логическую нагрузку и может потерять много преимуществ, которые обычно предоставляют функции базы данных.
Вы могли бы использовать Scytale. Это крипто-прокси NoSQL для современных СУБД и веб-приложений. Поддерживает многопользовательское и групповое шифрование. Загружен сильной криптосистемой RSA/AES. Это также на 100% бесплатно и с открытым исходным кодом.
Возможно, вы захотите взглянуть на ezNcrypt, который использует ecryptfs, средства управления доступом и управление ключами, чтобы обеспечить высокую безопасность и производительность для шифрования Linux баз данных MySQL и других процессов. Нет, я не работаю на них.