Детальный анализ изменений 187-ФЗ и проекта Постановления Правительства РФ № 127
Укрепление безопасности КИИ
Услуги
Как бизнесу защититься от киберугроз и не раздуть бюджет
Кейс компании «ДОМА» и УЦСБ SOC
Сервисы
Apsafe
Облачная DevSecOps-платформа для непрерывного анализа защищенности приложений
Главная / О Центре / Новости /FAQ: ответы на вопросы к вебинару «Zero Trust: современное прочтение правила “доверяй, но проверяй”»








FAQ: ответы на вопросы к вебинару «Zero Trust: современное прочтение правила “доверяй, но проверяй”»

21 октября 2025

9 сентября прошел вебинар «Zero Trust: современное прочтение правила “доверяй, но проверяй”». В ходе обсуждения участники вместе с экспертами УЦСБ разбирались, почему старые подходы больше не работают, что из себя на самом деле представляет архитектура нулевого доверия и как она воплощается в конкретных технологиях на примере российского продукта Efros DefOps.

В этом материале мы собрали и подготовили ответы на самые интересные вопросы от участников вебинара.

Гносеологическое противоречие: никому и ничему доверять нельзя, но если очень хочется, то можно (в соответствии с политикой безопасности).

Строго говоря, концепция Zero Trust, несмотря на название, не означает «никому не доверяй». Это не абсолютный запрет, а система явного, продуманного доверия, которое не предоставляется по умолчанию (например, потому что устройство находится внутри корпоративной сети), а выдается на основе строгого соблюдения политик безопасности, проверки контекста и постоянного мониторинга. Политика безопасности как раз и является формализованным правилом, определяющим, когда и кому «можно доверять».

Если концепция Zero Trust гласит «никому не доверяй», то как тогда построить систему, которая должна доверять человеку, принимающему решение о предоставлении доступа? С учетом + и - концепции Zero Trust?

Система не доверяет человеку «на слово». Процесс принятия решений о доступе должен быть автоматизирован и основан на данных. Человек (например, администратор) не предоставляет доступ произвольно, а действует в рамках строгих регламентов и политик, которые сами по себе являются проявлением принципа «проверяй все». Его действия должны быть задокументированы, проконтролированы и также подвергаться аудиту. Таким образом, доверие смещается с конкретного человека на корректность и надежность всей системы контроля и управления доступом.

Как убедить директора и бухгалтера в необходимости перехода на Zero Trust, учитывая значительные инвестиции?

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

А мы не доверяем даже сотрудникам службы ИБ? Или только другим?

В рамках концепции Zero Trust никому не доверяют по умолчанию, включая сотрудников ИБ и администраторов. Для них особенно важен принцип минимальных привилегий (Just Enough Access). Учетная запись администратора не должна использоваться для проверки почты, а доступ к критичным системам должен предоставляться по необходимости (JIT — Just-In-Time) и с использование многофакторной аутентификации. Это защищает как от злонамеренных действий, так и от компрометации учетных данных администратора.

Какие вы видите возможности аварийного восстановления работоспособности при сбое систем, реализующих концепцию ZTNA?

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

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

В Efros Defence Operations каким образом построено отслеживание новых уязвимостей?

Efros DefOps обновляет базы уязвимостей с собственных серверов Газинформсервис, которые аккумулируют информацию из различных источников, таких как БДУ ФСТЭК, CVE, OVAL, БДУ производителей и других различных открытых источников или специализированных баз данных. При обнаружении данных о вендоре и версии ПО в ходе сканирования объектов защиты, Efros DefOps предоставляет релевантные уязвимости для конкретных версий программного обеспечения.

Уязвимости по версионности контролируются в NA (для АСО) и в ICC (для ОС).
В подсистеме VC реализован централизованных аудит уязвимостей для всех контролируемых устройств. Реализован автоматический сбор информации об ИТ-активах из сканеров, получение данных об уязвимостях по портам. Возможен расчет возможных векторов атак с учетом модели нарушителя и визуализация вектора на интерактивной карте.

Efros Defence Operations является российской разработкой? Опыт каких вендоров и решений предыдущих поколений использовался?

Efros DefOps является российской разработкой и включен в реестр российского ПО. Решение под текущим названием появилось в 2022 году. Сам продукт развивается с начала 2010-х годов, первоначальное было два продукта — Efros Config Inspector (CI) и Efros Access Control Server (AC) — с 2022 года они вошли в состав обновленной платформы Efros DefOps. Развитие этих функциональностей продолжилось в модуле EDO Network Assuarance, EDO Firewall Assuarance и EDO Network Access Control. Сейчас в них реализовано и добавлено множество новых функциональных возможностей.

На текущий момент в состав многофункционального комплекса Efros Defence Operations входит шесть программных модулей.

Позволяет ли решение Efros DefOps в полной мере выполнить требование Положения Банка России 821-П о взаимной (двусторонней) аутентификации участников СВТ операторов по переводу денежных средств?

Нет, не позволяет.
Речь шла о двусторонней аутентификации в разрезе Network Access Control и про взаимную аутентификацию сервера и клиента с использованием цифровых сертификатов, при подключении клиента к сети организации. Цифровые сертификаты могут быть выпущены в Удостоверяющем центре (УЦ), который есть в Efros DefOps модуль NAC. Но использовать этот УЦ для взаимной, двусторонней, аутентификации участников СВТ операторов по переводу денежных средств вы не можете, т.к. УЦ который есть в Efros DefOps модуль NAC не осуществляет выпуск цифровых сертификатов по ГОСТ.

Есть ли опыт внедрения в распределенную сеть с удаленными офисами и сотрудниками, разным оборудованием и ОС?

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

Есть возможность строить графическую модель сети с отражением политик и подсветкой слабых мест?

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

Есть возможность строить графическую модель сети с отражением политик и подсветкой слабых мест?

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

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

Анализируются ли ACL на сетевом оборудовании? Или только на МСЭ (межсетевых экранах)?

Да, анализируются ACL (access-листы) на всем сетевом оборудовании, включая коммутаторы и маршрутизаторы, а не только на межсетевых экранах.

Напишите нам на cybersec@ussc.ru или оставьте заявку

Нужна консультация по внедрению DevSecOps?

Нажимая кнопку «Отправить», я даю свое согласие на обработку моих персональных данных, в соответствии с Федеральным законом от 27.07.2006 года №152-ФЗ «О персональных данных», на условиях и для целей, определенных в Согласии на обработку персональных данных