Безопасное зашифрованное проектирование баз данных
У меня есть веб-(perl/MySQL) CRM система, и мне нужен раздел для HR для добавления деталей о дисциплинарных мерах и зарплате.
Вся эта информация, которую мы храним в базе данных, должна быть зашифрована так, чтобы мы разработчики не видели его.
Я думал об использовании Шифрования AES, но что я использую в качестве ключа? Если я использую пароль Менеджера отдела кадров тогда, если она забывает свой пароль, мы теряем всю информацию о HR. Если она изменяет свой пароль, то мы должны дешифровать всю информацию и повторно зашифровать с новым паролем, который кажется неэффективным, и опасным, и мог пойти ужасающе неправильно, если существует ошибка половина пути посредством процесса.
У меня была идея, что у меня мог быть ключ шифрования, который шифрует всю информацию, и используйте пароль Менеджера отдела кадров для шифрования ключа. Тогда она может изменить свой пароль все, что она любит, и мы должны будем только повторно зашифровать ключ. (И без пароля Менеджера отдела кадров, данные безопасны),
Но тогда существует все еще проблема многопользовательского доступа к зашифрованным данным.
Я мог сохранить копию 'простого текста' ключа от сайта и зашифровать его с каждым новым паролем человека HR. Но тогда я знаю главный ключ, который не кажется идеальным.
Кто-либо попробовал это прежде и успешно выполнился?
5 ответов
GnuPG позволяет шифровать документы с помощью нескольких открытых ключей, а расшифровывать их с помощью любого из соответствующих закрытых ключей. Таким образом, вы можете позволить шифровать данные с помощью открытых ключей всех сотрудников отдела кадров. Расшифровка может быть выполнена любым человеком, имеющим один из закрытых ключей. Для расшифровки потребуется, чтобы системе были известны как закрытый ключ, так и парольная фраза, защищающая ключ. Закрытые ключи могут храниться в системе, а парольная фраза запрашиваться у пользователя.
При использовании GnuPG большого количества ключей данные, вероятно, будут довольно громоздкими: он должен создать сеансовый ключ для полезной нагрузки, а затем зашифровать этот ключ с помощью каждого из открытых ключей. Зашифрованные ключи хранятся вместе с данными.
Слабые стороны системы заключаются в том, что закрытые ключи должны быть доступны системе (т.е. не под контролем пользователя), а парольная фраза должна проходить через систему, и поэтому может быть скомпрометирована (т.е. записана в журнал, украдена) изворотливым кодом. В конечном счете, необработанные данные тоже проходят через систему, поэтому нечестный код может скомпрометировать их, не заботясь о ключах. Хорошая проверка кода и контроль выпуска будут необходимы для поддержания безопасности.
Лучше всего избегать использования встроенных функций шифрования MySQL: они регистрируются в журналах репликации, медленных запросов и запросов, а также могут быть видны в списке процессов - и поэтому любой, кто имеет доступ к журналам и списку процессов, имеет доступ к данным.
Почему бы просто не ограничить доступ к базе данных или таблице в целом. Это кажется намного проще. Если у разработчика есть доступ для запроса продукции, нет никакого способа предотвратить их просмотр данных b / c в конце дня, пользовательский интерфейс должен расшифровать / отобразить данные каждый раз.
По моему опыту, объем работы, необходимой для достижения «разработчики вообще не могут видеть производственные данные», огромен и почти невозможен. В конце концов, если разработчикам придется поддерживать систему, этого будет сложно достичь. Если вам нужно отладить производственную проблему, то невозможно не дать некоторым разработчикам доступ к производственным данным. Альтернативой является создание большого количества уровней и групп поддержки, резервных копий, тестовых данных и т. Д.
Это может сработать, но это не так просто, как думают владельцы бизнеса.
Другой подход заключается в использовании одного общесистемного ключа, хранящегося в базе данных - возможно, с уникальным идентификатором, чтобы можно было периодически добавлять новые ключи. Используя режим счетчика, можно использовать стандартное шифрование MySQL AES без непосредственного отображения открытого текста в базе данных, а размер зашифрованных данных будет точно таким же, как размер открытого текста. Набросок алгоритма:
- Приложение генерирует уникальное начальное значение счетчика для записи. Это может быть основано на каком-то уникальном атрибуте записи, или вы можете сгенерировать и сохранить уникальное значение для этой цели.
- Приложение генерирует поток блоков счетчика для записи на основе начального значения счетчика. Поток счетчика должен быть такого же размера или на 1 блок больше, чем открытый текст.
- Приложение определяет, какой ключ использовать. Если ключи периодически меняются, то следует использовать самый последний из них.
Поток счетчика отправляется в базу данных для шифрования: что-то вроде
выберите aes_encrypt ('counter', key) из hrkeys, где key_id = 'id';
Полученное зашифрованное значение счетчика обрезается до длина открытого текста и XORed с открытым текстом для создания зашифрованного текста.
- Сохранен зашифрованный текст.
- Расшифровка - это точно такой же процесс, который применяется к зашифрованному тексту.
Преимущества заключаются в том, что открытый текст никогда не проходит где-либо рядом с базой данных, и поэтому администраторы не могут видеть конфиденциальные данные. Однако в этом случае возникает проблема предотвращения доступа администраторов к зашифрованным значениям счетчиков или ключам. Первое может быть достигнуто путем использования SSL-соединений между вашим приложением и базой данных для операций шифрования. Второе можно смягчить с помощью управления доступом, гарантируя, что ключи никогда не появляются в дампах базы данных, сохраняя ключи в таблицах в памяти, так что контроль доступа не может быть нарушен перезапуском базы данных с помощью «пропуска-грантов». В конечном счете, единственный способ устранить эту угрозу - использовать защищенное от несанкционированного доступа устройство (HSM) для выполнения шифрования. Чем выше уровень безопасности, который вам нужен, тем меньше вероятность того, что вы сможете хранить ключи в базе данных.
Я просто размышляю вслух.
Похоже, это требует механизма открытого/закрытого ключа. Информация будет храниться в зашифрованном виде с открытым ключом HR и будет доступна для просмотра только тому, кто владеет соответствующим закрытым ключом.
Это, на мой взгляд, исключает возможность использования веб-интерфейса для просмотра этих конфиденциальных данных (ввод их через веб-интерфейс, конечно, возможен).
Учитывая, что люди приходят и уходят, привязка ключей к учетной записи конкретного человека представляется неосуществимой. Вместо этого необходимо отдельно распределять ключи и предусмотреть механизм, позволяющий сменить используемую пару ключей (и заново зашифровать базу данных - опять же без использования веб-интерфейса) в случае замены нынешнего менеджера по персоналу на другого. Конечно, ничто не помешает HR-менеджеру сбросить все данные перед уходом, пока ключи не будут заменены.
Я не уверен, насколько это возможно в настоящее время или какие текущие стабильные системы БД поддерживают это, но альтернативные механизмы аутентификации на уровне базы данных могут помочь . Например, Drizzle, рефакторинг базы кода MySQL, поддерживает (или стремится?) Полностью подключаемую аутентификацию, не разрешая аутентификацию, аутентификацию на сервере или аутентификацию через PAM или какой-либо другой механизм, что означает, что вы можете использовать LDAP.
Если бы у вас были разные уровни доступа в зависимости от соединения с базой данных, и при входе в приложение также указывалось, к чему вы действительно можете получить доступ в базе данных, вы теоретически могли бы построить систему, в которой невозможно было бы получить доступ к конфиденциальной информации о базе данных, если только с использованием учетной записи с определенными правами доступа, независимо от попыток повышения привилегий в самом приложении.
Пока люди, устанавливающие права доступа к учетным записям пользователей, могут доверять или сами могут видеть конфиденциальную информацию, это должно быть достаточно безопасно.
P.S. Может быть полезно использовать обычное соединение с БД для «обычной» информации приложения, но когда делается попытка доступа к конфиденциальной информации, то предпринимается попытка конкретного соединения с БД. Это позволяет нескольким соединениям с БД обрабатывать большинство запросов, если большинство пользователей не просматривают конфиденциальную информацию. В противном случае отдельное подключение к БД для каждого пользователя может стать обременительным для БД.