Сколько стоит соответствие 152-ФЗ для небольшой компании

MAATRIX

Рано или поздно небольшая компания, которая собирает данные клиентов или сотрудников — имя, телефон, почту, паспортные данные, историю заказов — упирается в вопрос: «А мы вообще нормально работаем по 152-ФЗ, и сколько это будет стоить?». Закон описывает требования словами, а не сметой, поэтому перевести их в конкретные статьи расхода на инфраструктуру самостоятельно тяжело. Дальше — не юридическая консультация, а инженерный взгляд на типичные затраты на техническую часть: сервер, шифрование, бэкапы, доступы, аудит. > Важная оговорка. Это обзорный технический материал о том, как обычно выглядит и во что обходится инфраструктурная сторона соответствия закону о персональных данных. Он не заменяет юридическую консультацию и не покрывает всю процедуру целиком — модель угроз, согласия на обработку, уведомление регулятора, назначение ответственного за обработку персональных данных и прочие организационно-правовые шаги здесь не разбираются. Для конкретного вывода о том, что нужно именно вашей компании, обратитесь к юристу или специалисту по защите персональных данных.

Что входит в техническую часть, а что нет

152-ФЗ — это закон в первую очередь про процедуры и ответственность, а не про конфигурацию серверов. Юридическая часть соответствия обычно включает: модель угроз и уровень защищённости информационной системы персональных данных, согласия субъектов на обработку, политику обработки персональных данных, приказ о назначении ответственного, при необходимости — уведомление Роскомнадзора. Это работа юриста или специалиста по защите данных, и её стоимость сильно зависит от объёма и категории данных, юрисдикции компании и того, нанимаете вы консультанта разово или на аутсорс постоянно — здесь она не оценивается.

Техническая часть — то, что можно спроектировать и настроить на уровне серверов, сетей и процессов — обычно сводится к пяти направлениям:

• физическое размещение сервера с персональными данными на территории России (требование локализации);
• шифрование каналов передачи и хранения данных;
• резервное копирование с учётом требований к защите информации;
• разграничение доступов к данным и логирование обращений;
• регулярный аудит безопасности.

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

Локализация: сервер с персональными данными в России

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

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

1. Полностью российская инфраструктура — весь стек (сайт, CRM, база данных) на сервере в РФ. Проще всего с точки зрения соответствия, но может не подходить, если у компании есть зарубежная аудитория или сервисы, которым нужны серверы за пределами страны.
2. Гибридная схема — фронтенд, вспомогательные сервисы или сервер для доступа к внешним API размещаются там, где удобно бизнесу, а именно база персональных данных — на выделенном сервере или VPS в России, с репликацией или синхронизацией только не персонифицированных данных наружу.
3. Первичный сбор в России, обработка аналитики — где угодно — данные собираются и первично сохраняются на российском сервере, а для отчётов и аналитики наружу выгружаются обезличенные агрегаты (без ФИО, телефонов, адресов).

Частая ошибка — думать, что localization требование выполнено, если «сайт вроде бы работает из России». Смотрят не на то, откуда открывается сайт, а на то, где физически лежит база с персональными данными и где стоит сервер, который её обрабатывает первым. Если форма обратной связи пишет данные сразу в CRM, физически размещённую за границей, требование не выполняется, даже если домен зарегистрирован в зоне .ru.

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

Шифрование каналов передачи и хранения данных

Здесь две независимые задачи: защита данных в момент передачи (транзит) и защита данных на диске (хранение). Обе решаются стандартными инструментами, без экзотики.

