Безопасность в распределенных системах

контроля доступа;

3) индивидуальные пользователи должны быть идентифицированы;

4) система должна поддерживать совокупность сведений накапливающихся со

временем и используемых для упрощен проверки средств защиты;

5) система должна быть открыта для независимой оценки безопасности

информации;

6) система должна быть постоянно защищена от измененений конфигурации

или каких-либо других изменений.

Со времени выпуска Оранжевой книги было опубликовано множество других

документов с различными цветами обложек. Эта «радужная серия» охватывает

вопросы Интерпретации Достоверных Сетей (Trusted Network Interpretation),

Интерпретации Достоверных Баз Данных (Trusted DataBase Interpretation),

руководства по паролям, руководство по избирательному контролю доступа и

Перечень Оцененных Средств.

Некоторые реализации

Корпорация Oracle разработала реляционную СУБД с обеспечением

многоуровневой защиты информации (Multi-Level Security — MLS) — Trusted

ORACLE7, обладающую, в том числе, и всеми стандартными возможностями

ORACLE7.

В прошлом компании, которые желали защитить секретную или

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

специальное или выделенное оборудование. С появлением таких продуктов, как

Trusted ORACLE7, эта необходимость отпала. Trusted ORACLE7 позволяет

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

хранится общая информация, без всякого риска, что какой-то пользователь

случайно или преднамеренно получит доступ к секретной или конфиденциальной

информации.

Trusted ORACLE7 функционирует с использованием двух наборов правил:

Избирательное Управление Доступом (DAC — Discretionary Access Control) и

Полномочное Управление Доступом (MAC — Mandatory Access Control).

Использование DAC ограничивается такими объектами баз данных, как таблицы,

виды, последовательности и хранимые процедуры, основанные на идентификации

пользователей, и групповые ассоциации. Создатель объектов баз данных —

например, таблиц — может предоставлять доступ другому пользователю.

MAC представляет собой шаг вперед по сравнению с DAC и помечает

содержание объектов баз данных. MAC ограничивает доступ к объекту путем

сравнения так называемой метки объекта с уровнем авторизации пользователя.

Помимо меток MAC Trusted ORACLE7 помечает такие элементы объектов, как

строки и таблицы. В результате этого свойства даже при условии, что DAC

пытается дать пользователю доступ к помеченному объекту, ему будет разрешен

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

авторизации информации, к которой пытается получить доступ пользователь.

Обратите внимание, что Trusted ORACLE7 должна функционировать над ОС

с многоуровневой защитой информации, чтобы обеспечить уровни защиты

информации, заложенные в ней при проектировании. Обмен между системами с

многоуровневой защитой (меточной), а также между системой с многоуровневой

защитой и обычной системой, не использующей метки, возможен только

посредством меточного сетевого протокола. Такие протоколы передают в

дополнение к другим атрибутам защиты информации, подобно идентификаторам

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

передающего процесса. Большинство общих меточных протоколов являются

вариантами протокола MaxSix, представляющего собой совокупность сетевых

протоколов защиты информации и программных интерфейсов, теоретически

спроектированного для поддержки сетей OSI и TCP/IP, хотя в настоящее время

имеются только реализации MaxSix. Протоколы MaxSix соответствуют RIPCO,

CIPCO и DNSIX. Большинство поставщиков рабочих станций MLS с Режимом

Разделения на Секции (CMW — Compartamented Mode Workstation) реализовали

протоколы MaxSix в своих защищенных ОС. MaxSix обеспечивает не только

службы расставления меток и трансляции, но и допускает единственную заранее

определенную метку MLS.

Таким образом, помеченный сервер в действительности действует как

сторож; аналогично, БД Trusted ORACLE7 на этом сервере работает как сторож

сервера СУБД.

Как и обычные протоколы, SQL* Net поддерживает эти меточные протоколы

посредством протокольных адаптеров; например, имеются реализации адаптеров

протоколов SQL* Net для TNET фирмы Sun, MaxSix фирмы DEC и MaxSix фирмы HP.

На станциях, где многоуровневая среда соединяется с неметочной средой, на

одной стороне соединения (многоуровневой) работает адаптер SQL* Net для

варианта MaxSix, а на другой — адаптер SQL* Net для протокола TCP/IP

(неметочная среда).

Все продукты корпорации Oracle Developer 2000, Designer 2000 и др.

могут использоваться с Trusted ORACLE7.

Перспективы развития

С появлением Oracle RDBMS версии 7.2 разработчики приложений смогут

поставлять код PL/SQL в свернутом (Wrapped) формате. Разработчик, который

