8.1. Общие вопросы защиты

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

8.1.1. Угрозы, правила и механизмы

Защита в компьютерных системах жестко связана с понятием надежности (de­pendability). Говоря неформально, надежной компьютерной системой считается система, службам которой мы оправданно доверяем [256]. Как мы говорили в главе 7, надежность подразумевает доступность, безотказность, безопасность и ремонтопригодность. Однако, если мы собираемся доверять компьютерной сис­теме, следует также принимать во внимание конфиденциальность и целостность. Под конфиденциальностью (confidentiality) мы понимаем свойство компьютер­ной системы, благодаря которому доступ к информации в ней ограничен кругом доверенных лиц. Целостность (integrity) — это характеристика, указывающая на то, что изменения могут быть внесены в систему только авторизованными лица­ми или процессами. Другими словами, незаконные изменения в защищенной компьютерной системе должны обнаруживаться и исправляться. Основные час­ти компьютерной системы — это аппаратура, программы и данные.

Другой способ взглянуть на защиту в компьютерных системах — считать, что мы стараемся защитить службы и данные от угроз защиты (security threats). Мы выделяем четыре типа угроз защите [351]:

• перехват (interception);

+ прерывание (interruption);

• модификация (modification); + подделка (fabrication).

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

Примером прерывания может служить повреждение или потеря файла. Обыч­но прерывание связывают с такой ситуацией, когда службы или данные стано­вятся недоступными, уничтожаются, их невозможно использовать и т. п. В этом смысле атаки типа «отказ в обслуживании» (denial of service), при которых кто-то злонамеренно старается сделать определенную службу недоступной для дру­гих, — это угроза защите, классифицируемая как прерывание.

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

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

Отметим, что прерывание, модификация и подделка могут рассматриваться как формы фальсификации данных.

Просто констатировать, что система должна быть в состоянии противостоять всевозможным угрозам защите — это не метод построения защищенных систем. Прежде всего, следует описать требования к защите, то есть правила защиты. Правила защиты (security policy) точно описывают разрешенные и запрещенные действия для системных сущностей. В понятие «системные сущности» входят пользователи, службы, данные, машины и т. п. После составления правил защи­ты можно сосредоточиться на механизмах защиты (security mechanisms), посред­ством которых реализуются эти правила. Наиболее важные из них:

+ шифрование (encryption);

+ аутентификация (authentication);

+ авторизация (authorization);

+ аудит (auditing).

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

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

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

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

Пример — архитектура защиты Globus

Понятие о правилах защиты и роли, которую механизмы защиты играют в со­блюдении этих правил, часто лучше объяснять на конкретном примере. Рассмот­рим правила защиты, определенные в глобальной системе Globus [100]. Globus — это система поддержки распределенных вычислений, в которой для производства вычислений одновременно используется множество хостов, файлов и других ре­сурсов. Такие системы часто называют вычислительными сетями [148]. Ресурсы в таких сетях нередко расположены в различных административных доменах, ко­торые могут находиться в разных частях света.

Поскольку пользователи и ресурсы велики числом и рассеяны по множеству административных доменов, важность защиты резко возрастает. Чтобы разрабо­тать и правильно использовать механизмы защиты, необходимо понять, что на самом деле нужно защищать и какие допущения по этому поводу можно сделать. Опуская некоторые подробности, мы можем сказать, что правила защиты в Glo­bus вытекают из следующих восьми умозаключений [147].

• Среда состоит из множества административных доменов.

• Локальные операции (то есть операции, протекающие в пределах одного домена) обеспечиваются исключительно локальными мерами защиты.

• Глобальные операции (то есть операции, в которые включается несколько доменов) требуют инициатора, известного во всех вовлеченных в опера­цию доменах.

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

+ Глобальная аутентификация стоит выше локальной.

+ Контроль доступа к ресурсам относится к компетенции локальной иденти­фикации.

+ Пользователи могут делегировать свои права процессам.

+ Группа процессов в одном домене может использовать свои идентифика­торы совместно.

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

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

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

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

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

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

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

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

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

Для этой цели вводятся два типа представителей. Заместитель пользователя (user proxy) представляет собой процесс, которому дано право действовать от лица пользователя в течение ограниченного времени. Ресурсы представляются в виде заместителей ресурсов. Заместитель ресурса (resource proxy) — это процесс, ра­ботающий в определенном домене и используемый для трансляции глобальных операций с ресурсами в локальные операции, удовлетворяющие требованиям ло­кальных правил защиты. Так, например, заместитель пользователя обычно при­меняется для связи с заместителем ресурса в процессе доступа к необходимым ресурсам.

Архитектура защиты системы Globus в основном состоит из различных сущ­ностей, таких как пользователи, заместители пользователей, заместители ресур­сов и процессы общего назначения. Эти сущности размещены в доменах и взаи­модействуют друг с другом. В частности, архитектура защиты определяет четыре различных протокола взаимодействия, показанных на рис. 8.1 [148].

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

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

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

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

Конкретные подробности каждого из протоколов описаны в [148]. Самый важный момент во всем этом заключается в том, что архитектура защиты Globus соответствует описанным ранее правилам защиты. Механизмы реализации этой архитектуры, в частности рассмотренные здесь протоколы, едины для многих распределенных систем и будут обсуждаться далее в этой главе. Трудность раз­работки защищенных распределенных систем связана не столько с механизмами защиты, сколько с тем, как использовать эти механизмы для обеспечения защи­ты. В следующем подразделе мы обсудим некоторые из вариантов.