Инвентаризация компьютеров на Astra Linux: автоматический учёт активов

Более 5 000 российских организаций перевели рабочие станции на Astra Linux по требованиям ФСТЭК и директивам Минцифры — и столкнулись с одной и той же проблемой: стандартные ITAM-инструменты не работают. 10-Страйк Network Inventory, SCCM, LANDesk — все они созданы для Windows и опираются на WMI, групповые политики и реестр .msi-пакетов. На Astra Linux они либо вообще не запускаются, либо возвращают пустые карточки активов.

Задача — провести инвентаризацию в смешанном парке: 300 Windows-машин и 200 рабочих станций на Astra Linux в одном реестре, с единым дашбордом и полным учётом СЗИ. Ниже — техническая методика, bash-команды для ручного сбора и пошаговая инструкция по развёртыванию агента.

Чем Astra Linux отличается от Windows с точки зрения инвентаризации

Astra Linux — это не «Linux вместо Windows». С точки зрения инвентаризации это принципиально другая архитектура, и каждое отличие ломает привычный ITAM-инструментарий.

Нет WMI — нет безагентного сбора данных

На Windows большинство ITAM-решений собирают данные через Windows Management Instrumentation (WMI): удалённо запрашивают список ПО, процессоры, объём RAM, серийные номера. На Astra Linux WMI отсутствует как класс. Ближайший аналог — D-Bus и системные файлы /proc/, /sys/, вывод утилит dmidecode и lshw. Но эти данные недоступны удалённо без SSH или установленного агента.

SELinux и мандатный контроль доступа

