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