Какие объекты IT-компании могут относиться к КИИ
К объектам критической информационной инфраструктуры относят не любую информационную систему, а только ту, сбой которой способен затронуть значимые процессы. Для IT-компании это может быть информационная система, информационно-телекоммуникационная сеть или автоматизированная система управления, если через нее обеспечиваются функции, связанные с обработкой данных, управлением сервисами, обменом информацией или поддержкой технологических процессов.
Категорирование объектов критической информационной инфраструктуры для IT-компаний обычно начинается с проверки сферы деятельности и состава используемых систем. https://andreyex.ru/stati-partnerov/inzheneriya/kategorirovanie-obektov-kii-neobhodimo-li-ono-dlya-it-kompanij-i-zachem-provoditsya/ Подробный порядок описан в материале о категорировании объектов КИИ. Если объект обслуживает только внутренние офисные задачи и его отказ не влияет на устойчивость ключевых процессов, он может не попасть под регулирование.
Признаки объекта, который попадает под регулирование
К признакам относятся наличие устойчивой связи с основным процессом, участие в передаче или хранении значимых данных, а также влияние на доступность, целостность или конфиденциальность информации. Значение имеет не только назначение системы, но и последствия ее нарушения: простой сервиса, потеря данных, искажение сведений, сбой интеграций, нарушение технологической цепочки.
Если объект обслуживает функции, без которых работа компании или связанных с ней процессов нарушается в заметном объеме, он подлежит оценке на категорию значимости. При этом учитываются не названия систем, а фактическая роль объекта и его взаимосвязи с другими ресурсами.
Где проходит граница между обычной системой и объектом КИИ
Граница проходит по уровню последствий инцидента. Обычная система поддерживает вспомогательные задачи и при отказе не создает существенного ущерба. Объект КИИ связан с процессами, где сбой может привести к масштабным нарушениям, затронуть несколько подразделений, внешних пользователей или технологические контуры.
Для разграничения анализируют архитектуру, точки интеграции, состав данных, сценарии отказа и наличие резервирования. Если система дублируется без потери управляемости процесса, это снижает вероятность отнесения к значимым объектам, но не отменяет анализа.
По каким критериям присваивают категорию значимости
Категорирование определяет степень значимости объекта по критериям, которые описывают возможные последствия нарушения его функционирования. Оценивают масштаб ущерба, последствия для безопасности, влияние на выполнение задач и объем нарушений, которые возникнут при инциденте.
Масштаб возможного ущерба и последствия инцидента
При оценке учитывают продолжительность простоя, число затронутых пользователей, объем потерянных или искаженных данных, влияние на смежные системы и вероятность нарушения обязательств перед клиентами или партнерами. Для автоматизированных систем управления значимым фактором становится влияние на технологический процесс, где ошибка может вызвать остановку оборудования или сбой производственной логики.
Технически важны и характеристики самого объекта: наличие резервного копирования, журналирования, сегментации сети, механизмов восстановления и контроля доступа. Эти параметры не заменяют оценку по критериям, но помогают определить, насколько быстро нарушение перейдет в инцидент с существенными последствиями.
Как различаются первая, вторая и третья категории
Первая категория присваивается объектам, для которых последствия нарушения наиболее тяжелые и затрагивают крупный масштаб процессов. Вторая категория применяется, если ущерб ниже, но инцидент все еще способен вызвать серьезные сбои. Третья категория отражает меньший уровень значимости, когда последствия ограничены по масштабу, но объект все же относится к регулируемым.
Если объект не достигает порогов ни по одному из критериев, он признается некатегорируемым. Такое решение возможно только после анализа исходных данных и сравнения фактических функций объекта с установленными признаками значимости.
Как организовать категорирование внутри компании
Процедура начинается с назначения ответственных лиц и формирования комиссии по категорированию. Субъект КИИ организует сбор исходных данных, а комиссия анализирует свойства объекта и риски, после чего оформляет результат в установленном документе.
Подготовка перечня объектов и сбор исходных сведений
На первом этапе составляют перечень всех информационных систем, сетей и автоматизированных систем управления, которые могут быть связаны с критичными процессами. Затем собирают сведения о назначении объекта, архитектуре, составе программных и аппаратных компонентов, потоках данных, взаимосвязях с другими системами и сценариях отказа.
Полезны внутренние регламенты, схемы интеграций, описания процессов, перечни пользователей, данные о резервировании и восстановлении. Неполные исходные сведения искажают оценку, поэтому документы сверяют между подразделениями, которые эксплуатируют объект и используют его результаты.
Работа комиссии и оформление решения
Комиссия сопоставляет собранные данные с критериями значимости, оценивает последствия инцидента и фиксирует вывод по каждому объекту. По результатам оформляют акт или иной предусмотренный документ, где указывают присвоенную категорию либо решение о некатегорируемости.
После утверждения результата сведения закрепляют во внутренних процессах: обновляют перечни объектов, регламенты реагирования, схемы контроля и процедуры защиты. Если категория определена неверно, ошибки переходят в дальнейшее управление рисками и затрагивают меры защиты, отчетность и планы восстановления.
Какие риски и ошибки возникают при категорировании
Ошибки чаще связаны с неполным учетом процессов, формальным сбором сведений и попыткой оценивать систему без анализа реального влияния на деятельность компании. Неверная категория может появиться, если не учтены интеграции, зависимости от внешних сервисов или цепочки передачи данных между подсистемами.
Неполные данные, неверная оценка и формальный подход
Распространенная ошибка — рассматривать объект только по его названию или техническому паспорту, без проверки фактической нагрузки и сценариев отказа. Еще одна проблема — исключение из анализа резервных контуров, каналов связи, средств удаленного доступа и хранилищ данных, хотя именно они меняют последствия инцидента.
Формальный подход приводит к тому, что категория значимости выбирается без расчета масштаба ущерба и без сопоставления с критериями. Это создает риск несоответствия требованиям и осложняет последующие действия по защите объекта.
Что проверить после завершения процедуры
После завершения категорирования проверяют, закреплены ли результаты во внутренних документах, обновлены ли перечни объектов и отражены ли требования в регламентах эксплуатации и реагирования. Дополнительно сверяют, совпадают ли сведения в акте с фактической архитектурой системы и не появились ли новые интеграции, которые меняют оценку.
Если объект меняет функции, состав данных или контуры взаимодействия, ранее присвоенная категория может потребовать пересмотра. Для IT-компании это означает не разовую формальную процедуру, а постоянную проверку связи между системой, процессом и последствиями сбоя.