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

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

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

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

рые данные X, S добавляет X в журнал, пометив X своей подписью

sig(Sy

X),

и вычисляет контрольную сумму:

Kowner(Coidy

sig(S,

Z), 5).

Здесь

Cold —

предыдущая контрольная сумма.

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

рить,

не фальсифицирован ли журнал. Владелец начинает считывать журнал с

конца, последовательно вычисляя значения

K~owner{C)

для контрольной суммы С.

Каждая итерация возвращает контрольную сумму

Cnext

для следующей итерации,

а также

sig{S,

X) для каждого сервера S. Владелец в состоянии проверить, дейст-

вительно ли очередной элемент журнала соответствует

sig{Sy

X). Если это так,

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

итерации. Итерации заканчиваются по достижении исходной контрольной сум-

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

был фальсифицирован.

И, наконец, Ajanta поддерживает выборочный показ {selective revealing) со-

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

ответствует определенному серверу. Каждый элемент для сохранения конфиден-

циальности зашифрован открытым ключом соответствующего сервера. Массив

подписан владельцем агента для сохранения целостности всего массива. Иными

словами, если какой-либо элемент модифицируется хостом-злоумышленником,

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

Кроме защиты агента от хостов-злоумышленников Ajanta предоставляет раз-

нообразные механизмы защиты хостов от агентов-злоумышленников. Как мы в

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

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

системе Ajanta можно найти в

[464].

Защита получателя

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

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

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

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

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

го агента. Что касается агента, попавшего в вашу систему, нередко все, что вы мо-

жете,

—

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

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

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

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

может быть невозможна, но всегда можно хотя бы дать возможность владель-

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

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

плохого. Однако при работе с приходящими вредоносными агентами частенько

то,

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

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

слишком поздно. В этом случае важно защитить все ресурсы от неавторизовано-

го доступа со стороны полученного по сети кода.

Один из способов защиты

—

создать сито. Сито {sandbox) — это механизм,

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

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

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

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

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

прещены хостом.

Реализовать сито не так-то просто. Один из методов предполагает проверку

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

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

[480].

К счастью,

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

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

[456].

Каждая программа на язы-

ке

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

нии программы. Глобальных переменных или функций не существует, все они

объявляются частями классов. Выполнение программы начинается с метода

main. Программа на языке Java компилируется в набор инструкций, интерпрети-

руемый так называемой виртуальной Java-машиной (Java

Virtual

Machine у

JVM),

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

на языке

Java,

должен запустить JVM как клиентский процесс. После этого JVM

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

каждой ее инструкции, начиная с инструкций, содержащихся в методе main.

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

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

Java производится посредством набора

загрузчиков классов (class

loaders).

Загруз-

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

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

объект этого класса. Загрузчик классов

—

это просто еще один класс Java, поэто-

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

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

—

это первое,

что обеспечивает сито. В частности, Java-программам не разрешается создавать

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

док загрузки классов.

Второй компонент Java-сита

—

это

верификатор байтов кода

(byte

code

verifier).

Верификатор проверяет, соблюдает ли загруженный класс правила защиты, пред-

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

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

все классы, как показано на рис. 8.26 , а только те, которые загружаются на кли-

ента с внешних серверов. Классы, находящиеся на машине клиента, обычно яв-

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

Наконец, после того как класс правильно загружен и проверен, JVM может

создавать объекты этого класса и вызывать методы этих объектов. Чтобы пре-

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

8.3.

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

503

зуется менеджер защиты {security manager), который производит различные

проверки во время исполнения программы. Попытка загрузки Java-программ

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

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

ректность и не будут произведены, если менеджер защиты скажет «нет». Таким

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

ли ранее.

Загруженный

объект

класса

Программа на Java

Запрошенный

класс

Загрузчик

локальных

классов

Верификатор

классов

КтН Интерпретатор JavahjH

Загрузчик

удаленных

классов

Выбрать соответствующий загрузчик

Удаленный сайт Локальный сайт

Рис. 8.26. Организация Java-сита

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

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

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

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

JVM также за-

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

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

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

ты,

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

на программа. Во многих случаях базовая

модель

Java-сита чересчур ограничена.

Требуется большая гибкость. Ниже мы рассмотрим другой распространенный

