8.3. Контроль доступа

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

Формально подтверждение прав доступа называется контролем доступа (ac­cess control), в то время как для выдачи прав доступа применяется термин авто­ризация (authorization). Эти два понятия тесно связаны друг с другом, и нередко одно из них используется вместо другого. Существует множество методов кон­троля доступа. Мы начнем с обсуждения некоторых общих вопросов, а потом займемся различными моделями контроля доступа. Один из особенно значимых методов контроля доступа к ресурсам — это создание брандмауэра, защищающе­го приложение или даже всю сеть целиком. Брандмауэры мы обсудим отдельно. В связи с повышением мобильности кода контроль доступа становится невоз­можно осуществлять только традиционными методами. Для этого были разрабо­таны новые технологии, которые мы также обсудим в этом разделе.

8.3.1. Общие вопросы контроля доступа

Чтобы разобраться в различных аспектах контроля доступа, рассмотрим простую модель, представленную на рис. 8.22. Она состоит из субъектов (subjects), кото­рые посылают запросы на доступ к объекту (object). Этот объект очень похож на те объекты, которые мы уже обсуждали. Мы можем думать об инкапсуляции его внутреннего состояния и реализации операций внутри этого состоянии. Опера­ции объекта, запросы на выполнение которых посылаются субъектами, доступны через интерфейсы. Лучше всего представлять, что субъекты осуществляют по за­данию пользователей процессы, но могут также быть и объектами, которые для выполнения своей работы нуждаются в помощи других объектов.

Управление доступом к объектам — это все то, что защищает объекты от об­ращений субъектов, не имеющих прав на вызов соответствующих методов, а воз­можно, и вовсе не имеющим прав на вызов каких бы то ни было методов. Кроме того, защита может относиться и к некоторым аспектам управления объектами,

таким как создание, переименование или удаление объектов. Защита часто реа­лизуется при помощи программы под названием монитор ссылок (reference mo­nitor). Монитор ссылок записывает, что может делать тот или иной субъект, и ре­шает, допустимо ли для данного субъекта выполнение конкретной операции. Этот монитор вызывается (например, базовой доверенной операционной систе­мой) при любых обращениях к объекту. Таким образом, очень важно, чтобы мо­нитор ссылок сам по себе имел повышенную защиту от атак: злоумышленник должен быть не в состоянии его обмануть.

Матрица контроля доступа

Общепринятый подход к моделированию прав доступа субъекта по отношению к объектам состоит в построении матрицы контроля доступа (access control matrix). Каждый субъект представлен строкой этой матрицы, каждый объект — столбцом. Если ввести для матрицы обозначение М, то элемент M[s,o] точно определяет, выполнения каких операций субъект s может требовать от объекта о. Другими словами, если субъект s пытается обратиться к методу т объекта о, монитор ссы­лок должен проверить, указан ли метод т в M[s,o]. Если т в M[s,o] отсутствует, вызова не произойдет.

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

Один из широко применяемых способов состоит в том, что каждый из объек­тов поддерживает список прав доступа субъектов, которые желают иметь доступ к этому объекту. Это означает, что матрица разбивается на столбцы, которые распределяются по объектам, при этом пустые элементы отбрасываются. Такой способ реализации приводит нас к так называемому списку контроля доступа (Access Control List, ACL). Предполагается, что каждый объект имеет собствен­ный, ассоциированный только с ним список ACL.

Другой подход состоит в том, что матрица разбивается по строкам и каждый субъект получает список мандатов (capabilities) для каждого из объектов. Други­ми словами, мандат соответствует элементу в матрице контроля доступа. Отсут­ствие для конкретного объекта мандата означает, что субъект не имеет прав на доступ к этому объекту.

