Обобщенный прикладной программный интерфейс службы безопасности GSS-API не содержит средств, направленных на контроль прав доступа или хотя бы на передачу авторизационной информации. Для этого, однако, есть веские причины.
Интерфейс безопасности должен обслуживать разнообразные приложения. Содержательная трактовка прав доступа, как и определение того, что (или кто) является объектом или субъектом контроля, может быть выполнена только самими приложениями. Даже для устоявшихся и сравнительно однородных сервисов, таких как файловый, авторизация в разных операционных средах может носить существенно разный характер. Более того, характер авторизации может меняться и для одной операционной среды при переходе от изолированной системы к распределенной конфигурации. В качестве примера достаточно привести SunOS, где правила доступа к файлам, находящимся на смонтированных NFS-томах, гораздо сложнее, чем в локальном случае.
Другую причину можно назвать политической. Спецификациям GSS-API в их нынешнем виде удовлетворяет такая популярная система, как Kerberos, не содержащая средств контроля доступа. Специфицировать подобные средства в GSS-API — значит лишиться поддержки со стороны Kerberos. В результате такой акции интерфейс безопасности "повиснет в воздухе", из-под него будет выбита почва.
В то же время проблемы авторизации, делегирования полномочий с ограничениями, несомненно, требуют решения (на прикладном уровне). Как передать серверу печати право на доступ только к определенным файлам и только на чтение? Как защитить строки своих таблиц в базе данных от удаления сервером приложений, оставив за ним возможность добавления информации? В общем виде решение очевидно — нужно перестроить систему авторизации на основе архитектуры клиент/сервер. В нынешней ситуации, когда каждое приложение (операционная система, СУБД, почтовая служба и т.п.) использует специфические методы контроля доступа, универсальное, стандартное решение в духе открытых систем получить невозможно.
Впрочем, первый и весьма важный шаг уже сделан. Имеется в виду реализация серверов аутентификации, которые позволили системно-независимым образом идентифицировать субъекты доступа. Трудно сказать, насколько быстро процесс пойдет дальше. По-видимому, рассчитывать на быстрый прогресс не приходится - слишком велика масса программного обеспечения, нуждающегося в пересмотре.
Еще одна проблема технического плана, вытекающая из архитектуры интерфейса GSS-API, состоит в том, что для коротких сообщений накладные расходы, связанные с обеспечением целостности и конфиденциальности данных, могут оказаться весьма значительными. Это может резко ухудшить характеристики таких протоколов, как telnet. Выбор минимально допустимого качества защиты и буферизация данных — вот методы, которые, вероятно, способны улучшить ситуацию.
|
|
|
|
| Детальное описание некоторых функций безопасности | Содержание | Представление некоторых объектов интерфейса безопасности в среде языка C |
| Copyright ╘ 1993-2000, Jet Infosystems |