Исследование подхода использования распределенных модулей для обеспечения защиты информации

Аннотация

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

Введение

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

В связи с тем, что к распределенным ресурсам осуществляют доступ многие пользователи, становится актуальной задача защиты и ограничения доступа к распределенному ресурсу. Некоторым пользователям должен быть полностью запрещен доступ к ресурсу, другим позволяться выполнять только ограниченный набор операций. Также все пользователи должны быть синхронизированы по данным. То есть если один из пользователей изменил состояние ресурса, например запись в базе данных, то все остальные пользователи должны работать только с новым состоянием.

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

Сейчас существует несколько наиболее популярных технологий для построения распределенных систем, таких как CORBA, DCOM, .NET Remoting. Для разработки предлагаемой системы будет использоваться технология .NET Remoting, как наиболее современная, простая в использовании и подходящая для решения поставленной задачи.

1. Задачи и преимущества распределенных систем

Распределенная система – это набор независимых компьютеров, представляющийся их пользователям единой объединенной системой [1]. Согласно этому определению все машины автономны, а с другой стороны пользователи думают, что работают с единой системой.

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

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

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

Прозрачность местоположения скрывает где именно физически расположен ресурс. Доступ к ресурсу осуществляется только по его имени, которое не отражает физического положения (например URL). Ресурс может перемещаться, при этом его имя не меняется и соответственно доступ к нему остается.

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

Прозрачность отказов означает, что пользователь не уведомляется, о том что ресурс неработоспособен и доступ был получен от его копии или в системе были обнаружены повреждения, которые уже устранены.

Прозрачность сохранности маскирует сохранение ресурса в оперативной памяти на диск или его восстановление с диска в оперативную память. Распределенные системы обладают такими важными преимуществами как отказоустойчивость и масштабируемость.

Отказоустойчивость означает, что система должна сохранять работоспособность при сбоях в ней. Основным способом построения отказоустойчивой системы является избыточность. Распределение копий функциональных модулей по разным узлам повышает вероятность того, что сбой не повлияет на избыточные объекты, которые исполняются на других узлах. Функции отказавшего узла может взять на себя один из избыточных объектов, что позволит системе в целом продолжить работу.

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

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

2. Архитектуры распределенных систем

Наиболее ранней и фундаментальной распределенной архитектурой является клиент-сервер. Клиентский процесс, работающий от имени пользователя, запрашивает службу у сервера путем посылки запроса и ожидания ответа. Сервер реализует некоторую службу, например службу файловой системы или базы данных и отвечает на запросы клиента. Взаимодействие клиента и сервера известно также под названием режим работы запрос-ответ [1]. У одного сервера, как правило, бывает много клиентов. Клиент-серверные приложения также называют двухуровневыми, так как клиент взаимодействует с сервером непосредственно [2]. Обычно двухуровневые архитектуры легко реализуются, но имеют проблемы масштабируемости. Поэтому рекомендуется выделять три уровня: уровень представления (пользовательский интерфейс), уровень обработки (бизнес-уровень), уровень данных, рисунок 1.

Уровень представления реализуется на клиентах. На нем содержатся программы для взаимодействия пользователя с приложением.

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

Уровень данных содержит программы, которые предоставляют данные клиентам или выполняют действия (например вычисления) запрошенные клиентами. Уровень данных обычно находится на стороне сервера.

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

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

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

3. Модели взаимодействия в распределенных системах

Связь между процессами – это суть распределенных систем [1]. Взаимодействие в распределенных системах всегда базируется на низкоуровневом механизме передачи сообщений, предоставляемом базовой сетью. Чтобы упростить разработку больших приложений используются различные модели взаимодействия. Наиболее распространенными являются: удаленный вызов процедур (Remote Procedure Call, RPC), удаленное обращение к методам (Remote Method Invocation, RMI), ориентированный на сообщения промежуточный уровень (Message-Oriented Middleware, MOM).

Удаленный вызов процедур позволяет программам вызывать процедуры находящиеся на других машинах. Когда процесс, запущенный на машине А, вызывает процедуру с машины В, вызывающий процесс на машине А приостанавливается, а выполнение вызванной процедуры происходит на машине В [1]. Информация может быть передана от вызывающего процесса вызываемой процедуре через параметры и возвращена процессу в виде результата выполнения процедуры.

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

