Современные угрозы и вызовы

Российские компании находятся сегодня в эпицентре кибервойны. Учащающиеся успешные целевые атаки приводят к параличу бизнес-процессов и катастрофическим убыткам. Анализ развития атак показал, что основной фактор успеха современных кибератак — слабость парольной аутентификации, выраженной в простоте компрометации пароля с помощью различных вариаций фишинга, что усугубляется повторным использованием паролей от разных ресурсов (включая личные-корпоративные), совместным использованием учетных записей разными сотрудниками и подрядчиками и слабыми механизмами хранения секретов в инфраструктуре. 

Статистика выглядит однозначно: по данным Solar, до 37 % инцидентов связаны с компрометацией учетных записей; Kaspersky фиксирует, что 29 % первичных проникновений начинаются именно с похищенных учетных данных, а BI.ZONE указывает, что 35 % критичных инцидентов связаны с привилегированными аккаунтами. Международная картина еще показательнее: Microsoft заявляет, что 61 % атак включает использование привилегированных учетных записей, Google отмечает, что около 50 % успешных атак стартуют с компрометации учетных данных. ФСТЭК прямо указывает на слабые пароли и однофакторную аутентификацию как ключевые причины успешных атак. 

Параллельно с эскалацией угроз стремительно ужесточается регуляторное давление. Для госсектора введение Приказа ФСТЭК №117 и Указа Президента №250 стало жестким императивом к переходу на строгую аутентификацию в полностью импортонезависимый стек. Частный сектор также испытывает на себе давление растущих требований со стороны ЦБ РФ, международных стандартов и фреймворков (ISO27001, PCI DSS, CIS Controls, NIST CSF) и концепции типа Zero Trust, которые часто ложатся в основу корпоративных стратегий информационной безопасности.

Нормативная неизбежность Zero Trust  

Важно подчеркнуть, что концепция Zero Trust не противоречит российской нормативной базе и не требует ее пересмотра — напротив, она системно развивает уже закрепленные требования. Приказ ФСТЭК №117 устанавливает необходимость строгой аутентификации и управляемого доступа, Указ Президента №250 акцентирует импортонезависимость механизмов доверия, а отраслевые регуляторы требуют прослеживаемости и доказуемости контроля. Zero Trust переводит эти требования в целостную архитектурную логику: отказ от неявного доверия, обязательность подтверждения доступа и контроль привилегий на всех значимых этапах взаимодействия с ресурсами. В условиях, когда компрометация учетных данных становится доминирующим сценарием атак, а регулятор требует доказуемой управляемости доступа, задача уже не ограничивается внедрением отдельных средств защиты. Речь идет о пересмотре самой модели доверия и формировании системного механизма контроля. 

В классическом определении Zero Trust исходит из предположения, что доверие не должно предоставляться по умолчанию ни субъекту, ни устройству, ни сегменту сети — независимо от их расположения или результатов предыдущих проверок. Однако на практике многие внедрения ограничиваются лишь первоначальной аутентификацией, фактически воспроизводя модель «доверия после входа» в обновленной терминологии. Если доверие действительно не предполагается по умолчанию, оно не может быть сформировано однократно и затем неявно унаследовано на всю сессию. Оно должно подтверждаться в каждой значимой точке получения доступа — при первичном входе, повышении привилегий, смене контекста, обращении к критичным ресурсам. Следовательно, доверие должно формироваться, проверяться и пересматриваться в рамках непрерывного процесса, охватывающего всю цифровую экосистему. При этом необходимо обеспечить доверие не только к субъекту доступа, но и к самому процессу его формирования — а значит, и к сущностям, участвующим в этом процессе. 

В перманентном формировании цифрового доверия такие сущности разнородны: методы подтверждения личности, контекст доступа и среда выполнения, состояние устройства, механизмы их взаимодействия. Очевидно, что в этой цепочке должен быть элемент, доверие которому не ставится под сомнение в силу крайне высокой сложности компрометации, неподверженный фишингу, атакам типа запись и воспроизведение, промежуточному перехвату и т.д., а значит речь идет об элементе с аппаратной криптографией, обеспечивающей многофакторную аутентификацию. 

