Облако для объектов КИИ: требования 187-ФЗ и чек-лист для CISO

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

Эти изменения порождают множество вопросов, особенно в части размещения и защиты объектов КИИ.

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

Субъект КИИ — это не формальный статус и не запись в реестре.

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

Принадлежность к КИИ определяется совокупностью следующих факторов:

1. Осуществляется ли деятельность в одной из сфер КИИ, указанных в ст. 2 187-ФЗ.

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

   Работа в сферах, указанных выше, рассматривается как базовый индикатор принадлежности к субъектам КИИ, даже если соответствующее направление не является основным бизнесом. Ваш ОКВЭД может быть отправной точкой для сопоставления основных и дополнительных кодов с типовыми перечнями объектов КИИ и проектами нормативных актов. 

2. Эксплуатируются ли ИС, АСУ ТП или сети связи, реализующие процессы (функции), выполняемые типовыми объектами КИИ РФ согласно Распоряжению правительства 360-Р. 

3. Повлияет ли отказ или компрометация ваших систем на устойчивость отраслевых процессов в целом.

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

Категорирование КИИ — это оценка значимости объекта КИИ, определение возможного ущерба при наступлении инцидентов и последующее присвоение одной из категорий значимости (1, 2, 3) либо решение об отсутствии категории в соответствии со статьей 7 187-ФЗ.

Порядок  категорирования описан в Постановлении Правительства № 127 и состоит из следующих действий:

• Инвентаризация информационных систем и бизнес-процессов

• Выявление объектов КИИ и их сопоставление с типовыми отраслевыми перечнями (при наличии)

• Оценка возможных последствий инцидентов, расчет показателей значимости и присвоение категории значимости объекту КИИ

• Оформление и направление материалов регулятору
  
  Дальнейшие шаги определяются тем, присвоена ли объекту КИИ категория значимости.

  Статус объекта КИИ	Требования нормативно-правовых актов
  Объект получил категорию (1,2 или 3)	Для значимых объектов КИИ (ЗОКИИ) к мерам 187-ФЗ добавляются требования по обеспечению защиты ЗОКИИ согласно Приказу ФСТЭК № 239
  Объект без категории значимости	Требования Приказа ФСТЭК № 239 не обязательны, однако субъект КИИ обязан выполнять общие требования 187-ФЗ

  Незначимый объект КИИ не означает «вне закона». Субъект КИИ все равно обязан провести категорирование, встать на учет в ФСТЭК и обеспечить взаимодействие с ГосСОПКА. 

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

Согласно 187-ФЗ ответственность за безопасность объектов КИИ лежит на их субъектах. 

Это ставит перед компаниями важный вопрос: можно ли такие объекты размещать в облаках и насколько это безопасно? 

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

1. Провайдер должен соответствовать нормативным требованиям. 

2. Данные должны физически находиться на территории РФ. 

3. Ответственность должна быть разграничена в договоре.

Тем не менее на рынке сложилась устойчивая практика, когда для размещения ЗОКИИ 1 категории организации выбирают выделенные или частные облачные сегменты. Дело в том, что для выполнения требований регулятора часто приходится использовать средства защиты и стек ПО, отличные от текущего ИТ-ландшафта. Построение частного облака является оптимальным компромиссом: OPEX-модель позволяет избежать масштабных инвестиций на старте, а изолированность инфраструктуры и использование средств защиты гарантируют необходимый уровень безопасности. 

Рабочий вариант для большинства субъектов КИИ — гибридная модель, по которой системы, на которые не распространяются требования 187-ФЗ, размещаются on premise, а объекты КИИ находятся в частном облаке, реализованном на базе ЦОД провайдера.

При размещении объекта КИИ в частном облаке ответственность делится между двумя сторонами — облачным провайдером и субъектом КИИ.

Провайдер обеспечивает безопасность платформы, субъект КИИ — безопасность того, что на ней работает. Граница проходит на уровне гипервизора.

Это разграничение должно быть зафиксировано в договоре с провайдером в виде матрицы ответственности. В случае инцидента без такого документа не удастся выяснить, кто что должен был защищать. Регулятор задаст этот вопрос субъекту КИИ, а ответа не окажется.

Запросите матрицу ответственности до подписания договора. Если провайдер не может ее предоставить, это сигнал.

Приведенный ниже чек-лист поможет вам сравнить провайдеров и сделать обоснованный выбор. Скачайте оформленную версию для работы со своей командой.

Скачать чек-лист в PDF

1. Аттестат ФСТЭК соответствует вашей категории объекта КИИ

Запросите копию аттестата. Проверьте, для каких категорий значимости (1, 2 или 3) он выдан. Уровень провайдера должен покрывать вашу категорию.

2. ЦОД аттестован по Приказу ФСТЭК №117

С 1 марта 2026 года аттестация ИС невозможна без аттестации ЦОД, на котором она работает. Уточните, прошел ли ЦОД провайдера аттестацию по новым правилам.
*данный критерий актуален только в случае, если вы работаете с ЗОКИИ, которые являются ГИС  

