Защита персональных данных 152: облако против своего сервера

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

На этом месте бизнес обычно выбирает между двумя сценариями. Первый — аттестованное облако, где провайдер уже закрыл значительную часть инфраструктурных вопросов. Второй — собственный сервер, который выглядит как символ контроля, пока не выясняется, что вместе с ним компания получила физическую охрану ЦОД, СЗИ, резервирование, аттестацию и отдельный фронт работ для ИБ-специалиста.

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

Что именно требует 152-ФЗ

Федеральный закон № 152-ФЗ, с учётом изменений, связанных с локализацией, требует первичного сбора и хранения персональных данных граждан РФ на серверах, физически расположенных в России. Это базовая точка, но не вся система требований.

Компания, обрабатывающая персональные данные, остаётся оператором. Она определяет цели обработки, состав данных, сроки хранения и правила доступа. Она же отвечает за прикладную систему: сайт, мобильное приложение, CRM, личный кабинет, интеграции с платёжными и маркетинговыми сервисами.

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

Для ИСПДн необходимо определить уровень защищённости — от УЗ-1 до УЗ-4. На него влияют:

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

Технические и организационные меры защиты регулируются, в частности, Постановлением Правительства № 1119 и Приказом ФСТЭК России № 21. Поэтому разговор «облако дешевле сервера» без определения уровня УЗ — примерно такой же полезный, как выбор автомобиля по цвету кузова без понимания, нужно ли перевозить пассажиров или бетон.

Облако: быстрый старт без покупки собственного ЦОДа

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

Это особенно заметно при запуске нового сервиса. Компании не нужно самостоятельно покупать серверное оборудование, проектировать отказоустойчивую площадку, организовывать физическую охрану помещения и проходить весь путь аттестации с нуля. Вместо капитального проекта появляется договор на облачную инфраструктуру и набор документов, которые нужно внимательно прочитать, а не отправить юристу с пометкой «посмотри, вроде нормально».

В модели облака расходы в основном переходят из CAPEX в OPEX:

• не нужно сразу инвестировать крупную сумму в серверы, сетевое оборудование и СЗИ;
• вычислительные ресурсы можно масштабировать по мере роста нагрузки;
• часть расходов на эксплуатацию и обновление инфраструктуры уже заложена в тариф;
• запуск обычно быстрее, чем строительство собственного защищённого контура;
• проще подключить дополнительные мощности для резервного копирования и отказоустойчивости.

Но облако не превращает компанию в пассажира без билета. Оно закрывает инфраструктурную часть, а не всю ответственность оператора.

Прикладной уровень остаётся у заказчика. Если разработчики выкатили API без авторизации, оставили тестовую базу доступной из интернета или выдали сотрудникам административные права «на всякий случай», аттестат облачной площадки не станет магическим щитом. Провайдер отвечает за свою зону. Компания — за свою.

Аттестованное облако снимает с бизнеса часть инфраструктурной работы, но не снимает ответственность за приложение, доступы и внутренние процессы.

Где облако действительно экономит время

Скорость внедрения важна не только стартапам. Даже зрелая компания может столкнуться с проектом, который нужно запустить в сжатые сроки: новый личный кабинет, региональный сервис, медицинская платформа, внутренняя кадровая система или мобильное приложение с авторизацией.

В собственном контуре часть времени уйдёт на закупку оборудования, согласование архитектуры, подготовку помещения, настройку средств защиты и взаимодействие с подрядчиками. В облаке базовая инфраструктура уже существует. Это не означает, что проект запускается одной кнопкой, но количество строительных блоков заметно сокращается.

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

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

Собственный сервер: контроль без скидки на сложность

Собственный сервер выбирают не только из-за недоверия к облакам. У такого подхода есть рациональные основания.

Компания получает больше контроля над архитектурой, размещением оборудования, сетевыми маршрутами и внутренними процедурами. Можно построить изолированный контур, адаптировать систему под нестандартные требования и не зависеть от изменений тарифов или ограничений конкретного провайдера.

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

Но «свой сервер» — это не один сервер в шкафу. Для выполнения требований 152-ФЗ понадобится полноценная защищённая инфраструктура:

• оборудование с подходящими характеристиками и резервированием;
• физическая охрана и контроль доступа к серверному помещению;
• сетевое разделение и защита периметра;
• сертифицированные средства защиты информации, если они требуются для выбранной архитектуры и уровня УЗ;
• резервное копирование и сценарии восстановления;
• журналирование событий и контроль действий пользователей;
• управление учётными записями и привилегиями;
• документация по системе;
• оценка угроз и модель нарушителя;
• аттестация ИСПДн;
• регулярное сопровождение и подтверждение работоспособности мер защиты.

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

Когда собственный контур имеет смысл

Собственная инфраструктура оправдана, если у компании уже есть зрелая ИТ- и ИБ-функция. Не один системный администратор, который одновременно чинит Wi-Fi, продлевает домены и хранит пароль от резервной копии в заметках телефона, а команда с распределёнными ролями и понятными регламентами.

