Щеглов А.Ю. Защита компьютерной информации от несанкционированного доступа

Подождите немного. Документ загружается.

Глава 5. Архитектура системы защиты

Функционально (с учетом действий пользователя при доступе к ресур-

сам, а также с учетом противодействия НСД к информации механизма-

ми защиты) система защиты должна строиться как иерархическая систе-

ма - - могут быть выделены несколько основных уровней иерархии

защиты. Выделение данных уровней и их реализация является необхо-

димым (определяется формализованными требованиями) условием пост-

роения системы защиты.

Функциональная модель системы защиты, которая может быть получена

на основании анализа формализованных требований к системе защиты,

представлена на рис. 5.3.

л1я;м!111Д

Для конкретных уровней функциональной модели системы защиты сопостав-

ление механизмов защиты не приводится, т.к. оно здесь достаточно очевидно.

Рис. 5.3. Функциональная модель системы защиты информации

на основе формализованных требований

Функциональная модель системы добавочной защиты [9, 10, 12], реша-

ющей рассмотренные выше задачи (п. 3.3.3), представлена на рис. 5.4.

Рис. 5.4. Функциональная модель системы защиты информации на основе

разработанных требований к добавочной защите

Из сравнения функциональных моделей, представленных на рис. 5.3 и

рис. 5.4 видно, что с целью решения сформулированных выше задач

добавочной защиты в модель защиты включены:

Часть II. Архитектурные принципы построения системы защиты информации

» уровень контроля (мониторинга) активности ПО системы защиты;

» уровень контроля (мониторинга) наличия оборудования системы защиты;

» кроме того, принципиально изменены функции уровня контроля це-

лостности — данный уровень защиты здесь функционально предназ-

начен для контроля (мониторинга) корректности выполнения функ-

ций защиты и контроля целостности.

Рассмотрим назначение уровней защиты в приведенной функциональной

модели. Задачи, решаемые на различных уровнях, реализуются с учетом

сформулированных для них требований. При этом каждый уровень защиты

будем рассматривать как функциональный блок в представленной схеме.

Уровень авторизации пользователя при доступе к ресурсам системы

Для начала надо определиться, кого мы будем понимать под пользова-

телем. К пользователям, в рамках уровневой модели защиты, могут быть

отнесены как пользователи приложений, решающие с использованием

данного средства соответствующие производственные задачи, так и ад-

министратор безопасности, являющийся пользователем системы защиты.

Уровень авторизации пользователя обеспечивает проверку учетных парамет-

ров пользователя при доступе в систему и к системе защиты. Также этим

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

процесса (приложения) после авторизации ответственного лица и др. Рас-

смотрению авторизации целиком посвящена третья часть данной книги.

Уровень управления доступом (разграничения прав доступа)

пользователя к ресурсам

Уровень управления доступом (разграничения прав доступа) реализу-

ет собственно разграничительную схему доступа пользователей к ре-

сурсам защищаемого объекта, а также политику администрирования

системы защиты в рамках выполнения политики информационной бе-

зопасности. Под системой защиты здесь понимаем соответствующие

механизмы, встроенные в ОС, СУБД, приложения, а также добавоч-

ные механизмы защиты.

Для решения задачи управления доступом к ресурсам на этом уровне

выделяются локальные и сетевые ресурсы. К локальным ресурсам, тре-

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

» файловые объекты (логические диски, каталоги, файлы);

« устройства со сменными носителями (в частности, дисковод и

CD-ROM);

* отчуждаемые физические носители информации (в частности диске-

ты и CD-ROM диски);

коммуникационные порты;

» локальные принтеры;

Глава 5. Архитектура системы защиты

» процессы (исполняемые файлы), в том числе процессы ОС, системы

защиты и приложений — в части их модификации и запуска;

» настройки ОС (для ОС Windows — реестр ОС);

* файлы настроек системы защиты;

» файлы настроек приложений;

» при использовании СУБД — таблицы данных и таблицы настроек;

» настройки «рабочего стола»

'ОС

и т.д.

К сетевым ресурсам (в составе ЛВС), требующим разграничения доступа

пользователей, относятся:

* разделяемые сетевые ресурсы (по протоколу NetBios для сети

Microsoft),

к которым относятся разделяемые файловые объекты, устройства со