в настоящее время подход.

Механизм

полигона {playground)

похож на механизм сита, но более гибок

[457].

Полигон

—

это отдельная машина, специально предназначенная для выполнения

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

или сетевые соединения с внешними серверами, доступные для программ, вы-

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

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

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

полигону стандартными способами, например при помощи вызовов RPC. Одна-

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

но.

Эту разницу между ситом и полигоном иллюстрирует рис. 8.27.

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

Доверенный код Неизвестный код Только доверенный код

Неизвестный код

Локальная сеть

Сито

„ / Локальная сеть

Полигон

Рис. 8.27. Сито (а). Полигон (б)

Следующий шаг по пути ослабления ограничений

—

аутентификация каждой

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

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

чтобы программы аутентифицировали себя, относительно просто: мобильный

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

подписа-

ния кода (code-signing) часто используется как альтернатива ситу. Допускается

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

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

В [484] для Java-программ предложено три механизма. Первый из них состоит в ис-

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

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

осуществляющий при его загрузке файловые операции. Если ссылка не получена,

способа получить доступ к файлам нет. Этот принцип иллюстрирует рис. 8.28.

Доступ

локальным

ресурсам через объекты

ооооо

Ссылки "

обрабатываются

во время

загрузки

Загруженная программа

Защищенная область

"А'

Незащищенная область

Рис. 8.28. Использование в качестве мандатов ссылок на Java-объекты

Все интерфейсы объектов, реализующих файловую систему, изначально скры-

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

фейсы. Строгий контроль типов в Java гарантирует невозможность построения

ссылок на один из интерфейсов во время исполнения. Кроме того, мы можем ис-

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

В частности, программе можно запретить создавать свои собственные объекты

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

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

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

сов-наследников).

Второй механизм соблюдения правил защиты

—

это

расширенный самоанализ

стека

{extended stack

introspection).

По существу, это означает, что любой вызов

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

enable_privilege, которая проверяет, имеет ли вызывающий код право на вызов

этого метода данного ресурса. Если обращение авторизовано, вызвавший код на

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

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

ная процедура clisable_privilege, которая отбирает эти права.

Чтобы иметь возможность вызова процедур enable_privilege и clisable_privilege,

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

соответствующие места программы. Однако будет лучше, если интерпретатор

Java станет осуществлять эти вызовы автоматически. Это стандартный подход

для работы с Java-апплетами, принятый, например, в web-браузерах. Очень хо-

рошо выглядит следующее решение: когда происходит обращение к локальным

ресурсам, интерпретатор Java автоматически вызывает процедуру enable_privi-

lege,

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

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

привилегии будут сняты. Подобный способ предотвращает обход правил про-

граммистами с дурными намерениями.

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

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

ма обращается к локальному объекту 01, который, в свою очередь, обращается к

объекту 02, При этом даже если 01 имеет разрешение на обращение к

02у

некото-

рая процедура 01 может не иметь такого разрешения на обращение к некоторому

методу объекта 02

—

тогда эта цепочка вызовов будет запрещена. Самоанализ

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

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

веряя, имеет элемент соответствующую привилегию (тогда вызов разрешен) или

нет (тогда вызов немедленно прерывается). Этот подход иллюстрирует рис. 8.29.

Ячейка стека 02

disable_privilege

Ячейка стека 01

dlsable_privilege

Вызов enable_privilege

Ячейка стека

Первый вызов метода

disable_privilege

Проверка прав доступа

Рис. 8.29. Принцип самоанализа стека

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

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

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

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

щищенные домены на основе классов. Детально это рассматривается в

[173].

Третий метод соблюдения правил защиты

—

управлепие

пространством имен

(пате space management). Идея следующая. Чтобы программа получила доступ

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

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

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

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

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

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

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

должны быть специально адаптированы. Детали можно найти в

[484].

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

была загружена программа. Возможность поддерживать соблюдение правил за-

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

Java. Понятно, что архитектура защиты в значительной степени зависит от ис-

пользуемого языка и для других языков должна разрабатываться «с нуля». Не

зависящие от языка решения, описанные, например, в

[211],

требуют более обоб-

щенных методов защиты и реализовать их значительно труднее. В этих подходах

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

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

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

8.4. Управление защитой

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

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

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

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

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

