Идентификация и аутентификация. Рассмотрим стандартную процедуру идентификации и аутентификации пользователя. Система ищет имя пользователя в файле /etc/passwd и, если пользователь идентифицируется (т. е. его имя найдено), аутентификация заключается в сравнении образа аутентификации от введенного пароля с эталоном. При этом предусмотрены некоторые правила относительно характеристик пароля и возможности его изменения. Но, как показала практика, этих правил недостаточно для реализации надежной защиты.
В надежной системе стандартная процедура идентификации и аутентификации расширена. В ней предусмотрено больше правил, касающихся типов используемых паролей. Введены процедуры генерации и изменения паролей. Изменены местоположение и механизм защиты некоторых частей базы данных паролей. Администратору аутентификации предоставлены дополнительные возможности для контроля за действиями пользователей.
Для усиления качественных и количественных характеристик процедур идентификации и аутентификации в UNIX существуют следующие средства.
Задание администратором учета пользователей и терминалов определенных требований на пароли:
1) ограничение минимальной длины вводимого пользователем пароля;
2) требование наличия в пароле обязательного минимального количества букв нижнего регистра, букв верхнего регистра, цифр и специальных символов;
3) запрещение пользователю введения собственных паролей; разрешение вводить только пароли, созданные системой.
Задание администратором временных ограничений по частоте сменяемости и времени жизни паролей. При этом для удобства пользователя возможно задание интервала между началом требования смены пароля и окончанием срока его действия.
Автоматическое блокирование пользователя на входе в систему по старости пароля, по числу неуспешных попыток входа.
Задание количества и номеров терминалов для входа в систему для каждого пользователя.
Проверка системой паролей пользователей при вводе на их семантические и контекстуальные особенности (вхождение идентификатора, имени пользователя, повторяемость символов и т. д.).
Хранение зашифрованных паролей не в /etc/passwd, как в старых версиях, поскольку этот файл открыт для чтения всем пользователям, а в закрытом от доступа отдельном файле.
Получение статистической информации по времени работы пользователя в системе, его блокировке, номеру терминала и т. д.
Помимо этого существует возможность блокирования по числу неуспешных попыток входа не только пользователя, но и терминала. При этом можно задать интервал времени, который должен пройти между попытками регистрации. Также предусмотрено ведение записей об успешных и неуспешных попытках входа в систему.
Хорошо себя зарекомендовало использование командного интерпретатора rsh. Пользователь, во-первых, не может перейти никуда из своего домашнего справочника. Во-вторых, он может использовать только команды из тех справочников, которые определены в переменной окружения PATH. При этом изменить значение переменной окружения PATH пользователь не может. В-третьих, пользователь не может задавать полные имена программных файлов и перенаправлять потоки ввода-вывода.
Защита файловой системы. Очевидно, что наибольшее внимание в вопросах защиты операционной системы должно быть уделено защите файловой системы.
Каждый файл в системе имеет уникальный индекс. Индекс – это управляющий блок. В литературе он также называется индексным дескриптором, i-node, или i-узлом. Индекс содержит информацию, необходимую любому процессу для того, чтобы обратиться к файлу, например, права собственности на файл, права доступа к файлу, размер файла и расположение данных файла в файловой системе. Процессы обращаются к файлам, используя четко определенный набор системных вызовов и идентифицируя файл строкой символов, выступающих в качестве составного имени файла. Каждое составное имя однозначно определяет файл, благодаря чему ядро системы преобразует это имя в индекс файла. Индексы существуют на диске в статической форме, и ядро считывает их в память прежде, чем начать с ними работать.
Традиционно в файловых системах ОС UNIX за доступ ко всем типам файлов (файлы, каталоги и специальные файлы) отвечают 9 бит, которые хранятся в i-узле.
Первая группа из 3 бит определяет права доступа к файлу для его владельца, вторая – для членов группы владельца, третья – для всех остальных пользователей.
Например, права доступа “rwxr-xr—” к файлу означают, что владелец файла имеет полный доступ, члены группы имеют возможность чтения и выполнения, все остальные имеют возможность только читать данный файл. Для каталога установка бита выполнения “х” означает возможность поиска (извлечения) файлов из этого каталога.
Такая система защиты файлов существует достаточно давно и не вызывает существенных нареканий. Действительно, для того чтобы вручную, т. е. не используя системные вызовы и команды, изменить права доступа к файлу, необходимо иметь доступ к области i-узлов. Для того чтобы иметь доступ к области i-узлов, необходимо изменить права доступа специального файла (например, /dev/root), биты доступа которого также хранятся в области i-узлов.
Иными словами, если случайно или умышленно не испортить права доступа ко всем файлам системы, установленные по умолчанию (обычно правильно) при инсталляции, то можно с большой степенью вероятности гарантировать безопасность работы системы.
Некоторые UNIX-системы (например, Solaris) предоставляют дополнительные возможности по управлению правами доступа к файлам путем использования списков управления доступом (Access Control List). Данный механизм позволяет для каждого пользователя или для отдельной группы установить индивидуальные права доступа к заданному файлу. При этом списки доступа сохраняются всеми системными средствами копирования и архивирования. Нельзя сказать, что введение этого механизма принципиально улучшает защиту файлов, но он вносит некоторую гибкость в процедуру формирования прав доступа к файлам.
Контроль целостности системы. Целостность системы должна контролироваться ОС. В ОС 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. Следовательно, системный вызов можно отобразить в несколько типов событий в зависимости от объекта, к которому осуществляется доступ, и (или) результата вызова.
Однако следует иметь в виду, что при включении всех событий контроля и при активной работе пользователей, объем записываемой информации может достигать нескольких мегабайт на одного пользователя в час.
ВВЕДЕНИЕ В БАЗЫ ДАННЫХ