Astra Linux SE реализует мандатный контроль доступа (МКД) на базе SELinux. Это значит, что даже процесс с правами root не может произвольно читать системные файлы, если его метка безопасности не соответствует метке объекта. Агент инвентаризации, запущенный без правильно настроенной SELinux-политики, получит отказ в доступе при попытке прочитать /etc/shadow, /proc/*/exe или системные логи — именно те источники, которые используются для учёта пользователей и процессов.

Это не баг, а намеренная защита. Решение — не отключать SELinux (что запрещено регуляторными требованиями для сертифицированных конфигураций), а прописать агент в список доверенных процессов с минимально необходимым набором разрешений.

Другая структура реестра ПО

На Windows источник правды о ПО — реестр (HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\) и .msi-база. На Astra Linux (дистрибутив на базе Debian) это пакетная база dpkg: /var/lib/dpkg/status. Формат пакетов — .deb, а не .msi. Утилиты управления — apt, dpkg, apt-cache. Ни одна из них не эмулируется под Windows-инструментарий.

Специфичные СЗИ, которых нет в Windows-реестрах

На рабочих станциях с Astra Linux в госсекторе устанавливаются специфичные сертифицированные средства защиты:

• Dallas Lock 8.0-K для Linux — система разграничения доступа (сертификат ФСТЭК №3509)
• Secret Net Studio для Linux — комплексная защита рабочих станций
• Avet — антивирус для Linux, сертифицированный ФСТЭК
• КриптоПро CSP для Linux — СКЗИ (сертификат ФСБ)
• ViPNet Client для Linux — VPN-клиент

ITAM-система, не умеющая идентифицировать эти пакеты по debian-имени и проверять состояние их служб через systemd, не пригодна для ИБ-инвентаризации на Astra Linux.

Нет MMC и GPO — управление через конфигурационные инструменты

Централизованное управление Windows строится на групповых политиках (GPO) и оснастках MMC. На Astra Linux эквивалент — Ansible, Puppet, SaltStack или собственный механизм Astra Linux Administrator (ALD Pro). Развёртывание агента инвентаризации должно это учитывать.

Вывод: для Astra Linux нужен специализированный агент, собранный под linux-архитектуру, с поддержкой dpkg-реестра, SELinux-политик и перечня российских СЗИ. Универсальных Windows-решений здесь недостаточно.

Что инвентаризировать на Astra Linux

Полный набор данных, который должна собирать система инвентаризации с рабочих станций на Astra Linux:

Отдельного внимания требует поле «Версия Astra Linux» — оно критично для проверки ФСТЭК, поскольку сертификат распространяется на конкретные релизы. Astra Linux 1.7.4 и 1.7.5 — разные позиции в реестре сертифицированных СЗИ. Агент должен читать именно /etc/astra_version, а не /etc/os-release, которое может содержать родительский дистрибутив Debian.

Инструменты инвентаризации Astra Linux

Агентные решения: сравнение

GLPI и OCS Inventory — это open-source ITAM без ИБ-контекста: они собирают железо и ПО, но не классифицируют СЗИ, не связывают активы с уязвимостями из БДУ ФСТЭК и не формируют журнал учёта СКЗИ. Для технических нужд они подходят; для подготовки к проверке ФСТЭК — нет.

MaxPatrol собирает данные с Linux-хостов, но основная специализация — сканирование уязвимостей, а не ведение реестра активов с учётом российских СЗИ.

Ручной сбор данных: bash-команды

Для понимания того, какие данные собирает агент, и для точечной диагностики полезны прямые команды. Ниже — полный набор для Astra Linux:

# Версия Astra Linux (критично для ФСТЭК)
cat /etc/astra_version
lsb_release -a

# Уровень мандатного контроля доступа
pdpl-user -l $(whoami) 2>/dev/null || echo "МКД не настроен"

# Версия ядра и архитектура
uname -r && uname -m

# Список всего установленного ПО
dpkg --list

# Поиск СЗИ и СКЗИ по имени пакета
dpkg --list | grep -E "dallas|secretnet|avet|vipnet|cprocsp|cryptopro|kontinent"

# История установки пакетов (последние 50 операций)
grep "install" /var/log/dpkg.log | tail -50

# Аппаратная информация: производитель, модель, серийный номер
dmidecode -t system

# Процессор
dmidecode -t processor | grep -E "Socket|Family|Manufacturer|Version|Max Speed"

# Оперативная память
dmidecode -t memory | grep -E "Size|Type|Speed|Manufacturer"

# Полная аппаратная сводка (требует root)
lshw -short 2>/dev/null

# Сетевые интерфейсы с IP и MAC
ip addr show | grep -E "inet |link/ether"

# Hostname
hostname -f

# Открытые порты и слушающие службы
ss -tlnp

# Таблица маршрутизации
ip route show

# Активные службы (включая СЗИ)
systemctl list-units --state=active --type=service | grep -E "dallas|avet|secret|vipnet|cprocsp"

# Пользователи системы (локальные)
getent passwd | awk -F: '$3 >= 1000 {print $1, $5, $7}'

# Членство текущего пользователя в группах
groups $(whoami)

Почему ручной сбор не масштабируется на 200+ машин: каждая команда требует отдельного SSH-сеанса, результаты нужно парсить и агрегировать вручную, данные устаревают сразу после сбора, а любое изменение конфигурации (новый пакет, новая служба) остаётся незамеченным до следующего обхода. На 200 машинах это 200 × 10 команд = 2 000 операций за каждый цикл инвентаризации. Агент инвентаризации делает это автоматически по расписанию и отправляет изменения, а не полный дамп.

Как развернуть агент КиберОснова на Astra Linux

Шаг 1: Проверить совместимость

Перед развёртыванием убедитесь в соответствии требованиям:

• Поддерживаемые версии: Astra Linux 1.7.4+, Astra Linux SE 1.7.4+
• Уровни МКД: 0 (базовый) и 1 (усиленный) — поддерживаются в стандартной конфигурации; уровни 2–3 — по согласованию
• Архитектура: x86_64 (amd64), aarch64 (arm64) — для ARM-платформ «Эльбрус» уточняйте актуальность версии
• Зависимости: systemd, curl или wget (для загрузки пакета), openssl 1.1+
• Сеть: порт 443 (HTTPS) от рабочей станции до сервера КиберОснова (on-premise или облако)

Шаг 2: Установка через пакет .deb

# Загрузить пакет с сервера КиберОснова
wget https://[адрес-сервера]/agents/cyberosnova-agent_latest_amd64.deb \
  -O /tmp/cyberosnova-agent_latest_amd64.deb

# Установить пакет
sudo dpkg -i /tmp/cyberosnova-agent_latest_amd64.deb

# При отсутствующих зависимостях — доустановить
sudo apt-get install -f

# Убедиться, что служба запустилась
systemctl status cyberosnova-agent

После установки агент автоматически регистрируется на сервере КиберОснова, используя токен из конфигурационного файла /etc/cyberosnova/agent.conf. Первый сбор данных происходит в течение 2–5 минут.

Шаг 3: Централизованная установка через Ansible

Для парка от 10 машин ручная установка нецелесообразна. Ansible-плейбук для Astra Linux:

---
- name: Установить агент КиберОснова на Astra Linux
  hosts: astra_workstations
  become: true
  vars:
    agent_package: cyberosnova-agent_latest_amd64.deb
    agent_server: https://sgrc.example.ru

  tasks:
    - name: Скопировать .deb пакет на хост
      copy:
        src: "{{ agent_package }}"
        dest: /tmp/{{ agent_package }}
        mode: '0644'

    - name: Установить агент КиберОснова
      apt:
        deb: /tmp/{{ agent_package }}
        state: present

    - name: Настроить адрес сервера
      lineinfile:
        path: /etc/cyberosnova/agent.conf
        regexp: '^server_url'
        line: "server_url = {{ agent_server }}"
      notify: Перезапустить агент

    - name: Запустить и добавить в автозагрузку
      systemd:
        name: cyberosnova-agent
        state: started
        enabled: yes

  handlers:
    - name: Перезапустить агент
      systemd:
        name: cyberosnova-agent
        state: restarted

Инвентарный файл (hosts.ini) для группы Astra Linux:

[astra_workstations]
ws-001.domain.local
ws-002.domain.local
ws-003.domain.local

[astra_workstations:vars]
ansible_user=ansible_svc
ansible_ssh_private_key_file=~/.ssh/ansible_id_rsa
ansible_become_method=sudo

Запуск плейбука:

ansible-playbook -i hosts.ini deploy_agent.yml --check   # проверочный запуск
ansible-playbook -i hosts.ini deploy_agent.yml           # боевой запуск

Шаг 4: Настройка SELinux-политик

Если рабочие станции работают на Astra Linux SE с активным МКД, агенту нужно разрешение на чтение системных ресурсов. Выполните на каждой машине (или через Ansible):

# Добавить агент в список доверенных исполняемых файлов
sudo astra-admin trust /usr/bin/cyberosnova-agent

# Проверить контекст SELinux процесса агента
ps -Z | grep cyberosnova-agent

# Убедиться, что агент не блокируется audit-логами
sudo ausearch -m avc -ts recent | grep cyberosnova

Агент не требует отключения SELinux (setenforce 0) — это запрещено для сертифицированных конфигураций Astra Linux SE. Он работает в рамках штатных политик, запрашивая только чтение: /proc/, /sys/, /var/lib/dpkg/, /etc/.

Шаг 5: Проверить сбор данных

После развёртывания откройте веб-консоль КиберОснова:

1. Перейдите в раздел Активы → Компьютеры
2. Примените фильтр ОС: Astra Linux
3. Убедитесь, что для каждой машины заполнены поля:
   • Версия Astra Linux (из /etc/astra_version)
   • Список ПО (из dpkg --list)
   • Обнаруженные СЗИ (Dallas Lock, Avet и другие)
   • Сетевые интерфейсы и IP-адреса
   • Пользователи (из /etc/passwd и LDAP)

Если карточка активна, но поля пустые — проверьте статус службы на хосте (systemctl status cyberosnova-agent) и SELinux-аудит (ausearch -m avc).

Учёт СЗИ на Astra Linux — что важно для ФСТЭК

При проверке ФСТЭК один из первых запросов — «предоставьте перечень средств защиты информации с привязкой к конкретным рабочим местам». На Windows это решается через реестр и GPO-отчёты. На Astra Linux — только через системы инвентаризации с Linux-поддержкой.

Сертифицированные СЗИ для Astra Linux

Как работает обнаружение в КиберОснова: агент инвентаризации проверяет три источника параллельно:

1. Пакетная база dpkg — наличие пакета с нужным именем и его версия
2. Статус служб systemd — активна ли служба СЗИ (systemctl is-active dallas-lock-linux)
3. Файловая система — наличие характерных файлов в /usr/lib/, /opt/ (дополнительная верификация)

Результат — в реестре учёта СЗИ каждое средство защиты привязано к конкретной машине с указанием версии, статуса службы и даты последнего обнаружения.

Учёт СКЗИ: от автообнаружения до журнала

КриптоПро CSP и ViPNet Client КиберОснова классифицирует как СКЗИ — отдельную категорию с расширенными атрибутами: серийный номер лицензии, класс СКЗИ, ответственное лицо, дата ввода в эксплуатацию. Это позволяет вести журнал учёта СКЗИ напрямую в платформе без отдельного Excel-файла — что критично при выездной проверке по Приказу ФАПСИ №152.

Почему это критично

Проверяющий ФСТЭК не принимает «мы проверили вручную, всё стоит». Требуется документированный реестр с датой актуальности. Если между проверками одна рабочая станция была переустановлена без Dallas Lock — это нарушение. Автоматический учёт СЗИ с историей изменений решает эту задачу системно.

Особенности смешанного парка: Windows + Astra Linux

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

Единая консоль для двух ОС

КиберОснова развёртывает разные агенты под каждую ОС — Windows-агент и Linux-агент — но все данные поступают в одну платформу. Результат: единый реестр активов с возможностью фильтрации по ОС, ответственному подразделению, наличию СЗИ, уровню уязвимостей.

Сравнительный дашборд показывает:

• Сколько машин на Astra Linux, сколько на Windows, сколько на ALT или RED OS
• На каких машинах отсутствует антивирус (отдельно для каждой ОС)
• Какой процент парка охвачен КриптоПро (агрегированно)
• Где давно не было сбора данных (агент не выходил на связь > 7 дней)

Единая политика контроля конфигурации

Приказ ФСТЭК №239 требует управления конфигурациями значимых объектов КИИ. В смешанном парке это означает: разные эталонные конфигурации для Windows и Astra Linux, но единый процесс контроля отклонений. КиберОснова позволяет задать эталон для каждого типа ОС и автоматически выявлять отклонения — например, появление неучтённого ПО или отсутствие обязательного СЗИ.

Практический пример

ФГУП с 500 рабочими станциями: 300 на Windows 10, 200 на Astra Linux 1.7.5. После развёртывания агентов КиберОснова (Ansible для Linux, GPO для Windows) единый реестр сформировался за 4 часа. В результате первой инвентаризации обнаружено:

• 12 машин на Astra Linux без активной службы Avet (антивирус установлен, но служба остановлена)
• 3 машины с КриптоПро CSP версии 4.0 (устаревшая, не поддерживается производителем)
• 8 машин без Dallas Lock при наличии записи в таблице распределения СЗИ

Без автоматической инвентаризации эти расхождения обнаружились бы только при проверке ФСТЭК.

Нормативные требования к инвентаризации рабочих станций Astra Linux

Инвентаризация компьютеров с Astra Linux — не просто технический процесс. Она прямо предусмотрена или вытекает из требований нескольких регуляторных документов.

Приказ ФСТЭК №21 и №239: учёт активов как обязательная мера

Приказ ФСТЭК №21 (для ИСПДн) и №239 (для КИИ) в числе первых организационных мер называют инвентаризацию информационных активов. Конкретно: идентификация и аутентификация субъектов и объектов доступа (ИАФ.1) требует актуального реестра рабочих станций — в том числе тех, на которых установлена Astra Linux.

Для значимых объектов КИИ (Приказ №239) требование жёстче: должен существовать перечень компонентов объекта КИИ с актуальными данными об их конфигурации. Это невозможно поддерживать вручную при парке от 50 машин.

187-ФЗ: реестр объектов КИИ

Закон об информационной безопасности КИИ (187-ФЗ) требует от субъектов вести реестр объектов КИИ и поддерживать его в актуальном состоянии. Рабочие станции на Astra Linux, обрабатывающие информацию в рамках значимых объектов, входят в этот реестр. Каждый объект должен быть идентифицирован: ОС, версия, ответственный, местоположение.

Приказ ФАПСИ №152: поэкземплярный учёт СКЗИ

На рабочих станциях с Astra Linux часто устанавливается КриптоПро CSP для Linux — сертифицированное СКЗИ. Приказ ФАПСИ №152 требует поэкземплярного учёта: каждый экземпляр СКЗИ должен быть закреплён за конкретным пользователем и рабочим местом с отражением в журнале. При ручном ведении этого журнала в Excel ошибки неизбежны — особенно при переустановках и ротации сотрудников.

Что проверяет ФСТЭК на практике

При плановой проверке субъекта КИИ инспекторы запрашивают:

1. Перечень технических средств — список компьютеров с указанием ОС, версии, местоположения
2. Перечень СЗИ — с привязкой к конкретным рабочим местам и сертификатами
3. Перечень СКЗИ — с серийными номерами, классом, ответственным лицом
4. Актуальность данных — дата последней инвентаризации не позднее 1 года

Если в организации 200 рабочих станций на Astra Linux и для них нет отдельного инструмента учёта — это гарантированное замечание при проверке. Автоматизированный реестр с отметкой времени последнего сбора данных закрывает этот вопрос документально.

Типичные ошибки при инвентаризации Astra Linux

За практику работы с организациями, переходящими на российские ОС, мы выявили несколько системных ошибок.

Ошибка 1: Попытка использовать WMI-сканер через WINE

Некоторые администраторы пробуют запустить Windows-ITAM через WINE или в Windows-секции смешанной среды. Результат — сканер видит только Windows-раздел и не получает данных о пакетах Astra Linux, СЗИ и системных службах. Реестр остаётся пустым для linux-машин.

Ошибка 2: Отключение SELinux для «упрощения» инвентаризации

Отключение мандатного контроля (setenforce 0) позволяет запустить любой агент без настройки политик. Но это нарушает сертифицированную конфигурацию Astra Linux SE, что автоматически делает недействительным сертификат ФСТЭК на используемую версию ОС. Этот факт легко обнаруживается при проверке: getenforce возвращает Permissive или Disabled, что прямо противоречит требованиям к эксплуатации сертифицированного СЗИ.

Ошибка 3: Учёт только установленных пакетов без проверки служб

Инвентаризация показывает, что Dallas Lock установлен на всех 200 машинах. Но проверка systemctl is-active dallas-lock-linux выявляет, что на 15 машинах служба остановлена — то есть СЗИ фактически не работает. Пакетная база dpkg отражает факт установки, но не факт активной защиты. Полноценная инвентаризация должна проверять оба показателя.

Ошибка 4: Игнорирование ARM-платформ

В госсекторе встречаются рабочие станции на базе отечественных процессоров: «Эльбрус» (МЦСТ), «Байкал-М» (Байкал Электроникс). Astra Linux поддерживает aarch64-архитектуру, но не все ITAM-агенты собраны под неё. Перед развёртыванием уточняйте у производителя агента наличие сборки для конкретной архитектуры.

Ошибка 5: Сбор данных без проверки версии Astra

/etc/os-release на машинах с Astra Linux содержит строку Debian GNU/Linux 10 — родительский дистрибутив. Если ITAM-система читает этот файл, она классифицирует машину как «Debian 10», а не как «Astra Linux 1.7.5». Для проверки ФСТЭК это критично: сертификат выдан именно на Astra Linux, и именно эта запись должна быть в реестре. Используйте /etc/astra_version как основной источник информации об ОС.

Заключение

Инвентаризация Astra Linux — это не «тот же ITAM, только на Linux». Это отдельная задача с отдельной архитектурой: dpkg вместо реестра Windows, SELinux вместо ACL, российские СЗИ вместо западных агентов защиты. Большинство существующих ITAM-решений с этой задачей не справляются.

КиберОснова — первая ITAM-платформа с нативной поддержкой Astra Linux, ALT Linux и RED OS. Один агент, один реестр, одна консоль — независимо от того, сколько ОС в вашем парке. Учёт СЗИ, сверка с БДУ ФСТЭК, журнал СКЗИ и контроль конфигураций работают одинаково для Windows и российских ОС.

Отдельное решение для российских ОС больше не нужно.

Запросите демо — покажем инвентаризацию Astra Linux в живую: от установки агента до карточки актива с перечнем СЗИ.