Научная Петербургская Академия

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

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

САНКТ-ПЕТЕРБУРГСКАЯ ИНЖЕНЕРНАЯ

ШКОЛА ЭЛЕКТРОНИКИ

КУРСОВАЯ РАБОТА

по курсу “СЕТЕВЫЕ ТЕХНОЛОГИИ”.

Тема

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

Группа 386-ф

Ковпак Л.В.

Санкт-Петербург

Введение

Концентрация информации в компьютерах — аналогично концентрации наличных

денег в банках — заставляет все бо­лее усиливать контроль в целях защиты

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

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

правительст­венных организациях. Работы в этом направлении привели к

появлению новой дисциплины: безопасность информации. Специалист в области

безопас­ности информации отвечает за разработку, реализацию и экс­плуатацию

системы обеспече­ния информсционной безопас­ности, направленной на

под­держание целостности, пригод­ности и конфиденциальности накопленной в

организации ин­формации. В его функции вхо­дит обеспечение физической

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

(данные, прикладные программы, опера­ционная система) защиты ин­формационных

ресурсов.

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

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

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

изменении.

Проблема защиты компьютер­ных сетей от несанкциониро­ванного доступа

приобрела особую остроту. Развитие ком­муникационных технологий позволяет

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

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

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

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

риск несанкци­онированного подключения к сети для доступа к важной

ин­формации. Особенно неприят­ной такая перспектива может оказаться для

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

коммерческого или любо­го другого характера. В этом случае необходимы

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

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

пользова­теля прав доступа к ней.

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

идентифицировать пользователя при входе в систему. Сре­ди них, например, есть

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

пальцев. Кроме того, ряд систем ис­пользуют технологии, основанные на

применении специального иден­тификационного кода, постоянно передаваемого по

сети. Так, при ис­пользовании устройства SecureID (фирмы Security Dinamics)

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

шести­значного кода. В данном случае работа в сети невозможна без наличия

специальной карты SecureID (похожей на кредитную), которая обес­печивает

синхронизацию изменяющегося кода пользователя с храня­щимися на UNIX-хосте,

При этом доступ в сеть и работа в ней может осуществляться лишь при знании

текущего значения кода, который отображается на дисплее устройства SecureID.

Однако основным не­достатком этой и ей подобных систем является необходимость

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

дополни­тельные затраты.

В статье рассматриваются некоторые возможности обеспечения безопас­ности в

системах — шифрование информации при передаче по каналам связи и

использование надежных (достоверных, доверительных) (Trusted) систем — на

примере СУБД ORACLE, а так же система защиты от несанкционированого доступа к

сети Kerberos.

Безопасность в среде баз данных

Очевидные достоинства баз данных в современной среде обработки дан­ных служат

гарантией их дальнейшего развития и использования. Конт­роль доступа в этой

области важен ввиду колоссальной концентрации ин­формации.

В настоящий момент «хребтом» базовых систем обработки информации во многих

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

такое же место и в фирмах меньшего размера. Растущая по­пулярность локальных

сетей требует соответствующей защиты информа­ции, но исторически они были

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

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

здания или района (городка) сотрудник, имеющий доступ к физической линии,

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

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

авторизация и шифрование ин­формации, дополненные резервированием.

Определение потребности в защите информации

Обеспечение безопасности информации — дорогое дело, и не столько из-за затрат

на закупку или установку средств, сколько из-за того, что труд­но

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

поддержания системы в работоспособном состоянии.

Если локальная сеть разрабатывались в целях совместного использова­ния

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

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

минимальных системах шифрования/дешифрования информации.

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

до тех пор, пока не произведен соответствующий анализ.

Анализ риска должен дать объективную оценку многих фак­торов (подверженность

появлению нарушения работы, веро­ятность появления нарушения работы, ущерб от

коммерче­ских потерь, снижение коэффициента готовности системы, общественные

отношения, юридические проблемы) и предо­ставить информацию для определения

подходящих типов и уровней безопасности. Коммерческие организации все в

боль­шей степени переносят критическую корпоративную инфор­мацию с больших

вычислительных систем в среду открытых систем и встречаются с новыми и

сложными проблемами при реализации и эксплуатации системы безопасности.

Сегодня все больше организаций разворачивают мощные распределен­ные базы

данных и приложения клиент/сервер для управле­ния коммерческими данными. При

увеличении распределе­ния возрастает также и риск неавторизованного доступа к

дан­ным и их искажения.

Шифрование данных традиционно использовалось прави­тельственными и оборонными

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

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

шифрованием для обеспечения конфиденциальности ин­формации.

