Критическая информационная инфраструктура: почему статус субъекта КИИ может появиться неожиданно для IT-компании
TL;DR
IT-компании автоматически становятся субъектами КИИ по закону 187-ФЗ, если их программное обеспечение или сервисы обеспечивают управленческие, технологические или производственные процессы в банках, медицине, ТЭК и других стратегических сферах. Нарушение правил эксплуатации таких систем, повлекшее сбой, квалифицируется по статье 274.1 УК РФ и грозит руководителям и техспециалистам лишением свободы на срок до 10 лет. Главная опасность — скрытый статус КИИ через облачные сервисы (SaaS) или интеграционные модули, внедренные в инфраструктуру заказчика.
IT-компании автоматически становятся субъектами КИИ по закону 187-ФЗ, если их программное обеспечение или сервисы обеспечивают управленческие, технологические или производственные процессы в банках, медицине, ТЭК и других стратегических сферах. Нарушение правил эксплуатации таких систем, повлекшее сбой, квалифицируется по статье 274.1 УК РФ и грозит руководителям и техспециалистам лишением свободы на срок до 10 лет. Главная опасность — скрытый статус КИИ через облачные сервисы (SaaS) или интеграционные модули, внедренные в инфраструктуру заказчика.
Что такое субъект КИИ и как IT-компания получает этот статус неожиданно?
Субъектами критической информационной инфраструктуры (КИИ) признаются организации и индивидуальные предприниматели, которым на праве собственности, аренды или ином законном основании принадлежат информационные системы, информационно-телекоммуникационные сети или автоматизированные системы управления (АСУ), функционирующие в стратегических сферах. Согласно Федеральному закону от 26.07.2017 № 187-ФЗ «О безопасности КИИ РФ», к таким сферам относятся:
Ловушка неожиданного статуса заключается в том, что IT-компания может не быть банком или клиникой, но стать субъектом КИИ через свои продукты. Это происходит в трех случаях:
Ловушка неожиданного статуса заключается в том, что IT-компания может не быть банком или клиникой, но стать субъектом КИИ через свои продукты. Это происходит в трех случаях:
- Здравоохранение и медицина
- Наука и высшее образование
- Транспорт и логистика
- Связь и телекоммуникации
- Энергетика и топливно-энергетический комплекс (ТЭК)
- Банковская сфера и финансовый рынок
- Атомная, оборонная, ракетно-космическая, химическая и металлургическая промышленность
Ловушка неожиданного статуса заключается в том, что IT-компания может не быть банком или клиникой, но стать субъектом КИИ через свои продукты. Это происходит в трех случаях:
- Поставка SaaS-решений: Если IT-компания продает доступ к своей ERP, CRM или HRM системе по модели облачного сервиса, а среди клиентов есть хотя бы одна организация из перечня КИИ (например, частная клиника или региональный оператор связи). Информационная система физически принадлежит IT-компании, а значит, она обязана категорировать ее и защищать по требованиям ФСТЭК и ФСБ.
- Аутсорсинг и администрирование: Если разработчик берет на себя техническую поддержку, обновление и администрирование софта, установленного на серверах КИИ-заказчика. Имея удаленный доступ с правами суперпользователя, IT-компания интегрируется в чужой контур КИИ.
- Разработка заказного ПО: Создание уникальных модулей, которые управляют технологическими процессами или финансовыми транзакциями на стороне клиента из КИИ-сферы.
- Здравоохранение и медицина
- Наука и высшее образование
- Транспорт и логистика
- Связь и телекоммуникации
- Энергетика и топливно-энергетический комплекс (ТЭК)
- Банковская сфера и финансовый рынок
- Атомная, оборонная, ракетно-космическая, химическая и металлургическая промышленность
Ловушка неожиданного статуса заключается в том, что IT-компания может не быть банком или клиникой, но стать субъектом КИИ через свои продукты. Это происходит в трех случаях:
- Поставка SaaS-решений: Если IT-компания продает доступ к своей ERP, CRM или HRM системе по модели облачного сервиса, а среди клиентов есть хотя бы одна организация из перечня КИИ (например, частная клиника или региональный оператор связи). Информационная система физически принадлежит IT-компании, а значит, она обязана категорировать ее и защищать по требованиям ФСТЭК и ФСБ.
- Аутсорсинг и администрирование: Если разработчик берет на себя техническую поддержку, обновление и администрирование софта, установленного на серверах КИИ-заказчика. Имея удаленный доступ с правами суперпользователя, IT-компания интегрируется в чужой контур КИИ.
- Разработка заказного ПО: Создание уникальных модулей, которые управляют технологическими процессами или финансовыми транзакциями на стороне клиента из КИИ-сферы.
Чем грозит статья 274.1 УК РФ для руководства и IT-специалистов?
Статья 274.1 УК РФ регулирует неправомерное воздействие на критическую информационную инфраструктуру Российской Федерации. Она применяется не только к внешним хакерам, но и к внутренним сотрудникам IT-подрядчиков (разработчикам, системным администраторам, DevOps-инженерам, директорам), чьи действия или бездействие привели к сбою в КИИ.
Уголовная ответственность дифференцируется по пяти частям статьи:
Уголовная ответственность дифференцируется по пяти частям статьи:
Уголовная ответственность дифференцируется по пяти частям статьи:
- Часть 1 (Создание или распространение вредоносных программ): Наказание до 5 лет лишения свободы. Под это определение может попасть передача неоттестированного кода, содержащего критические уязвимости (бэкдоры) или недокументированные функции.
- Часть 2 (Неправомерный доступ к информации в КИИ): Наказание до 6 лет лишения свободы. Сюда относится использование технических доступов (SSH-ключей, VPN-доступов) сотрудниками IT-компании вне рамок официального технического задания или регламента.
- Часть 3 (Нарушение правил эксплуатации): Наказание до 6 лет лишения свободы. Ключевая часть для IT-специалистов. Наступает, если нарушение регламентов, инструкций, правил обновления софта или проведения технических работ повлекло причинение вреда КИИ.
- Часть 4 (Действия по предварительному сговору или группой лиц): Наказание от 3 до 8 лет лишения свободы. Применяется, если ошибка или несанкционированное действие совершены командой разработки по согласованию с техническим директором.
- Часть 5 (Тяжкие последствия): Наказание от 5 до 10 лет лишения свободы. Наступает, если сбой в системе привел к длительной остановке работы банка, отключению электроэнергии, сбою в медицинском оборудовании или крупному материальному ущербу.
Уголовная ответственность дифференцируется по пяти частям статьи:
- Часть 1 (Создание или распространение вредоносных программ): Наказание до 5 лет лишения свободы. Под это определение может попасть передача неоттестированного кода, содержащего критические уязвимости (бэкдоры) или недокументированные функции.
- Часть 2 (Неправомерный доступ к информации в КИИ): Наказание до 6 лет лишения свободы. Сюда относится использование технических доступов (SSH-ключей, VPN-доступов) сотрудниками IT-компании вне рамок официального технического задания или регламента.
- Часть 3 (Нарушение правил эксплуатации): Наказание до 6 лет лишения свободы. Ключевая часть для IT-специалистов. Наступает, если нарушение регламентов, инструкций, правил обновления софта или проведения технических работ повлекло причинение вреда КИИ.
- Часть 4 (Действия по предварительному сговору или группой лиц): Наказание от 3 до 8 лет лишения свободы. Применяется, если ошибка или несанкционированное действие совершены командой разработки по согласованию с техническим директором.
- Часть 5 (Тяжкие последствия): Наказание от 5 до 10 лет лишения свободы. Наступает, если сбой в системе привел к длительной остановке работы банка, отключению электроэнергии, сбою в медицинском оборудовании или крупному материальному ущербу.
Почему игнорирование регламентов КИИ становится поводом для преследования?
Правоохранительные органы и регуляторы (ФСТЭК, ФСБ) используют формальный подход: если произошел инцидент информационной безопасности или технический сбой, проверяется строгое соблюдение установленных государством регламентов. Игнорирование правил автоматически доказывает вину ИТ-компании.
Основные регламенты КИИ, за нарушение которых привлекают к ответственности:
Основные регламенты КИИ, за нарушение которых привлекают к ответственности:
- Приказ ФСТЭК России № 235: Утверждает требования к созданию систем безопасности субъектов КИИ. Игнорирование этого приказа означает отсутствие на предприятии сертифицированных средств защиты информации (СЗИ), межсетевых экранов и систем обнаружения вторжений.
- Приказ ФСТЭК России № 239: Устанавливает требования по обеспечению безопасности значимых объектов КИИ. Он обязует проводить аудит уязвимостей, контролировать обновления ПО и вести строгий учет конфигураций систем. Если обновление софта "уронило" базу данных КИИ-объекта, а процедура предварительного тестирования на тестовом стенде не была задокументирована, это трактуется как нарушение 239-го приказа.
- Указы Президента № 166 и № 250: Запрещают использование иностранного программного обеспечения и средств защиты информации на значимых объектах КИИ. Если IT-компания внедрила в продукт для банка или энергетической компании зарубежную библиотеку без сертификации или софт из недружественных стран, это расценивается как прямое нарушение законодательства, создающее угрозу национальной безопасности.
- Регламент ГосСОПКА: Субъекты КИИ обязаны информировать Национальный координационный центр по компьютерным инцидентам (НКЦКИ) обо всех атаках и сбоях в течение 24 часов (для значимых объектов) или 72 часов. Сокрытие инцидента IT-компанией с целью избежать штрафов переводит дело из плоскости технического сбоя в уголовную плоскость.
Как защитить IT-компанию от скрытых рисков КИИ: пошаговое руководство
Чтобы обезопасить бизнес, руководство и инженерный состав от уголовной ответственности, необходимо перестроить юридические и технические процессы взаимодействия с клиентами.
Шаг 1. Проведите аудит клиентской базы и архитектуры продуктов
Составьте полный список контрагентов. Запросите у каждого крупного клиента официальное уведомление: является ли их организация субъектом КИИ, и входят ли ваши программные продукты в контур КИИ. Определите тип размещения вашего ПО: на серверах заказчика (On-Premise) или в вашем облаке (SaaS).
Шаг 2. Разграничьте зоны ответственности в договорах и SLA
В договорах на разработку и техническую поддержку (SLA) четко пропишите границы ответственности:
Шаг 3. Внедрите регламент безопасной разработки (DevSecOps)
Задокументируйте и строго соблюдайте внутренние технические правила:
Шаг 4. Организуйте ведение и хранение цифровых следов (Логов)
Настройте систему сбора и хранения логов (SIEM) внутри IT-компании. Логи авторизации сотрудников, логи коммитов в репозитории, записи сессий удаленного подключения к серверам клиентов должны храниться в неизменяемом виде не менее 3 лет. Это позволит доказать следствию, что конкретный сбой не был вызван действиями ваших специалистов.
Шаг 1. Проведите аудит клиентской базы и архитектуры продуктов
Составьте полный список контрагентов. Запросите у каждого крупного клиента официальное уведомление: является ли их организация субъектом КИИ, и входят ли ваши программные продукты в контур КИИ. Определите тип размещения вашего ПО: на серверах заказчика (On-Premise) или в вашем облаке (SaaS).
Шаг 2. Разграничьте зоны ответственности в договорах и SLA
В договорах на разработку и техническую поддержку (SLA) четко пропишите границы ответственности:
- Зафиксируйте, что IT-компания не несет ответственности за сбои, вызванные действиями инфраструктуры заказчика.
- Пропишите регламент предоставления удаленного доступа (VPN, SSH). Доступы должны открываться заказчиком только на время проведения конкретных регламентных работ и полностью логироваться на его стороне.
- Введите пункты о форс-мажоре, связанном с недокументированными уязвимостями в стороннем ПО (Open Source), используемом в проекте.
Шаг 3. Внедрите регламент безопасной разработки (DevSecOps)
Задокументируйте и строго соблюдайте внутренние технические правила:
- Проводите обязательный статический (SAST) и динамический (DAST) анализ кода на наличие уязвимостей перед каждым релизом.
- Запретите прямое внесение изменений в рабочую среду (production) КИИ-объекта. Любые обновления должны проходить стадию тестирования на изолированном staging-сервере.
- Заведите журналы ознакомления сотрудников с правилами информационной безопасности.
Шаг 4. Организуйте ведение и хранение цифровых следов (Логов)
Настройте систему сбора и хранения логов (SIEM) внутри IT-компании. Логи авторизации сотрудников, логи коммитов в репозитории, записи сессий удаленного подключения к серверам клиентов должны храниться в неизменяемом виде не менее 3 лет. Это позволит доказать следствию, что конкретный сбой не был вызван действиями ваших специалистов.