Для сокрытия механизма удаленного вызова процедуры требуется, чтобы обе стороны следовали одному протоколу взаимодействия. Также необходимо, чтобы клиент и сервер пришли к договоренности по вопросу представления простых типов данных, таких как целые числа, символы, логические значения и так далее. После определения протокола необходимо организовать клиентские и серверные заглушки. Заглушки работающие по одному протоколу, для разных процедур различаются лишь интерфейсом с приложениями. Интерфейс состоит из набора процедур, которые могут быть вызваны клиентом, но реализуются на сервере. Для упрощения работы, интерфейсы часто описываются с использованием языка определения интерфейсов (Interface Definition Language, IDL). Интерфейс, определенный на IDL, компилируется затем в заглушки клиента и сервера.

Объектно-ориентированная технология показала свое значение при разработке нераспределенных приложений. Одним из наиболее важных свойств объекта является то, что он скрывает свое внутреннее строение от внешнего мира посредством строго определенного интерфейса. Такой подход позволяет легко изменять или заменять объект, оставляя интерфейс неизменным. Объект инкапсулирует данные (состояние) и операции над этими данными (методы). Доступ к методам можно получить через интерфейс. Единственным способом изменять состояние объекта, является использование его методов. Объект может реализовывать множество интерфейсов. Разделение на интерфейсы и объекты позволяет помещать интерфейс на одну машину, а сам объект на другую.

Когда клиент осуществляет привязку к распределенному объекту, в адресное пространство клиента загружается реализация интерфейса объекта, называемая заместителем. Заместитель клиента аналогичен клиентской заглушке в RPC. Единственное что он делает это выполняет маршалинг параметров в сообщения при обращении к методам и демаршалинг данных из ответных сообщений. Сами объекты находятся на сервере и предоставляют необходимые клиентам интерфейсы. Входной запрос на обращение к методу попадает сначала на серверную заглушку (скелетон). Скелетон преобразовывает его в правильное обращение к методу через интерфейс объекта находящегося на сервере. Серверная заглушка также отвечает за маршалинг параметров в ответных сообщениях и их пересылку заместителю клиента.

Характерной особенностью большинства распределенных объектов является то что, их состояние локализовано на одной машине. Объекты делятся на сохранные и нерезидентные. Сохранный объект продолжает существовать даже не находясь постоянно в адресном пространстве серверного процесса, то есть не зависит от текущего состояния сервера. Нерезидентный объект существует только пока сервер управляет им. Когда сервер завершает работу, объект прекращает свое существование. Обычно распределенная система объектов предоставляет ссылки на объекты уникальные в пределах системы. Такие ссылки можно передавать между процессами, запущенными на различных машинах. Когда процесс обращается к объекту по ссылке, он сначала должен выполнить привязку к объекту, результатом которой будет заместитель в адресном пространстве процесса.

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

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

4. Использование процессов в распределенных системах

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

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

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

Таким же образом существует несколько подходов к использованию потоков выполнения. Сервер может содержать единственный управляющий поток выполнения. С другой стороны отдельный поток выполнения может создаваться для каждого объекта. В случае прихода запроса с обращением к объекту сервер просто передает запрос потоку выполнения, который отвечает за этот объект. Можно также выделять отдельный поток для каждого запроса. Независимо от способа назначения потока, необходимо решить создавать каждый поток по запросу или поддерживать пул потоков.

5. Защита распределенной системы

Очень важным свойством распределенной системы является ее защищенность. Защита должна пронизывать всю систему целиком. Единственная брешь в системе защиты может сделать бесполезными все предпринимаемые меры обеспечения безопасности. Защита в компьютерных системах жестко связана с понятием надежности. Надежной компьютерной системой считается система, службам которой мы оправдано доверяем [1]. Рассматривая защиту системы, можно считать, что мы пытаемся защитить службы и данные от угроз защиты. Можно выделить четыре типа угроз защите [1]: перехват, прерывание, модификация, подделка.

Перехват – это ситуация, когда неавторизованный агент получает доступ к службам или данным, например, когда связь между двумя агентами подслушивает кто-то третий.

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

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

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

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

Шифрование преобразовывает данные, чтобы злоумышленник не мог их понять. Кроме того, оно позволяет проверить целостность данных.

Аутентификация использует для проверки заявленного имени пользователя, клиента, сервера и пр. До начала работы службы с клиентом служба должна определить подлинность клиента. Обычно пользователи аутентифицируют себя при помощи пароля.

Авторизация выполняется для проверки, имеет ли клиент право на выполнение запрашиваемых действий, например, доступ к базе данных.

Средства аудита используются для контроля за тем, что делает клиент и как он это делает. Хотя средства аудита не защищают от угроз защите, журналы аудита постоянно используются для анализа дыр в системах защиты с последующим принятием мер против нарушителей.

