Аттестованное облако: требования, провайдеры и выбор для госсектора

Аттестованное облако и облако с сертифицированными СЗИ — не одно и то же. Поэтому перед выбором провайдера важно оценить свою ИС и классифицировать данные по уровню критичности. Это позволит определить требования и подобрать уровень аттестата, который обеспечит соблюдение нормативных требований.

1. Введение
2. Отличия аттестованного облака от облака, использующего сертифицированные СЗИ
3. Нормативные требования к защите информации
4. Действия провайдера для аттестации облака
5. Действия заказчика для соответствия требованиям регулятора
6. RACI: роли и ответственность участников
7. Ключевые игроки и их особенности
8. Практический чек-лист вопросов провайдеру
9. Выводы

Введение

Облака остаются привлекательным инструментом для заказчиков благодаря сочетанию удобства, надёжности и высокой степени автоматизации. Они обеспечивают быстрое развёртывание инфраструктуры, снижают нагрузку на эксплуатационные подразделения и повышают стабильность работы информационных систем (ИС). Гибкость и масштабируемость таких решений позволяют адаптировать ресурсы под конкретные задачи и оперативно реагировать на изменения требований бизнеса или ведомственных процессов, о чём мы говорили в одном из эфиров телепроекта AM Live.

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

В России наряду с единой государственной облачной платформой «ГосОблако» доступны и коммерческие облачные инфраструктуры, прошедшие процедуру аттестации и готовые к использованию для размещения государственных информационных систем (ГИС), информационных систем персональных данных (ИСПДн) и объектов критической информационной инфраструктуры (КИИ).

Отличия аттестованного облака от облака, использующего сертифицированные СЗИ

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

Уровень полученного аттестата может быть разным: ИСПДн до УЗ‑1, ГИС до К1, КИИ до 1 категории. Процедура аттестации регламентируется Приказом № 77 ФСТЭК России и проводится только аккредитованными организациями, имеющими право выполнять такие проверки. Проверка мер защиты проводится комплексно.

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

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

Нормативные требования к защите информации

При выборе аттестованного облака необходимо учитывать нормативные документы, регулирующие защиту данных и инфраструктуры в России.

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

ПП РФ № 1119 и приказ ФСТЭК № 21. Нормативные документы определяют уровни защищённости информационных систем персональных данных и конкретный перечень мер защиты: разграничение доступа, применение средств криптографической защиты информации, журналирование и контроль действий пользователей и др.

187-ФЗ. Регулирует порядок обеспечения безопасности КИИ с целью её устойчивого функционирования при возможных кибератаках. Определяет полномочия государственных органов в области обеспечения безопасности КИИ, а также права, обязанности и ответственность субъектов КИИ.

ЦБ РФ (757‑П / 851‑П), ГОСТ Р 57580. Описывают требования к ИБ финансовых организаций, включая банки и небанковские кредитные учреждения. Часто требуется отдельно провести оценку соответствия выполнения регуляторных мер (контроль доступа, аудит действий и др.).

Приказы ФСТЭК № 117 (ГИС), № 239 (ЗОКИИ). Первый приказ корректирует порядок разработки мер защиты информационных систем. Вступит в силу с 01.03.2026. Приказ № 239 определяет требования к мерам и средствам, которые применяются для защиты ЗОКИИ (значимых объектов критической информационной инфраструктуры) от кибератак.

В зависимости от отраслевой специфики организации может понадобиться соответствие ИС другим стандартам и нормативным требованиям. Например, стандарту безопасности данных платёжных карт (Payment Card Industry Data Security Standard, PCI DSS), требованиям к средствам электронной подписи, соответствие стандартам ISO и др.

Действия провайдера для аттестации облака

Провайдер готовит облачную платформу к аттестации следующим образом:

