Мы аттестовали облако по 21-му и 117-му приказам ФСТЭК России. Что из нашего опыта облегчит жизнь операторам ГИС и ИСПДн

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

Меня зовут Максим Куртин, я руковожу департаментом информационной безопасности «Группы Астра». Этим летом наша команда провела аттестацию инфраструктуры Astra Cloud сразу по двум приказам: по 117-му по классу защищенности К1 для государственных информационных систем и по 21-му по уровню защищенности УЗ-1 для систем, обрабатывающих персональные данные. На этой базе теперь работает сервис «Защищённое аттестованное облако». Ниже разберу, из чего на практике состоит выполнение требований, какую часть реально отдать подрядчику и что в любом случае останется на операторе системы.

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

Более подробно читайте ниже. Я, как заядлый ИБшник, начну с регулятора.

Приказы ФСТЭК России. Страшно ли это?

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

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

Шума вокруг приказа много, но польза от него, на мой взгляд, все-таки больше. Он меняет саму идеологию защиты. Раньше все шло по порядку: определили требования, спроектировали систему защиты, внедрили, аттестовали. Дальше можно было спокойно жить до следующей переаттестации. 117-й же приказ перевел защиту на процессы. То есть риск инцидентов, как минимум, должен снижаться. 

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

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

С персональными данными логика та же, только нормы другие. Для ИСПДн базой остается 152-ФЗ и 21-й приказ ФСТЭК России, а уровень защищенности зависит от того, какие данные обрабатываются. Медицинские системы работают со сведениями о здоровье и биометрией. Они защищаются по первому уровню защищенности, самому высокому из предусмотренных. Банки, страховые и МФО тоже живут под 21-м приказом. Поэтому облако мы аттестовывали сразу по обоим документам.

Сколько стоит пройти аттестацию самостоятельно

Инфраструктуру Astra Cloud мы аттестовывали сами, и со стороны ИБ проектом занимались 15 специалистов. Со стороны ИТ людей было еще больше, проект очень масштабный.

По срокам я бы ориентировался так: минимум год, в среднем полтора. Большая часть времени уходит на проектирование и закупку оборудования, так как 117-й приказ требует применять средства защиты с соблюдением требований Указа Президента №250, то есть иностранные СЗИ из недружественных стран вне игры. Подобрать и закупить подходящее железо и софт сейчас непросто само по себе.

И это при условии, что у вас уже есть опыт и сертифицированные российские продукты.

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

В итоге цена самостоятельного пути складывается из трех статей. 

1. Оборудование и сертифицированные средства защиты (СЗИ/СКЗИ), которые еще нужно найти и дождаться. 

2. Полтора года работы команды, где только со стороны ИБ 15 человек, плюс ИТ.

3. Найм, обучение и удержание этих людей для дальнейшей эксплуатации системы. 

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

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

Про ответственность между заказчиком и Astra Cloud

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

Классическая схема делит зоны по среде виртуализации. Все, что ниже, отвечает оператор инфраструктуры, в нашем случае Astra Cloud: ЦОД, оборудование, встроенные средства защиты, физическая изоляция контура, системное ПО. Все, что выше, остается на операторе информационной системы: приложения, данные, защита виртуальных машин, настройка доступов.

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

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

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

Как выглядит путь на аттестованной инфраструктуре Astra Cloud

Порядок аттестации регулирует приказ ФСТЭК России № 77, сам аттестат выдает независимый аттестационный орган с лицензией. Все, что до этого, мы можем пройти вместе с заказчиком: разобраться, что нужно сделать, спроектировать, внедрить, провести испытания.

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

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

Проект случается, только когда работают обе стороны.

По срокам на готовой облачной инфраструктуре я бы говорил о сокращении процесса аттестации ИС примерно в три раза: от трех до шести месяцев. Разброс зависит от объема системы и требований заказчика. 

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

Жизнь после аттестата

После получения аттестата ИС в облаке начинается процесс непрерывного соответствия. 

Если своих ресурсов на это нет, цикл тоже можно замкнуть на нас:

• анализ угроз и уязвимостей информационной системы;

• периодический пересчет показателя защищенности;

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

• контроль обновлений и конфигурации, этот процесс вообще не должен останавливаться;

• мониторинг событий ИБ. 

Но кое-что за заказчика не сделает никто. Организационные меры всегда на нем: ознакомить пользователей с регламентами и инструкциями, объяснить зоны ответственности и последствия нарушений, научить работать с системой и следить, чтобы персонал все это выполнял. 

Кому наше облако подходит и кому нет

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

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

Второй понятный сценарий касается медицины, банков, страховых и МФО, которые живут под 21-м приказом. Особенно если у вас несколько систем с высокими требованиями, но строить ради них собственный аттестованный ЦОД экономически невыгодно. 

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

Есть нюансы, о которых я скажу честно. Не каждую информационную систему можно разместить в «Защищённом аттестованном облаке». Например, для систем с государственной тайной такой сценарий не подходит. Здесь мы можем построить частное облако на базе продуктов «Группы Астра», они сертифицированы по самым высоким классам защищенности.

Значимые объекты КИИ в «Защищённое аттестованное облако» тоже не переносим. Для них нужен частный или гибридный контур, спроектированный под конкретного заказчика. С АСУ ТП отдельная история. Она завязана на производство и конкретный объект, и вынос управления в облако остается риском, который должен принять сам заказчик. Практичнее ставить такую инсталляцию прямо на площадке заказчика.

Гибридная схема, где часть системы on-premise, часть в облаке, возможна. Приказам ФСТЭК России этот сценарий не противоречит. Гибрид, конечно, сложнее, но задача техническая и решаемая. Основные вопросы встанут вокруг отказоустойчивости и взаимодействия частей облака между собой. 

Что будет дальше или прогноз регуляторики 2027

Если смотреть более глобально, то на 21-м и 117-м приказах ФСТЭК России точно не остановится. Каждый год требования меняются, причем существенно. Что примерно мы ожидаем далее? 

Проект нового приказа по защите персональных данных на замену 21-го сохраняет четыре уровня защищенности, но оператор в нем сам выбирает состав мер и регулярно оценивает их зрелость, как в 117-м. Следом очередь требований к защите КИИ (приказ № 239). Новые документы строятся в той же идеологии и структуре.

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

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

Новые требования тоже на подходе. 117-й уже частично покрывает использование искусственного интеллекта, отдельным мероприятием в том же пункте 34. Проект нового приказа по ПДн тоже затрагивает вопрос защиты ИИ. Все нововведения мы держим «на карандаше» и учитываем в рамках модернизации облака, которая у нас началась сразу после получения аттестата.

Я спрогнозировал плюс-минус на 2027 год. Как будто этого пока всем достаточно) 

Не превратится ли все это в очередную «бумажную» безопасность, за которой потеряются реальные угрозы?

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

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