Карта Data Security: роли, угрозы, данные и quick start в финтехе

Что такое Data Security и кто за что отвечает

В финтехе один и тот же пользовательский перевод может одновременно быть деньгами, юридическим обязательством, набором персональных данных и цепочкой технических событий в десятках систем. Если такой перевод утечёт, исказится или станет недоступен, проблема будет не только в безопасности: пострадают операции, комплаенс, доверие клиентов и иногда сама лицензия бизнеса. Именно поэтому защита данных — не узкая техническая функция, а способ удержать компанию в рабочем и правовом поле.

Когда новички слышат слово security, они часто представляют сеть, уязвимости и злоумышленника снаружи. Но в реальной компании значительная часть риска рождается внутри обычных процессов: аналитик выгрузил лишнее, разработчик включил подробный лог, подрядчик получил доступ шире необходимого, а тестовая база оказалась почти копией боевой. В этих ситуациях данные становятся главным объектом защиты, а не только сервер или приложение.

Что именно означает защита данных

Data Security — это дисциплина, которая обеспечивает, чтобы данные были доступны нужным людям и системам, недоступны посторонним, не менялись незаметно и использовались в допустимых целях. На языке классической безопасности это обычно раскладывают на три свойства:

конфиденциальность — данные не видит тот, кто не должен их видеть;

целостность — данные не искажены и не подменены;

доступность — нужные процессы и люди получают данные вовремя.

В финтехе к этому почти всегда добавляются ещё два практических измерения:

прослеживаемость — можно понять, кто, когда и зачем обращался к данным;

контекст использования — одинаковый набор полей по-разному рискован в разных сценариях.

Например, номер карты в токенизированном виде внутри платёжного сервиса и тот же номер в CSV-файле, отправленном по почте, — это формально “те же данные”, но совершенно разный профиль риска. Поэтому защита данных почти никогда не сводится к одному инструменту вроде шифрования.

> Хорошая защита данных начинается не с покупки продукта, а с ответа на вопрос: какие данные где живут, куда текут и кто может превратить их в ущерб.

Важно ещё одно различие. Data Security защищает сами данные в хранилищах, потоках, логах, резервных копиях, аналитических витринах и моделях. Это шире, чем защита приложения как кода. Приложение может быть написано без критических уязвимостей, но при этом опасно обращаться с данными: писать секреты в логи, отдавать лишние поля в API, копировать PII в BI-систему или хранить production dump в dev-среде.

Почему в финтехе этот домен выделяется особенно сильно

Финансовые сервисы почти всегда работают сразу с несколькими классами чувствительных данных. Это не только PII — персональные данные клиента, но и платёжные реквизиты, транзакционная история, сведения о доходе, скоринговые признаки, документы KYC, события антифрода, данные о бенефициарах, токены доступа и ключи интеграций.

У этих данных есть три неприятных свойства:

Они высоколиквидны для злоумышленника. Карточные данные, учётные записи, документы и платёжные токены можно быстро монетизировать.

Они регуляторно нагружены. Ошибка быстро переходит в тему аудита, штрафов, претензий партнёров и обязательств по уведомлению.

Они сильно размножаются по системам. Один клиентский атрибут попадает в CRM, core banking, антифрод, data warehouse, логи, support tools и ML-пайплайн.

В 2019 году Capital One раскрыла крупный инцидент с утечкой данных, затронувший более 100 миллионов заявителей и клиентов в США и Канаде; среди скомпрометированных данных были имена, адреса, кредитные баллы, части номеров счетов и данные кредитных заявок. Этот кейс часто обсуждают не только как историю про облако и SSRF, но и как пример того, что ценность атакуемого объекта была именно в данных, а не в самой инфраструктуре.

Кто обычно отвечает за защиту данных

В зрелой организации нельзя честно сказать: “за данные отвечает один человек”. Ответственность почти всегда распределённая. Но именно поэтому новичку нужна карта, иначе все будут считать, что отвечает “кто-то другой”.

Ниже — упрощённая модель ролей, характерная для финтех-команд.

| Роль | Главный фокус | Типичные вопросы | |---|---|---| | Data Security Engineer | Защита данных в потоках, хранилищах, доступах и процессах | Где лежат чувствительные данные? Кто к ним имеет доступ? Чем защищены выгрузки, логи, бэкапы, интеграции? | | Application Security Engineer | Безопасность приложений и SDLC | Есть ли уязвимости в коде, API, зависимостях, механизмах auth? | | Privacy Engineer | Реализация требований к персональным данным в системах | Какие данные можно собирать, на каком основании, как ограничить срок хранения и доступ? | | Platform / Cloud Security | Безопасность инфраструктуры и платформы | Как настроены облачные сервисы, сети, IAM, секреты, мониторинг? | | Data Engineer / Platform Engineer | Пайплайны и платформы данных | Как данные перетекают между системами, как устроены ETL/ELT, витрины и каталоги? | | Product / Business Owner | Цель обработки и допустимость использования | Зачем вообще нужны эти данные и можно ли обойтись меньшим набором? | | Compliance / Legal / Risk | Нормативные обязательства и контроль | Какие требования нужно выполнить, как доказать соответствие, где unacceptable risk? |

!Карта ролей и зон ответственности

Самая частая ошибка — думать, что Data Security Engineer “настраивает DLP” и на этом всё. На практике эта роль ближе к системному стыку между инженерией, риском и данными. Такой инженер помогает ответить на вопросы:

какие типы данных наиболее чувствительны;

где они появляются и копируются;

какие доступы избыточны;

какие технические меры реально снижают риск;

как встроить защиту в архитектуру, а не повесить сверху.

Если разработчик пишет сервис выдачи выписок, AppSec больше озаботится безопасностью API, авторизацией и уязвимостями. Data Security посмотрит, не утекают ли лишние поля, как маркируются выгрузки, кто видит PDF, сколько хранится кэш, куда идут события аудита. Privacy Engineering спросит, все ли поля действительно нужны и не нарушается ли срок хранения. Это не конкурирующие области, а разные углы зрения на одну систему.

За что Data Security Engineer отвечает лично, а за что влияет косвенно

В профессии полезно рано разделить прямую ответственность и зону влияния. Иначе возникает ложное ощущение, что инженер по безопасности данных должен “закрыть всю безопасность компании”.

Обычно в прямую ответственность входят:

классификация данных и правила чувствительности;

картирование потоков данных между системами;

политики доступа к данным и принцип наименьших привилегий;

контроли для хранилищ и выгрузок: шифрование, маскирование, токенизация, аудит доступа;

контроль вторичных копий: логи, дампы, резервные копии, тестовые среды;

обнаружение чувствительных данных в неожиданных местах;

подготовка требований к командам платформы, разработки и аналитики.

В зону влияния, но не полного владения, обычно попадают:

