Просто группировка. В статье отдельно подсветил, что внутри слоя безопасности две подгруппы: активные системы безопасности и системы, близкие к бизнес-процессам.
Группировка на слои не означает, что все интеграции и запросы идут сверху вниз. Условная АБС может быть интегрирована с системами безопасности, например с фрод-мониторингом, и запрашивать оттуда данные (через системы интеграционного слоя).
Второй вариант с предложенным вами доверенным УЦ мне тоже нравится, но, к сожалению, хранение и обработка даже зашифрованных стойким алгоритмом SAD - это нарушение стандарта, а значит сразу подведёт RBS под CDE-адит.
Действительно, RBS всё равно может реализовать MITM-атаку, но её риск не так велик (в сравнении с вариантом 1 и 2), так как любая подобная активность тут же отразится в системе мониторинга и в виде массовых жалоб пользователей из-за использования одноразовых ссылок. Но это, конечно, лишь пассивная контрмера.
Для исправления этого сценария у меня есть идея реализовать защищённый канал связи между клиентом и SRS как раз через доверенный УЦ и асимметричное шифрование — и по нему передавать JWT-токен для получения iframe.
Возможно, у вас есть идеи, как реализовать это более элегантно? Был бы рад обсудить тут либо в личке.
К сожалению тут не смогу помочь, мы отвечаем за обработку запросов юрлиц, а для физических лиц есть чат в интернет банке, попробуйте обратиться с деталями проблемы туда.
Вы говорите про frame-ancestors? Шифрование канала, журналирование, аудит, это, конечно, неотъемлемые части, в статье я сделал акцент на архитектурном решении и подумал что детали реализации могут еще больше усложнить и без того сложный материал.
Мой путь был долгим - это информационная безопасность->DevOps->разработчик->тим лид (примерно 5 лет)->архитектор
все верно, 99.99% всех проводок закрываются в срок до месяца, тут мы говорим о технических артефактах, которые операционист случайно обнаружил и решил привести в порядок. Фактически там в событиях летели нули, но их было безумно много.
Вы правы, паттерн outbox - это один из ключевых механизмов обеспечения надежной доставки событий. Насколько мне известно он используется на стороне АБС-адаптера.
Однако, как вы верно заметили, даже эта практика не устраняет проблема на 100%. В реальной системе всегда остаются «серые операции» в обход стандартных интерфейсов взаимодействия с АБС, человеческий фактор, сбои на стороне потребителя или интеграции.
Наше решение не идеально и мы работаем над более элегантными методами. Если у вас есть опыт реализации подобных интеграций - буду раз услышать ваши идеи и предложения.
Спасибо за комментарий! Я не осветил этот момент подробно, а он действительно важен.
В проработке вопросов UX на первое место выходит работа продукт-овнера - это ключевое звено между разработкой и клиентом. Именно наши крутые продукт-овнеры опираясь на анализ бизнес метрик, А/В тесты, анализ рынка, общение с клиентом и что главное - на технические ограничения архитектуры принимают взвешенное решение что хуже для клиента - получить устаревшие данные и уведомляющий баннер или бесконечный спиннер и окно «сервис недоступен, попробуйте позже»
Более того, некоторые требования исходят от регуляторов. В частности важное Положение ЦБ от 13 января 2025 г. N 850-П определяет какие системы с какой надежностью должны работать.
Спасибо, отличное замечание. В статье дал ответ косвенно, раскрою подробнее:
был ли прав подрядчик? да, но лишь в идеальном мире, где АБС выдерживает любую нагрузку и ее можно масштабировать и горизонтально и вертикально, в нашем случае мы сразу понимали, что при полной миграции клиентов, даже с учетом использования КЭШ при синхронных запросов мы вызовем DoS на АБС, тем самым вызвав практически полный отказ банка. Собеседование подрядчика было призвано так же проверить реальный, не теоретический опыт разработки ДБО у организации.
что, если «легло» само ДБО Вы абсолютно правы и это ключевой вопрос статьи. Вся наша архитектура была построена как раз для того, что бы не допустить этого. Мы осознанно выбрали статус «АР» системы в терминах САР теоремы и это значит что данные будут eventually consistent, но пользователь с высокой доступностью (99.99) сможет зайти, посмотреть кэшированные данные, отправить платеж и полноценно воспользоваться функционалом. Посмотрите предыдущую статью (ссылка в начале) где я описал некоторые из инструментов отказоустойчивости ДБО.
Основная проблема, которую мы решали с помощью kafka - это высокая нагрузка операций чтения на АБС. Вы правы, это усложнило архитектуру, но альтернатива - это рискнуть работоспособностью всего банка и для нас этот риск был абсолютно неприемлем.
Kafka в этой истории выступила не просто переносчиком проблем, а наименьшим из всех зол и инструментом, который позволил перенести нагрузку с монолитной АБС на мастабируемую и отказоустойчивую интеграционную систему. Показать на нашем опыте проблемы консистетности и сложности применения событийной архитектуры в финтех - это и есть основная цель данной статьи.
Благодарю за комментарий. Технологическая поправка, где вы указываете, что REST - это архитектурный стиль, абсолютно корректна. В статье мы сознательно использовали упрощение для лучшей читаемости, чтобы не перегружать и без того сложный материал формулировками вроде «синхронное взаимодействие, реализованное через REST API».
Вы затронули важный вопрос о методологии. В идеальном мире мы бы, конечно, начали с глубокого анализа и безупречного проектирования. Но банковская среда - это мир жёстких ограничений: legacy-системы, требования регуляторов, информационная безопасность, ограниченные сроки и бюджеты. В нашем случае идеальное решение было недостижимо. Посмотрите предыдущую статью, ссылка в начале.
Мы действовали итеративно в рамках Agile: начали с того, что было уже в банке, собрали на синхронных интеграциях MVP решение, а уже дальше, постепенно с миграцией клиентов эволюционировали к событийной архитектуре.
Прочитав ваш комментарий вспомнилась история о двух инженерах (из книги «Мифический Человеко-месяц», если не ошибаюсь) - идеалисте и прагматике. Идеалист 2 года пишет идеальное ядро, а прагматик выливает «полурабочее» решение на рынок, быстро набирает клиентов и в итоге нанимает идеалиста к себе на зарплату. Идеалистом быть в нашем неидеальном мире очень тяжело)
Просто группировка. В статье отдельно подсветил, что внутри слоя безопасности две подгруппы: активные системы безопасности и системы, близкие к бизнес-процессам.
Группировка на слои не означает, что все интеграции и запросы идут сверху вниз. Условная АБС может быть интегрирована с системами безопасности, например с фрод-мониторингом, и запрашивать оттуда данные (через системы интеграционного слоя).
Спасибо за комментарий!
Второй вариант с предложенным вами доверенным УЦ мне тоже нравится, но, к сожалению, хранение и обработка даже зашифрованных стойким алгоритмом SAD - это нарушение стандарта, а значит сразу подведёт RBS под CDE-адит.
Действительно, RBS всё равно может реализовать MITM-атаку, но её риск не так велик (в сравнении с вариантом 1 и 2), так как любая подобная активность тут же отразится в системе мониторинга и в виде массовых жалоб пользователей из-за использования одноразовых ссылок. Но это, конечно, лишь пассивная контрмера.
Для исправления этого сценария у меня есть идея реализовать защищённый канал связи между клиентом и SRS как раз через доверенный УЦ и асимметричное шифрование — и по нему передавать JWT-токен для получения iframe.
Возможно, у вас есть идеи, как реализовать это более элегантно? Был бы рад обсудить тут либо в личке.
К сожалению тут не смогу помочь, мы отвечаем за обработку запросов юрлиц, а для физических лиц есть чат в интернет банке, попробуйте обратиться с деталями проблемы туда.
Вы говорите про frame-ancestors? Шифрование канала, журналирование, аудит, это, конечно, неотъемлемые части, в статье я сделал акцент на архитектурном решении и подумал что детали реализации могут еще больше усложнить и без того сложный материал.
Мой путь был долгим - это информационная безопасность->DevOps->разработчик->тим лид (примерно 5 лет)->архитектор
все верно, 99.99% всех проводок закрываются в срок до месяца, тут мы говорим о технических артефактах, которые операционист случайно обнаружил и решил привести в порядок. Фактически там в событиях летели нули, но их было безумно много.
Вы правы, паттерн outbox - это один из ключевых механизмов обеспечения надежной доставки событий. Насколько мне известно он используется на стороне АБС-адаптера.
Однако, как вы верно заметили, даже эта практика не устраняет проблема на 100%. В реальной системе всегда остаются «серые операции» в обход стандартных интерфейсов взаимодействия с АБС, человеческий фактор, сбои на стороне потребителя или интеграции.
Наше решение не идеально и мы работаем над более элегантными методами. Если у вас есть опыт реализации подобных интеграций - буду раз услышать ваши идеи и предложения.
Спасибо за комментарий! Я не осветил этот момент подробно, а он действительно важен.
В проработке вопросов UX на первое место выходит работа продукт-овнера - это ключевое звено между разработкой и клиентом. Именно наши крутые продукт-овнеры опираясь на анализ бизнес метрик, А/В тесты, анализ рынка, общение с клиентом и что главное - на технические ограничения архитектуры принимают взвешенное решение что хуже для клиента - получить устаревшие данные и уведомляющий баннер или бесконечный спиннер и окно «сервис недоступен, попробуйте позже»
Более того, некоторые требования исходят от регуляторов. В частности важное Положение ЦБ от 13 января 2025 г. N 850-П определяет какие системы с какой надежностью должны работать.
Спасибо, отличное замечание. В статье дал ответ косвенно, раскрою подробнее:
был ли прав подрядчик? да, но лишь в идеальном мире, где АБС выдерживает любую нагрузку и ее можно масштабировать и горизонтально и вертикально, в нашем случае мы сразу понимали, что при полной миграции клиентов, даже с учетом использования КЭШ при синхронных запросов мы вызовем DoS на АБС, тем самым вызвав практически полный отказ банка. Собеседование подрядчика было призвано так же проверить реальный, не теоретический опыт разработки ДБО у организации.
что, если «легло» само ДБО
Вы абсолютно правы и это ключевой вопрос статьи. Вся наша архитектура была построена как раз для того, что бы не допустить этого. Мы осознанно выбрали статус «АР» системы в терминах САР теоремы и это значит что данные будут eventually consistent, но пользователь с высокой доступностью (99.99) сможет зайти, посмотреть кэшированные данные, отправить платеж и полноценно воспользоваться функционалом. Посмотрите предыдущую статью (ссылка в начале) где я описал некоторые из инструментов отказоустойчивости ДБО.
Основная проблема, которую мы решали с помощью kafka - это высокая нагрузка операций чтения на АБС. Вы правы, это усложнило архитектуру, но альтернатива - это рискнуть работоспособностью всего банка и для нас этот риск был абсолютно неприемлем.
Kafka в этой истории выступила не просто переносчиком проблем, а наименьшим из всех зол и инструментом, который позволил перенести нагрузку с монолитной АБС на мастабируемую и отказоустойчивую интеграционную систему.
Показать на нашем опыте проблемы консистетности и сложности применения событийной архитектуры в финтех - это и есть основная цель данной статьи.
Благодарю за комментарий. Технологическая поправка, где вы указываете, что REST - это архитектурный стиль, абсолютно корректна. В статье мы сознательно использовали упрощение для лучшей читаемости, чтобы не перегружать и без того сложный материал формулировками вроде «синхронное взаимодействие, реализованное через REST API».
Вы затронули важный вопрос о методологии. В идеальном мире мы бы, конечно, начали с глубокого анализа и безупречного проектирования. Но банковская среда - это мир жёстких ограничений: legacy-системы, требования регуляторов, информационная безопасность, ограниченные сроки и бюджеты. В нашем случае идеальное решение было недостижимо. Посмотрите предыдущую статью, ссылка в начале.
Мы действовали итеративно в рамках Agile: начали с того, что было уже в банке, собрали на синхронных интеграциях MVP решение, а уже дальше, постепенно с миграцией клиентов эволюционировали к событийной архитектуре.
Прочитав ваш комментарий вспомнилась история о двух инженерах (из книги «Мифический Человеко-месяц», если не ошибаюсь) - идеалисте и прагматике. Идеалист 2 года пишет идеальное ядро, а прагматик выливает «полурабочее» решение на рынок, быстро набирает клиентов и в итоге нанимает идеалиста к себе на зарплату. Идеалистом быть в нашем неидеальном мире очень тяжело)