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

№	Вопрос	Ответ
	Реализация каких мер защиты информации 17 и 21 приказов ФСТЭК сертифицирована для ПК СВ «Брест», ОС Astra Linux Special Edition, ALD Pro, RuBackup, BILLmanager и других компонентов AIC?	ПК СВ «Брест» сертифицирован на соответствие «Требованиям по безопасности информации к средствам виртуализации» ФСТЭК России по 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 уровню доверия и на соответствие техническим условиям: Cертификат ФСТЭК России № 4830 от 26.07.2024 г. RuBackup сертифицирован на соответствие «Требованиям по безопасности информации, устанавливающим уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» (ФСТЭК России, 2020) — по 4 уровню доверия и на соответствие техническим условиям: Сертификат ФСТЭК России № 4879 от 25.11.2024 г. Компоненты BILLmanager, DCImanager, Astra Monitoring, Astra Automation на данный момент не планируются к сертификации. Прорабатываются меры защиты с помощью встроенных СЗИ и наложенных средств.
	Существует ли рекомендованный Группой Астра список совместимых с AIC наложенных средств защиты информации, cертифицированных и реализующих недостающие технические меры защиты при аттестации ИС, построенной на базе ПК СВ «Брест», ОС Astra Linux, BILLmanager, по требованиям 17 и 21 приказов ФСТЭК?	Для полноценного закрытия ряда мер в конкретной информационной системе (ИС) необходимо использование дополнительных СЗИ. При аттестации целевой ИС необходимо использовать сертифицированные СЗИ. Список дополнительных и рекомендуемых СЗИ формируется исходя из потребностей Заказчика. Однако есть перечень средств прошедших тестирование , на совместимость с ОС, которые потенциально можно рассматривать как дополнительные СЗИ в целевой ИС. Перечень совместимого ПО с ОС ALSE можно получить на портале Ready for Аstra. Также можно ознакомиться с перечнем межсетевых экранов для применения в виртуальной инфраструктуре в виде программного решения (МСЭ типа «Б»), в том числе совместно с программным комплексом «Средства виртуализации «Брест» (ПК СВ «Брест»).
	Верно ли утверждение, что использование OCFS2 (как и NFS) при развертывании ГИС не рекомендуется из-за отсутствия поддержки меток безопасности?	OCFS2 поддерживает метки безопасности, но на данный момент не рекомендуется к использованию в защищенном режиме, так как при определенной нагрузке приводит к возникновению ошибок. Подробнее об этом можно прочитать в статье о хранилищах на базе файловой технологии хранения. Кроме того, OCFS2 имеет ряд других ограничений (к примеру, для обслуживания данной файловой системы требуется отключения общего тома от всех серверов). Потому рекомендуется использовать драйвер Ceph или LVM_LVM. В ПК СВ «Брест» 3.3.3 реализован новый драйвер BREST_LVM, неимеющий недостатков драйвера LVM_LVM.
	Существует ли у AIC инструкция/рекомендации по приведению в безопасное состояние ОС Astra Linux, FreeIPA и ПК СВ «Брест»?	Для ОС Astra Linux Special Edition есть RedBook. Для ПК СВ «Брест» и FreeIPA могут быть применены рекомендации Astra Automation — Center for Information Security.
	Существуют ли публичные баг-трекеры систем ОС Astra Linux, FreeIPA и ПК СВ «Брест»?	На данный момент публичные Баг-трекеры для этих продуктов не реализованы. При необходимости, Пользователь может открыть тикет в личном кабинете.
	Существуют ли рекомендации/ решения по организации резервного копирования AIC?	Одним из компонентов AIC является подсистема резервного копирования — RuBackup. Данная подсистема применяется для резервирования как файлов, так и Баз Данных. Однако, средствами данной подсистемы резервируются только компоненты AIC. Резервное копирование элементов инфраструктуры AIC выполняется только в части копирования конфигурационных файлов и баз данных для фронтальных машин, серверов виртуализации и контроллеров домена. При установке AIC настраиваются сценарии для резервного копирования системных компонентов. При необходимости соответствия требованиям ФСТЭК в части резервного копирования, можно ознакомиться с методической документацией ФСТЭК 2014 «Меры защиты информации в государственных информационных системах».
	Существуют ли рекомендации/ решения по организации резервного копирования для пользовательской части?	Для выполнения резервного копирования пользовательской части требуется развертывание отдельного сервиса RuBackup.
	Существует ли у Группы Астра опыт/рекомендации по использованию KSC на базе ОС Astra Linux Special Edition без дополнительной установки ОС Windows?	Kaspersky Security Center (KSC) сертифицирован для использования с ОС Astra Linux: О наличии/отсутствии технической возможности установки KSC на инфраструктуру Заказчика следует узнавать у разработчиков KSC.
	Существуют ли у AIC готовые решения/рекомендации по биллингу ресурсов в ЦОД, которые можно использовать в аттестованном сегменте? Либо рекомендации к использованию API?	Сбор информации о потреблении вычислительных ресурсов, тарификации, выставлении счетов и контроль за ресурсами осуществляется при помощи встроенного в AIC Портала самоослуживания.
	Для аттестации ПК СВ «Брест» будет ли необходимость устанавливать антивирусное ПО непосредственно на хостовые ОС (фронтальные машины и гипервизоры)?	Для закрытия мер АВЗ (ФСТЭК 17) потребуется антивирус. ОС Astra Linux Special Edition и ПК СВ «Брест» не могут закрывать требования по антивирусной защите.
	Существует ли список рекомендованных/совместимых версий антивирусов для фронтальных машин, гипервизоров ПК СВ и серверов FreeIPA?	Узнать о совместимости ПО можно на портале Ready For Astra.
	Какие исключения требуется настроить в политиках АВ?	За рекомендациями по настройке исключений следует обращаться к разработчикам выбранного Антивируса.
	Какие способы георезервирования поддерживает платформа?	Реализация способов георезервирования представлена в разделе СЦ: Сценарии и варианты аварийного восстановления данных.
	Возможно ли обновление на актуальные версии ОС Astra Linux (например с 1.7 на новые версии), RuBackup, ALD Pro, ПК СВ «Брест». Остаются ли бессрочные права на данные версии после обновления?	Возможность обновления на следующие версии предусмотрена и ограничена сроком действия приобретенной лицензии.
	Существует ли механизм импорта правил межсетевого экрана на платформу?	Функционал поддерживается. Для реализации импорта правил можно использовать ПО UserGate.
	Какие виды изоляции предусмотрены в платформе?	Разграничение возможно с помощью управления логическими объектами на уровне Портала самообслуживания. Предполагается поддержка на уровне Тенантов, Информационных Систем, Ландшафтов и Групп ВМ.
	Что из себя представляет механизм миграции на AIC?	Миграция с ПК СВ «Брест» на AIC возможна с установкой дополнительных компонентов. Требуется обследование и проектный подход (обновление компонентов до совместимых версий и миграция данных). Необходимо будет доустановить компоненты в зависимости от редакции: Базовой (доустанавливаются ALD Pro, RuBackup, BILLmanager, Astra Monitoring) или Стандартной (входят все компоненты Базовой редакции + Astra Automation).
	Какие способы установки предлагаются платформой AIC?	Основной инструмент установки AIC — Графический Инсталлятор.
	Сможет ли Заказчик использовать RuBackup, входящий в AIC, для целей резервного копирования других элементов своей инфраструктуры, не входящих в AIC?	Все компоненты продукта могут использоваться только для функционирования самого AIC, согласно EULA не предполагается отдельное использование компонентов для нужд Заказчика.
	Какие пользовательские интерфейсы предоставляет платформа?	Для пользователей — Портал самообслуживания; для администраторов — Портал самообслуживания и Портал администратора в подсистеме виртуализации.
	Будут ли подсисетмы AIC работать на СУБД Tantor?	Реализация данного функционала ожидается в релизе AIC 2.0 (ОС ALSE 1.8 и ПК СВ 4.0).
	Укажите текущие версии компонентов AIC. Будет ли AIC работать на новых версиях?	Текущие версии компонентов, совместимых с AIC 1.3: ОС СН ALSE — 1.7.7; ПК СВ «Брест» — 3.3.3; ALD Pro — 2.4.1; RuBackup — 2.4; BILLmanager Hosting&Cloud — 6.121; Astra Monitoring — 0.7.1. DCImanager - 6 Новые версия компонентов и их совместимость тестируется технической командой AIC.
	Какая частота выхода обновлений (очередных, оперативных, срочных) предусмотрена для ОС и других компонентов AIC?	Выпуск релизов AIC производится один раз в полгода (Май и Октябрь). Выход очередных, оперативных, срочных обновлений производится по мере готовности. Обновление производится единым пакетом для всех компонентов AIC сразу. Обновление отдельных компонентов AIC не предусмотренно.
	Возможно ли обновление без остановки сервиса?	Платформа предусматривает возможность обновления без остановки сервиса. Крайне важно проводить тестовое обновление на тестовом стенде, чтобы точно спрогнозировать возможность реализации различных сценариев обновления и минимизировать риски.
	Будет ли синхронизирован релизный цикл AIC и ПК СВ «Брест»?	Нет. Продукт ПК СВ «Брест» продолжает развиваться как отдельный продукт со своей дорожной картой. AIC использует ПК СВ в качестве средства управления виртуализацией.
	Возможна ли интеграция существующего контроллера домена (SAMBA, MS AD , FreeIPA\ALDPro) с AIC?	Входящая в AIC подсистема ALD Pro позволяет через механизмы доверительных отношений интегрироваться с различными вариантами контроллеров домена.
	Планируется ли в будущем блокировка отдельных веб-интерфейсов компонентов AIC?	На данный момент блокировка доступа к Веб-интерфейсам компонентов AIC для администраторов платформы не планируется. В будущих версиях планируется организации полноценного Wеb-SSO.
	Когда в платформе AIC планируется поддержка ОС СН ALSE 1.8?	Последний компонент, который будет переходить на ОС СН ALSE 1.8 — ALD Pro. После его обновления предполагается и обновление AIC.
	Планируется ли в новых версиях AIC поддержка VxLAN через BGP EVPN для организации взаимодействия между ЦОД-ами?	В AIC 1.3 реализован функционал использования динамических протоколов маршрутизации OSPF и BGP в виртуальном маршрутизаторе. Для реализации взаимодействие между ЦОД-ами предполагается использование связки VLAN/VXLAN на виртуальном маршрутизаторе при дополнительной настройке оборудования Заказчика.
	Как выглядит процесс обновления платформы AIC?	Подробно о процессе обновления AIC описано в разделе: Обновление AIC с версии 1.2 до версии 1.3.
	Есть ли поддержка внешней авторизации OIDС/SAML, к примеру keycloak/blitz?	В платформе планируется IAM-компонент, который будет поддерживать OIDС/SAML.
	Есть ли поддержка использования 2FA внешний/внутренний?	Механизмы 2FA могут быть реализованы: Средствами ОС СН ALSE; Средствами BILLmanager. <https://www.ispsystem.ru/docs/bc/nastrojki-billmanager/nastrojki/dvuhetapnaya-autentifikatsiya/>
	Перечислите основные функциональные возможности подсистемы мониторинга в платформе AIC.	В AIC инструменты мониторинга развиваются с прицелом на практическую пригодность в продуктивных средах. Система мониторинга включает в себя следующие уровни: Мониторинг инфраструктуры. Используется для сбора и визуализации метрик по узлам виртуализации, ВМ, сетям и хранилищам. Поддерживается отображение нагрузки CPU, памяти, I/O, сетевых интерфейсов, а также алерты по пороговым значениям. Графики, истории значений и экспорт данных доступны из интерфейса. Мониторинг состояния подсистем платформы. Отслеживается работоспособность ключевых компонентов облака (ПК СВ «Брест», ALD Pro, BILLmanager, RuBackup и др.). Возможна интеграция с внешними системами оповещения и SIEM. Поддержка инцидент-менеджмента и событийной корреляции. Все события могут быть логированы, агрегированы и направлены в централизованные хранилища. Также предусмотрена возможность интеграции с внешними системами Service Desk. Гибкость настройки. Поддерживаются кастомные дашборды, метрики, технические шаблоны, настраиваемые алерты и сценарии реакции. Все это позволяет обеспечить проактивный подход к поддержанию доступности, быструю диагностику проблем и соответствие требованиям к наблюдаемости, в том числе для защищенных систем.
	Какая стратегия миграции предлагается при переходе на Ваш продукт?	Переход на платформу AIC должен быть поддержан тщательно разработанной стратегией миграции, адаптированной под конкретные условия Заказчика. Наиболее часто применяются следующие стратегии миграции: Горизонтальный перенос (cold migration) — виртуальные машины переносятся с предварительным отключением, что минимизирует риски, но влечет за собой плановое прерывание сервиса. Этот подход оптимален при переносе ВМ вне пиковых часов или в выходные дни; Миграция через промежуточное хранилище — применяется при больших объемах данных. ВМ копируются на общий репозиторий, затем разворачиваются в AIC. Это позволяет сократить время простоя до минимума; Live migration (для KVM совместимых сред) — возможна при определенных условиях: схожие версии гипервизоров, одинаковый формат виртуальных дисков, наличие общей СХД. Применяется точечно для систем с высокими SLA; Пошаговая миграция с репликацией и переключением — наиболее гибкий и безопасный подход. Создаются реплики ВМ в AIC, после чего производится финальная синхронизация и переключение. Позволяет держать сервисы доступными до самого момента переключения.
	Насколько длительное прерывание сервиса может быть при миграции больших виртуальных машин на AIC?	Ожидаемое время прерывания: Для больших виртуальных машин (100-500+ ГБ), в зависимости от метода и инфраструктуры: при холодной миграции: от 10 до 60 минут, включая подготовку; при использовании репликации с переключением: менее 5 минут реального прерывания (в момент cutover); при Live migration (если применимо): до 1 минуты. Факторы, влияющие на длительность миграции: пропускная способность сети между старой платформой и AIC; производительность хранилищ; способ хранения дисков (qcow2, raw, Ceph и др.); наличие онлайн-доступа к гипервизору и форматам метаданных. Время на перенос ВМ может значительно варьироваться в зависимости от реализованной Заказчиком инфрастуктуры и выбранного режима миграции.
	Какие механизмы обеспечения отказоустойчивости и катастрофоустойчивости могут применяться для повышения доступности?	В контексте повышения доступности облачной платформы AIC могут применяться следующие механизмы отказоустойчивости и катастрофоустойчивости (DR): Отказоустойчивость Уровень управления: использование RAFT-кластера ПК СВ «Брест» с автоматическим перехватом управления в случае сбоя одного из фронтендов. Уровень гипервизоров и ВМ: настройка автоматического перезапуска ВМ на доступных хостах при сбоях (VM failover); поддержка RAID/ Ceph-репликации на уровне хранилища. Сетевой уровень: применение bonding/teaming сетевых интерфейсов; использование резервных маршрутов и SDN (например, с OVN) для отказоустойчивости L2/L3. Катастрофоустойчивость (Disaster Recovery, DR) Геораспределенность: возможность построения двух (или более) площадок, синхронно или асинхронно реплицирующих состояние и данные. Резервное копирование: использование RuBackup или внешних систем для регулярных бэкапов ВМ и конфигураций ПК AIC; поддержка хранилищ, устойчивых к сбоям (Ceph, iSCSI с зеркалированием). Сценарии DR: Cold Standby — подготовленный, но выключенный Кластер, запускаемый вручную; Warm Standby — периодическая репликация и частичный запуск; Hot DR — постоянно работающий дублирующий Кластер (возможен при наличии второй площадки).
	Можно ли считать AIC гиперконвергентным (HCI) решением и/или гипервизором первого типа?	AIC как HCI (Hyper-Converged Infrastructure) AIC соответствует всем ключевым признакам гиперконвергентной архитектуры: Интеграция в одном программном контуре вычислений, хранения и управления: виртуализация KVM; хранение (через Ceph/iSCSI/ локальные LVM); управление — ПК СВ «Брест». Программная централизация и автоматизация: управление всеми ресурсами из единого интерфейса (GUI + API); поддержка шаблонов развертывания, биллинга, мониторинга и самообслуживания. Масштабируемость горизонтального типа: возможность масштабирования за счет добавления новых узлов без изменения архитектуры. Гибкость развертывания: поддержка как программных комплексов, так и ПАК-решений для ЦОД. AIC как система на гипервизоре первого типа Гипервизоры первого типа (bare-metal hypervisors) работают напрямую на оборудовании, без участия хостовой ОС. Это определение соответствует KVM в составе ОС Astra Linux: KVM в ОС СН Astra Linux Special Edition интегрирован на уровне ядра Linux (работает в ring 0) и не требует отдельной хостовой ОС, что делает его гипервизором первого типа; управляется через libvirt и взаимодействует напрямую с оборудованием по стандартам Intel VT-x и AMD-V. Таким образом, платформа AIC использует KVM как типичный гипервизор первого типа, а управляющая надстройка ПК СВ «Брест» функционирует как оркестратор над ним, не влияя на тип гипервизора.
	Какие основные механизмы обеспечения информационной безопасности реализованы в продукте и какие могут быть реализованы накладными средствами?	Реализованные в платформе AIC (встроенные) механизмы ИБ: Аутентификация и авторизация: интеграция с 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-решений для мониторинга внутриоблачной активности.