1. Подготовка и лицензии. Проверка соответствия требованиям закона, оценка угрозы для системы и получение необходимых лицензий ФСТЭК и ФСБ для средств криптографической защиты.
2. Проектирование защиты. Изолирование сегментов, внедрение сертифицированных СЗИ на все уровни: доверенную загрузку, гипервизор, межсетевые экраны и системы предотвращения вторжений, СКЗИ (средства криптографической защиты информации), SIEM (Security Information and Event Management, управление информацией и событиями информационной безопасности), резервирование и управление уязвимостями.
3. Предварительные проверки. Проведение внутреннего аудита, устранение уязвимостей, актуализация документации.
4. Аттестационные испытания. Лицензированная организация проводит испытания и оформляет аттестат необходимого уровня.

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

Действия заказчика для соответствия требованиям регулятора

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

Классификация информации по уровню конфиденциальности и критичности (уровень ИСПДн / класс ГИС / категория КИИ) позволит сформулировать конкретные требования к конфигурации и обеспечить соответствие нормативным требованиям регуляторов.

Далее необходимо выполнить следующие шаги:

1. Выбрать провайдера с требуемым уровнем аттестата и заключить договор с чётко оговорёнными обязанностями по 152‑ФЗ, доступу к данным, реагированию на инциденты и так далее.
2. Настроить среду: организовать доступы, VPN/СКЗИ, обеспечить сегментацию, настроить резервное копирование, политики безопасности в своих виртуальных машинах/сервисах.
3. Документировать и при необходимости аттестовать свою ИС, опираясь на материалы провайдера: выписку из модели угроз, копию аттестата и перечень реализованных мер.

Теперь остаётся регулярно вести аудит логов, управлять учётными записями с использованием MFA (Multi-factor Authentication, многофакторной аутентификации), выполнять обновления, совместно реагировать на инциденты и поддерживать готовность к проверкам.

RACI: роли и ответственность участников

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

Таблица 1. Ответственность сторон

Ключевые игроки и их особенности

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

Таблица 2. Облачные провайдеры и их особенности

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

Практический чек-лист вопросов провайдеру

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

Предлагаем задать следующие вопросы:

1. Инфраструктура выделена полностью под заказчика или осуществляется разделение инфраструктуры заказчиков на программном уровне? Какое оборудование выделено исключительно под заказчика, а какое — общее (сервера, СХД, коммутаторы, ИБ)?
2. Какой аттестат имеется? На какие объекты он распространяется: ИСПДн УЗ‑1 / 2 / 3, ГИС К1 / К2 / К3, КИИ I–III? Кем и когда выдан?
3. Какие сервисы входят в границы аттестации провайдера: IaaS, объектное хранилище, Kubernetes / DBaaS, Bare Metal?
4. Какие СЗИ, СКЗИ применяются? Каким образом реализованы ключевые меры защиты: МЭ / IDS / IPS, доверенная загрузка, SIEM, резервирование.
5. Имеются ли необходимые лицензии, проведены ли аудиты для работы в конкретном домене: требования к средствам электронной подписи, соответствие стандартам ISO, 757‑П / 851‑П, ГОСТ 57580, PCI DSS?
6. Как распределена ответственность между провайдером и клиентом в договоре и SLA: за инциденты, уведомления о событиях, проведение аудита или проверок, последствия при нарушении требований безопасности?
7. Каким образом обеспечена изоляция среды и управление доступом: выделенные сегменты / VLAN / хосты, собственные криптошлюзы, dedicated server, Bare Metal?
8. Как процедуры обновлений и масштабирования влияют на действующий аттестат, включая процедуры изменений, вторые площадки, DR (Disaster Recovery, аварийное восстановление), единые границы аттестации?
9. Какой пакет документов предоставляется клиенту: копия аттестата, выписка из модели угроз, методические материалы, рекомендации по безопасной эксплуатации инфраструктуры?
10. Как устроена устойчивость и резервирование мер ИБ: дублирование СЗИ, распределение нагрузки между зонами доступности и центрами обработки данных, охват резервной площадки.
11. Как обеспечивается катастрофоустойчивость? Есть второй ЦОД?
12. Какова финансовая модель и условия SLA: надбавка за защищённый контур, целевые RTO / RPO (максимальное время простоя и точка восстановления), штрафы за нарушения мер ИБ.

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

Выводы

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

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