Контроль целостности системы

Целостность системы должна контролироваться ОС. В ОС UNIX контроль целостности системы осуществляется рядом команд.

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

1) выполнение проверки файловой системы;

2) составление контрольного отчета;

3) проверка базы данных аутентификации;

4) проверка разрешений для системных файлов.

Средства аудита

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

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

1) использования механизма идентификации и аутентификации;

2) внесения объектов в адресное пространство пользователя (на­пример, открытие файла);

3) удаления объектов;

4) действий администраторов;

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

Каждая регистрационная запись должна включать следующие поля:

1) дата и время события;

2) идентификатор пользователя;

3) тип события;

4) результат действия.

Система контроля UNIX использует системные вызовы и утилиты для классификации действий пользователей, подразделяя их на события различного типа. Например, при возникновении события типа «DAC Denials» (отказ доступа при реализации механизма избирательного разграничения доступа) регистрируются попытки такого использова­ния объекта, которые не допускаются разрешениями для этого объекта. Иными словами, если пользовательский процесс пытается писать в файл с доступом «только для чтения», то возникает событие типа «DAC Denials». Если просмотреть контрольный журнал, то легко мож­но увидеть повторяющиеся попытки доступа к файлам, на которые не получены разрешения.

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

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

Например, системный вызов open классифицируется как событие «Сделать объект доступным». Если пользователь выполняет систем­ный вызов open для файла /unix и данный системный вызов завершает­ся успешно, то генерируется контрольная запись об этом событии. Од­нако если системный вызов open заканчивается неудачно в силу того, что пользователь запросил в системном вызове доступ на запись файла /unix, не имея разрешения, то это действие классифицируется как со­бытие «Отказ доступа» для данного пользователя и объекта /unix. Сле­довательно, системный вызов можно отобразить в несколько типов со­бытий в зависимости от объекта, к которому осуществляется доступ, и (или) результата вызова.

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

2. Защита информации
от несанкционированного доступа

2.1. Принципы защиты информации
от несанкционированного доступа

Несанкционированный доступ (НСД)– преднамеренное обращение пользователя к данным, доступ к которым ему не разрешен, с целью их чтения, обновления или разрушения.

Задача защиты информации от НСД решается на основе ряда основополагающих принципов.

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

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

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

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

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

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

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

Рис. 7. Структура монитора обращений

Практическое создание монитора обращений, как видно из приве­денного рисунка, предполагает разработку конкретных правил разграни­чения доступа в виде модели защиты информации. Модель защиты информации – абстрактное описание комплекса программно-технических средств и организационных мер защиты от несанкционированного доступа к информации. Исторически модели защиты информации возникли из работ по теории защиты операционных систем. Первая попытка использования такой модели была предпринята при разработке защищенной ОС Адепт-50 по заказу министерства обороны США. Поведение этой модели описывается следующими простыми правилами:

1) пользователю разрешен доступ в систему, если он входит в множество известных системе пользователей;

2) пользователю разрешен доступ к терминалу, если он входит в подмножество пользователей, закрепленных за данным терминалом;

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

Одна из первых фундаментальных моделей защиты была разрабо­тана Лэмпсоном и затем усовершенствована Грэхемом и Деннингом.

Основу их модели составляет матрица (таблица) доступа А, в которой столбцы O1,О2,...,Оnпредставляют объекты доступа, а строки S1,S2,...,Sm– субъекты доступа. Элемент таблицы A[Si,Оj] содержит список видов дос­тупа T1,T2,...,Tk, который определяет привилегии субъекта Siпо отноше­нию к объекту Оj.

Данная модель предполагает, что все попытки доступа к объектам перехватываются и проверяются специальным управляющим процессом. Таким образом, субъект Siполучит инициируемый им доступ Тkк объекту Оjтолько в случае, если элемент матрицы A[Si,Oj] имеет значение Тk.

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

Рассмотренная выше модель защиты информации относится к классу матричных, которые получили наибольшее распространение вследствие того, что они служат не только для целей анализа логического функцио­нирования системы, но и успешно поддаются реализации в конкретных программах. Так как программы в этих моделях выступают в правилах доступа в качестве субъектов, то они могут, при необходимости, расши­рять права конкретных пользователей. Например, программа может иметь права на сортировку файла, чтение которого пользователю запрещено. В других случаях может потребоваться сужение прав пользователей правами используемых ими программ. В то же время программы могут выступать и в качестве объектов доступа, ти­пичными операциями для которых являются исполнение (Ехесutе) и ис­пользование (Use).

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

Наибольшее распространение получила многоуровневая модель защиты Бэлла – Ла Падула. Основой этой модели являются поня­тия уровня конфиденциальности (формы допуска) и категории (приклад­ной области) субъекта и объекта доступа соответственно. На основании присвоенных ка­ждому субъекту и объекту доступа конкретных уровней и категорий в модели определяются их уровни безопасности, а затем устанавливается их взаимодействие. При этом в модели принимается, что один уровень безо­пасности доминирует над другим тогда и только тогда, когда соответст­вующий ему уровень конфиденциальности больше или равен уровню конфиденциальности другого, а множество категорий включает соответ­ствующее множество другого. Уровни конфиденциаль-ности являются упорядоченными, в то время как уровни безопасности упорядочены час­тично, так что некоторые субъекты и объекты могут быть несравнимы. Например, на рис. 8 уровень безопасности L1доминирует над уровнем L3, так как его уровень конфиденциальности выше,
а множество катего­рий включает множество категорий уровня L3.
С другой стороны, уровни безопасности L1и L2являются несравнимыми, так как множество категорий уровня безопасности L1 не совпадает с множеством категорий уровня безопасности L2.

Рис. 8. Взаимодействие уровней безопасности

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

 ни чтение, ни изменение;

 только чтение;

 только изменение;

 и чтение, и изменение.

Главная цель модели состоит в предотвращении потоков информации из объектов более высокого уровня безопасности в объекты более низкого уровня. Данная цель реализуется выполнением следующих правил:

 если субъект доступа формирует запрос на чтение, то уровень безопасности субъекта должен доминировать над уровнем безопасности объекта;

 если формируется запрос на изменение, то уровень безопасности объекта должен доминировать над уровнем безопасности субъекта;

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

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

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