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

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

Глава 16. Практическая реализация механизмов добавочной защиты

16.2.2. Проблемы централизации схемы

администрирования

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

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

ратором (ввиду сложности и специфики их администрирования) и кото-

рые имеют встроенные механизмы защиты информации. В качестве

примера таких приложений можно рассмотреть СУБД. С одной сторо-

ны, возлагать функции по администрированию СУБД на администрато-

ра безопасности, наверное, нецелесообразно. С другой стороны, СУБД

вносит новый объект доступа — «ТАБЛИЦА», разграничение к которо-

му реализуется встроенными механизмами защиты СУБД и администра-

тор должен иметь контроль над ними.

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

Ч™ защитных механизмов СУБД было рассмотрено в п. 14.6.2.

16.2.3. Метод централизации схемы

администрирования

Для решения задачи централизации схемы администрирования может ис-

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

КСЗИ

«Панцирь». Пусть

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

ко уровней иерархии, к которым можно отнести системный уровень, уро-

вень СУБД и уровень приложений. На каждом уровне решаются задачи

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

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

(например, к таблицам на уровне СУБД), администрирование которыми

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

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

(некоторые задачи, например, создание разделяемого ресурса для ОС

Windows 95/98 вообще решаются пользователем). Сказанное проиллюст-

рировано рис. 16.4.

Для обеспечения информационной безопасности сложной системы дол-

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

ты информации. Однако в данном случае это невозможно, ввиду того,

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

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

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

сложная задача и не всегда достигаемая в принципе. При децентрализа-

ции схемы администрирования информационной безопасности снижается

ее защищенность (администраторы соответствующих уровней иерархии

281

Часть

IV.

Управление доступом к ресурсам

Администратор

приложений

Администратор

СУБД

Системный

администратор

(администратор

безопасности)

Настройка

механизмов

уровня платформы (ОС)

Блок анализа

текущих настроек

механизмов

управления

доступом

Администратор

• безопасности

Автоматическое

восстановление настроек

Рис. 16.4. Иллюстрация распределения задач

администрирования информационной безопасностью

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

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

Идея метода централизации схемы администрирования состоит в следу-

ющем [9,

17]:

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

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

мы (ОС) формируются эталонные копии настроек механизмов защиты

(в частности, таблиц настроек безопасности СУБД — таблицы пользова-

телей и паролей, таблицы ролей и т.д.). Эти эталонные копии настроек

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

ступом (в соответствующих объектах, доступ к которым разрешен толь-

ко администратору безопасности). В процессе функционирования систе-

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

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

лонными (например, при помощи контрольных сумм). Если обнаружи-

вается расхождение, то текущие настройки восстанавливаются из эталон-

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

Таким образом, достигается следующий результат

--на

уровне СУБД и

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

администраторы соответствующих уровней, но введение их в действие

(равно как и любое изменение) возможно только при участии админист-

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

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

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

тического восстановления настроек из эталонных копий.

282

Глава 16. Практическая реализация механизмов добавочной защиты

16.2.4. Схема централизации администрирования

сложного иерархического объекта

На рис. 16.5 приведена схема централизации администрирования меха-

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

ющей несколько уровней администрирования).

Работает схема следующим образом. Перед началом работы пользователь дол-

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

метры авторизации — имя и пароль пользователя блок 1 запрашивает и получа-

ет от блока 5. Данные текущего пользователя блоком 1 выдаются в блок 4,

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

зарегист-

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

информационным ресурсам со входа

(запрашивается объект доступа,

например, файл и действия — чтение или запись и т.п.) блок 4 анализирует

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

параметры доступа. Если они не противоречивы — запрашиваемый доступ

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

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

Рис.

16.5.

Схема централизации администрирования

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

283

Часть IV. Управление доступом к ресурсам

Со входа 12 задаются параметры прав доступа. Изменять данные права

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

зависимости от иерархического уровня системы это может быть как соб-

ственно пользователь, так и один из администраторов: системный, СУБД,

приложения). При этом должен

быть'Выработан

соответсвующий

сигнал

от блока 4, формируемый после

авторизации

пользователя и его запроса

(со входа

11)

на получение доступа к блоку 5 (блок 5 в общем случае

также является файловым объектом).

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

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

ности должен пройти авторизацию со входа 13, которая осуществляется

блоком 2. Параметры авторизации — имя и пароль администратора безо-

пасности блок 2 запрашивает и получает от блока 6. Данные текущего

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

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

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

При запросе пользователем (администратором безопасности) доступа к

информационным

ресурсам со входа 18 блок 7 анализирует заданные для

пользователя права доступа и запрашиваемые пользователем параметры

