Безопасный зашифрованный дизайн базы данных

У меня есть основанная на Интернете (perl/MySQL) CRM-система, и мне нужен раздел для HR, чтобы добавить информацию о дисциплинарных мерах и зарплате.

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

Я думал об использовании шифрования AES, но что я использую в качестве ключа? Если я использую пароль HR Manager, то, если она забывает пароль, мы теряем всю информацию о персонале. Если она изменяет свой пароль, мы должны расшифровать всю информацию и повторно зашифровать с помощью нового пароля, который кажется неэффективным и опасным, и может пойти ужасно неправильно, если есть ошибка на полпути через процесс.

У меня возникла идея, что у меня может быть ключ шифрования, который шифрует всю информацию и использует пароль менеджера HR для шифрования ключа. Затем она может изменить свой пароль, который ей нравится, и нам нужно будет снова зашифровать ключ. (И без пароля HR Manager данные безопасны)

Но тогда все еще существует проблема многопользовательского доступа к зашифрованным данным.

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

Кто-нибудь пробовал это раньше и преуспел?

Ответ 1

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

Данные, вероятно, будут сильно раздуты GnuPG, используя множество ключей: он должен создать ключ сеанса для полезной нагрузки, а затем зашифровать этот ключ, используя каждый из открытых ключей. Зашифрованные ключи хранятся вместе с данными.

Слабые части системы заключаются в том, что закрытые ключи должны быть доступны системе (т.е. не под контролем пользователя), и парольная фраза должна проходить через систему и поэтому может быть скомпрометирована ( т.е. занесено в журнал, украдено) хитроумным кодом. В конечном счете, необработанные данные также проходят через систему, поэтому хитроумный код может скомпрометировать это, не беспокоясь о ключах. Хороший обзор кода и контроль релиза будут необходимы для обеспечения безопасности.

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

Ответ 2

Почему бы просто не ограничивать доступ к базе данных или таблице в целом. Это кажется намного проще. Если у разработчика есть доступ к запросам на производство, нет возможности предотвратить их просмотр данных в конце дня, пользовательский интерфейс должен расшифровать/отобразить данные anwyays.

В опыте, который у меня был, объем работы, которую требуется для достижения "разработчиков, не может видеть данные о производстве вообще", огромен и практически невозможен. В конце концов, если разработчики должны поддерживать систему, ее будет сложно достичь. Если вам нужно отладить проблему с производством, тогда невозможно предоставить некоторым разработчикам доступ к производственным данным. Альтернативой является создание большого количества уровней и групп поддержки, резервных копий, тестовых данных и т.д.

Он может работать, но это не так просто, как могут подумать владельцы бизнеса.

Ответ 3

Другим подходом является использование единого ключа всей системы, хранящегося в базе данных, возможно, с уникальным идентификатором, чтобы периодически добавлять новые ключи. Используя режим счетчика, можно использовать стандартное шифрование MySQL AES без непосредственного отображения открытого текста в базе данных, а размер зашифрованных данных будет точно таким же, как размер открытого текста. Эскиз алгоритма:

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

выберите aes_encrypt ('counter', key) из hrkeys, где key_id = 'id';
Полученное значение зашифрованного счетчика обрезается до длины открытого текста и XORed с открытым текстом для создания зашифрованного текста.
Зашифрованный текст сохраняется.
Расшифровка - это точно такой же процесс, применяемый к зашифрованному тексту.

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

См. Википедия - Режим счетчика

Ответ 4

Я просто думаю вслух.

Это, похоже, требует механизма открытого/закрытого ключа. Информация будет храниться в зашифрованном виде с помощью открытого ключа HR и будет доступна только кому-то, у кого есть связанный закрытый ключ.

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

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

Ответ 5

Я не уверен, насколько это возможно в настоящее время, или о том, что поддерживает текущие стабильные системы БД, но альтернативные механизмы аутентификации на уровне базы данных могут помочь. Например, Drizzle, рефакторинг базы данных MySQL, поддерживает (или стремится?) Полностью подключаемую аутентификацию, не позволяя auth, серверу помещать auth или auth через PAM или какой-либо другой механизм, то есть вы можете использовать LDAP.

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

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

P.S. Возможно, было бы полезно использовать общее соединение БД для "обычной" информации о приложении, но когда делается попытка доступа к конфиденциальной информации, создается попытка подключения к конкретному БД. Это позволяет нескольким соединениям БД обрабатывать большинство запросов, предполагая, что большинство пользователей не просматривают конфиденциальную информацию. В противном случае отдельное соединение БД на пользователя может стать обременительным для БД.