2016-09-15 9:04 GMT+03:00 Victor Wagner <vi...@wagner.pp.ru>:

> On Thu, 15 Sep 2016 08:27:40 +0300
> Bogdan <bog...@gmail.com> wrote:
>
> > Добрый день!
> >
> > Спасибо за ответы, судя по всему готового решения нет (что крайне
> > странно). Писать самостоятельно продукт такого рода - опасно и дорого.
>
> Не то чтобы опасно и дорого. При предполагамемом (да и более высоком)
> уровне безопасности это пишется за полдя. Скорее как раз именно потому
> что трудно придумать решение, отвязанное от регламентов конкретной
> организации, тиражируемых продуктов и нет. Проще сделать свой,
> заточенный под свою схему безопасности, чем адаптировать процессы
> управления персоналом к готовому.
>
> > FreeIPA смотрю, но так и не понял пока, где там могла бы быть подобная
> > функциональность.
>
>
> Готового решения нет потому, что заявленный регламент работы
> противоречит базовым представлениям о безопасности тех, кто работает с
> криптографией.
>

Если я правильно интерпретировал документацию. то готовое решение - это
Auto Enrollment в Microsoft Active Directory Certification Services -
https://technet.microsoft.com/en-us/library/cc771107(v=ws.11).aspx т.е., но
к сожалению работает только с AD :/


>
> И в тех случаях, когда такой уровень безопасности считается достаточным,
> предпочитают обходиться вообще без сертификатов и PKI.
>
> А когда PKI все же нужна, предпочитают решения, в которых есть некий
> ответственный сотрудник, который знает пассфразу от ключа УЦ и
> проверяет что тот, кто пришел за сертификатом, именно он и есть.
> (в этом случае в маленькой фирме хватит чего-то типа tinyca, gnomint,
> pyca или даже easyrsa (входит в комплект openvpn).
>
> Ведь если у нас единственный proof of authencity который
> предоставляется при получении сертификата - это пароль хранящийся LDAP,
> то зачем нужна аутентификация по сертификату, когда проще везде
> аутентифицироваться оп  тому же самому паролю?
>


Доступные мне протоколы авторизации позволяют передавать только плейнтекст,
либо заведомо уязвимые хэши паролей (md5 или ntlm) поверх TLS-сессии.
Защищенность такой сессии зависит исключительно от корректности настройки
(принудительная проверка "моего" CA) на стороне клиента, который будет
выполнять настройки подключения сам. Honeypot и/или MitM  технически просты
и достаточно вероятны в силу передачи данных по незащищенной и
неконтролируемой среде. Я хочу полностью отказаться от такого типа
авторизации в сервисе и перейти на авторизацию с использованием PKI.
Вероятность успешного MitM/honeypot для веб-сайта раздающего сертификаты
существенно меньше, чем для целевого сервиса.



> Другие модели безопасности сравнимого уровня которые широко
> распространены, это пожалуй только domain-validadated only сертификаты
> для веб-серверов. Где проверяется что подавший заявку сертификат может
> по крайней мере выложить файлик на web-сервер с именем, на которое
> выписывается сертификат.
>
> По-моему в случае описанной задачи было бы логично генерировать для
> пользователя сертификат и ключевую пару в момент заведения его в LDAP и
> выдавать ему в виде PKCS12-файла и использовать автоматизированный
> rollover. Т.е. чтобы заявку на новый сертификат пользователь подписывал
> на старом.
>
> --
>
>
>


-- 
WBR,  Bogdan B. Rudas

Ответить