|
|
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ #01/97
|
|
Защита корпоративных информационных систем - непростая задача, и в особенности это относится к защите данных. Технологии безопасности всегда отставали от других областей, таких как сетевые и коммуникационные средства. Многие модели, предложенные еще в середине - конце 80-х годов (например, поддержка различных уровней защиты данных, хранящихся в одной базе данных), только сейчас начинают внедряться в коммерческие продукты. Если в течение долгого времени развитием большинства аспектов безопасности баз данных двигали интересы правительственных - в частности оборонных - учреждений, то теперь в игру все активнее вступают интересы коммерческих структур. Результаты многих проведенных к настоящему времени исследований, скорее всего, найдут применение и в сфере безопасности коммерческой информации, хотя реальную значимость некоторых из них (например, схем многоуровневой защиты) еще предстоит оценить. Важно понимать, что коммерческие продукты, проходящие сертификацию в Национальном центре компьютерной безопасности (NCSC - National Computer Security Center), фактически проверяются на соответствие требованиям, возникшим в ответ на запросы оборонного сектора; причем в соответствующие технологии уже вложены астрономические средства. Поэтому весьма вероятно, что схемы безопасности, разрабатываемые для коммерческих систем, будут аналогичны моделям, выдвинутым в оборонной сфере. Поэтому, даже если ваша организация не имеет ничего общего с компьютерными системами оборонного назначения, описанные в этой главе модели безопасности могут тем не менее сыграть важную роль и в выработке вашей программы защиты баз данных.
Можно начать с двух абсолютно справедливых утверждений о безопасности баз данных: во-первых, это задача непростая, во-вторых, это обходится недешево.
Несмотря на весьма интенсивную деятельность в этой сфере начиная уже с начала 80-х средства безопасности начали внедряться в коммерческих продуктах СУБД не ранее начала 90-х. При этом то, что мы сегодня реально имеем, еще очень далеко от наших представлений о том, какой должна быть действительно безопасная среда баз данных будущего.
Сложности здесь связаны не только с техническими проблемами (подробно обсуждаемыми в этой главе), но и с рядом вопросов, которые перечислены ниже1).
Безопасность вообще и безопасность баз данных в частности - это дорогое удовольствие, всегда связанное с определенными неудобствами. Почти любая мыслимая мера безопасности вступает в конфликт с теми или иными преимуществам в других сферах, таких как связность, межоперабельность, простота использования, производительность.
В сегодняшних условиях экономических ограничений, принятие долговременных инвестиционных мер сопряжено с трудностями с точки зрения оценки периода возврата средств и получения реальной отдачи. Здесь мы ориентируемся на разукрупнение, стандартизацию и другие популярные в 90-х мероприятия. Вложения в безопасность не обещают немедленного возврата средств, их можно сравнить со страхованием: реальная выгода проявляется только тогда, когда случается что-то плохое, а вероятность подобного события относительно невелика.
В свете вышесказанного интересно отметить, что движущей силой развития средств безопасности традиционно было правительство США, в особенности Министерство обороны. Усилия по продвижению средств безопасности со стороны коммерческих структур, где они весьма существенны для ряда отраслей, таких как банковское дело, и в некоторых сферах типа борьбы с вирусами, всегда отставали от инициатив правительственного сектора. Сашил Джаджодиа из Университета Джорджа Мейсона иронично заметил по этому поводу: "Трудно представить себе, чтобы крупное нарушение безопасности, каким бы серьезным оно ни было, привело бы к национальной катастрофе; в то же время нарушение защиты того же масштаба вполне могло бы привести к крушению компании или крупного концерна"2).
Раз информация представляет собой исключительную ценность как для корпораций, так и для правительства - и в США, и во всем мире - то, стало быть, информационная защита есть насущная необходимость. Организации постепенно осознают это и переходят к внедрению или по крайней мере исследованию различных программ безопасности, охватывающих такие области компьютерных технологий, как коммуникации, операционные системы, информационное управление.
Проблема отчасти заключается в том, что у разных организаций существуют весьма разнообразные потребности в информационной защите. Для некоторых коммерческих организаций случайные утечки информации не составляют большой угрозы (если не считать осложнений, связанных с Законом о конфиденциальности). Такие компании значительно больше озабочены проблемами доступности систем, предотвращением порчи приложений, вызванной вирусами, Троянскими конями, червями и проч. и, возможно, недопущением несанкционированных изменений данных (в особенности, финансовой информации, такой как балансы банковских счетов).
В то же время в других организациях - например в военных ведомствах - раскрытие данных высокого уровня секретности может нанести значительный ущерб. Разглашение имен агентов, планов военных кампаний и тому подобных сведений может серьезно нарушить способность военного формирования успешно решать свои задачи.
Безопасность баз данных в течение долгого времени находилась как бы на втором плане в сравнении с такими областями, как безопасность сетей и коммуникаций (что в особенности относится к коммерческим организациям), но некоторые нашумевшие происшествия, например вирус "Микеланджело" или червь "Интернет", привлекли внимание к проблеме защиты баз данных и информационных активов. Благодаря этим событиям, продвижения в сфере безопасности баз данных могут, пожалуй, пойти более быстрыми темпами, чем если бы ничего такого не произошло.
Вопросы компьютерной и коммуникационной безопасности приобрели особый статус в течение последних нескольких лет, после того как Министерство обороны США издало в 1985 г. документ под названием "Критерии оценки надежных компьютерных систем". Этот документ, известный также под названием "Оранжевая книга" (которое соответствует цвету обложки), предлагает стандартизированный подход к оценке компьютерной безопасности на основе иерархической структуры, состоящей из нескольких классов безопасности. Выделяется четыре уровня безопасности, от D (самый низкий уровень защиты) до A, причем уровни C и B подразделяются на несколько классов (от низшего к высшему: C1, C2, B1, B2, B3).
Детальный анализ каждого уровня и класса выходит за рамки рассмотрения этой книги (вероятно, "Оранжевая книга" будет заменена другими правительственными стандартами безопасности). Для нас важно то, что "Оранжевая книга" послужила основой для выработки другого документа Национального центра компьютерной безопасности - Интерпретация "Критериев оценки надежных компьютерных систем" в применении к понятию надежной системы управления базой данных - вышедшего в апреле 1991 г. и известного под сокращенным названием TDI. Роль TDI заключается в том, чтобы придать деятельности, проводимой в русле "Оранжевой книги", дополнительную направленность в плане выработки руководящих принципов и интерпретаций для создания и оценки надежных СУБД. TDI окажет влияние как на современные усилия, так и на направления будущего развития в области безопасности баз данных и информации, которые мы будем обсуждать далее.
В этой главе мы рассмотрим принципы, лежащие в основе безопасности баз данных, а также недавние достижения (с конца 80-х годов), которые могут оказать существенное влияние на развитие этой области в ближайшие несколько лет. Мы обсудим такие вопросы, как многоуровневая защита данных, многозначные реализации (где для каждого кортежа поддерживается несколько вариантов, что позволяет по-разному отражать реальность для различных пользователей), косвенные каналы и их отношение к безопасности баз данных, направления исследований в области безопасности баз данных.
На самом элементарном уровне концепции обеспечения безопасности баз данных исключительно просты. Необходимо поддерживать два фундаментальных принципа: проверку полномочий и проверку подлинности (аутентификацию). Проверка полномочий основана на том, что каждому пользователю или процессу информационной системы соответствует набор действий, которые он может выполнять по отношению к определенным объектам. Проверка подлинности означает достоверное подтверждение того, что пользователь или процесс, пытающийся выполнить санкционированное действие, действительно тот, за кого он себя выдает. Рассмотрим подробнее оба эти понятия.
На рис. 21-1 показана базовая модель проверки полномочий. Теоретически мы могли бы поддерживать матрицу безопасности, устанавливающую отношения между всеми пользователями и процессами системы с одной стороны и всеми объектами с другой. В каждой клетке матрицы хранится список, содержащий от 0 до N операций, которые данный пользователь или процесс может выполнять по отношению к данному объекту. Всемогущая и неуязвимая система управления безопасностью, которая поддерживала бы такую матрицу и обеспечивала бы ее применение при выполнении любой операции в данной среде, могла бы, по-видимому, гарантировать высокий уровень защиты информации (хотя в реальности, как мы увидим, дело обстоит несколько сложнее).
Рисунок 21-1.
Простая модель проверки полномочий.
На рис. 21-2 показано, почему такая базовая модель недостаточна для обеспечения хотя бы минимального уровня безопасности. Если Процессу 2 удастся выдать себя за Процесс 1, то он сможет выполнять действия, разрешенные Процессу 1 (но не Процессу 2). Поэтому очевидно, что необходимы какие-то дополнительные меры, которые мы и обсудим в следующем разделе.
Рис. 21-2.
Необходимость проверки подлинности в дополнение к проверке полномочий.
В силу описанных выше причин в безопасной среде должна присутствовать модель проверки подлинности, которая обеспечивает подтверждение заявленных пользователями или процессами идентификаторов. Проверка полномочий приобрела еще большее значение в условиях массового распространения распределенных вычислений. При существующем высоком уровне связности вычислительных систем необходимо контролировать все обращения к системе.
Проблемы проверки подлинности обычно относят к сфере безопасности коммуникаций и сетей, поэтому мы не будем их здесь более обсуждать, за исключением следующего замечания. В целостной системе компьютерной безопасности, где четкая программа защиты информации обеспечивается за счет взаимодействия соответствующих средств в операционных системах, сетях, базах данных, проверка подлинности имеет прямое отношение к безопасности баз данных. Многие механизмы защиты баз данных, обсуждаемые в этой главе, непосредственно зависят от наличия надежных средств проверки подлинности.
Заметим, что модель безопасности, основанная на базовых механизмах проверки полномочий и проверки подлинности, не решает таких проблем, как украденные пользовательские идентификаторы и пароли или злонамеренные действия некоторых пользователей, обладающих полномочиями, - например, когда программист, работающий над учетной системой, имеющей полный доступ к учетной базе данных, встраивает в код программы Троянского коня с целью хищения средств или с другими подобными умыслами. Такие вопросы выходят за рамки нашего обсуждения развития средств защиты баз данных, но следует тем не менее представлять себе, что программа обеспечения информационной безопасности должна охватывать не только технические области (такие как защита сетей, баз данных и операционных систем), но и проблемы физической защиты, надежности персонала (скрытые проверки), аудит, различные процедуры поддержки безопасности, выполняемые вручную или частично автоматизированные. Даже если бы все средства, которые мы будем обсуждать в этой главе, были легко осуществимы, потенциальные проблемы все равно остаются, если программа безопасности неполна.
Сочетание средств проверки полномочий и проверки подлинности - мощное орудие борьбы за безопасность информационных систем и баз данных. Если все пользователи, работающие в интерактивном режиме или запускающие пакетные приложения, достаточно надежны и имеют доступ к максимально закрытой информации, хранимой в системе, то упомянутый подход к обеспечению безопасности может быть вполне достаточным. Например, если в системе хранится информация, классифицированная по уровням от полностью открытой до совершенно секретной (чуть ниже мы рассмотрим понятие уровней защиты данных), но все пользователи системы имеют доступ к самым секретным данным, то в такой системе достаточно иметь надежные механизмы проверки полномочий и проверки подлинности. Такая модель называется "работой на высшем уровне (секретности)" (running at system high).
Однако она оказывается неудовлетворительной, если в учреждении необходимо организовать действительно многоуровневую среду защиты информации. Многоуровневая защита означает, что (1) в вычислительной системе хранится информация, относящаяся к разным классам секретности; (2) часть пользователей не имеют доступа к максимально секретному классу информации3). Классический пример подобной среды - вычислительная система военного учреждения, где в логически единой базе данных (централизованной или распределенной) может содержаться информация от полностью открытой до совершенно секретной, при этом степень благонадежности пользователей также варьируется от допуска только к несекретной информации до допуска к совершенно секретным данным. Таким образом, пользователь, имеющий низший статус благонадежности, может выполнять свою работу в системе, содержащей сверхсекретную информацию, но ни при каких обстоятельствах не должен быть допущен к ней.
Многоуровневая защита баз данных строится обычно на основе модели Белл-ЛаПадула (Bell-LaPadula), которая предназначена для управления субъектами, т. е. активными процессами, запрашивающими доступ к информации, и объектами, т. е. файлами, представлениями, записями, полями или другими сущностями данной информационной модели4).
Объекты подвергаются классификации, а субъекты причисляются к одному из уровней благонадежности (clearanсe). Классы и уровни благонадежности называются классами доступа или уровнями5).
Класс доступа характеризуется двумя компонентами. Первый компонент определяет иерархическое положение класса. Второй компонент представляет собой множество элементов из неиерархического набора категорий, которые могут относиться к любому уровню иерархии. Так, в военных ведомствах США применяется следующая иерархия классов (сверху вниз):
Второй компонент может относиться, например, к набору категорий:
В частной компании возможны такие уровни иерархии:
Второй компонент в такой компании мог бы принадлежать к набору категорий:
Очевидно, что можно определить матрицу соотношений между иерархическими и неиерархическими компонентами. Например, если некоторый объект классифицирован как совершенно секретный, но ему не приписана ни одна из категорий неиерархического набора, то он может предоставляться иностранным правительствам, в то время как менее секретный объект может иметь категорию "недоступно для иностранных правительств" и, следовательно, не должен им предоставляться. Однако в модели Белл-ЛаПадула создается "решетка", где неирархические компоненты каждого уровня иерархии автоматически приписываются и всем более высоким уровням (так называемое "обратное наследование"). Эта модель отображена на рис. 21-3.
Рис. 21-3.
Решетка классов доступа в модели Белл-ЛаПадула.
До сих пор наше обсуждение касалось вполне очевидных понятий. Из него следует, что субъект класса CL1 имеет доступ к объектам класса CL2, если CL2 не выше CL1. Например, пользователь класса "совершенно секретно", имеет доступ к информации классов "совершенно секретно", "секретно", "конфиденциально", "несекретно". В модели Белл-ЛаПадула этот принцип известен под названием простого свойства секретности (simple security property)6).
Менее очевидно другое свойство, обозначаемое символом *7), которое позволяет субъекту иметь право на запись в объект только в том случае, если класс субъекта такой же или ниже, чем класс записываемого объекта. Это означает, что информация, принадлежащая какому-либо уровню секретности, никогда не может быть записана в какой-либо объект, имеющий более низкий уровень секретности, поскольку это могло бы привести по неосторожности к деградации защиты классифицированной информации.
С учетом двух принятых в модели Белл-ЛаПадула ограничений (простое свойство секретности и *-свойство) можно представить себе базу данных с многоуровневой защитой так, как показано на рис. 21-4. Заметим, что субъект 1, пользователь или процесс, имеющий высший уровень благонадежности, может читать информацию всех кортежей, но в силу *-свойства он может записать данные только в кортеж наивысшей классификации (субъект может записывать информацию только "вверх по иерархии", но не "вниз по иерархии"). Субъект 2, принадлежащий к классу "секретно", не может прочитать "самую секретную" строку, но может прочитать две остальные. В то же время, субъекту 2 разрешена запись в строку класса "секретно" и в строку класса "совершенно секретно" (запись "вверх")8).
Рис. 21-4.
Пример применения правил доступа Белл-ЛаПадула.
Как и в большинстве областей вычислительных средств и информационного управления и, в особенности, в области безопасности, приведенная выше простая модель в реальности представляет не слишком большую ценность, подобно упрощенным моделям проверки полномочий и подлинности, которые мы обсуждали в разд. 21.2. Хотя принципы Белл-ЛаПадула сами по себе вполне здравые, но требование поддержки нескольких уровней защиты в пределах одной таблицы (или в одной базе данных) сопряжено с рядом серьезных проблем. Рассмотрим, например, следующие ситуации.
Сотрудник военного ведомства, чьи персональные данные хранятся в базе данных с многоуровневой защитой, может иметь "настоящую" миссию, например быть сотрудником отдела по борьбе с терроризмом, и в то же время некоторое "прикрытие", согласно которому он является, допустим, членом отряда десантников. При этом в базе данных должна быть представлена и реальная информация, и прикрытие.
Сержант оказывается в действительности майором контрразведки; или разжалованный и с позором уволенный ветеран на самом деле является глубоко засекреченным государственным агентом, причем в чине полковника (такие истории все мы не раз видели в кино).
Настоящее имя суперсекретного правительственного эксперта по борьбе с терроризмом классифицировано как сверхсекретная информация; его официальный статус - почтовый служащий на пенсии.
Мы могли бы расширить представленную на рис. 21-4 модель, добавив свойство секретности не только для каждой строки, но и на уровне элементов, т. е. для каждого столбца (значение каждого столбца внутри каждой строки имеет свою классификацию). Но это расширение приведет к новым серьезным проблемам, поскольку каждый столбец в строке может принимать одно из нескольких возможных значений, в зависимости от обозреваемой классификации (рис. 21-5). Такое положение дел на фундаментальном уровне нарушает требование первой нормальной формы (множественные значения, рассматриваемые как нечто вроде повторяемых групп), т. е. один из важнейших принципов реляционных баз данных. Следовательно, необходимо каким-то образом решить эту проблему. В следующем разделе мы рассмотрим такое решение, а именно многозначные кортежи.
Рис. 21-5.
Поэлементная классификация и возникающие в связи с этим проблемы.
Наше решение проблемы поэлементной классификации, упомянутой в предыдущем разделе, основано на идее многозначности, когда в рамках одного отношения может существовать множество кортежей с одним и тем же значением первичного ключа 9).
На рис. 21-6 показан пример многозначного отношения, где для сотрудников военного учреждения указаны наряду с их реальными званиями и видами деятельности также фальшивые данные для прикрытия. На рис. 21-7 показано применение двух правил Белл-ЛаПадула в многозначной базе данных.
Рис. 21-6.
Многозначность.
Многозначность впервые была применена в 1988 г. в модели безопасной базы данных SeaView (Secure Data Views10)). За прошедшие с тех пор годы в этом направлении были проведены значительные исследования и написано немало работ, авторами многих из которых являются Сушил Джаджодия (Sushil Jajodia) и Рави Сандху (Ravi Sandhu) из Мейсоновского Университета.
Одно из направлений исследований - проблема многозначной целостности, возникшая в СУБД SeaView в связи с введением многозначности. Если не входить в детали, то правила многозначной целостности в SeaView включают функциональный и многозначный компоненты и сужают набор допустимых вариантов многозначного кортежа до подмножества вариантов, удовлетворяющих ограничениям многозначной целостности. Поскольку, по мнению некоторых специалистов, принятые в SeaView правила слишком ограничительны, то в статье "Polyinstantiation Integrity in Multilevel Relations"11) ("Целостность многозначности в многоуровневых отношениях") были предложены способы ослабления данной модели целостности. В этой статье описаны различные типы многозначных кортежей и сценарии, при помощи которых база данных должна поддерживать каждый экземпляр кортежа. В статье также предлагается удалить из модели многозначной целостности ту часть, которая касается многозначных зависимостей12).
Рис. 21-7.
Многозначность и свойства Белл-ЛаПадула.
Так в чем же, собственно, состоит суть идеи многозначности? Даже если отвлечься от проблемы хранения в базе данных разного рода легенд и прикрытий, многозначность все равно должна стать неотъемлемым свойством баз данных с многоуровневой защитой. Для того чтобы прояснить причины этого и перейти к обсуждению нашей следующей темы - косвенных каналов - рассмотрим следующую ситуацию.
В отсутствие многозначности отношение с многоуровневой защитой, показанное на рис. 21-8(a), следовало бы обрабатывать следующим образом. База данных может маскировать значения, недоступные пользователю или процессу по соображениям безопасности, и такое маскирование обычно осуществляется при помощи пустых значений (null values, рис. 21-8(b)).
Рис. 21-8.
Маскированные представления данных с целью обеспечения секретности.
Напомним, что каждый кортеж существует в единственном экземпляре, поэтому непривилегированный процесс может попытаться записать неклассифицированные данные в столбцы кортежа, содержащие как бы пустые значения (рис. 21-9). В связи с этим в СУБД с многоуровневой защитой возникает проблема обработки таких операций, поскольку на самом деле значение столбца непустое, и замещать его нельзя. Естественно, что подобные попытки должны отвергаться средствами системы безопасности.
Рис. 21-9.
Попытка модификации маскированных объектов.
Однако неудача при выполнении операции модификации открывает определенные возможности, получившие название косвенных каналов (для получения закрытой информации), т. е. пути для снижения классификации данных (преднамеренного или случайного, что будет обсуждаться далее)13). Отказ в выполнении вполне вроде бы законной транзакции на модификацию пустых значений в базе данных с многоуровневой защитой выдает информацию о том, что эти элементы на самом деле не пусты, а содержат классифицированные данные. Уведомляя не наделенного соответствующими полномочиями пользователя или процесс о наличии в том или ином кортеже классифицированных данных, мы открываем тем самым косвенный канал.
Допустим, что СУБД с многоуровневой защитой симулирует выполнение подобных модификаций, чтобы не раскрывать скрытый канал. Но что будет, если пользователь, только что изменивший некоторые данные, попытается выполнить запрос или приложение, которое обращается к этим данным, а ему ответят, что они отсутствуют? Значит, мы опять создаем косвенный канал.
А что если попытаться поддерживать в СУБД с многоуровневой защитой нечто вроде журнала таких модификаций и использовать его для последующих выборок? Знакомая идея, и неудивительно - ведь мы только что говорили о многозначности. Даже если мы предусмотрим какое-нибудь специфическое решение для реализации многозначности, например хранить два экземпляра кортежей, - это всего лишь одна из реализаций. Важно, что многозначность - это существенное свойство данных с многоуровневой защитой14), а как она будет реализована - это вопрос второстепенный, не имеющий отношения к самой идее по-разному представлять информацию для пользователей разных уровней благонадежности; хотя способы реализации многозначности остаются важным направлением для исследовательской работы.
Рассматривая проблему реализации многозначности, полезно обратить внимание на концептуальное сходство между многозначными кортежами в базе данных с многоуровневой защитой и кортежами с множественными значениями в хронологических базах данных (гл. 15). Напомним, что в большинстве реляционных баз данных с расширениями для поддержки хронологизма должны существовать несколько экземпляров одного кортежа с одним и тем же значением первичного ключа, чтобы обеспечить отображение и текущего состояния объекта, и исторической информации о нем. В реляционной СУБД с расширениями для поддержки многоуровневой защиты по существу присутствует такой же тип представления с той разницей, что определяющим признаком экземпляров некоторого кортежа в хронологической базе данных является время, а в базе данных с многоуровневой защитой - класс доступа. Хотя с других точек зрения, помимо реализации многозначности, хронологические СУБД и СУБД с многоуровневой защитой имеют мало общего, в связи с коммерциализацией СУБД обоих типов может оказаться полезным применять в них общие алгоритмы представления и доступа к многозначным кортежам.
Итак, многозначность, примененная впервые в проекте SeaView, стала общепринятой моделью реализации баз данных с многоуровневой защитой, в особенности реляционных. Многозначность активно исследуется и в качестве механизма обеспечения безопасности в объектно-ориентированных базах данных (развитие средств защиты в СУБД этого типа пока еще значительно отстает по сравнению с реляционными СУБД, но их значение будет неуклонно расти вместе со стремлением позиционировать ООСУБД на рынке продуктов для коммерческих и правительственных организаций).
Мы не будем здесь рассматривать все нюансы понятия многозначности, отослав заинтересованного читателя к ссылкам в конце этой главы. Отметим лишь, что направления будущего развития средств безопасности СУБД тесно связаны с моделями многоуровневой защиты, в которых, в силу проблемы косвенных каналов, важную роль будет играть реализация многозначности.
В определениях высших уровней безопасности компьютерных систем и баз данных по классификации "Оранжевой книги" проблеме косвенных каналов уделяется важное значение. Косвенный канал - это механизм, посредством которого субъект, обладающий высоким уровнем благонадежности, может предоставлять информацию менее благонадежным субъектам15). Согласно *-свойству модели Белл-ЛаПадула, непосредственная запись информации в объекты более низкого класса секретности запрещена, и косвенные каналы обычно реализуются при помощи непрямых способов передачи информации.
"Оранжевая книга" идентифицирует два типа косвенных каналов16):
1) косвенные каналы памяти;
косвенные каналы времени.
Хотя для баз данных более характерны косвенные каналы памяти17), косвенные каналы времени также нельзя сбрасывать со счетов. Мы рассмотрим примеры обоих типов.
Косвенный канал памяти открывается, когда некоторая область памяти, например содержащая объект базы данных, прямо или косвенно используется как средство раскрытия классифицированных материалов. В предыдущем разделе мы уже рассматривали пути возникновения косвенных каналов памяти. Без соблюдения *-свойства Белл-ЛаПадула классифицированные данные легко могли бы быть скомпрометированы путем явной записи, скажем посредством Троянского коня, сверхсекретных данных в область, относящуюся к низшему классу секретности, откуда ее потом может прочитать менее благонадежный пользователь или процесс.
Но и при соблюдении *-свойства Белл-ЛаПадула информация может быть скомпрометирована косвенными способами, опять же при посредстве Троянского коня. Пример на рис. 21-8 показывает ситуацию, когда в условиях отсутствия многозначности для скрытия секретной информации от недостаточно благонадежных процессов используются пустые значения. Мы говорили о том, что отказ, полученный низкоуровневым процессом при попытке модифицировать эти как бы пустые значения, открывает косвенный канал, поскольку тем самым предоставляется информация о наличии секретных данных, маскируемых пустыми значениями (хотя содержание информации при этом не раскрывается). Однако при той же модели, путем кооперирования встроенного Троянского коня с низкоуровневым процессом, можно организовать передачу реальной классифицированной информации при помощи некоторого сигнального механизма. Троянский конь может открыть транзакцию, создать фиктивную таблицу известной структуры, заполнив ее фиктивными классифицированными данными и установив маски пустых значений. Низкоуровневый процесс затем мог бы в определенное время предпринять серию модификаций по отношению к этой таблице, интерпретируя коды результатов успешного или неуспешного завершения по отношению к выбранным строкам в соответствии с установленным кодом. Код может быть просто последовательностью бит ASCII-кодировки интересующих секретных данных. Например, для каждой восьмерки строк в таблице коды результата модификации будут интерпретироваться как 8-битный код одного символа. Могут применяться и более сложные коды. Закончив передачу данных по такому косвенному каналу, высокоприоритетный процесс может затем уничтожить (DROP) таблицу.
Описанный выше канал вполне может быть обнаружен (в журналах базы данных будут зафиксированы спорадические создания и уничтожения таблиц, хотя это и не всегда просто выявить в активно работающей базе данных); но существуют и другие аналогичные способы, использующие уже имеющиеся таблицы. Поэтому политика безопасности организации должна учитывать подобные факторы.
Мы говорили уже, что и косвенные каналы времени до некоторой степени имеют отношение к базам данных. При помощи неклассифицированного или низкоуровневого процесса сетевого анализа можно наблюдать закономерности трафика и времена отклика для всех системных операций. Отметив, сколько времени занимает передача несекретных данных известного объема (например списка личного состава), и сравнивая эти данные с временем передачи классифицированной информации, можно оценить объем передаваемых секретных данных. Но даже и не имея данных о передаче несекретных данных, которые можно использовать для сравнения, и о структуре передаваемых секретных сведений, но зная пропускную способность сети, протоколы (для определения накладных расходов) и другие характеристики сети, можно анализировать секретные передачи для оценки объемов данных. Сравнивая наблюдения за некоторый период, можно обнаружить те или иные тенденции. Например, если известно о том, что в некоторое иностранное государство периодически пересылается список засекреченного персонала или оборудования и время пересылки за период наблюдения возросло вдвое, то можно сделать вывод о том, что удвоилось и количество представляющего интерес персонала и оборудования, следовательно, можно сделать вывод о подготовке каких-либо акций в данном регионе.
Косвенные каналы времени обычно исключаются за счет соответствующих решений в сфере коммуникаций, например за счет заполняющего трафика (traffic padding), позволяющего замаскировать истинные объемы передаваемой информации. Т. е. косвенные каналы времени - это, прежде всего, вопрос коммуникаций. Но по мере того, как растет степень распределенности баз данных и возрастает значение мер безопасности, в надежной среде баз данных эти вопросы должны рассматриваться наряду с проблемами косвенных каналов памяти.
Ниже приведен еще один пример косвенного канала18). Поскольку высокоуровневым процессам разрешено читать данные из объектов низкой классификации, может возникнуть следующая ситуация. Предположим, что высокоуровневый процесс посылает следующий SQL-запрос удаленной низкоуровневой СУБД:
SELECT name, rank, date_of_birth FROM roster WHERE duty_building=445
Возможно, это всего-навсего безобидный запрос на сведения обо всех сотрудниках, работающих в здании номер 445, но это может быть и запрос, сгенерированный Троянским конем, в котором в явном виде содержится секретная информация. Возможно, это сообщение о том, что 445 танков или вооруженных лиц пересылаются в определенный район для выполнения секретной миссии. Или число 445 имеет еще какой-то скрытый смысл (возможно, интерпретируемый при посредстве механизмов дешифрования, с помощью битовой маски и т. п.). Эта проблема исключительно важна, и она подводит нас к еще одной теме - безопасность среды распределенной базы данных. Все вопросы и направления исследований, которые мы рассматривали до сих пор, относились к базам данных вообще. Свойство распределенности баз данных привносит дополнительные проблемы и угрозы безопасности. Состояние дел в области безопасности распределенных баз данных значительно отстает по сравнению с положением для централизованных СУБД. Тем не менее на решение этих вопросов в настоящее время направлены значительные исследовательские усилия.
Если в области баз данных с многоуровневой защитой уже в значительной степени устоялись по крайней мере основные концепции (например признана необходимость многозначности), хотя конкретные реализации еще значительно отстают, то исследования в сфере безопасности распределенных СУБД существенно уступают в отношении зрелости.
Истоки исследований безопасных РаБД относятся к 1982 г., к проекту Woods Hole американских ВВС, в котором были определены две альтернативные архитектуры распределенных СУБД19). Общей чертой обеих было наличие надежного компонента переднего плана, который мог подключаться к двум физически раздельным СУБД. В одной из архитектур (показанной на рис. 21-10) одна база данных содержит высокосекретные данные, другая - данные низкой секретности. Компонент переднего плана соответствующим образом направляет выполнение операций (в том числе запросов) над базой данных. Запросы на доступ к высокосекретной информации от процессов и пользователей с необходимым уровнем благонадежности направляются на СУБД высокого уровня, а многоуровневые запросы подвергаются декомпозиции и соответствующим образом распределяются.
Рис. 21-10.
Архитектура безопасной распределенной СУБД с раздельными компонентами
заднего плана.
Такая архитектура, впрочем, не имеет отношения к базам данных с многоуровневой защитой и к достигнутым в этой области результатам. Хотя распределенные приложения обрабатывались посредством надежного компонента переднего плана и имели дело с единой глобальной схемой (как обсуждалось в гл. 2), но принцип автономного выполнения локальных приложений по отношению к локальной базе данных (также обсуждавшийся в гл. 2) нарушается по крайней мере для многоуровневых приложений (например, в случае нераспределенной, но многоуровневой обработки все равно нельзя иметь дело только с одной локальной СУБД с многоуровневой защитой).
Альтернативная архитектура, изображенная на рис. 21-11, несколько сложнее и предусматривает наличие нескольких уровней в пределах одной СУБД, хотя ее и нельзя назвать истинно многоуровневой. Операции низкого уровня обрабатываются так же, как в первой архитектуре. Но операции высокого уровня и многоуровневые операции обрабатываются СУБД, на которой хранятся высокосекретные данные и копии данных низших степеней секретности. Отметим, что такая архитектура подразумевает использование средств тиражирования, подобных тем, которые обсуждались в гл. 2; следовательно, в ней должны присутствовать менеджеры тиражирования и необходимы соответствующие политики обеспечения целостности данных.
Рис. 21-11.
Архитектура безопасной распределенной СУБД с псевдомногоуровневым компонентом
заднего плана.
В середине 80-х началась работа по расширению предложенных в 1982 г. рекомендаций и выработке новых спецификаций РаСУБД с многоуровневой защитой, спонсором которой был центр Rome Air Development Center (RADC) ВВС США20). Этот проект, получивший название SD-DBMS, не предусматривал реализацию распределенной СУБД в классическом понимании этого термина (т. е. со средствами вертикальной и горизонтальной фрагментации кортежей по организационным соображениям или в соответствии с оценками затрат на сетевые пересылки); распределение использовалось в нем как инструмент для организации принудительного управления доступом (MAC - mandatory access control21)). SD-DBMS предназначалась для выполнения в локальной сети с многоуровневой защитой.
SD-DBMS следует базовой модели Белл-ЛаПадула (т. е. с определением классов доступа, включающим иерархический и неиерархические компоненты, с понятиями субъектов и объектов и т. п.). Система обеспечивает добровольное управление доступом (DAC - discretionary access control) посредством представлений доступа (access views) или виртуальных отношений, производных от базовых отношений и подобных традиционным SQL-представлениям. Субъектам (пользователям и процессам) не разрешается обращаться непосредственно к базовым отношениям, они имеют доступ к данным только через посредство представлений с контролируемым доступом22).
Обратите внимание на сходство между этим механизмом контролируемого посредством представлений доступа и механизмом, введенным в стандарте SQL-92 для управления метаданными при помощи оператора INFORMATION_SCHEMA (см. разд. 12.3.2), где доступ к метаданным допускается только через представления, а не непосредственно из таблиц.
Добровольное управление доступом осуществляется при помощи списков управления доступом (ACL - access control list), где задаются допустимые над данным представлением операции с указанием идентификаторов пользователей или групп. Принудительное управление доступом, MAC, обеспечивается путем ассоциирования класса доступа с каждым кортежем базового отношения. Производное отношение, т. е. отношение, полученное в результате применения к существующим представлениям реляционных операций, состоит из производных кортежей, которые подвергаются MAC-разметке23). Процедуры разметки - предмет интенсивных исследований. Для управления производными кортежами необходимы соответствующие алгоритмы24).
Архитектура SD-DBMS была также основана на физически разделенных компонентах заднего плана, по одному на каждый класс доступа (рис. 21-12). Каждое вновь создаваемое многоуровневое отношение разбивается на одноуровневые фрагменты, хранимые на разных узлах заднего плана в соответствии со своим классом безопасности25).
Были также предложены различные альтернативные политики и архитектуры, направленные на решение проблем, свойственных SD-DBMS, таких как, например, необходимость кодирования данных, содержащихся непосредственно в запросах пользователей, работающих с данными высших классов секретности (с целью перекрытия косвенных каналов, о которых говорилось в предыдущем разделе)26).
Рис. 21-12.
Архитектура SD-DBMS27)
Работы в области безопасных распределенных баз данных продолжаются в таких направлениях, как создание архитектур, обеспечивающих поддержку и локальной, и глобальной многоуровневой обработки. Еще одна область исследований - безопасность неоднородных систем мультибаз данных. Степень применимости мощных средств многоуровневой защиты данных к корпоративным окружениям мультибаз данных до сих пор не ясна, поскольку в этой сфере еще слишком много сложных нерешенных проблем (см. гл. 6 и 7).
Может случиться так, что в корпорации будут существовать островки безопасной обработки, включающие безопасные базы данных и информационные менеджеры, отделенные от каких бы то ни было грандиозных планов всеобщей интеграции (рис. 21-13). Пользователь соответствующего класса благонадежности может иметь доступ к среде безопасной обработки, возможно, включающей защищенную РаСУБД, находящуюся за рамками программы интеграции корпоративной информационной среды, независимо от реализации, уровня прозрачности и других аспектов организации мультибаз данных.
Рис. 21-13.
Возможная архитектура с поддержкой сосуществования мультибаз данных
и безопасных баз данных.
В гл. 15 мы обсуждали расширения языка SQL для поддержки хронологических баз данных, но отметили, что ни стандарт SQL-92, ни текущая версия стандарта SQL3 не поддерживают эти средства. То же можно сказать и об языковых расширениях для поддержки баз данных с многоуровневой защитой.
Важно отметить, что, хотя в SQL предусмотрены операторы поддержки безопасности (например операторы GRANT и REVOKE), но они не обеспечивают многоуровневой защиты (и следовательно, принудительного управления доступом, MAC). Возможность предоставлять (GRANT) привилегии доступа и модификации по отношению к определенным объектам и передавать другим пользователям права на предоставление привилегий (конструкция WITH GRANT OPTION), а также отбирать (REVOKE) права (предоставленные непосредственно или в результате использования опции WITH GRANT OPTION) - все это средства поддержки добровольного управления доступом (DAC). Даже несмотря на то, что модель безопасности в SQL-92 проработана значительно тщательнее, чем в предыдущих версиях (отметим, впрочем, что многие коммерческие реляционные SQL-ориентированные СУБД имели собственные расширения для поддержки безопасности даже и до выхода SQL-92), но все эти возможности все равно недостаточны для обеспечения безопасности баз данных не только в будущем, но и в настоящем.
В ожидаемых коммерческих версиях СУБД с многоуровневой защитой, вероятно, будут присутствовать определенные языковые расширения. Пример исследовательского прототипа такого расширенного языка - MSQL (multilevel SQL), язык СУБД SeaView28). MSQL содержит операторы DDL со средствами спецификации классов безопасности29):
create relation roster (
name char (30) [U:S]
primary-key,
rank char (10) [U:S],
job_code char (10)
[U:TS],
duty_location char (20) [U:TS],
...
)
MSQL допускает составные первичные ключи, как в следующем примере:
create relation roater (
group (last_name char (20),
first_name char (10),
middle_initial char (1) )
[U:TS] primary-key,
...
)
Спецификация классов защиты для атрибута может задаваться не только в виде диапазона, как в предыдущих примерах, но и путем перечисления:
create relation missions (
...
task char (30) [S; TS
NUCLEAR; TS INTEL],
...
)
В этом примере столбец TASK может содержать значения класса "секретно", "совершенно секретно/ядерное оружие", "совершенно секретно/разведка".
MSQL допускает задание классификационных ограничений, концептуально подобных ограничениям целостности SQL:
create class-constraint
JOBCodeRules
on roster as
name.class = SECRET,
rank.class = SECRET,
mission.class =
(if roster.mission = "COUNTERINTELLIGENCE" then
TOP SECRET else SECRET)
Отметим, что элемент метаданных класс должен быть обязательно определен для всех атрибутов.
MSQL включает функции типа HIGHEST-CLASS для обработки многозначной классифицированной информации (которая позволяет, например, при помощи оператора SELECT выбрать строки максимальной секретности, соответствующей благонадежности данного пользователя или процесса).
Хотя SQL3 в настоящее время не содержит команд MLS (multilevel security), и эти средства, вероятно, будут предоставляться в виде специфических для конкретных продуктов расширений, мы можем тем не менее высказать некоторые предположения относительно языковых расширений MLS.
SQL, по-видимому, предоставит основу для языковых расширений обеспечения безопасности, хотя нетрадиционные операторы, подобные принятым в MSQL (CREATE RELATION вместо CREATE TABLE), скорее всего, приблизятся к синтаксису стандартных операторов SQL.
Когда реализации многозначности вместе с поддержкой многоуровневой защиты войдут в коммерческие версии СУБД, будут приняты и соответствующие языковые расширения, причем не только в виде конструкций языка определения данных (DDL), но и в виде новых функций типа HIGHEST-CLASS. Примеры - функции HIGHEST-COVER-STORY и LOWEST-COVER-STORY, возвращающие "легенды" агента, соответственно максимального и минимального классов секретности.
По мере проникновения концепций безопасности СУБД в ООСУБД, в языки ODMG, которые обсуждались в гл. 13 (OQL, OML и ODL), будут включаться специальные расширения для поддержки многоуровневой защиты, подобные соответствующим расширениям SQL. Разумеется, сначала поставщикам придется реализовать в своих продуктах исходные версии языков ODMG, что может занять несколько лет. Пользователи ООСУБД, заинтересованные в средствах многоуровневой защиты, могут повлиять на поставщиков и на процесс стандартизации в отношении языковых средств безопасных ООСУБД.
Перейдем теперь от реляционных СУБД к проблемам безопасности в объектно-ориентированных базах данных. По мере того как продукты ООСУБД приобретают зрелость, и их применение выходит за рамки масштабов небольшого подразделения, при том что значение безопасности информационного управления постоянно возрастает, будет расширяться и роль безопасных ООСУБД и ООБД. В этом разделе мы обсудим направления развития безопасных ООСУБД.
В отношении безопасности ООСУБД можно высказать два самых общих суждения.
Уровень развития средств безопасности в ООСУБД существенно ниже, чем в реляционных СУБД, но, в основном, в силу относительной "молодости" объектно-ориентированных технологий.
Принципы многоуровневой защиты, разработанные для реляционных баз данных, такие как многозначность и модель Белл-ЛаПадула, нашли отражение и в безопасных системах ООБД.
Объектно-ориентированным аналогом СУБД SeaView является система SODA (Secure Object-oriented DAtabase). В SODA применяется политика безопасности Белл-ЛаПадула и стратегия присваивания меток безопасности для классификации объектов30). В SODA поддерживается два различных типа меток.
1) Метки переменных-компонентов объектов. Каждой переменной может быть присвоена независимая метка, соответствующая диапазону классификации; это аналогично классификации на уровне элементов кортежей, когда каждый столбец отношения имеет собственный допустимый диапазон классификации, а элемент кортежа - индивидуальную классификацию, независимую от других элементов.
2) Метки объектов. Аналогичны классификации кортежей (один общий класс для всего кортежа или объекта).
В связи с классификацией составных или несоставных объектов в ООСУБД возникает ряд проблем. Существует набор правил (предложенный Б. Тхурейзингхэмом), при помощи которого можно управлять уровнями защиты экземпляров, объектов и отношениями между экземплярами и объектами обоих типов31).
Поскольку для ООБД, в отличие от реляционных баз данных, отсутствует достаточная стандартизация терминологии и моделей (хотя стандарт ODMG-93, вероятно, поправит ситуацию), то исследования в области безопасности ООБД, как правило, проводятся в отношении несколько различающихся моделей. Как уже отмечалось, большинство принципов безопасности реляционных баз данных находят отражение в ООБД, и сближение ООБД со стандартом ODMG создаст основу для коммерциализации безопасных ООСУБД.
Так каково же нынешнее положение дел с безопасностью баз данных? Хотя в этой области немало было сделано за последние годы, в особенности в отношении многоуровневой защиты (четкое выделение понятия многозначности, выработка соответствующих методик и их уточнение), однако факт остается фактом - коммерческие реализации все еще значительно отстают от исследовательских результатов. Как отметил Сушил Джаджодиа, "относительно несложно обеспечить безопасность на 99%; но последний 1% может не только обойтись слишком дорого, но и оказаться недостижимым"32).
Сегодня лишь небольшое число СУБД проходят сертификацию на причисление к классу безопасности B1. Это говорит о том, что многие вопросы, например, исключение косвенных каналов, еще не нашли адекватного решения в предлагаемых СУБД. Политики принудительного управления доступом (MAC) еще только начинают внедряться в коммерческие продукты.
Однако путь, который нам предстоит пройти, простирается значительно дальше. Тереза Лунт указывает на следующие проблемы, которые дают представление о том, какими возможностями должны обладать безопасные базы данных будущего33).
Определение семантики операций для баз данных с многоуровневой защитой. Это означает, что следует точно определить, какие действия произведет, например, операция DELETE или UPDATE над всеми затрагиваемыми ею объектами. Необходимо расширить определение семантики операций в условиях многозначности, доведя его до уровня, приемлемого для реализации в коммерческих СУБД. Автор хотел бы также подчеркнуть значение стандартизации подобных определений - важно, чтобы оператор DELETE выполнялся одинаково в любой СУБД с многоуровневой защитой.
Распространение концепции многоуровневой защиты на другие модели и на распределенные базы данных. Мы обсудили этот вопрос в отношении ООБД и распределенных баз данных. Исследования охватывают также модели сущность-связь и дедуктивные базы данных, хотя коммерческий потенциал этих исследований менее значителен.
Предотвращение нежелательных выводов. Проблема вывода возникает, когда из совокупности фактов, относящихся к классу секретности C1, можно вывести полную или частичную информацию, имеющую более высокий класс секретности. Рассмотрим, например, следующие факты вместе с их классами секретности.
"Капитан Смит - разведчик" - СЕКРЕТНО.
"Капитан Смит отбывает завтра в {название_страны}" - КОНФИДЕНЦИАЛЬНО.
"Капитан Смит улетает рейсом 1:45 ночи" - КОНФИДЕНЦИАЛЬНО.
"Капитан Смит возвратился из отпуска раньше срока" - НЕСЕКРЕТНО.
Собрав все эти сведения воедино, получаем следующее: "Капитан Смит, разведчик, возвратился из отпуска раньше срока, чтобы в 1:45 отбыть в... (страна неизвестна) - скорее всего, для проведения какой-либо разведывательной операции". Выведенная таким образом информация может иметь очень высокий класс секретности, возможно, СОВЕРШЕННО СЕКРЕТНО, т. е. она более секретная, чем любой из исходных фактов. Как замечает Т. Лунт, в области изучения способов вывода в условиях многоуровневой защиты не получено пока ни формальных, ни количественных результатов, за исключением отдельных частных решений.
Инструменты для проектирования и разработки баз данных с многоуровневой защитой. Рассмотрим диаграмму сущность-связь на рис. 21-14. Поскольку элементы и кортежи реляционной базы данных, а также атрибуты и экземпляры объектов в ООБД могут принадлежать к разным классам секретности, то разумно было бы потребовать, чтобы инструмент для моделирования структур баз данных с многоуровневой защитой содержал средства для поддержки классификации. Модель сущность-связь (или любая другая) с расширениями безопасности должна иметь соответствующим образом расширенный язык определения данных (DDL), подобный языку MSQL, обсуждавшемуся в разд. 21.7.
Рис. 21-14.
CASE-инструмент для моделирования отношений сущность-связь с поддержкой
средств безопасности.
Еще одна область, в которую следует ожидать проникновения концепций безопасности, - это высокопроизводительные базы данных, включая параллельные (см. гл. 3) и многоуровневые дедуктивные базы данных34).
В заключение хотелось бы отметить, что средства безопасности баз данных, несомненно, будут активно развиваться, просто в силу необходимости. Мы живем в опасном мире, не только в "географическом" плане, но и в отношении коммерческих интересов. Промышленный шпионаж постоянно усиливается, и защита корпоративной информации становится все более настоятельной потребностью.
Мы не можем лишь предсказать, до какой степени в действительности будут развиты средства безопасности. Тот самый "последний 1%", о котором говорит Сушил Джаджодиа, может оказаться непреодолимым препятствием для достижения стопроцентной защиты. Тем не менее достижения ближайшего будущего и их внедрение в коммерческие продукты обеспечит нам значительно более высокий уровень безопасности, чем мы имеем сегодня - возможно, достаточный для защиты от всех угроз, за исключением действий исключительно высококвалифицированных злоумышленников.
S. Jajodia and R. Sandhu. Polyinstantiation Integrity in Multilevel Relations. - Proceedings of the 1990 IEEE Computer Soсiety Symposium on Research in Security and Privacy.
S. Jajodia and R. Sandhu. Toward a Multilevel Secure Relational Data Model. - Proceedings of ACM SIGMOD 1991.
T.F. Lunt, ed., Research Directions in Database Security. - New York: Springer-Verlag, 1992.
National Research Council. Computer at Risk: Safe Computing in the Information Age. - Washington, D.C.: National Academy Press, 1991.
1. S. Jajodia. Частные обсуждения. Май 1993.
2. S. Jajodia. Частные обсуждения.
3. T.F. Lunt. Security in Database Systems: A Research Perspective. - Computers and Security, March 1992, 41.
4. S. Jajodia and R. Sandhu. Toward a Multilevel Secure Relational Data Model, 51.
5. S. Jajodia and R. Sandhu. Toward a Multilevel Secure Relational Data Model.
6. S. Jajodia and R. Sandhu. Toward a Multilevel Secure Relational Data Model.
7. S. Jajodia and R. Sandhu. Toward a Multilevel Secure Relational Data Model.
8. Может показаться не вполне понятным, почему пользователь, имеющий доступ к информации класса "секретно", может записывать данные в объект класса "совершенно секретно". Здесь нужно понимать, что речь идет не о том, что он может записывать данные, имеющие класс "совершенно секретно", а о том, что он может производить запись в область памяти, способную содержать совершенно секретные данные. Но как только такие данные записаны, они приобретают статус "совершенно секретных". Логически пользователь или процесс, имеющие класс "секретно", не могут иметь доступа к какой-либо совершенно секретной информации, которую бы они могли записать в эту область памяти. Они помещают в нее секретную, конфиденциальную или несекретную информацию, которая может понадобиться пользователю или процессу с классом "совершенно секретно".
9. S. Jajodia and R. Sandhu. Toward a Multilevel Secure Relational Data Model, 52.
10., и T.F. Lunt. SeaView. В книге T.F. Lunt, ed., Research Directions in Database Security. - New York: Springer-Verlag, 1992.
11. S. Jajodia and R. Sandhu. Polyinstantiation Integrity in Multilevel Relations. - Proceedings of the 1990 IEEE Computer Society Symposium on Research in Security and Privacy, 104.
12. S. Jajodia and R. Sandhu. Polyinstantiation Integrity...
13. S. Jajodia and R. Sandhu. Toward a Multilevel Secure Relational Data Model, 52.
14. T.F. Lunt. Security in Database Systems, 43.
15. S. Jajodia and R. Sandhu. Toward a Multilevel Secure Relational Data Model, 51-52.
16. U.S. Department of Defence. Department of Defence Trusted Computer Systems Criteria, December 1985, 81.
17. G.W. Smith. Session Report: The Semantics of Data Classification. В книге T.F. Lunt, ed., Research Directions in Database Security. - New York: Springer-Verlag, 1992, 139.
18. Адаптированный пример из статьи J.P. O'Connor et al. An Investigation of Secure Distributed DBMS Architectures. В книге T.F. Lunt, ed., Research Directions in Database Security. - New York: Springer-Verlag, 1992, 53.
19. J.P. O'Connor et al. An Investigation... , 41.
20. J.P. O'Connor et al. An Investigation... , 41.
21. J.P. O'Connor et al. An Investigation... , 42.
22. J.P. O'Connor et al. An Investigation... , 45.
23. J.P. O'Connor et al. An Investigation... , 45-46.
24. Подробнее см. J.P. O'Connor et al. An Investigation... , 46.
25. Подробнее см. J.P. O'Connor et al. An Investigation... , 46.
26. J.P. O'Connor et al. An Investigation... , 59-61.
27. J.P. O'Connor et al. An Investigation... , 48.
29. Примеры из Lunt. SeaView, 25.
30. T.F. Keefe and T.W. Tsai. Security Model Consulting in Secure Object-Oriented Systems. - Proceedings of the 5th Computer Security Applications Conference. 1989, 290-291.
31. B. Thuraisingham. Multilevel Secure Object-Oriented Model - Issues on Noncomposite Objects, Composite Objects and Versioning. - Journal of Object-Oriented Programming, Focus on OODBMS, Special Issue, 1992, 121-130.
32. S. Jajodia. Частные обсуждения. Май 1993.
33. Lunt. Security in Database Systems. 54-55.
34. B. Thuraisingham. Current Status of R&D in Trusted Database Management Systems. - ACM SIGMOD Record, September 1992, 46.
Средства безопасности баз данных долгое время пребывали в зачаточной стадии и сводились к принятой в SQL модели GRANT/REVOKE, которая позволяет владельцу данных передавать другим пользователям системы права на выполнение тех или иных операций чтения-записи. В реальности подобные упрощенные модели имеют весьма ограниченную ценность с точки зрения защиты данных не только от злоумышленников, целенаправленно стремящихся скомпрометировать принадлежащую компании информацию, но даже и от случайных нарушений безопасности.
Правительство США уже в течение долгого времени проявляет активный интерес к развитию моделей информационной безопасности, и выдвинуло в начале - середине 80-х годов ряд инициатив, имеющих целью привлечь внимание к этой сфере (а также к другим областям, относящимся к информационной безопасности, таким как сетевые и коммуникационные средства). За прошедшее десятилетие в этих областях были проведены обширные исследования, и их результаты уже находят применение в коммерческих продуктах в виде новых технологий безопасности.
Коммерческий мир значительно отставал от правительственных учреждений, как в отношении общего внимания к проблеме, так и в реализации соответствующих средств. Однако широкомасштабные и разрушительные нарушения сетевой безопасности, имевшие место в конце 80-х - начале 90-х (вирусы, черви и проч.), вызвали новую волну интереса к вопросам защиты коммерческой информации. Остается, впрочем, пока неясно, какие же модели безопасности будут развиты, поскольку "правительственные" модели необязательно окажутся приемлемыми в коммерческой сфере.
Защита корпоративной информации абсолютно необходима! Будет ли угроза исходить от конкурента или от зарубежных спецслужб, которые уже не столь рьяно охотятся за военным противником, ясно одно - число попыток скомпрометировать коммерческую информацию будет расти, затрагивая интересы все большего числа как крупных корпораций, так и компаний среднего масштаба.
Даже если подходы, выдвинутые правительственным сектором, и не вполне отвечают потребностям частных корпораций, их по крайней мере можно принять в качестве отправной точки и использовать как основу для выработки практических программ защиты корпоративной информации, которые прежде полностью игнорировались. Необходимо четко представлять себе две вещи: во-первых, то, что средства безопасности, имеющиеся сегодня в коммерческих СУБД, ни в коей мере не отвечают потребностям обеспечения реальной защиты; во-вторых, то, что безопасность - это комплексная проблема, охватывающая не только работу баз данных и информационных менеджеров, но и функционирование сети, операционных систем и других компонентов среды.
|
|