Контроль программно-аппаратной среды рабочих мест пользователя

Введение

Контроль состояния и конфигурации информационной системы необходимо обеспечивать на этапах жизненного цикла с внедрения до утилизации [1].

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

Про развитие «Паспорта ПО» и пойдёт речь в текущем докладе.

1. Состав, функционирование и развитие «Паспорт ПО»

Прежде чем перейти к направлениям доработок продукта, напомню из чего состоит и как функционирует «Паспорт ПО».

Основными элементами программного модуля (ПМ) «Паспорт ПО» являются:

1. серверный компонент (Сервер) с базой данных;
2. компонент управления (АРМ управления);
3. клиентский компонент (Клиент), устанавливаемый на подконтрольные объекты (ПКО), – рабочие места (СВТ), конфигурацию которых контролирует программный модуль;
4. сервис обмена сообщениями RabbitMQ, обеспечивающий взаимодействие по сети между всеми элементами [2].

Подготовка системы для работы ПМ «Паспорт ПО» заключается в выполнении следующих действий:

1. регистрация учетных записей административного персонала, отвечающего за контроль целостности программной среды в АРМ управления, формирование ролей и назначение их учётным записям;
2. формирование списка ПКО с разбиением на логические группы (подразделения);
3. формирование общей базы шаблонов (прототипов конфигураций рабочих мест пользователей);
4. назначение шаблонов подконтрольным объектам;
5. проведение опроса на ПКО (сканирования конфигурации СВТ в соответствии с назначенным шаблоном) и формирование его паспорта ПО, то есть его эталонного состояния [3].

Паспорт СВТ представляет собой подписанный набор данных: различные данные о ПКО, включая имя и адрес в сети, данные о подписавшем паспорт сотруднике и время создания паспорта, данные о контролируемых файлах, включая полный путь и хэш-сумму, вычисленную от его содержимого, и данные о программах, установленных на подконтрольный объект.

В ходе дальнейшей работы программного модуля выполняется сканирование подконтрольных объектов по заданному для СВТ расписанию или по запросу управляющего персонала ПМ «Паспорт ПО». В ходе сканирования Клиент определяет конфигурацию программной среды СВТ и отправляет информацию на Сервер, который автоматически сверяет полученные данные о текущем состоянии ПКО с эталонным и информирует управляющий персонал ПМ «Паспорт ПО» о выявленных нарушениях. Для каждого ПКО в случае обнаружения нарушений управляющим персоналом должен быть выполнен анализ возникших изменений, в результате которого возможно обновление паспорта ПКО (в случае если это были санкционированные модификации) или же принятие мер по устранению причин возникших несоответствий, разбор инцидента безопасности [3].

Полученное в результате сканирования ПКО описание конфигурации СВТ называется  «проект паспорта» или просто «проект». Такой проект для каждого ПКО в каждый момент времени существует только один, каждый новый проект автоматически заменяет предыдущий и таким образом всегда отражает последнее известное состояние СВТ.

За время эксплуатации были обнаружены возможности развития в нескольких разных направлениях и были предложены следующий доработки:

1. Возможность сохранения промежуточных проектов
2. Возможность контроля рабочих, работающих под управлением ОС семейства Linux
3. Возможность контроля аппаратных средств рабочей станции

2. Сохранение промежуточных проектов

От одного из пользователей спустя некоторое время эксплуатации «Паспорта ПО» поступила просьба добавить возможность сохранения всех промежуточных проектов для того, чтобы информация обо всех промежуточных состояниях СВТ также была доступна для анализа в случае необходимости.

