Для взлома банка не понадобилось ядро
Банк может сохранить core ledger в неприкосновенности и всё равно потерять чувствительные данные клиентов.
Именно такой неприятный вывод следует из серии инцидентов, о которых сообщили корейские финансовые организации. Атакованы были не основные системы интернет- и мобильного банкинга. В список вошли сервис для кредитных агентов, мобильная система для сотрудников, приложение поддержки продаж и доступ, связанный с outsourced workers.
По данным The Korea Times, Shinhan Bank сообщил об утечке данных примерно 25 000 клиентов после обхода authentication в сервисе для кредитных агентов. KB Kookmin Bank подтвердил 119 пострадавших клиентов после аномального доступа к мобильной системе сотрудников. Hana Bank сообщил о 89 клиентах после атаки на sales-support system. BNK Financial Group сообщил об утечке данных 11 внешних сотрудников. Woori Bank и NH NongHyup Bank также столкнулись с атаками, но не обнаружили подтверждённой утечки.
В раскрытых данных были сведения об identity, контактах, месте работы, доходах и доступных суммах кредита. Transaction data, возможно, остались внутри ядра, но полученной информации уже достаточно для fraud, impersonation, social engineering и подготовки следующих атак на счета.
Значимой границей оказалось не разделение на core и non-core. Значим каждый путь, по которому можно прочитать клиентские данные.
Связанный периметр — это часть банка
Core banking обычно защищён зрелыми controls: строго управляемыми identities, ограниченными сетями, change governance, reconciliation и подробным monitoring. Системы вокруг ядра часто развиваются в других условиях.
Broker portal должен быть удобен внешним агентам. Sales tool должен поддерживать быстрый клиентский процесс. Employee mobile application должна работать за пределами офисной сети. Внешней операционной команде нужен доступ через границы организаций. Каждое требование обоснованно. Вместе они создают connected perimeter со множеством identities, devices, vendors и authentication flows.
Для атакующего архитектурная классификация не имеет значения. Если периферийное приложение может запрашивать клиентские записи, оно является интерфейсом к клиентским данным. Если оно может инициировать workflow, оно находится рядом с транзакционным контуром. Если оно доверяет повторно используемому паролю или long-lived session, это доверие становится частью security model банка — даже если его нет на архитектурной схеме.
Поэтому фраза «ядро не пострадало» полезна в оперативном отчёте, но стратегически неполна. Она описывает containment после инцидента. Она не доказывает, что банк защитил информацию, защиту которой ожидали клиенты.
Не путать след AI-инструмента с доказанной AI-атакой
В сообщениях об инцидентах была и эффектная деталь: на инфраструктуре, предположительно связанной с атакой на Shinhan, нашли китайское название, которое переводится как «консоль автономного AI penetration testing». Но расследование ещё не установило, что AI стал причиной атак или автономно их выполнил.
Это важное различие.
AI tool рядом с атакой — основание для расследования, а не готовый вывод о причине. Подтверждённая проблема в Shinhan — обход authentication в сервисе кредитных агентов. В других случаях сообщалось об аномальном внешнем доступе к системам сотрудников и поддержки продаж. Если слишком рано назвать всё это «AI-атакой», конкретные отказы controls растворятся в новой размытой категории угроз.
AI может снизить стоимость reconnaissance, проверки credentials, адаптации и параллельного выполнения действий. Он способен ускорить эксплуатацию существующей слабости и увеличить масштаб. Но защитный ответ остаётся конкретным: strong identity, scoped authorization, rate limits, segmentation, telemetry и быстрое revocation.
Главный вопрос не в том, использовал ли атакующий агента. Главный вопрос — почему любой автоматизированный клиент смог пересечь границу. Если агент участвовал, полезна не сама находка AI-инструмента, а запись о том, кто дал право на каждое действие и какой механизм контроля его разрешил.
Четыре controls для non-core attack surface
1. Инвентаризировать пути к данным, а не только приложения
Application inventory показывает, какое программное обеспечение существует. Data-path inventory показывает, кто может получить какие клиентские поля, через какой API или интерфейс, под какой identity, с какого device и network и для какой бизнес-цели.
В такой инвентарь должны входить broker portals, employee tools, CRM extensions, document platforms, contact-centre consoles, batch exports, vendor integrations, аналитические копии и emergency support access. Система, раскрывающая только имя, доход или лимит кредита, не становится low risk лишь потому, что не может создать проводку.
Полезная единица учёта — queryable capability, например customer.credit.read, а не имя сервера.
2. Связывать доступ с principal и device
Shared accounts и повторно используемые пароли уничтожают attribution и делают credential stuffing экономически выгодным. Доступ к чувствительным клиентским данным должен требовать именованного workforce, partner или service principal, phishing-resistant authentication, проверки состояния device и short-lived sessions.
Внешние кредитные агенты и outsourced workers не должны получать более слабые identity controls только потому, что находятся вне корпоративного каталога. Их доступ рискованнее именно потому, что lifecycle, владение устройством, контроль и revocation проходят через границы организаций.
3. Изолировать каналы и сокращать доступные данные
Sales-support application не нужен тот же набор данных, что и credit decision service. Агенту, проверяющему статус заявки, не нужен общий endpoint поиска клиентов. Employee mobile client не должен незаметно получать права desktop operations console.
Least privilege нужно обеспечивать на уровне данных и операций. Каналы партнёров, сотрудников, клиентов и vendors следует разделять. Им нужны разные credentials и policy boundaries. Массовые запросы и enumeration должны быть ограничены. Revocation следует спроектировать так, чтобы один скомпрометированный канал можно было отключить, не останавливая весь банк.
Segmentation — это не только network control. Это также разделение identity domains, API scopes, data fields, rate budgets и administrative authority.
4. Коррелировать telemetry между каналами
Credential-stuffing campaign может выглядеть безобидно внутри отдельного приложения: повторные logins, распределённые адреса, корректные credentials и обычные read requests. Паттерн становится виден, только когда можно связать события identity, device, API, data access и threat intelligence.
Monitoring model должна отвечать на вопросы:
- Не появляется ли одна identity одновременно с нескольких devices или из разных регионов?
- Не перебирает ли одно device множество клиентских или employee identities?
- Не запрашивает ли partner account записи вне своего обычного портфеля?
- Не изменились ли внезапно rate, search pattern или набор читаемых полей у сессии?
- Может ли security немедленно отозвать identity, token, device или весь channel?
Одного архива logs недостаточно. Для detection нужна общая межканальная модель нормальных полномочий и нормального использования.
Architecture review нужен другой вопрос
Обычный вопрос на architecture review звучит так: «Может ли эта система перемещать деньги?»
Для connected perimeter нужен ещё один: «Что эта система может раскрыть и как эта информация поможет провести следующую атаку?»
Non-transactional application может отдать всё необходимое для impersonation клиента, целевой атаки на сотрудника, ответа на recovery questions или подготовки более дорогого fraud. Поэтому blast radius следует измерять не только прямыми финансовыми проводками, но и количеством identities и data relationships.
Ядро остаётся критически важным. Но security современного банка не работает, если core считается единственной системой, достойной серьёзной защиты. Каждый workflow брокера, сотрудника, поддержки, vendor или outsourced team, способный получить клиентские данные, уже входит в фактический security perimeter банка. В масштабе всей отрасли те же общие поставщики и подрядчики превращают один сбой в системный сценарий.
Архитектура должна признать это раньше, чем следующий инцидент сделает это за неё.