Стандарты информационной безопасности
       

Основные понятия


Обобщенный прикладной программный интерфейс службы безопасности содержит следующие основные понятия:

  • удостоверение;

  • контекст безопасности;

  • токен безопасности;

  • механизм безопасности;

  • имя;

  • канал передачи данных.

Удостоверение - это структура данных, позволяющая ее владельцу доказать партнеру по общению или третьей стороне, что он (владелец) является именно тем, за кого себя выдает. Таким образом, в 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 предлагается возможность связывания контекста безопасности с определенными каналами передачи данных: инициатор формирования контекста может указать набор каналов, которые допустимо использовать в рамках открываемого сеанса общения.


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

Каждая функция, входящая в состав обобщенного интерфейса безопасности GSS-API, возвращает два кода ответа - основной и дополнительный. Набор основных кодов регламентируется в рамках GSS-API, дополнительные могут быть специфичны для различных служб безопасности.

Основные коды подразделяются на информирующие и сигнализирующие об ошибке. Перечислим некоторые информирующие коды:

  • GSS_S_COMPLETE - нормальное завершение;
  • GSS_S_CONTINUE_NEEDED - требуется дополнительный вызов данной функции;
  • GSS_S_DUPLICATE_TOKEN - обнаружено дублирование токена защиты сообщений.


Следующие значения входят в число кодов, сигнализирующих об ошибке:

  • GSS_S_BAD_NAME - задано некорректное имя;
  • GSS_S_CONTEXT_EXPIRED - истек срок действия контекста;
  • GSS_S_CREDENTIALS_EXPIRED - истек срок действия удостоверения;
  • GSS_S_DEFECTIVE_TOKEN - обнаружено повреждение токена безопасности;
  • GSS_S_NO_CONTEXT - не задан контекст;
  • GSS_S_NO_CRED - не задано удостоверение.


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


Содержание раздела