сменными носителями (виртуальные каналы связи сети Microsoft);

» сетевые ресурсы, например, по протоколу TCP/IP

(хосты,

протоко-

лы), виртуальные каналы связи сети TCP/IP;

« сетевые принтеры;

сетевые службы и приложения (в том числе приложения информаци-

онных систем, например, СУБД), в части их модификации и запуска;

файлы настроек сетевых служб и приложений и т.д.

Разграничительная политика рассматривается как в виде разграничения

доступа к ресурсам, так и в виде функций, реализующих разрешенный

доступ (например, чтение, запись, исполнение и др). Решение задач раз-

граничения доступа пользователей к ресурсам предполагает и реализацию

процедур возврата коллективно используемого ресурса в исходное состо-

яние для его предоставления другому пользователю (например, очистка

оперативной и внешней памяти).

На этом уровне также решается задача распределения функций администри-

рования безопасностью системы между пользователями, системным (сетевым)

администратором, администраторами СУБД и приложений, администратором

безопасности. При этом решается задача централизации схемы администри-

рования безопасности, в рамках которой изменение настроек безопасности

на различных уровнях иерархии системы должно осуществляться только при

непосредственном контроле со стороны администратора безопасности.

Вопросы корректности и полноты, а также возможности противодей-

ствия группе скрытых угроз, связанных с нерегламентированными дей-

ствиями пользователя, для данного уровня защиты будут рассматриваться

в четвертой части.

Уровень контроля (мониторинга) корректности

выполнения функций защиты и контроля целостности

Отметим, что сама по себе задача контроля целостности предполагает

возможность несанкционированного доступа к информации (в против-

Часть II. Архитектурные принципы построения системы защиты информации

ном случае достаточно первых двух уровней защиты). Таким образом,

данный механизм априори служит противодействию скрытым угрозам в

предположении, что злоумышленником преодолены первые два уровня

защиты, которые реализуют разграничительную политику доступа к ре-

сурсам защищаемого объекта.

В рамках формализованных требований недостаток механизма контроля

целостности состоит в том, что данный механизм, во-первых, реализует

очень ограниченный набор функций, а во-вторых, не позволяет обеспе-

чивать эффективную реакцию на скрытую атаку в реальном времени. По

сути он только фиксирует ее факт и последствия.

С учетом сказанного функциональные задачи этого уровня защиты имеет

смысл принципиально расширить. При этом к уже существующим задачам

контроля целесообразно добавить контроль (мониторинг) корректности вы-

полнения разграничительной политики доступа, реализуемой на предыдущем

уровне. В том числе на этом уровне следует в реальном времени фиксиро-

вать факты использования злоумышленником ошибок и закладок в систем-

ном и прикладном ПО, а также оказывать противодействие данной группе

скрытых угроз. К этому уровню также следует отнести контроль целостности

программ и данных, то есть контроль объектов файловой системы.

В отличие от двух предыдущих уровней, где соответствующие механиз-

мы (программные модули системы защиты) запускаются асинхронно по

факту запроса в системе на доступ к ресурсу, данный уровень реализует

синхронную процедуру контроля. При этом он контролирует соответству-

ющие события периодически, что связано с его более сильным влияни-

ем на загрузку вычислительного ресурса защищаемого объекта по срав-

нению с большинством механизмов защиты двух предыдущих уровней.

Исключение составляют лишь реализуемые на предыдущем уровне ме-

ханизмы распределения функций администрирования безопасностью си-

стемы между пользователями, системным (сетевым) администратором, ад-

министраторами СУБД и приложений, а также администратором

безопасности. Эти механизмы также реализуются с использованием син-

хронной процедуры контроля.

Подробно эти технологии и особенности их реализации рассматривают-

ся в соответсвующих главах книги (п. 16.2 и гл. 17).

Уровень контроля (мониторинга) активности системы защиты

Очевидно, что большинство задач защиты информации решаются про-

граммно, т.е. защищенность компьютерной информации обеспечивается

до тех пор, пока активно ПО системы защиты. При этом включение в

систему механизмов добавочной защиты, которые могут быть реализова-

ны на различных уровнях (как на системном, так и на прикладном), свя-

зано с появлением дополнительной группы угроз — угроз загрузки сис-

Глава 5. Архитектура системы защиты