3. Провайдер: российское юрлицо под контролем граждан РФ

Требование 187-ФЗ. Запросите выписку из ЕГРЮЛ и подтверждение структуры собственности. Иностранное юрлицо с российским офисом этому критерию не соответствует.

4. Данные физически размещены в России

Условие должно быть закреплено в договоре с указанием конкретных адресов ЦОД. Проверьте, нет ли технической возможности репликации данных за пределы РФ.

5. Платформа работает на отечественном ПО

Для значимых объектов КИИ обязательно ПО из реестра Минцифры (требование 58-ФЗ). Запросите список программного обеспечения, задействованного в инфраструктуре, и проверьте наличие каждого продукта в реестре.

6. СЗИ в составе инфраструктуры сертифицированы ФСТЭК и/или ФСБ

Запросите перечень средств защиты с номерами сертификатов. Проверьте актуальность на сайте ФСТЭК России.

7. Провайдер подключен к ГосСОПКА

187-ФЗ требует непрерывного взаимодействия с системой. Провайдер, хранящий или обрабатывающий объекты КИИ, должен иметь механизмы интеграции с ней и передавать данные об инцидентах.

8. Матрица ответственности зафиксирована в договоре

Документ, в котором явно прописано, что делает провайдер, а что берет на себя субъект КИИ. Без матрицы размытая ответственность при инциденте становится вашей проблемой.

9. Возможность аттестации вашей ИС поверх инфраструктуры провайдера

Уточните: предоставляет ли провайдер документацию для аттестации вашей системы? Можно ли привлечь стороннего аккредитованного аттестующего? Есть ли у провайдера фактический опыт совместного прохождения аттестаций с клиентами?

Ошибка 1: принять «сертифицированные СЗИ» за «аттестованное облако»

Провайдер пишет: «наша инфраструктура использует сертифицированные средства защиты». Это чистая правда. Но аттестат соответствия и наличие сертифицированных СЗИ — это разные документы с разными правовыми последствиями.

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

Ошибка 2: не зафиксировать матрицу ответственности в договоре

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

Ошибка 3: не проверить соответствие уровня аттестата категории объекта

Провайдер аттестован «для КИИ». В аттестате написано: до 3 категории включительно. Организация размещает объект 1 категории. Аттестация этой системы по Приказу №239 в рамках данной инфраструктуры невозможна.

В 2025 году надзорные органы возбудили более 400 административных дел за нарушения в сфере категорирования КИИ. Для сравнения, годом ранее таких дел было в разы меньше.

Статья 13.12.2 КоАП РФ предусматривает следующие штрафные санкции за нарушение правил эксплуатации объектов КИИ. 

• Граждане: от 5 000 до 10 000 рублей

• Должностные лица (CISO, CIO, директор по ИТ): от 10 000 до 50 000 рублей

• Организации: от 100 000 до 500 000 рублей

  За нарушение процедуры категорирования: от 50 000 до 500 000 рублей на организацию.

Уголовная ответственность наступает при причинении значительного ущерба: до 10 лет лишения свободы по ст. 274.1 УК РФ. Ответственность персональная, под нее подпадают те, кто принимал решения о выборе инфраструктуры и организации защиты.

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

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

1. Убедитесь, что категорирование проведено. Без него невозможно понять, какие требования к вам применимы.

2. Запросите у провайдера аттестат ФСТЭК с указанием уровня и сверьте с категорией ваших объектов.

3. Зафиксируйте матрицу ответственности в договоре или отдельном приложении к нему.

Скачайте чек-лист CISO в удобном формате: для переговоров с провайдером и внутренней проверки.

Скачать чек лист

Если ваши задачи выходят за рамки КИИ (разработка, тестовые среды, вспомогательные системы, хранение некритичных данных), инфраструктура должна быть надежной, но не обязательно проходить аттестацию по 187-ФЗ. Подробнее о том, как устроены модели облачных услуг и что входит в зону ответственности провайдера, читайте в материале Модели облачных услуг: IaaS, PaaS и SaaS.

За последние два года число запросов на размещение инфраструктуры по требованиям КИИ заметно выросло. 187-ФЗ активно обновлялся, и компании начали разбираться, что это значит для их инфраструктуры.

В ответ мы выделили в нашем ЦОД отдельный сегмент, соответствующий требованиям Приказа ФСТЭК №17, 187-ФЗ и Приказа ФСТЭК №21. Это дополнительный контур внутри К2 Облака — заказчики могут в любой момент мигрировать нужную систему в защищенный сегмент, не меняя провайдера.

Один из популярных сценариев в К2 Облаке — размещение ERP на базе 1С. Риск того, что ERP конкретного заказчика попадет в перечень значимых объектов КИИ, довольно высок. Самостоятельно выполнить требования 187-ФЗ — задача дорогая и долгая. Готовая аттестованная инфраструктура провайдера закрывает ее быстрее и дешевле.