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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

4. Поток счетчика отправляется в базу данных для шифрования: что-то вроде

   выберите aes_encrypt ('counter', key) из hrkeys, где key_id = 'id';

5. Полученное значение зашифрованного счетчика обрезается до длины открытого текста и XORed с открытым текстом для получения зашифрованного текста.

6. Зашифрованный текст сохраняется.
7. Расшифровка - точно такой же процесс, который применяется к зашифрованному тексту.

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

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

Answer 4

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

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

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

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

Answer 5

Я просто размышляю вслух.

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

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

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