Какие данные можно собирать в Mini App

Запуск Mini App почти всегда начинается с продуктовой логики. Команда думает про сценарий, экраны, конверсию, оплату, запись, статусы, CRM. Вопрос про данные всплывает позже, когда приходит ИБ, юрист или заказчик с очень спокойным лицом и короткой фразой про ПДн, логи и доступы. В этот момент выясняется неприятная вещь: если архитектуру данных не продумали заранее, потом приходится перекладывать половину системы, чистить таблицы, вычищать логи и объяснять, зачем в debug-выгрузке оказался телефон клиента.

У Mini App есть своя специфика. Сервис живёт внутри экосистемы мессенджера, получает стартовые параметры, связан с ботом, ходит в бэкенд, отправляет события в аналитику, пишет технические журналы и часто стыкуется с CRM или ERP. Вопрос звучит шире, чем обычное «какие поля можно положить в форму»: какие персональные данные реально нужны, что допустимо держать в журнале, как долго хранить следы действий, кто из команды видит эти данные.

В «ОЧЕНЬ» через Mini App проходят заказы и платежи, поэтому персональные данные держим на бэкенде, а в клиенте — только то, что нужно для показа меню и статуса заказа.

Избыток данных редко приносит пользу — он создаёт новую поверхность риска. Умная схема собирает ровно то, что нужно для сценария, отделяет операционные данные от диагностических, маскирует чувствительные поля, режет сроки хранения и строит доступы по ролям.

Ниже — ПДн в Mini App, логирование персональных данных, ретеншн, права доступа команды и подготовка к вопросам ИБ до того, как они прозвучали на созвоне слишком громко.

Mini App в MAX получает часть стартовых параметров от платформы через MAX Bridge. После подключения max-web-app.js сервису доступен window.WebApp, а вместе с ним initData, initDataUnsafe, идентификатор сессии query_id, auth_date, start_param, а также объект user, где могут передаваться user.id, имя, фамилия, username, язык и ссылка на фото профиля. Документация MAX отдельно предупреждает: initDataUnsafe нельзя использовать для валидации пользователя, а подлинность стартовых данных стоит проверять через процедуру валидации.

Если платформа уже даёт набор полей, нужно ли тянуть их все в свою систему? Чаще всего — нет. ПДн в Mini App стоит собирать от цели, а не от соблазна. Если сценарий запускает каталог, вам почти никогда не нужен весь профиль. Если Mini App ведёт в запись, доставку или договор, набор полей будет шире, но и тут его стоит резать до рабочих пределов.

Роскомнадзор напоминает базовую рамку: оператором персональных данных считается организация или лицо, которое определяет цели обработки, состав данных и операции с ними. Понятие обработки широкое: сбор, запись, систематизация, накопление, хранение, уточнение, использование, передача, обезличивание, блокирование, удаление, уничтожение. С 1 сентября 2022 года оператор в большинстве случаев должен уведомлять Роскомнадзор о начале или осуществлении обработки персональных данных.

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

Условно данные в Mini App удобно делить на четыре корзины.

1. Данные для запуска сессии. Идентификатор пользователя MAX, query_id, start_param, технический контекст запуска, тип клиента, версия интерфейса. Это нужно сервису для старта сценария и трассировки событий. MAX передаёт часть этих данных сам.

2. Данные для выполнения действия. Адрес доставки, слот записи, номер договора, состав корзины, тип услуги, комментарий пользователя. Принцип минимального набора: если шаг можно выполнить без нового поля, поле не нужно.

3. Данные для поддержки и расследования инцидентов. Статус запроса, код ошибки, технический идентификатор операции, correlation id, время ответа, источник запуска.

4. То, что лучше не тянуть в логи и широкие выборки. Полные access token, session id, пароли, секреты, чувствительные ПДн, номера документов, полные платёжные реквизиты, сырые ответы внешних систем с персональными полями.

OWASP указывает: в журналы обычно не стоит записывать session id, access token, пароли, чувствительные персональные данные, ключи шифрования и другие секреты. Если журналу нужен коррелятор сессии, вместо самого session id лучше использовать его salted hash. Для менее чувствительных ПДн рекомендуют удаление, маскирование, санитизацию, хеширование, шифрование или де-идентификацию. Доступ к журналам нужно ограничивать и периодически пересматривать.

Логи любят расти: сначала HTTP-коды и тайминги, потом payload запроса, потом сырая ошибка внешней системы — и журнал внезапно знает о клиенте больше, чем CRM. Логирование персональных данных стоит проектировать как часть архитектуры, а не как побочный эффект разработки.

Практичная схема:

• бизнес-лог и технический лог разделены;
• debug-логи отключены по умолчанию в production;
• поля с ПДн проходят маскирование до записи;
• токены, cookies, session id и секреты режутся до сохранения;
• доступ к журналам выдаётся по ролям;
• экспорт логов и дампов фиксируется;
• retention для логов отделён от retention для бизнес-данных.

