Введение.
Это вторая часть цикла статей про zerotrust. В ней разберем процесс создания “доверенного устройства”
Куда класть сертификат
Для того, чтобы участники zt проверяли друг друга, нам необходим какой-то механизм. В прошлой части мы выбрали для этого старый добрый mTLS. Он позволяет надежно и безопасно верифицировать обе стороны взаимодействия.
Обратимся к нашей практической задаче - защита веб админок. Проверять валидность и доверие сертификату веб-ресурса браузеры научились очень давно, и механизм отлично отлажен. С проверкой сервером эндпоинта не все так просто. Первая проблема, которая приходит на ум - куда положить сертификат на машине пользователя, чтобы его не украли? Есть несколько вариантов - просто на файловую систему, в защищенное парольное хранилище (например Keychain на macOS), или же в еще более защищенное хардварное хранилище TPM или Secure Enclave.
Мой практический опыт пентестов показывает, что всё, что лежит на машине пользователя можно вытащить. Просто сертификат с диска вытаскивается на раз два, пароль из Keychain вытаскивается сфабрикованным поп-апом с просьбой ввести от него пароль. Остается TPM. Явным его плюсом является то, что сгенеренный внутри сертификат не может быть извлечен - то есть при пробиве машины и даже получении на ней рута атакующий все равно не сможет получить закрытый ключ. Получается наш выбор очевиден - кладем сертификаты для mTLS в TPM/SecEnclave.
И вот тут начинается интересное.
Windows + TPM
Начнем с наиболее корректно работающей платформы - Windows. Вся логика работы c TPM зашита в нескольких системных DLL разного уровня абстракции, для которых человечество разработало большое количество оберток.
Если не вдаваться в технические подробности, генерация и хранение сертификата выполняется вызовом уже написанных добрыми людьми функций из go пакета (мы пишем на go). Все, что нужно - упаковать вызов функций в бинарь, добавить поддержку cli и silent режима, после чего протестировать его разливку и выполнение с помощью доменных политик.
MacOS + Secure Enclave
Устройства Apple выступили не так гладко. Начнем по порядку.
Отсутствуют развитые opensource библиотеки/софт для работы с Secure Enclave. Из более-менее живых - софт для записывания ssh ключей в tpm (не тестировали) и POC-софт для полноценной работы c SecureEncavle, записывания и удаления произвольных ключей, их листинга и так далее. Именно он бы взят за основу, и нормально работал. Пока Apple не выкатило обновления ОС, после чего всё работать перестало. Было принято волевое решение писать всё с нуля.
Из-за отсутствия открытых библиотек приходится пользоваться родным macOS API. Из-за этого ты вынужден писать на Objective C. После героического экспресс обучения в боевых условиях новому языку, ты приходишь к новой интересной задаче.
Подписание бинаря. Нельзя просто так взять и распространить программу, работающею с защищенным криптопровайдером. Для этого понадобится а) платный аккаунт на Apple Developer б) сакральные, нигде не описанные знания, какие именно entitlements нужно запросить софту, и какие именно галочки проставить в XCode.
Совместимость. Собственные процессоры и SoC Apple - безусловно, выдающиеся технические достижения. Проблема в том, что с каждой новой версией чипа меняется спецификация и необходимые entitlements. Для того, чтобы бинарь корректно заработал сразу на всех платформах потребовалась консультация с духом Стива Джобса.
После преодоления вышеописанного удалось сделать работающий софт. Короткие выводы - Secure Enclave еще сырой и требует большого внимания и поддержки, платформодержатель - Apple - в любой момент может изменить правила игры, твое ПО перестанет работать, твои процессы сломаются. Нужно быть к этому готовым и иметь план Б на каждый вариант негативного развития событий.
Аттестация устройств
Как только мы начнем разливать на устройства сертификаты, мы столкнемся с проблемой - как понять, что устройство, которое запрашивает сертификат наше, корпоративное?
Так как мы используем самописные бинари для запроса и выполнения сертификата, нам нужен какой-то механизм, чтобы условный сотрудник Вася, не пришел в офис с личным ноутбуком, поставил наш бинарь, дернул ручку и превратил свой личный ноутбук в корпоративный.
Первый вариант решения - использовать официальный рекомендованный производителями способ аттестации. Apple предлагает протокол ACME - официальный протокол менеджмента сертификатов в корпоративной среде. По нему вердикт короткий - он сырой и не работает. Для Windows есть официальный процесс TPM Key Attestation, который на нашем опыте работает. Тут мы приходим к тому, что половина нашего парка будет работать нормально (Windows) а половина нет (macOS). Нужен другой способ.
Второй способ. Ретроградский. Организуем секретную комнату в которой стоит сервер с Certification Authority из которого торчит один патч-корд. Все ноутбуки компании привозим в эту комнату, и разливаем сертификат по проводу. Способ, как ни смешно, рабочий но не очень удобный. Разлить сертификаты на существующий парк оборудования будет чудовищно трудозатратно. Тем не менее способ вполне валиден для сетапа нового оборудования. Пока оставляем в такой урезанной форме.
Третий способ. Самостоятельный Enroll с валидацией. Наш софт для общения с нашим CA распространяется открыто, он уже идет в комплекте с корпоративной наливкой. При запросе сертификата от нового устройства оно попадает в лист ожидания, в котором инженер в ручном режиме анализирует, действительно ли устройство корпоративное, после чего согласует сертификат. Способ хорош, но только на небольших объемах. Используем его для исключительных случаев. Также используем его для первоначальной разливки на парк текущих устройств, которые
выданы пользователям.
Итого - в идеальном мире, когда заработают вендорские решения мы сможем полностью автоматизировать процесс аттестации с помощью MDM. В настоящий же момент мы вынуждены пользоваться вспомогательными средствами.
Certification Authority
Для валидации mTLS нашей прокси нужен CA, от которого она может получить подтверждение, “наш” или “не наш” компьютер пришел. Небольшая картинка для наглядности:
Также CA нам нужна для первоначальной аттестации устройств:
Как видно из схемы, нам требуется небольшое middleware для работы с CA и нашим софтом. На нем мы можем апрувить новые компьютеры, накручивать при необходимости аутентификацию, собирать статистику, и, что немаловажно, собирать логи нашего софта (при падениях, например).
Поддержка браузеров
Так как mTLS довольно обкатанная технология, браузеры работают с ней хорошо и имеют достаточный набор инструментов с тонкой настройкой. Между тем TPM/Secure Enclave технологии новые, поэтому качество работы связки браузер <-> криптопровайдер может быть нестабильным.
Для обеспечения стабильной работы желательно иметь ферму для тестов всех нужных браузеров для всех необходимых ОС. На момент написания браузеры Chrome, Firefox, Safari на macOS и Windows работали корректно.
После удачной установки сертификата в tpm, когда пользователь открывает админку за нашей zt прокси, браузер ему предлагает выбрать сертификат для аутентификации (так работает mtls). Для улучшения пользовательского опыта потребуется небольшая донастройка, чтобы прозрачно этот сертификат “подложить” браузеру. Делается это стандартными задокументированными способами, и по опыту работает корректно. Эта донастройка позволит обеспечить нулевое пользовательское взаимодействие при переходе на zt, что обеспечит нам почет, уважение и положительные отзывы сотрудников.
Итоговая схема. С нее надо было бы начать
Для подключения пользовательских машин к процессу zt нам потребуется:
Разработать механизм (ПО) для доставки, управления и аттестации сертификатов на все поддерживаемые нами ОС и устройства.
Понять и поднять Certification Authority для обеспечения аутентификации устройств
Написать middleware для взаимодействия c Certification Authority
Еще несколько замечаний. Для нашего MVP мы берем в поддержку ноутбуки с Windows и macOS. Исследования *nix мы провели, работоспособности добились, но официально не поддерживаем. Также мы не рассматриваем тут мобильные устройства, их поддержка выходит за рамки MVP.
Дополнительная литература
Github repositories
golang: certtostore - working with TPM and Windows certificate store
Secretive app for storing and managing SSH keys in the Secure Enclave.
Books
A Practical Guide to TPM 2.0 - много чего про TPM: история, как читать спецификацию TPM, криптографические примитивы, структура TPM, ключи, иерархии, менеджмент ключей, команды TPM, прикладные и системные API для работы с TPM.
Documentations & Articles
The Trusted Platform Module Key Hierarchy - более подробно про ключи в TPM + код на golang как работать с ключами на Linux
Certificate, Key, and Trust Services - официальная документация от Apple по Sec Enclave