Цифровизация госсектора привела к появлению сервисов, которые упростили взаимодействие граждан с государством. Яркий пример — портал Госуслуг, работа которого опирается на обширную инфраструктуру государственных информационных систем (ГИС). 

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

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

На связи Максим Кузнецов, руководитель отдела защиты информации ГИС в Бастионе. Сегодня расскажу об особенностях защиты ГИС и о том, с какими сложностями мы сталкиваемся в таких проектах.

Особенности защиты ГИС

ГИС — это своеобразные «бэкенды государства», которые работают под капотом цифровых услуг. Требуется ли получить загранпаспорт, заменить водительское удостоверение или записаться к врачу, все пути ведут в ГИС — например, на Госуслуги. 

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

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

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

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

Чем защита ГИС отличается от корпоративной ИБ

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

Только сертифицированные средства защиты

Для ГИС действует строгое требование: использовать только сертифицированные средства защиты информации. Если у СрЗИ нет сертификата соответствия, внедрение ставится на паузу до официального согласования с регулятором.

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

Согласование с регуляторами

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

Долгие и сложные процедуры закупок СрЗИ

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

Консервативность регулирования

Нормативная база по ГИС обновляется крайне редко и дозированно. Законодательство в этой сфере значительно отстает по своей динамике от правового регулирования в сфере защиты персональных данных или объектов КИИ. Впрочем, это не значит, что при построении систем защиты ГИС нельзя использовать нестандартные подходы. Главное — грамотно обосновать их перед регуляторами. 

В последнее время внимание к ГИС со стороны ФСТЭК и ФСБ растет, и уже сейчас понятно, что требования будут меняться. Мы внимательно отслеживаем все проекты нормативных документов, чтобы подготовиться к возможным изменениям еще до их вступления в силу.

Как регулируется защита ГИС

Регулирование защиты ГИС это вотчина сразу двух надзорных органов: ФСТЭК — в части СрЗИ и ФСБ — в части СКЗИ, проще говоря — криптографии. 

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

Создание ГИС, как правило, заканчивается аттестацией. Со стороны ФСТЭК она регулируется Приказом № 77, принятым в 2021 году. Он дополнил ГОСТы, которые описывали механизмы аттестации до 2021 года. 

Вся криптографическая часть ГИС относится к ведению ФСБ. Здесь основополагающим нормативным актом является Приказ ФСБ № 117 (принят взамен Приказа № 524). 

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

Наряду с профильным законодательством, важно учитывать и ряд базовых документов в сфере информационной безопасности, которые затрагивают проблематику ГИС в общем контексте. Основа основ — Закон «Об информации, информационных технологиях и о защите информации». Не стоит забывать и о Постановлении Правительства № 676, которое касается общих принципов работы таких систем. 

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

Да, это создает дополнительные сложности, но коллизий между требованиями разных регуляторов, как правило, не возникает. Вышеупомянутый Приказ ФСТЭК № 17 «перекрывает» Приказ № 21 по ПДн. В свою очередь, Приказ ФСТЭК № 239, регулирующий безопасность объектов КИИ, гармонично дополняет законодательство по защите ГИС. Словом, выстраивается иерархическая регуляторная система. 

Как строится система защиты ГИС (в идеальном мире)

Чтобы избежать недоразумений, сразу сделаем оговорку: будет приведено описание идеальной картины мира при построении системы защиты в ГИС. Для упрощения также опустим первоначальные шаги, когда только зарождается идея создания ГИС, и рассмотрим сразу ту часть, которая относится к ИБ.

Глобально построение системы защиты ГИС состоит из нескольких ключевых этапов:

1. Аудит требований — изучаем потребности заказчика, который планирует внедрить систему защиты.

2. Моделирование угроз — моделируем возможные угрозы с учетом всех внешних и внутренних факторов, которые могут повлиять на безопасность конкретной ГИС.

3. Разработка технического задания — на этом этапе формулируется ТЗ на систему защиты информации, подробно описывающее защитные меры и усиления в зависимости от класса ГИС, уровня защищенности ПДн и других факторов. 

4. Следующий этап — согласование модели угроз (МУ) с регуляторами и отработка замечаний. Регуляторы нередко предлагают лучшие практики, которые команда оперативно интегрирует в документацию.

5. Проектирование системы защиты — инженеры подбирают средства защиты (СрЗИ и СКЗИ), готовят документацию и согласовывают с заказчиком описания настроек и конфигураций.

