MySQL Encryption и управление ключами

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

Я не уверен, однако, о том, что было бы лучшим способом сделать это при сохранении доступности данных.

Это трудный вопрос: где хранятся ключи? Как лучше защитить ключ? Если ключ хранится на компьютере каждого пользователя, как его защитить, если компьютер эксплуатируется? Если ключ используется, как изменить ключ?

Если ключ хранится в БД, как его там защитить? Как бы пользователи получили к нему доступ?

На самом деле нет никаких встроенных функций MySQL для обработки сложных настроек зашифрованных ключей. Вам нужно будет реализовать большую часть логики шифрования в своем собственном коде PHP и / или на стороне браузера (javascript?).

Но ваши высказанные опасения немного странны: кажется, что ваши единственные настоящие опасения - это инъекция SQL или атака грубой силой (я полагаю, паролем) с удаленного клиентского рабочего стола / ноутбука. Это заставляет меня подозревать, что у вас уже запланированы некоторые другие, не упомянутые меры безопасности, и вы проанализировали возможные пути компромисса.

• Во-первых, я предполагаю, что у вас есть правила брандмауэра, защищающие хост MySQL / PHP от любого доступа с неутвержденных IP-адресов удаленных клиентов. Если я прав, то имеет смысл, что вы беспокоитесь только об атаках с рабочих мест скомпрометированных пользователей.

• Кроме того, я предполагаю, что вы понимаете, что если злоумышленник на удаленном клиентском хосте может перейти к привилегированным учетным записям root / Admin или напрямую скомпрометировать собственную учетную запись реального пользователя, то данные этого клиента имеют нулевую защиту независимо от шифрования или любых других мер защиты. (Злоумышленник может прочитать ключи оттуда, где они сохранены на диске, или отследить их, когда реальный пользователь вводит их при входе в систему, а ключи ведут к данным.)

Исходя из этих двух предположений, для нас имеет смысл сделать вывод, что единственными двумя соответствующими угрозами являются: A) угадывание паролем и B) попытки внедрения SQL:

• Если злоумышленник не завладеет ключом реального пользователя или хочет получить доступ не только к данным реального пользователя, он может попробовать грубые кредиты для входа в систему для реального пользователя или другой учетной записи. (Теоретически вы можете привязать каждую учетную запись к определенному IP-адресу удаленного клиента, что также поможет разделить риски на части.)
• Если злоумышленник действительно получает действительный ключ для реального пользователя, он проходит мимо экрана входа в систему (который, по-видимому, достаточно прост, чтобы быть безопасным), к мягкому дно потенциально ошибочного кода приложения. Успешная инъекция SQL из контекста реального пользователя может также дать ему доступ к данным других клиентов.

Теперь поговорим о том, как шифрование на стороне сервера применяется в следующих ситуациях:

• Шифрование на стороне сервера определенно помогает против угрозы внедрения SQL. Если значения строк зашифрованы в таблицах БД, злоумышленник может видеть только зашифрованный зашифрованный текст данных, принадлежащих другим учетным записям. Угроза сдерживается, разделена.
• Тем не менее, злоумышленникам не удается усложнить взлом паролей, если они сталкиваются с шифрованием на стороне сервера. Независимо от того, хранятся ли ключи пользователей на сервере или генерируются на месте из пароля, единственное, что имеет значение, - это наличие у вас правильного пароля. Либо сервер решит разрешить вам использовать действительный сохраненный ключ, потому что он проверяет, что ваш пароль правильный, или он вычислит действительный ключ для вас, потому что ваш пароль является правильным вводом для генерации этого ключа.

С другой стороны, шифрование на стороне клиента фактически делает атаки с использованием перебора паролей неактуальными. Вы не можете грубо заставить правильно построенный ключ. Шифрование на стороне клиента поддерживает в основном тот же уровень защиты от внедрения SQL, что и шифрование на стороне сервера. Клиент может передать ключ серверу при входе в систему, сохраняя копию в памяти до завершения сеанса, что увеличивает нагрузку на крипто-процессор на сервере. Или клиент может самостоятельно обрабатывать шифрование / дешифрование в браузере. Есть взлеты и падения к обеим методам:

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

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

Возможно, вы захотите взглянуть на ezNcrypt , который использует ecryptfs, средства управления доступом и управление ключами, чтобы обеспечить высокую безопасность и производительность для шифрования Linux баз данных MySQL и других процессов. Нет, я не работаю на них.

Вы могли бы использовать Scytale. Это крипто-прокси NoSQL для современных СУБД и веб-приложений. Поддерживает многопользовательское и групповое шифрование. Загружен сильной криптосистемой RSA / AES. Это также на 100% бесплатно и с открытым исходным кодом.

https://bitbucket.org/maximelabelle/scytale