В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 20. PKI: жестокая реальность ряет сам себе, а его клиенты уже высказали доверие банку, вложив в него свои деньги. Компания может выполнять роль собственного ЦС для виртуальной частной сети. Собственный ЦС может быть и у ассоциации кредитных карт. Интересно отметить, что ЦС использует существующие отношения до- верия, основанные на договорных отношениях. Это всегда учитывается при разработке криптографических систем: все базовые отношения доверия, от которых мы отталкиваемся при разработке системы, основаны на договорных отношениях. 20.4 Непрямая авторизация Мы подошли к большой проблеме классической мечты о PKI. Инфра- структура открытого ключа привязывает ключи к именам людей, но боль- шинство систем не интересует имя конкретного человека. Банковская система должна знать, какие транзакции следует авторизовать; виртуальная частная сеть — к каким каталогам следует предоставить доступ. Ни одну из этих систем не волнует, кому принадлежит ключ. Их интересует лишь то, что позволено делать владельцу этого ключа. Для разрешения данной проблемы большинством систем используются так называемые списки контроля доступа (access control list — ACL) . Спи- сок контроля доступа — это всего лишь база данных, в которой указано, кому из пользователей системы какие действия разрешено выполнять. Ино- гда содержимое списка контроля доступа сортируется по имени пользовате- ля (например, пользователю по имени Боб разрешено выполнять следующее: открывать файлы в каталоге /usr/bob , использовать офисный принтер, осу- ществлять доступ к файловому серверу), но в большинстве случаев список контроля доступа индексируется по действию (например, вносить деньги на данный счет может только Боб либо Бетти). Зачастую для упрощения спис- ков контроля доступа пользователей объединяют в группы, однако базовая функциональность при этом не изменяется. Итак, теперь у нас есть три объекта: ключ, имя и разрешение на выпол- нение какого-нибудь действия. Система при этом должна знать, какой ключ какое действие авторизует, другими словами, есть ли у заданного ключа раз- решение на выполнение определенного действия. Классическая инфраструк- тура открытого ключа решает эту проблему, привязывая ключи к именам и используя список контроля доступа, чтобы привязать имена к разрешени- ям. Это непрямой метод авторизации, который к тому же создает больше потенциальных объектов для нападения [27]. Первый объект нападения — это сертификат типа “имя-ключ”, выдан- ный инфраструктурой открытого ключа. Второй объект нападения — база 20.5. Прямая авторизация 351 данных со списком контроля доступа, который привязывает имена к разре- шениям. И наконец, третий объект нападения — путаница в именах. Однако понятие имени, как уже отмечалось, весьма расплывчатое. Как определить, является ли имя, указанное в списке контроля доступа, тем самым именем, что фигурирует в сертификате? И как по ошибке не присвоить двум разным людям одно и то же имя? Если вы проанализируете эту ситуацию, то поймете, что в данном слу- чае техническое проектирование следует наивной формулировке требований пользователей. Эта проблема рассматривается в терминах идентификации владельца ключа и предоставления доступа тому или иному человеку — имен- но так поступают охранники в офисе. Автоматизированные системы могут использовать гораздо более прямой подход. Дверному замку все равно, кто именно держит в руках ключ. Он пропустит в помещение любого, у кого этот ключ есть. 20.5 Прямая авторизация Намного эффективнее привязать разрешения непосредственно к ключу, используя для этого инфраструктуру открытого ключа. Сертификат боль- ше не будет привязывать ключ к имени; вместо этого он связывает ключ с набором разрешений [27]. Все системы, использующие сертификаты инфраструктуры открытого ключа, теперь могут непосредственно решать, предоставлять доступ или нет. Для этого им достаточно взглянуть на сертификат и выяснить, обладает ли соответствующий ключ необходимыми разрешениями. Это прямой и простой метод. Прямая авторизация избавляет от необходимости поддерживать списки контроля доступа и работать с именами, тем самым устраняя соответствую- щие объекты нападения. Правда, некоторые из этих проблем вновь всплывут на стадии выдачи сертификатов. Кто-то должен определить, какому пользо- вателю будет разрешено осуществлять какие действия, и гарантировать, что это соответствие будет правильно закодировано в сертификате. База дан- ных всех этих соответствий станет эквивалентом списка контроля доступа, но атаковать ее будет намного сложнее. Во-первых, принятие подобных ре- шений легко распределить между несколькими людьми, что позволяет изба- виться от централизованной базы данных и всех уязвимых мест, связанных с ее наличием. Лица, принимающие решения, могут просто выдать пользо- вателю соответствующий сертификат, не прибегая к развертыванию какой- либо дополнительной инфраструктуры и обеспечению ее безопасности. Во- вторых, это позволяет снизить зависимость процесса выдачи сертификатов |