ФЗ‑152 на практике: как выбирать серверы и инфраструктуру, чтобы выдержать аудит Роскомнадзора и ФСТЭК
После ужесточения требований ФЗ‑152, 242‑ФЗ и новых поправок по локализации персональных данных выбор серверов перестал быть задачей «где дешевле больше ядер». Теперь ключевой вопрос звучит так: «Эти машины через три года смогут спокойно пройти совместную проверку Роскомнадзора и ФСТЭК?».
Ключевая мысль: безопасный выбор железа под ФЗ‑152 — это не только локализация данных в РФ, но и способность доказать на уровне «железо + ЦОД + логи», что персональные данные обрабатываются в контролируемой среде и могут быть полностью проаудированы.
1. Что ФЗ‑152 реально требует от серверов: переводим правовые нормы на язык ИТ
Нормативка (ФЗ‑152, 242‑ФЗ, постановление №1119, приказ ФСТЭК №21 и сопутствующие акты) написана юридическим языком, но на уровне серверов и ЦОД всё сводится к трём практическим вопросам: где физически лежат данные, как защищена инфраструктура и кто за что отвечает.
1.1. Локализация персональных данных: «не просто в России, а весь контур в России»
Базовое требование ФЗ‑152 и 242‑ФЗ — все операции с персональными данными российских граждан (сбор, запись, систематизация, накопление, хранение, уточнение, извлечение) должны выполняться на базе данных, расположенных в Российской Федерации.
- Нельзя строить схему «сначала принимаем данные на зарубежный сервер/облако, потом реплицируем в РФ». Первичный контур сбора и основной обработки обязан физически находиться в российском ЦОД.
- Для серверного железа это означает, что все узлы, на которых лежат и обрабатываются персональные данные, должны быть установлены в дата‑центрах на территории РФ, с документально подтверждённым адресом и юрисдикцией.
1.2. Уровень защищённости ИСПД и требования к ЦОД
Информационные системы персональных данных (ИСПД) классифицируются по уровням защищённости согласно постановлению №1119, а набор технических мер защиты определяется, в частности, приказом ФСТЭК №21.
- Если вы размещаете серверы в стороннем ЦОД или облаке, сам дата‑центр должен соответствовать требованиям по физической безопасности, инженерной инфраструктуре и каналам связи для нужного уровня ИСПД.
- На практике это означает: наличие у провайдера подтверждённых сертификатов/заключений ФСТЭК/ФСБ или независимой оценки, плюс готовность предоставить формализованное описание применяемых мер защиты.
1.3. Аудит, Revizor и разделение ответственности
Роскомнадзор уже давно использует автоматизированные инструменты контроля (включая системы наподобие «Ревизор») для проверки того, где реально находится ваш сервер, какие IP‑адреса задействованы и по каким маршрутам идут запросы с персональными данными.
- Ответственность делится между оператором персональных данных (ваша компания) и обработчиком (ЦОД/облако): ЦОД отвечает за физический периметр и базовую сеть, вы — за серверы, ОС, приложения, настройки, журналы и внутренний контроль доступа.
- Поэтому мало просто «стоял в российском ЦОД»: вам нужно уметь показать, какие конкретно серверы обрабатывают персональные данные, как к ним ограничен доступ и какие аудиторские следы вы ведёте.
Практический вывод: базовый критерий соответствия — это возможность доказать, что «серверы + СХД + сеть, обслуживающие персональные данные, физически находятся в РФ, контролируются вами и описаны в документации так, чтобы любое изменение было прозрачно».
2. Как выбирать ЦОД и форм‑фактор серверов, чтобы не заложить «врождённый» риск
На уровне архитектуры проще сразу исключить варианты, которые с высокой вероятностью принесут проблемы на стадии аудита: «пограничные» облака, полностью облачные контрол‑плейны, неконтролируемое смешение контуров.
2.1. Деплой: российский ЦОД + понятная юридическая связка по ФЗ‑152
- Выбирайте дата‑центр с понятным юридическим статусом: площадка должна физически находиться в РФ, предоставляться российским юрлицом и иметь оформленные документы по ФЗ‑152 и смежным требованиям.
- Запрашивайте у провайдера: фактический адрес площадки, уровень TIER, перечень сертификатов, номера заключений ФСТЭК/ФСБ при наличии, краткое описание архитектуры защитных мер по ИСПД.
- В договоре и приложениях формализуйте: ваши серверы, обрабатывающие персональные данные, размещаются только в конкретных российских ЦОД; оператор не имеет права переносить ВМ/контейнеры с ПДн на зарубежные площадки или в сегменты, не описанные в документации.
2.2. Форм‑фактор и тип серверов: «управляемое» железо вместо чёрных ящиков
С точки зрения ФЗ‑152 у вас проблем больше всего там, где вы не можете объяснить, как именно работает железо и как контролируются его обновления и удалённый доступ.
- Отдавайте предпочтение стандартным серверным платформам (Supermicro, Dell, HPE, Lenovo, Huawei, xFusion и др.), где BIOS, BMC, микрокод и сетевые адаптеры документированы и поддерживают аудит, а не полностью закрытым «чёрным ящикам».
- Избегайте решений, которые завязаны на обязательный внешний облачный контрол‑плейн: если железо не работает без постоянного выхода к зарубежному управлению, вы не сможете убедительно доказать, что административный трафик и телеметрия не пересекают границу.
- Убедитесь, что производитель допускает локальное администрирование, локальные образы прошивок и умеет работать в полностью изолированном от внешнего интернета контуре.
2.3. Стратегия хранения: разделять персональные данные и прочие данные
- Для томов, на которых находятся персональные данные, закладывайте физическое или логическое разделение: отдельные массивы/пулы, отдельные RAID‑группы, приоритетное шифрование средствами, совместимыми с требованиями ФСТЭК.
- Логи, мониторинг и аналитика: храните полные неанонимизированные журналы и события внутри РФ, а за рубеж по возможности отправляйте только агрегированную и обезличенную информацию.
- Важно явно прописывать в политике резервного копирования: бэкапы с персональными данными не покидают российские площадки, включая автоматические off‑site сценарии.
3. Аудируемость железа: как с этапа закупки строить цепочку «можем показать и доказать»
Многие компании ограничиваются тем, что «формально соответствуют ФЗ‑152», но не думают о том, как потом покажут проверяющим, на каких именно серверах что крутится и как это контролируется. Ниже — как заложить аудируемость сразу.
3.1. Трассируемые метаданные: от закупки до ИСПД‑документации
- При закупке серверов, СХД и сетевого оборудования фиксируйте: серийные номера, модели, MAC‑адреса, заводские данные, номера стоек и шкафов, с привязкой к конкретным площадкам ЦОД.
- Заносите эту информацию в CMDB или систему учёта активов и связывайте с логической архитектурой ИСПД: какие классы персональных данных на каких физических машинах обрабатываются.
- В проектной документации делайте понятную карту соответствия: «подсистема ИСПД уровня X → вот эти серверы → вот такая стойка/зал → вот эти серийные номера», чтобы на проверке не собирать схему по крупицам.
3.2. BMC и прошивки: не допустить «невидимого» удалённого доступа
- На уровне выбора железа убедитесь, что BMC (iDRAC, iLO, IPMI и аналоги) поддерживает локальное управление, экспорт логов и тонкую настройку доступа, а не требует облачного аккаунта и постоянного внешнего соединения.
- В политиках эксплуатации зафиксируйте: обновление прошивок и микрокода выполняется по утверждённому регламенту, с журналированием и возможностью отката, а не через «автообновление из интернета».
- Доступ к BMC и консолям администрирования должен быть заведён через ограниченные административные сегменты (VPN, бастион‑хосты), где каждый вход и операция фиксируются в логах.
3.3. Системный и сетевой аудит: железо должно помогать, а не мешать
- Серверные платформы должны поддерживать стандартные механизмы журналирования (syslog, SNMP, агентский сбор метрик), чтобы события безопасности и отказов без «костылей» уходили в SIEM и систему мониторинга.
- Количество и функциональность сетевых интерфейсов должны позволять изолировать контур ИСПД (отдельные VLAN, ACL, QoS) от обычного офисного и внешнего трафика и при необходимости детально логировать выходы в интернет.
- Важный критерий: вы должны иметь возможность на понятном языке ответить на три вопроса — «где хранятся данные?», «кто и как имеет к ним доступ?», «какие журналы доказывают, что контроль реально работает?».
Если на этапе выбора железа вы добавите к техническим критериям три требования — трассируемость метаданных, управляемый BMC без внешнего облака и полноценную поддержку журналирования, вы заранее экономите недели работы при любом аудите.
4. Типичные ошибки в инфраструктуре под ФЗ‑152 и как их избежать ещё на этапе ТЗ
Ниже — не теория, а реальные причины, по которым компании получают предписания или вынуждены срочно перестраивать инфраструктуру. Их проще предотвратить, чем потом объяснять проверяющим.
Ошибка 1: считать зарубежное облако с «российским регионом» автоматически соответствующим ФЗ‑152
Наличие «регионов в РФ» у иностранного провайдера не означает, что контрол‑плейн, бэкапы, журналы и служебная телеметрия не выходят за пределы России. Для ФЗ‑152 это критическое различие.
- При выборе облачного провайдера уточняйте отдельно: где физически находятся контрол‑плейн, системы резервного копирования, журналы и мониторинг; есть ли автоматические сценарии экспорта данных в зарубежные регионы.
- Включайте в договор запрет на хранение и обработку ПДн вне РФ, а также обязательство провайдера уведомлять о любых изменениях архитектуры, затрагивающих локализацию.
Ошибка 2: использовать один и тот же массив/СХД для контуров с ПДн и без
Когда один и тот же СХД или пул дисков обслуживает и ИСПД под ФЗ‑152, и другие нагрузки, вам сложнее доказать чёткие границы и контролировать, куда уходят бэкапы, клоны и снимки.
- Планируйте отдельные пулы/кластеры хранения для ИСПД, как минимум с отдельными политиками доступа и резервного копирования; лучше — с физическим разделением или выделенными контроллерами.
- Жёстко фиксируйте, какие тома и бэкапы могут выходить за пределы площадки или страны, и технически блокируйте сценарии, при которых копия ПДн случайно уезжает на зарубежный ресурс.
Ошибка 3: не прописать требования по аудируемости в ТЗ и RFP
Без явных требований по журналированию, BMC, API и форматам логов вы рискуете получить железо, с которым невозможно построить нормальный аудит: логи бедные, BMC завязан на облако, интеграции нет.
- Включайте в ТЗ: обязательную поддержку syslog/SNMP/API‑доступа к событиям, наличие собственных журналов BMC, управление учётными записями и ролями, локальные пакеты прошивок и обновлений.
- Для сетевого оборудования — возможность выделять отдельные сегменты для ИСПД, зеркалировать трафик на системы анализа, ограничивать и логировать весь исходящий трафик в интернет с серверов ИСПД.
5. Итоговая формула: «локализовано, контролируемо, аудируемо» + что делать дальше
Если свести все требования ФЗ‑152, 242‑ФЗ и подзаконных актов для серверов в одну формулу, она будет звучать так: физически в России, технически под контролем, документально привязано к бизнес‑процессам и ИСПД.
Правильный стандарт выбора серверов под ФЗ‑152 — это не «максимум ядер и памяти», а «железо, для которого вы можете показать: оно находится в РФ, управляется по понятным регламентам, его журналы и метаданные позволяют проверить каждое действие с персональными данными».
Если вы планируете обновление серверного парка, перенос в новый ЦОД или запуск ИСПД под ФЗ‑152, имеет смысл сначала сформулировать требования к локализации, аудиту и управляемости на уровне железа, а уже потом переходить к выбору конкретных моделей и брендов.
Нужна архитектура под ФЗ‑152 и локализацию персональных данных?
Опишите кратко ваши системы, объём персональных данных и текущую инфраструктуру — по этим вводным можно предложить 1–2 варианта архитектуры (серверы, СХД, сети и ЦОД в РФ), которые учитывают ФЗ‑152, локализацию и требования по аудиту на уровне железа и логов.
Заполнить форму и получить предложение по архитектуре
