Защита информации в глобальной сети Internet .

Защита информации в глобальной сети Internet.

Технология работы в глобальных сетях Solstice FireWall-1.

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

      В настоящем документе рассматриваются основные понятия экранирующих систем, а также требования, предъявляемые к ним. На примере пакета Solstice FireWall-1 рассматривается неcколько типичных случаев использования таких систем, особенно применительно к вопросам обеспечения безопасности Internet-подключений. Рассмотрено также несколько уникальных особенностей Solstice FireWall-1, позволяющих говорить о его лидерстве в данном классе приложений.

 

НАЗНАЧЕНИЕ ЭКРАНИРУЮЩИХ СИСТЕМ И ТРЕБОВАНИЯ К НИМ

.

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

Рисунок 3.1.1.1

      Экран FireWall.

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

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

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

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

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

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

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

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

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

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

 

ПРИМЕР РЕАЛИЗАЦИИ ПОЛИТИКИ БЕЗОПАСНОСТИ.

      Расcмотрим процесc практической реализации политики безопасности организации с помощью программного пакета FireWall-1.

 

Рисунок.3.1.3..1

 

      Реализация политики безопасности FireWall.

 

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

2. После утверждения эти правила надо воплотить в жизнь. Для этого их нужно перевести в структуру типа “откуда, куда и каким способом доступ разрешен или, наоборот, запрещен. Такие структуры, как мы уже знаем, легко переносятся в базы правил системы FireWall-1.

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

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

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

 

Рассмотрим простой пример реализации следующих правил:

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

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

3. Из Internet разрешается только отправлять и получать почту. Обо всех других попытках связи необходимо делать подробную запись. 

 

      Все эти правила естественным образом представляются средствами графического интерфейса Редактора Правил FireWall-1.

Р исунок 3.1.3..2

 

                  Графический интерфейс Редактора Правил FireWall-1.

 

      После загрузки правил, FireWall-1 для каждого пакета, передаваемого по сети, последовательно просматривает список правил до нахождения элемента, соответствующего текущему случаю.

      Важным моментом является защита системы, на которой размещен административно-конфигурационный модуль FireWall-1. Рекомендуется запретить средствами FireWall-1 все виды доступа к данной машине, или по крайней мере строго ограничить список пользователей, которым это разрешено, а также принять меры по физическому ограничению доступа и по защите обычными средствами ОС UNIX.

 

ЕЩЕ ОДИН ПРИМЕР РЕАЛИЗАЦИИ ПОЛИТИКИ БЕЗОПАСНОСТИ.

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

      Пусть мы решили установить у себя в организации несколько общедоступных серверов для предоставления информационных услуг. Это могут быть, например, серверы World Wide Web, FTP или другие информационные серверы. Поскольку такие системы обособлены от работы всей остальной сети организации, для них часто выделяют свою собственную подсеть, имеющую выход в Internet через шлюз.

Рисунок 3.1.5.1

 

      Схема шлюза Internet.

 

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

 

Ограничения доступа в WWW серверах.

Рассмотрим два из них:

•     Ограничить доступ по IP адресам клиентских машин;

•     ввести идентификатор получателя с паролем для данного вида документов.

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

 

Ограничения по IP адресам.

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

                          123.456.78.9

                           123.456.79.

В этом случае доступ будет разрешен (или запрещен в зависимости от контекста) для машины с IP адресом 123.456.78.9 и для всех машин подсетки 123.456.79.

ПРОЦЕДУРНЫЕ МЕРЫ.

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

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

• поддержка жизненного цикла информации, наполняющей Intranet.

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

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

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

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

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

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

