Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

8.2. Защищенные каналы 491

ему результата ничто не будет угрожать. Подобные атаки могут произойти в слу-

чае успешного взлома злоумышленником одного или нескольких серверов.

Способом защиты клиента от подобных атак является сбор ответов всех сер-

веров с идентификацией каждого из них. Если ответы невзломанных (то есть аутен-

тифицированных) серверов составляют большинство, клиент может считать, что

ответ корректен. К сожалению, подобный подход нарушает прозрачность репли-

кации серверов.

В [376] было предложено решение для защищенного реплицируемого серве-

ра, позволяющее сохранить прозрачность репликации. Достоинство такого под-

хода состоит в том, что клиенты остаются в неведении о реальных репликах и

поэтому значительно проще скрытно добавлять и удалять реплики. Мы вернем-

ся к вопросу управления защищенными группами ниже, при обсуждении вопро-

сов управления ключами.

Смысл защищенных и прозрачно реплицируемых серверов кроется в том, что

пдзыъдс^тся разделением секрета {secret

sharing).

При разделении секрета ни один

из нескольких пользователей (или процессов) не знает секрета целиком, секрет

может быть открыт только в случае их совместной работы. Такие схемы могут

быть очень удобными. Рассмотрим, например, запуск ракеты с ядерной боего-

ловкой. Это действие требует подтверждения как минимум двумя людьми. Каж-

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

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

ни к чему не приведет.

В случае защищенных реплицируемых серверов при поиске ответа максимум

k из N серверов могут дать неверный ответ, а из этих k максимум c<k серверов

могут быть действительно взломаны злоумышленником. Отметим, что это тре-

бование предполагает, что служба устойчива к k ошибкам. Этот вопрос мы обсу-

ждали в предыдущей главе. Разница состоит в том, что сейчас серверы, которые

работают ошибочно, взломаны намеренно.

Теперь рассмотрим ситуацию, когда серверы активно реплицируются. Други-

ми словами, запрос рассылается всем серверам одновременно, после чего обраба-

тывается каждым из них. Каждый сервер генерирует ответ, который возвращает-

ся клиенту. В случае защищенной реплицируемой группы серверов предполага-

ется, что каждый сервер сопровождает свой ответ цифровой подписью. Если г,

—

ответ сервера 5,, то пусть

тс1(Г{)

обозначает дайджест сообщения, вычисленный

сервером 5/. Этот дайджест подписан закрытым ключом

iC^

сервера 5,.

Представим себе, что мы хотим защитить клиента от максимум с взломанных

серверов. Другими словами, группа серверов должна быть в состоянии скрыть

последствия взлома максимум с серверов, оставаясь при этом в состоянии сгене-

рировать ответ, которому клиент сможет доверять. Если подписи отдельных сер-

веров можно скомбинировать таким образом, чтобы построение правильной под-

писи для результата требовало минимум с +

подписей, это решает проблему.

Другими словами, мы хотим, чтобы реплицируемые серверы создавали секрет-

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

нии собрать эту подпись без помощи минимум одного «честного» сервера.

В качестве примера рассмотрим группу из пяти реплицируемых серверов, ко-

торые должны быть в состоянии выдержать взлом двух из них и давать при этом

492 Глава 8. Защита

результат, которому сможет доверять клиент. Каждый сервер

посылает ответ

Гг

вместе со своей подписью

sig(Si,

г,) = Kj(md(ri)) клиенту. Соответственно, клиент

последовательно получает пять триплетов <г/, md(ri), sig(Si, r,)>, из которых он

должен выделить правильные. Эту ситуацию иллюстрирует рис. 8.21.

Группа серверов

Компьютер клиента

г1

г2

гЗ>

г4

г5

sig(S1.r1)

sig(S2.r2)

sig(S3,r3)

sig(S4,r4)

sig(S5,r

r w

Хэш-функция,

функция

расшифровки,

D(V)

md(r) = H(r)

> r

d = md(r)?

Нет

Да

^ в порядке

Набор из трех подписей Выбрать другую комбинацию (г, V)

Рис. 8.21. Разделяемая секретная подпись группы реплицируемых серверов

Каждый дайджест md(ri) вычисляется также и на клиенте. Если ответ г, неве-

рен, это обычно можно определить, вычислив

KXK~i{md{ri))),

однако, поскольку

мы не можем доверять ни одному серверу в отдельности, этот метод применять

нельзя. Вместо него клиент использует специальную открытую функцию рас-

шифровки

Z),

которая в качестве исходных данных получает набор из трех сигна-

