Cgfcb
Ми зв'яжемося з вами найближчим часом
Что изменил норматив № 19/1
В августе 2025 года Центральный банк Республики Узбекистан утвердил норматив № 19/1 — новые минимальные требования к информационной и кибербезопасности коммерческих банков, включая микрофинансовые.
Документ смещает отрасль от реактивной модели к зрелой: он предписывает непрерывный круглосуточный мониторинг ИТ-активов, прозрачность цифровых сервисов, способность выявлять аномалии в реальном времени, немедленное уведомление регулятора о серьёзных инцидентах и взаимодействие с центром кибербезопасности CERT-CBU.
Среди принципиальных изменений — запрет на аутсорсинг функций управления и кибербезопасности и обязательное создание отдельной службы с прямой ответственностью за защиту данных.
Уровень выполнения требований отражается в рейтинговой системе ЦБ, превращая кибербезопасность в публичный и измеримый показатель, влияющий на репутацию и положение банка на рынке. Для CIO, CISO и CTO это новый уровень ответственности и прозрачности.
Получите сводную карту соответствия
В отличие от обзорных материалов, этот разбор сфокусирован на конкретных пунктах норматива, которые напрямую ложатся на возможности единой платформы наблюдаемости (observability) и безопасности. Для каждого требования мы указываем конкретную возможность Dynatrace и честно отмечаем границы — там, где платформа дополняет специализированное средство контроля, а не заменяет его.
Рассмотрены шесть групп требований: обнаружение инцидентов (п. 30), доказательная целостность журналов (логов) и резервных копий (п. 32), аудит действий пользователей (п. 43), мониторинг активности баз данных (п. 53), состояние сетевых устройств и средств защиты (п. 67), а также безопасность приложений (пп. 156, 164, 79).
Обнаружение инцидентов и постоянная рабочая группа (п. 30)
Требование. В банке внедряются системы мониторинга для получения сведений об инцидентах ИБ; создаётся постоянно действующая рабочая группа для контроля работы этих систем и устранения возникающих инцидентов.
Ключевая сложность здесь не в том, чтобы собрать события, а в том, чтобы рабочая группа не утонула в потоке разрозненных оповещений. Классические системы порогового мониторинга генерируют тысячи сигналов, среди которых теряются критические важные.
Dynatrace опирается на встроенный ИИ-движок Davis, который не просто собирает телеметрию, а автоматически определяет причинно-следственные связи, объединяет связанные сигналы в единую проблему и приоритизирует её по степени влияния на бизнес. Вместо «шторма» алертов рабочая группа получает ограниченный набор обоснованных карточек инцидентовс уже установленной первопричиной и зоной влияния — круглосуточно, в режиме реального времени. Это и есть операционная основа для постоянно действующей группы, предусмотренной нормативом.
Доказательная база инцидента: целостность журналов и резервных копий (п. 32)
Требование. Сведения об инцидентах документируются Службой; при их обнаружении используются данные систем мониторинга ИБ, а электронные журналы информационных систем и резервные копии (backup, snapshot и др.) серверов на момент события сохраняются с обеспечением их целостности.
Хранилище данных Dynatrace Grail удерживает весь спектр телеметрии в едином пространстве с возможностью расследования на языке запросов DQL. Это позволяет восстановить полную хронологию событий в конкретный промежуток времени и предоставить регулятору и CERT-CBU не просто факт сбоя, а детальную картину того, что, где и почему произошло. Целостность доказательной базы обеспечивается политиками хранения и контролем доступа к данным.
Граница решения. Создание снимков и резервных копий самих серверов (образов виртуальных машин) — инфраструктурная задача систем резервного копирования. Dynatrace сохраняет телеметрический доказательный контур — логи, трассировки, метрики и события, — который дополняет серверные бэкапы и дает им необходимый контекст при расследовании.
Аудит действий пользователей: логи, трассировки и RUM (п. 43)
Требование. Фиксируются дата (день/месяц/год) и время (час/минута/секунда) операции; идентификатор пользователя в системах и приложениях; идентификационные данные устройства (IP-адрес, MAC-адрес, имя устройства и иные идентификаторы); все операции и действия пользователя в течение активной сессии — в соответствующих электронных протоколах. Изменять или удалять записи вправе только уполномоченные приказом председателя правления сотрудники Службы.
Это требование покрывается тремя взаимодополняющими слоями телеметрии Dynatrace. Логи фиксируют структурированные события с атрибутами (время, идентификаторы). Распределённые трассировки (PurePath) сопровождают каждую транзакцию сквозь все компоненты с полным контекстом запроса и пользователя. Real User Monitoring (RUM) фиксирует действия пользователя на уровне сессии, тип устройства, IP-адрес и геолокацию, а при необходимости — воспроизведение сессии. Вместе они дают тот самый «электронный протокол» действий, который требуется по нормативу.
Граница решения. Захват MAC-адреса и принцип «изменять записи может только уполномоченный сотрудник» реализуются на уровне источника телеметрии и модели доступа: данные в Grail управляются ролевыми политиками IAM, а сроки хранения и неизменяемость задаются настройками хранилища. Полнота отдельных атрибутов (например, MAC) зависит от того, какой источник их передаёт.
Контроль активности баз данных (п. 53)
Требование. В банке внедряется система мониторинга активности баз данных (DAM, Database Activity Monitoring) для оперативного выявления и предотвращения подозрительных действий в режиме реального времени.
Dynatrace обеспечивает глубокую наблюдаемость (observability) баз данных: контроль на уровне отдельных SQL-запросов через распределённые трассировки, мониторинг состояния и производительности СУБД через расширения для Oracle, Microsoft SQL Server, PostgreSQL и MySQL (включая сбор аудит-логов и сведений о заблокированных сессиях), а также выявление аномалий в реальном времени средствами Davis — например, аномального роста числа запросов или нагрузки на сервер. События специализированного DAM-решения могут передаваться в Dynatrace для корреляции в едином аналитическом контуре.
Граница решения. DAM — это самостоятельный класс средств безопасности, и Dynatrace его дополняет, а не заменяет. В частности, Dynatrace связывает SQL-запрос с породившим его сервисом или действием пользователя приложения, но не идентифицирует конкретного пользователя базы данных на уровне отдельного запроса. Рекомендуемая модель — связка «специализированное DAM как контроль безопасности + Dynatrace как слой наблюдаемости (observability) и корреляции по бизнес-влиянию».
Состояние сетевых устройств и средств защиты (п. 67)
Требование. Ведутся мониторинг состояния ПО и технических средств, применяемых для обеспечения сетевой безопасности, сбор и анализ статистических данных, раннее выявление проблем и предотвращение чрезвычайных ситуаций на их основе.
Dynatrace распространяет единую наблюдаемость (observability) на сетевую инфраструктуру через SNMP-расширения: Generic Network Device, Generic Cisco Device, Juniper (SNMP), F5 BIG-IP, Fortinet FortiGate и другие. Модуль SNMP Traps обеспечивает событийный алертинг (обрыв связи, перегрев, отказ компонента), а механизмы автообнаружения (SNMP Autodiscovery, Discovery & Coverage) находят устройства в сети и подключают подходящее расширение. Davis выявляет аномалии в метриках интерфейсов — ошибки, сброс пакетов, утилизацию — на ранней стадии, до перерастания в инцидент. Все эти данные сводятся на единую платформу рядом с прикладной и инфраструктурной телеметрией.
Граница решения. Dynatrace — не полноценная система класса NPM/NDR. Платформа отслеживает или показывает состояние, производительность и статистику сетевых устройств и средств защиты, а также обеспечивает алертинг по SNMP-трапам, дополняя специализированные сетевые средства, но не заменяя глубокий анализ трафика.
Безопасность приложений в среде исполнения (пп. 156, 164, 79)
Требование. Регулярное сканирование и устранение уязвимостей с использованием баз CVE, оценкой по CVSS, установкой обновлений (patch) и отчётностью руководству (п. 156); проверка уязвимостей до ввода системы в эксплуатацию (п. 164); защита интернет-сервисов средствами IDS/IPS, WAF и Anti-DDoS (п. 79).
Dynatrace Application Security покрывает прикладную часть этих требований двумя модулями. Runtime Vulnerability Analytics непрерывно выявляет уязвимости в сторонних библиотеках, средах исполнения и собственном коде, сопоставляя их с базами CVE (NVD и собственный фид Dynatrace) и оценками CVSS v3/v4. Davis Security Score добавляет контекст среды исполнения — доступность из интернета и достижимость уязвимого кода, — это позволяет отделить действительно критичные уязвимости от теоретических, а Davis Security Advisor рекомендует приоритетные патчи и интегрируется с системами тикетов. Это напрямую отвечает требованиям пп. 156 и 164, в том числе на этапе препродакшна.
Runtime Application Protection обеспечивает защиту в среде исполнения (подход RASP): в реальном времени выявляет и блокирует атаки на уровне приложения — SQL-инъекции, инъекции команд, JNDI-инъекции (вектор Log4Shell) и обход путей. Оба модуля работают на том же агенте OneAgent, что и мониторинг производительности, что избавляет от необходимости развёртывания отдельных агентов или сетевых устройств.
Граница решения. Runtime Application Protection дополняет сетевой WAF и Anti-DDoS из п. 79, но не заменяет их: защита от объёмных DDoS-атак и фильтрация трафика на сетевом периметре остаются задачей специализированных средств. Контроль кода на этапе сборки — SAST/DAST из п. 163 — также выходит за рамки возможностей платформы и требует внедрения отдельного инструмента в конвейер CI/CD. Отдельные требования к гостевым Wi-Fi-зонам (п. 84) относятся к физическим и сетевым средствам контроля и не входят в область компетенций observability-платформы.
Выводы
Норматив № 19/1 ЦБ Узбекистана — это системный сдвиг в том, как регулятор измеряет зрелость банка в области кибербезопасности. Требования к непрерывному мониторингу, быстрому реагированию, прозрачности процессов и доказательной базе формируют новую операционную реальность для CIO, CISO и CTO.
Dynatrace как унифицированная платформа для observability и безопасности закрывает значительную часть технических требований норматива — обнаружение инцидентов (п. 30), доказательную целостность телеметрии (п. 32), аудит действий пользователей (п. 43), состояние сетевых устройств (п. 67), безопасность приложений в среде исполнения (пп. 156, 164, 79) — и существенно усиливает контроль активности баз данных (п. 53).
При честном понимании границ: специализированные DAM-решения, сетевые NPM/NDR, WAF и Anti-DDoS, а также SAST/DAST остаются самостоятельными средствами, которые Dynatrace объединяет в единый аналитический контур и корреляцией с учетом их влияния на бизнес-процессы. Итог для банка — меньше инцидентов, быстрее реакция, контроль изменений и реальная доказательная база для регулятора и CERT-CBU.
BAKOTECH, как официальный дистрибьютор Dynatrace в Узбекистане, готов помочь банкам пройти путь от оценки текущего состояния до полноценного внедрения платформы — глобально проверенного решения, локально поддержанного экспертизой.