Шифрование данных или шифрование уровня приложения?

Question

Когда вам необходимо хранить конфиденциальные данные, такие как CC или SSN, вы:

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

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

Какие компромиссы вы нашли для своего решения? Делает ли запись вашей собственной программы плохой по сравнению с TDE? Является ли поддерживаемость кода или, наоборот, заблокирована поставщиком БД?

Answer 1

Я использовал множество методов шифрования, и я считаю, что для шифрования на стороне приложения проще и безопаснее использовать проверенную подпрограмму шифрования (т. Е. Библиотеки .NET).

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

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

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

EDIT:

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

Answer 2

Я согласен с Mayo, , но шифрование в БД может упростить обслуживание всей системы.

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

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

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

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

Шифрование в БД защищает только в БД, но вы можете рассмотреть возможность использования какой-либо связи SSL с БД. Я думаю (но я не уверен) TDE реализует такую ​​безопасную связь.

Приложение используется от пользователя, ненадежного субъекта. Вы должны учитывать, что данные в приложении потеряны. Зачем? Если я хочу украсть данные из системы, которая реализует шифрование данных на уровне приложения или уровне БД, достаточно было бы использовать фотокамеру для получения данных! Очень просто!

Вы должны учитывать безопасность системы, но и функциональность. Больше - безопасность, меньше - Функциональность. Надеюсь, мои соображения будут полезны для вас.

Answer 3

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

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

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

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

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

Answer 4

Будучи PCI-DSS Compliant не снимает вашу юридическую ответственность ...

В настоящее время существует только два состояния, которые обеспечивают такое освобождение: Вашингтон & Миннесота ... Продвижение TDE

АБД как Решение PCI-DSS BEWARE!

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

ИМХО TDE хорошо, когда в сочетании с надежным решением для шифрования на уровне приложений ... В качестве автономного решения, использующего только TDE, это тикающая бомба замедленного действия, которую PCI QSA покупает с PCI-DSS Compliant, с треском провалилась, чтобы принять к сведению ... Подождите, пока юристы поймут этот фундаментальный недостаток ...

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