доступа. Если эти права не противоречивы, то запрашиваемый доступ

разрешается и соответсвующий сигнал подается в блок 6.

Со входов 14 либо 15 задаются параметры прав доступа. Изменять данные

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

соответствующие полномочия — если выдается соответствующий сигнал

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

тора безопасности) и его запроса (со входа 18) на получение доступа к блоку

6. Блок 6 в общем случае также является файловым объектом).

Таким образом, блоки 1, 4, 5 служат для контроля доступа пользователей к

файловым объектам. Администрирование этих блоков осуществляется либо

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

СУБД, приложений). Администратор безопасности, пройдя авторизацию в

блоке 2, в рамках своих полномочий (его доступ разграничивается блоком 7)

создает в блоке 6 эталонные настройки либо ограничения на настройки

разграничений, заданных в блоке 5. Создание эталонных настроек предпо-

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

граничений доступа, являющаяся эталоном для блока 5.

Администратор безопасности имеет две возможности задания таких на-

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

мер, с клавиатуры), либо копированием их из блока 5. При этом адми-

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

блока 5 перезаписываются в блок 6. Работа блока 8 на это время блоки-

руется. Другой режим — это задание ограничений на возможные в блоке

5 настройки. Например, разрешить пользователю для разделения только

284

Глава 16. Практическая реализация механизмов добавочной защиты

какой-либо диск, каталог, файл, либо, наоборот, запретить пользовате-

лю для разделения диск, каталог, файл и т.д.

Данные ограничения также в блок 6 выдаются со входа 14 после обра-

ботки соответствующего запроса администратора безопасности со входа 18

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

ется его доступ блоком

7).

Итак, администратором безопасности в блоке 6 создаются эталонные

настройки (с клавиатуры — со входа 14, либо копированием из блока 5 -

со входа 15) либо ограничения на разграничения прав доступа, в соот-

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

формационным ресурса со входа

11.

Далее администратором безопасности со входа 16 задается режим конт-

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

да 3 запускается таймер — блок 3. Сигналами с выхода блока 3 в блок 8

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

граничения доступа (из блока 5) и эталонные настройки, либо ограни-

чения (с блока 6).

Блок 8 осуществляет сравнение текущих и эталонных настроек либо вы-

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

обнаружении некорректности текущих

настроек,

блок 8 выдает об этом

сигнал в блок 9. Блок 9, получая текущие настройки из блока 5 и эта-

лонные настройки либо ограничения на настройки из блока 6, коррек-

тирует текущие настройки в соответствии с разграничениями, задавае-

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

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

мер (блок таймера 3) отключается со входа 17.

Ввиду того, что блок 6 также представляет собою файловый объект, раз-

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

выхода блока 4 проходит дополнительное разграничение на блоке 7 (блок

7 запрещает корректировку информации в блоке 6 всем, кроме админи-

стратора безопасности). В случае корректного запроса доступа пользова-

телем блоком 7 вырабатывается сигнал на выход 19.

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

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

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

Возможны следующие режимы функционирования вышеприведенной

схемы администрирования:

* Все управление безопасностью осуществляется администратором безо-

пасности. В этом случае он самостоятельно (со входа 14) заносит в

блок 6 эталонные настройки доступа. После этого запускает таймер

(блок 3) со входа 17. Система переходит в режим контроля текущих

285

Часть IV. Управление доступом к ресурсам

настроек разграничения доступа в блоке 5 — заносит туда настройки

из блока 6 при первом обнаружении несовпадения, фиксируемом

блоком 8. При этом любые изменения настроек блока 5 будут автома-

тически восстановлены. Интервал времени, через который необходи-

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

этого интервала не позволит возможным несанкционированным из-

менениям вступить в действие.

* Администратором безопасности решаются задачи контроля и противо-

действия несанкционированному изменению настроек безопасности. В

этом режиме администратор безопасности после соответствующего

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

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

стройки сигналом со входа 15 в блок 6 — эти настройки считаются

корректными (эталонными). Затем запускает подсистему контроля

настроек, запустив блок таймера 3 со входа 17.

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

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

чения доступа к информационным ресурсам, хранящиеся в блоке 5, в

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

ках разграничений задаваемых блоками 1 и 4 (т.е. любые изменения,

проводимые без ведома администратора безопасности будут немед-

ленно устранены).

Для изменения эталонных настроек необходимо отключить блок тай-

мера 3 (со входа 17), изменить настройки таблицы разграничений

прав доступа в блоке 5 (соответствующим пользователем или админи-

стратором, в рамках полномочий, заданных блоками 1 и 4, в случае

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

ра безопасности) администратором безопасности, после чего (бло-

ком 2) со входа 15 переписать в блок 6 новые корректные настройки.

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

