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