Клиентские SSL сертификаты используются для реализации взаимной аутентификации между клиентом и сервером, обеспечивая высокий уровень безопасности за счет двустороннего подтверждения подлинности. В отличие от «обычного» SSL, где сервер подтверждает свою подлинность перед клиентом, при использовании клиентских SSL-сертификатов проверку проходят обе стороны. Это значит, что клиент должен предъявить свой сертификат для подтверждения своей личности. Такой подход не только дополнительно идентифицирует клиента, но и практически исключает атаки типа MitM ("человек посередине"), так как злоумышленник не сможет перехватить трафик или внедриться в сессию без валидного сертификата. В результате обеспечивается высокий уровень доверия и конфиденциальности, критически важный для безопасного обмена данными в корпоративных системах.
Уже везде есть
Одним из ключевых преимуществ клиентских SSL сертификатов является то, что эта технология изначально поддерживается «из коробки» на всех платформах, будь то Windows, macOS, Linux, Android или iOS. Все стационарные и мобильные устройства имеют встроенные средства для работы с SSL сертификатами, что позволяет легко интегрировать эту форму аутентификации в существующие системы без необходимости устанавливать дополнительное программное обеспечение. Это выгодно отличает SSL сертификаты от традиционных VPN, где для подключения обычно требуется установка и настройка клиентских приложений. Установка приложений на мобильных устройствах сейчас осложнена их отсутствием или недоступностью в магазинах. А в случае с SSL, пользователю достаточно импортировать сертификат, что значительно упрощает процесс, снижает административные затраты и устраняет потенциальные проблемы с совместимостью.
Прозрачность
Протокол HTTPS, использующий SSL/TLS сертификаты, является одним из наиболее широко используемых в Интернет, что делает его практически неуязвимым для блокировки со стороны провайдеров. В отличие от многих VPN-протоколов, которые могут быть легко распознаны и заблокированы с помощью DPI (глубокого анализа пакетов), HTTPS выглядит как обычный веб-трафик, что затрудняет его фильтрацию. Это важно в условиях, когда идет массовая блокировка нелегитимного трафика, связанного с обходами блокировок, а в результате недостаточно точной фильтрации страдает доступ к вполне легитимным корпоративным ресурсам. Кроме того, HTTPS-трафик может легко проходить через прокси-серверы, что дает дополнительную гибкость в построении архитектуры сетей и эшелонов защиты.
Универсальность
Абсолютное большинство корпоративных сервисов и так уже работает через HTTPS, что делает интеграцию клиентских SSL сертификатов простой и удобной. Даже если сам сервис изначально не поддерживает SSL/TLS, его можно защитить, развернув на уровне инфраструктуры «reverse-proxy». Такой прокси-сервер будет обрабатывать SSL-трафик, проверяя клиентские сертификаты до передачи запросов к конечному сервису. Это решение позволяет обеспечить дополнительный уровень безопасности без необходимости изменять сам сервис. В частности, централизованный WAF (Web Application Firewall) может выполнять проверку запросов к целому ряду сервисов с учетом присутствия сертификатов.
Использование клиентских SSL сертификатов легко интегрируется с системами балансировки нагрузки, что особенно важно для крупных компаний с большим количеством пользователей. Проверка клиентских сертификатов происходит централизованно, что упрощает управление аутентификацией и снижает нагрузку на каждый отдельный сервер. Это обеспечивает не только безопасность, но и масштабируемость инфраструктуры, позволяя обслуживать тысячи пользователей без снижения производительности.
Гибкость
Клиентские SSL сертификаты позволяют организовать гибкое управление доступом к корпоративным ресурсам, что делает их отличным инструментом для контроля за правами отдельных пользователей или групп. Администраторы могут точно регулировать доступ к различным системам, устанавливая правила, кто и к каким ресурсам имеет право подключаться. Процесс выпуска и отзыва сертификатов очень прост и легко автоматизируется. Например, при увольнении сотрудника его сертификат можно оперативно отозвать, тем самым ограничив доступ к корпоративным системам. Это, в частности, решает проблему изменения паролей или закрытия аккаунтов в многочисленных системах без доменного управления.
Использование собственного Центра сертификации (CA) добавляет дополнительный уровень безопасности и контроля, позволяя ИТ- и ИБ-отделам разделять свои полномочия при управлении доступом. Так, управлением аккаунтами пользователей в информационных системах занимаются администраторы, а выпуском и отзывом сертификатов офицеры безопасности.
Цена внедрения
Технология клиентских SSL сертификатов обладает низким TCO. Для их использования не требуется нанимать дополнительного администратора системы безопасности. В отличие от многих решений, которые требуют дополнительной инфраструктуры и постоянного мониторинга, развертывание SSL сертификатов можно осуществить быстро и с минимальными затратами. Инструменты для выпуска, управления и отзыва сертификатов уже встроены в большинство платформ, что упрощает интеграцию. Кроме того, масштабирование системы происходит без дополнительных инвестиций: даже при увеличении числа пользователей или ресурсов, инфраструктура легко адаптируется без необходимости покупки дополнительного оборудования или лицензий, что делает это решение крайне экономичным для компаний любого размера.
Для многих платформ существуют бесплатные Open Source решения для управления клиентскими сертификатами, что дополнительно снижает стоимость внедрения.
Второй фактор
В рамках концепции двухфакторной аутентификации (2FA) клиентский SSL сертификат выполняет роль «того, что у меня есть», дополняя традиционный пароль. Это означает, что для доступа к системе пользователю недостаточно просто знать свой пароль — он также должен обладать сертификатом, установленным на его устройстве. Такая комбинация двух факторов значительно повышает уровень безопасности: даже если пароль будет скомпрометирован, доступ к корпоративным ресурсам останется заблокированным для злоумышленника, поскольку у него не будет клиентского сертификата.
Или второй первый
Существует давний спор, действительно ли сертификат является полноценным вторым фактором «то что у меня есть», или это второй первый «то что я знаю» в дополнение к паролю. Компрометация клиентского SSL сертификата представляет собой неочевидную задачу.
Рассмотрим конечного пользователя как наиболее частый канал утечки первого фактора. В отличие от пароля сертификат невероятно сложно «продиктовать» по телефону или «записать на стикер под монитором», так как он состоит из длинной последовательности символов. Если он уже установлен в систему, то действия по экспорту приватного ключа также значительно усложняются для конечного пользователя (в частности, в некоторых операционных средах сертификат можно сделать не экспортируемым). Поэтому отправка сертификата конечным пользователем по электронной почте или через мессенджер также весьма маловероятна. Переданный для установки bundle p12 обычно шифруется стойким длинным паролем, так что даже утечка самого контейнера не создает значительных рисков и оставляет достаточно времени для принятия мер. Если устройство утеряно или украдено, можно просто отозвать сертификат, заблокировав доступ.
Технические каналы утечки различаются для стационарных и мобильных устройств. В общем случае, приватный ключ по самой сути остается на устройстве и не передается по публичным каналам связи, что исключает утечку в момент установления сессии (чего никак не скажешь о пароле). Это означает, что даже в случае перехвата самого сертификата на этапе handshake, злоумышленник не сможет его использовать без соответствующего приватного ключа.
Получить приватный ключ, установленный на мобильном устройстве, практически нерешаемая задача. Современные мобильные операционные системы снабжены API крипто-провайдера, которые выполняют все необходимые действия без раскрытия приватного ключа приложению.
Наиболее слабым местом остается браузер на компьютере и его хранилище сертификатов. Но здесь задача также схожа с получением ключа из хранилища операционной системы. Злоумышленнику нужно предварительно получить полноценный административный контроль или доступ, от чего защищают различного рода антивирусы и брандмауэры. А вероятность появления zero-day уязвимости, которая позволит обойти технические средства защиты рабочего места практически совпадает с вероятностью аналогичной уязвимости самой защищаемой сертификатами информационной системы.
Генерация закрытого ключа не зависит от человеческого фактора и полностью исключает недостаточную стойкость или несоответствие требованиям. Также, благодаря сложности вычислений, сертификаты практически невозможно подобрать, в отличие от паролей.
Таким образом, сертификат на мобильном устройстве однозначно является полноценным вторым фактором, а на стационарном – с незначительными оговорками.
Цифровой след
Несоответствие предъявленных реквизитов доступа и идентификатора сертификата однозначно можно трактовать как событие безопасности.
Логи о попытках нелегитимного доступа, зафиксированные при использовании клиентских SSL сертификатов, можно автоматически отправлять в SIEM. Это позволяет администраторам получать централизованный обзор и оперативно реагировать на потенциальные угрозы. На сегодняшний день все существующие SIEM системы имеют интеграцию с веб-технологиями и способны также «из коробки» обрабатывать сообщения об использовании сертификатов.
Кроме того, технология клиентских сертификатов легко интегрируется с решениями расширенного детектирования и реагирования (XDR). Это позволяет объединять данные из различных источников — от сетевых до конечных устройств — для более комплексного анализа и улучшенной видимости безопасности.
Технология также может быть интегрирована с существующими механизмами аутентификации и авторизации, такими как OAuth и OpenID, или дополнять их как второй фактор при SSO.
Почему не используются
Несмотря на множество преимуществ, клиентские SSL сертификаты иногда остаются недооцененными по следующим причинам:
- Недостаток знаний и недостаточная документация: использование сертификатов требует знания специфических технологий, а имеющаяся документация может быть неполной. Попытки получить информацию в открытых источниках в абсолютном большинстве приводят к описаниям создания и применения исключительно серверных SSL сертификатов. Описания разворачивания собственного CA не снабжаются достаточными объяснениями назначения тех или иных функций или команд.
- Непрофильная компетенция ИТ: многие ИТ-специалисты фокусируются на традиционных методах безопасности, таких как VPN и парольные политики.
- Стандартная инфраструктура Active Directory не предполагает использование SSL сертификатов для аутентификации. Встроенные механизмы направлены на «прозрачный» выпуск и распространение клиентских сертификатов на устройства, включенные в домен. Поэтому при отсутствии MDM или применении BYOD пользователи не имеют возможности установить сертификаты на свои мобильные устройства или ноутбуки.
Внедрение
Первым шагом при внедрении клиентских SSL сертификатов является создание собственного центра сертификации (CA), который будет выдавать сертификаты сотрудникам и сервисам. Далее планируется архитектура системы контроля и вносятся соответствующие правки в конфигурацию публикуемых сервисов.
Для повышения удобства пользователей и упрощения процессов управления сертификатами можно развернуть портал самообслуживания. На таком портале сотрудники смогут самостоятельно запрашивать, получать и обновлять свои клиентские сертификаты без необходимости обращения в IT-отдел. Это существенно сокращает время ожидания и снижает нагрузку на администраторов и техническую поддержку.
Пользовательский интерфейс портала может быть интуитивно понятным и доступным, обеспечивая простоту и удобство в использовании. Кроме того, система может включать автоматизированные уведомления о необходимости обновления сертификатов, что помогает избежать ситуаций с истечением срока действия и обеспечивает бесперебойный доступ к корпоративным ресурсам.
Вместо заключения
Технология клиентских SSL сертификатов на самом деле гораздо ближе, чем кажется. Каждые два из трех мобильных банковских приложений используют их. Также они применяются в системах защищенной передачи данных с государственными органами (например, сдача отчетности). И во всех этих случаях остаются в тени. Конечно, остается вопрос комплаенс и регулирования. Но если мы говорим о коммерческой замкнутой корпоративной среде – никаких специальных требований к применению сертификатов не предъявляется.
Если у вас возникли вопросы, не стесняйтесь обращаться.
