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

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

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

Литература

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

М.- 1995г.

II] Information Security Service DATAPRO International,

III] McGraw-HTl, Inc.

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

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

VI] Trusted ORACLE7 Technical Overview. P/N Al 4774.

VII] Computer Security and Evaluations Criteria White Paper.

P/NA12944.

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

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

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

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

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