архитектура IAM;

безопасность CI/CD;

дизайн бизнес-процессов;

правовые основания обработки данных;

инцидент-менеджмент всей компании.

Хороший ориентир простой: если риск возникает из-за того, как данные хранятся, перемещаются, открываются и копируются, это почти наверняка область Data Security. Если риск возникает из-за уязвимости в коде или компрометации хоста, это может быть соседняя дисциплина — но последствия всё равно часто измеряются через данные.

> Data Security Engineer редко “владеет всем”, но обязан видеть всю цепочку: от поля в API до архива, лога, витрины и внешнего получателя.

Как мыслить не системами, а жизненным циклом данных

Новичок обычно смотрит на архитектуру как на список сервисов: mobile app, backend, Kafka, warehouse, S3, BI. Но защита данных становится понятнее, если смотреть на жизненный цикл данных.

Упрощённо он выглядит так:

сбор — данные вводятся пользователем, партнёром, оператором, устройством;

передача — они идут через API, очереди, файлы, шины;

обработка — система считает баланс, скоринг, антифрод-оценку, отчёты;

хранение — данные лежат в БД, объектных сторах, индексах, витринах;

использование — данные читают сотрудники, сервисы, модели, подрядчики;

архивирование и удаление — данные стареют, копируются в архив или уничтожаются.

На каждом этапе набор рисков меняется. При сборе опасен избыточный запрос данных. При передаче — неправильная аутентификация или утечка в интеграции. При хранении — избыточные доступы и слабая сегментация. При использовании — широкие роли, ручные выгрузки и “временные” исключения. При удалении — вечные резервные копии и забытые кэши.

Один и тот же атрибут, например телефон клиента, может пройти все этапы за минуты. Он попадает в форму onboarding, идёт в backend, сохраняется в CRM, попадает в антифрод-правило, уходит в push-провайдера, фиксируется в логах доставки и остаётся в support ticket. Именно так маленькое поле становится распределённым объектом безопасности.

Пошагово: как разобрать ответственность на примере перевода между счетами

Возьмём простой финтех-сценарий: клиент переводит деньги между счетами внутри мобильного приложения. На поверхности это одна кнопка, но для Data Security это цепочка решений.

Шаг первый: определить чувствительные данные

В этом потоке есть идентификатор клиента, номера счетов, сумма, валюта, устройство, IP-адрес, токен сессии, назначение платежа, результат антифрода и операционные логи. Не все поля одинаково критичны, но почти все требуют режима обращения. Назначение платежа нередко содержит лишнюю личную информацию, потому что люди пишут туда что угодно — от номера договора до медицинского комментария.

Шаг второй: увидеть все места появления копий

Данные живут не только в транзакционной БД. Они могут оказаться в брокере сообщений, аналитическом озере, системе поддержки, алертах мониторинга, SIEM, резервных копиях и песочнице для тестов. В реальных компаниях проблема часто не в “основной” базе, а в вторичных копиях, про которые вспоминают поздно.

Шаг третий: назначить владельцев решений

Продуктовая команда решает, зачем нужно поле “назначение платежа” и как оно показывается. Backend-команда отвечает за бизнес-логику и API. Платформенная команда — за секреты, шифрование и IAM облака. Data Security определяет требования: какие поля маскировать, кому запрещать выгрузку, где включать аудит, как ограничить чтение в support tools.

Шаг четвёртый: выбрать меры по риску, а не по моде

Не every sensitive field требует одинаковой защиты. Для токена сессии критичны короткий срок жизни и защита от утечки в логах. Для номера счёта — контроль отображения, маскирование и ограничения на экспорт. Для антифрод-решения важнее целостность и прослеживаемость, потому что его подмена может влиять на деньги и расследования.

Шаг пятый: проверить операционную реальность

Политика бесполезна, если саппорт по-прежнему делает скриншоты экрана, аналитики скачивают CSV на ноутбук, а разработчики используют production-like dumps в тестах. Data Security работает только тогда, когда требования переживают повседневную рутину, а не только аудит.

Этот разбор важен потому, что показывает: речь не о “защите таблицы в БД”, а о координации нескольких слоёв контроля вокруг одного бизнес-события.

Где чаще всего путают границы ролей

Есть три особенно частые путаницы.

Первая: “если данные идут через API, это целиком AppSec”. На самом деле AppSec нужен, чтобы API не ломали и не обходили. Но вопрос, какие именно поля можно отдавать, как их маскировать, можно ли использовать payload для аналитики и где хранить следы вызовов, — это уже ядро Data Security.

Вторая: “если данные персональные, значит это только privacy”. Privacy действительно определяет правомерность, согласие, минимизацию и сроки хранения. Но техническая реализация — где включить masking, как сегментировать доступы, как не допустить утечку в витрину — требует Data Security.

Третья: “если есть DLP или DSPM, профессия уже закрыта инструментом”. Инструменты помогают обнаруживать и контролировать, но не заменяют модель данных, здравую классификацию и инженерные решения. DLP может поймать попытку отправить CSV наружу, но он не исправит плохую архитектуру доступа к данным.

Зрелость начинается не с идеала, а с видимости

Многие команды ждут момента, когда можно будет “правильно внедрить всё сразу”: полную классификацию, тотальный каталог, идеальный IAM, централизованное маскирование, тонкую политику retention. На практике путь начинается с видимости.

Первый зрелый вопрос звучит не “какой продукт купить?”, а “какие 10 наборов данных для бизнеса наиболее чувствительны, где они находятся и кто к ним имеет доступ?”. Если на него нельзя ответить за час, значит у компании не проблема отсутствия инструмента, а проблема отсутствия карты.

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

Если из этой главы запомнить три вещи — это: Data Security защищает не только базы, а весь жизненный цикл данных; ответственность в этой области распределена, но Data Security Engineer собирает картину целиком; в финтехе ключевой навык на старте — видеть, где данные появляются, копируются и открываются сверх необходимости.

Какие данные есть в финтехе и почему они чувствительны

Два поля в базе могут выглядеть почти одинаково: строка из цифр и строка из букв. Но одна строка окажется номером счёта, другая — токеном доступа, и последствия их утечки будут совершенно разными. В финтехе проблема не в абстрактных “данных вообще”, а в том, что разные данные наносят разный тип ущерба: финансовый, правовой, репутационный, операционный и даже физический, если речь идёт о давлении на клиента.

Новички часто делят всё слишком грубо: персональные данные, платёжные данные, “прочее”. Для старта этого хватает на пять минут, но не для инженерных решений. Чтобы понимать защиту данных, нужно видеть не только названия категорий, но и почему конкретный набор полей становится чувствительным именно в данном контексте.

Не все чувствительные данные одинаковы

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

В финтехе один и тот же атрибут может быть:

умеренно чувствительным сам по себе;

высокочувствительным в связке с другими полями;

почти безвредным в агрегированном виде;

снова опасным, если его можно связать с конкретным клиентом.

Например, город клиента сам по себе редко критичен. Но город + возраст + банк + дата крупного перевода + часть номера телефона уже может позволить уверенную деанонимизацию. Такой эффект называют комбинаторной чувствительностью: риск рождается из сочетания, а не из одного поля.

> В защите данных опасно смотреть на поля по отдельности. Реальные утечки почти всегда монетизируются через связки атрибутов.

Основные классы данных в финтехе

Для инженерной работы полезно делить данные не по учебнику права, а по тому, как они участвуют в системах и рисках. В финтехе обычно встречаются как минимум шесть больших классов.

Данные идентичности клиента

Это всё, что позволяет понять, кто именно перед нами. Сюда входят:

ФИО;

дата рождения;

телефон;

email;

адрес;

паспортные и иные удостоверяющие данные;

селфи, фото документа, результаты биометрической сверки;

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

Для злоумышленника такие данные ценны не только для перепродажи, но и для социальной инженерии, открытия новых аккаунтов, обхода поддержки, фишинга и давления на клиента. Для компании риск в том, что ошибка с identity-данными почти сразу становится вопросом privacy и комплаенса.

В 2017 году в утечке Equifax были затронуты имена, адреса, даты рождения, номера социального страхования и другие идентификаторы примерно 147 миллионов человек. Этот кейс часто разбирают как пример того, что identity-данные живут дольше, чем пароль: пароль можно сменить, дату рождения — нет.

Финансовые и платёжные данные

Это данные, которые прямо участвуют в движении денег или описывают финансовое состояние клиента:

номера счетов и карт;

IBAN, BIN, последние цифры карты;

история транзакций;

остатки и лимиты;

реквизиты получателей;

данные кредитов, просрочек, графиков платежей;

merchant data и платёжные маршруты.

Эти данные чувствительны сразу по нескольким причинам. Они помогают украсть деньги напрямую, строить мошеннические сценарии и детально восстанавливать образ жизни человека. История трат часто рассказывает о человеке больше, чем анкета: где он лечится, куда ездит, какие сервисы использует, каков его доходный ритм и семейное положение.

Данные аутентификации и секреты

Эта категория часто недооценивается новичками, потому что кажется “чисто технической”. На самом деле секреты — один из самых опасных типов данных в системе. Сюда относятся:

пароли и их хэши;

refresh tokens и session tokens;

API keys;

client secrets;

криптографические ключи;

seed-материалы, recovery-коды, OTP-секреты.

Если identity-данные помогают понять, кто клиент, то секреты позволяют действовать от его имени или от имени самой системы. Утечка логов с токенами доступа иногда опаснее утечки базы email-адресов, потому что ущерб начинается сразу, без дополнительной социальной инженерии.

Поведенческие и технические данные

Многие команды называют это “телеметрией” и из-за этого ошибочно считают менее чувствительным классом. Но в финтехе сюда входят:

IP-адреса;

device ID;

user-agent;

геолокационные признаки;

время и частота действий;

паттерны входов и переводов;

fingerprint устройства;

сигналы антифрода.

Эти данные нередко не выглядят интимными, но позволяют устойчиво отслеживать человека, связывать события между сервисами, оценивать привычки и строить скоринг риска. Для антифрода они критичны, а для privacy — потенциально проблемны, потому что позволяют профильную идентификацию даже без явного ФИО.

Операционные и служебные данные

Это логи, трассировки, дампы, алерты, тикеты поддержки, комментарии операторов, файлы расследований, экспорт для аналитики, резервные копии. Формально их часто не считают “бизнес-данными”, но именно здесь чувствительные сведения всплывают особенно часто.

!Слои данных в финтех-сервисе и вторичные копии

Классический пример — access log API, в котором случайно логируются параметры запроса вместе с токеном или номером документа. Второй пример — support ticket со скриншотом из личного кабинета. Третий — дамп ошибки, содержащий объект запроса целиком. Все три случая кажутся второстепенными, пока не происходит инцидент.

Производные и аналитические данные

Это сегменты, признаки моделей, скоринговые фичи, клиентские кластеры, fraud score, propensity score, внутренние метки риска, агрегаты и витрины. Такие данные чувствительны по двум причинам.

Во-первых, они часто восстанавливают исходные данные косвенно. Во-вторых, они могут влиять на решения о человеке: выдачу кредита, блокировку операции, усиленную проверку. Если такой набор неверен или непрозрачен, это уже риск не только утечки, но и несправедливого решения.

Почему одна и та же категория не всегда одинаково опасна

На старте полезно избегать магического мышления: нет списка полей, который автоматически решит всё. Чувствительность зависит от контекста, как минимум от четырёх факторов:

| Фактор | Что меняет | |---|---| | Связуемость | Можно ли связать запись с конкретным человеком или счётом | | Действуемость | Можно ли на основе данных провести операцию или обман | | Масштаб | Скольких клиентов затрагивает набор | | Восстановимость | Можно ли “отменить” ущерб, как в случае смены токена, или данные неизменны, как дата рождения |

Телефон клиента в CRM и телефон в агрегированной статистике по регионам — это не один и тот же риск. Последние четыре цифры карты на экране поддержки и полный PAN в незащищённой выгрузке — тоже не один и тот же риск. Даже хэш пароля не равен открытому паролю, хотя при слабых алгоритмах и плохом salt риск быстро растёт.

В этом месте удобно мыслить вопросами:

можно ли по данным идентифицировать человека;

можно ли по ним инициировать действие;

можно ли из них вывести новые чувствительные сведения;

можно ли их безопасно сократить, замаскировать или агрегировать.

Пошагово: как разложить один клиентский профиль по типам чувствительности

Представим типичный профиль клиента в финтех-приложении. В нём есть ФИО, телефон, email, паспорт, селфи, список карт, остатки, история платежей, fraud score, device ID и заметка оператора поддержки.

Шаг первый: разделить данные по функции, а не по экрану

На экране это один профиль, но по смыслу там минимум пять разных классов: identity, финансовые, аутентификационные следы, поведенческие сигналы и операционные комментарии. Этот шаг нужен, потому что один экран часто собирает данные, которые в архитектуре должны защищаться по-разному.

Шаг второй: найти поля с прямой монетизацией

Номер счёта, реквизиты, доступ к сессии, данные для обхода поддержки и документы — это поля, которые помогают украсть деньги или захватить аккаунт. Они требуют самого жёсткого режима доступа и почти никогда не должны свободно уходить в выгрузки.

Шаг третий: найти поля с долгим следом ущерба

