Обзор САКУРА 3, комплекса для контроля и мониторинга удалённых рабочих мест

1. Введение
2. Функциональные возможности САКУРА 3
   1. 2.1. Назначение профиля РМ
   2. 2.2. Проверка РМ и реагирование на нарушения
   3. 2.3. Использование сценариев
   4. 2.4. Интеграции
   5. 2.5. Инвентаризация
3. Архитектура САКУРА 3
   1. 3.1. Механизмы взаимодействия
   2. 3.2. Отказоустойчивость
4. Системные требования САКУРА 3
5. Применение САКУРА 3
   1. 5.1. Агентская проверка
   2. 5.2. Серверная проверка
   3. 5.3. Пример интеграции с NAC
6. Выводы

Введение

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

В таких условиях даже одна не выполняющаяся политика безопасности может привести к серьёзным последствиям: утечке конфиденциальной информации, внедрению вредоносных программ и прочее. Эти и другие риски подробно рассматривались в нашем материале «Удалённый доступ в 2025: новые требования ФСТЭК России, Zero Trust и контроль подрядчиков».

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

Программный комплекс САКУРА входит в класс решений Device Posture Check, применяемых для обеспечения ИБ и централизованного управления политиками безопасности на рабочих местах. Его функциональность напрямую связана с задачами контроля комплаенса — как при защите рабочих мест, так и при обеспечении нормативного соответствия в организациях. САКУРА — полностью отечественная разработка, внесена в реестр отечественного ПО (№ 9018 от 05.02.2021).

В апреле 2025 года вышла третья версия комплекса — доработанная и переосмысленная с архитектурной точки зрения. В процессе разработки третьей версии «ИТ-Экспертиза» учла пожелания пользователей, переработала архитектуру решения, внедрила новые сущности и внесла ряд изменений, описанных в этом обзоре.

Функциональные возможности САКУРА 3

САКУРА предназначена для обеспечения контроля политик безопасности защищённости рабочих мест в организациях с распределённой инфраструктурой. Функциональность комплекса ориентирована на соблюдение требований внутренней политики ИБ как в пределах периметра, так и при работе через удалённые подключения, например, в облачных или гибридных средах.

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

Назначение профиля РМ 

В третьей версии ПК САКУРА введено понятие «профиль рабочего места», это ключевой элемент настройки, объединяющий основные параметры работы агента, категории безопасности, правила контроля, сценарии реагирования на нарушения, используемые настройки интеграции, а также мониторы для инвентаризации рабочего места.

Первоочередная задача — взять рабочее место (РМ) под управление из средства администрирования САКУРА (рис. 1). Для этого выполняется соответствующая настройка профиля рабочего места, в соответствии с которой оно будет управляться. Профиль РМ включает в себя:

• Проверка на соответствие рабочего места политикам безопасности — реализуется с помощью инструмента категоризации безопасности и создания различных правил контроля рабочего места с гибкой системой уровней нарушений.
• Интеграция средств контроля доступа к сети, которые используются на рабочем месте. Также в «Интеграции NAC» предусмотрена полная настройка и взаимодействие с различными решениями средств контроля доступа к сети.
• В матрице реагирования, которая применима к категории безопасности и «Интеграции NAC», существует возможность описать проактивное реагирование по результатам контроля рабочих мест, благодаря сценариям, которых не было в прошлой версии.
• Набор данных, который будет формировать агент с рабочего места для проведения инвентаризации. Эта функциональность реализуется с помощью инструмента «Мониторы».

Рисунок 1. Рабочее место в САКУРА 3

Проверка РМ и реагирование на нарушения

Для проверки рабочего места на соответствие политикам безопасности необходимо обратиться к правилам контроля. По умолчанию «ИТ-Экспертиза» предоставляет набор стандартных правил контроля (рис. 2), включающий проверку:

• актуальности обновлений операционной системы (ОС);
• антивирусных средств (KSC);
• запрещённых или обязательных процессов, служб;
• подключённых USB-устройств;
• сетевого доступа (REST GET, TCP, ICMP) и других параметров безопасности;
• разрешённых доменов;
• наличия прав локального администратора;
• контроля конфигурации устройства;
• контроля сертификатов;
• поддерживаемых ОС.