Финансовые службы компаний (прежде всего в США) представляют важную и большую

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

алгоритму, ис­пользуемому в процессе шифрования. Опубликованные алго­ритмы,

например DES (См. ниже), являются обязательными. В то же время, рынок

коммерческих систем не всегда требует та­кой строгой защиты, как

правительственные или оборонные ве­домства, поэтому возможно применение

продуктов и другого типа, например PGP (Pretty Good Privacy).

Шифрование

Шифрование данных может осуществляться в режимах On-Line (в темпе поступления

информации) и Off-Line (авто­номном). Остановимся подробнее на первом типе,

представля­ющем больший интерес. Наиболее распространены два алго­ритма.

Стандарт шифрования данных DES (Data Encryption Standard) был разработан

фирмой IBM в начале 70-х годов и в настоящее время является правительственным

стандартом для шифрования цифровой информации. Он рекомендован Ассо­циацией

Американских Банкиров. Сложный алгоритм DES ис­пользует ключ длиной 56 бит и

8 битов проверки на четность и требует от злоумышленника перебора 72

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

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

удовлетворительно решает проблему превращения кон­фиденциальной информации в

недоступную.

Алгоритм RSA был изобретен Ривестом, Шамиром и Альде-маном в 1976 году и

представляет собой значительный шаг в криптографии. Этот алгоритм также был

принят в качестве стандарта Национальным Бюро Стандартов.

DES, технически, является СИММЕТРИЧНЫМ алгорит­мом, а RSA — АСИММЕТРИЧНЫМ, то

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

имеют два ключа и могут широко распространять свой отк­рытый ключ. Открытый

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

определенный получатель может дешифровать его своим секретным ключом;

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

соглашения о передаче ключей между корреспонден­тами. DES определяет длину

данных и ключа в битах, а RSA мо­жет быть реализован при любой длине ключа.

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

процесс шифрования и дешифрования). Если ключи DES можно сгенерировать за

микросекунды, то примерное время ге­нерации ключа RSA — десятки секунд.

Поэтому открытые клю­чи RSA предпочитают разработчики программных средств, а

секретные ключи DES — разработчики аппаратуры.

Некоторые решения

Примером архитектуры клиент/сервер, которую хорошо дополняют средства

шифрования, могут служить Oracle Server, сетевые продукты (SQMNet) и

программное обеспечение кли­ента.

Сетевая служба безопасности (SNS — Secure Network Services) предлагает

стандартный, оптимизированный алго­ритм шифрования DES с ключом длиной 56 бит

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

за­казчиков вне пределов США или Канады SNS предлагает DES40, в котором

комбинируется использование алгоритма шифрования DES с общепринятым ключом

длиной 40 бит (эк­спорт технологий шифрования в США законодательно

ограни­чен). Наряду с DES возможно также использование алгоритма шифрования

RSA RC4.

Секретный, генерируемый случайным образом ключ для каждой сессии SQL* Net

сохраняет весь сетевой трафик — включая пароли, значения данных, SQL-

утверждения и сохра­няемые вызовы и результаты.

Для обнаружения модификации или подмены данных во время передачи SNS

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

сообщения, и включает его в каждый пакет, передаваемый по сети. При

полу­чении пакета в пункте назначения SNS немедленно производит проверку

целостности каждого пакета.

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

1) криптографически защищенная контрольная сумма в каждом пакете SQL*

Net обеспечивает защиту от модификации данных и замены операции;

2) при обнаружении нарушений операции незамедлительно автоматически

завершаются;

3) информация о всех нарушениях регистрируется в жур­нале.

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

полностью поддерживается Oracle Multiprotocol Interchange — при работе с

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

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

информации. SNS полностью поддерживает­ся сквозными шлюзами, Oracle

Transparent Gateways, и проце­дурными шлюзами, Oracle Procedural Gateways,

которые дают возможность организовывать полностью зашифрованные сес­сии

клиент/сервер к отличным от Oracle источникам данных, включая Adabas, CA-

Datacom, DB2, DRDA, FOCUS, IDMS, IMS, ISAM, MUMPS, QSAM, Rdb, RMS, SAP,

SQL/DS, SQL/400, SUPRA, Teradata, TOTAL, VSAM и другие.

SNS работает со всеми основными протоколами, поддержи­ваемыми SQL* Net,

включая AppleTalk, Banyan, DECnet, LU6.2, MaxSix, NetBIOS, SPX/IPX, TCP/IP,

X.25 и другие.

Обеспечивается независимость от топологии сети — SNS работает во всех

