Вход в личный кабинет Создание и уничтожение контекста безопасности
Создание контекста безопасности предшествует всем операциям по обмену сообщениями между потенциальными партнерами. В процессе формирования контекста партнеры могут убедиться в подлинности друг друга, а также договориться о степени защищенности коммуникаций.
Для работы с контекстами обобщенный интерфейс безопасности GSS-API предоставляет следующие функции:
GSS_Init_sec_context. формирование “исходящего”
GSS_Accept_sec_context. формирование “входящего”
GSS_Delete_sec_context. отказ от контекста, ставшего ненужным
GSS_Process_context_token. обработка полученного контекстного токена
GSS_Context_time. выяснение времени, в течение которого контекст будет оставаться годным
GSS_Inquire_context. получение информации о контексте
GSS_Wrap_size_limit. выяснение максимального размера сообщения, которое можно зашифровать в рамках заданного контекста безопасности
GSS_Export_sec_context. передача контекста другому процессу
GSS_Import_sec_context. прием контекста, переданного другим процессом
Инициатор общения вызывает функцию GSS_Init_sec_context, передавая ей свое удостоверение — явно полученное или подразумеваемое. Кроме того, инициатор специфицирует запрашиваемую процедуру взаимной аутентификации и уровень защиты сообщений. В ответ ему возвращается токен, который следует переслать партнеру.
Партнер, получив токен, передает его функции GSS_Accept_sec_context (вместе со своим удостоверением). Как правило, на этом формирование контекста заканчивается. Партнеры должны проанализировать флаги, ассоциированные с контекстом, чтобы узнать, каков реально предоставленный уровень защиты.
Если инициатор общения (обычно это клиент) желает убедиться в подлинности партнера, он передает функции GSS_Init_ sec_context флаг mutual_req_ flag (требуется взаимная аутентификация). В таком случае вызов GSS_Init_sec_context возвращает в качестве основного кода значение GSS_S_CONTINUE_NEEDED (а не GSS_S_ COMPLETE).
Соответствующим образом меняется и генерируемый контекстный токен. Партнер, приняв и обработав (с помощью функции GSS_Accept_sec_context) присланную информацию, получит на выходе установленный флаг mutual_state и новый контекстный токен, который следует вернуть инициатору.
В принципе служба безопасности может требовать при формировании контекста обмена несколькими токенами (даже без взаимной аутентификации). В этом случае инициатору придется несколько раз вызывать функцию GSS_Init_sec_context, а его партнеру — функцию GSS_Accept_sec_context.
Общающиеся партнеры должны сами определять (способами, внешними по отношению к GSS-API), что из пересылаемой информации представляет собой контекстный токен и какой функции его следует передать.
При отказе от контекста, ставшего ненужным, можно получить от функции GSS_Delete_sec_context управляющий токен, подлежащий пересылке партнеру. Партнер, приняв токен, должен вызвать функцию GSS_Process_context_token, которая проанализирует управляющую информацию и удалит вторую половину сбрасываемого контекста.
Как правило, в процессе формирования контекста партнер получает информацию о его инициаторе. Инициатор может, посредством флага anon_req_ flag, запросить формирование “анонимного” контекста. Это имеет смысл при пользовании общедоступными услугами (получение свободно распространяемой информации и т.п.). Партнер вправе принять или отвергнуть анонимный контекст.
Функция GSS_Inquire_context позволяет получить информацию о контексте — имена инициатора общения и его партнера, срок годности, тип задействованного механизма безопасности, а также ассоциированные флаги (replay_det_state — обеспечивается отслеживание продублированных сообщений, conf_avail – предоставляется возможность шифровать сообщения и т.п.).
Функция GSS_Export_ sec_context позволяет получить токен, пригодный для передачи контекста безопасности другому процессу в пределах одной вычислительной системы. Передавать можно только полностью сформированный контекст. Вообще говоря, экспортировав контекст, процесс теряет право на его использование.
Для приема (импорта) контекста безопасности служит функция GSS_Import_sec_context.
I. терминологический словарь
Авторизация. процесс определения правомочности использования клиентом определенной услуги, перечня доступных объектов, а также разрешенных видов доступа.
Аутентификатор. запись, содержащая информацию, про которую можно доказать, что она была недавно сгенерирована с использованием сеансового ключа, известного только клиенту и серверу.
Аутентификационный заголовок. запись, содержащая билет и удостоверение. Эта запись будет представлена серверу в процессе проверки подлинности.
Аутентификационный маршрут. последовательность промежуточных областей управления, пересекаемых в процессе проверки подлинности субъектов из разных областей.
Аутентификация (проверка подлинности). проверка того, что субъект является тем, за кого он себя выдает.
Билет. запись, помогающая клиенту доказать серверу свою подлинность. Билет содержит сведения о клиенте, сеансовый ключ, временной штамп и другую информацию. На билете ставится печать с помощью секретного ключа сервера. Билет действителен только вместе со свежим аутентификатором.
Билет на билеты (Ticket-Granting Ticket, TGT). билет к серверу выдачи билетов (Ticket-Granting Server, TGS), позволяющий получать билеты к другим серверам.
Доверенность. документ, дающий предъявителю право на доступ к определенным объектам или услугам. В системе Kerberos это может быть билет, использование которого ограничено содержимым поля авторизации. К билету должен прилагаться сеансовый ключ.
Идентификатор субъекта. имя, используемое для уникальной идентификации субъекта.
Клиент. процесс, использующий сетевые сервисы от имени пользователя. Отметим, что в некоторых случаях сервер сам может являться клиентом некоторого другого сервера (например, сервер печати может пользоваться услугами файлового сервера).
Обычный текст. исходные данные для функции шифрования или результат функции расшифровки. Расшифровка преобразует шифрованный текст в обычный.
Печать. средство, позволяющее так зашифровать запись, содержащую несколько полей, что замена отдельных полей невозможна без знания ключа шифрования (иначе подмена будет обнаружена).
Сеансовый ключ. временный ключ шифрования, используемый двумя субъектами. Время жизни такого ключа ограничено одним сеансом работы в системе.
Секретный ключ. ключ шифрования, разделяемый субъектом и KDC и используемый длительное время. В случае, когда субъектом является пользователь, секретный ключ вычисляется по паролю.
Сервер. субъект, предоставляющий ресурсы сетевым клиентам.
Сервис (услуга). ресурс, предоставляемый сетевым клиентам. Зачастую может поддерживаться несколькими серверами (например, сервис удаленных файлов).
Субсеансовый ключ. временный ключ шифрования, используемый двумя субъектами. Обмен субсеансовыми ключами защищается посредством сеансовых ключей. Время жизни субсеансового ключа ограничено одним сеансом общения между субъектами.
Субъект. пользователь, клиент или сервер, имеющий уникальное имя и участвующий в сетевом общении.
Удостоверение. совокупность билета и секретного сеансового ключа, необходимого для успешного использования билета в процессе проверки подлинности.
Центр распределения билетов (Key Distribution Center, KDC). сетевой сервис, предоставляющий билеты и временные сеансовые ключи, или конкретный сервер, оказывающий данную услугу, или хост, на котором функционирует этот сервер. KDC обслуживает запросы и на начальный билет (соответствующий компонент иногда называют сервером начальной аутентификации — Authentication Server, AS), и на билеты к конкретным серверам (этот компонент именуют сервером выдачи билетов — Ticket-Granting Server, TGS).
Цербер (Kerberos). не только мифологический трехголовый пес, охранявший подземное царство, но и название сервиса проверки подлинности для проекта Афина (Массачусетский технологический институт), протокол, используемый этим сервисом, а также программная реализация сервиса аутентификации.
Шифрованный текст. результат функции шифрования. Шифрование преобразует обычный текст в шифрованный.
Nodejs: sso-авторизация через kerberos
Всё гениальное просто. Но до этой простоты нужно перечитать тысячи мануалов. Поэтому, разобравшись, мне захотелось написать quick start по тому, как сделать прозрачную авторизацию в Web-приложении для пользователя, авторизованного в AD, и поделиться своим тестовым проектом. Интересен взгляд со стороны.
Для начала немного теории. SSO, она же прозрачная авторизация, это идея, по которой пользователь раз вводит логин/пароль своей учётной записи в Active Directory при входе на компьютер, и дальше, открывая Web-приложение (не только, но речь о нём) уже автоматически авторизуется с данными своей учётки.
В браузерах для этого заложен принцип — получая в ответ на свой Get-запрос HTTP-код 401 «Not Authorized», и в HTTP-заголовках <WWW-Authenticate: Negotiate>, он, браузер, делает запрос в KDC (Key Distribution Center — одна из служб AD) на получение специального SPNEGO-токена для данного Web-сервиса. Если учётки для такого Web-сервиса нет в AD, то браузер берёт стандартный ответ для авторизации по NTLM. Но в данном случае мы считаем, что что-то пошло не так.
Итак, браузер, в случае корректных настроек данного Web-сервиса в AD, на ответ 401 вновь отправляет Get-запрос, но уже с заголовком вида <Authorization: YIIJvwYGKw… > Если токен начинается так, с «YII», значит это Kerberos-закодированный тикет, содержащий данные для авторизации.
Kerberos — это просто тип шифрования, но поскольку он в основном используется для SSO, эти понятия тесно связаны.
Далее Web-сервис, получив токен, с помощью kerberos-клиента отправляет его в KDC на проверку. И, в случае успеха, получает имя пользователя в AD. Которое дальше уже можно использовать для поиска данных о пользователе (например, групп, в которых он состоит) уже через другой сервис доступа к AD — LDAP.
Наиболее наглядно описывает этот процесс схема из официальной документации Microsoft. И, надо сказать, на удивление именно их документация дала наибольшее понимание предмета.
.gif)
Отсюда
Таким образом, помимо создания Web-приложения, нужны следующие действия:
Что требуется сделать на стороне администраторов AD
— задать в AD SPN-имя для Web-сервиса (вида HTTP/[email protected]). Это позволит клиентским браузерам запрашивать токен для данного сервиса и передавать его в HTTP-заголовке Web-сервису, а Kerberos-клиенту через данный сервис на основе ключа проверять подлинность пользователей,
— сформировать для этого сервиса ключ krb5.keytab, который будет использоваться в Kerberos-клиенте для проверки подлинности пользователей.
Дополнительные действия на сервере Web-сервиса
— потребуется установить Kerberos-клиент (в Windows он уже есть, в случае Linux — например, для RedHat команда для установки: yum install krb5-workstation krb5-libs krb5-auth-dialog krb5-devel);
— для него нужно будет настроить файл конфигурации krb5.conf для доступа к KDC (как — администраторы AD назовут правильные настройки, главный параметр — kdc);
— а также подложить файл ключа /etc/krb5.keytab.
В Web-приложении
— устанавливается модуль kerberos, для работы с kerberos-клиентом,
— и модуль activedirectory, для выполнения LDAP-запросов.
Один неприятный момент — для Windows модуль kerberos предоставляет отдельный API, и использовать его не вышло. Если у кого-то есть решение — это была бы неоценимая помощь.
Для Linux модуль kerberos предоставляет два основных метода, которые нужны в работе:
— authGSSServerStep — отправка токена на проверку,
— authUserKrb5Password — авторизация по логин/пароль, на случай если прозрачная авторизация не сработала.
Документации по использованию методов нет, но есть толковые комментарии в файле libkerberos.js.
Вот основной кусок кода, проверяющий пришедший от браузера токен:
//cut phrase "Negotiate "
var ticket = req.headers.authorization.substring(10);
//init context
kerberos.authGSSServerInit("HTTP", function(err, context) {
//check ticket
kerberos.authGSSServerStep(context, ticket, function(err) {
//in success context contains username
res.set( 'WWW-Authenticate', 'Negotiate ' context.response);
res.send(context.username);
});
});
→ Ссылка на
тестовый проект на GitHub
В коде есть бонус — фильтр для поиска всех групп пользователя, работающий при большом числе групп на порядок быстрее метода, предложенного в модуле activedirectory.
В результате при открытии страницы, если всё сделано верно, должно быть
Ожидаемые ограничения:
— адрес Url не может быть в виде ip:port, а только с указанием DNS-имени (связано с регистрацией Web-сервиса в AD),
— данная авторизация работает только при определённых настройках IE, но это настройки по умолчанию («Автоматический вход в сеть только в зоне интрасети», «Разрешить встроенную проверку подлинности Windows»). Chrome использует настройки IE. В остальных браузерах возможно потребуются свои настройки.
Идентификация и аутентификация
Идентификация – присвоение пользователям идентификаторов (уникальных имен или меток) под которыми система “знает” пользователя. Кроме идентификации пользователей, может проводиться идентификация групп пользователей, ресурсов ИС и т.д. Идентификация нужна и для других системных задач, например, для ведения журналов событий.
В большинстве случаев идентификация сопровождается аутентификацией. Аутентификация – установление подлинности – проверка принадлежности пользователю предъявленного им идентификатора. Например, в начале сеанса работы в ИС пользователь вводит имя и пароль.
Система идентификации и аутентификации является одним из ключевых элементов инфраструктуры защиты от несанкционированного доступа (НСД) любой информационной системы. В соответствии с рассмотренной ранее моделью многоуровневой защиты, аутентификация пользователя компьютера относится к уровню защиты узлов.
Обычно выделяют 3 группы методов аутентификации.
- Аутентификация по наличию у пользователя уникального объекта заданного типа. Иногда этот класс методов аутентификации называют по-английски “I have” (“у меня есть”). В качестве примера можно привести аутентификацию с помощью смарт-карт или электронных USB-ключей.
- Аутентификация, основанная на том, что пользователю известна некоторая конфиденциальная информация – “I know” (“я знаю”). Например, аутентификация по паролю. Более подробно парольные системы рассматриваются далее в этом разделе.
- Аутентификация пользователя по его собственным уникальным характеристикам – “I am” (“я есть”). Эти методы также называются биометрическими.
Нередко используются комбинированные схемы аутентификации, объединяющие методы разных классов. Например, двухфакторная аутентификация – пользователь предъявляет системе смарт-карту и вводит пин-код для ее активации.
Наиболее распространенными на данный момент являются парольные системы аутентификации. У пользователя есть идентификатор и пароль, т.е. секретная информация, известная только пользователю (и возможно – системе), которая используется для прохождения аутентификации.
В зависимости от реализации системы, пароль может быть одноразовым или многоразовым. Операционные системы, как правило, проводят аутентификацию с использованием многоразовых паролей. Совокупность идентификатора, пароля и, возможно, дополнительной информации, служащей для описания пользователя составляют учетную запись пользователя.
Если нарушитель узнал пароль легального пользователя, то он может, например, войти в систему под его учетной записью и получить доступ к конфиденциальным данным. Поэтому безопасности паролей следует уделять особой внимание.
Как отмечалось при рассмотрении стандарта ISO 17799, рекомендуется, чтобы пользователи системы подписывали документ о сохранении конфиденциальности пароля. Но нарушитель также может попытаться подобрать пароль, угадать его, перехватить и т.д.
- Задание минимальной длины используемых в системе паролей. Это усложняет атаку путем подбора паролей. Как правило, рекомендуют устанавливать минимальную длину в 6-8 символов.
- Установка требования использовать в пароле разные группы символов – большие и маленькие буквы, цифры, специальные символы. Это также усложняет подбор.
- Периодическая проверка администраторами безопасности качества используемых паролей путем имитации атак, таких как подбор паролей “по словарю” (т.е. проверка на использование в качестве пароля слов естественного языка и простых комбинаций символов, таких как “1234”).
- Установка максимального и минимального сроков жизни пароля, использование механизма принудительной смены старых паролей.
- Ограничение числа неудачных попыток ввода пароля (блокирование учетной записи после заданного числа неудачных попыток войти в систему).
- Ведение журнала истории паролей, чтобы пользователи, после принудительной смены пароля, не могли вновь выбрать себе старый, возможно скомпрометированный пароль.
Современные операционные системы семейства Windows позволяют делать установки, автоматически контролирующие выполнение требований 1,2,4-6. При использовании домена Windows, эти требования можно распространить на все компьютеры, входящие в домен и таким образом повысить защищенность всей сети.
Но при внедрении новых механизмов защиты могут появиться и нежелательные последствия. Например, требования “сложности” паролей могут поставить в тупик недостаточно подготовленного пользователя. В данном случае потребуется объяснить, что с точки зрения операционной системы Windows надежный пароль содержит 3 из 4 групп символов (большие буквы, малые буквы, цифры, служебные знаки).
Аналогичным образом, надо подготовить пользователей и к внедрению блокировки учетных записей после нескольких неудачных попыток ввода пароля. Требуется объяснить пользователям, что происходит, а сами правила блокировки должны быть хорошо продуманы. Например, если высока вероятность того, что пользователь заблокирует свою запись в период отсутствия администратора, лучше ставить блокировку не насовсем, а на какой-то срок (30 минут, час и т.д.).
Это приводит к тому, что должна быть разработана политика управления паролями, сопровождающие ее документы, а потом уже проведено внедрение.
При использовании ОС семейства Windows, выявить учетные записи со слабыми или отсутствующими паролями можно, например, с помощью утилиты Microsoft BaselineSecurityAnalyzer.
Как работает kerberos 5 в картинках
Неформальное изложение возможностей kerberos
Система Kerberos предназначена для решения следующей задачи. Имеется открытая (незащищенная) сеть, в узлах которой сосредоточены субъекты — пользователи, а также клиентские и серверные программные системы. Каждый субъект обладает секретным ключом. Чтобы субъект C мог доказать свою подлинность субъекту S (без этого S не станет обслуживать C), он должен не только назвать себя, но и продемонстрировать знание своего секретного ключа.
C не может просто послать S свой секретный ключ, во-первых, потому, что сеть открыта (доступна для пассивного и активного прослушивания), а, во-вторых, потому, что S не знает (и не должен) знать секретный ключ C. Требуется менее прямолинейный способ демонстрации знания секретного ключа.
Система Kerberos представляет собой надежную третью сторону (то есть сторону, которой доверяют все), владеющую секретными ключами обслуживаемых субъектов и помогающую им в попарной проверке подлинности.
Чтобы с помощью Kerberos получить доступ к S (обычно это сервер), C (как правило — клиент) посылает Kerberos’у запрос, содержащий сведения о нем (клиенте) и о запрашиваемой услуге. В ответ Kerberos возвращает две порции информации: так называемый билет, зашифрованный секретным ключом сервера, и копию части информации из билета, зашифрованную секретным ключом клиента.
Клиент должен расшифровать вторую порцию данных и переслать ее вместе с билетом серверу. Сервер, расшифровав билет, может сравнить его (билета) содержимое с дополнительной информацией, присланной клиентом. Совпадение свидетельствует о том, что клиент смог расшифровать предназначенные ему данные (ведь содержимое билета никому, кроме сервера и Kerberos, недоступно), то есть продемонстрировал знание своего секретного ключа.
Значит, клиент — именно тот субъект, за кого себя выдает. Подчеркнем, что секретные ключи в процессе проверки подлинности не передавались по сети (даже в зашифрованном виде) — они только использовались для шифрования. Как организован первоначальный обмен ключами между Kerberos и субъектами и как субъекты хранят свои секретные ключи — вопрос отдельный.
Проиллюстрируем описанную процедуру Рис. 1.
Изложенный вариант 1 — крайне упрощенная версия реальной процедуры проверки подлинности. Прежде всего, необходимо уточнить структуру пересылаемых запросов и возвращаемых ответов. И билет, и вторая порция информации, предоставляемая со стороны Kerberos, содержат случайный ключ, пригодный для шифрования сообщений, пересылаемых между клиентом и сервером.
Этот ключ называется сеансовым и представляет собой общую секретную информацию, разделяемую C и S. Появление подобной общей информации и возможность организации конфиденциального взаимодействия — важный побочный продукт аутентификации средствами Kerberos.
Билет, который выдает Kerberos, имеет ограниченный срок годности. Естественно распространить этот срок и на сеансовый ключ. Когда срок годности истекает, необходимо проведение повторной проверки подлинности. Продолжительность стандартного срока годности зависит от политики безопасности, проводимой организацией. Типичный срок годности — 8 часов.
Вполне вероятно, что клиент C захочет убедиться в подлинности обслуживающего его сервера S. Чтобы это было возможным, клиент шифрует дополнительную информацию, передаваемую серверу, с помощью сеансового ключа. Сервер может узнать сеансовый ключ, только расшифровав билет.
Далее, необходимо защитить информацию, пересылаемую по сети, от воспроизведения. Если этого не сделать, злоумышленник сможет послать серверу дубликаты билета и дополнительной информации и успешно выдать себя за “второго C”. Стандартный способ защиты от воспроизведения — включение в нее временных штампов и/или так называемых одноразовых номеров, позволяющих удостовериться в “свежести” сообщений и в их неповторяемости (и, более того, в целостности последовательности сообщений). Одноразовые номера позволяют также ассоциировать ответы с предыдущими запросами.
Отобразим упомянутые уточнения на новом рисунке (Рис. 2).
Отдельного пояснения заслуживает обозначение s1 в первом запросе. Вообще говоря, клиенту нужен не конкретный сервер, а определенный сервис, о чем он и просит Kerberos. В ответ клиент получает адрес сервера, способного оказать запрашиваемую услугу.
Порции информации в сообщениях 3 и 4, шифруемые сеансовыми ключами, называют аутентификаторами. Они позволяют убедиться в подлинности предъявившего их субъекта. В дальнейшем аутентификатор клиента мы будем обозначать Ac, аутентификатор сервера — As.
Вариант 2 гораздо практичнее варианта 1, однако и он нуждается в уточнении. Естественно предположить, что клиенту понадобятся услуги нескольких серверов. Соответственно, чтобы доказать свою подлинность, клиенту придется несколько раз повторять диалог с Kerberos и использовать свой секретный ключ.
К сожалению, долго держать наготове секретный ключ опасно — его могут украсть. Чтобы справиться с указанной проблемой, сервер Kerberos “раздваивается” на сервер начальной аутентификации (AS — Authentication Server) и сервер выдачи билетов (TGS — Ticket Granting Server).
Клиент запрашивает у AS по схеме, изображенной на Рис. 2, билет к TGS (“билет на получение билетов”, “билет на билеты” — TGT, Ticket-Granting Ticket). TGT содержит сеансовый ключ для засекречивания общения между клиентом и сервером выдачи билетов. Билеты к другим серверам клиент получает у TGS на основании “билета на билеты”.
В результате схема получения доступа к серверу приобретает вид, изображенный на Рис. 3.
Таким образом, секретный ключ нужен клиенту только на короткое время для получения “билета на билеты”. В дальнейшем используется сеансовый ключ, разделяемый клиентом и сервером выдачи билетов. Компрометация сеансового ключа, имеющего ограниченный срок годности, — вещь существенно менее опасная, чем раскрытие секретного ключа.
Любопытно отметить, что AS, вопреки своему названию, не проверяет подлинности обратившихся к нему субъектов. Билет на билеты может получить кто угодно, в том числе и злоумышленник, но воспользоваться этим билетом он сможет, только если знает секретный ключ субъекта, от имени которого он выступает.
Отметим также, что если для программных субъектов (клиентов и серверов) способ хранения секретного ключа не определен, то для пользователей специфицируется алгоритм преобразования пароля в ключ. Иными словами, пользователю достаточно помнить только свой пароль.
Каждый сервер Kerberos обслуживает определенную область управления. До сих пор мы рассматривали случай, когда клиент и сервер находились в пределах одной области и взаимодействовали посредством локального Kerberos. Теперь обратимся к ситуации, когда клиент и сервер зарегистрированы в разных областях.
Чтобы субъекты из разных областей управления могли общаться друг с другом, между областями должно быть заключено соглашение, а серверы Kerberos должны обменяться секретными ключами. (Ключи могут быть разными для различных общающихся пар серверов Kerberos.)
Поскольку между областями управления Kerberos существуют стандартные иерархические отношения, каждой области достаточно заключить соглашение и обменяться ключами с родителем и всеми потомками. В принципе возможно заключение соглашения между двумя произвольными областями, субъекты которых активно общаются друг с другом. Рис. 4 иллюстрирует отношения между областями управления.
При наличии договорных отношений локальный сервер выдачи билетов может выдать билет к удаленному TGS, который, в свою очередь, выдаст билет к удаленному серверу. Последовательность обмена сообщениями для этого случая показана на Рис. 5.
В более общем случае клиенту придется пройти через несколько промежуточных серверов выдачи билетов. Впрочем, поскольку глубина вложенности областей управления обычно невелика (3 — 4), не должен быть длинным и путь до удаленного сервера.
Такова идейная основа механизма аутентификации, принятого в Kerberos. Следует отметить, что, помимо изложенных, сервер Kerberos предоставляет много дополнительных возможностей. Так, на самом деле время жизни билета задается как пара (начальное время, конечное время).
В результате можно получать билеты “на потом”, например, для пакетных заданий, выполняющихся ночью. Далее, имеется механизм билетов с правом передачи, что позволяет серверам выполнять определенные действия от имени обратившихся к ним клиентов (скажем, серверу печати осуществлять доступ к файлам пользователя). Есть и другие средства, на которых, однако, мы сейчас останавливаться не будем.
На реализацию и использование Kerberos можно смотреть с разных точек зрения. Пользователь видит Kerberos как набор команд (например, kinit — начало Kerberos-сеанса, kdestroy – разрушение Kerberos-билетов и окончание сеанса, klist — выдача текущего списка билетов, kpasswd — смена Kerberos-пароля и т.п.) или не видит его вообще, если соответствующие вызовы встроены в утилиты и команды операционной системы, такие как login, logout, passwd.
Для программиста Kerberos представляет собой набор библиотек, весьма разумно структурированных, так что можно легко заменять разные компоненты, например, криптографические. Две функции основной библиотеки — krb_mk_req и krb_rd_req, позволяют, соответственно, построить аутентификационный запрос к серверу и обработать его.
При этом прикладной программист избавляется от рутинных аспектов общения с Kerberos. “Керберизация” приложений, то есть встраивание в них средств проверки подлинности, в значительной степени сводится к добавлению вызовов упомянутых функций, что, естественно, не слишком сложно.
С точки зрения системного администратора Kerberos — это набор административных средств конфигурирования, регистрации субъектов, работы с базой данных секретных ключей.
В последующих разделах Kerberos рассматривается более формально. Основой изложения является официальный документ сообщества Internet — RFC 1510 “The Kerberos Network Authentication Service (V5)”.
Представление некоторых объектов интерфейса безопасности в среде языка c
Представление средствами языка C объектов, фигурирующих в обобщенном интерфейсе безопасности GSS-API, по большей части довольно очевидно (или не может быть стандартизовано, так как зависит от специфики механизма безопасности).
Прежде всего, вводится тип OM_uint32, соответствующий 32-битным беззнаковым целым значениям. Большинство структурных значений представляется с помощью указателя на дескриптор).
Тип gss_buffer_t используется при задании составных аргументов — имен, дескрипторов, токенов, сообщений и т.п.
Идентификаторы объектов представляются следующим образом:
Указатели elements ссылаются на начало представления идентификаторов, то есть на последовательности байт, устроенных в соответствии с базовыми правилами ASN.1.
Наборы объектных идентификаторов представлены на Рис. 2.
Рисунок 2. Наборы объектных идентификаторов
Вводятся и некоторые другие типы, уточняющие представление структурированных значений.
Описание функции GSS_ Init_sec_context на языке C показано на Рис. 3.
Рисунок 3. Описание функции GSS_ Init_sec_context
Отметим, что параметр context_handle является здесь одновременно входным и выходным, а основной код завершения возвращается как результат функции.
На Рис. 4 приведено определение еще нескольких величин.
Рисунок 4. Дополнительные определения
Разумеется, есть еще много аспектов, оговоренных в документе [3], например, кто и когда отводит память под объекты и под дескрипторы, и каким образом эту память можно освобождать. Мы, однако, не будем на этом останавливаться.
Примечания
- ↑Kerberos [Электронный ресурс] : Материал из http://cryptowiki.net: — Режим доступа: http://cryptowiki.net/index.php?title=Керберос
- ↑Kerberos [Электронный ресурс] : Материал из https://www.freebsd.org: — Режим доступа: https://www.freebsd.org/doc/ru/books/handbook/kerberos5.html
- ↑Kerberos [Электронный ресурс] : Материал из https://habrahabr.ru/: — Режим доступа: https://habrahabr.ru/company/aktiv-company/blog/170829/
- ↑Kerberos [Электронный ресурс] : Материал из http://itband.ru/: — Режим доступа: http://itband.ru/2022/12/kerberos1/
- ↑Kerberos [Электронный ресурс] : Материал из Википедии: — Режим доступа: https://ru.wikipedia.org/wiki/Kerberos
- ↑Kerberos [Литрература] : Шнайер Б. Глава 3. Основные протоколы. Протокол Kerberos // Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си = Applied Cryptography. Protocols, Algorithms and Source Code in C. — М.: Триумф, 2002. — С. 81. — 816 с. — 3000 экз. — ISBN 5-89392-055-4.
- ↑Kerberos [Электронный ресурс] : Материал из Википедии: — Режим доступа: https://ru.wikipedia.org/wiki/Kerberos
- ↑Kerberos [Электронный ресурс] : Материал из http://www.rhd.ru: — Режим доступа: http://www.rhd.ru/docs/manuals/enterprise/RHEL-AS-2.1-Manual/custom-guide/s1-kerberos-clients.html
- ↑Kerberos [Электронный ресурс] : Материал из Википедии — свободной энциклопедии: — Режим доступа:https://ru.wikipedia.org/wiki/Kerberos
- ↑Kerberos [Электронный ресурс] : Материал из https://habrahabr.ru/: — Режим доступа: https://habrahabr.ru/company/aktiv-company/blog/170829/
Форматы данных в системе kerberos
Опишем форматы двух важнейших объектов системы Kerberos – билета и аутентификатора. Описание дается в нотации ASN.1. Понимание этих форматов позволит лучше прочувствовать тонкости механизма аутентификации. Рис. 7 содержит описание структуры билета, а Рис. 6 — описание шифруемой (секретным ключом сервера) части билета.
Рисунок 6. Описание структуры билета
Рисунок 7. описание шифруемой части билета
Поясним смысл компонентов билета.
tkt-vno. номер версии формата билета. Данный документ описывает версию 5.
realm. область управления, выдавшая билет, и, одновременно, область, содержащая сервер.
sname. имя сервера, к которому выдан данный билет.
enc-part. зашифрованная часть билета.
flags. битовая шкала флагов.
key. сеансовый ключ, выданный Kerberos для связи между клиентом и сервером.
crealm. область управления, в которой зарегистрирован клиент, и, одновременно, область, в которой происходила начальная проверка подлинности.
cname. имя клиента.
transited. список промежуточных областей управления, участвовавших в аутентификации клиента.
authtime. время выдачи первоначального билета, “наследником”
starttime. время, отмечающее начало срока годности билета. Если данное поле не задано, используется значение authtime.
endtime. время, отмечающее окончание срока годности билета. В принципе конкретные серверы могут накладывать свои, более жесткие, ограничения на время жизни билета.
renew-till. время, после которого даже обновляемый билет становится негодным.
caddr. список сетевых адресов, откуда билет может быть использован. Если список пуст, билет можно использовать откуда угодно. Данный список затрудняет использование злоумышленником украденного билета.
authorization-data. авторизационная информация, передаваемая владельцем билета серверу приложений. Предполагается, что это поле содержит имена обслуживаемых объектов и права доступа к ним. Поле authorization-data позволяет выдать доверенность на совершение определенных действий.
Например, клиент, желающий напечатать файл, может передать серверу печати доверенность на чтение файла. Содержательная трактовка поля авторизации находится вне компетенции Kerberos; последний лишь переносит туда информацию, содержащуюся в запросе клиента на билет к серверу приложений.
Аутентификатор — это запись, посылаемая серверу вместе с билетом, удостоверяющая знание клиентом ключа шифрования, содержащегося в билете, помогающая серверу обнаружить воспроизведение (дублирование) информации и позволяющая выбрать “настоящий сеансовый ключ” для обслуживания конкретного сеанса связи между клиентом и сервером. Аутентификатор шифруется сеансовым ключом, копия которого находится в билете (Рис. 8).
Рисунок 8. Аутентификатор
Gss_init_sec_context — инициация контекста безопасности
Функция GSS_Init_sec_ context предназначена для инициации контекста безопасности, формируемого общающимися партнерами, и для генерации токена, пересылка которого позволит удаленному партнеру выполнить свою часть работы по формированию контекста.
Входные параметры:
- claimant_cred_handle: CREDENTIAL_HANDLE {дескриптор удостоверения инициатора взаимодействия; NULL означает подразумеваемое удостоверение}
- input_context_handle: CONTEXT_HANDLE {дескриптор формируемого контекста; 0 означает, что формирование только начинается}
- targ_name: INTERNAL_NAME {имя партнера по общению}
- mech_type: OBJECT_IDENTIFIER {механизм безопасности, который должен поддерживать формируемый контекст; NULL означает подразумеваемый механизм}
- deleg_rec_flag: BOOLEAN {запрашивается ли делегирование полномочий}
- mutual_req_flag: BOOLEAN {запрашивается ли взаимная аутентификация}
- replay_det_req_flag: BOOLEAN {запрашивается ли выявление продублированных токенов}
- sequence_req_flag: BOOLEAN {запрашивается ли контроль целостности последовательности сообщений}
- anon_req_flag: BOOLEAN {запрашивается ли анонимный контекст}
- lifetime_req: INTEGER {запрашиваемый срок годности контекста в секундах; 0 означает подразумеваемый срок}
- chan_bindings: OCTET_ STRING {набор каналов, с которым связывается контекст}
- input_token: OCTET_ STRING {токен, полученный от партнера в результате предшествующих действий по формированию контекста; NULL означает, что формирование только начинается}
Выходные параметры:
- major_status: INTEGER
- minor_status: INTEGER
- output_context_handle: CONTEXT_HANDLE {дескриптор формируемого контекста}
- actual_mech_type: OBJECT_ IDENTIFIER {реальный механизм, поддерживающий формируемый контекст — значение, заведомо отличное от NULL}
- output_token: OCTET_ STRING {выходной токен, который нужно переслать партнеру, чтобы тот мог продолжить формирование контекста; NULL означает, что больше ничего пересылать не нужно}
- deleg_state: BOOLEAN {обеспечивается ли передача полномочий}
- mutual_state: BOOLEAN {обеспечивается ли взаимная аутентификация}
- replay_det_state: BOOLEAN {обеспечивается ли выявление продублированных токенов}
- sequence_state: BOOLEAN {обеспечивается ли контроль целостности последовательности сообщений}
- anon_state: BOOLEAN {обеспечивается ли анонимность контекста}
- trans_state: BOOLEAN {возможен ли экспорт контекста}
- prot_ready_state: BOOLEAN {обеспечивается ли защита сообщений, когда формирование контекста еще не завершено}
- conf_avail: BOOLEAN {обеспечивается ли шифрование сообщений}
- integ_avail: BOOLEAN {обеспечивается ли контроль целостности сообщений}
- lifetime_rec: INTEGER {срок годности контекста в секундах}
Возможные значения основного кода завершения:
- GSS_S_COMPLETE – контекст успешно инициализирован, а выходной токен содержит достаточно информации для завершения формирования контекста партнером и для начала защищенного обмена сообщениями.
- GSS_S_CONTINUE_NEEDED — сгенерированный выходной токен нужно переслать партнеру. Тот должен прислать ответ, который послужит аргументом input_token для последующего ассоциированного вызова функции GSS_Init_sec_context. Пока не будет выдан код завершения GSS_S_COMPLETE, контекст безопасности нельзя считать сформированным.
- GSS_S_DEFECTIVE_TOKEN — обнаружено нарушение целостности входного токена input_token. Формирование контекста не может быть продолжено.
- GSS_S_DEFECTIVE_CREDENTIAL — обнаружено нарушение целостности удостоверения, заданного аргументом claimant_cred_handle. Формирование контекста не может быть продолжено.
- GSS_S_BAD_SIG — входной токен input_toke содержит некорректную подпись. Формирование контекста не может быть продолжено.
- GSS_S_NO_CRED — контекст не может быть сформирован либо по причине некорректности значения claimant_cred_handle, либо из-за того, что удостоверение не предназначено для инициации контекста, либо из-за отсутствия прав на использование данного удостоверения.
- GSS_S_CREDENTIALS_EXPIRED — удостоверение просрочено. Формирование контекста не может быть продолжено.
- GSS_S_BAD_BINDINGS — обнаружено несоответствие между информацией о наборе каналов, заданной аргументом chan_bindings, и аналогичной информацией, извлеченной из входного токена input_token. Несоответствие означает, что партнеры не могут договориться о привязке контекста к каналам. Формирование контекста не может быть продолжено.
- GSS_S_NO_CONTEXT — значение параметра input_ context_handle не является корректным дескриптором контекста, в то время как оно должно быть таковым (выполняется не первый из ассоциированных вызовов GSS_ Init_sec_context). Формирование контекста не может быть продолжено.
- GSS_S_BAD_NAMETYPE — запрашиваемое имя не удается проинтерпретировать. Формирование контекста не может быть продолжено.
- GSS_S_BAD_NAME — некорректное имя. Формирование контекста не может быть продолжено.
- GSS_S_BAD_MECH — запрашивается неподдерживаемый механизм безопасности. Формирование контекста не может быть продолжено.
- GSS_S_FAILURE — формирование контекста не может быть продолжено по причинам, не специфицируемым на уровне GSS-API.
Вызов функции GSS_ Init_sec_context может привести к временной блокировке обратившегося к ней процесса, если для генерации контекста и получения выходного токена служба безопасности должна воспользоваться услугами сервера аутентификации, службы директорий или иного удаленного сервера.
Обычно для инициации контекста достаточно одного обращения к функции GSS_Init_ sec_context. Если это не так (например, из-за требования взаимной аутентификации), то для всех последующих обращений значение параметра claimant_cred_ handle должно оставаться неизменным. Это значение позволяет связать в цепочку ассоциированные вызовы GSS_Init_sec_context.
При первом обращении к GSS_Init_sec_context значение параметра input_context_handle должно равняться 0. При последующих вызовах его следует устанавливать равным output_context_handle (ассоциированные вызовы Goutput_context_handle, начиная со второго, не меняют дескриптор контекста безопасности).
Инициатор, посредством входных флагов, может запросить у службы безопасности предоставление дополнительных услуг: возможности делегирования прав доступа (флаг deleg_rec_flag), организации взаимной аутентификации (mutual_req_flag), контроля целостности последовательности сообщений (флаги replay_det_ req_flag и sequence_req_flag), сохранения инкогнито инициатора контекста (anon_req_flag).
Соответствующие выходные флаги показывают, в состоянии ли служба безопасности предоставить запрашиваемые услуги. Кроме того, еще два выходных флага, integ_avail и conf_avail, показывают, поддерживается ли службой безопасности контроль целостности сообщений и их конфиденциальность (в принципе можно представить себе механизм, обеспечивающий только аутентификацию партнеров).
Отказ в поддержке некоторых запрашиваемых услуг не обязательно должен вести к отказу от формирования контекста безопасности. Мобильное приложение может принять те или иные меры (например, проинформировать пользователя о достижимом уровне защиты, взять на себя шифрование и т.п.), позволяющие продолжить работу.