Требования к информационной безопасности банков Казахстана: что это значит для AppSec

Требования к ИБ банков Казахстана устанавливает Агентство по регулированию и развитию финансового рынка (АРРФР), которое с 2026 года заменило прежние требования Нацбанка собственными актами: постановлением № 53 от 3 апреля 2026 года и постановлением № 81 от 20 апреля 2026 года. Для AppSec это означает необходимость доказуемо тестировать свои приложения, управлять уязвимостями и отвечать за результат на уровне первого руководителя. Ниже — какие акты мы подтвердили по официальным и справочным источникам и что из них следует для безопасной разработки.

Какие акты регулируют ИБ банков в Казахстане

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

• Постановление Правления АРРФР от 3 апреля 2026 года № 53 «Об утверждении Требований к обеспечению информационной безопасности банков, филиалов банков-нерезидентов Республики Казахстан и организаций, осуществляющих отдельные виды банковских операций». По данным справочной системы, введено в действие с 18 апреля 2026 года; принято на основании статьи 55 Закона «О банках и банковской деятельности». Структура: общие положения, система управления ИБ, категорирование информационных активов, доступ к активам, безопасность информационной инфраструктуры.
• Постановление Правления АРРФР от 20 апреля 2026 года № 81 «Об утверждении минимальных требований по обеспечению информационной безопасности на финансовом рынке». Вступило в силу 12 июля 2026 года. По комментарию юридической фирмы, охватывает банки, страховщиков, участников рынка ценных бумаг, МФО и другие финансовые организации.
• Постановление Правления Нацбанка от 27 марта 2018 года № 48 (рег. № 16772) — прежние требования к ИБ банков и правила уведомления об инцидентах. Утратило силу в связи с принятием постановления АРРФР № 53.
• Цифровой кодекс РК от 9 января 2026 года № 255-VIII — вступил в силу в июле 2026 года; задаёт рамку кибербезопасности, детали вынесены в подзаконные акты.
• Закон «Об информатизации» от 24 ноября 2015 года № 418-V — на него ссылаются Единые требования в области ИКТ и ИБ.

Важная оговорка про «Единые требования»: это постановление Правительства РК от 20 декабря 2016 года № 832, а не акт АРРФР. Они обязательны для госорганов, квазигосударственного сектора, владельцев критически важных объектов ИКТ и владельцев негосударственных информационных систем, интегрированных с государственными. При этом сам документ исключает случаи, когда его применение противоречит банковскому законодательству. Поэтому для банка основной документ — требования АРРФР, а Единые требования становятся актуальными там, где ваша система интегрирована с государственными сервисами.

Что требовали прежние нормы к безопасной разработке

Постановление № 48 в прежней редакции содержало конкретные нормы для программного обеспечения дистанционных услуг (по тексту, опубликованному в справочной системе до его отмены):

• исходный код хранится в системах управления репозиториями внутри периметра безопасности, с резервным копированием;
• среды разработки и тестирования отделены от промышленной, разработчики не вносят изменения в продуктив;
• перед запуском меняются настройки безопасности по умолчанию и удаляются тестовые учётные записи;
• обязательное тестирование безопасности, включающее как минимум статический анализ кода и анализ компонентов и сторонних библиотек (то есть SAST и SCA по сути);
• критические уязвимости устраняются до ввода в эксплуатацию, ответственность за разработку, выполненную подрядчиком, остаётся на банке;
• сканирование информационных активов не реже раза в полгода, пентест инфраструктуры силами независимых внешних специалистов.

Мы не нашли открытого полного текста постановления № 53 и поэтому не утверждаем, какие из этих норм перенесены в него дословно. Практическое правило: исходите из того, что прежний уровень требований сохранится или вырастет, а точные формулировки сверяйте по тексту на adilet.zan.kz.

Что подтверждено в новых актах

По комментарию к постановлению № 81 (источник — юридическая фирма, не текст акта):

• первый руководитель финансовой организации несёт персональную ответственность за информационную безопасность;
• об инцидентах (эксплуатация уязвимостей ПО, несанкционированный доступ, DDoS, заражение серверов, несанкционированные переводы, простои более часа) нужно незамедлительно сообщать через автоматизированную систему обработки инцидентов (АСОИ);
• для внешнего доступа нужно не менее двух независимых факторов аутентификации;
• журналы аудита хранятся с защитой целостности (три месяца онлайн и год в архиве либо год онлайн);
• при использовании внешних серверов и сервисов хранения организация обязана не допускать доступа третьих лиц к данным, которые закон запрещает раскрывать, включая персональные данные.

