За предыдущее десятилетие банки стали центром ИТ-инноваций и высочайшей культуры разработки и эксплуатации ИТ-сервисов. Однако из-за жёсткого регулирования внедрение в банках даже простых и привычных сервисов часто требует усложнений.
Я Михаил Никифоров, эксперт К2Тех по ВКС. Эту статью мы подготовили вместе с моими коллегами - Ольгой Трофимовой, руководителем направления консалтинга в К2 Кибербезопасность, и Василием Куцем, директором по отраслевым решениям в коммерческих банках К2Тех.
Хочу рассказать о специфике требований к ИТ-инфраструктуре в банках и на примере показать, как реализация этих требований отражается на довольно-таки стандартных проектах.
Требования регулятора к ИБ в банках
На банковские ИТ-системы распространяется достаточно большой объем требований в области информационной безопасности со стороны как российского законодательства, так и международных организаций:
Регулятор банковской и финансовой сферы России — Центробанк. Он разрабатывает нормативные акты, определяющие требования к управлению ИТ и ИБ в банках и иных финансовых организациях.
Осуществляя платежи и переводы денежных средств, банки должны выполнять требования положений ЦБ РФ и национального стандарта для систем переводов денежных средств ГОСТ Р 57580.1-2017 «Безопасность финансовых (банковских) операций…».
При обработке данных платежных карт, выпущенных иностранными платежными компаниями (Visa, MasterCard, American Express, Discover Card, JCB), банк обязан выполнять требования стандарта безопасности платежных карт PCI DSS.
Как субъекты КИИ, банки подпадают под требования 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» и указа президента РФ №250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации».
В связи с обработкой персональных данных (в том числе данных работников, клиентов и контрагентов) банки должны выполнять требования Федерального закона от 27.07.2006 № ФЗ-152 «О персональных данных».
Согласно требованиям указа президента РФ №250, банки должны до января 2025 года прекратить использование средств защиты информации и сервисов по обеспечению ИБ, предоставляемых компаниями из «недружественных» стран.
Дополнительные требования к ИБ возникают при подключении определённых сервисов, например, интеграции с Единой биометрической системой (ЕБС) для идентификации и аутентификации граждан по лицу, голосу.
Для выполнения всех этих требований по ИБ в банках нужно реализовать комплексную систему защиты информации. Ключевые особенности ее построения:
Для учета всех требований ИБ до проектирования и внедрения системы защиты информации банку нужно определить необходимый уровень защиты, включая определение уровня защищенности персональных данных при их обработке в ИСПДн (информационных системах персональных данных), уровень защищенности в соответствии с требованиями ЦБ РФ, наличие и уровень важности значимых объектов КИИ.
При проектировании и внедрении системы защиты информации должны учитываться актуальные угрозы ИБ, определенные по требованиям законодательства.
Законодательство РФ в области ИБ, в особенности ГОСТ Р 57580.1, предъявляет повышенные требования к используемым в банках техническим средствам защиты. Так, помимо традиционных средств антивирусной защиты и межсетевого экранирования банковские организации должны использовать и решения класса SIEM и WAF.
При проектировании системы защиты банки должны учитывать наличие и форму прохождения оценки соответствия решений по защите информации, особенно — при использовании сертифицированных решений. Например, криптографические средства шифрования персональных данных, передаваемых по открытым каналам, должны иметь сертификат ФСБ России.
Внутренняя ИТ-инфраструктура банка должна быть сегментирована. В отдельный сегмент выносятся сервера, используемые для платёжных транзакций. Необходимо выделить в отдельный сегмент ресурсы, которым нужен доступ в интернет (выделение DMZ).
Помимо технических средств, в банке нужно внедрить организационные меры защиты информации. В структуре банка также выделяется подразделение, ответственное за управление ИБ и находящееся в подчинении заместителя руководителя организации (в соответствии с требованиями указа президента № 250).
Если банк самостоятельно разрабатывает ПО, обязательно внедрение SDLC, DevSecOps-практики.
При возникновении инцидентов служба информационной безопасности (ИБ) банка должна корректно и своевременно информировать о них всех заинтересованных регуляторов, в том числе НКЦКИ ФСБ России, ФинЦЕРТ ЦБ РФ и РКН (при возникновении инцидентов, связанных с утечками персональных данных).
Законодательство обязывает банк поддерживать эффективность системы защиты и проведение периодических аудитов ИБ по соответствию требованиям ЦБ РФ и законодательства о ПДн. Отчет о соответствии требованиями ГОСТ Р 57580.1 банк должен своевременно направлять регулятору в установленной ГОСТ Р 57580.2 форме.
Для реализации всего этого используются и технические средства защиты, и механизмы на уровне прикладного ПО: идентификация, аутентификация, авторизация, логирование, контроль целостности, шифрование на прикладном уровне и так далее.
Наличие функций, связанных с ИБ, у того же Active Directory (например, групповые политики) делает его средством защиты информации.
Кроме обязательных требований банк может добровольно принять решение о соответствии дополнительным требованиям в области ИБ. Например, внедрить режим коммерческой тайны по требованиям Федерального закона № 98-ФЗ или обеспечить соответствие системы управления ИБ требованиям СТО БР ИББС (Стандарт Банка России по обеспечению информационной безопасности организаций банковской системы), или стандарта ISO 27001:2022. Тогда при проектировании системы защиты рассматривают и требования этих документов.
Внутренние требования банков к ИТ-системам
«Самоограничения» банков в использовании тех или иных решений строже, чем требования регулятора. Например, банкам не запрещено использовать облака для определённых задач, выносить туда маскированные, анонимизированные данные. Но по факту банки аккумулируют и инсталляцию прикладных сервисов, и данные, и инфраструктуру разработки в собственном контуре.
При выработке внутренних ограничений банк исходит не только из регуляции, но и из оценок последствий утечек: штрафы, финансовые и репутационные потери. А лица, принимающие решение о внедрении чего-то небезопасного, рискуют ещё и своей карьерой. Поэтому банки поднимают максимум сервисов во внутреннем контуре. Разумеется, это затрудняет выделение ресурсов on-demand по сравнению с публичными облаками. И когда мы приходим делать пилотный проект, ждать по несколько месяцев ресурсы, которые клиент нам выделит в своей частной инфраструктуре, — это является нормой.
В итоге банки с точки зрения ИБ — эдакие бастионы. Возрастает фокус ИБ на защите от внутреннего фрода. А недавно наши клиенты в банках стали запрашивать дистрибутивы внедряемых решений для исследований. Чтобы что-то развернуть, нам нужно физически приходить в контур с сервером, ставить его, там же настраивать, развертывать. И забирать оттуда только логи.
Ещё одна особенность банков, впрочем, как и того же ретейла, в котором минутный даунтайм стоит миллионы, — высокие требования к аптайму и скорости прикладных сервисов. Транзакции должны выполняться, ВКС не должна сбоить и так далее. При сбоях летят головы.
Какие решения сложнее всего импортозаместить
Некоторые решения достаточно распространены, но проекты по их замещению долгие и дорогие. Например, большие тяжеловесные корпоративные хранилища данных на Oracle и системы типа Siebel, используемые в роли BPM (business process management). Проекты по переходу с таких систем на отечественные решения займут от 1 года и более и оттянут на себя значительные ресурсы. Также для прогнозирования стабильности дорожной карты развития продукта важно, на каком стеке базируются отечественные аналоги: собственная разработка или разработка на базе open-source решений. Осложняет переход и мизерная линейка отечественных аналогов NGFW, хотя с этим мы уже неплохо справляемся.
Поэтому замену всех этих систем потенциальные заказчики откладывают до последнего.
Риски внедрения ИИ в банках
ЦБ ещё не создал регуляции использования ИИ в банках, но она наверняка скоро появится. ЦБ выпустил отчёт об обсуждении применения ИИ на финансовом рынке. Если в двух словах, внедрение ИИ, по оценкам ЦБ, создаёт риски:
в области оборота данных и ИБ (утечка персональных данных и иной конфиденциальной информации, кибератаки, цифровое мошенничество);
разработки и искажения работы моделей ИИ (галлюцинации, ошибки в тестировании и валидации, отсутствие контроля, неверная интерпретация результатов);
этические риски и риски нарушения прав потребителей;
использование дипфейков и вообще генеративного ИИ в мошенничестве;
зависимость от крупных участников рынка, разрабатывающих инструменты ИИ, макроэкономические риски и риски финансовой нестабильности, необходимость использования иностранных решений.
Пока что, по нашим наблюдениям, ИИ в банках применяется там, где последствия отдельной маленькой ошибки невелики: сегментация базы лидов и пользователей для промоакций, кастомизация user experience, BI, автоматизация поддержки. Если же ИИ получит доступ к персональным данным, реальной информации о продуктах, к принятию управленческих решений, то это уже будет совсем другая история.
Нюансы привлечения подрядчиков к внедрению и эксплуатации ИТ-систем
Формально, если работы подрядчика хоть как-то касаются ИБ, то ему требуется лицензия ФСТЭК на деятельность по технической защите конфиденциальной информации (ТЗКИ). А организации, внедряющей средства криптографической защиты (СКЗИ), нужны специальные лицензии ФСБ России.
Фактически сложно представить себе развертывание какой-либо инфраструктуры без развертывания средств защиты. Так что внедрение любых инфраструктурных решений требует от подрядчика наличия как минимум лицензии ФСТЭК.
Внутренние ИТ-службы банков уже давно имеют топовую экспертизу и решают огромное число задач своими силами. Когда они всё же привлекают интеграторов, из них получаются отличные клиенты: они хорошо понимают, чего хотят, и говорят с интеграторами на одном языке.
Как требования к ИТ в банках влияют на реализацию простых проектов: кейс внедрения ВКС
Приведу пример того, как достаточно простой проект становится гораздо сложнее из-за регуляции. Один из топовых российских банков с десятками представительств и офисов в России обратился к нам для реализации сервиса видеоконференцсвязи (ВКС). ВКС предполагалось использовать в том числе для коммуникаций с корпоративными клиентами, контрагентами, партнёрами.
Проект решал сразу две задачи:
Переход на решение одного вендора. До внедрения каждая команда использовала для коммуникаций что-то своё: Teams, Skype for Business, Cisco, Zoom. Всё это определялось личными предпочтениями и опытом использования. В какой-то момент стало слишком сложно администрировать столько систем, а сотрудники постоянно путались, куда идти на встречу.
Импортозамещение. Тут всё стандартно: лишившись поддержки, банк хочет снять риски схлопывания коммуникационных решений, что может произойти в любой момент.
Мы предложили внедрить решение ВКС от IVA — зрелого вендора с более чем 10-летней историей на рынке, опытной командой, адекватными инженерами и техподдержкой. Мы доверяем их решениям и они всегда в нашем шортлисте на клиентских внедрениях.
Элементы решения. Главный элемент инфраструктуры ВКС IVA — сервер, к которому подключаются клиенты для участия в видеозвонке. Клиенты бывают софтовые, веб- и видеофоны.
Веб-клиент позволяет подключаться к конференции без скачивания клиента, по ссылке. Это принципиально для работы с партнёрами, контрагентами и крупными клиентами.
Если клиенты подключены к разным серверам ВКС, они не находятся в одной конференции. Но их всё же можно объединить, для этого выполняется соединение самих серверов — транк (каскадное соединение). Этот момент станет ключевым в решении этого кейса.
Выбор архитектуры решения. Хотя задача внедрения ВКС — довольно тривиальная, ползунок УДОБНО ←→ БЕЗОПАСНО в банках однозначно выкручен на безопасность до максимума. Так что в данном проекте нужно было придумать, как соединять звонящих из внутренней сети и интернета, которые друг от друга изолированы.
Когда мы думали, как реализовать ВКС на уровне архитектуры, у нас было несколько вариантов:
Размещение сервера ВКС | Детали | плюсы | минусы |
Открытие портов | |||
В DMZ | Для подключения к серверу ВКС из внутренней сети и из интернета открываются порты на границе DMZ с внутренней сетью и интернетом. | Просто настроить. | Категорически не устраивает ИБ из-за открытия портов. |
WAF | |||
Во внутренней сети | В DMZ размещается WAF для фильтрации трафика, Nginx/TURN-серверы для проксирования аудио и видео. Пользователи внутренней сети имеют прямой доступ к серверу ВКС, пользователи в интернете подключаются через WAF, Nginx/TURN. | Эту схему рекомендует вендор. | Требуется открыть слишком много портов, проверять совместимость ВКС с конкретным WAF. |
VPN | |||
Во внутренней сети. | Пользователи внутренней сети имеют прямой доступ к серверу ВКС. Внешние пользователи подключаются через VPN, установленный на доверенных устройствах. | Схема устраивает ИБ, понятный пользователю процесс эксплуатации. | Нельзя подключить сторонних пользователей, у которых нет корпоративного VPN. |
Два сервера ВКС | |||
Устанавливается два сервера ВКС: в DMZ и во внутренней сети. | Внутренние пользователи подключаются на внутренний сервер, внешние — на сервер в DMZ. Между двумя серверами создаётся каскад (транк). | Схема устраивает ИБ. | Нужен дополнительный сервер ВКС, на него нужна отдельная лицензия. Для создания каскада требуются ручные операции сотрудника, организующего конференцию. |
Сейчас, в 2024 году, оптимальным было бы решение с пограничным контроллером сессий. Но в 2023 году, когда мы делали этот проект, у IVA его ещё не было. Теперь он есть, в их линейке он называется IVA SBC. SBC позволяет безопасно устанавливать соединения абонентов ВКС во внутренней сети и интернете. Решение с пограничным контроллером сессий с точки зрения сетевой топологии аналогично решению с WAF. Только вместо сервера WAF в DMZ размещается SВC, который может дополнительно фильтровать протоколы видеосвязи и не требует прямого открытия множества портов из интернета, которое стало причиной отказа службы безопасности от этой схемы. IVA SBC мы уже успешно внедрили в нескольких проектах. Так что сегодня это решение было бы самым простым. |
Первоначально департамент ИБ заказчика согласовал первый вариант, с открытием большого числа портов. Во время реализации они поняли, что не готовы дать доступ из интернета во внутреннюю сеть банка. Службы ИБ — они такие, внезапные, но неумолимые, переубедить их нереально. Так что мы пошли дальше по вариантам.
Вариант с WAF службу ИБ тоже не устроил. Вариант с VPN фатально усложнял использование сервера для не-сотрудников банка.
В итоге мы делали вариант с DMZ. Он самый стабильный и безопасный, хоть и не самый удобный:
пользователи из интернета могут инициировать соединение только с сервером в DMZ, но не с внутренним;
каскад инициируется со стороны сервера ВКС во внутренней сети, который подключается к серверу в DMZ.
Реализация и планы развития ВКС. Мы приступили к реализации проекта в начале 2023 года. Общая длительность проекта внедрения, включая документирование, составила 4 месяца. Можно выделить следующие этапы реализации:
Этап пилотирования занял 30% времени проекта и позволил проверить интеграцию с системами банка: телефонами и терминалами Cisco, Active Directory. Кроме того, мы реализовали доступ к ВКС из всей инфраструктуры заказчика: ЦОДов, подсетей, локальных площадок. Это прям отдельный этап, потому что в банках согласования доступа в сети происходят долго и муторно.
На пилотировании мы столкнулись с ещё одной стандартной особенностью банков — они много что делают сами, потому что не могут нас пустить к себе. Мы развернули у заказчика пилотную зону с решениями IVA, но сами решения в период пилотирования тестировали только технические специалисты заказчика.
Во время пилотирования сервер ВКС поднялся в виде ВМ с тестированием возможности 20-30 подключений.
Этап масштабирования решения, реализованного при пилотировании. В дополнение к основному серверу, управляющему конференцией, поднимается специализированный сервер видеообработки, который увеличивает пропускную способность видеосвязи до сотен участников. Кроме того, все серверы ВКС реализуются в виде отказоустойчивого кластера.
Реализация сервера ВКС в DMZ. Сервер поднимается в виде ВМ, сопрягается с сервером ВКС во внутренней сети и с интернетом.
Дальнейшие возможности развития системы. ВКС развернута в ЦОДе в Москве. Региональные подразделения заказчика, общаясь по ВКС через защищенные магистральные каналы, таким образом гоняют трафик через московский ЦОД со всей страны. Если понадобится масштабировать систему, можно инсталлировать выносные серверы ВКС в региональных офисах.
Итоги
С точки зрения ИТ банки одновременно зарегулированы и технологически продвинуты. Требования к ИТ-инфраструктуре в банках во многом определяются требованиями регулирующих документов к ИБ. Они определяют и особенности конкретных внедряемых решений, и организацию их обслуживания.
При этом банки сами по себе вырабатывают жёсткие внутренние требования. Даже то, что не запрещено регулятором, банки себе не позволяют из-за штрафов, репутационных рисков, убытков. Например, банки очень осторожно пользуются облаками, даже ФЗ-152-compliant, и предпочитают создавать всё инхаус.
Реализация даже не самых сложных проектов, таких как ВКС, приводит к усложнению архитектуры, удорожанию и усложнению бизнес-процесса, который включает ручные операции. Но это осознанный выбор банков.
