Часто задаваемые вопросы (FAQ)

№	Вопрос	Ответ
	Реализация каких мер защиты информации 17 и 21 приказов ФСТЭК сертифицирована для ПК СВ «Брест», ОС Astra Linux Special Edition, ALD Pro, RuBackup, BILLmanager и других компонентов Платформы Astra Cloud?	ПК СВ «Брест» сертифицирован на соответствие «Требованиям по безопасности информации к средствам виртуализации» ФСТЭК России по 2 классу, 2 уровень доверия: Сертификат № 4864 от 08.10.2024 г. ОС СН Astra Linux Special Edition сертифицирована на соответствие: «Требованиям к операционным системам» (утв. приказом ФСТЭК России от 19.08.2016 г. № 119), «Требованиям по безопасности информации к средствам виртуализации» (утв. приказом ФСТЭК России от 27.10.2022 г. № 187) и «Требованиям по безопасности информации к средствам контейнеризации» (утв. приказом ФСТЭК России от 4 июля 2022 г. № 118). Сертификаты соответствия Astra Linux Special Edition ОС СН Astra Linux Special Edition в двух режимах функционирования: Усиленный «Воронеж» и Максимальный «Смоленск», каждый из режимов закрывает определенный набор мер 17 и 21 Приказов. С возможностями реализации мер основных Приказов ФСТЭК механизмами ОС СН Astra Linux Special Edition можно ознакомиться в соответствующем разделе Справочного центра. ALD Pro сертифицирован на соответствие «Требованиям по безопасности информации, устанавливающим уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» (ФСТЭК России, 2020) — по 2 уровню доверия и на соответствие техническим условиям: Сертификат ФСТЭК России № 4830 от 26.07.2024 г. RuBackup сертифицирован на соответствие «Требованиям по безопасности информации, устанавливающим уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» (ФСТЭК России, 2020) — по 4 уровню доверия и на соответствие техническим условиям: Сертификат ФСТЭК России № 4879 от 25.11.2024 г. Компоненты BILLmanager, DCImanager, Astra Monitoring, Astra Automation и проч. на данный момент не планируются к сертификации
	Существует ли рекомендованный Группой Астра список совместимых наложенных средств защиты информации, сертифицированных и реализующих недостающие технические меры защиты при аттестации ИС, построенной на базе ПК СВ «Брест», ОС Astra Linux, BILLmanager, по требованиям 17 и 21 приказов ФСТЭК?	Для полноценного закрытия ряда мер в конкретной информационной системе (ИС) необходимо использование дополнительных СЗИ. При аттестации целевой ИС необходимо использовать сертифицированные СЗИ. Список дополнительных и рекомендуемых СЗИ формируется исходя из потребностей Заказчика. Однако есть перечень средств, прошедших тестирование , на совместимость с ОС, которые потенциально можно рассматривать как дополнительные СЗИ в целевой ИС. Также можно ознакомиться с перечнем межсетевых экранов для применения в виртуальной инфраструктуре в виде программного решения (МСЭ типа «Б»), в том числе совместно с программным комплексом «Средства виртуализации «Брест» (ПК СВ «Брест»).
	Верно ли утверждение, что использование OCFS2 (как и NFS) при развертывании ГИС не рекомендуется из-за отсутствия поддержки меток безопасности?	OCFS2 поддерживает метки безопасности, но на данный момент не рекомендуется к использованию в защищенном режиме, так как при определенной нагрузке приводит к возникновению ошибок. Подробнее об этом можно прочитать в статье о хранилищах на базе файловой технологии хранения. Кроме того, OCFS2 имеет ряд других ограничений (к примеру, для обслуживания данной файловой системы требуется отключение общего тома от всех серверов). Потому рекомендуется использовать драйвер Ceph или LVM_LVM. В ПК СВ «Брест» 4.0.2 реализован новый драйвер BREST_LVM, не имеющий недостатков драйвера LVM_LVM.
	Существует ли инструкция/рекомендации по приведению в безопасное состояние ОС Astra Linux, ALD Pro и ПК СВ «Брест»?	Для ОС Astra Linux Special Edition есть RedBook. Для ПК СВ «Брест» и ALD Pro могут быть применены рекомендации Astra Automation — Center for Information Security.
	Существуют ли публичные баг-трекеры систем ОС Astra Linux, ALD Pro и ПК СВ «Брест»?	На данный момент публичные Баг-трекеры для этих продуктов не реализованы. При необходимости, Пользователь может открыть тикет в личном кабинете.
	Существуют ли рекомендации/ решения по организации резервного копирования для пользовательской части?	Для выполнения резервного копирования пользовательской части требуется развертывание отдельного сервиса СРК.
	Существует ли у Группы Астра опыт/рекомендации по использованию KSC на базе ОС Astra Linux Special Edition без дополнительной установки ОС Windows?	Kaspersky Security Center (KSC) сертифицирован для использования с ОС Astra Linux: О наличии/отсутствии технической возможности установки KSC на инфраструктуру Заказчика следует узнавать у разработчиков KSC.
	Существуют ли готовые решения/рекомендации по биллингу ресурсов в ЦОД, которые можно использовать в аттестованном сегменте? Либо рекомендации к использованию API?	Сбор информации о потреблении вычислительных ресурсов, тарификации, выставлении счетов и контроль за ресурсами осуществляется при помощи встроенного в Платформу Astra Cloud Портала самообслуживания.
	Для аттестации ПК СВ «Брест» будет ли необходимость устанавливать антивирусное ПО непосредственно на хостовые ОС (фронтальные машины и гипервизоры)?	Для закрытия мер АВЗ (ФСТЭК 17) потребуется антивирус. ОС Astra Linux Special Edition и ПК СВ «Брест» не могут закрывать требования по антивирусной защите.
	Существует ли список рекомендованных/совместимых версий антивирусов для фронтальных машин, гипервизоров ПК СВ и серверов ALD Pro?	Узнать о совместимости ПО можно на портале Ready For Astra.
	Какие исключения требуется настроить в политиках АВ?	За рекомендациями по настройке исключений следует обращаться к разработчикам выбранного Антивируса.
	Какие способы георезервирования поддерживает платформа?	Реализация способов георезервирования представлена в разделе СЦ: Сценарии и варианты аварийного восстановления данных.
	Возможно ли обновление на актуальные версии ОС Astra Linux, ALD Pro, ПК СВ и проч.	Обновление производится единым пакетом для всех компонентов Платформы Astra Cloud сразу. Обновление отдельных компонентов Платформы Astra Cloud не предусмотренно.
	Существует ли механизм импорта правил межсетевого экрана на платформу?	Функционал поддерживается. Для реализации импорта правил можно использовать ПО UserGate.
	Какие виды изоляции предусмотрены в платформе?	Разграничение возможно с помощью управления логическими объектами на уровне Портала самообслуживания. Предполагается поддержка на уровне Тенантов, Информационных Систем, Ландшафтов и Групп ВМ.
	Что из себя представляет механизм миграции в Платформе Astra Cloud?	Миграция с ПК СВ «Брест» на Платформу возможна с установкой дополнительных компонентов. Требуется обследование и проектный подход (обновление компонентов до совместимых версий и миграция данных). Необходимо будет доустановить компоненты в зависимости от выбранной редакции ОП: Базовой или Стандартной
	Какие способы установки предлагаются платформой?	Установка Платформы Astr Cloud осуществляется с помщью встроенной в нее Подсистемы развертывания и настройки.
	Сможет ли Заказчик использовать компоненты ОП для обслуживания других элементов своей инфраструктуры, не входящих в состав Платформы?	Все компоненты продукта могут использоваться только для функционирования самой Платформы Astra Cloud. Использование компонентов ОП для нужд Заказчика не предполагается отдельное .
	Какие пользовательские интерфейсы предоставляет платформа?	для пользователей — Портал самообслуживания; для администраторов — Портал самообслуживания и Портал администратора в подсистеме виртуализации.
	Укажите текущие версии компонентов Платформы Astra Cloud. Будет ли Платформа работать на новых версиях?	Текущие версии компонентов Платформы Astra Cloud 2.1.x: ОС СН ALSE — SE 1.8.5.46, SE 1.7.9.46; ПК СВ «Брест» — 4.0.2; ALD Pro — 3.2.0; RuBackup — 3.0 (в случае установки Платформы Astra Cloud версии 2.1.1); BILLmanager — 6.149 (в случае установки Платформы Astra Cloud версии 2.1.0 – 6.139); Astra Monitoring — 1.3.0; DCImanager — 6; Боцман — 3.1.0; UIDM — 1.0.0; APOS — 1.0.0; APIM — 1.0.0. Новые версии компонентов и их совместимость тестируются технической командой Платформы Astra Cloud.
	Какая частота выхода обновлений (очередных, оперативных, срочных) предусмотрена для ОС и других компонентов Платформы Astra Cloud?	Выпуск релизов Платформы Astra Cloud производится один раз в полгода. Выход очередных, оперативных, срочных обновлений производится по мере готовности. Обновление производится единым пакетом для всех компонентов Платформы Astra Cloud сразу. Обновление отдельных компонентов Платформы Astra Cloud не предусмотренно.
	Будет ли синхронизирован релизный цикл Платформы Astra Cloud и ПК СВ «Брест»?	Нет. Продукт ПК СВ «Брест» продолжает развиваться как отдельный продукт со своей дорожной картой. Платформа Astra Cloud использует ПК СВ в качестве средства управления виртуализацией.
	Возможна ли интеграция существующего контроллера домена (SAMBA, MS AD, FreeIPAALDPro) с Платформой Astra Cloud?	Входящая в ОП Подсистема контроллера домена позволяет через механизмы доверительных отношений интегрироваться с различными вариантами контроллеров домена.
	Планируется ли в будущем блокировка отдельных веб-интерфейсов компонентов Платформы Astra Cloud?	На данный момент блокировка доступа к Веб-интерфейсам компонентов Платформы для администраторов не планируется. В будущих версиях планируется организация полноценного Wеb-SSO.
	Планируется ли в новых версиях Платформы поддержка VxLAN через BGP EVPN для организации взаимодействия между ЦОД-ами?	В Платформе Astra Cloud реализован функционал использования динамических протоколов маршрутизации OSPF и BGP в виртуальном маршрутизаторе. Для реализации взаимодействия между ЦОД-ами предполагается использование связки VLAN/VXLAN на виртуальном маршрутизаторе при дополнительной настройке оборудования Заказчика.
	Есть ли поддержка внешней авторизации OIDС/SAML, к примеру keycloak/blitz?	В Платформе реализована Подсистема управления идентификацией и доступом, который будет поддерживать OIDС/SAML.
	Есть ли поддержка использования 2FA внешний/внутренний?	Механизмы 2FA могут быть реализованы: средствами ОС СН ALSE; средствами BILLmanager.
	Перечислите основные функциональные возможности подсистемы мониторинга в платформе Astra Cloud.	В Платформе Astra Cloud инструменты мониторинга развиваются с прицелом на практическую пригодность в продуктивных средах. Система мониторинга включает в себя следующие уровни: Мониторинг инфраструктуры. Используется для сбора и визуализации метрик по серверам виртуализации, ВМ, сетям и хранилищам. Поддерживается отображение нагрузки CPU, памяти, I/O, сетевых интерфейсов, а также алерты по пороговым значениям. Графики, истории значений и экспорт данных доступны из интерфейса. Мониторинг состояния подсистем платформы. Отслеживается работоспособность ключевых компонентов ОП. Возможна интеграция с внешними системами оповещения и SIEM. Поддержка инцидент-менеджмента и событийной корреляции. Все события могут быть логированы, агрегированы и направлены в централизованные хранилища. Также предусмотрена возможность интеграции с внешними системами Service Desk. Гибкость настройки. Поддерживаются кастомные дашборды, метрики, технические шаблоны, настраиваемые алерты и сценарии реакции. Все это позволяет обеспечить проактивный подход к поддержанию доступности, быструю диагностику проблем и соответствие требованиям к наблюдаемости, в том числе для защищенных систем.
	Какая стратегия миграции предлагается при переходе на Ваш продукт?	Переход на Платформу Astra Cloud должен быть поддержан тщательно разработанной стратегией миграции, адаптированной под конкретные условия Заказчика. Наиболее часто применяются следующие стратегии миграции: Горизонтальный перенос (cold migration) — виртуальные машины переносятся с предварительным отключением, что минимизирует риски, но влечет за собой плановое прерывание сервиса. Этот подход оптимален при переносе ВМ вне пиковых часов или в выходные дни. Миграция через промежуточное хранилище — применяется при больших объемах данных. ВМ копируются на общий репозиторий, затем разворачиваются в Платформе Astra Cloud. Это позволяет сократить время простоя до минимума. Live migration (для KVM совместимых сред) — возможна при определенных условиях: схожие версии гипервизоров, одинаковый формат виртуальных дисков, наличие общей СХД. Применяется точечно для систем с высокими SLA. Пошаговая миграция с репликацией и переключением — наиболее гибкий и безопасный подход. Создаются реплики ВМ в Платформе Astra Cloud, после чего производится финальная синхронизация и переключение. Позволяет держать сервисы доступными до самого момента переключения.
	Насколько длительное прерывание сервиса может быть при миграции больших виртуальных машин на Платформу Astra Cloud?	Ожидаемое время прерывания: Для больших виртуальных машин (100-500+ ГБ), в зависимости от метода и инфраструктуры: при холодной миграции: от 10 до 60 минут, включая подготовку; при использовании репликации с переключением: менее 5 минут реального прерывания (в момент cutover); при Live migration (если применимо): до 1 минуты. Факторы, влияющие на длительность миграции: пропускная способность сети между старой платформой и Платформой Astra Cloud; производительность хранилищ; способ хранения дисков (qcow2, raw, Ceph и др.); наличие онлайн-доступа к гипервизору и форматам метаданных. Время на перенос ВМ может значительно варьироваться в зависимости от реализованной Заказчиком инфраструктуры и выбранного режима миграции.
	Какие механизмы обеспечения отказоустойчивости и катастрофоустойчивости могут применяться для повышения доступности?	В контексте повышения доступности облачной платформы Astra Cloud могут применяться следующие механизмы отказоустойчивости и катастрофоустойчивости (DR): Отказоустойчивость Уровень управления: использование RAFT-кластера Подсистемы виртуализауции с автоматическим перехватом управления в случае сбоя одного из серверов управления. Уровень гипервизоров и ВМ: настройка автоматического перезапуска ВМ на доступных серверах при сбоях (VM failover); поддержка RAID/ Ceph-репликации на уровне хранилища. Сетевой уровень: применение bonding/teaming сетевых интерфейсов; использование резервных маршрутов и SDN (например, с OVN) для отказоустойчивости L2/L3. Катастрофоустойчивость (Disaster Recovery, DR) Геораспределенность: возможность построения двух (или более) площадок, синхронно или асинхронно реплицирующих состояние и данные. Резервное копирование: использование RuBackup или внешних систем для регулярных бэкапов ВМ и конфигураций ПК Платформы Astra Cloud; поддержка хранилищ, устойчивых к сбоям (Ceph, iSCSI с зеркалированием). Сценарии DR: Cold Standby — подготовленный, но выключенный Кластер, запускаемый вручную; Warm Standby — периодическая репликация и частичный запуск; Hot DR — постоянно работающий дублирующий Кластер (возможен при наличии второй площадки).
	Можно ли считать Платформу гиперконвергентным (HCI) решением и/или гипервизором первого типа?	Платформа как гиперконвергентная архитектура (Hyper-Converged Infrastructure, HCI) Платформа Astra Cloud соответствует всем ключевым признакам гиперконвергентной архитектуры: Интеграция в одном программном контуре вычислений, хранения и управления: виртуализация KVM; хранение (через Ceph/iSCSI/ локальные LVM); управление — Подсистема виртуализации. Программная централизация и автоматизация: управление всеми ресурсами из единого интерфейса (GUI + API); поддержка шаблонов развертывания, биллинга, мониторинга и самообслуживания. Масштабируемость горизонтального типа: возможность масштабирования за счет добавления новых серверов без изменения архитектуры. Гибкость развертывания: поддержка как программных комплексов, так и ПАК-решений для ЦОД. Платформа Astra Cloud как система на гипервизоре первого типа Гипервизоры первого типа (bare-metal hypervisors) работают напрямую на оборудовании, без участия хостовой ОС. Это определение соответствует KVM в составе ОС Astra Linux: KVM в ОС СН Astra Linux Special Edition интегрирован на уровне ядра Linux (работает в ring 0) и не требует отдельной хостовой ОС, что делает его гипервизором первого типа; управляется через libvirt и взаимодействует напрямую с оборудованием по стандартам Intel VT-x и AMD-V. Таким образом, платформа использует KVM как типичный гипервизор первого типа, а Подсистема виртуализации функционирует как оркестратор над ним, не влияя на тип гипервизора.
	Какие основные механизмы обеспечения информационной безопасности реализованы в продукте и какие могут быть реализованы накладными средствами?	Реализованные в платформе (встроенные) механизмы ИБ: Аутентификация и авторизация: интеграция с ALD Pro (FreeIPA): поддержка Kerberos, LDAP; ролевая модель доступа (RBAC) на уровне платформы и API. Изоляция арендаторов (мультитенантность): изоляция сетей (VLAN/VXLAN), хранилищ и вычислений; отдельные квоты, шаблоны, пользовательские контексты. Журналирование и аудит: системный аудит действий пользователей, администраторов и сервисов; возможность централизованного экспорта логов в SIEM. Сетевые политики: использование firewall-правил (security groups) на уровне групп ВМ; поддержка защищенного доступа. Безопасность образов ВМ: проверка и контроль доступов к шаблонам и дискам; возможность использования подписанных и сертифицированных образов. Управление обновлениями: пошаговое обновление кластеров ПК СВ «Брест» без прерывания доступа; использование Astra Linux в качестве базовой сертифицированной ОС. Механизмы, которые могут быть реализованы дополнительно (накладные средства): Средства криптографической защиты (СКЗИ): подключение сертифицированных модулей (ViPNet CSP, Крипто-Про и др.) в ВМ; шифрование трафика между компонентами. Аппаратная доверенная загрузка. Интеграция с внешними DLP/SIEM-системами: через syslog/webhook/agent модели. Сегментация на уровне L3/L7: использование внешнего межсетевого экранирования, Web Application Firewall (WAF). Многофакторная аутентификация (MFA): через SAML, OTP-токены или внешние IdP. Анализ трафика и поведенческой активности: внедрение NDR/UEBA-решений для мониторинга внутриоблачной активности.