Comments 61
комплексное применение этих СЗИ (особенно в режимах их функционирования «Усиленный» или «Максимальный») обеспечивает реальную защищенность от основных угроз безопасности информации.
А что с неосновными (какими?) угрозами безопасности информации?
Основныее угрозы перечислены в методике ФСТЭК России:
СБОР ИНФОРМАЦИИИ
ПОЛУЧЕНИЕ ПЕРВОНАЧАЛЬНОГО ДОСТУПАВНЕДРЕНИЕ И ИСПОЛЬЗОВАНИЕ ВРЕДОНОСНОГО КОДА
ЗАКРЕПЛЕНИЕ В СИСТЕМЕ И СЕТИ
УПРАВЛЕНИЕ ВРЕДОНОСНЫМ КОДОМ И КОМПОНЕНТОМПОВЫШЕНИЕ ПРИВИЛЕГИЙ
СОКРЫТИЕ ДЕЙСТВИЙ
ПОЛУЧЕНИЕ ДОСТУПА К ДРУГИМ КОМПОНЕНТАМ
СБОР И ВЫВОД ИНФОРМАЦИИ
НЕПРАВОМЕРНЫЙ ДОСТУП ИЛИ ВОЗДЕЙСТВИЕ
Непонятно зачем было отключать selinux в базовой версии, только ради того, чтобы во второй версии сделать его аналог платным, и чтобы пользователи не могли его сами настраивать в бесплатной, типа: хочешь защиты - плати, а не используй встроенный бесплатный функционал? Или я не так прочитал.
Архитектура безопасности системы изначально должна выстраиваться правильно. Здесь основное качество не «платный или бесплатный» механизм защиты, а доверенный, верифицированный или нет. При этом с учетом того, что возможен переход из режима «Базовый» (путем приобретения соответствующей лицензии) в режим «Усиленный» или «Максимальный», то включать SELinux в дистрибутив крайне не желательно (его потом уже просто не отключишь, и прикладное ПО в работающей системе не перенастроишь).
Так а никто и не говорит, про перенастройку и т.д. Хочешь продавать платную защиту в расширенной версии, окей, никто не запрещает, кто захотел - купил. Но тут в базовой версии просто выпилили selinux как таковой, как я понял оставив эту версию без малейшей защиты намекая на то, что если нужно защита, то будьте добры купить лицензию и перейти на другую версию - там вам будет защита наша. Я не говорю что она плохая или нет. Просто сейчас получается так, что человека просто принуждаю переходить на платную версию, потому что в базовой версии ее выпилили, хотя кому-то было бы достаточно и ее, но человека лишают возможности.
Настройка SELinux в графике для пользовательских приложений, да еще в режимах запуска одним пользователем приложения под разными уровнями конфиденциальности очень проблематична.
Политика TE тут неприменима, а в режиме MLS слишком много проблем, в том числе при работе с доменом (каталогом пользователей).
Об этом писали в одной из предыдущих статей, вот пример проблем selinux в графике:https://habrastorage.org/getpro/habr/post_images/e12/7db/1a1/e127db1a1bded19abb9467212ef00330.png
Совершенно верно, SELinux за счет применения многочисленных настроек правил управления доступом (часто называемых политиками) позволяет закрыть отдельные изъяны дискреционного Linux. При этом не дается обоснования, что это в целом будет хорошо, т. е. что всем этим политикам в совокупности можно доверять. В результате нет объективной оценки — действительно без SELinux все плохо, или только иногда и в каких-то отдельных случаях. По крайней мере мнение, что без SELinux использовать Linux нельзя, не является самым распространенным.
Для сравнения, описанные в статье механизмы МКЦ и ЗПС действительно выводят защиту на качественно более высокий уровень, во-первых, тому есть обоснование, во-вторых, практический опыт это подтверждает, в-третьих, упомянутые в статье чем-то похожие механизмы MIC и UAC в ОС семейства Windows яркий тому пример.
А у ОС Astra Linux Special Edition в режиме «Базовый» кроме отмеченных в статье механизмов защиты (изоляция процессов, защита памяти, регистрация событий безопасности и др.) есть еще другие полезные качества, например, техническая поддержка, документация, обучение и т. д., для многих это важно.
Это что. Получается что это просто целочисленный атрибутик на каждом файле от 0 до 63 и распиханные по коду ядра сравнения, которые запрещают бинарям с циферкой выше читать файл с циферкой ниже? Кстати а случайно то же самое на селинуксе аналогично не реализуется ли? Там же тоже атрибутики. Контекст селинукса это не аналог мандата ли в некотором роде?
ЗЫ и да, винду с её юаком приводить в пример это вообще ржака.
а что смешного в сравнении аналогичных подходов к контролю целостности?
почитайте как это работает в Windows - ровно те же самые уровни целостности:
"Уровень целостности является мерой доверия. Приложение с высоким уровнем целостности — это приложение, в котором выполняются задачи по изменению системных данных, например приложение для разбивки диска на разделы. Приложение с низким уровнем целостности выполняет задачи, которые могут потенциально подвергать риску операционную систему (например, веб-браузер). Приложения с более низким уровнем целостности не могут изменять данные в приложениях с более высоким уровнем целостности."
В указанных в некотором смысле аналогах механизму МКЦ в ОС Astra Linux Special Edition механизмах MIC и UAC в ОС семейства Windows ключевым является первый — MIC (Mandatory Integrity Control). Однако их вернее указывать в паре, т. к. механизм UAC (User Account Control) показывает, что только меток целостности на файлах, каталогах, процессах и соответствующих проверок этих меток при предоставлении доступов не достаточно для полнофункциональной реализации МКЦ. Важно, например, надежно защитить процедуру и интерфейс перехода на высокий уровень целостности, а это делает как раз UAC.
Не совсем так. Говоря про уровни целостности в Windows лучше обратиться к статье Mandatory Integrity Control Mandatory Integrity Control (https://docs.microsoft.com/en-us/windows/win32/secauthz/mandatory-integrity-control). По умолчанию там уже используются не менее 7 различных уровней (https://docs.microsoft.com/en-us/windows/win32/secauthz/well-known-sids): SECURITY_MANDATORY_UNTRUSTED_RID, SECURITY_MANDATORY_LOW_RID и т.д. При этом администратор может задействовать в ряде случаев и промежуточные значения уровней, правда это редко где применяется, во многом из-за того, что удобнее всего использовать уже встроенные правила управления доступом вместо написания собственных политик. В этом плане встроенная реализация МКЦ в ОС Astra Linux обеспечивает достойную замену, а в ряде случаев предоставляет и более гибкие механизмы администрирования.
Согласен, что некоторые технические аспекты в статье изложены не достаточно глубоко. Это сделано специально, чтобы сделать ее удобной для прочтения широкого круга специалистов. При этом статья вводная и, надеюсь, не последняя. Два конкретных примера (с иллюстрацией на рис. 2 и 3) в статье есть. В ней есть ссылки на ряд источников, например, учебное пособие (http://www.techbook.ru/book.php?id_book=1137) или ГОСТ Р 59453.1-2021, где основные свойства МКЦ и МРД описываются. Есть другие источники, например, учебное пособие – http://www.techbook.ru/book.php?id_book=1075.
Однако, понимаю, что разъяснений и профильной литературы маловато, поэтому мы работаем над этим. Например, с коллегами подготовили (надеюсь, летом будет издано) учебное пособие «Основы безопасности операционной системы Astra Linux Special Edition. Управление доступом». В нем первая глава посвящена управлению доступом в режиме «Базовый», вторая - «Усиленный», третья - «Максимальный», а четвертая — лабораторному практикуму.
Также отмечу, что было бы очень хорошо, чтобы специалисты по возможности обращались и к теории информационной безопасности, которая успешно развивается и внедряется в практику более 50 лет. Тогда бы отдавалось должное уважение классикам, внесшим фундаментальный вклад в эту теорию, таким как Bell D.E., LaPadula L.J., Biba K.J. и др. Написанные ими в 70-е годы прошлого столетия формальные (математические) модели были впервые в истории ориентированы на реальную «живую» систему — ОС Multics. И в этих описаниях было много конкретных примеров, как «целочисленные атрибуты» или «циферки» (метки конфиденциальности и целостности) используются для реализации МКЦ и МРД.
В итоге, сходство SELinux, AppArmor и механизмов защиты в ОС Astra Linux Special Edition весьма отдаленное. Например, SELinux и AppArmor совершенно не реализуют мандатный контроль целостности (МКЦ).
Возможно какие-то преимущества есть, я не отрицаю, но чтобы это юзер понял, это надо разъяснить) может, там, с точки зрения удобства эксплуатации. Но вот я даже щас документацию какую-то нашёл и почитал astralinux.ru/products/astra-linux-special-edition/relizyi/smolensk/dokumentacziya/rukovodstvo-po-kompleksu-sredstv-zashhityi.-chast-1.pdf и как-то не возникло ощущения простоты)
Действительно, и там LSM-модуль (SELinux) и там (PARSEC в ОС Astra Linux Special Edition), и тот и другой чего-то на основе меток проверяют, тогда в чем разница? А разница огромная. В первую очередь лежащие в основе МКЦ (и МРД) в PARSEC именно ясные и четкие правила управления доступом. Их не много, большая часть из них есть в ГОСТ Р 59453.1-2021. В нашем случае, например, правило – низкоцелостный процесс (даже от имени суперпользователя root) не должен модифицировать высокоцелостные (системные) файлы, или, нельзя запустить высокоцелостный процесс из низкоцелостного бинарного файла. Понять главный принцип МКЦ — нельзя с меньшего уровня целостности модифицировать или захватывать управление над компонентами большего уровня целостности, не составляет большого труда как пользователям, так и администраторам ОС. В SELinux для выражения подобных правил требуется многочисленные (исчисляемые в совокупности сотнями) труднопонимаемые отдельные политики.
И конечно надо еще раз отметить, что в случае SELinux в его безопасность вообще, и конкретных наборов политик в частности, надо по сути верить на слово. А безопасность PARSEC подтверждается, начиная с развитой формальной модели, и заканчивая всесторонним анализом и дедуктивной верификацией его кода, о чем подробнее можно посмотреть в нашей статье про методологию разработки безопасного системного ПО (https://ispranproceedings.elpub.ru/jour/article/view/1449).
Некоторая сложность документации объясняется тем, что ОС общего назначения достаточно сложный продукт, в ней велико разнообразие компонент (разные файловые системы, файлы и каталоги разных видов, сокеты и т. д.) доступом к которым надо управлять. Поэтому в документации (на то она и документация) приходится описывать все эти случаи и особенности.
Понимая это, мы стремимся ситуацию исправить. На это направлены и данная статья, и упомянутые в предыдущих комментариях учебные пособия, которые либо вышли, либо готовятся к выходу.
Наверное, потому обычно SELinux обычно отключают, за редким исключением фиксированного сценария применения какого-то сервиса. Переписывать (а уж тем более разрабатывать политики с нуля) обычно никто желанием не горит и таких специалистов на мировом рынке не так уж и много. А уж специалистов, которые имеют опыт и знания верификации политик SELinux вообще днем с огнем не сыскать.
Ну в случае парсека аналог "правил" это собственно сами метки, как их расставишь, так и будет работать защита. Ну они попроще, конечно, тут понятно. Хотя наверно можно и в селинуксе сделать некий предустановленный набор уровней секретности и так же все ими помечать)
А статья сводится к тому, что прогнали статическим анализатором? Если на то пошло, как гарантируется то, что какой-то системный вызов не выдаст случайно более секретные данные?)
Ну и я короче к тому, что реальные преимущества, которые есть, нужно в юзеро-понятном виде показывать, а то все эти статьи и книжки - это тяжело для восприятия)
Если книжки тяжелы для понимания, то вот хороший вариант - видео доклады.
Для понимания того, что и для чего делается, рекомендую вам ознакомиться к хорошим докладом Дениса Колегова (Positive Technologies), на тему моделирования безопасности управления доступом и инфопотоками, там все понятно разложено по полочкам:
Послушав доклад, вы поймете, что и зачем делается в рамках Астры.
Если вас интересует сравнение архитектуры и возможностей Parsec и Selinux, то вот вам доклад Виктора Кулямина, ИСП РАН, на тему: Архитектура и возможности средств защиты информации на основе LSM — SELinux, AstraLinux и др.:
https://www.youtube.com/watch?v=AtVjWAm_s9Q
Также можете послушать в дополнение доклад на тему анализа сложности реализации и верификации средств защиты информации в различных архитектурах защищенных ОС Linux на OS Day сотрудника ИСП РАН Хорошилова Алексея. Так вы поймете как проверяются СЗИ:
Статический анализ программного кода не позволяет проверить логику работы обсуждаемых в статье механизмов управления доступом. Этот анализ в основном направлен на выявление типичных «программистских» ошибок (деление на ноль, выход за границы массива, разыменование нулевого указателя и т.п.) и поэтому его применяют очень широко и не только при разработке сертифицированных СЗИ. Ведь никому ненадежное сбоящее ПО не нужно.
В части того, что системный вызов может случайно что-то «секретное» выдать, то, как правило, это не происходит. Хотя проблема такая есть, она решается в рамках анализа скрытых каналов по памяти и по времени (что это такое, можно посмотреть в ГОСТ Р 53113.1-2008 или с теорией и практическими примерами из «жизни» ОС в учебном пособии - http://www.techbook.ru/book.php?id_book=1137). Дело это конечно сложное, но мы работаем над этим, и результаты есть — они в основном реализованы в нашей ОС в режиме «Максимальный» в механизме мандатного управления доступом (МРД).
В том и преимущество, что средства защиты информации ОС Astra Linux работают "прозрачно" для пользователей и для большинства ПО, непрерывно обеспечивая все заложенные в них еще на этапе разработки ОС правила управления доступом (МКЦ, ЗПС, МРД и т.д.). Т.е вне зависимости от типа ПО и выполняемых им функций, его системные компоненты будут защищены от непреднамеренной модификации за счет обладания высоким мандатным уровнем целостности (МКЦ), а пользовательские данные сохранены и доступны только на соответствующем пользователю уровне конфиденциальности (МРД). Например, не важно, используете ли вы для редактирования файлов vim, nano, mcedit, kate или что-то еще и от имени какого пользователя вы это делаете - СЗИ отработают в любом случае одинаково на основе одних и тех же "вшитых" правил.
Контексты (политики) же SELinux (AppArmor), например, могут и задаются для каждого ПО отдельно (для AppArmor - профиль ПО, для SELinux - домены процессов и типы файлов, соответствующие данному ПО, если совсем упрощенно). При этом нет гарантий, что разработчик этого ПО или администратор действительно задал и задал вообще правильные правила в рамках данных контекстов (политик), что эти контексты непротиворечивы между собой и т.п, что приводит к ситуациям, представленным в скринах по ссылке в комментариях выше. И тут проблема даже больше не в том, что были излишне запрещены какие-то доступы, а наоборот - что в попытках избежать подобных ситуаций, были предоставлены чрезмерно высокие полномочия. Да и осуществлять поддержку систем, где используются политики, сконфигурированные на "свой вкус и лад" (при этом без гарантии корректности), куда сложнее...
все верно, при этом простота работы СЗИ в Астре подтверждается тем, что под мандатное управление доступом в Астре разработано довольно большое количество тяжелых приложений, например 1С Предприятие с поддержкой мандатного управления доступом.
Пройти такой подвиг под политики SELinux пока никто не решился.
Так есть же все рекомендации и руководства: документация для разработчиков
Дополнительно еще готовим контрольные примеры в коде, скоро опубликуем уже
// даже чего-то про «лападулу» в документации селинукса пишут
В самом общем виде можно с этим согласиться. Потенциально после доработки SELinux может начать делать то, что умеет PARSEC, например, реализовывать МКЦ. Но ключевым здесь все равно останется вопрос доверия, т. е. почему безопасности решений на основе SELinux можно доверять. На чем строится доверие несколько слов сказано в статье и в комментариях выше.
Здесь добавлю, что есть еще одно препятствие для применения SELinux во многих важных на практике случаях. Оно кроется в архитектуре самого SELinux — наборы подготовленных для него политик перед загрузкой в соответствующий LSM-модуль ядра ОС компилируются в бинарный формат. Это затрудняет применение SELinux в составе сертифицированных средств защиты информации (СЗИ), где возможность модификации исполняемого кода в процессе эксплуатации СЗИ четко регламентирована. Реализация рассматриваемой технологии в SELinux может потребовать запрета на изменение заранее подготовленных разработчиком СЗИ политик, что не удобно и не гибко (например, при эксплуатации СЗИ может быть запрещено корректировать политики управления доступом при установке нового ПО).
Ну про сертифицированные то понятно, что это основной смысл существования астры, интересовало что с точки зрения юзера)
Если приглядеться, для пользователя в этом и есть вся прелесть простых, но надежных и научно обоснованных правил управления доступом, которые реализованы в наших МКЦ и МРД. Ведь как хорошо и удобно, что даже если нарушителю удастся «подсунуть» высокоцелостному «красному» администратору зараженный вирусом исполняемый файл, то администратор его все равно не запустит, т. к. нарушитель сможет это сделать только на низком уровне целостности. При этом «красному» администратору ни о чем таком даже думать не надо, ОС все сделает. Или о помеченных высоким уровнем целостности системных каталогах (/bin, /etc и т. д.) также можно не беспокоиться, на то как в них права rwx расставить время не тратить. ОС сама уровни целостности на системные каталоги и файлы правильно расставит и их защитит — у нее для этого есть ясные и четкие правила. Таких примеров много.
А быть сертифицированной — это не основной смысл существования ОС Astra Linux Special Edition. Это только часть общей задачи - быть лучше, надежнее и безопаснее.
Еще не проверял этот вариант в Астре. Но хочу спросить. Как обстоять дела с безопасностью, если например сделать образ live линукса и загрузиться с него, где установленная Астра. Таким образом можно получить доступ к жесткому диску и его данным или будет отказано в доступе?
Таким образом можно получить доступ к жесткому диску
тогда получается, что можно скопировать или прочесть информацию с жесткого диска (на разных дистрибутивах это было проверено). А какие методы защиты применяются в Астре против этого способа? Например, криптография используется для защиты папок и файлов?
Можно использовать шифрование, можно средства доверенной загрузки - все, что угодно и все что применяется сейчас для таких типов угроз, как загрузка с внешнего носителя
А в Астре это есть ?
Да, начиная с применения штатного защитного преобразования данных и встроенных утилит шифрования, в том числе на основе ГОСТовых алгоритмов, заканчивая применением модулей доверенной загрузки и специализированных криптографических средств.
В Астре есть все эти возможности, в том числе можно сразу при инсталляции задать использование томов LVM с применением LUKS
LVM есть и в других дистрибутивах. так в чем же заключается безопасность Астры от других дистрибутивов? Была ли она протестированная хакерскими сообществами или независимыми организациями или сообществами по безопасности?
Да, мы проводим такие проверки по коммерческим контрактам. Это позволяет нам непрерывно совершенствовать решения по безопасности.
спасибо за ответ. в таком случаем возникает спорная ситуация. Если нету публичных независимых результатов, тогда нет возможности говорить надежная система или нет. А что делать пользователю, если в процессе работы он обнаруживает уязвимости в Астре?
На ОС Astra Linux Special Edition поставлено уже более миллиона лицензий, что может говорить о достаточной апробации и публичности анализа ее надежности и безопасности на практике. Кроме того, она активно поставляется вузам для учебных и научных целей, где несомненно также подвергается исследованиям ее безопасности.
Также мы заключаем частные договоры на исследования Astra Linux с частными компаниями, специализирующимися на пентесте и исследованиях на предмет наличия уязвимостей.
Кроме того, в процессе сертификационных исследований независимой испытательной лабораторией регулярно проводится довольно основательное тестирование на проникновение.
Я это все к тому, что процесс выявления проблем в Astra Linux выстроен на очень серьезном уровне. Никто не говорит, что невозможно выявить уязвимость - их выявляли и будут выявлять, но мы стараемся их выявить первыми и оперативно устранить. Как и любой другой ответственный вендор.
Именно поэтому новые оперативные обновления в Astra Linux не просто закрывают выявленные уязвимости, но и корректируют архитектуру безопасности ОС в целом, в том числе, благодаря вышеперечисленным работам и исследованиям.
Подробный рассказ о том, как ищутся и выявляются уязвимости в Astra Linux, можно увидеть здесь: https://youtu.be/Zz9zOj9Z6SE?t=14383
Сама презентация из доклада тоже выложена: https://www.tbforum.ru/hubfs/TBF/2022/Presentations_LIVE/Фокин_TBF_2022_hall4_1602.pdf?hsLang=ru
Сообщить о выявленной уязвимости в Astra Linux можно через соответствующую форму: https://astralinux.ru/support/bug-report
Если собираетесь использовать серьезные средства криптографической защиты, придется получать соответствующую лицензию ФСБ (спокойно, мальчики, вами занимается другое управление этой организации ;)).
Так что, с защитой от загрузки с внешнего носителя не так все просто.
да, поэтому сейчас популярность программных СДЗ выросла, например, ViPNet SafeBoot
Да и ещё морока с проверкой работоспособности конкретной матиринки после того как ее BIOS слегка «усовершенствовали» некие умельцы.
Оптимальный вариант, на мой взгляд, своя системная плата и свой BIOS с встроенным сертифицированным СДЗ. Кажется, «Крафтаэй» что-то такое делал.
много лет работало с иностранными решениями, например, ОС Microsoft Windows
Эта, а Линукс отечественный, значить?
Astra — отечественный дистрибутив Linux
Плюс к этому, в основе ОС лежит не просто открытое общедоступное ядро Linux - для обеспечения качества и доверия к нему прилагаются немалые усилия со стороны отечественных специалистов.
Спасибо за дополнение. Стоит отметить, что компоненты собственной разработки решают ключевые задачи обеспечения безопасности и возможностей взаимодействия с графическим интерфейсом.
Серверы-то успели закупить или теперь на базе JINGSHA всё будет собираться?)
Астралинуксы, РЕДОСы, Росы, Альты, etc готовы к внедрению "российского" ядра от ИСП РАН, а участвовать в процессе разработки будут?
Сборка нашего дистрибутива всегда осуществлялась на собственных серверных мощностях
Вопрос был касаемо статьи "Создание российской ветки ядра Linux", где для реализации проекта заявлено 4 сервера.
Ну и от вас хотелось бы услышать по второй части, если вдруг когда-нибудь таки создадут российскую ветку ядра Linux, то вы готовы перейти на него? или может непосредственно принимать участие в разработке планируете, есть у вас специалисты которые могут разрабатывать ядро?)
Конечно, есть специалисты. Ведь в Астре используются собственные LSM и LKM модуля ядра, и ядерщики, безусловно, есть в штате. Как без них разрабатывать собственные СЗИ, работающие на уровне ядра ОС?
Часть ответов дает комент ниже) По серверам - думаю, этот вопрос уже успешно решен.
В Астре естественно готовы и внедрять и полноценно участвовать как в этом, так и во многих других, в том числе совместных, проектах. В ОС Astra Linux большинство СЗИ изначально внедряются на уровне ядра ОС, так что и соответствующие разработки уже давно ведутся.
Ежели на форуме астры не хотят отвечать по поводу судьбы бесплатного "Common Edition" - отвечайте тут - какая судьба уготована ей ?
Зоопарк ПО, да часть программ будет из ваших подписанных репов, но часть задач придётся автоматизировать скриптами и самописным ПО, а кое-где и wine с древним софтом применить.
В связи с этим вопросы.
1. ЗПС хочется сохранить на больших объемах техники, чтобы никакой левый bash скрипт не запустился из /home или /tmp пользователя. Нужно удобно Централизованно добавлять разрешения для серверов и ПК на запуск программ и скриптов. Не только из ваших репов, но и своих наработок. Применять гибкие политики или профили разрешений. (Эти сидят в асутп — поджать сильнее, эти админы — дать разрешение для софта администрирования, эти в интернете — разрешить только браузеры) Это есть?
2. Нужна Централизованная отчётность о попытках запуска посторонних программ, скриптов с целью своевремменого реагирования на инцидент. Это есть?
Если есть, где почитать.
Все управление СЗИ в Astra Linux осуществляется путем внесения значений в конфигурационные файлы. Для управления этими настройками есть утилиты CLI и GUI.
На данный момент централизованное управление настройками осуществляется при помощи средств управления конфигурацией: ansible, puppet, saltstack (как раз путем внесения изменений в конфигурационные файлы или их разливка из архива конфигураций).
Централизованный аудит событий в Astra Linux на данный момент осуществляется через Zabbix, события аудита довольно гибко настраиваются. Настройка Zabbix в Astra Linux описана в эксплуатационной документации и на нашей wiki.
Но понятно, что ваш вопрос по сути, про аналог появления групповых политик. Этот инструментарий сейчас разрабатывается в рамках нашего проекта ALD Pro - решения для централизованного управления объектами организаций различного масштаба. Там как раз и групповые политики и единая консоль управления, мониторинга и так далее.
это мой не правильный комментарии - разобрался с Вопросом :)
Преимущества использования СЗИ в ОС Astra Linux Special Edition