В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 20. PKI: жестокая реальность от имен, поскольку лица, принимающие решения, занимают более низкую ступень в руководстве компании и работают с гораздо меньшими группами людей. Как правило, они лично знакомы с пользователями или хотя бы знают их в лицо, что во многом позволяет избежать путаницы с именами. Так, может быть, стоит совсем избавиться от имен в сертификатах? Вообще-то нет. Хотя имена и не будут фигурировать в обычных опера- циях, сведения о пользователях могут понадобиться для проведения аудита и т.п. Предположим, банк только что обработал выдачу заработной платы, авторизованную одним из четырех ключей, имеющих полномочия переводить средства компании на данный счет. Через три дня главный финансовый ад- министратор компании звонит в банк и спрашивает, на каком основании был выполнен этот платеж. Банк знает, что выдача заработной платы была авто- ризована некоторым ключом, но финансовому администратору нужно нечто большее, чем несколько тысяч случайных бит открытого ключа. Вот почему в сертификат все-таки нужно включать имя пользователя. Тогда банк смо- жет сообщить администратору, что ключ, посредством которого была авто- ризована выдача заработной платы, принадлежит некоему Дж. Смиту. Этого будет вполне достаточно, чтобы администратор понял, что произошло. Отме- тим, однако, что в данном случае имена, указанные в сертификатах, должны иметь значение только для людей. Компьютеру никогда не придется выяс- нять, относятся ли два разных имени к одному и тому же человеку или на кого конкретно ссылается заданное имя. Люди гораздо лучше управляются с такими расплывчатыми понятиями, как имена, в то время как компьюте- рам нравятся более простые и строго определенные вещи наподобие наборов разрешений. 20.6 Системы мандатов Продолжая развивать описанный принцип доступа на основе разрешений, мы получим полноценную систему мандатов. Это уже не просто инфраструк- тура, а суперинфраструктура открытого ключа. В подобной системе для выполнения каждого действия пользователю нужно иметь мандат (creden- tial) в виде подписанного сертификата. Если у пользователя А есть мандат, который разрешает ему открывать конкретный файл для чтения и записи, этот пользователь может передать полностью или частично свои полномочия пользователю Б. Например, пользователь А может подписать сертификат от- крытого ключа пользователя Б, в котором будет утверждаться нечто напо- добие: “Ключу PK B разрешено открывать файл X для чтения, так как ему были переданы полномочия ключа PK A ”. Если пользователь Б хочет считать файл X , он должен предъявить этот сертификат, а также сертификат, дока- 20.6. Системы мандатов 353 зывающий, что пользователю А действительно разрешено открывать файл X для чтения. Система мандатов может обладать и дополнительными функциями. На- пример, пользователь А может ограничить срок действия передачи своих полномочий, включив его в сертификат. Кроме того, пользователь А может ограничить возможность пользователя Б передавать полномочия на чтение файла X другим пользователям 2 . В теории система мандатов является исключительно мощной и гибкой. На практике же по ряду причин подобные системы применяются крайне редко. Во-первых, системы мандатов довольно сложны, а их применение вле- чет за собой массу дополнительных расходов. Права пользователя на доступ к ресурсу могут зависеть от цепочки из пяти-шести сертификатов, каждый из которых должен быть передан и тщательно проверен. Во-вторых, применение мандатов требует своеобразного микроуправле- ния доступом. Полномочия так легко разбивать на части все меньшего и мень- шего размера, что пользователи начинают тратить слишком много времени на обдумывание того, сколько именно полномочий следует передать своему коллеге. Это время, как правило, уходит впустую. Еще большей проблемой, однако, является потеря времени того самого коллеги, когда оказывается, что у него не хватает прав доступа для выполнения работы. Возможно, проблема микроуправления может быть решена путем обучения пользователей и улуч- шения пользовательских интерфейсов, но вопрос все еще остается открытым. Некоторые пользователи успешно избегают проблемы микроуправления, пе- редавая все (или практически все) свои полномочия любому, кто нуждается в каком-либо уровне доступа, что подрывает безопасность всей системы. В-третьих, чтобы реализовать систему мандатов, необходимо разработать специальный язык передачи полномочий. Сообщения о передаче полномочий должны быть написаны на логическом языке, который будет понятен ком- пьютерам. Этот язык должен быть достаточно мощным для того, чтобы на нем можно было выразить всю требующуюся функциональность, и вместе с тем достаточно простым, чтобы обеспечить быстрое сцепление заключе- ний. Он также должен быть разработан с запасом на будущее. После того как система мандатов будет развернута, в каждую программу понадобит- 2 Многие клиенты требуют, чтобы система обладала подобным свойством, однако нам это кажется в корне неверным. Ограничение возможности пользователя Б передавать свои полномочия другим лишь вынуждает его запустить какую-нибудь службу прокси, благо- даря которой другие пользователи смогут применять мандат пользователя Б для доступа к нужным ресурсам. Использование подобных программ подрывает инфраструктуру без- опасности и должно быть запрещено, но это имеет смысл только тогда, когда у людей нет практических причин передавать свои полномочия и, следовательно, запускать прокси. А такие причины всегда найдутся. |