Привет, Хабр! У этой статьи два автора. Я – Олег Ассур, технический директор SafeMobile, мы делаем систему управления мобильными устройствами (MDM). Мой соавтор – Евгений Швалёв @eshvalev, владелец продукта SafeTech CA в компании SafeTech Lab, которая делает корпоративный центр сертификации.

Повод такой. Российские компании уходят с Microsoft Certificate Authority: продажи и поддержка Microsoft в России прекращены, а Microsoft CA до сих пор стоит в большинстве компаний с собственной PKI. При переезде на новый центр сертификации быстро выясняется, что сертификаты живут не только на серверах и ноутбуках, но и на телефонах, которые по ним ходят в корпоративный Wi-Fi, VPN и почту. Чтобы телефоны переезд пережили, мы интегрировали SafeMobile с SafeTech CA. А заодно решили один раз и письменно ответить на вопросы, которые нам задают чаще всего.

В статье три части:

• зачем телефону сертификат, если есть пароль и одноразовые коды (OTP);

• как SafeMobile выпускает сертификаты так, чтобы приватный ключ оставался на устройстве;

• как SafeTech CA закрывает задачи, с которыми Microsoft CA уже не справляется.

Добро пожаловать под кат.

Зачем телефону сертификат, если есть пароль

Олег Ассур, SafeMobile

У сотрудника уже есть доменная учётка, одноразовые коды в приложении и биометрия на телефоне. Зачем городить ещё и инфраструктуру открытых ключей (Public Key Infrastructure, она же PKI)? Затем, что пароль и OTP подтверждают человека, а во многих сценариях нужно подтвердить устройство, причём без участия человека.

Wi-Fi, VPN и почта

Корпоративный Wi-Fi пускает устройства либо по логину и паролю пользователя, либо по сертификату. С паролем начинается то, что знает любой администратор, переживший плановую смену паролей: пользователь сменил пароль на ноутбуке, телефон продолжает стучаться в Wi-Fi со старым, контроллер домена блокирует учётку, пользователь идёт в поддержку. Хуже того, если телефон не проверяет, что подключается к настоящей корпоративной сети (а на личных устройствах это руками никто не настраивает), злоумышленник поднимает точку доступа с тем же именем, собирает попытки входа и подбирает по ним пароли.

При входе по сертификату телефон и сервер аутентификации проверяют сертификаты друг друга, поэтому поддельная точка доступа не пройдёт, если проверка сервера настроена. А пароля в схеме нет: менять нечего, подбирать нечего. А OTP в Wi-Fi не вобьёшь – телефон подключается к сети сам, в фоне.

С VPN то же самое: корпоративный VPN на телефоне обычно включается сам, и спрашивать код при каждом подключении невозможно. Почтовые клиенты, внутренние веб-сервисы и приложения компании тоже умеют проверять клиентский сертификат через mTLS (взаимный TLS, где сертификат предъявляет и сервер, и клиент).

Чем плох TOTP

Ничем, коды, которые меняются по времени (TOTP), – нормальный второй фактор. Но в мобильных приложениях их часто спрашивают один раз, при первом входе, а дальше человек заходит по отпечатку пальца или четырёхзначному PIN-коду.

Здесь пригодится немного теории. Способы доказать системе, что ты – это ты, называют факторами аутентификации, и их три: знание (пароль, PIN), владение (телефон, токен, смарт-карта) и свойство (отпечаток, лицо). Надёжная аутентификация опирается на разные факторы: украсть одновременно пароль и устройство сложнее, чем что-то одно.

TOTP формально фактор владения, но в таком сценарии владение проверяют однажды. Сертификат, ключ которого создан на устройстве и не может его покинуть, – тоже фактор владения, только проверяется он при каждом подключении. А менять сертификат можно хоть каждую неделю: пользователю ничего вводить не надо, перевыпуск идёт в фоне.

Где тут MDM