В системе также предусмотрена возможность формирования собственных правил контроля с использованием скриптов PowerShell, CMD, Python и Bash.

Рисунок 2. Меню «Правила контроля»

Рисунок 3. Меню «Создание правил контроля»

В САКУРА 3 реализована система оценки важности правил благодаря «Уровням нарушений» (рис. 3). Каждому правилу может быть назначен индивидуальный балл, отражающий его значимость для организации. Это позволяет формировать приоритеты обработки и адекватно распределять ресурсы реагирования.

Модель уровней нарушений, впервые реализованная в версии САКУРА 2, доказала свою эффективность как инструмент структурирования событий и оценки их критической значимости. В базовой реализации использовался принцип трёх категорий: «критическое», «предупреждение», «информационное».

Однако практика эксплуатации показала ограниченность такого подхода для задач с различной глубиной анализа и требуемым временем реагирования. Поэтому «ИТ-Экспертиза» в третьей версии продукта переработала механизм: теперь специалист по ИБ может самостоятельно определить необходимое количество уровней нарушений (рис. 4), каждый из которых будет адаптирован под специфику корпоративных процессов. Для каждого уровня возможны:

• присвоение уникальных визуальных признаков — цвета, наименования (рис. 5);
• привязка к конкретным правилам контроля;
• использование в логике сценариев реагирования;
• настройка сетевых ограничений в связке с решениями класса «контроль сетевого доступа» (NAC).

Рисунок 4. Меню «Уровни нарушения»

Рисунок 5. Меню «Создание уровня нарушений»

Название, цветовой индикатор и «балл» — полностью регулируемые.

Если вернуться к правилам контроля, то можно отметить, что инструмент создания правил контроля также позволяет гибко выполнить настройку по периодичности проверки (рис. 6): отложенный запуск, выбор интервала или установка расписания проверок.

Рисунок 6. Меню «Редактирование расписания»

Для каждого правила контроля есть возможность выбора сценария реагирования — например, отправить уведомление (рис. 7) пользователю или выполнить скрипт.

Рисунок 7. Меню «Настройка уведомлений для правил контроля»

Настроенные уведомления (рис. 8) по нарушениям правил контроля будут отображаться сессионным агентом САКУРА на рабочем месте пользователя.

Рисунок 8. Агент САКУРА «Уведомления»

После настройки и распространения правил контроля можно получить информацию о состоянии рабочего места в разделе «Инфраструктура», открыв вкладку «Рабочие места» (рис. 9). 

Рисунок 9. Меню «Рабочее место»

Использование сценариев 

Один из центральных элементов панели управления — Сценарии. Это новый механизм в САКУРА, реализованный в виде последовательности команд, где каждая команда зависит от результата выполнения предыдущего действия.

Например, благодаря сценарию можно реализовать:

• собственное правило контроля для рабочего места;
• уведомление пользователю по результатам выполнения какой-либо проверки;
• описание сложной проверки сервером на уровне взаимодействия с внешними системами, такими как SCCM, NAC, службы каталогов, где требуется последовательное принятие решений.

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

Перечень доступных команд агента:

• Скрипт (для проверок).
• Скрипт (для вычисления атрибутов).
• Уведомление.

Перечень доступных команд сервера:

• Заполнить пользовательский атрибут РМ.
• Запрос во внешнюю систему.
• Назначить профиль РМ.
• Отвязать профиль РМ.
• Получить группы LDAP пользователя.
• Скрипт сервера.
• Сценарий агента.
• Управление группами LDAP пользователя.
• RADIUS-запрос.

Функциональность сценариев позволяет также описывать реакцию на выявленные нарушения, что позволяет выстраивать проактивную модель управления безопасностью рабочих мест. Такая модель является гибко настраиваемой и может быть адаптирована под конкретные требования организации. «Сценарии» применимы к матрице реагирования. «Матрица реагирования» в данном случае предоставляет возможность выполнения сложных сценариев по какому-либо изменению состояния рабочего места. Суть матрицы в том, чтобы определять как реагировать.

Интеграции