важную роль играют сертификаты.

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

ров,

сосредоточившись при этом на проблеме добавления в группу нового члена,

за которого ручаются присутствующие в группе серверы.

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

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

авторизации в распределенных системах важную роль играет возможность деле-

гирования одним процессом другому части или всех своих права доступа. Безо-

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

мы обсудим в этом разделе.

8.4. Управление защитой 507

8.4.1.

Управление ключами

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

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

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

нии открытый ключ получателя и для поддержания конфиденциальности может

зашифровать им свое сообщение. Точно так же, рассматривая аутентификацию с

использованием центра распространения ключей (KDC), мы полагали, что каж-

дая из сторон уже предоставила свой секретный ключ в распоряжение KDC.

Однако создание и распространение ключей

—

это не такая простая задача.

Например, нам, вне всякого сомнения, придется найти нестандартные решения

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

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

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

испорчен. Так, например, если ключ попадет в чужие руки, его нужно будет объ-

явить недействительным.

Создание ключей

Начнем с вопросов создания сеансовых ключей. Когда Алиса хочет организовать

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

связи открытый ключ Боба, как это показано на рис. 8.18. Если Боб согласится

начать взаимодействие, он должен создать сеансовый ключ и вернуть его Алисе,

зашифровав открытым ключом Алисы. После шифрования общего сеансового

ключа его можно смело передавать по сети.

Подобная схема может использоваться для генерации и распространения се-

ансового ключа в том случае, если Алиса и Боб уже обладают общим секретным

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

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

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

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

ной, например KDC.

Красивый и широко используемый способ создания общего ключа и передачи

его по небезопасным каналам [126]

—

это обмен ключами по Диффи—Хеллману

(Diffie—Hellman key exchange). Этот протокол работает следующим образом.

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

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

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

ничениям (о них мы поговорим позже). Оба этих числа нет необходимости

скрывать от посторонних. Далее Алиса выбирает большое случайное число, ска-

жем,

которое она держит в секрете. Боб также выбирает свое секретное число,

назовем его у. В этот момент, как мы видим из рис. 8.30, у нас имеется вся ин-

формация, необходимая для создания секретного ключа.

Алиса начинает с того, что посылает Бобу число g^

mod

гг,

вместе cnug. Важ-

но отметить, что эту информацию можно послать открытым текстом, так как,

имея значение g^ mod

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

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

ние,