ЗАЩИТА WEB-СЕРВЕРОВ.

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

      В Web-серверах объектами доступа выступают универсальные локаторы ресурсов (URL - Uniform (Universal) Resource Locator). За этими локаторами могут стоять различные сущности - HTML-файлы, CGI-процедуры и т.п.

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

      В большинстве Web-серверов права разграничиваются с точностью до каталогов (директорий) с применением произвольного управления доступом. Могут предоставляться права на чтение HTML-файлов, выполнение CGI-процедур и т.д.

      Для раннего выявления попыток нелегального проникновения в Web-сервер важен регулярный анализ регистрационной информации.     

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

      Еще один общий принцип состоит в том, чтобы минимизировать объем информации о сервере, которую могут получить пользователи. Многие серверы в случае обращения по имени каталога и отсутствия файла index.HTML в нем, выдают HTML-вариант оглавления каталога. В этом оглавлении могут встретиться имена файлов с исходными текстами CGI-процедур или с иной конфиденциальной информацией. Такого рода “дополнительные возможности” целесообразно отключать, поскольку лишнее знание (злоумышленника) умножает печали (владельца сервера).

 

PGP.

Алгоритмы шифрования реализуются программными или аппаратными средствами. Есть великое множество чисто программных реализаций различных алгоритмов. Из-за своей дешевизны (некoторые и вовсе бесплатны), а также все большего быстродействия процессоров ПЭВМ, простоты работы и безотказности они весьма конкурентоспособны.

Нельзя не упомянуть пакет PGP (Pretty Good Privacy, автор Philip Zimmermann), в котором комплексно решены практически все проблемы защиты передаваемой информации. Применены сжатие данных перед шифрованием, мощное управление ключами, вычисление контрольной функции для цифровой подписи, надежная генерация ключей.

В Internet фактическим стандартом шифрования является программа PGP (Pretty Good Privacy), разработанная в 1991 году Филиппом Циммерманом. PGP позволяет зашифровывать сообщения так, чтобы только получатели могли их прочесть, или ставить на них цифровые подписи так, чтобы можно было убедиться в подлинности автора. В настоящий момент программа доступна на платформах UNIX, DOS, Macintosh и VAX. PGP свободно распространяется по Internet для некоммерческих пользователей вместе с 75-страничным справочным руководством. Кроме того, последняя версия PGP 2.6.6 можно приобрести в MIT.

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

PGP предназначена, в первую очередь, для защиты электронной почты, хотя ее целиком можно использовать и для защиты файлов на жестком диске. Особенно привлекательными чертами PGP есть многочисленные plug-ins для популярных почтовых программ, таких как Eudora, Netscape и Outlook. Plug-ins настраивают PGP для этих программ и дополняют их некоторыми приятными мелочами, такими, как дополнительная кнопка панели инструментов. Иконка в правом нижнем углу (tray), всплывающая панель инструментов (floating toolbox) и меню правой клавиши мышки (right-click menu) в PGP необычайно логично и удобно продуманы. Поэтому она очень проста в управлении.

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

PGP особенно быстродейственна при пересылке зашифрованной информации пользователям Mac. Опция Smart Binary новых версий облегчает пересылку зашифрованных писем из Mac на Windows (и в обратном направлении).

Можно столкнуться с системой защиты PGP в программе, которая называется Nuts & Bolts, производство Helix Software. Это та же программа, только PGP – более новая версия. Network Associates поглотила Helix и завладела правами на продукт. Новая версия PGP for Personal Privacy – совместима с предыдущими версиями, в том числе Nuts & Bolts. В целом Pretty Good Privacy – это приятная и удобная в работе программа.   

Основные команды PGP

pgp –kg Создать два ключа и вашу связку отрытых ключей.

Pgp –kx [a] имя_пользователя Извлечь ключ (например, ваш открытый ключ)

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

Pgp –ka имя_файла Добавить чей-либо ключ в связку.

Pgp –e имя_файла получатель/получатели Зашифровать файл так, чтобы только определенные

пользователи могли его прочитать (для этого необходимо иметь копию

соответствующих отрытых ключей).

Pgp –es имя_файла получатель/получатели Зашифровать файл и поставить цифровую подпись.

