Безпека банківських даних: чому офлайн-перший підхід — єдина чесна відповідь

Більшість додатків для особистих фінансів, що пропонують синхронізацію з банком, покладаються на агрегатор фінансових даних. Агрегатор знаходиться між вами та вашим банком, збирає ваші облікові дані або OAuth-токени та передає транзакційні дані назад до додатку. Цей шаблон настільки поширений, що багато користувачів вважають його єдиним способом роботи автоматичної синхронізації з банком.

Це не так. І шаблон агрегатора несе ризики, які рідко чітко розкриваються користувачам. У цій статті пояснюється, що роблять агрегатори, чому масова агрегація створює цінну ціль для злому та як офлайн-перша архітектура забезпечує структурно безпечнішу альтернативу.

Шаблон агрегатора: що робить Plaid і що він бачить

Plaid — це агрегатор фінансових даних, що виступає посередником між споживчими фінансовими додатками та банками. Коли ви підключаєте банківський рахунок через додаток, що використовує Plaid, ось що відбувається на рівні даних:

• Збір облікових даних — Для банків без прямої підтримки OAuth Plaid раніше використовував скрейпінг екрану, що вимагав справжнього логіна та пароля. Багато інтеграцій перейшли на OAuth-токени, але обробка облікових даних все одно проходить через інфраструктуру Plaid.
• Дублювання транзакцій — Plaid забирає ваш потік транзакцій з банку та зберігає його. Агрегатор зберігає копію вашої фінансової історії на своїх серверах, окремо від додатку, який ви фактично використовуєте.
• Передача даних — Дані Plaid можуть передаватися іншим додаткам, підключеним до Plaid, яким ви раніше надали дозвіл, кредиторам, кредитним бюро та партнерам на умовах, які користувачі рідко читають повністю.
• Збереження — Транзакційні дані зберігаються після закінчення активного терміну будь-якого окремого підключення до додатку. Видалення додатку не видаляє автоматично дані з агрегатора.

Це означає, що коли ви використовуєте будь-який бюджетний додаток, підтримуваний великим агрегатором, ваші банківські дані існують щонайменше в трьох місцях: у вашому банку, у додатку та в агрегаторі. Кожне з них є незалежною поверхнею для злому.

Чому масова агрегація є цінною ціллю для злому

Агрегатор фінансових даних, що обслуговує мільйони користувачів, зберігає облікові дані або токени доступу для мільйонів банківських рахунків в одній системі. З точки зору зловмисника, це набагато привабливіша ціль, ніж будь-який окремий банк, тому що:

• Єдина точка входу — Компрометація однієї системи дає доступ до облікових даних сотень різних банків і фінансових установ. Зловмисникам не потрібно атакувати кожен банк окремо.
• Концентрована історія транзакцій — Агрегатори зберігають не лише облікові дані, але й роки нормалізованої історії транзакцій. Ці дані цінні для крадіжки особистих даних, захоплення облікових записів і атак соціальної інженерії.
• Безпека третіх сторін — Рівень безпеки великого агрегатора визначається цією компанією, а не вашим банком. Ваш банк може мати чудові практики безпеки, але ваша схильність до ризику залежить від третьої сторони, яку ви явно не вибирали.

Цей ризик не є теоретичним. Великі агрегатори фінансових даних та фінтех-посередники пережили значні інциденти безпеки протягом років, розкриваючи банківські облікові дані споживачів, номери рахунків та історію транзакцій. Кожен інцидент торкнувся користувачів кількох додатків одночасно, оскільки злом відбувся на рівні агрегатора, а не будь-якого окремого додатку.

Офлайн-перший підхід як архітектурна відповідь

Архітектура з офлайн-першим підходом усуває ризик агрегаторів на структурному рівні, а не через обіцянки в політиках. Коли ваші фінансові дані зберігаються на вашому пристрої, а банківська синхронізація відбувається безпосередньо — без посередника — поверхня атаки агрегатора не існує.

Що змінюється архітектурно

• Жодного депонування облікових даних — Ваші банківські облікові дані або OAuth-токени зберігаються лише на вашому пристрої у зашифрованому вигляді. Жоден сторонній сервер не зберігає копію.
• Пряма комунікація з банком — При синхронізації ваш пристрій безпосередньо спілкується з API вашого банку. Транзакційні дані надходять від банку до пристрою без проходження через проміжний сервер.
• Жодної копії вашої історії в агрегатора — Оскільки синхронізація є прямою, жодна друга копія вашого потоку транзакцій не зберігається на сервері агрегатора. Єдині копії — у вашому банку та на вашому пристрої.
• Ізольований вплив витоку — Якщо ваш пристрій скомпрометований, ризик обмежується вашими рахунками. Витік в агрегатора може одразу торкнутися всіх користувачів.