Боб вычисляет (g^ mod пУ, что равно g^ mod п. Кроме того, он посылает

Алисе число g^ mod п, а она, в свою очередь, вычисляет (g^ mod nf =g^^ mod п.

Соответственно, Алиса и Боб, и только они двое, имеют теперь общий секретный

ключ g^ mod

п.

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

свое секретное число (соответственно, х или у).

выС

Компьютер Алисы

(дУ mod

п)^

д^У

mod

)ира

го

етх

п,

д,

g'^mod

^ ^

g^mod

выб

Боб

ира

ету

Компьютер Боба

(g'^mod п)дУ

д^У

mod

Рис. 8.30. Обмен ключами по Диффи—Хеллману

Протокол Диффи—Хеллмана можно рассматривать как криптосистему с от-

крытым ключом. В случае Алисы х

—

это ее закрытый ключ,

mod п —

откры-

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

ключей очень напоминает протокол Диффи—Хеллмана.

Распространение ключей

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

—

это распространение

исходных ключей. В симметричных криптосистемах исходный общий секретный

ключ должен распространяться по безопасным каналам с аутентификацией и

конфиденциально, как показано на рис. 8.31, а

[290].

Если у Алисы и Боба нет

ключа для организации защищенного канала, необходимо обменяться ключами

другим способом. Иными словами, Алиса и Боб должны войти в контакт при по-

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

по телефону или послать ключ на дискете обычной бандеролью.

В случае криптосистемы с открытым ключом нам необходимо распростра-

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

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

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

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

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

только по безопасному каналу, с идентификацией и конфиденциально.

Аутентифицированное распространение открытого ключа выглядит более лю-

бопытно. На практике распространение открытых ключей осуществляется при

помощи

сертификатов открытого

ключа

{public

key

certificates).

Эти сертифика-

ты состоят из открытого ключа и строки, определяющей сущность, с которой ас-

соци/фован этот ключ. Сущностью может быть пользователь, хост или некое

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

ются

сертифицирующей организацией {certification

authority), и эта подпись так-

же добавляется к сертификату (наименование сертифицирующей организации

8.4. Управление защитой 509

является естественной частью сертификата). Подпись производится закрытым

ключом

К~сА,

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

вующий открытый ключ

К^сл

не считается секретным. Так, открытые ключи раз-

личных сертифицирующих организаций встроены в большинство web-браузеров

и распространяются вместе с файлами программ.

Простой

текст, Р

Метод

шифрования

Ключ

шифрования, К

Метод

расшифровки

Шифрованный текст

Генератор

симметричных

ключей

Простой

текст

Ключ

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

^Конфиденциальный"

безопасный канал с идентификацией

Простой

текст, Р

Метод

шифрования

Открытый

ключ,

К"^

Метод

расшифровки

Шифрованный текст

Генератор

асимметричных]

ключей

Простой

текст

Закрытый

ключ.

К"

Безопасный канал

с идентификацией

Конфиденциальный

безопасный канал с идентификацией

Рис. 8.31. Распространение секретного ключа (а). Распространение открытого ключа (б)

Сертификаты открытого ключа используются следующим образом. Предпо-

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

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

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

пись сертификата. Если подпись сертификата соответствует паре (открытый

ключ,

идентификатор), то клиент считает, что открытый ключ действительно

принадлежит указанной сущности.

Важно отметить, что, считая сертификат годным, клиент на самом деле верит,

что сертификат не подделан. В частности, клиент должен предполагать, что от-

крытый ключ /Сел действительно принадлежит соответствующей сертифици-

рующей организации. Если на этот счет имеются сомнения, можно проверить

правильность

7<Ссл

через другой сертификат, полученный от другой сертифици-

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

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

Такие иерархические

модели доверия

(trust

models)^

в которых сертифицирую-

щей организации самого верхнего уровня доверяют все

—

не редкость. Так, на-

пример,

конфиденциальная почта (Privacy Enhanced

Mail РЕМ) использует трех-

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

уровня идентифицируются организациями сертификации правил (Policy Certi-

fication

Authorities,

РСА)у

которые, в свою очередь, идентифицируются

организа-

цией регистрации

правил в

Интернете (Internet Policy Registration

Authority,

IPRA).

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

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

почтой РЕМ. Дополнительную информацию по этой модели можно почерпнуть

из

[232].

Другие модели доверия обсуждаются в

[290].

Срок жизни сертификатов

Важный вопрос, связанный с сертификатами,

—

это их

срок жизни

(lifetime). Рас-

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

янные сертификаты. По существу, такой сертификат означает, что открытый

ключ для сущности, им идентифицируемой, всегда является истинным. Ясно, что

это нереально. Если закрытый ключ идентифицируемой сущности однажды бу-

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

вать открытые ключи (в отличие от клиентов с дурными намерениями). Для по-

добных случаев нужен механизм

отзыва (revoke)

сертификата, который позволил

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

Существует несколько способов отзыва сертификата. Один из традиционных

методов

—

воспользоваться

списком отозванных сертификатов

(Certificate Revo-

cation List, CRL), который регулярно публикуется сертифицирующей организа-

цией. Когда клиент проверяет сертификат, он просматривает CRL, чтобы опре-

делить, не был ли данный сертификат отозван. Это означает, что клиент должен

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

ходе нового списка CRL. Отметим, что если CRL публикуется ежедневно, то на

отзыв сертификатов также дается всего один день. Таким образом, скомпромети-

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

он не будет включен в очередной список CRL. Соответственно, время между

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

CRL вызывает дополнительные затраты.

Альтернативный подход предполагает ограничение срока жизни сертификата.

В сущности, этот подход напоминает аренду, о которой мы говорили в главе 6.

Действие сертификатов по истечении определенного времени автоматически пре-

кращается. Если по каким-то причинам сертификат был отозван до прекраще-

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

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

ривать последний список CRL вне зависимости от времени получения сертифи-

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

низацией или доверенной базой данных, содержащей последний список CRL.

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

—

сократить срок жизни сертификатов почти до

нуля. В действительности это означает полный отказ от использования сертифи-