Проблемы утечек персональных данных особенно остро стоят в банках, ведь инциденты, связанные с утечками, сильно вредят репутации банков и создают реальные риски для клиентов. Поэтому во всех местах, где в банке есть чувствительные данные, которые обрабатываются или передаются, вопросы защиты и обезличивания весьма актуальны.
Причём надо понимать, что некоторые бизнес-процессы традиционно сложно реализовать на базе обезличенных данных, например, из области AML/ПодФТ, антифрода, кредитного скоринга.
Иногда приходится слышать суждение о том, что отличным подспорьем в данном вопросе может стать реализация концепции открытых данных на базе открытых API, разработанная Банком России. Утверждается, что подход Open API даёт возможность построить реальную безбарьерную среду для оборота данных и дело, как говорится, за малым. Не соглашусь с этими утверждениями. В теории, может быть, безбарьерная среда достижима и в долгосрочной перспективе мы к этому придём, но на практике до этого пока очень далеко. В качестве примера можно привести опыт внедрения открытых данных/OpenAPI (это немного разные вещи) в Европе. Там это уже несколько лет работает, но пользовательский опыт (UX) оставляет желать лучшего, пользователям неудобно этим пользоваться. И этот фактор — одна из причин того, что популярность сервисов растёт медленно.
С нашей точки зрения, открытые данные — это про удобство, повышение конкуренции и демонополизацию, но никак не про безопасность. Поэтому нужны новые подходы, которые могли бы дополнить модель открытых данных или помочь рынку, работая параллельно с ней. Что это за подходы?
На этот вопрос можно отвечать долго. Дело в том, что общепринятых стандартов нет, но активно развиваются разнообразные академические и прикладные исследования, а также прототипы технологий. Есть забавная обобщающая аббревиатура PET (Privacy Enhancing Technologies), которая объединяет такие подходы, как федеративное машинное обучение, дифференциальная приватность, технологии на базе блокчейна, MPC и многие другие. Исследовательских работ много, но как всё это выглядит с точки зрения практической реализации?
ПРАГМАТИЧЕСКИЙ ПОДХОД К ОБЕСПЕЧЕНИЮ ПРИВАТНОСТИ
Мы за прагматичный подход — пользователей нужно защищать уже сейчас и при этом учитывать реалии российской технологической и регуляторной среды. Поэтому мы занимаемся решениями на базе криптопротоколов и распределённых вычислений. Также на рынке есть любопытные и успешные пилоты на базе MPC.
Но для начала нужно зафиксировать, что понимается под конфиденциальностью. На практическом уровне это означает, что:
- Никто, кроме запрашивающего данные, не может однозначно идентифицировать субъекта;
- Участники системы не видят, кто делает запросы.
Чтобы реализовать эти свойства, мы разработали криптопротокол, состоящий из двух частей. Сначала участники обмена данными осуществляют процедуру Private Membership Test, с помощью которой выясняется, у кого из участников есть интересующие данные, причём без раскрытия идентификатора записи (например, номера телефона). Затем между нужными участниками проводится процедура Oblivious Transfer: данные передаются, но отвечающая сторона точно не знает, какие данные были переданы.
Отдельно отметим, что обе процедуры нужно реализовать не только безопасно, но и с высокой производительностью, чтобы обслуживать объёмы запросов крупных банков. Для этого пришлось подумать над структурами данных и реализовать протокол поверх эллиптических кривых.
В результате мы вывели на рынок решение КРаБ (криптографическая распределённая база), которое поддерживает распределённое хранение данных на основе криптопротокола и распределённую идентификацию (рис. 1).
Рисунок 1. Схема решения КРаБ — криптографическая распределённая база
Гарантии безопасности решения КРаБ обеспечиваются следующим образом:
- Децентрализация. Каждый участник хранит и контролирует собственные данные. Координатор ведёт учёт, но данные не хранит.
- Обезличенность. Участники сети, за исключением запрашивающего, не могут однозначно идентифицировать субъекта, по которому запрашивается информация. Это предотвращает кражу лидов.
- Анонимность. Участники сети не знают, кто с кем обменивался информацией и кому принадлежат полученные записи.
- Журналирование. Координатор записывает факты сделок, что обеспечивает возможность проводить аудит, и контролирует участников на предмет недобросовестного поведения (перебор, синтетические данные и др.).
Каждый узел распределённой базы представляет собой независимую виртуальную машину, стоящую у участника обмена данными. Вместе с доступностью сети на уровне не менее 99,9% у координатора это обеспечивает надёжность сети.
КРАБ В БАНКЕ
В мировом финтехе стремительно набирают популярность сервисы класса BNPL (Buy Now Pay Later — «Купи сейчас, заплати потом»), которые помогают разбить стоимость покупки на равные части и выплачивать в течение одного-двух месяцев. Эксперты говорят, что к 2030 г. в русле развития e-commerce BNPL-сервисы станут общепринятым способом оплаты, а мировой объём рынка достигнет 4 трлн долл.
На российском рынке BNPL-сервисы пока являются новинкой. Пожалуй, ключевым драйвером их развития является «Тинькофф Банк». Он использует для безопасной обработки данных клиентов решение КРаБ. Мы помогаем коллегам обмениваться данными, чтобы лучше считать платёжную нагрузку и осуществлять риск-скоринг, включая защиту от мошенников. В результате потерь оказывается меньше, конечные клиенты получают лучшие условия — это ситуация win-win.
В настоящее время «Кибертоника» и «Тинькофф Банк» прорабатывают новые кейсы в области антифрода, машинного обучения, которые выйдут на уровень промышленного внедрения в 2024 г.
В целом, говоря об обезличивании клиентских данных и борьбе с их утечками, стоит выделить два ключевых тезиса:
- Криптография — это, конечно, хорошо, но это только часть комплекса мер по информационной безопасности. Только весь комплекс в целом обеспечивает защищённость ИТ-решений.
- Обезличить данные так, чтобы гарантированно в любом случае нельзя было определить субъекта и при этом иметь возможность решать полезные прикладные задачи, крайне сложно. Может быть, даже невозможно. Приходится искать компромисс. И это неизбежно, ведь на практике, помимо обезличивания, обычно приходится соблюдать такие важные требования, как возможность аудита работы системы, выполнение запросов от субъектов или регулятора.
Источник: BIS Journal