Ключевой особенностью САКУРА 3 является универсальность взаимодействия между внешними системами и сервером САКУРА. САКУРА 3 сохранила поддержку базовых интеграций, таких как NAC-системы (системы сетевого контроля доступа), но и значительно расширила их настройку. Также вместо жёсткой привязки к конкретным LDAP-каталогам (вроде Active Directory) добавлена поддержка работы с различными службами каталогов.

Важным дополнением стала возможность использования RADIUS-сервера для интеграции в различные сценарии в виде сущности «Точки аутентификации». Кроме того, добавлена возможность создания сценариев, с использованием общепринятых инструментов (SSH, REST-запросы), автоматизирующих взаимодействие с внешними системами. Это особенно актуально для решений, где требуется корреляция событий безопасности, или для интеграции с такими инструментами, как SCCM, EMP и NAC.

Из доступных внешних систем предусмотрено:

• Взаимодействие с SCCM и EMP.
• Универсальный коннектор для обращения по REST API.
• Взаимодействие по SSH.
• SIEM-системы.
• Взаимодействие с различными службами каталогов, такими как Active Directory, OpenLDAP, AldPRO, FreeIPA, REDADM.

Настройка NAC-систем также претерпела изменения (рис. 10): конфигурация приведена к единому стандарту, что сокращает время развёртывания. Благодаря расширенным сценариям интеграции теперь можно динамически адаптировать правила доступа, например, на основе атрибутов рабочего места пользователя или с использованием новой системы уровней нарушений.

Рисунок 10. Меню «Редактирование интеграции с NAC»

На сегодняшний день в САКУРА 3 доступны интеграции с системами (рис. 11): 

• ФПСУ-IP от «АМИКОН».
• NGate от «Крипто ПРО».
• Check Point Remote Access VPN.
• ZTN-клиент от «Код Безопасности». 

Для взаимодействия с VPN-решениями используются разные механизмы. Для ФПСУ-IP, например, всё взаимодействие происходит по RADIUS-протоколу. 

Для NGate возможно взаимодействие в двух вариантах:

• по API шлюза и с перемещением подключающегося пользователя по LDAP-группам;
• по API шлюза с отправкой RADIUS-запросов.

Для Check Point также есть несколько вариантов:

• прямое обращение к шлюзу с перемещением пользователя по LDAP-группам;
• взаимодействие на уровне ролей Identity Awareness по API шлюза.

Рисунок 11. Меню «Интеграции с NAC»

Инвентаризация

Новая функциональность «Мониторы» (рис. 12) обеспечивает выборочный сбор ряда данных с рабочих мест. Администратор может определить, какую информацию будет собирать агент в рамках назначенного профиля. Все возможности раздела «Мониторы» предназначены для работы модуля Инвентаризации.

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

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

Рисунок 12. Меню «Мониторы»

Рисунок 13. Меню «Инвентаризация операционных систем»

Архитектура САКУРА 3

САКУРА представляет собой программный комплекс, построенный на клиент-серверной архитектуре и включающий в себя два основных компонента: «САКУРА-Сервер» и «САКУРА-Агент». Серверная часть формирует основу системы и состоит из трёх ключевых элементов:

• База данных отвечает за хранение и управление информацией. Используется PostgreSQL либо система, совместимая с его архитектурой.
• Веб-сервис обеспечивает работу панели управления САКУРА и обработку HTTPS-запросов администраторов системы. Реализован на базе Nginx.
• Сервер обрабатывает запросы агентов и взаимодействует с базой данных.

«САКУРА-Сервер» ориентирован только на работу в среде Linux. «САКУРА-Агент» отличается кроссплатформенностью и поддерживает операционные системы семейства Windows, Linux и macOS, включая архитектуру процессоров ARM.

Рисунок 14. Архитектура САКУРА 3

Механизмы взаимодействия

Механизмы взаимодействия между компонентами были существенно переработаны. В САКУРА 3 для обмена данными между агентом и сервером используется высокопроизводительный и двунаправленный протокол gRPC, работающий поверх HTTP/2, который обеспечивает:

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

Безопасность канала связи гарантируется применением TLS-шифрования, обеспечивая защиту данных от перехвата и подмены.

Отказоустойчивость

