Использование DPAPI / ProtectedData в среде веб-фермы с хранилищем пользователей

Question

Мне было интересно, успешно ли кто-нибудь использовал DPAPI с хранилищем пользователей в среде веб-фермы?

Поскольку наше приложение недавно преобразовано из приложения ASP.NET из 1.1 в 2.0, мы используем специальную оболочку, которая напрямую вызывает методы CryptUnprotect. Но это должно быть так же, как метод ProtectedData, доступный в платформе 2.0.

Поскольку мы работаем в среде веб-фермы, мы не можем гарантировать, что машина, которая выполняла шифрование, будет той, которая ее расшифровывает. (Также, потому что сбои машины не должны разрушать наши зашифрованные данные).

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

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

«Ключ недействителен для использования в указанном состоянии».

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

Если это проблема, как другие используют DPAPI с хранилищем пользователей в среде веб-фермы?

Answer 1

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

Вы бы «установили» ключ на каждый сервер как часть процесса развертывания. Сценарий установки должен запускаться под идентификатором AppPool и может хранить зашифрованный ключ либо в файле app.config, либо в реестре.

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

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

Answer 2

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

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

надеюсь, что поможет!

Answer 3

Плакат Microsoft не прав. http://support.microsoft.com/default.aspx?scid=kb;en-us;309408#6

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

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