Организуя защиту распределенных приложений, можно использовать три основных подхода. Первый подход – это защита непосредственно ассоциированных с приложением данных. Основная ее задача сохранить целостность данных в независимости от того, какие с ними могут производиться операции. Второй подход – это защита путем точного указания того, кто и как может использовать операции доступа к данным или ресурсам. Например, в системе, построенной на основе объектов, для каждого из методов, доступ к которым открывается клиентам, можно указать, какой именно клиент имеет право к нему обратиться. Третий подход – сосредоточить внимание непосредственно на пользователе, приняв меры, чтобы доступ к приложению имели только определенные люди, независимо от операций, которые они собираются производить. Например, в университетах доступ к некоторым данным может быть разрешен только преподавателям и персонала, а студентам закрыт. При этом подходе управление сведено к определению ролей пользователей. После подтверждения соответствующей роли ей предоставляется или запрещается доступ к соответствующим ресурсам. В процессе разработки системы защиты определяются роли, которые могут понадобиться пользователям, и предоставляются механизмы управления доступом на основе списка ролей.

6. Основы платформы .NET

.NET – это новая модель для создания приложений (пока только под Windows). С точки зрения программиста .NET вполне можно рассматривать просто как новую среду выполнения и новую библиотеку базовых классов [3]. Среда выполнения обеспечивается с помощью Common Language Runtime (CLR, стандартная среда выполнения для языков). При компиляции кода для .NET компилятор генерирует код на общем промежуточном языке (common intermediate language, CIL), а не традиционный код, состоящий из процессорных команд. При исполнении CLR транслирует CIL в команды процессора. Поскольку трансляция выполняется в период выполнения, генерируются команды конкретного процессора. Это значит, что приложение .NET можно развертывать на любой машине, где работает CLR и FCL (Framework Class Library – базовая библиотека классов). .NET позволяет интегрироваться разным языкам, т.е. одному языку использовать типы созданные на других языках. Например, CLR позволяет создать класс на С++, производный от класса, реализованного на Visual Basic. CLR делает это возможным, так как она определяет и предоставляет общую систему типов (Common Type System, CTS), которую должны использовать все языки ориентированные на CLR.. Общеязыковая спецификация (Common Language Specification, CLS) определяет правила, которым должны следовать разработчики компиляторов, чтобы их языки интегрировались с другими.

Специально для платформы .NET был разработан новый язык программирования C#, синтаксис которого очень похож на синтаксис Java. Основными особенностями C# являются: отсутствие указателей, автоматическое управление памятью, встроенные синтаксический конструкции для работы с перечислениями, структурами и свойствами классов, возможность перегрузки операторов, поддержка использования программных интерфейсов, возможность присваивания типам атрибутов.

Когда с помощью компилятора для платформы .NET создается модуль DLL или EXE, в нем содержится сборка на языке IL. Помимо инструкций IL, модули .NET содержат также метаданные, которые подробно описывают все типы (классы), использованные в модуле, также полностью описываются все методы, свойства и события этого типа. Метаданные описывают не только типы, используемые в сборке, но и саму сборку. Эта часть метаданных называется манифестом. В манифесте содержится информация о текущей версии сборки, об использованных ограничениях по безопасности, о поддерживаемом естественном языке, а также список всех внешних сборок, которые потребуются для нормального выполнения. Таким образом, сборка является самоописываемой. Благодаря манифесту устраняется проблема с версиями и значительно упрощается развертывания приложения в системе.

.NET Remoting – это объектно-ориентированная архитектура для поддержки распределенных приложений в Microsoft .NET [2]. Эта архитектура значительно упрощает, или, лучше того, организует, методы создания и расширения распределенных приложений [2] по сравнению с DCOM. .NET Remoting поддерживает множество стандартных сценариев, требуя лишь незначительных объемов работы или настройки. Это позволяет легко получить работоспособное распределенное приложение. Приложение может строиться из подключаемых модулей, поддерживающих определенный интерфейс подключения, например, можно подключить нужный тип канала (например, HTTP или TCP) и тип форматировщика (бинарный или SOAP). Таким образом можно выбирать из стандартных, но мощных конфигураций, просто подключая другой модуль. В настоящее время поддерживается несколько вариантов настройки распределенных приложений. Первый вариант – с помощью конфигурационных файлов. Настройка удаленного взаимодействия легко выполняется посредством файлов в формате XML. Эти файлы позволяют также выполнять установку приложения на компьютер путем простого копирования дерева каталогов и кроме того, они значительно облегчают сопровождение приложения. Второй вариант настройки это программный. Если изменение настройки распределенного приложения нежелательно, то можно полностью управлять им непосредственно из кода программы.

