Защищеныые системы – общие принципы

В настоящий момент перед отечественными разработчиками средств защиты стоят две противоречивые задачи:

– реализовать довольно высокие по мировым меркам требования безопасности, предъявляемые отечественными пользователями к системам обработки закрытой информации;

– сохранить в полном объеме совместимость с используемыми повсеместно незащищенными прикладными импортными средствами.

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

Ни один из популярных продуктов не рассчитан на решение задач, связанных с обеспечением безопасности, о чем свидетельствует отсутствие сертификации этих продуктов в западных странах в работоспособной конфигурации. Единственные системы общего назначения, получившие сертификаты безопасности, — это специальные защищенные версии ОС Unix типа CX/SXHarris Computer Systems Corporation, HP-UX BLS Hewlett Packard Corporation, Trusted IRIX/B Silicon Graphics Inc. и т. д.. Однако возможности применения подобных систем в нашей стране ограничены дорогой эксклюзивной аппаратной платформой, да и сама возможность поставки систем такого класса также вызывает сомнение. Поэтому отечественный потребитель, нуждающийся в средствах работы с закрытой информацией, в полной мере является заложником ситуации, сложившейся на рынке программных средств, и вынужден искать частные или половинчатые решения своих проблем.

Концепция построения защищенных систем

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

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

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

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

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

Схема применения предложенной концепции в ходе разработки защищенной системы показана ни рис 1.

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

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

clip_image002

Рис. 1. Схема применения концепции построения защищенных систем

clip_image004

Рис. 3. Предпосылки нарушений безопасности

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

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

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

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

3. Поскольку ошибок программирования избежать все равно невозможно, при построении защищенных систем и реализации средств защиты необходимо минимизировать объем программного кода, ошибки в котором являются критичными с точки зрения безопасности. Следствием этого принципа является необходимость минимизации объема функций кода, входящего в состав так называемой TCB (Trusted Computing Base).

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

Методы обеспечения корректности защиты и их применение на различных стадиях разработки защищенных систем показаны на рис. 4.

clip_image006

Рис. 4. Обеспечение корректности при построении защищенных систем

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

Универсальные методы обеспечения безопасности

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

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

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

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

2. Обобщенное представление субъектов и объектов в виде однозначно идентифицируемых векторов значений атрибутов безопасности.

3. Использование специального языка для задания правил разграничения доступа с помощью логических предикатов.

4. Раздельная реализация контроля доступа субъектов к объектам и управления значениями их атрибутов безопасности.

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

Интеграция средств защиты и распространенных приложений

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

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

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

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

В качестве основы для такой архитектуры предлагается использовать иерархическую структуру, присущую современным программным системам, в которых высокоуровневые средства опираются на сервисы, предоставляемые компонентами нижнего уровня. Предлагается использовать для построения защищенных систем такую иерархическую архитектуру, в которой взаимодействия между сущностями системы, представляющими интересы пользователей, контролируется средствами защиты, расположенными на уровне, находящемся ниже того, на котором реализуется взаимодействие. Назовем этот уровень “уровнем контроля”. Поскольку интересы пользователей могут представлять многочисленные приложения, функционирующие на нескольких уровнях иерархии, может потребоваться несколько уровней контроля, но при этом должно выполняться указанное требование — контроль должен осуществляться средствами уровня, лежащего ниже того, на котором происходит взаимодействие. При этом безопасность взаимодействий для каждого слоя опирается на безопасность взаимодействий нижнего уровня. Единственное условие, которые должно быть выполнено в такой архитектуре — это невозможность осуществления информационных взаимодействий в обход контроля со стороны средств защиты (в обход сервиса нижнего уровня). Схема, иллюстрирующая предложенную архитектуру показана на рис. 5.

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

clip_image008

Рис. 5. Контроль взаимодействия в защищенной системе

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

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

2. Определить уровень, на котором необходимо осуществлять контроль доступа к этим информационным ресурсам в соответствии с указанными требованиями.

3. Спроектировать архитектуру защищенной системы, предусматривающую размещение средств защиты на выбранном уровне.

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

5. Осуществить интеграцию средств защиты и прикладных средств в состав единой системы в соответствии с разработанной архитектурой.

пресс-релизы

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100