Паспорт, дата рождения, история транзакций, селфи, сведения о семье или доходе сложно “переиздать”. Даже если злоумышленник не украл деньги сразу, ущерб может тянуться годами через мошенничество, давление и перепроверки личности.

Шаг четвёртый: отметить вторичные места риска

Заметка оператора может содержать фразы вроде “клиент звонил с нового номера, назвал паспорт и адрес”. Fraud score может лежать в аналитической витрине. Device ID может оказаться в логах мобильной аналитики. В этот момент становится видно, что опасные данные живут не только в основном профиле.

Шаг пятый: оценить, где можно снизить чувствительность технически

Часть данных можно маскировать при показе, часть — токенизировать, часть — не копировать в аналитику, часть — агрегировать. Это и есть инженерный поворот: не только признать риск, но и уменьшить поверхность экспозиции.

Такой разбор кажется медленным, но именно он превращает разговор “у нас есть PII” в практическую карту решений.

Частое заблуждение: “если данные обезличены, значит они безопасны”

На практике между “обезличены” и “безопасны” лежит большая дистанция. Данные могут быть:

псевдонимизированы — прямые идентификаторы заменены, но связь потенциально восстанавливается;

маскированы — часть значений скрыта для отображения;

токенизированы — исходное значение заменено управляемым токеном;

агрегированы — сведения сведены до уровня группы;

анонимизированы — идентификация практически необратима в разумном контексте.

Команды часто называют анонимизацией то, что на деле является псевдонимизацией. Если в витрине убрали ФИО, но оставили device ID, точные даты операций, географию и устойчивый customer_id, набор может быть повторно связан с человеком. Особенно это опасно в финтехе, где внешние источники и поведенческие паттерны делают re-identification проще, чем кажется на бумаге.

Вторичные копии — скрытый центр тяжести риска

Когда компания впервые картирует данные, она почти всегда находит больше чувствительной информации в боковых системах, чем ожидала. Причина проста: вторичные копии возникают естественно:

для аналитики;

для отладки;

для поддержки;

для интеграций;

для резервирования;

для обучения моделей.

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

По данным IBM Cost of a Data Breach Report, инциденты с участием чувствительных клиентских и персональных данных остаются среди самых дорогих категорий из-за стоимости уведомлений, расследования, простоев и потери доверия. Для финтеха это особенно жёстко, потому что клиентские данные тесно связаны с деньгами и обязательствами перед регулятором.

Если из этой главы запомнить три вещи — это: в финтехе чувствительны не только персональные и платёжные данные, но и секреты, телеметрия, логи и производные наборы; риск определяется не именем поля, а его связуемостью, действуемостью и масштабом; самые опасные находки часто лежат не в основной БД, а во вторичных копиях — логах, выгрузках, витринах и тикетах.

Основные угрозы данным и зоны защитного контроля

Большинство людей представляют утечку данных как один большой взлом снаружи. Но в реальной финтех-компании серьёзный инцидент нередко начинается куда прозаичнее: у аналитика слишком широкая роль, разработчик включил debug-лог в production, подрядчику забыли отозвать доступ, а старый бакет с экспортами оказался доступен не той группе. Угроза данным — это не только злоумышленник, это любой механизм, через который данные становятся видны, искажены, украдены, заблокированы или использованы не по назначению.

Поэтому полезно сразу отказаться от мышления “есть атаки, а есть наши внутренние процессы”. Для данных и то и другое одинаково реально. Внешний атакующий, неосторожный сотрудник, чрезмерно любопытный подрядчик, ошибочная автоматизация и плохо спроектированный продукт могут привести к одному и тому же исходу: потере контроля над данными.

От чего именно нужно защищать данные

Если в предыдущих главах данные были объектом, то теперь важен тип ущерба. Для практики удобно выделять пять базовых сценариев.

утечка — данные стали доступны тому, кто не должен их видеть;

подмена — данные изменены, и это влияет на решения, расчёты или расследования;

утрата — данные недоступны, удалены или повреждены;

злоупотребление доступом — разрешённый пользователь использует данные не по назначению;

неправомерное распространение — данные уходят дальше допустимого контура, даже если инициатор не злонамерен.

Например, оператор поддержки, открывший карточку VIP-клиента “из любопытства”, и злоумышленник, похитивший ту же карточку через скомпрометированный аккаунт, технически реализуют разные цепочки. Но с точки зрения Data Security обе ситуации — нарушение контроля доступа к чувствительным данным.

> Для инженера по защите данных важнее не “кто плохой”, а “какой путь привёл к потере контроля над данными”.

Главные источники угроз в финтехе

Удобно делить источники угроз не на “хакеры” и “остальные”, а на четыре группы.

Внешний атакующий

Это наиболее очевидный источник: злоумышленник ищет уязвимость в API, компрометирует учётную запись, крадёт токен, использует misconfiguration облака, атакует поставщика или интеграцию. Его цель — получить данные, повлиять на операции или создать шантажируемую ситуацию.

Такие сценарии ярко видны, потому что похожи на кино. Но даже здесь корневая причина часто не “гениальность атаки”, а отсутствие базовых ограничений: избыточный IAM, открытый storage, отсутствие сегментации, логирование секретов, незащищённые выгрузки.

Внутренний пользователь с легитимным доступом

Это сотрудник, аналитик, оператор поддержки, разработчик, подрядчик, который уже находится внутри доверенного контура. Опасность здесь в том, что многие процессы специально дают таким людям доступ к данным, а значит защита не может строиться только на барьере “снаружи-внутрь”.

Иногда речь идёт о злонамеренности, но намного чаще — о бытовой избыточности. Человек скачал выгрузку “для удобства”, отправил CSV в мессенджер, сделал скриншот, клонировал таблицу в личное пространство BI. Риск усиливается тем, что эти действия кажутся нормальной работой, пока не начинается расследование.

Ошибка системы или команды

Плохо написанный код, неверная конфигурация, забытая тестовая таблица, неочищенный лог, неправильная схема репликации, неверный retention — всё это создаёт инциденты без единого атакующего действия. В финтехе такой сценарий особенно опасен, потому что масштабы автоматизации велики: одна ошибка в пайплайне может размножить чувствительные поля в десятки систем за часы.

Партнёр и цепочка поставок

Финансовый сервис редко существует сам по себе. Есть KYC-провайдеры, скоринговые бюро, платёжные шлюзы, SMS-платформы, антифрод-поставщики, облачные хранилища и аналитические сервисы. Каждый внешний контур расширяет поверхность риска. Если данные покинули основной контур, контроль уже делится между несколькими сторонами, а значит, возрастает значение договорных, технических и процессных ограничений.

Типовые угрозы по жизненному циклу данных

Новичку трудно запомнить длинный список угроз. Проще связать их с этапами жизни данных.

