Приказ ФСТЭК России № 117: от формального комплаенса к измеримой безопасности

Новый регуляторный акт смещает акцент с бумажного соответствия на реальные технические меры. Можно выделить 10 ключевых изменений:

1. Масштабирование периметра защиты. Регламент охватывает не только узаконенные ГИС, но и весь массив ведомственных ИТ-ресурсов, включая системы бюджетных организаций и унитарных предприятий, а также любые платформы, потребляющие информацию из государственного контура. Под действие нормы не попадают лишь объекты спецслужб, высших эшелонов власти и управления оборонным потенциалом.
2. Внедрение количественной оценки безопасности. Защищённость становится измеримой. Регулятор вводит обязательные ключевые показатели: индекс защищённости (КЗИ) и индекс зрелости ИБ-процессов (ПЗИ). Отчёты о вычислениях отправляют во ФСТЭК в пятидневный срок после аудита, поэтому компании обязаны внедрить автоматический сбор телеметрии.
3. Актуализация технологического стека. Перечень защитных механизмов расширен до 18 категорий. Впервые вводится обязательная регламентация таких сфер, как контейнеризация (Kubernetes, Docker), безопасность программных интерфейсов (API), интернет вещей (IoT), мобильные терминалы, а также нейросети и алгоритмы машинного обучения.
4. Радикальные технологические запреты. Во всех подконтрольных сегментах вводится полный запрет на зарубежное программное обеспечение. Обработку критически значимой информации полностью выводят за рамки публичных облачных платформ. Разрешены исключительно сертифицированные средства криптографической и технической защиты отечественного производства с локальной поддержкой. Для искусственного интеллекта предписано использовать только доверенное российское ПО.
5. Дисциплина устранения уязвимостей. Автоматизированные сканеры становятся обязательными. Регулятор устанавливает жесткие сроки ликвидации дефектов, а также обязывает ежемесячно проводить инвентаризацию активов и передавать информацию о новых уязвимостях регулятору в течение пяти рабочих дней.
6. Кадровый ценз. Не менее 30% сотрудников подразделения информационной безопасности должны иметь профильное образование или переподготовку. Аттестация всего персонала проводится раз в три года, а любой инцидент требует внепланового инструктажа. Доступ к управлению системами закрыт для лиц без подтверждённой квалификации.
7. Безопасность разработки (SDLC). Требования ИБ применяются на всех этапах разработки и эксплуатации продукта. При внутренней разработке необходимо следовать ГОСТ Р 6939-2024, а при передаче задач внешнему исполнителю требования безопасной разработки обязаны фиксироваться в контракте.
8. Смежная ответственность контрагентов. Аутсорсинг больше не снимает ответственность с оператора. Подрядчики включаются в общий контур безопасности, обязаны соблюдать политику ИБ заказчика и зафиксировать требования по защите в договорах.
9. Взаимодействие с ГосСОПКА. Операторы обязаны поддерживать непрерывное взаимодействие с ГосСОПКА напрямую или через коммерческие центры мониторинга, имеющие соглашение с НКЦКИ.
10. Правовые последствия нарушений. Невыполнение требований влечёт приостановку работы несоответствующих систем, а также административные штрафы по ст. 13.12 КоАП РФ и штрафы за утечки данных по ст. 13.11 КоАП РФ.

Если приказ уже действует, а процессы в компании ещё не перестроены, необходимо выполнить следующие шаги:

1. Собрать команду и назначить ответственного. Сформируйте отдел информационной безопасности так, чтобы профильное образование или переподготовка были минимум у 30% сотрудников, и утвердите общую политику защиты данных.
2. Обновить внутренние правила. Пересмотрите регламенты доступа к системам, удалённой работы, резервного копирования и безопасной разработки, а также пропишите требования по защите информации во всех договорах с подрядчиками.
3. Настроить мониторинг угроз. Наладьте автоматическую сверку систем с банком данных ФСТЭК (БДУ) и внедрите регламент: сообщать регулятору о любой найденной уникальной уязвимости в течение пяти рабочих дней.
4. Подготовиться к сбоям. Обеспечьте восстановление критически важных функций систем по установленным классам и регулярно проводите учебные тренировки для персонала.
5. Разработать новые инструкции. Создайте правила безопасного применения искусственного интеллекта (без передачи чувствительных данных вовне), интернета вещей и контейнеров.
6. Ввести регулярную отчётность. Организуйте постоянный расчёт показателей защищённости (КЗИ) и зрелости процессов (ПЗИ) с отправкой результатов во ФСТЭК России.
7. Провести аттестацию ГИС. Пройдите проверку государственных информационных систем на соответствие требованиям приказа № 117.
8. Обучить персонал. Запустите регулярные тренинги по кибергигиене и проверьте готовность сотрудников к атакам с применением социальной инженерии.

