Сертификат безопасности отменили. Как его удалить и можно ли отслеживать трафик без него?
Введение сертификата безопасности оказалось тестом. Что говорит о сертификате закон и как его удалить с различных устройств?
Чуть более двух недель в Нур-Султане спецслужбы тестировали национальный сертификат безопасности. Чтобы получить полноценный доступ к интернету, жители столицы должны были установить его на свои мобильные телефоны, компьютеры и другие устройства.
6 августа в Комитете национальной безопасности заявили об успешном завершении тестирования сертификата безопасности. Национальный координационный центр информационной безопасности выявил более 8 млн фактов вирусной активности и 130 тысяч кибератак на государственные органы и частные компании, также были выявлены факты кибершпионажа в отношении ряда государственных органов.
Было объявлено, что казахстанцы могут удалять национальные сертификаты безопасности Qaznet Trust Network со своих устройств. Informburo.kz рассказывает, значит ли это, что власти отказались от идеи контролировать казахстанский интернет и как удалить пресловутый сертификат со своего устройства.
А это законно?
В Законе «О связи» от 2015 года есть пункт, касающийся национального сертификата безопасности. После того, как казахстанцев попросили установить сертификат, в социальных сетях было много высказываний о том, почему четыре года с момента принятия Закона «О связи» на этот пункт не обращали внимания.
В законе сказано следующее:
«Операторы междугородной и (или) международной телефонной связи обязаны:
– осуществлять пропуск трафика с использованием протоколов, поддерживающих шифрование с применением сертификата безопасности, за исключением трафика, шифрованного средствами криптографической защиты информации на территории Республики Казахстан «.
При этом закон не даёт операторам право ограничивать доступ к интернету тем, кто не установил на своё устройство национальный сертификат безопасности. Как поясняли представители компаний, операторы обязаны уведомлять своих абонентов о необходимости установки сертификата, который выпускает Национальный удостоверяющий центр РК. и предоставлять к нему доступ.
Также закон не обязывает казахстанцев устанавливать национальный сертификат на свои устройства, чтобы получить доступ к интернету.
Если я удалю сертификат, то будут ли за мной следить?
Если вы удалите национальный сертификат безопасности со своего устройства, то у представителей спецслужб не будет абсолютного доступа к вашему трафику. Это значит, что они не смогут его подменять, но это не значит, что они не смогут его считывать.
Согласно статье 26 Закона «О связи» операторы обязаны весь трафик пропускать через систему централизованного управления сетями телекоммуникаций РК. Также представители Министерства цифрового развития, оборонной и аэрокосмической промышленности в Казахстане сказали, что действует промежуточная система, которая позволяет вмешиваться в поток данных и считывать его, для чего и нужна централизация всех потоков. Сертификат безопасности – часть промежуточной системы. В основном он необходим для удобства управления трафиком, так как он позволяет получать его в незашифрованном виде.
Если на вашем устройстве нет национального сертификата, то государство всё равно может перехватывать ваш трафик, просто он будет в зашифрованном виде.
Больше никаких сертификатов?
На сегодняшний день государство приостановило внедрение национального сертификата безопасности, но это не значит, что в следующий раз подобное «тестирование» на проведут на территории всего государства по нескольким причинам:
Отключить сертификат Qaznet Trust Network:
Удаление сертификата безопасности Qaznet Trust Network ( IOS ).
Удалить сертификат Qaznet Trust Network:
Удаление сертификата безопасности Qaznet Trust Network (Andriod).
Как удалить сертификат из Windows?
Независимо от того, через какой браузер вы устанавливали сертификат безопасности, его можно удалить одним способом.
Для начала вам нужно зайти в «Панель управления«:
Как удалить сертификат из MacOS?
Устройства под управлением MacOS независимо от версий обычно имеют схожую логику меню. Вне зависимости от того, старой или новой операционной системой вы пользуетесь, чтобы найти расположение сертификата безопасности, запустите приложение «Связка ключей».
Как найти приложение «Связка ключей»:
На устройстве установлен сертификат цс что это значит
Пользователям устройств на база Android давно известно, что жизненный цикл гаджетов зависит не только от работоспособности железа, но и от соответствующей поддержки программной экосистемы. В отличие от устройств на платформе iOS, устройства Android вполне себе могут «жить» на достаточно старых версиях Android. Как стало недавно известно, все может достаточно сильно измениться. Что же произошло?
реклама
Не секрет, что большинство мобильных гаджетов в том числе берутся для доступа и использования онлайн. Каждое устройство для доступа к сайтам должно иметь соответствующие корневые сертификаты (корневой сертификат (СА) — часть ключа, которым центры сертификации подписывают выпущенные SSL-сертификаты. Выдавая корневой сертификат, каждый такой центр гарантирует, что пользователи или организации, запросившие SSL, верифицированы и действия с доменом легальны). Без них доступ к сайтам будет серьёзно ограничен.
В 2015 года появился новый сервис Let’s Encrypt.
На официальной страничке сервиса мы можем увидеть следующее:
06.11.2020 данный сервис сообщил о некоторых изменениях в своей работе с корневыми сертификатами (КС).
Как объясняют сами Let’s Encrypt, на этапе формирования новых центров сертификации (ЦС) необходимо, чтобы его корневой сертификат пользовался доверием в самых разных операционных системах (ОС) и браузерах. Также понятно, что программная поддержка нового корневого сертификата ОС-ами и браузерам могут потребоваться годы (безопасность превыше всего), и еще намного больше времени для того, чтобы у людей появились повсеместно соответствующие устройства. Поэтому наиболее оптимальными и быстрым способом интеграции новых КС является перекрестная подпись сертификатов с существующим доверенным ЦС. ЦС Let’s Encrypt именно таким путем и пошел и 19.10.2015 года стало известно о перекрёстном подписании своих сертификатов Let’s Encrypt с организацией IdenTrust (сертификат DST Root X3). IdenTrust является ведущим поставщиком цифровых сертификатов, которые создают основу для надежных решений идентификации, признанных финансовыми учреждениями, поставщиками медицинских услуг, правительственными учреждениями и предприятиями по всему миру. Так как КС IdenTrust DST Root X3 существует достаточно давно, то все основные программные платформы уже доверяют ему: Windows, Firefox, macOS, Android, iOS и множество дистрибутивов Linux, что сразу позволило сертификатам Let’s Encrypt работать со всеми перечисленными платформами. Фактически, без IdenTrust Let’s Encrypt как глобальный ЦС могла бы никогда не состояться. Тем временем Let’s Encrypt выпустили свой собственный корневой сертификат (ISRG Root X1) и подали заявку на то, чтобы его поддерживали (доверяли) основные программные платформы.
Let’s Encrypt с использованием DST Root X3 добилась своего: на 2020 год все актуальные программные платформы поддерживают корневой сертификат ISRG Root X1 и готовы с ним работать. Так как перекрестная сертификация с DST Root X3 заканчивается 01.09.2021 года Let’s Encrypt сообщает, что вполне способна обойтись без перекрестной сертификации. Вот здесь и существует проблемы совместимости для обычных пользователей Android.
Естественно, когда к 2016 году началось повсеместное внедрение ISRG Root X1 (к 2016 году), устаревшие к тому моменту программные среды не имеют возможности доверять корневому сертификату Let’s Encrypt напрямую в силу отсутствия соответствующей программной поддержки. Например, сюда входят версии Android 7.1 и более ранние. Это означает, что старые версии Android больше не будут доверять сертификатам, выданным Let’s Encrypt с 01.09.2021 и получать доступ к соответствующим сайтам.
Хотя в настоящий момент корпорация Google официально не предоставляет информацию по распространению различных версий Android, тем не менее некоторую информацию можно получить из Android Studio (данные на сентябрь 2020):
Таким образом, в настоящее время около 66% устройств Android работают под управлением версии 7.1.1 или выше. Остальные примерно 40% устройств Android имеют более ранние версии и в конечном итоге начнут получать ошибки корневого сертификата при посещении сайтов с сертификатом ISRG Root X1.
Так же, Let’s Encrypt, исследуя данную проблему, обратилась к крупными интеграторами и обнаружила следующее: средний интернет-трафик устаревших устройств составляет около 1-5%. Естественно, нельзя исключать, что эти цифры упадут к моменту истечения срока действия DST Root X3, но все же рассчитывать на какое-либо существенное падение надеяться не стоит.
Что же можно предложить пользователям старых версий Android в данной ситуации?
Как установить доверенный сертификат ЦС на Android-устройство?
Я создал свой собственный сертификат CA и теперь хочу установить его на свое устройство Android Froyo (HTC Desire Z), чтобы оно доверяло моему сертификату.
Теперь Android, похоже, не перезагружает файл автоматически. Я прочитал в нескольких сообщениях в блоге, что мне нужно перезагрузить устройство. Это приведет к тому, что файл снова будет перезаписан исходным.
Итак, как правильно установить мой собственный сертификат корневого ЦС на устройстве Android 2.2 в качестве доверенного сертификата? Есть ли способ сделать это программно?
10 ответов
До Android KitKat вам необходимо выполнить рутирование устройства, чтобы установить новые сертификаты.
С Android KitKat (4.0) до Nougat (7.0) это возможно и просто. Мне удалось установить сертификат Charles Web Debbuging Proxy на мое некорневое устройство и успешно прослушивать SSL-трафик.
Начиная с Android 4.0 (Android ICS / ‘Ice Cream Sandwich’, Android 4.3 ‘Jelly Bean’ и Android 4.4 ‘KitKat’), системные доверенные сертификаты находятся в системном разделе (только для чтения) в папке ‘/ system / etc / security / ‘как отдельные файлы. Однако теперь пользователи могут легко добавлять свои собственные «пользовательские» сертификаты, которые будут храниться в «/ data / misc / keychain / certs-added».
Установить сертификаты CAcert как «доверенные» сертификаты пользователя очень просто. Установка новых сертификатов в качестве «доверенных системным» сертификатов требует больше работы (и требует корневого доступа), но это дает то преимущество, что позволяет избежать требования блокировки экрана Android.
Начиная с Android N становится немного сложнее, см. этот отрывок из Прокси-сайт Charles:
Начиная с Android N, вам необходимо добавить конфигурацию в свое приложение, чтобы оно доверяло сертификатам SSL, созданным Charles SSL Proxying. Это означает, что вы можете использовать SSL-прокси только с приложениями, которые вы контролируете.
Чтобы настроить приложение на доверие Чарльзу, вам необходимо добавить в приложение файл конфигурации сетевой безопасности. Этот файл может переопределить системное значение по умолчанию, позволяя вашему приложению доверять установленным пользователем сертификатам CA (например, корневому сертификату Charles). Вы можете указать, что это применяется только в отладочных сборках вашего приложения, чтобы производственные сборки использовали профиль доверия по умолчанию.
Добавьте в приложение файл res / xml / network_security_config.xml:
Затем добавьте ссылку на этот файл в манифест приложения следующим образом:
Я потратил много времени, пытаясь найти ответ на этот вопрос (мне нужен Android, чтобы увидеть сертификаты StartSSL). Вывод: Android 2.1 и 2.2 позволяют импортировать сертификаты, но только для использования с WiFi и VPN. Пользовательского интерфейса для обновления списка доверенных корневых сертификатов нет, но обсуждается возможность добавления этой функции. Неясно, существует ли надежный обходной путь для ручного обновления и замены файла cacerts.bks.
Руководство, связанное здесь, вероятно, ответит на исходный вопрос без необходимости для программирования настраиваемого коннектора SSL.
Нашел очень подробное руководство по импорту корневых сертификатов, которое фактически поможет вам установить доверенные сертификаты CA на разные версии устройств Android (среди других устройств).
В основном вам необходимо:
Загрузите: файл cacerts.bks со своего телефона.
adb pull /system/etc/security/cacerts.bks cacerts.bks
Измените файл cacerts.bks на своем компьютере с помощью BouncyCastle Provider.
Загрузите файл cacerts.bks обратно на свой телефон и перезагрузитесь.
Вот более подробные пошаговые инструкции по обновлению более ранних версий телефонов Android: Как обновить хранилище ключей центра сертификации безопасности HTTPS в версиях до Android- 4.0 устройство
Что я сделал, чтобы использовать сертификаты startssl, было довольно просто. (на моем рутированном телефоне)
Я скопировал /system/etc/security/cacerts.bks на свою SD-карту
Зашел на portecle.sourceforge.net и запустил portecle прямо с веб-страницы.
Открыл мой файл cacerts.bks с моей SD-карты (ничего не ввел при запросе пароля)
Выберите импорт в портакле и откройте sub.class1.server.ca.crt, в моем случае он уже имел ca.crt, но, возможно, вам также нужно установить его.
Сохранил хранилище ключей и скопировал его baxck в /system/etc/security/cacerts.bks (на всякий случай я сделал резервную копию этого файла)
Перезагрузил телефон, и теперь я могу без ошибок заходить на свой сайт, используя сертификат startssl.
Если у вас есть рутированное устройство, вы можете использовать модуль Magisk для перемещения пользовательских сертификатов в систему, чтобы он стал доверенным сертификатом.
Эти шаги работали для меня:
В качестве альтернативы я нашел следующие варианты, которые мне не нужно было пробовать самому, но которые выглядели простыми:
Наконец, это может быть неактуальным, но, если вы хотите создать и настроить самозаверяющий сертификат (с помощью mkcert) для своего приложения (веб-сайта) PWA, размещенного на локальном веб-сервере IIS, я следил за этой страницей:
Вот альтернативное решение, которое фактически добавляет ваш сертификат во встроенный список сертификатов по умолчанию: Доверие ко всем сертификатам с использованием HttpClient через HTTPS
Однако это будет работать только для вашего приложения. Невозможно программно сделать это для всех приложений на устройстве пользователя, поскольку это может представлять угрозу безопасности.
Я не уверен, почему это еще не ответ, но я просто последовал этому совету, и он сработал.
Как установить и удалить цифровые сертификаты на Android
Хотя наш терминал готов к работе одновременно с тем, как мы включаем его в первый раз, правда в том, что бывают случаи, когда его безопасность заставляет нас использовать известные цифровые сертификаты. Эта опция доступна на всех Android терминалы и могут быть необходимо для успешного проведения некоторых процедур.
Что такое цифровые сертификаты?
Так называемые цифровые сертификаты идентифицируют компьютеры, телефоны и приложения по соображениям безопасности. Сопоставимым примером могут быть наши водительские права, которые используются для подтверждения того, что мы можем водить машину на законных основаниях. Таким же образом цифровой сертификат идентифицирует наше устройство и подтверждает имеющиеся у него права доступа.
Если мы зайдем в Настройки / Безопасность / Шифрование и учетные данные, мы можем ознакомиться со всеми этими сертификатами. Как мы говорим, цель состоит в том, чтобы наш терминал может без проблем получить доступ к большому количеству функций. Например, если мы посмотрим на длинный список, мы увидим некоторые из них, такие как «Google Trust Services», отвечающие за работу с сертификатами как Google, так и всего Alphabet.
Как устанавливаются новые сертификаты?
Поскольку все чаще проводить процедуры, требующие обмена конфиденциальной информацией, это Возможно, что в некоторых случаях нам придется установить цифровой сертификат. Например, в Испании это Фабрика национальной валюты и марок, которая действует как «поставщик сертификационных услуг», предоставляя нам различные типы электронных сертификатов, с помощью которых мы можем идентифицировать себя и выполнять формальные процедуры. безопасно через Интернет.
Чтобы установить новые сертификаты, мы должны сначала скачал файл с соответствующего веб-сайта. После этого мы нажимаем на Настройки / Безопасность / Шифрование и учетные данные. Теперь коснемся установки сертификатов из хранилища.
Удалить личные сертификаты
Возможно, что мы больше не нужен сертификат, или по соображениям безопасности мы хотим отменить его присутствие в нашей системе. В этом случае всегда важно соблюдать осторожность, чтобы не удалить из системы какие-либо сертификаты, которые необходимы для правильной работы телефона. В этом случае мы возвращаемся в Настройки / Безопасность / Шифрование и учетные данные. Затем в хранилище учетных данных мы касаемся «удалить учетные данные» и принимаем.
Установка центра сертификации на предприятии. Часть 1
Привет, Хабр! Мы начинаем новую серию статей. Она будет посвящена развертыванию службы сертификатов на предприятии на базе Windows Server 2016 с практическими примерами. Сегодня обозначим вступительные моменты и поговорим о типовых схемах развёртывания иерархии PKI: двухуровневой и многоуровневой. Обо всем этом читайте под катом.
Введение
Целевая аудитория
ИТ-администраторы, ИТ-инженеры и специалисты по безопасности, имеющие основные понятия о цифровых сертификатах.
Словарь терминов
В этой части серии использованы следующие сокращения и аббревиатуры:
Зачем нужен частный PKI?
Шифрование, цифровые подписи и сертификаты всё плотнее входят в нашу повседневную интернет-жизнь. Если об этих терминах 10 лет назад говорили мало, и далеко не всем ИТ специалистам был известен смысл этих слов, то сейчас они у многих на слуху. И этот процесс длится не год и не два, а добрый десяток лет. Сейчас мы находимся в активной фазе развития клиент-серверных веб-сервисов (привет мейнфреймам!), и значительная доля коммуникации людей и устройств перекладывается на компьютерные сети и интернет. Как следствие, новые условия диктуют новые требования к защите данных. Крупные производители ПО активно продвигают идеологию «безопасного интернета», требуя поддержки цифровых сертификатов, начиная от серверов с конфиденциальными данными, облачных служб, вплоть до кухонного чайника или бельевого утюга (IoT).
Некоторые компании делают это весьма настойчиво. Так, начиная с 2017 года, компания Google считает все сайты без поддержки HTTPS небезопасными: Moving towards a more secure web. И это весьма ощутимо влияет на интернет-индустрию. Во-первых, предупреждение в браузере (Google Chrome) явно не будет радовать ваших потенциальных клиентов и просто посетителей. Во-вторых, сайты без поддержки HTTPS опускаются в поисковой выдаче. Mozilla и другие крупные вендоры также не отстают от Google: Deprecating Non-Secure HTTP. С одной стороны, компании давят на интернет-индустрию, толкая организации на дополнительные расходы, связанные с цифровыми сертификатами. С другой стороны, это — вынужденный шаг, и всем нужно идти в ногу со временем.
Для решения этих проблем крупнейшие вендоры ПО объединились и совместными усилиями наводят порядок с цифровыми сертификатами в Internet PKI. Во-первых, создан единый стандартизирующий орган — CAB Forum (CA/Browser Forum), который определяет стандартные практики для коммерческих CA, производителей веб-ПО и потребителей сертификатов. Во-вторых, активное продвижение некоммерческого CA (но глобально доверенного) Let’s Encrypt для обеспечения бесплатными сертификатами с возможностью автоматического продления.
Казалось бы, это решает все проблемы безопасной коммуникации, и частные PKI (разворачиваемые в пределах организации) стали сразу ненужными. В какой-то, да, если частный PKI занимался обслуживанием внешних серверов (веб, VPN и т.д.). Но сервисы наподобие Let’s Encrypt в настоящее время покрывают лишь узкий спектр корпоративных потребностей в сертификатах. Например, не покрываются сертификаты для шифрования документов, почты, цифровых подписей. Часть задач, как аутентификация клиентов не покрывается совсем. Ещё одним ограничением является то, что для использования публичных сертификатов, выданных коммерческими CA вам необходимо иметь публичный домен. Получить сертификат для веб-сервера на имя domain.local от Let’s Encrypt технически невозможно. Именно поэтому актуальность частных PKI остаётся на очень высоком уровне. Пример использования частных PKI в корпоративной среде изображён на следующем рисунке:
Если компания решает использовать частный PKI в пределах организации, встаёт другой насущный вопрос: как же правильно его организовать, чтобы он отвечал современным практикам и стандартам хотя бы в пределах организации. В интернете можно найти многочисленные статьи о том, как развернуть PKI в компании на основе Active Directory Certificate Services (ADCS). Но в большинстве своём они изобилуют ошибками, исходят из неверных предпосылок и нередко являются копированием какого-то исходного (не всегда удачного) материала, а к имеющимся фундаментальным ошибкам привносят ещё и свои. Как следствие, многочисленные провалы в развёртывании PKI. Об этом можно судить по количеству соответствующих тем на форумах (в частности, TechNet Server Security). Качественной документации на английском языке не хватает, а на русском… Этот цикл статей призван восполнить этот пробел и систематизировать современные наработки.
Общие положения
PKI является технологией безопасности, которая основывается на стандарте X.509 и использует цифровые сертификаты. Целью PKI является повышение безопасности ИТ инфраструктуры предприятия за счёт предоставления механизмов по защите данных от несанкционированного доступа и незаконного изменения данных (подделка данных). Это достигается двумя основными криптографическими механизмами:
Поскольку ЦС выстраиваются в древовидную иерархию, возможно организовать многоуровневую иерархию, где на каждом уровне ЦС будет выполнять как роль издающего ЦС, так и дополнительные функции. В самом простом случае один ЦС может совмещать все роли, т.е. быть корневым, обеспечивать какие-то политики выдачи и выдавать сертификаты конечным потребителям. Более крупные компании и/или с более зрелой организацией ИТ-процессов уже используют разделение ЦС по ролям. Например, в головном офисе держат корневой ЦС, выдающий сертификаты только другим ЦС, которые уже на себе накладывают политики выдачи. Они могут не обслуживать напрямую конечных потребителей, а выдавать сертификаты другим подчинённым ЦС, которые, в свою очередь, и будут обслуживать конечных потребителей. В каждом подходе есть свои плюсы и минусы, которые будут рассмотрены ниже.
Отзыв сертификатов
Помимо задач по выпуску сертификатов, каждый ЦС периодически выпускает списки отзыва (Certificate Revocation List, CRL). Как и сертификаты, целостность списков отзыва обеспечивается цифровой подписью. CRL содержит серийные номера сертификатов, действие которых прекращено по какой-либо причине до официального истечения срока действия сертификата. Таким образом ЦС обеспечивает своевременное изъятие недействительного сертификата из оборота.
Каждый клиент после установки доверия сертификата через цепочку должен убедиться, что ни один сертификат в цепочке не был отозван своим издателем. Для этого клиент перебирает каждый сертификат в цепочке, выбирает CRL предоставленный издателем и проверяет наличие/отсутствие текущего сертификата в списке CRL. Если текущий сертификат находится в CRL, то доверие к сертификату (и всем ветвям дерева под ним) автоматически обрывается.
Фактически, если корневой ЦС отозвал все свои непосредственно изданные сертификаты, то ни один сертификат под этим корнем не будет доверенным вне зависимости от высоты иерархии. Здесь следует отметить один крайне важный и принципиальный момент: невозможно отозвать корневой (самоподписанный) сертификат. Т.е. если по какой-то причине он был скомпрометирован, его можно отозвать только принудительным удалением сертификата из хранилища сертификатов каждого клиента. Дело в том, что ЦС не определяет списки отзывов для самого себя, это делает издатель. В случае самоподписанного сертификата, ЦС является издателем самого себя. И при попытке включить себя в свой же список отзыва получается неопределённость: сертификат ЦС включен в CRL, который подписан ключом этого же ЦС. Если предположить, что сертификат ЦС недействителен, то и цифровая подпись на CRL является недействительной. Как следствие, невозможно достоверно утверждать, что сертификат корневого ЦС отозван. Причём, отзыв корневых сертификатов не предусмотрен и основным регламентирующим стандартом, RFC 5280, параграф §6.1 которого гласит:
When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path.
А на отзыв проверяется только проспективная цепочка. Если говорить в контексте Microsoft ADCS, то тут ситуация усугубляется ещё больше. В частности, вы технически можете отозвать корневой сертификат при помощи certutil.exe или CryptoAPI. Но как только вы это сделаете, ЦС не сможет подписать ни один CRL, как следствие, сертификат ЦС никогда не попадёт в CRL. Более того, даже если использовать различные утилиты (тот же certutil.exe), можно насильно включить сертификат ЦС в CRL, но это мало чем поможет. Дело в том, что конфигурация по умолчанию CryptoAPI даже не пытается проверить корневой сертификат на отзыв.
Проблема отзыва корневых сертификатов во многих случаях будет одним из решающих факторов в выборе подходящей для компании иерархии ЦС. А также будет диктовать дополнительные меры безопасности для корневых ЦС, чтобы предельно снизить риск компрометации корневого ЦС.
Типовые схемы развёртывания иерархии PKI
В этом разделе мы рассмотрим типовые (или классические) схемы развёртывания иерархии PKI в условиях предприятия и проводятся оценки каждой схемы и рекомендации. Следует отметить, что ни одна из них не является универсальной, и каждая может иметь смысл в своих пределах.
Одноуровневая иерархия
Одноуровневая иерархия является самой простой в реализации и имеет следующий вид:
Такая иерархия является самой простой и экономичной как по ресурсам (лицензиям), так и по расходам на обслуживание и управление. Достаточно развернуть один такой ЦС в лесу Active Directory, и он будет обеспечивать сертификатами всех потребителей. Из неочевидных, но немаловажных достоинств можно отметить очень короткую цепочку сертификатов. Т.е. время на проверку доверенности и отзыва сертификата будет тратиться гораздо меньше, чем в любых других иерархиях.
Однако одноуровневая иерархия обладает рядом достаточно существенных недостатков. Самый крупный из них – низкий уровень безопасности. Поскольку ЦС в такой схеме должен быть постоянно включенным в сеть, чтобы клиенты могли запрашивать сертификаты, значительно увеличивается риск его компрометации. Последствия компрометации могут быть чудовищными, вплоть до полной потери контроля над Active Directory и краху ИТ систем. Это может быть вызвано как недостаточными мерами безопасности, наличием не закрытых уязвимостей ОС или компонентах системы, которые позволяют удалённое исполнение кода и т.д. Как отмечалось выше, отозвать нормальным способом такой сертификат уже нельзя, и последствия будут действительно тяжёлыми.
Другой момент связан с гибкостью разделения ЦС на функциональные уровни (делегирование). Например, невозможно организовать несколько различных политик выдачи, разделить на классы (например, один ЦС издаёт сертификаты только машинам и устройствам, другой только для пользователей) и т.д., потому что он всего один.
Недостатки одноуровневой иерархии заметно перевешивают её преимущества в лёгкости и компактности. Именно поэтому такая конфигурация имеет смысл лишь в каких-то небольших и изолированных сетях с низкими требованиями по безопасности. Например, это может быть какая-то тестовая среда. В бизнес-среде такое решение использовать не рекомендуется.
Двухуровневая иерархия
Двухуровневая иерархия уже подразумевает как минимум два ЦС в дереве, в котором один строго корневой, а остальные — подчинённые. Схема такой иерархии представлена ниже:
Примечание: здесь пунктирными линиями отмечен ручной (неавтоматизированный) процесс получения сертификата. Сплошными линиями отмечен автоматизированный процесс получения сертификатов.
В двухуровневой иерархии уже возможно решить недостатки одноуровневой иерархии. Здесь корневой ЦС выпускает сертификаты только для подчинённых ЦС, а уже подчинённый ЦС выдаёт сертификаты конечным потребителям. Поскольку издающие ЦС развёртываются не так часто, и срок их действия достаточного велик, это позволяет изолировать корневой ЦС от сети. Это автоматически сводит к нулю шанс компрометации такого ЦС, поскольку без сети к нему не добраться. Более того, основное время жизни он может (и должен) проводить в выключенном состоянии. Включать его нужно только для обновления собственного сертификата, подчинённого ЦС или для публикации нового CRL. В остальное время он никому не нужен.
Другим достоинством двухуровневой иерархии является улучшенная гибкость в разбиении подчинённых ЦС на какие-то классы. Тот же типичный сценарий, когда два ЦС управляются разными подразделениями ИТ, и каждый ЦС выпускает сертификаты для своих групп потребителей. Например, для машин отдельно, для пользователей отдельно. Можно для корпоративных разработчиков (которые обычно живут в своих средах) выделить свой подчинённый ЦС.
Именно здесь уже можно начинать задумываться о разделении ЦС по политикам выдачи (или классам). Например, можно выделить один ЦС для выдачи сертификатов с повышенными требованиями к сертификатам (например, сертификаты для аутентификации и цифровой подписи) и ЦС общего назначения. Управлять ими могут различные команды ИТ-администраторов. При этом каждый подчинённый ЦС будет совмещать задачи ЦС политики и издающего ЦС. Это вполне допустимо, если предположить, что количество ЦС на каждый класс не более одного.
Из недостатков можно выделить лишь некоторое увеличение как административных, так и финансовых издержек (требуется дополнительная лицензия). К административным издержкам добавятся контроль за сроком действия каждого ЦС и списка отзыва корневого ЦС, а также их своевременное обновление. Кроме того, несколько увеличится время построения и проверки цепочек сертификатов, поскольку добавляется ещё один уровень. На практике это время практически не ощутимо.
Для небольших и средних предприятий такая схема является наиболее оптимальной, поскольку она позволяет обеспечить должный уровень безопасности и приемлемый уровень гибкости разделения ЦС на определённые функции.
Трёх- и более уровневые иерархии
В более крупных компаниях со сложной организацией сетей может случиться, что двухуровневая иерархия не может обеспечить необходимый уровень гибкости управления ЦС. Например, когда компания использует географический принцип разделения с относительной автономией ИТ отделов в каждом регионе. Представьте международную компанию с региональными офисами в разных странах. В них может действовать своё законодательство в вопросах безопасности, например, при обработке персональных данных. Для соблюдения подобных юридических формальностей на каждый такой регион выделяется свой собственный ЦС политик (при этом, размещается он, как правило, в головном офисе компании). В в своём сертификате он указывает поддержку (и ссылку на соответствующий документ) тех или иных нормативных документов и выпускает сертификаты для издающих ЦС, действующих в рамках тех политик, которые обозначены в сертификате (грубо говоря, в данном регионе).
В таких иерархиях корневой ЦС и ЦС политик изолируют от сети, а к сети уже подключаются только издающие ЦС:
Здесь также пунктиром отмечен ручной процесс получения сертификата для ЦС и сплошными линиями автоматизированный процесс получения сертификата для клиентов.
К плюсам такой схемы можно отнести гибкость полученной PKI с возможностью адаптации под практически любые условия. Правда, за это придётся платить. Во-первых, многоуровневые иерархии удорожают стоимость развёртывания и сопровождения PKI. Во-вторых, клиентам требуется больше времени на построение и проверки на отзыв полных цепочек сертификатов, что может вызывать отказы из-за превышения таймаутов верхних протоколов передачи данных. И на практике такие схемы зачастую являются избыточными. Поэтому при выборе подходящей иерархии ЦС следует искать баланс между гибкостью и практической целесообразностью с учётом капитальных и операционных затрат на содержание PKI.
В рамках этой серии статей рассматривается наиболее популярная (в большинстве случаев) двухуровневая иерархия.
