Хранение данных SSN/CC

Question

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

Раньше пользователь вводил тонну информации, включая SSN, супруг SSN и данные СС. Когда пользователь завершил процесс, информация была нажата на PDF-файлы, зашифрована (которая затем была зашифрована), а затем FTPed обратно на наш сервер. Мы сохранили все в БД, кроме SSN и CC, которые были стерты, когда сессия умерла.

Теперь нам необходимо сохранить эту информацию в базе данных, а также в некоторых случаях, когда после того, как пользователь A будет выполнен, пользователю B необходимо войти и подписать на бланках. После выполнения пользователем B файлы создаются и удаляются SSN/CC. Это означает, что данные должны жить в нашей БД с нескольких минут до месяца. Существует дата истечения срока действия, когда я уничтожаю данные из БД и начинаю их. Примечание. Я не использую данные CC, чтобы фактически взимать плату, поэтому я не могу передать ее третьей стороне, такой как Authorize.net или Paypal.

С учетом этого мне нужно знать, как лучше всего зашифровать этот материал и защитить его. Я разорван между выполнением AES в моем коде, используя GUID пользователя в качестве ключа или только столбца SQL Server 2005, который шифрует и ограничивает функцию расшифровки для пользователя сети.

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

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

Answer 1

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

В зависимости от того, как ваш сервер приложений подключается к серверу базы данных, встроенное функционирование шифрования столбцов в SQL Server должно быть хорошим решением. Если вы используете встроенную проверку подлинности, вы можете избежать наличия текстового пароля для пользователя приложения. Используя средства контроля доступа, доступные для защиты ваших ключей шифрования, вы можете настроить их таким образом, чтобы ни один другой пользователь (и, необязательно, даже администратор базы данных) не мог произвольно расшифровать данные из базы данных.

В июне 2008 года я выступил с докладом об использовании функции шифрования в SQL Server 2005 и 2008, который доступен here

Вот пример кода из этой презентации, что дает представление о том, как сделать это так, что только соответствующие пользователи могут просматривать расшифрованные данные:

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

CREATE MASTER KEY ENCRYPTION BY password = 'MasterKey1$' 

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

CREATE CERTIFICATE data_cert AUTHORIZATION data WITH SUBJECT = 'Data Cert' 

- обратите внимание, что вы также можете использовать параметр ENCRYPTION BY PASSWORD для предотвращения того, что администратор баз данных, который не знает пароль, не открывает пароль и, следовательно, не может дешифровать данные

- создать симметричные ключи для каждого пользователя, чтобы защитить свои данные - обратите внимание, что при запуске SQL Server на XP алгоритмы AES недоступны, вы должны использовать 3DES

CREATE SYMMETRIC KEY data_key WITH ALGORITHM = AES_256 ENCRYPTION BY CERTIFICATE data_cert 

- обратите внимание, вы можете также использовать ENCRYPTION BY PASSWORD здесь, а также предотвратить DBA, который не знает пароль от открытия этой клавиши

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

GRANT VIEW DEFINITION ON SYMMETRIC KEY::data_key TO [DOMAIN\ApplicationServiceAccount] 

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

Answer 2

Вы уже пересмотрены требования к Payment Card Industry?

Использование GUID пользователя в качестве ключа AES не похоже на совместимость.