Шифрование транзита. Для веб-форм и API — обычный TLS-сертификат (Let's Encrypt через Caddy или Certbot закрывает почти все случаи бесплатно). Для соединений между внутренними сервисами (например, веб-сервер общается с базой данных на отдельной машине) — TLS для самой базы данных (PostgreSQL и MySQL это умеют «из коробки») либо туннель WireGuard/VPN между серверами, если сервисы физически разнесены.

# Пример: включить TLS для соединений с PostgreSQL
# в postgresql.conf
ssl = on
ssl_cert_file = '/etc/postgresql/certs/server.crt'
ssl_key_file = '/etc/postgresql/certs/server.key'

Шифрование хранения. Здесь два уровня:

• шифрование диска целиком (LUKS на Linux) — защищает от кражи физического диска или его образа, но не спасает, если сервер скомпрометирован и работает (диск расшифрован во время работы);
• шифрование на уровне приложения для отдельных чувствительных полей (например, паспортные данные шифруются перед записью в базу, а не хранятся открытым текстом) — сложнее в реализации, зато защищает и при компрометации доступа к самой базе.

# Быстрая проверка: зашифрован ли диск с данными
lsblk -f
# Раздел с типом crypto_LUKS означает, что шифрование на месте

Для небольшой компании обычно достаточного уровня защиты даёт связка «TLS везде + LUKS на разделе с базой данных», без полного шифрования на уровне приложения — это оправдано только для по-настоящему чувствительных полей (паспорт, СНИЛС, платёжные данные).

Резервное копирование с учётом требований к защите

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

Практическая схема для небольшой компании:

• резервные копии шифруются перед отправкой во внешнее хранилище (например, restic и borgbackup делают это «из коробки», ключ шифрования хранится отдельно от сервера);
• офсайт-копия (правило 3-2-1) располагается на отдельном сервере или VPS, тоже физически в России, а не просто «в облаке»;
• ретенция бэкапов ограничена разумным сроком хранения — хранить копии персональных данных бессрочно «на всякий случай» — это тоже отдельный риск с точки зрения принципа минимизации данных;
• доступ к самим файлам бэкапа так же разграничен, как и к продовой базе — скачать зашифрованный дамп с ключом от него в общем чате не редкость, и это сводит на нет весь смысл шифрования.

# Пример: restic с шифрованием, бэкап базы в отдельное хранилище
restic -r sftp:backup-user@backup-server:/data init
restic -r sftp:backup-user@backup-server:/data backup /var/lib/postgresql/data

Подробнее про саму настройку шифрованного бэкапа и частые ошибки — в отдельном разборе: как установить и настроить бэкап с шифрованием на VPS.

Разграничение доступа и логирование обращений к данным

Требование звучит просто: доступ к персональным данным должен быть у тех, кому он нужен по работе, и не больше. На практике это означает отказ от общего root-доступа и переход к именным учётным записям с ограниченными правами.

Базовый набор мер:

• у каждого сотрудника — свой SSH-ключ и своя учётная запись, а не общий пароль от root;
• доступ к базе данных разграничен по ролям (например, отдел поддержки видит имя и телефон клиента, но не платёжные реквизиты);
• команда sudo и обращения к чувствительным таблицам логируются — не для слежки за сотрудниками, а чтобы при инциденте можно было восстановить, кто и когда обращался к каким данным;
• уволенным сотрудникам доступ отзывается в тот же день, а не «когда руки дойдут».

# Пример: роль в PostgreSQL с доступом только на чтение к части таблиц
CREATE ROLE support_readonly LOGIN PASSWORD '...';
GRANT SELECT (name, phone) ON clients TO support_readonly;

# auditd: логировать обращения к конкретному файлу с базой
auditctl -w /var/lib/postgresql/data -p rwa -k pd_access

Разворачивание доступов без раздачи root команде и построение логирования по факту обращений — тема, которую стоит закрыть до аудита, а не во время него. Подробнее — в отдельной статье: как раздать доступ команде без выдачи root.

Регулярный аудит безопасности

Соответствие 152-ФЗ — не разовая настройка, а процесс: конфигурации меняются, появляются новые сотрудники и сервисы, находят новые уязвимости. Регулярный аудит — это способ убедиться, что то, что было настроено полгода назад, всё ещё работает так, как задумано.

Для небольшой компании разумная периодичность — раз в год как полноценная проверка (внешняя или внутренняя), плюс автоматизированные проверки чаще (раз в квартал или ежемесячно) с помощью инструментов вроде Lynis, которые проверяют базовую гигиену сервера: обновления, открытые порты, конфигурацию SSH, права на файлы.

# Быстрый автоматический аудит сервера с Lynis
sudo apt install lynis
sudo lynis audit system

Что обычно смотрят на аудите (внешнем или внутреннем): актуальность обновлений ОС и ПО, настройки firewall и список открытых портов, политику паролей и способ доступа по SSH, факт и качество логирования, шифрование при передаче и хранении, права доступа к файлам и базам данных. Подробный чек-лист подготовки разобран отдельно: как подготовить сервер к аудиту безопасности.

Разница между «сделали один раз и забыли» и «проверяем регулярно» в реальности и есть разница между формальным и рабочим соответствием — регулятор или партнёр, который придёт с проверкой через два года, будет смотреть на текущее состояние, а не на то, что было настроено при запуске проекта.

Сколько это стоит: сводная картина

Если собрать всё вместе, техническая часть соответствия 152-ФЗ для небольшой компании раскладывается на разовые затраты (в основном время на настройку) и постоянные (аренда серверов, место под данные, время на регулярные проверки). Ниже — сводная таблица без точных сумм, потому что они сильно зависят от объёма данных, числа сотрудников и от того, есть ли у компании штатный администратор или всё делается на аутсорсе.

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

Частые вопросы