Каждый день десятки миллионов людей оплачивают покупки, переводят деньги и управляют счетами через мобильные приложения. Мы привыкли доверять своему смартфону больше, чем кошельку: один взгляд в камеру — и операция подтверждена. Но что на самом деле происходит между нажатием кнопки и успешным переводом? И почему успешная биометрическая проверка — это только начало длинной цепочки доверия?
В эпоху deepfake-мошенничества, украденных сессий и модифицированных приложений безопасность платёжных систем перестала быть просто технической задачей. Это постоянная гонка вооружений, где атакующие используют всё более изощрённые методы, а защитники должны думать на два шага вперёд.
Гусейн Джалилов — мобильный разработчик, специализирующийся на платёжных и банковских технологиях. Он работает на всей глубине стека: от пользовательского интерфейса до двоичного обмена с банковской картой по NFC. В крупнейшем платёжном сервисе страны, которым пользуются около 20 миллионов человек, он написал большую часть мобильной функциональности, через которую люди сегодня платят и переводят деньги. Его подход прост и радикален одновременно: каждая финансовая операция проектируется исходя из презумпции атаки. Сначала разбираются все способы, которыми её могут подделать, перехватить или выполнить от имени пользователя — и только потом строится удобный пользовательский сценарий.
В интервью он объясняет, почему биометрия отвечает только на часть вопросов безопасности, как выглядит цепочка доверия к платёжной операции и почему самый надёжный способ защиты — это тот, о котором пользователь никогда не узнает.
— Гусейн, ваш главный принцип звучит парадоксально: «проектировать так, будто атака уже идёт». Обычно же сначала делают продукт, а потом — если повезёт — думают о защите. Почему вы делаете наоборот?
— Потому что в финансовом приложении нельзя строить безопасность на предположении, что клиент всегда честный. Мобильный клиент — это часть системы, которую атакующий может изучать и пытаться модифицировать. Поэтому я проектирую не только сценарий успешной операции. Сначала я разбираю, как эту операцию попробуют подделать, повторить, перехватить или выполнить от имени пользователя, — и только после этого строю пользовательский путь.
Представьте, что вы строите банк. Можно сделать красивый холл, удобные кресла и быструю очередь — а сейф оставить на потом. А можно сначала спросить: а если грабители уже в здании? Если у них есть копии ключей? Если они выдают себя за сотрудников? Когда вы ответите на эти вопросы, холл и кресла уже будут стоять на правильном фундаменте.
— Давайте разберём на пальцах. Я открыл приложение, вошёл по Face ID, хочу перевести деньги. Что происходит «под капотом»? Почему просто «вошёл — значит, можешь платить» — это опасная логика?
— Успешная авторизация пользователя не означает, что любой последующий запрос автоматически безопасен. Биометрия отвечает только на часть вопроса — кто подтверждает действие. Отдельно нужно проверять приложение, устройство, сессию и сам контекст транзакции.
Я смотрю на операцию как на цепочку доверия. Сначала — личность: кто именно подтверждает действие? Потом — устройство: можно ли доверять этому конкретному телефону прямо сейчас? Затем — приложение: пришёл ли запрос из настоящего, неизменённого экземпляра программы? Дальше — сессия: действительна ли она именно в этот момент? Потом — намерение: пользователь должен понимать и подтверждать конкретную операцию — сумму, получателя, тип. И только потом — сама транзакция: параметры не должны незаметно поменяться после подтверждения.
Если сломается одно звено, цепь должна остаться на месте. Обход одного слоя не должен автоматически давать злоумышленнику возможность выполнить финансовую операцию.
— Многие думают: Face ID — это когда телефон сфотографировал моё лицо и сравнивает. Насколько это вообще верно?
— Это распространённое заблуждение. Приложение, использующее системную биометрию, не получает от Face ID «фотографию лица» для самостоятельного сравнения. Apple описывает биометрический контур как системный механизм; данные Face ID, включая математические представления лица, защищаются специальным изолированным процессором внутри чипа телефона. Face ID использует данные глубины, которых нет в обычной плоской фотографии, и встроенные механизмы противодействия подделке.
Так что правильнее говорить не «мы сравниваем лицо через Face ID», а «приложение запрашивает системное биометрическое подтверждение и получает результат аутентификации; биометрические шаблоны не передаются приложению». Это важно: даже если злоумышленник взломает само приложение, он не вытащит из него ваше лицо.
— Но ведь сейчас deepfake — это уже не фантастика. Можно синтезировать видео, голос, даже мимику. Не делает ли это биометрию бесполезной?
— Deepfake — это не причина отказаться от биометрии. Это причина перестать считать один сигнал достаточным доказательством доверия.
Развитие синтетического видео и голоса заставляет перестать рассматривать один биометрический канал как абсолютную гарантию. Существуют разные классы атак: когда злоумышленник показывает сенсору фотографию, видео или маску — это presentation attack. А когда поддельные данные подаются напрямую в цифровой тракт, минуя камеру, — это injection attack.
Поэтому liveness, «оживлённость», — это один слой защиты, а не замена всем остальным. Для чувствительных финансовых действий результат проверки должен рассматриваться вместе с контекстом устройства, приложения, сессии и операции.
— Вы говорите, что «ломаете» функцию до релиза. Как это выглядит на практике? Вы сидите и думаете: а что если…?
— Именно так. Перед разработкой финального сценария я задаю себе вопросы, которые неприятно задавать, но гораздо неприятнее получить на них ответ от реального мошенника.
Что произойдёт, если телефон уже находится у злоумышленника в разблокированном состоянии? Что если атакующий получил действующий токен сессии? Можно ли сформировать тот же запрос вне официального приложения? Можно ли повторить ранее корректный запрос и получить второй перевод? Можно ли изменить сумму или получателя после того, как пользователь визуально подтвердил операцию? Что если клиентское приложение модифицировано или его методы перехватываются специальными инструментами?
Threat model нужен не для перечисления страшных атак. Его задача — определить, какое решение должно приниматься на устройстве, какое — только на сервере, какие данные можно считать доверенными и где нужны дополнительные доказательства. Самый дешёвый инцидент — тот, который произошёл только на такой сессии и не дошёл до продакшена.
— Почему нельзя просто доверять приложению? В конце концов, оно установлено на моём iPhone, а iPhone — это же не какой-то китайский no-name.
— Клиентское приложение нельзя считать полностью доверенной средой только потому, что оно установлено на iPhone. iPhone — надёжное устройство, но само приложение — это поле боя. Его можно изучать, модифицировать, перехватывать вызовы методов во время работы, подменять ответы.
Поэтому критические решения нельзя оставлять только на стороне мобильного клиента. Успешный Face ID не должен превращаться в универсальное разрешение на любую финансовую операцию. Важно подтверждать конкретное действие и заново оценивать его контекст. На сервере должна происходить валидация, проверка уникальности запроса, защита от повторной отправки. Безопасность как архитектурное свойство — это когда обход одного слоя не даёт атакующему всю систему целиком.
— У вас в резюме есть работа с NFC и банковскими картами. Для обычного человека это «поднёс телефон к терминалу — готово». Что там происходит с точки зрения безопасности?
— Когда приложение получает данные банковской карты по NFC, инженерная задача не заканчивается успешным обменом командами с чипом. Нужно заранее определить, какие данные вообще нужны приложению, где они могут существовать, что клиент имеет право инициировать и какие решения должны приниматься только на сервере.
Схема примерно такая: карта → телефон → сервер → платёжная операция → подтверждение пользователя. На каждом из этих этапов есть свои риски. И если на каком-то из них вы решили «ну, тут можно довериться», — вы уже оставили дверь приоткрытой.
— Вы работаете в крупнейшем платёжном сервисе страны, им пользуются миллионы. Это давит?
— Это скорее фокусирует. Когда знаешь, что твои решения касаются реальных денег реальных людей, нет соблазна срезать углы. Ты не можешь сказать: «ну, вдруг никто не заметит». Заметят. И если не заметят хорошо — заметят плохо.
Для меня хороший платёжный сценарий — это не только тот, который удобно проходит пользователь. Это тот, который неудобно и дорого воспроизвести атакующему.
— Что вы вынесли как главный урок за годы в этой профессии?
— Что безопасность — это не набор отдельных защитных механизмов, а способ мышления. Чувствительная операция рассматривается как цепочка доверия, в которой каждый участок может быть атакован независимо. Защита закладывается в архитектуру и протокол операции до запуска функции, а не достраивается после первого инцидента.
И ещё один урок: нельзя обещать абсолютную защиту. В безопасности абсолютные гарантии некорректны. Можно только повышать стоимость атаки, уменьшать окно возможностей и проектировать так, чтобы компрометация одного элемента не означала компрометацию всего.
— Спасибо, Гусейн. Получился разговор о том, что настоящая безопасность не кричит о себе. Она просто не даёт случиться тому, о чём мы даже не узнаем.
— Да. Именно поэтому лучшая новость из мира финансовой безопасности — это отсутствие новостей.
