Re: PKI self-service
On Wed, 14 Sep 2016 12:57:55 +0300
Eugene Berdnikov <bd4@protva.ru> wrote:
> On Wed, Sep 14, 2016 at 11:55:21AM +0300, Bogdan wrote:
> > Ищу решение для самообслуживания: нужно дать возможность
> > авторизованным пользователям выпускать клиентские сертификаты и
> > автоматически подписывать их специальным отдельным CA-ключем.
>
> "Автоматически подписывать их специальным отдельным CA-ключем"
> означает, что это ключ должен быть нешифрован и находиться в сетевом
> доступе.
Что он должен находиться в сетевом доступе - не значит.
Он может находиться на отдельном компьютере, изолированном от сети.
Главное, чтобы существовала автоматическая процедура, позволяющая
забрать по какому-то каналу (не обязательно являющемуся полноценной
сетью, предоставляющей полноценный удаленный доступ), заявки и вернуть
подписанные сертификаты, выполнив в процессе произвольное количество
проверок.
Мы, например как-то разрабатывали конструкцию, когда собственно УЦ
коннектился к регистрирующему центру (имеющему сетевой доступ) через
последовательный порт и изображал из себя юзера последовательного
терминала, получая заявки с помощью команды cat и в нее же передавая
подписанные сертификаты.
Кроме того, ключ CA может хранится в аппаратном токене. Это несколько
меньший уровень защищенности, так как человек, получивший рутовый
доступ к компьютеру, куда воткнут токен, может подписать на нем что
угодно, но существенно более высокий чем хранение ключа в файле,
который злоумышленник может скопировать.
>
> > Авторизация пользователей - во LDAP. Очень желательно иметь
> > автоматическое управление CRL/OCSP (пользователь пропал из LDAP -
> > все его сертификаты автоматически отзываются)
>
> И для этой задачи нужно держать нешифрованный ключ CA в сетевом
> доступе.
Тут тем более все не так. Ключ OCSP-респондера и ключ CA это в общем
случае разные ключи. И протокол OCSP сдизайнен таким образом именно
потому, что ключ OCSP-респондера должен использоваться для выработки
подписей на компьютере, подключенном к сети.
Ну и вообще для специализированного СA, клиентские сертификаты которого
дают доступ только к ограниченному набору сервисов, например vpn,
наличие ключа на компьютере с сетевым доступом не обязательно является
неприемлемым секьюрити-риском.
Кстати, рекомендую внимательно прочитать раздел PATH PHRASE ARGUMENTS в
openssl(1). То, что там написано может помочь избежать хранения
незашифрованного ключа и пассфразы к зашифрованному ключа на диске
компьютера, подключенного к сети, аналогично тому как ключи для ssh
или gpg хранятся в памяти специальной программы-агента.
> Правильный ответ: openssl и руки. В модуле "ca" есть вполне рабочий
> набор функционала для массовой (поточной) обработки, который можно
> вставить в полностью автоматизированную среду. Проверено, работает.
На самом деле это не совсем правильный ответ. Потому что написание
удостоверяющих центров, тем более таких, от которых требуется высокая
usability, которая, как известно, прямо противоречит security, задача,
имеющая уйму тонкостей. Поэтому посмотреть на известные реализации было
бы крайне полезно. Но, к сожалению посоветовать реализацию, у которой
стоит поучиться "как надо" я не могу. Можно на примере разных
реализаций клиента Let's Encrypt разобрать "как совсем не надо", и "как
относительно приемлемо".
Reply to: