Меры защиты информации по приказам ФСТЭК: организационные, технические, физические

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

В этой статье разберём классификацию мер защиты по приказу ФСТЭК №117 целиком: организационные меры (группы I–IV), технические меры (группы V–XI), физические требования, алгоритм выбора применимых мер и подход к автоматизации контроля через SGRC-платформу. Материал рассчитан на CISO, руководителей ИБ-подразделений и специалистов, которые готовятся к аттестации ГИС или выстраивают систему управления соответствием.

Что такое меры защиты информации и зачем они нужны

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

Зачем нужна систематизация мер? Без структурированного перечня организации сталкиваются с хаосом: одни требования дублируются, другие упускаются, ответственность размыта между ИТ и ИБ, доказательства выполнения не собираются. При проверке регулятора или аттестационных испытаниях отсутствие доказательной базы равнозначно невыполнению меры — даже если защитный механизм фактически функционирует.

Приказ ФСТЭК №117 (для ГИС) и аналогичные приказы №21 (ИСПДн), №239 (КИИ), №31 (АСУ ТП) формализуют меры защиты, создавая единый язык между оператором системы, аттестационным органом и регулятором. SGRC-платформа добавляет операционный слой: переводит нормативный перечень в управляемые задачи с ответственными, сроками и доказательствами. Запросите демо и посмотрите, как это работает для вашего класса ГИС.

Нормативная основа: приказы ФСТЭК и группы мер

Меры защиты информации в ГИС определяются приказом ФСТЭК России №117 от 11 апреля 2025 г. — актуальным документом для всех ГИС, пришедшим на смену №117 (2013). Оба документа используют единую структуру: меры организованы в группы, каждая группа имеет буквенный идентификатор и содержит конкретные меры, обозначаемые комбинацией буква-цифра (например, ИАФ.1, УПД.5, РСБ.3).

Сводная таблица групп мер защиты

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

Классы защищённости ГИС: К4 — низшая степень важности, К1 — высшая. Чем выше класс, тем более полный набор мер применяется и тем строже требования к используемым средствам защиты (сертификация по более высоким уровням доверия).

I–IV группы: организационные меры

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

I. Управление информационной безопасностью (ОИБ)

Группа ОИБ охватывает системный уровень управления защитой информации в организации.

Политика информационной безопасности (ОИБ.1). Документ верхнего уровня, определяющий цели, принципы и направления деятельности в области ИБ. Политика утверждается руководителем организации и доводится до всего персонала. Для ГИС класса К1 требуется регулярный пересмотр политики (не реже одного раза в год).

Назначение ответственных (ОИБ.2). Формальное назначение администратора безопасности и оператора ГИС приказом по организации с определением их полномочий и ответственности. Без документально закреплённой ответственности аттестационный орган фиксирует несоответствие, даже если фактически функции выполняются.

Классификация информации (ОИБ.3). Определение состава обрабатываемой информации, её категорий (государственная тайна, персональные данные, служебная информация) и требований к защите каждой категории.

Обучение и осведомлённость персонала (ОИБ.4). Инструктажи, обучение правилам безопасной работы, проверка знаний. Для систем высоких классов — регулярные тренинги и тестирование персонала, имеющего доступ к критичным ресурсам.

Внутренний аудит (ОИБ.5+). Для классов К2–К1 обязательны периодические проверки соблюдения требований политики ИБ и выполнения мер защиты. Результаты аудита документируются и хранятся в качестве доказательной базы.

II. Управление конфигурациями (УКФ)

Группа УКФ направлена на предотвращение несанкционированных изменений конфигурации ИС, которые могут ослабить защиту.

Базовая конфигурация (УКФ.1). Разработка и документирование эталонной конфигурации для каждого типа компонентов ИС: серверов, рабочих станций, сетевого оборудования, средств защиты. Эталонная конфигурация фиксирует «золотой стандарт» настроек безопасности.