Реализована поддержка отказоустойчивой архитектуры «Active-active», основанной на технологии Multi-Master, которая пришла на смену «Active-passive». При таком подходе узлы системы работают одновременно и равноправно, обеспечивая непрерывную доступность. Это позволяет повысить стабильность и отказоустойчивость решения, минимизируя время простоя даже в случае сбоя отдельных компонентов.

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

Системные требования САКУРА 3

Минимальные требования для установки «САКУРА-Агент» на ПК: 

• объём оперативной памяти — минимально 4 ГБ, рекомендовано — 8 ГБ;
• разрешение экрана при работе с панелью управления — 1080p FullHD.

Минимальные требования для установки «САКУРА-Сервер» на ПК:

• объём оперативной памяти — 4 ГБ;
• количество ядер — 4;
• объём дискового пространства — 60 ГБ.

Корректная работа программного комплекса САКУРА в панели управления гарантируется в браузере Google Chrome.

Поддерживаемые ОС для «САКУРА-Сервер» — Astra Linux 1.7. Поддерживаемые ОС для «САКУРА-Агент»:

• Windows 10, 11;
• Windows Server 2022, 2025;
• Astra Linux 1.7.3, 1.7.5, 1.8;
• macOS 14, 15.

Требования к СУБД: поддерживаемая СУБД — PostgreSQL версии 15, совместимость с PostgreSQL версий выше 15.

Применение САКУРА 3

Программный комплекс САКУРА позволяет реализовывать контроль соответствия требованиям политики безопасности, соблюдение комплаенса. Возможно проведение двух типов проверок: агентская — выполняется непосредственно на рабочих местах с помощью установленного «САКУРА-Агент»; серверная — решение о соответствии принимается на стороне «САКУРА-Сервер» на основе данных из внешних источников. 

Эти типы проверок отражают разные подходы к оценке защищённости: локальный и централизованный. Поскольку от выбора и настройки проверок напрямую зависит полнота и актуальность контроля, мы рассмотрим применение САКУРА 3 на примере обоих сценариев.

Агентская проверка

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

Сценарий «Редактирование файла HOSTS». 

В данном сценарии выполняется последовательность команд.

Первая команда — проверка операционной системы. САКУРА, определив тип ОС, выбирает соответствующее условие и переходит к выполнению следующей команды по заданной логике.

Далее запускается скрипт проверки — в данном случае, на предмет редактирования файла HOSTS (рис. 15). Для каждой ОС предусмотрен свой вариант скрипта, соответствующий её особенностям.

Если результат выполнения скрипта указывает на нарушение (например, файл был отредактирован), система фиксирует инцидент и последовательно выполняет следующие действия:

• делает скриншот экрана;
• направляет уведомление пользователю через агента САКУРА.

Для использования такого сценария его необходимо указать в правиле контроля с типом проверки «Собственное правило».

Рисунок 15. Меню «Сценарий редактирования файла HOSTS»

Сценарий «Актуальность защиты антивируса» (рис. 16).

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

Дополнительно предусмотрена возможность описания дальнейших действий системы. Например, при выявлении устаревших антивирусных баз может автоматически запускаться дополнительная команда — скрипт обновления. При этом в уведомлении, отображаемом пользователю, может быть указано, что система инициирует попытку устранения нарушения.

Рисунок 16. Меню «Сценарии / Актуальность защиты антивируса»

Серверная проверка

При серверных проверках решение о соответствии рабочего места политикам безопасности принимается на стороне сервера на основе данных, полученных из внешних источников. Они особенно актуальны при интеграции с системами контроля сетевого доступа (NAC), где требуется оперативно оценивать доверенность устройств. Например, возможен сценарий, при котором пользователь пытается подключиться с недоверенного рабочего места — и именно сервер САКУРА, опираясь на данные внешней системы, будет принимать решение о факте нарушения.

Представим, что рабочее место обладает определёнными уникальными отпечатками или идентификаторами устройства, по которым сервер САКУРА сам должен выполнить вычисление и принять решение на основе внешних по отношению к нему систем. То есть сервер получил от рабочего места какой-то идентификатор и обратился к внешней системе для проверки.

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

Рисунок 17. Меню «Пользовательские атрибуты»

