Предложения по архитектуре средства контроля конфигурации произвольных информационных систем

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

Ключевые слова: контроль целостности, конфигурация информационной системы.

V. MOZOLINA, postgraduate student, MIPT, Moscow, Russia

Architecture proposals of configuration control system for arbitrary information systems

In the article requirements to the configuration control system (CCS) of an arbitrary information system were formed. Based on the received requirements the CCS architecture was proposed. Universal (permanent) and specialized (variable) structural components were distinguished in the CCS.

Keywords: integrity control, information system configuration.

Введение

Одним из необходимых объектов защиты информации является информационная технология (ИТ) – «последовательность приемов, способов и методов применения средств вычислительной техники при выполнении функций сбора, хранения, обработки, передачи и использования данных». Обеспечение же защищённости ИТ неразрывно связано с обеспечением защищенности той информационной системы (ИС), среды, в которой она реализуется [1, 2].

Конфигурации ИС, используемого в ней программного обеспечения (ПО) влияют на процессы реализации информационных технологий: одна и та же программа при различных настройках, может работать по-разному – реализовывать разные ИТ, собственно, в этом и заключается смысл изменения этих настроек. Некоторые же конфигурации могут создавать угрозы безопасности, способствовать работе в системе «опасных» информационных технологий. Становится понятным, что необходимо контролировать не только отдельные элементы информационной системы, но и саму её конфигурацию [3].

Вопрос контроля конфигурации информационной системы можно рассматривать с нескольких точек зрения: во-первых, кто может влиять на её изменение (задача контроля доступа к настройкам ИС, например, для виртуальных инфраструктур [4-6]), во-вторых, какие изменения являются допустимыми и разрешение, а какие должны блокироваться (задача контроля целостности конфигурации ИС [3, 7]).

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

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

Разработка требований к системе контроля конфигурации

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

Примечательно, что все приведённые выше рассуждения не учитывали, с какой именно системой мы работаем – мы рассматривали произвольную ИС. Это могла быть, например, и система виртуализации, построенная как на базе Microsoft Hyper-V, так и на основе VMware vSphere или QEMU/KVM, и распределённый вычислительный кластер, работающий на основе программной платформы Hadoop. Потому и решение задачи контроля целостности конфигурации должно быть универсальным и не зависеть от конкретной системы, которую мы защищаем.

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

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

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

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

Также важным требованием является масштабируемость системы контроля конфигурации и возможность её адаптации к новым ИС. Это требование связано с непрерывным развитием информационных систем, развитием как количественным (ИС становятся больше, повышается число элементов в их составе), так и качественным (в ИС появляются подсистемы новых типов).

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

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

Так мы получили следующий список требований к системе контроля конфигурации:

1. возможность задания эталона (множества разрешённых состояний) ИС, в том числе, его изменение и удаление;
2. возможность считать текущую конфигурацию ИС;
3. возможность сравнения текущей конфигурации ИС с эталоном;
4. модульная архитектура, состоящая из универсального для любой ИС ядра СКК и специализированных модулей взаимодействия с различными типами информационных систем;
5. масштабируемость и возможность адаптации к различными типам ИС;
6. разделение пользователей СКК на обычных и привилегированных, их идентификация и аутентификация в системе;
7. ведение журнала событий.

Предложения по архитектуре СКК

На основе разработанных в предыдущем требований были предложены состав и структура системы контроля конфигурации, изображенные на рисунке 1. Приведём описание модулей СКК и их функциональных требований.

Модуль управления устанавливается на рабочее место администратора безопасности ИС (пользователя или администратора СКК). Этот структурный компонент отвечает за следующие функции:

1. идентификация и аутентификация пользователей и администраторов СКК;
2. формирование запроса (автоматически или по требованию пользователя) на получение данных о текущем состоянии ИС и передача его на модель запроса информации;
3. формирование запроса (автоматически или по требованию пользователя) на сравнение текущего состояния ИС и заданного эталона;
4. работа с конфигурационными файлами (КФ): их импорт и удаление;
5. предоставление пользователю возможности создать через консоль управления (КУ) эталон конфигурации ИС (её подсистемы указанного типа) на основе конфигурационного файла и данных о текущем её состоянии;
6. предоставление пользователю возможность изменения и удаления эталона;
7. ведение архива применяемых эталонов;
8. передача данных об установленных эталонах и изменениях в них модулю проверки;
9. отображение в КУ текущее состояние системы;
10. сбор событий СКК, хранить журнал событий, отображать его для пользователя в КУ;
11. работа с несколькими модулями проверки.

Конфигурационный файл представляется собой обобщённое описание ИС определённого типа: наборы элементов в неё, возможные связи между ними. КФ уникален для каждого типа ИС.

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

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

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

1. получение эталонов от модуля управления;
2. формирование запроса на получение информации о текущем состоянии ИС к модулю запроса информации и получение соответствующих данных;
3. сравнение текущего состояния ИС с эталоном (при получении соответствующего запроса от модуля управления) – проверка конфигурации;
4. формирование результата проверки конфигурации и передача его на модуль управления;
5. работа с несколькими модулями управления.

Результат сравнения эталона ИС и её текущей конфигурации должна быть информация о нарушении или сохранении целостности конфигурации. В случае нарушения должна получаться информация о некорректных настройках (атрибутах системы).

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

1. получение информации об ИС от агентов (модулей получения информации) по запросу модуля управления или модуля;
2. передача полученных от агентов данных модулям проверки и управления;
3. работа с несколькими модулями управления, проверки и несколькими агентами.

Агент (модуль получения информации о системе) отвечает за следующие функции:

1. получение данных из подсистемы ИС по запросу модуля запроса информации;
2. преобразование полученных данных в стандартный вид, универсальный для всех систем и удобный для получения модулем запроса информации;
3. передача данных модулю запроса информации.

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

Заключение

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

Список литературы

1. Конявский В. А. Научно-методические проблемы создания защищенных информационных технологий // ВКСС Connect! М., 2006. № 1 (34). С. 41–43.
2. Конявская С. В. К вопросу о классификации объектов защиты информации // Безопасность информационных технологий. М., 2013. № 3. С. 14–18.
3. Мозолина Н. В.Решение задачи контроля целостности конфигурации, основанное на атрибутной модели контроля доступа. // Вопросы защиты информации, 2017. № 3. С. 23–25.
4. Конявская С. В., Угаров Д. В., Постоев Д. А.Инструмент контроля доступа к средствам управления виртуальной инфраструктурой // Information Security/Информационная безопасность. М., 2016. № 2. С. 9.
5. Угаров Д. В., Постоев Д. А. Проблемы реализации разграничения доступа к функциям управления виртуальных сред // Вопросы защиты информации: Научно-практический журнал/ФГУП «ВИМИ». М., 2016. Вып. 3. № 114. С. 34–35.
6. Журов П. М.Разграничение доступа к функциям управления средства виртуализации VMware vSphere // Труды 60-й Всероссийской научной конференции МФТИ (26–27 ноября 2017 года). М., Долгопрудный, Жуковский. 2017. С. 184–185.
7. Мозолина Н. В.Контроль целостности виртуальной инфраструктуры и ее конфигурации // Вопросы защиты информации: Научно-практический журнал/ФГУП «ВИМИ». М., 2016. Вып. 3. № 114. С. 31–33.

Автор: Мозолина Н. В.

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

Библиографическая ссылка: Мозолина Н. В. Предложения по архитектуре средства контроля конфигурации произвольных информационных систем // Вопросы защиты информации. М., 2018. № 2 (121). С. 14-17.

---