Обсуждение участника:NoStRaDaMuS
Материал из Википедии — свободной энциклопедии
Содержание |
[править] Добро пожаловать
Здравствуйте! От имени участников Википедии — приветствую Вас в её разделе на русском языке. Надеемся, Вы получите большое удовольствие от участия в проекте.
Ниже приведены некоторые полезные для начинающих ссылки:
- Википедия:Руководство для быстрого старта
- Википедия:Первые шаги
- Википедия:Именование статей
- Википедия:Как править статьи
- Википедия:Правила и указания
- Википедия:Изображения
Обратите внимание на основные принципы участия: правьте смело и предполагайте добрые намерения.
Одна из самых частых ошибок новичков — нарушение авторских прав. В Википедию запрещается копировать тексты без разрешения обладателя авторских прав! См. подробнее — Википедия:Авторские права.
Вы можете подписываться на страницах обсуждения, используя четыре идущих подряд знака тильды (~~~~), или нажав на соответствующую кнопку на панели инструментов. Если у Вас возникли вопросы, воспользуйтесь системой помощи. Если Вы не нашли в ней ответа на Ваш вопрос, задайте его на форуме проекта.
И ещё раз, добро пожаловать! :-) -=Altes=- 14:45, 4 октября 2006 (UTC)
Содержание:
1. Введение…………………………………………………………3 2. Модели RBAC…………………………………………………...4 3. Расширение RBAC – модель RBDM………………………….19 4. РРД в Oracle 8i………………………………………………….27 5. Особенности РРД в Oracle 9i…..………..…………….………32 6. Заключение………………………….………………………….35 7. Ссылки………………………………………………………….36
1. Введение.
Как известно, информационной безопасности и компьютерной безопасности, в частности, в наше время уделяется очень большое внимание. Создана большая нормативно-теоретическая база, формальные математические методы которой обосновывают большинство понятий информационной безопасности, формулировавшихся ранее лишь с помощью расплывчатых словесных описаний. При этом разработчики систем безопасности, реализующих различные способы и методы противодействия угрозам информации, стараются максимально облегчить работу по администрированию безопасности ответственному за нее лицу. Для этого большинством информационных систем используются стандартные подходы, ставшие результатом накопления разработчиками систем защиты опыта создания и эксплуатации подобных систем. Разработка системы защиты информации должна реализовывать какую-либо политику безопасности(набор правил, определяющих множество допустимых действий в системе), при этом должна быть реализована полная и корректная проверка ее условий. Существуют так называемые «модели» - системы, функционирующие в соответствии со строго определенным набором формализованных правил, и реализующие какую-либо политику безопасности. Данная работа будет посвящена модели ролевого разграничения доступа, сокращенно – РРД. За рубежом употребляется термин RBAC- roll-based access control. Мы рассмотрим классическую модель RBAC и ее расширение, позволяющее осуществлять иерархическое делегирование полномочий – модель RBDM(roll-based delegation model). В дальнейшем нами будет рассмотрен механизм РРД, реализованный в конкретной информационной системе. Это будет наиболее распространенная на сегодняшний день корпоративная СУБД Oracle версии 8. Также мы коснемся ее новой версии – версии 9. Нами будут рассмотрены особенности ролевого разграничения доступа этой версии, которые обеспечивают еще большее удобство администрирования системы по сравнению с предыдущими версиями данной СУБД.
2. Модель RBAC.
Основной идеей управления доступом на основе ролей (RBAC- Role Based Access Control) является то, что разрешения связаны с ролями, а каждому пользователю соответствует определенная роль. Таким образом пользователь приобретает разрешения роли. Эта идея возникла одновременно с появлением многопользовательских систем. Однако, до недавнего времени исследователи мало обращали внимание на RBAC. В этом разделе описываются цели, результаты и вопросы, которые остаются открытыми в последнем исследовании RBAC. В разделе рассмотрены четыре основных понятия. Во-первых, RBAC - это понятие, которое может быть очень простым в одном случае и достаточно сложным в другом. В связи с этим возникают проблемы в каждой конкретной модели RBAC. Мы увидим, как можно решить эту задачу при наличии семейства моделей. Во-вторых, мы обсудим, как можно используя RBAC управлять самим RBAC. Здесь представлены основные модели, разработанные для этой цели. 2.1 ВВЕДЕНИЕ.
Понятие управления доступом на основе ролей (RBAC) появилось в процессе развития многопользовательских и многозадачных систем реального времени в начале 70-х годов. Основная идея RBAC заключается в том, что разрешения связаны с ролями, а пользователям предписаны определенные роли. Роли созданы для различных функций в организации, и пользователям назначены роли, на основе их обязанностей и квалификаций. Пользователю легко может быть назначена другая роль вместо предыдущей. Ролям можно предоставлять, новые разрешения, по мере необходимости, а также роли можно лишать разрешений. Эта идея появлялась везде в той или иной форме в течение долгого времени. Все же, до недавнего времени этому уделялось мало внимания со стороны исследователей. Этот раздел описывает задачи, результаты и открытые вопросы в недавнем исследовании RBAC. В этом разделе представлены общие вопросы связанные с RBAC. В разделе 2.6 мы покажем, что RBAC - понятие простое в одних случаях и достаточно сложное в других. Поэтому трудно создать одну модель RBAC на все случаи. Вместо этого мы опишем семейство моделей, которые могут быть приспособлены к различным условиям. 2.2 Цели и задачи RBAC. Исследование, проведенное Национальным Институтом Стандартов и Технологий США (NIST) показало, что RBAC удовлетворяет многим потребностям коммерческих и правительственных организаций. В этом исследовании участвовало 28 организаций, требования к управлению доступом устанавливались, в соответствии с рядом обстоятельств, включая заказчика, акционера, конфиденциальности персональной информации, предотвращения незаконного распределение финансовых активов, предотвращения незаконного использования каналов связи, и требований к профессиональным стандартам. В результате исследования выяснилось, что во многих организациях решения относительно управления доступом основывались на должностях, которые пользователи занимали в организациях. Многие организации предпочитали централизованно управлять правами доступа, не по усмотрению системного администратора, а больше в соответствии с рекомендациями защиты организации. Исследование также показало, что организации обычно рассматривали свои потребности в управлении доступом как уникальные и считали, что доступные программные продукты управлении доступом не обладали достаточной гибкостью. Также заинтересованность в RBAC проявляется со стороны стандартизации. Роли рассматриваются как часть языка SQL3, который становится стандартом для систем управления базами данных, и поддерживаются в СУБД Oracle 7 и старше. Роли также были включены в коммерческий вариант безопасности Common Criteria . В NIST ведутся работы по разработке стандартов и руководства для RBAC. RBAC также хорошо согласовывается с развивающейся технологией и тенденциями в бизнесе. Определенные программные продукты в некоторой форме поддерживают RBAC непосредственно, а другие поддерживают близкие по смыслу механизмы, типа групп пользователей, которые также можно использовать, чтобы осуществить поддержку ролей. Многие коммерчески успешные системы управления доступом для универсальных ЭВМ применяют механизм ролей для обеспечения безопасности. Например, роль оператора имеет доступ ко всем ресурсам, но не имеет разрешения изменять права доступа, роль офицера безопасности имеет разрешение изменять права доступа, но не имеет доступ к ресурсам, а роль аудитора имеет доступ к журналу аудита. Такое использование ролей для администрирования находит применение в современных сетевых операционных системах, таких как , Novell NetWare и Microsoft Windows NT. Недавний всплеск, интереса к RBAC сконцентрировался на общей поддержке RBAC на прикладном уровне. Некоторые прикладные программы создаются с уже встроенным в код приложения RBAC. Существующие операционные системы и среды предоставляют небольшую поддержку для использования RBAC на уровне приложений. Такая поддержка начинает появляться в некоторых программных продуктах. Смысл заключается в том, чтобы определить программно-независимые средства, которые обладают достаточной гибкостью и просты в реализации, чтобы поддерживать широкий диапазон прикладных программ с минимальными изменениями. Сложные разновидности RBAC включают в себя возможность устанавливать отношения как между ролями так и между разрешениями и ролями, а также между пользователями и ролями. Например, две роли могут быть взаимоисключающими, так что пользователю не разрешено брать на себя обе роли. Между ролями также можно устанавливать отношения наследования, в результате чего одна роль наследует разрешения другой роли. Эти отношения могут использоваться, для того, чтобы формально описать политику безопасности, которая включает разделение режимов работы и разделение полномочий. Раньше, эти отношения должны были быть встроены в прикладное программное обеспечение; с RBAC, они могут быть определены всего один раз. С помощью RBAC можно заранее определить отношения типа "роль-права", что упрощает назначение пользователей на предопределенные роли. Исследование NIST, упомянутое выше показывает, что права, связанные с ролями имеют тенденцию изменяться очень медленно по сравнению с изменениями в принадлежности пользователей к определенным ролям. Исследование также показало, что желательно разрешить администраторам создавать и отменять принадлежность пользователей к существующим ролям без предоставления администраторам полномочий, создать новые роли или изменять назначенные ролям разрешения. Обычно назначение пользователям ролей будет требовать меньше технических навыков чем назначение разрешений ролям. Без RBAC, трудно определять каким пользователям какие предоставлены разрешения. Политика управления доступом реализуется в с помощью различных компонент RBAC, таких, как отношения типа "разрешение-роль", "роль-пользователь" и "роль-роль". Эти компоненты все вместе определяют, получит ли конкретный пользователь доступ к конкретному ресурсу. Компоненты RBAC могут быть сконфигурированы непосредственно владельцем системы или косвенно с помощью соответствующих административных ролей. Созданная политика есть результат точной конфигурации различных компонент RBAC в соответствии с требованиями владельца системы. Кроме того, политика управления доступом может меняться во время цикла жизни системы. Возможность изменять политику, чтобы удовлетворять изменяющимся потребностям организации является важным достоинством RBAC. Несмотря на то, что RBAC является "политико-независимым", оно непосредственно поддерживает три известных принципа безопасности: наименьшее количество привилегий, разделение полномочий и абстракцию данных. "Наименьшее количество привилегии" поддерживается, потому что RBAC может быть конфигурирован так, что роли назначаются только те права, которые требуются для задач, выполняемых членами роли. "Разделение полномочий" достигается, с помощью взаимоисключающих ролей. "Абстракция данных" поддерживается посредством абстрактных разрешений типа credit и debit для объекта учетной записи, вместо разрешений read и write, обычно поддерживаемых операционной системой. Степень, до которой поддерживается абстракция данных определяется деталями реализации. 2.3 Ограничения RBAC. Важно подчеркнуть, что RBAC не является панацеей для всех вопросов управления доступом. Более сложные формы управления доступом требуются в тех случаях, где должны контролироваться последовательности операций. RBAC не используется непосредственно для управления правами в такого рода последовательностях событий. Другие формы управления доступом могут послужить в качестве надстроек над RBAC для этих целей. Mohammed и Dilts , Sandhu [San92, San97] и Thomas и Sandhu обсуждают некоторые из этих вопросов. Мы считаем что средства управления последовательностями операций находятся вне прямых возможностей RBAC, хотя RBAC может быть основой, для создания таких средств. 2.4 Что такое - Роль? Роль должна рассматриваться как семантическая конструкция, вокруг которой сформулирована политика управления доступом. Определенная совокупность пользователей и разрешений связаны ролью. Роль более устойчива, потому что должности в организации обычно изменяются менее часто. Роли могут быть введены по нескольким причинам, включая следующие. Роль может гарантировать компетентность, для выполнения определенных работ типа врача или фармацевта. Роль может определять полномочия и ответственность, например, руководитель проекта. Полномочия и ответственность отличаются от компетентности. Человек может быть достаточно компетентным, чтобы возглавить несколько отделов, но он может быть назначен, чтобы возглавить один из них. Модели RBAC должны поддерживать все эти свойства роли. Понятие роли появилось в организационной теории задолго до появления компьютеризированных информационных систем. Даже в контексте современных информационных систем роли имеют значение вне их приложения в безопасности и управлении доступом. Поэтому для перспективы RBAC важно различать понятие и контекст роли для целей управления доступом и общий организационный контекст, в котором роли рассматриваются. Роли имеют большее значение, чем управление доступом, но мы при рассмотрении ролей не будем выходить за рамки этого контекста. Мы сосредоточимся на аспектах ролей, которые напрямую связаны с управлением доступом. Этот вопрос не затрагивает задач проектирования ролей, которые могут иметь большое значение даже при том, что роли рассматриваются в контексте управления доступом. 2.5 Роли и группы.
Часто задается вопрос: "В чем различие между ролями и группами? ". Группы пользователей как единицы управления доступом часто используются во многих системах. Главное различие между понятиями групп и ролей заключается в том что группы обычно рассматриваются как совокупность пользователей а не как совокупность разрешений. Роль является как совокупностью пользователей с одной стороны так и совокупностью прав - с другой. Роль служит посредником, который связывает эти две совокупности вместе. Рассмотрим операционную систему Unix. Группы пользователей в Unix определены в двух файлах, /etc/passwd и /etc/group. Таким образом легко определить к каким группам принадлежит конкретный пользователь. Разрешения предоставляются группам на основании битов прав, связанных с файлами и каталогами. Для того чтобы определить, какие разрешения имеет группа, требуется просмотреть всю файловую систему. Таким образом намного проще определить принадлежность к группе чем разрешения группы. Кроме того предоставление разрешений группам происходит не централизовано. По существу, владелец любого поддерева в файловой системе может предоставить разрешения на это поддерево группе (Детали зависят от варианта ОС Unix). Однако, группы в Unix можно использовать, чтобы реализовать в некоторых случаях механизм ролей, несмотря на то, что группа не совпадает с нашим пониманием роли. Рассмотрим систему, в которой требуется вдвое больше времени чтобы определить принадлежность к группе, чем определить разрешения группы. Предположим, что разрешения и состав группы может изменять только офицер безопасности. В этом случае, механизм групп был бы очень близок к нашему пониманию роли. Предшествующее обсуждение предлагает две характеристики роли: должно быть приблизительно одинаково просто определить принадлежность к роли и разрешения роли, а управление составом и разрешениями роли должно осуществляться небольшим количеством пользователей. Многие механизмы, о которых говорят, что они основаны на ролях, не выполняют либо одного либо обоих требований. Группы также являются устоявшимся понятием с хорошо понимаемым значением подобно другим известным понятиям например каталога. Хотя понятие группы можно расширить для того, чтобы у группы были свойства роли, все же будет лучше, если ввести новый термин во избежании путаницы с уже существующим понятием группы. Кроме того, группа и без этого является полезным понятием. Поэтому лучше различать эти два понятия.
2.6 МОДЕЛИ RBAC96.
Несмотря на признанную полноценность понятия RBAC, общего соглашения по тому, что RBAC означает, пока нет. В результате получается, что RBAC является понятием, интерпретируемым различными способами, в пределах от простого до достаточно сложного. Чтобы полностью понимать RBAC, мы определим семейство, состоящее из четырех моделей. Модель RBAC0 является основной моделью и определяет минимальные требования для любой системы, которая полностью поддерживает RBAC. Модели RBAC1 и RBAC2 обе включают в себя RBAC0, но в остальном являются независимыми. Они называются расширенными моделями. Модель RBAC1 добавляет понятие иерархий ролей (случаи, когда роли могут наследовать права других ролей). Модель RBAC2 добавляет ограничения (constraints) (которые налагают ограничения на конфигурации различных компонент RBAC). Модели RBAC1 и RBAC2 не зависят друг от друга. Объединенная модель RBAC3, включает в себя RBAC1 и RBAC2 и, как следствие, RBAC0. Мы будем обозначать это семейство моделей как RBAC96. Связи между четырьмя моделями RBAC96 изображены на рис.1(a), а объединенная модель RBAC3 показана на рис.1(b). Эти модели предлагают руководство для разработки программных продуктов и их оценки предполагаемыми заказчиками. Предположим, что только офицер безопасности уполномочен устанавливать различные наборы и связи этих моделей 2.6.1 Основная Модель: RBAC0
RBAC0 состоит из той части изображения на рис.1(b), которая не связана ни с одной из трех расширенных моделей, то есть она не включает иерархию ролей и ограничения. Имеются три множества объектов, называемых пользователями (U), ролями (R), и разрешениями (P). Диаграмма также показывает совокупность сеансов (S). Пользователь в этой модели - это человек. Понятие пользователя можно обобщить, чтобы оно включало в себя программы, компьютеры, или даже сети компьютеров. Для простоты, под пользователем мы подразумеваем человека. Роль - это название работы или должности в организации со связанной с ней семантикой, определяющей полномочия и ответственность исполнителя роли. Разрешения - это подтверждение определенного вида доступа к одному или нескольким объектам в системе. Для обозначения разрешения в литературе также используется термины «авторизация», «право доступа» и «привилегия». Разрешения всегда положительны и предоставляют возможность их владельцу выполнять некоторые действия в системе. Объектами являются данные или ресурсы. Наша модель позволяет нам рассматривать множество интерпретаций для разрешений, от очень "скупой", где доступ разрешается ко всей подсети компьютеров, до очень "богатой", где единица доступа - это определенное поле определенной записи. В некоторой литературе, посвященной управлению доступом рассматриваются "отрицательные разрешения", которые скорее запрещают чем разрешают доступ. В нашей работе запрещение доступа смоделировано, как ограничение вместо отрицательного разрешения. Сущность разрешения зависит от деталей реализации системы и ее свойств. Поэтому общая модель управления доступом должна рассматривать разрешения как в какой-то степени не интерпретируемые обозначения. Каждая система защищает абстрактные объекты,
(b) Модель RBAC3
Рис.1: Семейство Моделей RBAC96 которые она реализует. Таким образом операционная система например защищает такие объекты как файлы, каталоги, устройства, и порты ввода вывода, с операциями типа чтения, записи, и выполнения. Реляционная СУБД защищает отношения, кортежи, атрибуты, и представления, с операциями типа SELECT, UPDATE, DELETE, и INSERT. Приложение учета защищает учетные записи и программы финансового учета с операциями типа дебета, кредита, передачи, создания учетной записи, и удаления учетной записи. Должно быть разрешено назначать роли операцию кредита без необходимости назначения той же роли операции дебета. Обратите внимание, что обе операции требуют доступа на чтение и запись к файлу, в котором операционная система хранит учетные записи. Разрешения могут относиться как к одному так и к нескольким объектам. Например, разрешение может быть доступом на чтение к конкретному файлу или доступом на чтение ко всем файлам, объединенным общим признаком. Способ, согласно которому индивидуальные разрешения объединяются в одно универсальное разрешение, чтобы их можно было рассматривать как единое целое, в большой степени зависит от реализации системы. На рис.1(b) показаны отношения user assignment (UA) и permission assignment (PA). Оба отношения являются отношениями "многие ко многим". Пользователь может быть членом нескольких ролей, и роль может содержать несколько пользователей. Точно так же роль может иметь много разрешений, и одно разрешение может быть предоставлено нескольким ролям. Ключ к пониманию RBAC находится в этих двух отношениях. В конечном счете, разрешения принадлежат пользователю. Но использование роли как посредника, для передачи пользователю разрешений обеспечивает больший контроль доступа, чем непосредственная передача разрешений пользователям. Каждый сеанс - это соответствие между пользователем и множеством ролей, то есть пользователь в течение сеанса активизирует некоторое подмножество множества ролей, членом которых он является. Двойная стрелка, направленная от сеансов S к ролям R на рис.1(b) указывает на то, что во время сеанса активизировано несколько ролей одновременно. Разрешения, доступные пользователю - это объединение разрешений всех ролей, активизированных в сеансе. Каждый сеанс связан с отдельным пользователем, как показывает стрелка от сеанса S к пользователю U. Эта зависимость остается неизменной в течении всего сеанса. У пользователя может быть открыто несколько сеансов одновременно, например, каждый в своем окне на экране рабочей станции. У каждого сеанса может быть свое множество активных ролей. Эта особенность RBAC0 обеспечивает принцип наименьшего количества привилегии. Пользователь, являющийся членом нескольких ролей, может активизировать любое их подмножество, которое является подходящим для задач, которые пользователь будет решать в данном сеансе. Таким образом, пользователь, являющийся членом роли с большим количеством разрешений, может и не активизировать эту роль без необходимости. Мы оставляем рассмотрение всех видов ограничений, включая ограничения на активизацию ролей, в модели RBAC2. Таким образом в RBAC0, какие роли активизировать в данном сеансе, решается по усмотрению пользователю. Модель RBAC0 также разрешает динамическую активизацию и деактивизацию ролей во время сеанса. В литературе, посвященной управлению доступом понятие сеанса приравнивают к традиционному понятию субъекта. Субъект (или сеанс) - это единица управления доступом, и пользователь может работать несколькими субъектами (или сеансами) с различными разрешениями, активными в одно и то же время.
Следующее определение формализует проведенное обсуждение. Определение 1: Модель RBAC0 содержит следующие компоненты: • U, R, P и S (пользователи, роли, разрешения и сеансы), • PA P R, отношение предоставления роли разрешения (многие-ко-многим), • UA U R, отношение назначения пользователя на роль (многие-ко-многим), • user : S U, функция, которая ставит в соответствие каждому сеансу si одного пользователя user(si) (является константой в течении времени жизни сеанса) • roles : S 2R, функция, которая ставит в соответствие каждому сеансу si набор ролей roles(si) {r | (user(si),r) UA} (который может меняться со временем), следовательно в сеансе si есть следующее множество разрешений Мы предполагаем, что каждое разрешение и каждый пользователь, связаны хотя бы с одной ролью. Возможно, что у двух различных ролей, будут одинаковые наборы разрешений. То же самое справедливо и для пользователей. Роль должна рассматриваться как семантическая конструкция, вокруг которой сформулирована политика управления доступом. Определенная совокупность пользователей и прав, связаны ролью. Например, на момент создания роли, с ней могут быть не связаны ни один пользователь и ни одно разрешение. В любой момент времени в системе могут находиться несколько таких ролей. Такая конфигурация может сохраняться в течение сколь угодно долгого времени. Однако эти роли не должны рассматриваться как идентичные. Как отмечено ранее, модель RBAC0 рассматривает разрешения как не интерпретируемые символы, потому что природа разрешений зависит от реализации системы. Мы полагаем, что разрешения применяются к объектам данных и ресурсам а не к компонентам RBAC непосредственно. Разрешения изменять множества U, R, и P и отношения PA и UA называются административными разрешениями. Пока мы предполагаем, что только офицер безопасности может изменять эти компоненты. Сеансы находятся под управлением пользователей. Пользователь может создать сеанс и активизировать некоторое подмножество своего набора ролей. Пользователь может менять активные в данный момент роли по своему усмотрению. Сеанс заканчивается по инициативе пользователя. (Некоторые системы закрывают сеанс, если он слишком долго остается неактивным. Строго говоря, это - ограничение и относится к RBAC2.) Модель RBAC0 не предусматривает создания сеанса другим сеансом. Сеансы создаются непосредственно пользователем. Для простоты мы опустили этот аспект, но мы признаем, что в некоторых случаях требуется, чтобы существующий сеанс породил другой сеанс, возможно с другими ролями. Некоторые авторы включают понятие обязанностей в дополнение к разрешениям, как атрибут ролей. Обязанность - обязательство пользователя выполнить одну или несколько задач, которые необходимы для нормального функционирования организации. В нашем случае обязанности - это понятие, которое не принадлежит RBAC0. Мы также решили не включать обязанности в наши расширенные модели. С одной стороны их можно рассматривать как разрешения. Другие подходы могут быть основаны на новых принципах управления доступом типа "task-based authorization" [San97, San92]. 2.6.2 Иерархии Ролей: RBAC1
Модель RBAC1 представляет собой иерархии ролей (RH). В литературе вместе с ролями почти всегда рассматриваются иерархии ролей [FK92,SCFY96]. Обычно они реализуются в системах, которые основаны на ролях. Иерархии Ролей - это средства для структурирования ролей, для того, чтобы правильно отражать полномочия и ответственности в организации. Примеры иерархий ролей показаны на рис. 2. Обычно более сильные (или старшие) роли располагают ближе к вершине этих диаграмм, а менее сильные (или младшие) роли - ближе к основанию. На рис. 2(a) самая младшая роль - это health-care provider. Роль physician является более старшей чем health-care provider и таким образом наследует все ее разрешения. Роль physician может иметь и другие разрешения в дополнение к тем, которые она унаследовала от роли health-care provider. Наследование разрешений обладает свойством транзитивности, так, например, на рисунке 2(a), роль primary-care physician наследует разрешения ролей physician и health-care provider. Роли primary-care physician и specialist physician обе наследуют разрешения от роли physician, но все, они будут иметь различные разрешения, непосредственно им предоставленные. Рис. 2 (b) иллюстрирует множественное наследование разрешений, где роль project supervisor наследует разрешения от ролей test engineer и programmer. С точки зрения математики, иерархии - это частичные порядки. Частичный порядок - это рефлексивное, транзитивное и антисимметричное отношение. Наследование рефлексивно, потому что роль наследует собственные разрешения, транзитивность очевидна, а антисимметричность следует из того, что не существует ролей, которые могут наследовать друг у друга разрешения. Формальное определение RBAC1 приводится ниже. Определение 2 : RBAC1 содержит в себе следующие компоненты: • U, R, P, S, PA, UA и user остаются неизменными от RBAC0 • , является частичным порядком на R и называется иерархией ролей (в инфиксном представлении записывается с помощью символа ) • Модифицированная функция roles : где требуется следующее (что может меняться со временем), следовательно в сеансе si есть следующее множество разрешений Когда мы пишем x>y, мы имеем в виду x y и x y. Обратите внимание, на то, что пользователю разрешено создавать сеанс с любой комбинацией ролей, которые младше тех ролей, членом которых является пользователь. Также, разрешения в сеансе состоят из разрешений активных ролей сеанса и разрешений ролей, являющихся более младшими по сравнению с ними. Иногда полезно ограничить возможности наследования. Рассмотрим иерархию ролей на рис. 2(b), где роль project supervisor старше ролей test engineer и programmer. Теперь предположим, что инженеры испытаний желают сохранить некоторые личные разрешения только для своей роли и не допустить их наследование ролью руководителей проекта. Такое может иметь место по вполне законным причинам, например, доступ к незаконченной работе может не совсем соответствовать старшей роли, в то время как RBAC может быть полезен для предоставления такого доступа инженерам. Это можно реализовать, определив новую роль, называемую test engineer' и связав ее с test engineer как показано на рис. 2(c). Личные разрешения инженеров предоставляются роли test engineer'. Инженеры назначаются на роль
Рис.2: Пример Иерархий Ролей
test engineer' и наследуют разрешения от роли test engineer, которые также наследуются ролью project supervisor. Однако разрешения роли test engineer' не наследуются ролью project supervisor. Мы будем называть такие роли как test engineer' личными ролями. На рис. 2(c) также показана личная роль programmer'. В некоторых системах поддержка личных ролей достигается с помощью блокировки наследования некоторых разрешений. В этом случае иерархия не отражает точное распространение разрешения. Более предпочтительнее рассматривать личные роли, и не изменять значение понятия иерархических отношений. На рис. 3 показано, как в общем случае создать подиерархию личных ролей. Иерархия на рис. 3(a) состоит из четырех ролей задач - T1, T2, T3 и T4, все из которых наследуют разрешения от общей роли P. Роль S наверху иерархии предназначена для руководителей проекта. Задачи T3 и T4 – это подпроект с общей ролью P3, и с S3 в качестве роли руководителя подпроекта. Роль T1' на рис. 3(c) - личная роль для членов задачи T1. Предположим подпроекту ролей S3, T3, T4, и P3 на рис. 3(a) требуется личная подиерархия в пределах которой личные разрешения проекта могут быть разделяемыми без наследования ролью S. Подиерархия созданная таким способом, показана на рис. 3(c). Разрешения которые S может наследовать могут быть назначены ролям S3, T3, T4, и P3, в то время как личные разрешения могут быть назначены ролям S3', T3', T4', и P3', что разрешает их наследование только в пределах подпроекта. Как было и раньше члены подпроекта назначены непосредственно на роли S3, T3, T4, или P3. Рис. 3(c) показывает зачем вообще в системе существуют личные роли, и помогает разобраться в доступе, чтобы определить природу личных разрешений. 2.6.3 Ограничения: RBAC2 Модель RBAC2 определяет понятие ограничений. Ограничения применяются ко всем аспектам RBAC как показано на рис. 1(b). Несмотря на то что мы и назвали наши модели RBAC1 и RBAC2, нумерация ничего не означает. Все равно что рассматривать сначала: ограничения или иерархии ролей. Ограничения – это важный аспект RBAC и иногда утверждается, что это и есть центральное понятие в RBAC. Предположим, есть две роли - менеджер по продажам и менеджер по учетным записям. В большинстве организаций одному человеку будет запрещено быть членом обеих ролей, потому что это создаст возможность совершения мошенничества. Это - известный и проверенный временем принцип, называемый разделением полномочий.
Рис.3: Иерархия Ролей в Проекте
Ограничения - это мощный механизм для определения высокоуровневой политики безопасности организации. Как только определенные роли будут объявлены взаимоисключающими, не надо будет беспокоиться по поводу назначения индивидуальных пользователей на роли. Последнее может быть делегировано и децентрализованно без опасения компрометации целей политики безопасности организации. Однако, если управление RBAC децентрализовано (что будет обсуждено позже), ограничения становятся механизмом с помощью которого старшие офицеры безопасности могут ограничить возможности пользователей, которые имеют административные привилегии. Это позволяет главному офицеру безопасности, определить перечень того что разрешено и применить это как принудительное требование к другим офицерам безопасности и пользователям, участвующим в управлении RBAC. В RBAC0 ограничения могут применяться к отношениям UA и PA, а также к функциям пользователей и ролей в различных сеансах. Ограничения - это предикаты которые возвращают значение "разрешено" или "не разрешено" если их применить к этим функциям и отношениям. Ограничения можно также рассматривать как предложения (или выражения) на некотором формальном языке. Интуитивно, ограничения лучше рассматривать в соответствии природой их происхождения. Мы обсудим ограничения скорее на неформальном языке чем на формальном. Определение 3 : RBAC2 ничем не отличается от RBAC0 за исключением добавления туда совокупности ограничений, которые определяют являются ли разрешенными значения различных компонент RBAC0. Только разрешенные значения будут рассматриваться. С точки зрения реализации лучше рассматривать простые ограничения, которые можно быстро и эффективно проверять и применять. К счастью, в RBAC с помощью простых ограничений можно добиться многого. Теперь мы рассмотрим некоторые ограничения, которые как мы считаем, необходимо реализовать. Если не все, то большая часть ограничений, применяемых к отношению назначения пользователей имеют аналоги, которые применяются к отношению назначения разрешения. Поэтому мы будем рассматривать эти два вида ограничений параллельно. Наиболее часто упоминаемым ограничением в контексте RBAC являются взаимоисключающие роли. Пользователь может быть назначен максимум на одну роль из набора взаимоисключающих ролей. Это обеспечивает разделение полномочий. Условия этого ограничения не требует большого пояснения. Двойное ограничение на назначение разрешений редко упоминается в литературе. На самом деле, ограничение взаимоисключения на назначение разрешений может обеспечить дополнительные гарантии разделения полномочий. Это двойное ограничение требует чтобы одно и то же разрешение могло быть предоставлено максимум одной роли из взаимоисключающего набора. Рассмотрим две взаимоисключающие роли, менеджер по счетам и менеджер по продажам. Взаимное исключение в терминах отношений UA требует, чтобы один индивидуум не мог быть членом обеих ролей. Взаимное исключение в терминах отношений PA требует, чтобы то же самое разрешение не могло быть предоставлено обеим ролям. Например, разрешение выписывать чеки не должно быть предоставлено обеим ролям. Обычно такое разрешение предоставляется менеджеру по счетам. Ограничение взаимоисключения на отношения PA предотвратило бы случайное или преднамеренное предоставление этого разрешения роли менеджера по продажам. Ограничения исключения на PA являются эффективными средствами предотвращения распространения "сильных" разрешений. Например, нам может быть все равно какая из ролей получит разрешение на допуск к какой-то учетной записи, но мы можем потребовать, чтобы только одна из двух ролей получила такое разрешение. В общем случае можно рассматривать принадлежность пользователей к различным комбинациям ролей. Таким образом пользователю может быть разрешено выполнять роли, программиста и тестера в различных проектах, но запрещено выполнять обе роли внутри одного проекта. Для назначения разрешений все аналогично. Другой пример ограничения на назначение пользователя на роль - это, то что количество членов данной роли может быть ограничено. Например, только один человек может выполнять роль руководителя отдела. Аналогично число ролей которые данный пользователь может выполнять, также можно ограничить. Назовем это количественными ограничениями. Соответственно, число ролей которым данное разрешение может быть предоставлено, может иметь количественные ограничения, что позволяет контролировать распространение "сильных" разрешений. Следует отметить, что ограничения на минимальное количество элементов могут оказаться трудными для реализации. Например, если у данной роли минимальное количество членов, что делать системе если один из они исчезает? Как вообще система узнает, что это произошло? Понятие необходимых (как условие) ролей основано на компетентности пользователей, то есть пользователь может быть назначен на роль A, если он уже является членом роли B. Например, только пользователи, являющиеся членами проекта, могут быть назначены на роль испытателей внутри проекта. В этом примере необходимая роль является более младшей по сравнению с упомянутой ролью. Подобным образом можно рассматривать и несравнимые роли. Ограничение на назначение разрешений может возникнуть следующим способом. Для соблюдения последовательности действий можно потребовать, чтобы разрешение p могло быть предоставлено какой-то роли только если эта роль уже обладает разрешением q. Например, в многих системах разрешение на чтение файла требует разрешения на чтение каталога, в котором находится файл. Предоставление первого разрешения без предоставления второго было бы не корректным. В общем случае мы имеем необходимые условия то есть пользователь может быть назначен на роль A, если он уже назначен или нет на определенные роли, и аналогично для разрешений. Ограничения назначения пользователей эффективны только в том случае когда, соответствующая дисциплина соблюдается при назначении людям пользовательских идентификаторов. Если один и тот же человек имеет два или больше пользовательских идентификатора, средства управления разделением полномочий и количественными ограничениями не работают. Идентификаторы пользователей и люди должны быть связаны отношением "один к одному". Подобные рассуждения справедливы и для ограничений относящимся к разрешениям. Если одна и та же операция санкционирована двумя различными разрешениями то система основанная на RBAC не может нормально управлять разделением полномочий и количественными ограничениями . Ограничения также можно применять к сеансам, а также к пользовательским и ролевым функциям, связанными с сеансом. Пользователю может быть разрешено быть членом двух ролей, но обе роли не могут быть активны в одно и то же время. Другие ограничения на сеансы могут лимитировать количество активных в данный момент сеансов у пользователя. Соответственно, можно ограничить количество сеансов, на которые разрешение распространяется. Иерархию ролей также можно рассматривать как ограничение. Ограничение заключается в том что разрешение предоставленное младшей роли должно быть предоставлено всем старшим ролям. Или, что эквивалентно, пользователь назначенный на старшую роль, должен быть назначен на все младшие роли. Таким образом модель RBAC1 в некотором смысле является избыточной и заменяется моделью RBAC2. Однако, мы считаем, что знать о существовании иерархий ролей как об отдельном понятии целесообразнее. Они сведены к ограничениям только, из-за избыточности назначений разрешений или пользователей. Непосредственная поддержка иерархий более предпочтительна чем их косвенная поддержка с помощью избыточности назначений. 2.6.4 Объединенная Модель: RBAC3
Модель RBAC3 объединяет модели RBAC1 и RBAC2, для того чтобы обеспечить, иерархию ролей и ограничения. При объединении этих двух понятий возникают некоторые вопросы. Давайте их обсудим. Ограничения можно непосредственно применять к иерархиям ролей. Иерархия ролей должна быть частичным порядком. Это ограничение уже встроено в модель. Можно наложить дополнительные ограничения на количества старших (или младших) ролей у данной роли. Двум или более ролям может быть запрещено иметь общую старшую (или младшую) роль. Эти виды ограничений полезны в случаях, когда полномочия изменять иерархию ролей децентрализованы, но главный офицер безопасности желает ограничить возможности производить такие изменения. Достаточно тонкие взаимодействия возникают между ограничениями и иерархиями. Предположим, что роли инженера испытаний и программиста объявлены взаимоисключающими (смотрите рис. 2(b)). Роль руководителя проекта нарушает это взаимное исключение. В некоторых случаях такое нарушение ограничения взаимного исключения старшей ролью может быть разрешено, в то время как в других случаях - запрещено. Мы считаем, что модель не должна исключать ни ту ни другую возможность. Похожая ситуация возникает с количественными ограничениями. Предположим, что пользователь может быть назначен не более чем на одну роль. Нарушает ли назначение на роль инженера испытаний на рис. 2(b) это ограничение? Другими словами, применяются ли количественные ограничения только к прямой принадлежности, или они также распространяются на унаследованную принадлежность? Иерархия на рисунке 2(c) показывает, насколько ограничения полезны при описании личных ролей. В этом случае роли test engineer', programmer' и project supervisor можно объявить взаимоисключающими. Так как они не имеют общих старших ролей, то здесь нет никаких противоречий. В общем случае личные роли не имеют общих старших ролей с любой другой ролью, тат как они находятся на самом высоком уровне в иерархии. Таким образом взаимное исключение личных ролей может быть определено без противоречий. Общедоступные копии личных ролей можно объявить как имеющие максимум ноль членов. В этом случае инженеры испытаний должны быть назначены на роль test engineer'. Роль test engineer служит как средство для совместного использования разрешений с ролью project supervisor.
3. Модели RBDM.
3.1 Делегирование полномочий.
В данном разделе мы рассмотрим концепцию делегирования прав в контексте РКД. Основной идеей делегирования прав (далее - просто делегирования) является существование в системе некой активной сущности, предоставляющей некоторые свои возможности другой активной сущности. Делегирование в компьютерной системе может принимать различные формы: человек - человеку, человек - машине, и, возможно, даже машина - человеку. В этой статье мы остановимся на первой из возможностей. Точнее, мы рассмотрим способность пользователя, владеющего ролью, предоставлять владение ей пользователю, владеющему некоторой другой ролью. Мы разработаем простую, но действенную модель для делегирования, называемую RBDM00. Мы объясним необходимость модели и дадим ее формальное описание, а также рассмотрим некоторые ее расширения, вносящие в оригинал определенную сложность: аннулирование, частичное делегирование, многошаговое делегирование и делегирование с использованием иерархии ролей. Для оценки необходимости расширений давайте рассмотрим гипотетический научный отдел в университете. Интуитивным сценарием для иллюстрации делегирования будет передача профессором ключа от своего кабинета секретарю для заполнения каких-либо бумаг, или своему помощнику для подготовки к экзамену или проверки домашнего задания. Другим сценарием является замена сторонним лектором профессора, читающего курс. Во всех этих случаях проблема делегирования проста, так как в каждом случае прежний владелец роли предоставляет свою роль кому-то для выполнения некоторой задачи вместо себя. Это может соответствовать общим интересам организации, потому что работа выполняется и в отсутствие носителя определенной роли. Эти виды взаимодействий должны контролироваться по типу возможной защищенности внутреннего ресурса организации.
В примере, профессору могла быть разрешена передача роли профессора помощнику или секретарю, но не студенту. Помощнику, получившему ключ, в свою очередь, не разрешено передавать его кому-либо (это называется одношаговым делегированием).
В литературе существует множество форм и определений делегирования. Наиболее глубоко изучалось делегирование прав человеком машине и машиной машине [Glad97], [ABLP96], [GM90]. Модели делегирования прав доступа также косвенно ссылаются на делегирование (HRU, TAM,SPM, Take - Grant) [HRU76], [San97], [Lamp71]. Содержание нашей модели (RDBM0) - взаимодействие между двумя людьми, когда некоторый пользователь, являющийся владельцем роли предоставляет ее пользователю-владельцу другой роли. Этот тип делегирования серьезно в литературе не обсуждался. Эта статья является пробной попыткой моделирования такого взаимодействия. Гассер(Gasser) и МакДермотт(McDermott) [GM90] определили делегирование пользователя машине как ' процесс, в ходе которого пользователь в распределенной среде авторизует систему на доступ к удаленным ресурсам вместо себя'. Авторизация пользователя, дающая возможность процессу вместо него, является одной из форм делегирования прав пользователем процессу. Иногда пользователь может предоставить права одной из допустимых ролей или тождественностей (например, входя в систему под разными именами и/или паролями), чтобы ограничить действия процесса тем подмножеством, на котором пользователь авторизован. Ограниченное делегирование также возникает обычно в многоуровневых системах безопасности, в котором пользователь выбирает простую классификацию своего процесса как подмножества того класса доступа, для которого пользователь авторизован [GM90]. Гледни(Gladny) [Glad97] рассматривает требования безопасности для электронной библиотеки, которая напоминает значительные собрания бумаги и других предметов для офисного, инженерного и культурного применения. Он предложил методику контроля доступа, напоминающую организационную практику, соединив дерево субъектов с моментальным делегированием роли, которое управляет привилегиями
для множества операций независимо. Масштабирование на большое количество пользователей завершается чем-то напоминающим вертикальное делегирование в организационной иерархии, расширенное возможностью разрешать передачу между любыми узлами вверх, вниз или поперек в организационном дереве; это обеспечивает возможность представить особые администраторские роли в виде офицеров безопасности. Конечная цель: каждая привилегия должна отслеживаться в виде последовательности, исходящей от полномочного пользователя.
Варадхараджан эт аль (Varadharajan et al) представил суть проблемы в виде проверки на правомочность объекта, требующего замены, авторизовать другой объект. На практике это значит, что мы должны быть уверены, что информация безопасно передается между объектами.
Целью наших усилий является делегирование вида 'пользователь-пользователь', основанное на РКД(RBAC). Мы будем основывать нашу работу на RBAC0 из семейства моделей RBAC96 [SCFY96]. Это значит, что мы будем рассматривать только плоские роли. Расширение до делегирования с иерархическими ролями обсуждается в этом подразделе как дополнение. Мы избрали этот путь для детальной разработки простой, но полезной модели и дальнейшего постепенного рассмотрения расширений с целью увеличения функциональности. 3.2 RBAC0 - плоские роли.
Наша работа будет происходить в рамках хорошо известной модели RBAC96 [San97]. Мы используем простейшую форму этой модели, называемую RBAC0. Пользователь - человек, роль - рабочая функция, а разрешение есть возможность доступа к некоторым объектам или привилегия на выполнение определенной задачи. Управление разрешениями и ролями очень упрощено путем наделения привилегиями ролей и присвоения ролей пользователям. При этом пользователи приобретают эти привилегии. Права, необходимые для выполнения определенных задач, распределены между ролями. Ролям могут быть даны новые права по мере появления новых приложений и систем. Права, не являющиеся необходимыми, у ролей могут быть отняты. Пользователи получают роли в зависимости от ответственности и квалификации и их роли могут меняться. ( Концепцию сессии модели RBAC96 мы здесь не используем и поэтому умолчим о ней).
3.3 RBDM0 - плоские роли.
Эта модель является простейшей формой модели RBDM и основана на RBAC0 из семейства RBAC96. Это значит, что делегирование, рассматриваемое в этой части, происходит между двумя пользователями с плоскими ролями (нет никакого наследования прав между ролями).
Для начала мы сделаем некоторые предположения и построим базу для дальнейшего изложения.
3.3.1 Предположения и основы.
Делегирование между пользователями с одинаковыми ролями не разрешено, так как оно бессмысленно. Это предположение очень простое и в дальнейшем будем строго его придерживаться. Делегирование в рассматриваемой модели - одношаговое. Это значит, что роль, делегированная однажды, не может быть делегирована дальше. Следовательно, только исходные владельцы могут делегировать. Будем придерживаться этого предположения в нашей основной модели, но в ее расширении откажемся от него для рассмотрения многошагового делегирования.
Делегирование абсолютно. Каждый пользователь делегирующей роли делегирует полный пакет разрешений, включенных в роль, или не делегирует их полностью. Это предположение также будет смягчено далее, когда мы расширим нашу модель включением частичного делегирования, где мы будем различать делегируемые и не делегируемые полномочия.
В каждой делегирующей роли r есть два типа владельцев:
- Исходные Users_O(r) - те, которым роли присваивались системным администратором. - Делегированные Users_D(r) - те, которым роли присваивались исходными владельцами роли.
Для упрощения аннулирования мы предположим в нашей основной модели, что любой исходный владелец роли может аннулировать делегирование любого делегированного владельца роли. То есть делегирование не зависит от того, кто делегировал роль. Как мы увидим, аннулирование - это обширная область, которую мы рассмотрим в расширениях далее в этом разделе.
Предположим, что каждое делегирование имеет свой элемент, с ним ассоциированный, называемый продолжительностью(T). Продолжительность каждого делегирования находится под управлением делегирующего пользователя. Когда время делегирования истекает, делегирование автоматически аннулируется. Аннулирование также может быть произведено исходным владельцем, даже если время действия еще не вышло. Следующие определения формализуют все вышесказанное.
Определение 1: Нижеследующее является списком компонентов RBAC96: • U, R и P – это множества пользователей, роле и прав соответственно. • UA UR - отношение ‘многие ко многим’ между пользователями и ролями. • PA PR - отношение ‘многие ко многим’ между правами и ролями. • Пользователи: R2U – функция, полученная из UA путем отображения каждой роли r на множество пользователей, где Users(r) = {U | (U,r)UA}. • Права: R2P – функция, полученная из PA путем отображения каждой роли r на множество прав, где Permissions(r) = {P | (P,r)PA}.
Определение 2: Модель RBDM0 добавляет следующие компоненты: • UAOUR - отношение ‘многие ко многим’ между исходными пользователями и ролями. • UADUR - отношение ‘многие ко многим’ между делегированными пользователями и ролями. • UA = UAOUAD. • UAOUAD = . Множества исходных и делегированных пользователей одной и той же роли не пересекаются. • Users_O(r) = {U | (U,r)UAO} • Users_D(r) = {U | (U,r)UAD} • Все элементы Users_O(r)(Users_D(r)) получают полный набор привилегий этой роли. • T – множество продолжительности действия делегирования. • Делегирующие роли: UAD(T) – функция, отображающая каждое делегирование в его продолжительность. 3.3.2 Делегирование.
В RBAC96 офицер безопасности обеспечивает присвоение ролей пользователям [San97]. В RBDM0 делегирование в делегирующей роли другому пользователю в другой роли - это добавление этого пользователя в группу владельцев делегирующей роли. То есть, эту функцию несет делегирующий пользователь. В данной статье внимание сосредоточено исключительно на делегировании вида ‘пользователь-пользователь’. Этот вид совершенно децентрализован, и он может осуществляться пользователями без вмешательства офицера безопасности.
Делегирование вида ‘пользователь-пользователь’ определяется в RBDM0 с помощью следующего определения.
Определение 3: RBDM0 управляет делегирование вида ‘пользователь-пользователь’ путем определения отношения ‘возможно делегирование’ RR.
Отношение ‘возможно делегирование’ не рефлексивно. Это значит, что пользователь роли не может делегировать ее другому пользователю роли, так как это бессмысленно.
Значение (a,b) ‘возможно делегирование’ в следующем: пользователь (скажем, Alice), являющаяся исходным пользователем роли может делегировать свою роль любому другому пользователю (скажем, Bob), являющемуся исходным пользователем другой роли b. Например, если Alice User_O(a), Bob User_O(b), то Alice может делегировать права Bob’у, то есть (Bob,a) UAD.
3.3.3 Аннулирование.
Итак, мы описали, как пользователи делегирующих ролей могут делегировать свои полномочия пользователям с другими ролями, и как мы можем управлять этим процессом, используя отношение ‘возможно делегирование’. Однако, как часто происходит в реальной жизни, мы можем захотеть аннулировать права. В примере, описанном выше, когда глава отдела уезжает, одному или нескольким профессорам могут быть делегированы его права. Впоследствии, когда глава отдела возвращается, необходимо вернуть делегированные профессору права. В этой части мы рассмотрим возможные пути, которыми пользователь в делегируемой роли может аннулировать права, которые он делегировал. Мы также рассмотрим условия, при которых невозможно аннулировать предыдущее решение и посмотрим, какой результат может вызвать попытка аннулирования.
3.3.3.1 Типы аннулирования.
RBDM0 определяет два способа аннулирования: использование временных ограничений и способностью исходного пользователя любой роли аннулировать делегирование любого делегированного пользователю (аннулирование, независимое от предоставления).
В следующих двух подразделах описываются оба подхода и обсуждаются их плюсы и минусы. Аннулирование по истечению времени.
При этом подходе мы выделяем временной промежуток для каждого делегирования, по прошествии которого делегирование прекращается. Этот подход имеет свои преимущества и недостатки.
Преимущества подхода: - Аннулирование является автоматизированным процессом, которым просто управлять. - После назначения времени действия делегирования нет необходимости в контроле со стороны делегирующей роли. Недостатки: - Само по себе временное ограничение еще не гарантирует безопасность. - Если не существует особого механизма слежения, то возможно нанесение большого ущерба системе до истечения времени действия делегирования. - При использовании этого подхода мы должны осторожно подходить к назначению срока действия, потому что мы можем назначить слишком много или слишком мало времени пользователям, которым делегируются права.
Аннулирование, не зависящее от предоставления.
Этот тип аннулирования позволяет любому исходному владельцу делегирующей роли аннулировать владение любого делегированного пользователя этой роли. Это дает возможность исходным владельцам защищать роль от делегированных владельцев, которая имеет свои преимущества и недостатки. Преимуществом является то, что если делегированный владелец роли выполняет недопустимые действия, то исходный пользователь может немедленно аннулировать его права и минимизировать тем самым вред еще до истечения времени.
С другой стороны, недостатком является возможный конфликт между исходными пользователями. Это может произойти в случае, если аннулирование происходит не тем, кто делегировал права этой роли делегированному владельцу.
Нет необходимости определять отношение ‘возможно аннулирование’ для управления аннулированием, так как лишь одна роль уместна для этого процесса.
В итоге, модель RBDM0 описывается определениями 1 и 2 и авторизует делегирование при помощи отношения ‘возможно делегирование’ из определения 3. Вдобавок, в модели работает аннулирование.
3.4 Расширения RBDM0.
В этом разделе исследуются возможные способы возможные расширения модели. Ниже приводится список возможных расширений и описание их возможного воздействия на основную модель. 3.4.1 Аннулирование, зависящее от предоставления.
Это значит, что только тот владелец роли, который делегировал роль другому пользователю, может её аннулировать. Добавление этого расширения в модель значительно усложняет модель. Оно также имеет свои преимущества и недостатки. Преимущества: - Улучшается управление процессом аннулирования. - Не возникает конфликтов между исходными владельцами роли. Но результатом расширения является следующий перечень усложнений: 1. Со стороны делегирующей стороны: - В случае аннулирования мы должны отслеживать, кто делегировал роль, чтобы произвести аннулирование. Это особенно сложно при наличии большого количества пользователей. - Если аннулирована роль пользователя, делегировавшего роль, то мы должны решить, что и как делать с делегированной ролью. - Злоупотребление со стороны делегированного владельца может продолжаться достаточно долго, пока роль не будет аннулирована. - Необходимо определить, что делать в случае, если разрешено делегировать со стороны более чем одного пользователя. 2. С делегируемой стороны. - Необходимо заботиться о начальном состоянии делегирующей роли. - Нужно знать, что происходит в случае потери делегирующей ролью исходного владения делегируемой роли. - Придется иметь дело с каскадным аннулированием, а это очень неудобно. - Значимым фактором становится количество делегирующих ролей, так как в этом случае соответственно усиливаются проблемы каскадного аннулирования и исходного состояния делегирующих ролей. 3.4.2 Два типа прав (Делегируемые и не делегируемые).
Добавление прав в существующую модель никак не отразится на делегировании или аннулировании, потому что единственным их участником является человек. Это улучшает, однако, управление делегированием.
Определяя право как делегируемое или не делегируемое, мы передаем управление в руки администрации. Потребуется дополнительный процесс, который может предопределять набор прав как один пакет.
Формальное определение измененной модели RBDM0 будет иметь те же компоненты, что и основная, плюс следующие:
- Делегируемые права (PD) – это те, которые могут быть делегированы. Эти типы прав доступны как исходным владельцам роли, так и делегированным. - Не делегируемые права (PD) – это те, которые не могут быть делегированы. Эти типы прав доступны только исходным владельцам роли.
• P – это множество обычных прав. • PA PR - отношение ‘многие ко многим’ между правами и ролями. • PDA PR - отношение ‘многие ко многим’ между делегируемыми правами и ролями. • PNA PR - отношение ‘многие ко многим’ между не делегируемыми правами и ролями. • PA = PDAPNA. • PDAPNA = . • Права: R(2P – функция, отображающая каждую роль r на множество прав: Permission(r) = {P | (P,r)(PA}. Permission PD(r) = {P | (P,r)(PDA}. Permission PN(r) = {P | (P,r)(PNA}. • Исходные владельцы O(r) роли получают все права этой роли. • Делегированные владельцы D(r)роли получают только делегируемые права. 3.4.3 Двухшаговое делегирование.
Этот тип делегирования позволяет делегированной роли делегировать ее дальше другим ролям. Покажем, как можно смоделировать двухшаговое делегирование. Мысль можно развить и на многошаговое делегирование.
Определение 4: RBDM0 c двухшаговым делегированием содержит следующие компоненты: • U, R, P – это множества пользователей, ролей и прав соответственно. • UA UR - отношение ‘многие ко многим’ между пользователями и ролями. • UAO UR . • UAD UR . • UADD UR . • UA = UAO UAD UADD. • UAO UAD UADD = . • Права: R2U – функция, отображающая каждую роль r на множество пользователей.
Users(r) = {U | (U,r) UA}
Users_O(r) = {U | (U,r) UAO}
Users_D(r) = {U | (U,r) UAD}
Users_DD(r) = {U | (U,r) UADD}
• Заметим, что Users_O(r) Users_D(r) =, потому что UAO UAD UADD = .
3.4.4 Делегирование в иерархии ролей.
В иерархии ролей, старшие роли наследуют права младших ролей. Если включить иерархию ролей в рассматриваемое нами взаимодействие ‘пользователь-пользователь’, то модель сильно усложняется. Здесь мы имеем дело с различными типами делегирования. Некоторые из них полезны, а иные рискованны. В этом разделе мы лишь сделаем обзор различных типов делегирования, использующих иерархические роли, и представим формальное определение, дополняющее основную модель. Более подробное описание требует продолжения исследований. Ниже дается список различных типов делегирования.
Восходящее делегирование.
Этот тип делегирования бесполезен ввиду наследования. Поэтому нет необходимости владельцу младшей роли делегировать свою роль владельцу старшей роли.
Нисходящее делегирование.
Этот тип делегирования работает только с частичным делегированием, так как нельзя делегировать роль целиком – это нарушит иерархию. Полезно для продвижения владельца младшей роли до более старшей.
Перекрестное делегирование.
Этот тип делегирования чрезвычайно полезен. К примеру, менеджер торгового отдела может делегировать свою роль сотруднику отдела аудита для проведения аудита в своем отделе.
В этом типе делегирования не только исходный владелец роли может ее делегировать, но, также, это может сделать любой владелец старшей роли.
Аннулирование становится более сложным в случае иерархии ролей, ввиду участия нескольких ролей.
Частичное делегирование может быть произведено лишь для соответствующей младшей роли или нескольких таких ролей.
3.5. Заключение.
В этом разделе мы описали схему новой простой и необычной модели для делегирования вида ‘пользователь-пользователь’, называемой RBDM (role-based delegation model), основанной на RBAC96, разработанной [SCFY96]. RBDM состоит из двух основных компонент: RBDM0 (RBDM с плоскими ролями) и RBDM1 (RBDM с иерархическими ролями). В этой статье детально был описан только первый компонент. Второй – является предметом для дальнейших исследований. Далее в этом разделе мы определили и обсудили список возможных направлений, по которым модель может быть расширена. Он включает аннулирование, частичное делегирование, многошаговое делегирование и делегирование в иерархии ролей.
4. РРД в Oracle 8i.
В данном разделе мы рассмотрим основные средства, реализующие РРД в СУБД Oracle 8i. Нами будут кратко описаны представления словаря данных, содержащие информацию о существующих в системе ролях и привилегиях, предоставленных этим ролям. Механизм создание ролей, присвоения им привилегий и присвоения ролей пользователям и другим ролям рассматриваться не будет, так как эта задача напрямую упирается в простое изучения языковых средств SQL. Следует заметить, что средства SQL, реализующие методы реляционной алгебры(в частности, нас будут интересовать отношения между пользователями, ролями и привилегиями) позволяют достаточно просто и емко описать основные требования описанных выше моделей РРД. Истинность предиката «возможен доступ» также может быть проверена достаточно тривиально. Ниже перечислены самые интересные на наш взгляд представления словаря данных, содержащие информацию о существующих в системе ролях.
DBA_USERS Хранит информацию о всех, кто имеет учетную запись в базе данных Oracle. Вместе с именем и хешированным паролем пользователя хранится имя назначенного ему пользователя.
USERNAME USER_ID PASSWORD ACCOUNT_STATUS ----------------- ----------- ----------------------- -------------------------------- DBSNMP 16 E066D214D5421CCC OPEN
LOCK_DAT EXPIRY_D
----- -----------
DEFAULT_TABLESPACE TEMPORARY_TABLESPACE CREATED PROFILE
--------------------------------------- -------------- ------------
SYSTEM SYSTEM 11.10.03
INITIAL_RSRC_CONSUMER_GROUP EXTERNAL_NAME
------------------------------------------------- --------------------------
DBA_ROLES Детализирует все роли, содержащиеся в базе данных.
ROLE PASSWORD
-------------------
CONNECT NO RESOURCE NO DBA NO SELECT_CATALOG_ROLE NO EXECUTE_CATALOG_ROLE NO DELETE_CATALOG_ROLE NO EXP_FULL_DATABASE NO IMP_FULL_DATABASE NO RECOVERY_CATALOG_OWNER NO AQ_ADMINISTRATOR_ROLE NO AQ_USER_ROLE NO SNMPAGENT NO OEM_MONITOR NO
DBA_ROLE_PRIVS Роли, которые были назначены конкретным пользователям и другим ролям.
GRANTEE GRANTED_ROLE ADM DEF
------------------------------ -------- ------
DBA DELETE_CATALOG_ROLE YES YES DBA EXECUTE_CATALOG_ROLE YES YES DBA EXP_FULL_DATABASE NO YES DBA IMP_FULL_DATABASE NO YES DBA SELECT_CATALOG_ROLE YES YES DBSNMP CONNECT NO YES DBSNMP RESOURCE NO YES DBSNMP SNMPAGENT NO YES EXP_FULL_DATABASE EXECUTE_CATALOG_ROLE NO YES EXP_FULL_DATABASE SELECT_CATALOG_ROLE NO YES IMP_FULL_DATABASE EXECUTE_CATALOG_ROLE NO YES
DBA_SYS_PRIVS Системные привилегии, которые были выданы конкретным пользователям или ролям.
GRANTEE PRIVILEGE ADM
---------------------------------- --------------
DBA ALTER USER YES DBA ANALYZE ANY YES DBA AUDIT ANY YES DBA AUDIT SYSTEM YES DBA BACKUP ANY TABLE YES DBA BECOME USER YES DBA COMMENT ANY TABLE YES DBA CREATE ANY CLUSTER YES DBA CREATE ANY CONTEXT YES
DBA_TAB_PRIVS Привилегии Select, Insert и Update, которые были выданы конкретным пользователям или ролям.
GRANTEE OWNER TABLE_NAME GRANTOR
---------------- ------------------------ ---------------
SNMPAGENT SYS V_$SGASTAT SYS SNMPAGENT SYS V_$DATAFILE SYS
PRIVILEGE GRA
------ ---
SELECT NO SELECT NO
ROLE_ROLE_PRIVS Роли, назначенные другим ролям.
ROLE GRANTED_ROLE ADM
------------------------------ ---
DBA DELETE_CATALOG_ROLE YES DBA EXECUTE_CATALOG_ROLE YES DBA EXP_FULL_DATABASE NO DBA IMP_FULL_DATABASE NO DBA SELECT_CATALOG_ROLE YES EXP_FULL_DATABASE EXECUTE_CATALOG_ROLE NO EXP_FULL_DATABASE SELECT_CATALOG_ROLE NO IMP_FULL_DATABASE EXECUTE_CATALOG_ROLE NO IMP_FULL_DATABASE SELECT_CATALOG_ROLE NO
ROLE_TAB_PRIVS Привилегии доступа к таблицам, выданные ролям.
ROLE OWNER TABLE_NAME COLUMN_NAME
------------ ------------------------------ --------------------------
SELECT_CATALOG_ROLE SYS V_$TYPE_SIZE
PRIVILEGE GRA
---
SELECT NO
USER_SYS_PRIVS Системные привилегии, выданные текущему пользователю.
USERNAME PRIVILEGE ADM
---------------------------------------- ---
SYSTEM UNLIMITED TABLESPACE YES
РРД в Oracle полностью отвечает концепции ограничения привилегий. Пользователям предоставляются лишь те привилегии, которые действительно им необходимы, выполнение действий, привилегии на выполнение которых им не предоставлены явно, запрещается. Роли могут быть легко детализированы с применением тривиальных SQL-запросов: Рассмотрим это на примере роли DBA. 1. Детализация роли: SELECT * FROM DBA_ROLES WHERE ROLE=’DBA’; Имеет ли роль пароль, назначена ли она WITH ADMIN OPTION. 2. Системные привилегии: SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE=’DBA’; 3. Привилегии делегированных данной роли ролей: SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE IN ( SELECT GRANTED_ROLE FROM ROLE_ROLE_PRIVS WHERE ROLE=’DBA’); Необходимо вследствие отсутствия записи типа DBA-DBA. Oracle работает в рамках классической модели RBAC0 с плоскими ролями. Объектно-ориентированные черты Моделей RBAC1 и RBAC2 не используются. Управление назначением ролей может быть как централизованным, так и распределенным. Управление возможностью создания и присвоения ролей реализуется путем назначения ответственным за это пользователям соответствующих привилегий. Однако, при этом имеется возможность делегирования ролей, как одношагового, так и многошагового. Это сильно повышает удобство работы с СУБД, но, при этом, может привести к возможности НСД при неосторожном обращении с опцией WITH ADMIN OPTION или при нежелании администратора, ответственного за назначение ролей, тщательно проверять, какие делегируются привилегии. Аннулирование делегирования производится как делегировавшим субъектом, так и имеющим привилегию REVOKE ANY пользователем. Это вносит дополнительные сложности, описанные подробно в предыдущем разделе. Таким образом, мы можем придти к выводу, что в Oracle 8i реализовано расширение модели RBDM0 семейства RBAC96 с поддержкой многошагового делегирования, дополнительных предикатов типа «возможно делегирование» и расширенным аннулированием. Точные подробности реализации механизма работы РРД в Oracle нам неизвестны. Однако, стандартные языковые средства, используемые в Oracle для работы с РРД, позволяют нам придти к вышележащим выводам. В заключение приведем PL/SQL код, реализующий работу предиката «разрешена привилегия» модели RBAC0.
CREATE OR REPLACE FUNCTION permitted (p user IN varchar2,p object IN varchar2, p mode IN varchar2) RETURN varchar2 AS CURSOR permissions IS SELECT rh.junior role FROM role permission assign rpa, (SELECT junior role FROM role hier CONNECT BY prior junior role Q senior role START WITH junior role in (SELECT DISTINCT sess.role FROM v$session s, role session sess,user role assign r WHERE sess.username Q p user AND sess.session id Q userenv(’SESSIONID’) AND sess.session id Q s.audsid AND r.role Q sess.role AND r.username Q sess.username AND SYSDATE BETWEEN r.st date and r.end date) ) rh WHERE rh.junior roleQ rpa.role AND rpa.object Q p object –Allow READ access if INSERT, UPDATE or DELETE privileges held– AND (rpa.permission Q p mode OR p mode Q ’READ’) AND SYSDATE BETWEEN rpa.st date AND rpa.end date; l role ROLE.role%TYPE; BEGIN OPEN permissions; FETCH permissions INTO l role; IF permissions%FOUND THEN CLOSE permissions; RETURN ’TRUE’; ELSE CLOSE permissions; RETURN ’FALSE’; END IF; END permitted;
Для работы этой функции предварительно должны быть созданы таблицы, содержащие отношения между пользователями и ролями, привилегиями и ролями, таблицы разрешений на пользование привилегиями. Подобного рода код может позволить нам расширить стандартные средства РРД СУБД Oracle.
5. Особенности РРД в Oracle 9i.
5.1 Роли и Oracle 9i.
В данной работе мы рассмотрим концепцию ролевого разграничения доступа в контексте СУБД Oracle 9i. Больше всего нас интересуют особенности, которые характерны исключительно для этой, последней версии популярного продукта. Ниже будут рассмотрена классификация ролей в Oracle девятой версии и их краткая характеристика. Будет уделено внимание интеграции Oracle в состав системного и прикладного ПО, в частности, взаимодействие механизмов безопасности Oracle и операционной системы(в частности, внешняя аутентификация пользователей с использованием NT User Manager). Предполагается знакомство читателя с основными понятиями ролевого разграничения доступа и механизмом его реализации в предыдущих версиях Oracle.
5.2 Виды ролей.
В качестве небольшого напоминания заметим, что роль-это именованный набор привилегий. Каждому пользователю или группе пользователей может быть назначена своя роль или группа ролей. Также роль может быть назначена другим ролям, что выглядит вполне корректно в рамках расширенной модели RBAC с пошаговым делегированием. Определение различных видов ролей позволяет упростить администрирование управления доступом.
5.2.1 Роли баз данных(Database Roles).
Привилегии позволяют пользователям получать доступ к данным или модифицировать данные, содержащиеся в базе данных. Роли баз данных – это именованные наборы привилегий, отвечающих за выполнение определенных специфических процедур, назначаемые пользователям или другим ролям. Так как именно использование ролей упрощает работу администратора, привилегии обычно назначаются ролям, а не конкретным пользователям. Администратор может селективно активизировать и отключать роли, назначенные пользователям. Данная концепция позволяет контролировать доступ в любой ситуации. Роль может быть защищена паролем. Приложения могут быть созданы с расчетом на использование при своей работе определенных ролей, если был введен правильный пароль. Пользователи не могут активизировать роли, если они не знают соответствующие пароли. Следующие свойства ролей упрощают управление привилегиями: 1) Уменьшение числа операций по назначению привилегий – вместо того, чтобы много раз назначать одни и те же привилегии большому числу пользователей, администратор безопасности может назначить эти привилегии роли, а затем назначить роль пользователю или группе пользователей, когда это необходимо. 2) Динамическое управление привилегиями – если необходимо изменить(в частности, отменить) привилегию группы пользователей, администратор может изменить ее у соответствующей роли, назначенной группе. 3) Селективная доступность привилегий – роли, назначенные пользователю, могут быть отключены или активизированы в зависимости от ситуации. 4) Ответственность за действия приложения - приложения баз данных могут быть сконфигурированы таким образом, чтобы автоматически отключить или активизировать определенные роли, когда пользователь пытается использовать эти приложения. Для лучшей структуризации(и, соответственно, улучшения контроля безопасности) доступов может быть использована иерархическая древовидная структура ролей.
5.2.2 Глобальные роли(Global Roles).
Глобальная роль – компонент пользовательской безопасности предприятия(enterprise user security).
Глобальная роль применима только для определенной базы данных, но она может быть назначена роли предприятия(enterprise role), определенной в каталоге предприятия(enterprise directory – на наш взгляд, данное понятие близко к понятию «Active Directory»). Несмотря на то, что глобальная роль действует в составе каталога, ее привилегии содержатся в единственной базе данных – в той, в которой она была определена. Глобальная роль может быть определена локально путем назначения ей ролей и привилегий, но она реально не может быть назначена пользователям или ролям внутри этой базы данных(в которой глобальная роль определена ). Когда пользователь каталога пытается соединится с базой данных, в которой определена глобальная роль, каталог предприятия осуществляет запрос на получение всех ролей, ассоциированных с данным пользователем. Этот механихм взаимодействия напоминает работу олицетворения в операционных системах семейства NT.
5.2.3 Роли предприятия(Enterprise roles).
Роли предприятия представляют собой каталогизированную структуру, которая может содержать глобальные роли множества баз данных, могущие быть назначены пользователю предприятия. При использовании механизма хранения и управления ролями с помощью LDAP-подобной службы каталога можно централизованно управлять зависящей от пользователей информацией, включая их авторизацию. Например, роль Администратор содержит глобальную роль Админ_БД_1, которая содержит уникальные привилегии, определенные в БД_1 и роль Админ_БД_2, содержащую привилегии в другой базе данных БД_2. Роли каталога могут быть назначены или отозваны от любого пользователя предприятия. В дополнении к ролям предприятия, пользователи могут обладать локальными ролями и привилегиями.
5.2.4 Безопасные роли приложений(Secure Applications Roles).
Рассмотрим давно известную проблему безопасности, заключающуюся в том, что пользователя, среди которых могут находиться и злоумышленники, должен быть запрещен прямой доступ к данным, т.е. данные должны быть инкапсулированы от пользователя как по форме представления, так и по множеству допустимых операций каким-либо промежуточным контрольным механизмом. Например, в нашей ситуации, в случае использования web-приложений даже если пользователь известен внутри базы данных и может быть успешно в ней авторизован, не рекомендуется позволять ему непосредственный доступ к данным. То есть получить доступ, осуществляемый непосредственно пользовательской программой. Вообще, проблема проверки допустимости выполнения программой пользователя определенных операций(принадлежности ко множеству разрешенных программ) лежит в области формулирования корректных правил мандатной политики безопасности и является сложно решаемой. В частности, пользователь может написать программу, выдающуй себя за легальную(допустимую). Одним из путей решения этой проблемы является использование безопасных ролей приложений, реализуемых с помощью пакетов(packages). Пакет может выполнить любую требуемую проверку необходимых условий перед тем, как пользователь использует какую-либо привилегию, назначенную роли в базе данных. База данных удостоверяется в том, что только доверенный пакет, корректно определяющий допустимые условия доступа, реализует роль. Безопасные роли приложений используются приложениями, могут быть активированы ими и не требуют пароля. На этом мы закончим рассмотрение концепции ролей в Oracle 9i и поговорим поподробнее о внешней аутентификации и внешних привилегиях пользователей.
5.2.5 Внешняя авторизация и внешние роли.
Для начала мы заметим, что политика безопасности, реализованная в Oracle, запрещает нам выполнение действий, которые явно не были разрешены(то есть привилегии явно не были назначены и параметры конфигурации не были переинициализированы). Зачастую бывает использовать внешнюю авторизацию(с использованием средств безопасности операционной системы, в дальнейшем термин «внешний» будет использоваться именно в контексте средств безопасности ОС), так как это позволяет упростить работу с доверенными пользователями, в особенности, при большом их количестве. Для успешной работы с внешними ролями необходимо, чтобы выполнялись следующие условия: OS_ROLES=TRUE REMOTE_OS_AUTHENTIFICATION=TRUE в файле конфигурации init.ora. Включение этих параметров позволит нам задействовать внешнюю аутентификацию и внешние роли. Затем с использованием мастера Create External OS Role мы последовательно назначаем привилегии для внешних ролей(то есть ролей, используемых операционной системой). При этом автоматически будет использована внешняя аутентификация, т.е аутентификация средствами операционной системы. Например, если пользователь вошел в систему под учетной записью, соответствующей группе Администратора и эта роль определена, как внешняя с соответствующими привилегиями, то при соединении с базой данных пользователю автоматически будет присвоена эта роль. Есть еще одна возможность по использованию внешних ролей. Пользователь может войти в систему, как SYSOPER или SYSDBA, если была задействована интеграция ролей с помощью DCE. Соответственно, должны быть истинными перечисленные выше параметры файла конфигурации. После этого должна быть добавлена роль(группа ролей) вида ORA_global_name_role[_[a][d]], где global_name – глобальное имя БД, role – имя внешней роли, необязательные параметры a и d – роль будет назначаться с опцией администратора и будет ролью по умолчанию на время сеанса, соответственно. Пользователь каталога предприятия в этом случае может соединиться с базой данных командой dce_login. Следует заметить, что назначение внешних ролей и использование аутентификации операционной системой следует использовать с осторожностью, так как в этом случае могут возникнуть дополнительные возможности несанкционированного доступа вследствие уязвимостей средств авторизации самой ОС.
6. Заключение
В заключение хотелось бы отметить, что данный вид разграничения доступа является весьма актуальным во многопользовательских и многозадачных системах реального времени, так как использование механизма ролей позволяет значительно упростить работу офицера безопасности. При это, если присвоение привилегий офицером безопасности ведется корректно, то возможные НСД могут возникнуть лишь как следствие ошибок в формулировках требуемой политики безопасности или при ошибках разработчиков системы РРД. В целом же, ролевое разграничение доступа вместе со своими расширениями представляет собой простой и мощный механизм контроля безопасности в современных вычислительных системах. Простота реализации и, как следствие, скорость работы проверяющего механизма, являются немаловажным достоинством РРД.
7. Ссылки
1. [ABLP96] Martin Abadi, Michael Burrows, Butler Lampson and Gordon Plotkin. A Calculus for Access Control in Distributed Systems. ACM Transactions on Programming Languages and Systems. Vol.15, No. 4, September 1993, pages 706-734.
2. [FCK95] David Ferriaolo, Janet Cugini and Richard Kuhn. Role-based access control (RBAC): Features and motivations. In Proceedings of 11th Annual Computer Security Application Conference, pages 241-248, New-Orleans, LA, December 11-15 195.
3. [FK92] David Ferriaolo and Richard Kuhn. Role-based access controls. In Proceedings of 15th NIST-NCSC National Computer Security Conference, pages 554-563, Baltimor, MD, October 13-16 1992.
4. [Glad97] Henry M. Gladny, Access Control for Large Collections. ACM Transactions on Information Systems, Vol.15, No.2, April 1997, pages 154-194.
5. [GM90] Morrie Gasser, Ellen McDermott. An Architecture for practical Delegation in a Distributed System. 1990 IEEE Computer Society Symposium on Research in Security and Privacy. Oakland, CA, May 7-9, 1990.
6. [HRU76] M.H. Harrison, W.L. Ruzzo and J.D. Ullman, Protection in Operating Systems Communications of ACM. 1976. Pages 461-471.
7. [Lamp71] B.W. Lampson, Protection. 5th Princeton Symposium on information science and systems. Pages 437-443.
8. [San92] Ravi Sandhu, The Typed Access Matrix Control Model. Proceeding Symposium on Security and Privacy, Oakland, CA, May 4-6, 1992, pages 122-136.
9. [San97] Ravi Sandhu. Rationale for the RBAC96 family of access control models. In proceeding of the 1st ACM Workshop on Role-Based Access Control. ACM, 1997.
10. [SB97] Ravi Sandhu and Venkata Bhamidipati. Role-based administration of user-role assignment: The UR97 model and its Oracle implementation. In Proceedings of IFIP WG11.3 Workshop on Data Security. August 1997.
11. [SCFY96] Ravi S.Sandhu, Edward J. Coyne, Hal L. Feinstein and Charles E. Youman. Role-based access control models. IEEE Computer, 29(2):38-47, February 1996.
12. Материалы сайта www.sql.ru
13. Смирнов С.Н., «Работаем с Oracle», изд-во Гелиос, 1998г.
14. Oracle 9i Database Online Documentation.
15. Oracle 8i Administrator’s Guide.
Операционная система Аутентификация по протоколу Kerberos в Windows 2000 Информационный документ Краткий обзор В операционной системе Microsoft® Windows® нового поколения аутентификация пользователей производится по умолчанию с помощью протокола Kerberos. Этот развивающийся стандарт создает надежную основу взаимодействия между различными платформами и при этом значительно повышает безопасность сетевой аутентификации в сетях предприятий. В Windows 2000 применяется протокол Kerberos версии 5, дополненный расширениями аутентификации с открытым ключом. Безопасность системы обеспечивает клиент Kerberos с помощью интерфейса Security Support Provider Interface. Первоначальная проверка пользователя производится в рамках архитектуры Winlogon, которая обеспечивает единую регистрацию пользователей в системе. Центр распределения ключей Key Distribution Center (KDC), входящий в Kerberos, интегрирован с другими службами безопасности Windows 2000, установленными на контроллере домена. Учетные записи безопасности хранятся в базе данных службы каталога Active Directory соответствующего домена. В настоящем документе рассматриваются различные компоненты данного протокола и подробно описывается его практическая реализация.
© 1999 Корпорация Microsoft. Все права защищены.
Информация, включенная в настоящий документ, отражает текущую точку зрения корпорации Microsoft по обсуждаемым вопросам на момент публикации. Microsoft постоянно совершенствует свои продукты, ей приходится реагировать на меняющиеся условия рынка, поэтому изложенная информация не должна восприниматься как обязательства со стороны Microsoft. Кроме того, корпорация Microsoft не может гарантировать точность любой информации, представленной после выпуска настоящего документа. Предлагаемый информационный документ предназначен только для информационных целей. MICROSOFT НЕ ДАЕТ В ЭТОМ ДОКУМЕНТЕ НИКАКИХ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ. Microsoft, Active Desktop, BackOffice, логотип BackOffice, MSN, Windows и Windows NT являются зарегистрированными товарными знаками корпорации Microsoft, которые официально признаны на территории как США, так и других стран. Названия других продуктов и фирм, приводимые в настоящем документе, могут быть защищены законом об авторских правах и являться собственностью их владельцев. Корпорация Microsoft; One Microsoft Way • Redmond, WA 98052-6399 • USA0999
СОДЕРЖАНИЕ ВВЕДЕНИЕ 1 Аутентификация в Windows 2000 1 Преимущества аутентификации по протоколу Kerberos 1 Стандарты аутентификации по протоколу Kerberos 2 Расширения протокола Kerberos 3 ОБЗОР ПРОТОКОЛА KERBEROS 4 Основные концепции 4 Аутентификаторы 5 Управление ключами 6 Сеансовые мандаты 8 Мандаты на выдачу мандатов 10 Аутентификация за пределами домена 11 Подпротоколы 13 Подпротокол AS Exchange 13 Подпротокол TGS Exchange 14 Подпротокол CS Exchange 15 Мандаты 16 Что такое мандат 16 Какие данные из мандата известны клиенту 17 Как служба KDC ограничивает срок действия мандата 17 Что происходит после истечения срока действия мандата 18 Обновляемые мандаты TGT 18 Делегирование аутентификации 19 Представительские мандаты 19 Передаваемые мандаты 20 КОМПОНЕНТЫ KERBEROS В WINDOWS 2000 21 Центр распределения ключей KDC 21 База данных учетных записей 22 Политика Kerberos 23 Делегирование аутентификации 24 Предварительная аутентификация 24 Поставщик поддержки безопасности Kerberos 24 Кэш-память удостоверений 25 Разрешение имен DNS 26 Транспорт IP 27 ДАННЫЕ АВТОРИЗАЦИИ 29 Контроль доступа в Windows 2000 29 Как KDC готовит данные авторизации 30 Как данные авторизации используются службами 31 Зачем подписывать данные авторизации 32 ИНТЕРАКТИВНАЯ РЕГИСТРАЦИЯ 34 Процесс регистрации 34 Вход в систему по паролю 35 Вход в систему с помощью смарт-карты 37 Данные предварительной аутентификации 39 УДАЛЕННАЯ РЕГИСТРАЦИЯ 40 Интерфейс поставщика поддержки безопасности 40 Выбор поставщика поддержки безопасности 41 Пример: открытие файла на уделенном сервере 41 Процесс согласования с поставщиком поддержки безопасности 42 С чего клиент начинает процесс аутентификации 42 Что отвечает служба «Сервер» 42 Взаимная аутентификация 43 Пример: междоменная аутентификация 43 ВОПРОСЫ СОВМЕСТИМОСТИ 47 Сценарии 47 Дополнительная информация 48
ВВЕДЕНИЕ Настоящий документ представляет технические аспекты реализации протокола аутентификации Kerberos 5 в операционной системе Microsoft® Windows® 2000. Здесь приводится подробное описание некоторых наиболее важных концепций, архитектурных элементов, а также функций аутентификации по протоколу Kerberos. Первый раздел «Обзор протокола Kerberos» рассчитан на тех, кто не знаком с аутентификацией по этому протоколу. Несколько последующих разделов посвящено более подробному описанию того, как Microsoft реализовала Kerberos в своей операционной системе Windows 2000. Завершается информационный документ кратким обсуждением вопросов взаимодействия описываемого протокола с другими его реализациями. Аутентификация в Windows 2000 Windows 2000 поддерживает несколько протоколов, которые помогают убедиться, что входящий в систему пользователь в самом деле имеет здесь свою учетную запись. Среди них – протоколы аутентификации удаленных подключений и протоколы аутентификации пользователей, входящих в сеть через Интернет. Однако внутри доменов Windows 2000 для проверки пользовательских данных предусмотрено всего два метода: • Kerberos версия 5. Протокол Kerberos 5 является стандартным средством аутентификации сетевых пользователей на всех компьютерах с операционной системой Windows 2000. • Windows NT LAN Manager (NTLM). Протокол NTLM применялся в качестве стандартного средства сетевой аутентификации в операционной системе Windows NT® 4.0. В среде Windows 2000 он используется для аутентификации серверов и доменов Windows NT 4.0. Кроме того, NTLM применяется для аутентификации на автономных компьютерах, работающих под управлением Windows 2000. Компьютеры под управлением Windows 3.11, Windows 95, Windows 98 и Windows NT 4.0 смогут использовать протокол NTLM для сетевой аутентификации в доменах Windows 2000. Компьютерам же, работающим под управлением Windows 2000, этот протокол обеспечит аутентификацию на серверах Windows NT 4.0 и откроет доступ к ресурсам доменов Windows NT 4.0. Однако в тех случаях, когда есть выбор, в среде Windows 2000 по умолчанию будет использоваться протокол Kerberos 5. Преимущества аутентификации по протоколу Kerberos Протокол Kerberos выгодно отличается от NTLM большей гибкостью и эффективностью использования. Обеспечивает он и повышенный уровень безопасности. Ряд преимуществ, которые дает переход на Kerberos, приводится ниже. • Более эффективная аутентификация на серверах. При аутентификации по протоколу NTLM серверу приложений приходится подключаться к контроллеру домена при проверке каждого клиента. С Kerberos такая необходимость отпадает – здесь аутентификация производится за счет проверки удостоверения, представленного клиентом. Индивидуальное удостоверение клиент получает от конкретного сервера единожды, после чего может неоднократно использовать его на протяжении всего сеанса работы в сети. • Взаимная аутентификация. Протокол NTLM позволяет серверу идентифицировать своих клиентов, однако не предусматривает верификации сервера ни клиентами, ни другими серверами. Этот протокол разрабатывался для сетей, в которых все серверы считаются легитимными. В отличие от него Kerberos такого допущения не делает, поэтому проверяет обоих участников сетевого подключения, каждый из которых в результате может точно узнать, с кем поддерживает связь. • Делегированная аутентификация. Когда клиент сети Windows обращается к ресурсам, службы операционной системы прежде всего производят его идентификацию. Во многих случаях для выполнения этой операции службе достаточно информации на локальном компьютере. Как NTLM, так и Kerberos обеспечивают все данные, необходимые для идентификации пользователя на месте, однако иногда их бывает недостаточно. Некоторые распределенные приложения требуют, чтобы при подключении к серверным службам на других компьютерах идентификация клиента производилась локально службой самого этого клиента. Решить проблему помогает Kerberos, где предусмотрен специальный механизм представительских мандатов, который позволяет на месте идентифицировать клиента при его подключении к другим системам. В протоколе NTLM такая возможность отсутствует. • Упрощенное управление доверительными отношениями. Одно из важных достоинств взаимной аутентификации по протоколу Kerberos состоит в том, что доверительные отношения между абонентами безопасности (security authority) доменов Windows 2000 по умолчанию являются двусторонними и переходными. Благодаря этому в сетях со множеством доменов больше не придется плести сложную паутину явно выраженных доверительных отношений между каждой парой доменов. Вместо этого все домены большой сети можно свести в дерево переходных отношений взаимного доверия. Удостоверение, выданное системой безопасности для любого домена, может приниматься во всех ветвях дерева. Если же сеть содержит несколько деревьев, то удостоверение любого из них будет приниматься по всему «лесу». • Совместимость. В основу своей реализации протокола Kerberos корпорация Microsoft положила стандартные спецификации, рекомендованные группой IETF. Благодаря такому подходу удалось обеспечить аутентификацию клиентов Windows 2000 во всех сетях, которые поддерживают Kerberos 5. Стандарты аутентификации по протоколу Kerberos Протокол Kerberos впервые увидел свет десять с лишним лет назад, создан он был в Массачусетском технологическом институте в рамках проекта Athena . Однако общедоступным этот протокол стал лишь после появления версии 4. После того, как специалисты отрасли изучили новый протокол, его авторы разработали и предложили пользователям очередную версию – Kerberos 5, которая и была принята в качестве стандарта IETF. Реализация протокола в Windows 2000 выполнена в строгом соответствии с требованиями, изложенными в документе RFC 1510 . Кроме того, при ее разработке были использованы механизм и формат передачи жетонов безопасности в сообщениях Kerberos, описанные в спецификациях Интернета из документа RFC 1964 . Расширения протокола Kerberos В Windows 2000 нашли применение расширения протокола Kerberos, упрощающие начальную аутентификацию клиентов. Обычно для этой цели используются секретные ключи, которыми должны заранее обменяться между собой участники сеанса, но теперь такую процедуру можно провести с помощью открытых ключей. Благодаря этому появилась возможность интерактивной регистрации пользователя с помощью микропроцессорных карточек. В основу расширений, обеспечивающих аутентификацию с открытым ключом, положен проект спецификации, который сейчас рассматривается в рабочей группе IETF. Он внесен рядом независимых разработчиков, заинтересованных в развитии технологий шифрования с открытым ключом . Корпорация Microsoft также принимает участие в рассмотрении этого стандарта и впредь намерена поддерживать работы в данном направлении. ОБЗОР ПРОТОКОЛА KERBEROS Протокол аутентификации Kerberos предлагает механизм взаимной идентификации клиента и сервера (или двух серверов) перед установлением связи между ними. В протоколе учтено, что начальный обмен информацией между клиентами и серверами происходит в открытой среде, не обеспечивающей физической безопасности большинства компьютеров, а пакеты, передаваемые по каналам связи, могут быть перехвачены и модифицированы. Другими словами, протокол предназначен для работы в среде, которая очень напоминает сегодняшний Интернет. Здесь злоумышленник легко может имитировать запросы клиента или сервера, перехватывать связь между легитимными клиентами и серверами, даже искажать передаваемую информацию. Основные концепции Протокол Kerberos активно использует технологии аутентификации, опирающиеся на «секреты для двоих». Основная концепция довольно проста: если есть секрет, известный только двоим, любой из его хранителей может легко удостовериться, что имеет дело именно со своим напарником. Для этого ему достаточно каким-либо способом проверить, знает ли собеседник их общий секрет. Рассмотрим это на простом примере. Допустим, Алиса часто посылает сообщения Бобу, который использует содержащуюся в них информацию только тогда, когда полностью уверен, что она поступила именно от Алисы. Чтобы никто другой не смог подделать письма, они договорились о пароле, который пообещали никому больше не говорить. Если из сообщения можно будет заключить, что отправитель знает этот пароль, Боб может точно сказать: оно пришло от Алисы. Теперь Бобу и Алисе остается только решить, каким образом показать свое знание пароля. Можно, скажем, просто включить его в текст сообщения, например, после подписи: «Alice, Our$ecret». Это было бы очень просто, удобно и надежно, если бы Алиса и Боб были уверены, что никто другой не читает их сообщений. К сожалению, об этом можно только мечтать. Почта передается по сети, где работают и другие пользователи. А среди них есть Кэрол, которая очень любит подключать к сети свой анализатор пакетов в надежде выведать чьи-нибудь секреты. И становится совершенно ясно, что Алиса не может просто назвать пароль в тексте письма. Чтобы секрет оставался секретом, о нем нельзя говорить открыто, нужно найти способ только дать знать собеседнику, что он тебе известен. В протоколе Kerberos эта проблема решается средствами криптографии с секретным ключом. Вместо того, чтобы сообщать друг другу пароль, участники сеанса обмениваются криптографическим ключом, знание которого подтверждает личность собеседника. Но чтобы такая технология оказалась работоспособной, общий ключ должен быть симметричным, то есть, обеспечивать как шифрование, так и дешифрование. Один из участников использует такой ключ для шифрования блока информации, а другой с его помощью извлекает эту информацию. Аутентификаторы Простой протокол аутентификации с секретным ключом вступает в действие, когда кто-либо стучится в сетевую дверь и просит впустить его. Чтобы доказать свое право на вход, пользователь предъявляет аутентификатор (authenticator) в виде блока информации, зашифрованного с помощью секретного ключа. Содержание этого блока должно меняться при каждом последующем сеансе, в противном случае злоумышленник вполне может проникнуть в систему, воспользовавшись перехваченным сообщением. Получив аутентификатор, привратник расшифровывает его и проверяет полученную информацию, чтобы убедиться в успешности дешифрования. Если все прошло нормально, страж может быть уверен, что человеку, предъявившему аутентификатор, известен секретный ключ. А ведь этот ключ знают всего двое, причем один из них – сам привратник. Таким образом, можно он делает вывод, что пришелец в самом деле тот человек, за которого себя выдает. Но может случиться и так, что постучавшийся в дверь захочет провести взаимную аутентификацию. В этом случае используется тот же самый протокол, но в обратном порядке и с некоторыми изменениями. Теперь привратник извлекает из исходного аутентификатора часть информации, а затем шифрует ее, превращая в новый аутентификатор, и в таком виде возвращает пришельцу. Тот, в свою очередь, расшифровывает полученную информацию и сравнивает ее с исходной. Если все совпадает, пришелец может быть уверен: если привратник дешифровал оригинал, значит, он знает секретный ключ. А теперь вернемся к нашему примеру. Предположим, Алиса и Боб договорились: перед тем, как пересылать информацию между своими компьютерами, они с помощью известного только им двоим секретного ключа будут проверять, кто находится на другом конце линии. В ситуации, когда Алиса играет роль осторожного гостя, а Боб – бдительного привратника, это будет выглядеть так. 1. Алиса посылает Бобу сообщение, содержащее ее имя в открытом виде и аутентификатор, зашифрованный с помощью секретного ключа, известного только им двоим. В протоколе аутентификации такое сообщение представляет собой структуру данных с двумя полями. Первое поле содержит информацию об Алисе, так сказать, ее имя. Во втором поле указывается текущее время на рабочей станции Алисы. 2. Боб получает сообщение и видит, что оно пришло от кого-то, кто называет себя Алисой. Он сразу же достает ключ, которым они с Алисой договорились шифровать аутентификатор, и, дешифровав второе поле, узнает время отправки сообщения. Задача Боба намного упрощается, если его компьютер работает синхронно с компьютером Алисы, поэтому давайте предположим, что оба они сверяют свои часы с сетевым временем, благодаря чему те идут практически одинаково. Допустим, часы на компьютерах Алисы и Боба никогда не расходятся больше, чем на пять минут. В этом случае Боб может сравнить извлеченное из второго поля аутентификатора значение с текущим временем на своих часах. Если различие составит более пяти минут, компьютер автоматически откажется признавать подлинность аутентификатора. Если же время оказывается в пределах допустимого отклонения, можно с большой долей уверенности предположить, что аутентификатор поступил именно от Алисы. Но Бобу этого мало, ему нужна полная уверенность. Ведь, рассуждает он, может быть и так: кто-то перехватил предыдущую попытку Алисы связаться со мной и теперь пытается воспользоваться ее аутентификатором. Впрочем, если на компьютере сохранились записи о времени аутентификаторов, поступивших от Алисы за последние пять минут, Боб может найти последний и отказаться от всех других сообщений, отправленных одновременно с ним или ранее. Но если второе поле свидетельствует, что сообщение ушло в сеть уже после отправки последнего аутентификатора Алисы, то и его автором вполне могла быть Алиса. 3. Боб шифрует время из сообщения Алисы с помощью их общего ключа и включает его в собственное сообщение, которое направляет Алисе. Обратите внимание, что Боб возвращает Алисе не всю информацию из ее аутентификатора, а только время. Если бы он отправил все сразу, у Алисы закралось бы подозрение, что кто-то, решив притвориться Бобом, просто скопировал аутентификатор из ее исходного сообщения и без каких-либо изменений отправил его назад. Но в полученном письме содержится только часть информации, а это значит, что получатель исходного аутентификатора смог дешифровать его и обработать содержащуюся там информацию. А время он выбрал потому, что это поле является уникальным идентификатором сообщения Алисы. Алиса получает ответ Боба, дешифрует его, а затем сравнивает полученный результат со временем, которое было указано в исходном аутентификаторе. Если эти данные совпадают, она может быть уверена, что ее аутентификатор дошел до того, кто знает их с Бобом секретный ключ. Этот человек смог расшифровать сообщение и извлечь из него информацию о времени. Поскольку ни она, ни Боб никому свой ключ не передавали, Алиса делает вывод, что именно Боб получил ее аутентификатор и ответил на него.
Рис. 1. Взаимная аутентификация (Алиса-Боб) Управление ключами При использовании простых протоколов наподобие описанного выше возникает одна очень важная проблема. В случае с Алисой и Бобом мы ни слова не сказали о том, как и где они договаривались о секретном ключе для своей переписки. Конечно, люди могут просто встретиться в парке и обсудить все детали, но ведь в сетевых переговорах участвуют машины. Если под Алисой понимать клиентскую программу, установленную на рабочей станции, а под Бобом – службу на сетевом сервере, то встретиться они никак не могут. Проблема еще более осложняется в тех случаях, когда Алисе – клиенту – нужно посылать сообщения на несколько серверов, ведь для каждого из них придется обзавестись отдельным ключом. Да и службе по имени Боб потребуется столько секретных ключей, сколько у нее клиентов. Но если каждому клиенту для поддержания связи с каждой службой требуется индивидуальный ключ, и такой же ключ нужен каждой службе для каждого клиента, то проблема обмена ключами очень быстро приобретает предельную остроту. Необходимость хранения и защиты такого множества ключей на огромном количестве компьютеров создает невероятный риск для всей системы безопасности. Само название протокола Kerberos говорит о том, как здесь решена проблема управления ключами. Кербер (или Цербер) – персонаж классической греческой мифологии. Этот свирепый пес о трех головах, по поверьям греков, охраняет врата подземного царства мертвых. Трем головам Кербера в протоколе Kerberos соответствуют три участника безопасной связи: клиент, сервер и доверенный посредник между ними. Роль посредника здесь играет так называемый центр распределения ключей Key Distribution Center или, сокращенно, KDC. KDC представляет собой службу, работающую на физически защищенном сервере. Она ведет базу данных с информацией об учетных записях всех главных абонентов безопасности (security principal) своей области (области Kerberos в сетях Windows 2000 соответствует домен, поэтому в дальнейшем мы будем применять именно этот привычный термин). Вместе с информацией о каждом абоненте безопасности в базе данных KDC сохраняется криптографический ключ, известный только этому абоненту и службе KDC. Данный ключ, который называют долговременным, используется для связи пользователя системы безопасности с центром распределения ключей. В большинстве практических реализаций протокола Kerberos долговременные ключи генерируются на основе пароля пользователя, указываемого при входе в систему. Когда клиенту нужно обратиться к серверу, он прежде всего направляет запрос в центр KDC, который в ответ направляет каждому участнику предстоящего сеанса копии уникального сеансового ключа (session key), действующие в течение короткого времени. Назначение этих ключей – проведение аутентификации клиента и сервера. Копия сеансового ключа, пересылаемая на сервер, шифруется с помощью долговременного ключа этого сервера, а направляемая клиенту – долговременного ключа данного клиента.
Рис. 2. Управление ключами (в теории) Теоретически, для выполнения функций доверенного посредника центру KDC достаточно направить сеансовые ключи непосредственно абонентам безопасности, как показано выше. Однако на практике реализовать такую схему чрезвычайно сложно. Прежде всего, серверу пришлось бы сохранять свою копию сеансового ключа в памяти до тех пор, пока клиент не свяжется с ним. А ведь сервер обслуживает не одного клиента, поэтому ему нужно хранить пароли всех клиентов, которые могут потребовать его внимания. В таких условиях управление ключами требует значительной затраты серверных ресурсов, что ограничивает масштабируемость системы. Нельзя забывать и о превратностях сетевого трафика. Они могут привести к тому, что запрос от клиента, уже получившего сеансовый пароль, поступит на сервер раньше, чем сообщение KDC с этим паролем. В результате серверу придется повременить с ответом до тех пор, пока он не получит свою копию сеансового пароля. То есть, нужно будет сохранить состояния сервера, а это накладывает на его ресурсы еще одно тяжкое бремя. Поэтому на практике применяется другая схема управления паролями, которая делает протокол Kerberos гораздо более эффективным. Ее описание приводится ниже. Сеансовые мандаты В ответ на запрос клиента, который намерен подключиться к серверу, служба KDC направляет обе копии сеансового ключа клиенту, как показано на рис. 3. Сообщение, предназначенное клиенту, шифруется посредством долговременного ключа, общего для данного клиента и KDC, а сеансовый ключ для сервера вместе с информацией о клиенте вкладывается в блок данных, получивший название сеансового мандата (session ticket). Затем сеансовый мандат целиком шифруется с помощью долговременного ключа, который знают только служба KDC и данный сервер. После этого вся ответственность за обработку мандата, несущего в себе шифрованный сеансовый ключ, возлагается на клиента, который должен доставить его на сервер.
Рис. 3. Управление ключами (на практике) Обратите внимание, что в данном случае функции службы KDC ограничиваются генерацией мандата. Ей больше не нужно следить за тем, все ли отправленные сообщения доставлены соответствующим адресатам. Даже если какое-нибудь из них попадет не туда, – ничего страшного не случится. Расшифровать клиентскую копию сеансового ключа может только тот, кто знает секретный долговременный ключ данного клиента, а чтобы прочесть содержимое сеансового мандата, нужен секретный код сервера. Получив ответ KDC, клиент извлекает из него мандат и свою копию сеансового ключа, которые помещает в безопасное хранилище (оно располагается не на диске, а в оперативной памяти). Когда возникает необходимость связаться с сервером, клиент посылает ему сообщение, состоящее из мандата, который по-прежнему зашифрован с применением долговременного ключа этого сервера, и собственного аутентификатора, зашифрованного посредством сеансового ключа. Этот мандат в комбинации с аутентификатором как раз и составляет удостоверение, по которому сервер определяет «личность» клиента.
Рис. 4. Взаимная аутентификация (клиент-сервер) Сервер, получив «удостоверение личности» клиента, прежде всего с помощью своего секретного ключа расшифровывает сеансовый мандат и извлекает из него сеансовый ключ, который затем использует для дешифрования аутентификатора клиента. Если все проходит нормально, делается заключение, что удостоверение клиента выдано доверенным посредником, то есть, службой KDC. Клиент может потребовать у сервера проведения взаимной аутентификации. В этом случае сервер с помощью своей копии сеансового ключа шифрует метку времени из аутентификатора клиента и в таком виде пересылает ее клиенту в качестве собственного аутентификатора. Одно из достоинств применения сеансовых мандатов состоит в том, что серверу не нужно хранить сеансовые ключи для связи с клиентами. Они сохраняются в кэш-памяти удостоверений (credentials cache) клиента, который направляет мандат на сервер каждый раз, когда хочет связаться с ним. Сервер, со своей стороны, получив от клиента мандат, дешифрует его и извлекает сеансовый ключ. Когда надобность в этом ключе исчезает, сервер может просто стереть его из своей памяти. Такой метод дает и еще одно преимущество: у клиента исчезает необходимость обращаться к центру KDC перед каждым сеансом связи с конкретным сервером. Сеансовые мандаты можно использовать многократно. На случай же их хищения устанавливается срок годности мандата, который KDC указывает в самой структуре данных. Это время определяется политикой Kerberos для конкретного домена. Обычно срок годности мандатов не превышает восьми часов, то есть, стандартной продолжительности одного сеанса работы в сети. Когда пользователь отключается от нее, кэш-память удостоверений обнуляется и все сеансовые мандаты вместе с сеансовыми ключами уничтожаются. Мандаты на выдачу мандатов Как уже отмечалось, долговременный ключ пользователя генерируется на основе его пароля. Чтобы лучше понять это, вернемся к нашему примеру. Когда Алиса проходит регистрацию, клиент Kerberos, установленный на ее рабочей станции, пропускает указанный пользователем пароль через функцию одностороннего хеширования (все реализации протокола Kerberos 5 должны обязательно поддерживать алгоритм DES-CBC-MD5, хотя могут применяться и другие алгоритмы). В результате генерируется криптографический ключ. В центре KDC долговременные ключи Алисы хранятся в базе данных с учетными записями пользователей. Получив запрос от клиента Kerberos, установленного на рабочей станции Алисы, KDC обращается в свою базу данных, находит в ней учетную запись нужного пользователя и извлекает из соответствующего ее поля долговременный ключ Алисы. Такой процесс – вычисление одной копии ключа по паролю и извлечение другой его копии из базы данных – выполняется всего лишь один раз за сеанс, когда пользователь входит в сеть впервые. Сразу же после получения пользовательского пароля и вычисления долговременного ключа клиент Kerberos рабочей станции запрашивает сеансовый мандат и сеансовый ключ, которые используются во всех последующих транзакциях с KDC на протяжении текущего сеанса работы в сети. На запрос пользователя KDC отвечает специальным сеансовым мандатом для самого себя, так называемый мандат на выдачу мандатов (ticket-granting ticket), или мандат TGT. Как и обычный сеансовый мандат, мандат TGT содержит копию сеансового ключа для связи службы (в данном случае – центра KDC) с клиентом. В сообщение с мандатом TGT также включается копия сеансового ключа, с помощью которой клиент может связаться с KDC. Мандат TGT шифруется посредством долговременного ключа службы KDC, а клиентская копия сеансового ключа – с помощью долговременного ключа пользователя. Получив ответ службы KDC на свой первоначальный запрос, клиент дешифрует свою копию сеансового ключа, используя для этого копию долговременного ключа пользователя из своей кэш-памяти. После этого долговременный ключ, полученный из пользовательского пароля, можно удалить из памяти, поскольку он больше не понадобится: вся последующая связь с KDC будет шифроваться с помощью полученного сеансового ключа. Как и все другие сеансовые ключи, он имеет временный характер и действителен до истечения срока действия мандата TGT, либо до выхода пользователя из системы. По этой причине такой ключ называют сеансовым ключом регистрации (logon session key). С точки зрения клиента мандат TGT почти ничем не отличается от обычного. Перед подключением к любой службе, клиент прежде всего обращается в кэш-память удостоверений и достает оттуда сеансовый мандат нужной службы. Если его нет, он начинает искать в этой же кэш-памяти мандат TGT. Найдя его, клиент извлекает оттуда же соответствующий сеансовый ключ регистрации и готовит с его помощью аутентификатор, который вместе с мандатом TGT высылает в центр KDC. Одновременно туда направляется запрос на сеансовый мандат для требуемой службы. Другими словами, организация безопасного доступа к KDC ничем не отличается от организации такого доступа к любой другой службе домена – она требует сеансового ключа, аутентификатора и мандата (в данном случае мандата TGT). С точки же зрения службы KDC, мандаты TGT позволяют ускорить обработку запросов на получением мандатов, сэкономив несколько наносекунд на пересылке каждого из них. Центр распределения ключей KDC обращается к долговременному ключу пользователя только один раз, когда предоставляет клиенту первоначальный мандат на выдачу мандата. Во всех последующих транзакциях с этим клиентом центр KDC дешифрует мандаты TGT с помощью собственного долговременного ключа и извлекает из него сеансовый ключ регистрации, который использует для проверки подлинности аутентификатора клиента. Аутентификация за пределами домена Функции центра KDC можно разделить на две категории: службу аутентификации, в задачу которой входит генерация мандатов TGT, и службу выдачи мандатов, создающую сеансовые мандаты. Такое разделение труда позволяет применять протокол Kerberos и за пределами его «родного» домена. Клиент, получивший мандат TGT из службы аутентификации одного домена, теперь вполне может воспользоваться им для получения сеансовых мандатов в службах выдачи мандатов других доменов. Чтобы лучше понять принцип междоменной аутентификации, рассмотрим для начала простейшую сеть, содержащую всего два домена – «Восток» и «Запад». Предположим, что администраторы этих доменов являются сотрудниками одной организации или у них есть какие-либо другие веские причины уравнять пользователей второго домена со своими собственными. В любом из этих случаев наладить аутентификацию между доменами нетрудно, для этого достаточно договориться о едином междоменном ключе (в Windows 2000 такой ключ генерируется автоматически, когда между доменами устанавливаются доверительные отношения). Как только ключ создан, служба выдачи мандатов каждого домена регистрируется в центре KDC другого домена в качестве главного абонента безопасности. В результате служба выдачи мандатов каждого из доменов начинает рассматривать службу выдачи мандатов второго домена, как еще одну службу, мало чем отличающуюся от других. Благодаря этому клиент, прошедший аутентификацию и зарегистрировавшийся в системе, может запрашивать и получать сеансовые мандаты для нее. А теперь рассмотрим, что происходит, когда пользователь с учетной записью в домене «Восток» запрашивает доступ к серверу из домена «Запад». Прежде всего клиент Kerberos, установленный на рабочей станции этого пользователя, посылает запрос в службу выдачи мандатов своего домена, в котором просит выдать сеансовый мандат для доступа на нужный сервер. Служба выдачи мандатов домена «Восток» проверяет список своих абонентов безопасности и убеждается, что такого сервера среди них нет. Поэтому она направляет клиенту так называемый мандат переадресации (referral ticket), который представляет собой простой мандат TGT, зашифрованный с помощью междоменного ключа, общего для служб KDC доменов «Восток» и «Запад». Получив мандат переадресации, клиент использует его для подготовки другого запроса на сеансовый ключ. Однако на этот раз запрос пересылается в службу выдачи мандатов того домена, где находится учетная запись нужного сервера, то есть, домена «Запад». Его служба выдачи мандатов пытается расшифровать мандат переадресации с помощью собственной копии междоменного ключа. Если попытка удается, центр KDC направляет клиенту сеансовый мандат на доступ к соответствующему серверу своего домена. Процесс переадресации запроса значительно усложняется в сетях, где развернуто более двух доменов. Теоретически служба KDC каждого домена может установить непосредственную связь с аналогичными службами всех доменов сети, договорившись с каждой из них об индивидуальном междоменном ключе. Однако на практике количество и сложность подобных взаимосвязей очень быстро возрастают до такой степени, что становятся просто неуправляемыми, особенно в сложных сетях. Протокол Kerberos решает эту проблему, делая ненужными прямые связи между доменами. Клиент одного домена может получить мандат на доступ к серверу другого домена через один или несколько промежуточных серверов, каждый из которых выдаст ему мандат переадресации. В качестве примера рассмотрим сеть, состоящую из трех доменов: «Восток», «Запад» и «ШтабКвартира». В службе KDC домена «Восток» нет междоменного ключа для аналогичной службы домена «Запад», но центры распределения ключей обоих доменов наладили обмен мандатами с доменом «ШтабКвартира». Когда пользователь с учетной записью в домене «Восток» хочет подключиться к серверу домена «Запад», его запрос будет передресован дважды. Сначала он пройдет через службу KDC «родного» домена, затем – через промежуточный домен «ШтабКвартира» и, наконец, достигнет центра распределения ключей домена «Запад», которому известен ключ нужного сервера. Таким образом, клиент здесь посылает сеансовые мандаты трижды в три различные службы KDC. 1. Клиент запрашивает у службы KDC домена «Восток» мандат на доступ к серверу домена «Запад». Служба KDC домена «Восток» направляет клиенту мандат переадресации в службу KDC домена «ШтабКвартира», зашифрованный междоменным ключом, общим для доменов «Восток» и «ШтабКвартира». 2. Клиент обращается в службу KDC домена «ШтабКвартира» с просьбой о мандате на доступ к серверу домена «Запад». Служба KDC домена «ШтабКвартира» направляет клиенту мандат переадресации в службу KDC домена «Запад», зашифрованный междоменным ключом, общим для доменов «ШтабКвартира» и «Запад». 3. Клиент обращается в службу KDC домена «Запад» с просьбой о мандате на доступ к серверу домена «Запад». Служба KDC домена «Запад» направляет клиенту мандат на доступ к нужному серверу. Подпротоколы Протокол Kerberos содержит в себе три подпротокола. Первый из них используется службой KDC для передачи клиенту сеансового ключа регистрации и мандата TGT. Он называется Authentication Service Exchange (обмен между службами аутентификации) или, сокращенно AS Exchange. Второй подпротокол под названием Ticket-Granting Service Exchange (обмен между службами выдачи мандатов) или TGS Exchange служит для рассылки служебных сеансовых ключей и сеансовых ключей самой службы KDC. Третий подпротокол, Client/Server Exchange (клиент-серверный обмен) или CS Exchange, используется клиентом для пересылки сеансового мандата доступа к службам. Чтобы лучше разобраться в том, как эти подпротоколы взаимодействуют между собой, давайте посмотрим, что происходит, когда Алиса, пользователь рабочей станции, обращается к Бобу, сетевой службе. Подпротокол AS Exchange Прежде всего Алиса входит в сеть, для чего вводит свое пользовательское имя и пароль. Клиент Kerberos, установленный на ее рабочей станции, преобразует пароль в криптографический ключ и сохраняет полученный результат в кэш-памяти удостоверений. После этого клиент посылает в службу аутентификации центра KDC запрос KRB_AS_REQ (Kerberos Authentication Service Request – запрос к службе аутентификации Kerberos). Первая часть его сообщения содержит идентификатор пользователя, то есть Алисы, а также имя службы, для которой ей нужно удостоверение, то есть службы выдачи мандатов. Во второй же части указываются данные предварительной аутентификации (pre-authentication data), которые подтверждают, что Алиса знает пароль. Обычно в качестве таких данных используется метка времени, зашифрованная долговременным ключом Алисы, хотя Kerberos допускает и другие виды предаутентификационных данных.
Рис. 5. Подпротокол AS Exchange Получив запрос KRB_AS_REQ, служба KDC обращается в свою базу данных и находит в ней долговременный ключ Алисы, после чего расшифровывает данные предварительной аутентификации и оценивает метку времени, содержащуюся в них. Если проверка прошла успешно, служба KDC делает вывод, что данные предварительной аутентификации были зашифрованы долговременным ключом Алисы и, следовательно, поступили от клиента, имя которого содержится в первой части сообщения. После того, как проверка личности Алисы завершена, служба KDC генерирует удостоверение, подтверждающее, что клиент Kerberos на ее рабочей станции имеет право обратиться к службе выдачи мандатов. Этот процесс выполняется в два этапа. Во-первых, KDC создает сеансовый ключ регистрации и шифрует его копию с помощью долговременного ключа Алисы. Во-вторых, служба включает еще одну копию сеансового ключа регистрации в мандат TGT. Туда же заносятся и другая информация об Алисе, например, ее данные авторизации. Затем KDC шифрует мандат TGT собственным долговременным ключом и, наконец, включает шифрованный сеансовый ключ регистрации вместе с мандатом TGT в пакет KRB_AS_REP (Kerberos Authentication Service Reply – ответ службы аутентификации Kerberos), который направляет клиенту. Получив такое сообщение, клиент вновь генерирует ключ на основе пароля Алисы, расшифровывает с его помощью сеансовый ключ регистрации и сохраняет его в кэш-памяти удостоверений. После этого из сообщения извлекается мандат TGT, который также помещается в эту кэш-память. Подпротокол TGS Exchange Клиент Kerberos, установленный на рабочей станции Алисы, запрашивает удостоверение на доступ к службе Боб, для чего посылает в службу KDC сообщение KRB_TGS_REQ (Kerberos Ticket-Granting Service Request – запрос к службе выдачи мандатов Kerberos). В него включается имя пользователя, аутентификатор, зашифрованный с помощью сеансового ключа регистрации Алисы, мандат TGT, который был получен с помощью подпротокола AS Exchange, а также имя службы, на доступ к которой нужен мандат.
Рис. 6. Подпротокол TGS Exchange Получив запрос KRB_TGS_REQ, служба KDC с помощью собственного секретного ключа дешифрует мандат TGT и извлекает из него сеансовый ключ регистрации Алисы, который тут же использует для расшифровки аутентификатора. Если содержимое аутентификатора выдерживает проверку, служба KDC извлекает из мандата TGT регистрационные данные Алисы и на их основе генерирует сеансовый ключ, общий для клиента Алисы и службы Боб. Одну копию этого ключа KDC шифрует с помощью сеансового ключа регистрации Алисы, а другую вместе с данными авторизации Алисы помещает в мандат, который шифрует с помощью долговременного ключа Боба. После этого удостоверение Алисы включается в пакет KRB_TGS_REP (Kerberos Ticket-Granting Service Reply – ответ службы выдачи мандатов Kerberos) и направляется на ее рабочую станцию. Получив такое сообщение, клиент с помощью сеансового ключа регистрации Алисы расшифровывает сеансовый ключ доступа к службе и помещает его в кэш-память удостоверений. После этого клиент извлекает мандат на доступ к службе и сохраняет его в той же кэш-памяти. Подпротокол CS Exchange Клиент Kerberos, установленный на рабочей станции Алисы, обращается к службе Боб, для чего посылает на нее запрос KRB_AP_REQ (Kerberos Application Request – запрос приложения Kerberos). Это сообщение содержит аутентификатор Алисы, зашифрованный посредством сеансового ключа для службы Боб, мандат, полученный с помощью протокола TGS Exchange, а также флаг, указывающий о желании клиента провести взаимную аутентификацию (наличие или отсутствие этого флага определяется конфигурацией Kerberos; он устанавливается автоматически без запроса пользователя).
Рис. 7. Подпротокол CS Exchange Получив сообщение KRB_AP_REQ, служба Боб дешифрует мандат, извлекает из него данные авторизации Алисы и сеансовый ключ, с помощью которого сразу же расшифровывает аутентификатор Алисы. Если метка времени, заложенная в него, выдерживает проверку, Боб ищет в запросе флаг взаимной аутентификации. Найдя его, Боб шифрует метку времени из аутентификатора Алисы сеансовым ключом, включает полученный результат в пакет KRB_AP_REP (Kerberos Application Reply – ответ приложения Kerberos) и возвращает его на рабочую станцию Алисы. После получения пакета клиент рабочей станции Алисы дешифрует аутентификатор Боба, используя для этого сеансовый ключ, и сравнивает полученную метку времени с исходной. Если они совпадают, делается вывод, что связь установлена с нужной службой и можно приступать к обмену информацией. В ходе сеанса прикладные данные шифруются, как правило, с помощью сеансового ключа, но не обязательно – клиент и сервер могут воспользоваться в этих целях и другими ключами. Мандаты Выше мы говорили о мандатах лишь в общих чертах. Теперь пришло время более подробно рассмотреть, что же это такое, как рассчитывается срок годности мандата и какая его часть становится известной клиенту. Все эти детали важны для разработки политики Kerberos, поэтому к ним нужно присмотреться как можно ближе. Что такое мандат Для целей настоящего информационного документа достаточно перечислить поля мандата и описать содержащуюся в них информацию. Более подробно структура мандата и различных сообщений Kerberos описана в документе RFC 1510. Таблица 1. Поля мандата Название поля Описание Первые три поля мандата не шифруются. Содержащаяся здесь информация пересылается открытым текстом, что позволяет клиенту использовать ее для управления мандатами, хранящимися в кэш-памяти. tkt-vno Номер версии формата мандата. Для Kerberos 5 здесь указывается цифра 5. Realm Имя области (домена), где генерирован мандат. Служба KDC может создавать мандаты только для серверов собственной области, поэтому здесь, по существу, указывается имя области, где расположен сервер. Sname Имя сервера. Остальные поля шифруются с помощью секретного ключа сервера. Flags Флаги мандата. Key Сеансовый ключ. Crealm Имя области (домена) клиента. Cname Имя клиента. Transited Список областей Kerberos, принимавших участие в аутентификации клиента, которому выдан данный мандат. Authtime Время первоначальной аутентификации клиента. Служба KDC заполняет это поле в момент генерации мандата TGT. При генерации мандатов на основе мандата TGT временная метка из поля authtime мандата TGT копируется в поле authtime генерируемого мандата. Starttime Время вступления мандата в силу. Endtime Время истечения срока действия мандата. renew-till Наибольшее значение поля endtime, которое может быть задано с помощью флага RENEWABLE (поле необязательное). Caddr Один или несколько адресов, из которых может использоваться данный мандат. Поле необязательное. Если оно не заполнено, мандатом можно воспользоваться из любого адреса. Authorization-data Атрибуты привилегий клиента. Поле необязательное. Его содержимое Kerberos не обрабатывает – оно интерпретируется службой. Содержимое поля flags адресуется побитно. Включение и выключение флагов здесь производится изменением значения (0 или 1) соответствующего бита. Длина поля – 32 разряда, однако для администратора Kerberos интерес представляют только 9 флагов мандата. Таблица 2. Флаги мандата Флаг Описание FORWARDABLE Указывает, что на основании данного мандата TGT служба выдачи мандатов может генерировать новый мандат TGT с другим сетевым адресом (поле имеется только в мандатах TGT). FORWARDED Указывает на то, что данный мандат TGT был переадресован или генерирован на основе другого мандата TGT, прошедшего переадресацию. PROXIABLE Указывает, что служба выдачи мандатов может генерировать мандаты, сетевой адрес которых будет отличаться от приведенного в данном мандате TGT (поле имеется только в мандатахTGT). PROXY Указывает на то, что сетевой адрес в данном мандате отличается от адреса, приведенного в мандате TGT, на основании которого он выдан. RENEWABLE Используется в сочетании с полями endtime и renew-till, разрешая периодическое обновление службой KDC мандатов с повышенным сроком действия. INITIAL Указывает, что данный мандат является мандатом выдачи мандатов (поле имеется только в мандатах TGT).
Какие данные из мандата известны клиенту Клиенту необходимо знать часть информации, содержащейся как в обычных мандатах, так и в мандатах TGT, чтобы управлять своей кэш-памятью удостоверений. Возвращая мандат и сеансовый ключ с помощью подпротоколов AS Exchange или TGS Exchange, служба KDC упаковывает клиентскую копию сеансового ключа в структуру данных, где уже могут быть заполнены поля flags, authtime, starttime, endtime и renew-till. Вся эта структура шифруется с помощью ключа клиента, включается в пакет KRB_AS_REP или KRB_TGS_REP и возвращается на рабочую станцию клиента. Как служба KDC ограничивает срок действия мандата В мандате указывается время начала и конца его действия. В течение этого промежутка клиент, которому выдан данный мандат, может неограниченное количество раз представить его для получения доступа к службе. Чтобы уменьшить риск компрометации мандата или соответствующего сеансового ключа, администратор вправе ограничить максимальный срок действия мандата. Этот срок является одним из элементов политики Kerberos. Запрашивая в центре KDC мандат для доступа к службе, клиент может указать конкретное время начала его действия. Если этого не сделано или заданное время уже минуло, центр KDC указывает в поле starttime текущее время. Но независимо от того, указал клиент время начала действия мандата или нет, запрос обязательно должен содержать время прекращения срока его действия. Получив такой запрос, служба KDC рассчитывает значение поля endtime. Для этого она суммирует наибольший срок действия мандата, предусмотренный политикой Kerberos, со значением поля starttime, а затем сравнивает полученный результат со временем прекращения действия мандата, указанным в запросе клиента. Если они не совпадают, в поле endtime заносится то время, которое наступит раньше. Что происходит после истечения срока действия мандата О скором истечении срока действия сеансового мандата или мандата TGT служба KDC не уведомляет клиента. Не следит она и за транзакциями с клиентом, если не считать краткосрочных записей, главная цель которых – предотвратить повторное использование перехваченных пакетов. Если клиент, пытаясь подключиться к серверу, передаст просроченный сеансовый мандат, то в ответ он получит сообщение об ошибке. В этом случае клиенту придется вновь обращаться в службу KDC и заказывать новый сеансовый мандат. Однако после аутентификации подключения срок действия сеансового мандата перестает играть какую-либо роль, поскольку он нужен только для подключения к серверу. Даже если срок действия сеансового мандата прекратится во время проведения сеанса, это никак не скажется на ходе текущих операций. Может случиться и так, что клиент включит просроченный мандат TGT в свой запрос на сеансовый мандат, который направит в службу KDC. В этом случае центр выдачи мандатов перешлет клиенту сообщение об ошибке, после чего клиенту придется запросить новый мандат TGT, а для этого ему понадобится долговременный ключ пользователя. Если в процессе начальной регистрации такой ключ не был занесен в кэш-память, система может попросить пользователя еще раз ввести свой пароль, на основании которого будет вновь рассчитан долговременный ключ. Обновляемые мандаты TGT Один из методов защиты сеансовых ключей состоит в частой их смене. С этой целью в политике Kerberos можно предусмотреть относительно небольшой максимальный срок действия мандатов. Но есть и другой способ – использовать обновляемые мандаты. При этом обеспечивается периодическое обновление сеансовых ключей без необходимости запрашивать совершенно новый мандат. Если политика Kerberos разрешает применение обновляемых мандатов, служба KDC включает в каждый генерируемый мандат флаг RENEWABLE и указывает два срока истечения его действия. Первый из них ограничивает жизнь текущего экземпляра мандата, а второй определяет общее время, в течение которого может использоваться мандат с учетом его обновлений. Время истечения срока действия текущего экземпляра мандата указывается в поле endtime. Как и в случае с необновляемыми мандатами, значение этого поля равно сумме значения из поля starttime и наибольшего срока действия мандатов, определенного политикой Kerberos. Клиент, использующий обновляемый мандат, должен представить его в службу KDC для обновления до времени, указанного в поле endtime. Одновременно с мандатом в центр распределения ключей направляется и новый аутентификатор. Получив мандат, который нужно обновить, служба KDC прежде всего проверяет общий срок его действия, указанный в поле renew-till. Это время задается при первичной генерации мандата. Оно определяется путем суммирования значения из поля starttime с максимально допустимым политикой Kerberos сроком действия мандата с учетом всех обновлений. Если указанное в поле renew-till время еще не наступило, служба KDC генерирует новый экземпляр мандата, где указывает более позднее время endtime и заменяет сеансовый ключ. Это дает администратору возможность предусмотреть в политике Kerberos сравнительно частое обновление мандатов, например, ежедневно. Смена сеансовых ключей при обновлении мандата намного снижает риск их компрометации. В то же время администратор может задать довольно длительное общее время использования мандата – неделю, месяц, а то и больше. По истечении этого срока мандат становится полностью непригодным для дальнейшего использования и обновлению не подлежит. Делегирование аутентификации Особую сложность для протокола Kerberos создают многоуровневые клиент-серверные приложения. Здесь клиент может подключаться к серверу, который, в свою очередь, должен будет подключиться к другому серверу более высокого уровня. Для этого первому серверу понадобится мандат на подключение ко второму. В идеале такой мандат должен ограничивать доступ первого сервера ко второму лишь теми функциями, на которые клиент имеет права. Для решения этой проблемы в протоколе Kerberos имеется специальный механизм – так называемое делегирование аутентификации. По существу, в такой ситуации клиент поручает свою аутентификацию серверу. С этой целью он уведомляет службу KDC о том, что данный сервер имеет право представлять клиента. Такой подход напоминает концепцию персонификации (concept of impersonation) Windows 2000. Делегирование аутентификации возможно двумя способами. Во-первых, клиент может получить мандат на подключение к серверу высшего уровня, а затем передать его ближайшему серверу. Мандаты, полученные таким способом – клиентом для ближайшего сервера – называются представительскими (proxy tickets). Однако на этом пути имеется одна серьезная трудность: чтобы получить представительский мандат, клиенту нужно знать имя сервера высшего уровня. Решить проблему помогает второй способ делегирования аутентификации. Здесь клиент передает на ближайший к нему сервер свой мандат TGT, который тот по мере необходимости использует для запроса собственных мандатов. Мандаты TGT, полученные таким образом, то есть, по удостоверению клиента, называются передаваемыми (forwarded tickets). Какой из описанных способов применяется службой KDC, зависит от политики Kerberos. Представительские мандаты Когда служба KDC приступает к генерации мандата TGT, она прежде всего обращается к политике Kerberos и проверяет, допускается ли применение представительских мандатов. Если да, центр управления мандатами выставляет в мандате TGT, который он готовит клиенту, флаг PROXIABLE. Чтобы получить представительский мандат, клиент пересылает свой мандат TGT в службу выдачи мандатов и запрашивает в ней мандат на подключение к серверу высшего уровня. В запросе выставляется специальный флаг, свидетельствующий о том, что нужен представительский мандат, а также указывается имя сервера, который будет являться представителем клиента. Получив такой запрос, служба KDC создает мандат на доступ к серверу высшего уровня, выставляет в нем флаг PROXY и отсылает в таком виде клиенту. Клиент затем направляет полученный мандат на сервер, который будет его представлять, а тот, в свою очередь, использует этот мандат для доступа к серверу высшего уровня. Передаваемые мандаты Клиент, который намерен делегировать свои права на получение мандата для доступа к серверу высшего уровня, должен запросить в службе KDC передаваемый мандат TGT. Это делается с помощью подпротокола AS Exchange. В запрос обязательно включается имя сервера, который будет представлять клиента. Если политика Kerberos допускает использование передаваемых мандатов, служба KDC генерирует мандат TGT на доступ данного клиента к серверу высшего уровня, выставляет в нем флаг FORWARDABLE и в таком виде направляет клиенту. Клиент, в свою очередь, пересылает полученный мандат TGT тому серверу, с которым работает непосредственно. Этот сервер, направляя мандат на сервер высшего уровня, представляет в службу KDC мандат TGT, полученный от клиента. Обнаружив в нем флаг FORWARDABLE, центр управления мандатами выставляет в новом мандате флаг FORWARDED и возвращает его первому серверу. КОМПОНЕНТЫ KERBEROS В WINDOWS 2000 Центр распределения ключей KDC В операционной системе Windows 2000 Центр распределения ключей (Key Distribution Center, KDC) реализован как служба домена. В качестве базы данных учетных записей он использует службу каталога Active Directory домена. Кроме того, некоторые данные о пользователях поступают в него из глобального каталога (Global Catalog). Как и в других реализациях протокола Kerberos, центр KDC Windows 2000 представляет собой единый процесс, объединяющий две службы: • Служба аутентификации Authentication Service (AS). Эта служба выдает мандаты на выдачу мандатов (мандаты TGT), открывающие доступ к службе выдачи мандатов своего домена. Прежде, чем получить мандат на обслуживание, сетевой клиент должен запросить первоначальный мандат TGT, обратившись для этого к службе аутентификации того домена, где находится учетная запись пользователя. • Служба выдачи мандатов Ticket-Granting Service (TGS). Эта служба выдает мандаты на доступ к другим службам своего домена или к службе выдачи мандатов доверяемого домена. Чтобы обратиться в службу TGS, клиенту нужно сначала войти в контакт со службой выдачи мандатов того домена, где находится учетная запись службы, представить свой мандат TGT и запросить нужный мандат. Если у клиента нет мандата TGT, который открывает доступ к данной службе выдачи мандатов, он может воспользоваться процессом переадресации (referral process). Начальной точкой этого процесса является служба того домена, где находится учетная запись пользователя, а конечной –служба выдачи мандатов домена, где находится учетная запись требуемой службы. Центр KDC, как и служба каталога Active Directory, имеется в каждом домене. Обе службы автоматически запускаются подсистемой LSA (Local Security Authority – распорядитель локальной безопасности), которая установлена на контроллере домена. Они работают в пространстве процессов этого распорядителя. Ни одну из этих служб остановить невозможно. Чтобы гарантировать постоянный доступ к KDC и Active Directory, в Windows 2000 предусмотрена возможность развертывания в каждом домене нескольких равноправных контроллеров домена. При этом запросы на аутентификацию и на выдачу мандата, адресованные службе KDC данного домена, может принимать любой контроллер домена. В доменах Windows 2000 служба KDC является абонентом безопасности. Как и предусмотрено документом RFC 1510, в этом качестве она выступает под именем krbtgt. Учетная запись абонента безопасности для нее создается автоматически при организации нового домена; эту запись нельзя ни изменить, ни переименовать. Пароль учетной записи KDC также присваивается автоматически, а затем регулярно меняется на плановой основе вместе с паролями доверенных учетных записей домена (domain trust account). Пароль учетной записи KDC используется при вычислении секретного ключа, необходимого для шифрования и дешифрования генерируемых этой службой мандатов TGT. Пароль же доверенной учетной записи домена необходим для расчета междоменных (межобластных) ключей, которые используются для шифрования мандатов переадресации. Все экземпляры службы KDC одного домена используют единую учетную запись абонента безопасности с именем krbtgt. При обращении к центру распределения ключей домена клиент должен указать как имя абонента безопасности krbtgt, так и имя домена. Эти сведения приводятся и в мандатах, где идентифицируют службу, выдавшую данный мандат. Подробная информация о формах имен и адресных конвенциях приведена в документе RFC 1510. База данных учетных записей База данных, которая необходима службе KDC для получения информации относительно абонентов безопасности, хранится в каталоге Active Directory домена. Каждый абонент здесь представлен в виде объекта учетной записи. Криптографические ключи, применяемые для связи с пользователем, компьютером или службой, хранятся в виде атрибутов объекта учетной записи конкретного абонента безопасности. Серверами службы каталога Active Directory являются только контроллеры доменов. На каждом из них хранится копия каталога, в которую можно вносить изменения. Это позволяет создавать новые учетные записи, изменять пароли и корректировать состав групп, обратившись на любой контроллер домена. Изменения, внесенные в одну реплику каталога, автоматически переносятся на все другие его реплики. Правда, Windows 2000 не использует для этой цели протокол репликации Kerberos. Копирование и распространение информации, хранящейся в Active Directory, производится посредством протокола децентрализованной репликации (multi-master replication protocol), разработанного корпорацией Microsoft , причем пересылка ее осуществляется по безопасным каналам между контроллерами доменов. Физическим хранением информации об учетных записях управляет агент DSA (Directory System Agent – агент каталожной системы). Этот защищенный процесс интегрирован с подсистемой LSA, также работающей на контроллере домена. Клиенты службы каталога никогда не получают прямого доступа к хранилищу с данными об учетных записях. Любой клиент, которому нужна каталожная информация, должен воспользоваться для подключения к DSA одним из поддерживаемых интерфейсов ADSI (Active Directory Service Interface – интерфейс служб Active Directory). Лишь после этого он может искать, читать и записывать каталожные объекты и их атрибуты. Запросы на доступ к объектам или атрибутам этого каталога подлежат проверке в механизмах управления доступом Windows 2000. Подобно объектам файлов и папок в файловой системе NTFS, объекты Active Directory защищаются посредством ACL (Access Control List – список управления доступом), где содержится информация о том, кто и каким способом имеет право обращаться к объектам. Правда, в объектах Active Directory, в отличие от файлов и папок, список управления доступом имеется для каждого атрибута. Благодаря этому появилась возможность вводить дополнительные ограничения на доступ к отдельным атрибутам, содержащим наиболее конфиденциальную информацию. Самым секретным элементом любой учетной записи, конечно же, является пароль. В объекте учетной записи атрибут пароля хранит не сам пароль, а криптографический ключ, полученный на его основе, однако этот ключ представляет для взломщика не меньшую ценность. По этой причине доступ к атрибуту пароля предоставляется исключительно владельцу учетной записи. Такого права не имеет никто другой, даже администратор. Прочесть информацию о пароле или изменить ее могут только процессы с привилегией Trusted Computer Base, которые работают в контексте безопасности LSA. В Windows 2000 приняты меры и против возможного взлома учетной записи изнутри, то есть, злоумышленником с доступом к резервным копиям доменного контроллера. Чтобы помешать этому, атрибут пароля в объекте учетной записи подвергается второму шифрованию с использованием системного ключа. Этот криптографический ключ может храниться на сменном носителе, для которого нетрудно предусмотреть дополнительные меры защиты, либо даже на контроллере домена, но под защитой механизма дисперсии (dispersal mechanism). Где хранить системный ключ, – выбирает администратор, одновременно определяя алгоритм шифрования атрибутов пароля. Политика Kerberos В среде Windows 2000 политика Kerberos определяется на уровне домена и реализуется службой KDC домена. Она сохраняется в каталоге Active Directory как подмножество атрибутов политики безопасности домена. По умолчанию вносить изменения в политику Kerberos имеют право только члены группы администраторов домена. В политике Kerberos предусматриваются: Примечание: Приведенные ниже значения по умолчанию не являлись стандартными в третьей бета-версии. • Максимальный срок действия пользовательского мандата (Maximum user ticket lifetime). Под «пользовательским мандатом» здесь имеется в виду мандат на выдачу мандатов (мандат TGT). Значение задается в часах и по умолчанию равно 10 час. • Максимальное время, в течение которого допускается обновление пользовательского мандата (Maximum lifetime that a user ticket can be renewed). Задается в сутках; по умолчанию составляет 7 суток. • Максимальный срок действия служебного мандата (Maximum service ticket lifetime). Под «служебным мандатом» здесь имеется в виду сеансовый мандат. Значение этого параметра должно быть более 10 минут, но менее значения Maximum user ticket lifetime. По умолчанию оно равно 10 час. • Максимально допустимое отклонение в синхронизации компьютерных часов (Maximum tolerance for synchronization of computer clocks). Указывается в минутах; по умолчанию равно 5 мин. • Проверка ограничений при входе пользователя в систему (Enforce user logon restrictions). Если этот пункт помечен флажком, служба KDC анализирует каждый запрос на сеансовый мандат и проверяет, имеет ли данный пользователь право на локальный вход в систему (привилегия Log on Locally) или на доступ к запрашиваемому компьютеру через сеть (привилегия Access this computer from network). Такая проверка занимает дополнительное время и может замедлить предоставление сетевых услуг, поэтому администратору предоставляется право ее отключения. По умолчанию она включена. Делегирование аутентификации Как уже отмечалось, политика Kerberos для домена может разрешать делегированную аутентификацию методом передаваемых мандатов, однако такое разрешение вовсе не обязательно должно распространяться на всех пользователей или на все компьютеры. Воспользовавшись атрибутом учетной записи конкретного пользователя, администратор может запретить передачу его удостоверения с одного сервера на другой. Кроме того, можно запретить передачу удостоверения любого пользователя, установив соответствующий атрибут в учетной записи какого-либо компьютера. При необходимости можно также запретить делегирование аутентификации всем пользователям или всем компьютерам, входящим о организационное подразделение внутри домена. Предварительная аутентификация По умолчанию служба KDC требует проведения предварительной аутентификации всех учетных записей, что предельно затрудняет атаки с подбором паролей. Однако такая функция может вызвать проблемы совместимости с другими реализациями протокола Kerberos, поэтому предусмотрена возможность ее отключения в отдельных учетных записях. Поставщик поддержки безопасности Kerberos Протокол аутентификации Kerberos реализован в форме поставщика поддержки безопасности (security support provider, сокращенно SSP) – динамически подключаемой библиотеки, входящей в состав операционной системы. В Windows 2000 предусмотрен также поставщик SSP для протокола NTLM. По умолчанию оба эти компонента загружаются подсистемой LSA на компьютер Windows 2000 одновременно с загрузкой операционной системы. Каждый из этих поставщиков позволяет производить аутентификацию как входа в сеть, так и клиент-серверных подключений. Какой поставщик будет использован в том или ином конкретном случае, зависит от возможностей компьютера, с которым устанавливается связь, однако в первую очередь система всегда пытается воспользоваться поставщиком Kerberos SSP. После того, как подсистема LSA создаст контекст безопасности для интерактивного пользователя, может потребоваться еще один экземпляр Kerberos SSP. Его загрузку производит процесс, запущенный в пользовательском контексте безопасности, чтобы обеспечить поддержку подписи и заверение сообщений. Системные службы и приложения транспортного уровня обращаются к SSP через интерфейс SSPI (Security Support Provider Interface – интерфейс поставщика поддержки безопасности) корпорации Microsoft. Он представляет собой интерфейс Win32®, позволяющий просмотреть список доступных на системе поставщиков, выбрать один из них и использовать его для организации аутентифицированного подключения. Выполнение всех этих функций производится в SSPI стандартизированными методами (method), своего рода подпрограммами «черного ящика», которыми разработчик может пользоваться, даже не разбираясь в тонкостях самого протокола. К примеру, при аутентификации клиент-серверного подключения пересылка удостоверения клиентского приложения на сервер производится с помощью метода InitializeSecurityContext. Если выбран поставщик Kerberos SSP, этот метод генерирует на клиентском компьютере сообщение KRB_AP_REQ. В ответ серверное приложение, используя метод AcceptSecurityContext, направляет на клиент сообщение KRB_AP_REP. Когда аутентификация подключения завершена, серверная подсистема LSA генерирует жетон доступа, основанный на информации из клиентского мандата. После этого сервер обращается к методу SSPI под названием ImpersonateSecurityContext и с его помощью прикрепляет жетон доступа к нити персонификации службы (impersonation thread for service). Для доступа к посреднику Kerberos SSP все распределенные службы Windows 2000 используют интерфейс SSPI. С помощью протокола Kerberos можно производить аутентификацию: • служб спулера печати; • доступа к удаленным файлам в файловой системе CIFS по протоколу SMB; • запросов к Active Directory по протоколу LDAP; • управления распределенной файловой системой и переадресации запросов в ней; • распорядителя безопасности при организации подключения между хост-компьютерами по протоколу IPSec; • резервирования ресурсов для обеспечения качества обслуживания в сети; • элементов интрасетей на сервере Internet Information Server; • управления удаленным сервером или рабочей станцией с использованием удаленного вызова процедур с их аутентификацией; • получения на сервере Microsoft Certificate Server сертификатов, необходимых для доступа к пользователям и компьютерам домена. Кэш-память удостоверений На компьютерах под управлением Windows 2000 мандаты и ключи, полученные из службы KDC, сохраняются в кэш-памяти удостоверений – области оперативной памяти, защищенной подсистемой LSA. Содержимое кэш-памяти удостоверений никогда не сбрасывается в файл подкачки. Выход абонента безопасности из системы и отключение самой системы приводят к уничтожению всех хранящихся здесь объектов. Управление кэш-памятью удостоверений возложено на поставщика Kerberos SSP, который работает в контексте безопасности подсистемы LSA. Каждый раз, когда возникает необходимость в получении мандата или ключа, либо в их обновлении, распорядитель LSA обращается к Kerberos SSP, который и выполняет эту задачу. В подсистеме LSA сохраняются также копии хешированных паролей интерактивных пользователей. Если в ходе сеанса работы истекает срок действия пользовательского мандата TGT, поставщик Kerberos SSP использует такую копию для получения нового мандата. Это делается в фоновом режиме, без прекращения сеанса. Пароль здесь находится во временном хранении, его локальная копия уничтожается после прекращения сеанса работы пользователя. По иному обстоит дело с хешированными паролями для служб и компьютеров. Как и в прежних версиях Windows NT, они сохраняются в безопасной области системного реестра компьютера. Реестр используется также для хранения хешированных паролей для учетных записей пользователей на локальных системах, однако локальные учетные записи пригодны исключительно для доступа к компьютерам, работающим в автономном режиме, но не через сеть. Разрешение имен DNS Согласно документу RFC 1510, для пересылки сообщений между клиентами и службой KDC должен использоваться протокол IP. Чтобы послать первоначальный запрос аутентификации, поставщику Kerberos SSP, установленному на клиентском компьютере, нужно найти адрес центра распределения ключей того домена, где находится учетная запись пользователя. Другими словами, необходимо знать имя сервера со службой KDC в доменной системе имен DNS. Если это имя может быть преобразовано в IP-адрес, Kerberos SSP направляет на него свое сообщение, если же нет, – выдается сигнал ошибки, указывающий на то, что домен не найден. Служба KDC устанавливается на всех контроллерах домена Windows 2000. Кроме функций серверов KDC эти контроллеры выполняют еще и функции серверов LDAP (Lightweight Directory Access Protocol – облегченный протокол доступа к каталогам). Обе эти службы регистрируются в записях указателя служб системы DNS (записях ресурсов SRV). Чтобы найти контроллер домена, клиенту достаточно запросить на сервере DNS запись ресурса SRV с именем _ldap._tcp.dc._msdcs.ИмяДоменаDNS. А запросив запись ресурса SRV с именем _kerberos._udp.ИмяДоменаDNS, клиент получит в ответ адрес службы KDC. Но есть и такие клиенты, преобразователи IP-адресов которых не поддерживают тип записей SRV. Им, чтобы найти нужный адрес, приходится запрашивать запись хост-компьютера (запись ресурса А) с именем требуемого домена. Компьютеры под управлением Windows 2000 могут обращаться и в те области Kerberos, которые не входят в домены Windows 2000. Здесь служба KDC размещается на доменных контроллерах, работающих под управлением других операционных систем, поэтому имена DNS для таких серверов KDC приходится сохранять к реестре клиентского компьютера. В этом случае поставщик Kerberos SSP сначала находит в реестре доменное имя DNS области пользователя, а затем запрашивает соответствующий сервер DNS и преобразует это имя в IP-адрес. В Windows 2000 имеется специальная инструментальная программа, помогающая настраивать клиенты для работы с областями Kerberos, которые не входят в домены Windows 2000. Она запускается файлом ksetup.exe из каталога Support на установочном компакт-диске Windows 2000. Транспорт IP В соответствии с документом RFC 1510, для подключения к службе KDC клиент должен послать дейтаграмму UDP (User Datagram Protocol – протокол дейтаграмм пользователя) на порт 88 соответствующего IP-адреса. Служба KDC отвечает дейтаграммой на тот порт IP-адреса отправителя, откуда поступил запрос. UDP относится к транспортным протоколам, не устанавливающим логического соединения, поэтому его применение вполне оправданно в тех случаях, когда организация подключения предусматривает предварительный обмен служебными сообщениями. Этот протокол хорошо подходит и там, где обмен ограничивается единственным запросом и единственным ответом на него, как это имеет место в сеансах связи между клиентом и службой KDC. Важно только, чтобы каждое такое сообщение полностью умещалось в одну дейтаграмму. Но наилучшие результаты применение протокола UDP дает в тех случаях, когда дейтаграммы передаются как единое целое, то есть, каждая из них полностью вписывается в один кадр. Емкость же кадра зависит от передающей среды. В кадре Ethernet, например, максимальный размер передаваемого блока данных (MTU) равен 1 500 октетов. Следовательно, в физических сетях Ethernet сообщения Kerberos, отправляемые в виде дейтаграмм, могут содержать до 1 500 октетов данных. В среде Windows 2000 объем данных, передаваемых при входе пользователя в сеть, может легко превысить это значение. В то же время такие данные используются только компьютерами под управлением Windows 2000, поэтому их можно смело исключить из мандатов, которые направляются на компьютеры с другими операционными системами. В результате размер таких сообщений значительно сокращается, и они вполне вписываются в рамки транспорта UDP. Именно этот протокол и используется для передачи мандатов. Сообщения же с мандатами для компьютеров Windows 2000 часто превышают предел в 1 500 байт, поэтому для их передачи используется протокол ТСР (Transport Control Protocol – протокол управления транспортом), отличающийся гораздо большей емкостью. Применение транспорта ТСР полностью согласуется с требованиями недавно опубликованного обновления спецификации RFC 1510 . ДАННЫЕ АВТОРИЗАЦИИ Протокол Kerberos служит для аутентификации, но не для проверки полномочий (авторизации) пользователей. Его задача – только удостовериться, что абонент безопасности в самом деле является тем, за кого себя выдает. Kerberos не проверяет ни того, доступ к каким файлам и другим объектам разрешен этому абоненту, ни того, как тот может воспользоваться предоставленным доступом. Эти аспекты работы находятся в ведении механизмов контроля за доступом, имеющимися в системе. Но протокол Kerberos помогает им в этом, отводя одно из полей своего мандата под данные, которые необходимы для проверки полномочий пользователя. Правда, он не описывает формат этих данных и ничего не говорит о том, как эти данные будут использованы сервером. Контроль доступа в Windows 2000 Некоторые операционные системы возлагают проверку полномочий пользователей на собственные механизмы конкретных приложений. Зачастую этой цели служат списки с именами пользователей, которым разрешен доступ к той или иной информации. Такой тип контроля за доступом легко можно интегрировать в процесс аутентификации Kerberos. Для этого достаточно указать в поле данных авторизации мандата имя абонента безопасности в той или иной форме. Такой метод можно назвать поименной проверкой полномочий (name-based authorization). Приложения для Windows 2000 могут содержать механизмы поименной проверки полномочий, которые обеспечат контроль за доступом к внутренней информации данного приложения. Базы данных, например, часто снабжаются частными таблицами проверки полномочий, в которых указывается, какие поля записей может просматривать или изменять данный пользователь. К сожалению, частные механизмы проверки полномочий, как следует из их названия, являются всего лишь частными. Приложение базы данных не в силах помешать любому пользователю запустить другую программу и с ее помощью отредактировать файл с данными. В среде Windows 2000 предусмотрены специальные меры защиты общих файлов и других ресурсов от несанкционированного доступа. Если такой файл используется двумя процессами, операционная система обеспечивает его безопасность собственными механизмами контроля за доступом. Заголовок каждого объекта содержит дескриптор безопасности со списком контроля доступа ACL. Последний находится в полном ведении владельца объекта, который имеет право разрешать и запрещать доступ к нему любого абонента безопасности, а также определять пределы полномочий абонентов, которым разрешен доступ к этому объекту. Чтобы обеспечить выполнение заданных условий, операционная система производит проверку полномочий каждый раз, когда от приложения поступает запрос на идентификатор защищенного объекта. Перед тем, как выдать ответ, она обращается к списку ACL объекта и убеждается, что абонент безопасности, использующий данное приложение, может обращаться к этому объекту. Если такое право пользователю не предоставлено, доступ запрещается. Еще одно важное отличие механизма Windows 2000 от других механизмов контроля за доступом состоит в том, что в этой среде абоненты безопасности не идентифицируются по имени ни в самой операционной системе, ни в записях ACL. Вместо этого каждому абоненту присваивается уникальный идентификатор безопасности SID (Security Identifier) – алфавитно-цифровая последовательность, по структуре напоминающая телефонный номер. Первую ее часть можно сравнить с кодом города, так как она указывает на домен, выдавший SID. Вторая часть идентификатора определяет учетную запись внутри этого домена, подобно тому, как последняя группа телефонного номера – номер конкретного телефона в городе. Код домена уникален для предприятия, а код учетной записи не повторяется внутри домена. В отличие от телефонных номеров идентификатор безопасности никогда не используется повторно. Возможность получить SID, уже принадлежавший ранее другому пользователю, полностью исключена, тогда как в механизмах контроля за доступом, основанных на именах пользователей, избежать такой проблемы бывает непросто. У описываемого способа есть и еще одно важное преимущество над контролем доступа по именам. Полномочия здесь определяются не только по идентификатору пользователя, но и по его принадлежности к одной или нескольким группам безопасности. И действительно, сегодня в большинстве случаев права на доступ к ресурсам определяются не для отдельного пользователя, а для группы, и уровень привилегий зависит от потребностей ее членов. Такой подход значительно упрощает обновление списков ACL в сетях с тысячами пользователей и миллионами объектов. Членством в группах администратор может управлять централизованно: чтобы изменить уровень доступа конкретного пользователя ко многим ресурсам, его достаточно включить в определенную группу или исключить из нее. Управление безопасностью ресурсов в среде Windows 2000 еще больше облегчается за счет применения вложенных групп (nested group). Группу, созданную в одном домене, можно включить в члены группы другого домена или даже сделать ее членом универсальной группы, которая действует по всему дереву доверяемых доменов. В результате этого у администратора появляется отличная возможность: когда сотрудник организации переводится на другое место, уровень его доступа к ресурсам можно изменить сразу по всему предприятию, не затронув при этом ни единого списка ACL. Как и индивидуальные абоненты безопасности, каждая группа безопасности Windows 2000 получает собственный идентификатор SID. Таким образом, в этой среде права пользователя на доступ к объектам определяются несколькими идентификаторами – одного его личного плюс по одному на каждую группу, членом которой состоит данный пользователь. Как KDC готовит данные авторизации Аутентификация по протоколу Kerberos предусматривает пересылку на локальный компьютер идентификаторов SID самого абонента безопасности и всех групп, членом которых он является. С этой целью в сеансовом мандате предусмотрено специальное поле данных авторизации. Сбор информации, необходимой для проверки полномочий, осуществляется в два не связанных между собой этапа. Первый из них проводится, когда служба KDC домена Windows 2000 создает мандат TGT, а второй – когда она готовится генерировать сеансовый мандат для сервера своего домена. Получив от пользователя запрос на мандат TGT, служба KDC того домена, где находится учетная запись пользователя, обращается в каталог Active Directory этого же домена. Один из атрибутов учетной записи пользователя содержит его собственный идентификатор SID, а другой – идентификаторы всех групп безопасности домена, в которые этот пользователь входит. Все обнаруженные идентификаторы передаются в KDC, где включаются в поле мандата TGT, отведенное под данные авторизации. В сети с несколькими доменами служба KDC, кроме того, обращается в глобальный каталог Global Catalog за информацией об универсальных группах, в которые входит сам пользователь либо группы безопасности домена, членом которых он состоит. Если такие универсальные группы найдены, их идентификаторы SID включаются в то же поле мандата TGT. Когда пользователь запрашивает сеансовый мандат на доступ к серверу, служба KDC домена, где находится этот сервер, копирует содержимое поля мандата TGT, отведенное под данные авторизации, в такое же поле сеансового мандата. Если сервер и учетная запись пользователя находятся в разных доменах, служба KDC обращается в каталог Active Directory и ищет группы безопасности локального домена, куда входит сам пользователь или одна из его групп безопасности. Идентификаторы SID найденных групп включаются в поле сеансового мандата, отведенное под данные авторизации. Такое применение поля с данными авторизации полностью отвечает требованиям обновлений документа RFC 1510, представленных на рассмотрение Целевой группы инженерной поддержки Интернета IETF . Точный формат таких данных в Windows 2000 может изменяться вплоть до выхода этой операционной системы в свет. На момент публикации настоящего документа они представлялись в формате NDR (Network Data Representation – представление сетевых данных) и подписывались службой KDC. Как данные авторизации используются службами В среде Windows 2000 службы функционируют в собственном контексте безопасности только при доступе к тем ресурсам, которые находятся в их полном распоряжении. В большинстве случаев это происходит лишь тогда, когда они выполняют внутренние задачи: обращаются к данным в ключах реестра, подключаются к коммуникационным портам или выполняют другие операции, не связанные с работой конкретного клиента. Когда же служба начинает действовать по запросам клиента, она персонифицирует его, после чего переходит в контекст безопасности этого клиента. Таким образом, службам Windows 2000 приходится не только идентифицировать клиентов, но и учитывать некоторые их характеристики, в первую очередь, уровень полномочий на данной системе. Выполняя внутренние задачи на компьютере под управлением Windows 2000, служба вызывает метод AcquireCredentialsHandle интерфейса SSPI, получая тем самым доступ к собственному удостоверению – секретному ключу для учетной записи, которая используется для работы этой службы. После этого она подключается к коммуникационному порту, где начинает ожидать сообщения клиентов. Когда клиент высылает запрос на подключение и представляет свой сеансовый мандат, служба вызывает метод AcceptSecurityContext интерфейса SSPI, посредством которого просит поставщика Kerberos SSP проверить удостоверение клиента, и пересылает ему сеансовый ключ клиента вместе с описателем для секретного ключа службы. В ответ Kerberos SSP проводит аутентификацию полученного мандата, открывает его и извлекает содержимое поля с данными авторизации, которое пересылает в родительский процесс, то есть, в подсистему LSA. Если в этих данных имеется список идентификаторов SID, подсистема LSA создает на их основе жетон доступа, представляющий пользователя на локальной системе. Кроме того, подсистема LSA обращается в собственную базу данных, чтобы определить, не является ли сам пользователь или одна из групп безопасности, в которую он входит, членом группы безопасности на локальной системе. Если это так, LSA добавляет в жетон доступа соответствующие идентификаторы SID. После этого подсистема уведомляет службу, из которой поступил запрос, о том, что проверка клиента успешно завершена, и вкладывает в свой ответ жетон доступа для данного клиента. Получив такое подтверждение, служба завершает связь с клиентом и обращается к методу ImpersonateSecurityContext, посредством которого прикрепляет жетон доступа клиента к персонифицированной нити. Этот жетон вступает в действие, когда требуется доступ персонифицированной нити к какому-либо объекту. Операционная система контролирует доступ, сверяя идентификаторы SID из жетона с этими же идентификаторами в списке ACL объекта. Если они совпадают, проверяется соответствие уровня доступа, отмеченного в ACL, с тем, который затребован нитью. При выполнении этого условия доступ разрешается, в противном случае – запрещается. Зачем подписывать данные авторизации Сеансовый мандат шифруется секретным ключом той учетной записи, в интересах которой была запущена служба. Доступ к этому ключу может получить любая служба, имеющая описатель своего собственного удостоверения. Это открывает возможность для мошенничества. Пользователь со вполне законной учетной записью в сети может попытаться повысить уровень своих прав, воспользовавшись для этого фиктивной службой. Установив ее, злоумышленник запрашивает сеансовый мандат для новой службы, а затем дешифрует его, изменяет данные авторизации (например, добавляет в них идентификатор SID привилегированной группы), вновь шифрует скорректированный мандат и представляет его в подсистему LSA для вызова метода AcceptSecurityContext. Таким способом ему удается расширить свои права на том компьютере, где запущена его служба. Чтобы предотвратить подделку данных авторизации, они перед внесением в сеансовый мандат подписываются службой KDC. После этого любая попытка скорректировать такие данные неизбежно приведет к искажению подписи. Подсистема LSA на компьютере Windows 2000 обязательно проверяет достоверность такой подписи во всех сеансовых мандатах, кроме тех, что поступили от доверяемых служб. При получении запроса на метод AcceptSecurityContext подсистема LSA доверяет только тем службам, которые работают под эгидой учетной записи Local Systems. Дело в том, что эта учетная запись по умолчанию доступна лишь службам, которые были установлены вместе с самой операционной системой, например внутренней службе «Сервер» (Server). Конечно, использование этой учетной записи нетрудно предусмотреть в конфигурации и других служб, однако сделать это может лишь член группы Администраторов. Предполагается, что администратор, установивший такую службу, полностью отвечает за ее безопасность. Службам, работающим в интересах других учетных записей, подсистема LSA не доверяет. Получив сеансовый мандат от любого приложения, которое не входит в число локальных систем (группа Local System), она просит центр KDC своего домена проверить подпись в поле с данными авторизации. Запрос и ответ на него производятся с помощью вызова удаленной процедуры по безопасному каналу Netlogon контроллера домена. Такие запросы на проверку никогда не покидают пределов локального домена, что объясняется просто: сеансовые мандаты всегда выдаются, – а значит, и подписываются, – службой KDC того домена, где находится запрашиваемый компьютер. ИНТЕРАКТИВНАЯ РЕГИСТРАЦИЯ Пользователи зачастую считают, будто регистрация в домене Windows сразу же открывает им выход в сеть. Конечно же, это не так. Если для сетевой аутентификации используется протокол Kerberos, то пользователь после входа в систему получает доступ лишь к службе аутентификации домена. Точнее говоря, он получает мандат TGT, которые должен предъявить при запросе сеансовых мандатов для обращения к другим службам домена. Когда пользователь входит в домен с компьютера под управлением Windows 2000, ему обязательно нужен хотя бы один сеансовый мандат –для той машины, на которой он регистрируется. В отличие от других компьютеров, каждая машина Windows 2000 имеет в домене собственную учетную запись, которую для простоты можно представить как служебную. Таким образом, чтобы получить доступ к ресурсам на компьютере Windows 2000, удаленному пользователю нужно представить запрос в службу «Сервер» (Server) этого компьютера. Интерактивные же пользователи для этого направляют свои запросы в службу «Рабочая станция» (Workstation). Однако получить доступ к любой из этих служб, как и к любой другой службе группы «Локальная система» (Local System), можно лишь после того, как будет представлен сеансовый мандат для данного компьютера. Процесс регистрации Когда пользователь компьютера Windows 2000 с учетной записью в домене Windows 2000 вводит с клавиатуры свои регистрационные данные, его запрос на вход в систему проходит трехэтапную обработку. 1. Пользователь посылает заявку на подключение к службе выдачи мандатов домена. Это делается с помощью протокола AS Exchange, обеспечивающего связь между поставщиком Kerberos SSP пользовательского компьютера и службой KDC домена, где находится учетная запись пользователя. Результатом успешного обмена данными является мандат TGT, который пользователь должен будет представлять в ходе всех последующих транзакций с KDC. 2. Пользователь запрашивает мандат на компьютер. Эта операция выполняется с помощью протокола TGS Exchange, который обеспечивает связь между поставщиком Kerberos SSP компьютера и службой KDC домена, где находится учетная запись этого компьютера. После завершения операции генерируется сеансовый мандат, который пользователь должен будет представлять для получения доступа к системным службам компьютера. 3. Пользователь посылает запрос на доступ к службам «Локальной системы» компьютера. При выполнении этой операции поставщик Kerberos SSP на компьютере пользователя представляет сеансовый мандат в подсистему LSA этого же компьютера. Если учетные записи пользователя и компьютера, на котором он работает, находятся в разных доменах, выполняется еще одна дополнительная процедура. Перед тем, как запросить сеансовый мандат для компьютера, поставщик Kerberos SSP запрашивает в службе KDC домена пользователя мандат TGT, пригодный для обращения к службе KDC домена, где находится учетная запись компьютера. Затем он представляет полученный мандат TGT в эту службу и получает от нее сеансовый мандат для компьютера. Особенности процесса регистрации во многом зависят от конфигурации компьютера. В Windows 2000 для этой цели обычно используется пароль, хотя в операционной системе предусмотрена возможность входа в систему по предъявлении микропроцессорной карточки. В обоих случаях выполняется примерно одинаковая последовательность операций, однако есть между ними и различия, которые будут рассмотрены ниже. Сначала остановимся на регистрации с применением пароля. Вход в систему по паролю Предположим, что Алиса имеет учетную запись в домене «Запад». Там же находится и учетная запись сервера Боб, с которым она обычно работает. Вход в сеть Алиса начинает с нажатия клавиш CTRL+ALT+DEL, комбинация которых в стандартной конфигурации Windows 2000 генерирует сигнал SAS (Secure Attention Sequence – последовательность обращения к системе безопасности). В ответ служба Winlogon компьютера переключается на настольную систему, с которой поступил сигнал SAS, и направляет на нее динамически подключаемую библиотеку GINA (Graphical Identification and Authentication – графическая идентификация и аутентификация) – компонент, загружаемый службой Winlogon. GINA служит для получения от пользователя данных регистрации, их упаковки в структуру данных и отправки в подсистему LSA на проверку. Независимые производители, возможно, предложат замену этой библиотеке, однако здесь мы рассмотрим случай, когда Winlogon загружает стандартный файл MSGINA.DLL из состава операционной системы. На экране появляется стандартное диалоговое окно входа в систему. Алиса вводит имя пользователя и пароль, а в ниспадающем списке доменов выбирает «Запад». После щелчка на кнопке ОК библиотека MSGINA пересылает введенные данные в службу Winlogon. Та, в свою очередь, вызывает метод LsaLogonUser и с его помощью направляет регистрационную информацию в подсистему LSA для проверки. Получив пакет с данными регистрации Алисы, подсистема LSA первым делом преобразует текстовый пароль в секретный ключ, для чего производит его одностороннее хеширование. Полученный результат сохраняется в кэш-памяти удостоверений, откуда он может быть извлечен при необходимости обновления мандата TGT или аутентификации по протоколу NTLM, если потребуется подключиться к серверу, не поддерживающему протокол Kerberos. Чтобы проверить регистрационные данные Алисы и начать сеанс ее работы на компьютере, подсистеме LSA необходимо получить: • мандат TGT, который нужно представить в службу выдачи мандатов; • сеансовый мандат, открывающий доступ к серверу Боб.
Подсистема LSA получает эти мандаты при посредничестве поставщика поддержки безопасности Kerberos SSP, который обменивается сообщениями непосредственно со службой KDC домена «Запад».
Рис. 8. Интерактивная регистрация в домене Обмен сообщениями осуществляется в следующем порядке: 1. Подсистема LSA направляет в службу KDC домена «Запад» сообщение KRB_AS_REQ. В сообщении указываются: • пользовательское имя Алисы – Alice; • имя домена с учетной записью Алисы – West. • данные предварительной аутентификации, зашифрованные посредством секретного ключа, который был рассчитан на основе пароля Алисы. 2. Если данные предварительной аутентификации клиента верны, служба KDC отвечает сообщением KRB_AS_REP. В сообщение включаются: • сеансовый ключ для связи Алисы со службой KDC, зашифрованный с помощью секретного ключа, который был рассчитан на основе пароля Алисы. • мандат TGT для службы KDC домена «Запад», зашифрованный с помощью секретного ключа службы KDC. В мандате TGT указываются: • сеансовый ключ для связи Алисы со службой KDC; • данные авторизации Алисы. Данные авторизации включают в себя: • идентификатор SID учетной записи Алисы; • идентификаторы SID групп безопасности домена «Запад», членом которых состоит Алиса; • идентификаторы SID универсальных групп предприятия, в которые входит либо сама Алиса, либо одна из ее групп домена. 3. Подсистема LSA направляет в службу KDC домена «Запад» сообщение KRB_TGS_REQ. В сообщение включаются: • имя компьютера, к которому нужно подключиться, – Bob; • имя домена этого компьютера – West; • мандат TGT Алисы; • аутентификатор, зашифрованный сеансовым ключом, который используется для связи Алисы с данной службой KDC. 4. Служба KDC отвечает сообщением KRB_TGS_REP. В сообщении указываются: • сеансовый ключ Алисы и Боба, зашифрованный посредством сеансового ключа, который Алиса использует для связи со службой KDC; • сеансовый мандат Алисы для компьютера Боб, зашифрованный сеансовым ключом, который используется для связи Боба со службой KDC. Сеансовый мандат содержит: • сеансовый ключ, общий для Боба и Алисы; • данные авторизации, скопированные из мандата TGT Алисы. Получив сеансовый мандат Алисы, подсистема LSA расшифровывает его с помощью секретного ключа этого компьютера и извлекает данные авторизации Алисы. Затем она обращается в локальную базу данных диспетчера учетных записей безопасности SAM (Security Account Manager). Здесь она проверяет, не является ли Алиса членом какой-либо группы безопасности, локальной для данного компьютера, и не имеет ли она специальных привилегий на этой локальной машине. Если проверка дает положительный результат, подсистема LSA добавляет обнаруженные идентификаторы SID в список данных авторизации, извлеченный из мандата. Пополненный таким образом список используется для генерации жетона доступа, описатель которого возвращается в Winlogon вместе с идентификатором сеанса регистрации Алисы и подтверждением подлинности введенных ею данных. В ответ Winlogon создает для Алисы оконную станцию (windows station) и несколько объектов настольной системы, прикрепляет ее жетон доступа и запускает оболочечный процесс, который позволит Алисе взаимодействовать с компьютером Боб. Жетон доступа Алисы впоследствии будет включаться во все прикладные процессы, запускаемые в ходе текущего сеанса. Вход в систему с помощью смарт-карты При стандартной регистрации с помощью Kerberos пользователь прежде всего должен доказать службе KDC, что он является именно тем, за кого себя выдает. Для этого ему необходимо продемонстрировать знание секрета, который известен только ему и службе KDC. Роль такого секрета играет криптографический ключ, рассчитанный на основе пароля пользователя. Он используется только при обмене сообщениями по подпротоколу AS Exchange в тех случаях, когда: • клиент шифрует данные предварительной аутентификации; • служба KDC расшифровывает данные предварительной аутентификации; • служба KDC шифрует ключ сеанса регистрации; • клиент расшифровывает ключ сеанса регистрации.
Для шифрования и дешифрования данных используется один и тот же общий секретный ключ, который по этой причине называют симметричным. Для регистрации с помощью смарт-карт в Windows 2000 реализовано специальное расширение исходного подпротокола AS Exchange из набора Kerberos, позволяющее использовать открытые ключи . В отличие от общих секретных ключей криптография открытых ключей асимметрична. Здесь требуется применение двух ключей, один из которых служит для шифрования сообщения, а другой – для его дешифрования. Вместе они образуют пару, состоящую из секретного и открытого ключа. Секретный ключ известен только владельцу этой пары и никогда не передается второму абоненту. Открытый ключ владелец пары сообщает всем, с кем намерен обмениваться конфиденциальной информацией. При регистрации с помощью смарт-карт вместо общего секретного ключа, рассчитываемого на основе пароля пользователя, применяется пара, состоящая из секретного и открытого ключей, которая хранится в памяти смарт-карты. Расширение протокола Kerberos, определяющее порядок применения открытых ключей при обмене по подпротоколу AS Exchange, предусматривает следующий порядок использования такой пары. Открытая ее часть служит для шифрования сеансового ключа пользователя службой KDC, а секретная – для дешифрования этого ключа клиентом. Регистрация начинается с того, что пользователь вставляет свою смарт-карту в специальное считывающее устройство, подключенное к компьютеру. При соответствующей конфигурации Windows 2000 это равносильно сигналу SAS, то есть, одновременному нажатию клавиш CTRL+ALT+DEL. В ответ Winlogon направляет на настольную систему динамически подключаемую библиотеку MSGINA, которая выводит на экран стандартное диалоговое окно регистрации. Правда, теперь пользователю достаточно ввести только один параметр – персональный идентификационный номер PIN (Personal Identification Number). MSGINA вызывает метод LsaLogonUser и с его помощью пересылает регистрационные данные пользователя в подсистему LSA точно так же, как и при парольной регистрации. Эта подсистема использует PIN пользователя для доступа к смарт-карте, где хранятся секретный ключ пользователя и сертификат Х.509 v3, содержащий открытый ключ пары. В дальнейшем все криптографические операции с использованием данной пары будут производится через смарт-карту. Поставщик Kerberos SSP клиентского компьютера направляет в службу KDC сообщение KRB_AS_REQ – первоначальный запрос на аутентификацию. В поле данных предварительной аутентификации этого запроса включается сертификат открытого ключа пользователя. Центр распределения ключей проверяет подлинность сертификата и извлекает из него открытый ключ, которым шифрует ключ сеанса регистрации. После этого он включает этот ключ вместе с мандатом TGT в сообщение KRB_AS_REP и направляет его клиенту. Расшифровать сеансовый ключ сможет только тот клиент, у которого есть секретная половина криптографической пары, функции которой на этом заканчиваются. Вся дальнейшая связь между клиентом и службой KDC поддерживается на основе сеансового ключа. Никаких других отклонений от стандартного процесса регистрации и вхождения в сеть не требуется. О том, какие типы смарт-карт и устройств их чтения поддерживаются в среде Windows 2000, можно узнать из списка устройств, совместимых с этой операционной системой, «Windows 2000 Hardware Compatibility List». Данные предварительной аутентификации По умолчанию поставщик Kerberos SSP, работающий на клиентском компьютере, в качестве данных предварительной аутентификации направляет в службу KDC шифрованную метку времени. На системах же, конфигурация которых предусматривает регистрацию с применением микропроцессорной карточки, роль данных предварительной аутентификации отводится сертификату открытого ключа. УДАЛЕННАЯ РЕГИСТРАЦИЯ Когда вы вводите с клавиатуры имя пользователя и пароль, процесс регистрации создает контекст безопасности для всех ваших действий на локальном компьютере. Ваш идентификатор безопасности инкапсулируется в жетон доступа, прикрепленный к объекту процесса, который представляет текущий сеанс входа в систему. При запуске любого приложения оно включается в процесс текущего сеанса, благодаря чему наследует ваш жетон доступа. Таким образом, приложение попадает в ваш контекст безопасности, то есть может обращаться лишь к тем ресурсам, доступ к которым вам разрешен. Нечто подобное происходит и тогда, когда вы используете клиентский компонент серверного приложения, также работающего на том же компьютере. В этом случае серверный процесс порождает множество нитей, прикрепляет к каждой из них копию вашего жетона безопасности и персонифицирует эту нить, пока она работает на вас. Такая нить исполняется в вашем контексте безопасности и может выполнять только то, что вам разрешено на локальном компьютере. Когда клиентское приложение вашего компьютера подключается к серверному приложению, запущенному на другом компьютере, к персонифицированной нити сервера никакого жетона доступа не прикрепляется. Все дело в том, что у вас на удаленном компьютере просто нет контекста безопасности и не будет до тех пор, пока вы не зарегистрируетесь на нем. Правда, в отличие от локальной машины, вход в систему удаленного компьютера не является интерактивным. Пользователю не нужно вводить свои данные в диалоговое окно – клиент локального компьютера передаст всю необходимую для регистрации информацию на удаленное серверное приложение, которое и создаст контекст безопасности для вашей работы там. Интерфейс поставщика поддержки безопасности Как правило, аутентификация проводится на основе механизма клиент-серверного приложения, который обеспечивает связь между процессами. Клиент-серверным приложениям, разработанным для Windows 2000, нет никакой необходимости знать детали протокола аутентификации, более того, им не нужен даже список поддерживаемых протоколов. Обоим компонентам такого приложения вполне достаточно вызовов в интерфейс поставщика поддержки безопасности SSPI (Security Support Provider Interface). Клиентское приложение направляет туда запрос на контекст безопасности для пользователя, а серверное обращается к этому интерфейсу, чтобы создать такой контекст. Все остальное берет на себя интерфейс SSPI. С некоторой натяжкой можно сказать, что интерфейс SSPI превращает протокол аутентификации Kerberos в подтекст прикладного протокола, организуя своего рода переговоры внутри переговоров. На обоих концах канала связи клиента с сервером интерфейс SSPI действует через поставщика поддержки безопасности SSP, который владеет всеми кодами, необходимыми для работы конкретного протокола аутентификации. SSP просто передает сообщения аутентификации транспортному приложению. Для этого приложения, если не оговорено иного, передаваемые данные остаются невидимыми. Оно не знает ни того, что содержится в сообщении аутентификации, ни того, что отвечать при получении такого сообщения. Функции обработки и реагирования на сообщения аутентификации полностью возложены на поставщика SSP.
Рис. 9. Протокол аутентификации как подтекст прикладного протокола Выбор поставщика поддержки безопасности В состав Windows 2000 входит несколько поставщиков поддержки безопасности, разработанных для проведения аутентификации по протоколам Kerberos, NTLM и SChannel. При обращении к интерфейсу SSPI приложение может указать, какой из поставщиков ему нужен, но предусмотрена и другая возможность: функция согласования, заложенная в SSPI, позволяет приложению выбрать из числа доступных тот протокол, который обеспечит наивысшую безопасность сеанса . Когда предложение запрашивает вход в систему с согласованием, клиент предлагает ему весь список имеющихся протоколов безопасности, начиная с самых безопасных. Сервер определяет, какие из этих протоколов доступны ему, и выбирает из их числа самый безопасный. На системах Windows 2000 первым в списке всегда идет Kerberos, за ним следует NTLM, а потом – SChannel. Если и клиент, и сервер работают под управлением Windows 2000, механизм согласования всегда будет выбирать для аутентификации протокол Kerberos. Пример: открытие файла на уделенном сервере Предположим, что Алиса вошла в сеть со своей рабочей станции, воспользовавшись для этого принадлежащей ей учетной записью в домене. Затем она запустила Microsoft Word и решила открыть документ, хранящийся на сервере файлов. Чтобы открыть этот документ, Microsoft Word передает в операционную систему Windows 2000, установленную на рабочей станции, запрос ввода-вывода, для чего использует вызов интерфейса прикладного программирования (API). Операционная система определяет, что документ относится к числу удаленных ресурсов, и пересылает запрос на редиректрор (redirector) своей файловой системы. Тот, в свою очередь, посредством протокола совместного использования файлов Server Message Block (SMB) связывается со службой «Сервер» (Server) удаленного сервера файлов, открывает файл и считывает данные из него. Все эти действия выполняются поэтапно, с помощью последовательности сообщений SMB. Первый – и единственный, который нас интересует, – этап состоит в организации аутентифицированного подключения между перенаправителем и удаленной службой. Процесс согласования с поставщиком поддержки безопасности Перед тем, как приступить к идентификации абонента на другом конце подключения SMB, оба участника сеанса должны договориться насчет протокола аутентификации. С этой целью клиент и сервер обмениваются списками поставщиков поддержки безопасности, доступных им, и указывают наиболее предпочтительные. В нашем случае оба они работают в среде Windows 2000, поэтому под первым номером указывают Kerberos SSP. Именно его они и договариваются применять. С чего клиент начинает процесс аутентификации Протокол аутентификации вступает в действие, когда перенаправитель рабочей станции Алисы обращается к SSPI и вызывает метод AcquireCredentialsHandle, указав в качестве абонента безопасности Алису. В ответ он получает описатель удостоверения, выданного Алисе при ее интерактивной регистрации на своей рабочей станции. Затем перенаправитель вновь обращается к SSPI, но на этот раз вызывает метод InitializeSecurityContext, с помощью которого передает описатель к мандату TGT Алисы и указывает сервер, к которому нужно подключиться, – в нашем случае сервер файлов. В результате такого вызова генерируется сообщение Kerberos KRB_TGS_REQ, содержащее мандат TGT Алисы. Поставщик Kerberos SSP направляет это сообщение непосредственно в службу KDC того домена, где хранится учетная запись Алисы, и получает от нее мандат на доступ к соответствующему серверу файлов. Затем Kerberos SSP кэширует полученный мандат и вновь обращается к процессу, от которого был получен вызов, то есть, к редиректору. Тем самым он указывает, что процесс аутентификации еще не завершен. В продолжение предыдущего вызова редиректор вновь посылает запрос на метод InitializeSecurityContext. На этот раз поставщик Kerberos SSP генерирует сообщение Kerberos KRB_AP_REQ, содержащее мандат, зашифрованный посредством секретного ключа, общего для запрашиваемого сервера и службы KDC. Сюда же включается аутентификатор, зашифрованный с помощью сеансового ключа, который получили Алиса и этот сервер. Затем Kerberos SSP возвращает созданное сообщение на редиректор. Тот, в свою очередь, преобразует полученное сообщение в жетон аутентификации и в таком качестве включает его в сообщение SMB, которое посылает службе «Сервер». Что отвечает служба «Сервер» Получив от редиректора сообщение SMB, служба «Сервер» создает локальный контекст безопасности для нового клиента. С этой целью она обращается в SSPI, вызывает метод AcceptSecurityContext и выставляет указатель на жетон аутентификации. Поставщик Kerberos SSP, запущенный на сервере файлов, открывает сообщение KRB_AP_REQ, достает мандат и извлекает из него сеансовый ключ, с помощью которого оценивает достоверность аутентификатора Алисы. Если проверка прошла успешно, Kerberos SSP удаляет из сеансового мандата данные авторизации Алисы и передает его в подсистему LSA сервера. Та, в свою очередь, генерирует жетон доступа Алисы и создает контекст безопасности для ее работы на данной системе. Сделав все это, поставщик Kerberos SSP готовит сообщение KRB_AP_REP и возвращает его вместе с описателем контекста безопасности Алисы тому процессу, от которого поступил первоначальный запрос. Когда вызов метода AcceptSecurityContext возвращается в службу «Сервер», та включает KRB_AP_REP в поле данных сообщения SMB и отправляет последнее на редиректор рабочей станции Алисы. Описатель контекста безопасности Алисы используется для персонификации пользователя. С этой целью редиректор обращается к интерфейсу SSPI и вызывает метод ImpersonateSecurityContext. В результате такого вызова жетон доступа Алисы прикрепляется к персонифицированной нити сервисного процесса, после чего та от имени Алисы открывает файл. Если Алиса имеет право на чтение этого файла, служба отвечает на запрос ввода-вывода, поступивший от перенаправителя. Взаимная аутентификация Когда редиректор получает сообщение SMB, содержащее KRB_AP_REP, он передает эти данные поставщику Kerberos SSP на рабочей станции Алисы для идентификации сервера. С помощью своей копии сеансового ключа Kerberos SSP расшифровывает аутентификатор сервера, а затем сравнивает метку времени из него с той, которая была отправлена в сообщении KRB_AP_REQ. Если эти метки не совпадают, Kerberos SSP выдает сигнал ошибки, и редиректор разрывает подключение с сервером файлов. При положительном же результате проверки сеанс продолжается. Так проходит взаимная аутентификация. Пример: междоменная аутентификация Сеть, где работает Алиса, содержит три домена, в том числе один родительский и два дочерних – «Восток» и «Запад». Учетная запись Алисы хранится в домене «Запад». Она уже зарегистрировалась в своем домене и получила мандат TGT для службы KDC домена «Запад». Но вот, работая на своем компьютере, она решила взглянуть на документ в каталоге общего пользования на сервере Боб из домена «Восток».
Рис. 10. Сеть Алисы Порядок организации безопасного клиент-серверного подключения очень похож на тот, что был описан в предыдущем примере. Однако на этот раз Алиса и сервер файлов находятся в разных доменах, поэтому поставщику Kerberos SSP, установленному на рабочей станции Алисы, нужно сначала получить мандат TGT для домена сервера. Только после этого он может обращаться за мандатом на доступ к самому серверу. Таким образом, появляется еще одно звено – процесс переадресации, который выполняется в следующей последовательности. 1. Рабочая станция Алисы направляет в центр распределения ключей (служба KDC) домена west.company.com сообщение KRB_TGS_REQ. В сообщение включаются: • имя компьютера, к которому нужно подключиться – Bob, • имя домена, в котором находится этот компьютер, –east.company.com, • мандат TGT для доступа к службе KDC домена west.company.com, • аутентификатор, зашифрованный посредством сеансового ключа, общего для Алисы и службы KDC этого домена. 2. Служба KDC домена west.company.com отвечает сообщением KRB_TGS_REP. В сообщении содержатся: • сеансовый ключ для связи Алисы со службой KDC домена company.com, зашифрованный посредством сеансового ключа Алисы, который она получила при регистрации в системе; • мандат TGT для доступа к службе KDC домена company.com, зашифрованный посредством секретного ключа, о котором эти домены договорились при установлении доверительных отношений. 3. Рабочая станция Алисы направляет службе KDC домена company.com сообщение KRB_TGS_REQ. В сообщение включаются: • имя компьютера, к которому нужно подключиться, – Bob; • имя домена, в котором находится этот компьютер, –east.company.com; • мандат TGT для доступа к службе KDC домена company.com; • аутентификатор, зашифрованный сеансовым ключом, который используется для связи Алисы с этой службой KDC. 4. Служба KDC домена company.com отвечает сообщением KRB_TGS_REP. Это сообщение содержит: • мандат TGT на доступ к службе KDC домена east.company.com, зашифрованный с помощью секретного ключа, о котором эти домены договорились при установлении доверительных отношений; • сеансовый ключ, который используется для связи Алисы с данной службой KDC, зашифрованный посредством сеансового ключа, общего для Алисы и службы KDC домена company.com. 5. Рабочая станция Алисы посылает службе KDC домена east.company.com сообщение KRB_TGS_REQ. Сообщение содержит: • имя компьютера, к которому нужно подключиться, – Bob; • имя домена, в котором находится этот компьютер, –east.company.com; • мандат TGT для доступа к службе KDC домена east.company.com; • аутентификатор, зашифрованный сеансовым ключом, который используется для связи Алисы с этой службой KDC. 6. Служба KDC домена east.company.com направляет в ответ сообщение KRB_TGS_REP. В сообщение включаются: • сеансовый ключ для связи Алисы с компьютером Боб, зашифрованный с помощью сеансового ключа, общего для Алисы и службы KDC домена east.company.com; • сеансовый мандат для доступа к компьютеру Боб, зашифрованный посредством секретного ключа, который используется компьютером Боб и этой службой KDC. Сеансовый мандат содержит: • сеансовый ключ для связи компьютера Боб с Алисой; • данные авторизации, скопированные из мандата TGT Алисы, а также данные для локального домена east.company.com. В состав данных авторизации входят: 1. идентификатор SID учетной записи Алисы; • идентификаторы SID групп домена west.company.com, членом которых является Алиса; • идентификаторы SID универсальных групп, в состав которых входит либо сама Алиса, либо одна из групп домена west.company.com, где Алиса состоит членом; • идентификаторы SID групп домена east.company.com, в состав которых входит либо сама Алиса, либо одна из ее групп домена west.company.com, либо одна из ее универсальных групп. 7. Рабочая станция Алисы посылает компьютеру Боб сообщение KRB_AP_REQ. Сообщение содержит: 1. имя пользователя – Alice. • мандат для компьютера Боб; • аутентификатор, зашифрованный посредством сеансового ключа, общего для Алисы и компьютера Боб. 8. Компьютер Боб отвечает сообщением KRB_AP_REP. Это сообщение содержит аутентификатор, зашифрованный с помощью сеансового ключа, общего для компьютера Боб и Алисы. ВОПРОСЫ СОВМЕСТИМОСТИ Главная цель реализации протокола аутентификации Kerberos 5 в операционной системе Windows 2000 – обеспечить полную совместимость с эталонным протоколом Kerberos, опубликованным Массачусетским технологическим институтом. Сценарии Корпорация Microsoft проверила совместимость своей реализации Kerberos с эталонным протоколом Массачусетского технологического института при взаимодействии со следующими системами. Служба KDC операционных систем Windows. Реализации протокола Kerberos для других сред обеспечивают аутентификацию в центрах распределения ключей доменов Windows 2000. Аутентификация пользователей таких реализаций, а также хост-компьютеров, на которых они развернуты, требует применения утилиты kinit и шифрования по стандартам DES-CBC-MD5 или DES-CBC-CRC. Центры распределения ключей Kerberos для других операционных систем. Системы под управлением Windows 2000 могут проходить аутентификацию на хост-компьютерах, выполняющих функции центров распределения ключей областей Kerberos. Кроме того, возможна такая конфигурация автономных систем Windows 2000, при которой учетные записи локального компьютера будут отображаться на абоненты безопасности Kerberos. При такой конфигурации пользователь может одновременно регистрироваться на компьютере и в области Kerberos. Клиент Windows и служба Kerberos для другой операционной системы. Клиентское приложение, запущенное в среде Windows 2000, может пройти аутентификацию в службе Kerberos для другой операционной системы, если эта служба поддерживает интерфейс прикладного программирования GSS-API (Generic Security Service Application Program Interface – интерфейс прикладного программирования для службы общей безопасности), описанный в документе RFC 1964. В состав Windows 2000 интерфейс GSS-API не входит. Чтобы обеспечить аутентификацию по протоколу Kerberos 5, создаваемые для этой операционной системы приложения должны опираться на интерфейс SSPI. Оба эти интерфейса совместимы и имеют между собой много общего. Клиент Kerberos для другой операционной системы и служба Windows. Клиентские приложения, использующие протокол Kerberos для других операционных систем, могут пройти аутентификацию в службах, которые работают в среде Windows 2000. Для этого они должны поддерживать интерфейс прикладного программирования GSS-API, описанный в документе RFC 1964. Доверительные отношения. Домены Windows 2000 могут доверять областям Kerberos в сетях, которые работают под управлением других операционных систем. Такие области при соответствующей конфигурации также могут доверять доменам Windows. Однако подобные доверительные отношения не столь всеобъемлющи, как доверие между доменами Windows. В частности, пользователь области Kerberos не может представить данных авторизации, необходимых для управления доступом к службам на Windows 2000. Чтобы включить такие данные в мандат пользователя, необходим механизм отображения учетных записей. Для идентификации пользователей Kerberos из доверенной области производится отображение нескольких избранных учетных записей этого домена, результаты которого сохраняются в свойстве altSecurityID объекта учетной записи пользователя. Управление отображенными учетными записями может производиться с помощью ветви Active Directory Users and Computers. Конфигурирование системы В папке Support установочного компакт-диска Windows 2000 имеется несколько вспомогательных программ, которые помогают настроить эту операционную систему для работы с системами UNIX. Описание работы с ними приведено в разделе «MIT Kerberos 5 (krb5 1.0) Interoperability» краткого технического руководства «Beta 3 Technical Walkthrough». Дополнительная информация Самую свежую информацию по операционной системе Windows 2000 всегда можно найти на узле http://www.microsoft.com/windows.
Методы изучения программ. Постановка задачи. Зачем нужно изучать программы. Задача анализа программного обеспечения возникает в самых различных ситуациях. Предположим, например, что компьютерную сеть нашей организации поразил неизвестный компьютерный вирус. Для того, чтобы создать способный с ним бороться антивирус, необходимо вначале понять принципы функционирования этого вируса. А для этого необходимо провести анализ машинного кода вируса. Другой пример. Систему защиты информации нельзя считать надежной до тех пор, пока не проведена экспертиза, которая показала, что известные методы преодоления систем защиты данного класса не работают для тестируемой системы. Другими словами, эксперт или группа экспертов становятся в позицию злоумышленника и пытаются преодолеть защиту, реализуемую тестируемой системой. Если преодолеть защиту не удается, значит, систему защиты можно рекомендовать для практического использования, в противном случае эта система нуждается в доработке. Такая экспертиза должна включать в себя опробование всех известных методов преодоления защиты, в том числе и методов, связанных с анализом программного обеспечения системы защиты. Таким образом, при проведении экспертизы программно реализованной системы защиты информации неизбежно возникает задача анализа программного обеспечения этой системы. Следует отметить, что описываемую в данной главе методику анализа программ можно применять не только для защиты информации, но и для «нападения» – получения незаконных копий программ, встраивания в программы закладок и вирусов и т.д. Поскольку авторы не рассматривают эту книгу как пособие для начинающего хакера, вопросы, связанные с применением методов изучения программ для выполнения подобных незаконных действий, рассматриваться не будут. Собственно постановка задачи. Задачу изучения программы в общем случае можно сформулировать следующим образом. Мы имеем бинарный код программы (например, exe-файл) и минимальную информацию о том, что эта программа делает. Нам нужно получить более детальную информацию о функционировании этой программы. Другими словами, мы знаем, что делает программа, и хотим узнать, как она это делает. Конечно, во многих случаях аналитику доступна более детальная информация об анализируемой программе (техническая документация, исходный текст и т.д.), что существенно упрощает процесс анализа. Но мы будем рассматривать наиболее общий (и наиболее сложный) случай, когда ничего, кроме кода программы, аналитику неизвестно. Понятие программа здесь и далее мы будем понимать в широком смысле. Под программой мы будем подразумевать не только exe- или com-файл, но и библиотеку функций, драйвер устройства и т.д. Обычно мы будем употреблять слово «программа» в единственном числе, но это не означает, что изложенную ниже методику нельзя применять к программным комплексам, включающим в себя более одной программы. Хотя в дальнейшем мы будем рассматривать применение данной методики только к системам защиты информации, эта методика может быть применена к любым программам. Основные этапы анализа программы. Работа по анализу программы включает в себя три основных этапа: 1. Подготовительный этап. На этом этапе аналитик проводит первичное знакомство с анализируемой программой, изучает доступную документацию, планирует дальнейшие исследования, подбирает коллектив и организует его работу. Важность этого этапа нельзя недооценивать. Эффективность дальнейшей работы очень сильно зависит от того, насколько полная информация об анализируемой программе была получена на первом этапе. Если аналитик сумел получить исходный текст анализируемой программы, задача анализа программы в большинстве случаев решается тривиально. Наличие у аналитика отладочной информации об анализируемой программе также существенно упрощает дальнейшую работу. 2. Восстановление алгоритмов функционирования программы. На этом этапе, собственно, и производится изучение программы. Методам, применяемым на этом этапе, посвящена большая часть данной главы. 3. Проверка полученных результатов. На этом этапе аналитик проверяет результаты проведенных исследований. Обычно эта проверка заключается в написании тестовой программы, которая реализует восстановленные алгоритмы анализируемой программы. Если поведение тестовой программы не отличается от поведения анализируемой в отношении анализируемых алгоритмов, задачу можно считать решенной. Если же поведение тестовой программы отличается от поведения анализируемой, это означает, что в анализе программы допущены ошибки, которые необходимо устранить. Как правило, правильно восстановить анализируемые алгоритмы с первого раза не удается. Основные методы изучения программ. В настоящее время сформировались три подхода к восстановлению алгоритмов, реализуемых программой: • метод экспериментов; • статический метод; • динамический метод. Остальная часть главы посвящена описанию этих методов. Метод экспериментов. Метод экспериментов заключается в проведении многократных экспериментов с изучаемой программой и сравнительном анализе полученных результатов. Изучаемая программа рассматривается как «черный ящик», для которого известны входные и выходные данные, но неизвестно внутреннее устройство. Задача аналитика заключается в том, чтобы, подбирая входные данные, восстановить алгоритмы функционирования «черного ящика». Эффективность метода экспериментов слабо зависит от программной реализации системы защиты (на нее, в частности, не влияет применение средств защиты программного обеспечения от изучения) и определяется, в первую очередь, сложностью анализируемых алгоритмов. Метод экспериментов эффективен при анализе программ, реализующих относительно простые алгоритмы. Метод экспериментов редко применяется в чистом виде. Чаще этот метод применяется как дополнение к динамическому или статическому методу. Это обусловлено тем, что, как правило, восстанавливаемые алгоритмы оказываются слишком сложными для данного метода. Системы защиты, сложность алгоритмов которых позволяет ограничиться при анализе методом экспериментов, существуют, но встречаются довольно редко. Статический метод. Статический метод заключается в восстановления алгоритма защиты посредством анализа имеющегося в распоряжении программного обеспечения. Исполняемые файлы программы обычно состоят из заголовка, в котором содержится необходимая для работы вспомогательная информация, и последовательности исполняемых команд, записанные в машинных кодах команд процессора. В файлах программного обеспечения заключены все данные, нужные для восстановления алгоритма. Задача состоит лишь в том, чтобы найти соответствующие участки программы и перевести их на язык, понятный аналитику. В настоящее время имеется целый ряд программ анализа, которые облегчают перевод. Основу для такого перевода составляют программы дизассемблирования (дизассемблеры), которые переводят последовательность машинных кодов в листинг, близкий к исходному тексту программы на языке ассемблера. Эффективные программы перевода на более понятные языки высокого уровня, к сожалению, отсутствуют. Дальнейшая работа после дизассемблирования сводится к анализу полученных листингов, поиску участков, отвечающих за защиту информации, и перевод описания процедур функционирования алгоритмов защиты на понятный аналитику язык. Статический метод при отсутствии в программе специальных средств защиты от дизассемблирования позволяет полностью восстановить алгоритмы защиты. Он дает возможность понять структуру программы, способ вызова и взаимодействия отдельных модулей. Эффективность метода не зависит от сложности самих алгоритмов защиты. Успех здесь в меньшей степени зависит от удачливости аналитика. Это – достоинства метода. Для применения статического метода достаточно иметь в своем распоряжении программное обеспечение. Не требуется, чтобы анализируемая программа, имеющаяся у аналитика, была работоспособна. Это очень удобно в случаях, когда предметом исследований является программный комплекс, требующий дорогостоящих технических средств, которые отсутствуют у аналитика. Статический метод позволяет использовать и дополнительную информацию, содержащуюся в программном обеспечении (имена экспортируемых функций, вызываемых библиотек динамической компоновки и т.п.), что недоступно для метода экспериментов с черным ящиком. Статический метод в большей мере, чем другие подходы, допускает автоматизацию отдельных этапов анализа. С другой стороны, при применении статического метода аналитик может встретиться и со значительными трудностями. Далеко не всегда удается найти подходящую программу дизассемблирования. Для того чтобы провести дизассемблирование, надо знать, как осуществляется преобразование информации в вычислительной системе. А документация по этим вопросам для целого ряда мощных вычислительных систем, как правило, малодоступна. Положение, конечно, не является безвыходным. К любой вычислительной системе должны прилагаться программные средства, позволяющие пользователю разрабатывать собственные программы на привычных языках программирования или на модификациях этих языков. Должны прилагаться и соответствующие компиляторы, переводящие листинги программ в машинные коды соответствующей ЭВМ. В принципе аналитик на основе этих программ имеет возможность восстановить и способы обработки информации в вычислительной системе (например, методом экспериментов с черным ящиком). При этом, однако, аналитику придется решать сложные и трудоемкие задачи, далеко выходящие за рамки анализа конкретной системы защиты информации. При практической реализации алгоритмов дизассемблирования возникают следующие проблемы: 1. Проблема восстановления символических имен. В программе, написанной на языке ассемблера все переменные, метки, процедуры и сегменты имеют символические имена. При компиляции программы эти имена заменяются физическими адресами. В скомпилированном машинном коде не остается информации о символических именах, если, конечно, она специально не помещена туда для отладки или для взаимодействия с другими программами (например, динамически подгружаемые библиотеки Windows содержат таблицу имен экспортируемых функций, необходимую для их импорта программами). Обычно эта проблема решается путем «придумывания» дизассемблером символических имен типа var1, label2, proc3 и т.д. 2. Проблема различения команд и данных. В скомпилированной программе машинный код и данные отличаются друг от друга только по контексту использования. Например, машинная команда может непосредственно следовать за глобальной переменной. Если дизассемблер принимает код за данные или наоборот, текст, выдаваемый дизассемблером, становится бессмысленным. 3. Проблема определения границы машинной команды. Команды машинного кода следуют друг за другом подряд непосредственно, без каких-либо разделителей. При выполнении кода процессор начинает считывать очередную команду с байта, непосредственно следующего за только что выполненной командой. Если дизассемблер неправильно определяет границу команды, он неправильно восстанавливает эту команду и несколько команд, следующих за ней. Например, пусть мы имеем следующий машинный код: F7 D1 2B F9 Этот код дизассемблируется следующим образом: not cx sub di,cx Если же дизассемблер решил, что граница команд пролегает между байтами F7 и D1, то этот же код будет дизассемблирован следующим образом: shr word ptr [bp+di],1 stc Таким образом, программы дизассемблирования в своей работе могут допускать серьезные ошибки. Дизассемблеры условно можно разделить на “глупые” (dumb) и “умные” (smart). «Глупые» дизассемблеры даже не пытаются решить описанные проблемы, в результате чего результат работы дизассемблера напоминает ассемблеровский текст весьма отдаленно. В то же время “глупые” дизассемблеры преобразуют машинный код очень быстро (почти мгновенно). К «глупым» дизассемблерам относятся встроенные дизассемблеры отладчиков и антивирусных утилит, предназначенные для интерактивного просмотра небольших участков машинного кода. «Умные» дизассемблеры преобразуют машинный код в ассемблеровский настолько точно, что в отдельных случаях повторное ассемблирование приводит к тому же самому машинному коду. «Умные» дизассемблеры различают команды и данные, практически всегда правильно определяют границы машинных команд, выделяют в машинном коде отдельные функции, отслеживают перекрестные ссылки. Однако за такие возможности приходится платить. Время дизассемблирования программы «умным» дизассемблером может составлять десятки минут. Любой дизассемблер не в состоянии восстановить машинный код самораскрывающейся или самошифрующейся программы. В этом случае дизассемблер либо выдает бессмысленную последовательность команд, либо интерпретирует большую часть программы как данные. Для получения полного ассемблеровского текста оверлейной программы необходимо дизассемблировать все ее оверлейные модули. Существует ряд приемов программирования, при применении которых генерируется машинный код, некорректно воспринимаемый дизассемблером. Следует отметить, что современные программные продукты имеют размер, измеряемый десятками и сотнями мегабайт, листинг программы на языке ассемблера обычно в десятки раз превосходит по размерам исполняемый файл. Значительная часть программного обеспечения связана с организацией интерфейса, анализом конфигурации ЭВМ, распределением и загрузкой памяти и т.п. Таким образом, большая часть программы никак не связана с защитой, и описания алгоритмов защиты (или других алгоритмов, интересующих аналитика) занимают мизерную часть программного обеспечения. Найти их в тексте программы не проще, чем иголку в стоге сена. Особую трудность составляет то обстоятельство, что отдельные, сравнительно небольшие и обозримые участки листинга мало информативны с точки зрения понимания функций, исполняемых данным участком программы. Расположены отдельные блоки программы в исполняемом файле достаточно хаотично. В связи с вышеизложенным актуальной является задача разработки специальных программных средств автоматизации анализа ассемблеровских листингов. Эти средства должны обладать элементами искусственного интеллекта. Они должны уметь строить графы вызова процедур, по тем или иным признакам автоматически выделять нужные участки листинга, осуществлять автоматический перевод текста с ассемблера на более понятный язык и т.п. К сожалению, разработка подобных программных средств является весьма трудоемкой, хотя и разрешимой задачей. Указанные программные средства будут иметь достаточно ограниченный спрос. Поэтому в настоящее время проработка вопросов автоматизации анализа находится лишь в зачаточном состоянии. В настоящее время статический метод используется чаще всего как вспомогательный инструмент для проверки предположений о восстанавливаемых алгоритмах защиты. Большинство аналитиков отдают предпочтение описываемому ниже динамическому методу. На наш взгляд, роль статического метода может возрасти по мере развития средств автоматизации анализа и дальнейшего усложнения и увеличения по объему программного обеспечения анализируемых продуктов. Применение статического метода для восстановления алгоритма генерации псевдослучайных чисел компилятора Turbo C. Постановка задачи. Используем статический метод анализа с применением дизассемблера Sourcer для решения задачи восстановления алгоритма генерации псевдослучайных чисел программы Turbo C, вызываемой функциями srand – задание начального положения генератора и rand – получение очередного псевдослучайного числа. Данная задача имеет самостоятельный интерес. Разработчики алгоритмов защиты нередко, когда у них появляется потребность в получении последовательностей псевдослучайных чисел, используют стандартные, датчики псевдослучайных чисел (ДСЧ), встроенные в программное обеспечение. Поэтому полезно знать, как устроен такой ДСЧ. Данный пример полезен и как прототип для решения других похожих задач. Нередко разработчики предлагают специализированные библиотеки, содержащие процедуры защиты. Каждый обладатель библиотеки может включать процедуры из нее в свои программные продукты, решая с минимальными затратами проблемы защиты информации. В подобных случаях для оценки качества предлагаемой защиты необходимо восстановить алгоритм защиты, включенный в библиотеку. Получение листинга программы. Один из возможных способов (далеко не единственный) восстановления алгоритма заключается в построении в среде Turbo C программы, включающей процедуру генерации псевдослучайных чисел, компиляции программы, дизассемблировании исполняемого файла программы и восстановлении из полученного листинга интересующего нас алгоритма. Приступим к реализации этого плана. Ниже приведен листинг на языке С одного из вариантов программы, включающей процедуры srand и rand.
- include <stdio.h>
- include <stdlib.h>
void Rand(int u0,int SeqLength);
// // Точка входа в программу // main ()
{ Rand (13, 10);
}
// // Функция Rand генерирует псевдослучайную последовательность длины SeqLength. // Используется стандартный ДСЧ Turbo C. В качестве начальной установки ДСЧ берется // u0. void Rand (int u0, int SeqLength)
{ // Очередное псевдослучайное число
int r;
// Счетчик цикла
int i;
// Задаем начальную установку ДСЧ
srand(u0);
// Печать пустой строки
printf (“\r\n”);
for(i = 0; i < SeqLength; i++)
{ // Генерируем очередное псевдослучайное число
r = rand();
// Инвертируем младший бит полученного числа
r ^= 1;
// Распечатываем результат
printf(“%d “,r);
}
}
Нами выбран довольно нестандартный вариант генерации псевдослучайной последовательности. Сделано это умышленно. В дальнейшем нам придется в дизассемблированном листинге выделить участок, отвечающий интересующим нас функциям. Сделать это будет проще, если участок будет достаточно большим и нестандартным по внешнему виду. Следующий шаг состоит в сохранении программы в файле rand.c и его компиляции – создании исполняемого файла rand.exe. При компиляции следует указать модель памяти small. В данном примере мы скомпилировали exe-файл без отладочной информации. Дело в том, что если дизассемблер понимает формат отладочной информации компилятора, он генерирует гораздо более простой и понятный листинг, разобраться в котором гораздо проще. Но то программное обеспечение, которое продается в магазинах, в подавляющем большинстве случаев поставляется без отладочной информации! Поскольку наша цель – продемонстрировать технику применения статического метода, мы решили усложнить себе задачу, приблизив ее сложность к среднему для подобных задач уровню. Если бы такая задача возникла на практике, естественно, отладочную информацию обязательно нужно было включить в exe-файл. Теперь нам необходимо запустить командной строкой sr программу Sourcer, нажать клавишу I и задать имя входного файла rand.exe, затем нажать O и набрать имя выходного файла rand.lst, проверить правильность установленных по умолчанию опций и при необходимости их откорректировать и, наконец, нажав G, запустить программу дизассемблирования. После завершения работы программы в текущей директории мы обнаруживаем созданный программой файл rand.lst с листингом программы, полученным в результате дизассемблирования. Теперь нам нужно найти в этом листинге участки, отвечающие процедурам srand и rand и перевести их текст на понятный математикам язык. Заметим, что это не простая задача. Файл rand.c составленной нами программы содержит 318 байт, исполняемый файл rand.exe имеет 9257 байт, а файл rand.lst уже содержит 131666 байт. Ситуация, когда исполняемый файл более чем в 10 раз больше файла с листингом на языке высокого уровня и в свою очередь в десятки или сотни раз меньше результата дизассемблирования, является типичной. Если распечатать листинг средствами DOS, то он займет 58 страниц мелкого текста. Для того чтобы найти в этом тексте интересующие нас участки, необходимо более детально познакомиться с особенностями компиляции исходных текстов программ в исполняемые файлы. Типовые особенности компиляции программ. Вид листинга дизассемблера определяется способом преобразования программы на языке высокого уровня в машинные коды, осуществляемого компилятором. Поэтому при анализе листинга неплохо знать, с помощью какого компилятора был сгенерирован машинный код. Вместе с тем, большинство компиляторов придерживаются сложившейся практики генерации кода. Аналитику в своей работе следует ориентироваться на эти соглашения, отдавая себе отчет, что конкретный компилятор совсем не обязан им следовать. К наиболее существенным для анализа относятся следующие правила: 1. Программа обычно начинается с вспомогательных процедур (проверка версии операционной системы, получение системной даты и системного времени компьютера и т.п.). 2. При компиляции программы код каждой функции занимает непрерывный участок файла и не прерывается фрагментами, относящимися к другим функциям. 3. Параметры передаются функции, как правило, через стек. Вызывающая функция записывает в стек последовательно каждый аргумент, а затем адрес памяти, куда должна возвратиться программа после исполнения вызываемой функции. Таким образом, в момент вызова функции в стеке, начиная с его вершины, оказываются записаны адрес возврата и аргументы функции. Параметры могут записываться, начиная с первого (стиль компиляторов языка Pascal) или начиная с последнего (стиль компиляторов языка С). 4. Для каждого аргумента функции используется целое машинное слово, даже если реальный размер аргумента меньше. 5. Адресация при обращении программы к сегменту стека осуществляется через регистр bp (для 32-разрядных программ – ebp или esp). Если программа откомпилирована с использованием 16-разрядного компилятора в модели памяти small, параметры функции располагаются по адресам [bp+4], [bp+6], … 6. Большинство функций 16-разрядной программы начинаются командами push bp mov bp,sp а большинство функций 32-разрядной программы – командами push ebp mov ebp,esp 7. При выполнении функции для хранения промежуточных результатов используются регистры процессора. Для того чтобы информация, хранившаяся в регистрах до этого, не была потеряна, обычно в начале функции значения регистров копируются в стек командой push, а в конце –восстанавливаются командой pop. 8. Если процедура имеет локальные переменные, то их значения также хранятся в стеке. В этом случае в начале процедуры присутствует команда sub sp, n (или sub esp, n), где n – количество байтов, выделяемых под локальные переменные. Обращение к данным переменным проводится по адресам вида [bp-1], [bp-2], … (или [ebp-1], [ebp-2], …). Многие компиляторы оптимизируют генерируемый код таким образом, что наиболее часто используемые локальные переменные хранятся не в стеке, а в регистрах процессора. 9. Возвращаемое значение функции записывается в зависимости от типа возвращаемого значения и разрядности кода программы в регистр al, ax, eax или в пару регистров dx:ax. 10. Имеются традиционные способы реализации простейших операций языка высокого уровня. Так, обнуление регистра осуществляется командой xor или sub. (например, xor ax, ax или sub ax, ax), Операции “^” языка С соответствует команда xor, операции “=” – mov или lea и т.п. Восстановление алгоритма генерации псевдослучайных чисел Turbo C. Для восстановления алгоритма генерации псевдослучайных чисел загрузим полученный с помощью дизассемблера Sourcer листинг в какой-нибудь текстовый редактор. Желательно иметь также под рукой справочник по командам языка ассемблер. Прежде всего, найдем участок листинга, содержащий функцию Rand. Здесь нам может помочь то, что мы заранее включили в эту функцию достаточно нетипичный для подобных программ оператор r ^= 1; Выше отмечалось, что операции ^ на языке ассемблер обычно соответствует команда xor. Давайте осуществим средствами выбранного редактора последовательный просмотр всех мест листинга, где встретился этот оператор. Мы многократно встретим команды обнуления регистра вида xor bx, bx и лишь один раз наткнемся на команду 70A7:0346 xor ax,1 Эта команда относится к функции, которой дизассемблер присвоил имя sub_10. Детальный анализ последовательности команд убеждает нас, что это – функция Rand. Ниже приведен этот участок с нашими комментариями. Комментарии дизассемблера нами опущены. Их можно найти в листинге, приведенном в предыдущем пункте. sub_10 proc near ;Функция Rand (u0.dlina) 70A7:0327 push bp ;Стандартная процедура сохранения регистров 70A7:0328 mov bp,sp 70A7:032A push si 70A7:032B push di 70A7:032C push word ptr [bp+4];Пересылка в стек аргумента u0 70A7:032F call sub_19 ;Вызов функции srand 70A7:0332 pop cx 70A7:0333 mov ax,14B0h ;Пересылка в стек адреса константы “\r\n” 70A7:0336 push ax 70A7:0337 call sub_16 ;Вызов функции printf 70A7:033A pop cx ;Очистка стека 70A7:033B xor di,di ;Обнуление счетчика цикла i 70A7:033D jmp short loc_15 ;Первый вход в цикл 70A7:033F loc_14: ;Начало цикла по i 70A7:033F call sub_20 ;Вызов функции rand 70A7:0342 mov si,ax ;Присвоение переменной r возвращаемого значения 70A7:0344 mov ax,si 70A7:0346 xor ax,1 ;Оператор r^=1 70A7:0349 mov si,ax 70A7:034B push si ;Пересылка в стек r 70A7:034C mov ax,14B3h ;Пересылка в стек адреса константы “%d “ 70A7:034F push ax 70A7:0350 call sub_16 ;Вызов функции printf 70A7:0353 pop cx ;Очистка стека 70A7:0354 pop cx 70A7:0355 inc di ;Увеличение значения счетчика i 70A7:0356 loc_15: 70A7:0356 cmp di,[bp+6] ;Сравнение i и SeqLength 70A7:0359 jl loc_14 ;Выход из цикла или возврат на начало 70A7:035B pop di ;Восстановление регистров 70A7:035C pop si 70A7:035D pop bp 70A7:035E retn ;Возврат из функции sub_10 endp Учитывая цели анализа, нас должны заинтересовать в первую очередь подпрограммы sub_19 и sub_20, поскольку, судя по всему, именно они реализуют функции srand и rand. Найти эти программы в листинге уже несложно. Достаточно осуществить средствами редактора поиск слов sub_19 и sub_20. Рассмотрим листинг программы sub_19. sub_19 proc near ;Функция srand 70A7:07E1 push bp ;Стандартное начало функции 70A7:07E2 mov bp,sp 70A7:07E4 mov ax,[bp+4] ;Пересылка по адресу ds:data_14e аргумента u0 70A7:07E7 mov ds:data_14e,ax 70A7:07EA mov word ptr ds:data_15e,0 ;Обнуление ячейки ds:data_15e 70A7:07F0 pop bp ;Стандартный конец функции 70A7:07F1 retn ;Возврат из функции sub_19 endp Просматривая строку за строкой листинг, мы видим, что программа делает две простых вещи: записывает аргумент функции srand, равный [bp+4], в оперативную память по адресу ds:data_14e и обнуляет машинное слово по адресу ds:data_15e. Программа sub_20 проводит некоторые манипуляции, при этом вызывает подпрограмму sub_50. Нам удобнее вставить эту подпрограмму в текст sub_20 и рассмотреть общий листинг. Проанализируем последовательно все проводимые преобразования. Чтобы не запутаться, удобно после каждого преобразования фиксировать содержимое всех текущих регистров. Для 32-х разрядного числа V мы будем обозначать через H(V) и через L(V) соответственно старшие и младшие разряды числа. sub_20 proc near 70A7:07F2 mov cx,ds:data_15e 70A7:07F6 mov bx,ds:data_14e В регистры cx и bx заносится содержимое ячеек памяти ds:data_15e и ds:data_14e. Напомним, что заполнение этих ячеек было задано функцией srand. bx=ds:data_14e, cx=ds:data_15e При первом обращении к подпрограмме ds:data_14e=u0, ds:data_15e=0. 70A7:07FA mov dx,15Ah 70A7:07FD mov ax,4E35h В dx заносится число 15Ah, а в ax – число 4E35h. ax=4E35h, bx=ds:data_14e, cx=ds:data_15e, dx=15Ah 70A7:0800 call sub_50 Вызывается функция sub_50. Никакие параметры в стек не записываются. Все дальнейшее до команды retn относится к функции sub_50. 70A7:13F3 push si 70A7:13F4 xchg ax,si Меняется местами содержимое регистров ax и si. Теперь si = 4E35h. ax=?, bx=u0, cx=0, dx=15Ah, si=4E35h 70A7:13F5 xchg ax,dx Меняется местами содержимое dx и ax. Теперь ax = 15Ah. ax=15Ah, bx=ds:data_14e, cx=ds:data_15e, dx=?, si=4E35h 70A7:13F6 test ax,ax 70A7:13F8 jz loc_263 Если ax = 0, то осуществляется переход. В нашем случае ax не может равняться 0. Поэтому эти две команды фактически являются лишними. 70A7:13FA mul bx Команда mul осуществляет беззнаковое умножение содержимого регистра bx на содержимое регистра ax. Результат заносится в регистровую пару dx:ax. Произведение является 32-разрядным числом. Старшие 16 разрядов находятся в регистре dx, а младшие – в регистре ax. Данная команда объясняет, зачем было нужно менять местами содержимое регистров. Этим осуществлялась подготовка к выполнению умножения. Таким образом, в регистровой паре dx:ax находится произведение bx и ax. При первом обращении произведение равно bx*15Ah=u0*15Ah. ax=L(15Ah*ds:data_14e), bx=ds:data_14e, cx=ds:data_15e, dx=H(15Ah*ds:data_14e), si=4E35h 70A7:13FC loc_263: 70A7:13FC jcxz loc_264 Если cx=0, то происходит переход по адресу loc_264. При первом обращении cx=0. 70A7:13FE xchg ax,cx Меняются местами ax и cx. При первом обращении cx=0 и, следовательно, ax=0. В регистре cx теперь оказывается младшая половина произведения bx*15Ah. ax=ds:data_15e, bx=ds:data_14e, cx=L(15Ah*ds:data_14e), dx=H(4E35h*ds:data_15e), si=4E35h. 70A7:13FF mul si После умножения в регистровой паре dx:ax оказывается записано ax*si=ax*4E35h. ax=L(4E35h*ds:data_15e), bx=ds:data_14e, cx=L(15Ah*ds:data_14e), dx=H(4E35h*ds:data_15e), si=4E35h. 70A7:1401 add ax,cx Производится прибавление к регистру ax содержимого регистра cx. ax=L(4E35h*ds:data_15e)+L(15Ah*ds:data_14e), bx=ds:data_14e, cx=L(15Ah*ds:data_14e), dx=H(4E35h*ds:data_15e), si=4E35h. 70A7:1403 loc_264: 70A7:1403 xchg ax,si Меняются местами ax и si. ax=4E35h, bx=ds:data_14e, cx=L(15Ah*ds:data_14e), dx=H(4E35h*ds:data_15e), si=L(4E35h*ds:data_15e)+L(15Ah*ds:data_14e) 70A7:1404 mul bx Очередное умножение. ax=L(4E35h*ds:data_14e), bx=ds:data_14e, cx=L(15Ah*ds:data_14e), dx=H(4E35h*ds:data_14e), si=L(4E35h*ds:data_15e)+L(15Ah*ds:data_14e). 70A7:1406 add dx,si Очередное сложение. ax=L(4E35h*ds:data_14e), bx=ds:data_14e, cx=L(15Ah*ds:data_14e), dx=H(4E35h*ds:data_14e)+ +L(4E35h*ds:data_15e)+L(15Ah*ds:data_14e), si=L(4E35h*ds:data_15e)+L(15Ah*ds:data_14e) 70A7:1408 pop si 70A7:1409 retn sub_50 endp Конец функции sub_50. 70A7:0803 add ax,1 70A7:0806 adc dx,0 К ax добавляется 1. Если происходит переполнение, то бит переполнения добавляется к dx. Данные преобразования удобно трактовать следующим образом. Если под парой dx:ax понимать 32-битовое число, то в результате выполнения последних двух команд к этому числу просто добавлена единица. В терминах 32-битовых чисел удобно трактовать и остальные преобразования, выполненные программой. А именно, пусть U(t) - число, определяемое парой ячеек памяти ds:data_15e и ds:data_14e, U(t+1) – число, определяемое парой регистров dx и ax, C – число, задаваемое парой чисел 15Ah и 4E35h, C=15A4E35h. Тогда U(t+1)=1+U(t)*C (mod 232) 70A7:0809 mov ds:data_14e,ax 70A7:080C mov ds:data_15e,dx Подтверждая нашу трактовку, программа заносит в оперативную память новое значение U(t+1). Таким образом, программа реализует рекуррентное преобразование U(t+1)=1+U(t)*C (mod 232) с начальными условиями U(0)=u0, где u0 - начальное состояние, задаваемое как аргумент функции srand. 70A7:0810 mov ax,ds:data_15e Данная команда заносит в ax старшие разряды числа U(t+1). 70A7:0813 cwd Команда cwd расширяет арифметическое значение в регистре ax до размеров двойного слова, дублируя при этом знаковый (самый старший) бит ax через регистр dx. Обычно эта команда используется для получения 32-битового делимого. 70A7:0814 and ax,7FFFh Происходит обнуление старшего бита регистра ax. В результате всех действий в регистре сформировано возвращаемое значение подпрограммы – целое число, заключенное в пределах от 0 до 215-1. 70A7:0817 retn sub_20 endp В итоге имеем, что псевдослучайное число R(t) в обозначениях языка С получается по формуле R(t)=(U(t+1)%231)/216 где U(t+1)=1+U(t)*C(mod 232), C=15A4E35h, начальное состояние рекурренты U(0)=u0 задается как аргумент функции srand. Указанный способ генерации псевдослучайных чисел широко известен как линейный смешанный конгруэнтный метод. Динамический метод. Динамический метод восстановления алгоритмов защиты основан на использовании программных отладочных средств (отладчиков). Отладчик – это программа, которая загружает в память другую программу и предоставляет пользователю возможность наблюдать за ходом выполнения этой программы. Существует достаточно много отладчиков. Среди наиболее распространенных можно назвать Turbo Debugger, SoftIce, WinDbg. Большинство современных компиляторов имеют встроенные отладчики. Выбор отладчика зависит от цели его применения. Для анализа машинного кода EXE-файла, не имеющего отладочной информации, можно использовать только специализированный (не встроенный) отладчик. Из перечисленных отладчиков наиболее удобны в использовании Turbo Debugger и WinDbg, имеющие удобный многооконный интерфейс. Однако наблюдается следующая закономерность: чем более отладчик удобен, тем менее он эффективен. Под эффективностью здесь понимается способность «проникать» в системные области памяти и противостоять защите от отладчика. Основные принципы функционирования отладчика. Механизм работы любого отладчика основан на использовании специальных средств, аппаратно реализованных в процессорах ЭВМ. Для процессоров семейства Intel x86 к этим средствам относятся: 1. Флаг трассировки (Trace flag, tf). Это – бит 8 регистра флагов. Когда этот бит равен единице, процессор после выполнения каждой машинной команды вызывает прерывание 1. Флаг трассировки используется отладчиками для организации пошагового прохода программы. В этом случае отладчик перехватывает прерывание 1, и после выполнения каждой машинной команды отлаживаемой программы отображает на экране состояние регистров процессора, флагов, сегментов памяти и т.д. 2. Точка останова (Breakpoint). Машинный код команды вызова прерывания 3 (int 3), в отличие от других прерываний, занимает всего один байт. Поэтому эта команда может быть вставлена в любое место отлаживаемой программы. Отладчик перехватывает прерывание 3, и после установки точки останова (замены первого байта машинной команды на байт CCh – код команды int 3) передает управление отлаживаемой программе. Перед выполнением команды, на которой стоит точка останова (команды, первый байт которой заменен на CCh), управление передается в отладчик. Перед повторным запуском отлаживаемой программы отладчик должен восстановить исправленную команду. 3. Отладочные регистры (Debug registers). Начиная с модели 80386, процессоры семейства Intel имеют восемь отладочных регистров. Эти регистры позволяют разместить в памяти ЭВМ четыре аппаратные точки останова. В отличие от обычных точек останова, аппаратные обладают более широкими возможностями. Отлаживаемая программа может быть остановлена не только при выполнении определенной команды, но и при обращении к определенному участку памяти. При остановке программы аппаратной точкой останова вызывается прерывание 1. Наличие аппаратных точек останова несколько замедляет работу программы. 4. Карта портов. Когда процессор (модель 386 или выше) работает в защищенном режиме, каждая задача (процесс или поток) имеет свой сегмент состояния задачи (TSS). При аппаратном переключении задач в этом сегменте сохраняется текущее состояние прерванной задачи. Кроме того, TSS содержит карту портов, описывающую, к каким портам данная задача может обращаться и каким образом (чтение, запись, и то, и другое, или вообще не может обращаться). Когда программа пытается обратиться к порту, доступ к которому ей запрещен, на процессоре возникает исключительная ситуация – вызывается соответствующее прерывание. Отладчик, загружая программу, модифицирует ее TSS таким образом, что отлаживаемой программе запрещена работа со всеми портами. После этого при каждом обращении отлаживаемой программы к портам генерируется исключительная ситуация, вызывается прерывание, которое перехватывается отладчиком. Отладчик, обнаружив факт обращения отлаживаемой программы к порту, либо пытается разрешить доступ «своей властью», либо, если на данный порт пользователем установлена точка останова, останавливает выполнение программы. Основные функции отладчиков. Отладчики реализуют следующие возможности: • пошаговый проход программы (трассировка); • пошаговый проход программы, при котором вызов функции обрабатывается как одна команда; • пошаговый проход программы с «провалом» в прерывания; • установка/снятие точки останова с заданной команды; • установка/удаление аппаратной точки останова; • установка/удаление точки останова с порта/портов; • выполнение участка программы до ближайшей точки останова; • выполнение участка программы до команды, подсвеченной курсором, или до ближайшей точки останова; • перезагрузка программы; • просмотр кода/памяти/регистров/флагов/стека; • поиск строки в памяти; • поиск машинной команды в памяти; • изменение содержимого регистров/флагов/памяти/кода; • чтение порта или запись в порт. Перечислены только те функции отладчика, которые могут использоваться для анализа машинного кода, для которого неизвестен исходный текст. В момент остановки отладчики позволяют просматривать содержимое оперативной памяти как в 16-ичном виде, так и в виде дизассемблированного кода. Встроенные дизассемблеры отладчиков всегда относятся к числу «глупых» (dumb), однако это практически не затрудняет работу с отладчиком, поскольку данные легко отличаются от команд по контексту обращений к ним. Следует иметь в виду, что неаккуратное обращение с отладчиком можно привести к краху операционной системы, а в отдельных (очень редких) случаях и к разрушению файловой системы дисков компьютера. Некоторые факторы, ограничивающие возможности отладчика. 1. Отладчик не может установить точку останова (кроме аппаратных) в ПЗУ, поскольку данный участок памяти физически не может быть изменен. Если программа на низком уровне работает с системными буферами базовой системы ввода-вывода (BIOS), расположенной в ПЗУ, может возникнуть необходимость подробного анализа отдельных функций BIOS. Поскольку при этом доступны лишь пошаговый проход и аппаратные точки останова, подобный анализ является весьма нетривиальной задачей. Впрочем, единственной программой из числа исследованных авторами до настоящего времени, напрямую взаимодействующей с BIOS через системные буферы, является игра Microprose Stealth Fighter F-19. 2. В отдельных случаях отладчик может конфликтовать с драйвером аппаратуры. Это происходит тогда, когда драйвер некорректно выполняет некоторую функцию, используемую самим отладчиком. Например, резидентный драйвер, устанавливающий таймер на полночь и держащий его в таком положении до перезагрузки компьютера, моментально «вешает» Turbo Debugger. 3. Большинство отладчиков зависают, если какая-либо из системных программ, кроме него самого, переключает процессор в другой режим (из реального в защищенный, из защищенного в виртуальный и т.д.). 4. Отладчик может зависнуть, если хотя бы одна точка останова установлена внутри самого отладчика или функции операционной системы, используемой отладчиком. В этом случае происходит зацикливание: точка останова передает управление в функцию отладчика, анализирующую изменения в регистрах и памяти, в процессе анализа отладчик снова встречает ту же самую точку останова, снова передает управление в ту же функцию анализа и т.д. Другими словами, отладчик не может отлаживать сам себя. Зацикливание также может произойти, если аппаратная точка останова установлена так, что срабатывает при изменении некоторого участка памяти в сегменте стека. Это связано с тем, что исследуемая программа, отладчик и операционная система используют общий сегмент стека. Поэтому аппаратная точка останова может сработать внутри отладчика или операционной системы, что, как в предыдущем случае, приводит к зацикливанию. 5. Если программа имеет оверлейную структуру, т.е. в каждый момент времени в памяти находятся только те функции и данные, которые необходимы программе в данный момент, возможна «потеря точки останова», когда программа записывает поверх функции, содержащей точку останова, другую функцию. 6. Если программа работает в многозадачной операционной системе с принудительным переключением задач (типа Windows NT), возможны проблемы, связанные с тем, что в системе одновременно выполняются несколько экземпляров отлаживаемого кода. 7. Существует множество приемов программирования, которые позволяют так модифицировать программу, что она не может быть исследована под отладчиком. Говорят, что такая программа защищена от отладчика. Более подробно эти приемы рассматриваются в следующей главе. Методика изучения программ динамическим методом. Анализ программы динамическим методом разбивается на следующие этапы: 1. Поиск подходов к интересующим функциям программы (найти путь, по которому идти). 2. Поиск интересующих функций программы (пройти этот самый путь). 3. Анализ интересующих функций программы. Поиск подходов к интересующим функциям программы. При анализе машинного кода первой задачей является выявление в необозримом массиве машинного кода программы некоторых «зацепок», позволяющих достаточно быстро подобраться к интересующим функциям. Существуют два метода решения этой задачи – метод маяков и метод Step-Trace. Метод маяков. Метод маяков основан на установке точек останова на так называемые маяки – точки программы, в которых программа выполняет действия, легко понимаемые без знания контекста, в котором эти действия выполняются. В роли маяков обычно выступают системные вызовы. Для примера рассмотрим фрагмент листинга кода, полученный с помощью встроенного дизассемблера отладчика Turbo Debugger. cs:2D85 B440 mov ah,40 cs:2D87 8B5E06 mov bx,[bp+06] cs:2D8A 8B4E0A mov cx,[bp+0A] cs:2D8D 8B5608 mov dx,[bp+08] cs:2D90 CD21 int 21 Легко понять, что этот участок кода выполняет системный вызов DOS «запись в файл». Также легко видно, что первый параметр текущей функции представляет собой дескриптор файла, второй параметр является ближним указателем на буфер с данными, записываемыми в файл, третий определяет количество байт, которые нужно записать в файл. Таким образом, обнаружив в функции маяк, мы смогли легко выяснить смысл трех параметров функции. При применении метода маяков аналитик должен выбрать в изучаемой программе интересующие его маяки (например, если анализируется программа непрозрачного шифрования файлов, в качестве маяков целесообразно выбрать обращения программы к файловой системе) и установить на них точки останова. Это можно сделать двумя способами: 1. Найти в программе все маяки и установить на каждый точку останова. 2. Установить точку останова в обработчик соответствующего системного вызова. Второй способ проще (требуется устанавливать меньшее количество точек останова), но может привести к «зависанию» отладчика. Если отладчик использует данный системный вызов для своих нужд, то внутри отладчика возможно зацикливание. Кроме того, поведение многих системных вызовов операционных систем (например, системного вызова int 21h MS-DOS) существенно зависит от параметров вызова. Если поставить точку останова в обработчик такого вызова, она будет срабатывать при каждом обращении к данной системной функции, что во многих случаях неудобно. Первый способ менее удобен, но более надежен – при его использовании сбои отладчика исключены. Его следует использовать в тех случаях, когда второй способ неприменим. После того, как на интересующие маяки установлены точки останова, программа запускается под отладчиком. При каждом проходе очередного маяка выполнение программы приостанавливается и аналитик, просматривая содержимое регистров и памяти, получает информацию о ходе выполнения программы (порядок выполнения системных вызовов, параметры этих вызовов, расположение в памяти передаваемых операционной системе или получаемых от операционной системы буферов). Объем и ценность получаемой информации определяются выбором маяков. Метод Step-Trace. Метод Step-Trace получил свое название по двум режимам трассировки программы отладчика Turbo Debugger – с входом во вложенные функции программы (Trace, клавиша F7) и без входа (Step, клавиша F8). Суть метода заключается в пошаговом проходе изучаемой программы с попеременным использованием обоих режимов. Метод может быть использован, для поиска в анализируемой программе функции x, удовлетворяющей следующим условиям: 1. Функция x реализует интересующие аналитика алгоритмы. 2. Вызов функции x легко обнаруживается аналитиком по внешним проявлениям программы. Этим условиям удовлетворяет, например, функция ввода пароля с клавиатуры. При применении метода Step-Trace вначале в режиме Step покомандно проходится главная функция программы. При проходе через вызов одной из вложенных функций, назовем ее f1, мы убеждаемся, что внутри этого вызова вызывается интересующая нас функция, например программа запрашивает у пользователя пароль. На втором этапе программа перезагружается, главная функция проходится в режиме Step до команды call f1. Затем с помощью команды Trace производится переход внутрь этой функции и тело функции f1 пошагово проходится в режиме Step до тех пор, пока не встретится вызов функции, скажем, f2, внутри которого вызывается функция x. После того, как обнаружена функция f2, программа снова перезагружается, главная функция проходится в режиме Step до вызова f1, в режиме Trace управление передается внутрь f1, далее f1 проходится в режиме Step до вызова f2, управление передается внутрь f2, внутри f2 ищется вызов функции, вызываемой из f2, в котором выполняются интересующие нас действия. Когда такая функция найдена, программа опять перезагружается и т.д. В процессе выполнения этих операций полезно записывать на бумаге последовательность вызовов функций, ведущих к функции x. При использовании данного метода не следует использовать точки останова, поскольку это может привести к тому, что будет анализироваться последовательность вложенных вызовов функций, заведомо не ведущая к функции x. Эту ситуацию иллюстрирует следующий рисунок.
Предположим, что аналитик, проведя две итерации метода Step-Trace, убедился, что интересующая его функция x вызывается внутри функции f3 в последовательности вложенных вызовов, обозначенных тонкой линией. Если после перезагрузки программы аналитик вместо того, чтобы заново пошагово пройти эту последовательность, поставит точку останова в начале функции f3, то после запуска программы отладчик в первый раз остановится на этой точке, когда функция f3 будет вызвана из f1 в последовательности вызовов, обозначенной жирной линией. Функция x в этой последовательности не вызывается (в противном случае это было бы обнаружено на первой итерации). Таким образом, в процессе дальнейшего анализа программы будет изучаться последовательность вызовов, не ведущая к искомой функции x. Обычно при использовании данного метода требуется пройти 10-20 итераций. Метод Step-Trace очень эффективен, если в качестве функции x выбрана функция, принимающая решение разрешить или запретить пользователю выполнение некоторого действия. Например, при анализе игры Microprose Stealth Fighter F-19 в качестве функции x была выбрана функция, принимающая решение о результатах угадывания пользователем силуэта самолета. Результат выполнения этой функции хорошо виден на экране компьютера, так что эта функция удовлетворяет условиям на функцию x. Подход к этой функции по методу трассировки занял менее двух часов. После выявления места расположения этой функции в коде программы вскрытие защиты стало тривиальным (осталось только заменить в коде программы команду условного перехода на команду возврата из функции). Поиск интересующих функций программы. По окончании первого этапа анализа программы динамическим методом мы знаем либо расположение в коде программы одной из интересующих нас функций, либо расположение в памяти буферов, содержащих интересующие данные. Задачей второго этапа анализа программы является выявление всех функций анализируемой программы, реализующих интересующие нас алгоритмы. Второй этап заключается в анализе потоков данных внутри программы и выяснении путей преобразования этих данных. На втором этапе анализа программы эффективно работают два метода – метод аппаратной точки останова и метод Step-Trace. Метод аппаратной точки останова. Этот метод целесообразно использовать в качестве продолжения метода маяков. В этом случае по окончании первого этапа нам известно расположение в памяти буферов с интересующими данными в определенные моменты выполнения программы. Требуется выявить в программе функции, заполняющие или анализирующие эти буфера. Суть метода заключается в установке на интересующие данные аппаратной точки останова, срабатывающей при чтении данных из буфера или записи данных в буфер в зависимости от того, что происходит с буфером в процессе работы анализируемой программы. Как только данные изменены или прочитаны процессором, отладчик останавливается на команде, следующей за той, которая изменила или использовала интересующие данные. Остается выяснить характер работы программы с интересующими данными и, если это неинтересно, продолжить отслеживание преобразований этих данных. Данный метод весьма эффективен, если интересующие данные лежат не в стеке. В противном случае возможно зацикливание внутри отладчика. Метод Step-Trace. Метод Step-Trace может применяться и на втором этапе анализа программы. В этом случае искомая функция x должна удовлетворять всего одному условию – функция x изменяет интересующие нас данные. При использовании данного метода на втором этапе анализа программы трассировка начинается не с начала программы, а с момента либо прохода маяка, либо завершения трассировки на первом этапе. Тот факт, что функция x была вызвана внутри некоторого вызова функции, устанавливается не по внешнему виду экрана компьютера, а по состоянию интересующих нас буферов памяти. Если в момент прохода вызова некоторой функции в режиме Step содержимое буферов изменилось, это означает, что функция x вызывается внутри данного вызова. В остальном применение метода Step-Trace на втором этапе ничем не отличается от его применения на первом этапе. Анализ интересующих функций программы. К началу третьего этапа анализа машинного кода все интересующие функции программы уже выявлены. Осталось только выяснить, в чем, собственно, заключаются алгоритмы, реализуемые этими функциями. Обычно для этого достаточно внимательно просмотреть дизассемблированные листинги интересующих функций. Если листинги выглядят слишком сложными для понимания, можно попробовать вручную перевести машинный код функции на один из языков программирования высокого уровня. После того, как выдвинута гипотеза о сути интересующих алгоритмов, эту гипотезу нужно обязательно проверить. Для этого можно, например, запрограммировать интересующий алгоритм на языке высокого уровня, вставить в тестовую программу, запустить и посмотреть, совпадает ли ее поведение в части анализируемых алгоритмов с поведением изучаемой программы. Как правило, на этапе проверки полученных результатов выявляются ошибки в понимании анализируемого алгоритма. В среднем для полного восстановления алгоритма работы программы требуется три четыре итерации анализа/проверки. Особенности анализа некоторых видов программ. Особенности анализа оверлейных программ. Обычно весь код и все данные запущенной программы постоянно находятся в оперативной памяти. Однако существуют так называемые оверлейные программы, которые размещают в оперативной памяти только те фрагменты кода, которые выполняются в данный момент. При переполнении оперативной памяти ненужные более функции программы удаляются из памяти, и занимаемая ими память освобождается. При необходимости эти функции могут быть повторно считаны с диска. При анализе оверлейной программы возникает проблема, выражающаяся в потере точек останова, установленных внутри программы. Когда программа удаляет из оперативной памяти участок кода, в котором установлена точка останова, из памяти удаляется и точка останова (байт CCh). Когда данный участок кода повторно считывается с диска в оперативную память, вместо байта CCh в память считывается байт, который был на этом месте до установки точки останова, и точка останова не восстанавливается. Таким образом, если изучаемая программа является оверлейной, нельзя исключать, что установленная точка останова будет потеряна до того момента, когда на нее будет передано управление. При использовании метода Step-Trace для изучения оверлейных программ также возникают трудности. Дело в том, что для оверлейных программ довольно частой является ситуация, когда после вызова функции командой call управление никогда не возвращается на команду, следующую за командой call. Если в процессе выполнения вызванной функции произошла подкачка (считывание) кода с диска и расположение кода в оперативной памяти изменилось, возврат из функции будет осуществлен не туда, где была команда call в момент вызова функции, а туда, где эта команда находится в момент возврата. Если такая ситуация возникла в процессе анализа программы с использованием метода Step-Trace, происходит «уход» программы из-под отладчика. Преодолеть описанные трудности не так сложно, как кажется на первый взгляд. Любая оверлейная программа содержит диспетчер оверлеев – код, отвечающий за подкачку фрагментов программы с диска и за удаление ненужных в данный момент фрагментов программы из оперативной памяти. Диспетчер оверлеев никогда не удаляется из оперативной памяти. Если поставить внутри диспетчера оверлеев точку останова, которая срабатывает при каждом изменении расположения кода программы в памяти, все перечисленные проблемы исчезают (по крайней мере, для отладчика Turbo Debugger). Turbo Debugger, как и некоторые другие отладчики, каждый раз, когда срабатывает точка останова, проверяет наличие в памяти других точек останова. Если какая-то точка останова потеряна, отладчик ее восстанавливает. При наличии в диспетчере оверлеев вышеописанной точки останова отладчик при каждом ее срабатывании восстанавливает все остальные точки останова. При наличии в диспетчере описанной точки останова исчезает и проблема, связанная с «уходом» трассируемой программы из-под отладчика. Когда расположение кода в памяти изменяется, управление передается диспетчеру оверлеев, срабатывает точка останова и «уход» программы из-под отладчика не происходит. Особенности анализа программ в среде Windows. Программы, выполняющиеся под управлением MS-DOS, имеют всего одну точку входа. С момента запуска программы и до момента ее завершения управление никогда не передается другим программам (за исключением системных вызовов). Программа возвращает управление операционной системе только после завершения. Программа, выполняющаяся под управлением Windows, возвращает управление в Windows сразу же по окончании инициализации и создания главного окна. В дальнейшем программа получает управление только тогда, когда в одно из ее окон приходит сообщение. При этом управление передается в ту точку входа программы, которая связана с данным окном – в оконную или диалоговую функцию. Функции Windows-программы можно условно разделить на три основных класса (пересекающихся): 1. Главная точка входа (функция WinMain) и функции, вызываемые из нее. 2. Оконные функции и функции, вызываемые из них. 3. Диалоговые функции и функции, вызываемые из них. С помощью классической схемы метода Step-Trace (описанной выше) можно трассировать только функции из первого класса. Для того чтобы применить этот метод к функциям второго и третьего класса, его нужно несколько модифицировать. При использовании метода Step-Trace для анализа функций второго класса нужно вначале выбрать точку входа в программу, из которой имеется прямая передача управления в интересующую нас функцию x. Другими словами, нужно получить адрес оконной функции окна, в котором пользователь дает команду выполнить действие, ведущее к вызову функции x. Проще всего сделать это, воспользовавшись утилитой Spy, поставляемой вместе с компилятором Visual C++ или утилитой WinSight, поставляемой с Borland C++. Эти утилиты позволяют, указав мышью окно, получить практически всю информацию об этом окне, в том числе и адрес его оконной функции. Следующий рисунок иллюстрирует использование утилиты Spy.
Здесь утилита Spy была применена для получения адреса оконной функции главного окна программы DISCo Commander 96. Этот адрес указан в строке Window Proc и равен 008F65A0. После того, как адрес оконной функции получен, нужно поставить в нее точку останова. Не следует ставить точку останова в начало функции, поскольку в этом случае программа будет останавливаться на ней при приходе в окно любых сообщений, в том числе и сообщений, совершенно не интересных с точки зрения анализа программы (например, сообщения о том, что окно необходимо перерисовать). Обычно оконная функция начинает свою работу с анализа идентификатора пришедшего сообщения (второй параметр оконной функции, располагается в Windows 3.x по адресу [bp+08], в Windows 95 и NT по адресу [ebp+0C]). В подавляющем большинстве случаев аналитика интересует только реакция оконной функции на сообщение WM_COMMAND (111h), которое приходит в окно, когда пользователь выбирает пункт меню, нажимает специальную комбинацию клавиш (например, Ctrl-Ins) или выполняет какое-то действие с одним из контрольных элементов окна (например, нажимает кнопку ОК). Для того чтобы точка останова срабатывала только при приходе сообщения WM_COMMAND нужно просмотреть код оконной функции, найти там команды типа mov eax,[ebp+0C] cmp eax,111h jne ... и поставить точку останова после них. Многие отладчики позволяют ставить на оконные функции точки останова, срабатывающие только при приходе определенных сообщений, но, к сожалению, эти точки останова часто работают некорректно. Поэтому данной возможностью лучше не пользоваться. После того, как в нужную оконную функцию установлена точка останова, можно начинать трассировку программы. В качестве исходной точки для трассировки берется эта точка останова. В остальном применение метода Step-Trace в этом случае ничем не отличается от его применения в MS-DOS. Все вышеописанное относится только к обычным (не диалоговым) окнам. Попытки применить описанную методику к трассировке функций третьего класса (вызываемых из диалоговых функций) к успеху не приводят. Дело в том, что для всех диалоговых окон, имеющихся в системе, в роли оконной функции выступает одна и та же системная функция Windows DefDlgProc, которая при необходимости вызывает диалоговую функцию, ассоциированную с данным диалоговым окном. Код функции DefDlgProc имеет достаточно сложный вид, и обнаружить передачу управления из DefDlgProc в диалоговую функцию весьма затруднительно. Вышеописанная методика позволяет установить точку останова в DefDlgProc, но с точки зрения изучения программы это ничего не дает аналитику. Поэтому при трассировке функций программы, вызываемых из диалоговых окон, нужно использовать другие подходы. Один из возможных подходов заключается в следующем. Вначале устанавливается точка останова на системную функцию Windows, с помощью которой создается интересующее нас диалоговое окно. Всего в Windows имеется восемь системных функций, с помощью которых можно создать диалоговое окно, и в общем случае надо ставить точку останова на каждую из них (обычно по внешнему виду диалогового окна видно, с помощью какой функции оно создавалось). Предположим, что интересующее нас диалоговое окно создано с помощью функции DialogBox. Мы запускаем анализируемую программу под отладчиком, устанавливаем точку останова на функцию DialogBox и даем программе команду на создание диалогового окна. Программа останавливается на точке останова. Четвертым параметром функции DialogBox является указатель на диалоговую функцию создаваемого окна. Этот адрес размещается в стеке по адресу [bp+0Ch] в Windows 3.x и по адресу [ebp+14h] в Windows 95 и NT. После того, как адрес диалоговой функции окна стал известен, нам остается только поставить точку останова в диалоговую функцию и дальше действовать так же как в случае, когда функция x относится ко второму классу. Особенности анализа параллельного кода. Современные программные интерфейсы (например, Win32) допускают создание программ, имеющих несколько параллельно выполняющихся потоков (threads). При этом возможна ситуация, когда один и тот же фрагмент кода программы одновременно выполняется в нескольких параллельных потоках. При установке точек останова в такие программы возникает следующая проблема. Когда мы ставим точку останова на функцию, используемую более чем одним потоком, программа будет останавливаться на ней независимо от того, какой поток в данный момент выполняется. Если эта точка останова используется как отправная точка трассировки, рано или поздно возникает ситуация, когда два или более параллельных потоков «попадают под трассировку». Пусть, например, мы дали команду Step в одном потоке программы, и в этот момент другой поток остановился на точке останова. Мы имеем два потока, выполнение которых приостановлено отладчиком. Когда мы дадим команду Step в следующий раз, будет продолжено выполнение второго потока. Что же касается первого потока, здесь ситуация зависит от отладчика. В одних отладчиках его выполнение никогда не возобновляется, что приводит к сбоям в работе анализируемой программы, в других при запуске отлаживаемой программы возобновляется выполнение всех приостановленных отладчиком потоков. При этом следующая остановка программы может произойти в любом из потоков программы, «попавших под трассировку». С точки зрения аналитика это выглядит как хаотичное и, на первый взгляд, абсолютно бессмысленное, изменение данных в окнах отладчика. Дальнейшая работа в таком режиме становится практически невозможной. Следует отметить, что некоторые отладчики (например, WinDbg) позволяют устанавливать точку останова на конкретный поток программы. К сожалению, такие точки останова часто работают некорректно. Для того чтобы решить описанную проблему, при анализе параллельного кода нужно придерживаться следующего правила: в начале трассировки все точки останова должны быть удалены из программы. Только так можно гарантировать, что трассировке будет подвергнут единственный поток программы. Многие отладчики допускают временное удаление точки останова (команда Disable). При этом точка останова удаляется из отлаживаемой программы, но информация о ней сохраняется в памяти отладчика, и эта точка останова может быть восстановлена всего двумя-тремя нажатиями клавиш. Применение динамического метода на примере Diskreet 5.0. Постановка задачи. Программа Diskreet входит в состав популярного программного пакета Norton Utilities. Diskreet реализует шифрование двух видов: непрозрачное шифрование файлов и прозрачное шифрование логических дисков. Поддерживаются два алгоритма шифрования: так называемый быстрый алгоритм – собственная разработка Symantec Corporation и DES-алгоритм. Мы попытаемся решить следующие задачи: • восстановление формата зашифрованного файла (sec-файла) Diskreet; • восстановление быстрого алгоритма шифрования файлов; • восстановление алгоритма генерации ключа для быстрого алгоритма шифрования файлов. Запуск отладчика. Для начала нам нужно запустить программу diskreet.exe под отладчиком. Мы использовали отладчик Turbo Debugger 3.1, поставляемый вместе с компилятором Borland C++. Для запуска программы под этим отладчиком нужно набрать в командной строке td <имя_программы> На экране появляется экран отладчика, который после нажатия клавиш Enter и F5 приобретет следующий вид: Ё File Edit View Run Breakpoints Data Options Window Help READY ╔═[■]═CPU 80486═══════════════════════════════════════════════╤═══════1════[↕]═╗ ║ cs:12DC►BF977B mov di,7B97 ▲ ax 0000 │c=0║ ║ cs:12DF 8EDF mov ds,di ■ bx 0000 │z=0║ ║ cs:12E1 FA cli ▒ cx 0000 │s=0║ ║ cs:12E2 8ED7 mov ss,di ▒ dx 0000 │o=0║ ║ cs:12E4 81C44EDE add sp,DE4E ▒ si 0000 │p=0║ ║ cs:12E8 FB sti ▒ di 0000 │a=0║ ║ cs:12E9 B430 mov ah,30 ▒ bp 0000 │i=1║ ║ cs:12EB CD21 int 21 ▒ sp 1800 │d=0║ ║ cs:12ED A2C800 mov [00C8],al ▒ ds 5D3A │ ║ ║ cs:12F0 8826C700 mov [00C7],ah ▒ es 5D3A │ ║ ║ cs:12F4 3C02 cmp al,02 ▒ ss 897C │ ║ ║ cs:12F6 730D jnb 1305 ▒ cs 5D4A │ ║ ║ cs:12F8 8D164200 lea dx,[0042] ▒ ip 12DC │ ║ ║ cs:12FC B409 mov ah,09 ▒ │ ║ ║ cs:12FE CD21 int 21 ▼ │ ║ ╟◄■▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒►┼────────────┴───╢ ║ ds:0000 CD 20 FF 9F 00 9A F0 FE ═ Я ЪЁ■ │ ss:1802 0200 ║ ║ ds:0008 1D F0 E0 01 3F 2A AA 01 ↔Ёр☺?*к☺ │ ss:1800►005A ║ ║ ds:0010 3F 2A 89 02 9A 24 0C 16 ?*Й☻Ъ$♀▬ │ ss:17FE 0000 ║ ║ ds:0018 01 01 01 00 02 FF FF FF ☺☺☺ ☻ │ ss:17FC 0200 ║ ║ ds:0020 FF FF FF FF FF FF FF FF │ ss:17FA F64C ║ ╚═════════════════════════════════════════════════════════════╧═══════════════─┘ F1-Help F2-Bkpt F3-Mod F4-Here F5-Zoom F6-Next F7-Trace F8-Step F9-Run F10-Menu В верхней части экрана располагается строка меню, в нижней – строка подсказки. Остальную часть экрана занимает окно состояния процессора. В верхнем левом углу окна указывается тип процессора. Turbo Debugger 3.1 не распознает модели процессоров выше 486. Ниже располагается панель кода, содержащая дизассемблированный листинг кода программы. Треугольная стрелка слева от команды указывает, что эта команда является текущей, т.е. будет выполнена первой после запуска программы. Справа от панели кода размещается панель регистров, содержащая информацию о значениях регистров процессора. Правее от нее находится панель флагов, описывающая состояние отдельных битов флагового регистра процессора. В нижней части экрана располагаются панель данных, показывающая содержимое оперативной памяти компьютера, и панель стека, отображающая вершину стека программы. Треугольная стрелка в панели стека указывает адрес, на который указывает регистр sp. Мы не будем подробно описывать возможности отладчика Turbo Debugger. Эту информацию можно получить из прилагаемой документации, а также из интерактивной справки, вызываемой клавишей F1. Следует отметить, что содержание справки зависит от того, какое окно и какая панель окна является активной в данный момент. Расстановка маяков. Исходя из поставленных задач, оптимальным представляется выбор в качестве маяков системных вызовов, связанных с обращениями программы к файловой системе. Нас интересуют следующие вызовы: • создание файла – int 21h, ah = 3Ch, cx = атрибуты создаваемого файла, ds:dx имя создаваемого файла, при возврате ax = дескриптор созданного файла; • открытие файла – int 21h, ah = 3Dh, al = режим открытия файла, ds:dx имя открываемого файла, при возврате ax = дескриптор открытого файла; • закрытие файла – int 21h, ah = 3Eh, bx = дескриптор закрываемого файла; • чтение файла – int 21h, ah = 3Fh, bx = дескриптор файла, ds:dx буфер, cx = длина буфера; • запись в файл – int 21h, ah = 40h, bx = дескриптор файла, ds:dx буфер, cx = длина буфера; • смещение маркера файла (file seek) – int 21h, ah = 42, al = точка отсчета, cx:dx = новое смещение маркера. Знак “” здесь означает, что соответствующая пара регистров содержит адрес буфера памяти, содержащего указанные данные (является указателем на буфер). Поскольку интересующие нас маяки представляют собой отдельные функции прерывания 21h, при установке точек останова мы не можем ограничиться единственной точкой останова в обработчике прерывания 21h. Если мы поставим такую точку останова, она будет срабатывать при вызове любой функции прерывания 21h, а не только при вызове интересующих нас функций. Поэтому нам надо найти в коде программы diskreet.exe все обращения к интересующим нас системным функциям MS-DOS. Начнем с системного вызова «создание файла». Перейдем в панель кода и нажмем Ctrl-PgUp для того чтобы перейти в начало сегмента кода. Потом нажмем Ctrl-S. В появившемся окне наберем “mov ah,3C”. Нажмем Enter. Курсор переместится на адрес cs:13C5, по которому размещается эта команда. Посмотрев на следующий за ней код cs:13C5 B43C mov ah,3C cs:13C7 CD21 int 21 мы убеждаемся, что данная команда действительно используется для подготовки к выполнению системного вызова «создание файла». Поставим точку останова на эту команду. Переместим курсор на одну строку ниже и продолжим поиск команды “mov ah,3C”. Больше таких команд нет. Проводя аналогичные действия для машинных команд “mov ah,3Dh”, “mov ah,3Eh”, … , “mov ah,42h”, мы устанавливаем точки останова на следующие маяки: Команда Адрес Обозначение mov ah,3Ch cs1:13C5 create mov ah,3Dh cs1:13B1 open1 mov ah,3Dh cs1:17E4 open2 mov ah,3Eh cs1:0D79 close1 mov ah,3Eh cs1:1420 close2 mov ah,3Eh cs1:181A close3 mov ah,3Fh cs1:13E0 read1 mov ah,3Fh cs1:13F8 read2 mov ah,40h cs1:1065 write1 mov ah,40h cs1:1468 write2 mov ah,40h cs1:15CA write3 mov ah,42h cs1:14DD seek Обратите внимание на команду “mov ah,40h” по адресу cs1:39FD. За этой командой не следует вызов прерывания 21h, поэтому эта команда не является интересующим нас маяком. Запуск программы. После того, как мы установили точки останова на все интересующие нас маяки, мы запускаем анализируемую программу, нажав клавишу F9. На экране компьютера появляется окно программы Diskreet. Выберем в меню File/File Options быстрый алгоритм шифрования и отключим все остальные опции. Теперь войдем в меню File/Encrypt. Выберем для зашифрования какой-нибудь текстовый файл . Мы выбрали файл с именем sample.txt длиной 1889 байт. Выберем какое-нибудь имя для файла, в который будет помещен шифртекст, например, предлагаемое по умолчанию имя sample.sec. В этот момент отладчик останавливается на маяке create. Перейдем в панель данных, нажмем Ctrl-G и в появившемся окне наберем “ds:dx”. Теперь в панели данных отображаются данные, расположенные по адресу, на который указывает пара регистров ds:dx. Мы видим там имя файла sample.sec и полный путь к нему: ds:F4AA 44 3A 5C 55 4D 4F 7E 31 D:\UMO~1 ds:F4B2 2E 42 4F 4F 5C 50 52 4F .BOO\PRO ds:F4BA 47 52 41 7E 31 5C 44 49 GRA~1\DI ds:F4C2 53 4B 52 45 45 54 5C 53 SKREET\S ds:F4CA 41 4D 50 4C 45 2E 53 45 AMPLE.SE ds:F4D2 43 00 97 7B C5 24 4A 5D C Ч{┼$J] Таким образом, в данный момент программа diskreet.exe создает файл sample.sec. Пройдя в пошаговом режиме команду “int 21h”, мы видим, что файл создан и ему присвоен дескриптор 5 (после возврата из прерывания ax=5). Запускаем программу дальше. Программа просит ввести пароль. Введем какой-нибудь пароль, например, «123456». Программа рисует на экране окно ╔═══════════════════ Encrypt ═══════════════════╗ ║ ║ ║ Combining D:\...\PROGRA~1\DISKREET\SAMPLE.TXT ║ ║ into D:\...\PROGRA~1\DISKREET\SAMPLE.SEC ║ ║ ║ ║ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║ 0% complete ║ ║ ║ ╚═══════════════════════════════════════════════╝ и останавливается на маяке write2. Содержимое регистра bx (дескриптор файла) равно 5, следовательно, сейчас будет произведена запись в файл sample.sec. Регистр cx=10h, следовательно, будет записано 10h=16 байт. Эти байты расположены по адресу ds:dx. ds:5862 50 4E 43 49 43 52 59 50 PNCICRYP ds:586A 54 00 01 00 00 00 00 00 T ☺ Временно выйдем из отладчика и зашифруем с помощью Diskreet несколько файлов. Мы убеждаемся, что, если используется быстрый алгоритм шифрования, все sec-файлы начинаются с этой строки, которая хранится там в незашифрованном виде. Если же используется DES-алгоритм, байт по смещению 14 равен не нулю, а единице. Судя по всему – это код алгоритма, с помощью которого был зашифрован файл. Возьмем какой-нибудь sec-файл и изменим с помощью Norton Commander значение этого байта с 0 на 1 или наоборот. Мы видим, что Diskreet не может расшифровать этот файл, даже если при расшифровании введен правильный пароль. Очевидно, программа пытается применить для расшифрования не тот алгоритм. Значит, наша гипотеза о назначении этого байта правильна. Теперь снова загрузим отладчик, выполним все вышеописанные действия и запустим программу выполняться дальше. Программа снова останавливается на маяке write2. В этот раз программа записывает в файл sample.sec завершающуюся нулем строку “ABCDEFGHENRIXYZ”. Эксперименты показывают, что эта строка одинакова во всех случаях. В следующий раз программа снова останавливается на маяке write2 с целью записи в тот же файл следующих 32 байтов: ds:F3BC 53 41 4D 50 4C 45 2E 54 SAMPLE.T ds:F3C4 58 54 00 00 00 F4 24 49 XT Ї$I ds:F3CC 6D 20 61 07 00 00 40 00 m a• @ ds:F3D4 00 00 00 00 00 00 00 00 Нетрудно убедиться в том, что это – имя шифруемого файла, его дата и время создания, атрибуты и длина. Начиная со смещения 22 данные в этом буфере одинаковы во всех случаях. Далее программа останавливается на маяке open1 для открытия файла sample.txt. Ему присваивается дескриптор 6. Следующий маяк – read1. Программа считывает в буфер по адресу ds1:0000 (ds1=cs1+2DB3h) содержимое файла с дескриптором 6, т.е. sample.txt. Потом программа останавливается на маяке write3 и записывает в файл sample.sec содержимое этого буфера. Фактически содержимое sample.txt скопировано в sample.sec после заголовка длиной 64 байта, записанного в результате трех вызовов write2. Затем программа останавливается на маяке close2 и закрывает файл sample.txt. Следующий маяк – снова write2. В sample.sec записываются 32 нулевых байта. Следующая остановка – на write3. В sample.sec записывается еще 71 нулевой байт. К этому времени окно, выводимое программой, приобретает вид: ╔══════════════ Encrypt Files ══════════════╗ ║ ║ ║ Encrypting ║ ║ D:\UMO~1.BOO\PROGRA~1\DISKREET\SAMPLE.SEC ║ ║ ║ ║ 0% complete ║ ║ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║ ║ ║ Encrypting files... ║ ║ ║ ╚═══════════════════════════════════════════╝ Судя по всему, начинается шифрование. Программа останавливается на маяке seek и перемещает маркер файла sample.sec на смещение 16 байт от начала файла. С помощью маяка read1 программа пытается считать в буфер ds1:0000 4000h=16384 байт (16К) из sample.sec. Поскольку длина этого файла сейчас равна 800h=2048 байт (2К), удается считать только это количество байт. Программа перемещает маркер файла sample.sec обратно на смещение 16 байт от начала. Используя маяк write3, программа записывает в sample.sec 2048 байт из буфера ds1:0000. Просмотрев содержимое буфера, мы убеждаемся, что это – шифртекст. Наконец, с помощью вызова close2 программа закрывает sample.sec. Sec-файл готов. Дальнейшие остановки программы на маяках нас не интересуют. Итак, используя метод маяков, мы всего за несколько минут обнаружили в оперативной памяти буфер, в котором происходит шифрование данных, и в значительной мере восстановили формат sec-файла Diskreet. Окончательное восстановление формата sec-файла предлагается в качестве упражнения, а мы займемся восстановлением быстрого алгоритма шифрования. Восстановление алгоритма шифрования. Мы уже установили, что шифруемые данные размещаются в оперативной памяти по адресу ds1:0000, и шифрование происходит между вторым проходом маяка read1 и третьим проходом маяка write3. Применим метод Step-Trace для обнаружения функции шифрования. В качестве начальной точки трассировки выберем момент второго прохода программой маяка read1. В качестве интересующих данных возьмем содержимое буфера ds1:0000. Еще раз загрузим программу под отладчиком и дойдем до момента второго прохода read1. В панели данных отобразим содержание интересующего нас буфера памяти. Начинаем трассировку. Пусть функция f1 – это функция, в которой находится маяк read1. Вначале мы проходим функцию f1 в режиме Step до тех пор, пока не встретим команду call, ret или retf. По адресу cs1:13E5 мы встречаем команду call 1B7E. Проходим ее в режиме Step и обнаруживаем, что содержимое буфера ds1:0000 не изменилось. Продолжаем трассировку. По адресу cs1:16DA нам встречается команда retf. Проходим ее и попадаем в функцию f2. Далее мы встречаем по адресу cs1:E036 команду call 14CE и убеждаемся, что эта функция не изменяет содержимое интересующего нас буфера. Следующая команда вызова функции call cs2:0000 (cs2=cs1+0E12h), расположена по адресу cs1:E067. При проходе этой команды в режиме Step мы замечаем, что содержимое буфера ds1:0000 изменилось, и там теперь находится шифртекст. Значит, f3=cs2:0000. Перезагружаем программу нажатием Ctrl-F2, доходим до адреса cs1:E067 так же, как и раньше, и входим в функцию f3 командой Trace. Далее продолжаем действовать по тому же алгоритму. Результаты трассировки удобно отобразить в следующей таблице: Функция Адрес первого входа в функцию Команда перехода f1 cs1:13D3 f2 cs1:DFC5 cs1:16DA retf f3 cs2:0000 cs1:E06C call cs2:0000 f4 cs2:023A cs2:000D call 023A f5 cs2:02B8 cs2:0243 call 02B8 Трассируя функцию f5, мы убеждаемся, что это и есть функция шифрования. Все, что нам остается – это разобраться в коде функции f5 и понять, как работает алгоритм шифрования. Эта задача решается практически так же, как и задача, которая решалась в разделе «Восстановление алгоритма генерации псевдослучайных чисел Turbo C». Восстановление быстрого алгоритма шифрования файлов Diskreet, так же как и восстановление алгоритма генерации ключа для этого алгоритма, предлагается в качестве упражнения. Литература. 1. Зегжда Д.П., Ивашко А.М. Как построить защищенную информационную систему. Мир и семья. СПб. 1997. 2. Проскурин В.Г. Программные закладки в защищенных компьютерных системах. «Банковские технологии» №6. 1998. 3. Проскурин Г.В. Принципы и методы защиты информации. МИЭМ. М. 1997. 4. Щербаков А.Ю. Разрушающие программные воздействия. М.: Эдель. 1993. 5.
[править] Защита программ от изучения
| При работе в Википедии обязательно соблюдение авторских прав. Если вы продолжите загружать защищённые авторским правом изображения или вставлять тексты без разрешения автора, к вам могут быть применены административные меры, вплоть до полного запрещения доступа к сайту. Примечание: Это предупреждение нельзя изменять и перемещать. Снять предупреждение могут только тот, кто его выставил, или администратор. |
INFOMAN 00:40, 8 октября 2006 (UTC)
[править] Изображения без источников
- Изображение:Иерархий Ролей.jpg
- Изображение:Модель RBAC3.jpg
- Изображение:Иерархия Ролей в Проекте.jpg
- Изображение:Кербер1.jpg
Здравствуйте! Спасибо за загрузку этих изображений. Однако, Вы не указали всю необходимую информацию — в частности, кто их автор, поэтому правовой статус и лицензия не могут быть подтверждены. Если данная информация не будет предоставлена в полном объёме, через 7 дней изображения подлежат удалению. Подробнее о правилах загрузки изображений Вы можете прочитать на странице Википедия:Лицензирование изображений. Спасибо за понимание. --Panther @ 17:24, 8 октября 2006 (UTC)
[править] Последнее предупреждение
| При работе в Википедии обязательно соблюдение авторских прав. Если вы продолжите загружать защищённые авторским правом изображения или вставлять тексты без разрешения автора, к вам могут быть применены административные меры, вплоть до полного запрещения доступа к сайту. Примечание: Это предупреждение нельзя изменять и перемещать. Снять предупреждение могут только тот, кто его выставил, или администратор. |