Также важны устойчивые нагрузки и специфические требования к архитектуре. Если система работает с большим объёмом данных, нуждается в нестандартной изоляции или интегрирована с внутренними контурами, облачная модель может потребовать сложной гибридной схемы. В отдельных случаях это съедает преимущество простого старта.

Но наличие бюджета само по себе не делает собственный сервер хорошим выбором. Если компания не готова содержать компетентную команду и регулярно инвестировать в защиту, облако часто оказывается более управляемым вариантом. Контроль без процессов — это не контроль. Это дорогая иллюзия, которая обычно заканчивается после первого инцидента.

Облако против своего сервера: где лежит реальная разница

Сравнивать варианты нужно не по принципу «аренда против собственности», а по распределению работ и рисков. Ниже — практическая матрица для первичного выбора.

Из таблицы видно главное: облако не сравнивается с сервером как «лёгкий» и «тяжёлый» вариант. Это две разные модели управления. В первой часть инфраструктурной ответственности передают внешнему поставщику. Во второй компания принимает её на себя вместе с затратами и необходимыми компетенциями.

Сколько стоит соответствие требованиям

Точная стоимость собственного контура зависит от уровня защищённости, категории данных, масштаба системы, количества пользователей, требований к отказоустойчивости и уже имеющейся инфраструктуры. Универсального прайса здесь нет. Диапазон может быть от сотен тысяч до десятков миллионов рублей, если речь идёт о сложном контуре с серьёзными требованиями к СЗИ, резервированию и аттестации.

Поэтому сравнивать тариф облака с ценой одного сервера некорректно. В расчёт нужно включать полный жизненный цикл.

Для облака это обычно:

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

Для собственного сервера список шире:

• закупка серверов, систем хранения и сетевого оборудования;
• лицензии и сертифицированные СЗИ;
• аренда или содержание помещения;
• физическая охрана и контроль доступа;
• электропитание и резервирование;
• охлаждение;
• мониторинг;
• резервные площадки;
• зарплаты администраторов и специалистов по ИБ;
• аудит и аттестация;
• обновление оборудования;
• восстановление после сбоев;
• утилизация и замена компонентов.

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

CAPEX против OPEX — не бухгалтерская игра

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

Собственный сервер требует заранее вложиться в инфраструктуру, даже если проект ещё не доказал свою нагрузку или бизнес-модель. Облако позволяет начинать с меньшего объёма ресурсов и наращивать его по фактической потребности. Для новых продуктов это снижает риск переплатить за оборудование, которое будет простаивать.

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

Главная ловушка: разделённая ответственность

Ключевой риск облачной модели — ошибочно считать, что провайдер защищает всё. Он защищает собственную инфраструктуру в пределах заявленной зоны. Клиент отвечает за то, как настроил и использует сервис.

К типичным клиентским ошибкам относятся:

1. Слишком широкие права доступа.

Администратор базы, разработчик и оператор поддержки получают один и тот же уровень полномочий. При увольнении или компрометации учётной записи доступ не закрывается вовремя.

2. Отсутствие сегментации.

Тестовая среда соединена с промышленной, а резервная копия доступна из того же контура. Один скомпрометированный компонент открывает дорогу к нескольким системам.

3. Открытые хранилища и панели управления.

Объектное хранилище, служебный API или административный интерфейс публикуются в интернет без необходимости. Дальше начинается поиск виноватого между DevOps, безопасностью и человеком, который нажал «разрешить всем».

4. Слабый контроль интеграций.

Персональные данные передаются внешнему сервису аналитики, рассылок или поддержки, но договоры, маршруты и права доступа никто не пересмотрел.

5. Непроверенное резервное копирование.

Копии создаются, но восстановление не тестируется. В день инцидента выясняется, что резервная база либо повреждена, либо содержит данные месячной давности.

6. Формальная двухфакторная аутентификация.

2FA включена для одного администратора, а сервисные учётные записи и старые аккаунты продолжают жить без дополнительной защиты.

7. Отсутствие внутреннего регламента.

Технические меры есть, но непонятно, кто выдаёт доступ, кто его отзывает, кто анализирует журналы и кто докладывает об инциденте.

В собственном контуре эти ошибки никуда не исчезают. К ним добавляются ошибки физической и сетевой инфраструктуры. Поэтому спор «облако безопаснее» или «свой сервер безопаснее» без анализа процессов остаётся спором о вкусе. Защищает не форма владения сервером, а архитектура, настройки и дисциплина эксплуатации.

Самая дорогая часть 152-ФЗ — не диск и не процессор. Это уверенность, что ответственность где-то рядом, но точно не у вашей команды.

Что проверять у облачного провайдера

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

У провайдера стоит запросить и сопоставить с проектом:

• область действия аттестации;
• доступные уровни защищённости УЗ-1–УЗ-4;
• физическое расположение площадок;
• порядок резервирования и восстановления;
• модель разграничения ответственности;
• перечень средств защиты на инфраструктурном уровне;
• правила управления доступом сотрудников провайдера;
• порядок регистрации и хранения событий безопасности;
• условия уведомления об инцидентах;
• правила удаления или возврата данных после завершения договора;
• возможность выгрузить данные в переносимом формате;
• порядок миграции при отказе от услуг;
• состав документов, которые можно использовать во внутреннем аудите.

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

Следует также проверить, какие сервисы входят в защищённый контур. Аттестованная виртуальная инфраструктура не означает автоматически, что все дополнительные продукты провайдера имеют тот же статус. Управляемая база данных, балансировщик, система логирования и сервис резервных копий могут подпадать под разные условия.

Что нужно подготовить для собственного сервера

Собственный сервер требует не только бюджета, но и проекта. Начинать с покупки оборудования нельзя. Сначала описывают систему и данные, затем определяют угрозы, уровень защищённости и набор мер.

Рабочая последовательность выглядит так:

1. Инвентаризация данных.

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

2. Описание бизнес-процессов.

Данные редко живут в одной системе. Они перемещаются между сайтом, CRM, мобильным приложением, кадровым контуром, службой поддержки и внешними API.

3. Определение уровня защищённости.

УЗ выбирают не по желанию владельца проекта, а с учётом категории данных, их объёма и актуальных угроз.

4. Проектирование архитектуры.

Определяются сетевые зоны, точки доступа, механизмы идентификации, резервирование и правила взаимодействия между компонентами.

5. Подбор СЗИ и организационных мер.

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

6. Аттестация и документирование.

Рабочая система должна соответствовать заявленным требованиям не только на схеме, но и в реальной эксплуатации.

7. Постоянный контроль.

После запуска продолжаются обновления, изменения состава пользователей, новые интеграции и новые угрозы. Аттестация не превращает систему в вечный памятник безопасности.

На практике самый сложный этап — не установка оборудования. Сложнее заставить бизнес-процессы не обходить защиту ради удобства. Пользователь хочет быстро выгрузить таблицу, менеджеру нужен доступ к клиентской базе, разработчику — копия продакшена, а службе поддержки — возможность видеть всё. Если этот сценарий не спроектировать заранее, сотрудники начнут собирать костыли. И обычно такие костыли имеют общий доступ и пароль в корпоративном чате.

Как выбрать между двумя моделями

Решение зависит от нескольких параметров. Удобнее всего рассматривать их в порядке влияния на проект.

Срок запуска

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

Собственный сервер имеет смысл, если сроки позволяют пройти закупку, проектирование и аттестацию без попытки превратить ИБ в ночную смену перед релизом.

Нагрузка и рост

Для переменной нагрузки облачная модель удобнее. Ресурсы можно увеличивать по мере роста продукта, не покупая оборудование заранее.

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

Внутренняя экспертиза

Если в компании нет специалистов, отвечающих за ИБ и эксплуатацию защищённого контура, собственный сервер создаст дефицит компетенций. Подрядчик может закрыть часть задач, но ответственность оператора всё равно не исчезнет.

Облако сокращает объём инфраструктурной работы, но не отменяет экспертизу в приложении, доступах, данных и документации.

Требования к изоляции

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

Финансовый горизонт

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

Собственный сервер нельзя оценивать только по цене закупки. Облако нельзя оценивать только по месячному тарифу.

Что изменилось в цене ошибки

С 30 мая 2025 года в России вступили в силу поправки в КоАП, усилившие ответственность за нарушения при работе с персональными данными и утечки информации. В числе последствий — оборотные штрафы до 3% годовой выручки, а в отдельных случаях сумма может достигать 500 млн рублей.

Это меняет подход к выбору инфраструктуры. Раньше компания могла воспринимать соответствие 152-ФЗ как проект для юристов и ИТ-отдела. Теперь недостаточно формально разместить базу в российском дата-центре и положить в папку несколько приказов. Нужно понимать, как устроена реальная защита и кто контролирует её состояние.

При этом штрафной риск не означает, что всем нужно срочно переносить данные в облако. Он означает другое: инфраструктурное решение нельзя принимать без анализа ответственности. Аттестованное облако уменьшает объём задач на стороне компании, но не закрывает прикладные ошибки. Собственный сервер даёт контроль, но требует доказать, что этот контроль существует не только в презентации проекта.

Итог: аренда инфраструктуры или собственная система

Для большинства компаний, которым нужно быстро запустить сервис и выполнить требования 152-ФЗ без строительства собственной ИБ-функции, аттестованное облако выглядит практичнее. Оно сокращает стартовые затраты, ускоряет развёртывание и передаёт провайдеру значительную часть инфраструктурной нагрузки.

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

Финальный выбор нужно делать после инвентаризации данных, определения уровня УЗ, расчёта совокупной стоимости и фиксации матрицы ответственности. Если провайдер не может понятно объяснить, что именно он защищает, облако выбирать рано. Если собственная команда не может ответить, кто отзовёт доступ у уволенного администратора и как восстановится база после сбоя, сервер покупать тоже рано.

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