Модель защиты для систем .NET Remoting существенно изменилась по сравнению со сложной и требующей больших объемов настройки модели DCOM. На данный момент предлагается помещать удаленный сервер внутрь IIS (Internet Information Services – информационные сервисы Интернет), что позволяет использовать его средства защиты, не внося изменения в код клиента или сервера. IIS предоставляет поддержку различных механизмов аутентификации, в том числе Windows-интегрированную (NTML), базовую, Passport и на основе сертификатов. Предоставляется также защита секретных данных, передаваемых между удаленными компьютерами, на основе SSL (Secure Sockets Layer). В настоящее время в .NET Remoting нет готового механизма защиты для распределенных приложений, не использующих IIS, однако архитектура подключаемых модулей позволяет написать собственный модуль защиты.

7. Архитектура .NET Remoting

В .NET при исполнении приложения CLR выполняет контроль типов в коде и проверяет, не обращается ли код к недопустимым адресам, поэтому несколько приложений могут исполняться внутри одного процесса с сохранением тех же преимуществ изоляции приложений, что и в модели одно приложение – один процесс. CLR определяет для приложений логическое подразделение: домен приложения. Код и объекты исполняющиеся в одном домене приложения, не имеют непосредственного доступа к коду и объектам, исполняющимся в другом домене приложения. Это обеспечивает защиту, так как сбой в одном домене не влияет на другие домены в том же процессе. Разделение между доменами приложения формирует границу .NET Remoting.

.NET Remoting позволяет объктам, исполняющимся внутри разных доменов приложений, взаимодействовать друг с другом через границы .NET Remoting. С точки зрения инфраструктуры .NET Remoting объекты делятся на две категории: дистанцируемые и недистанцируемые. Экземпляры недистанцируемых типов не могут пересекать границы .NET Remoting ни при каких условиях. Разные категории дистанцируемых типов либо могут проникать через границы .NET Remoting, либо доступны через эти границы. .NET Remoting определяет такие категории дистанцируемых типов как передаваемые по значению и передаваемые по ссылке.

Экземпляры типов, передаваемых по значению, пересекают границы .NET Remoting с помощью процесса, известного под названием сериализация, при которой текущее состояние объекта представляется в виде последовательности бит. После того как объект сериализован, он пересылается через границы .NET Remoting в другой домен приложения. в .NET Remoting тип считается если он объявлен с атрибутом Serializable.

При передаче по ссылке все вызовы объекта, созданного в некотором домене приложения, обращаются именно к экземляру в данном домене, а не к его копии в другом домене. Чтобы сделать объект передаваемым по ссылке, достаточно его наследовать от System.MarshalByRefObject. Прежде чем работать с экземпляром дистанцируемого типа, его следует создать и инициализировать путем активизации. В .NET Remoting типы, передаваемые по ссылке, поддерживают два вида активизации: серверную и клиентскую. Типы, передаваемые по значению, не требуют особого механизма активизации, так как они копируются в процессе сериализации и активизируются в процессе десериализации. Режим активизации определяется не самим типом, а настройкой инфрастуктуры.

Типы активизируемые сервером называются общеизвестными, так как серверный процесс, в котором находятся дистанцируемые типы, публикует их по определенным общеизвестным конечным точкам или адресам и активизирует экземпляры типа только при необходимости. .NET Remoting поддерживает два режима серверной активизации Singleton и SingleCall.

В режиме Singleton в отдельный момент времени может быть активен только один экземпляр типа, который активизируется при первом обращении к нему клиента в отсутствии другого экземпляра. Экземпляр такого типа способен сохранять состояние в промежутке между вызовами. В режиме SingleCall обеспечивается модель программирования без сохранения состояния. Для типа, сконфигурированного как SingleCall, инфраструктура будет активизировать новый экземпляр при каждом вызове клиентом метода этого типа. После того как вызов метода обработан, экземпляр типа становиться доступным сборщику мусора.

Когда необходимо, чтобы клиент работал с отдельным экземпляром удаленного объекта, используется клиентская активизация. Экземпляры таких типов могут оставаться активными в промежутках между вызовами методов и сохранять состояние.

