«Группа Астра» и компания «Аладдин» объявили о стратегическом партнёрстве по созданию защищённой доверенной инфраструктуры для импортозамещения. Её ключевым элементом станет центр сертификации открытых ключей, обеспечивающий доверенное взаимодействие устройств в сети.
- 1. Введение
- 2. Угроза применения «рубильника»
- 3. Доверие к УЦ: где возникает риск компрометации
- 4. Примеры компрометации цифровых сертификатов
- 5. Сервис PKI в Astra Server Core
- 6. Рекомендации по выстраиванию инфраструктуры открытых ключей
- 7. Выводы
Введение
В начале июня «Группа Астра» и компания «Аладдин» объявили о подписании соглашения о стратегическом партнёрстве и выпуске нового продукта в этом статусе — комплексного решения Astra Server Core на базе ОС Astra Linux Server, дополненного средствами ALD Pro и менеджером конфигураций ACM, который теперь усилен внедрением средств корпоративного центра сертификации Aladdin Enterprise CA (eCA).
Используя этот базовый фундамент, заказчики получают в поддержку своей корпоративной инфраструктуры связный технологический стек, во многом похожий по своей архитектуре на привычные решения Microsoft. После прекращения технической поддержки продуктов американского вендора на территории России необходимое доверие к его центрам сертификации было утрачено. Это создаёт повышенные риски для безопасности, поскольку центры сертификации являются, по сути, «рубильником» для поддержки работоспособности сети. В случае прекращения действия выданных сертификатов сеть перестаёт работать.
Стратегическое партнёрство «Группы Астра» и «Аладдин» восстанавливает утраченный стандарт для построения безопасной и доверенной ИТ-инфраструктуры. Теперь средства безопасности интегрированы в базовую архитектуру и являются основой для реализации подхода Secure by Design. Прямо «из коробки» заказчики получают набор сертифицированных инструментов, позволяющих самостоятельно развивать безопасную инфраструктуру с учётом своих прикладных задач.
Рисунок 1. А. Фоменко («Группа Астра») и С. Груздев («Аладдин») объявили о стратегическом партнёрстве
Угроза применения «рубильника»
Выступая на пресс-конференции, Алексей Фоменко, директор серверного ПО «Группы Астра», выделил несколько важных признаков партнёрства: «Объединяя нашу серверную платформу с лучшими PKI-компетенциями, мы создаём продукт, который рынок ждал со времени ухода Microsoft. Это безопасная инфраструктура, где управление пользователями, устройствами и сертификатами работает как единый организм».
Новое комплексное решение Astra Server Core призвано решить задачу выбора платформы для миграции с платформы Microsoft. Заказчики смогут сохранить функциональные возможности Astra Linux Server в прежнем объёме, получая в дополнение к ним полноценный механизм выдачи сертификатов, позволяющий реализовать на уровне сети принцип доверия и безопасности с использованием открытых ключей.
На тесную интеграцию указывает дополнение этой базовой конфигурации средствами поддержки службы каталога ALD Pro (аналог MS AD) и менеджера конфигураций ACM (Astra Configuration Manager, аналог Microsoft System Center) для инвентаризации и управления установкой ПО на рабочих местах и серверах. Аналогичный технологический стек заказчики получали раньше вместе с корпоративной платформой Microsoft, поэтому, переходя в рамках импортозамещения на российскую платформу, они были заинтересованы получить равноценную замену и привычный набор инструментов.
Но востребованность такой платформы объясняется не только требованиями регулятора. Как отметил Сергей Груздев, генеральный директор «Аладдин», прекращение технической поддержки Microsoft своих продуктов для российских заказчиков создаёт для них, в том числе, повышенный риск прекращения выдачи сертификатов её центрами сертификации (CA). В случае прекращения их выдачи или валидации этот механизм может сработать как «рубильник». Это способно породить хаос в работе российских корпоративных систем. Учитывая, что невозможно единовременно перейти на другие центры сертификации для всего парка установленного ПО, последствия могут оказаться катастрофическими.
Отметим, что из-за падения доверия к механизму выдачи сертификатов УЦ Microsoft для российских компаний серьёзно возросли риски кибератак, связанные с преднамеренной компрометацией ключей. Может возникнуть также прекращение проверки валидности предъявляемых сертификатов. В этом случае формально корпоративные системы продолжат свою работу, но их безопасность сразу станет проблематичной. Устранить проблему на стороне пользователей невозможно, поскольку валидацию проводит центр сертификации, поэтому к нему всегда предъявляются повышенные требования доверия.
Реальность подобного сценария подтверждают практические примеры. Например, можно вспомнить инцидент, произошедший в сентябре 2006 года. Тогда на стороне УЦ была непреднамеренно внесена ошибка в код генератора случайных чисел. После официального релиза новой версии в апреле 2007 года все закрытые ключи, сгенерированные в уязвимых системах Debian, оказались небезопасными. Проблема была выявлена не сразу, а спустя некоторое время.
Рисунок 2. Статистика компрометаций CA за 2011 год (Paolo Passeri, hackmageddon.com)
Доверие к УЦ: где возникает риск компрометации
Выбор центра сертификации всегда подразумевает, что доверие к нему подтверждено. Однако возникает вопрос: как формируется доверие? Широкое распространение Windows приучило многих к доверию к УЦ Microsoft; доверие к вендорам применяемых средств безопасности, таким как Symantec, в дальнейшем переносилось на поддерживаемые ими центры сертификации. Но было ли такое доверие оправдано? Ответ мы дадим немного позже.
Отметим, что само понятие «доверия» часто также интерпретируется недостаточно точно. Например, некоторые центры, выдавая идентификационные сертификаты, могут обходить стороной вопрос об отсутствии у них полномочий на делегирование своих функций авторизации дочерним компаниям. Формально любой выпускающий центр может присвоить себе «понравившееся» имя. В результате риски перекладываются на процедуру проверки идентификационного сертификата, а это уже технический вопрос, а не только ограниченный визуальным контролем его идентификационных данных.
В реальности же клиент, получая идентификационный сертификат, фактически контролирует визуально только информацию об имени владельца ключа. Поэтому его доверие сужается до доверия к этому имени.
Можно ли пользоваться сейчас доверием в таком объёме?
События последних лет показали, что риски, связанные с компрометацией доверия, ранее рассматривались в основном в отношении групп враждебных хакеров. Теперь вмешалась геополитика, хотя «предупреждения» об этом возникали и раньше. Их примеры мы приведём далее. Затем рассмотрим риски, возникающие при эксплуатации инфраструктуры открытых ключей.
Примеры компрометации цифровых сертификатов
Технология применения цифровых сертификатов развивается уже более 20 лет. Встречались ли случаи компрометации?
Назовём несколько инцидентов. Они произошли достаточно давно, но являются достаточно характерными, чтобы обратить на них внимание.
DigiNotar (2011)
DigiNotar — это голландский центр сертификации, открытый в 1998 году. Он подвергся полной компрометации, выразившейся в выпуске более 500 мошеннических сертификатов, включая поддельные сертификаты для доменов Google. Нарушение оказалось настолько серьёзным, что привело к банкротству компании.
Признаки произошедшей кибератаки были обнаружены в Иране. Оказалось, что некоторые пользователи там потеряли возможность авторизации в своих учётных записях Gmail. Анализ инцидента привёл к предположению, что атакующие были предположительно связаны с иранским правительством, а кибератака была осуществлена с целью дальнейшего проведения масштабных MITM-кибератак («человек посередине») против иранских граждан.
Для ИТ-отрасли данный инцидент стал поводом серьёзно пересмотреть набор требований, предъявляемых к компаниям — центрам сертификации. Изменённые правила появились в 2015 году.
Но были и другие важные последствия. Например, значительное сокращение количества действующих центров сертификации в мире. Теперь к ним стали предъявлять повышенные требования к авторизации.
Происходящие ныне изменения в геополитике — это уже вторая волна пересмотра этих правил. С одной стороны, наблюдается явное противодействие законной авторизации российских центров сертификации в глобальной системе. Но, кроме этого, возникают и другие серьёзные противоречия. Прежде всего они касаются стремления стран к развитию собственной технологической независимости на фоне обострения геополитических разногласий. Это касается не только России: аналогичные процессы наблюдаются в странах ЕС, в странах Африки и т. д. Это мировой процесс. Однако даже в этих условиях необходимо каким-то законным образом решать возникающие противоречия.
Comodo (2011)
15 марта 2011 года один из крупнейших в мире центров сертификации Comodo сообщил о взломе одного из своих центров регистрации (RA) — они уполномочены проверять и выдавать SSL-сертификаты от имени Comodo.
В результате успешно проведённой (предположительно иранским хакером) кибератаки была осуществлена выдача девяти SSL-сертификатов в мошеннических целях для крупных интернет-доменов. В их число попали: mail.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org и login.live.com (Microsoft).
Как показало расследование, выданные таким образом мошеннические SSL-сертификаты для mail.google.com могли позволить злоумышленнику осуществить перехват сетевого трафика Gmail и реализацию MITM-атаки («человек посередине») в случае успешного подбора DNS-адресов. Таким образом возникла опасность перехвата электронных писем, паролей и вложений, тогда как у жертвы продолжал отображаться в браузере значок доверенного подключения.
Рисунок 3. Процедура handshake при MITM-атаке
Позднее «объявился» и сам хакер. Он заявил, что ему 21 год и ранее именно он осуществил атаку на DigiNotar, действуя из патриотических побуждений.
Со слов хакера, он собирался установить слежку за перепиской иранских диссидентов. При планировании своей кибератаки он опирался на то, как в 2009 году китайские хакеры сумели реализовать серию кибератак (Operation Aurora) на ряд компаний.
То, что это не было фейком, стало ясно, когда в качестве атакованных целей публично подтвердили себя такие компании, как Adobe Systems, Akamai Technologies, Juniper Networks и Rackspace. Без публичного подтверждения остались кибератаки на Yahoo, Symantec, Northrop Grumman, Morgan Stanley и Dow Chemical, хотя они также вошли в список названных целей.
Рисунок 4. Информация по сертификату Adobe, скомпрометированному в УЦ Comodo
TurkTrust (2011)
В конце декабря 2013 года в Chrome был обнаружен неавторизованный цифровой сертификат на домен *.google.com. После немедленно последовавшего расследования выяснилось, что поддельный сертификат был выдан через ветвь, относящуюся к турецкому центру сертификации TurkTrust.
Предоставив необходимую информацию эмитенту, от него был получен ответ: в результате внутреннего расследования выявлены два ошибочно выданных сертификата-заготовки. Они позволяли их обладателям эмитировать готовые сертификаты для любого веб-сайта, «за которые злоумышленник мог пожелать выдать себя».
Согласно предупреждениям, разосланным Microsoft и Google, поддельные цифровые сертификаты, выданные турецким центром сертификации TurkTrust, могли находиться в обращении с августа 2011 года и быть использованы для MITM-кибератак на ресурсы Google. Microsoft заявила о наличии в компании доказательств реализации попыток проведения подобных атак, но о том, были ли они успешными или нет, не сообщалось.
WoSign и StartCom (2015–2016)
Расследуя серию странных совпадений и нелогичных сочетаний среди значений полей в выданных сертификатах, исследователи Mozilla выявили их общую принадлежность — китайский центр сертификации WoSign. Расследование проводилось на фоне ряда произошедших и потенциальных инцидентов, для которых исследователи искали причину.
Оказалось, что некоторые из изменений в полях сертификатов появились, по мнению исследователей Mozilla, не по вине WoSign. В качестве возможной причины назывался выявленный случай временного захвата домена, на который был выдан сертификат. Другие ошибки, допущенные уже со стороны WoSign, были отнесены к типу очень серьёзных, поскольку они позволяли, например, включать непроверенные доменные имена в сертификаты.
После раскрытия нехарактерных паттернов при генерации сертификатов были выявлены многочисленные обманные действия, которые были совершены сотрудниками центра. Например, они допускали ретроспективную выдачу сертификатов для обхода выпущенных позднее требований по безопасности или иногда применяли неадекватные методы проверки сертификатов.
В результате было принято решение о полном недоверии к сертификатам этого центра со стороны крупных браузеров.
Symantec (2015–2017)
Для начала скажем, что ряд крупных в мире компаний имеет в своём составе группы исследователей, которые заняты тестированием сертификатов, выдаваемых на домены, принадлежащие их компанию. Таким образом ведётся контроль за их достоверностью.
Подобные исследования проводились в Google в 2015 и 2016 годах. Именно там обнаружили некорректную выдачу тысяч сертификатов, включая несанкционированные тестовые сертификаты для доменов типа google.com. Их выдачей занимались УЦ Symantec, а ошибки произошли вследствие особенностей выстроенной там инфраструктуры.
В частности, расследование в Google выявило системные проблемы: неадекватный аудит субцентров сертификации Symantec (включая южнокорейского партнёра CrossCert), выдачу сертификатов с более ранней датой, нечёткое соблюдение базовых отраслевых требований.
В сентябре 2017 года Google объявила о постепенном отказе Chrome от доверия к любым сертификатам, выданным Symantec. Её примеру последовали затем Mozilla, Apple и Microsoft.
Инициированное недоверие в адрес Symantec привело к крупнейшей миграции сертификатов в истории интернета. Ее масштабы отражает факт, что до начала периода «охлаждения» дочерние компании Symantec (VeriSign, Thawte, GeoTrust, RapidSSL) в совокупности занимали наибольшую долю рынка центров сертификации — по оценкам, на них приходилось от 30 % до 40 % всех HTTPS-сертификатов.
Основными причинами сбоев в центрах сертификации Symantec были признаны следующие: некачественная практика обеспечения безопасности; неправильная конфигурация, чрезмерное доверие к сторонним реселлерам без надлежащих проверок; фундаментальное несоблюдение отраслевых правил.
Тем не менее, система работы УЦ Symantec продолжает существовать в значительной степени без изменений и до сих пор.
Сервис PKI в Astra Server Core
Но вернёмся к анонсу комплексного решения Astra Server Core.
Выступая на пресс-конференции, Сергей Груздев, генеральный директор «Аладдин», следующим образом прокомментировал появление встроенной поддержки сервиса PKI внутри ОС Astra Linux Server:
«Чтобы доверие и безопасность стали фундаментом, а не надстройкой, они должны быть „вшиты“ в системное и инфраструктурное ПО, а проектирование новой ИТ-инфраструктуры должно начинаться с правильной безопасной архитектуры».
В свою очередь Алексей Фоменко, директор серверного ПО «Группы Астра», отметил:
«У компании „Аладдин“ самая глубокая экспертиза в этой области и самый полный портфель продуктов. Это избавляет заказчиков от необходимости самостоятельно собирать доверенную архитектуру „по кусочкам“, а затем сталкиваться с рассинхронизированностью компонентов на протяжении жизненного цикла системы».
Комплексное решение Astra Server Core позволяет решить задачу выдачи сертификатов при построении корпоративной инфраструктуры. Ранее мы показали, почему дополнение этим сервисом базовой ОС Astra Linux Server является настолько важным.
Рекомендации по выстраиванию инфраструктуры открытых ключей
Применение сертификационных ключей несёт определённые риски само по себе, как и любой бизнес-процесс. Поэтому в завершение обратим внимание на то, где могут возникать проблемы при эксплуатации подобной инфраструктуры.
Надёжная физическая защита места хранения закрытого ключа
Основной риск для любой системы, основанной на применении центров сертификации, связан с необходимостью обеспечить недоступность закрытого ключа. В любой прикладной конфигурации важно обеспечить защищённость этого ресурса.
Как показывает практика, во многих защищённых вычислительных системах не налажен жёсткий контроль за физическим доступом, защитой от «прослушки» трафика, отсутствует «воздушный барьер» для обеспечения сетевой безопасности. Нередко закрытый ключ хранится на обычном компьютере, который может быть подвержен вирусным атакам или вредоносному вторжению.
С юридической стороны вся ответственность за сохранность закрытого ключа и любые совершаемые с его применением действия лежит на пользователе. Поэтому владелец платформы PKI рискует только своим доверием. Но разве этого мало?
Рисунок 5. Пример содержимого частного ключа
Защита проверяющего компьютера
В процедуре проверки сертификатов секретный ключ не используется, в ней достаточно применения только открытых ключей. Поэтому формально необходимости в установке дополнительной защиты нет.
Однако в конфигурации проверяющего компьютера всегда используется один или несколько «корневых» открытых ключей. Если злоумышленнику удастся заранее добавить в этот список собственный открытый ключ, то, выпустив свои сертификаты, он сможет ввести их в процесс проверки, и они будут рассматриваться как легитимные.
Хотя содержимое открытого ключа злоумышленника всегда будет отличаться от легитимного, скомпрометированные сертификаты могут совпадать с легитимными по внешним параметрам (описанию). Поэтому проверка сертификатов должна осуществляться только в доверенной компьютерной системе. Также должна присутствовать гарантия достоверной неуязвимости её инфраструктуры в отношении проникновения вредоносного кода или физического вмешательства.
Кто подписал сертификат
Обычно принадлежность сертификатов открытого ключа проверяют по имени. Но это всего лишь текстовая строка, за которой стоит название центра сертификации. Можно ли доверять только этим названиям?
С технической точки зрения имя сертификата дополнено другой информацией. Именно там отражена уникальность. Но если проверка проводится вручную, то легко ошибиться.
Например, в 2025 году эксперты компании Trend Micro выявили масштабную хакерскую активность, связанную с подделкой цифровых сертификатов и выстраиванием специальной инфраструктуры, которая скрытно действовала в течение 47 дней.
В результате расследования удалось выявить 2278 уникальных частных ключей, 169 из которых являлись ключами доступа к SSH-серверам и были защищены паролем. 88 частных ключей использовались для защиты передачи данных через SSH-сервер без парольной защиты. Кража ключей осуществлялась через скриншот ответа, выдаваемого на команду его просмотра, где отображалось значение частного ключа.
В результате такой кибератаки были выявлены 88 SSH-серверов, транзакции с которых были доступны злоумышленникам; для других 169 серверов данные могли быть украдены, если злоумышленникам удалось подобрать пароль.
Рисунок 6. Схема атаки с подделкой цифровых сертификатов, выявленная Trend Micro в 2025 году
Уровень авторитетности центра сертификации
На первый взгляд, очевидно: если центр сертификации уполномочен выдавать сертификаты, значит, ему доверяют. Но является ли такое доверие полным?
Например, с точки зрения ИБ в SSL-сертификате интересны два элемента: имя владельца ключа (обычно это название компании) и DNS-имя сервера. За назначение DNS-имени отвечают уполномоченные органы, но их упоминание отсутствует в списке сертификатов, например, тех, которые выбраны по умолчанию в браузере.
Подобная система доверия построена на том, что пользователю фактически предписано доверять тому, что сертифицирующий центр указал достоверное DNS-имя в выданном сертификате.
Пользователь сертификатов и система безопасности
С формальной точки зрения сертификат, выданный веб-серверу, служит гарантией достоверности его владельца. Но фактически центр сертификации никак не проверяет контент сервера, которому выдаёт сертификат. Средствами SSL нельзя контролировать содержимое веб-страниц и реагировать на случаи компрометации. Проверке подлежит только DNS-адрес.
Владелец сертификата фактически не является частью системы безопасности. Если сервер начинает осуществлять мошеннические действия, то со стороны системы сертификации нет возможности реагировать на это и предупредить пользователей.
Центры сертификации и регистрационные центры
Принято считать, что процесс выдачи ключей ограничивается участием только центров сертификации. Но в реальности процесс нередко выстроен по более сложной схеме.
В систему вводятся также центры регистрации (Registration Authority, RA), на которые возлагается функция проверки запросов (валидация и аутентификация пользователей); затем эта информация передаётся центру сертификации.
Несмотря на то, что рабочий процесс становится более эффективным, модель RA+CA является менее безопасной, чем однокомпонентная модель CA. Возникает риск внесения изменений в содержимое сертификата, при этом пользователь не будет оповещён об этом.
Рисунок 7. Пример кода, восстановленного из Dockerfile, по копированию скриншота для кражи данных
Доверие к центру сертификации
Прежде чем выдать информацию, центр сертификации должен идентифицировать заявителя: серверу необходимо удостовериться в наличии закрытого ключа. Доверие к УЦ должно быть высоким, прежде всего в отношении того, как собранная информация может быть использована.
Безопасность методов сертификации
Полученный ключ обладает сроком службы. Существует определённый регламент для замены ключей в случае обнаружения их компрометации.
Назначаемый срок службы ключа может быть использован злоумышленниками, поскольку отзыв ключа — это определённая процедура, которая должна находиться под контролем ИБ.
Выводы
В этой статье было рассказано о дополнении комплексного решения Astra Server Core поддержкой средств корпоративного центра сертификации Aladdin Enterprise CA (eCA). На первый взгляд, это чисто техническая особенность. Но достигнутое стратегическое партнёрство между «Группой Астра» и компанией «Аладдин» можно оценить значительно выше, если принять во внимание, зачем в корпоративной инфраструктуре применяется механизм PKI и какие риски могут возникать в случае компрометации подобного механизма при использовании внешних УЦ без должного доверия к ним.
