Назад | Перейти на главную страницу

Каков безопасный способ разрешить любому пользователю Windows зашифровать файл, но только определенное приложение расшифрует его

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

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

1) Есть ли способ для администратора импортировать файл .cer или .pfx в личный магазин другого пользователя?

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

2) Есть ли соответствующий магазин Windows, в котором я должен хранить MyServiceAccount.cer, чтобы автономное приложение могло получить открытый ключ независимо от того, под какой учетной записью запущен пользователь?

Поскольку MyServiceAccount.pfx хранится в личном хранилище MySrviceAccount, я предполагаю, что единственная учетная запись, которая может получить закрытый ключ, - это эта учетная запись. Я знаю, что администратор может войти в систему под этой учетной записью, поэтому я должен защищать закрытый ключ, чтобы пароль требовался. Но..

3) Как сервисное приложение может получить доступ к ключу в личном хранилище, защищенном паролем, без встраивания пароля в код?

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

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

В вашем случае лучшим вариантом может быть размещение закрытого ключа и сертификата в хранилище «LocalMachine». Все пользователи могут читать сертификаты, которые находятся в этом хранилище, но не могут писать в него. Более того, по умолчанию доступ к закрытому ключу ограничен администраторами, но вы можете изменить эти права доступа. Попробуйте использовать mmc.exe, затем добавьте оснастку «Сертификат», выбрав «локальный компьютер». Это позволит вам импортировать файл PFX специально в хранилище LocalMachine «Мой». Затем щелкните сертификат правой кнопкой мыши и выполните не выберите «Свойства»; вместо этого выберите «Все задачи», затем «Управление закрытым ключом». Это приведет вас к графическому интерфейсу для изменения прав доступа к закрытому ключу. Примечание: права доступа «чтение» достаточно для использования закрытого ключа для криптографических операций; другие права касаются удаления или перезаписи ключа.

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