За предыдущее десятилетие банки стали центром ИТ-инноваций и высочайшей культуры разработки и эксплуатации ИТ-сервисов. Однако из-за жёсткого регулирования внедрение в банках даже простых и привычных сервисов часто требует усложнений.

Я Михаил Никифоров, эксперт К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 — сервер, к которому подключаются клиенты для участия в видеозвонке. Клиенты бывают софтовые, веб- и видеофоны.

Веб-клиент позволяет подключаться к конференции без скачивания клиента, по ссылке. Это принципиально для работы с партнёрами, контрагентами и крупными клиентами.

Если клиенты подключены к разным серверам ВКС, они не находятся в одной конференции. Но их всё же можно объединить, для этого выполняется соединение самих серверов — транк (каскадное соединение). Этот момент станет ключевым в решении этого кейса.

Выбор архитектуры решения. Хотя задача внедрения ВКС — довольно тривиальная, ползунок УДОБНО ←→ БЕЗОПАСНО в банках однозначно выкручен на безопасность до максимума. Так что в данном проекте нужно было придумать, как соединять звонящих из внутренней сети и интернета, которые друг от друга изолированы.

Когда мы думали, как реализовать ВКС на уровне архитектуры, у нас было несколько вариантов:

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

Вариант с WAF службу ИБ тоже не устроил. Вариант с VPN фатально усложнял использование сервера для не-сотрудников банка.

В итоге мы делали вариант с DMZ. Он самый стабильный и безопасный, хоть и не самый удобный: 

• пользователи из интернета могут инициировать соединение только с сервером в DMZ, но не с внутренним;

• каскад инициируется со стороны сервера ВКС во внутренней сети, который подключается к серверу в DMZ.

Реализация и планы развития ВКС. Мы приступили к реализации проекта в начале 2023 года. Общая длительность проекта внедрения, включая документирование, составила 4 месяца. Можно выделить следующие этапы реализации:

1. Этап пилотирования занял 30% времени проекта и позволил проверить интеграцию с системами банка: телефонами и терминалами Cisco, Active Directory. Кроме того, мы реализовали доступ к ВКС из всей инфраструктуры заказчика: ЦОДов, подсетей, локальных площадок. Это прям отдельный этап, потому что в банках согласования доступа в сети происходят долго и муторно.

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

Во время пилотирования сервер ВКС поднялся в виде ВМ с тестированием возможности 20-30 подключений.

2. Этап масштабирования решения, реализованного при пилотировании. В дополнение к основному серверу, управляющему конференцией, поднимается специализированный сервер видеообработки, который увеличивает пропускную способность видеосвязи до сотен участников. Кроме того, все серверы ВКС реализуются в виде отказоустойчивого кластера.

3. Реализация сервера ВКС в DMZ. Сервер поднимается в виде ВМ, сопрягается с сервером ВКС во внутренней сети и с интернетом.

Дальнейшие возможности развития системы. ВКС развернута в ЦОДе в Москве. Региональные подразделения заказчика, общаясь по ВКС через защищенные магистральные каналы, таким образом, гоняют трафик через московский ЦОД со всей страны. Если понадобится масштабировать систему, можно инсталлировать выносные серверы ВКС в региональных офисах.

Итоги

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

При этом банки сами по себе вырабатывают жёсткие внутренние требования. Даже то, что не запрещено регулятором, банки себе не позволяют из-за штрафов, репутационных рисков, убытков. Например, банки очень осторожно пользуются облаками, даже ФЗ-152-compliant, и предпочитают создавать всё инхаус.

Реализация даже не самых сложных проектов, таких как ВКС, приводит к усложнению архитектуры, удорожанию и усложнению бизнес-процесса, который включает ручные операции. Но это осознанный выбор банков.