планирует распространять приложения на PL/SQL, больше не должен отправлять

исходный код PL/SQL. Скрытие исходного кода облегчает защиту

интеллектуальной собственности и уменьшает возможные злоупотребления или

искажения приложений.

Защищенные СУБД других поставщиков

Informix поставляет OnLine/Secure 5.0, который, подобно другим

конкурирующим продуктам в данной области, представляет собой реляционную

СУБД, обеспечивающую многоуровневую защиту информации в БД и работающую с

использованием двух наборов правил DAC и MAC.

Аналогичные механизмы поддерживает Sybase в продукте Secure SQL

Server Version 10.0.

Система Kerberos

Система Kerberos (по-русски — Цербер), разработанная участниками

проекта Athena, обеспечивает защиту сети от несанкционированного доступа,

базируясь исключительно на программных решениях, и предполагает

многократную шифрование передаваемой по сети управляющей информации.

Kerberos обеспечивает идентификацию пользователей сети и серверов, не

основываясь на сетевых адресах и особенностях операционных систем рабочих

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

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

прочитаны и при желании изменены.

Клиент/ Kerberos/ Cepвep

Kerberos имеет структуру типа клиент/сервер и состоит из клиентских

частей, установленных на все машины сети (рабочие станции пользователей и

серверы), и Kerberos-сервера (или серверов), располагающегося на каком-либо

(не обязательно выделенном) компьютере. Kerberos-сервер, в свою очередь,

делится на две равноправные части:

сервер идентификации (authentication server) и сервер выдачи

разрешений (ticket granting server). Следует отметить, что существует в

третий сервер Kerberos, который, однако, не участвует в идентификации

пользователей, а предназначен для административных целей. Область действия

Kerberos (realm) распространяется на тот участок сети, все пользователи

которого зарегистрированы под своими именами и паролями в базе Kerberos-

сервера и где все серверы обладают общим кодовым ключом с идентификационной

частью Kerberos. Эта область не обязательно должна быть участком локальной

сети, поскольку Kerberos не накладывает ограничения на тип используемых

коммуникаций (о способе доступа из области действия одного Kerberos-сервера

в область действия другого будет сказано чуть ниже).

Упрощенно модель работы Kerberos можно описать следующим образом.

Пользователь (Kerberos-клиент), желая получить доступ к ресурсу сети,

направляет запрос идентификационному серверу Kerberos. Последний

идентифицирует пользователя с помощью его имени и пароля и выдает

разрешение на доступ к серверу выдачи разрешений, который, в свою очередь,

дает «добро» на использование необходимых ресурсов сети. Однако данная

модель не отвечает на вопрос о надежности защиты информации, поскольку, с

одной стороны, пользователь не может посылать идентификационному серверу

свой пароль по сети, а с другой — разрешение на доступ к обслуживанию в

сети не может быть послано пользователю в виде обычного сообщения. В обоих

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

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

неприятностей Kerberos, применяет сложную систему многократного шифрования

при передаче любой управляющей информации в сети.

Доступ пользователей к сетевым серверам, файлам, приложениям,

принтерам и т.д. осуществляется по следующей схеме.

Клиент (под которым в дальнейшем будет пониматься клиентская часть

Kerberos, установленная на рабочей станции пользователя) направляет запрос

идентификационному серверу на выдачу «разрешения на получение разрешения»

(ticket-granting ticket), которое даст возможность обратиться к серверу

выдачи разрешений. Идентификационный сервер адресуется к базе данных,

хранящей информацию о всех пользователях, и на основании содержащегося в

запросе имени пользователя определяет его пароль. Затем клиенту отсылается

«разрешение на получение разрешения» и специальный код сеанса (session

key), которые шифруются с помощью пароля пользователя как ключа. При

получении этой информации пользователь на его рабочей станции должен ввести

свой пароль, и если он совпадает с хранящимися в базе Kerberos-сервера,

«разрешение на получение разрешения» и код сеанса будут успешно

расшифрованы. Таким образом решается проблема с защитой пароля — в данном

случае он не передается по сети.

После того как клиент зарегистрировался с помощью идентификационного

сервера Kerberos, он отправляет запрос серверу выдачи разрешений на

получение доступа к требуемым ресурсам сети. Этот запрос (или «разрешения

на получение разрешения») содержит имя пользователя, его сетевой адрес,

отметку времени, срок жизни этого разрешения и код сеанса. «Разрешение на

получение разрешения» зашифровывается два раза: сначала с помощью

специального кода, который известен только идентификационному серверу и

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

пользователя. Это предотвращает не только возможность использования этого