6. Закупка оборудования и решений — заказчик или подрядчик приобретает утвержденные СрЗИ, СКЗИ и другие компоненты, необходимые для работы системы. 

7. Пусконаладочные работы — инженер ИБ настраивает систему на основе утвержденного комплекта документов и готовит ее к приемке.

8. Аттестация — на этом этапе производится подготовка аттестационных документов, а после — проверка ГИС на соответствие предъявляемым требованиям по ИБ в зависимости от класса, уровня защищенности ПДн и категории значимости. 

Если абстрагироваться от ГИС, процесс работы по построению системы защиты практически не отличается от создания систем защиты корпоративных систем или любых других информационных систем, в которых выделяются подсистемы ИБ. Но это только на первый взгляд — на деле обнаруживается масса нюансов и подводных камней. Начиная от двойного согласования регуляторов (ФСТЭК и ФСБ) до бумажной волокиты, которая жизненно необходима структурам, финансируемым из бюджета государства. Большинство сложностей связано с бюрократией и кипами документации, которую нужно предоставлять заказчику для успешного закрытия каждого этапа разработки в определенный срок. 

В итоге некоторые этапы затягиваются, и вышеописанная стройная последовательность нарушается. Например, иногда приходится на свой страх и риск переходить к стадии ТЗ и проектирования, еще не согласовав модель угроз. Но не будем забегать вперед. Для начала кратко опишем четыре этапа, на которых обычно возникает больше всего сложностей. 

Моделирование угроз

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

В качестве примера можно рассматривать абсолютно любую систему — проблематика моделирования будет применима к любой ГИС.

При разработке МУ мы анализируем, интересен ли этот ресурс, скажем, зарубежным спецслужбам. Пожалуй, произвольному «спецагенту» нет никакого дела до того, как работает, чем живет и сколько зарабатывает абстрактный пользователь, использующий ресурсы 1С или иного модуля, который может быть разработан и внедрен в ГИС.

А вот различные хакеры, напротив, могут заинтересоваться такой информацией. И необязательно ради наживы: возможны варианты, когда хакер просто тешит свое самолюбие и говорит нам «смотрите, как могу!». 

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

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

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

Как мы уже упомянули, в МУ включаются как специфические риски, актуальные для конкретной организации и системы, так и общие угрозы. Например, ФСТЭК ведет на своем сайте специализированный банк угроз. Правда, этот перечень не обновлялся с 2020 года и несколько устарел. В нем не отражены риски ИБ, связанные с популярными сегодня контейнерами, а тематика искусственного интеллекта и виртуализации затронута лишь по касательной. 

В настоящее время регулятор ведет работы по адаптации, консолидации и типизации угроз. Надеемся, в ближайшем будущем мы увидим новый раздел угроз, который выйдет из статуса опытной эксплуатации и заменит или же дополнит устоявшиеся типовые УБИ. Ознакомиться с планируемыми нововведениями можно на сайте ФСТЭК.

Когда МУ разработана и одобрена заказчиком, она направляется на утверждение во ФСТЭК и ФСБ России. Первый регулятор обычно согласовывает документацию относительно быстро. Обычно ФСТЭК приходит с обратной связью по документу в течение 30 рабочих дней, а повторные согласования после отработки замечаний могут занять от пары дней до пары недель. 

Согласование с ФСБ в среднем более продолжительное. Порой оно может требовать пересмотра выбранного СКЗИ и закупки дополнительных средств защиты информации. Нередко ФСБ утверждает модель угроз, когда мы уже находимся на этапе проектирования. Часто приходится многое менять уже на финальной стадии реализации, чтобы выполнить требования надзорного органа. Но лучше так, чем «проект длиною в жизнь». 

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

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

Впрочем, однозначного ответа на вопрос «спорить или не спорить с регулятором?» не существует. Каждая система и заказчик индивидуальны: что хорошо одному — неприменимо для другого. Зачастую решение зависит от сроков проекта: если дедлайн близко, проще принять корректировки и не тратить время на препирательства. Если времени достаточно, а отработка замечаний может повлечь удорожание проекта или потребовать закупки дополнительных СрЗИ, то есть смысл поспорить. Главное — не махать шашкой, а аргументированно доказать свое решение. Многие замечания регуляторов справедливы — в таком случае тоже нет никакого смысла действовать по принципу «Баба Яга против». 

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

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

ТЗ и проектирование системы защиты 

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

