У личного кабинета есть отказ дороже любого падения: один клиент увидел данные другого. Сайт при этом работает, в журнале ошибок пусто, а узнают об этом обычно от самого клиента — и почти всегда через несколько месяцев после того, как это началось.
В России у этой истории есть вторая половина, про которую вспоминают позже: закон.
Сначала про 152-ФЗ, потому что это решается не кодом
Как только в кабинете появляются данные людей — а сотрудники контрагента это люди, — вы оператор персональных данных. Из этого следует набор вещей, которые делаются документами и до разработки:
- Уведомление в Роскомнадзор о начале обработки. Подаётся один раз, но подаётся.
- Политика обработки и согласие. Не страница ради галочки: в ней перечисляются цели, состав данных и сроки хранения, и она должна совпадать с тем, что кабинет правда делает.
- Хранение на территории России. Вопрос к выбору хостинга, а не к коду, и решать его надо до того, как сервер выбран.
- Сроки. Данные нельзя хранить дольше, чем нужно для заявленной цели. Кабинет, который «на всякий случай» держит всё вечно, этому противоречит.
Штрафы за утечку персональных данных в последние годы выросли и считаются от оборота, так что это перестало быть темой для юриста в фоне.
Кто у контрагента имеет право
В B2B кабинет открывает не «пользователь», а сотрудник компании, и вопрос, кто именно вправе видеть цены и подписывать заявки, — это вопрос о доверенности, а не о ролях в интерфейсе.
Решите заранее:
- Кто заводит сотрудников — вы по заявке или администратор на стороне клиента. Второе дешевле в поддержке и требует роли, которой обычно не проектируют.
- Что происходит при увольнении. Ничто само не свяжет «человек ушёл» с «доступ закончился». Через полгода уволившийся снабженец всё ещё видит ваши цены для его бывшего работодателя.
- Кто видит деньги. Почти в каждом кабинете есть поле, которое стоит показывать не всем сотрудникам контрагента: скидка, отсрочка, долг.
Три способа сломаться технически
Угадываемый адрес. Документ лежит по ссылке, в ссылке номер, номер меняют. Если проверка живёт только в интерфейсе, у кабинета вместо замка табличка.
Роль, выданная в спешке. Кому-то понадобилось увидеть одну вещь — выдали роль, где ещё сорок. Пересматривать это некому, потому что не с чем сверять.
Общий вход на компанию. Один логин на всех «чтобы не плодить» — и журнал перестаёт отвечать на вопрос, кто скачал акт сверки. Именно этот вопрос однажды и зададут.
Журнал как доказательство
Отдельная причина вести журнал доступа в России — споры с контрагентами. «Мы не получали эти документы» — фраза, которая звучит в претензионной переписке регулярно. Запись о том, что документ был открыт таким-то сотрудником такого-то числа, закрывает разговор быстрее, чем письма.
Поэтому журнал стоит проектировать читаемым для человека, а не только для разработчика: кто, что, когда, с какого адреса.
Как это проверяется
Права мы проверяем жёстче остального — в нашей сборке кабинета это отдельная строка объёма, — потому что ломаются они тихо. На практике самое ценное — отрицательные проверки: клиент просит чужой заказ и получает отказ, документ тянут по угаданному адресу и получают отказ, сессия протухла посреди формы, приглашение использовали дважды.
Этих путей нет ни в одной демонстрации, и именно по ним кабинет судят в день, когда что-то пошло не так.
Коротко
Кабинет защищают три вещи: проверка на сервере при каждом запросе, читаемый журнал и второй фактор для тех, кто видит деньги. Все три недорогие рядом с ценой самого кабинета. А страница «мы заботимся о безопасности ваших данных» не защитила ещё никого — клиент, которому это важно, спросит про доверенности и про увольнения.