Один сертификат на один телефон выпустить нетрудно. Проблемы начинаются на масштабе: устройств тысячи, сертификаты надо перевыпускать до истечения, а не после звонка в поддержку, отзывать в день увольнения и настраивать Wi-Fi, VPN и почту так, чтобы они их использовали. Центр сертификации подписывает сертификаты и ведёт список отозванных. MDM знает, какой телефон чей и в каком он состоянии, поэтому решает, кому, когда и какой сертификат выпустить, доставляет его на устройство, настраивает, где им пользоваться, и запускает отзыв, когда телефон выводят из управления.

Как это устроено в SafeMobile

Олег Ассур, SafeMobile

Приватный ключ остаётся на мобильном устройстве

Доставить сертификат на устройство можно двумя путями. Первый: сервер сам генерирует ключевую пару, получает сертификат и отправляет на устройство контейнер PKCS#12 (файлы .pfx или .p12). Приватный ключ при этом рождается на сервере и едет по сети под паролем, который тоже надо как-то доставить. В SafeMobile такая опция есть, но рекомендовать её мы не будем.

Второй путь – наш по умолчанию. Ключевая пара создаётся на устройстве, наружу уходит только запрос на выпуск сертификата (CSR). В нём открытый ключ и данные будущего сертификата: кому он выдаётся и для чего. Приватный ключ лежит в системном хранилище устройства и не покидает его ни при выпуске, ни при перевыпуске.

Запрос устройство отправляет по протоколу автоматического запроса сертификатов SCEP (Simple Certificate Enrollment Protocol). На iOS и Windows мы управляем встроенными в ОС MDM-агентами, которые SCEP умеют сами, а на Android и Авроре клиент SCEP встроен в наш клиент.

Зачем мы сделали свой SCEP-сервер

SCEP (RFC 8894) – старый и простой протокол: устройство подписывает и шифрует CSR, отправляет его на SCEP-сервер и с заданным интервалом спрашивает, готов ли сертификат. Его слабое место – аутентификация запроса: секрет (challenge), который клиент кладёт в запрос. Если секрет один на всех, узнавший его может просить сертификаты от имени кого угодно. В службе Microsoft для SCEP-запросов (NDES) такой режим общего пароля есть, и сама Microsoft предупреждает, что он годится только для сети, где доверяют каждому устройству. Строже проверять запросы NDES умеет с дополнительным модулем политик.

Мы пошли другим путём: SCEP-сервер у нас свой, а центр сертификации заказчика наружу не публикуется. Challenge уникален для каждого устройства и каждой цели: для подключения к серверу SafeMobile, для Wi-Fi, для VPN. SCEP-сервер проверяет challenge, а потом проверяет сам CSR. Администратор заранее задаёт, что должно быть в субъекте и альтернативных именах сертификата, с переменными о пользователе и устройстве. Если устройство Пети прислало запрос от имени Васи, запрос отклоняется. Так даже с доступом к устройству и секрету не выпустить сертификат на имя топ-менеджера. До такой паранойи нас довели банковские заказчики, за что им спасибо.

Работаем с SafeTech CA по REST API

Проверенный запрос забирает из очереди регистрационный агент: передаёт его в центр сертификации и возвращает выпущенный сертификат устройству. К Microsoft CA агент обращается через его штатный Windows-интерфейс, к SafeTech CA – по REST API. SCEP при этом заканчивается на нашем сервере, поэтому центр сертификации не надо выставлять туда, куда ходят телефоны, а агент входит в SafeTech CA под отдельной сервисной учётной записью, без общего SCEP-секрета. От ЦС нужно всего два метода: выпустить сертификат по CSR и шаблону и отозвать его. Для заказчика интеграция отдельно не лицензируется ни у нас, ни у SafeTech Lab.

Что нужно настроить администратору

Администратор выбирает центр сертификации и шаблон, задаёт субъект с переменными (имя, почта, подразделение, серийный номер, IMEI) и порог перевыпуска – за сколько дней до истечения или на каком проценте срока. Нижняя граница – 10% срока жизни, чтобы ошибка в настройке не обрушила центр сертификации лавиной запросов. Дальше в профиле Wi-Fi достаточно выбрать вход по сертификату: телефон сам выпустит сертификат и подключится к сети.