Это несложная доработка, требующая внесения небольших изменений в логику работы сервера и в АРМ управления. При появлении нового проекта старый будет не удаляться, а переводиться в состояние «архивный проект» и оставаться в БД. Но просто хранить проекты было бы недостаточно, ведь цель доработки – не просто добавить возможность просматривать промежуточные состояния СВТ, а полноценно следить за всеми изменениями (то есть за разницей между состояниями, отличиях от утверждённых паспортов). Без дополнительной информации, без продуманной системы навигации между всеми проектами и паспортами ориентироваться в них, когда их станет много, было бы. Поэтому было решено добавить к проекту информацию о том, совпал ли он с паспортом, установленным для данного СВТ в момент формирования проекта и имя паспорта, с которым проводилось сравнение. Это позволит даже спустя значительно время просмотреть не просто состояние ПКО в некоторый момент, но знать, в чём именно это состояние отличалось от эталонного, даже если на момент просмотра для СВТ утверждён уже другой паспорт. Такой подход позволяет легко выделять наиболее важные – то есть не совпавшие с паспортом – проекты и при необходимости анализировать именно их.

Также в рамках этой доработки был добавлен ещё один механизм, позволяющий сильнее акцентировать внимание пользователя «Паспорта ПО» на проектах, отличных от паспорта СВТ. Любой отличающийся от паспорта находится в статусе «не просмотрен», для перемещения его в архив или превращения в паспорт пользователь должен открыть проект и ознакомиться с его содержимым, подтвердив это действие нажатие кнопки «Просмотрено». Проекты в статусе «не просмотрен» будут постоянно отображаться в интерфейсе как требующие просмотра. Данный механизм обязательного просмотра позволит снизить число инцидентов, при которых один проект не совпал с паспортом, следующий после проекта – совпал, а пользователь «Паспорт ПО», отвечающий за контроль состояния программной среды ПКО, не обратил на это внимание и не произвел необходимых в такой ситуации действий. Но пока данный механизм будет сделан опциональным: его сможет включать/выключать администратор программного модуля, обладающий правом на эту настройку.

Необходимо учесть одно немаловажное последствие такого изменения системы: хранение всех проектов в базе приведет к её очень быстрому росту, ведь новые проекты создаются гораздо чаще новых паспортов, зачастую ежедневно. На данный момент для оптимизации размеров базы самая объёмная часть паспорта – информация о файлах – хранится в базе не в виде строк таблицы, а в серилизованном виде – в байтах. Более того, серилизованные данные ещё и дополнительно сжаты архиватором, чтобы занимать ещё меньше места. Это позволяет значительно экономить место и экономить время на обращение к базе – вместо тысяч строк таблицы, хранящих данные о файлах, используется одна ячейка для хранения сериализованных упакованных данных. В дальнейшем для экономии места предложено применить аналогичный подход и ко второму по объёму элементу паспорта – к информации о продуктах, что, с учётом большого числа проектов, даст значительный выигрыш по памяти.

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

3. Возможность контроля рабочих станций, работающих под управлением ОС семейства Linux

В связи с тенденцией импортозамещения на всё большее число рабочих станций в различных организациях устанавливаются операционные системы семейства Linux [4], в связи с этим стал актуальным вопрос контроля ПКО, на которых установлен Linux.

Так как «Паспорт ПО» написан на языке C#, то перенос и запуск клиентского компонента на ОС семестра Linux не вызвал сложностей –  потребовались незначительные изменения исходного кода успешного запуска Клиента и осуществления взаимодействия с сервером. Интересной инженерной задачей стало обновление алгоритмов работы Клиента с файловой системой ПКО (опрос исполняемых файлов) и получения списка установленного программного обеспечения.

При работе с файлами основное изменение алгоритма потребовалось ввиду различной логики работы с расширениями файлов с ОС Windows и Linux. В Windows расширения файлов являются неотъемлемой частью имени, используются везде и однозначно характеризуют файл. В Linux расширения файлов необязательны: многие важные файлы, в том числе и бинарные файлы, являющиеся важной характеризующий частью системы, могут вообще не иметь расширений. Сейчас, при работе с ПКО под управлением ОС Windows в шаблоне управляющий персонал «Паспорт ПО» может указать определенные типы файлов, отфильтровав тем самым список опрашиваемых объектов. Это позволяет гибко исключить из опроса те файлы, которые не являются частью ПО или не описывают его конфигурацию.

