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