Единая ведомственная платформа «Облако-65» — обоснование для Архитектурного комитета

Постановка задачи

Почему нужен переход: сегодня против целевого состояния

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

Как есть (AS-IS)

Каждое ОИВ — само себе ЦОД

Серверы: у каждого министерства/агентства свои физические серверы — часть простаивает, часть перегружена, консолидации нет.
Лицензии: каждое ОИВ отдельно закупает ОС, среды виртуализации/контейнеризации, СУБД и СЗИ — N копий одних и тех же расходов.
СУБД: базы разворачиваются подрядчиками «как умеют» — без единых бэкапов, обновлений и контроля доступа.
Аттестация: каждая система аттестуется целиком, с нуля — железо, сеть, СЗИ. Дорого, медленно, результат не переиспользуется.
ИБ: у каждого ОИВ свои политики (или их отсутствие) — фактический уровень защиты зависит от добросовестности конкретного подрядчика.
«Быстрые сервисы»: запускаются вне контроля, при этом по Приказу № 117 подпадают под требования как «иные ИС госорганов» — прямой комплаенс-риск.

Как будет (TO-BE)

Одна платформа — все системы

Серверы: единый опорный кластер платформы; мощности ОИВ консолидируются, утилизация ресурсов растёт в разы.
Лицензии: лицензии на среду оркестрации и СЗИ покупаются один раз — на ноды платформы. Прикладные ИС лицензий на Kubernetes не требуют.
СУБД: централизованные аттестованные сервисы (PostgreSQL-оператор, Kafka, S3) предоставляются системам по запросу — с бэкапами и обновлением за счёт платформы.
Аттестация: платформа аттестуется один раз по максимальному классу (ГИС К1 / УЗ-1); прикладные системы наследуют меры инфраструктуры.
ИБ: политики единые, настраиваются платформой; ОИВ администрирует только своё пространство (namespace) и не может повлиять на чужие системы и общий периметр.
«Быстрые сервисы»: вводятся в эксплуатацию внутри аттестованного периметра после автоматической проверки безопасности в CI/CD — легально и за дни.

Целевая архитектура

Карта платформы с размещением систем ОИВ

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

ГИС ИСПДн Иная ИС (аналитика) Иная ИС (интеграции) Базовая платформа СЗИ (сквозной контроль) ⚖ — блок обоснования под каждой карточкой

👤 Граждане / сотрудники ОИВ → 3.1 Единый шлюз · WAF → 3.2 Keycloak / ЕСИА · проверка прав → 🟩 Namespace нужной системы

КОНТУР Б · ПРИКЛАДНЫЕ СИСТЕМЫ ОИВ

Изолированные пространства (Namespaces) — наследуют меры защиты платформы

администрирование ОИВ — только внутри своего пространства

ГИС «Единая карта сахалинца» gis-card-prod

ГИС · аттестация прикладного уровня

🧩 Бизнес-логика: транспорт, льготы, соцсервисы

🗄️ Прикладная БД — выдана оператором платформы (2.2)

Создана НПА. Лицензиат проверяет только прикладную часть — инфраструктура уже аттестована.

⚖ Обоснование размещенияОбязательная аттестация ГИС (Приказ ФСТЭК № 117) выполняется по схеме «типового сегмента»: лицензиат проверяет бизнес-логику, ролевую модель и API. В части инфраструктуры, ОС, СЗИ и сети в акте указывается ссылка на действующий Аттестат Платформы «Облако-65». Экономия: месяцы работ и полный цикл инфраструктурных испытаний на каждую новую версию системы.

ИСПДн «Острова-65» pdn-islands-prod

ИСПДн · самостоятельная оценка

🧑‍🤝‍🧑 Жители региона — пользователи сервисов

🪪 ПДн жителей: профили, заявления, выплаты, уведомления

Региональное приложение для жителей области. Не является ГИС — оценка мер силами ИБ-департамента.

⚖ Обоснование размещенияРегиональный сервис для жителей: личный профиль, подача заявлений, запись на приём, социальные выплаты и уведомления. Система обрабатывает персональные данные жителей, но не имеет статуса ГИС, поэтому регулируется Приказом ФСТЭК № 21, который разрешает оператору провести оценку эффективности мер самостоятельно, с оформлением внутреннего Акта. Основная часть мер (защита среды, каналов, СУБД, аудит) уже закрыта Платформой — легализация без затрат на внешнего лицензиата.

ИС «Система обогащения данных» data-enrich-prod

Иная ИС · класс К3

📊 Аналитика, сопоставление ведомственных датасетов

📥 Приёмники данных через шину платформы (3.3)

Без ПДн и гостайны. Ввод в эксплуатацию — приказом профильного департамента.

⚖ Обоснование размещения«Иная информационная система госоргана» по Приказу № 117. Для минимального класса (К3) при отсутствии ПДн и КИИ полная аттестация не требуется: ввод в эксплуатацию — решением ОИВ при условии размещения внутри аттестованной платформы и успешного прохождения автоматических сканеров безопасности (SAST/DAST/Trivy) в CI/CD. Раньше такая система была бы «вне закона» — теперь она легальна и контролируема.

ИС «Менеджмент ботов МАКС» max-bots-prod

Иная ИС · класс К3

🤖 Конструктор и мониторинг ботов в мессенджере МАКС

🔗 Подключение к API МАКС через шлюз платформы

Тот же трек, что и у «Обогащения данных»: CI/CD-проверки + приказ о вводе.

⚖ Обоснование размещенияИдентично предыдущей — «иная ИС» по Приказу № 117, класс К3, аттестация не требуется при размещении в аттестованном периметре. Ключевой плюс платформы: интеграционные ключи к API МАКС хранятся в общем секрет-хранилище платформы, а не в коде подрядчика; весь трафик ботов проходит через единый шлюз и попадает в общий аудит.