| Этап | Типовые угрозы | |---|---| | Сбор | сбор лишних данных, подмена входных данных, небезопасные формы и SDK | | Передача | слабая аутентификация интеграций, утечка в API, MITM при плохой конфигурации, ошибки схем | | Хранение | избыточные права, открытые бакеты, слабое шифрование, незащищённые бэкапы | | Использование | ручные выгрузки, широкие роли, несанкционированный просмотр, копирование в сторонние инструменты | | Аналитика и ML | деанонимизация, переиспользование не по цели, чувствительные признаки в витринах | | Архив и удаление | вечные копии, забытые snapshot, неработающий retention, данные в тестовых средах |

Эта таблица полезна тем, что снимает магию с понятия угрозы. Угроза — это не абстракция, а конкретный способ потерять контроль на конкретном этапе.

!Сопоставление угроз данным и зон защитного контроля

Что такое зоны защитного контроля

Зона защитного контроля — это место в архитектуре или процессе, где можно реально снизить риск. Не декларативно “быть внимательнее”, а поставить конкретное ограничение, проверку или наблюдение.

На практике зоны контроля обычно группируются так:

идентификация и доступ — кто и при каких условиях получает данные;

приложение и API — что именно сервис принимает, хранит и отдаёт;

хранилища и платформы данных — базы, объектные хранилища, брокеры, витрины, бэкапы;

операционные процессы — support, выгрузки, инциденты, ручные процедуры;

интеграции и внешние контуры — поставщики, партнёры, SaaS;

мониторинг и аудит — логирование действий, алерты, расследования, доказуемость.

Важно, что один риск почти всегда требует нескольких контролей. Если боимся утечки CSV с транзакциями, недостаточно только запретить export в интерфейсе. Нужны ограничения ролей, журналирование действий, политика хранения выгрузок, контроль каналов отправки и иногда маскирование части полей ещё до выгрузки.

Пошагово: как сопоставить угрозу и контроль на примере логов

Разберём частый и недооценённый сценарий: backend-сервис финтех-приложения пишет в лог тело запроса при ошибке. В теле могут быть телефон, номер документа, токен сессии, реквизиты перевода.

Шаг первый: определить актив

Актив здесь — не “лог как таковой”, а чувствительные поля внутри лога. Если команда думает только “логи нужны для отладки”, она пропускает факт, что лог становится новым хранилищем данных.

Шаг второй: описать путь угрозы

Данные попадают в центральную систему логирования. Доступ к ней имеют SRE, разработчики, иногда аналитики и подрядчики. Значит, одно ошибочное решение в коде расширяет круг читателей чувствительной информации в разы.

Шаг третий: найти зоны контроля

Здесь их несколько:

в приложении — не логировать секреты и чувствительные поля;

в лог-пайплайне — редактировать или вырезать поля;

в доступе — ограничить чтение логов по ролям;

в мониторинге — искать паттерны PAN, токенов, паспортов;

в retention — не хранить сырые логи дольше необходимого.

Шаг четвёртый: выбрать первичный контроль

Самый сильный контроль — не допустить запись чувствительных данных в лог вообще. Все остальные меры полезны, но они вторичны. Это важный принцип: лучший контроль ставится как можно ближе к источнику появления риска.

Шаг пятый: закрыть операционный хвост

Даже после исправления кода остаются старые логи, резервные копии, индексы поиска и экспортированные фрагменты расследований. Если их не учесть, инцидент формально “исправлен”, а фактически продолжает жить.

Этот пример хорошо показывает, что один риск пересекает сразу код, платформу, IAM и процессы.

Какие контроли работают в финтехе чаще всего

В защите данных много модных слов, но базовый рабочий набор довольно приземлённый. Чаще всего высокий эффект дают следующие меры:

минимизация данных — не собирать и не копировать лишнее;

наименьшие привилегии — выдавать доступы только по реальной необходимости;

сегментация — разделять контуры, окружения, роли и каналы;

маскирование и токенизация — снижать экспозицию значений при чтении и передаче;

шифрование — защищать данные в хранении и передаче;

аудит доступа — видеть обращения к чувствительным наборам;

retention и удаление — не хранить ненужное вечно;

обнаружение аномалий — замечать необычные выгрузки, массовые чтения, нехарактерные запросы.

Это скучные меры, но именно они чаще всего отделяют управляемый риск от регулярных инцидентов. В отчётах о расследованиях редко фигурирует “не хватало AI”, зато постоянно встречаются “права были шире нужного”, “данные логировались”, “backup был доступен”, “интеграция не проверялась”.

Частое заблуждение: “если есть шифрование, данные защищены”

Шифрование очень важно, но оно не решает основную часть повседневных рисков доступа. Если у сотрудника или сервиса уже есть разрешение читать данные, шифрование “на диске” не помешает их увидеть, выгрузить или переслать. То же относится к утечкам через приложение, API, отчёты и логи.

Поэтому полезно различать:

защиту от кражи носителя или snapshot;

защиту от неправильного логического доступа;

защиту от злоупотребления уже выданным доступом.

Шифрование прекрасно работает в первой категории и частично помогает во второй, но без IAM, журналирования, маскирования и политики использования оно не закрывает весь риск. В финтехе это особенно заметно в аналитических контурах: данные могут быть идеально зашифрованы в storage и при этом слишком широко открыты через SQL-доступ.

Как выглядит зрелое мышление о контролях

Незрелый подход звучит так: “У нас есть DLP, значит выгрузки под контролем” или “У нас включено encryption at rest, значит база защищена”. Зрелый подход задаёт цепочку вопросов:

где риск возникает впервые;

какой самый ранний и самый дешёвый контроль его режет;

кто может этот контроль обойти;

где нужны компенсирующие меры;

как мы узнаем, что контроль перестал работать.

Именно так строится карта защитных зон. Не один серебряный патрон, а слоистая защита, где каждый слой понимает свою роль.

Если из этой главы запомнить три вещи — это: угрозы данным приходят и снаружи, и из обычных внутренних процессов; контроль нужно ставить там, где риск рождается, а не только там, где его уже заметили; самые рабочие меры в финтехе часто базовые — минимизация, доступы, сегментация, маскирование, аудит и удаление ненужных копий.

Смежные области: AppSec, Privacy Engineering, DSPM и DLP

В одной компании проблему формулируют так: “надо защитить данные клиента в API”. В другой — “нужно выполнить требования по персональным данным”. В третьей — “нам нужен DSPM, потому что никто не знает, где лежит чувствительная информация”. Формулировки разные, а новички быстро начинают путать области и инструменты. В результате возникает хаос: AppSec ждёт, что privacy опишет маскирование, privacy ждёт, что DLP поймает всё сам, а data security пытается закрыть архитектурную дыру политикой.

