Добрынин В.Ю. Технологии компонентного программирования
Подождите немного. Документ загружается.
Основные понятия
Начнем с некоторой теории, точнее, с некоторого набора понятий, общих для различных моделей и стандартов, связанных с
самим понятием распределенной транзакции.
Прежде всего надо разграничить понятия обычной ( уровня одной базы данных) транзакции и распределенной транзакции. В
первом случае имеется множество клиентов, одновременно обращающихся с запросами к одной базе данных. Во втором
случае в
логически единый процесс вовлечены несколько баз данных, управляемых независимыми СУБД. В случае сбоя необходимо
выполнить откат не в одной, а во всех вовлеченных базах данных, даже в тех, с чьей точки зрения все операции по модификации
данных были выполнены успешно.
В распределенную транзакцию вовлечены следующий объекты:
z Прикладные компоненты
Число и функции прикладных компонентов определяются бизнес-логикой приложения.
z Менеджеры ресурсов
Для каждого ресурса, представляющего собой некоторую систему хранения данных со свойством восстановления после
программных и технических сбоев, имеется свой менеджер ресурса.
z Менеджер транзакций
Обычно всеми транзакциями в рамках одной машины управляет один менеджер транзакций. В случае, когда транзакция
распределена по нескольким машинам, она координируется при взаимодействии менеджеров транзакций со всех
вовлеченных машин.
Транзакция - это некоторая единица работы, которую выполняют вышеописанные объекты в течении относительно короткого
временного интервала (в COM+ по умолчанию транзакция длится
не более 60 секунд). Транзакция должна обладать следующими
ACID свойствами:
z Atomicity - атомарность транзакции
Атормарность означает необходимость реализации принципа ``все или ничего''. Иными словами, либо транзакция
завершается к удовольствию всех ее участников, либо выполняется полный откат назад, к положению до начала
транзакции.
z Consistency - целостность распределенных данных
В предположении целостности данных до начала транзакции, целостность данных должна иметь место и по завершении
транзакции. Здесь под данными понимаются данные, хранимые во всех вовлеченных в транзакцию ресурсах данных.
Целостность данных означает то, что данные удовлетворяют ряду определяемых приложением ограничений.
z Isolation - изоляция транзакции
В процессе выполнения транзакции модифицируется часть данных, хранимых в ресурсах данных. Доступ к таким данным
извне транзакции должен быть заблокирован по двум причинам.
Во-первых, во время выполнения транзакции обычно не известен конечный результат - будут ли результаты транзакции
сохранены или будет выполнен откат назад. В связи с этим
использование модифицируемых данных извне транзакции
запрещается.
Во-вторых, в процессе выполнения транзакции может быть временно нарушен принцип целостности данных. Объект вне
транзакции, имеющий доступ к данным, вовлеченным в транзакцию, может воспринять данную ситуацию как сбой в работе
системы и начать выполнение каких-либо корректирующих действий.
z Durability - сохранность результатов транзакции
Результаты выполнения транзакции должны сохраняться в форме, способной пережить программный или технический
сбой.
Рассмотрев участников транзакции и ее свойства, перейдем к рассмотрению ряда более специальных понятий, в терминах
которых позднее будет описан полных алгоритм выполнения транзакции:
z Демаркация транзакции
Данное понятие означает способ определения единицы работы, составляющей одну атомарную транзакцию. Работа состоит
из некоторой совокупности операций (транзакционных операций), выполняемых вовлеченными в транзакцию объектами.
Имеется два способа демаркации транзакции:
{ Программная демаркация
Этот способ обычно применяется при следовании процедурной парадигме программирования. Некоторому потоку
приписывается метка транзакции, и все операции, выполняемые в этом потоке до момента выполнения команды
успешного завершения или прерывания транзакции, принадлежат данной транзакции. Транзакцию можно временно
приостанавливать, снимая метку с потока и вновь помечивая поток.
{ Декларативная демаркация
Данный способ применяется в рамках технологий компонентного программирования. Требования каждого
прикладного компонента к среде выполнения описываются набором атрибутов, которые просматриваются системой в
момент активации компонента. Если активируемый компонент требует своего выполнения в рамках транзакции, все
выполняемые им операции будут выполняться в рамках некоторой транзакции. Какой именно транзакции -
определяется как
требованиями активируемого компонента, так и требованиями компонента, инициировавшего
активацию (активатора). Активируемый компонент может выполняться в рамках транзакции, в которой выполняется
активатор (конечно, если такая транзакция имеется), или во вновь созданной транзакции, или выполняться вне какой-
либо транзакции.
z Контекст транзакции
Транзакция порождается менеджером транзакций путем создания контекста транзакции. Контекст транзакции сохраняет
состояние транзакции, в частности, ее идентификатор. Все объекты, вовлеченные в транзакцию, имеет доступ к контексту
транзакции.
z Регистрация ресурсов
Каждый вовлекаемый в транзакцию менеджер ресурсов регистрируется у менеджера транзакций. Эта регистрация
снимается по завершении транзакции.
z Двух-фазный протокол завершения транзакции
В случае, когда все прикладные компоненты голосуют за успешное завершение транзакции, вся дальнейшая работа по ее
завершению выполняется менеджером транзакций и менеджерами ресурсов, зарегистрировавшихся для участия в данной
транзакции. Этот процесс описывается так называемым двух-фазным протоколом завершения транзакции.
На первой фазе менеджер транзакций просит всех
менеджеров ресурсов подготовиться к завершению транзакции.
Подготовка состоит в сохранении результатов транзакции в форме, которая может пережить программный или технический
сбой (запись в файл). Заметим, что при этом результаты транзакции еще не публикуются, т.е., например, не заносятся в базу
данных. При успешном завершении фазы подготовки менеджер ресурса уведомляет об
этом менеджера транзакций.
Во второй фазе менеджер транзакций принимает окончательное решение об успешном завершении транзакции или об
откате назад.
Если все зарагистрированные в транзакции менеджеры ресурсов подтвердили успешное завершение первой фазы, то
менеджер транзакций дает команду на внесение результатов транзакции во все базы данных. При этом он уже не ждет
подтверждений
от менеджеров ресурсов. Если во время выполнения второй фазы в каком-либо из ресурсов данных
произошел сбой, то после восстановления его работоспособности менеджер ресурса завершает обновление данных
самостоятельно. Если из-за сбоя он не получил команды от менеджера транзакций, он обращается к менеджеру транзакций
с просьбой повторить эту команду.
Если
кто-то из менеджеров ресурсов не смог завершить успешно (или вовремя) фазу подготовки, менеджер транзакций
выдает команду на откат назад.
Теперь опишем процесс порождения, распространения и завершения распределенной транзакции в целом. Остановимся на случае
декларативной демаркации транзакции, т.к. именно этот способ используется в COM+.
1. Порождение транзакции
Новая транзакция порождается при
активации некоторого прикладного компонента. Данный прикладной компонент либо
требует порождения новой транзакции не зависимо от наличия транзакции, в которой выполняется его активатор, либо ему
требуется какая-либо транзакция, но активатор выполняется вне транзакций.
Порождается транзакция менеджером транзакций, который формирует контекст транзакции, делая его доступным для
данного прикладного компонента.
В соответствии с
декларативным принципом демаркации транзакции, все операции, выполняемые данным прикладным
компонентом, принадлежат этой транзакции.
2. Распространение транзакции
Если прикладной компонент, выполняющийся в некоторой транзакции, инициирует активацию нового прикладного
компонента, то этот компонент помещается в текущую транзакцию если он не требует явно выполнения в новой транзакции
или выполнения вне всякой транзакции. Контекст текущей
транзакции становится доступным вновь включенному в
транзакцию компоненту.
Если прикладной компонент, выполняющийся в некоторой транзакции, обращается к некоторому ресурсу данных, для
которого имеется менеджер ресурса, то последний регистрируется у менеджера транзакций для участия в текущей
транзакции (если такая регистрация не была выполнена ранее).
Прикладные компоненты не заботятся о том, чтобы
транзакция удовлетворяла ACID свойствам. Эта ответственность
возложена на менеджера транзакций и менеджеров ресурсов, вовлеченных в текущую транзакцию.
3. Завершение транзакции
Каждый прикладной компонент по завершении своей доли работ в рамках текущей транзакции информирует систему о
своем согласии на успешное завершение транзакции либо о своем требовании выполнить откат назад.
Если хотя бы один
прикладной компонент потребовал отката назад, менеджер транзакций выдает соответствующую
команду всем зарегистрированным менеджерам ресурсов.
В противном случае, если все прикладные компоненты удовлетворены результатами транзакции, выполняется двух-фазный
протокол завершения транзакции.
Далее мы перейдем к рассмотрению того, как распределенные транзакции реализованы в COM+. Но предварительно уместно
остановиться на вопросе совместимости менеджеров транзакций и
менеджеров ресурсов от различных поставщиков. Очевидно,
что при работе на платформе COM+ разработчик будет использовать менеджер транзакций этой платформы, который будет без
проблем понимать и прикладные компоненты, созданные на этой платформе. Несомненно, этот менеджер транзакций способен
регистрировать для участия в транзакции менеджеров ресурсов, разработанных в Microsoft. Это Microsoft SQL Server, Microsoft
Message Queue Server. Но как быть с менеджерами
транзакций от других поставщиков ?
Имеется стандарт X/Open Distributed Transaction Model от консорциума Open Group. Эта модель специфицирует несколько
интерфейсов, среди которых два описывают взаимодействие между прикладными компонентами, менеджером транзакций и
менеджерами ресурсов:
z TX интерфейс
Данный интерфейс реализуется менеджером транзакций и используется прикладными компонентами при формировании
транзакции, информировании менеджера транзакций о согласии данного компонента завершить текущую транзакцию
успешно или о требовании выполнить откат и т.п.
z XA интерфейс
Этот двунаправленный интерфейс обеспечивает взаимодействие менеджера транзакций и менеджера ресурсов. Часть
функций данного интерфейса реализуется менеджером ресурсов, а часть - менеджером транзакций. В частности, менеджер
транзакций реализует функции регистрации и дерегистрации менеджера ресурсов для участия в транзакции.
Для совместимости менеджера транзакций из COM+ с менеджерами ресурсов от других поставщиков в COM+ предусмотрена
поддержка XA интерфейса. В результате в распределенную транзакцию, порожденную прикладными компонентами
выполняющимися под COM+, могут быть вовлечены менеджеры ресурсов для таких систем хранения данных как Oracle,
Informix, IBM DB2, Sybase SQL Server, Ingres, выполняющихся на различных платформах.
Теперь перейдем непосредственно к транзакционной модели, реализованной в COM+.
Модель транзакций в COM+
Прикладные компоненты
Начнем с прикладных компонентов. В COM+ прикладным компонентом является экземпляр конфигурированного класса,
который должен быть описан определенным набором атрибутов. Связанные с транзакциями атрибуты и их возможные значения
будут приведены далее.
Прежде всего участие или неучастие объекта в транзакции определяется его транзакционным атрибутом. Значение этого атрибута
может быть задано как разработчиком класса (в
IDL файле, содержащем описание данного класса), так и администратором
(посредством использования Component Services).
Для задания этого атрибута посредством IDL файла достаточно включить одно из возможных его значение в список атрибутов,
предваряющий описание соответствующего класса. Указанный атрибут после компиляции IDL файла будет храниться в
библиотеке типов.
При использовании Component Services необходимое значение атрибута задается на вкладке Transactions.
Транзакционный атрибут
может принимать одно из пяти значений (ниже эти значения приведены в той форме, которая
используется в Components Services):
z Disabled
Выбор этого значения отключает автоматическое управление транзакциями для всех экземпляров данного класса.
Разработчик должен самостоятельно реализовать взаимодействие объекта с менеджером транзакций для обеспечения,
например, некоторого нестандартного поведения объекта.
z Not Supported
Объект, которому приписано это значение, не только сам отказывается участвовать в каких-либо транзакциях, но и не
распространяет транзакцию на объкты, активацию которых он инициирует. Иными словами, пусть объект A выполняется в
транзакции T1, объект B активируется объектом A и имеет
Not supported в качестве значения транзакционного атрибута.
Пусть, наконец, объект C активируется объектом B. Тогда, не зависимо от значения транзакционного параметра,
приписанного объекту C, данный объект не будет выполняться в транзакции T1.
z Supported
Объект с таким значением транзакционного атрибута согласен на все. Если его активировал объект, выполняющийся в
некоторой транзакции, то он будет выполняться в той же транзакции. Если активатор вне транзакций, то и активированный
объект вне транзакций.
z Required
При выборе этого значения мы получаем объект, который всегда выполняется в контексте некоторой транзакции. Если его
активатор уже принадлежит некоторой транзакции, то и он принадлежит той же транзакции. В противном случае при
активации объекта порождается новая транзакция, в контексте которой и будет выполняться данный объект. Заметим, что в
последнем случае
этот объект называется корнем транзакции, в контексте которой он выполняется.
z Requires New
В этом случае при активации объекта всегда порождается новая транзакция, корнем которой является данный объект.
Имеется еще один атрибут, который необходимо приписать классу, собирающемуся участвовать в транзакциях. Это атрибут
активация по необходимости (Just-In-Time Activation), имеющий два значения (on/off). В транзакционной модели COM+ все
классы, которые могут выполняться в контексте какой-либо транзакции, должны быть
активируемыми по необходимости (тут
надо заметить, что и объекты, не собирающиеся участвовать в транзакциях, могут активироваться по необходимости).
Что такое активация по необходимости? Вспомним, как устроен жизненный цикл объекта. При создании объекта формируется
счетчик числа ссылок на этот объект. Только когда значение этого счетчика станет равно нулю, объект будет уничтожен. Легко
представить себе ситуацию, когда клиент инициировал формирование некоторого объекта на стороне сервера и изредка в течении
нескольких часов вызывает отдельные его методы. Столь длительное присутствие этого объекта в оперативной памяти сервера
приводит к излишней трате ресурсов, особенно в случае, когда данный объект удерживает дефицитное соединение с некоторой
базой данных. Было
бы оправдано удалять такой объект из оперативной памяти и вызывать его к жизни автоматически по мере
необходимости, т.е. тогда, когда от клиента приходит новый вызов. Данный процесс и называется активацией объекта по
необходимости.
При первичной активации объекта (например, клиент использует фабрику класса для построения экземпляра класса) формируется
сам объект, а
также прокси на стороне клиента, стаб на стороне сервера и соединяющий их канал. Пока клиент имеет хотя бы
одну ссылку на данный объект, система прокси/канал/стаб продолжает существовать. Циклом же активации/деактивации объекта
на стороне сервера управляет COM+. Объет деактивируется, если он не нужен, и активируется по необходимости. Точнее говоря,
любой объект, выполняющийся в контексте некоторой транзакции, деактивируется не позднее завершения этой транзакции.
Более подробно это обсуждается далее. Вторичную активацию объекта инициирует его стаб, получивший вызов от клиента.
Механизм активации по необходимости очевидно помогает решить проблему создания масштабируемого приложения. Но
необходимость его использования именно в случае транзакционных объектов связана вовсе не с заботой о масштабируемости.
Основная причина - повышение надежности программирования транзакционных приложений. Дело в
том, что по завершении
транзакции в рамках модели COM+ прикладные компоненты ничего не знают об окончательном ее результате - была ли
транзакция успешной, либо завершилась откатом. В этих условиях опасно оставлять у прикладных компонентов, участвовавших
в транзакции, какую-либо память о завершившейся транзакции. Эта память может противоречить реальному положению дел.
Например, некоторый
объект помнит, что счет некоторого клиента был увеличен на 100 долларов, но реально транзакция была
прервана и был выполнен откат назад. В резултате имеется опастность нарушения целостности данных, если упомянутый объект
будет действовать далее с учетом имеющейся у него информации. Принудительная деактивация всех прикладных компонентов,
участвовавших в транзакции, очищает их память, сохраняя
тем самым целостность данных.
Говоря про активацию по необходимости, следует упомянуть про пул объектов. Это еще один сервис, предоставляемый COM+
как средство решения проблемы масштабируемости приложения. При активации объект может либо формироваться заново, либо
извлекаться из пула ранее построенных объектов данного типа. При деактивизации вместо уничтожения некоторого объекта его
можно вернуть
в пул для последующего использования. Выбор за разработчиком.
Помещение объекта в пул и извлечение его из пула выполняется автоматически при условии, что соответствующий класс
удовлетворяет ряду требований.
Прежде всего, при конфигурировании класса на вкладке Activation необходимо отметить, что экземпляры данного класса
допускают помещение их в пул объектов. Здесь же задаются минимальный и
максимальный размер пула. При активации
приложения, содержащего данный класс, формируются экземпляры класса в числе, равном минимальному размеру пула. В
дальнейшем, при активации объекта данного типа, некоторый объект извлекается из соответствующего пула или формируется
новый экземпляр класса если пул пуст. Заметим, что общее число объектов данного типа не должно превышать максимальный
размер соответствующего пула.
Далее приведены требования к классу, экземпляры которого можно помещать в пул:
z Класс должен реализовать стандартный интерфейс IObjectControl
Данный интерфейс имеет три метода, которые автоматически вызываются COM+.
{ Activate
Этот метод вызывается автоматически при активации объекта. Здесь следует выполнить инициализацию данных
объекта, получить указатель на объект контекста.
{ Deactivate
Этот метод вызывается автоматически при деактивизации объекта. Здесь следует освободить все ресурсы,
захваченные объектом.
{ CanBePooled
Этот метод вызывается автоматически на последнем этапе деактивации. Тут объект может отказаться по каким-либо
причинам от помещения в пул. В этом случае он просто будет уничтожен.
z Допустимые потоковые модели: Free, Both, Neutral
Иными словами, объект, допускающий помещение в пул, должен жить в MTA или NA апартаменте. Это связано с тем, что
один поток сформирует данный объект и поместит его в пул, и совсем другому потоку понадобится извлечь его из пула и
вызвать какой-либо из его методов.
z Класс должен допускать агрегацию, но сам не должен агрегировать другие помещаемые в пул объекты.
z Класс не должен использовать FTM для оптимизации маршализации указателя на интерфейс.
Распространение транзакции
Менеджер транзакций в COM+ имеет имя координатор распределенных транзакций - DTC (Distributed Transaction Coordinator).
При активации объекта, который должен быть корнем некоторой новой транзакции, DTC порождает новую транзакцию, которая
получает уникальный идентификатор (GUID). Этот идентификатор хранится к объекте контекста данного объекта. Кроме того,
объект контекста хранит два бита, модифицируя которые объект информирует DTC о своем отношении к текущей транзакции.
Эти биты иногда называют бит голосования и бит деактивации по возврату:
z Бит голосования
Принимает значение 1, если объект в данный момент удовлетворен ходом дел и собирается голосовать за успешное
завершение транзакции если ничего не изменится. По умолчанию именно это значение выбирается при активации объекта.
Принимает значение 0, если объект в данный момент не удовлетворен результатами и собирается голосовать за откат назад.
z Бит деактивации по возврату
Если данный бит установлен в 1, то сразу же после возврата из выполняемого метода данный объект будет деактивирован, а
значение его бита голосования будет учтено DTC при принятии решения об успешном завершении транзакции или об
откате назад.
Если данный бит установлен в 0, объект еще не готов к деактивации и
по возврату из текущего метода будет ожидать новых
вызовов. Именно это значение устанавливается по умолчанию при активации объекта.
Для модификации указанных битов имеется несколько возможностей. Рассмотрим одну из них. Интерфейс
IObjectContext
объекта контекста имеет четыре метода, которые можно использовать для задания значений этих битов (см. таблицу 3.2)
Table: Задание битов голосования и деактивации
Метод Бит голосования Бит деактивации
Заметим, что интерфейс
IContextState объекта контекста имеет методы, позволяющие узнать текущее значение указанных
битов и задать их новые значения не парами, а по одному. Наконец, используя Components Services, можно пометить некоторый
метод как Auto-Done. В этом случае при возврате из этого метода произойдет деактивация объекта и он будет голосовать за
успешное завершение текущей транзакции или за откат
в зависимости от того, завершился ли вызов данного метода нормально
или с ошибкой. При использовании указанных выше интерфейсов этот режим перекрывается явным заданием битов голосования
и деактивизации.
Распространение транзакции происходит как обычно путем активации новых объектов и путем обращения к системам хранения
данных. В последнем случае соответствующий менеджер ресурса регистрируется у
DTC для участия в текущей транзакции.
Завершение транзакции
Завершается транзакция в следующих случаях
z Корневой объект транзакции деактивирован после возрата из метода, где был установлен бит деактивации
В этом случае DTC анализирует биты голосования всех ранее вовлеченных в транзакцию (в том числе и деактивированных)
объектов. Если все голосуют за успешное завершение транзакции, то начинается выполнения двух-фазного протокола.
Заметим, что прикладные компоненты, вовлеченные в транзакцию, деактивируются
до окончательного завершения
транзакции. Корневой объект может информировать клиента об успехе или неудаче выполненных им действий, но если
произойдет сбой на уровне отдельного менеджера ресурсов и во время двух-фазного протокола произойдет откат,
информировать клиента об этом будет некому.
Если хотя бы для одного объекта бит голосования равен 0, выполняется откат
назад без выполнения двух-фазного
протокола.
z Корневой объект был уничтожен в связи с тем, что клиент освободил все указывающие на объект ссылки
В этом случае DTC завершает транзакцию и выполняется откат назад без выполнения двух-фазного протокола.
z Закончился временной интервал, выделенный на текущую транзакцию
По умолчанию длительность транзакции не превышает 60 секунд. По их истечении DTC завершает транзакцию и
выполняется откат назад без выполнения двух-фазного протокола.
Безопасность
Безопасность в COM+ не привязана к модели безопасности, используемой платформой Windows. Причина в том, что разные
версии операционной системы Windows используют различные модели безопасности, и это никак не должно сказываться на
работе распределенного приложения, различные компоненты которого могут выполняться под управлением различных
операционных систем, поддерживающих COM+.
Различные протоколы безопасности могут быть реализованы в виде динамически
компонуемых библиотек, так называемых
провайдеров сервиса безопасности (SSP - Security Service Provider). Каждый SSP должен реализовать стандартный API -
интерфейс провайдера поддержки безопасности (SSPI - Security Support Provider Interface), который изолирует распределенное
приложение от конкретного протокола безопасности и позволяет повышать уровень безопасности используя более совершенные
протоколы.
В следующем разделе рассматривается протокол Kerberos, который является протоколом по умолчанию для Windows 2000 и
наилучшим на сегодня образом удовлетворяет потребности
в обеспечении безопасности распределенных COM+ приложений.
Заметим, что в COM+ может использоваться также протокол NT LAN Manager, который использовался ранее в COM
приложениях, исполняемых под Windows NT. Однако, данный протокол не обеспечивает всех возможностей, предоставляемых
протоколом Kerberos, в том числе тех, которые особенно важны для распределенных приложений с трех-уровневой архитектурой
(взаимная аутентификация клиента и сервера, делегирование).
Kerberos
Kerberos является протоколом, обеспечивающим безопасность функционирования распределенного приложения. Разработан этот
протокол в начале 80х годов в Массачусетском технологическом институте и в настоящее время принят как стандарт,
поддерживаемый различными независимыми производителями программного обеспечения. С этим стандартом можно
познакомиться по RFC 1510. Windows 2000 реализует этот стандарт, и далее рассматривается именно эта реализация - Windows
2000 Kerberos. Основой для данного раздела
является статья David Chappel ``Exploring Kerberos, the Protocol for Distributed
Security in Windows 2000'', Microsoft System Journal, August 1999.
Основные сервисы
Любая реализация Kerberos обеспечивает следующие сервисы:
z Аутентификация
При входе в систему пользователя или при вызове некоторого сервера клиентом в защищенных системах выполняется
SetComplete 1 1
SetAbort 0 1
EnableCommit 1 0
DisableCommit 0 0
процесс аутентификации, что означает, что клиент должен представить доказательства того, что он именно тот, за кого себя
выдает.
Аутентификация требует передачи от клиента на сервер некоторых данных, доказывающих его (клиента) идентичность
некоторому зарегистрированному в системе клиенту. Передаваемые данные должны быть зашифрованы. Kerberos
использует шифрование с секретным ключом, что означает, что и отправитель
, и получатель зашифрованной информации
должны иметь идентичные ключи.
Реализация Kerberos в Windows 2000 поддерживает два алгоритма шифрования:
{ DES - Data Encription Standard
Это первый официально предложенный правительством США стандарт в области шифрования, предназначенный для
коммерческого использования. Длина ключа равна 64 битам, из которых 8 используются для контроля ошибок, и,
следовательно, эффективная длина ключа равна 56 битам.
{ RC4
Более быстрый алгоритм шифрования потока данных с ключом переменной длины. Именно этот алгоритм
используется по умолчанию в Windows 2000 Kerberos. Длина ключа в версиях, используемых на территории США,
равна 128 бит, а за пределами США - 56 бит.
z Проверка целостности данных
Здесь имеется ввиду, что получатель данных должен быть уверен, что в процессе передачи данные не были изменены.
Реализация данного требования основана на вычислении контрольной суммы для каждого передаваемого пакета данных,
которая в зашифрованном виде передается вместе с ним. Контрольная сумма есть значение некоторой функции от
передаваемых данных, имеющей
различные значения на различных данных. В Kerberos для вычисления контрольной
суммы используется HMAC - Hash-based Message Authentication Code. Передача зашифрованной контрольной суммы
гарантирует, что искажение (случайное или умышленное) передаваемых данных будет обнаружено на принимающей
стороне.
z Шифрование трафика
Использование зашифрованных контрольных сумм гарантирует целостность передаваемых данных, но не защищает их от
неавторизированного просмотра. Данную проблему решает шифрование всего трафика. Заметим, что попутно при этом
решается и проблема проверки целостности данных и аутентификация. Только клиент или сервер, имеющий секретный
ключ, может подготовить и/или прочитать передаваемые данные.
Упомянутые
выше сервисы требуют определенных накладных расходов. Наиболее накладно шифрование трафика. Проверка
целостности данных дороже аутентификации. При изучении собственно модели безопасности в COM+ мы увидим, что клиент и
сервер совместно выбирают тот уровень безопасности, который удовлетворит их требования.
Основные сценарии использования сервисов Kerberos
В данном разделе рассматриваются основные сценарии, реализуемые в COM+, и способы, посредством которых Kerberos
обеспечивает необходимый уровень безопасности. Но прежде всего надо остановиться на основной идее этого протокола.
Если каждая пара клиент-сервер имеют известные только им секретные ключи, то проблемы с обеспечением всех упомянутых
выше сервисов нет. Проблема в масштабируемости такого подхода
, в его надежности и удобстве.
Идея Kerberos состоит в том, что при обращении клиента к серверу первый должен предъявить второму специальный билет,
доказывающий его идентичность и содержащий необходимую серверу информацию о правах данного клиента, о секретном
ключе, используемом для шифровки пересылаемых данных, и т.п.
Рассмотрим основные поля данных билета:
z Нешифруемые поля
{ Домен
Домен, где был выдан этот билет. Предполагается, что на контроллере домена запущен сервер Kerberos - KDS (Key
Distribution Server), который и выдает все билеты в данном домене.
{ Имя принципала
Принципалом здесь называется любая сущность, обладающая в данном домене именем и паролем. Это и все
зарегистрированные в данном домене пользователи, и приложения, и машины. Все принципалы регистрируются на
контролере домена в Active Directory, где в зашифрованном виде для каждого принципала хранится, в частности, его
имя и хешированный пароль.
z Шифруемые поля
{ Флаги билета
{ Ключ сессии
Билет выдается клиенту для предъявления некоторому серверу. Именно этим ключом будут шифроваться данные,
передаваемые между данными клиентом и сервером в текущей сессии (или пока не истекло время действия билета)
{ Домен
{ Имя принципала
Клиент не имеет доступа к зашифрованным полям билета. Сопоставляя Домен и Имя приципала в шифруемых и
нешифруемых полях билета, сервер может заметить ситуацию, когда предъявляемый билет был выдан другому
клиенту.
{ Время выдачи билета
{ Время прекращения действия билета
{ Адреса хоста
Список IP адресов, с которых клиент может вызывать сервер
{ Авторизационные данные
Эти данные использ
у
ются се
р
ве
р
ом для оп
р
еделения п
р
ав данного клиента п
р
и вызове методов данного се
р
ве
р
а.
Для дальнейшего изложения удобно использовать следующие обозначения:
z - секретный ключ принципала , полученный хешированием его пароля. В случае клиента , в случае сервера
, в случае KDS
z - ключ сессии между и .
z - данные , зашифрованные ключом
Вход пользователя в систему
Процесс входа пользователя в систему состоит из нескольких стадий
1. Ввод имени, домена и пароля
2. Запрос TGT (ticket-granting ticket) у KDS
Специальный билет TGT можно рассматривать как паспорт данного пользователя в данном домене (но принимаемый
только KDS). При всех последующих обращениях к KDS в рамках данного сеанса клиентское приложение предъявляет KDS
этот билет, доказывая идентичность пользователя. Запрос на получение
TGT формируется автоматически и включает в себя
{ Имя пользователя
{ Временную метку - момент выдачи запроса, шифрованный ключем
3. Получение и ключа сессии между пользователем и KDS
Получив запрос, KDC использует известные ему из Active Directory секретный ключ пользователя для расшифровки
временной метки. Если расхождение между этой временной меткой и текущим временем по часам KDS не превышает 5
минут, делается вывод о том, что клиент аутентифицирован, т.к.
только он мог воспользоваться секретным ключом для
кодирования свежей временной метки.
Использование в протоколе Kerberos временной метки для аутентификации пользователя опционно и используется именно
в реализации данного протокола в Windows 2000. При отсутствии временной метки аутентификация пользователя реально
выполняется при попытке клиента расшифровать полученные от KDS данные, зашифрованные его секретным ключом, и
получить ключ сессии
между данным пользователем и KDS -
Билет TGT имеет структуру обычного билета. Заметим, что TGT зашифрован секретным ключом самого KDS. Никто кроме
KDS, включая самого пользователя, не может прочитать шифрованные поля. В поле Ключ сессии этого билета содержится
, что позволяет KDS не хранить ключи сессий со всеми своими клиентами. В поле Авторизационные данные
содержатся взятые из Active Directory
права данного пользователя и идентификаторы безопасности (SID) этого
пользователя и всех групп, в которые он входит.
4. Запрос билета для локальных сервисов
Для обращения к локальным сервисам на машине пользователя последнему также необходим билет для локальных
сервисов, который автоматически и запрашивается у KDS с предъявлением TGT.
5. Получение билета для локальных сервисов
С этого момента
пользователь может обращаться к локальным сервисам, на чем вход в систему и завершается.
Аутентификация клиента удаленным серверным приложением
Данный процесс выполняется автоматически при вызове клиентским приложением удаленного сервера. Точнее, здесь
описывается процесс, выполняемый при первом обращении клиента к серверу в данном сеансе. В зависимости от выбранных
клиентом и сервером уровнях аутентификации (этот вопрос будет рассмотрен позже), аутентификация клиента сервером может
выполняться с различной периодичностью, от однократной при первом вызове
сервера до аутентификации при получении
каждого нового пакета. При повторной аутентификации выполняется только часть из рассматриваемых ниже операций.
Процесс аутентификации клиента C сервером S при первичном вызове состоит из следующих шагов:
z Клиент C посылает KDS запрос на получение билета для сервера S
Этот запрос включает
{ - билет TGT клиента C, зашифрованный ключом KDS
{ имя сервера S
{ - аутентификатор, зашифрованный ключем сессии для C и S
Аунтетификатор содержит текущее время и имя пользователя. Так как он зашифрован ключом сессии , никто
кроме самого клиента C не может его сформировать. Временная метка усложняет попытку перехватить и послать этот
запрос повторно от другого клиента (кроме того, KDS будет еще анализировать и IP адрес, с которого пришел запрос)
z KDS аутентифицирует клиента
Используя свой собственный секретный ключ KDS расшифровывает TGT клиента и извлекает из него ключ сессии
. Используя ключ сессии, KDS расшифровывает аутентификатор. Аутентификация клиента считается успешной если
{ Удалось расшифровать аутентификатор
{ Имя клиента из TGT совпадает с именем, указанным в аутентификаторе
{ Временная метка из аутентификатора отличается от текущего времени по часам KDS не более чем на 5 минут
{ Запрос пришел с одного из указанных в TGT IP адрессов
$
$\{...
\
$\{TGT\}
K
$\{K_{C
K
$
K
$
$\{TGT\}
K
$\{Auth\}K_
{
$
$
z При успешной аутентификации KDS высылает клиенту - билет для сервера S и - ключ сессии между
клиентом и сервером S
Заметим, что билет T зашифрован секретным ключем сервера S и, следовательно, клиент не сможет узнать и
модифицировать его поля. В этот билет KDS включает некоторые данные из TGT (имя клиента, авторизационные данные).
Кроме того, задаются флаги, срок действия билета, генерируется
(случайный) и помещается в билет ключ сессии .
z Клиент предъявляет серверу S билет и новый аутентификатор
z Сервер S аутентифицирует клиента, используя тот же алгоритм, что и KDS.
Используя билет T, сервер S авторизирует клиента, разрешая ему выполнять определенные функции в зависимости от
авторизационных данных клиента. Альтернативно, по просьбе клиента, сервер может выполнить его имперсонализацию, что
означает, что сервер будет использовать права доступа к ресурсам данного клиента. Подробно эти вопросы будут рассмотрены
далее.
Еще один достойный рассмотрения вопрос связан с понятием взаимной аутентификации, что означает аутентификацию не только
клиента, но и сервера. Очевидна критичность этого вопроса в том случае, когда клиент собирается переслать на сервер секретную
информацию (например, номер кредитной карты).
Возможность взаимной аутентификации появилась именно в Kerberos (в NT LAN Manager она отсутствовала). Механизм очень
прост - сервер S после аутентификации клиента C высылает последнему временную метку из аутентификатора этого самого
клиента, зашифрованную ключем сессии . Это доказывает клиенту, что данный сервер действительно является сервером S,
т.к. для расшифровки аутентификатора ему был необходим ключ , который он мог извлечь только из билета T,
зашифрованного секретным ключом сервера S.
Реализация сервисов проверки целостности данных и шифрования трафика
Смысл и алгоритм реализации данных сервисов уже описан выше. Осталось заметить, что в качестве секретного ключа,
известного только передающй и принимающей сторонам, можно использовать соответствующий ключ сессии.
Делегирование
Подробно понятие делегирования (как и понятие имперсонализация) будут рассматриваться далее. Здесь будет объяснена только
его суть и описан механизм реализации делегирования в Windows 2000 Kerberos.
При имперсонализации клиента (с его согласия) сервер получает доступ к локальным ресурсам от имени данного клиента
(уровень передаваемых прав доступа определяется клиентом). Однако имперсонализация не позволяет серверу делать
удаленные
вызовы других серверов от имени клиента. Конечно, выполняя некоторый вызов клиента C сервер S может послать удаленный
вызов на другой сервер Q, но с точки зрения сервера Q вызов получен именно от сервера S, а не клиента C. Следовательно, даже
если клиент C имеет особые права доступа к серверу Q, сервер S не сможет ими воспользоваться, выполнив простую
имперсонализацию
клиента C.
В чем причина ограниченности возможностей имперсонализации? Имперсонализация реализуется средствами конкретной
операционной системы. При имперсонализации в Windows потоку в серверном процессе, выполняющему вызов пользователя,
приписывается маркер доступа (access token), в котором записаны права данного пользователя, а не серверного процесса (как
обычно бывает по умолчанию). Это позволяет получить от имени пользователя доступ к локальным
ресурсам, т.к. при этом
просто сопоставляются права доступа из маркера доступа со списком принципалов, которым разрешен или запрещен доступ к
конкретному локальному ресурсу.
При удаленном доступе необходимо обеспечить такие сервисы как аутентификация, контроль целостности данных, шифрование
трафика. Очевидно, что маркер доступа не содержит необходимых для этого данных. Фактически, говоря в
терминах протокола
Kerberos, Cервер S должен обратиться к KDS с запросом на получение билета для сервера Q, причем сервер Q при получении
этого билета должен быть уверен, что получил он его от клиента C, а не от сервера S.
Данная возможность реализована в Kerberos и называется делегированием. Отметим, что делегирование отсутствует в NT LAN
Manager.
Делегирование прав от клиента C серверу S осуществляется следующим образом:
z Клиент C посылает серверу S (которым он уже аутентифицирован) свой билет для KDS - и ключ сессии с KDS -
Сервер S должен иметь эти данные для того, чтобы получить от KDC билет для какого-либо другого сервера (например, Q),
выданный как бы клиенту C. В отличие от сервера Q, KDS обмануть очень сложно (да и сервер Q можно обмануть только с
помощью
самого KDS). Поэтому от KDS и не скрывается то, что запрашивает билет сервер S, но выписать его необходимо
на имя клиента C. Среди флагов билета TGT должен быть флаг
FORWARDABLE, указывающий на то, что клиент C еще при
первом обращении к KDS уведомил его о том, что в будущем он будет делегировать свои полномочия другим серверам
(кстати, не любому серверу, а только тому, который зарегистрирован в домене как заслуживающий доверия (trusted)
сервер).
z Сервер S посылает (от лица клиента C) запрос KDS на получение билета для сервера Q, в который включается, как обычно,
имя сервера Q, билет и аутентификатор
Зметим, что в аунтетификатор включается имя клиента и он кодируется ключем сессии клиента C и KDS.
z KDS аутентифицирует клиента
$\{
T
$\{K_{CS}\
}
$
$\{
T
$\{Auth\}K
_
$
$
$\{TGT\}
K
$\{K_{CK}\
}
$\{TGT\}
K
$\{Auth\}K_
{
Конечно, KDS замечает, что билет запрашивает не клиент C (вызов пришел не с того IP адреса, который указан в TGT).
Однако он закрывает на это глаза в связи с тем, что в TGT имеется флаг
FORWARDABLE, и отправитель запроса знает ключ
, который он мог получить только от клиента .
z KDS посылает серверу S запрошенный билет , зашифрованный ключом сервера Q, и ключ сессии сервера S и
сервера Q -
z Далее общение сервера S и сервера Q проходит как обычное общение клиента и сервера
Заметим, что с точки зрения сервера Q он работает с клиентом C. Это позволяет серверу S делегировать полученные от
клиента полномочия серверу Q и т.д. Для этого у него есть все необходимое : TGT, закодированный ключом KDS, и ключ
сессии .
Удаленный вызов за пределы домена
Проблема удаленного вызова за пределы домена состоит в том, что клиент должен получить билет для сервера из другого домена
у KDS этого другого домена. Но наш клиент не зарегистрирован в этом новом домене и, следовательно, не может получить там
TGT.
Решение проблемы - доверие двух KDS из разных доменов друг другу. Выражается это доверие
в том, что эти KDS из первого и
второго доменов генерируют общий только им известный секретный ключ . Краткое описание механизма аутентификации
при вызове за пределы домена:
z Клиент С из первого домена, желающий получить доступ к серверу R из второго домена обращается прежде всего к KDS
своего домена. Первый KDS возвращает клиенту новую версию его TGT, зашифрованную паролем и ключ сессии для
общения с KDS второго домена (это ключ хранится и в новой версии TGT).
z Клиент отправляет KDS второго домена новый TGT, зашифрованный ключом и аутентификатор, зашифрованный
ключем сессии клиента и второго KDS.
z Второй KDS расшифровывает TGT и, доверяя первому KDS, возвращает клиенту билет для запрашиваемого сервера из
своего домена.
Модель безопасности в COM+
Как уже говорилось ранее, определенная независимость модели безопасности, используемой в COM+, достигается за счет
использования интерфейса SSPI, через который COM+ может пользоваться услугами различных провайдеров сервиса
безопасности SSP. Для определенности остановимся на SSP, представленном реализацией в Windows 2000 протокола Kerberos.
Будем полагать, что все клиенты и серверы в данном домене используют этот SSP.
Как и другие сервисы COM+, сервис безопасности может
быть использован без написания какого-либо кода, за счет
администрирования. Однако возможен (и в некоторых случаях очень полезен) программный доступ к этому сервису.
Сервис безопасности весьма сложен. Для его изложения здесь выбран следующий подход. Мы рассмотрим обычный сценарий
вызова клиентом некоторой функции удаленного сервера, который в процессе выполнения этого вызова
будет имперсонировать
клиента и использовать делегированные ему права для вызова некоторого другого сервера от лица клиента. Весь этот сложный
процесс контролируется сервисом безопасности, основная функциональность которого на данном примере и будет рассмотрена.
Активация серверного приложения клиентским приложением
Для активации удаленного серверного приложения клиентское приложение может, например, вызвать функцию
CoGetClassObject для получения указателя на фабрику класса (включенного в данное приложение) и последующего получения
необходимо числа экземпляров данного класса. При вызове упомянутой функции клиентское приложение задает следующие
входные параметры:
z CLSID нужного класса
z Тип сервера (сервер в процессе клиента, локальный или удаленный)
z Указатель на структуру COSERVERINFO, содержащей некоторые данные об удаленной машине, о клиенте, о требуемом
уровне безопасности
z IID запрашиваемого интерфейса (обычно IID_IClassFactory)
Единственный выходной параметр при успешном выполнении вызова возвращает указатель на запрашиваемый интерфейс.
Самый интересный для нас параметр - указатель на структуру
COSERVERINFO. Предположим для начала, что этот указатель равен
NULL.
В этом случае вся связанная с данным вызовом информация на стороне клиента определяется по умолчанию:
z Имя машины
В реестре машины клиента под ключем
CLSID должен иметься раздел для нужного класса (CLSID класса), а в нем подключ
RemoteServerName, определяющий имя удаленной машины, на которой установлено приложение, содержащее этот класс.
z Уровень аутентификации
Как клиентское, так и серверное приложение должны определить требуемый ими уровень аутентификации. При их
несовпадении выбирается максимальный из двух уровней. Уровень аутентификации по умолчанию для всех приложений,
установленных на данной машине, определяется ее администратором. Приложение может само определить требуемый ему
$
$\{T
\
$\{K_{SQ}
\
$
уровень аутентификации и даже изменить его в процессе выполнения. Ниже приводятся возможные значения этого уровня:
1. None
Аутентификация не выполняется. В этом случае клиент анонимен для сервера и никакого контроля за передаваемыми
данными не проводится.
2. Connect
Именно этот уровень обычно выбирается администратором как уровень по умолчанию. Аутентификация клиента
выполняется при первом соединении клиента
с сервером. Защиты передаваемых данных нет.
3. Call
Аутентификация клиента выполняется при каждом вызове метода сервера. Выполняется защита от перехвата и
прочтения передаваемых данных стандартными средствами. Для этого выполняется шифрование последовательных
номеров передаваемых пакетов.
4. Packet
Аутентификация выполняется при пересылке каждого пакета. Шифруются номера передаваемых пакетов.
5. Packet_Integrity
Кроме того, что выполняется на предыдущем уровне
, вычисляется, шифруется и передается контрольная сумма
пакета. В результате контролируется целостность передаваемых данных.
6. Packet_Privacy
В дополнение к функциональности предыдущего уровня выполняется шифрование всех передаваемых данных.
Выбор того или иного уровня аутентификации определяется соотношением степени секретности данных и расходами на
поддержку того или иного уровня безопасности. COM+ предоставляет возможность задавать разные уровни безопасности
динамически, что позволяет гибко учитывать требования приложения к безопасности.
z Уровень имперсонализации
Этот уровень определяется только клиентским приложением (и серверным, когда оно выступает клиентом по отношению к
другому серверному приложению). Уровень имперсонализации определяет объем прав доступа, которые клиентское
приложение желает передать серверному.
Рассмотрим прежде всего сам механизм имперсонализации. После входа пользователя в систему все запускаемые (прямо и
косвенно) им процессы имеют
маркер доступа (access token), содержащий, в частности, такую информацию как SID
(Security IDentifier) пользователя и SID всех груп, в которых зарегистрирован данный пользователь, а также различные его
привелегии. Каждому локальному ресурсу приписан список ACL (Access Control List), содержащий элементы ACE (Access
Control Entry), в каждом из которых разрешается или запрещается определенный набор способов доступа к данному ресурсу
для некоторого SID. При попытке обращения некоторого
потока к некоторому локальному ресурсу происходит
последовательный просмотр ACL этого ресурса и все SID из маркера доступа процесса, содержащего данный поток,
сопоставляются с SID из очередного ACE. Процесс просмотра ACL прекращается, как только выясняется, что данный поток
обладает достаточными правами для доступа к ресурсу, либо, напротив, что доступ запрещается.
Каждое запущенное серверное приложение в COM+ является принципалом
, обладающим собственным SID. Предположим,
что некоторый поток в этом приложении исполняет вызов, пришедший от некоторого клиента. По умолчанию права
доступа данного потока определяются маркером доступа процесса, в котором исполняется приложение. Таким образом, по
умолчанию используются права доступа, данные администратором принципалу, от имени которого запущено приложение.
Однако, как правило, принципал, от имени
которого запущено приложение, не совпадает с клиентом, запустившим
приложение. Таким образом, прав приложения может быть недостаточно для доступа к необходимым локальным ресурсам.
Однако эти права могут иметься у клиента. Вызвав функцию
ImpersonateClient (подробнее это будет рассмотрено далее),
поток серверного приложения будет далее использовать новый маркер доступа, содержащий данные вызвавшего его
клиента, и, следовательно, сможет выступать от его имени.
Объем передаваемых прав определяет сам клиент. В нашем случае (все параметры заданы по умолчанию) уровень
имперсонализации для всех вызовов с данной машины на на
удаленные машины определяет администратор. Вот
возможные значения для этого уровня:
1. Anonimous
Данный уровень, при котором клиент анонимен для сервера, не используется
2. Identity
Идентификационная информация о клиенте известна серверу, но ее недостаточно для доступа к локальным ресурсам
от лица клиента. Именно этот уровень обычно выбирается администратором как уровень имперсонализации по
умолчанию.
3. Impersonate
Данный
уровень имперсонализации достаточен для того, чтобы сервер мог получать доступ ко всем локальным
ресурсам от лица клиента. Это наивысший уровень имперсонализации для SSP NT LAN Manager.
4. Delegate
При этом уровне сервер может делать удаленные вызовы от лица клиента. Этот уровень появился в SSP Kerberos.
Что делать, если уровни аутентификации и имперсонализации, установленные по умолчанию администратором данной
конкретной
машины, не устраивают клиентское приложение? Имеются два выхода:
z Клиентское приложение задает собственный уровень безопасности по умолчанию в рамках своего процесса
z Клиентское приложение может динамически менять свои требования к уровню безопасности в процессе выполнения.
Для задания собственного уровня безопасности по умолчанию в рамках своего процесса клиентское приложение может вызвать
функцию
CoInitializeSecurity. Серверное COM+ приложение не должно вызывать эту функцию, т.к.она вызывается автоматически и
вторичный ее вызов завершится ошибкой.
Если клиентское приложение не вызвало
CoInitializeSecurity явно, эта функция будет вызвана автоматически при первом
маршалинге интерфейса, который был инициирован данным приложением. При этом при задании уровня безопасности будут
использованы параметры, заданные в локальной системе по умолчанию. При явном вызове этой функции клиентское приложение
задает, в частности, следующие параметры: