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

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