Pgp –s имя_файла Поставить цифровую подпись.

(Создается двоичный файл, который не так просто переслать по почте;

получателям необходимо воспользоваться PGP).

Pgp –sa имя_файла Поставить цифровую подпись и сохранить

результат как ASCII-текст. (Просто пересылается по сети, но также требует PGP для прочтения).

Pgp зашифрованный_файл Проверить подпись на зашифрованном файле.

Pgp зашифрованный_файл расшифрованный_файл Расшифровать присланный файл.

 

Blowfish.

Blowfish 97 использует ряд схем систем защиты в два этапа. Первичный механизм шифрования базируется на Blowfish, которую разработал в 1993 году Bruce Schneier. Blowfish – это симметричный шифр, который использует ключи сменной длины – от 32 бит до 448 бит. Система защиты Blowfish не запатентована, и, следовательно, разрешена для использования в любом продукте, в который входит. Существуют четыре разных варианта Blowfish, вы часто можете встретиться с ней среди опций многих программ защиты.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

Blowfish -блочный шифр с ключом переменной длины. Это подходит для приложений, где ключ изменяется не часто, подобных линии связи или автоматическому шифрователю файла. Он значительно быстрее, чем DES при выполнении на 32-битных процессорах с большим КЭШем данных, таких как Pentium и PowerPC.

ОПИСАНИЕ АЛГОРИТМА

Blowfish - 64-битный блочный шифр с ключом переменной длины. Алгоритм включает в себя 2 части: часть расширения ключей и часть шифрования данных. Расширение ключа преобразует ключ, в большинстве 448-битный, в несколько суммированных массивов подключей в 4168 байт.

Шифрование данных происходит через 16-итерационную сеть Feistel. Каждая итерация состоит из ключе-зависимой перестановки, и зависящей от ключа и данных замены. Все операции - XOR и сложение на 32-битных словах. Единственные дополнительные операции - 4 поиска в индексированных массивах на итерацию.

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

1. P-массив включает 18 32-битных подключей:
P1, P2,..., P18.

2.Имеются четыре 32-битных S-блока с 256 входами каждый:
S1,0, S1,1,..., S1,255;
S2,0, S2,1,..,, S2,255;
S3,0, S3,1,..., S3,255;
S4,0, S4,1,..,, S4,255.

Шифрование: Blowfish - сеть Feistel, которая включает 16 итераций.

Реализации Blowfish, которые требуют наибольших скоростей, не должны организовываться в цикле, что гарантирует присутствие всех подключей в КЭШе.

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

MINI-BLOWFISH

Следующие малые версии Blowfish определены исключительно для криптоанализа. Они не предлагаются для реализации. Blowfish-32 имеет размер блока в 32 бита, и массивы подключей с 16 битными входами (каждый S-блок имеет 16 входов). Blowfish-16 имеет размер блока в 16-бит, и массивы подключей с 8-битными входами (каждый S-блок имеет 4 входа).

РЕАЛИЗАЦИЯ ПРОЕКТА

Вероятность ошибок в реализации алгоритма мала, т.к. сами S блоки и P-блок очень просты. 64-битный блок в действительности разбивается на 32-битные слова, что совместимо с существующими алгоритмами. В Blowfish можно легко повышать размер блока до 128-бит, и понижать размер блока. Криптоанализ вариантов мини-Blowfish может быть значительно проще, чем криптоанализ полной версии.

Сеть Feistel, составляющая тело Blowfish, разработана так, чтобы при наибольшей простоте она сохраняла свои криптографические свойства.

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

Отнимающий много времени процесс порождения подключей добавляет сложность для нападения "в лоб". Всего 522 итераций алгоритма шифрования требуется, чтобы проверить один ключ, что добавляет 29 шагов при любом нападение в лоб.

ВОЗМОЖНЫЕ УПРОЩЕНИЯ

