 |
|
|
|
Инфраструктура открытых ключей в Windows Server 2016. Часть 5. Отказоустойчивость
Инфраструктура открытых ключей
|
СТЕПАН МОСКАЛЕВ, инженер ИТ-систем, MCSE, MCSE:S, MCSE:M, MCITP EA, MCITP EMA, HP AIS, 
ЛЕОНИД ШАПИРО, архитектор ИТ-систем, MVP, MCT, MCSE, MCITP:EA, MCSE:S, MCSE:M, 
Продолжаем тему построения инфраструктуры открытых ключей для корпоративного использования. Нельзя забывать о необходимости отказоустойчивости и доступности, причем это касается не только самих удостоверяющих центров/центров сертификации, но и, разумеется, всего необходимого для их работы окружения| Давайте разберемся с тем, какие сбои могут встретиться при работе с сервером сертификатов |
При сбоях оборудования и повреждении данных все стандартные, привычные нам варианты защиты приходят на помощь. Это резервирование по электропитанию, 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-путь, поскольку с его помощью мы сможем проверить список отзыва и цепочку сертификатов. Получается, что еще на начальном этапе мы уже кое-что сделали для повышения надежности функционирования нашей системы.
Подведем итоги. Мы разобрались с тем, какие сбои могут встретиться при работе с сервером сертификатов. Это отказы оборудования, некорректная модификация данных в силу тех или иных причин, наконец, компрометация сервера сертификатов.
Мы стали понимать, какие методы противодействия есть в нашем арсенале. Мы не касались компрометации самого сервера сертификатов. К этому нам еще предстоит вернуться. Что касается остальных проблем, то тут нам помогают, помимо известных средств, дублирование и кластеризация.
Выбор того или иного варианта связан с несколькими аспектами, и здесь у нас возникает противоречие между требованиями безопасности и необходимостью сокращения расходов.
Продолжение следует…
- Шапиро Л. Внедрение инфраструктуры открытых ключей на основе Windows Server 2016. Часть 1. Предварительный этап. / «Системный администратор», № 1-2, 2018 г. – С. 23-27. URL: http://samag.ru/archive/article/3576.
- Москалев С., Шапиро Л. Инфраструктура открытых ключей в Windows Server 2016. Часть 2. RootCA. / «Системный администратор», № 3, 2018 г. – С. 16-19. URL: http://samag.ru/archive/article/3605.
- Москалев С., Шапиро Л. Инфраструктура открытых ключей в Windows Server 2016. Часть 3. Установка и настройка издающего центра сертификации (Issuing CA). / «Системный администратор», № 7-8, 2018 г. – С. 26-28. URL: http://samag.ru/archive/article/3685.
- Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map – https://tools.ietf.org/html/rfc4510.
- Шапиро Л. Атаки DDoS. Часть 1. Война объявлена... / «БИТ. Бизнес&Информационные технологии», № 5, 2015 г. – С. 28-31. URL: http://bit.samag.ru/archive/article/1504.
Ключевые слова: отказоустойчивость, доступность, сервер сертификатов.
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
