Как защитить данные пользователей в приложении на ИИ (без команды безопасности)

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

Вот тут до неё и дошло: она больше не хранила свои собственные заметки. Она хранила чужие заметки о их клиентах — детали здоровья, личные трудности, имена. Если бы эти данные утекли, это был бы не её позор. Это был бы их.

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

Начните с того, чтобы заметить, какие данные пользователей вы на самом деле храните

Большинство создателей это недооценивают. «У меня всего лишь форма регистрации» обычно означает, что у вас есть:

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

Потратьте десять минут и выпишите каждую единицу информации, которую ваше приложение хранит о человеке. Не поля базы данных — человеческий смысл. «Email», «какие добавки он принимает», «заметки, которые его тренер написал о нём». Этот список — ваша зона ответственности. Всё остальное в этом посте — про то, как сделать её меньше и безопаснее.

Привычка 1. Собирайте меньше

Самые дешёвые в защите данные — те, которые вы никогда не собирали. Прежде чем что-либо защищать, сократите список.

Пройдитесь по списку, который вы только что составили, и спросите по каждому пункту: а я этим пользуюсь? Приложение коуча запрашивало дату рождения при регистрации, потому что она была в шаблоне регистрации ИИ-конструктора. Она нигде её не использовала. Одно предложение ИИ-конструктору — «убери дату рождения из регистрации и удали столбец» — и целая категория чувствительных данных исчезла.

Что приложения часто собирают и никогда не используют: даты рождения, телефоны, физические адреса, пол, «как вы о нас узнали». Если вы не используете это в этом месяце, вы всегда можете запросить это позже. А вот вернуть утёкшее обратно нельзя.

Привычка 2. Контролируйте, кто что может видеть

У этого вопроса две версии, и нужны обе.

Внутри приложения: может ли один пользователь видеть данные другого? Если в вашем приложении есть клиенты и коучи, может ли клиент А когда-либо увидеть заметки клиента Б? Мы написали целое руководство про права пользователей в приложении на ИИ, но коротко: опишите правило своему ИИ-конструктору простыми словами («коуч видит только своих клиентов; клиенты видят только себя»), а затем проверьте это сами с помощью двух аккаунтов. Залогиньтесь под одним пользователем, попробуйте дотянуться до данных другого, кликая по приложению. Пять минут, два тестовых аккаунта. Именно этот тест ловит самую частую утечку в небольших приложениях.

Вне приложения: кто может видеть саму базу данных? Это вы, платформа вашего ИИ-конструктора и все, с кем вы поделились логинами. Что подводит нас к вопросам.

Привычка 3. Задайте своему конструктору эти пять вопросов

Вам не нужно глубоко понимать ответы. Вам нужно задать вопрос, и ответы должны быть уверенными «да». Вставьте эти вопросы в свой ИИ-конструктор приложений по одному за раз:

«Пароли пользователей хранятся в захешированном виде или их кто-то может прочитать?» Единственный приемлемый ответ содержит слово «захешированы». Если ваше приложение хранит пароли, которые кто-то может прочитать, исправьте это сегодня же — обычно это решается одним промптом, и большинство современных конструкторов делают это правильно по умолчанию.
«Соединение с приложением зашифровано (HTTPS)?» Ищите замочек в собственном браузере. Если адрес вашего приложения начинается с https://, с этим пунктом вы закончили.
«Если бы кто-то получил файл базы данных, смог бы он прочитать чувствительные поля?» Это про шифрование в состоянии покоя. Большинство хостинг-платформ делают это автоматически — спросите всё равно и запишите ответ.
«Какие сторонние сервисы получают данные пользователей?» Почтовые инструменты, аналитика, платёжные процессоры. Вы их не убираете — вы делаете свой список полным, потому что каждый сервис, хранящий данные ваших пользователей, — часть вашей зоны ответственности.
«Есть ли резервная копия и у кого есть к ней доступ?» Резервные копии — это копии ваших данных, а копии тоже нужно защищать. (Если вы вообще не настроили резервные копии, начните отсюда.)

Сохраните ответы в документе. Этот документ — начало вашей системы безопасности, и вы будете рады, что он существует, в первый же раз, когда клиент — или юрист клиента — об этом спросит.

Когда кто-то говорит «удалите мои данные»

Рано или поздно кто-нибудь это скажет, и закон в большинстве мест (GDPR в Европе, похожие правила в других местах) обязывает вас действительно это сделать. Решите сейчас, каким будет ваш ответ:

Можете ли вы удалить одного пользователя и всё, что с ним связано? Попросите свой ИИ-конструктор добавить это — «сделай админ-действие, которое удаляет пользователя и все его данные» — до того, как это понадобится вам под дедлайн.
Удаляет ли их из приложения заодно и из вашего почтового инструмента и аналитики? Сверьтесь со списком из вопроса 4.
Резервные копии ещё какое-то время будут их содержать. Это нормально и в целом приемлемо — просто знайте об этом, чтобы честно об этом сказать.

Ответить на запрос об удалении за день, потому что вы подготовились, выглядит профессионально. Метаться две недели выглядит ровно тем, чем оно и является.

Напишите страницу политики конфиденциальности простым языком

Пропустите пока сгенерированный юридический текст на 4000 слов. Напишите пять честных предложений: что вы собираете, зачем, кто ещё к этому прикасается (ваш почтовый инструмент, ваш платёжный процессор), как долго вы это храните и как попросить об удалении. Разместите её по адресу /privacy и поставьте ссылку со страницы регистрации.

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

Планка ниже, чем вы боитесь, и выше нуля

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

Коуч из начала статьи сделала всё это за один день: удалила два неиспользуемых поля, провела тест с двумя аккаунтами (и поймала одну утечку — клиенты могли видеть имена друг друга в выпадающем списке), задала пять вопросов, написала свою страницу конфиденциальности. После этого её приложение не стало выглядеть иначе. Но когда подруга спросила «а этому можно доверить заметки о моих клиентах?», у неё был настоящий ответ.

Выделите этот день. Ваши пользователи дали вам свои данные по доверию — вот как выглядит его оправдание.