Меньшее количество итераций. Вероятно, возможно уменьшение количества итераций с 16 до 8 без сильного ослабления защиты. Число итераций требуемых для защиты может зависеть от длины ключа. Обратите внимание, что с имеющейся процедурой порождения подключа, алгоритм с 8 итерациями не может обрабатывать ключ длиной больше 192 бит.

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

Наиболее эффективный способ взломать Blowfish - через полный перебор ключей Исходный текст на Си и тестовые векторы может получить любой, желающий реализовать алгоритм, в соответствие с законами США об экспорте.

Blowfish незапатентован, и будет таким оставаться во всех странах. Алгоритм тем самым помещен в общую область и может быть использован любым.

Blowfish - это простая и легкая в понимании программа. Панель инструментов содержит только картинки и ни одного слова. Четкая система подсказок. Выбрав файл, и нажав на изображение «замка», вы получите сообщение, что сейчас возможно использование шифрования только с ключом из пяти позиций, но после регистрации доступными будут и 32000-символьные ключи шифрования. После введения ключа процесс шифрования длится несколько секунд. Файл получает новое расширение (.BFA), которое служит командой для операционной системы при встрече с ним запустить в действие Blowfish Advanced.

В сети существует также защитная программа под Windows 95/NT, которая использует механизм Blowfish. EncLib 5/5 Использует для шифрования варианты Blowfish CDC и ECB.

 

KERBEROS.

Развитие криптологии с открытым ключом позволило криптологическим системам довольно быстро найти широкое коммерческое применение. Но интенсивное использование криптографии не обходится без “накладок”. Время от времени появляется информация о неприятностях в той или иной системе защиты. Последним нашумевшим в мире происшествием стал взлом системы Kerberos. Система эта, разработанная в середине 80-х годов, довольно популярна в мире, и ее взлом вызвал немалое беспокойство пользователей.

Проблема защиты компьютерных сетей от несанкционированного доступа приобрела особую остроту. Развитие коммуникационных технологий позволяет строить сети распределенной архитектуры, объединяющие большое количество сегментов, расположенных на значительном удалении друг от друга. Все это вызывает увеличение числа узлов сетей, разбросанных по всему миру, и количества различных линий связи между ними, что, в свою очередь, повышает риск несанкционированного подключения к сети для доступа к важной информации. Особенно неприятной такая перспектива может оказаться для банковских или государственных структур, обладающих секретной информацией коммерческого или любого другого характера. В этом случае необходимы специальные средства идентификации пользователей в сети, обеспечивающие доступ к информации лишь в случае полной уверенности в наличии у пользователя прав доступа к ней. Существует ряд разработок, позволяющих с высокой степенью надежности идентифицировать пользователя при входе в систему. Среди них, например, есть технологии, идентифицирующие пользователя по сетчатке глаза или отпечаткам пальцев. Кроме того, ряд систем использует технологии, основанные на применении специального идентификационного кода, постоянно передаваемого по сети. Так, при использовании устройства (фирмы Security Dinamics) обеспечивается дополнительная информация о пользователе в виде шестизначного кода. В данном случае работа в сети невозможна без наличия специальной карты SecureID (похожей на кредитную), которая обеспечивает синхронизацию изменяющегося кода пользователя с хранящимися на UNIX-хосте. При этом доступ в сеть и работа в ней может осуществляться лишь при знании текущего значения кода, который отображается на дисплее устройства SecureID. Однако основным недостатком этой и ей подобных систем является необходимость в специальном оборудовании, что вызывает неудобства в работе и дополнительные затраты. Система Kerberos (по-русски – Цербер), разработанная участниками проекта Athena, обеспечивает защиту сети от несанкционированного доступа, базируясь исключительно на программных решениях, и предполагает многократное шифрование передаваемой по сети управляющей информации. Kerberos обеспечивает идентификацию пользователей сети и серверов, не основываясь на сетевых адресах и особенностях операционных систем рабочих станций пользователей, не требуя физической защиты информации на всех машинах сети и исходя из предположения, что пакеты в сети могут быть легко прочитаны и при желании изменены. 

