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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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, чтобы администратор БД, не знающий пароль, не открыл этот ключ

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

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

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

Answer 2

Вы уже рассмотрели требования индустрии платежных карт ?

Использование GUID пользователя в качестве ключа AES не будет соответствовать требованиям.