Индекс
НазадОглавлениеВперед


Глава 10
Защита ресурсов

10.1. Общие требования безопасности

В системе ценностей современного мира информация занимает одно из ведущих мест, и рейтинг ее в этой системе возрастает с течением времени почти экспоненциально. Как всякая ценность, информация должна быть надежно защищена. Защита информации достигается комплексом мер безопасности (security), включающим в себя как обеспечение целостности (непротиворечивости) и сохранности информации, так и контроль доступа к ней.

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

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

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

Основными понятиями обязательного управление безопасность являются уровень секретности и уровень доступа. Каждый объект, включенный в систему защиты, имеет некоторый уровень секретности (например: совершенно секретно, секретно, для служебного пользования и т.д.). Каждый пользователь, получающий доступ к защищенным ресурсам имеет некоторый уровень допуска. Число уровней допуска равно числу уровней секретности. Если обозначить уровни секретности и уровни допуска числовыми кодами, таким образом, чтобы больший числовой код соответствовал большей секретности или более высокому допуску, то правила предоставления разрешений на доступ к ресурсам можно сформулировать следующим образом:

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

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

Министерством обороны США разработана общая классификация уровней безопасности, которая применяется и во всем мире. Эта классификация определяет четыре класса безопасности (в порядке возрастания):

На сегодняшний день некоторые компьютерные системы в бизнесе удовлетворяют требованиям класса B1, однако, большинство коммерческих применений компьютерных систем ограничиваются требованиями класса C2.

Основные требования класса C2 сводятся к следующим:

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

10.2. Объектно-ориентированная модель доступа и механизмы защиты

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

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

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

Кодирование предполагает шифрование информации, составляющей объект. Любой субъект может получить доступ к информации, но воспользоваться ею может лишь привилегированный субъект, знающий ключ к коду. Другой вариант защиты через кодирование предполагает, что расшифровка информации производится системными средствами, но только для привилегированных субъектов. Кодирование не защищает объект от порчи, поэтому оно может использоваться только для защиты узкого класса специфических объектов или в качестве дополнительного средства в сочетании с другими механизмами защиты. Рассмотрение способов кодирования не входит в задачи нашего пособия, оно должно происходить при изучении курса "Защита информации".

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

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

Непроницаемость ящика обеспечивается чаще всего средствами защиты памяти. Область памяти, в которой расположен объект, делается недоступной для любых субъектов, кроме монитора, реализующего операции над объектом. Как мы знаем (см. главу 3), защита памяти поддерживается аппаратными средствами вычислительных систем, и защита объектов, таким образом, представляется реализованной на аппаратном уровне. Надежность такой защиты, однако, в значительной степени иллюзорна. Во-первых, память также представляет собой объект, нуждающийся в защите. От того, насколько сама защита памяти защищена от перепрограммирования ее произвольным субъектом, зависит эффективность всей системы защиты в целом. Во-вторых, аппаратно поддерживается только конечное число уровней защиты памяти, на практике же используются только два уровня: доступ к ограниченному подмножеству адресов и полный доступ. Если в системе имеется большое количество объектов разного типа, то каждый тип обеспечивается своим монитором. Если все мониторы работают с полным доступом, то нет гарантии в том, что монитор в результате, например, ошибки в нем не воздействует на объект, не предусмотренный в данной операции.

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

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

Неизбыточный набор операций повышает надежность объекта, лишая потенциального "взломщика" возможностей воздействовать на объект. Так, например, для объекта "программа" могут отсутствовать операции Read и Write. Действие всех компьютерных вирусов заключаются в том, что они читают программный файл, как файл данных, и дописывают в него (как в файл данных) коды, выполняющие несанкционированные действия. Если программу невозможно читать и писать, то у вируса просто нет возможности "заразить" ее своим кодом.

Перечень всех операций, допустимых для данной пары субъект-объект, составляет привилегию доступа (access privilege) или право доступа (access right) данного субъекта к данному объекту.

Каждая пара субъект-объект при каждом акте доступа взаимодействует в определенном режиме доступа (access mode). Условием разрешения доступа является совпадение запрошенного субъектом режима доступа с его привилегиями по отношению к запрошенному объекту.

Проведение политики контроля доступа включает в себя процедуры аутентификации и авторизации, показанные на рис.10.1.


Рис.10.1. Процедуры аутентификации и авторизации

В соответствии с требованиями безопасности система должна различать пользователей. Пользователь - это некоторое имя, определенное в системе и связанное с некоторым субъектом, который может выполнять доступ к ее ресурсам. Система должна "знать" своих пользователей, следовательно, в системе должна быть некоторая база данных, хранящая дескрипторы пользователей (имена м пароли). Информацию, хранящуюся в дескрипторе пользователя, иногда называют профилем (profile) пользователя. Различение пользователей (и, соответственно, ведение базы профилей) может быть заложено в ядро ОС или выполняться утилитами. По тому признаку, различает ли ядро ОС пользователей, мы и делим ОС на одно- или многопользовательские. (Так, например, OS/2 на уровне ядра является однопользовательской системой, но дополнительное программное обеспечение позволяет вводить регистрацию пользователей.) Хотя утилиты могут превратить однопользовательскую ОС в многопользовательскую, возможности защиты ресурсов в той ОС, у которой эти свойства заложены в ядро, принципиально большие.

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

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

В системах обычно предусматривается возможность входа в систему пользователя-гостя (guest). Такой пользователь имеет доступ только к полностью открытым ресурсам и не имеет никаких полномочий.

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

10.3. Представление прав доступа