темы без механизмов добавочной защиты и угроз перевода механизмов

защиты в пассивное состояние (отключение) в процессе функциониро-

вания защищаемого объекта.

В задачи данного уровня входит контроль активности системы защиты,

с предотвращением возможности функционирования системы в незащи-

щенном состоянии. Последнее может быть связано как с возможностью

загрузки ОС без системы защиты (либо с усеченными функциями), так

и с возможностью перевода системы защиты, либо ее компонент, в пас-

сивное состояние в процессе функционирования защищаемого объекта.

Очевидно, что активность одной программы не имеет смысла контроли-

ровать другой программой, запущенной на том же компьютере. Поэтому

в рамках данного уровня должны быть реализованы следующие две воз-

можности анализа активности системы защиты:

* локальная — с использованием аппаратной компоненты (платы);

* сетевая — удаленно, администратором с сервера безопасности.

При реализации данного уровня защиты должно

оказываться

противо-

действие как явным, так и скрытым угрозам. Соответствующая техноло-

гия защиты рассматривается в шестой части книги.

Уровень контроля (мониторинга)

наличия оборудования системы защиты

Данный уровень защиты целесообразно реализовывать в том случае, если

система защиты содержит аппаратную составляющую. При этом защита

от угрозы удаления аппаратной компоненты, помимо организационных

мероприятий, может обеспечиваться техническими средствами.

Изначально данный уровень обеспечивает техническую защиту от угрозы

удаления аппаратной компоненты системы защиты. Однако его реализация

позволяет комплексировать в единой технической системе защиты инфор-

мации различные функции защиты: защиты компьютерной информации,

контроля доступа в помещения, противопожарной безопасности и т.д. При-

чем все это будет доступно с единого рабочего места администратора.

Функции аппаратной компоненты защиты и методы ее реализации бу-

дут рассмотрены в шестой части книги.

5.2.2. Сводные рекомендации по отдельным

уровням функциональной модели

С учетом сказанного в данном разделе можем сделать следующие выводы:

При построении системы добавочной защиты информации целесо-

образно принципиально пересмотреть функции уровня контроля

Часть II. Архитектурные принципы построения системы защиты информации

целостности. Будем позиционировать данный уровень защиты, как

уровень контроля (мониторинга) корректности выполнения функ-

ций защиты и контроля целостности.

2. В уровневую функциональную модель защиты имеет смысл вклю-

чить уровень контроля (мониторинга) активности системы защиты,

а при использовании аппаратной компоненты защиты функцио-

нальная модель может быть дополнена уровнем контроля (монито-

ринга) наличия оборудования системы защиты.

3. Уровни же авторизации пользователя и управления доступом должны

обеспечивать решение задач корректности и полноты разграничений

доступа пользователя к ресурсам. Кроме того, должна быть реализова-

на также возможность противодействия группе скрытых угроз, связан-

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

5.3. Регистрация (аудит) событий

Регистрация (аудит) событий осуществляется каждым реализованным в си-

стеме механизмом защиты. С учетом включения в функциональную модель

системы защиты уровня контроля (мониторинга) корректности выполнения

функций защиты и контроля целостности имеет смысл принципиально из-

менить концепцию сбора и обработки регистрационной информации.

Особенностью реализованной модели защиты с точки зрения построе-

ния подсистемы регистрации (аудита) является введение в системе двух

уровней аудита.

* Аудит первого уровня. Этот аудит осуществляется уровнем авторизации

пользователя при доступе к ресурсам системы, а также уровнем управле-

ния доступом (разграничения прав доступа) пользователя к ресурсам. На

этих уровнях ведется полный аудит действий пользователя системы. При

этом фиксируются все действия, связанные как с правомерными, так и

неправомерными попытками доступа пользователя к ресурсам защищае-

мого объекта. Регистрируемыми фактами НСД здесь являются неправо-

мерные (противоречащие реализуемой политике информационной безо-

пасности) действия пользователя (как ошибочные, так и сознательные),

которые предотвращены механизмами защиты рассматриваемых уровней.

» Аудит второго уровня. Осуществляется уровнем контроля (мониторин-

га) корректности выполнения функций защиты и контроля целостно-

сти. Аудит второго уровня уже фиксирует не все действия пользовате-