Независимый фактор доверия: аппаратная аутентификация как фундамент.

В поиске аппаратной основы доверия нередко упоминается модуль доверенной платформы (TPM). Его возможности действительно важны: он обеспечивает контроль целостности загрузки, защищенное хранение ключей и привязку криптографических операций к конкретному конечному устройству. Однако TPM не может рассматриваться как независимый аппаратный фактор аутентификации, поскольку является частью самой вычислительной платформы, через которую и к которой осуществляется доступ. Он подтверждает состояние устройства, но не личность пользователя. Иными словами, TPM формирует доверие к среде выполнения, но не создает дополнительного внешнего фактора, отделенного от объекта доступа. При компрометации учетной записи или при физическом доступе к машине TPM продолжает работать в рамках той же платформы. Поэтому он не решает задачу персонализированного подтверждения действия и не может выступать вторым независимым аппаратным фактором в модели Zero Trust. 

Непрерывность доверия как архитектурный принцип

Если доверие должно быть персонализированным, переносимым между устройствами и устойчивым к компрометации, требуется иная опора — аппаратный аутентификатор с неизвлекаемыми криптографическими ключами. Токен или смарт-карта генерируют и используют ключи внутри защищенного контейнера, исключая возможность его извлечения в программную среду. Дополнительное усиление обеспечивает контроль присутствия пользователя — подтверждение операции нажатием или биометрией, исключающей возможность скрытой передачи полномочий третьим лицам. Однако сама по себе защищенность ключа еще не гарантирует целостности модели доверия. Аппаратный фактор должен работать не в одной точке входа, а во всей инфраструктуре, где принимаются решения о доступе. 

Теоретическая модель Zero Trust предполагает единообразное и непрерывное подтверждение доступа — вне зависимости от платформы и способа подключения. Современная крупная организация представляет собой гибридную среду с Linux и Windows как на уровне серверов, так и на уровне рабочих станций, с несколькими доменными службами и разнородными механизмами аутентификации. Active Directory может сосуществовать с FreeIPA, а также с решениями отечественных вендоров, такими как РЕД АДМ или Альт Домен. У каждого контура — собственные протоколы, логика делегирования прав и точки принятия решений. В таких гетерогенных средах существует множество точек контроля доступа, каждая из которых использует собственные механизмы: локальный вход в систему, доменная аутентификация, SSH-доступ к серверам, повышение привилегий через SUDO или UAC, подключение по VPN, работа через VDI, доступ к прикладным системам и контейнерным платформам. Каждая из этих точек формирует отдельный сценарий подтверждения доступа, и аппаратный фактор должен быть встроен в них единообразно. Отдельное измерение — мобильные устройства, через которые сотрудники получают доступ к корпоративным ресурсам вне периметра организации. Это расширяет контур взаимодействия и увеличивает количество точек, где доверие должно быть подтверждено. 

Разнородность среды становится ключевой проблемой: механизмы подтверждения доступа различаются в зависимости от платформы или сервиса, архитектура перестает быть целостной, и реализация Zero Trust в такой среде легко распадается на набор локальных решений, не образующих управляемой системы. 

Материализация Zero Trust: требования к платформе управления доступом

Логичен вопрос: что именно нужно, чтобы описанная модель работала не в презентации, а в инфраструктуре: чтобы токен действительно мог выполнять свою роль корня доверия во всех точках доступа. Один токен сам по себе не решает задачу: ему требуется инфраструктурная обвязка, реализующая множество служебных процессов, скрытых от пользователя. Давайте опишем, на базе каких компонентов и с каким функционалом возможно создать универсальную платформу управления доступом, решающую нашу задачу в современных гетерогенных ландшафтах.

Платформа должна содержать криптографическое ядро — корпоративный центр сертификации, формирующий инфраструктурный контур доверия. Он должен обеспечивать построение иерархии PKI (корневые, промежуточные и выпускающие центры), публикацию точек распространения списков отзыва и служб проверки статуса, а также защищенное хранение ключей центра, включая использование аппаратных модулей через интерфейсы типа PKCS#11.

