Главная Security, Windows, Новое Проектирования Инфраструктуры Открытых Ключей. Часть 1
  • Проектирования Инфраструктуры Открытых Ключей. Часть 1

    keyБезопасность сети формируется из комплекса элементов, один из важнейших – инфраструктура открытых ключей. Теоретические основы проектирования PKI [1] рассматривается в этой статье. Полагаю, что всем хорошо известно: внедрение инфраструктуры открытых ключей все чаще   становится насущной необходимостью огромного числа компаний.

     

     

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

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

    Инфраструктура открытых ключей (PKI) — инфраструктура, предназначенная для управления открытыми ключами и сертификатами с целью поддержки услуг аутентификации, шифрования, целостности и неотрицания авторства. Открытый ключ, связанный с определенным пользователем, должен быть удостоверен сертификатом, подлинность которого должна проверяться доверенным учреждением — Центром Сертификации (Certification Authority).

    Другой термин, принятый для именования такого объекта — Удостоверяющий Центр (УЦ). По сути, такое именование более корректно, однако менее распространено в технической литературе.

    Сертификат открытого ключа — структура данных, состоящая из раздела данных и раздела подписи. В первом содержатся открытые данные, включающие, как минимум, открытый ключ и строку, идентифицирующую сторону (представляемый объект). Во втором — цифровая подпись органа сертификации. На практике наиболее часто используются сертификаты формата Х.509.

    Термин «инфраструктура открытых ключей» встречается довольно часто как в технической литературе, так и в документации по продуктам. Можно сказать, что инфраструктура открытых ключей представляет собой совокупность цифровых сертификатов, центров регистрации и удостоверяющих центров, цель которых проверка подлинности участников обмена зашифрованными сообщениями.

    Собственно говоря, инфраструктура открытых ключей  определяет механизмы подтверждения того, что участник безопасности, например, пользователь, взаимодействующий с другими, является именно тем, за кого он себя выдает. Реализации PKI могут быть как простыми, так и сложными. Таким образом, каждая организация, планирующая развертывание указанных служб, должна разобраться в существующих сценариях внедрения и принять решения, какой вариант использовать для решения собственных задач. Windows 2008 также как и предыдущие версии операционных систем, имеет в своем составе Удостоверяющий Центр. Эта служба отвечает за создание сертификатов, проверку их подлинности и последующее управление.

    Удостоверяющий Центр (УЦ). Центр сертификации (CA) — доверенная третья сторона, чья подпись под сертификатом подтверждает подлинность открытого ключа, связанного с представляемым объектом. Простейшую модель PKI можно построить из одного компонента, называемого издателем (Issuer), который выполнял бы все необходимые функции. Пользователи использовали бы криптографию с открытым ключом в своих приложениях через получение и обработку сертификатов и списков отзыва сертификатов (CRL) [2]. Сложно обеспечить в рамках одного сервера необходимый уровень защищенности при выполнении всех задач, связанных с созданием и распространением сертификатов и CRL. Поэтому обычно PKI представляет собой более сложную структуру, каждый из элементов, которой предназначен для выполнения специализированных функций.

    Функции Удостоверяющего Центра

    Список функций Удостоверяющего Центра может показаться не слишком значительным, однако важность их весьма существенна.

    1.    Подтверждение аутентичности объекта,  запрашивающего сертификат. Механизмы проверки зависят от типа CA
    2.    Выдача сертификатов. Информация в сертификате определяется его шаблоном.
    3.    Управление отзывом сертификатов. Список отзыва сертификатов (CRL) гарантирует невозможность использования «неправильных» сертификатов.

    Принятие решения о структуре Удостоверяющих Центров (выбор иерархии) – задача, которая требует вдумчивого отношения, так как неправильный выбор может привести к серьезным проблемам в области безопасности. Отдавая предпочтение тому или иному варианту архитектуры, учитывают следующие факторы: потребности приложений, необходимый уровень безопасности, бизнес-требования компании.

    В результате проектирования инфраструктуры PKI необходимо определить:

    •    Кол-во уровней иерархии и структуру УЦ;
    •    Типы используемых цифровых сертификатов;
    •    Виды УЦ, работающих на каждом из уровней иерархии;
    •    Необходимость интеграции со службой каталога;
    •    Методы защиты УЦ;
    •    Потребности в различных политиках сертификатов.

    Итак, сколько же уровней иерархии использовать? Какое кол-во УЦ расположить на каждом из уровней иерархии?

    Модели иерархий УЦ и критерии выбора

    Одноуровневая модель

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

    Двухуровневая модель

    Иерархия, состоящая из двух уровней представляет собой отключенный корневой сервер и один или несколько издающих сертификаты серверов. См. рис. 1.

    clip_image002[4]

    Рис. 1. Двухуровневая иерархия PKI

    При этом на издающие УЦ ложится функционал по управлению политиками сертификатов. Для обеспечения безопасности инфраструктуры корневой центр является отдельностоящим (stand-alone) и автономным (offline), то есть не входит в состав домена не подключается к сети предприятия, и, практически, постоянно находится в отключенном состоянии. Тем самым, мы избегаем атак на корневой сервер.  Что касается издающих центров, то они получают сертификат, подписанный корневым сервером, которому доверяют все участники взаимодействия, то есть обладатели сертификатов, полученных с любого УЦ предприятия.
    Для повышения уровня доступности и отказоустойчивости сервиса предусматривается развертывания более чем одного издающего сервера. Что касается количества издающих центров, то оно определяется бизнес-требованиями компании. Необходимо также предусмотреть отказоустойчивость списков отозванных сертификатов. Чуть позже мы рассмотрим механизмы решения проблемы отказоустойчивости.

    Трехуровневая модель

    Трехуровневая архитектура обеспечивает наилучшие характеристики безопасности, масштабируемости инфраструктуры. В этом варианте осуществляется развертывание корневого центра на отдельностоящем сервере, не входящем в состав корпоративной сети.
    Дополнительно выполняется внедрение серверов политик (Policy CA), являющихся подчиненными к корневому УЦ. Эти серверы, также, не входят в состав корпоративной сети, и являются отдельностоящими. И корневой, и подчиненные ему Policy CA, являются отключенными (Offline). Издающие сертификаты серверы являются подчиненными к Policy CA и могут быть как корпоративными (Enterprise), так и отдельностоящими (Standalone). См. рис. 2.

    clip_image002[6]

    Рис. 2. Трехуровневая иерархия PKI

    Рекомендуется использовать трехуровневую архитектуру в следующих ситуациях:

    •    Компания предъявляет высокие требования к безопасности. За счет использования отключенных УЦ, удается избежать сетевых атак.
    •    Существует потребность в различных политиках сертификатов. Например, в зависимости от принадлежности к тому или иному филиалу предъявляются различные требования к используемым сертификатам.
    •    Есть необходимость в раздельном управлении, например поддержка УЦ и управление сертификатами для представительств компании в Москве и Петербурге должна осуществляться разными командами.

    Четырехуровневая модель

    В ряде случаев может потребоваться более сложная модель, состоящая из 4-х уровней иерархии. Пример такой модели показан на рис. 3, однако, следует иметь ввиду, что такой вариант архитектуры более сложен в реализации. И, как правило, трех уровней иерархии будет достаточно. Реализация моделей, состоящих из более, чем 4-х уровней, не рекомендуется Microsoft ввиду ее избыточной сложности и неочевидной полезности.

    clip_image002[8]

    Рис. 3. Четырехуровневая иерархия PKI

    Особенности выбора архитектуры издающих центров

    Выбор структуры издающих УЦ определяется исходя из следующих факторов:

    Количество издаваемых сертификатов.

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

    Требования доступности для пользователей.

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

    Модель администрирования инфраструктуры открытых ключей.

    В ряде компаний для администрирования разных приложений, связанных с PKI, используются разные команды специалистов.  Например, за безопасный почтовый обмен в организации отвечает одна группа, а за VPN доступ другая. Это может потребовать использования разных серверов для обеспечения разделения ролей.

    Структура компании.

    Довольно часто, компания, в которой требуется внедрить инфраструктуру PKI, представляет собой холдинг, объединяющий несколько автономных предприятий. Которые при этом могут иметь потребность во взаимодействии и общие цели. Например, речь может идти об издательском холдинге, объединяющем, собственно, издательство и компанию с сетью книжных магазинов в разных городах. В данном случае мы можем рассматривать вариант использования двух Policy CA, соответственно определяющих политику сертификатов для каждой из компаний, входящих в состав холдинга, и нескольких выдающих сертификаты серверов, подчиненных соответствующим Policy CA. Критерии для выбора подчиненных издающих УЦ могут быть различными, например, в основу может быть положен принцип ролевого или функционального разделения.

    Что влияет на выбор архитектуры PKI?

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

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

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

    Список литературы

    [1] Brian Komar Windows Server 2008 PKI and Certificate Security
    [2] http://www.microsoft.com/pki
    [3] http://technet.microsoft.com/en-us/magazine/2009.05.pki.aspx
    [4] http://www.windowsecurity.com/articles/Microsoft-PKI-Quick-Guide-Part1.html
    [5] http://www.windowsecurity.com/articles/Microsoft-PKI-Quick-Guide-Part2.html
    [6] http://www.verisign.com

    [1] PKI — Public Key Infrastructure (Инфраструктура Открытых Ключей)
    [2] CRL – Certificate Revocation List (Список отозванных сертификатов)

     

    Автор: Леонид Шапиро,
    MCT, MCSE:S, MCSE:M, MCITP EA, TMS Certified Trainer.

    P.S Статья опубликована в журнале Системный Администратор