ля, включая НСД, а только критичные факты НСД, связанные с

преодолением злоумышленником механизмов защиты первых двух уров-

ней рассматриваемой модели. По существу, на данном уровне осуще-

ствляется мониторинг корректности функционирования разграничи-

тельных механизмов защиты. При этом здесь уже речь идет не об

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

Глава 5. Архитектура системы защиты

Таким образом, реализация уровневой модели защиты позволяет ввести

уровневую модель аудита. При этом принципиально различается функци-

ональное назначение уровней аудита. На первом уровне регистрируются

все действия пользователей, в том числе и попытки НСД. Причем регис-

трации подлежат как сознательные нарушения, так и нарушения, связан-

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

факты НСД, обусловленные сознательными нарушениями пользователей,

связанные с преодолением защиты первых двух уровней модели защиты

(либо с некорректным функционированием данных уровней защиты).

Другими словами, рассматриваемый подход позволяет разделить регист-

рируемые события на некритичные (аудит первого уровня) и критичные

(аудит второго уровня). При этом различаются как требования к опера-

тивности обработки регистрационной информации уровней аудита, так

и вероятность регистрируемых событий на данных уровнях, а также объе-

мы регистрируемой информации.

Так, на первом уровне аудита ведется непрерывная регистрация собы-

тий, т.е. накапливаются большие объемы некритичной к оперативности

обработки регистрационной информации. Подобную информацию адми-

нистратор может получать на сервер по своему запросу в моменты ми-

нимальной нагрузки на опорную сеть, а затем обрабатывать ее в рамках

проведения расследований по факту НСД.

Напротив, на втором уровне аудита регистрируется критичная к опера-

тивности обработки информация по фактам НСД. Данные этого уровня

аудита должны поступать администратору безопасности немедленно и

обрабатываться в реальном времени. При этом данные обычно поступа-

ют на специальный сервер ошибок — специальную программу сервера

безопасности, а их обработка производится либо автоматически, либо с

привлечением администратора безопасности.

Что касается мониторинга функционирования системы защиты, то от-

метим, что здесь также реализуются два уровня мониторинга: мони-

торинг корректности выполнения системой защиты своих функций и

мониторинг активности системы защиты (возможности выполнения ею

своих функций).

Итак, мы можем сделать вывод, что включение в функциональную мо-

дель защиты уровня контроля (мониторинга) корректности выполнения

функций защиты и контроля целостности позволяет реализовать в систе-

ме двухуровневую схему обработки данных регистрации событий (данных

аудита). Это позволяет выделить

лишь

малую часть регистрационной ин-

формации, к которой выставляются требования по обработке в реальном

времени. Таким образом, реализация двухуровневой модели аудита значи-

тельно повышает оперативность обработки регистрационной информации

администратором безопасности и снижает нагрузку на трафик опорной сети

при реализации сетевой системы защиты.

Зак.

369 97

г л а в а 6

Особенности архитектуры

сетевой системы защиты.

Состав и назначение

функциональных блоков

6.1.

Архитектура сетевой системы защиты

Общим элементом архитектуры любой современной информационной

системы, в том числе, сетевой системы защиты, является использование

в той или иной мере распределенной модели межсетевого взаимодействия

клиент—сервер.

Причем в большинстве случаев это взаимодействие ос-

новывается на протокольных стеках TCP/IP.

В общем случае в ЛВС могут быть реализованы следующие варианты

архитектур системы защиты:

» распределенная архитектура;

• централизованная архитектура;

• централизованно-распределенная архитектура.

Возникает необходимость обоснованного выбора архитектуры системы

защиты, а в случае выбора централизованно-распределенной архитекту-

ры — задача функционального распределения задач защиты между архи-

тектурными компонентами.

Распределенная архитектура системы защиты

Распределенная архитектура представляет собой исходный вариант систе-

мы без обеспечения функций сетевого контроля и управления с выделен-

ного рабочего места администратора безопасности (которое для данной

архитектуры отсутствует). Все механизмы защиты и функции их админи-

стрирования реализуются непосредственно на защищаемом объекте. При

этом какой-либо элемент централизации системы отсутствует как таковой.

К неоспоримым достоинствам подобной архитектуры следует отнести:

* максимальный обеспечиваемый уровень надежности системы защи-