Контроль изменений (УКФ.2). Регламентированный процесс внесения изменений в конфигурацию компонентов ИС: согласование, тестирование, документирование, контроль результата. Несогласованные изменения должны обнаруживаться и отменяться.

Инвентаризация компонентов (УКФ.3). Актуальный реестр всех компонентов ИС с указанием их характеристик, версий ПО и конфигурационных параметров. Без актуальной инвентаризации невозможно ни управление уязвимостями, ни контроль изменений.

Анализ конфигурации (УКФ.4+). Для высоких классов — периодический анализ конфигурации компонентов на предмет отклонений от эталона и наличия уязвимостей конфигурации (неиспользуемые службы, слабые настройки криптографии, избыточные права).

III. Управление обновлениями (ОБС)

Устаревшее программное обеспечение с известными уязвимостями — одна из наиболее распространённых точек входа для атакующих. Группа ОБС систематизирует процесс обновления.

Мониторинг уязвимостей (ОБС.1). Отслеживание публикаций о новых уязвимостях в компонентах ИС через БДУ ФСТЭК, бюллетени вендоров и другие источники. SGRC-платформа автоматизирует этот мониторинг, интегрируясь с БДУ и уведомляя ответственных об уязвимостях в инвентаризированных компонентах.

Управление патчами (ОБС.2). Регламентированный процесс тестирования и установки обновлений: получение обновления → тестирование на тестовой среде → согласование окна установки → установка на продуктивную систему → верификация. Сроки устранения определяются критичностью уязвимости по CVSS v3.1.

Контроль версий ПО (ОБС.3). Учёт версий всех программных компонентов ИС. Особое внимание — к компонентам с истёкшим сроком поддержки (EOL): они не получают патчи безопасности и требуют компенсирующих мер или замены.

Тестирование обновлений (ОБС.4+). Для систем высоких классов — обязательное тестирование обновлений на изолированном стенде перед установкой в продуктивную среду. Критически важно для объектов КИИ и АСУ ТП, где некорректный патч может нарушить технологический процесс.

IV. Обеспечение непрерывности (НПД)

Группа НПД обеспечивает восстановление работоспособности ГИС после инцидентов, сбоев и катастроф.

Резервное копирование (НПД.1). Регулярное создание резервных копий критичных данных и конфигурационных файлов. Параметры: частота копирования (ежедневно, еженедельно), место хранения (локальное, удалённое), срок хранения копий. Для классов К1–К2 — хранение копий на территориально удалённом объекте.

Планирование восстановления (НПД.2). Разработка и актуализация плана восстановления после сбоев (DRP — Disaster Recovery Plan) с указанием ответственных, последовательности действий, контрольных точек и целевых показателей: RTO (целевое время восстановления) и RPO (допустимая потеря данных).

Тестирование восстановления (НПД.3). Периодическое тестирование процедур восстановления из резервных копий. Нетестированный план восстановления — фикция: ИТ-команда обнаружит проблемы только в момент реального инцидента, когда дорога каждая минута.

Резервные мощности (НПД.4+). Для систем высоких классов — наличие резервных каналов связи, резервного источника электропитания, резервного вычислительного ресурса. Целевое значение доступности (SLA) фиксируется в техническом паспорте системы.

V–XI группы: технические меры защиты

Технические меры реализуются с использованием программных и программно-аппаратных средств защиты информации. Для ГИС класса К1 большинство применяемых СрЗИ должны иметь сертификат соответствия ФСТЭК России по требованиям безопасности.

V. Идентификация и аутентификация (ИАФ)

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

Идентификация субъектов (ИАФ.1). Каждый пользователь, процесс и устройство, получающие доступ к ИС, должны иметь уникальный идентификатор. Обезличенные учётные записи (shared accounts типа «admin», «user1») недопустимы в ГИС.

Аутентификация пользователей (ИАФ.2). Проверка подлинности субъекта при каждом входе в систему. Парольная аутентификация — базовый уровень. Требования к паролям: минимальная длина (от 8 символов для К4, от 12 для К1), сложность (буквы, цифры, спецсимволы), срок действия (не более 90 дней), запрет повторного использования последних N паролей.

