Симметричное хранилище ключей
Моя компания будет хранить конфиденциальные данные для наших клиентов и будет шифровать данные с помощью одного из классов управляемых алгоритмов шифрования.NET. Большая часть работы выполнена, но мы не выяснили, как / где хранить ключ. Я провел легкий поиск и чтение, и кажется, что аппаратное решение может быть наиболее безопасным. У кого-нибудь есть какие-либо рекомендации относительно решения или метода хранения ключей?
Спасибо всем за ваши ответы.
Спулсон, проблема на самом деле в обеих "сферах", которые ты упомянул. Полагаю, мне следовало быть понятнее.
Сами данные, а также логика, которая их шифрует и дешифрует, абстрагируются в поставщика профилей ASP.NET. Этот поставщик профилей допускает как зашифрованные свойства профиля, так и обычные текстовые. Зашифрованные значения свойств хранятся точно так же, как и обычные текстовые значения - с очевидным исключением, что они были зашифрованы.
Тем не менее, ключ должен быть в состоянии быть вызванным по одной из трех причин:
- Авторизованное веб-приложение, работающее на авторизованном сервере, должно шифровать данные.
- То же, что № 1, но для расшифровки данных.
- Авторизованные члены нашей бизнес-команды должны просматривать зашифрованные данные.
Я представляю себе, что никто никогда не узнает ключ - будет программное обеспечение, контролирующее фактическое шифрование и дешифрование данных. Тем не менее, ключ все еще должен прийти откуда- то.
Полное раскрытие - если вы уже не могли сказать, я никогда не делал ничего подобного раньше, поэтому, если я совершенно не уверен в своем восприятии того, как это должно работать, во что бы то ни стало, дайте мне знать.
9 ответов
Есть только два реальных решения (технический аспект) этой проблемы. Предполагая, что доступ к ключу нужен только самому приложению...
Модуль аппаратной безопасности (HSM) - обычно довольно дорогой и не простой в реализации. Может быть выделенным устройством (например, nCipher) или специальным токеном (например, Alladin eToken). И тогда вы все еще должны определить, как обращаться с этим оборудованием...
DPAPI (API защиты данных Windows). Для этого есть классы в System.Security.Cryptography (ProtectedMemory, ProtectedStorage и т. Д.). Это отдает управление ключами ОС - и хорошо с этим справляется. Используемый в "USER_MODE", DPAPI блокирует расшифровку ключа для одного пользователя, который его зашифровал. (Не вдаваясь в подробности, пароль пользователя является частью схемы шифрования / дешифрования - и нет, изменение пароля не нарушает его.)
ДОБАВЛЕНО: Лучше всего использовать DPAPI для защиты вашего мастер-ключа, а не для непосредственного шифрования данных вашего приложения. И не забудьте установить надежные ACL-списки для вашего зашифрованного ключа...
В ответ на № 3 этого ответа от ОП
Один из способов, позволяющий авторизованным пользователям просматривать зашифрованные данные, но без их фактического знания ключа, - использовать условное депонирование ключей (rsa labs) (википедия).
Таким образом, ключ разбит на отдельные части и передан "попечителям". Из-за природы закрытых ключей каждый сегмент бесполезен сам по себе. Тем не менее, если данные необходимо расшифровать, "доверенные лица" могут объединить свои сегменты в единый ключ.
У нас та же проблема, и мы прошли через тот же процесс.
Нам нужно запустить процесс на одном компьютере (клиент), который затем войдет на второй компьютер (сервер базы данных).
В настоящее время мы считаем, что наилучшей практикой будет:
- Оператор вручную запускает процесс на клиентском ПК.
- Клиентский ПК запрашивает у оператора личные учетные данные для входа.
- Оператор вводит свои учетные данные.
- Клиентский ПК использует их для входа на сервер базы данных.
- Клиентский ПК запрашивает свои учетные данные для входа на сервер базы данных.
- Сервер базы данных проверяет, авторизованы ли учетные данные оператора для получения учетных данных клиентского процесса, и возвращает их на клиентский ПК.
- Клиентский ПК выходит из базы данных сервера.
- Клиентский компьютер входит обратно на сервер базы данных, используя свои собственные учетные данные.
По сути, пароль оператора является ключом, но он нигде не хранится.
Вы можете зашифровать симметричный ключ, используя другой симметричный ключ, полученный из пароля, используя что-то вроде PBKDF2.
Пусть пользователь представит пароль, сгенерирует новый ключ, используемый для шифрования данных, сгенерирует другой ключ с использованием пароля, затем зашифрует и сохранит ключ шифрования данных.
Он не так безопасен, как использование аппаратного токена, но все же может быть достаточно хорошим и довольно простым в использовании.
Лучше всего физически обезопасить оборудование, на котором находится ключ. Кроме того, никогда не записывайте его на диск - найдите какой-нибудь способ предотвратить перенос этой части памяти на диск. При шифровании / дешифровании ключ должен быть загружен в память, а при использовании небезопасного оборудования всегда есть место атаки.
Как вы сказали, существуют аппаратные устройства шифрования, но они не масштабируются - все шифрование / дешифрование проходит через чип.
Используйте жестко закодированный ключ для шифрования сгенерированного ключа перед его записью. Тогда вы можете написать это где угодно.
Да, вы можете найти жестко закодированный ключ, но пока вы предполагаете, что можно хранить симметричный ключ в любом месте, он не менее безопасен.
Я думаю, что я неправильно понял ваш вопрос. Вы спрашиваете не о том, как приложение обрабатывает свое хранилище ключей, а о том, как ваша компания будет хранить его.
В этом случае у вас есть два очевидных варианта:
Физический: запись на USB-накопитель, запись на компакт-диск и т. Д. Хранить в физически безопасном месте. Но вы сталкиваетесь с рекурсивной проблемой: где вы храните ключ от хранилища? Как правило, вы назначаете двух или более человек (или команду) для хранения ключей.
Программное обеспечение: Cyber-Ark Private Ark - это то, что моя компания использует для хранения своей секретной цифровой информации. Мы храним все наши пароли администратора, лицензионные ключи, закрытые ключи и т. Д. Он работает, используя сервер "хранилища" Windows, который не присоединен к домену, защищает все порты, кроме его собственного, и сохраняет все свои данные в зашифрованном виде на диске. Пользователи получают доступ через веб-интерфейс, который сначала аутентифицирует пользователя, а затем безопасно связывается с сервером хранилища через интерфейс, подобный проводнику. Все изменения и версии регистрируются. Но у этого также есть та же самая рекурсивная проблема... главный диск доступа администратора. Это хранится в нашем физическом хранилище с ограниченным доступом.
В зависимости от вашего приложения вы можете использовать метод Диффи-Хеллмана для двух сторон для безопасного согласования симметричного ключа.
После первоначального безопасного обмена ключ согласовывается, и остальная часть сеанса (или новый сеанс) может использовать этот новый симметричный ключ.
Сервер Microsoft Rights Management (RMS) имеет аналогичную проблему. Он просто решает проблему путем шифрования конфигурации с помощью мастер-пароля. ... пароль на пароль, если хотите.