Задумывались ли вы, что основы информационной безопасности ваших клиентов начинают формироваться ещё на этапе дизайна продукта? Это может показаться странным, но именно дизайнер/проектировщик - тот человек, который закладывает фундамент сохранности аккаунта, финансов и персональных данных пользователей.
Разумеется, это вотчина не только и не столько дизайнера - большинство проблем в этой области возникает на этапе реализации. Однако если дизайнер допустил ошибки при проектировании, то архитекторам и программистам потом будет куда сложнее залатать все его дыры. И не факт вообще, что у них получится это сделать.
У меня нет задачи в этой маленькой статье предостеречь вас ото всех возможных промахов и неверных решений, допускаемых при проектировании цифрового продукта. Каждый проект уникален. Максимум, что я могу сделать - это на примере нескольких популярных случаев показать, в каком направлении нужно мыслить и какие вопросы задавать себе или разработчикам.
Сценарии
Начинается всё уже с этапа сценариев. Регистрация, логин, восстановление доступа. Оплата, привязка карты, пополнение счёта. Изменение данных профиля, добавление сотрудника, экспорт информации. Вот лишь малая часть потенциально уязвимых сценариев - и в каждом продукте таких моментов вагон. Если вы думаете, что достаточно сделать "как у всех" и ничего не случится, то у меня для вас плохие новости.
Не продумали сценарий проверки авторизации, не прописали это в функциях системы, не отрисовали соответствующее сообщение - и всё. Этого хватит, чтобы разработчики даже не подумали про какие-то пограничные ситуации.
Каждый сценарий нужно дополнительно оценивать с точки зрения безопасности. Если есть сомнения, обсуждайте с коллегами-разработчиками.
Пример
Далеко ходить не будем. Восстановление доступа к аккаунту.
Схема простая:
- пользователь забыл пароль,
- запросил сброс пароля,
- ему на почту пришло специальное письмо;
- он перешёл по ссылке в письме,
- ввёл новый пароль,
- система его авторизовала.
Какие макеты отрисует наш дизайнер, исходя из этой логики? Представим, что дизайнер крутой и не просто делает дефолтные экраны, но и все их возможные состояния: с ошибками, например. Он понимает, что во время отправки формы сервер может лежать, что пользователь может ввести несуществующую почту или вообще не почту в нужное поле. Также он понимает, что после отправки нужно показать пользователю соответствующее сообщение.
Итак, у нас получается три группы макетов:
- Экран восстановления доступа в четырёх состояниях: обычное, заполненное с ошибкой, отправленное, ошибку отправки.
- Само письмо с кнопкой восстановления доступа (это если дизайнер ответственный и не пренебрёг макетом для письма).
- Экран ввода пароля также в тех же четырёх состояниях.
Что дальше? А дальше разработчик сядет за реализацию. У него есть конкретные задачи по вполне понятному сценарию. Представим, что разработчик обычный, и не привык делать за аналитика/проектировщика его работу. Он просто реализует то, что ему было предоставлено. Схема-то обыкновенная, он тысячу раз такие делал.
Но не всё так просто. Представьте, что наш пользователь прошёл по всему сценарию. Он восстановил доступ, но ссылка на это восстановление каким-то образом утекла к третьим (не очень добросовестным) лицам. Это могло произойти тысячей способов, но мы рассмотрим наиболее популярный: наш клиент воспользовался бесплатным, но скомпрометированным вайфаем.
Как правило, такие "точки" не анализируются в реальном времени, а собирают некий пул информации, который потом отправляют всяким плохим дядям. Которые раз в некоторое количество времени эти данные анализируют (чаще всего в полуавтоматическом режиме) и решают, как именно они могут их использовать. Такой дядя может потом продать эту информацию, или самостоятельно завладеть нужным ему аккаунтом.
Как? Банально перейти по полученной ссылке, сменить пароль, зайти в аккаунт - а там уже вариации на любой вкус: сменить почту, вывести деньги, удалить содержимое и так далее.
Решение
Самая красота в том, что для предотвращения этой грустной ситуации достаточно сделать лишь одну дополнительную ветку сценария и отрисовать всего один дополнительный типовой макет.
Понимаете? Мы просто добавляем ветку с "протухшей" ссылкой. По истечении суток мы банально деактивируем ссылку из письма с восстановлением доступа. Наш дизайнер собирает ещё один макет, на котором показывает сообщение типа "ссылка устарела". Разработчик, видя этот сценарий, реализует дополнительную функциональность. Пользователь даже не заметит изменений - чаще всего, ссылка используется в первые несколько минут после запроса.
При этом разработка сильно не усложняется: наш программист просто добавляет поле со временем формирования ссылки в базу данных, а в момент загрузки страницы включает соответствующую проверку. При правильной архитектуре это делается в несколько строчек кода.
Данные
Следующий блок работ, в котором может накосячить проектировщик - это данные, способы их отправки/получения/отображения внутри продукта.
Кто-то сейчас скажет, что это не задача дизайна: продумывать схемы обмена информацией. В этом случае я просто предложу загуглить дизайн данных - и почитать пару статей с моего основного сайта. У продуктового дизайнера должна иметься хотя бы минимальная техническая грамотность - невозможно создавать качественные продукты, не понимая (хотя бы на базовом уровне), как они будут работать. Это влияет не только на безопасность продукта, но и на его качество, удобство использования, возможность дальнейшего развития.
Однако, даже если отбросить технические или около-технические нюансы, то всё равно останется информация, которая отображается в продукте. Почта, номера телефона и банковской карты, внутренний идентификатор пользователя, время последней активности - этот список может быть бесконечным.
Любая информация, которую предполагается выводить в интерфейсы, должна сначала проходить через фильтр "а как это может навредить?"
Пример
Случаев, когда аккаунт или даже целый сервис оказался в том или ином виде скомпрометирован, тьма. И очень часто причиной такой компрометации является какое-нибудь малозаметное число в интерфейсе. Или не совсем в интерфейсе.
Несколько лет назад случился один скандал. Он тогда наделал довольно много шума в определённых кругах. На рынке оказались более пятидесяти тысяч живых аккаунтов: персональные и финансовые данные клиентов некоего финтех-сервиса. Скандал оперативно замяли, выкинув ворох иных подобных инфоповодов - на которые со вкусом набросилась аудитория. И только в тех самых "определённых кругах" неделю проводили собственное, (можно сказать, волонтёрское) расследование.
По итогу выяснилась презабавная штука. В том сервисе была возможность расшарить свои данные контрагентам. По ссылке. Технически всё было грамотно: URL не содержал в себе прямого идентификатора пользователя, лишь длинный персональный хэш. Перебирать такие ссылки, чтобы спарсить данные аккаунтов - дело муторное, дорогое и нерентабельное.
Однако этот хэш (закреплённый за конкретным юзером) использовался ещё и в API этого сервиса. Однако он был бесполезен, если ты не знал внутреннего ID владельца хэша. А вот его как раз дизайнеры аккуратненько разместили сереньким шрифтом в углу той самой расшариваемой "визитки". Зачем - непонятно. Но те самые недобросовестные дядьки очень быстро поняли, что к чему, и шустренько спарсили весь сервис: написали простенького бота, который через несколько VPN перебрал всех пользователей и сохранил данные каждого. А потом выкинули эту инфу на чёрный рынок.
Не далее, чем сегодня "Коммерсантъ" рассказал, что в сеть утекла информация о нарушителях режима самоизоляции - и что сделать это оказалось возможным путём того самого парсингa, простого перебора значений.
Решение
А решение элементарно: достаточно было не выводить ненужный и опасный внутренний идентификатор пользователя во внешнюю часть продукта.
Если вам нужно показать какой-то идентификатор, используйте случайный набор символов - просто укажите разработчикам, что этот набор должен быть уникален для каждой сущности.
Итого
Выполняйте функциональное проектирование. Оно позволяет досконально прощупать все сценарии во всех пограничных состояниях и случаях. Не пренебрегайте дизайном данных, ибо информация сама себя не защитит. Всегда думайте, прежде чем вывести важную информацию во внешнюю часть вашего продукта.
И подписывайтесь на этот канал в Дзене - здесь будет много интересного.