Критическая точка любой информационной системы — контур входа пользователей. Приказ ФСТЭК России № 117 усиливает требования к управлению субъектами доступа и формализует конкретный набор защитных мер. Для успешного прохождения аттестации ГИС необходимо реализовать три ключевые группы требований:

• ИАФ (идентификация и аутентификация): правила, по которым система проверяет подлинность пользователя перед входом.
• УПД (управление доступом): принципы разграничения прав, назначения ролей и контроля полномочий внутри системы.
• РСБ (регистрация событий безопасности): требование непрерывно фиксировать все ключевые действия в журналах для анализа инцидентов.

В распределённых системах разрозненные локальные учётные записи снижают безопасность и повышают расходы на обслуживание. Эти проблемы решает единый сервер аутентификации Blitz Identity Provider — отечественное решение класса Identity and Access Management (включено в реестр российского ПО под № 842).

Blitz Identity Provider имеет действующий сертификат ФСТЭК России (№ 4525 от 10.03.2022), подтверждающий соответствие требованиям по безопасности информации по 4 уровню доверия. Это гарантирует отсутствие недекларированных возможностей в средстве идентификации и позволяет применять его в системах до 1 класса защищённости включительно.

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

1. Пользователь вводит учётные данные на портале, и запрос направляется на сервер Blitz Identity Provider.
2. Сервер проверяет пароль и запрашивает второй фактор (push-уведомление в мобильное приложение или OTP-код).
3. После успешной проверки Blitz Identity Provider выдаёт JWT-токены порталу.
4. При обнаружении аномальной активности (например, входа из нетипичного региона) Blitz Identity Provider блокирует доступ пользователя ко всем подсистемам, выполняя требования приказа № 117 по оперативному реагированию на угрозы (мера РСБ.5).

Приказ ФСТЭК № 117 делает ставку на архитектурную целостность систем защиты. Попытки реализовать функции аутентификации внутри самописных модулей приложений больше не отвечают требованиям регулятора.

Интеграция специализированного отечественного решения Blitz Identity Provider позволяет:

• сократить сроки подготовки системы к аттестации по новым требованиям;
• вынести риски обработки аутентификационных данных на продукт с подтверждённым соответствием;
• обеспечить масштабируемость решения при дальнейшем развитии функционала государственной системы.

Переходный период до вступления приказа в силу — удобное время для рефакторинга контура безопасности и миграции на современные стандарты управления идентификацией.

Используемые термины

Kubernetes — платформа для автоматического запуска, масштабирования и управления контейнерными приложениями.
Docker — программная платформа для автоматизации разработки, доставки и запуска приложений в изолированных средах, называемых контейнерами.
API — Application Programming Interface, программный интерфейс, который позволяет одной компьютерной программе общаться с другой.
IoT — интернет вещей, сеть физических объектов («вещей»), оснащённых датчиками, чипами и модулями связи для обмена данными через интернет без участия человека.
SDLC — структурированный процесс планирования, создания, тестирования и обслуживания программных продуктов.
Identity and Access Management, IAM — управление идентификацией и контролем доступа.
SSO — Single Sign-On, технология единого входа.
MFA — Multi-Factor Authentication, многофакторная аутентификация.
OTP — One-Time Password, уникальный временный пароль, который действует только для одного сеанса входа.
Push — короткое всплывающее сообщение, которое сайт или мобильное приложение отправляет на устройство пользователя.
SAML — Security Assertion Markup Language, открытый стандарт для безопасного обмена данными об аутентификации и авторизации между системами.
OIDC — OpenID Connect, протокол аутентификации, который позволяет приложениям безопасно узнавать личность пользователя с помощью сторонних сервисов.
OAuth 2.0 — стандартный протокол авторизации, который позволяет приложению получать доступ к данным пользователя на другом сервисе без передачи логина и пароля.
CRM — Customer Relationship Management, программа для автоматизации работы с клиентами и управления продажами.
JWT — JSON Web Token, безопасный открытый стандарт для передачи информации между клиентом и сервером.