Криптографическая модель должна поддерживать как международные алгоритмы (RSA, ECDSA), так и отечественные стандарты, что будет обеспечивать применимость в инфраструктурах со смешанными требованиями к криптографии. Центр сертификации должен обеспечивать полный цикл работы с сертификатами пользователей, сервисов и оборудования — выпуск, перевыпуск и отзыв, с проверкой статуса через CRL и OCSP.

Ключевым требованием является интеграция с каталогами пользователей и доменными службами, а также поддержка широкого спектра протоколов регистрации и автоматического получения сертификатов: MS-WSTEP (для интеграции с Active Directory), SCEP и EST (для сетевого оборудования и MDM), ACME (для веб-инфраструктуры, Kubernetes и OpenShift), CMP (для взаимодействия с криптографическими библиотеками) и механизмов выпуска SSH-ключей.

Таким образом, центр сертификации должен выступать не только средством выпуска пользовательских сертификатов, но и универсальным механизмом обеспечения доверия для сервисов, контейнерных сред, DevOps-процессов и сетевого оборудования. Архитектура должна поддерживать и обеспечивать масштабируемость до сотен тысяч сертификатов без деградации производительности. Для этого необходимо иметь возможность создавать иерархические структуры, которые так же позволят разграничить зоны доверия внутри инфраструктуры и обеспечат изоляцию рисков.

Дополнительно должны поддерживаться механизмы миграции с существующих PKI (в первую очередь Microsoft CA), централизованный мониторинг и формирование отчетности. 

Во-вторых, платформа должна обеспечивать системный механизм строгой аутентификации в среде Linux. В отличие от Windows, где аутентификация по смарт-карте является нативной, в большинстве Linux-дистрибутивов она требует дополнительных компонентов. Это означает интеграцию в стек PAM, использование PKCS#11, поддержку доменной аутентификации по сертификату X.509 либо с использованием секретов, хранимых на аппаратном носителе.

Платформа должна обеспечивать взаимодействие с доменными средами (Active Directory, FreeIPA, SambaDC и др.) через стандартные механизмы Kerberos, включая сценарии единого входа. Проверка сертификатов должна выполняться через CRL и/или OCSP. Поддержка корпоративных Linux-дистрибутивов и различных аппаратных архитектур (x86, ARM) является обязательным условием применимости в гетерогенной инфраструктуре.

С точки зрения эксплуатации этот клиентский модуль должен поддерживать централизованное развертывание и конфигурацию через системы управления конфигурациями (Puppet, Ansible и др.), а также обеспечивать журналирование событий и интеграцию с SIEM-системами (например, через syslog). Должны поддерживаться политики входа, включая обязательное использование аппаратного фактора, блокировку при извлечении носителя и контроль пользовательских действий.

При реализации этого функционала Linux-среда получит функционально сопоставимый с Windows механизм аппаратной аутентификации, что позволяет унифицировать процессы строгой аутентификации в гетерогенной инфраструктуре.

В-третьих, платформа должна обеспечивать централизованное управление доступом к разнородным ресурсам. После аутентификации в операционной системе пользователь взаимодействует с множеством систем: корпоративные приложения с веб-интерфейсом, VPN-шлюзами, терминальными сервисами, VDI, ERP/CRM, серверами (SSH), репозиториями кода, CI/CD-конвейерами и контейнерными платформами.

Платформа должна выполнять функции принятия решений и применения политик доступа. Это означает проверку параметров запроса и передачу целевой системе результата проверки. Необходима поддержка стандартных протоколов интеграции — RADIUS, SAML, OpenID Connect, Kerberos и аналогичных механизмов федерации.

Особое значение этот уровень приобретает в технологическом контуре. Доступ по SSH, операции в CI/CD, взаимодействие с Kubernetes требуют строгой персонификации и контроля повышения привилегий. Необходимо обеспечить возможность задания политик, требующих обязательное использование аппаратного фактора при административных действиях, выпуске релизов или изменении конфигурации инфраструктуры.

