С 1 марта 2026 года действуют новые требования ФСТЭК к государственным и другим регулируемым информационным системам. Astra Cloud уже получила аттестат по приказам №117 и №21: класс К1 и уровень УЗ-1.
Но аттестат облака не переходит к размещённой в нём 1С. Информационную систему заказчика всё равно аттестуют отдельно. Поэтому новость сокращает часть работ, но не даёт разрешения сразу переносить рабочую базу.
Практический вопрос звучит так: можно ли включить Astra Cloud в проект размещения 1С с государственными или персональными данными? Да, если системе нужен аттестованный инфраструктурный слой К1 или УЗ-1. Перед пилотом придётся проверить область аттестата, границы ответственности и свою связку 1С, СУБД, ОС и интеграций.
Что подтвердила аттестация Astra Cloud
«Группа Астра» сообщает об аттестации изолированной облачной инфраструктуры Astra Cloud. Аттестат подтверждает соответствие приказу ФСТЭК №117 по классу К1 и приказу №21 по уровню УЗ-1.
Речь идёт именно об инфраструктуре провайдера. В неё входят вычислительные ресурсы, средства защиты и защищённый доступ. Конкретной информационной системы заказчика в этой области пока нет.
Мы не расшифровываем К1 и УЗ-1 как универсальные наборы мер. Среди доступных материалов нет текстов приказов ФСТЭК и самого аттестата с областью действия. Для проектного решения запросите эти документы у Astra Cloud и передайте их специалисту по защите информации.
| Документ | Что подтверждено у Astra Cloud | Для каких систем это существенно | Что проверяет заказчик |
|---|---|---|---|
| Приказ ФСТЭК №117 | Облачная инфраструктура соответствует классу К1 | ГИС и другие системы органов власти, подведомственных организаций и компаний, работающих с государственным сегментом | Класс своей системы, модель угроз, состав мер и включение клиентского контура в область аттестации |
| Приказ ФСТЭК №21 | Инфраструктура соответствует уровню УЗ-1 | ИСПДн, включая системы со специальными категориями персональных данных | Требуемый уровень защищённости, категории данных, состав рабочих мест и способы доступа |
| Аттестат Astra Cloud | Проверен инфраструктурный слой провайдера | Системы, которым подходит заявленная область аттестации | Срок действия, точные границы, ограничения конфигурации и перечень включённых средств защиты |
| Аттестат системы заказчика | Astra Cloud его не заменяет | Конкретный экземпляр 1С вместе с СУБД, ОС, доступом и интеграциями | Подготовку документов, испытания и устранение замечаний по всей информационной системе |
Вывод из таблицы: готовый аттестованный слой закрывает только часть будущего контура. Приложения, данные и процессы заказчика остаются предметом отдельной проверки.
Кому аттестат меняет условия размещения 1С
Первый кандидат — государственный орган или подведомственное учреждение. По сообщению «Группы Астра», такие организации должны размещать ГИС и ИСПДн в аттестованной среде. Приказ №117 также охватывает компании, которые работают с государственным сегментом.
Если в 1С хранятся персональные данные, одного названия облака для решения мало. Нужно определить категорию данных и требуемый уровень защищённости. Затем эту потребность сверяют с областью аттестата Astra Cloud.
Отдельного внимания требуют медицинские системы. «Группа Астра» указывает, что приказ №21 задаёт УЗ-1 для медицинских систем со специальными категориями персональных данных. Это может касаться 1С, если она входит в соответствующую информационную систему и обрабатывает такие сведения.
Для банка, МФО, страховщика или финтех-компании проверка шире. По материалам Astra Cloud, кроме приказа №21, здесь учитывают ГОСТ Р 57580.1 и PCI DSS 4.0. Аттестат ФСТЭК не подтверждает соответствие всем этим требованиям одновременно.
У коммерческой компании без государственного сегмента и регулируемых данных мотив будет другим. К1 или УЗ-1 сами по себе не делают облако подходящим для 1С. Сначала определите обязательные требования к системе, иначе проект начнётся с выбранной площадки, а не с задачи.
Как читать границу аттестата
Представьте будущий контур как несколько слоёв ответственности. Нижний слой принадлежит облачному провайдеру. Верхние слои собирает и эксплуатирует заказчик либо его подрядчик.
Astra Cloud сообщает, что инфраструктура размещена в ЦОД уровня Tier IV и построена на отечественном оборудовании. В аттестованный контур входят сертифицированные межсетевые экраны, антивирус, средства доверенной загрузки, SIEM и системы выявления вторжений.
Эти сведения отвечают на вопрос о базовом защитном слое. Они не подтверждают настройки конкретной виртуальной машины, права пользователей 1С или безопасность внешнего обмена. Граница проходит там, где заканчивается управляемая провайдером инфраструктура.
| Часть контура | Что заявляет Astra Cloud | Что нужно выяснить до пилота | Кто фиксирует результат |
|---|---|---|---|
| ЦОД и физическая инфраструктура | Размещение в ЦОД уровня Tier IV, отечественное оборудование | Какие площадки входят в область аттестата и где хранятся резервные копии | Провайдер в договоре и приложениях к нему |
| Сетевой периметр | Сертифицированные межсетевые экраны и средства выявления вторжений | Где проходит граница сети заказчика, кто меняет правила и хранит журналы | Провайдер и заказчик в матрице ответственности |
| Защита узлов | Антивирус и средства доверенной загрузки | Какие образы ОС доступны, кто устанавливает обновления и контролирует настройки | Сторона, которая администрирует виртуальные машины |
| События безопасности | SIEM внутри защищённого контура | Какие события получает заказчик, сколько хранятся журналы и кто разбирает инциденты | Провайдер и служба информационной безопасности заказчика |
| Канал доступа | Подключение через сертифицированные СКЗИ | Какие средства нужны на рабочих местах, кто выдаёт ключи и как подключают филиалы | Заказчик вместе с провайдером |
| Платформа 1С и СУБД | Аттестат инфраструктуры их совместимость не подтверждает | Версии, лицензии, поддержка ОС, расширения, фоновые задания и резервное копирование | Администратор 1С и владелец системы |
| Интеграции | В составе аттестованного слоя не заявлены | Маршруты обмена, сервисные учётные записи, криптография и выход за границу контура | Владелец каждой интеграции |
Вывод: запросите у провайдера схему границ до расчёта проекта. Без неё нельзя понять, какие средства защиты уже включены, а какие придётся покупать и сопровождать отдельно.
Что провайдер уже берёт на себя
Готовый инфраструктурный слой избавляет заказчика от самостоятельной сборки части защитного контура. Сертифицированные средства защиты уже включены в сервис, согласно сообщению Astra Cloud.
Это снижает объём работ именно на нижнем уровне. Не нужно заново проектировать ЦОД или отдельно собирать набор инфраструктурных средств, которые вошли в аттестованную среду. Точный состав всё равно сверяют с областью действия аттестата.
Доступ пользователей проходит через защищённое соединение на базе сертифицированных средств криптографической защиты. Значит, проект не заканчивается созданием виртуальной машины. Нужно подготовить рабочие места, каналы филиалов, ключи и порядок подключения администраторов.
Здесь часто обнаруживается скрытая часть бюджета. Сам облачный ресурс уже заказан, но удалённая площадка или рабочие места ещё не готовы к защищённому каналу. Эту часть стоит оценить до договора, а не перед рабочим переносом.
Что остаётся на стороне заказчика
Аттестат Astra Cloud не подтверждает работу вашей версии «1С:Предприятия» на выбранной ОС. Он также ничего не говорит о совместимости СУБД, расширений, драйверов защиты и внешних обработок.
Это не недостаток аттестата, а его граница. Проверяли инфраструктуру и средства защиты провайдера. Результатов испытаний конкретного прикладного контура в опубликованных материалах нет.
Поэтому сертификат или аттестат одного компонента нельзя переносить на всю систему. Похожую границу приходится учитывать при проверке сертифицированной ОС перед миграцией 1С: подтверждённая платформа не закрывает доработки и сторонние продукты.
До пилота соберите перечень компонентов. Нужны версии платформы 1С, СУБД и серверной ОС, расширения, внешние обработки, драйверы лицензирования, резервное копирование и все обмены. Для каждого пункта назначьте владельца проверки.
Проверьте и порядок сопровождения Astra Linux. Перед рабочим окном полезно пройти контрольные точки обновления серверной ОС: поддержку версии, откат и совместимость со стороны поставщиков 1С и СУБД.
Почему нельзя начинать с рабочей базы
Перенос данных подтверждает только то, что копию удалось доставить в новый контур. Он не доказывает готовность системы к рабочей нагрузке, аттестационным испытаниям и отказам отдельных компонентов.
Обещание «перенести за день» тоже требует расшифровки. За один рабочий день подрядчик может развернуть машины и восстановить копию. Полный результат включает проверки пользователей, обменов, резервных копий и защищённого доступа. Эти границы подробно разобраны в материале о том, что считать законченным переносом 1С в облако.
Пилот нужно отделить от рабочего контура. В него переносят копию базы, подключают тестовые рабочие места и воспроизводят критичные операции. Такой подход оставляет действующую систему на месте, пока новая схема не прошла проверку.
Пилот пригодится и для доменной инфраструктуры. Изменения политик и переключение контроллеров способны затронуть вход пользователей и службы. Пример состава такой проверки есть в материале о стенде для изменений доменного контура.
Что проверить на пилоте
Набор проверок зависит от конфигурации, но четыре группы нужны почти любому серверному контуру 1С. Это запуск служб, прикладные операции, интеграции и восстановление из резервной копии.
Не подменяйте проверку успешным входом одного администратора. Пользователь может открыть базу, пока регламентные задания, обмен с банком или печать через внешний компонент уже не работают.
| Проверка | Что сделать | Признак готовности | Что фиксировать |
|---|---|---|---|
| Платформа и СУБД | Развернуть заявленные версии и восстановить копию базы | Службы запускаются, база открывается без изменения рабочей системы | Версии пакетов, параметры служб, протокол восстановления |
| Пользовательские сценарии | Выполнить операции из разных ролей | Права, печать и проведение работают в выбранном наборе сценариев | Роль, операция, результат и найденное отклонение |
| Фоновые процессы | Запустить регламентные задания и дождаться их завершения | Нет зависших заданий и необъяснённых ошибок в журналах | Время запуска, статус и журнал ошибки |
| Интеграции | Проверить каждый входящий и исходящий обмен | Данные проходят через утверждённую границу контура | Маршрут, учётная запись, способ защиты и результат |
| Защищённый доступ | Подключить тестовые рабочие места и администратора | Пользователь входит по согласованной схеме, события попадают в журналы | Тип подключения, выданные права и место хранения событий |
| Резервное копирование | Создать копию и восстановить её отдельно | Восстановленная база открывается и проходит контрольные операции | Длительность, состав копии и порядок восстановления |
Вывод: пилот закончен не после запуска 1С, а после прохождения заранее записанных сценариев. Без протокола положительный результат нельзя предъявить аттестационной комиссии или владельцу системы.
Ускорит ли готовое облако аттестацию
Astra Cloud оценивает ускорение аттестации клиентского контура в три-пять раз. Эту цифру нельзя превращать в обещанный срок проекта: компания не раскрыла исходный календарный план конкретного заказчика.
Допустим, одна система требует новых документов, интеграций и рабочих мест со средствами защиты. Другая уже подготовлена и меняет только инфраструктурную площадку. Даже в одном облаке сроки у таких проектов будут разными.
Полезнее считать не дни, а снятые работы. Готовая инфраструктура может убрать проектирование и аттестацию части нижнего слоя. Документы заказчика, испытания приложений и проверка каналов остаются.
Запросите у исполнителя два перечня: что закрывает аттестат Astra Cloud и что войдёт в аттестацию вашей системы. Тогда оценку ускорения можно проверить по конкретным работам, а не по коэффициенту из пресс-релиза.
Что запросить до решения о пилоте
Начните с копии аттестата и его области действия. Нужны срок, перечень площадок, состав инфраструктуры, ограничения и условия сохранения аттестованной конфигурации.
Следом запросите схему разделения ответственности. В ней должны быть перечислены сеть, виртуальные машины, ОС, журналы, обновления, резервные копии, ключи доступа и реакция на инциденты.
Третий документ — схема подключения. Она покажет требования к СКЗИ, рабочим местам, филиалам и административному доступу. Без неё нельзя оценить готовность пользователей к переходу.
Четвёртый пакет относится уже к 1С. Соберите матрицу совместимости платформы, СУБД, ОС и средств защиты. Отдельно внесите компоненты, для которых нет подтверждения поставщика и потребуется испытание на копии базы.
Если границу ответственности не удаётся свести в один документ, проект ещё рано выпускать в рабочий контур. Разобрать спорные места можно на консультации по архитектуре конкретной системы, когда ответ зависит от состава базы и подключений.
Изменение конфигурации может потребовать новой аттестации
По сообщению «Группы Астра», аттестаты, выданные до 1 марта 2026 года, действуют при неизменной конфигурации системы. Модернизация после этой даты требует переаттестации по новым правилам.
Для заказчика это означает контроль изменений. Новый сетевой маршрут, средство защиты или компонент инфраструктуры нужно сначала сверить с областью аттестата. Иначе рабочее изменение может затронуть подтверждённую конфигурацию.
Уточните у провайдера порядок согласования таких работ. В договоре должны быть срок уведомления, состав передаваемых документов и действия сторон после изменения аттестованного слоя.
Решение: включать ли Astra Cloud в короткий список
Включайте Astra Cloud в короткий список, если вашей информационной системе нужны К1 по приказу №117 или УЗ-1 по приказу №21. Аттестованная инфраструктура снимает часть работ по нижнему защитному слою.
Не принимайте аттестат за подтверждение готовности 1С. Заказчику ещё нужно аттестовать свою систему, проверить прикладной контур и организовать защищённый доступ.
До пилота пройдите один чек-лист:
- запросите аттестат, область действия, срок и ограничения конфигурации;
- зафиксируйте ответственность за сеть, ОС, защиту, журналы, копии и обновления;
- получите требования к СКЗИ, рабочим местам и каналам филиалов;
- сверьте поддержку своей связки 1С, СУБД, ОС и внешних компонентов;
- разверните копию базы в отдельном пилоте и проведите записанные сценарии.
Рабочее окно назначайте после протокола пилота. Если хотя бы один критичный обмен или способ восстановления не проверен, перенос ещё не подготовлен.