· пользователь U может выполнять логические правила r, если slU ? slr;
· пользователь может получить результаты логических выводов rL, если slU ? slrL.
На рисунке 1 показан общий процесс обеспечения безопасности СБД. Процесс обеспечения безопасности СБД выполняется следующим образом:
Если запрос пользователей к СБД является прямым запросом, то модуль "управление доступом" выполняет следующие действия:
· проверяет уровни доступа пользователей;
· определяет уровни безопасности полученных ответов на запрос;
· даёт результаты пользователям в соответствии с их уровнями доступа.
Рисунок 1 - Процесс обеспечения безопасности СБД
Если запрос является логическим запросом, то модуль "подсистема выполнения логических выводов" выполняет следующие действия:
· проверяет уровни доступа пользователей;
· определяет возможность выполнения логических правил; выполняет логические выводы;
· обнаружит нарушения результатов логических выводов; контролирует результаты логических выводов;
· даёт результаты пользователям в соответствии с их уровнями доступа.
Для реализации предлагаемой системы обеспечения безопасности семантических БД необходимо решить набор задач, таких, как согласование уровней безопасности элементов онтологии, определение уровней безопасности триплетов и результатов логических выводов, обнаружение нарушений результатов логических выводов и контроль полученных результатов при выполнении запросов.
Механизмы, обеспечивающие безопасность информации в БД на основе анализа перечисленных факторов, разрабатываются в рамках определенной политики безопасности, которая, в свою очередь, вырабатывается, исходя из соображений юридического характера, особенностей функционирования организационных структур, использующих базу данных, и т.п. При этом указанные механизмы должны быть, по возможности, достаточно гибкими с тем, чтобы их можно было эффективно использовать независимо от возможных изменений политики безопасности.
Существуют два в известном смысле противоположных подхода к политике безопасности. Первый, соответствующий так называемой политике минимума привилегий, состоит в том, чтобы в максимальной степени ограничить круг лиц, допущенных к информации в БД. При этом указанные лица получают доступ только к тем сведениям, которые необходимы им для выполнения служебных обязанностей. Существо второго подхода состоит в том, чтобы, наоборот, обеспечить максимальное использование информации, имеющейся в БД. При этом категорирование данных по грифу секретности по-прежнему имеет место, однако в остальном ограничения на доступ к информации таковы, что каждому пользователю доступен как можно более широкий круг сведений.
Первым шагом при разработке политики безопасности является определение информационного объекта - минимальной единицы информации, которой оперируют механизмы обеспечения безопасности БД. Выбор информационного объекта зависит как от принятого подхода к политике безопасности, так и от модели данных, положенной в основу СУБД. Так, информационным объектом применительно к реляционным системам может быть целое отношение, атрибут отношения либо значение атрибута. В сетевых и иерархических СУБД информационным объектом может быть запись либо элемент (поле) записи. Очевидно, что использование более мелких информационных объектов позволяет реализовать прецизионные механизмы обеспечения безопасности и, таким образом, более избирательную политику безопасности.
Защищаемую информацию в БД принято делить на контекстно-зависимую (контекстно-чувствительную) и контекстно-независимую. Контекстно-независимой считается информация, принятие решений на доступ к которой определяется первыми тремя из перечисленных выше факторов и не связано с использованием полномочий пользователя и предыстории его обращений к базе данных. Всю остальную информацию принято относить к контекстно-чувствительной.
Механизмы обеспечения безопасности контекстно-независимой информации реализуются достаточно просто и поэтому наиболее широко распространены в реальных СУБД. Из них представляют определенный интерес механизмы представлений и модификации запроса, обеспечивающие защиту информации с учетом конкретного содержимого БД. Для удобства изложения при рассмотрении существа этих механизмов мы будем придерживаться понятийного аппарата реляционной модели данных.
Механизм представлений, который был впервые реализован в одной из наиболее развитых реляционных СУБД System R (SQL/DS) [1], основывается на выделении каждому пользователю собственной подсхемы схемы базы данных и работе только с этой подсхемой. Так, если БД содержит отношения АНКЕТА и ЗАРПЛАТА со схемами АНКЕТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ДАТА-РОЖДЕНИЯ, ПОЛ, СЕМЕЙНОЕ-ПОЛОЖЕНИЕ, ДОЛЖНОСТЬ) и ЗАРПЛАТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ОКЛАД-ПО-ДОЛЖНОСТИ, НАДБАВКА-ЗА-ВЫСЛУГУ-ЛЕТ, ПРЕМИЯ, НАЛОГ, ОБЩАЯ-СУММА), то одной группе пользователей могут быть выделены подсхемы отношений АНКЕТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО.ДОЛЖНОСТЬ) и ЗАРПЛАТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ОКЛАД-ПО-ДОЛЖНОСТИ) а другой - только подсхема первого отношения АНКЕТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ДАТА-РОЖДЕНИЯ). Администрация БД работает с полными схемами обоих отношений. При этом, естественно, значения атрибутов, не входящих в выделенные подсхемы, соответствующим пользователям недоступны.
Механизм модификации запроса, поддерживаемый, в частности, другой эффективной реляционной СУБД INGRES [2,3], основывается на принудительном (невидимом пользователю) приформировывании к тексту запроса дополнительных условий отбора, исключающих возможность получения сведений, доступ к которым пользователю запрещен. СУБД обрабатывает модифицированный таким образом запрос и выдает пользователю ответ, в котором содержатся только разрешенные элементы информации. Указанные условия отбора могут быть установлены и, как правило, устанавливаются индивидуально для каждого пользователя. Так, применительно к БД, содержащей отношения с приведенными выше схемами, подобные условия могут иметь следующий вид: ДОЛЖНОСТЬ = (МНС,СНС,ЗАВЕДУЮЩИЙ СЕКТОРОМ) & ДАТА-РОЖДЕНИЯ >31.12.1931 для отношения АНКЕТА и ОБЩАЯ СУММА < 1500 для отношения ЗАРПЛАТА. Первое позволяет выдавать пользователю сведения только о младших и старших научных сотрудниках и заведующих секторами, родившихся в 1932-м и последующих годах. Второе условие пзволяет выдавать сведения о заработной плате только тех сотрудников, которые получают менее 1500 рублей. При поступлении от пользователя запроса вида АНКЕТА: ДАТА-РОЖДЕНИЯ<01.01.1963 & ДОЛЖНОСТЬ = (ЗАВЕДУЮЩИЙ СЕКТОРОМ, ЗАВЕДУЮЩИЙ ОТДЕЛОМ) он будет преобразован в АНКЕТА: ДАТА-РОЖДЕНИЯ<01.01.1963 & ДОЛЖНОСТЬ = (ЗАВЕДУЮЩИЙ СЕКТОРОМ, ЗАВЕДУЮЩИЙ ОТДЕЛОМ) & ДОЛЖНОСТЬ = (МНС,СНС,ЗАВЕДУЮЩИЙ СЕКТОРОМ) & ДАТА-РОЖДЕНИЯ >31.12.1931. При этом пользователь получит анкетные данные только о заведующих секторами, родившихся в 1932-1962 г.г., тогда как затребованные им сведения о заведующих отделами, родившихся до 1962 г., а также о заведующих секторами, родившихся до 1932 г., не будут включены в ответ.
Описанные механизмы, вообще говоря, не делают различия между операциями, выполняемыми над защищаемой информацией: считается, что информационный объект либо доступен пользователю, либо недоступен, причем в первом случае пользователь может выполнять над объектом любые операции, а во втором - никакие. Более тонкие механизмы реализуют избирательную защиту информации, когда для каждой операции и каждого пользователя определяется свое множество информационных объектов, над которыми она может быть выполнена пользователем. Например, одному из пользователей могут быть разрешены внесение, удаление и отбор любых элементов отношения АНКЕТА и отбор любых элементов отношения ЗАРПЛАТА. В это же время другому пользователю может быть разрешено внесение и удаление элементов отношения АНКЕТА, значениями атрибута ДОЛЖНОСТЬ, в которых не являются ЗАВЕДУЮЩИЙ ОТДЕЛОМ и ЗАВЕДУЮЩИЙ СЕКТОРОМ, а также отбор элементов отношения ЗАРПЛАТА по сотрудникам, не занимающим указанные должности.
Механизмы обеспечения безопасности контекстно-чувствительной информации существенно сложнее и в настоящее время находятся в стадии теоретической проработки и экспериментальных программных реализаций [4].
Основные требования по безопасности в базах данных
Основные требования по безопасности данных, предъявляемые к БД и СУБД, во многом совпадают с требованиями, предъявляемыми к безопасности данных в компьютерных системах. Поэтому некоторые из механизмов защиты БД (рис.8.1.) идентичны механизмам, используемым для защиты ОС.
Тем не менее, специфические особенности технологии БД определяют ряд требований по безопасности, характерных именно для БД. Основные требования можно разделить на требования по управлению доступом и требования по управлению целостностью данных.
Требования по управлению доступом в базах данных
Под управлением доступом в БД понимается защита данных в БД от НСД. Обычно выделяют следующие требования по безопасности, связанные с доступом в БД.
1. Возможность контроля доступа. В СУБД должны быть предусмотрены механизмы установления субъекта, осуществляющего тот или иной доступ к конкретному элементу данных, а также тип осуществленного доступа.
2. Доступность данных. Пользователи, которые авторизованы для работы с БД, должны иметь гарантированный доступ к соответствующим данным.
3. Управляемость доступом. Пользователь должен иметь доступ только к тем данным, для работы с которыми он имеет полномочия. При этом пользователи могут быть ограничены различными типами доступа (чтение, модификация, добавление, удаление и т.п.) к одним и тем же данным.
Требования по управлению целостностью в базах данных
Под управлением целостностью в БД понимается защита данных в БД от неверных (в отличие от несанкционированных) изменений и разрушений. Поддержание целостности БД состоит в том, чтобы обеспечить в каждый момент времени корректность (правильность) как самих значений всех элементов данных, так и взаимосвязей между элементами данных в БД.
С поддержанием целостности связаны следующие основные требования.
1.Обеспечение достоверности. В каждый элемент данных информация заносится точно в соответствии с описанием этого элемента. Должны быть предусмотрены механизмы обеспечения устойчивости элементов данных и их логических взаимосвязей к ошибкам или неквалифицированным действиям пользователей.
2. Управление параллелизмом. Нарушение целостности БД может возникнуть при одновременном выполнении операций над данными, каждая из которых в отдельности не нарушает целостности БД. Поэтому должны быть предусмотрены механизмы управления данными, обеспечивающие поддержание целостности БД при одновременном выполнении нескольких операций.
3. Восстановление. Хранимые в БД данные должны быть устойчивы по отношению к неблагоприятным физическим воздействиям (аппаратные ошибки, сбои питания и т.п.) и ошибкам в программном обеспечении. Поэтому должны быть предусмотрены механизмы восстановления за предельно короткое время того состояния БД, которое было перед появлением неисправности.
Вопросы управления доступом и поддержания целостности БД тесно соприкасаются между собой, и во многих случаях для их решения используются одни и те же механизмы. Различие между этими аспектами обеспечения безопасности данных в БД состоит в том, что управление доступом связано с предотвращением преднамеренного разрушения БД, а управление целостностью - с предотвращением непреднамеренного внесения ошибки.
2. Определение уровней безопасности элементов, классов, свойств, индивидов и триплетов онтологий
Согласование уровней безопасности классов онтологии.
· В онтологиях O нет классов сx, не имеющих уровней безопасности slСx .
· Уровень безопасности slCx класса сx должен быть больше или равен уровню безопасности его суперкласса slCsup, slCx ? slCsup.
· Если класс сx связывается с классом сy, имеющим уровень безопасности slу, с помощью отношений owl:sameAs, owl: equivalentClass, то
slСx = MAX(slСx, slCу);
Согласование уровней безопасности свойств онтологии.
· В онтологиях O нет свойств px, не имеющих уровней безопасности slPx .
· Уровень безопасности slPx свойства px должен быть больше или равен уровню безопасности его суперсвойства slPsup, slPx ? slPsup.
· Если px связывается с другими свойствами py по отношением rdfs:subPropertyOf, owl:inverseOf, owl:equivalentProperty, owl:InverseFunctionalProperty, то slPx = MAX(slPx, slPy), где slPy - уровень безопасности свойства py .
Согласование уровней безопасности индивидов.
· В семантических БД каждому индивиду ix задан начальный уровень безопасности slIx .
· Уровень безопасности slIx индивида ix должен быть больше или равен уровню безопасности slСy класса, которому он принадлежит, slIx ? slCy .
В онтологии O имеется множество классов C = {с 1, ..., сm} и множество заданных им уровней безопасности SLC ={slC1, ..., slCm}, где slC1, ..., slCm - уровни безопасности классов c1, ..., cm соответственно.
Уровень безопасности slСx класса сx ? С может быть определён следующим образом:
1. если уровень безопасности slСx класса сx не задан, то slСx = 0;
2. если сх связывается с сy отношением owl:sameAs, owl: equivalentClass, то slСx = MAX(slСx, slСу), где slСу - уровень безопасности класса cy ;
3. если класс сx является подклассом класса сz, который имеет уровень безопасности slСz, то slСx = MAX(slСx, slСz).