Клиент/ Kerberos/ Сервер.

Kerberos имеет структуру типа клиент/сервер и состоит из клиентских частей, установленных на все машины сети (рабочие станции пользователей и серверы), и Kerberos-сервера (или серверов), располагающегося на каком-либо (не обязательно выделенном) компьютере.Kerberos-сервер, в свою очередь, делится на две равноправные части: сервер идентификации (authentication server) и сервер выдачи разрешений (ticket granting server). Следует отметить, что существует и третий сервер Kerberos, который, однако, не участвует в идентификации пользователей, а предназначен для административных целей. Область действия Kerberos (realm) распространяется на тот участок сети, все пользователи которого зарегистрированы под своими именами и паролями в базе Kerberos-сервера и где все серверы обладают общим кодовым ключом с идентификационной частью Kerberos. Эта область не обязательно должна быть участком локальной сети, поскольку Kerberos не накладывает ограничения на тип используемых коммуникаций. Упрощенно модель работы Kerberos можно описать следующим образом. Пользователь (Kerberos-клиент), желая получить доступ к ресурсу сети, направляет запрос идентификационному серверу Kerberos. Последний идентифицирует пользователя с помощью его имени и пароля и выдает разрешение на доступ к серверу выдачи разрешений, который, в свою очередь, дает “добро” на использование необходимых ресурсов сети. Однако данная модель не отвечает на вопрос о надежности защиты информации, поскольку, с одной стороны, пользователь не может посылать идентификационному серверу свой пароль по сети, а с другой – разрешение на доступ к обслуживанию в сети не может быть послано пользователю в виде обычного сообщения. В обоих случаях информация может быть перехвачена и использована для несанкционированного доступа в сеть. Для того, чтобы избежать подобных неприятностей Kerberos применяет сложную систему многократного шифрования при передаче любой управляющей информации в сети. Доступ пользователей к сетевым серверам, файлам, приложениям, принтерам и т.д. осуществляется по следующей схеме. Клиент (под которым в дальнейшем будет пониматься клиентская часть Kerberos, установленная на рабочей станции пользователя) направляет запрос идентификационному серверу на выдачу “разрешения на получение разрешения” (ticket-granting ticket), которое даст возможность обратиться к серверу выдачи разрешений. Идентификационный сервер адресуется к базе данных, хранящей информацию о всех пользователях, и на основании содержащегося в запросе имени пользователя определяет его пароль. Затем клиенту отсылается “разрешение на получение разрешения” и специальный код сеанса (session key), которые шифруются с помощью пароля пользователя как ключа. При получении этой информации пользователь на его рабочей станции должен ввести свой пароль, и если он совпадает с хранящимися в базе Kerberos-сервера, “разрешение на получение разрешения” и код сеанса будут успешно расшифрованы. Таким образом решается проблема с защитой пароля – в данном случае он не передается по сети. После того как клиент зарегистрировался с помощью идентификационного сервера Kerberos, он отправляет запрос серверу выдачи разрешений на получение доступа к требуемым ресурсам сети. Этот запрос (или “разрешение на получение разрешения”) содержит имя пользователя, его сетевой адрес, отметку времени, срок жизни этого разрешения и код сеанса.“Разрешение на получение разрешения” зашифровывается два раза: сначала с помощью специального кода, который известен только идентификационному серверу и серверу выдачи разрешений, а затем, как уже было сказано, с помощью пароля пользователя. Это предотвращает не только возможность использования этого разрешения при его перехвате, но и делает его недоступным самому пользователю. Для того чтобы сервер выдачи разрешений дал клиенту доступ к требуемым ресурсам, недостаточно только “разрешения на получение разрешения”. Вместе с ним клиент посылает так называемый аутентикатор (authenticator), зашифровываемый с помощью кода сеанса и содержащий имя пользователя, его сетевой адрес и еще одну отметку времени. Сервер выдачи разрешений расшифровывает полученное от клиента “разрешение на получение разрешения”, проверяет, не истек ли срок его “годности”, а затем сравнивает имя пользователя и его сетевой адрес, находящиеся в разрешении, с данными, которые указаны в заголовке пакета пришедшего сообщения. Однако на этом проверки не заканчиваются. Сервер выдачи разрешений расшифровывает аутентикатор с помощью кода сеанса и еще раз сравнивает имя пользователя и его сетевой адрес с предыдущими двумя значениями, и только в случае положительного результата может быть уверен наконец, что клиент именно тот, за кого себя выдает. Поскольку аутентикатор используется для идентификации клиента всего один раз и только в течение определенного периода времени, становится практически невозможным одновременный перехват “разрешения на получение разрешения” и аутентикатора для последующих попыток несанкционированного доступа к ресурсам сети. Каждый раз, при необходимости доступа к серверу сети, клиент посылает “разрешение на получение разрешения” многоразового использования и новый аутентикатор. После успешной идентификации клиента в качестве источника запроса сервер выдачи разрешений отсылает пользователю разрешение на доступ к ресурсам сети (которое может использоваться многократно в течение некоторого периода времени) и новый код сеанса. Это разрешение зашифровано с помощью кода, известного только серверу выдачи разрешений и серверу, к которому требует доступа клиент, и содержит внутри себя копию нового кода сеанса. Все сообщение (разрешение и новый код сеанса) зашифровано с помощью старого кода сеанса, поэтому расшифровать его может только клиент. После расшифровки клиент посылает целевому серверу, ресурсы которого нужны пользователю, разрешение на доступ и аутентикатор, зашифрованные с помощью нового кода сеанса. Для обеспечения еще более высокого уровня защиты, клиент, в свою очередь, может потребовать идентификации целевого сервера, чтобы обезопаситься от возможного перехвата информации, дающей право на доступ к ресурсам сети. В этом случае он требует от сервера высылки значения отметки времени, увеличенного на единицу и зашифрованного с помощью кода сеанса. Сервер извлекает копию кода сеанса, хранящуюся внутри разрешения на доступ к серверу, использует его для расшифровки аутентикатора, прибавляет к отметке времени единицу, зашифровывает полученную информацию с помощью кода сеанса и отсылает ее клиенту. Расшифровка этого сообщения позволяет клиенту идентифицировать сервер. Использование в качестве кода отметки времени обеспечивает уверенность в том, что пришедший клиенту ответ от сервера не является повтором ответа на какой-либо предыдущий запрос. Теперь клиент и сервер готовы к передаче необходимой информации с должной степенью защиты. Клиент обращается с запросами к целевому серверу, используя полученное разрешение. Последующие сообщения зашифровываются с помощью кода сеанса. Более сложной является ситуация, когда клиенту необходимо дать серверу право пользоваться какими-либо ресурсами от его имени. В качестве примера можно привести ситуацию, когда клиент посылает запрос серверу печати, которому затем необходимо получить доступ к файлам пользователя, расположенным на файл-сервере. Кроме того, при входе в удаленную систему пользователю необходимо, чтобы все идентификационные процедуры выполнялись так же, как и с локальной машины. Эта проблема решается установкой специальных флагов в “разрешении на получение разрешения” (дающих одноразовое разрешение на доступ к серверу от имени клиента для первого примера и обеспечивающих постоянную работу в этом режиме для второго). Поскольку, как было сказано выше, разрешения строго привязаны к сетевому адресу обладающей ими станции, то при наличии подобных флагов сервер выдачи разрешений должен указать в разрешении сетевой адрес того сервера, которому передаются полномочия на действия от имени клиента. Следует отметить также