⬇⬆ Очищенный трафик 3.1 → Namespace ⬆ Телеметрия всех систем → SIEM 4.3 (принудительно) ⬆ Бэкапы всех БД → S3 2.3

ЛИНИЯ РАЗДЕЛА ОТВЕТСТВЕННОСТИ · Аттестат Платформы: ГИС К1 / ИСПДн УЗ-1

выше — системы ОИВ (наследуют защиту) · ниже — платформа (аттестуется один раз на всех)

КОНТУР А · БАЗОВАЯ ПЛАТФОРМА «ОБЛАКО-65»

Единая инфраструктура для всех ОИВ: аттестуется 1 раз по максимальному классу

1 аттестат вместо N

3Общие сервисы (переиспользуются всеми ИС)то, за что каждое ОИВ платит отдельно сегодня

3.1Единый API Gateway / Istio

mTLS, маршрутизация, канареечные релизы

⚖ ОбоснованиеЕдиная точка входа для всех систем области. Сегодня каждое ОИВ покупает и настраивает свой шлюз и SSL-сертификаты — завтра это один сертифицированный узел. Весь трафик между системами идёт по mTLS внутри Service Mesh.

3.2Keycloak / ЕСИА

Сквозной вход во все системы области

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

3.3Интеграционная шина · Kafka

Внутренний аналог СМЭВ для обмена между ОИВ

⚖ ОбоснованиеВедомственная шина данных: обмен датасетами между департаментами без прямых интеграций «каждый с каждым». Аттестованные коннекторы предоставляются платформой — системам не нужно разрабатывать свои.

2Оркестрация и данныелицензируется один раз — на ноды платформы

2.1K8s Control Plane

Единый сертифицированный дистрибутив

⚖ ОбоснованиеКлючевой тезис для комитета: лицензия на Kubernetes (Deckhouse CSE / Штурвал) покупается только здесь — на ноды платформы. ГИС, ИСПДн и «быстрые сервисы» не разворачивают собственный Kubernetes и лицензий не требуют: они используют мощности платформы по модели внутреннего облака (PaaS).

2.2Оператор СУБД (PostgreSQL/Redis)

БД по запросу: «нужна база на 100 ГБ» → манифест

⚖ ОбоснованиеЦентрализованный аттестованный СУБД-сервис: бэкапы, репликация, обновления безопасности — за счёт платформы. Подрядчикам запрещено ставить собственные СУБД. Любая система получает базу за минуты, а не закупает под неё сервер.

2.3Хранилище S3 · MinIO

Документы, файлы, бэкапы всех систем

⚖ ОбоснованиеЕдиное хранилище области. Все бэкапы прикладных БД автоматически стекаются сюда по настроенным платформой политикам — сегодня же у части систем бэкапов нет вообще.

1Инфраструктураконсолидированные мощности всех ОИВ

1.1Серверы / СХД

Консолидация разрозненных мощностей ОИВ

⚖ ОбоснованиеСуществующие серверы министерств и агентств передаются под управление платформы (либо закупается один консолидированный кластер). Простаивающие мощности ОИВ становятся полезной ёмкостью общего облака.

1.2Защищённая ОС

Astra Linux SE / RED OS — сертифицированная

⚖ ОбоснованиеСертифицированная ОС на всех нодах — обязательное условие аттестата платформы. Закупается централизованно на все ноды, а не каждым ОИВ отдельно.

1.3Сетевая фабрика

VLAN/VXLAN, микросегментация контуров

⚖ ОбоснованиеЕдиная сетевая фабрика с сегментами DEV/TEST/PROD и изоляцией namespace'ов. Трафик между системами разных ОИВ по умолчанию запрещён (NetworkPolicies) — разрешается только явно предусмотренными интеграциями.

🛡️

СЗИ и контроль ФСТЭК СКВОЗНОЙ СЛОЙ · ДЛЯ ВСЕХ СИСТЕМ СРАЗУ

4.1Контейнерный МСЭ

Runtime-защита всех систем области

⚖ ОбоснованиеСертифицированное СЗИ уровня контейнеров (vCore / Luntry / аналог). Закупается один раз — защищает все namespace'ы. Сегодня каждому ОИВ пришлось бы покупать собственный комплект.

4.2DevSecOps-конвейер

GitLab CI/CD + сканеры (SAST/DAST/Trivy)

⚖ ОбоснованиеОбязательное условие ввода ЛЮБОЙ системы в эксплуатацию, включая «быстрые сервисы». Деплой блокируется при наличии High/Critical уязвимостей. Протоколы проверок — готовое доказательство комплаенса для регулятора.

4.3Центральный SIEM / аудит

Логи всех ОИВ → единая шина → ГосСОПКА

⚖ ОбоснованиеКлючевая гарантия для ИБ: разработчик или администратор ОИВ технически не может удалить логи своих действий — телеметрия передаётся принудительно. Один аудит закрывает требования ко всем системам сразу.

⬍ Один комплект СЗИ защищает все системы области. Это главный источник экономии: сегодня каждое ОИВ должно собрать собственный сертифицированный набор средств защиты.

Обоснование состава прикладного слоя. Состав систем на схеме подобран так, чтобы продемонстрировать комитету: платформа легализует все типы систем ведомства, а не только крупные. Представлены все три законодательно выделенные категории: официальная ГИС («Единая карта сахалинца» — прикладной аттестат через лицензиата), ИСПДн без статуса ГИС («Острова-65» — региональное приложение для жителей, самостоятельная оценка по Приказу № 21) и «иные ИС» («Система обогащения данных», «Система менеджмента ботов МАКС» — ввод приказом ОИВ после автоматических проверок, класс К3).