Для каждого ресурса должны задаваться контекстные правила: повторная аутентификация при повышении привилегий, ограничения по времени, источнику подключения, сетевой зоне или типу операции. Политики должны централизованно администрироваться и единообразно применяться ко всей инфраструктуре — от пользовательских рабочих мест до серверных и DevOps-контуров.

Реализация этих требований формирует единый слой управляемого допуска к ресурсам: аппаратный носитель подтверждает личность, центр сертификации обеспечивает цифровую идентичность, а система управления доступом определяет условия использования ресурсов.

В-четвертых, платформа должна включать полноценный эксплуатационный контур управления жизненным циклом аппаратных носителей и сертификатов. Даже при масштабах в 500 пользователей этот контур становится критическим элементом устойчивости всей архитектуры доверия. Что позволит обеспечить стабильную и безопасную эксплуатацию, исключающую ошибки, обусловленные человеческим фактором, при десятках и сотнях тысячей пользователей?

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

Система должна поддерживать интеграцию с LDAP-каталогами (включая Active Directory) и центрами сертификации, одновременно работая с различными их комбинациями. Все операции должны выполняться на основе настраиваемых политик, определяющих параметры сертификатов на базе их шаблонов, требования к PIN-кодам. При рассмотрении масштабных внедрений в сложной инфраструктуре необходимым становится не просто ролевой принцип управления, при котором допустимый функционал сопоставлен с ролями, но и их привязка к группам пользователей — держателей токенов, которые должны формироваться по определенным критериям, например, принадлежности к структурным элементам или группам в службах каталогов.  

Критически важным является аудит: фиксация всех операций, возможность создания отчетности по устройствам, пользователям, типам действий и временным интервалам.

Платформа также должна предоставлять пользователям механизмы самообслуживания: смена и разблокировка PIN-кода, перевыпуск сертификатов, временная блокировка или отзыв носителя. Это снизит нагрузку на службы поддержки и сократит простои, обусловленные невозможностью выполнить операцию из-за недоступности токена,  и улучшит пользовательский опыт.

Хорошим дополнением будет интеграция с внешними системами:  СКУД (для возможности использования универсальной карты сотрудника со встроенным RFID-чипом) и IDM-системами (для автоматизации выпуска и назначения носителей при онбординге).

Таким образом, управление жизненным циклом превращает аппаратный носитель из устройства в элемент контролируемой корпоративной инфраструктуры доверия.

Платформа управления доступом как стратегический актив организации

Формализованный и автоматизированный жизненный цикл носителей завершает построение платформы управления доступом как основы всей архитектуры доверия. На этом уровне становится очевидно: речь идет не о внедрении отдельных средств, а о создании целостной системы, в которой аппаратная аутентификация, центр сертификации и централизованное применение политик работают как единый механизм. В современных условиях, когда основным объектом атак остается учетная запись, устойчивость организации определяется способностью управлять цифровым доверием — от генерации ключей до контроля использования привилегий. Здесь проявляется практический симбиоз российской нормативной базы и реальной реализации Zero Trust: требования ФСТЭК к строгой аутентификации и управляемости доступа получают архитектурное воплощение в виде единой платформы, обеспечивающей непрерывное подтверждение доступа и прослеживаемость действий. Импортонезависимый стек в этой модели становится не только формальным условием соответствия, но и элементом архитектурной зрелости. Он позволяет выстроить воспроизводимый, масштабируемый и проверяемый механизм контроля во всей гетерогенной среде — в Windows и Linux, в пользовательском и технологическом контуре, при локальном и удаленном доступе. Только при такой целостности аппаратный фактор перестает быть дополнительной мерой и становится фундаментом корпоративной инфраструктуры доверия. В результате платформа управления доступом превращается в стратегический актив организации. Она снижает операционные риски, обеспечивает доказуемость контроля для регулятора и формирует устойчивость бизнеса в условиях постоянного внешнего давления. Переход к такой модели — это уже не вопрос технологического выбора, а необходимое условие системной безопасности и долгосрочного развития.