Материал Аудит. воссоздание официальных звонков от банковских и других ivr (англ. Interactive Voice Response) систем 40, с. 175
 Скачать 3.81 Mb.
|
|
Тема 6. Сервер аутентификации KERBEROS Введение Идентификация и проверка подлинности пользователей (аутентификация) — это основное средство защиты информационных систем от одной из главных угроз — постороннего вмешательства. Если у злоумышленника нет средств для нелегального доступа, возможности информационного нападения существенно уменьшаются. Под идентификацией мы будем понимать процедуру, посредством которой пользователь или компьютерный процесс сообщает сведения о себе (называет себя). Проверка подлинности, или аутентификация — это процедура проверки достоверности предъявленных данных. Современные информационные системы представляют собой совокупность разнородных (реализованных на различных аппаратно-программных платформах), территориально разнесенных компонентов. Как правило, большинству пользователей требуется доступ ко многим сервисам, предоставляемым системами. В то же время ни им, ни системным администраторам не хочется размножать регистрационную информацию и особым образом входить в каждый сервер. В соответствии с технологией клиент/сервер, выход заключается в создании специального сервера проверки подлинности, услугами которого будут пользоваться другие серверы и клиенты информационной системы. На сегодняшний день на роль фактического стандарта сервера аутентификации имеется только один реальный претендент — Kerberos, продукт, разработанный в середине 1980-х годов в Массачусетском технологическом институте и претерпевший с тех пор ряд принципиальных изменений. Клиентские компоненты Kerberos присутствуют в большинстве современных операционных систем; в такие системы, как Solaris, Kerberos проник весьма глубоко, а концерн OSF сделал Kerberos частью своей распределенной компьютерной среды (DCE). Выделение особого сервера аутентификации позволяет реализовывать собственные прикладные системы со своей системой понятий, но со стандартной процедурой проверки подлинности, что существенно облегчает управление правами доступа пользователей. Kerberos (точнее, его версия, реализованная в MIT) является свободно распространяемым программным продуктом, доступным в исходных текстах (кроме, быть может, криптографических компонентов). Таким образом, в руках разработчиков прикладных систем и лиц, отвечающих за информационную безопасность, оказывается не "черный", а "прозрачный ящик", функционирующий понятным и проверяемым образом и доступный для "подгонки" с учетом нужд конкретной организации. Теоретический материал От чего защищает и от чего не защищает Kerberos Kerberos предоставляет средства проверки подлинности субъектов, работающих в открытой (незащищенной) сети, то есть сети, не исключающей возможности перехвата, модификации и пополнения пересылаемой информации. Kerberos не полагается на средства аутентификации, реализованные в операционных системах сетевых компьютеров, на подлинность сетевых адресов, на физическую защищенность сетевых компьютеров (кроме тех, на которых работает сервер Kerberos). С точки зрения реализации Kerberos — это один или несколько серверов проверки подлинности, функционирующих на физически защищенных компьютерах. Серверы поддерживают базу данных субъектов и их секретных ключей. В данном документе не рассматривается протокол администрирования, позволяющий безопасным образом изменять базу данных субъектов, а также протокол репликации этой базы. Kerberos не защищает от: атак на доступность. Отражение подобных атак (как и реакция на "нормальные" отказы) возлагается на пользователей и администраторов. кражи секретных ключей. Субъекты должны сами заботиться о секретности своих ключей. угадывания паролей. Плохо выбранный пароль может не устоять против подбора с помощью словаря, вычисления по паролю секретного ключа с последующей попыткой расшифровать полученную от Kerberos информацию. Соответствующим образом измененная программа ввода пользовательского пароля ("троянский конь") позволит злоумышленнику узнать пароли многих пользователей. Таким образом, Kerberos все же предполагает некоторый уровень защищенности обслуживаемых компьютеров. повторного использования идентификаторов субъектов. В принципе возможна ситуация, когда новый субъект Kerberos получит тот же идентификатор, что был у ранее выбывшего субъекта. Возможно, что этот идентификатор остался в списках управления доступом какой-либо системы в сети. В таком случае новый субъект унаследует права доступа выбывшего. рассогласования часов на компьютерах. Kerberos полагается на приблизительную согласованность часов сетевых компьютеров. Подобное предположение упрощает обнаружение воспроизведения (дублирования) информации. Допустимая погрешность часов может устанавливаться индивидуально для каждого сервера. Если синхронизация часов выполняется сетевыми средствами, соответствующий протокол должен сам заботиться о безопасности. Неформальное изложение возможностей Kerberos Система Kerberos предназначена для решения следующей задачи. Имеется открытая (незащищенная) сеть, в узлах которой сосредоточены субъекты — пользователи, а также клиентские и серверные программные системы. Каждый субъект обладает секретным ключом. Чтобы субъект C мог доказать свою подлинность субъекту S (без этого S не станет обслуживать C), он должен не только назвать себя, но и продемонстрировать знание своего секретного ключа. C не может просто послать S свой секретный ключ, во-первых, потому, что сеть открыта (доступна для пассивного и активного прослушивания), а, во-вторых, потому, что S не знает (и не должен) знать секретный ключ C. Требуется менее прямолинейный способ демонстрации знания секретного ключа. Система Kerberos представляет собой надежную третью сторону (то есть сторону, которой доверяют все), владеющую секретными ключами обслуживаемых субъектов и помогающую им в попарной проверке подлинности. Чтобы с помощью Kerberos получить доступ к S (обычно это сервер), C (как правило — клиент) посылает Kerberos'у запрос, содержащий сведения о нем (клиенте) и о запрашиваемой услуге. В ответ Kerberos возвращает две порции информации: так называемый билет, зашифрованный секретным ключом сервера, и копию части информации из билета, зашифрованную секретным ключом клиента. Клиент должен расшифровать вторую порцию данных и переслать ее вместе с билетом серверу. Сервер, расшифровав билет, может сравнить его (билета) содержимое с дополнительной информацией, присланной клиентом. Совпадение свидетельствует о том, что клиент смог расшифровать предназначенные ему данные (ведь содержимое билета никому, кроме сервера и Kerberos, недоступно), то есть продемонстрировал знание своего секретного ключа. Значит, клиент — именно тот субъект, за кого себя выдает. Подчеркнем, что секретные ключи в процессе проверки подлинности не передавались по сети (даже в зашифрованном виде) — они только использовались для шифрования. Как организован первоначальный обмен ключами между Kerberos и субъектами и как субъекты хранят свои секретные ключи — вопрос отдельный. Проиллюстрируем описанную процедуру Рис. 10.  Рис. 10. Проверка сервером S подлинности клиента C (вариант 1). Здесь: c и s — сведения (например, имя), соответственно, о клиенте и сервере, d1 и d2 — дополнительная (по отношению к билету) информация. Tc.s — билет для клиента C на обслуживание у сервера S, Kc и Ks — секретные ключи клиента и сервера, {info}K — информация info, зашифрованная ключом K. Изложенный вариант 1 — крайне упрощенная версия реальной процедуры проверки подлинности. Прежде всего, необходимо уточнить структуру пересылаемых запросов и возвращаемых ответов. И билет, и вторая порция информации, предоставляемая со стороны Kerberos, содержат случайный ключ, пригодный для шифрования сообщений, пересылаемых между клиентом и сервером. Этот ключ называется сеансовым и представляет собой общую секретную информацию, разделяемую C и S. Появление подобной общей информации и возможность организации конфиденциального взаимодействия — важный побочный продукт аутентификации средствами Kerberos. Билет, который выдает Kerberos, имеет ограниченный срок годности. Естественно распространить этот срок и на сеансовый ключ. Когда срок годности истекает, необходимо проведение повторной проверки подлинности. Продолжительность стандартного срока годности зависит от политики безопасности, проводимой организацией. Типичный срок годности — 8 часов. Вполне вероятно, что клиент C захочет убедиться в подлинности обслуживающего его сервера S. Чтобы это было возможным, клиент шифрует дополнительную информацию, передаваемую серверу, с помощью сеансового ключа. Сервер может узнать сеансовый ключ, только расшифровав билет. Если это случится и сервер вернет клиенту свидетельство того, что он сумел прочитать дополнительную информацию, C вправе считать подлинность сервера S установленной. Далее, необходимо защитить информацию, пересылаемую по сети, от воспроизведения. Если этого не сделать, злоумышленник сможет послать серверу дубликаты билета и дополнительной информации и успешно выдать себя за "второго C". Стандартный способ защиты от воспроизведения — включение в нее временных штампов и/или так называемых одноразовых номеров, позволяющих удостовериться в "свежести" сообщений и в их неповторяемости (и, более того, в целостности последовательности сообщений). Одноразовые номера позволяют также ассоциировать ответы с предыдущими запросами. Отобразим упомянутые уточнения на новом рисунке (Рис. 11).  Рис. 11. Взаимная проверка клиентом C и сервером S подлинности другдруга (вариант 2). Здесь: timeexp — срок годности билета, n — одноразовый номер, Kc.s — сеансовый ключ, ts — временной штамп, ck — контрольная сумма. Отдельного пояснения заслуживает обозначение 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 на основании "билета на билеты". В результате схема получения доступа к серверу приобретает вид, изображенный на Рис. 12.  Рис.12. Взаимная проверка клиентом C и сервером S подлинности друг друга (вариант 3). Здесь: Ac — аутентификатор клиента. Таким образом, секретный ключ нужен клиенту только на короткое время для получения "билета на билеты". В дальнейшем используется сеансовый ключ, разделяемый клиентом и сервером выдачи билетов. Компрометация сеансового ключа, имеющего ограниченный срок годности, — вещь существенно менее опасная, чем раскрытие секретного ключа. Любопытно отметить, что AS, вопреки своему названию, не проверяет подлинности обратившихся к нему субъектов. Билет на билеты может получить кто угодно, в том числе и злоумышленник, но воспользоваться этим билетом он сможет, только если знает секретный ключ субъекта, от имени которого он выступает. Отметим также, что если для программных субъектов (клиентов и серверов) способ хранения секретного ключа не определен, то для пользователей специфицируется алгоритм преобразования пароля в ключ. Иными словами, пользователю достаточно помнить только свой пароль. Каждый сервер Kerberos обслуживает определенную область управления. До сих пор мы рассматривали случай, когда клиент и сервер находились в пределах одной области и взаимодействовали посредством локального Kerberos. Теперь обратимся к ситуации, когда клиент и сервер зарегистрированы в разных областях. Чтобы субъекты из разных областей управления могли общаться друг с другом, между областями должно быть заключено соглашение, а серверы Kerberos должны обменяться секретными ключами. (Ключи могут быть разными для различных общающихся пар серверов Kerberos.) Поскольку между областями управления Kerberos существуют стандартные иерархические отношения, каждой области достаточно заключить соглашение и обменяться ключами с родителем и всеми потомками. В принципе возможно заключение соглашения между двумя произвольными областями, субъекты которых активно общаются друг с другом. Рис. 13 иллюстрирует отношения между областями управления.  Рис.13. Отношения между областями управления Kerberos. При наличии договорных отношений локальный сервер выдачи билетов может выдать билет к удаленному TGS, который, в свою очередь, выдаст билет к удаленному серверу. Последовательность обмена сообщениями для этого случая показана на Рис. 14.  Рис. 14. Взаимная проверка клиентом C и удаленным сервером S-rem подлинности друг друга (вариант 4). В более общем случае клиенту придется пройти через несколько промежуточных серверов выдачи билетов. Впрочем, поскольку глубина вложенности областей управления обычно невелика (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)". Флаги, используемые в билетах Каждый Kerberos-билет содержит набор флагов. Большинство из них запрашивается клиентом перед получением билета. Некоторые флаги автоматические устанавливает и сбрасывает сам Kerberos. Рассмотрение флагов и способов их использования позволяет в полном объеме продемонстрировать аутентификационные возможности сервера Kerberos. Напомним, что клиент получает билеты, зашифрованные секретными ключами серверов (это может быть сервер выдачи "билетов на билеты" или один из прикладных серверов). Тем самым клиент лишен возможности изменять содержимое билетов. В частности, он не может устанавливать и сбрасывать флаги — эту роль целиком берет на себя Kerberos. Начальные билеты Флаг INITIAL указывает на то, что билет выдан сервером начальной аутентификации (AS). Серверы приложений, которым нужно знать секретный ключ пользователя (пример — программа изменения пароля), могут принимать билеты только с установленным флагом INITIAL как свидетельство недавнего использования именно секретного, а не сеансового, ключа. Два дополнительных флага, PRE-AUTHENT и HW-AUTHENT, могут нести дополнительную информацию о начальной аутентификации, независимо от того, кто выдал данный билет — AS или TGS. Негодные билеты Флаг INVALID свидетельствует о том, что билет негоден. Серверы приложений должны отвергать билеты с этим флагом. Обычно флагом INVALID помечаются предварительные билеты, предназначенные для использования в будущем. Чтобы предварительный билет стал годным, его нужно зарегистрировать, направив в TGS запрос с опцией VALIDATE. Регистрация пройдет успешно только после наступления начального времени годности билета. Процедура регистрации позволяет выявлять (и отвергать) украденные предварительные билеты. Обновляемые билеты Билеты с длительным сроком годности удобны, но небезопасны, поскольку кража содержащейся в них информации открывает злоумышленнику доступ к соответствующим серверам также на длительное время. С другой стороны, использование краткосрочных билетов заставляет постоянно обращаться к секретному ключу, что представляет еще большую опасность. Обновляемые билеты позволяют смягчить последствия кражи информации. Они имеют два срока годности — промежуточный и окончательный. Клиент должен периодически, до окончания промежуточного срока, представлять обновляемый билет в TGS с опцией RENEW. В ответ TGS возвращает новый билет с другим сеансовым ключом и более поздним промежуточным сроком годности. Все остальные поля переносятся из старого билета без изменений. Подобная периодическая перерегистрация в принципе позволяет TGS выявлять украденные билеты и отвергать их. В результате потенциальное время жизни нелегальных билетов уменьшается. Обычно флаг RENEWABLE интерпретируется только TGS, однако некоторые особенно осторожные серверы могут отвергать билеты с этим флагом. Флаг RENEWABLE устанавливается в билете лишь по явному запросу клиента к серверу начальной аутентификации (AS). Предварительные билеты Иногда нужны билеты, которые будут использоваться спустя довольно долгое время после выдачи. Например, от момента порождения пакетного задания до начала выполнения может проходить несколько часов. Поскольку держать годные билеты в пакетной очереди рискованно, Kerberos предлагает механизм предварительных билетов, получаемых в момент порождения задания, но "дремлющих" до момента активации и перерегистрации в TGS. Флаг MAY-POSTDATE обычно интерпретируется только TGS в "билетах на билеты" и устанавливается лишь по явному запросу клиента к серверу начальной аутентификации (AS). По "билету на билеты" с флагом MAY-POSTDATE TGS выдает билет (к серверу) с флагом POSTDATED. Сервер может проверить, как давно был выдан предварительный билет и, возможно, отказать клиенту в обслуживании. Более того, билет с флагом POSTDATED первоначально содержит и флаг INVALID, так что клиент перед использованием должен перерегистрировать билет в TGS. Доверенности Когда возникает необходимость позволить серверу выполнить некоторые действия от имени клиента (например, получить доступ к файлам для их печати), можно воспользоваться имеющимся в Kerberos механизмом доверенностей. Флаг PROXIABLE, установленный в "билете на билеты" (это происходит по умолчанию), дает право TGS выдать новый билет (но не "билет на билеты") с другим сетевым адресом. В новом билете устанавливается флаг PROXY. Клиент может передать серверу новый билет в качестве доверенности. Чтобы затруднить использование украденных удостоверений, Kerberos-билеты обычно разрешается использовать только субъектам с сетевыми адресами, явно указанными в билете. В принципе сетевые адреса в билете можно не указывать, но это не рекомендуется. Вот почему клиент должен передать серверу доверенность — билет с его (сервера) сетевым адресом. Билеты с правом передачи Билеты с правом передачи позволяют развить механизм доверенностей и передавать серверу права на совершение любых действий от имени клиента. Подобное сильнодействующее средство полезно, например, когда пользователь, войдя в удаленную систему, хочет, чтобы проверка подлинности проходила так же, как и в случае локального входа. Флаг FORWARDABLE трактуется почти так же, как PROXIABLE, однако дает право на получение новых "билетов на билеты" с другими сетевыми адресами и устанавливается лишь по явному запросу пользователя к серверу начальной аутентификации (AS) при получении первоначального "билета на билеты". В принципе пользователь может получить новый "билет на билеты" с другими сетевыми адресами и без флага FORWARDABLE, обратившись непосредственно к AS, но тогда ему придется вводить свой пароль. Флаг FORWARDED устанавливается в новом билете по явному запросу пользователя, когда он представляет TGS билет с флагом FORWARDABLE, задает опцию FORWARDED и указывает новый список сетевых адресов. Флаг FORWARDED наследуется при выдаче новых билетов. Форматы данных в системе Kerberos Опишем форматы двух важнейших объектов системы Kerberos - билета и аутентификатора. Описание дается в нотации ASN.1. Понимание этих форматов позволит лучше прочувствовать тонкости механизма аутентификации. Рис.15 содержит описание структуры билета, а Рис. 16 - описание шифруемой (секретным ключом сервера) части билета. Листинг 1
Рис. 15. Описание структуры билета Листинг 2
Рис. 16. Описание шифруемой части билета Поясним смысл компонентов билета. 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; последний лишь переносит туда информацию, содержащуюся в запросе клиента на билет к серверу приложений. Аутентификатор — это запись, посылаемая серверу вместе с билетом, удостоверяющая знание клиентом ключа шифрования, содержащегося в билете, помогающая серверу обнаружить воспроизведение (дублирование) информации и позволяющая выбрать "настоящий сеансовый ключ" для обслуживания конкретного сеанса связи между клиентом и сервером. Аутентификатор шифруется сеансовым ключом, копия которого находится в билете (Рис. 17). Листинг 3
Рис. 17. Аутентификатор Комментарии к листингу: authenticator-vno. номер версии формата аутентификатора (5). crealm и cname. то же, что и для билета. cksum. контрольная сумма прикладных данных, передаваемых серверу. cusec. микросекундная часть временного штампа клиента. ctime. основная часть временного штампа клиента. subkey. выбранный клиентом ключ для защиты конкретного сеанса связи. Если это поле не задано, будет использоваться сеансовый ключ. seq-number. начальный номер последовательности сообщений. Механизм номеров используется для контроля целостности последовательности и, в частности, для защиты от дублирования. Начальный номер рекомендуется выбирать случайным образом, а последующие номера не использовать дважды даже в разных сеансах. authorization-data. то же, что и для билета (позволяет уточнить информацию, переданную в билете). Типы пересылаемых сообщений Обмен с сервером начальной аутентификации Таблица 12. Обмен с сервером начальной аутентификации  Общение с сервером начальной аутентификации обычно инициируется клиентом, желающим получить удостоверение к определенному серверу, но не имеющим пока других удостоверений. Для шифровки и расшифровки используется секретный ключ клиента. Как правило, данный обмен происходит при входе в систему, для получения удостоверения к серверу выдачи билетов. Кроме того, общение с сервером начальной аутентификации используется для получения удостоверения к серверам, требующим знания именно секретного ключа (пример - сервер смены пароля). В своем запросе (KRB_AS_REQ) клиент посылает открытым текстом свое имя и имя сервера, к которому он хочет получить удостоверение. Ответ, KRB_AS_REP, содержит билет, который клиент должен будет представить серверу, и сеансовый ключ для совместного использования клиентом и сервером. Билет шифруется секретным ключом сервера, сеансовый ключ и дополнительная информация — секретным ключом клиента. Сообщение KRB_AS_ REP содержит данные, позволяющие связать его с предыдущим запросом (KRB_AS_REQ) и обнаружить дублирование сообщений. В случае какой-либо ошибки возвращается сообщение KRB_ERROR, которое не шифруется. Сервер аутентификации не делает попыток убедиться в подлинности обратившегося к нему субъекта. Просто он возвращает информацию, воспользоваться которой может лишь тот, кто знает секретный ключ субъекта. Обмен с сервером выдачи билетов Таблица 13. Обмен с сервером выдачи билетов  Обмен между клиентом и сервером выдачи билетов инициируется клиентом, когда тот хочет получить удостоверение к определенному серверу (возможно, зарегистрированному в удаленной области управления), обновить или зарегистрировать существующий билет или получить билет с доверенностью. В первом случае клиент должен располагать предварительно полученным от сервера начальной аутентификации билетом к TGS. Формат сообщений при обмене с сервером выдачи билетов почти тот же, что и для сервера начальной аутентификации. Основное отличие состоит в том, что для шифровки и расшифровки используется сеансовый ключ. Запрос (KRB_TGS_REQ) состоит из информации, подтверждающей подлинность клиента, и заявки на удостоверение. Ответ (KRB_TGS_REP) содержит запрашиваемое удостоверение, зашифрованное сеансовым ключом, и данные, позволяющие обнаружить дублирование сообщений и связать ответ с запросом. Аутентификационный обмен клиент/сервер Таблица 14. Аутентификационный обмен клиент/сервер  Данный обмен используется сетевыми приложениями для взаимной проверки подлинности. Клиент должен располагать предварительно полученным удостоверением к серверу. Клиент передает серверу билет, аутентификатор зашифрованный сеансовым ключом) и некоторую дополнительную учетную информацию. Сервер в ответ (если этот ответ требуется) возвращает только аутентификатор, зашифрованный тем же сеансовым ключом. Защищенные сообщения Сообщения типа KRB_SAFE могут использоваться партнерами по общению, желающими контролировать целостность передаваемой информации. Контроль целостности достигается за счет включения в сообщение криптографической контрольной суммы. Используется последний субсеансовый или сеансовый ключ. Конфиденциальные сообщения Сообщения типа KRB_PRIV могут использоваться партнерами по общению, желающими защитить данные от нелегального прочтения и контролировать их целостность. Цель достигается криптографическими методами. Пересылка удостоверений Сообщения типа KRB_CRED используются для пересылки удостоверений с одного хоста на другой. В сообщение входят билет и зашифрованные данные, содержащие сеансовый ключ и другую ассоциированную с билетом информацию. База данных Kerberos Сервер Kerberos должен иметь доступ к базе данных, содержащей идентификаторы и секретные ключи субъектов. Записи в этой базе должны содержать по крайней мере информацию, показанную в Таб. 15. Таблица 15. Обязательные поля базы данных Kerberos  Секретные ключи субъектов могут шифроваться "мастер-ключом" Kerberos. Когда секретный ключ сервера изменяется нормальным образом (то есть не в результате компрометации старого ключа), старый ключ следует сохранять до тех пор, пока остаются годными билеты, выданные с его помощью. Таким образом, возможна ситуация, когда один субъект имеет несколько активных ключей. Информация, шифруемая секретным ключом, всегда помечается версией примененного ключа, иначе правильная расшифровка может стать невозможной. Субъекту с несколькими активными ключами соответствует несколько записей в базе данных Kerberos. При выдаче билетов и в процессе начальной аутентификации всегда используется самый свежий ключ (с максимальным номером версии). В реализации Kerberos в рамках проекта Афина записи базы данных содержали дополнительные поля, показанные в Таб. 16. Таблица 16. Дополнительные поля базы данных Kerberos  Битовая шкала атрибутов может задавать характеристики билетов, допустимые для данного субъекта, или влиять на процесс преобразования пароля в секретный ключ. Если политика безопасности, проводимая организацией, требует более детальной отчетности, в записи базы данных Kerberos могут быть включены поля, помогающие отследить все операции с билетами. Правда, при этом следует учитывать необходимость частых изменений базы, что может быть нежелательным и по соображениям эффективности, и по соображениям безопасности. Также возможно, но нежелательно использование внешней по отношению к Kerberos базы данных (например, службы имен сетевой операционной системы). Предлагаемые направления развития системы Kerberos Популярность системы Kerberos довольно быстро растет, а вместе с ней растет и число предложений, направленных на развитие Kerberos. Эти предложения можно разбить на две основные группы: стандартизация программного интерфейса (как часть процесса выработки более общего прикладного программного интерфейса безопасности, затрагивающего не только аутентификацию); стандартизация использования в процедуре начальной аутентификации одноразовых паролей и/или асимметричных методов шифрования. Можно надеяться, что доступность системы Kerberos и гласность процедуры стандартизации сделают аутентификационный сервис еще более надежным и гибким. Глоссарий Авторизация. процесс определения правомочности использования клиентом определенной услуги, перечня доступных объектов, а также разрешенных видов доступа. Аутентификатор. запись, содержащая информацию, про которую можно доказать, что она была недавно сгенерирована с использованием сеансового ключа, известного только клиенту и серверу. Аутентификационный заголовок. запись, содержащая билет и удостоверение. Эта запись будет представлена серверу в процессе проверки подлинности. Аутентификационный маршрут. последовательность промежуточных областей управления, пересекаемых в процессе проверки подлинности субъектов из разных областей. Аутентификация (проверка подлинности). проверка того, что субъект является тем, за кого он себя выдает. Билет. запись, помогающая клиенту доказать серверу свою подлинность. Билет содержит сведения о клиенте, сеансовый ключ, временной штамп и другую информацию. На билете ставится печать с помощью секретного ключа сервера. Билет действителен только вместе со свежим аутентификатором. Билет на билеты (Ticket-Granting Ticket, TGT). билет к серверу выдачи билетов (Ticket-Granting Server, TGS), позволяющий получать билеты к другим серверам. Доверенность. документ, дающий предъявителю право на доступ к определенным объектам или услугам. В системе Kerberos это может быть билет, использование которого ограничено содержимым поля авторизации. К билету должен прилагаться сеансовый ключ. Идентификатор субъекта. имя, используемое для уникальной идентификации субъекта. Клиент. процесс, использующий сетевые сервисы от имени пользователя. Отметим, что в некоторых случаях сервер сам может являться клиентом некоторого другого сервера (например, сервер печати может пользоваться услугами файлового сервера). Обычный текст. исходные данные для функции шифрования или результат функции расшифровки. Расшифровка преобразует шифрованный текст в обычный. Печать. средство, позволяющее так зашифровать запись, содержащую несколько полей, что замена отдельных полей невозможна без знания ключа шифрования (иначе подмена будет обнаружена). Сеансовый ключ. временный ключ шифрования, используемый двумя субъектами. Время жизни такого ключа ограничено одним сеансом работы в системе. Секретный ключ. ключ шифрования, разделяемый субъектом и KDC и используемый длительное время. В случае, когда субъектом является пользователь, секретный ключ вычисляется по паролю. Сервер. субъект, предоставляющий ресурсы сетевым клиентам. Сервис (услуга). ресурс, предоставляемый сетевым клиентам. Зачастую может поддерживаться несколькими серверами (например, сервис удаленных файлов). Субсеансовый ключ. временный ключ шифрования, используемый двумя субъектами. Обмен субсеансовыми ключами защищается посредством сеансовых ключей. Время жизни субсеансового ключа ограничено одним сеансом общения между субъектами. Субъект. пользователь, клиент или сервер, имеющий уникальное имя и участвующий в сетевом общении. Удостоверение. совокупность билета и секретного сеансового ключа, необходимого для успешного использования билета в процессе проверки подлинности. Центр распределения билетов (Key Distribution Center, KDC). сетевой сервис, предоставляющий билеты и временные сеансовые ключи, или конкретный сервер, оказывающий данную услугу, или хост, на котором функционирует этот сервер. KDC обслуживает запросы и на начальный билет (соответствующий компонент иногда называют сервером начальной аутентификации — Authentication Server, AS), и на билеты к конкретным серверам (этот компонент именуют сервером выдачи билетов — Ticket-Granting Server, TGS). Цербер (Kerberos). не только мифологический трехголовый пес, охранявший подземное царство, но и название сервиса проверки подлинности для проекта Афина (Массачусетский технологический институт), протокол, используемый этим сервисом, а также программная реализация сервиса аутентификации. Шифрованный текст. результат функции шифрования. Шифрование преобразует обычный текст в шифрованный. Приложение 2. Николас Петрели Windows и Linux: что безопаснее? |