При работе с ПКО под управлением Linux такой способ не подойдёт, нужен другой подход. Включать все файлы в шаблон поимённо было бы невероятно трудоёмко и сделало бы невозможным использование «Паспорта ПО» в реальных условиях: время опроса ПКО и требуемые на его проведения ресурсы повлекли бы за собой затруднение работы пользователей с контролируемым ПКО.

В итоге было решено ввести понятие исполняемых файлов как совокупности файлов определенных MIME-типов, и позволить пользователям ставить на контроль именно исполняемые файлы.

Был выбран следующий список MIME-типов:

application/x-elf

application/x-sharedlib

application/x-dosexec

application/x-object

application/x-executable

application/x-coredump

application/x-perl

application/x-python-code

application/x-php

text/x-shellscript

text/x-python

text/x-perl

text/x-java

text/x-php

Данные об установленном в системе ПО легко получаются от пакетного менеджера, используемого в текущем клиентском дистрибутиве, наиболее распространённые системы управления пакетами – RPM и dpkg, на данный момент поддержано обращение к этим системам.

4. Возможность контроля аппаратных средств рабочей станции

Несмотря на название продукта – «Паспорт ПО», подразумевающее под собой контроль состояний именно программного обеспечения подконтрольных станций, нельзя забывать, что основная задача, которую решает программный модуль – это контроль целостности конфигураций рабочих мест. Очевидно, что конфигурация рабочего места включает в себя не только программную часть, но и аппаратную, поэтому было решено добавить возможность контроля аппаратной составляющей ПКО.

Список контролируемого оборудования следующий:

1. Processor
2. BIOS
3. DiskDevice
4. Ram
5. CDROM
6. USBController
7. PCI
8. NetworkAdapter
9. Motherdoard

Для каждого элемента определяются следующие данные:

1. Type (тип оборудования, один из вышеперечисленных)
2. Caption
3. Name
4. Manufacturer
5. SerialNumber
6. Status
7. ExpDescription (для каждого типа – свой)
8. DeviceName
9. DeviceId

В Windows эти данные можно получить из системы через системные вызовы и описание драйверов, в Linux было решено получить это с использованием утилиты Linux Hardware Lister (lshw) – утилиты с открытым исходным кодом, позволяющей собрать данные об аппаратных компонентах текущей рабочей станции [5].

Вывод

Активная обратная связь от пользователей «Паспорта ПО» показывает, что функциональность контроля конфигурации рабочих мест востребована на местах по существу, а не только ради формального удовлетворения требованиям тех или иных регламентов. Не секрет, что это лучший стимул для разработчика, а значит, теоретические исследования и практические разработки в этом направлении будут иметь развитие, и их результатам будут посвящены доклады и на будущих конференциях.

СПИСОК ЛИТЕРАТУРЫ:

1. ГОСТ Р 51583-2014. Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие положения.
2. Мозолина Н. В. Реализация концепции управления конфигурациями при помощи программного модуля «Паспорт ПО» // Вопросы защиты информации. М., 2020. № 3. С. 11–15.
3. Мозолина Н. В. Дубликатом бесценного груза: «Паспорт ПО» // Information Security/Информационная безопасность. М., 2020. № 5. С. 46–47.
4. Госорганы России массово меняют Windows на Astra Linux [Электронный ресурс] URL: https://www.cnews.ru/news/top/2020-11-12_gosorgany_rossii_massovo (дата обращения 06.05.2021).
5. Hardware Lister (lshw) [Электроный ресурс] URL: https://ezix.org/project/wiki/HardwareLiSter (дата обращения: 06.05.2021).

Авторы: Чадов А. Ю.; Мозолина Н. В.

Дата публикации: 19.08.2021

Библиографическая ссылка: Чадов А. Ю., Мозолина Н. В. Контроль программно-аппаратной среды рабочих мест пользователя // Комплексная защита информации: материалы XXVI научно-практической конференции. Минск. 25–27 мая 2021 г. Минск: Издатель Владимир Сивчиков, 2021. С. 84–87.

---