основных сетевых средах, поддерживаемых SQL-Net.

SNS представляет собой дополнительный продукт к стан­дартному пакету SQL*

Net, то есть требуется предварительно приобрести лицензию на SQL* Net.

Продукт надо покупать и для клиента, и для сервера.

Вместе тем СУБД Oracle, начиная с версии 7.1, пароль пере­дается по сети в

зашифрованном виде.

Это означает, что при организации связи клиент/сервер ис­пользуется новый

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

только для единст­венной попытки соединения с базой данных и используемый в

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

Oracle-сервер находит зашифрованный па­роль для этого пользователя и

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

Затем сервер пересылает этот зашифрованный сеансовый ключ клиенту. Клиент

шифрует (применяя тот же самый односторонний ал­горитм, который используется

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

зашифрованный сеансовый ключ. Обнаружив этот сеансовый ключ, он исполь­зует

его — это становится совместным секретом клиента и сер­вера — для шифрования

пароля пользователя. Этот зашифро­ванный пароль затем передается через сеть

серверу. Сервер де­шифрует пароль и затем зашифровывает его, используя

одно­сторонний алгоритм сервера; результат этих вычислений све­ряется со

значением, хранимым в словаре данных. Если они совпадают, клиенту

предоставляется доступ. Такой подход ре­ализуется как в соединениях типа

клиент/сервер, так и сер­вер/сервер, где сеансы устанавливаются через так

называемые полномочные звенья баз данных (т.е. звенья баз данных без

вложенных имен пользователей и паролей).

Понятия идентификации и аутентифи­кации

в достоверных системах

Известны большие выгоды, которые дает переход к откры­тым системам. Но среди

них не значится безопасность инфор­мации. Это и понятно — центр обработки

данных передает не­которые из своих функций по контролю за системой отделам и

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

Сохранить требуемый уровень безопасности системы воз­можно при использовании

операционных систем класса В1 (Trusted), которые позволяют администратору

системы прис­воить каждому пользователю уровень доступности объектов системы

(Secret, Confidential, Unclassified).

Обработка секретной и конфиденциальной информации требует от системы

использовать механизм гарантии соответст­вующей идентификации и

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

аутентификации' дол­жны быть идентифицированы, рассмотрены и сравнены с

Кри­терием Оценки Достоверности Вычислительных Систем (TCSEC), или с

«Оранжевой Книгой» (в Европе — Критерием Оценки Безопасности Информационных

Технологий, или «Бе­лой Книгой»).

TCSEC делится на четыре класса: D, С, В и А. Эти классы упорядочены, причем

самый высокий класс (А) зарезервиро­ван за системами, имеющими наивысший

уровень защиты ин­формации. Внутри классов В и С имеются подклассы, которые

тоже упорядочены в соответствии с обеспечиваемым уровнем защиты. Коротко

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

защиты информации (неклас­сифицированная), к классу С — что она имеет

некоторые сред­ства избирательной защиты (классифицированная), к классу В —

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

описываются как «полномочные» (секрет­ная информация), ну а если система

отнесена к классу А, зна­чит, средства защиты ранее проверены (совершенно

секретная информация). Многие популярные операционные системы (например,

различные варианты PС UNIX, Sun Solaris 2.3 и т.п.) соответствуют классу С.

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

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

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

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

которые Достоверная Компьютерная База (ТСВ — Trusted Computer Base)

сравни­вает со своей базой данных пользователей, содержащей ранги авторизации

для каждого пользователя. Если информация, указанная при вхождении в связь,

корректна и ее уровень признан соответствующим запросу, ТСВ допускает

пользова­теля в систему. При попытке доступа к файлам ТСВ выступа­ет в роли

арбитра, при этом ТСВ основывается на уровне пользователя и метке файла или

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

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

а разрешение на доступ к объекту определяет­ся конфиденциальностью и объекта,

и субъекта (внешний п ( отношению к ТСВ), авторизация субъекта становится

компонентом требований к авторизации.

Оранжевая Книга фокусирует внимание на законченны вычислительных системах и

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

1) система должна иметь четкий сертификат безопасности

2) каждый объект, ассоциированный с этим сертификате! должен иметь метку

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

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

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

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

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

информации;

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

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

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

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

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

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

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

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

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

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

защиты информации (Multi-Level Security — MLS) — Trusted ORACLE7, обладающую,

в том чис­ле, и всеми стандартными возможностями ORACLE7.

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

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

выделенное обору­дование. С появлением таких продуктов, как Trusted ORA­CLE7,

эта необходимость отпала. 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 годы.



(C) 2009