В логах можно хранить не «телефон клиента», а phone_hash или masked_phone: поддержка видит достаточно для поиска кейса, ИБ — что журнал не превратился в архив клиентской базы.

Ретеншн данных в Mini App проще всего понимать как календарь забывания: система должна помнить ровно столько, сколько нужно для операции, поддержки, отчётности, безопасности и законных обязанностей.

Полезно разделить сроки по классам:

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

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

Командный доступ часто ломает комплаенс сильнее, чем код: на старте доступы раздаются широко, тестовые выгрузки гуляют по чатам, staging содержит реальные данные — а потом выясняется, что половина команды видит лишнее.

Для Mini App разумная схема:

• разработка видит тестовые или обезличенные данные;
• аналитика получает события без лишних персональных полей;
• поддержка видит ограниченный профиль под кейс;
• ИБ и администраторы — расширенный доступ по регламенту;
• прод отделён от теста;
• админские действия логируются;
• чувствительные выгрузки согласуются и фиксируются.

OWASP для доступа советует least privilege, deny by default и регулярный пересмотр прав. Это снижает радиус поражения при ошибке, утечке или компрометации аккаунта.

ИБ обычно задаёт земные вопросы: какие ПДн собирает Mini App, на каком основании, где хранятся, кто видит, что пишется в логи, сколько живёт, как маскируются, как удалить, какие права у подрядчика, где граница между MAX, ботом и вашим бэкендом.

Краткий чек-лист:

1. Опишите все классы данных в Mini App.
2. Для каждого поля зафиксируйте цель.
3. Разделите пользовательские данные, техлоги и аналитику.
4. Пропишите срок хранения для каждого класса.
5. Опишите маскирование логов.
6. Утвердите ролевую матрицу доступов.
7. Проверьте staging, бэкапы и экспортные выгрузки.
8. Зафиксируйте, какие данные приходят от MAX Bridge и как вы их валидируете — MAX рекомендует валидировать стартовые параметры, а не доверять initDataUnsafe на слово.

1. Меньше лишней обработки ПДн — хранится нужное, а не весь цифровой шкаф.

2. Чище логи — проще расследовать ошибки, ниже риск утечки.

3. Проще проходить вопросы ИБ и юристов — ответы в документации, а не в голове у техлида.

4. Понятнее доступы команды — каждый видит свой слой данных.

ПДн и initDataUnsafe в MAX — надёжный источник для авторизации?
Нет. В документации MAX это разделено ясно: initDataUnsafe — для удобства интерфейса, для проверки подлинности стартовых данных нужна процедура валидации. Фронт может показывать имя или аватар, решения про доступ и привязку аккаунта принимает сервер после проверки.

Можно ли писать телефон и email в технические журналы?
Без острой необходимости лучше избегать. OWASP советует не писать в журналы чувствительные ПДн, токены и секреты в открытом виде. Для диагностики — маска, hash или служебный идентификатор.

Ретеншн на пилоте: как выбрать срок?
Не сохранять всё подряд «на потом». Задайте короткие сроки для техлогов, отдельный срок для активных заявок и для обезличенных отчётов. Бессрочное хранение почти всегда бьёт по проекту позже.

Кто владелец комплаенса?
Коллективный: продукт — зачем полю место в сценарии; разработка — хранение, маскирование, доступы; юрист — рамка и документы; ИБ — риски, логи, ролевая модель.

Как выдавать доступ подрядчику и поддержке?
По роли, задаче и сроку: отдельный контур, журнал действий, ограниченный набор данных; поддержка видит кейс, а не весь внутренний профиль. OWASP рекомендует least privilege и регулярный пересмотр прав.

Какие данные собирать без лишнего риска?
То, без чего сценарий не выполняется. Полезно делить поля на обязательные, сервисные и аналитические.

Нужно ли уведомлять Роскомнадзор?
Во многих случаях да: с 1 сентября 2022 года операторы должны уведомлять о начале или осуществлении обработки ПДн, кроме отдельных исключений. Конкретику лучше прорабатывать с юристом по ПДн.

Полные логи запросов в production ради отладки?
Плохая привычка: полные payload быстро превращаются в копию клиентской базы с бонусом в виде токенов. Для диагностики чаще хватает id операции, статуса и безопасных атрибутов.

Какой доступ разработке и аналитике?
Разработке — обезличенный или тестовый контур; аналитике — события без прямых персональных полей. Доступ к бою — ограничить по времени, роли и журналировать.

Нужна помощь с архитектурой данных, логированием и запуском Mini App в MAX — команда Else Digital подскажет, как собрать схему до разработки, а не после.

Вопрос про данные в Mini App редко бывает сугубо юридическим: он идёт от продукта через архитектуру в логи, доступы и к ИБ. Хорошая модель — минимальный набор ПДн, маскирование в логах, фиксированные сроки по классам данных, ролевые доступы, валидация стартовых данных от MAX, а не слепое доверие. Комплаенс Mini App выигрывает от дисциплины в деталях: стоит запустить один слой без контроля — и трещина идёт по всей системе.