Многофакторная аутентификация (ИАФ.3+). Для систем класса К2 и К1 обязательна многофакторная аутентификация для привилегированных пользователей (администраторов, операторов с расширенными правами). Второй фактор: аппаратные токены (ГОСТ-сертифицированные), смарт-карты, одноразовые пароли.

Аутентификация устройств (ИАФ.4+). Для высоких классов — аутентификация не только пользователей, но и устройств (рабочих станций, серверов, сетевого оборудования), обращающихся к ресурсам ГИС. Реализуется через сертификаты на устройство или протоколы типа IEEE 802.1X.

Защита аутентификационной информации (ИАФ.5). Хранение паролей в хешированном виде (алгоритмы семейства SHA-2 или ГОСТ), запрет передачи паролей в открытом виде по сети, защита от атак перебора (блокировка учётной записи после N неудачных попыток).

VI. Управление доступом (УПД)

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

Матрица разграничения доступа (УПД.1). Документированное описание того, какой субъект (пользователь, роль, процесс) к каким объектам (файлам, папкам, базам данных, сервисам) имеет какой доступ (чтение, запись, выполнение, удаление). Матрица является основой для настройки технических средств контроля доступа.

Управление привилегированными пользователями (УПД.2). Учёт учётных записей с административными привилегиями. Для выполнения административных задач используются выделенные привилегированные учётные записи (не совмещаемые с рабочими). PAM-решения (Privileged Access Management) автоматизируют контроль.

Разграничение доступа к ресурсам (УПД.3–УПД.7). Реализация матрицы разграничения через технические средства: права на файловую систему, права СУБД, сетевые ACL, настройки приложений. Особые требования — к доступу к персональным данным и другой защищаемой информации.

Контроль потоков информации (УПД.8+). Для систем К1–К2 — управление информационными потоками между компонентами ИС, предотвращение несанкционированной передачи данных между сегментами разной категории (например, из ГИС во внешние системы).

Управление внешними подключениями (УПД.9). Контроль удалённого доступа к ИС: VPN с сильной аутентификацией, ограничение списка разрешённых внешних подключений, протоколирование всех сессий удалённого доступа.

VII. Регистрация событий безопасности (РСБ)

Без журналирования расследование инцидентов невозможно, соответствие требованиям недоказуемо.

Перечень регистрируемых событий (РСБ.1). Определение и документирование перечня событий, подлежащих обязательной регистрации: входы/выходы пользователей, изменение прав доступа, действия привилегированных пользователей, запуск и остановка критичных процессов, обращения к защищаемым ресурсам, события срабатывания средств защиты.

Централизованный сбор журналов (РСБ.2). Для ГИС средних и высоких классов — сбор журналов со всех компонентов ИС в централизованное хранилище (SIEM или защищённое хранилище журналов). Цели: предотвращение уничтожения журналов при компрометации компонента, корреляция событий из разных источников.

Защита журналов от модификации (РСБ.3). Обеспечение целостности и неизменности зарегистрированных событий. Технические механизмы: хранение в append-only хранилище, цифровая подпись записей, отдельный сервер журналирования с ограниченным доступом.

Анализ событий (РСБ.4+). Для систем К1–К2 — регулярный анализ журналов событий с целью выявления аномалий и признаков атак. Автоматизируется через SIEM-системы (MaxPatrol SIEM, RuSIEM, PT SIEM).

Срок хранения журналов (РСБ.5). Хранение журналов событий в течение установленного срока: для большинства ГИС — не менее 1 года, для объектов КИИ — требования определяются приказом №239. Архивные журналы должны быть доступны для расследования инцидентов.

VIII. Антивирусная защита (АВЗ)

Установка средств антивирусной защиты (АВЗ.1). Антивирусные средства устанавливаются на все компоненты ИС, где возможно выполнение вредоносного кода: рабочие станции, серверы приложений, почтовые серверы, серверы хранения файлов. Для ГИС К1–К2 применяемые антивирусные средства должны иметь сертификат ФСТЭК.

