«Сделайте безопасно» — это не требование, а пожелание. Аналитик обязан закладывать конкретику. Шифрование в передаче (TLS/HTTPS — данные по сети только в зашифрованном виде) и в покое (на диске тоже зашифрованы). PII / персональные данные — всё, что позволяет опознать человека: ФИО, телефон, паспорт, e-mail. Хранить их — юридический риск (152-ФЗ в России, GDPR в Европе). Минимизация: не собирай данные, которые не нужны. Наименьшие привилегии: у каждого доступ только к тому, что нужно для работы. В логи нельзя писать пароли, карты и токены — их маскируют. И главное: любой ввод проверяется на сервере, клиенту верить нельзя. Безопасность — это не про доступ (это аутентификация и авторизация), а про защиту самих данных.
Однажды на инциденте мы открыли логи платёжного сервиса и обнаружили, что туда несколько месяцев писались номера карт целиком — в открытом виде, рядом с суммой и именем. Никто не закладывал это специально: разработчик просто логировал «весь запрос для отладки», а в запросе была карта. Спека про логирование молчала, и поэтому дыра жила полгода. Чинили не только код — чинили процесс: с тех пор в каждой моей спеке, где есть чувствительные данные, отдельным абзацем написано, что из этого нельзя писать в логи. Безопасность дешевле закладывать словами в требованиях, чем выгребать инцидентами.
«Безопасно» — это не требование
Слово «безопасно» в спеке не значит ничего, потому что его нельзя проверить. Разработчик прочитает его так, как ему удобно, тестировщик не сможет написать тест, а на ревью каждый будет уверен, что имел в виду правильное. Аналитик переводит «безопасно» в проверяемые пункты: что шифруем, какие данные считаем персональными, кто имеет к ним доступ, что нельзя писать в логи, где проверяем ввод.
Важно сразу развести две темы, которые путают. Есть доступ — кто ты и что тебе можно; это аутентификация и авторизация, про них отдельная запись про OAuth2 и JWT. А есть защита самих данных — чтобы даже тот, кто как-то добрался до них, не смог ими воспользоваться, и чтобы они не утекли по дороге. Эта запись — про вторую тему. Безопасность данных — типичное нефункциональное требование: пользователь его не видит как фичу, но его отсутствие однажды стоит компании репутации и штрафа.
Шифрование: в передаче и в покое
Данные уязвимы в двух состояниях, и защищают их по-разному.
В передаче (in transit) — когда данные едут по сети между браузером и сервером или между сервисами. Здесь работает TLS — тот самый протокол, из-за которого в адресе https, а не http. Без него данные идут открытым текстом, и любой на пути (Wi-Fi в кафе, провайдер) может их прочитать. Правило простое и без исключений: любые данные по сети — только по HTTPS. Это не предмет обсуждения в 2020-х, это база. Отдельный острый случай — что можно и что нельзя отправлять во внешнюю модель: про это в записи про ИИ и LLM.
В покое (at rest) — когда данные лежат на диске: в базе, в бэкапах, в файлах. Если диск украдут или сольют дамп базы, шифрование в покое не даст прочитать содержимое без ключа. Особенно это касается чувствительных полей — паролей (которые вообще не хранят в открытом виде, а только в виде необратимого хэша), паспортов, карт.
Как формулировать в спеке
Не пишите «данные защищены». Пишите конкретно: «передача — только по TLS 1.2+», «пароли хранятся в виде хэша (bcrypt/argon2), а не в открытом виде», «поле „паспорт“ шифруется в базе». Такие формулировки проверяемы: тестировщик может убедиться, что http отвергается, а в дампе базы нет открытых паролей. Проверяемое требование — единственное настоящее требование.
PII: что это и почему это риск
PII (Personally Identifiable Information), по-русски — персональные данные, это любая информация, по которой можно опознать конкретного человека. ФИО, телефон, e-mail, адрес, паспорт, СНИЛС, номер карты, иногда даже IP и геолокация. Отдельно ФИО — это персональные данные; ФИО рядом с диагнозом или зарплатой — это уже чувствительные данные, и риск выше.
Почему это не просто «приватность», а юридический риск. Государство регулирует обращение с персональными данными законами, и за нарушение штрафуют. В России это 152-ФЗ «О персональных данных»: он требует согласия на обработку, хранения данных россиян на серверах в РФ, мер защиты. В Евросоюзе — GDPR, и его штрафы исчисляются процентами от мирового оборота компании. Если ваш продукт собирает персональные данные, требования этих законов — не «юристы потом разберутся», а вход в постановку задачи.
Это касается аналитика напрямую
Когда вы проектируете форму регистрации или таблицу в базе и добавляете поле «дата рождения» или «адрес», вы принимаете решение собирать персональные данные. С этого момента на продукт ложатся обязательства: согласие пользователя, защита, право удалить. Поэтому каждое поле с личной информацией — это не просто колонка, это юридическое обязательство, и добавлять его надо осознанно.
Минимизация и наименьшие привилегии
Два принципа, которые сокращают риск ещё до всякого шифрования.
Минимизация данных: не собирай то, что тебе не нужно. Самые защищённые данные — те, которых у вас нет. Если для услуги не нужен паспорт — не просите паспорт. Каждое лишнее поле — это то, что можно потерять, что нужно защищать и за что можно получить штраф. На ревью формы полезно спрашивать по каждому полю: «зачем оно нам и что сломается, если его убрать?».
Наименьшие привилегии (least privilege): у каждого человека и каждого сервиса — доступ только к тому, что нужно для его работы, и не граммом больше. Оператору поддержки не нужен доступ ко всем картам клиентов; сервису отправки писем нужен e-mail, но не паспорт. Чем уже доступ, тем меньше украдут, если учётку взломают или сотрудник окажется недобросовестным.
Маскирование в логах
Логи — недооценённая дыра. Их пишут для отладки, читают многие, хранят долго и часто складывают в отдельную систему (см. наблюдаемость). И именно туда по недосмотру утекают самые чувствительные данные.
Правило: пароли, номера карт, токены и коды в логи не пишут никогда. Остальные персональные данные — маскируют или обезличивают: вместо +79161234567 в лог идёт +7916***4567, вместо полного e-mail — a***@mail.ru. Этого достаточно, чтобы по логу найти проблему, но недостаточно, чтобы по утёкшему логу навредить человеку. В спеке на любой обработчик чувствительных данных полезно прямо писать строку «в логи попадает то-то, маскируется то-то» — именно её отсутствие стоило нам тех полугода с картами.
Валидация на сервере: клиенту верить нельзя
Золотое правило безопасности: весь ввод проверяется на сервере, всегда. Проверки в браузере (подсветка «неверный e-mail», ограничение длины) — это удобство для пользователя, а не защита. Почему — подробно в записи про клиенты и браузеры: код на клиенте полностью под контролем пользователя, его можно обойти, подменить запрос напрямую, отправить что угодно мимо вашей формы.
Поэтому всё, что пришло от клиента, сервер считает потенциально враждебным, пока не проверил: тип, длину, диапазон, формат, права на эту операцию. Атаки вроде SQL-инъекций и XSS живут ровно там, где серверу скормили непроверенный ввод и он его доверчиво выполнил. Для аналитика это значит: правила валидации (что допустимо в поле, что отвергаем, какую ошибку возвращаем) — это требования, и описывать их — ваша работа, а не «бэк сам разберётся».
Класс данных → как защищаем
| Класс данных | Примеры | Как защищаем |
|---|---|---|
| Секреты | Пароли, токены, ключи | Пароль — только хэш; в логи никогда; в ответах API не отдаём |
| Чувствительные PII | Паспорт, карта, СНИЛС | Шифрование в покое, маскирование в логах, минимум доступа |
| Обычные PII | ФИО, телефон, e-mail, адрес | TLS в передаче, согласие на обработку, маскирование в логах |
| Внутренние данные | id заказа, статусы | TLS, доступ по авторизации |
| Публичные данные | Каталог, цены | Защита не требуется, но валидация ввода — всё равно да |
Эта таблица — рабочий чек-лист для спеки. Когда вы проектируете новое поле или эндпоинт, найдите его строку и перенесите меры защиты прямо в требования. Так «сделайте безопасно» превращается в конкретные, проверяемые пункты, по которым тестировщик сможет вас проверить, а разработчик — не угадывать.
Откуда это взялось
Долгое время к персональным данным относились беспечно — собирали всё подряд «на всякий случай». Перелом во многом задал GDPR, вступивший в силу в Евросоюзе в 2018 году: он ввёл согласие на обработку, право быть забытым и штрафы до 4% мирового оборота — после этого защита данных перестала быть необязательной. В России похожую роль играет 152-ФЗ «О персональных данных» (действует с 2006 года, с тех пор не раз ужесточался, включая требование хранить данные россиян в РФ). А практическим чек-листом по защите приложений много лет служит OWASP Top-10 — регулярно обновляемый список самых частых уязвимостей веб-приложений; держать его рядом при постановке требований к безопасности — хорошая привычка аналитика.
Частые вопросы
Что такое PII простыми словами?
PII (персональные данные) — это любая информация, по которой можно опознать конкретного человека: ФИО, телефон, e-mail, адрес, паспорт, СНИЛС, номер карты, иногда IP и геолокация. Как только продукт начинает собирать такие данные, на компанию ложатся юридические обязательства по законам о персональных данных (152-ФЗ в России, GDPR в Европе): согласие на обработку, защита, право удалить. Поэтому каждое поле с личной информацией стоит добавлять осознанно.
Чем безопасность данных отличается от авторизации?
Авторизация — это про доступ: кто ты и что тебе можно (см. запись про OAuth2 и JWT). Безопасность данных — про защиту самой информации, чтобы даже добравшийся до неё не смог навредить и чтобы она не утекла по дороге: шифрование в передаче (TLS) и в покое, маскирование в логах, минимизация сбора. Это разные слои: можно правильно настроить доступы и всё равно слить базу, если данные в ней лежат открытым текстом, а пароли — без хэширования.
Почему нельзя доверять проверкам на стороне клиента?
Потому что код в браузере полностью под контролем пользователя: его можно изменить, обойти или отправить запрос на сервер напрямую, минуя вашу форму. Проверки на клиенте (подсветка ошибок, ограничение длины) нужны для удобства, но не для защиты. Сервер обязан перепроверять весь ввод сам: тип, длину, формат, права. Именно на непроверенном вводе живут атаки вроде SQL-инъекций и XSS. Правила валидации — это требования, которые описывает аналитик.