На iOS сертификат указывается прямо в профиле VPN. На Android SafeMobile кладёт его в системное хранилище, откуда его берёт приложение – так мы, например, настраивали клиент OpenVPN. Ограничение: системные хранилища мобильных ОС не умеют хранить сертификаты с ключами ГОСТ. Такие сертификаты живут в криптопровайдере, и удобной автоматизации их выпуска через MDM, совместимой с нормативными требованиями, мы пока не нашли. Но ищем.

Отзыв сертификатов

Когда устройство отключается от управления – сотрудник уволился, учётку заблокировали в домене, телефон списали, – SafeMobile автоматически, с небольшой задержкой, отзывает его сертификаты в SafeTech CA. Чтобы отозванный сертификат перестал открывать двери, Wi-Fi и VPN-серверы должны проверять его статус по списку отзыва или через OCSP. Каждое событие от запроса до отзыва уходит в Syslog с идентификаторами запроса и сертификата.

С Microsoft CA автоматического отзыва у нас нет, и это сознательное решение. Для этого учётной записи MDM пришлось бы выдать право управлять сертификатами в ЦС, а с ним она сможет отозвать любой сертификат этого ЦС, включая те, к которым MDM отношения не имеет. Давать системе управления мобильными устройствами такую власть над всей PKI компании мы не готовы.

Что умеет SafeTech CA

Евгений Швалёв, SafeTech Lab

SafeTech CA – корпоративный центр сертификации (ЦС), который мы изначально проектировали как замену Microsoft CA. Он работает на Linux, в том числе на отечественных дистрибутивах, разворачивается на виртуальных машинах или в Kubernetes, может хранить ключи ЦС во внешнем аппаратном модуле (HSM). Продукт внесён в реестр отечественного ПО и сертифицирован ФСТЭК России по 4-му уровню доверия.

95% сертификатов в компании – технические

Когда говорят о сертификатах, обычно вспоминают электронную подпись. Но, по нашей оценке, это около 5% сертификатов компании. Остальные 95% – технические: TLS на внутренних сайтах, VPN, почта, взаимная аутентификация сервисов, сетевое оборудование, мобильные устройства. У такого сертификата нет владельца, который придёт в поддержку: он привязан к серверу или устройству, и если он истёк, сразу падает интеграция или рвётся VPN. Пока инфраструктура была на Windows, всё это закрывал Microsoft CA с групповыми политиками. Для Linux, контейнеров, отечественных ОС и сетевого оборудования штатных механизмов у него нет.

Выпустили сертификат, а что потом?

Выпустить сертификат умеет любой ЦС. Сложности начинаются после выпуска:

1. Доставка. Забрали ли сертификат и положили ли на нужный сервер?

2. Применение. Сертификат доставлен, но сервис может продолжать работать со старым.

3. Аудит. Кто, когда и какой сертификат выпустил, где он используется и когда истекает. На 20 серверах это можно удержать в голове, на 10 000 – нет.

Лицензия не зависит от числа сертификатов

SafeTech CA лицензируется по числу экземпляров ЦС и подключаемых функциональных модулей, а число пользователей и сертификатов не ограничено. Для мобильного парка это важно: у каждого телефона бывает по сертификату на Wi-Fi, VPN и почту, а при перевыпуске старый и новый какое-то время действуют одновременно. Когда ЦС лицензируется по числу сертификатов или их владельцев, счёт растёт с каждым новым сценарием. При больших объёмах это превращается в прямую экономию: затраты фиксируются на уровне инфраструктуры и не зависят от того, сколько сертификатов выпущено и сколько устройств ими пользуется.

Протоколы

MS-WSTEP: автовыпуск для Windows сохраняется

Самое неприятное в замене ЦС – переходный период, когда старый и новый работают одновременно, а администраторы помнят, какой сертификат откуда выпущен. MS-WSTEP – протокол, на котором работает штатный автоматический выпуск сертификатов в Active Directory. SafeTech CA его поддерживает, поэтому Windows-машины получают сертификаты через привычные групповые политики, только из нового ЦС. Вместе с импортом шаблонов и выпущенных сертификатов из Microsoft CA это сокращает переходный период.