разрешения при его перехвате, но и делает его недоступным самому

пользователю. Для того чтобы сервер выдачи разрешений дал клиенту доступ к

требуемым ресурсам, недостаточно только «разрешения на получение

разрешения». Вместе с ним клиент посылает так называемый аутентикатор

(authenticator), зашифровываемый с помощью кода сеанса и содержащий имя

пользователя, его сетевой адрес и еще одну отметку времени.

Сервер выдачи разрешений расшифровывает полученное от клиента

«разрешение на получение разрешения», проверяет, не истек ли срок его

«годности», а затем сравнивает имя пользователя и его сетевой адрес,

находящиеся в разрешении, с данными, которые указаны в заголовке пакета

пришедшего сообщения. Однако на этом проверки не заканчиваются. Сервер

выдачи разрешений расшифровывает аутентикатор с помощью кода сеанса и еще

раз сравнивает имя пользователя и его сетевой адрес с предыдущими двумя

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

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

используется для идентификации клиента всего один раз и только в течение

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

одновременный перехват «разрешения на получение разрешения» и аутентикатора

для последующих попыток несанкционированного доступа к ресурсам сети.

Каждый раз, при необходимости доступа к серверу сети, клиент посылает

«разрешение на получение разрешения» многоразового использования и новый

аутентикатор.

После успешной идентификации клиента в качестве источника запроса

сервер выдачи разрешений отсылает пользователю разрешение на доступ к

ресурсам сети (которое может использоваться многократно в течение

некоторого периода времени) и новый код сеанса. Это разрешение зашифровано

с помощью кода, известного только серверу выдачи разрешений и серверу, к

которому требует доступа клиент, и содержит внутри себя копию нового кода

сеанса. Все сообщение (разрешение и новый код сеанса) зашифровано с помощью

старого кода сеанса, поэтому расшифровать его может только клиент. После

расшифровки клиент посылает целевому серверу, ресурсы которого нужны

пользователю, разрешение на доступ и аутентикатор, зашифрованные с помощью

нового кода сеанса.

Для обеспечения еще более высокого уровня защиты, клиент, в свою

очередь, может потребовать идентификации целевого сервера, чтобы

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

ресурсам сети. В этом случае он требует от сервера высылки значения отметки

времени, увеличенного на единицу и зашифрованного с помощью кода сеанса.

Сервер извлекает копию кода сеанса, хранящуюся внутри разрешения на доступ

к серверу, использует его для расшифровки аутентикатора, прибавляет к

отметке времени единицу, зашифровывает полученную информацию с помощью кода

сеанса и отсылает ее клиенту.

Расшифровка этого сообщения позволяет клиенту идентифицировать

сервер. Использование в качестве кода отметки времени обеспечивает

уверенность в том, что пришедший клиенту ответ от сервера не является

повтором ответа на какой-либо предыдущий запрос.

Теперь клиент и сервер готовы к передаче необходимой информации с

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

используя полученное разрешение. Последующие сообщения зашифровываются с

помощью кода сеанса.

Более сложной является ситуация, когда клиенту необходимо дать

серверу право пользоваться какими-либо ресурсами от его имени. В качестве

примера можно привести ситуацию, когда клиент посылает запрос серверу

печати, которому затем необходимо получить доступ к файлам пользователя,

расположенным на файл-сервере. Кроме того, при входе в удаленную систему

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

так же, как и с локальной машины. Эта проблема решается установкой

специальных флагов в «разрешении на получение разрешения» (дающих

одноразовое разрешение на доступ к серверу от имени клиента для первого

примера и обеспечивающих постоянную работу в этом режиме для второго).

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

адресу обладающей ими станции, то при наличии подобных флагов сервер выдачи

разрешений должен указать в разрешении сетевой адрес того сервера, которому

передаются полномочия на действия от имени клиента.

Следует отметить также, что для всех описанных выше процедур

идентификации необходимо обеспечить доступ к базе данных Kerberos только

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

ключей или добавления новых пользователей. Тогда используется третий сервер

Kerberos — административный (Kerberos Administration Server). He вдаваясь

в подробности его работы, следует отметить, что его реализации могут сильно

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

Связь между Kerberos-областями

Как уже было сказано выше, при использовании Kerberos-серверов сеть

делится на области действия Kerberos. Схема доступа клиента, находящегося в

области действия одного Kerberos-сервера, к ресурсам сети, расположенным в

области действия другого Kerberos, осуществляется следующим образом.

Целевой сервер

Оба Kerberos-сервера должны быть обоюдно зарегистрированы, то есть