Обновление антивирусных баз (АВЗ.2). Регулярное (ежедневное) обновление сигнатурных баз антивирусного средства. Для систем с ограниченным доступом в интернет — организация локального сервера обновлений (update mirror).

Полное сканирование (АВЗ.3). Периодическое (еженедельное или ежемесячное) полное сканирование файловых систем защищаемых компонентов в дополнение к постоянной защите в реальном времени.

Реагирование на инциденты антивирусной защиты (АВЗ.4+). Для высоких классов — определённый порядок действий при обнаружении вредоносного кода: изоляция заражённого компонента, уведомление ответственных, расследование, восстановление.

IX. Обнаружение вторжений (СОВ)

Система обнаружения вторжений (СОВ.1). Развёртывание и настройка IDS/IPS (системы обнаружения/предотвращения вторжений). Размещение: на сетевом периметре (network IDS) и/или на хостах (host IDS). Для ГИС К1 применяемые СОВ должны быть сертифицированы ФСТЭК.

Обновление сигнатур (СОВ.2). Регулярное обновление баз сигнатур атак. Устаревшие сигнатуры не обнаруживают новые векторы атак.

Анализ оповещений (СОВ.3+). Мониторинг и своевременная обработка оповещений СОВ. Без процесса обработки СОВ генерирует предупреждения в пустоту.

Тонкая настройка (СОВ.4+). Для систем высоких классов — периодическая корректировка правил и сигнатур с учётом актуальной модели угроз и особенностей защищаемой инфраструктуры. Минимизация ложных срабатываний.

X. Межсетевое экранирование (МЭ)

Межсетевой экран на периметре (МЭ.1). Контроль входящего и исходящего трафика на границе ГИС с внешними сетями (интернет, другие ИС). Правила фильтрации реализуют принцип «запрещено всё, что не разрешено явно».

Сегментация сети (МЭ.2). Разделение ИС на сегменты (DMZ, внутренняя сеть, сегмент СУБД, сегмент управления) с контролем трафика между ними. Компрометация одного сегмента не должна автоматически давать доступ к остальным.

Правила фильтрации (МЭ.3). Документирование действующих правил МЭ, их периодический пересмотр, удаление устаревших разрешающих правил (накопление «мусорных» правил — типичная проблема при ручном управлении).

Журналирование трафика (МЭ.4+). Для систем К1–К2 — ведение журнала попыток несанкционированных подключений и срабатываний правил запрета. Журналы МЭ — ключевой источник данных для расследования инцидентов.

XI. Защита каналов передачи (ЗКС)

Шифрование каналов (ЗКС.1). Защита данных, передаваемых по каналам связи, с использованием криптографических протоколов. Для ГИС, обрабатывающих служебную информацию ограниченного распространения, — использование отечественной криптографии (ГОСТ 28147-89, ГОСТ Р 34.10-2012). Сертифицированные СКЗИ: КриптоПро, ViPNet, Континент.

VPN для удалённого доступа (ЗКС.2). Организация защищённых виртуальных частных сетей для удалённых подключений пользователей и подключения территориально распределённых объектов ИС.

Защита от перехвата (ЗКС.3). Меры по предотвращению несанкционированного перехвата трафика: использование коммутируемых сетей вместо концентраторов, физическая защита кабельной инфраструктуры, контроль портов коммутаторов.

Физические меры защиты (дополнительные требования)

Физические меры защиты информации в ГИС не выделены в отдельную группу приказа №117, но являются обязательным элементом системы защиты.

Контроль физического доступа. Серверные помещения и помещения, в которых размещены компоненты ГИС, должны быть оборудованы системой контроля и управления доступом (СКУД): кодовые замки, карточные ридеры, биометрический контроль. Журнал физического доступа ведётся и хранится.

