* Отказы ресурса
* Действия Администратора системы/оператора
* Действия авторизованной подсистемы
.
- 5-22 -
* Действия секретной базы данных
* События подсистемы контроля
Вы можете, используя эти типы событий, выполнять выборочный
сбор и редукцию данных контроля. Интерфейс подсистемы контроля
позволяет составлять список типов событий либо для подсистемы
контроля, либо для программы редукции данных.
Подсистема контроля использует типы событий для того, чтобы
определить, нужно ли заносить контрольную запись в контрольный
журнал. Будучи Администратором контроля, вы полностью управляете
отбором событий для контроля.
Для управления контролем типов событий в подсистеме контро-
ля имеется глобальная системная маска событий контроля, которая
описана ниже. Подсистема контроля также обеспечивает маску типов
событий для каждого процесса в системе (также описана ниже). Обе
эти маски являются битовыми представлениями целочисленных значе-
ний типов событий, подлежащих контролю.
Системная маска событий контроля
Системная маска событий является глобальной для подсистемы
контроля. Ее можно установить с помощью sysadmsh и изменить в
процессе контроля, если возникает необходимость выбрать другой
набор событий. В системной маске событий каждому типу события
соответствует один бит; он устанавливается равным единице, если
контроль нужен. Это позволяет быстро проверять (с помощью бито-
вых операций), подлежит ли контролю только что созданная запись.
Подсистема контроля использует системную маску событий для вы-
числения пользовательских масок, когда при регистрации в системе
создается новый процесс.
Пользовательская маска событий и маска событий процесса
Вы можете отменить действие общесистемной маски событий для
любого пользователя, установив пользовательскую маску событий в
пользовательской строке защищенного пароля. Каждый процесс в
системе обладает маской событий процесса, которая говорит систе-
ме, что нужно контролировать для данного процесса. При регистра-
ции пользователя программа login анализирует пользовательскую
маску событий и устанавливает маску событий процесса для команд-
ного процессора регистрации следующим образом.
В пользовательской маске событий для каждого типа события
контроля предусмотрено одно из трех значений:
* всегда контролировать это событие
* никогда не контролировать это событие
* использовать системную маску событий контроля
Для каждого типа события контроля маска контроля процесса
устанавливается по пользовательской маске, если в ней указано,
что данное событие контролируется всегда или никогда. В против-
.
- 5-23 -
ном случае маска контроля процесса устанавливается по системной
маске событий контроля. В большинстве случаев в пользовательской
маске событий будет установлено третье значение для всех событий
контроля, в результате чего для этого пользователя будут приме-
няться системные параметры, принятые по умолчанию. Пользователь-
скую маску можно использовать для того, чтобы увеличивать или
уменьшать контролируемый объем информации о пользователях, кото-
рым вы соответственно меньше или больше доверяете по сравнению с
остальными.
Эффективный системный контроль
При использовании подсистемы контроля нужно следовать неко-
торым правилам. Подсистема спроектирована так, чтобы обеспечить
гибкую производительность и надежность и дать возможность соби-
рать те данные контроля, какие вы желаете. Генерация контрольной
записи поддерживает предварительную выборку событий контроля,
идентификаторов пользователей и идентификаторов групп. Предвари-
тельная выборка нужна, если вы по каким-то причинам хотите скон-
центрироваться на каком-либо конкретном пользователе или группе
пользователей (когда отдельные пользователи имеют обычай пытать-
ся обращаться к файлам, к которым им не разрешен доступ). Для
предварительной выборки можно также использовать типы событий -
например, контроль только событий входа в систему и выхода из
нее. Предварительная выборка, кроме того, дает экономию прост-
ранства на диске, так как уменьшается число контрольных записей,
заносимых подсистемой контроля в файлы сбора данных. Но в ис-
пользовании предварительной выборки есть и отрицательная сторо-
на. Если произошло нарушение секретности системы, и это событие
или совершивший его пользователь не был выбран для контроля, то
запись об этом действии будет утеряна.
Поэтому следует быть более консервативными - не делать
предварительную выборку событий контроля и пользователей/групп,
а вместо этого осуществлять полный контроль. В итоге любое про-
исшедшее событие, связанное с секретностью, будет зафиксировано
в контрольном журнале. Недостатки полного контроля: он занимает
много места на диске и увеличивает накладные расходы в системе.
Вы можете комбинировать полный контроль с пост-выборкой,
изучая только записи, представляющие интерес. Пост-выборка обес-
печивает выборочный анализ контрольного журнала на основе типов
событий, идентификаторов пользователей, идентификаторов групп и
имен объектов, а также момента генерации записи. В общем, под-
система контроля в сочетании с утилитой редукции/анализа данных
даст вам с помощью предварительной выборки гибкость при выборе
между системной производительностью и объемом пространства на
диске, а также удобство полного контроля в сочетании с пост-вы-
боркой.
Административные аспекты
Административное управление подсистемой контроля служит
ключом к эффективному контролю. Если тщательно установить и ак-
куратно пользоваться подсистемой контроля, она будет мощным
средством в деле поддержания секретности системы и идентификации
возникающих проблем. Эта подсистема спроектирована в довольно
завершенном виде в терминах охвата событий контроля - как со
стороны действий ядра, так и со стороны использования системных
утилит. Она спроектирована также для обеспечения надежности и
для минимизации влияния на производительность системы в целом.
.
- 5-24 -
Насколько хорошо подсистема удовлетворяет вашим целям, за-
висит от правильного административного управления системой. Вы
управляете согласованием надежности и производительности, ис-
пользуя параметры контроля. Неправильная установка может привес-
ти к низкой производительности, потере данных контроля или ко
всему сразу. Например, решающее значение имеет установка маски
событий контроля для управления типами событий, контролируемыми
подсистемой. Так, если предварительная выборка событий не вклю-
чает события регистрации, то проникновение в систему через ком-
мутируемую линию связи может остаться незамеченным. Поэтому
очень важно тщательно рассмотреть следующие три аспекта:
* задачи, связанные с производительностью
* задачи, связанные с надежностью
* требования к контрольному журналу
Задачи, связанные с производительностью
При оценке влияния подсистемы контроля на производитель-
ность системы важно продумать, какие действия должна выполнять
подсистема. Драйвер устройства подсистемы контроля - это главное
место сбора контрольных записей из всевозможных источников; он
отвечает за внесение этих записей в контрольный журнал. Драйвер
выполняет запись в файл сбора данных, совместно используемый
всеми процессами, контролируемыми в системе. Это напоминает сис-
тему резервирования мест на самолетах, где множество клерков вы-
полняют доступ к общей базе данных. Должны быть предусмотрены
механизмы блокировки, чтобы не допустить смешивания контрольных
записей и обеспечить совместимость базы данных. То же касается и
файлов сбора данных подсистемы контроля.
Механизм внутренней буферизации и стратегия записи (write-
behind) пытаются минимизировать воздействие многократной однов-
ременной записи на файлы сбора данных. Это позволяет подсистеме
обслуживать контрольные записи от процессов и прикладных прог-
рамм в то время, как параллельно идет запись в файлы сбора дан-
ных. Вы можете настроить этот механизм, учитывая, как интенсивно
используется буферизация и как часто идет запись в файл сбора
данных.
Задачи, связанные с надежностью
Так же, как и производительность системы, важна надежность
выдаваемого контрольного журнала. В традиционных системах UNIX
нет возможности сохранить целостность файловой системы в резуль-
тате фатального сбоя системы. Это вызвано тем фактом, что ввод-
-вывод выполняется с помощью пула буферов, в которые запись
(главным образом) ведется асинхронно. Так, изменения, внесенные
в файлы, на самом деле могут оказаться не записанными на диск
при фатальном сбое системы.
Это грустно, так как события, приводящие к фатальному сбою
системы, представляют для вас наибольший интерес с точки зрения
контроля. Очень хотелось бы минимизировать какую бы то ни было
потенциальную потерю данных из подсистемы контроля в результате
.
- 5-25 -
фатального сбоя системы. Для этого подсистема контроля использу-
ет механизм, называемый синхронным вводом-выводом, который вы-
полняет немедленное обновление буферов сбора данных контроля и
индексных дескрипторов файлов сбора данных, когда происходит их
изменение. Это сводит к минимуму возможные потери данных в ре-
зультате фатального сбоя системы.
Существует прямая связь между степенью надежности данных и
производительностью подсистемы контроля. Контрольные записи, ге-
нерируемые механизмом контроля ядра, надежными прикладными прог-
раммами и защищенными подсистемами, обычно имеют длину 40-60
байт. Если каждая запись пишется на диск синхронно, как только
она передана подсистеме, результатом будет низкая производитель-
ность; система ввода-вывода переполняется из-за высокой скорости
генерации записей. Выход состоит в том, чтобы буферизовать запи-
си и писать их в контрольный журнал вместе через назначенные ин-
тервалы времени. Эти интервалы можно определить по истекшему
времени или по пороговой величине накопленных данных. И здесь
также выбор зависит от вас.
Требования к контрольному журналу
И, наконец, последнее, что важно для административного уп-
равления подсистемой контроля, - определить, что именно нужно
контролировать. Можно использовать возможности предварительной
выборки при генерации записей, чтобы контрольный журнал скон-
центрировался на одном или нескольких событиях. Например, систе-
ма может использоваться всего лишь маленькой группой людей, а по
ночам простаивать. Кроме того, в нерабочее время предоставля-
ются несколько коммутируемых линий связи. Возможно, вас интере-
сует только учет того, кто и когда пользуется системой. В этом
случае предварительную выборку можно использовать только для от-
слеживания событий входа в систему и выхода из нее. Попытки про-
никновения в систему со стороны неавторизованных пользователей
будут зафиксированы как неудачные попытки регистрации.
Контроль можно также сосредоточить на конкретных пользова-
телях или группах пользователей. Это позволит вам сконцентриро-
ваться на лицах, подозреваемых в нарушении стратегии секретнос-
ти. Чем меньше запрошено контроля, тем меньше подсистема контро-
ля влияет на производительность системы. Полный контроль приво-
дит к созданию пространной и подробной записи о системных собы-
тиях, но он требует и больше ресурсов для работы. Однако чаще
оказывается удобнее зарегистрировать события и использовать
средства редукции, чтобы потом отбросить ненужные записи, чем
отказаться от сбора записей, действительно необходимых для ана-
лиза проблемы. Это решение зависит от степени секретности, кото-