При миграции с MS CA на SafeTech CA переносятся шаблоны, сертификаты и, если нужно, точки распространения – после этого MS CA можно отключить. Но его можно и оставить: для параллельной работы и обслуживания старых сертификатов, пока они не истекут.

SCEP: сетевое оборудование и мобильные устройства

SCEP прост и работает при ограниченной связи, поэтому маршрутизаторы в филиалах запрашивают сертификаты сами. Большинство MDM-систем тоже работают по нему. Коллеги из SafeMobile пошли по другому пути и обращаются к нам по REST API – почему, объяснили выше.

ACME: TLS без ручной работы

ACME – протокол Let’s Encrypt: сервер сам запрашивает сертификат, подтверждает домен и продлевает его до истечения. Для контейнерных сред с короткоживущими сертификатами это стандарт. У Microsoft CA ACME нет, среди российских ЦС он пока редкость.

SSH-сертификаты вместо authorized_keys

Вместо открытых ключей, разложенных вручную по authorized_keys на сотнях серверов, серверы доверяют ключу ЦС и принимают подписанные им SSH-сертификаты пользователей. Доступ выдаётся централизованно, обычно короткоживущими сертификатами, а для досрочного отзыва серверам раздают список отозванных (СRL). Microsoft CA SSH-сертификаты не выпускает.

REST API и Linux-домены

Для интеграций, как с SafeMobile, есть REST API. Для Linux в доменах ALD Pro, Samba и FreeIPA – автоматический выпуск сертификатов.

Агенты доставки и одна консоль

Протоколы решают доставку, но не применение. Для этого есть агенты: они работают на целевой системе, забирают сертификат по защищённому каналу, следят за сроком, перевыпускают и сами применяют сертификат. Обычно ради агентов покупают отдельную систему управления сертификатами и интегрируют её с ЦС. В SafeTech CA агенты встроены в сам центр сертификации, а протоколы и агенты управляются из одной консоли: в ней видно, какие сертификаты выпущены, кому и когда они истекают.

Пока агенты работают на Linux-системах – deb и rpm. Агент может положить сертификат в нужную директорию и перезапустить сервис, а также сообщить системе об успешности или неуспешности выпуска. За указанный срок он сам перевыпустит сертификат и положит его куда надо, а оповещения на почту можно настроить заранее – за определённое время до истечения сертификата.

Переезд: что проверить, пока работают оба ЦС

Выше мы писали, что Microsoft CA не обязательно отключать сразу: он может поработать параллельно с новым ЦС, пока не истекут выпущенные им сертификаты. На это время часть телефонов ходит в сеть с сертификатами старого ЦС, часть – с сертификатами нового. Чтобы ни те, ни другие не потеряли доступ, заранее проверьте несколько вещей:

• в новых сертификатах есть те же поля, по которым серверы пускают устройства и пользователей. Например, имя в альтернативном имени субъекта;

• Wi-Fi и VPN-серверы на переходный период принимают сертификаты обоих ЦС;

• старый ЦС продолжает публиковать список отзыва, пока не истечёт последний выпущенный им сертификат. Если отключить Microsoft CA раньше, серверы, которые проверяют отзыв, начнут отклонять и действующие сертификаты;

• корневой сертификат нового ЦС уже есть на телефонах, когда RADIUS-сервер переходит на сертификат от нового ЦС. Иначе телефоны не будут доверять серверу и перестанут подключаться к Wi-Fi.

Что дальше

Выпуск сертификата – только начало. Дальше его нужно вовремя перевыпустить, а когда устройство выводят из управления – отозвать. Ради этого мы и связали SafeMobile с SafeTech CA: на телефонах и то и другое происходит само, без участия пользователя.

Если вы переезжаете с Microsoft CA и не хотите, чтобы вместе с ним отвалились корпоративные телефоны, – напишите нам или коллегам из SafeTech Lab. Покажем это на стенде: как телефон сам выпускает сертификат, подключается к Wi-Fi и как сертификат отзывается при отключении устройства от управления.

А если вы уже перевели мобильные устройства на сертификаты – расскажите в комментариях, как устроили выпуск и отзыв и на чём споткнулись. Вопросы к нам и к SafeTech Lab тоже задавайте там – ответим вместе.