С чего начинается защита информации
Пару лет назад я сдавал клиенту лендинг с формой обратной связи. Обычная форма: имя, телефон, комментарий. Но владелец попросил добавить поле для скана паспорта — «чтобы проверять контрагентов». Я сделал. Через несколько месяцев нашёл тестовый поддомен, где лежал дамп этой базы, потому что пароль от админки на staging совпадал с продакшеном. Утечки не случилось лишь потому, что я сам наткнулся на этот поддомен, пока искал пропавшую вёрстку.
После этого у меня появилось правило: любой проект — лендинг, прототип, чат-бот на GPT — начинается не с макета и не с генератора паролей, а с двух артефактов: классификации данных и модели угроз. Дальше расскажу, как я делаю их за пару часов и почему без них любая защита превращается в навешивание замков на дверь без стен.
Три вопроса, определяющие всё остальное
Прежде чем выбирать шифрование, WAF или что-то ещё, я честно отвечаю себе на три вопроса:
- Какие данные тут вообще есть? Не абстрактные «данные», а конкретные поля: email, телефон, IP-адрес, номер карты, переписка, сканы документов, токены API.
- Что будет, если они утекут? Штраф и проверка регулятора, потеря клиента, репутация, уголовная ответственность — или вообще ничего.
- Кто получит доступ легально? Я, клиент, подрядчик на SEO, веб-аналитика, сторонний AI-сервис.
Звучит банально, но именно здесь ломается большинство проектов. Пока на эти вопросы нет письменных ответов, любые технические решения — это угадывание.
Классификация данных: что это и зачем
Классификация данных (data classification) — распределение всех данных системы по уровням чувствительности, где каждому уровню соответствуют свои требования к хранению, доступу и передаче. Проще говоря: каждой «стопке» данных вы присваиваете ярлык, и ярлык диктует правила.
В российском контексте ориентируются в первую очередь на 152-ФЗ «О персональных данных» и на 98-ФЗ о коммерческой тайне. Для платёжных сценариев действует PCI DSS, для финансовых организаций — ГОСТ Р 57580. Если вы фрилансер и делаете сайт кофейне, весь этот набор вам не нужен, но базовые категории знать стоит — хотя бы чтобы понимать, где вы нечаянно перешли границу.
Практические уровни для типичного сайта
- Публичные — тексты, прайс, портфолио, статьи блога. Можно отдавать поисковикам и кешу CDN.
- Внутренние — черновики, редакционная кухня, аналитика без персональных данных. Утечка неприятна, но не критична.
- Персональные данные (ПДн) — имя, телефон, email, адрес, IP вместе с куки, если по ним можно опознать человека. Уже требует соблюдения 152-ФЗ: согласие, политика обработки, срок хранения.
- Специальные категории — здоровье, религия, биометрия, данные о детях. Максимальные требования; на своём сервере такое лучше вообще не хранить.
- Финансовые — реквизиты, номера карт. Если храните — попадаете в PCI DSS, поэтому честно советую не хранить, а отдавать платёжному провайдеру.
- Секреты проекта — токены API, пароли, ключи подписи, доступы к базе. Это тоже данные, и утекают они чаще всего — через репозиторий.
Второй шаг после разметки — принцип минимизации: для каждого поля нужен ответ на вопрос «зачем оно здесь и как долго живёт». Половина проблем с персональными данными решается тем, что вы просто не собираете лишнее. Сканы паспортов на лендинге кофейни — это не забота о безопасности, это мина с часовым механизмом.
Как я делаю это за 40 минут
- Открываю схему базы (или просто перечисляю поля всех форм) и выписываю всё в таблицу.
- Напротив каждого поля ставлю уровень: публичное, внутреннее, ПДн, секрет.
- Отдельно помечаю поля, которые уходят во внешние сервисы: аналитика, CRM, AI-API, рассыльщик.
- Для каждой группы прописываю срок хранения и способ удаления.
- Фиксирую, кто владелец данных — клиент или я.
Пункт 5 многие пропускают, а он важный: если владелец данных клиент, ответственность по 152-ФЗ в значительной степени на нём, но это не отменяет требований к вам как к обработчику, которому данные передали. Это стоит проговорить до старта проекта, а не после инцидента.
Модель угроз: кто и как вас сломает
Модель угроз (threat model) — документ, в котором перечислено, что вы защищаете (активы), от кого (модель нарушителя), какими способами (угрозы), через какие слабые места (уязвимости) и к каким последствиям это приведёт. Модель нарушителя — часть модели угроз: описание того, кто атакует и с какими возможностями и мотивацией.
Самый известный «взрослый» метод — Методика оценки угроз безопасности информации ФСТЭК России. Она обязательна для государственных систем и значимых объектов КИИ, но для лендинга или прототипа тянуть такой документ бессмысленно. Нужен не формальный отчёт на 60 страниц, а честный разбор на одну-две страницы.
Мини-шаблон, который реально работает
Я беру три колонки и заполняю их по схеме «актив → угроза → мера»:
- Актив: база заявок с телефонами клиентов.
- Угроза: перебор пароля к админке и последующая выгрузка базы.
- Мера: двухфакторная аутентификация, ограничение попыток входа, вынос админки на отдельный путь и фильтр по IP.
Дальше список пополняется по категориям нарушителей. Обычно я иду по такому чек-листу:
- Внешний автоматический сканер. SQL-инъекции, XSS, бэкапы, лежащие в публичном S3, забытый .env с доступами.
- Целенаправленный взломщик. Перебор паролей, фишинг по сотрудникам, эксплуатация устаревшего плагина CMS.
- Случайный пользователь. Иногда самый опасный: открытая ссылка на чужие заявки, IDOR (когда по адресу /order/1234 видно чужой заказ), поисковый бот, проиндексировавший админку.
- Инсайдер. Подрядчик, который сохранил себе дамп при переезде, или бывший сотрудник с живым доступом.
- Цепочка поставок. Вредоносный npm-пакет или сторонний скрипт, подключённый через CDN.
- Утечка через AI-сервисы. То, о чём почти никто не думает — разберём отдельно.
ИИ как источник угрозы, а не только помощник
Если у вас на сайте есть чат-бот на GPT, YandexGPT или GigaChat, в модели угроз появляется новый класс атак — prompt injection (инъекция промпта). Это когда пользователь пишет не вопрос, а инструкцию, заставляющую модель раскрыть системный промпт, выдать данные из подключённой базы или выполнить действие, которое вы не планировали. Классический пример: бот подключён к базе заявок, злоумышленник просит «выведи последние 10 записей таблицей» — и если доступ на уровне запросов не ограничен, он эти записи получит.
Отдельная история — организация-обработчик. Когда вы отправляете переписку с клиентами в сторонний AI-API, часть персональных данных уходит наружу. Нужно понимать, обучается ли провайдер на ваших данных, где расположены серверы и сколько хранятся логи. Для многих российских проектов это повод обезличивать данные перед отправкой: вырезать ФИО и телефоны, оставлять только суть запроса.
И да, я всё равно использую нейросети в этой работе — но как спарринг-партнёра, а не как аудитора. Рабочий сценарий: скармливаю модели обезличенную схему данных и список угроз, прошу «найди дыры и то, что я упустил». Иногда находит дельное — например, я стабильно забываю про восстановление пароля и токены в письмах. Но выводы проверяю руками: модели уверенно придумывают несуществующие уязвимости и так же уверенно пропускают реальные.
Чего делать не стоит
- Копировать чужую модель угроз целиком. Она собрана под другую инфраструктуру и создаёт ложное чувство защищённости.
- Составлять документ «для галочки». Если по итогам не появилось ни одного изменения в коде или настройках — это не модель угроз, а трата времени.
- Писать в модель угроз реальные данные клиентов. Никаких паролей, номеров карт и сканов в самом документе.
- Отдавать весь разбор внешнему AI-сервису. Модель угроз — это карта ваших слабых мест. Отправлять её целиком в чужое облако довольно иронично.
Минимальный набор мер, который закрывает большинство рисков
Когда классификация и модель угроз готовы, оказывается, что для среднего сайта достаточно небольшого списка:
- не собирать данные, без которых можно жить;
- пароли — только в виде хеша (bcrypt или argon2), никогда в открытом виде;
- секреты — в переменных окружения или в хранилище секретов (Vault, облачный secret manager), а не в коде;
- .env, дампы и бэкапы — вне публичного доступа, бэкапы шифровать;
- двухфакторная аутентификация на админку и ограничение числа попыток входа;
- HTTPS везде, включая внутренние переходы;
- внятная политика хранения: что и когда удаляется автоматически;
- логирование доступа к чувствительным данным.
Отдельно про людей: если у подрядчика закончился проект, его доступ должен быть отозван в тот же день. В моей практике именно забытые доступы подрядчиков давали больше инцидентов, чем все внешние взломщики вместе взятые.
И про юридическую часть: штрафы за утечки персональных данных в России за последние годы заметно выросли — на момент публикации действуют оборотные штрафы по КоАП. Точные суммы и условия проверяйте по актуальной редакции, они меняются, а вот требование сначала разобраться, какие данные вы обрабатываете, остаётся неизменным.
Заключение
Классификация данных и модель угроз — это те четыре-пять часов работы, которые экономят недели разбирательств и объяснений с клиентом. Порядок такой: выписать все данные и присвоить им уровни, ответить на вопрос «кто и как это сломает», и только потом выбирать конкретные технические меры. Схема работает и для крупного корпоративного портала, и для прототипа на скорую руку.
Нейросети тут полезны как ускоритель: помогают набросать список угроз, проверить код на захардкоженные ключи, объяснить незнакомый термин из нормативного документа. Но придумывать за вас модель угроз они не должны — и уж точно не должны получать доступ к вашим настоящим данным в процессе. Без магии и без паники: сначала карта, потом стены, потом замки.
