Re: Тестирование DNS в lxc контейнере.
On Tue, Sep 06, 2016 at 10:45:32AM +0300, Eugene Berdnikov wrote: > > Но независимо от того чем эта конфигурация привлекательна, она штатная > > и kvm работает из коробки, также как и другие программы. В отличии > > от VirtualBox. > > В каком смысле, 64-битный VirtualBox не запускается в 32-битной > системе под 64-битным ядром, у которого все виртуалбоксовые > 64-битные модули подгружены? Да
PKI self-service
Добрый день! Ищу решение для самообслуживания: нужно дать возможность авторизованным пользователям выпускать клиентские сертификаты и автоматически подписывать их специальным отдельным CA-ключем. Авторизация пользователей - во LDAP. Очень желательно иметь автоматическое управление CRL/OCSP (пользователь пропал из LDAP - все его сертификаты автоматически отзываются) Как такой тип ПО вообще правильно называется, задача очевидная и должна иметь ряд решений, но не могу задать правильный вопрос гуглу. Спасибо. -- WBR, Bogdan B. Rudas
Re: PKI self-service
On Wed, 14 Sep 2016 11:55:21 +0300 Bogdan wrote: > Добрый день! > > Ищу решение для самообслуживания: нужно дать возможность > авторизованным пользователям выпускать клиентские сертификаты и > автоматически подписывать их специальным отдельным CA-ключем. > > Авторизация пользователей - во LDAP. Очень желательно иметь > автоматическое управление CRL/OCSP (пользователь пропал из LDAP - все > его сертификаты автоматически отзываются) > > Как такой тип ПО вообще правильно называется, задача очевидная и > должна иметь ряд решений, но не могу задать правильный вопрос гуглу. > > Спасибо. > Такой тип ПО называется "Удостоверяющий центр" или "Certification authority". Вот только готовых тиражируемых решений для вот такого (экстремально низкого) уровня безопасности, когда авторизованный пользователь может сам себе без дополнительных проверок выписать клиентский сертификат, я не знаю. EasyRSA она все таки про случай, когда все сертификаты под контролем одного системного администратора. Так то в принципе оно за полдня пишется на базе утилиты openssl. Только еще какой poll для ldap придется написать, чтобы отслеживать изменения в ldap. И понадобится явно интерфейс для отзыва сертификата авторизованным пользователем без удаления этого пользователя из ldap. --
Re: PKI self-service
On Wed, Sep 14, 2016 at 11:55:21AM +0300, Bogdan wrote: > Ищу решение для самообслуживания: нужно дать возможность авторизованным > пользователям выпускать клиентские сертификаты и автоматически подписывать > их специальным отдельным CA-ключем. "Автоматически подписывать их специальным отдельным CA-ключем" означает, что это ключ должен быть нешифрован и находиться в сетевом доступе. > Авторизация пользователей - во LDAP. Очень желательно иметь автоматическое > управление CRL/OCSP (пользователь пропал из LDAP - все его сертификаты > автоматически отзываются) И для этой задачи нужно держать нешифрованный ключ CA в сетевом доступе. > Как такой тип ПО вообще правильно называется, задача очевидная и должна > иметь ряд решений, но не могу задать правильный вопрос гуглу. Правильный ответ: openssl и руки. В модуле "ca" есть вполне рабочий набор функционала для массовой (поточной) обработки, который можно вставить в полностью автоматизированную среду. Проверено, работает. -- Eugene Berdnikov
Re: PKI self-service
On Wed, 14 Sep 2016 12:57:55 +0300 Eugene Berdnikov 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 разобрать "как совсем не надо", и "как относительно приемлемо".
Re: PKI self-service
В сообщении от [Ср 2016-09-14 11:55 +0300] Bogdan пишет: > Ищу решение для самообслуживания: нужно дать возможность авторизованным > пользователям выпускать клиентские сертификаты и автоматически подписывать их > специальным отдельным CA-ключем. > > Авторизация пользователей - во LDAP. Очень желательно иметь автоматическое > управление CRL/OCSP (пользователь пропал из LDAP - все его сертификаты > автоматически отзываются) > > Как такой тип ПО вообще правильно называется, задача очевидная и должна иметь > ряд решений, но не могу задать правильный вопрос гуглу. Если вы спрашиваете про инструменты, то значит вы ещё не создали свой центр сертификации, тогда у гугла можно спросить: «Как создать собственный центр сертификации?» В самом простом случае это выглядит как-то так [1], ну а дальше смотреть как можно выдавать доверенности на выпуск сертификатов, работать с отозванными и какие инструменты использовать. [1]: http://help.ubuntu.ru/wiki/руководство_по_ubuntu_server/безопасность/certificates -- Коротаев Руслан https://blog.kr.pp.ru
Re: PKI self-service
On 14/09/16 04:55 AM, Bogdan wrote: > Добрый день! > > Ищу решение для самообслуживания: нужно дать возможность > авторизованным пользователям выпускать клиентские сертификаты и > автоматически подписывать их специальным отдельным CA-ключем. > > Авторизация пользователей - во LDAP. Очень желательно иметь > автоматическое управление CRL/OCSP (пользователь пропал из LDAP - все > его сертификаты автоматически отзываются) Как вариант можно посмотреть на FreeIPA, но под Дебьян он ущербный и не самой последней версии.
Re: PKI self-service
Добрый день! Спасибо за ответы, судя по всему готового решения нет (что крайне странно). Писать самостоятельно продукт такого рода - опасно и дорого. FreeIPA смотрю, но так и не понял пока, где там могла бы быть подобная функциональность. 2016-09-14 19:15 GMT+03:00 Tim Sattarov : > On 14/09/16 04:55 AM, Bogdan wrote: > > Добрый день! > > > > Ищу решение для самообслуживания: нужно дать возможность > > авторизованным пользователям выпускать клиентские сертификаты и > > автоматически подписывать их специальным отдельным CA-ключем. > > > > Авторизация пользователей - во LDAP. Очень желательно иметь > > автоматическое управление CRL/OCSP (пользователь пропал из LDAP - все > > его сертификаты автоматически отзываются) > Как вариант можно посмотреть на FreeIPA, но под Дебьян он ущербный и не > самой последней версии. > > -- WBR, Bogdan B. Rudas
Re: PKI self-service
On Thu, 15 Sep 2016 08:27:40 +0300 Bogdan wrote: > Добрый день! > > Спасибо за ответы, судя по всему готового решения нет (что крайне > странно). Писать самостоятельно продукт такого рода - опасно и дорого. Не то чтобы опасно и дорого. При предполагамемом (да и более высоком) уровне безопасности это пишется за полдя. Скорее как раз именно потому что трудно придумать решение, отвязанное от регламентов конкретной организации, тиражируемых продуктов и нет. Проще сделать свой, заточенный под свою схему безопасности, чем адаптировать процессы управления персоналом к готовому. > FreeIPA смотрю, но так и не понял пока, где там могла бы быть подобная > функциональность. Готового решения нет потому, что заявленный регламент работы противоречит базовым представлениям о безопасности тех, кто работает с криптографией. И в тех случаях, когда такой уровень безопасности считается достаточным, предпочитают обходиться вообще без сертификатов и PKI. А когда PKI все же нужна, предпочитают решения, в которых есть некий ответственный сотрудник, который знает пассфразу от ключа УЦ и проверяет что тот, кто пришел за сертификатом, именно он и есть. (в этом случае в маленькой фирме хватит чего-то типа tinyca, gnomint, pyca или даже easyrsa (входит в комплект openvpn). Ведь если у нас единственный proof of authencity который предоставляется при получении сертификата - это пароль хранящийся LDAP, то зачем нужна аутентификация по сертификату, когда проще везде аутентифицироваться оп тому же самому паролю? Другие модели безопасности сравнимого уровня которые широко распространены, это пожалуй только domain-validadated only сертификаты для веб-серверов. Где проверяется что подавший заявку сертификат может по крайней мере выложить файлик на web-сервер с именем, на которое выписывается сертификат. По-моему в случае описанной задачи было бы логично генерировать для пользователя сертификат и ключевую пару в момент заведения его в LDAP и выдавать ему в виде PKCS12-файла и использовать автоматизированный rollover. Т.е. чтобы заявку на новый сертификат пользователь подписывал на старом. --