ты, так как отсутствует какой-либо структурообразующий элемент,

отказ которого приводит к отказу всей системы в целом;

Глава 6. Особенности архитектуры сетевой системы защиты

» отсутствие какого-либо влияния системы защиты на пропускную спо-

собность связного ресурса защищаемой сети.

К принципиальным

недостаткам

архитектуры относится:

» невозможность обеспечения оперативного управления рассредоточен-

ной системой защиты в целом. То есть невозможно управление защи-

той одного объекта при зарегистрированных событиях на других за-

щищаемых объектах. Можно управлять лишь отдельным элементом

защиты с локальной консоли;

* невозможность оперативной обработки регистрационной информа-

ции, а также невозможность оперативного контроля действий пользо-

вателей на защищаемых сетевых объектах. Как следствие, невозмож-

но оперативное расследование по фактам НСД.

. -

Централизованная архитектура системы защиты

В основу централизованного типа архитектуры положен принцип удален-

ной реализации защиты объектов с центральной консоли администрато-

ра безопасности. Все функции по обеспечению информационной безо-

пасности защищаемых объектов делегированы одной компоненте системы

защиты — серверу безопасности. Таким образом в основе централизован-

ных систем лежит построение виртуальной сетевой системы защиты,

наложенной на опорную сеть передачи данных (ЛВС).

Естественно, что данной архитектуре присущи достоинства и недостат-

ки, диаметрально противоположные распределенной архитектуре.

К неоспоримым недостаткам подобной архитектуры следует отнести:

» минимальный обеспечиваемый уровень надежности системы защиты. В

системе присутствует один структурообразующий элемент — сервер безо-

пасности, отказ которого приводит к отказу всей системы в целом;

» максимальное влияние системы защиты на пропускную способность

связного ресурса защищаемой сети.

К принципиальным достоинствам архитектуры относится:

« обеспечение максимально оперативного управления рассредоточен-

ной системой защиты в целом (управление защитой одного объекта

при зарегистрированных событиях на других защищаемых объектах).

Возможность управлять всеми элементами защиты с локальной кон-

соли сервера безопасности;

» максимальные возможности по оперативной обработке регистраци-

онной информации и контролю над пользователями. Как следствие,

можно выделить максимальную оперативность при расследовании фак-

тов

НСД.

Часть II. Архитектурные принципы построения системы защиты информации

6.2. Централизованно-распределенная

архитектура системы защиты

Достоинства и недостатки

Реализация данной архитектуры призвана объединить в себе все досто-

инства архитектурных решений, рассмотренных выше (соответственно,

устранить их недостатки).

Останавливаясь на рассмотрении достоинств и недостатков распределен-

ной и централизованной архитектур системы защиты, естественно (ин-

туитивно понятно) будет сделать предположение об оптимальности сле-

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

централизованно-распределенной сетевой системы защиты:

полностью распределенно должны решаться задачи защиты рабочих

станций и серверов ЛВС. Реализовываться это должно устанавливае-

мой на них клиентской частью системы защиты;

» централизованно должны решаться:

- администрирования клиентских частей системы защиты;

- обработка регистрационной информации, собираемой клиент-

скими частями системы защиты;

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

Все это должно производиться с серверной части системы защиты -

сервера безопасности.

Обратим внимание, что при централизованно-распределенной системе

защиты, ее администрирование осуществляется полностью централизо-

ванно. То есть выполняется то принципиальное условие, которое было

нами обосновано ранее. Описываемое далее распределение и масштаби-

рование

администрантивных

функций означает лишь распределение ре-

сурсов, призванное снизить вред от возможного выхода из строя сервера

безопасности. При этом сам принцип централизованного администриро-

вания сохраняется, так как вершиной системы защиты является не сер-

вер безопасности, а администратор безопасности. То есть именно адми-

нистратор безопасаности является централизующим звеном.

Итак для поддержания функционирования системы в случае отказа сер-

вера безопасности функции администрирования клиентских частей дол-

жны дублироваться распределенно. Кроме того сетевым агентам (кли-

ентским частям системы защиты) должна отводится часть общей задачи

контроля и управления. При этом настройка клиентских частей произ-

водится самим администратором безопасности (в рамках централизован-

ной схемы администрирования), а база данных администратора безопас-

ности оказывается распределенной.

100