Агент САКУРА, работающий с привилегиями администратора, автономно собирает необходимые пользовательские атрибуты с рабочего места.

Рисунок 18. Меню «Создание пользовательского атрибута» 

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

Для обращения к внешним системам, так же как и при выполнении агентских проверок, необходимо использовать сценарии. Ниже приведён пример такого сценария, демонстрирующего, как может быть реализована проверка устройства с использованием REST API (рис. 19).

Рисунок 19. Меню «Сценарий проверки устройств через REST API»

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

Далее, в зависимости от результата обработки, возможны различные действия. Например, при выявлении отклонения можно уведомить пользователя о нарушении и зафиксировать диагностическую информацию на сервере. Если проверка завершилась успешно, системе назначается соответствующий профиль для определённой инвентаризации рабочего места.

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

В качестве серверной проверки может выступать обращение в LDAP для проверки групп пользователя. Ниже представлен рисунок такого сценария (рис. 20).

Рисунок 20. Меню «Сценарий группы пользователя и внешней системы» 

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

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

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

Пример интеграции с NAC

Требование заказчика к реализации комплаенса — все устройства по умолчанию считаются недоверенными и не должны получать доступ к корпоративной инфраструктуре до выполнения полной проверки на соответствие политике безопасности. Нужно было учитывать:

• проверку корпоративного статуса устройства на основании данных внешних систем учёта;
• анализ учётной записи пользователя в службе каталогов LDAP, включая проверку на блокировку и определение его групповой принадлежности;
• проверку параметров подключения в клиенте NAC, в том числе валидацию сертификата пользователя и проверку принадлежности подключения заданному сегменту.

Для каждого типа операционной системы должен быть предусмотрен собственный набор проверок — до 15 условий. Проверка запускается строго в момент установления VPN-сессии.

Для реализации подобного подхода к комплаенсу вендор создал интеграцию, настроил взаимодействие со шлюзом, добавил все агентские проверки для всех типов устройств.

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

Рисунок 21. Меню «Матрица реагирования»

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

Сценарии активируются в следующих случаях:

• При новом подключении к VPN. В нашем случае это означает переход рабочего места в состояние «онлайн», поскольку доступ к серверу САКУРА возможен только через VPN.
• При изменении уровня нарушений — в случае выявления нового нарушения по результатам проверок РМ.
• При отключении пользователя от VPN, что интерпретируется как переход рабочего места в состояние «офлайн».

Рассмотрим первый сценарий — переход рабочего места в «онлайн». Именно он является ключевым, так как в этот момент выполняются все проверки, предусмотренные заказчиком, и реализуется принцип Zero Trust.

Ниже представлен рисунок серверного сценария (рис. 22), который выполняется при каждом подключении пользователя к инфраструктуре. Таким образом, соблюдены все требования заказчика по комплаенсу.

На рисунке добавлены сноски с описанием каждой команды.

Рисунок 22. Сценарий «Переход РМ в онлайн»

Выводы

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

ПК САКУРА 3 предотвращает последствия киберинцидентов, автоматически реагируя на отклонения в соответствии с предопределёнными политиками безопасности.

Преимущества:

• Профиль рабочего места как центральный элемент, через который задаются параметры, политики безопасности, сценарии реагирования и интеграционные настройки. Также возможно автоматизированное его назначение.
• Возможность проверки более 200 параметров безопасности для оценки соответствия требованиям политики ИБ.
• Формирование собственных правил контроля с использованием скриптов PowerShell, Bash, Python и CMD.
• Реализация подхода «нулевого доверия» (Zero Trust).
• Расширенные возможности инвентаризации — сбор информации об аппаратном и программном обеспечении, перечень устройств с классификацией по типам.
• Кроссплатформенность агентской части — поддержка Windows, Linux, macOS, включая архитектуру ARM.
• Формирование сценариев реагирования через графы команд, матрицу реагирования.
• Интеграция с внешними системами различных классов и назначений.
• Наличие в реестре отечественного программного обеспечения.

Недостатки:

• Бесшовная миграция с версии 2 на версию 3 невозможна.
• На сегодняшний день не сертифицирован ФСТЭК России.
• Корректная работа САКУРА гарантируется в браузере Google Chrome.