Прямі API-токени проти агрегаторного OAuth

Багато банків тепер пропонують офіційні API-програми з обмеженими OAuth-токенами. Ці токени надають доступ лише на читання до історії транзакцій без розкриття даних для входу. При використанні в офлайн-першому додатку це найбезпечніша доступна форма автоматизованої синхронізації з банком:

• Обмежені дозволи — Токен надає доступ лише до транзакційних даних. Він не може ініціювати перекази, змінювати деталі рахунку або отримувати доступ до інших банківських сервісів.
• Відкликається — Ви можете відкликати токен через портал банку в будь-який момент, негайно припиняючи доступ без зміни пароля.
• Жодного розкриття облікових даних — Токен генерується вашим банком, а не виводиться з вашого пароля. Навіть якщо токен буде перехоплений, ваші дані для входу залишаються в безпеці.
• Зберігається локально — У додатку з офлайн-першим підходом токен зберігається на вашому пристрої, а не на сервері агрегатора. Відкликання його через банк також усуває єдиний залишковий шлях доступу.

Агрегаторний OAuth, навпаки, маршрутизує вашу банківську авторизацію через платформу агрегатора. Отриманий токен зберігається агрегатором, а не додатком або вашим пристроєм. Ви довіряєте агрегатору використовувати його відповідально та надійно захищати.

Імпорт PDF, Excel та CSV як універсальний резервний варіант

Не кожен банк пропонує API-програму, і не кожен банк підтримується певною інтеграцією прямої синхронізації. Для таких випадків ручний імпорт виписок є резервним варіантом, що зберігає конфіденційність — і він є більш практичним, ніж більшість людей очікують.

Чому ручний імпорт недооцінений

• Універсальна сумісність — Кожен банк, що існував будь-коли, може видати виписку. Експорт CSV та PDF працює з кожною фінансовою установою у світі без потреби в API-доступі.
• Жодного постійного розкриття облікових даних — Ви завантажуєте виписку з сайту банку за допомогою звичайного логіна, потім імпортуєте файл. Жодних токенів, жодних збережених облікових даних і жодного постійного підключення для управління.
• Передбачувана частота — Більшість користувачів звіряють рахунки щотижня або щомісяця. Ручний імпорт виписок природно вписується в цей ритм без потреби у постійному підключенні до мережі.
• Контроль журналу аудиту — Ви самі вирішуєте, які часові проміжки імпортувати. Жодної фонової синхронізації, що завантажує дані без вашої явної дії.

Як Budgie реалізує це від початку до кінця

Budgie підтримує як пряму синхронізацію з банком, так і ручний імпорт, з незмінною відданістю зберіганню ваших даних на пристрої на кожному етапі.

Пряма синхронізація

Для підтримуваних банків Budgie підключається безпосередньо з вашого пристрою до банківського API за допомогою OAuth-токенів, збережених у зашифрованій локальній базі даних. Синхронізація виконується на вашому пристрої; сервери Budgie не беруть участі в потоці даних. Транзакційні дані записуються безпосередньо до локальної бази SQLite.

Імпорт CSV та PDF

Імпорт CSV та PDF у Budgie обробляє файли виписок на вашому пристрої. Жодний вміст файлу не завантажується на жодний сервер під час імпорту. Парсер працює локально, витягує транзакції та записує їх до локальної бази даних. Дедублікація гарантує, що імпорт перекриваючих діапазонів дат не створює дублікатів.

Зашифроване локальне сховище

Незалежно від того, надходять дані через пряму синхронізацію або ручний імпорт, вони зберігаються в тій самій зашифрованій базі даних SQLite AES-256. База даних захищена PIN пристрою, біометричною аутентифікацією або спеціальним блокуванням додатку. Жодні транзакційні дані не зберігаються на серверах Budgie в жодний момент.

Зашифроване резервне копіювання

Коли ви створюєте резервну копію, зашифрований файл бази даних експортується до вашого вибраного місця призначення — iCloud, Google Drive, локальний мережевий ресурс або пристрій, підключений через USB. Budgie не отримує і не зберігає резервну копію. Відновлення читає файл з того самого місця призначення і розшифровує його локально.

Часті запитання