Short:
Лучший способ перехода от значений базы данных в виде простого текста к полностью / полностью зашифрованным значениям в соответствии с правилами GDPR?
Объяснитель:
Я только что получил «хедз-ап», что из-за новой концепции «Конфиденциальность в соответствии с замыслом», юридически требуемой GDPR (Общим регламентом ЕС по защите данных), вся «конфиденциальная» информация должна быть зашифрованы. Это включает в себя имена, адреса, профили в социальных сетях, ..
В настоящее время мы работаем с полной производственной базой данных для 2000+ пользователей, доступной только через наш PHP REST API, который используется в качестве точки входа для всей сети и мобильное приложение (сторонних разработчиков пока нет). Эта база данных содержит адреса электронной почты, адреса, дескрипторы социальных сетей, имена, ip-адреса .., которые в настоящее время хранятся в виде простого текста (за исключением конфиденциальной информации на основе безопасности, такой как пароли, токены или другие значения, используемые для аутентификации). /identification).
Я не большой поклонник этого (с точки зрения разработки) из-за влияния мэра на производительность, алгоритмы поиска, весь PHP API и c (похоже на конец вся оптимизированная и «идеально настроенная база данных»), но так как это требуется и так как это дополнительный уровень защиты, я за все.
Теперь моя главная проблема заключается в том, что… все активно работает, и мы не можем просто сказать: «Хорошо, выключите сервер, зашифруйте все, разверните новую версию API и снова включите ее». Кроме того, эта миграция не может быть сделана «шаг за шагом», я думаю, все должно быть сделано сразу. Значения базы данных не могут быть зашифрованы, если API не готов обрабатывать дешифрование во всех запросах, и наоборот, база данных не может быть простым текстом, если API ожидает, что все будет зашифровано.
(Я рад, что все сделки типа API были единственной точкой входа / чтения для базы данных, без пользовательских сценариев / соединений, так что это облегчение)
Мы работаем VPS-сервер с высокой мощностью, поэтому небольшая потеря производительности из-за избыточных проверок и тому подобного является опцией, и мы также используем среды staging / dev, поэтому тестирование не представляет проблемы.
Я бы позволил MySQL обрабатывать AES с уникальным ключом для каждой записи, который основан на комбинации идентификатора (первичный ключ) и, например, метки времени создания (оба значения, которые никогда не изменятся) (что может быть не слишком умным для идеи в в случае «по какой-то причине» это значение изменяется, данные исчезают ... поэтому не уверены в этом), так что моему приложению PHP не нужно сообщать ключ в обычный текст при выполнении запросов, но, опять же, «создание ключа для дешифрования» все еще будет видно в журналах запросов и т. д. c, поэтому «наиболее безопасный» способ - это позволить приложению PHP шифровать и дешифровать все входящие / исходящие данные, но это может привести к невозможности, например, «поисковых запросов» (если я не отправлю ключ в этих указанных c запросах ..).
My вопрос:
Как бы go об этом ..? Должен ли я PHP обрабатывать en / decryption или предпочтительнее MySQL? Есть ли удобный способ перехода к зашифрованным значениям по пути, когда запрашивается запись? ..?
Моя идея состояла в том, чтобы не трогать какие-либо значения базы данных (за исключением обновления каждого нецелого столбца для обработки в 2-3 раза большего количества символов, которые указаны в данный момент), что можно сделать, не оказывая влияния на производство. Затем обновите все запросы API, шаг за шагом, чтобы проверить, зашифровано ли выбранное значение или нет. И когда один раздел работает нормально, обновите таблицу для этого раздела, чтобы зашифровать все значения. В качестве (простого) примера
MySQL -way; Каждый запрос SELECT:
SELECT IF_AES_ENCRYPTED(first_name, AES_DECRYPT(first_name), first_name) AS first_name FROM contacts WHERE id = 1;
(или) PHP -way: получение данных:
while ($row = $result->fetch_assoc()) {
$contact->setFirstName((IS_AES_ENCRYPTED($row['first_name']) ? AES_DECRYPT($row['first_name']) : $row['first_name']);
}
В конце развертывания:
UPDATE contacts SET first_name = AES_ENCRYPT(first_name);
Определенно есть способы сделать это sh, но, поскольку на данный момент я являюсь единственным разработчиком здесь, я просто не уверен, что было бы наиболее практичным / эффективным способом сделать это, или если я чрезмерно или недооценивая это или нет. Просто ищу других разработчиков, которые выполнили миграцию / обновление следующим образом.
Спасибо, Берт.