Целостность системы должна контролироваться ОС. В ОС 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. Взаимодействие уровней безопасности
Доступ к объекту может рассматриваться либо как чтение (получение из него информации), либо как изменение (запись в него информации). Тогда виды доступа определяются следующими возможными сочета-ниями этих операций:
ни чтение, ни изменение;
только чтение;
только изменение;
и чтение, и изменение.
Главная цель модели состоит в предотвращении потоков информации из объектов более высокого уровня безопасности в объекты более низкого уровня. Данная цель реализуется выполнением следующих правил:
если субъект доступа формирует запрос на чтение, то уровень безопасности субъекта должен доминировать над уровнем безопасности объекта;
если формируется запрос на изменение, то уровень безопасности объекта должен доминировать над уровнем безопасности субъекта;
если формируется запрос на чтение-запись, то уровни безопасности субъекта и объекта должны быть равны друг другу;
если уровни безопасности субъекта и объекта доступа несравнимы, то никакие запросы субъекта не выполняются.
Подводя итог рассмотрению двух классов моделей защиты информации, отметим, что преимущество матричных моделей состоит в легкости представления широкого спектра правил обеспечения безопасности информации. Основной же недостаток этих моделей состоит в отсутствии контроля за потоками информации. Со своей стороны, главным недостатком многоуровневых моделей является невозможность управления доступом к конкретным объектам на основе учета индивидуальных особенностей каждого из субъектов. Следовательно, оба подхода предполагают поиск различных компромиссов между эффективностью, гибкостью и безопасностью. Очевидно, что оптимальное решение вопросов безопасности должно вырабатываться с применением обоих видов моделей защиты.