При подготовке технического задания мы опираемся как на собственную экспертизу, так и на требования регуляторов. Чем выше класс системы с точки зрения ФСТЭК, тем весомее будет перечень защитных мер. Приказ ФСТЭК № 17 содержит сводную таблицу, где перечислены обязательные и дополнительные возможные меры для каждого из классов ГИС. Ко вторым относятся дополнительные СрЗИ и организационные мероприятия, которые выполняются по желанию заказчика. 

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

Если говорить в целом, то техническое задание — это «картина крупными мазками»: оно дает общее представление о системе защиты и применяемых мерах, которые необходимо реализовать как технически, так и организационно. При этом около 90% бюджета проекта обычно приходятся на описанные в ТЗ технические мероприятия, и только 10% — на организационные. В плане же трудозатрат на техническую составляющую и документацию соотношение, как правило, шестьдесят на сорок. 

К слову, на этапе подготовки ТЗ у многих заказчиков уже есть свое видение будущей системы, а в некоторых случаях даже закуплены средства защиты. Оптимально, когда подбор и закупка проходят с нашим участием: в противном случае нередко приходится подгонять систему под уже приобретенные компоненты или, наоборот, проводить закупку дополнительных СрЗИ. Все это неизбежно затягивает сроки реализации проекта. 

Идеальный вариант — закупка СрЗИ после утверждения заказчиком пояснительной записки на систему защиты информации для ГИС, однако, из-за сжатых (по разным причинам) сроков многие процессы происходят практически одновременно.

Подготовка пояснительной записки

Исходя из нашей практики, пояснительная записка готовится параллельно с пусконаладочными мероприятиями (ПНР). На этом этапе «крупные мазки» из ТЗ обрастают деталями: конкретизируются применяемые СрЗИ, от межсетевых экранов до средств обнаружения вторжений и антивирусов. Подробно описывается, как средства защиты будут взаимодействовать и какое место займут в общей структуре, а также какие настройки необходимо сделать под конкретный класс ГИС. 

Иногда возникают технические форс-мажоры. Например, не удается провести интеграцию оборудования и СрЗИ. Вспоминается случай из нашего проектного опыта, когда на закупленные заказчиком серверы отечественного производителя почему-то не устанавливался модуль доверенной загрузки (МДЗ). Решить проблему в итоге удалось много позже, но в рамках проекта пришлось заменить имеющийся МДЗ на аналог. Причины таких несовпадений могут быть самыми разными — приходится отдельно разбираться в каждой ситуации. 

Аттестация

Аттестация — финальный этап построения защищенной ГИС, на котором проверяется соответствие системы требованиям по безопасности информации.

Как и на остальных шагах проектирования, на этапе аттестации могут встречаться типовые проблемы, например:

• Несоответствие документации фактическому состоянию системы;

• Некорректная настройка средств защиты информации;

• Отсутствие процедур реагирования на инциденты или иных регламентов, необходимых для жизненного цикла системы;

• Недостаточная квалификация персонала организации-владельца ГИС;

• Проблемы с разграничением доступа и аутентификацией;

• Устаревшие версии программного обеспечения;

• Неправильное категорирование системы по уровню защищенности.

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

• Начинайте подготовку к аттестации на ранних этапах разработки системы.

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

• Своевременно обновляйте документацию и СрЗИ.

• Обучайте сотрудников, ответственных за эксплуатацию системы. 

• Используйте только сертифицированные решения. Заменяйте СрЗИ и СКЗИ с истекшим сертификатом на новые. 

• Привлекайте экспертов на ранних стадиях. Консультации еще на этапе проектирования помогают избежать дорогостоящих доработок в будущем.

Основные проблемы и нюансы в построении защиты ГИС 

Приведенный пример с несостыковкой оборудования и СрЗИ — лишь частный случай. Есть и систематические камни преткновения, которые существенно усложняют работу по защите ГИС. Рассмотрим их подробнее. 

Сложности подбора СрЗИ

Основные проблемы связаны с сертификацией. В качестве иллюстрации приведем еще один проект из нашего опыта — проектирование защиты ГИС для одной региональной госструктуры. По ряду причин на стороне заказчика проект растянулся на пять лет. За это время сертификаты на многие зарубежные СрЗИ утратили актуальность, а заменить эти решения оказалось нечем. Продолжать использовать средства защиты с истекшей разрешительной документацией рискованно — можно нарваться на штрафные санкции. 

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

Другая сложность в том, что поставщики СрЗИ не всегда поспевают за актуальными угрозами ИБ. Так, в течение прошедших двух лет в продаже не было ни одного сертифицированного решения, которое закрывало бы риски, связанные с применением контейнеров. Несколько таких российских СЗрИ появилось только в четвертом квартале 2024 года и еще не были достаточно изучены, чтобы однозначно рекомендовать их к покупке и внедрению. 

