Хмельницкий
Сегодня Zero Trust или концепция «нулевого доверия» — один из наиболее популярных подходов к защите корпоративной инфраструктуры. Насколько концепция распространена сейчас в России? Какие вы видите причины роста её популярности? Почему она приходит на смену традиционным подходам к корпоративной кибербезопасности?
Алексей Хмельницкий: Концепция Zero Trust — «нулевого доверия» — резко обрела популярность во время пандемии, когда переход сотрудников на удаленную работу стал массовым. Если еще в 2010-х годах «удаленка» была прерогативой ИТ и менеджмента, то в 2021 подавляющее большинство офисных работников должны были перейти на работу из дома. Подразделениям ИТ и информационной безопасности пришлось решать эту задачу средствами, которые были под рукой. Где-то использовали доступ к корпоративной сети с помощью VPN, где-то использовали удаленный доступ к рабочему столу. Сотрудникам раздали ноутбуки или разрешили пользоваться своими устройствами для входа в корпоративную сеть.
Казалось бы, проблема была решена — сотрудники смогли удаленно заходить внутрь «охраняемого периметра» компании. Однако такой периметр стало гораздо сложнее охранять.
Принцип «нулевого доверия» означает особый контроль доступа сотрудников к информационным системам компании. Даже если пользователь находится внутри корпоративной сети и использует корпоративный ноутбук, он должен пройти процедуру идентификации и аутентификации, а при каждом доступе к какому-либо корпоративному ресурсу необходимо проверять, есть ли у пользователя право на такой доступ. Догнать и перегнать: Российские ВКС прирастают новыми функциями 
Хорошая новость в том, что технологическая основа для реализации принципа Zero Trust проработана хорошо.
Как внедрение инструментов комплексного управления авторизацией и аутентификацией клиентов вписывается в концепцию Zero Trust?
Алексей Хмельницкий: В концепции Zero Trust безопасный доступ к системам компании обеспечивается не защищенной сетью, а так называемой «проверкой владения». Каждый раз, когда сотрудник обращается к системе (хочет совершить действие с каким-то корпоративным ресурсом), требуется ответить на вопрос «Имеет ли право данный конкретный сотрудник совершать действия с данным конкретным ресурсом?».
Ответ на этот вопрос состоит из двух технологических шагов. Сначала мы должны убедиться, что тот, кто совершает действие — это действительно тот сотрудник, за которого он себя выдает. Это процесс аутентификации пользователя. Затем мы должны убедиться, что корпоративные правила доступа позволяют этому сотруднику иметь доступ к запрашиваемому ресурсу. Это процесс авторизации и контроля доступа.
Оба этих процесса — аутентификация и авторизация пользователей — обеспечиваются системами класса IAM (Identity and Access Management). Поэтому такая система является важной, хоть и далеко не единственной, обеспечивающей практическое применение концепции Zero Trust.
Какова основа построения IAM в концепции Zero Trust? Что является её центром?
Алексей Хмельницкий: Системы управления доступом исторически делились на системы управления доступа сотрудников и системы управления доступа клиентов. У этих двух групп пользователей разные паттерны поведения, которые ранее приводили к тому, что начиная с архитектуры эти системы должны были строиться по разным принципам. Даже «железо» требовалось разное. У нашей платформы управления доступом RooX UIDM исторические корни лежат в управлении доступом клиентов (CIAM, Customer Identity and Access Management), и мы хорошо знаем эти отличия, даже делали об этом доклад на одной из ваших конференций.
Об этих отличиях необходимо иметь представление, так как концепция Zero Trust практически приравняла сотрудников к клиентам, сблизив эти два мира. Поэтому некоторые технические решения для сотрудников можно делать, как раньше, а некоторые необходимо брать из современных CIAM-систем. Например, многофакторную адаптивную аутентификацию или идентификацию устройства пользователя.
Каковы основные элементы авторизации и аутентификации в концепции Zero Trust?
Алексей Хмельницкий: Zero Trust полагается на подходы, проверенные на практике. Например, для проверки доступа пользователя к какому-либо ресурсу рекомендуется применять авторизацию на основе комплексных правил (политик) доступа. Этот подход пришел на смену доступа на основе ролей и успешно реализован во многих системах, как проприетарных, так и с открытым исходным кодом. В частности, мы успешно запускали сложные модели авторизации в концепции Zero Trust, проингерировав в свою платформу управления доступом RooX UIDM технологию Open Policy Agent для централизованной авторизации.
Обязательным условием Zero Trust нужно считать многофакторную аутентификацию. Для проверки пользователя недостаточно проверить его логин и пароль. Необходимо выполнить проверку несколькими принципиально различными способами, называемыми `факторами`. Если основной способ доступа — логин и пароль, то вторым фактором может быть одноразовый код, который сотрудник получит на свой смартфон, проверка биометрии или даже специальное устройство-ключ. Даже в пределах одной компании сценарии аутентификации могут быть самыми разнообразными, в зависимости от пользователей, устройств доступа, уровня безопасности систем и даже конкретных обстоятельств получения доступа.
Здесь на помощь приходят наработки из области аутентификации для клиентов (CIAM). Они изначально ориентированы на «незнакомых» пользователей, и в них разработаны десятки методов аутентификации пользователей за пределами корпоративной сети. Возможности в плане сценариев аутентификации у систем CIAM шире, чем у традиционных систем контроля доступа сотрудников. Например, в RooX UIDM более 30 готовых пользовательских методов аутентификации пользователя, из которых собираются сценарии любой сложности. Кроме «чистых» методов можно еще учитывать различные параметры контекста входа — устройство, местоположение, силу нажатия на экран, если вход производится со смартфона, и другие — чтобы усилить аутентификацию.
Какие возможности открывает бизнесу внедрение политик Zero Trust в части управления доступом (возможно, дополнительные варианты размещения инфраструктуры, сокращение расходов на обслуживание и др.)?
Алексей Хмельницкий: В дополнение к сокращению потерь на удаленный доступ в долговременной перспективе, бизнес получает одно мощное преимущество — возможность использовать облачные и SaaS-продукты. Ведь с применением Zero Trust безопасность опирается не на периметр, а на доступ к приложениям. Если облачный сервис поддерживает современные методы аутентификации и контроля доступа, то его вполне можно использовать в качестве корпоративной системы. Отсутствие «периметра» означает свободу выбора.
Как ваша платформа RooX UIDM помогает в реализации концепции Zero Trust на практике?
Алексей Хмельницкий: Несмотря на то, что Zero Trust — это концепция, ориентированная на практическое применение, перевести на неё существующую инфраструктуру крупной компании — задача со звездочкой. Но при запуске нового проекта можно и нужно заложить архитектурные принципы Zero Trust.
Важно помнить, что Zero Trust — это не продукт и не готовое решение. Сначала компании предстоит приложить значительные аналитические и административные усилия, чтобы классифицировать всех пользователей и все ресурсы компании. Затем определить политики доступа пользователей к ресурсам, устройства доступа и решить много других вопросов.
Исходя из получившейся модели будет выбрана архитектура и набор конкретных решений для реализации концепции. RooX UIDM является отличной платформой для решения задач аутентификации и авторизации в концепции Zero Trust. Наш продукт развивался как универсальная система аутентификации для современных приложений в компаниях самого крупного масштаба.
Какая кадровая трансформация необходима российскому бизнесу, чтобы полноценно перейти на управление доступом в концепции Zero Trust? Каких специалистов не хватает?
Алексей Хмельницкий: Это очень правильный и болезненный вопрос. Как уже говорил, Zero Trust — это не какое-то решение, а принципиальный подход. Не существует одного готового решения, внедрение которого позволит перейти на новый принцип всей компании. Помимо подразделений информационной безопасности и эксплуатации ИТ-систем, потребуются определенные изменения и для команд разработки. Разработчики внутренних сервисов должны также применять практики безопасной разработки, ставшие нормой, например, при разработке личных кабинетов и интернет-банков.
Кроме разработки и внедрения решений силами наших штатных сотрудников мы предоставляем услугу аутстафа со спецификой безопасной разработки. Иногда получается гибридный формат, когда переход к формату аутстаф происходит после внедрения решения по аутентификации и авторизации. В любом случае и в фазе первоначальной разработки, и в фазе развития на проекте работают люди с опытом защиты персональных и другие чувствительных данных.
