[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Crypto Pro\Settings\Users\{sid}\Keys\{container_name}]

К слову, провел достаточно интересное исследование как можно "прокинуть" контейнер с общей папки по сети. Напомню, что КриптоПро CSP игнорирует любые сетевые диски (по возвращаемому системой типу диска) - их и задержка больше и относительно менее безопасно использовать (но ключ же зашифрован в контейнере и пин-код установлен?), поэтому просто "подключить сетевой диск" и увидеть контейнер на конечной машине не выйдет. В ходе экспериментов выяснилось, что подключение тома в папку, юнкции и символические ссылки прозрачны для считывателя съемных дисков. Еще попробовал SUBST и подключение сетевого диска в различных сочетаниях. Сетевой диск игнорируется в любых комбинациях, в сочетании с SUBST вообще дает "отключенное сетевое устройство" (хотя все открывается в проводнике), что тоже игнорируется. Сам по себе SUBST не меняет типа диска, но все же скорее не рекомендую его использовать даже для локальных папок, так как диск, созданный SUBST, наследует VOLUMEID от диска, на котором исходная папка, и выходит 2 буквы диска с одним ID.

Тем не менее, способ нашелся, буквально впритирку: если создать символическую ссылку на сетевую папку и саму эту папку (символическая ссылка на папку это папка) подключать как SUBST, то результат будет "отключенное сетевое устройство". Однако, если применить SUBST к папке на уровень выше (локальная папка внутри которой расположена символическая ссылка на сетевую папку), то тип будет "локальный диск". Понятно, что SUBST здесь лишний (но очень хорошо иллюстрирует, что "лазейка" предельно узкая) и можно аналогично поместить в корень несистемного раздела символическую ссылку на сетевую папку с контейнером. Минус (или плюс? смотря как посмотреть) в том, нельзя прилинковать несколько контейнеров одной ссылкой на вышестоящую папку, надо линковать каждый контейнер отдельно.

В рамках тестирования сделал так: создал общую папку с разрешением полного доступа "пользователям" и включенным перечислением на основе прав доступа (access-based enumeration), при этом на уровне файловой системы пользователям только чтение этой папки, полный доступ системе и администраторам. "Администраторам" пока что распространяется на все вложенные папки, но вероятно уберу позднее, оставив одну "узко направленную" учетную запись администратора ИБ - для назначения прав на контейнеры. Далее показано, что и системе доступ не обязателен!

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

Выглядит достаточно привлекательно - пользователи, у которых нет доступа на уровне файловой системы к папке-контейнеру просто не увидят ее в общей папке (фишка access-based enumeration). Попытки указать адрес ручками тоже обламываются - не найдена папка. Далее - если пользователь не залогинен на сервере с общей папкой, то символическая ссылка дает ошибку доступа и контейнер не виден в криптопровайдере. Выходит, что если на компьютер зайдет другой пользователь, то он не сможет получить доступ к контейнеру: 1) ему надо залогиниться на сервер (да, даже если логинитесь на удаленный компьютер программой psexec с именем доменного администратора, надо потом залогиниться с удаленного компьютера на сервер, чтобы увидеть содержимое по ссылке); 2) надо иметь доступ к папке на общем ресурсе.

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

Вообще, как вариант, можно в хранилище не добавлять, а каждый раз проводить предыдущие шаги - создание контекста сертификата и проставление ссылки на контейнер в контекст сертификата, получение по ссылке контекста криптопровайдера HCRYPTPROV. Однако это если сама же программа и подписывает низкоуровневыми функциями, не полагаясь на хранилище сертификатов. Большинство программ (и высокоуровневые функции подписания!) ищут сертификат в хранилище.