• Администратором безопасности вносятся ограничения на возможности за-

дания параметров безопасности. В этом режиме предполагается, что

администратором безопасности в блоке 6 задаются не эталонные таб-

лицы настроек для блока 5, а ограничения на настройки. Возможны

два режима ограничений — запрещение и разрешение.

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

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

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

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

пример, создать общую папку) запретить доступ к файловому объекту

на запись и т.д. Т.е. данный режим реализует правило: все, что не

запрещено администратором безопасности — разрешено в системе.

Другой режим реализует альтернативное правило: все, что не разреше-

но администратором безопасности, запрещено в системе. В этом слу-

286

Глава 16. Практическая реализация механизмов добавочной защиты

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

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

иной администратор. Например, администратор безопасности может

разрешить доступ только к одному логическому диску. Доступ к ката-

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

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

В данном режиме ограничения заносятся администратором безопас-

ности (после

его

авторизации блоком 2) в блок 6, после чего со

входа 17 запускается блок таймера

Текущие настройки, располо-

женные в блоке 5, и ограничения из блока 6 с интервалом, заданным

со входа 16, поступают в блок 8, который анализирует, не противоре-

чат ли настройки в блоке 5 ограничениям, задаваемым блоком 6.

Если противоречат, то блок 9 осуществляет их корректировку и зано-

сит в блок 5 корректные настройки.

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

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

автоматического восстановления из эталонной копии, позволяет ввести

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

ным звеном схемы администрирования, обеспечивающий возможность

только санкционированного изменения настроек механизмов защиты в

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

Контроль

корректности

функционирования

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

Методы контроля целостности

Часть V

Метод уровневого контроля списков

санкционированных событий

Разработка и оптимизация

механизма уровневого контроля,

как механизма реального времени

4 Механизмы контроля целостности

файловых объектов

глава 17

Метод уровневого

контроля списков

санкционированных событий

Ранее в книге рассматривались механизмы разграничительной политики

доступа к ресурсам. Обсуждались различные приемы. Вырабатывалось оп-

тимальное решение, а также рекомендации и требования к нему. Однако в

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

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

политику доступа к ресурсам защищаемого объекта. Исходя из этого, в си-

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

» Контроль (мониторинг) корректности функционирования механизмов за-

щиты. Этот контроль должен позволять анализировать корректность

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

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

тельном этапе вырабатывать реакцию системы защиты и отсекать

попытки несанкционированных действий пользователей по отноше-

нию к

ней.

» Контроль целостности файловых объектов. Если предыдущий меха-

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

ной политики доступа, то данный механизм исходит из того, что эта

политика была преодолена. В соответствии с этим контроль целост-

ности призван свести к минимуму возможные потери от свершивше-

гося

НСД.

При этом он контролирует целостность заданных файло-

вых объектов и в случае необходимости может восстановить файловые

объекты в соответствии с эталонами.

С целью решения данной задачи в функциональную модель системы

защиты (см. главу 2) введен дополнительный уровень защиты. Этот уро-

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

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

роль целостности файловых объектов.

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

механизмов добавочной защиты, так и для усиления встроенных в ОС

Зак.

369 289

Часть V. Контроль корректности функционирования механизмов защиты

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

ошибки в реализации и ошибки в настройке при их администрировании.

17.1.

Основы метода уровневого контроля

списков санкционированных событий

В качестве возможного способа противодействия ошибкам и закладкам

в системном и прикладном ПО, а также контроля (мониторинга) кор-

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

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

уровневого контроля списков санкционированных событий (МУКССС).

Ранее было сказано, что контроль корректности должен реализовывать

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

за действиями пользователей. Рассмотрим, как оба этих направления ре-

ализуются предлагаемым методом уровневого контроля списков.

17.1.1.

Контроль

за

действиями

пользователей

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

ставить набором некоторых событий. Например, какой пользователь об-

ращается к ресурсу, какой процесс запущен пользователем, к какому

ресурсу обращается пользователь и т.д.

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

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

рактеризовано соответствующим списком санкционированных (разрешен-

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

списками, например, могут быть:

* список зарегистрированных в системе пользователей;

* список разрешенных к запуску процессов;

* список запрещенных событий в системе;

список ключей реестра ОС, разрешенных для изменения;

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

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

ошибок в ПО, можно показать, что большинство преодолений политики

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

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

текущие события системы в соответствии со списками разрешенных со-

бытий (списками санкционированных событий), можно контролировать

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

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

вырабатывать-

290