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
