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