Комментарии

  1. >1. Подтверждение аутентичности объекта, запрашивающего сертификат. Механизмы >проверки зависят от типа CA

    >2. Выдача сертификатов. Информация в сертификате определяется его шаблоном.

    >3. Управление отзывом сертификатов. Список отзыва сертификатов (CRL) гарантирует >невозможность использования «неправильных» сертификатов.

    «Подтверждение аутентичности» — это вообще в природе бывает? Аутентичность потому так и называется, что подтверждается самим объектом.

    Затем «подтверждение аутентичнности» (в представлении автора — аб.) это не функция, а свойство. Этим свойством, точнее механизмом, обеспечивающим аутентификацию, обладают все многопользовательские системы в том числе.

    Итак в сухом остатке только функция выдачи и функция отзыва.

    Рассмотрим что такое CRL. Это в сущности статический документ, подписанный корневым сертификатом. Публично он указывается как CRL Distribution point. В чем великая сложность обеспечения доступности статического веб-контента? Замечу, что CRL вообще рекомендуется хранить на внешник максимально публичных ресурсах так, что к CA они фукционально не должны иметь никакого отношения.

    Почему-то мне кажется, что вот эти n-уровневые модели сильно «высосаны из пальца» 😉

  2. Спасибо за Ваше замечание. Видимо, я неточно выразился, поэтому возникла несогласованность. Попробую пояснить. Дело в том, что УЦ удостовериться в «законности» запроса, который ему отправляют. Т. е. понять, что обращение к нему легально и, если это так, то выдать сертификат. Эта проверка может быть выполнена, либо посредством проверки наличия соответствующего разрешения у запрашивающего (для проверки используется УЗ и разрешения на нее (Enterprise CA)), либо администратор безопасности должен будет принять решение о выдачи, или невыдачи сертификата на основе, скажем так собственных представлений, т. е. поговорил с пользователем, спросил у начальства, проверил регламенты компании (Stand-Alone CA).

    CRL регулярно обновляется, например, Вы отозвали сертификат пользователя на смарт карту, и задача обеспечить отсутствие возможности входа. Справедливости ради, надо отметить, что с этим примером есть один «тонкий момент», но необходимости публикации CRL это не отменяет. Другая ситуация — компрометация какого-то дочернего УЦ, опять же надо срочно отзывать его сертификат и публиковать CRL. Так что CRL не совсем «статический» контент.

    Причинами отзыва сертификатов являются: компрометация ключа, компрометация УЦ, разрыв связи обладателя сертификата с организацией, замена сертификата, и т. д.

    Далее, то что имеет смысл использовать в качестве точек хранения сертификатов и списков отзыва сервер, отличный от самого УЦ, никто не отрицает.

    Не могу с этим согласиться, многоуровневые модели несомненно полезны. Например, у Вас распредленная большая организация, и Вы используете единственный УЦ. Его скомпрометировали... Вся Ваша структура рухнула.

  3. Леонид, хорошая, добротная статья у Вас получилась.

    alekseybb: «Итак в сухом остатке только функция выдачи и функция отзыва. Рассмотрим что такое CRL. Это в сущности статический документ, подписанный корневым сертификатом».

    Что такое «корневой сертификат»? Формально, «корневой сертификат» — это самоподписанный сертификат. Сертификаты и списки отзыва, соответственно, выпускают не только корневые УЦ.

    Стандарт X.509 определяет форрмирование списка отзыва и его подписание как функцию УЦ. В функции УЦ кроме «сертификации» (certification) и прочих функций также может входить функция архивирования ключевой пары.

    alekseybb: «Замечу, что CRL вообще рекомендуется хранить на внешник максимально публичных ресурсах»

    Не хранить, а публиковать.

  4. >Например, у Вас распредленная большая организация, и Вы используете >единственный УЦ. Его скомпрометировали... Вся Ваша структура рухнула.

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

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

    Нет, Леонид. Не для этого делают иерархическую структуру. Это делается с единственной целью сделать PKI максимально доступным для пользователей. Глобальная параноидация, приводящая к избыточному взаимодействию с УЦ может блокировать всю работу в сети, при недоступности сервиса УЦ.

    А теперь зададимся вопросом, на сколько такое взаимодействие может быть интенсивным.

    Как проверяется достоверность сертификата. Сам сертификат проверяется по пути его подписания. Если мы говорим о корпоративной сети, то путь подписания статичен. Для этого не надо постоянно запрашивать УЦ. Все сертификаты кэшируются в клиентских программах. Как проверяется список отзыва — он просто считывается. Это статический контент, и его также можно кешировать как любой вэбконтент. И никакой многослойной структуры для этого не надо. Нужен обычный балансировщик протокола хттп. Например, ngnix.

    Теперь реальный пример. Все давно пользуются системой отправки налоговых документов через Интернет. Там реализована система аутентификации сторон на основе PKI на х509. Клиентов очень много, географический охват очень большой, сделано все примитивно просто и нет никаких проблем.

    Создается впечатление, что проблемы лишь при реализации УЦ на платформе виндовс 😉

  5. IMHO alekseybb, у вас налицо недопонимание предмета.

  6. Нет, господа.

    У меня полное понимание предмета. Я в отличие от вас могу CA слепить пошагово. И я ТОЧНО представляю, что есть что на каждом этапе создания всей цепочки сертификатов.

    А вот «вы» понимаете PKI не глубже меню средств виндовс. И в этом все ваши проблемы. Для вас PKI это когда виндовс-программы работают с виндовс-PKI. А все остальное это «недопонимание предмета» 😉

    В таком ключе, да, я «недопонимаю» зачем мне PKI на винде. Объясните пожалуйста мне мои «проблемы». Возможно мое настоящее мнение в чем-то ошибочное и оно изменится. Никаких пальцерасстановок. Я, как вы заметили, стараюсь и отвечать и спрашивать максимально корректно, никого не задевая...

    Только не забывайте, прежде всех ваших виндовых PKI ВСЕ PKI делались исключительно НЕ на винде. Точно также как не надо забывать, что до всех ваших «лесов с деревьями» DNS выполнялся исключительно НЕ средствами винды. Так что все ДОПОЛНИТЕЛЬНЫЕ вытребенки, возникшие в этих простых предметах после копания в них Билла Гейтса, не более чем пятая нога собаки!

    Вот и подскажите мне, зачем эта самая «пятая нога»? Может я чего не понимаю в происхождении видов 😉

  7. >Никаких пальцерасстановок.

    Боюсь тогда представить как выглядят ваши распальцовки особенно в свете фраз аля «Я в отличие от вас могу CA слепить пошагово»

    З.Ы Вы чего здесь забыли? Зашли потеребить свое я, чтобы слегка его увеличить?

  8. Коллегии не надо ругаться, и платформенных войн. Есть тема поднятая по PKI с реализацией на винде, есть PKI как таковой не зависящий от платформы винды, никсов и т.д. В голом виде это технология (). Автор говорит по реализацию этой технологии на конкретной платформе, так это или нет на конпретной платформе давйте и осбуждать, а не саму технологию без реализации.

    Если коллега alekseybb может за пару шагов слепить CA, пожалуйста подготовь статью со своим виденьем этого процесса, и мы ее прочитаем и обусдим.

    Тема по PKI очень даже как интересная.

  9. >>>>Нет, Леонид. Не для этого делают иерархическую структуру. Это делается с единственной целью сделать PKI максимально доступным для пользователей.

    У меня для гуру один единственный вопрос — как выбор иерархии влияет на доступность СА. (В отрыве от платформы CA) ???

  10. > Только не забывайте, прежде всех ваших виндовых PKI ВСЕ PKI делались исключительно НЕ на винде

    Жаль, что работающие на Вербе или на каком-нибудь лоховском RSA Keon про это не знают. Всякие там Курьеры, Корветы, etc.

    Вы вообще, Алексей, масштабнее, категоричнее, ортодоксальнее. Это интересно ж.

  11. А что обидело то? Правда? Ну, расслабьтесь! 😉

    Не хотите о том, как там CA внутри, поскольку не знаете этого, давайте о том, как там PKI снаружи.

    Вот, например, получает некая программа (сторона) незнакомый сертификат в подтверждение аутентичности подключения. В сертификате есть два поля. Одно AIA указывает на размещение CA, имеет формат URI, и дает возможность с использованием корневого сертификата определить достоверность подписи. Второе поле, CDP, которое тоже URI, и оно позволяет узнать, нет ли индекса сертификата в списке отозванных.

    Оба этих поля, AIA и CDP, указывают на статичный контент! Вот это и все что нужно от PKI для взаимодействующих систем. Для этого нужна какая-то многоуровневость? Нет, очевидно.

    Ну, да, а какже процесс выдачи сертификатов. В самом начале статьи сказано, что все знания применимы в бизнесе, на предприятии. На предприятии (в бизнесе) персональные сертификаты (там не SOA все вытягивает и не xml-rpc, там же человека сам по меню-тебю тыкает) выдаются в процессе разрешения пользователям на взаимодействие с защищенными ресурсами. Какая интенсивность этого процесса. Раз в 5 минут? Раз в час? Раз в сутки? Сами ответьте, как часто увольняют, принимают персонал? Все время между приемом/увольнением персонала AIA и CDP это статический контент.

    Описанная в статье четырехуровневая структура легко может обслужить страну среднего размера — милионов так на 30 активного населения.

    Я без споров и сомнений признаю ценность всех перечисленных в подписи автора абревиатурок с буковкой «М» в том, что они позволяют вчухивать заказчикам подобные системы. Браво! Браво! 😉 Надо лишь в процессе беседы с заказчиком солидно так заявить, «а прикиньте что случиться, если ваш корневой PKI скомпроментируют!», — типа, вскроют у вас в кабинете сейф, — «надо поставить еще несколько PKI ниже уровнем!», — типа, завести еще несколько сейфов, чтобы взломщики имели много альтернативных путей взлома 😉

    А я то все по-старинке в каждую контору ставлю по CA, и сам скриптиком отзываю сертификаты, при увольнении персонала... Не, я все-таки жду, что мне расскажут, как надо все правильно и сразу на дюжине серверов, чтобы заказчика уесть IT-бюджетом 😉

    2Илья: Что я забыл тут? А чего так сразу грубо? Если нечего ответить, то это не предлог сразу грубить. «Не умеете вы общаться с людьми, Илья» © Иван.

  12. > А что обидело то?

    И почему все обиженные настолько одинаково себя ведут?

    > Оба этих поля, AIA и CDP, указывают на статичный контент!

    RFC 2560.

    Свежачок, за 1999й год.

    Предлагаю ознакомиться.

    > Ну, да, а какже процесс выдачи сертификатов

    [skipped]

    > Какая интенсивность этого процесса. Раз в 5 минут? Раз в час? Раз в сутки?

    Подскажу — ещё есть NAP. Там интенсивность может измеряться количеством запросов в секунду.

    > Я без споров и сомнений признаю ценность всех перечисленных в подписи автора абревиатурок с буковкой «М» в том, что они позволяют вчухивать заказчикам подобные системы.

    lurkmore.ru/%D0%91%D0%B0%...0%B5%D1%80%D1%82

    > Надо лишь в процессе беседы с заказчиком солидно так заявить, «а прикиньте что случиться, если ваш корневой PKI скомпроментируют!», — типа, вскроют у вас в кабинете сейф, — «надо поставить еще несколько PKI ниже уровнем!», — типа, завести еще несколько сейфов, чтобы взломщики имели много альтернативных путей взлома.

    Передёргиваете. Если продолжать Ваш пример, то распределив ценности по сейфам «альтернативных путей» больше не станет — наоборот, стойкость увеличится. Ценностей-то фиксированное количество.

    > А я то все по-старинке в каждую контору ставлю по CA, и сам скриптиком отзываю сертификаты

    1. Где Вы видите совет не ставить в разные конторы по отдельному CA?

    2. Зачем скриптиком отзывать сертификаты? Занятость имитировать? Отзывайте путём отправки ценных посылок или голубиной почты — ещё дольше будет. Главное, не забывать «этих больно умных городских» и «венду» помянуть правильным словом.

  13. Свободен. Тролей я здесь не кормлю, спец ты диванный как выяснилось. Разговор у меня с тобой закончен. Постить без мата можешь, оставлю для истории буду твоими комментами студентов веселить.

  14. alekseybb: "У меня полное понимание предмета. Я в отличие от вас могу CA слепить пошагово "

    Ключевое слово — «слепить». Капут.

    Алексей, покажите выпущенный по Вашему разумению сертификат — удивите профессионализмом. 😉

    P.S. Рус, каким образом такой классный специалист мог пройти мимо твоего биореактора... Или, таки, знакомый персонаж? 🙂

  15. Не, Дим, не знакомый. А биореактор сейчас в downtime — времени нет особо.

  16. А я все ждал этого. Подсказывал на счет параноидальности. Вот, Леонид, это Вам нужно было упомянуть NAP. Спасибо Руслан, а то меня уже всякие неучи пытались по поводу «доступности» разводить 😉

    И здесь возникает справедливый вопрос. А насколько NAP в принципе сопровождает внедрение PKI.

    2Илья:Да, я собственно беседовал с Леонидом. Никого из несдержанных и неграмотных не просил встревать. Сам пришел, сам ушел... Да и не жалко... 😉

    2Руслан: Нет устойчивость к взлому упадет, так как контент дублирован.

  17. > А насколько NAP в принципе сопровождает внедрение PKI

    Обычно наоборот — внедрение NAP влечёт использование PKI.

    > Нет устойчивость к взлому упадет, так как контент дублирован

    Алексей, расскажите, пожалуйста, что на разных ЦС в иерархии дублируется в части контента. Ключи? Выданные сертификаты? Списки отзыва?..

  18. А вот это «Зачем скриптиком отзывать сертификаты? Занятость имитировать?» меня искренне повеселило. Т.е. Вы в самом деле считаете, что мышей в меню тыкать эстетично, а просто запустить скрипт с параметром не кошерно? 😉 Ржунемогу однако. Когда в следующий раз буду запускать срипт с телефонного ssh клиента снова буду смеятся, вспоминая Ваше замечание.

    Вот, это самое «Обычно наоборот — внедрение NAP влечёт использование PKI.» и свидетельствует о том, что без упоминания данного обстоятельства структура, предложенная в статье избыточна во всех возможных случаях. Вам бы, Руслан, пойти к Леониду в научные редакторы. Во-на, как Вы быстро его на истинный путь вывели 😉

    Теперь об этом «Алексей, расскажите, пожалуйста, что на разных ЦС в иерархии дублируется в части контента.». Ну, просто же, Руслан 😉 Если взлом корневого CA опасен для всей системы, а взлом каждого промежуточного угрожает всем нижележащим, то в двухуровневой структуре из корневого и двух нижних поулчатся для атаки на сервисы предприятия есть всегда 2 хоста — можно ломать или корневой или нижний. На трехуровневой симметричной за защиту каждого сервиса отвечает уже три хоста и т.д. Т.е. все происходит в точности в обратном порядке, как уровни прятались.

    Э... чтобы Вы все поняли в точности, подскажу, под атакой понимается не только подмета стороны взаимодействия, но и DoS.

  19. > А вот это «Зачем скриптиком отзывать сертификаты? Занятость имитировать?» меня искренне повеселило. Т.е. Вы в самом деле считаете, что мышей в меню тыкать эстетично, а просто запустить скрипт с параметром не кошерно.

    Нет. Вы просто исходите из своих знаний, что бывает только два упомянутых варианта. Жизнь же сложнее, их больше. Отзыв скриптом — это самый медленный вариант. Религиозные предубеждения про мышь, кстати, никаких плюсов в знания Вам не дают. Вы пока что показываете крайне поверхностное знакомство с предметом.

    > Когда в следующий раз буду запускать срипт с телефонного ssh клиента снова буду смеятся, вспоминая Ваше замечание

    Берегите себя, срипт — это дело такое.

    Приходящий админ со сриптами с телефона — это, кстати, яркий образ. Если Вы думаете, что сие — Это Круто, сразу разочарую. Это наоборот. И обычно насовсем.

    По части вопроса про дублирование — Вы не поняли вопрос или сделали вид. Дублирование контента и описанное Вами — совсем про разное. И по Вашей логике вообще рост количества узлов должен однозначно вести к падению уровня безопасности системы, а это не так.

    Вы правда предполагаете, что атаки класса DoS на ЦС:

    1. Являются угрозой, с которой должен бороться сам ЦС.

    2. Увеличивают свою вредоносность от увеличения кол-ва узлов.

    ?

  20. /me ушел сносить досом корневой CA верисайна. Знал бы Билл для чего спустя годы после создания DOS ее будут использовать, умер бы со смеха.

  21. alekseybb, пожалуйста, только не уходите! Ваши коментарии очень интересно читать.

    Спасибо.

  22. Анекдот что-то вспомнился вчерашний — про немца и негров.

  23. Ну раз вспомнил расказывай.

  24. Немец попал в NY и заблудился.

    Попал в Гарлем.

    На него напали пять негров и начали насиловать.

    Немец орёт — «Найн! Найн!».

    Негры переглянулись и позвали ещё 4.

  25. Алексей, как у Вас с немецким?

  26. Гы, ребята с вами весело. Давайте по-немецки, я вас по-русски, что по-китайски не понимаю.

    Подвожу итог.

    Я выссказал Руслану три утверждения.

    По первому: человек сделал умное лицо 😉 и сменил тему. Слив засчитан.

    По второму: сразу отвалил. Слив засчитан. Леонид, он Вас тут просто сдал 😉

    По третьему: понес какой-то бред. Слив снова засчитан 😉

    Руслан, рост количества узлов в сети УМЕНЬШАЕТ её безопасность. Это факт! Если в сети нет узлов вообще она абсолюто безопасна.

    Э... да вас, видать, вовсе ничему не учили. Да?

    Короче. Для меня еще в какой-то степени осмысленно обсуждение статьи, но беседу с неучами я готов продолжать только, если вы меня будете развлекать. Давайте так: пара глупых постов, пара мямличей + 1 анекдот. Т.е. я этот блог буду читать, когда счетчик ответов прибавит 5 😉

  27. >можно ломать или корневой или нижний.

    Йе, бейби, сломай мой отключенный от сети и выключенный из розетки Root CA.

    Жду.

  28. А ведь если пропустить мимо ушей (вернее, мимо глаз) обоюдные наезды, то в коментариях можно увидеть нормальную дисскуссию о реальных причинах внедрения двух более уровней CA 🙂

    Действительно, описанные Русланом Кармановым причины мне кажутся более верными.

    Так, в двухуровневой архитектуре, Леонид Шапито говорит о повышении уровня безопасности за счет выноса и отключения корневого CA. Два и более выпускающих CA нужны, если верить статье, только для доступности и отказоустойчивости. Но если мы используем один выпускающий CA и его скомпометировали, то отозвав его, мы «потеряем» все выпущенные сертификаты. Понятно, что автор неверно выразился, но кто-то прочтет и примет как факт.

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

  29. Кстати, по поводду сейфов, ключей и сокровищ.

    И та и другая позиция, на мой взгляд, верны 🙂

    Если злоумышленнику удалось заполучить пару ключей с одного из выпускающих СА он уже может выпускать сертификаты, которым (при соответсующих условиях) будет доверять любой, кто доверяет корневому СА. То, о чем говорил Алексей.

    Но, если факт взлома был обнаружен вовремя, то отзвав сертификат выпускающего CA мы «потеряем» только сертификаты, которые он выпускал. О чем, если не ошибаюсь, говорил Руслан Карманов.

  30. Доступность УЦ — это отдельная тема, она никак не связана с иерархией.

    Каждая из организаций вольна выбирать свою структуру PKI, но, в общем случае, наличие корневого УЦ и выпускающего — это, как минимум, возможность для массштабирования PKI.

    Как правило, внедрение Policy CA продиктовано «юридическими» требованиями и в большинстве сценариев развертывания PKI этой ролью пренебрегают, но вот содержание нескольких выпускающих УЦ часто необходимо, так как позволяет технически разграничить «полномочия» УЦ. Например, может существовать несколько выпускающих УЦ: сертификаты одного доверены для регистрации пользователей, позволяют использовать их для процедур подписи и шифрования документов, а второй УЦ, например, выпускает сертификаты лишь для поддержки SSL на веб-серверах, поддерживает SAN'ы и его обслуживают другие администраторы согласно другим политикам выдачи.

    Сценарий с несколькими выпускающими УЦ позволяет в случае компрометации УЦ «лишить доверия» лишь службы или пользователей одной «области», но не всей инфраструктуры.

    Алексанлр Донин: «Если злоумышленнику удалось заполучить пару ключей с одного из выпускающих СА он уже может выпускать сертификаты, которым (при соответсующих условиях) будет доверять любой, кто доверяет корневому СА.»

    Это не так. Во-первых, злоумышленнику достаточно получить лишь закрытый ключ УЦ. Даже, если это ключ корневого УЦ, то злоумышленник никак не сможет выпустить сертификат на смарт карту, если для этого был назначен лишь определенный выпускающий УЦ.

  31. Леонид, спасибо за статью. Есть вопрос по версиям CA, возможно ответ будет в следующих статьях.

    Если с Root CA более-менее понятно, ему достаточно быть поднятым на STD Edition (шаблоны сертификатов V1). То как быть с Policy CA? Неужели придется держать Enteprise Edition, чтобы иметь возможность выпускать кастомизированные шаблоны?

    Спасибо.

  32. Алексей, не нервничайте. Вы реально в материале на нулях.

    Ретроспектива по треду:

    1. Вы не понимаете термина «аутентичность». Т.е. совсем. Можете почитать, что это такое, начав, к примеру, с перевода. Подскажу — аутентичность — это от слова

    «подлинный». Её можно и сохранять, и проверять. Сам по себе объект, без взаимодействия с другими, аутентичность свою не проявит никак. 🙂

    2. Вы не знаете, как используется CRL. По крайней мере, Вы упорно утверждаете, что это — «статический документ, подписанный корневым сертификатом». Он и не

    статический (Вам несколько раз про OCSP говорили), и подписан он не корневым сертификатом, а сертификатом конкретного CA. Да и предположение, что «Публично CRL

    указывается как CRL Distribution Point» показывает, что с крупными инсталляциями Вы не работали. CRL != CDP. В случае OCSP, допустим, будет и CRL, и работающий OCSP,

    и CDP будет указывать на OCSP, а CRL будет вообще лежать в другом месте (возможно, снаружи CRL _вообще_ виден не будет, а работать всё будет).

    Вы подумайте, как работает проверка отзыва у крупных инсталляций. Например, когда 1 CA выдаёт в год пару миллионов сертификатов. Вы размер CRL'а (файла самого)

    посчитайте, и подумайте, как оно работать должно в плане скорости. На правах подсказки.

    3. О том, что «CRL рекомендуется хранить на внешних максимально публичных ресурсах» — омг. Во-первых — не его хранить, а к CDP доступ предоставлять. Потому что иначе

    цепочка проверки «снаружи» просто не сработает, если «снаружи» не будет доступен. И не «рекомендуется», а «требуется». Если бы Вы затруднялись чтением таких

    документов, как RFC, например, то у Вас бы на разницу между MUST и SHOULD была бы другая реакция.

    4. То, что Вам кажется, что n-уровневые модели не нужны, хорошо проистекает из Вашего описания своей деятельности. Вы — приходящий админ, притом с набором комплексов

    про «сертифицированных всяких», «венду глючную» и понт вида «с мобильника по ssh». В силу вышеуказанного крупных систем Вы не видели, да и наврят ли увидите — смена

    картриджей в пределах МКАД манит динамичных парней с мобильниками и ssh подшивкой журнала «Хакер». А в конторах, где приходящий администратор, многоуровневые иерархии

    CA действительно не нужны обычно. Речь-то правда не про это в статье, а про ситуации, когда оные нужны.

    5. Иерархия CA отношения к high availability не имеет. Совсем. By design. Для появления HA вообще иерархические структуры не делают. HA — априори функция

    одноуровневых систем. В ширину, грубо говоря, для HA растут, а не в высоту. А Вы предполагаете, что это — _единственная_ задача появления иерархии. Вы не знаете, что

    такое HA, плюс что такое иерархия CA, и при этом — рассуждаете на эти темы.

    6. Про динамичность работы и пример с налоговой — тоже фейл. Вы радуетесь, что там всё «сделано примитивно просто и нет никаких проблем». Вы не задумывались, что там

    ОДИН сертификат на ОДИН узел? Там можно опубликовать CRL один раз в год, разово скачать и всё. Только вот это исключение, а не правило. Иерархии CA поддерживают

    сложные системы, где сертификатов могут быть десятки миллионов в год. А не один.

    7. Про то, иерархия CA заменяется «обычным балансировщиком http, например nginx», смеяться смысла нет — надо грустить. Не мне, замечу.

    8. Про платформозависимость тоже — написать написали, а зачем — загадка. Наверное, в Cisco IOS другие x.509v3 сертификаты, чем у всех? Или у Win2008 R2 в CA другой

    CRL формируется по структуре, чем у того же Keon'а? Вы показываете своё незнание целого класса технологий, а виновата в этом «венда глюшная». Традиционно. Может, не там ищете?

    9. Вы и в остальном могучий профи, если вчитаться.

    «Точно также как не надо забывать, что до всех ваших «лесов с деревьями» DNS выполнялся исключительно НЕ средствами винды.»

    Т.е. пишущий предполагает, что леса и деревья — это DNS. Это ж ахтунг.

    10. Про рост уязвимости системы от увеличения количества CA. Алексей, Вы, наверное, не в курсе (скриптом это ведь не делали с мобильника по ssh, а то бы помнили), но при организации даже двухуровневой структуры — с корневым и выдающим CA — уязвимость сетевых узлов в плане количества никак не меняется. Потому что в сети находится только выдающий CA. Корневой выпускает сертификат для subordinate, публикует CRL, и, к примеру, выключается. Если он на виртуалке — его кладут в паузу, пишут на флэшку и уносят в сейф. На сетевом уровне его _никак_ не сломать, потому что он в offline. Вы изучите функционал и задачи CA в иерархии, тогда увидите, что корневому быть в онлайне и не нужно, в общем-то.

    11. Дублирование контента на CA. Это треш, конечно, но Вы так и не ответили ни на один вопрос на тему оного утверждения. Как Вы себе вообще представляете _дублирование_ содержимого между разными CA? Что дублируется между корневиком и policy? Или между двумя выдающими одноуровневыми?

    12. Атака на корневой CA в Вашем представлении — это «не только подмета стороны взаимодействия, но и DoS». Вы правда думаете, что две именно этих атаки:

    a) Реализуемы на корневом CA?

    b) Будут топовыми по негативным последствиям для атакуемого?

    У Вас даже примерного представления о PKI нет. Зачем Вы про данную тему вообще пишете, при том с таким пафосом и понтами? Сходите к Леониду на курсы, поучитесь. Полезнее будет.

  33. Да, самое ценное в любом месте это люди 😉

    Вот например журнал «сисадмин». Понятно, что там кроме Дмитрия Шурупова никто в технологиях не «шурупит», простите за тафталогию. Но я все равно очень ценил этот коллектив, пока там не появился «пуп некомпетентности».

    Вот и здесь, если пропустить реплики главного пальцеразвадителя Ильи, начавшего с признания о своем недопонимании предмета, то можно найти тех, кто на самом деле обсуждает статью, а не комментарии. Да и вообще тут милые люди. Я почитал немного ресурс. Особенно поразило itband.ru/2009/10/it-interview/. Прикиньте, человек, мозг которого изнасилован майкрософтом, нашел в себе силы выглянуть наружу и поинтересоваться jooml-ой! Офигеть, он это даже противопоставляет Sharepoint-у! После такого вера в людей сильно возрастает 😉

    Мне конечно жаль, что Руслан не выполнил порученное ему Ильей смешить меня анекдотами, но все равно читать его посты весело. И еще жаль, что Леонид не сможет так же повеселиться читая всю эту байду.

    Хотя в общем то все достаточно просто. Статья хорошая. Но в статье есть мелкие недочеты. Я не буду придираться по пустякам, типа «внедрение инфраструктуры открытых ключей все чаще становится насущной необходимостью огромного числа компаний» — за это надо стучать по ушам редактора из «самага», ну, это просто не по-русски. Однако, аутентичность не подтверждается внешними средствами, так как это свойство самого объекта, неотделимое от него в рамках принятой концепции безопасности, и только сам объект может «подтвердить» это, потому и называется словом в котором использован префикс «ауто». (Руслан, Вам двайбан по теории!) Второе слабое место в статье, которое обсудить с Леонидом помешали набежавшие мальчиши под командованием Ильи, это слабая обоснованость предлагаемой в статье архитектуры многоуровневого PKI. Третье, если бы общение с автором происходило без малограмотных и крикливых посредников, можно было сказать, что автору следовало бы уделить внимание традиционной архитектуре построения PKI, состоящий из публичного фронтэнда и приватной части.

    Итого, поскольку Руслан не выполнил свои обязательства по размещению в треде анекдотов, то, увы, беседа моя с вами, дорогие коллеги, завершается 😉

  34. > Понятно, что там кроме Дмитрия Шурупова никто в технологиях не «шурупит», простите за тафталогию

    Шурупов — теоретик и оплачиваемый пропагандист СПО. Технических знаний у него минимум. Практики нет, потому что он не работал по профессии.

    > Однако, аутентичность не подтверждается внешними средствами

    Кому нужна аутентичность сама по себе, без подтверждения со стороны? Аутентичность без взаимодействия — это паспорт своего, уникального формата, никому не известного. ФИО есть, фотка есть, но документом не является.

    > и только сам объект может «подтвердить» это, потому и называется словом в котором использован префикс «ауто».

    Вы, случаем, не виртуал Михаила Задорнова? Он тоже вот любитель слова по частям поразбирать, исходя из своей, чудесатой и запредельной логики. Почитайте, что префикс «ауто» может обозначать — удивитесь.

    > традиционной архитектуре построения PKI, состоящий из публичного фронтэнда и приватной части.

    Придумывание собственной терминологии — гарантия незнания базовых вопросов и малого знакомства с документацией. Если бы Вы изучали предмет, про который пытаетесь говорить, Вы бы владели стандартной терминологией — это проще и удобнее, чем выдумывать «абы что, лишь бы ответить». Иерархическая структура PKI Вам не нравится, но вот некую «традиционную архитектуру, состоящую из фронтэнда и приватной части» (sic!!!!) Вы выдумываете.

    Жаль, что Вы ни на один вопрос ответить не смогли, а то можно было бы поговорить. И — всё же — попробуйте начать изучать PKI. Вам будет трудно, там для Вас много незнакомого и малопонятного, но попробуйте — очень интересная штука. Я гарантирую это.

  35. вставлю пять копеек исключительно в целях Grammar Nazi 🙂

    >Однако, аутентичность не подтверждается внешними средствами, так как это свойство самого объекта, неотделимое от него в рамках принятой концепции безопасности, и только сам объект может «подтвердить» это, потому и называется словом в котором использован префикс «ауто»

    Имея базовое образование в области медицины, в свое время год как минимум потратил на изучение основ lingua latina. Вы смешны, коллеги. «аутентичность» от слова «authentic» не имеет префикса «auto» вы удивитесь. Словарь Мюллера определяет «аутентичный» как 1) подлинный 2) достоверный, верный. Подлинность, чисто логически, должна кем-то удостоверяться. Иначе я «самодержец всея Великая и Белая и Малая» и не оспорить этого. тут психиатр нужен уже.

  36. to alekseybb

    Интересно, а кто Вам дал право оскорблять людей. Вообще Интернет развращает таких как Вы. Вот поговорили бы Вы со мной так (или с Русланом) -на улице-получили бы в рыло, извините. Я кстати не любитель делить мир на MS и не MS-просто возмущает такой тон ведения беседы. Человек тратит свое время -пишет статью, размещает на другом сайте, который поддерживается другим человеком-который тратит на это свое время. Все это делается для просвящения русскоязычной части админов MS и не только, кстати.

    Тут является какой-то мастер спорта по боксу полковник Чингачгук и начинает всех поливать г...м. Звали тебя сюда?

  37. Дмитрий,

    К сожалению, подобных унылых интернет-боксёров — тьма. В принципе, они и должны быть, чтобы показывать на контрасте разницу между знаниями (IT) и религией (опенсорс). Сами видите — человек не знает азов, но всех поучает, притом крайне агрессивно. Классическая сцена с проф.Преображенским, доктором Борменталем и Шариком, римейк.

    Потом вот спрашивают — почему в мире IT-про к фанатикам СПО так относятся. Казалось, бы, действительно.

  38. Притом что всегда удивляет — это маниакальная ненависть к обучению у подобных. Допустим, есть система, выполняющая некоторые задачи. Тот же CA. Вариантов реализации — тьма. И в любой ОС современной он имеется, и в оборудовании, и сторонний коммерческий софт есть. Чтобы предложить клиенту вариант решения его проблемы, надо все аналоги хотя бы знать. Не хорошо, а просто знать. Иначе сравнение получается волшебное — о каком адекватном выборе между 2 системами идёт речь, если человек одну не знает, а в другую просто верует «ибо круто потому что не венда»? Сможет ли такой человек работать архитектором, ГИП, ПМом? Ответ очевиден. Начнёт ли он учиться и будет ли вообще повышать свой уровень? Аналогично.

    Тут вот — человека аккуратно распросили про CA. Вербу он не видел. Встроенный в Windows CA — тоже. В IOS — тоже. Keon RSA'шный — тоже. В теоретических аспектах PKI — по нулям. Но он верует, что «если не на винде, то круто, ёба». Кому специалиста в штат блестящего, налетай, разбирай, угу...

    Классика — «ну я эта... дома на линухе поднял кароч днс... ну кароч посмотрел минуты 3... вроде всё понятно... чё там изучать, непонятно, муть какую-то выдумали злые взрослые, строго чтобы миня, борцуна с системой, сбить с панталыку...» . Так рождается иксперт во всех направлениях, который не имеет ни теоретических знаний (скучно ж), ни практических (работа — для быдла, и так всё понятно ж). Иксперт стирает пальцы, потому что молнией раскусывает в интернете школоту и лохов, задней ногой отпинывая родителей, спрашивающих про уроки и/или «когда ж ты, ванюша, на работу пойдёшь». Понятно, что потом идёт время, чувак так и остаётся бродячим админом, гордясь под бутылку пива «Охота» чем-то вида «ну я короче поднял чуваку нат на домашнем длинке... чё там, полчаса на всё... а тыщу получил... и нахер эти циски нужны... понапридумывают, чтобы трудовой народ облапошить... но мы-то хитрее». Отсюда острая ненависть у автора к упомянутым обладателям всяких аббревиатур и сертификатов, КПД на уровне парового катка и острые, простреливающие боли в районе крестца и musculus levatoris ani.

    А статья хорошая, материал из неё надо знать отлично, это базовые вопросы PKI, без них в профессии делать просто нечего.

  39. Ребятишки, да вы все веселее и веселее становитесь 😉

    Особенно приятно отметить «да если бы мы с тобой на улице повстречались...». Сразу видно очень смелых людей. Медаль за отвагу!

    Прикиньте, я здесь вообще ни одного человека не оскорбил. Лишь двоих, Илью да Руслана, назвал неучами. Однако все страшно все обиделись. И знаете почему?

    Люди делятся на дураков и романтиков. Дураки всегда чего-то не знают. Они не заявляют, «я овладел всеми технологиями». Они просто получают проблему, осознают необходимость её решения и решают её. Увы, для вас, я отношу себя к дуракам. Другое дело романтики. Они наивно верят, что можно написать статью без ошибок, что можно выполнить работу безупречно, жениться идеально, построить коммунизм, слиться с богом...

    Вот романтики, окопавшиеся здесь, не понимают, как можно обсуждать что-то написанное с применением такого числа сертификатов майкрософт. Нет! Это нельзя обсуждать. И автор вообще не человек, у него вместо унитаза стоит приемник для золотых слитков. И вы все мечтаете, что однажды вместе с MVP вам тоже вручат приемник золотых слитков в форме унитаза.

    И знаете почему вас всех так невзлюбил романтик-Иван? Да потому что в вас он узнал себя. Он достиг всех доступных ему «вершин» — набрал коллекцию сертификатов, защитил КТН, 20 лет воздерживался от вина, более 30 раз подкидывает гирю... Возможно у него уже есть лелеемый в ваших мечтах унитаз для накопления золота... Однако, как он не тужится золото не оседает 😉 Вот это его и кручинит.

    У этого Ивана харизмы больше всех вас вместе взятых... Жаль мужика, не нашлось рядом друга настучать ему по башке и полечить малешка. И с вами рядом тоже никого нет.

    Показательно как Руслан оценивает собеседников: "Кому специалиста в штат блестящего, налетай, разбирай, угу... "

    Это «по Фрейду». Чувак повернут на смене работы и ждет, что все такие же. Если есть, кто из HR, поставьте «засечку» не брать — продаст 😉

  40. Алексей, а почему Вы считаете, что «все страшно обиделись»? 🙂

    ИМХО: большинству посетителей вообще параллельна эта дискуссия и Ваши отношения с Русланом и Ильей 🙂 (хотя мне было интересно почитать дискуссию)

  41. to alekseybb

    Он достиг всех доступных ему «вершин» — набрал коллекцию сертификатов, защитил КТН, 20 лет воздерживался от вина, более 30 раз подкидывает гирю...

    И перелюбил всех теток в Голливуде:)

    Этот Иван- скорее всего чел, который кабеля по подъездам у местечкового провайдера тянет или в магазине одминит 6 компов 🙂

    Какая, нах... гиря, какая нах... кандидатская

  42. «Лишь двоих, Илью и Руслана, назвал неучами»

    www.certification.ru/cgi- ...1121605479-79119

    Ruslan V. Karmanov (Ruslan V. Karmanov)

    URL: www.atraining.ru

    День рождения: 13 ноября 1978

    Город: Москва

    Место работы: Advanced Training

    Должность: CEO

    Сертификаты: Microsoft: MCP,MCDST,MCSA:*.*,MCSE:*.*,MCAD,MCSD,MCDBA,MCT, Small Business Specialist, MCTS:Ex2007/SPS2007/Win2008/SQL2005, MCITP. CompTIA: A+,Network+,Server+,Security+,CTT+. CWNP: CWNA,CWSP,CWAP. Cisco: CCSI #31001, CCNA,CCDA,CQS:CWLSS,CSE,CCNP,CCIP,CCSP,CCDP, CCIE:RS/SP/Sec Written Symantec: SCTA. HP: AIS:Proliant. ARIS: ARIS 6 Analyst.

    Ты, чувак, сдай на ccnp без дампов-про CCIE:RS/SP/Sec я промолчу...

    Тогда будешь людей неучами...

    Поинтересуйся кто такой Бешков. Линуксц небось не хуже твоего знает. Но почему то в MS работает.

    Извиняюсь перед нормальными людьми за оффтоп

  43. Остро, как всегда, при участии Карманова. Что его профессионализма не отменяет.

    Илья, не хочешь кормить троллей — не забывай про СоС. Гаденько как-то и мелко вестись на здравые в общем-то временами выпады в довольно резкой форме.

  44. >>Прикиньте, я здесь вообще ни одного человека не оскорбил. Лишь двоих, Илью да Руслана, назвал неучами. Однако все страшно все обиделись. И знаете почему?

    Потому что если кто либо хамит — его просят перестать и говорить по человечески, если хамство продолжается — то человеческое отношение заканчивается. Я уж молчу о том, что приличный человек изначально не начинает с хамства.

    >>Вот романтики, окопавшиеся здесь, не понимают, как можно обсуждать что-то написанное с применением такого числа сертификатов майкрософт

    Слабо развирутализоваться то?

    Показать своё ФИО, свои сертификаты от лидеров индустрии, реализованные проекты, место работы? Может показать сайты, на которых другими людьми написано что вы мега гуру?

    А то окромя метания фекалий от вас ничего не слышно.

  45. Ruslan. V. Karmanov спасибо. дальше можно было не читать.

    Вроде все пояснили человеку.

  46. Статья очень помогла понять «что есть что в CA и PKI», даже спустя столько лет. Просто и доступно написано.

    Спасибо.

    p.s. не понимаю, из-за чего весь сыр бор.:)

Опубликовать

Я не робот.