Путаница возникает потому, что все эти домены действительно работают вокруг одних и тех же данных. Но они отвечают на разные главные вопросы. Чтобы быстро собрать карту профессии, нужно понимать не только пересечения, но и границы.

Data Security: фокус на самом объекте защиты

Data Security задаёт главный инженерный вопрос: как сделать так, чтобы данные были открыты только тем, кому можно, использовались по допустимым сценариям, не расползались по лишним контурам и оставались защищёнными в хранении, передаче и обработке.

Эта область смотрит на:

классификацию и чувствительность данных;

потоки между системами;

права доступа;

вторичные копии: логи, дампы, витрины, бэкапы;

меры снижения экспозиции: masking, tokenization, encryption, auditing;

архитектурные и операционные решения вокруг данных.

Если коротко, Data Security думает не только “как не взломать систему”, а “как не потерять контроль над данными даже в нормальной повседневной работе”. Это важно для финтеха, потому что значимая часть риска возникает не через кинематографический взлом, а через рутину — выгрузки, аналитические копии, расширенные роли и интеграции.

AppSec: фокус на приложении и способах его сломать

Application Security отвечает на другой вопрос: насколько безопасно само приложение и процесс его разработки. AppSec анализирует:

уязвимости в коде и зависимостях;

ошибки авторизации и аутентификации;

небезопасные API;

SSRF, SQL injection, XSS, insecure deserialization и другие классы дефектов;

безопасность CI/CD и SDLC-практики.

Если API позволяет клиенту получить чужую выписку из-за ошибки object-level authorization, это в первую очередь AppSec-проблема. Но как только мы спрашиваем, почему в ответе вообще есть лишние поля, должны ли они кэшироваться, логируются ли они и можно ли их маскировать для саппорта, подключается Data Security.

Здесь полезно помнить простую метафору. AppSec защищает дверь, окно и замок приложения; Data Security следит, что именно лежит внутри комнат, как это переносится между ними и кто имеет право открыть шкафы даже после входа.

Privacy Engineering: фокус на допустимости и ограничениях обработки

Privacy Engineering начинается с вопроса не “как защитить всё, что есть”, а “что вообще допустимо собирать, хранить и использовать”. Для этой области центральны темы:

персональные данные и их категории;

основания обработки;

consent, если он применим в конкретной модели;

purpose limitation — ограничение целей использования;

data minimization — минимизация;

retention — сроки хранения;

subject rights: доступ, удаление, исправление, экспорт;

privacy by design.

Если продуктовая команда хочет использовать историю переводов для новой модели персонализации, Privacy Engineering спрашивает: есть ли законное основание, соответствует ли это изначальной цели, можно ли ограничить набор полей, как документировать срок хранения и как удовлетворить запрос субъекта данных. Data Security же спрашивает: где будут лежать признаки, кто их увидит, как они маскируются и журналируются.

> Privacy отвечает на вопрос “можно ли и на каких условиях”, а Data Security — “как технически сделать это безопасно и контролируемо”.

На практике эти области тесно связаны. Ограничение цели без технических барьеров превращается в бумагу. Но и отличная инженерная защита не делает обработку допустимой, если сама цель сомнительна.

DSPM: увидеть, где данные вообще находятся

DSPM обычно расшифровывают как Data Security Posture Management. Это не отдельная философия безопасности, а класс подходов и инструментов, помогающих ответить на болезненный вопрос: где у нас лежат чувствительные данные, как они классифицированы, кто к ним имеет доступ и где конфигурация создаёт риск.

Типичные функции DSPM-подхода:

discovery чувствительных данных в хранилищах;

классификация по типам и чувствительности;

обнаружение misconfiguration;

анализ доступа и избыточных прав;

приоритизация рисков для data stores;

иногда — связывание data asset с владельцами и контекстом бизнеса.

!Сравнительная карта Data Security, AppSec, Privacy, DSPM и DLP

Представим, что у компании десятки бакетов, баз, data lake-слоёв и SaaS-хранилищ. Люди знают только часть из них, а чувствительные поля мигрировали годами. В такой среде DSPM полезен как “радар”: он помогает восстановить картину и найти зоны, где данные лежат без должного контроля. Но важно не перепутать инструмент с дисциплиной. DSPM помогает увидеть проблему, а не автоматически решить всю архитектуру доступа, минимизацию и lawful use.

DLP: удержать данные от нежелательного выхода

DLP — Data Loss Prevention — исторически фокусируется на предотвращении нежелательного распространения данных. В центре внимания обычно находятся каналы, через которые данные могут покинуть допустимый контур:

email;

web uploads;

мессенджеры и endpoint;

печать, clipboard, USB;

иногда облачные SaaS-каналы и совместная работа с файлами.

DLP особенно полезен там, где риск связан с человеческим действием: отправить файл наружу, скопировать содержимое, выгрузить таблицу в неподходящий канал. Для финтеха это важно в операционных и офисных сценариях: support, back office, аналитика, подрядчики, юридические и финансовые подразделения.

Но DLP тоже не стоит идеализировать. Он редко решает проблему, если:

данные изначально доступны слишком многим;

политика классификации сырая;

чувствительные значения расползлись по десяткам систем;

процессы вынуждают сотрудников постоянно обходить правила.

Иными словами, DLP часто работает как последний барьер на выходе, а не как замена архитектурной гигиены.

Одна ситуация — четыре разных вопроса

Лучше всего различия видны на одном сценарии. Представим: аналитик хочет выгрузить транзакции клиентов в CSV для исследования churn и открыть файл во внешнем BI-инструменте.

Что спросит AppSec

Безопасен ли механизм выгрузки?

Нет ли уязвимости в endpoint экспорта?

Как устроена аутентификация и авторизация доступа к функции?

Что спросит Privacy Engineering

Допустимо ли использовать эти данные для этой аналитической цели?

Можно ли сократить состав полей?

Каков срок хранения выгрузки и где отражена цель обработки?

Что спросит Data Security

Какие чувствительные поля попадают в CSV?

Можно ли заменить часть значений токенами или маской?

Кто увидит файл, куда он уйдёт, как будет журналироваться доступ?

Что сделают DSPM и DLP

DSPM может показать, что аналогичные выгрузки уже лежат в нескольких бакетах или витринах с плохими правами.

DLP может попытаться предотвратить отправку файла в недопустимый внешний канал или среагировать на чувствительный контент.

Одна и та же операция, но четыре разных слоя мышления. Именно это и нужно освоить на старте профессии: не путать углы зрения.

Таблица различий в одном кадре

