поиск по сайту
Неатомарный взгляд на РКБ, как на композицию перехвата управления и контроля целостности

Неатомарный взгляд на РКБ, как на композицию перехвата управления и контроля целостности

Алтухов А.А.

Закрытое акционерное общество «ОКБ САПР», Москва, Россия.

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

Ключевые слова: модуль доверенной загрузки, резидентный компонент безопасности, доверенная вычислительная среда, доверенные вычисления

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

Для создания ДВС обязателен резидентный компонент безопасности (РКБ) [Там же]. Одной из возможных реализаций РКБ является аппаратный модуль доверенной загрузки (АМДЗ) [2; 3].

А(П)МДЗ обеспечивает доверенную загрузку системы посредством решения двух глобальных задач: перехват процесса старта системы и контроль целостности системы. Строго говоря, основная и единственная задача, явно ставящаяся перед А(П)МДЗ, – обеспечить ДВС. Она решается с помощью различных методов контроля целостности (сравнения с эталонами). Задача перехвата процесса старта важна постольку, поскольку необходимо обеспечить возможность доверенного выполнения процедур контроля целостности.

С технической точки зрения реализации перехвата процесса загрузки «более платформозависимые», чем контроля целостности системы. Например, наиболее популярный вариант АМДЗ – это PCI/PCI-e плата расширения для IBM PC-совместимых ЭВМ. Однако многие серверные машины без дополнительных расширителей не имеют необходимых слотов для установки платы. Та же проблема наблюдается на ЭВМ, производящихся компанией «Apple». Решение в данном случае одно – использовать другой интерфейс, например USB или M.2.

Возможность разделения РКБ на функции контроля целостности и перехвата управления проявляется в логике разработки конкретной реализации, так как современные парадигмы разработки программного обеспечения (ПО) и аппаратных устройств (АУ) предполагают функционально-логическое разделение проекта на модули. Реализации перехвата управления РКБ являются чисто аппаратными и функционируют на достаточно низком уровне[1]. Чем плотнее конкретная реализация перехвата процесса загрузки операционной системы (ОС) взаимодействует с аппаратной составляющей средства вычислительной техники (СВТ), тем больше зависит от конкретной аппаратной реализации СВТ, и, как следствие, тем больше проблем возникает с переносом конкретной реализации способа перехвата загрузки ОС с одного СВТ на другое.

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

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

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

Необходимость поддерживать различные аппаратные платформы в составе условно универсального модуля доверенной загрузки уводит разработчика несколько в сторону от основной задачи разработки средства защиты, требуя для поддержки различных нюансов разных платформ погружения в сферу задач разработчиков материнской платы, и это тормозит эволюцию конкретной реализации А(П)МДЗ. В итоге пользователям приходиться либо ожидать поддержки особенностей конкретного СВТ со стороны разработчиков А(П)МДЗ или отказаться от конкретной связки модуля и СВТ в пользу уже совместимой.  

Соблазн реализовать средства защиты на «борту» материнской платы велик, но и тут много недостатков. В конечном итоге страдают пользователи, теряя гибкость решения и свободу выбора.

Функциональная составляющая конкретных реализаций РКБ, специализирующаяся на контроле целостности, более стабильна. Общая логика работы (алгоритм, блок схема) не будет меняться даже в случае перехода от одной платформы к другой. Современные технологии и методы разработки ПО позволяют даже создавать из одного набора исходных данных[2] с минимальными изменениями исполняемые модули для различных архитектур. Безусловно, исполняемые модули другие, но исходники и логика та же. Значение этого фактора трудно переоценить, например, для процесса анализа безопасности РКБ (в частности регуляторами на соответствия государственным требованиям), результаты которого должны гарантировать защищенность компонента безопасности. Грамотное и явное разделение функциональности оптимизирует процесс анализа и исследования, в частности сэкономит время и ресурсы регуляторам или прочим компаниям, осуществляющим подобного рода работы.

Грамотное разделение функциональности модуля доверенной загрузки на два различных устройства увеличило бы эффективность и придало бы большую гибкость процессу производства конкретных реализаций РКБ (АПМДЗ). Любой вариант модуля доверенной загрузки, получался бы композицией двух устройств. Более того, каждое устройство по отдельности (перехватчик управления и устройство контроля целостности) могли бы найти себе нишу на рынке как вместе, так и по отдельности [4].

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

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

  1. Конявский, В. А., Гадасин В. А. Основы понимания феномена электронного обмена информацией (Библиотека журнала «УЗИ»; Кн. 2). Мн.: «Беллитфонд», 2004. – 282 c.
  2. Конявский В. А. Управление защитой информации на базе СЗИ НСД «Аккорд». М.: «Радио и связь», 1999. – 325 c.
  3. Конявский В. А. Методы и аппаратные средства защиты информационных технологий электронного документооборота. Диссертация на соискание ученой степени доктора технических наук. М., 2005.
  4. Алтухов А. А. Концепция персонального устройства контроля целостности вычислительной среды // Вопросы защиты информации: Научно-практический журнал. ФГУП «ВИМИ», 2014. Вып. 4 (107). С. 12–14.
  5. Способ защиты от несанкционированного доступа к информации, хранимой на персональной ЭВМ. Патент на изобретение № 2475823. 20.02.2013, бюл. №5.

[1]Например, аппаратный прерыватель питания материнской платы.

[2] В частном случае речь идет об исходных кодах.


ФорумФорум
Форум ОКБ САПР
Вопросы специалистовВопросы специалистов
Вопросы, которые нам присылают, и наши ответы на них