Аудит безопасности движения данных для стартапов: сначала нарисуйте путь

Почему ревью безопасности буксуют

Ревью безопасности тормозятся, когда команды начинают с чек-листов поставщиков, а не с одного реального примера. Люди сравнивают SSO, регионы и значки соответствия, прежде чем ответить на более простой вопрос: куда попадает один файл клиента после загрузки?

Этот пробел важен, потому что риск редко живет только в первом инструменте. Он проявляется в тихих копиях рядом с ним: CSV, отправленный по email, синк в хранилище данных, скриншот в чате, отладочный лог, скачивание в браузере или «временная» таблица, которая висит месяцами.

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

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

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

Ревью безопасности сдвигается с места, когда кто-то рисует путь на одной странице. Это не обязано выглядеть аккуратно. Грубая схема того, где данные начинаются, где копируются, кто их видит и где они оказываются в конце дня, обычно говорит больше, чем час споров об инструментах.

Когда люди видят путь, разговор быстро меняется. Часто риск не в поставщике. Он в передаче данных, которую никто не посчитал.

Что нанести на схему

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

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

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

На каждом шаге отмечайте несколько базовых вещей:

• откуда данные входят
• где они хранятся
• кто или что может их читать
• где появляются копии
• как они покидают систему

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

Отдельного внимания требуют и экспорты. Резервные копии, запланированные отчеты, выгрузки в таблицы и CSV-дампы часто уезжают дальше оригинальной записи. Отчет по продажам может начаться в CRM, попасть в папку Downloads аналитика, уйти по email подрядчику и в итоге оказаться на диске финансов. Это уже четыре дополнительных места для проверки.

Например, клиент отправляет обращение в поддержку со скриншотом. Скриншот попадает в почту, синхронизируется в систему поддержки, копируется в чат для команды разработки, переносится в баг-трекер и позже появляется в еженедельном отчете. Если вы проверяете только систему поддержки, вы упускаете большую часть пути.

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

Почему промпты и логи должны быть на одной схеме

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

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

Логи создают еще одну копию, и команды быстро об этом забывают. API-лог может хранить тело запроса. Трекер ошибок может захватывать неудачный payload. Серверный лог может записывать имена файлов, ID пользователей и stack trace с упоминанием приватных записей. По отдельности это не выглядит драматично, но вместе набегает.

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

Представьте простой процесс. Сотрудник поддержки копирует тикет в ИИ-ассистент, чтобы набросать ответ. В тикете есть имя пользователя, email и имя файла скриншота. Запрос один раз тайм-аутится, поэтому инструмент ошибок сохраняет тело запроса. Позже сотрудник экспортирует переписку на проверку. Один тикет теперь существует в четырех местах, а не в одном.

Поэтому промпты и логи должны быть на одной схеме. Они часть одного и того же пути данных.

Когда команды смотрят на одну схему, они задают более хорошие вопросы:

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

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

Начните с одного реального процесса

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

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

Полезная первая схема отвечает на четыре вопроса: где запись начинается, кто может смотреть или редактировать ее на каждом шаге, кто может переслать, скачать или выгрузить ее и где она покидает ваши основные инструменты.

Последний пункт важнее, чем ожидает большинство команд. Лид может начинаться внутри инструментов, которым вы уже доверяете, а через несколько минут — уже покинуть их. Менеджер скачивает PDF из CRM на ноутбук. Другой человек копирует текст клиента в ИИ-ассистент. Кто-то вставляет ответ ИИ в чат. Позже команда выгружает CSV для еженедельного обзора продаж. Каждый такой шаг создает еще одну копию, еще один набор прав доступа и еще одно место, о котором легко забыть.

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

Многие стартапы пропускают это, потому что кажется слишком просто. Но это не так. Когда команда может показать на одну реальную запись и сказать: «Она пошла сюда, потом сюда, потом сюда, и эти пять человек могли с ней работать», — все становится яснее.

Как нарисовать путь

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

Запишите процесс в том порядке, в котором он происходит. Поместите первую систему слева, а конечную точку — справа. Затем заполните все остановки между ними, даже если шаг кажется скучным или временным.

Обычно достаточно одной страницы:

• Назовите точку входа, например веб-форму, почтовый ящик, чат-инструмент или загруженный файл.
• Добавьте каждую передачу по порядку, включая API-вызовы, ручные скачивания, экспорты и copy-paste в другой инструмент.
• Отметьте конечную точку, например запись в CRM, систему расчета зарплаты, облачную папку или локальный ноутбук.
• Укажите, кто отвечает за каждый шаг: продажи, поддержка, HR, разработка или внешний поставщик.
• Отметьте, сколько времени данные лежат в каждом месте, даже если ответ — «неизвестно».

Используйте стрелки для каждого перемещения. Одна стрелка может означать автоматическую синхронизацию. Другая — что человек скачал CSV и загрузил его куда-то еще. Copy-paste тоже считается. Команды часто игнорируют ручные перемещения, потому что они кажутся неформальными, но именно они создают самый запутанный риск.

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

Простой пример помогает. Клиент загружает документ через форму. Файл попадает в ваше приложение, затем в облачное хранилище, затем ИИ-инструмент читает часть через API, потом кто-то копирует сводку в тикет, а позже выгружает тикет в таблицу для еженедельного обзора. Это уже пять остановок, а большинство команд помнит только две.

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

Какие вопросы задавать на каждой передаче

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

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

Потом проверьте, кто сможет получить доступ к данным после перемещения. Запись, которую в вашем приложении видели только два человека, может стать доступной всей команде поддержки, внешнему поставщику или администратору рабочей среды, когда попадет в другое место. После передачи доступ часто расширяется, а не сужается.

Короткий чек-лист помогает проверять честно:

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

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

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

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

Где команды чаще всего упускают риск

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

Тестовые данные — один из самых частых слепых пятен. Их называют «sample data», но туда часто попадают реальные имена, email, счета, сообщения в поддержку или медицинские заметки, из которых убрали всего несколько полей. Как только такой файл попадает в staging-приложение, локальную папку или баг-репорт, чистая граница между продакшеном и тестом исчезает.

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

Отладка создает еще одну тихую проблему. Логи часто ловят больше, чем ошибки. Они могут хранить промпты, API-токены, сырые ответы, имена вложений, подписанные URL и фрагменты загруженных файлов. Если ваша команда использует ИИ-инструменты, это важно еще сильнее. Промпт, файл и лог обычно должны быть на одной схеме, потому что один баг-репорт может раскрыть все три.

Простой пример: продакт-менеджер выгружает неудачные записи онбординга в CSV, отправляет файл инженеру, а инженер запускает короткий скрипт на ноутбуке. Скрипт пишет подробные логи, CSV остается в Downloads, а логи уходят в общий мониторинг. Задача занимает 20 минут. Очистка так и не происходит.

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

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

Быстрые проверки перед тем, как одобрить инструмент

Большинство плохих одобрений ломаются на настройках по умолчанию, а не на демонстрации продаж. Прежде чем кто-то скажет «да», проследите одну реальную запись от момента, когда человек ее вводит, до момента, когда должна исчезнуть каждая копия. Если ваша команда не может объяснить этот путь простыми словами, остановитесь.

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

Используйте короткую проверку перед одобрением:

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

Настройки по умолчанию требуют особого внимания. Многие инструменты сохраняют историю промптов, журналы активности, предпросмотр файлов и архивы экспортов, если кто-то не изменит параметры. Команда может думать, что удалила заметку клиента, а текст промпта все еще лежит в логах 30 или 90 дней.

Права доступа не менее важны. Если любой может вставить продакшн-данные в любой блок промпта, ошибки будут. Держите правило простым: только одобренные роли могут использовать чувствительные данные в промптах и только в одобренных рабочих пространствах. Небольшие команды обычно выигрывают от короткого письменного правила, а не от длинной политики, которую никто не читает.

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

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

Если инструмент делает эти проверки сложными, это и есть ответ. Одобрение может подождать.

Что делать дальше

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

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

• Определите, какие данные можно отправлять в промпты, а какие нельзя.
• Решите, как долго хранятся логи, кто может их читать и когда они удаляются.
• Настройте один утвержденный путь для загрузки файлов и один — для экспортов.
• Зафиксируйте каждую передачу в SaaS, которая хранит данные клиентов вне вашей основной системы.

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

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

Если вам нужен второй взгляд перед тем, как одобрить инструмент или изменить процесс, Oleg Sotnikov at oleg.is делает такой ревью от частичного CTO для стартапов и небольших команд. Это особенно полезно, когда у команды уже есть один процесс на бумаге и нужна практическая помощь, чтобы сделать его безопаснее, не превращая все в бюрократию.