Эти положения напрямую касаются разработки: инциденты по эксплуатации уязвимостей ПО — отдельная категория уведомления, а значит, управление уязвимостями приложений становится вопросом отчётности перед регулятором.

Что это значит для практики AppSec

1. Статический анализ и SCA в процессе, а не раз в год. Если регулятор ждёт доказательств анализа кода и сторонних компонентов, нужны отчёты по каждой сборке. Начните с выбора классов инструментов и встройте их в CI/CD.
2. Реестр компонентов (SBOM). Чтобы за часы понять, затронуты ли вы новой уязвимостью, нужен актуальный перечень зависимостей — см. что такое SBOM.
3. Независимое тестирование. Внешний пентест и оценка защищённости критичных систем остаются стандартной практикой банков — подробнее об этой услуге на странице анализа защищённости.
4. Исходный код внутри периметра. Репозитории, CI и сканеры, работающие в контуре банка, проще защитить, чем внешние сервисы. Это один из аргументов в пользу on-premise решений.
5. Секреты и ключи. Требования к аутентификации и разграничению доступа распространяются на сервисные учётные записи и токены — см. управление секретами.
6. Подрядчики. За код подрядчика отвечает банк: нужны требования к безопасной разработке в договорах и проверка поставляемых сборок.

Выстроить процесс целиком помогает внедрение DevSecOps: оно превращает требования регулятора в проверки на каждом этапе конвейера и в готовую отчётность.

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

• Получить актуальные тексты постановлений № 53 и № 81 и составить матрицу «требование — мера — доказательство».
• Классифицировать приложения по критичности: от этого зависят глубина тестирования и частота проверок.
• Проверить, где в банке нет доказательств: отчётов SAST/SCA, результатов пентеста, журнала устранения уязвимостей.
• Согласовать с ИБ-службой процедуру уведомления об инцидентах, связанных с уязвимостями приложений.

Единые требования: что в них важно для разработчиков

Если часть систем банка интегрирована с государственными (например, с платформой «электронного правительства»), в игру вступают Единые требования (постановление № 832). По тексту в справочной системе, последние изменения в них внесены постановлением Правительства № 119 от 25 февраля 2026 года. Что в них содержится по теме ИБ:

• логи событий хранятся не менее трёх лет и не менее двух месяцев доступны для оперативного анализа; объекты «электронного правительства» классов 1 и 2 подключаются к системе мониторинга ИБ;
• для объектов классов 1 и 2 требуется многофакторная аутентификация;
• в числе обязательных документов — отчёт об оценке уязвимостей сетевых ресурсов и процедура уведомления об инцидентах и реагирования на них;
• ввод объектов «электронного правительства» в промышленную эксплуатацию осуществляется из исполняемого кода, собранного из исходного кода, переданного Государственной технической службе, по правилам единого репозитория.

Требований к SDLC и испытаниям на проникновение в доступной нам части текста мы не обнаружили, но документ длинный, а испытания объектов «электронного правительства» и критически важных объектов ИКТ регулируются отдельными методиками, утверждаемыми на основании Закона «Об информатизации». Если вы интегрируетесь с госсистемами, выясните класс объекта и связанные с ним требования.

Как построить матрицу соответствия

1. Выпишите требования из № 53 и № 81 в таблицу: пункт, формулировка, владелец, мера, доказательство.
2. Для каждого приложения укажите категорию критичности и тип данных, которые оно обрабатывает.
3. Свяжите требования с конкретными шагами конвейера: SAST и SCA на каждый pull request, DAST перед релизом, ручной пентест раз в период, который определит ваша политика.
4. Настройте автоматический сбор отчётов: аудитору легче показать выгрузку из системы, чем собирать скриншоты.
5. Назначьте ответственных за устранение уязвимостей и сроки по критичности.

Такая матрица пригодится и при проверке подрядчиков: те же требования можно включить в договор на разработку.

Частые вопросы

Статья носит информационный характер и не является юридической консультацией.

Источники

• Постановление АРРФР от 3 апреля 2026 года № 53 (prg.kz)
• Постановление Правления Нацбанка от 27 марта 2018 года № 48 (утратило силу)
• Минимальные требования к ИБ на финансовом рынке — постановление № 81 (комментарий SOLIS Partners, prg.kz)
• Постановление Правительства РК от 20 декабря 2016 года № 832 (Единые требования)
• Цифровой кодекс: что меняется для граждан и бизнеса (zakon.kz)