Видеонаблюдение. Серверные помещения оборудуются камерами видеонаблюдения с записью и хранением видеоархива. Для ГИС К1 — архив не менее 30 дней.

Защита от несанкционированного выноса. Учёт и маркировка носителей информации. Запрет на использование неучтённых внешних носителей (USB-флеш, внешние HDD). Для высоких классов — технические блокировки USB-портов.

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

Защита от утечки по техническим каналам. Для ГИС, обрабатывающих сведения ограниченного доступа, — специальные требования к экранированию помещений, электромагнитной совместимости и предотвращению утечки по акустическим и виброакустическим каналам (ПЭМИН).

Как выбрать применимые меры для вашей ИС

Выбор мер защиты — не механическое применение таблицы из приказа. Это аналитический процесс, результатом которого является индивидуальный перечень мер для конкретной ИС с учётом её особенностей и актуальных угроз.

Алгоритм выбора мер защиты

Шаг 1. Определение класса ГИС.

Класс ГИС определяется на основе двух параметров: масштаба системы (федеральная, региональная, объектовая) и категории обрабатываемой информации (информация о частной жизни граждан, служебная информация, информация без ограничений). Для ГИС класса К1 применяется наиболее полный набор мер.

Шаг 2. Выбор базового набора мер.

Из таблиц приказа №117 для установленного класса выбирается базовый набор мер. Это отправная точка — конкретные меры из каждой группы, обязательные для данного класса.

Шаг 3. Адаптация к модели угроз.

Базовый набор корректируется с учётом актуальных угроз из модели угроз и нарушителя, разработанной для данной ИС на основе БДУ ФСТЭК. Актуальные угрозы и уязвимости — в реестре БДУ ФСТЭК. Если угроза из модели не нейтрализуется базовым набором — добавляются дополнительные меры. Если угроза неактуальна для данной системы — мера может быть исключена с обоснованием.

Шаг 4. Введение компенсирующих мер.

Если базовая мера неприменима по техническим причинам (например, невозможно установить антивирус на компонент АСУ ТП в режиме реального времени), вводится компенсирующая мера, обеспечивающая тот же уровень защиты. Обоснование документируется.

Шаг 5. Документирование перечня мер.

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

Типичные ошибки при выборе мер

• Применение полного базового набора без адаптации к модели угроз — приводит к избыточным мерам и неоправданным затратам.
• Исключение мер без документированного обоснования — аттестатор расценивает как невыполнение требований.
• Выбор мер без учёта архитектуры системы — меры, которые невозможно реализовать на существующей инфраструктуре, создают проблемы при аттестации.
• Игнорирование взаимосвязей между мерами — некоторые меры являются предусловием для других (инвентаризация → управление уязвимостями, матрица доступа → управление доступом).

Как SGRC-платформа автоматизирует контроль выполнения мер

Ручное управление перечнем из 80–150 мер защиты — задача, масштабируемость которой ограничена. При первоначальной аттестации управление ещё возможно вручную. При плановой переаттестации через 3 года, когда инфраструктура изменилась, состав мер обновился, а ответственные сменились — ручной подход приводит к системным несоответствиям.

Что автоматизирует SGRC-платформа

Формирование перечня применимых мер. На основе класса ГИС и параметров системы платформа автоматически формирует перечень мер, применимых к данной ИС. Перечень структурирован по группам (I–XI), каждая мера имеет описание и статус выполнения.

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

Расчёт КЗИ (коэффициента защищённости информации). Платформа автоматически рассчитывает КЗИ на основе статуса выполнения мер и их весовых коэффициентов. CISO видит на дашборде текущий уровень защищённости и динамику его изменения.

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

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

Интеграция с управлением уязвимостями. Меры группы ОБС и СОВ связываются с модулем управления уязвимостями: обнаруженные уязвимости автоматически отражаются в статусе соответствующих мер.

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

Подробнее о возможностях платформы в части соответствия требованиям ФСТЭК и автоматизации аудита ИБ. Запросите демо и увидьте, как платформа формирует доказательную базу для аттестации в действии.

