Киберустойчивость – это способность организации обнаруживать кибератаки, оперативно на них реагировать и, самое главное, иметь возможность после них восстанавливаться. Важно понимать, что полной киберустойчивости достичь невозможно. Всегда есть гонка атакующих и защищающихся. Создаются новые векторы атак, появляются так называемые "черные лебеди" – негативные события, которых никто не ждал, но которые постфактум кажутся вполне объяснимыми. Так что риски остаются всегда и поэтому достичь стопроцентной безопасности невозможно, но можно максимально к ней приблизиться и сконцентрировать свои усилия на киберустойчивости тех бизнес-процессов, которые наиболее критичны для организации. А уже в рамках этих бизнес-процессов, а не в масштабах всей организации, можно принимать меры и внедрять средства безопасности и восстановления.
Контролировать огромные потоки данных, которые стали нашей повседневной реальностью, очень тяжело. Поэтому основной принцип киберустойчивости сейчас выглядит так: "По умолчанию не доверяй никому". Если раньше те, кто залогинился с учетной записью легитимного пользователя, считались доверенными априори, то сейчас это лишь одно из условий для получения ограниченного доступа к набору сервисов. И этот доступ следует пересматривать даже в рамках одной сессии подключения средствами мониторинга, выявления отклонений от исходных безопасных условий и реагирования на потенциальные инциденты.
Второй принцип – иметь механизмы для восстановления на случай кибератаки. Есть ряд специализированных решений, которые позволяют реализовать эти принципы.
Третий и основной принцип – выбор конкретных бизнес-сценариев, в отношении которых требуется внедрение ZTNA. Важно помнить, что киберустойчивость невозможно построить для всей организации целиком. Это приведет, по сути, либо к очень сложной и дорогой системе, либо к бесконечному проекту.
Принцип наименьших привилегий, который лежит в основе ZTNA, означает предоставление только того доступа, который необходим для реализации конкретного бизнес-сценария. Из этого вытекает необходимость гранулярного назначения прав и микросегментации сетей: получив доступ к сети, пользователь должен иметь доступ исключительно к тем сервисам и приложениям, которые ему положены по принципу минимальных привилегий для конкретного сценария.
Если бизнес-приложения построены с использованием технологий веб-сервисов, а такие решения сейчас составляют основную массу, требуется внедрение специализированных средств, таких как Web Application Firewall, способных разбирать запросы к веб-приложениям, выявлять специализированные векторы атак, нарушающих целостность данных или компрометирующих данные.
Также важен контроль пользовательских устройств на основе их профилей. Организация должна понимать, какие устройства закреплены за сотрудниками, и иметь их профили для исключения доступа с неизвестных и непроверенных устройств. Это один из сценариев реализации ZTNA для Bring Your Own Device: если устройство является личным, оно должно соответствовать корпоративным требованиям безопасности. Например, необходимо запрещать доступ с устройств с jailbreak (iOS) или root-доступом (Android), так как они более уязвимы к установке вредоносного ПО, способного незаметно передавать данные злоумышленникам.
Обязательным элементом стала многофакторная аутентификация. Парольная аутентификация должна быть усилена дополнительными факторами – токенами в приложениях или аппаратными токенами. Политики доступа должны строиться на основе User Entity (User ID), что позволяет сопоставить учетную запись конкретному сотруднику, даже если в разных системах используются различные логины. Это повышает удобство и гранулярность управления доступом в отношении конкретного сотрудника, а не отдельной его учетной записи в системе.
После внедрения указанных принципов необходимо организовать непрерывный мониторинг инцидентов с помощью SIEM-систем. В комбинации с IRP и хостовым реагированием возможно автоматическое предотвращение распространения атак без участия человека. Не менее важны механизмы бекапирования: резервное копирование хостов, данных и приложений, контроль и хранение конфигураций в изолированных хранилищах для быстрого восстановления инфраструктуры в состояние "до атаки".
Соотношение заключается прежде всего в предметной привязке нормативных требований к конкретным системам. В сегменте КИИ нормы ФСТЭК России (в т. ч. 187-ФЗ и подзаконные акты) адресованы сегментам АСУ ТП: это задает явные границы и концентрирует меры внутри выделенного периметра – фактически задается базовый принцип ZTNA в виде определения бизнес-процессов, сегментации и ограничения доступа. Набор требуемых средств и мер во многом пересекается с ZTNA, хотя отдельного акцента на жизнестойкости системы обычно нет. Тем не менее за счет совпадения механизмов безопасности и широкого перечня организационно-технических мер требования российских регуляторов не противоречат и в целом следуют логике Zero Trust Network Access.
То же самое справедливо для государственных информационных систем: приказы ФСТЭК по защите ГИС детально отвечают на вопросы "что защищать" и "как защищать" и включают принципы минимальных полномочий. Прямых ссылок на термины "киберустойчивость" или "Zero Trust" может не быть, однако заложенная в документах логика и практические предписания совпадают с методиками и принципами, применяемыми для киберустойчивости и ZTNA.
Да, такие методики есть, в том числе разработки международных институтов, включая документы NIST. В частности, NIST SP 800-207 описывает логику и общую архитектуру Zero Trust. Также применяется подход ZTX (Zero Trust Extended) – фреймворк аналитического агентства Forrester, раскрывающий принципы Zero Trust и их расширенную реализацию, или Google's BeyondCorp – как доказательство того, что ZTNA возможно построить в масштабах крупнейшей корпорации. В том числе многие коммерческие компании-производители систем информационной безопасности предлагают собственные методики построения ZTNA.
По итогам международного форума Kazan Digital Week.
Иллюстрация к статье сгенерирована нейросетью Kandinsky