| Область | Главный вопрос | Типичный объект внимания | Сильная сторона | Чего не хватает без соседей | |---|---|---|---|---| | Data Security | Как не потерять контроль над данными? | Данные в потоках, хранилищах, доступах, копиях | Системная защита жизненного цикла данных | Без AppSec и privacy можно упустить уязвимости и правомерность | | AppSec | Можно ли сломать приложение? | Код, API, auth, уязвимости SDLC | Находит и снижает эксплуатируемость приложения | Не решает сам по себе минимизацию и расползание данных | | Privacy Engineering | Допустима ли обработка и как её ограничить? | Цели, основания, права субъекта, retention | Превращает требования к данным в инженерные ограничения | Без data controls остаётся “бумажной” | | DSPM | Где чувствительные данные и каков их posture? | Хранилища, классификация, доступы, misconfig | Visibility и discovery в сложной среде | Не заменяет архитектуру и процессы | | DLP | Как не дать данным уйти не туда? | Каналы выхода, endpoint, контент | Контроль распространения и эксфильтрации | Не решает проблему избыточного доступа у источника |

Частая ошибка карьеры: путать профессию с продуктом

На старте особенно легко решить, что “заниматься data security” значит администрировать DSPM или DLP-систему. Это слишком узко. Продукты важны, но профессия шире:

понять модель данных бизнеса;

отличить чувствительные данные от просто полезных;

увидеть потоки и копии;

выбрать контроли по риску;

договориться с AppSec, privacy, platform и data teams;

превратить это в требования, процессы и наблюдаемость.

Инструменты помогают масштабировать работу, но не подменяют мышление. Команда может купить сильный DSPM-продукт и всё равно не знать, какие наборы данных для неё критичны. Может внедрить DLP и по-прежнему разрешать избыточные SQL-доступы. Может отлично делать privacy-документацию и при этом хранить тестовые дампы без маскирования.

Где у этих областей реальные точки пересечения

В финтехе особенно много совместной работы в трёх местах.

Первое — API и интеграции. AppSec отвечает за безопасность механизма, Data Security — за состав и экспозицию данных, Privacy — за допустимость передачи партнёру.

Второе — аналитика и ML. Data Security нужен для контроля витрин, признаков и доступов; Privacy — для целей, минимизации и ограничений; DSPM — чтобы увидеть, где эти наборы вообще лежат.

Третье — операционные контуры и выгрузки. DLP удерживает данные от недопустимого выхода, Data Security уменьшает риск ещё до выгрузки, Privacy задаёт рамки использования, AppSec следит, чтобы экспорт-функция сама не была дырой.

По данным Gartner и крупных вендоров облачной безопасности, рынок инструментов вокруг posture management и data governance быстро растёт именно потому, что компании перестали видеть данные как побочный продукт приложений. Но рост инструментов не отменяет фундаментального факта: нужны люди, которые понимают различия доменов и могут собрать их в одну рабочую программу.

Если из этой главы запомнить три вещи — это: Data Security, AppSec, Privacy Engineering, DSPM и DLP работают вокруг одних данных, но отвечают на разные главные вопросы; DSPM и DLP — это не замена профессии, а инструменты видимости и контроля; сильный инженер по безопасности данных умеет переводить проблему между доменами: от “можно ли” к “как безопасно”, от “где лежит” к “как не выпустить”.

Quick start: карта данных, рисков и контролей для финтех-сервиса

У начинающего data security engineer почти всегда одна и та же проблема: теории уже много, а первого практического результата ещё нет. Хочется не просто понимать термины, а уметь открыть схему сервиса и за час собрать осмысленную картину: какие здесь данные, где они наиболее чувствительны, какие риски реальны и какие базовые контроли нужно проверить в первую очередь. Именно это и даёт хороший быстрый старт.

В финтехе не нужно начинать с идеальной enterprise-программы. Гораздо полезнее научиться делать первую рабочую карту. Это компактная модель сервиса, в которой связаны четыре вещи: данные, места их появления, риски и зоны контроля. Она не заменяет архитектурный аудит, но уже позволяет говорить с разработкой, аналитикой, платформой и privacy на одном языке.

С чего начать: выбрать один конкретный сервис

Плохой старт звучит так: “сейчас опишем все данные компании”. Хороший — так: берём один сервис с понятной бизнес-функцией. Для финтеха удобный учебный пример — сервис перевода денег по номеру телефона внутри мобильного приложения.

У такого сервиса есть чёткий путь:

пользователь открывает мобильное приложение;

backend аутентифицирует запрос;

сервис ищет получателя;

антифрод оценивает операцию;

платёжный движок проводит перевод;

уведомления отправляют push или SMS;

событие идёт в аналитику и логи.

Этот пример хорош тем, что в нём уже есть почти все типичные элементы реальной среды: API, чувствительные данные, интеграции, логи, вторичные копии, support и аналитика.

Первый слой карты: где данные появляются и куда текут

Начинать нужно не с уровней чувствительности и не с комплаенса, а с потока. Если не видно движения, все последующие решения будут абстрактными.

Сначала выписывают узлы:

мобильное приложение;

API gateway;

сервис аутентификации;

переводной backend;

антифрод;

транзакционная БД;

система логирования;

data warehouse;

support tool;

внешние провайдеры уведомлений.

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

!Карта потока данных финтех-сервиса

Важно не пытаться с первого раза сделать идеальную диаграмму. Для quick start достаточно простого вопроса: какие данные покидают один контур и входят в другой. Именно на этих переходах потом будут жить многие риски.

> Если вы не можете нарисовать путь данных через сервис на одном экране, вы ещё не готовы обсуждать его защиту всерьёз.

Второй слой: подписать типы данных, а не все поля подряд

Частая ошибка новичка — начать перечислять десятки колонок. Для первого прохода это перегружает картину. Лучше подписывать семейства данных:

identity: ФИО, телефон, email, документ;

финансовые: счёт, сумма, получатель, история операции;

секреты: токены, API keys, сервисные ключи;

поведенческие: IP, device ID, геосигналы;

служебные: логи, тикеты, статусы ошибок;

производные: fraud score, сегменты, агрегаты.

Так карта остаётся читаемой. Потом, когда дойдёте до конкретного контроля, можно детализировать поле до уровня “последние 4 цифры карты” или “назначение платежа”.

Этот шаг важен ещё и потому, что помогает не путать бизнес-ценность и чувствительность. Например, fraud score может не выглядеть “личным”, но быть очень чувствительным как производный признак, влияющий на решения и расследования.

Третий слой: найти 5–7 самых реалистичных рисков

На старте не нужен каталог из сотни угроз. Для одного сервиса достаточно короткого набора наиболее правдоподобных сценариев. Для нашего перевода по номеру телефона такими рисками будут:

API отдаёт лишние поля о получателе.

Токен сессии или чувствительные параметры попадают в логи.

Аналитическая витрина содержит слишком подробную историю переводов с широким доступом.

Support tool показывает оператору больше данных, чем нужно для задачи.

Выгрузка транзакций уходит внешнему подрядчику без маскирования.

