Данный текст – некоторые тезисы и наблюдения на тему реализации задачи безопасной IT-инфраструктуры страны.
Первый вариант его был написан ещё в фейсбуке в 2014 году, в одном из диалогов; после, по ситуации в Гонконге-2014/2016/2019 и Минске-2020, изучая возникающие инциденты с IT-сервисами, некоторые пункты дорабатывались.
Здесь делается акцент на конкретные меры и минимизирована повествовательная часть; всё это можно добавить, но пока нет смысла.
Большинство технических мер описываются кратко, потому что я мысленно добавлял к описанию “… потому что я это на курсах сто раз рассказывал, кто посещал/занимался, тот понимает, про что речь”.
В качестве примера реализации подобных решений на практике используется отсылка к опыту Китая – возможно в других государствах также есть интересные решения.
Оглавление
Чем не является эта статья
Данный текст не претендует на:
- Замену собой корпоративных/отраслевых/государственных стандартов и рекомендаций;
- Спасение от всех возможных проблем с перечисленными сервисами и системами в будущем;
- Оптимизацию качества и скорости работы перечисленных служб;
Задачей является лишь напоминание о возможных угрозах и методах значительного снижения и/или обнуления связанных с этим рисков. Угрозах не уровня “хакер-одиночка”, а “враждебный внешний сегмент Интернета”.
Для администраторов корпоративных инфраструктур здесь также найдётся информация для размышлений.
Задачи сетевой инфраструктуры
Сервисы синхронизации времени
Время – единственный невосполнимый ресурс, поэтому учёт его критически важен во всём, и в IT тоже.
Правильное и одинаковое время во всех используемых информационных системах нужно для множества задач, как минимум для
- Корректного журналирования происходящих событий
- Регулярного и своевременного выполнения задач автоматизированного тех.обслуживания
- Функционирования ряда протоколов безопасности (Kerberos)
- Работы инфраструктуры PKI
- Функционирования систем ограничения доступа к ресурсам и фильтров сетевого трафика, привязанных к времени обработки
Проблемы
Если время идёт неправильно, синхронизируется “урывками”, синхронизируется хаотично несколькими разными способами (допустим с физического хоста на виртуальный и параллельно с внешнего сервера точного времени), или всё отдано на самотёк и у разных узлов разная погрешность хода часов, то возможны смещения (leap), отложенные проблемы (у разных устройств время накапливает разную погрешность за один и тот же промежуток, пока не “разъедется” окончательно) и аномальное поведение всего вышеперечисленного.
Если сервисы синхронизации времени брошены на произвол судьбы и настройки по умолчанию, то возможны и другие негативные исходы, в частности умышленная отправка фальшивой информации о времени. Это может нарушить работу множества систем.
Решения
Поддерживаемый государством и находящийся в национальной доменной зоне пул NTP-серверов, действующая привязка к которому критична для прохождения аудита инфраструктур гос.предприятий, операторов связи и крупных социальных/финансовых интернет-проектов.
Необходимо отвязываться от всяких “свободных и открытых”, которыми по традиции называются принадлежащие гражданам США и действующие в законодательном поле США проекты, типа pool.ntp.org, и перекрывать на глобальном уровне запросы к распространённым на пользовательских устройствах сервисам типа time.windows.com.
Операторы связи, раздающие адреса конечным абонентам, должны не забывать выдавать им свои и подвязанные на гос.инфраструктуру сервера через штатные возможности того же протокола DHCP – в ряде случаев это поможет даже самым простым устройствам получить правильные настройки.
В настройках локальных серверов времени сети предприятия – в минимальном сценарии это пара самых редко уходящих в офлайн сетевых устройств, например коммутаторов – должны быть прописаны основные и резервные сервера времени, плюс установлен максимальный сдвиг времени из-за новой информации с сервера – чтобы исключить атаки вида “сервер резко поменял время, узел последовал, в результате инвалидация Kerberos-тикетов и проблемы с валидацией x.509v3-сертификатов”.
Всё это реализуемо на любом современном сетевом оборудовании, *nix-приложениях ntpd/chrony, ну а в случае Windows-инфраструктуры надо будет разве что учесть, что леса Active Directory в лице PDC у forest root domain синхронизируются индивидуально.
Для обеспечения надёжной работы клиентских систем, повторюсь, возможна замена на уровне оператора связи типовых и используемых по умолчанию в популярных ОС сервисов, типа упомянутого выше time.windows.com, на адреса своих и доверенных.
Ни у одного используемого приложения не должно быть прав влиять на системное время – иначе возможны атаки “Админы приложения Х или разработчики сделали закладку – ПО перевело системное время и посыпалась валидация сертификатов и другие связанные сервисы”.
Доступ до внешних NTP-сервисов должен быть заблокирован, штучные исключения “этому узлу корпоративной сети надо” должны иметь чёткое объяснение.
Сервис DNS
Сервисов и служб, нужных, чтобы превращать наименования сущностей в технические адреса разных подвидов и обратно, много – но в случае обсуждаемой ситуации, нас волнует то, что используется для связи со внешним миром – а это сервис DNS. Сервис этот разработан давно, в куда как более мирные и древние по технологиям времена, и на уровне стартового дизайна и логики работы несёт в себе кучу проблем.
Проблемы
DNS-трафик легко подделать – и придуманные даже весьма изощрённые методы защиты, типа DNSSEC, это никак не исправляют, потому что их используют мало, и, судя по динамике, всё меньше и меньше. Ведь “и так работает, зачем заморачиваться”.
Все осовремененные методы получения DNS-информации, типа DNS over HTTPS/TLS, решают лишь одну проблему – “чтобы локальный оператор связи не подглядывал куда вы ходите”, но создают другую, фактически, отдавая resolve доменных имён некоей зарубежной крупной фирме, типа Cloudflare или Google. Которой не составит никакого труда в определённый момент на запрос “что такое A-запись для rt.com”, пришедший из-под нужных IP-диапазонов, отдавать не адрес А, а адрес Б.
DNSSEC же, даже будучи правильно развёрнутым, даёт возможность глобально сделать невалидной всю зону .ru, сменив ключи. Все эти риски смехотворны в мирное время, но не сейчас.
Решения – по DNSSEC
DNSSEC нужно использовать, но всерьёз и с достаточно чёткими условиями, как то
- Ключи от национальной доменной зоны должны быть под контролем внутри страны, чтобы никакой ситуации “root domain отозвал TLD-домен .ru и оно автоматически побежало распространяться в пределах страны” не могло быть;
- Trust anchor’ы зоны должны быть в обязательном порядке распространены по DNS-серверам операторов связи, и все доменные зоны 2го+ уровня у важных сервисов – тех же Госуслуг – должны быть подписаны;
- Для национальной доменной зоны проверка должна быть по простой логике – если домен в ней и DNSSEC-информация по нему есть, то без неё ответ не принимается вообще. А не “опционально”.
- Все инфраструктуры важных организаций должны использовать только российские операторские сервисы DNS;
В таком случае подделать результат разрешения имён вида seriuosdomain.ru будет невозможно – .ru подписан, делегирование seriousdomain.ru с подписью, записи A/AAAA/прочие тоже, если нет – то результат отвергается на уровне кэширующих DNS-серверов корпоративной сети. Ключи домена .ru лежат на этих же кэширующих серверах локально, форсированный отзыв/замена невозможны.
Всё это, возможно, звучит страшно, но по факту настройки достаточно тривиальны, процедуры замены ключей единичны в масштабах лет, всё решает административный ресурс, но итог прост – никакими внешними силами подделать ответ на DNS-запрос важного домена не выйдет.
Решения – по стандартному DNS
Помимо этого, нужна жёсткая формализация работы обычного DNS. Операторы связи должны использовать источником информации для своих кэширующих DNS информацию не от любых root hints, а от тех, кто находится на территории страны и не-автоматически принимает обновления по нац.зоне.
То есть если в районе древнего датацентра около м.Калужская есть f.root-servers.net, то у него должен быть режим не полного безакцептного приёма обновлений, а выборочного по национальному домену, с ручным подтверждением важных изменений. И именно его используют для итеративных запросов про TLD DNS-сервера операторов связи, а не какой-то из root hints по личному выбору. А, соответственно, клиенты уже должны использовать сервера операторов связи.
Решения – по DNS поверх HTTP/TLS
Сервисы типа DNS over HTTPS/TLS имеют право на существование, но когда они подконтрольные – если человек, физическое лицо / абонент обычного оператора, хочет защититься от потенциального изучения его трафика кем-то, или проблем в формате MitM, то такие сервисы можно и нужно предоставлять – просто на площадках крупных локальных провайдеров интернет-услуг, того же Яндекса. Которые [крупные провайдеры] будут брать нужную для разрешения таких запросов информацию от локальных верифицированных источников, опять же исключая возможность подделки ответа на запрос. Чтобы ушёл риск “труба-то для DNS-запроса шифрованная, но на другом конце вражеский ресурс, злонамеренно подделывающий ответы”.
Вопрос о доступности таких сервисов, не подпадающих под регулирование законодательства страны, открытый – вполне возможно, что нужно перехватывать запросы к ним от новых браузеров и перенаправлять к себе. Потому что всё то, что пишется про “это свобода и безопасность, лично для тебя парень”, по факту оказывается передачей одной из критичных для работы рунета подсистем неким американским организациям, которые получают исчерпывающую информацию “кто, откуда, когда, что запрашивал” и возможность отправлять любые нужные им ответы.
Решения – по EDNS0
Отдельно надо заметить про необходимость корректной настройки EDNS0 и включения этого требования в списки нужного для прохождения аудита на пригодность инфраструктуры; существует специфическая возможность атаки, состоящая в том, что если у абонента не принимаются датаграммы увеличенного размера, то можно добавить к правильным ответам (в DNS-ответе приходит список записей, а не одна) много мусора, так, что это формально не будет прямой подделкой ответа и атакой, но принимающая сторона где-то по пути следования датаграммы потеряет пакет из-за несоответствия его “обычным” DNS-размерам.
EDNS0 должен быть настроен так, чтобы даже набитый несколькими десятками AAAA-записей и подписей к ним ответ проходил до конечного получателя внутри корпоративной сети.
Тривиальщину про то, что пользоваться зарубежными сервисами DNS-хостинга не надо, добавлять не буду – 2014-й год и то, как тот же GoDaddy просто забирал домены по критерию “Имеют отношение к Крыму” – которые он даже не хостил, а просто помогал приобретать, по сути договора, в 2011-2013 годах – помнят все. Те, кто не помнят, спрашивают сейчас “как так вышло, что у меня был домен .ua, я за него денег вносил, а он пропал”.
Государственный сервис для удобного размещения DNS-зон российских сервисов – типа бесплатного варианта у Cloudflare, простой и удобный в работе – также сослужит отличную службу.
Всё перечисленное, в комплексе, делает возможность как-то навредить снаружи этой инфраструктуре – в плане что перебоев в разрешении имён узлов в национальной доменной зоне, что технических проблем – минимальной, делая невозможными целые классы атак.
Маршрутизация и фильтрация трафика
Этот пункт по части внешних угроз, наверное, самый минимальный, но всё ж пропускать его не следует – мало ли что.
Проблемы
У многих организаций в плане маршрутизации и фильтрации всё просто – есть NAT наружу, внутри сети динамическая маршрутизация, есть какое-то edge-решение для фильтрации трафика. Всё по минимуму, требует околонулевых затрат на обслуживание и минимизирует необходимость документирования добавления новых сервисов и изменения конфигураций инфраструктурного оборудования для этого.
В результате возможен целый класс атак и проблем, когда что оператор начинает присылать что-то плохое, что внутри сети возникают нездоровые активности.
Решения
Нужно в обязательном порядке, исходя из допущения “по умолчанию, вероятно, всё разрешено, а значит надо явно убедиться что это не так”, отключать неиспользуемые технологии/методики изменения маршрутов трафика, от ICMP redirect’ов и Proxy ARP до обработки специфических IPv4 options и IPv6 Routing Header / Destination Options header. Везде, где это включено, должно быть обоснование “почему”, состоящее не из “на всякий случай” и “вроде работает и норм”.
Убедитесь, что фильтруете martian-трафик как положено, на входе в инфраструктуру. Чем быстрее вы отстрелите на входе то, что не нужно внутри сети, тем проще.
Надо фильтровать в режиме “белого списка” весь служебный multicast, т.е. разрешать только явно используемое, исключая возможность организации неизвестной мультикастовой группы хостами в корп.сети. Явно запрещать любые неиспользуемые/экзотические протоколы, могущие приводить к изменению логики обработки трафика – например в случае отсутствия оборудования Cisco это будут CGMP, FHRP, HSRP. Используемые – типа VRRP или PIM – разрешать только между узлами, которые могут участвовать в таких задачах, т.е. допустим SVI-интерфейсов у коммутаторов или контейнеров/VM, занятых в балансировке трафика.
Для динамической маршрутизации нужна обязательная фильтрация принимаемых апдейтов – как минимум базовая, когда “я никогда не принимаю снаружи новую информацию о своих внутренних сетях”. Если внутри корпоративной сети есть подсети 10.1/16, 10.2/16, 10.3/16, то их никогда нельзя принимать в анонсах от внешнего, сколь угодно доверенного источника. У больших федеральных структур такое должно быть на уровне сегментов – чтобы в случае несанкционированного доступа к одному региональному сегменту инфраструктуры он не мог бы “отравить” ложными апдейтами остальные. То есть например регион, в котором внутренние сети сидят в префиксе 10.1.128/18, не должен отдавать в backbone ничего про сети из других префиксов, и это отсекается принимающей стороной. Как в подлодке, с раздельно герметизируемыми отсеками.
Всем перечисленным обнуляется эффект от ряда атак вида “в персонале провайдера, к которому мы подключены, появился квалифицированный вредитель” и подобных им.
CDN для веб-ресурсов
Любой веб-сайт при загрузке подключает какое-то число внешних ресурсов. Это и JS-скрипты, и описание стилей в CSS, и подгружаемые шрифты, и всякие графические элементы оформления.
Ранее, при HTTP 1.x, их число было критичным, т.к. каждый ресурс = сессия, и с ними боролись, уменьшая количество любой ценой. Сейчас, когда практически всё что можно поддерживает HTTP/2 и HTTP/3, свою суть эта задача практически потеряла – выигрыш из значительного стал крайне небольшим.
Проблемы
Для скорости доступа подобные ресурсы хранятся на внешних CDN – это даёт возможно отдавать запрашиваемый ресурс быстро и максимально близко к запрашивающему клиенту.
Часть из описанного – JS-скрипты и шрифты – достаточно типизирована и в основном не-уникальна для конкретного сайта. Типовые JS-библиотеки, тот же jQuery, используются многими сайтами, та же ситуация со шрифтами.
Всё это может быть или отключено предполагаемым противником, исключительно в целях создания проблем доступности ресурсов и оттягивания ресурсов на спешную ликвидацию проблемы, или подменено на свои злонамеренные варианты. В случае JS-скриптов можно подсунуть клиенту целый зоопарк злонамеренного кода; в случае шрифтов тоже развлечься – по аналогии с Wingdings, заменить символы на небольшие картинки с нужным смыслом.
И даже не делая ничего из перечисленного можно просто заменить файлы на сильно гипертрофированные версии – допустим, в случае шрифтов добавив много избыточных символов, ну а в JS-файлы – неиспользуемые функции. Номинально ничего, определяемого строго как вредоносный код, поставщик сервиса клиенту не отдаёт, но фактически сильно замедляет доступ к ресурсам, ухудшая их доступность.
Решения
Необходимо принудительное размещение всех подобных ресурсов, относящихся к ПО, которое входит в нац.реестры, на контролируемых государством CDN. Контроль включает в себя расположение в национальной доменной зоне, физическое расположение у провайдеров, контролируемых гражданами/организациями РФ и без влияющих на решения лиц, имеющих гражданство других государств.
Использующие данные ресурсы страницы должны дополнительно, на уровне браузера клиента, усиливать безопасность используя заголовок Content Security Policy с явным указанием разрешённых для подгрузки JS доменов, плюс использовать проверку целостности загружаемого файла с указанием хэша, через стандартный атрибут integrity у тэга script.
Это должно быть критерием прохождения аудита для сертификации на возможность оказания услуги “помогаю государству поддерживать инфраструктуру, обеспечиваю комфорт потребителям”.
Пример – если ПО с названием Bitrix входит в реестр ПО, на котором можно делать инфраструктурные сайты в РФ, то используемые этим ПО типовые веб-ресурсы – тот же jQuery – должен лежать на CDN, FQDN у адреса которой в зоне .ru, физическое нахождение у российского провайдера, а провайдер этот – российское юрлицо и без директора, принесшего присягу/клятву другому государству. Это несложные условия – в Китае сделано именно так, всё лежит на серверах, ставящихся на площадках того же China Unicom, кэширующий сервер стоит буквально в каждой деревне. Именно поэтому, кстати, российские вебмастера страшно кричат, видя китайские сайты торговых площадок с ~150 подгружаемыми JS-ресурсами, мол “это безумие, оно ж тормозить будет дико”, а китайцы не понимают, зачем кричать – учитывая топологию национального китайского CDN-сервиса, любая бабушка в деревне с noname-планшета на совершенно простом процессоре может быстро открывать такие сайты.
Речь не идёт о том, чтобы все JS- и шрифты мира закэшировать внутри страны и посадить миллион человек вручную их обновлять – речь про то, что есть относительно малый процент широко используемых и ключевых для функционала критичных веб-ресурсов внешних библиотек, и надо обеспечить их гарантированную доступность и обнулить целый список рисков.
В случае КНР это отлично работает, в случае РФ мы имеем типовую ситуацию “всё в плане сайтов делается грошовыми аутсорсерами, которые делают всё копипастой из широко распространяемых примеров, где все JS лежат на каком-нибудь cloudflare, а шрифты грузятся с гугла”, уязвимую практически ко всему.
Плотность расположения узлов таких CDN должна определяться по формуле примерного вида “минимум у двух операторов связи во всех населённых пунктах с населением более N человек”.
Для упрощения доступности ресурсов из внешних сетей (т.е. лежащих в AS других государств) можно дублировать доступность тех же самых узлов по FQDN из интернациональных TLD (.com, .net) и автоматически, на фазе формирования страницы подставлять эти адреса в случае таких запросов. Это повысит доступность ресурсов при внешних обращениях (условно говоря в сценарии “На Госуслуги заходит гражданин РФ, проживающий в другом государстве”) и никак не снизит надёжность схемы / не добавит нагрузки на ресурсы.
Ситуация со счётчиками посещений или элементами активности в соц.сетях – кнопками репостов-лайков и подобными – должна регулироваться просто; сами по себе они не запрещены, но загружать из внешних источников JS-код нельзя. Крутитесь как хотите, но если вы крупный ресурс, сайт банка, гос.сервис – без такого встраивания. Люди скажут спасибо, всё будет быстрее грузиться и на стороне клиента браузер не будет за счёт тормозов и траты электричества клиента собирать информацию о том, куда на экране мышка поехала.
Всё это, применённое в сумме, сделает подавляющее большинство рисков вредительства нулевыми.
Сервис report-uri
Благодаря специальным HTTP-заголовкам веб-браузеры клиентов могут отчитываться о странном или некорректном поведении веб-ресурса, к которому они обращаются. Это нужная для раннего оповещения о проблемах информация.
Проблемы
Так-то сам по себе механизм Report-URI никакой угрозы не несёт. Но являясь штатным инструментом для того, чтобы клиентские устройства сами говорили о всяком типа “Я иду на сайт gosuslugi.ru, там должен быть прикреплённый сертификат с FQDN домена, цепочка промежуточных сертификатов, и OCSP-ответ про то, что сертификат валиден на определённый момент времени, а этого нет, хотя заявляется, что всё перечисленное должно присутствовать”, он нужен для диагностики различных проблем. Этот механизм позволяет оперативно получать намёки вида “Внутри корпоративной сети А или региона Б оператор связи, вероятно, начал подменять наш сайт www.что-то.ru на свой клон”, “кем-то выпущен сертификат про наш сайт, но в сервисе Certificate Transparency он не прописан, а должен быть прописан”, и подобном.
Решения
На ключевых гос.сайтах для security headers – как минимум Expect-CT, Expect-Staple, Content-Security-Policy, X-XSS-Protection, плюс у CAA-записей в DNS-зонах – в report-uri должен быть указан адрес контролируемой государством системы, которая будет принимать всё это и хранить.
Это снимет с админов ресурсов задачу “как это всё организовать”, уберёт риски “злонамеренный админ или аутсорсер специально чистит журналы уведомлений report-uri, чтобы мы не видели, что к нашему ресурсу пытаются подключаться клиенты, испытывающие проблемы” – потому что админ веб-сайта X, занимающийся контентом, не сможет влиять на устанавливаемые на веб-фронте HTTP-заголовки и на систему хранения (туда будет только добавляться, зайти и стереть всё за определённый промежуток времени нельзя), а также даст возможность оперативного мониторинга и реагирования на возникающие нештатные ситуации. Вплоть до уведомления по OOB-каналам, типа SMS или приложения гос.услуг “Внимание, вы подключаетесь из страны X, где зарегистрированы случаи попытки подмены сертификата нашего веб-сайта”.
Сейчас на этот механизм, ещё раз – встроенный в любой современный браузер и уже готовый к использованию – обращается минимум внимания, нужно всё это стандартизировать и применять.
Сервис геолокации
Сервисы геолокации нужны для того, чтобы по техническому адресу абонента определять, к какой стране (по названию, коду ISO из двух или трёх букв) и городу он относится. Чаще всего эта операция делается на frontend, просмотром базы в формате MMDB и добавлением в HTTP-запрос заголовков с нужными данными.
Проблемы
Очевидные – сервисы, предоставляющие геоинформацию в удобоваримом для добавления к nginx/apache виде, американские, и пишут свои, политически выверенные, данные. Эти данные надо вручную перебивать на лету, прописывая что такой-то населённый пункт относится к такой-то стране – и все это делают по-разному.
Эти сервисы ещё и обновляются в бесплатном варианте редко, а в платном – хоть и часто, но все равно как-то неправильно платить в США за ложную информацию о территориальной принадлежности городов и сёл.
Дополнительной проблемой является отсутствие стандартизации написания русскоязычных названий населённых пунктов – то есть существуют и используются базы, где Алчевск, ЛНР, пишется не только Alchevsk, Ukraine, но и Alchevs’k, Ukraine. С разной степенью украинизации суржика, так сказать.
Решения
Российский гос.сервис, который будет предоставлять актуализированную, правильную и по стандартам написания названий населённых пунктов, и по их принадлежности, информацию. В тех же стандартах, например MMDB, ну или простых выгрузках в CSV. Использование этой базы должно быть обязательным для госсервисов и финансовых/социальных систем/сетей/сайтов. Это снимет пачку мелких проблем что с админов, что с техподдержки. Использование других баз коммерческими сайтами может продолжаться – хотят произвольно относить Париж к Гондурасу – да никаких проблем, просто такого не должно быть у фин.организаций, гос.сайтов и соц.сетей.
Почтовые сервисы
Электронной почтой пользуются все, и мер по её защите – масса. Но мы не про абстрактную защиту в плане “вообще”, а конкретное противодействие определённому подмножеству враждебных действий.
Проблемы
Основная проблема почты – спам, но в нашем случае это ещё и несанкционированные блокировки почтовых сервисов. Так как все используют внешние blacklist’ы, то любой российский хост можно объявить “плохим” по внешней команде, игнорировать обращения в техподдержку и получить блокировку почты всеми, кто сидит на автоиспользовании таких сервисов. С 4 марта подобное замечено за spamcop и spamhaus.
Решения
Множество штатных и простых защитных мер не могут применяться из-за разгильдяйства администраторов, которые забивают на абсолютные азы безопасности – использование правильно составленных SPF-записей, DMARC, DKIM, прописывание MTS-STS. Хотя бы PTR научились делать, уже неплохо. Чтобы отсекать потоки заведомо поддельных спам-сообщений, абсолютно все гос.сервисы должны чётко формировать перечисленное, в основном SPF и MTS-STS, явно указывая адреса исходящих почтовых сервисов и блокируя несанкционированную отправку из своих сетей. Это даст возможность ужесточить правила по обработке почтовых сообщений, частично перейдя с “помечать как спам” на “отсекать”.
Нужен российский сервис RBL, который будет покрывать национальный домен и правила обработки, которые будут указывать, что при процессинге с адресов внутри РФ надо пользоваться им, и что в случае конфликта он имеет превосходство над другими в случае использования нескольких. Это отсечёт возможность вышеприведённой атаки, которая делается при желании по аналогии с соцсетями, тупо массовой жалобой ботами.
Инфраструктура открытых ключей, ИОК/PKI
Для меня лично этот раздел самый главный, т.к. я работал в фирме, которая должна была стать российским Verisign. Было это в 2000 году, стартап назывался НП НДЦ – Некоммерческое партнёрство Национальный Доверительный Центр, руководила проектом Галина Стародубцева, и мы реально прорабатывали всероссийский удостоверяющий центр с сервисами как для корпоративных клиентов, так и для физ.лиц – для верифицированной электронной почты, например. К сожалению, всё сорвалось буквально на старте – Галина погибла в автоаварии, а так как она была основным corporate sponsor и вхожим в высшие круги власти человеком, тема закрылась.
PKI – сверхважная в плане безопасности тема, дающая огромное число механизмов влияния на ситуацию. И огромное число проблем.
Проблемы
Сейчас использование корпоративных PKI на минимуме. Всё решается через внешние сервисы или с выдаваемым прямо самим сервисом сертификатом (тот же Cloudflare), или с покупным (ну, кто ещё использует EV-сертификаты как особо статусные), или со свободно распространяемым (Let’s Encrypt). Внутрикорпоративных рабочих PKI очень мало, т.к. задача их корректного развёртывания массово считается сложной и неинтересной.
То есть вообще всё отдано наружу.
Любая из перечисленных фирм может, используя штатные возможности PKI, отозвать ваш сертификат в любой момент, ну или просто перестать вам их выдавать. Может выдать, используя всю предоставленную вами информацию, клон такого же сертификата, но другому абоненту. Может сделать это как публично, так и незаметно – если вы отдаёте генерацию ключей полностью на них, то они могут кому угодно сделать любой сертификат на “вашей” ключевой паре. Так как системы, обеспечивающие certificate transparency, тоже у США, то выход нового сертификата про ваш домен могут вам и не показать, но зато добавить его в CT, чтобы современные браузеры убедились, что именно этот сертификат валидный и правильный.
Некоторые – типа let’s encrypt – пошли ещё дальше и, например, генерят вам ещё и биты для DH – посмотрите в /etc/letsencrypt файл ssl-dhparams.pem, то есть делают стартовую совместную генерацию ключевого материала предсказуемой, а следовательно всю защиту сессии бессмысленной.
Вас в любой момент могут стереть и включить ваш PKI-клон – с валидным сертификатом от того же сервиса и полным комплектом информации в сервисах-валидаторах.
Решения
Гос.сервис корневых CA необходимо усилить в плане масштабов использования, плюс создать аналог сервиса Let’s Encrypt, но находящийся не под влиянием “некоммерческой организации FSF”, а по факту – США.
Корневые сертификаты CA РФ должны добавляться в хранилища у всех допущенных к использованию ОС, включая мобильные, и быть равноправными с другими корневыми сертификатами. Сейчас у ряда систем при добавлении любого root ca, кроме указанных в списке, выводится предупреждение о потенциальных проблемах безопасности – российские CA должны быть одноранговыми с CA других стран, иначе софт конкретной компании использоваться не может. Это касается и мобильных ОС.
Необходим также механизм ответственности, в котором будет чётко прописано, что ни один корневой сертификат с кодом страны RU не может быть добавлен через любой механизм обновлений, потому что нужно отсечь вариант “вендору из США приказали и он выпустил новый самоподписанный сертификат российского root CA, совпадающий добуквенно во всех полях с имеющимся, но с другой ключевой парой”.
В гос.приложениях желательно добавить доп.проверку класса certificate pinning, чтобы при ситуации “устанавливаем средствами ОС защищённое соединение” дополнительно проверялся хэш открытого ключа в сертификате, и если это сертификат российского CA – дополнительно, отдельным запросом самого приложения, уточнялось, настоящий ли это сертификат.
Для распространённых браузеров нужны плагины, которые будут регулярно проверять список корневых и прочих доверенных CA в браузере и добавлять/обновлять российские, плюс сообщать о ситуации появления неизвестных “российских”, полученных браузером через свой сервис обновлений.
Необходим аналог сервиса Let’s Encrypt, но находящийся под контролем государства – плюс свои, локальные списки certificate transparency.
Все FQDN у CRL/AIA, включая OCSP, должны быть в национальной доменной зоне и данные сервисы должны быть распределены по национальной CDN для максимизации скорости установки защищённых соединений.
На гос.сервис выдачи сертификатов для веб-сайтов должны явно указывать CAA-записи в доменных зонах, и ни на какой другой – чтобы сразу отсекать вариант “вражеский сервис выпустил валидный сертификат про наш домен” как минимум превращая его в “клиентские устройства сразу же вскинулись и начали писать про это на report-uri”.
Для сетевых узлов должен быть предусмотрен вариант получения сертификата, привязанного к FQDN, через протокол NDES – вида “в личном кабинете владельца домена что-то.ру можно у конкретной записи поставить пометку, что из-под этого A/AAAA адреса разрешены NDES-запросы на получение сертификата данного FQDN”.
И убедитесь в том, что базис криптографии – случайные числа, создаваемые на вашей системе – действительно случайны.
Список дополняется – корректировки, предложения, мнения, приветствуются.