знать общие секретные ключи и, следовательно, иметь доступ к базам

пользователей друг друга. Обмен этими ключами между Kerberos-серверами (для

работы в каждом направлении используется свой ключ) позво-ляет

зарегистрировать сервер выдачи разрешений каждой области как клиента в

другой области. После этого клиент, требующий доступа к ресурсам,

находящимся в области действия другого Kerberos-сервера, может получить

разрешение от сервера выдачи разрешений своего Kerberos по описанному выше

алгоритму. Это разрешение, в свою очередь, дает право доступа к серверу

выдачи разрешений другого Kerberos-сервера и содержит в себе отметку о том,

в какой Kerberos-области зарегистрирован пользователь. Удаленный сервер

выдачи разрешений использует один из общих секретных ключей для расшифровки

этого разрешения (который, естественно, отличается от ключа, используемого

в пределах этой области) и при успешной расшифровке может быть уверен, что

разрешение выдано клиенту соответствующей Kerberos-области. Полученное

разрешение на доступ к ресурсам сети предъявляется целевому серверу для

получения соответствующих услуг.

Следует, однако, учитывать, что большое число Kerberos-серверов в

сети ведет к увеличению количества передаваемой идентификационной

информации при связи между разными Kerberos-областями. При этом

увеличивается нагрузка на сеть и на сами Kerberos-серверы. Поэтому более

эффективным следует считать наличие в большой сети всего нескольких

Kerberos-серверов с большими областями действия, нежели использование

множества Kerberos-серверов. Тая, Kerberos-система, установленная компанией

Digital Equipment для большой банковской сети, объединяющей отделения в Нью-

Йорке, Париже и Риме, имеет всего один Kerberos-сервер. При этом, несмотря

на наличие в сети глобальных коммуникаций, работа Kerberos-системы

практически не отразилась на производительности сети.

Kerberos-5

К настоящему времени Kerberos выдержал уже четыре модификации, из

которых четвертая получила наибольшее распространение. Недавно группа,

продолжающая работу над Kerberos, опубликовала спецификацию пятой версии

системы, основные особенности которой отражены в стандарте RFC 1510. Эта

модификация Kerberos имеет ряд новых свойств, из которых можно выделить

следующие.

Уже рассмотренный ранее механизм передачи полномочий серверу на

действия от имени клиента, значительно облегчающий идентификацию в сети в

ряде сложных случаев, является нововведением пятой версии.

Пятая версия обеспечивает более упрощенную идентификацию

пользователей в удаленных Kerberos-областях, с сокращенным числом передач

секретных ключей между этими областями. Данное свойство, в свою очередь,

базируется на механизме передачи полномочий.

Если в предыдущих версиях Kerberos для шифрования использовался

исключительно алгоритм DES (Data Encryption Standard — Стандарт Шифрования

Данных), надежность которого вызывала некоторые сомнения, то в данной

версии возможно использование различных алгоритмов шифрования, отличных от

DES.

Заключение

Многие производители сетевого и телекоммуникационного оборудования

обеспечивают поддержку работы с Kerberos в своих устройствах.

Следует, однако, отметить, что использование Kerberos не является

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

сеть (например, он бессилен, если кто-либо узнал пароль пользователя),

поэтому его наличие не исключает других стандартных средств поддержания

соответствующего уровня секретности в сети.

Ни одна компьютерная система защиты информации не является абсолютно

безопасной. Однако адекватные меры защиты значительно затрудняют доступ к

системе и снижают эффективность усилий злоумышленника (отношение средних

затрат на взлом защиты системы и ожидаемых результатов) так, что

проникновение в систему становится нецелесообразным. Ключевым элементом в

системе безопасности является администратор системы. Какие бы средства вы

ни приобретали, качество защиты будет зависеть от способностей и усилий

этого человека.

Литература

Дьяченко В.И. “Теория систем безопасности данных”, ООО “Исток”, М.-

1995г.

Information Security Service DATAPRO International,

McGraw-HTl, Inc.

ORACLE7 Server Concepts Manual. P/N 6693-70.

Trusted ORACLE7 Server Administrator's Guide. P/N d610-70.

Trusted ORACLE7 Technical Overview. P/N Al 4774.

Computer Security and Evaluations Criteria White Paper. P/NA12944.

SQL* Net v. 4 Administrator's Guide. P/N 6545-20

Multiprotocol Interchange Administrator's Guide. P/N 6544-10.

Журналы (№3-10) “Сети” за 1998 год.

Журнал “Открытые системы” за 1997-1998 годы.

Страницы: 1, 2