Доверие в информационной системе

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

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

Иерархия

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

Userl и User2 располагаются под СА1. Следовательно, если СА1 говорит, что сертификат открытого ключа принадлежит пользователю Userl, пользователь User2 будет верить этому. На практике User2 передает пользователю Userl свой сертификат открытого ключа, подписанный СА1. Пользователь Userl проверяет подпись СА1 с использованием открытого ключа СА1. Так как СА1 находится в иерархии выше, чем Userl, то Userl доверяет СА1 и, следовательно, доверяет сертификату пользователя User2.

Иерархическая модель доверия

Рис. 12.12. Иерархическая модель доверия

Мы рассмотрели довольно простой случай. Если пользователю Userl нужно проверить информацию от пользователя User3, все несколько усложняется. СА1 не знает о пользователе User3, в отличие от СА2. Тем не менее, пользователь Userl не доверяет СА2, так как это бюро сертификатов напрямую не принадлежит цепочке пользователя Userl. Следующий уровень вверх по цепочке - СА4. Пользователь Userl может верифицировать информацию от пользователя User3 посредством проверки с помощью СА4 следующим образом.

  • 1. Пользователь Userl смотрит на сертификат пользователя User3. Он подписан в СА2.
  • 2. Пользователь Userl получает сертификат пользователя СА2. Он подписан в СА4.
  • 3. Так как пользователь Userl доверяет СА4, открытый ключ СА4 может использоваться для верификации сертификата СА2.
  • 4. Как только сертификат СА2 верифицирован, пользователь Userl может верифицировать сертификат пользователя User3.
  • 5. Как только будет верифицирован сертификат пользователя User3, пользователь Userl может использовать открытый ключ пользователя User3 для верификации данных.

Как видите, все довольно быстро усложняется. Представьте себе, какой объем операций по верификации необходимо было бы производить, если бы пользователю Userl нужно было верифицировать данные, поступившие от пользователя User4. Две цепочки не пересекаются вплоть до СА9! Так реализована сертификация в Х.509. Иерархия устанавливается таким образом, чтобы между любыми двумя нижними объектами могла быть создана цепочка сертификатов.

С теоретической точки зрения все выглядит неплохо. Однако на практике все иначе. Одной из причин, по которой данная технология не функционировала, заключается в том, что не существовало реальных СА корневого уровня. СА корневого уровня - это наивысшая точка в иерархии. В одно время было принято считать, что в каждой стране должно быть свое бюро сертификатов корневого уровня. Также предполагалось, что компании, выпускающие кредитные карты, должны стать корневыми СА, или что каждая организация должна иметь свое собственное СА. На практике почти ничего не было реализовано. Возникал еще один вопрос, который представлял собой потенциальную проблему: сколько СА должны сертифицировать каждого конечного пользователя? Если конечный пользователь живет в стране А, обладает кредитной картой компании В и работает в организации С, должны ли все три объекта подписывать один и тот же сертификат?

Установка СА

В некоторых организациях считается, что создание внутреннего СА (и

ззз соответствующей инфраструктуры с открытым ключом) необходимо в их деловой модели. Если это действительно так, существует несколько вопросов, которые необходимо решить, прежде чем устанавливать бюро сертификатов.

  • • Должна быть создана пара открытого ключа СА. Ключ должен быть достаточно большим, чтобы обеспечивать безопасность на большой период времени (как правило, больше чем на два года).
  • • Открытый ключ СА должен быть сертифицирован самим СА и, возможно, другим бюро сертификатов, расположенном на более высоком уровне иерархической модели. Если сертификат предоставляется внешней организацией, то это будет стоить определенную сумму денег.
  • • Секретный ключ СА должен быть защищен на весь период своего существования. Если он когда-нибудь будет раскрыт, может понадобиться перестройка всей инфраструктуры.
  • • Необходимо создать соответствующие политики и процедуры для аутентификации и подписывания сертификатов нижнего уровня.
  • • Необходимо реализовать механизм, позволяющий объектам нижних уровней верифицировать сертификаты друг друга. Это означает, что сертификат СА должен быть доступен каждому объекту нижнего уровня. В некоторых случаях это означает непосредственное взаимодействие с СА. В такой структуре необходимо, чтобы СА было доступно в течение всего периода времени, либо это бюро сертификатов вызовет ошибки в работе всей системы.