Тестовая среда использует production-like дамп.

Права к объектному хранилищу с экспортами выданы слишком широко.

Хороший риск-сценарий всегда конкретен. Не “возможна утечка данных”, а “история переводов клиента копируется в BI-витрину, к которой есть доступ у ролей, не связанных с расследованием или аналитикой этой функции”.

Четвёртый слой: для каждого риска выбрать первичную зону контроля

На этом этапе карта начинает превращаться в инженерный инструмент. Для каждого риска задаём два вопроса:

где риск возникает впервые;

какой контроль может его срезать раньше всего.

Например:

| Риск | Где возникает впервые | Первый сильный контроль | |---|---|---| | Лишние поля в API | backend / schema design | schema review, field-level authorization, минимизация ответа | | Секреты в логах | приложение | safe logging, redaction, запрет логирования чувствительных полей | | Широкий доступ к витрине | data platform / IAM | role review, least privilege, сегментация витрин | | Избыточный экран саппорта | support tool / product design | masking, purpose-based view, аудит обращений | | Небезопасная выгрузка подрядчику | экспортный процесс | минимизация полей, токенизация, договорный и технический контроль канала |

Это, пожалуй, главный практический навык для старта. Не просто назвать контроль, а привязать его к месту возникновения риска. Если риск начинается в схеме API, его нельзя “вылечить” одним лишь DLP на выходе. Если проблема в широких SQL-правах, шифрование storage мало поможет.

Пятый слой: отметить владельца действия

Молодые специалисты часто пишут красивые карты, которыми никто не пользуется. Причина проста: в них нет владельца следующего шага. Для quick start достаточно даже грубой привязки:

backend team;

data platform;

support product owner;

cloud/platform security;

privacy/legal;

data security.

Например, masking экрана поддержки редко сделает сама security-команда: она задаст требование и поможет с моделью риска, но реализует это продуктовая или frontend/backend-команда. Аудит чтений в warehouse может потребовать платформенную команду. Ограничение цели аналитики — участие privacy и владельца продукта.

Пошагово: собрать мини-карту за 45 минут

Ниже — рабочая последовательность, которую реально можно сделать быстро на одном сервисе.

Шаг первый: назвать сервис и бизнес-действие

Не “финтех-платформа”, а “перевод по номеру телефона”. Чем точнее бизнес-действие, тем легче увидеть конкретные данные и доступы.

Шаг второй: нарисовать 8–12 узлов

Берите только те системы, которые реально участвуют в потоке. Избыток деталей убивает обзор. Для старта важнее не все микросервисы, а места смены контура: приложение, API, основной сервис, БД, аналитика, логи, support, внешний провайдер.

Шаг третий: подписать 1–3 семейства данных на каждую стрелку

Между mobile app и API идут identity, секреты сессии, финансовые параметры операции. Между backend и anti-fraud — transaction context, device signals, derived risk features. Между backend и notifications — телефон, шаблон, статус доставки.

Шаг четвёртый: выбрать 5 самых неприятных рисков

Не распыляйтесь. Выберите те сценарии, где есть либо высокий ущерб, либо высокая вероятность. В финтехе это почти всегда API-экспозиция, логи, витрины, выгрузки и support access.

Шаг пятый: поставить по одному сильному и одному компенсирующему контролю

Например, для логов: сильный — не записывать чувствительные поля; компенсирующий — детектировать их шаблоны и сократить retention. Для витрины: сильный — сузить роли; компенсирующий — журналировать массовое чтение и выгрузки.

Шаг шестой: зафиксировать 3 ближайших действия

Quick start не должен завершаться гигантским backlog. Лучше выбрать три шага, которые реально двинут управление риском:

проверить, не логируются ли токены и номера документов;

пересмотреть доступ к витрине транзакций;

оценить, какие поля видит оператор поддержки при поиске клиента.

Так карта становится не учебным артефактом, а стартом программы.

Что обычно забывают даже умные команды

Есть три слепые зоны, которые всплывают почти всегда.

Первая — вторичные копии. Команда честно описывает боевую БД, но забывает про CSV-экспорты, тикеты, снапшоты и индексы поиска. В итоге карта выглядит аккуратно, а риск остаётся в стороне.

Вторая — цель доступа. Люди перечисляют роли, но не спрашивают, зачем именно каждой роли видеть этот набор данных. Между “может технически открыть” и “нужно для задачи” лежит большая разница.

Третья — необратимость ущерба. Некоторые данные можно заменить: токен, пароль, временный ключ. Другие — почти нет: документ, история поведения, финансовый след. Это должно влиять на приоритеты контроля.

Матрица, которую стоит уметь делать вручную

После первой карты потока полезно собрать короткую матрицу “данные — риск — контроль — владелец”.

!Матрица данных, рисков и контролей

| Данные | Основной риск | Базовый контроль | Владелец | |---|---|---|---| | Телефон клиента | утечка через support и notifications | masking, ограничение показа, аудит | product + data security | | История переводов | избыточный доступ в аналитике | сегментация витрин, role review | data platform | | Session token | утечка в логах и трейсах | safe logging, short TTL, secret scanning | backend + platform | | Fraud score | чтение не по назначению, непрозрачное переиспользование | ограничение доступа, purpose control | anti-fraud + privacy + data security | | CSV-экспорт транзакций | вывод наружу | минимизация, токенизация, DLP, approval workflow | business owner + security |

Такая таблица полезна не своей полнотой, а тем, что заставляет мыслить связками. Не “есть данные”, а “есть данные, конкретный риск, контроль и ответственный”.

Как понять, что quick start сделан хорошо

Хорошая первая карта обладает пятью признаками:

её можно объяснить разработчику за 5 минут;

по ней видно не только основную БД, но и вторичные копии;

в ней есть не абстрактные, а реалистичные риски;

каждый риск привязан к зоне первого контроля;

из неё следуют 2–3 реальные задачи на ближайшее время.

Плохая карта, наоборот, либо слишком юридическая, либо слишком продуктовая, либо слишком инструментальная. Она перечисляет категории данных, но не показывает их движение. Или перечисляет угрозы, но не указывает, где ставить контроль. Или содержит сорок пунктов без приоритетов и владельцев.

Для начала карьеры этого достаточно. Не нужно сразу проектировать полный DSPM-контур или корпоративную DLP-политику. Гораздо важнее научиться делать маленький, но честный разбор одного сервиса. Из таких разборов потом складывается зрелая программа безопасности данных.

Если из этой главы запомнить три вещи — это: первый практический результат в data security — не идеальная программа, а рабочая карта одного сервиса; хорошая карта связывает поток данных, 5–7 реалистичных рисков, зоны первого контроля и владельцев действий; в финтехе quick start почти всегда начинается с API, логов, аналитических витрин, support-доступа и выгрузок наружу.