FAQ

Сколько групп мер защиты в приказе ФСТЭК №117?

В приказе ФСТЭК №117 определено 11 групп мер защиты (I–XI). Группы I–IV охватывают организационные меры: управление ИБ, конфигурациями, обновлениями и непрерывностью. Группы V–XI — технические меры: идентификация и аутентификация, управление доступом, регистрация событий, антивирусная защита, обнаружение вторжений, межсетевое экранирование и защита каналов передачи. Число конкретных мер в каждой группе зависит от класса ГИС: чем выше класс, тем больше обязательных мер.

Что относится к организационным мерам защиты по ФСТЭК?

К организационным мерам защиты по приказу ФСТЭК №117 относятся четыре группы: I — Управление информационной безопасностью (политики, регламенты, назначение ответственных); II — Управление конфигурациями (эталонные конфигурации, контроль изменений); III — Управление обновлениями (своевременная установка патчей, контроль версий ПО); IV — Планирование непрерывности (планы восстановления, резервное копирование). Дополнительно организационные меры включают обучение и повышение осведомлённости персонала в области ИБ.

Что относится к техническим мерам защиты по ФСТЭК?

Технические меры защиты по приказу ФСТЭК №117 охватывают семь групп (V–XI): V — Идентификация и аутентификация пользователей и процессов (ИАФ); VI — Управление доступом субъектов к объектам (УПД); VII — Регистрация событий безопасности и их анализ (РСБ); VIII — Антивирусная защита (АВЗ); IX — Обнаружение и предотвращение вторжений (СОВ); X — Межсетевое экранирование (МЭ); XI — Защита каналов передачи данных (ЗКС). Каждая группа содержит конкретные подмеры, применимость которых определяется классом ГИС.

Как определить перечень применимых мер для конкретной ИС?

По приказу ФСТЭК №117 процедура выбора мер включает четыре шага: 1) определяется класс ГИС (К1–К4) на основании обрабатываемой информации и последствий нарушения безопасности; 2) для установленного класса выбирается базовый набор мер из таблиц приказа; 3) базовый набор адаптируется с учётом актуальных угроз из модели угроз, разработанной на основе БДУ ФСТЭК; 4) при необходимости вводятся компенсирующие меры, если базовая мера неприменима по техническим или организационным причинам. SGRC-платформа автоматизирует этот маппинг и формирует перечень применимых мер для каждой ИС.

Можно ли заменить одну меру защиты другой (компенсирующая мера)?

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

Какие меры обязательны для всех классов ГИС по приказу №117?

Базовый набор мер, обязательный для всех классов ГИС (К4–К1), включает около 80 мер: идентификация и аутентификация пользователей, парольная политика (длина, сложность, срок действия), разграничение прав доступа по принципу наименьших привилегий, регистрация событий входа/выхода и изменения прав, антивирусная защита рабочих станций и серверов, своевременное обновление ПО и операционных систем, межсетевое экранирование на периметре.

Как автоматизировать контроль выполнения мер в SGRC-системе?

SGRC-платформа КиберОснова автоматизирует полный цикл контроля мер защиты: загружает перечень применимых мер для конкретного класса ГИС, позволяет назначить ответственного за каждую меру, принять доказательства выполнения (политики, регламенты, отчёты сканирования, скриншоты настроек), автоматически рассчитывает коэффициент защищённости информации (КЗИ) и формирует отчёт о выполнении мер в формате, удобном для аттестатора.

Что будет, если меры защиты не выполнены при аттестации?

Если при аттестационных испытаниях выявлено невыполнение мер защиты, аттестационный орган выдаёт предписание с перечнем несоответствий и сроками их устранения. Аттестат соответствия не выдаётся до устранения всех критических замечаний. После устранения проводится повторная проверка в форме инспекционного контроля. Эксплуатация государственной информационной системы без действующего аттестата является нарушением, влекущим административную ответственность по КоАП РФ для должностных лиц и организации-оператора.