Вопрос к эксперту

Вопрос. Существуют ли С А общего пользования?

Ответ. Да, существуют "общие" бюро сертификатов, предназначенные для обслуживания основной массы населения, а не определенных организаций. VeriSign (ссылка: http://www.verisign.com) и Thawte (ссылка: http://www.thawte.com/) являются наиболее яркими примерами таких СА. Организация может создать пару открытого ключа, например для вебсервера, и отправить открытый ключ в СА. СА создает сертификат и предоставляет его организации. СА получает прибыль от предоставления этой услуги. Использование таких сертификатов можно наблюдать при посещении многих защищенных сайтов в интернете. Так как открытые ключи СА известны большей части веб-браузеров, сертификат веб-сайта верифицируется с помощью открытого ключа СА.

Примечание

Системы, используемые в СА, и сертификаты СА (в особенности секретные ключи СА) должны быть хорошо защищены, так как СА является "сердцем" системы. Меры, предпринимаемые для защиты секретного ключа СА, как правило, требуют, чтобы разблокировку секретного ключа производили два человека.

Как видно из списка, приведенного выше, при разработке СА возникает целый ряд вопросов. Если организация достаточно крупная или имеет большое число объектов нижних уровней (т. е. пользователей), администрирование сертификатов пользователей будет отнюдь не простой задачей. Перед подписыванием сертификата нужно будет проверить личность каждого пользователя. Срок действия сертификатов будет периодически истекать, и, следовательно, будет возникать потребность в издании новых сертификатов. Некоторые сертификаты придется аннулировать.

Аннулирование сертификатов

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

Если организация использует только одно СА, все не так сложно, однако при этом СА должно быть постоянно доступным. Если иерархия СА имеет большие размеры (как на рис. 12.12Е то проблема приобретает комплексный характер. Пользователь Userl может сообщить СА о том, что его сертификат аннулирован, и СА1 может обнародовать эту информацию, но как эта информация дойдет до пользователя User4 от СА6?

Сеть

Сеть с доверием представляет собой альтернативную модель доверия. Эта концепция была впервые использована в технологии Pretty Good Privacy (PGP). Она заключается в том, что каждый пользователь сертифицирует свой сертификат и передает его известным ассоциированным объектам. Эти объекты могут подписать сертификат другого пользователя, так как он известен (см. рис. 12.13).

В данной модели не существует центрального бюро сертификатов. Если пользователю Userl требуется верифицировать информацию, поступающую от пользователя User2, он запрашивает сертификат пользователя User2. Так как пользователь Userl знает пользователя User2, то доверяет сертификату и даже может его подписать.

Теперь рассмотрим ситуацию, в которой Userl получает информацию от User3. Пользователь User3 не известен пользователю Userl, но у пользователя User3 есть сертификат, подписанный пользователем User2. Таким образом, рассматриваемая модель распространяется на всю компьютерную сеть. Единственным решением, которое должно приниматься в процессе работы, является число переходов, которому доверяет пользователь. Как правило, это число равно 3 или 4. Кроме того, может возникнуть ситуация, в которой для установления доверия другому пользователю есть два пути. Например, User2 может использовать два пути установления доверия с пользователем User5: один через пользователя User3 и другой через пользователя User4. Так как оба пользователя User3 и User4 сертифицируют пользователя User5, пользователь User2 может быть уверен в сертификате пользователя User5.

Сеть модели доверия

Рис. 12.13. Сеть модели доверия

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

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

 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ   ОРИГИНАЛ   След >