Мандат можно сравнить с талоном — тот, кто им владеет, имеет определен­ные права, записанные в этом талоне. Понятно также, что талон должен быть за­щищен от попыток владельца модифицировать его. Один из способов, подходя­щий для распределенных систем и активно используемый в системе Amoeba, со­стоит в защите мандатов (списка мандатов) с помощью подписи [449]. Мы вер­немся к этому и другим вопросам позже при рассмотрении вопросов управления защитой.

Разницу между использованием для защиты объектов списков контроля дос­тупа и списков мандатов иллюстрирует рис. 8.23. В случае списков контроля доступа клиент посылает запрос на сервер, монитор ссылок выясняет, что ему известно про этого клиента, и если клиенту разрешается выполнять запрошен­ную операцию, она будет выполнена, что и показано на рис. 8.23, а.

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

Защищенный домен

Списки ACL и мандаты помогают успешно реализовать матрицу контроля досту­па с исключенными пустыми элементами. Тем не менее если не принимать ника­ких дополнительных мер, и списки контроля доступа, и списки мандатов в конце концов могут стать слишком большими.

Один из основных способов уменьшить размер списка ACL — использование защищенных доменов. Защищенный домен (protection domain) — это набор пар (объект, права доступа). Каждая пара идентифицирует операции, которые для данного объекта разрешается выполнять [391]. Запросы на выполнение опера­ции всегда разрешаются внутри домена. Таким образом, когда субъект запраши­вает у объекта выполнение операции, монитор ссылок сначала находит защи­щенный домен, связанный с этим запросом. Затем, выбрав домен, он проверяет, может ли быть выполнен указанный запрос. Существуют различные методы ис­пользования защищенных доменов.

Один из подходов состоит в построении групп (groups) пользователей. Рас­смотрим, например, web-страницу внутренней сети компании. К этой странице должны иметь доступ все сотрудники компании, и никто кроме них. Вместо того чтобы добавлять в ACL по элементу на каждого сотрудника, можно создать от­дельную группу, содержащую список всех текущих сотрудников. Каждый раз при попытке обращения пользователя к web-странице монитор ссылок должен будет только проверить, является ли пользователь сотрудником. Пользователи, включенные в группу сотрудников, должны быть перечислены в отдельном спи­ске (разумеется, защищенном от неавторизованного доступа).

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

Доступ к web-странице внутренней сети компании может быть разрешен всем ее работникам. Однако изменять, например, web-страницы, относящиеся к ам­стердамскому филиалу, может быть позволено только подмножеству сотрудников из Амстердама. Если пользователь Дик из Амстердама захочет почитать web-страницу внутренней сети, монитор ссылок должен будет сначала найти подгруп­пы Сотрудники_Лмстердам_} Сотрудники _Нъю-Йорк и Сотрудники_Сап-Фран~ циско, которые вместе образуют группу Сотрудники. После этого надо будет проверить, входит ли Дик в одну из этих подгрупп. Преимущество иерархи­ческой организации групп состоит в том, что управлять членством в группе стано­вится значительно легче. Кроме того, появляется возможность эффективного построения очень больших групп. Основной минус такой структуры в том, что по­иск элемента группы изрядно затрудняется, особенно если база данных о член­стве в группах является распределенной.

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

Кроме использования групп, защищенные домены можно также реализовать в виде ролей (roles). В случае контроля доступа на основе ролей пользователь всегда входит в систему под определенной ролью, которая обычно связана с его полномочиями в организации [396]. Пользователь может иметь несколько ро­лей. Так, например, Дик может одновременно быть начальником отдела, менед­жером проекта и членом группы по поиску сотрудников. В зависимости от роли, выбранной им при подключении, он может получить определенные права. Дру­гими словами, его роль определяет защищенный домен (то есть группу), в кото­ром он будет состоять.

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

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

Также допускается и комбинирование защищенных доменов и групп объек­тов. В [170] описано, как, используя оба этих приема вместе со специальными структурами данных и защищенными операциями объектов, реализовать списки ACL в очень больших наборах объектов цифровых библиотек.