Полный набор прав доступа для всех субъектов и всех объектов может быть представлен в виде матрицы доступа, строки которой соответствуют субъектам, а столбцы - объектам (или наоборот). На пересечениях строк и столбцов указываются права доступа для данной пары. Права доступа могут задаваться, например, в виде битовых строк с позиционными кодами. На Рисунке 10.2 представлен пример такой матрицы.


Рис.10.2. Матрица доступа

Как видно даже из рисунка 10.2, в матрице присутствует избыточность - пустые клетки, так как некоторые объекты недоступны для некоторых субъектов. В многопользовательских системах же с большим количеством как объектов, так и субъектов, во-первых, размер матрицы может быть чрезвычайно большим, во-вторых, сама матрица наверняка будет очень сильно разрежена. Поэтому матричное представление прав доступа является неэффективным. Матрица может быть представлена либо в виде списков привилегий (privileges list), либо в виде списков управления доступом (rights list). Списковые структуры позволяют экономить память за счет исключения из матрицы позиций с пустыми значениями доступа.

В первом случае в системе существует таблица субъектов, и с каждым элементом этой таблицы связывается список объектов, к которым субъект имеет доступ (рис.10.3).


Рис.10.3. Списки привилегий

Во втором случае имеется таблица объектов, с элементами которой связаны списки субъектов (рис.10.4).


Рис.10.4. Списки управления доступом

10.4. Дополнительные возможности

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

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

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

Специфицируемые домены могут создаваться и конфигурироваться динамически. Во всех ОС пользователи, разделяющие специфицированный домен, объединяются в группы. ОС поддерживает список групп и с каждой группой связывает отдельный домен. В примере раздела 7.7 мы видели, что Unix различает "группу, в которую входит владелец файла". В более развитых системах защиты пользователь может включаться в несколько групп, и домены групп могут пересекаться. Состав пользователей в группе, состав и возможности домена группы могут изменяться администратором или теми, пользователями, которые имеют на это право. Группам могут даваться также и полномочия. С точки зрения представления информации о безопасности группа выступает как один пользователь, и для каждой группы создается собственная запись в базе профилей. Вместо того, чтобы в список прав включать отдельные записи для всех членов какой-то группы, в список заносится единственная запись для всей группы. Имеются обычно также и системные, предустановленные группы - такие как системные администраторы, операторы и т.п., но состав системных групп может меняться динамически.

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

Еще одним средством сокращения объема такой информации являются интегрированные права, сформированные из нескольких элементарных прав, например, право данных - права читать и изменять данные.

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

В разделе 10.2 мы упоминали о возможности работы в системе "гостя". "Гость" не может иметь никаких индивидуальных или групповых прав, так как он не зарегистрирован в базе профилей, но некоторые объекты в системе могут быть для него доступны. Говоря шире, в системе могут быть объекты, доступные для всех. Права доступа "для всех" называются публичными (public), они реализуются либо в специальной группе пользователей PUBLIC (гости получают идентификатор безопасности этой группы), либо специальным разделом публичных прав в списках прав объектов и групп доступа.

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

Поиск прекращается, если на любом из этапов будут найдены права, соответствующие запрошенному доступу, доступ разрешается. Поиск прекращается, если на любом из этапов будет найдено право Exclude, доступ не разрешается. Если права, соответствующие запрошенному доступу, не найдены, доступ не разрешается. Индивидуальные права, таким образом, имеют приоритет над групповыми, а групповые - над публичными.

В ряде случаев пользователю может понадобиться выполнить какую-либо корректную задачу, включающую в себя доступ к тем системным объектам, к которым процесс права доступа не имеет. Для выполнения этой задачи ОС предоставляет в распоряжение пользователя процесса программы-утилиты, которые гарантируют корректность манипуляций с защищенными объектами. Но если такая утилита будет выполняться в контексте процесса пользователя, то есть, с его идентификатором безопасности, то в доступе ей будет отказано. Для решения этой проблемы применяется, так называемый, адаптивный доступ (adopted access). В дескрипторе исполняемого модуля - системной утилиты сохраняется признак, по которому ОС на время выполнения (только не время выполнения!) такого модуля предоставляет процессу, его вызвавшему, те же права, которые имеет создатель утилиты (привилегированный пользователь). Поскольку права предоставляются только на время выполнения утилиты, вызвавший ее пользователь этими правами воспользоваться не может.

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

Любые действия ОС по обеспечению безопасности (внутренние действия) не дадут желаемого эффекта, если они на будут поддержаны внешними действиями - системой организационных мероприятий, выполняемых администраторами системы, пользователями и их руководителями. Рассмотрение внешних действий по обеспечению безопасности не входит в наши задачи, упомянем только, что введение в эту область можно найти в [8, 20].

Контрольные вопросы

  1. В чем различие между избирательным и обязательным управлением доступом? Какой из этих подходов более надежен?
  2. В чем преимущества объектно-ориентированных (объектно-базированных) ОС с точки зрения защиты?
  3. Назовите те операции доступа, которые должны быть общими для любых типов объектов.
  4. Назовите специфические операции доступа для объектов типа: файл, папка, программа.
  5. В чем состоят процессы аутентификации и авторизации?
  6. В каком виде может храниться в системе информация о правах доступа?
  7. Что представляет собой "право" Exclude? Как оно применяется?
  8. В чем состоит отличие полномочий от прав?
  9. Опишите типовой сценарий процесса авторизации.
  10. Чем объясняется необходимость введения классов пользователей?

НазадОглавлениеВперед
Индекс