Смекни!
smekni.com

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

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

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

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

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

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

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

Следует отметить также, что для всех описанных выше процедур иден­тификации необходимо обеспечить до­ступ к базе данных 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 годы.