Для управления временем жизни удаленных объектов .NET Remoting использует вариант распределенной сборки мусора на основе лицензий. Лицензия – это объект, инкапсулирующий значения TimeSpan, которое содержит время жизни объекта. В каждом домене приложений имеется диспетчер лицензий, управляющий лицензиями экземпляров дистанцируемых объектов этого домена. При активизации удаленного объекта его лицензия передается диспетчеру лицензий, который периодически просматривает список лицензий, сравнивая время окончания действия лицензий с текущим временем. Каждая лицензия, срок действия которой истек, уведомляется об этом диспетчером лицензий, после чего она пытается себя продлить, опрашивая своих спонсоров. Если у лицензии нет спонсоров или никто ее не продлил, то она отменяет себя. Если лицензия объекта истекла, то она удаляется вместе с объектом, которому принадлежит. Спонсорами являются клиенты, которые подписываются на необходимый им удаленный объект. Для того чтобы передать объект по ссылке .NET Remoting выполняет создает экземпляр типа System.Runtime.Remoting.ObjRef и передает его по значению в целевой домен, где на основе этого типа создается объект-прокси (заместитель), посредством которого клиент может обращаться к удаленному объекту. ObjRef содержит метаданные передаваемого по ссылке объекта. При активизации экземпляра объекта, передаваемого по ссылке .NET Remoting назначает ему URI (Uniform Resource Identifier – унифицированный идентификатор ресурса), используемый клиентом при всех последующих обращения по ссылке на данный объект. Для непосредственной пересылки объектов через границы .NET Remoting используются каналы.

Клиент, для взаимодействия с удаленным объектом, использует два вида прокси: прозрачный (TransparentProxy) и реальный (RealProxy). Клиент имеет непосредственный доступ к прозрачному прокси, который создается по информации из ObjRef с интерфейсом идентичным интерфейсу удаленного объекта. При вызове клиентом метода прозрачного прокси последний преобразует вызов в объект-сообщение и передает его реальному прокси, который отправляет его инфраструктуре .NET Remoting для доставки удаленному объекту.

.NET Remoting пересылает сериализованные объекты-сообщения через границы посредством каналов, которые предоставляют транспортный механизм, обладающий большими возможностями по расширению и потенциальной возможностью поддержки самых разнообразных протоколов и сетевых форматов данных. Есть два стандартных типа канала: TCP и HTTP. Перед тем как сообщение будет передано в канал проходит через цепочку канальных приемников. Первым приемником является форматирующий приемник, отвечающий за сериализацию объекта-сообщения в поток байт определенного сетевого формата данных. Затем форматирующий приемник передает поток для дальнейшей обработки следующему приемнику в цепочке. Последний приемник в цепочке отвечает за пересылку потока байт по сети с использование определенного транспортного протокола. .NET Remoting предоставляет два типа форматирующих приемников: бинарный (BinaryFormatter) и SOAP-формата (SoapFormatter).

Выводы

В данной работе были рассмотрены задачи, для решения которых используются распределенные системы, рассмотрены основные архитектуры распределенных приложений, способы взаимодействия различных частей системы, использование процессов и потоков, а также основные принципы построения защиты компьютерных систем. Было определено, что при реализации защиты распределенную систему лучше строить на базе трехуровневой архитектуры, в которой реализация правил защиты выносится на уровень обработки. Также было выявлено, что наиболее эффективно использовать многопоточные сервера для увеличения производительности, на таком сервере может реализовываться уровень обработки. Так как в настоящее время используются объектно-ориентированные принципы программирования, то были рассмотрены основные аспекты платформы .NET, которая содержит средства для построения распределенных приложений .NET Remoting.

Далее планируется провести исследование способов построения систем защиты.

Литература

1. Таненбаум Э., М. ван Стеен Распределенные системы. Принципы и парадигмы. – СПб: Питер, 2003. – 877 с.
2. Маклин С., Нафтел Дж., Уильямс К. Micrsoft .NET Remoting. – М: Издательско-торговый дом Русская редакция, 2003. – 384 с.
3. Троелсен Э. C# и платформа .NET. Библиотека программиста. – СПб: Питер, 2004. – 796 с.
4. Рихтер Дж. Программирование на платформе Microsoft .NET Framework. – М: Издательско-торговый дом Русская редакция, 2003. – 512 с.
5. Цимбал А.А., Аншина М. Технологии создания распределенных систем. Для профессионалов. – СПб: Питер, 2002. – 576 с.
6. Брассар Ж. Современная криптология. – М: Издательско-полиграфическая фирма ПОЛИМЕД, 1999. – 176с.