“Глюк” познаётся в беде

С банковской карты автора этой статьи внезапно списались деньги за поездку на такси, которую он не заказывал. Поначалу было только легкое недоумение: приложение “Яндекс Go” давно не использовалось, а тут вдруг обнаружился заказ, за который с карты ушла небольшая сумма. Причем карта эта в приложении была отключена. Однако самое интересное выяснилось при ближайшем рассмотрении.

Путь в никуда

Начальной и конечной точками этого загадочного маршрута оказались два адреса, которые автор ранее на той же неделе самостоятельно вводил в “Яндекс Картах”.

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

То есть пользователь не заказывал машину, не выбирал марш­рут и вообще не то чтобы не давал согласия на эту поездку, а знать о ней ничего не знал. Однако система каким-то образом сумела подобрать и маршрут, и способ оплаты.

В службу поддержки “Яндекса” пришлось обращаться уже не столько из-за денег, сколько из-за вполне естественного вопроса: как вообще мог появиться такой заказ?

Деньги компания вернула сразу же. Но внятного объяснения механизма произошедшего получить не удалось. И тогда история получила еще один неожиданный поворот. После того как служба поддержки начала расследование… мой аккаунт вовсе оказался заблокирован!

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

Необходимо добавить, что, по данным мониторинговых платформ (IsDown, StatusGator, Detector404), в те дни массовых сбоев сервисов “Яндекса” на территории Казахстана не зафиксировано.

Что могло произойти

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

- У пользователя есть “Яндекс ID” - единый аккаунт, по которому приложение узнает его в разных своих сервисах. Проще говоря, это одна учетная запись, которая может связывать между собой почту, карты, Go и другие приложения компании, - объясняет эксперт по сетевой безопасности Вячеслав КАЦ. - Поэтому информация, связанная с одним сервисом, в определенных случаях может быть доступна и другому. Например, такси можно заказать непосредственно через “Яндекс Карты”, а банковская карта, сохраненная при оплате какого-либо сервиса “Яндекса”, может использоваться в других сервисах, связанных с тем же аккаунтом. Но сама по себе связь между картами и Go ничего криминального не означает.

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

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

По его словам, пользователю в такой ситуации недостаточно просто получить возврат денег:

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

Особого внимания заслуживает совпадение адресов:

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

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

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

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

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

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

- Здесь тоже важно не путать разные вещи, - замечает Кац. - Центр обработки данных (ЦОД) - это, грубо говоря, мес­то, где стоят серверы и работает вычислительная инф­ра­­структура. Хороший ЦОД должен быть защищен от отключений электричества, сбоев оборудования, потери данных и несанкционированного доступа. В казахстанских требованиях к информационным системам уже предусмотрены, например, резервное копирование, фиксация изменений, мониторинг событий информационной безопасности и другие меры контроля. Но ЦОД может исправно работать в тот момент, когда программа внутри него совершает неправильное действие. Скажем, как в нашем случае, если приложение решило, что поиск адреса - это заказ такси, сервер может быть абсолютно здоров, резервные копии на месте, а система защиты исправна. Поэтому в эпоху ИИ одной киберзащиты становится недостаточно.

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

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

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

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

Владислав ШПАКОВ, Астана