тур У=

{

sig(S, г), sig(S\ г'), sig(S'\

г")},

а в качестве результата генерирует един-

ственный дайджест:

dout = D(V) = D(sig(S, г), sig(S\ г'), sig(S'\ г")).

Детали о функции расшифровки D можно найти в

[376].

Существует

5!/(3!2!) = 10 комбинаций трех подписей, которые клиент может получить в ка-

честве результата D. Если одна из этих комбинаций даст правильный дайджест

md(ri) для некоторого результата г/, клиент может считать ответ г, правильным.

В частности, он может считать, что этот результат дан как минимум тремя пра-

вильно работаюш;ими серверами.

Для повышения прозрачности репликации в [376] предлагается, чтобы каж-

дый сервер

рассылал свой результат

г^

остальным серверам вместе с соответст-

вующей подписью sig(Si,

Vi).

Когда сервер получит как минимум с +

подобных

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

для одного из ответов. Если, например, это вычисление для ответа г и набора V

из с +

подписей будет успешным, он пересылает г и F клиенту одним сообще-

нием. Клиент после этого проверяет корректность г путем проверки подписи, то

есть того, что md(r) = D(V).

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

Описанный нами алгоритм известен как

т^п-пороговая

схема (m.n-threshold

sche-

me),

где, в случае нашего примера, m==c + l,a«=iV (число серверов). В т,п-порого-

вой схеме сообщение делится на п частей, известных под названием теней

{shadows).

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

теней, но любых т~

теней для этого будет недостаточно. Существует несколь-

ко способов построения г?г,гг-пороговых схем. Подробности можно найти в

[404].

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

в модели клиент-сервер, которую мы рассматривали все это время, после созда-

ния между клиентом и сервером защищенного канала клиент создавал запросы,

которые передавались серверу. Запросы включали операции над ресурсами, кон-

тролируемые сервером. Стандартная ситуация предполагала, что сервер объектов

управляет несколькими объектами. Запрос клиента обычно содержал обращение

к методу конкретного объекта. Такой запрос мог быть выполнен только в том

случае, если клиент обладал достаточными для такого обращения правами дос-

тупа

{access

rights).

Формально подтверждение прав доступа называется

контролем доступа

{ac-

cess

control),

в то время как для выдачи прав доступа применяется термин авто-

ризация

{authorization).

Эти два понятия тесно связаны друг с другом, и нередко

одно из них используется вместо другого. Существует множество методов кон-

троля доступа. Мы начнем с обсуждения некоторых общих вопросов, а потом

займемся различными моделями контроля доступа. Один из особенно значимых

методов контроля доступа к ресурсам

—

это создание брандмауэра, защищающе-

го приложение или даже всю сеть целиком. Брандмауэры мы обсудим отдельно.

В связи с повышением мобильности кода контроль доступа становится невоз-

можно осуществлять только традиционными методами. Для этого были разрабо-

таны новые технологии, которые мы также обсудим в этом разделе.

8.3.1.

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

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

модель, представленную на рис. 8.22. Она состоит из

субъектов

{subjects),

кото-

рые посылают запросы на доступ к

объекту

{object).

Этот объект очень похож на

те объекты, которые мы уже обсуждали. Мы можем думать об инкапсуляции его

внутреннего состояния и реализации операций внутри этого состоянии. Опера-

ции объекта, запросы на выполнение которых посылаются субъектами, доступны

через интерфейсы. Лучше всего представлять, что субъекты осуществляют по за-

данию пользователей процессы, но могут также быть и объектами, которые для

выполнения своей работы нуждаются в помощи других объектов.

Управление доступом к объектам

—

это все то, что защищает объекты от об-

ращений субъектов, не имеющих прав на вызов соответствующих методов, а воз-

можно, и вовсе не имеющим прав на вызов каких бы то ни было методов. Кроме

того,

защита может относиться и к некоторым аспектам управления объектами.

494 Глава 8. Защита

таким как создание, переименование или удаление объектов. Защита часто реа-

лизуется при помощи программы под названием

монитор ссылок {reference

mo-

nitor).

Монитор ссылок записывает, что может делать тот или иной субъект, и ре-

шает, допустимо ли для данного субъекта выполнение конкретной операции.

Этот монитор вызывается (например, базовой доверенной операционной систе-

мой) при любых обращениях к объекту. Таким образом, очень важно, чтобы мо-

нитор ссылок сам по себе имел повышенную защиту от атак: злоумышленник

должен быть не в состоянии его обмануть.

Субъект

Монитор

ссылок

Объект

Запрос Авторизованный

на операцию запрос

Рис. 8.22. Обобщенная модель контроля доступа к объектам

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

Общепринятый подход к моделированию прав доступа субъекта по отношению к

объектам состоит в построении

матрицы контроля доступа {access control

matrix).

Каждый субъект представлен строкой этой матрицы, каждый объект -• столбцом.

Если ввести для матрицы обозначение М, то элемент М[5,о] точно определяет,

выполнения каких операций субъект 5 может требовать от объекта о. Другими

словами, если субъект

пытается обратиться к методу т объекта о, монитор ссы-

лок должен проверить, указан ли метод т в

M[SyO].

Если т в М[5,о] отсутствует,

вызова не произойдет.

Учитывая, что системе может потребоваться поддерживать тысячи пользова-

телей и миллионы требующих защиты объектов, реализация матрицы контроля

доступа в виде реальной матрицы представляется не лучшей из идей. Большин-

ство элементов матрицы будут пустыми, поскольку один субъект обычно имеет

доступ к относительно небольшому числу объектов. Поэтому для реализации

матрицы контроля доступа используются более эффективные способы.

Один из широко применяемых способов состоит в том, что каждый из объек-

тов поддерживает список прав доступа субъектов, которые желают иметь доступ

к этому объекту. Это означает, что матрица разбивается на столбцы, которые

распределяются по объектам, при этом пустые элементы отбрасываются. Такой

способ реализации приводит нас к так называемому списку контроля

доступа

{Access

Control

List, ACL). Предполагается, что каждый объект имеет собствен-

ный, ассоциированный только с ним список ACL.

Другой подход состоит в том, что матрица разбивается по строкам и каждый

субъект получает список

мандатов {capabilities)

для каждого из объектов. Други-

ми словами, мандат соответствует элементу в матрице контроля доступа. Отсут-

ствие для конкретного объекта мандата означает, что субъект не имеет прав на

доступ к этому объекту.

Мандат можно сравнить с талоном

—

тот, кто им владеет, имеет определен-

ные права, записанные в этом талоне. Понятно также, что талон должен быть за-

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

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

щий для распределенных систем и активно используемый в системе Amoeba, со-

стоит в защите мандатов (списка мандатов) с помощью подписи

[449].

Мы вер-

немся к этому и другим вопросам позже при рассмотрении вопросов управления

защитой.

Разницу между использованием для защиты объектов списков контроля дос-

тупа и списков мандатов иллюстрирует рис. 8.23. В случае списков контроля

доступа клиент посылает запрос на сервер, монитор ссылок выясняет, что ему

известно про этого клиента, и если клиенту разрешается выполнять запрошен-

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

Клиент

Создать запрос

на доступ г

от имени субъекта s

(s.r)

ACL

Сервер

Объект

если (s содержится

если (г содержится

в /^

разрешить доступ

\CL)

;CL)

Клиент

Создать запрос

на доступ г

к объекту 0.

Передать мандат С

(0.

г. С)

если (г

разреш

Сервер

Объект

содержи!

ить дост^

гея

С)

Рис. 8.23. Сравнение вариантов защиты объектов с помощью ACL

мандатов.

Использование ACL (а). Использование мандатов (б)

При использовании списка мандатов клиент просто передает свой запрос

вместе со списком мандатов на сервер. Сервер не хранит сведений о клиенте,

список мандатов и так скажет ему все необходимое. Таким образом, сервер дол-

жен просто проверить, имеется ли в запросе корректный список мандатов и ука-

зана ли запрашиваемая операция в этом списке. Такой способ защиты объек-

тов

—

на основании мандатов

—

иллюстрирует рис. 8.23, б.

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

Списки ACL и мандаты помогают успешно реализовать матрицу контроля досту-

па с исключенными пустыми элементами. Тем не менее если не принимать ника-

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

концов могут стать слишком большими.

Один из основных способов уменьшить размер списка ACL

—

использование

защищенных доменов. Защищенный домен {protection domain) — это набор пар

(объект, права доступа). Каждая пара идентифицирует операции, которые для

496 Глава 8. Защита

данного объекта разрешается выполнять

[391].

Запросы на выполнение опера-

ции всегда разрешаются внутри домена. Таким образом, когда субъект запраши-

вает у объекта выполнение операции, монитор ссылок сначала находит защи-

щенный домен, связанный с этим запросом. Затем, выбрав домен, он проверяет,

может ли быть выполнен указанный запрос. Существуют различные методы ис-

пользования защищенных доменов.

Один из подходов состоит в построении групп {groups) пользователей. Рас-

смотрим, например, web-страницу внутренней сети компании. К этой странице

должны иметь доступ все сотрудники компании, и никто кроме них. Вместо того

чтобы добавлять в ACL по элементу на каждого сотрудника, можно создать от-

дельную группу, содержащую список всех текущих сотрудников. Каждый раз

при попытке обращения пользователя к web-странице монитор ссылок должен

будет только проверить, является ли пользователь сотрудником. Пользователи,

включенные в группу сотрудников, должны быть перечислены в отдельном спи-

ске (разумеется, защищенном от неавторизованного доступа).

Схема станет более гибкой, если сделать структуру групп иерархической. Так,

например, если организация имеет три различных филиала, скажем, в Амстердаме,

Нью-Йорке и Сан-Франциско, она может пожелать разбить группу сотрудников

на три подгруппы, по одной для каждого города, что приведет нас к структуре,

представленной на рис. 8.24.

Весь мир

Сотрудники Прочие

Сотрудники_Амстердам Сотрудники_Нью-Иорк Сотрудники_Сан-Франциско

/1.\

/ 'А / ' \

Дик Билл

Рис. 8.24. Иерархическая организация защищенных доменов в виде групп пользователей

Доступ к web-странице внутренней сети компании может быть разрешен всем

ее работникам. Однако изменять, например, web-страницы, относящиеся к ам-

стердамскому филиалу, может быть позволено только подмножеству сотрудников

из Амстердама. Если пользователь Дик из Амстердама захочет почитать web-

страницу внутренней сети, монитор ссылок должен будет сначала найти подгруп-

пы

Сотрудники_Лмстердам,

Сотрудники_НьЮ'Йорк

и Сотрудпики_СаП'Фрап-

циско,

которые вместе образуют группу Сотрудники. После этого надо будет

проверить, входит ли Дик в одну из этих подгрупп. Преимущество иерархи-

ческой организации групп состоит в том, что управлять членством в группе стано-

вится значительно легче. Кроме того, появляется возможность эффективного

построения очень больших групп. Основной минус такой структуры в том, что по-

иск элемента группы изрядно затрудняется, особенно если база данных о член-

стве в группах является распределенной.

8.3.

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

497

Вместо того чтобы заставлять монитор ссылок делать всю работу в одиночку,

мы можем заставить каждого субъекта хранить

сертификат

{certificate) со спи-

ском групп, в которые он входит. Таким образом, когда Дик захочет почитать

web-страницу внутренней сети компании, он предъявит монитору ссылок свой

сертификат, показывающий, что он является членом подгруппы Сотрудники_

Амстердам.

Чтобы гарантировать, что этот сертификат настоящий, не поддель-

ный, его можно защитить, например, цифровой подписью. Сертификаты немно-

го похожи на списки мандатов. Мы вернемся к этой теме позже.

Кроме использования групп, защищенные домены можно также реализовать

в виде ролей {roles). В случае контроля доступа на основе ролей пользователь

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

полномочиями в организации

[396].

Пользователь может иметь несколько ро-

лей. Так, например, Дик может одновременно быть начальником отдела, менед-

жером проекта и членом группы по поиску сотрудников. В зависимости от роли,

выбранной им при подключении, он может получить определенные права. Дру-

гими словами, его роль определяет защищенный домен (то есть группу), в кото-

ром он будет состоять.

Присваивая роли пользователям и требуя, чтобы во время подключения поль-

зователь выступал под одной из них, мы позволяем пользователю при необходи-

мости изменить свою роль. Так, например, можно потребовать, чтобы Дик, войдя

в систему начальником отдела, перешел затем к своей роли менеджера проекта.

Отметим, что эти переходы нелегко осуществить, если защищенные домены реа-

лизованы только в виде групп.

Кроме использования защищенных доменов производительность можно по-

высить путем иерархической или какой-либо другой группировки объектов на

основании операций, которые они осуществляют. Так, например, независимо от

самих объектов, объекты можно группировать по предоставляемым ими интер-

фейсам, возможно, используя подтипы (также называемые унаследованные ин-

терфейсы, [157]) для построения иерархии. В этом случае, если субъект запра-

шивает операцию, которую должен выполнить объект, монитор ссылок ищет,

в каком интерфейсе находится операция над этим объектом. Затем, вместо того

чтобы проверять право субъекта вызывать операции данного объекта, он прове-

ряет, имеет ли субъект право вызывать операции, принадлежащие к данному ин-

терфейсу.

Также допускается и комбинирование защищенных доменов и групп объек-

тов.

В [170] описано, как, используя оба этих приема вместе со специальными

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

ACL в очень больших наборах объектов цифровых библиотек.

8.3.2. Брандмауэры

Ранее мы рассматривали, как организовать защиту при помощи криптографи-

ческих методов в комбинации с реализацией матриц контроля доступа. Эти спо-

собы с успехом работают до тех пор, пока связывающиеся стороны играют по

одним правилам. Однако заставить соблюдать эти правила можно только при

498 Глава 8. Защита

разработке распределенной системы, изолированной от всего остального мира.

Дело значительно усложняется, когда доступ к ресурсам, которыми управляет

распределенная система, открывается сторонним пользователям. Примеры по-

добных случаев включают в себя, например, посылку почты, загрузку файлов или

выгрузку форм.

Чтобы в подобных условиях защитить ресурсы, необходим другой подход. На

практике доступ извне к любой из частей распределенной системы отслежива-

ется монитором ссылок особого типа

([101,

504]), известным под названием

брандмауэра {firewall). Грубо говоря, брандмауэр отсекает часть распределен-

ной системы от окружающего мира, как показано на рис. 8.25. Все выходящие

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

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

дальше не передается. Следует отметить, что сам брандмауэр должен быть на-

дежно защищен от угроз защиты любого рода: он никогда не должен выходить из

строя.

Маршрутизатор Шлюз Маршрутизатор

с фильтрацией прикладного с фильтрацией

пакетов уровня пакетов

Соединения

с внутренними

сетями

Соединения

с внешними

сетями

Брандмауэр

Рис. 8.25. Обобщенная реализация брандмауэра

Различают в основном брандмауэры двух типов, но часто реальные брандмау-

эры представляют собой комбинацию этих типов. Важнейший тип брандмау-

эра

—

это шлюз фильтрации

пакетов

{packet-filtering

gateway).

Брандмауэр тако-

го типа работает как маршрутизатор. Он принимает решение о том, пропускать

или нет сетевой пакет на основании адресов отправителя и получателя в заго-

ловке пакета. Обычно (см. рис. 8.25) шлюз фильтрации пакетов, находящийся

вне локальной сети (LAN), защиш;ает систему от входящих пакетов, а такой же

шлюз, находящийся во внутренней сети, фильтрует исходящие пакеты.

Так, например, для защиты внутреннего web-сервера от запросов хостов, не

входящих во внутреннюю сеть, шлюз фильтрации пакетов должен отбрасывать

все входящие пакеты, адресованные web-серверу.

Более тонкой является ситуация, когда сеть компании состоит из нескольких

локальных сетей, соединенных между собой, например, сетью SDMS. Мы уже

обсуждали такой вариант. Каждая внутренняя сеть может быть защищена шлю-

зом фильтрации пакетов, который сконфигурирован на пропуск входящего тра-

фика только от хостов других внутренних сетей. Таким образом, строятся част-

ные виртуальные сети.

8.3.

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

499

Другой тип брандмауэров

—

шлюз

прикладного

уровня

{application-level

gate-

way).

В противоположность шлюзу фильтрации пакетов, который проверяет толь-

ко заголовки пакетов, этот тип брандмауэра просматривает содержимое входящих

и исходящих сообщений. Типичным примером может быть шлюз почты, кото-

рый отбрасывает входящие или исходящие письма, превышающие установлен-

ный размер. Существуют и более сложные почтовые шлюзы, способные, напри-

мер,

отфильтровывать электронную почту рекламного характера (спам).

Другим примером шлюза прикладного уровня может быть шлюз внешнего

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

рефератами документов. Если внешний пользователь хочет получить что-то еще,

начинает работать протокол электронных платежей. Внутренний пользователь

имеет прямой доступ к библиотечным службам.

Существует особый тип шлюза прикладного уровня, известный под названием

прокси-гилюза

(proxy gateway). Этот тип брандмауэра скрывает работу некото-

рых типов приложений. Он гарантирует прохождение через него только сообще-

ний, удовлетворяющих заданным критериям. Рассмотрим, например, путешест-

вия в Web. Многие web-страницы содержат апплеты или сценарии, которые

должны выполняться браузером пользователя. Чтобы предотвратить попадание

этого кода в локальную сеть, весь web-трафик пропускается через прокси-шлюз.

Этот шлюз получает обычные HTTP-запросы как изнутри, так и снаружи бранд-

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

ный web-сервер, однако он фильтрует весь входящий и исходящий трафик, от-

брасывая определенные запросы и страницы или модифицируя страницы,

содержащие исполняемый код.

8.3.3. Защита мобильного кода

Как мы говорили в главе 3, важной особенностью современных распределенных

систем по сравнению с прежними является возможность переноса с хоста на хост

кода, а не только пассивных данных. Однако мобильный код приводит к появле-

нию серьезных угроз защиты. Так, например, отправляя в путешествие по Интер-

нету агента, владелец захочет защитить его от злоумышленников, желающих по-

хитить или изменить информацию, собранную агентом.

Другой вопрос состоит в том, что и сами хосты должны быть защищены от

агентов-злоумышленников. Большинство пользователей распределенных систем

не являются экспертами в системотехнике и не в состоянии сказать, повреждают

или нет их компьютер программы, пришедшие с других хостов. Во многих слу-

чаях для эксперта может быть затруднительно обнаружить даже сам факт за-

грузки программы.

Если не предпринимать специальных мер по поддержанию защиты, однажды

вредоносная программа может попасть в ваш компьютер и с легкостью поразить

хост. Перед нами стоит проблема контроля доступа: программы не должны

иметь неавторизованного доступа к ресурсам хоста. Как мы увидим, защита хос-

та от загрузки вредоносных программ иногда оказывается непростым делом.

Проблема настолько серьезна, что может заставить нас вообще отказаться от за-

500 Глава 8. Защита

грузки программ. Вместо этого следует рассмотреть возможность использования

мобильного кода, разрешая ему доступ, гибкий к локальным ресурсам при усло-

вии полного контроля за ситуацией с нашей стороны.

Защита агента

Прежде чем мы перейдем к вопросу защиты компьютерных систем от загрузки

вредоносного кода, рассмотрим противоположную ситуацию. Представим себе

мобильного агента, перемещающегося по распределенной системе по заданию

пользователя. Покупая по поручению владельца билет на самолет или резерви-

руя место, агент может использовать электронную кредитную карту.

Ясно,

что в этом случае нам необходима защита. По мере того как агент пере-

мещается с хоста на хост, эти хосты не должны иметь возможности узнать ин-

формацию о кредитной карте агента. Кроме того, агент должен быть защищен от

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

Так, например, хост Самых дешевых

партеров

Чака может заметить, что агент

еще не посетил хост его конкурента, Авиалиний

Алисы,

с более низкими ценами.

Чак может попытаться изменить код агента таким образом, чтобы тот не добрал-

ся до хоста Авиалиний

Алисы,

Другие примеры необходимости защиты агента от

атак враждебных хостов подразумевают злонамеренное разрушение агента или

фальсификацию агента таким образом, чтобы он по возвращении атаковал сво-

его владельца.

К сожалению, полная защита агента от всех типов атак невозможна

[141].

Эта

невозможность вызвана в первую очередь фактом отсутствия четких гарантий

того,

что хост будет работать, как обещано. Поэтому альтернативой является та-

кая организация агентов, чтобы их изменение можно было, по крайней мере, за-

метить. Такой подход используется в системе Ajanta

[225].

Ajanta предоставляет

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

фальсифицирован

—

это состояние только для чтения, журналы только для за-

писи и выборочный показ состояния для заданных серверов.

Состояние

только для чтения

{read-only

state) агента системы Ajanta содер-

жит набор элементов данных, которые подписаны владельцем агента. Подписа-

ние происходит в момент создания и инициализации агента, до того как он будет

отправлен на какой-либо другой хост. Владелец сначала создает дайджест сооб-

щения, а затем шифрует его своим закрытым ключом. Когда агент появляется на

хосте, тот легко может заметить, что состояние «только для чтения» было фаль-

сифицировано, просто проверив это состояние по подписанному дайджесту ис-

ходного состояния.

Чтобы позволить агенту при перемещении от хоста к хосту собирать инфор-

мацию, Ajanta использует защищенные

журналы только

для записи (append-only

logs).

Эти журналы отличаются тем, что данные в них можно только добавлять,

удалить или изменить данные незаметно для владельца агента невозможно.

Журналы только для записи работают следующим образом. Изначально журнал

пуст и содержит только ассоциированную с ним контрольную сумму

С^ш

вычис-

ляемую как

Cinit

Klj(^er(N)y

где К

owner —

открытый ключ владельца агента, а

Л/^

—

секретный одноразовый ключ, известный только владельцу.