Главная Networks, Security, Windows, Новое Инфраструктура открытых ключей в Windows Server 2016. Отказоустойчивость
  • Инфраструктура открытых ключей в Windows Server 2016. Отказоустойчивость

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

    Отказоустойчивость и доступность всей системы – это не только центры сертификации. Думаю, что вы уже заметили, что у нас есть еще некоторые компоненты решения, например точки распространения (Distribution Points). Они также составной элемент нашего решения. Значит, их до ступность и отказоустойчивость нам очень важны. Если пользователи системы не смогут получить к ним доступ, то система становится неработоспособной. Есть и другие элементы решения, чья отказоустойчивость и доступность нам также важны.
    В этой статье мы рассмотрим только то, что касается серверов сертификатов. Будем разбираться поэтапно и начнем с центров сертификации.
    Типовая иерархия удостоверяющих центров обычно двухили трехуровневая и состоит из корневого и издающего серверов для первого варианта и корневого сервера, сервера политик и издающего для второго. Рассмотрим первый вариант. Какую иерархическую модель предпочесть в том или ином случае, мы уже виделив статье [1]. Так что не будем на этом останавливаться. Теперь поговорим о том, что будет происходить в случае отказа. Кстати, неплохо было бы определиться, какие отказы возможны.
    первое – выход из строя оборудования,
    второе – повреждение данных,
    ну и третье – компрометация.
    Как бороться с первыми двумя проблемами, мы как рази разберем. Есть некоторая специфика, характерная для сервера сертификатов. Что касается компрометации,то это тема отдельного разговора, выходящая за рамки статьи.
    При сбоях оборудования и повреждении данных все стандартные, привычные нам варианты защиты приходят на помощь. Это резервирование по электропитанию, RAID-технологии и резервное копирование.
    Стоит отметить, что с корневым сервером и сервером политик все оказывается довольно просто, мы не слишком озабочены их отказоустойчивостью, и, как правило, нам достаточно простых решений. Почему так?
    Как вы знаете из статей [1, 2], потребность в этих серверах возникает крайне редко, да и вообще большую часть
    своего времени жизни они выключены. Это не означает,что мы можем о них забыть навсегда, но существенно упрощает задачи администратора системы.
    Важно понимать, что не следует совмещать роли на этих серверах или виртуальных машинах, использовать их для других задач, ну и, конечно, их нельзя удалять. Совмещение ролей приводит к снижению безопасности, так как требует постоянной доступности, что противоречит требованиям безопасности. Кстати, использование для корневого центра сертификации (RootCA) и центра политик (PolicyCA) именно виртуальных машин – неплохая мысль, поскольку, очевидно, дает возможность экономии аппаратных ресурсов. Для восстановления этих сервисов в случае сбоев нам вполне хватит резервного копирования.

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

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

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

    На первый взгляд может показаться, что такой вариант сможет нас удовлетворить. На самом деле здесь мы упускаем один очень важный аспект.
    Дело в том, что в случае компрометации необходимо сертификат отозвать, причем чем быстрее мы это сделаем, тем лучше, но у нас ведь не работает сервер сертификатов, отказ сервиса. Стало быть, потребуется сначала его восстановить и только после этого отзывать сертификат, публиковать список отзыва и прочее. Процесс затянется, а это вопрос безопасности…
    Если речь идет о каком-то тестовом стенде или учебной задаче, то мы можем и не обратить на это внимание. В реальной рабочей среде ситуация становится очень серьезной, поскольку злоумышленник, пользуясь скомпрометированным сертификатом, который мы не смогли отозвать, может выполнить некие деструктивные действия. Таким образом, вариант применения единственного сервера сертификатов создает, помимо невозможности обслуживания клиентов в течение некоторого времени, что для кого-то еще может быть приемлемым, угрозу безопасности, а этого допускать нельзя. Значит, мы вынуждены использовать другие более эффективные схемы.

    Что в этом смысле нам может предложить Microsoft? Один из вариантов – обеспечить более высокий уровень доступности сервиса для клиентов за счет дублирования (см. рис. 1).

    Рисунок 1.

     

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

    Рисунок 2.

    В этом случае база данных едина, то есть выход из строя одного из серверов кластера не приводит к тому, что мы не сможем отозвать скомпрометированный сертификат. Пользуясь той же самой базой, это сделает другой сервер кластера. Сервер сертификатов Microsoft поддерживает возможность кластеризации. Такой вариант оказывается весьма эффективным для решения задачи обеспечения доступности и отказоустойчивости инфраструктуры. Оба эти варианта могут быть применены совместно, например, в ситуации двух филиалов, каналы связи к которым не слишком хороши (см. рис. 3).

    Рисунок 3

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

    Еще один момент, который мы не обсудили раньше. Если вы обратили внимание, то, когда мы настраивали наш издающий центр сертификации (см. статью [3]), в extensions,
    помимо http-пути к сертификатам и спискам отзыва, мы еще добавили LDAP-путь [4]. Зачем же мы все-таки это сделали? Очевидно, что http-путь доступен для любого клиента, тог-
    да как LDAP – это только для клиента AD. При этом вы видите, что http в списке стоит первым, получается, что до проверки LDAP мы скорее всего даже не дойдем. Ситуация может быть разной. Веб-сервер, являющийся точкой распространения, сам может оказаться недоступен, что приведет к неработоспособности инфраструктуры. Да, конечно, мы подумаем и о его отказоустойчивости
    и надежности, но об этом речь пойдет в следующей статье, однако может сложиться ситуация, когда мы подверглись DDoS-атаке [5]… В конце концов для веб-сервера эта история куда более вероятна, чем для контроллера домена. Если веб-сервер под атакой и не отвечает, то проверку мы выполнить не сможем, и вот тут нам может помочь добавленный LDAP-путь, поскольку с его помощью мы сможем проверить список отзыва и цепочку сертификатов. Получается, что еще на начальном этапе мы уже кое-что сделали для повышения надежности функционирования нашей системы.

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

     

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

    Литература

    [1] Шапиро Л. Внедрение инфраструктуры открытых ключей на основе Windows Server 2016. Часть 1. Предварительныйэтап. / «Системный администратор», № 1-2, 2018 г. – С. 23-27.
    URL: http://samag.ru/archive/article/3576.
    [2] Москалев С., Шапиро Л. Инфраструктура открытых ключейв Windows Server 2016. Часть 2. RootCA. / «Системный администратор», № 3, 2018 г. – С. 16-19. URL: http://samag.ru/archive/
    article/3605.
    [3] Москалев С., Шапиро Л. Инфраструктура открытых ключей в Windows Server 2016. Часть 3. Установка и настройка издающего центра сертификации (Issuing CA). / «Системный ад-
    министратор», № 7-8, 2018 г. – С. 26-28. URL: http://samag.ru/
    archive/more/184.
    [4] Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map – https://tools.ietf.org/html/rfc4510.
    [5] Шапиро Л. Атаки DDoS. Часть 1. Война объявлена… / «БИТ.Бизнес&Информационные технологии», № 5, 2015 г. – С. 28‑31.
    URL: http://bit.samag.ru/archive/article/1504.