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

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

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

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

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

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

- модификация (modification);

- подделка (fabrication).

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

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

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

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

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

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

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

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

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

- аудит (auditing).

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

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

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

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

Архитектура защиты Globus

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 8 . 1 . Архитектура защиты Globus

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

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

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

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

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

Библиографический список

1. Таненбаум Э., ван Стеен М. Распределенные системы. Принципы и парадигмы. СПб.: Питер, 2003. — 877 с.

Лекция №25-26

Вопросы разработки

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

Фокус управления

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

Рис. 8.2. Три подхода к противодействию угрозам защите. Защита от неверных операций (а). Защита от неавторизованных обращений (б). Защита от неавторизованных пользователей (в)

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

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