Вопросы импортозамещения

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

Базовые потребности по защите ГИС реально удовлетворить при помощи отечественных СрЗИ. Российские разработчики предлагают инструменты резервного копирования, межсетевые экраны, средства обнаружения вторжений, антивирусы и т. д. Определенный пробел наблюдается разве что в средствах пропуска видеопотока, но это не самые широко востребованные решения. Возможно, выстроенная на российских СрЗИ система потребует дополнительных настроек и адаптации, но такая задача вполне выполнима.

Зато вопросы импортозамещения встают в полный рост для давно существующих ГИС, которые используют специфичные СЗИ. Например, ни один российский сертифицированный межсетевой экран не обладает пропускной способностью под 700 Гбит/c, как ушедшие с рынка зарубежные конкуренты. К тому же многие системы защиты ГИС заточены под Windows и плохо уживаются с Linux. Еще не так давно подбор СрЗИ под линуксовые системы был тем еще квестом. На сегодняшний день многие российские вендоры переработали подходы над совместимостью своих СрЗИ, но сложности все равно возникают. 

Излишняя гибкость и противоречивость нормативной базы

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

Казалось бы, свобода действий — это преимущество. Не можешь купить рекомендованное СрЗИ или оборудование — обоснуй это регламентом и обеспечь защиту оргмерами. Только не факт, что при согласовании модели угроз регулятор не потребует усилить защиту, настаивая на необходимости внедрения собственных рекомендаций. 

Такой риск особенно велик при утверждении документации в ФСБ. Чаще всего ФСБ требует повысить класс системы криптографической защиты (СКЗИ). Причем такие корректировки не исключены, даже если используются СКЗИ класса КС-3, что вполне достаточно для большинства ГИС. Мы пытаемся в ходе диалога донести это до регулятора, приводя обоснования, но отстоять свою позицию получается не всегда. 

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

Да, чаще всего прямые контакты с регулятором излишни, и лучше общаться в формате официальной переписки. Но если согласование буксует, приходится идти ва-банк. Такие инициированные нами мероприятия неоднократно помогали сдвинуть дело с мертвой точки и ускорить согласование модели угроз. 

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

Трудности модернизации и поддержки существующих ГИС

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

Некоторые меры по модернизации могут идти вразрез со сложившейся инфраструктурой. Условно, мы устанавливаем следующую версию антивируса — и в системе «падает» контейнер, поскольку они несовместимы. Такие сюрпризы всплывают не только по внутренним причинам, но также из-за недоработок в СрЗИ, о которых вендоры могут попросту не знать, пока к ним не придет обращение с конкретизацией проблемы. С другой стороны, не станешь же отключать антивирус, чтобы система хоть как-то работала. 

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

Несогласованность заказчиков при планировании работ

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

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

Урезания бюджетов на защиту ГИС

Типичная ситуация для государственных заказчиков — формирование бюджета для модернизации ГИС на пару лет вперед. Просчитать что-либо до рубля невозможно. Предсказать курс доллара с перспективой даже на год, конечно, можно, но точность будет на уровне гороскопа. А ведь от этого по-прежнему зависит стоимость СрЗИ. 

Не менее распространена другая ситуация: изначальный бюджет на систему в 1 миллион рублей сокращают до 500 тысяч. Как говорится, ни в чем себе не отказывайте. Такая экономия выходит боком и нам, и самим клиентам. Сколько ни урезай финансирование, регуляторные требования к уровню защиты не смягчаются. 

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

Бюрократия на стороне заказчиков

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

Что на самом деле проверяет ФСТЭК в документах? Прежде всего содержание: правильно ли вы определили угрозы, насколько адекватны предложенные меры защиты и соответствует ли ваша система нормативным требованиям по существу. 

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

Вместо заключения: строим защиту «не для галочки»

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

Наш опыт показывает, что успешные проекты по защите ГИС рождаются не столько из слепого следования нормативам, сколько из грамотного диалога между всеми участниками процесса. При таком подходе интегратор перестает быть обычным «исполнителем»: приходится брать на себя роль медиатора, балансирующего между требованиями регулятора и чаяниями клиента. 

Главное здесь — держать в голове, что в конечном счете такие системы проектируются не ради соблюдения формальностей, а для обеспечения безопасности цифрового государства. А вместе с ней — и того самого «цифрового удобства», ради которого и создаются ГИС.