Операционная надежность по 850-П: почему обычного учета ИТ-активов уже недостаточно

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

При этом меняется и само представление о том, что значит «учитывать ИТ»: инвентарного перечня серверов, программного обеспечения и систем становится недостаточно. Регуляторные требования подводят банки к более сложной модели, в которой технологический процесс связан с автоматизированными системами, системы – с компонентами, а компоненты описаны через набор технических, функциональных и классификационных характеристик.

От показателей надежности – к структуре ИТ-инфраструктуры

Положение Банка России № 850-П, вступившее в силу в 2025 году, устанавливает требования к операционной надежности кредитных организаций. Для технологических процессов определяются допустимое время простоя, а также сигнальные и контрольные значения допустимой доли деградации. Положение № 716-П, в свою очередь, включает риск информационных систем и риск информационной безопасности в контур управления операционным риском.

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

В 2026 году этот тренд получил новое развитие. Указание Банка России № 7419-У от 22 июля 2026 года вносит изменения в 850-П. Документ официально опубликован 3 сентября 2026 года. Большая часть изменений вступает в силу с 1 января 2027 года, а подпункт 1.5, которым вводится новый подпункт 7.1¹ о подробном учете объектов информационной инфраструктуры, – с 1 января 2028 года.

Регулятору нужен уже не просто перечень активов

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

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

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

18-МР заранее показали направление

Подход возник не в 2026 году. В Методических рекомендациях Банка России № 18-МР от 20 декабря 2023 года для описания наименований объектов информационной инфраструктуры предложен набор из 34 атрибутов. Среди них – технологический процесс, автоматизированная система, технологический участок, бизнес-функция, функциональное значение и критичность системы, разработчик, системы – источники и получатели данных. Для ИТ-продуктов дополнительно используются класс оборудования или ПО, страна, лицензирование, архитектура, закупка, техническая поддержка, автономность, обновление, уязвимости, управление, сертификаты и сведения из государственных реестров.

Показательна сама механика: наименование объекта 18-МР рекомендуют формировать перечислением значений этих атрибутов, разделенных символом «|». По сути, за «наименованием» скрывается структурированное описание объекта.

18-МР остаются методическими рекомендациями. Но 7419-У уже закрепляет обязанность определять, фиксировать и актуализировать значительную часть сходной информации в рамках требований 850-П. Поэтому происходящее разумно рассматривать не как появление еще нескольких полей, а как постепенное формирование регуляторного представления ИТ-инфраструктуры банка.

Почему обычной CMDB или discovery может оказаться мало

У крупного банка обычно уже есть несколько систем, каждая из которых знает об инфраструктуре свою часть. Discovery дает фактический состав обнаруживаемого оборудования и ПО, средства виртуализации – виртуальную инфраструктуру, IPAM – адресацию, CMDB – конфигурационные единицы и часть связей, архитектурные репозитории – информационные системы и их взаимодействие, учетные системы – закупки и договоры, средства ИБ – уязвимости и защитные характеристики.

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

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

Разная гранулярность учета. В одной системе объектом является физический сервер, в другой – виртуальная машина, в третьей – кластер, в четвертой – автоматизированная система целиком. Регуляторное представление требует связать эти уровни, а не выбрать один из них.

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

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

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

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

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

Отчетность – потребитель модели, а не сама модель

У банков уже есть несколько регуляторных и статистических представлений ИТ. Форма 0409072 связывает операционную надежность с технологическими процессами и применяемыми информационными технологиями; форма 0409070 рассматривает использование информационных систем при выполнении банковских операций; форма 3-информ использует данные об оборудовании, ПО и затратах на цифровые технологии.

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

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

Что придется изменить в системах учета ИТ

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

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

Разобрать источники атрибутов. Не все сведения должен вести ITAM. Часть данных логично получать из discovery, часть – из архитектурных систем, ИБ, закупок, договорного учета и внешних реестров.

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

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

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

Где здесь место ITAM

В такой архитектуре ITAM не обязан заменять CMDB, discovery, архитектурный репозиторий, IPAM, ERP или средства информационной безопасности. Попытка сделать одну систему первичным владельцем всех данных чаще усложняет ландшафт.

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

Именно в таком направлении развивается SkyV ITAM. Платформа позволяет консолидировать сведения из discovery, ITSM/CMDB, средств виртуализации, систем учета ЦОД, корпоративных учетных систем и других источников; сопоставлять и нормализовать объекты, расширять их атрибутивную модель и поддерживать связи между ними. Для банковского сценария поверх этого может формироваться специализированное представление инфраструктуры с необходимыми регуляторными классификаторами, атрибутами и контролями заполнения.

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

К 2028 году нужен не новый Excel

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

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

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