Суверенное облако, локальный сервер или public cloud для городских данных

Почему выбор площадки для города — это решение о рисках, а не о технологиях

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

Практическое следствие: прежде чем сравнивать цену за виртуальную машину или «регионы в РФ», стоит зафиксировать класс каждой системы и связанные с ней обязанности. Тогда вопрос «суверенное облако, локальный сервер или public cloud» превращается из идеологического в инженерный: какая модель может доказать локализацию, управляемость и аудируемость конкретного контура.

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

Три модели и что они реально дают

Локальные серверы в собственном или арендованном муниципальном ЦОД дают максимум контроля над физическим размещением, доступом и журналами. Плата — за капитальные вложения, инженерную инфраструктуру, резервирование, кадры и время на обслуживание. Для небольшого города собственная площадка уровня, достаточного под ИСПД, часто оказывается дороже, чем кажется при смете на «железо».

Российское суверенное облако (провайдер с площадками в РФ и документированным контуром) сохраняет эластичность и переносит заботы о физической инфраструктуре на оператора. Однако «российская юрисдикция» сама по себе не гарантирует соответствия: нужно проверять, где расположены контрол-плейн, резервные копии, журналы и телеметрия, и фиксировать это в договоре.

Публичное облако — как иностранного, так и отечественного провайдера — сильнее всего в масштабировании и скорости. Для персональных данных оно уместно лишь при доказанной локализации первичных баз в РФ по 242-ФЗ и при явном договорном запрете на обработку и хранение таких данных за пределами России, включая резервное копирование.

• Локально: контроль максимален, стоимость владения и нагрузка на ИТ-команду высоки.
• Суверенное облако: баланс контроля и эластичности, но нужна проверка всего контура.
• Публичное облако: экономия и масштаб, применимо только к низкочувствительным данным.

Правовой контур: локализация, уровни ИСПД и критическая инфраструктура

Ключевое требование для города — локализация персональных данных. Согласно 242-ФЗ, базы данных, используемые для записи, систематизации, накопления и хранения персональных данных граждан России, должны физически находиться на серверах в РФ. Это требование о физическом расположении, а не о логической настройке: виртуальная машина на зарубежном оборудовании не соответствует ему, даже если настроена «под РФ» или зашифрована.

Дополнительно системы персональных данных (ИСПД) классифицируются по уровням защищённости согласно постановлению №1119, а состав технических мер определяется, в частности, приказом ФСТЭК №21. Если городская информационная система отнесена к объектам критической информационной инфраструктуры, добавляются обязанности по 187-ФЗ и взаимодействию с ГосСОПКА/НКЦКИ, что заметно влияет на выбор между облаком и собственным контуром.

Изложенное — общая ориентировка по законодательству РФ, а не юридическая консультация. Конкретные обязанности зависят от перечня обрабатываемых данных, категорирования и типа системы, поэтому перед тендером целесообразно получить заключение профильного юриста и аккредитованной организации по требованиям ФСТЭК/ФСБ.

• 242-ФЗ: первичные базы персональных данных граждан РФ — физически в РФ.
• Постановление №1119: уровень защищённости ИСПД определяет состав мер защиты.
• Приказ ФСТЭК №21 и 187-ФЗ/ГосСОПКА: актуальны при отнесении к критической инфраструктуре.

Критерии выбора: класс данных, критичность, масштаб и бюджет

Первый критерий — класс данных. Персональные данные, реестры и служебные сведения требуют размещения в РФ с полным контролем. Открытые данные, обезличенная статистика и публичные порталы могут размещаться в облаке без потери соответствия. Второй критерий — критичность сервиса: системы, отказ которых парализует работу города, нуждаются в резервировании и чёткой зоне ответственности, что часто склоняет чашу весов к суверенному облаку или локальному контуру.

Третий критерий — масштаб и динамика нагрузки. Для сезонных пиков (налоговые кампании, отчётные периоды, массовые онлайн-услуги) облако даёт эластичность, которую дорого обеспечивать собственными мощностями. Четвёртый — совокупная стоимость владения: сюда входят не только серверы, но и ЦОД, охлаждение, резервирование, лицензии, персонал и стоимость аудита. Небольшие объёмы часто дешевле в облаке, а устойчиво высокая и предсказуемая нагрузка — на собственных или арендованных серверах.

Полезно сравнивать сценарии на горизонте трёх-пяти лет и отдельно оценивать «стоимость перехода»: миграцию, обучение, изменение процессов и риск vendor lock-in у конкретного провайдера.

• Класс данных: чувствительные — локально/суверенно, открытые — в облако.
• Критичность: непрерывность важнее цены для сервисов, блокирующих работу города.
• Масштаб: эластичность облака против предсказуемости собственных мощностей.
• TCO на 3–5 лет плюс стоимость миграции и lock-in.

Гибрид как рабочий компромисс и типичные ошибки

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

Типичные ошибки: считать наличие «региона в РФ» у иностранного провайдера достаточным основанием (контрол-плейн, логи и резервные копии могут находиться за границей); смешивать контуры с персональными данными и без них на одном хранилище; и не прописывать в тендере требования к аудируемости — журналирование, API доступа к событиям, управляемые прошивки и BMC без внешнего облачного управления. Такие упущения обнаруживаются лишь на проверке, когда исправление стоит дорого.

Планируйте изменения как непрерывный процесс: локализация и защита ИСПД — это не разовая миграция, а поддержание архитектуры, договоров и документации в актуальном состоянии.

• Закрепите границы: отдельные пулы, политики бэкапов, запрет выноса копий.
• Проверяйте весь контур провайдера, а не только «регион в РФ».
• Пропишите аудируемость в ТЗ ещё до выбора вендора.

Как принять решение за четыре шага

Сначала составьте реестр систем и данных с пометкой класса и критичности. Затем классифицируйте каждую ИСПД по постановлению №1119 и определите, попадает ли система под 187-ФЗ. Далее постройте 2–3 сценария размещения для каждого класса и сравните их по стоимости владения на 3–5 лет, требованиям соответствия и аудируемости.

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