Защита на уровне СУБД

Сервер баз данных управляет секретностью базы данных, используя различные средства:

─ управление пользователями базы данных;

─ управление привилегиями и ролями;

─ аудит базы данных;

─ шифрование хранимых программных единиц.

Распознавание пользователя предполагает:

─ идентификацию пользователя – пользователь указывает свой идентификатор (не секретный – логин);

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

После распознавания пользователя система производит следующие действия:

─ выделяет соответствующие пользователю ресурсы (трафик, расписание доступа, выделение памяти и т.д.);

─ устанавливает права доступа пользователя.

─ выполняет мониторинг (оперативное наблюдение) и аудит (подведение итогов, определение статистики) за пользователем;

Основное средство защиты – контроль доступа – использует два основных подхода:

─ обязательный;

─ избирательный.

Избирательный подход – дает меньшую степень защиты, но более просто реализуется. Дл этого пользователям назначаются привилегии.

Привилегия – право на выполнение некоторой операции. Разделяются на системные и объектные привилегии.

Системные (командные) привилегии – разрешают пользователю выполнять конкретную операцию с базой данных. Используются для выполнения административных задач (создание или удаление таблиц, представлений, хранимых процедур, ввод учетных записей пользователей и т.д.). Эта группа привилегий никак не стандартизирована и реализуется в разных системах с разным набором привилегий.

Объектные привилегии – разрешают выполнять действия над заданным объектом базы данных (таблицей, представлением и т.д.). Стандартизированы в SQL системах.

Основные объектные привилегии для внешних пользователей:

ALTER – разрешает изменение определения заданных таблиц, представлений

DELETE – разрешает удаление строк из заданных таблиц, представлений

EXECUTE – разрешает выполнение заданных хранимых процедур, функций, пакетов

INSERT – разрешает вставка строк в заданные таблицы, представления

SELECT – разрешает чтение данных из заданных таблиц, представлений

UPDATE – разрешает изменение данных в заданных таблицах, представлениях

При назначении привилегий различают субъект – (то, что выполняет действие – может быть пользователь или программа) и объект (то, над чем выполняется действие – может быть информационный объект или программа).

Для задания привилегий заполняется матрица доступа:

Привелегии (права) задаются с помощью команды:

GRANT <привилегия[, привилегия …] | ALL> ON <Объект> TO <Субъект>

("ALL" предоставляет все привилегии на объект)

Например, чтобы позволить пользователю Ivanov выполнять запросы к таблице Sotrudnik, нужно ввести команду

GRANT SELECT ON Sotrudnik TO Ivanov;

Привилегии, объекты и субъекты можно задавать списком.

Привилегии может назначать администратор, владелец объекта или уполномоченное (доверенное) лицо – тот, кому поручили перераспределение привилегий.

Доверенное лицо получает разрешение на выдачу привилегий добавлением GRANT опции:

GRANT <привилегия> ON <Объект> TO <Субъект> WITH GRANT OPTION

При этом конструкция "WITH ADMIN OPTION" разрешает предоставлять полученную привилегию другим пользователям

Напрмер, команда

“GRANT SELECT ON Sotrudnik TO Ivanov WITH GRANT OPTION”

предоставляет возможность пользователю Ivanov передавать право назначать привилегии работы с таблицей Sotrudnik другим пользователям.

Для отмены привилегии используется оператор

“REVOKE <привилегия> ON <объект> FROM <субъект>”.

Привилегию может снять только субъект, ее назначивший; снятие привилегии выполняется каскадно.

Одна из первых привилегий, которая должна быть определена - это привилегия создателей таблиц. Если все пользователи будут иметь возможность создавать в системе базовые таблицы, это может привести к избыточности данных, их несогласованности и, как следствие, к неэффективности системы. Пользователь, создавший таблицу, является ее владельцем. Это означает, что пользователь имеет все привилегии в созданной им таблице и может передавать привилегии другим пользователям в этой таблице.

Каждый пользователь в среде SQL имеет специальное идентификационное имя (или номер).

Для пользователя таблицы могут быть назначены следующие типы привилегий:

─ SELECT - разрешение выполнять запросы в таблице.

─ INSERT - разрешение выполнять оператор INSERT (вставка новой строки) в таблице.

─ UPDATE - разрешение выполнять оператор UPDATE (обновление значений полей) в таблице. Можно ограничить эту привилегию для определенных столбцов таблицы.

─ DELETE - разрешение выполнять оператор DELETE (удаление записей) в таблице.

─ REFERENCES - разрешение определить внешний ключ.

Недостатки избирательного подхода:

─ сложность назначения привилегий;

─ ошибки нарушения конфиденциальности из-за путаницы.

Для упрощения и большей наглядности назначений может быть реализовано группирование. Существуют две формы: пользователи объединяются в группы, привилегии в роли.

В первых системах создавались группы пользователей. При этом объявляются группы, пользователи причисляются к группам. Привилегии назначаются как отдельным пользователям, так и отдельным группам. Обычно существуют предопределенные группы (например, PUBLIC – в нее автоматически зачисляются все пользователи; этой группе определяют минимальные права).

Второй вариант, который в настоящее время чаще используется – управление привилегиями через роли. Роль – именованная группа привилегий, которая может быть предоставлена пользователю. Использование ролей позволяет группировать привилегии, необходимые для разных категорий пользователей и динамически управлять привилегиями (например, достаточно переопределить привилегии, назначенные роли, что немедленно отобразится на всех пользователях, которым назначена эта роль). Администратор базы данных создает роль, определяет набор привилегий для роли и присваивает роль пользователям:

Разница данных вариантов группирования в том, что назначение в группы является статическим. Создание ролей позволяет сделать динамически управление.

базы данных .

Эти два подхода отличаются следующими свойствами:

В случае избирательного управления некоторый пользователь обладает различными правами (привилегиями или полномочиями) при работе с данными объектами. Разные пользователи могут обладать разными правами доступа к одному и тому же объекту. Избирательные права характеризуются значительной гибкостью.
В случае неизбирательного управления, наоборот, каждому объекту данных присваивается некоторый классификационный уровень, а каждый пользователь обладает некоторым уровнем допуска. При таком подходе доступом к определенному объекту данных обладают только пользователи с соответствующим уровнем допуска.
Для реализации избирательного принципа предусмотрены следующие методы. В базу данных вводится новый тип объектов БД - это пользователи. Каждому пользователю в БД присваивается уникальный идентификатор. Для дополнительной защиты каждый пользователь кроме уникального идентификатора снабжается уникальным паролем, причем если идентификаторы пользователей в системе доступны системному администратору, то пароли пользователей хранятся чаще всего в специальном кодированном виде и известны только самим пользователям.
Пользователи могут быть объединены в специальные группы пользователей. Один пользователь может входить в несколько групп. В стандарте вводится понятие группы PUBLIC , для которой должен быть определен минимальный стандартный набор прав. По умолчанию предполагается, что каждый вновь создаваемый пользователь, если специально не указано иное, относится к группе PUBLIC .
Привилегии или полномочия пользователей или групп - это набор действий (операций), которые они могут выполнять над объектами БД.
В последних версиях ряда коммерческих СУБД появилось понятие "роли". Роль - это поименованный набор полномочий. Существует ряд стандартных ролей, которые определены в момент установки сервера баз данных. И имеется возможность создавать новые роли, группируя в них произвольные полномочия. Введение ролей позволяет упростить управление привилегиями пользователей, структурировать этот процесс. Кроме того, введение ролей не связано с конкретными пользователями, поэтому роли могут быть определены и сконфигурированы до того, как определены пользователи системы.
Пользователю может быть назначена одна или несколько ролей.
Объектами БД, которые подлежат защите, являются все объекты, хранимые в БД: таблицы, представления, хранимые процедуры и триггеры. Для каждого типа объектов есть свои действия, поэтому для каждого типа объектов могут быть определены разные права доступа.

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

Проверка полномочий основана на том, что каждому пользователю или процессу информационной системы соответствует набор действий, которые он может выполнять по отношению к определенным объектам. Проверка подлинности означает достоверное подтверждение того, что пользователь или процесс, пытающийся выполнить санкционированное действие, действительно тот, за кого он себя выдает.

Система назначения полномочий имеет в некотором роде иерархический характер. Самыми высокими правами и полномочиями обладает системный администратор или администратор сервера БД . Традиционно только этот тип пользователей может создавать других пользователей и наделять их определенными полномочиями.

СУБД в своих системных каталогах хранит как описание самих пользователей, так и описание их привилегий по отношению ко всем объектам.

Далее схема предоставления полномочий строится по следующему принципу. Каждый объект в БД имеет владельца - пользователя, который создал данный объект . Владелец объекта обладает всеми правами-полномочиями на данный объект , в том числе он имеет право предоставлять другим пользователям полномочия по работе с данным объектом или забирать у пользователей ранее предоставленные полномочия.

В ряде СУБД вводится следующий уровень иерархии пользователей - это администратор БД . В этих СУБД один сервер может управлять множеством СУБД (например, MS SQL Server , Sybase).

В СУБД Oracle применяется однобазовая архитектура , поэтому там вводится понятие подсхемы - части общей схемы БД и вводится пользователь , имеющий доступ к подсхеме.

В стандарте SQL не определена команда создания пользователя, но практически во всех коммерческих СУБД создать пользователя можно не только в интерактивном режиме, но и программно с использованием специальных хранимых процедур. Однако для выполнения этой операции пользователь должен иметь право на запуск соответствующей системной процедуры.

В стандарте SQL определены два оператора: GRANT и REVOKE соответственно предоставления и отмены привилегий .

Оператор предоставления привилегий имеет следующий формат:

GRANT {<список действий> | ALL PRIVILEGES } ON <имя_объекта> TO {<имя_пользователя> | PUBLIC }

Здесь список действий определяет набор действий из общедопустимого перечня действий над объектом данного типа.

Параметр ALL PRIVILEGES указывает, что разрешены все действия из допустимых для объектов данного типа.

<имя_объекта> - задает имя конкретного объекта: таблицы, представления, хранимой процедуры, триггера.

<имя_пользователя> или PUBLIC определяет, кому предоставляются данные привилегии.

Параметр WITH GRANT OPTION является необязательным и определяет режим, при котором передаются не только права на указанные действия, но и право передавать эти права другим пользователям. Передавать права в этом случае пользователь может только в рамках разрешенных ему действий.

Рассмотрим пример, пусть у нас существуют три пользователя с абсолютно уникальными именами user1, user2 и user3 . Все они являются пользователями одной БД .

User1 создал объект Tab1 , он является владельцем этого объекта и может передать права на работу с эти объектом другим пользователям. Допустим, что пользователь user2 является оператором, который должен вводить данные в Tab1 (например, таблицу новых заказов), а пользователь user 3 является большим начальником (например, менеджером отдела), который должен регулярно просматривать введенные данные.

Для объекта типа таблица полным допустимым перечнем действий является набор из четырех операций: SELECT, INSERT, DELETE, UPDATE . При этом операция обновление может быть ограничена несколькими столбцами.

Общий формат оператора назначения привилегий для объекта типа таблица будет иметь следующий синтаксис :

GRANT {[,INSERT][,DELETE][,UPDATE (<список столбцов>)]} ON <имя_таблицы> TO {<имя_пользователя> | PUBLIC }

Тогда резонно будет выполнить следующие назначения:

GRANT INSERT ON Tab1 TO user2 GRANT SELECT ON Tab1 TO user3

Эти назначения означают, что пользователь user2 имеет право только вводить новые строки в отношение Tab1 , а пользователь user3 имеет право просматривать все строки в таблице Tab1 .

При назначении прав доступа на операцию модификации можно уточнить, значение каких столбцов может изменять пользователь . Допустим, что менеджер отдела имеет право изменять цену на предоставляемые услуги. Предположим, что цена задается в столбце COST таблицы Tab1 . Тогда операция назначения привилегий пользователю user3 может измениться и выглядеть следующим образом:

GRANT SELECT, UPDATE (COST) ON Tab1 TO user3

Если наш пользователь user1 предполагает, что пользователь user4 может его замещать в случае его отсутствия, то он может предоставить этому пользователю все права по работе с созданной таблицей Tab1 .

GRANT ALL PRIVILEGES ON Tab1 TO user4 WITH GRANT OPTION

В этом случае пользователь user4 может сам назначать привилегии по работе с таблицей Tab1 в отсутствие владельца объекта пользователя user1 . Поэтому в случае появления нового оператора пользователя user5 он может назначить ему права на ввод новых строк в таблицу командой

GRANT INSERT ON Tab1 TO user5

Если при передаче полномочий набор операций над объектом ограничен, то пользователь , которому переданы эти полномочия, может передать другому пользователю только те полномочия, которые есть у него, или часть этих полномочий. Поэтому если пользователю user4 были делегированы следующие полномочия:

GRANT SELECT, UPDATE, DELETE ON Tab1 TO user4 WITH GRANT OPTION,

то пользователь user4 не сможет передать полномочия на ввод данных пользователю user5 , потому что эта операция не входит в список разрешенных для него самого.

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

Так как представления могут соответствовать итоговым запросам, то для этих представлений недопустимы операции изменения, и, следовательно, для таких представлений набор допустимых действий ограничивается операцией SELECT . Если же представления соответствуют выборке из базовой таблицы, то для такого представления допустимыми будут все 4 операции : SELECT , INSERT , UPDATE и DELETE .

Для отмены ранее назначенных привилегий в стандарте SQL определен оператор REVOKE . Оператор отмены привилегий имеет следующий синтаксис :

REVOKE {<список операций> | ALL PRIVILEGES} ON <имя_объекта> FROM {<список пользователей> | PUBLIC } {CASCADE | RESTRICT }

Параметры CASCADE или RESTRICT определяют, каким образом должна производиться отмена привилегий . Параметр CASCADE отменяет привилегии не только пользователя, который непосредственно упоминался в операторе GRANT при предоставлении ему привилегий, но и всем пользователям, которым этот пользователь присвоил привилегии, воспользовавшись параметром WITH GRANT OPTION .

Например, при использовании операции :

REVOKE ALL PRIVILEGES ON Tab1 FROM user4 CASCADE

будут отменены привилегии и пользователя user5 , которому пользователь user4 успел присвоить привилегии.

Параметр RESTRICT ограничивает отмену привилегий только пользователю, непосредственно упомянутому в операторе REVOKE . Но при наличии делегированных привилегий этот оператор не будет выполнен. Так, например, операция:

REVOKE ALL PRIVILEGES ON Tab1 TO user4 RESTRICT

не будет выполнена, потому что пользователь user4 передал часть cвоих полномочий пользователю user5 .

Посредством оператора REVOKE можно отобрать все или только некоторые из ранее присвоенных привилегий по работе с конкретным объектом. При этом из описания синтаксиса оператора отмены привилегий видно, что можно отобрать привилегии одним оператором сразу у нескольких пользователей или у целой группы PUBLIC .

Средства защиты БД в различных СУБД несколько отличаются друг от друга. На основе анализа современных СУБД Borland и Microsoft можно утверждать, что средства защиты БД условно делятся на две группы, основные и дополнительные.

К основным средствам защиты информации можно отнести следующие средства:

Парольная защита;

Шифрование данных и программ;

Установление прав доступа к объектам БД;

Защита полей и записей таблиц БД.

Парольная защита представляет простой и эффективный способ защиты БД от несанкционированного доступа. Пароли устанавливаются конечными пользователями или администраторами БД. Учет и хранение паролей производится самой СУБД. Обычно пароли хранятся в определенных системных файлах СУБД в зашифрованном виде. Поэтому просто найти и определить пароль невозможно. После ввода пароля пользователю СУБД предоставляются все возможности по работе с защищенной БД.

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

В целях контроля использования основных ресурсов СУБД во многих системах имеются средства установления прав доступа к объектам БД . Права доступа определяют возможные действия над объектами. Владелец объекта (пользователь, создавший объект), а также администратор БД имеют все права. Остальные пользователи к разным объектам могут иметь различные уровни доступа.

По отношению к таблицам в общем случае могут предусматриваться следующие права доступа.

Просмотр (чтение) данных;

Изменение (редактирование) данных;

Добавление новых записей;

Добавление и удаление данных;

Все операции, в том числе изменение структуры таблицы.

К данным, имеющимся в таблице, могут применяться меры защиты по отношению к отдельным полям и отдельным записям. В реляционных СУБД отдельные записи специально не защищаются.

Применительно к защите данных в полях таблиц можно выделить следующие уровни прав доступа:

Полный запрет доступа;

Только чтение;

Разрешение всех операций (просмотр, ввод новых значений, удаление и изменение).

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

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

Для исключения просмотра и модификации (случайной или преднамеренной) текстов программ, используемых в приложениях СУБД, помимо шифрации, может применяться их парольная защита.

К дополнительным средствам защиты БД можно отнести такие, которые нельзя прямо отнести к средствам защиты, но которые непосредственно влияют на безопасность данных. Это следующие средства:

Встроенные средства контроля значений данных в соответствии с типами;

Повышения достоверности вводимых данных;

Обеспечения целостности связей таблиц;

Организации совместного использования объектов БД в сети.

Редактируя БД, пользователь может случайно ввести такие значения, которые не соответствуют типу поля, в которое это значение вводится (например, ввод в числовое поле текстовой информации). В этом случае СУБД с помощью средств контроля значений блокирует ввод и сообщает пользователю об ошибке.

Средства повышения достоверности вводимых значений в СУБД служат для более глубокого контроля, связанного с семантикой обрабатываемых данных. Они обычно обеспечивают возможность при создании таблицы указывать следующие ограничения на значения: минимальное и максимальное значения, значение, принимаемое по умолчанию (если нет ввода), требование обязательного ввода; задание маски (шаблона) ввода и т.д.

Более совершенной формой организации контроля достоверности информации в БД является разработка хранимых процедур. Механизм хранимых процедур применяется в БД, размещенных на сервере. Сами хранимые процедуры представляют собой программы, алгоритмы которых предусматривают выполнение некоторых функций (в том числе контрольных) над данными. Процедуры хранятся вместе с данными и при необходимости вызываются из приложений либо при наступлении некоторых событий в БД.

Решение прикладной задачи, как правило, требует выбора информации из нескольких таблиц. Таблицы в базе данных могут быть связаны. Функции поддержания логической целостности связанных таблиц берет на себя СУБД. Если СУБД не реализует эти функции, то ответственность за корректность связей возлагается на приложение.

Приведем пример возможных действий СУБД по контролю целостности связей таблиц. Пусть между двумя таблицами существует связь вида 1.М и, следовательно, одной записи основной таблицы может соответствовать несколько записей вспомогательной таблицы.

При вставке записей во вспомогательную таблицу система контролирует наличие соответствующих значений в поле связи основной таблицы. Если вводимое значение отсутствует в основной таблице, СУБД временно блокирует работу с новой записью и предлагает изменить значение или удалить запись целиком.

Удаление записей из дополнительных таблиц не контролируется. При удалении записи из основной таблицы происходит проверка. В случае, когда запись основной таблицы связана с несколькими записями дополнительной таблицы, возможны два варианта поведения. Не удалять основной записи, пока имеется хотя бы одна подчиненная запись (записи должен удалять пользователь), либо удалить основную запись и все подчиненные записи (каскадное удаление).

В распределенных информационных системах, работающих с базами данных, возникает проблема разрешения конфликтов между различными действиями над одними и теми же объектами (совместного использования объектов БД). Например, что делать в случае, когда один из пользователей локальной сети редактирует БД, а другой хочет изменить ее структуру? Для таких ситуаций в СУБД должны быть предусмотрены механизмы разрешения конфликтов.

Обычно при одновременной работе нескольких пользователей в сети используются блокировки. Блокировки могут действовать на различные объекты БД и на отдельные элементы объектов. Блокировки объектов возникают, когда параллельно с использованием объекта предпринимается попытка входа в режим разработки этого же объекта. Применительно к таблицам баз данных дополнительные блокировки могут возникать при работе с отдельными записями или полями.

Блокировки бывают явные и неявные. Явные блокировки накладываются пользователем или приложением с помощью команд. Неявные блокировки организует сама система, чтобы избежать возможных конфликтов. Например, в случае попытки изменения структуры БД во время редактирования информации устанавливается запрет реструктурирования БД до завершения редактирования данных.

В современных СУБД поддерживается один из двух наиболее общих подходов к вопросу обеспечения безопасности данных: избирательный подход и обязательный подход. В обоих подходах единицей данных или «объектом данных», для которых должна быть создана система безопасности, может быть как вся база данных целиком, так и любой объект внутри базы данных.

Эти два подхода отличаются следующими свойствами:

В случае избирательного управления некоторый пользователь обладает различными правами (привилегиями или полномочиями) при работе с данными объектами. Разные пользователи могут обладать разными правами доступа к одному и тому же объекту. Избирательные права характеризуются значительной гибкостью.

В случае избирательного управления, наоборот, каждому объекту данных присваивается некоторый классификационный уровень, а каждый пользователь обладает некоторым уровнем допуска. При таком подходе доступом к определенному объекту данных обладают только пользователи с соответствующим уровнем допуска.

Для реализации избирательного принципа предусмотрены следующие методы. В базу данных вводится новый тип объектов БД -- это пользователи. Каждому пользователю в БД присваивается уникальный идентификатор. Для дополнительной защиты каждый пользователь кроме уникального идентификатора снабжается уникальным паролем, причем если идентификаторы пользователей в системе доступны системному администратору, то пароли пользователей хранятся чаще всего в специальном кодированном виде и известны только самим пользователям.

Пользователи могут быть объединены в специальные группы пользователей. Один пользователь может входить в несколько групп. В стандарте вводится понятие группы PUBLIC, для которой должен быть определен минимальный стандартный набор прав. По умолчанию предполагается, что каждый вновь создаваемый пользователь, если специально не указано иное, относится к группе PUBLIC.

Привилегии или полномочия пользователей или групп -- это набор действий (операций), которые они могут выполнять над объектами БД.

В последних версиях ряда коммерческих СУБД появилось понятие «роли». Роль -- это поименованный набор полномочий. Существует ряд стандартных ролей, которые определены в момент установки сервера баз данных. И имеется возможность создавать новые роли, группируя в них произвольные полномочия. Введение ролей позволяет упростить управление привилегиями пользователей, структурировать этот процесс. Кроме того, введение ролей не связано с конкретными пользователями, поэтому роли могут быть определены и сконфигурированы до того, как определены пользователи системы.

Пользователю может быть назначена одна или несколько ролей.

Объектами БД, которые подлежат защите, являются все объекты, хранимые в БД: таблицы, представления, хранимые процедуры и триггеры. Для каждого типа объектов есть свои действия, поэтому для каждого типа объектов могут быть определены разные права доступа.

Система назначения полномочий имеет в некотором роде иерархический характер. Самыми высокими правами и полномочиями обладает системный администратор или администратор сервера БД. Традиционно только этот тип пользователей может создавать других пользователей и наделять их определенными полномочиями.

Далее схема предоставления полномочий строится по следующему принципу. Каждый объект в БД имеет владельца -- пользователя, который создал данный объект. Владелец объекта обладает всеми правами-полномочиями на данный объект, в том числе он имеет право предоставлять другим пользователям полномочия по работе с данным объектом или забирать у пользователей ранее предоставленные полномочия.

В ряде СУБД вводится следующий уровень иерархии пользователей -- это администратор БД. В этих СУБД один сервер может управлять множеством СУБД (например, MS SQL Server, Sybase). В СУБД Oracle применяется однобазовая архитектура, поэтому там вводится понятие подсхемы -- части общей схемы БД и вводится пользователь, имеющий доступ к подсхеме. В стандарте SQL не определена команда создания пользователя, но практически во всех коммерческих СУБД создать пользователя можно не только в интерактивном режиме, но и программно с использованием специальных хранимых процедур. Однако для выполнения этой операции пользователь должен иметь право на запуск соответствующей системной процедуры.

В стандарте SQL определены два оператора: GRANT и REVOKE соответственно предоставления и отмены привилегий.

Оператор предоставления привилегий имеет следующий формат:

GRANT {<список действий | ALL PRIVILEGES }

ON <имя_объекта> ТО (<имя_пользователя> ] PUBLIC }

Параметр ALL PRIVILEGES указывает, что разрешены все действия из допустимых для объектов данного типа.

<имя_обьекта> -- задает имя конкретного объекта: таблицы, представления, хранимой процедуры, триггера.

<имя_пользователя> или PUBLIC определяет, кому предоставляются данные привилегии.

Рассмотрим пример, пусть у нас существуют три пользователя с абсолютно уникальными именами userl, user2 и user3. Все они являются пользователями одной БД.

User1 создал объект Таb1, он является владельцем этого объекта и может передать права на работу с эти объектом другим пользователям. Допустим, что пользователь user 2 является оператором, который должен вводить данные в Таb1 (например, таблицу новых заказов), а пользователь user 3 является большим начальником (например, менеджером отдела), который должен регулярно просматривать введенные данные.

Для объекта типа таблица полным допустимым перечнем действий является набор из четырех операций: SELECT, INSERT, DELETE, UPDATE. При этом операция обновление может быть ограничена несколькими столбцами.

Общий формат оператора назначения привилегий для объекта типа таблица будет иметь следующий синтаксис:

GRANT {[.INSERT][,DELETED[.UPDATE (<список столбцов>)]} ON <имя таблицы>

ТО {<имя_пользователя> PUBLIC }

Тогда резонно будет выполнить следующие назначения:

ТО user2 GRANT SELECT

Эти назначения означают, что пользователь user2 имеет право только вводить новые строки в отношение Таb1> а пользователь user3 имеет право просматривать все строки в таблице Таb1.

При назначении прав доступа на операцию модификации можно уточнить, значение каких столбцов может изменять пользователь. Допустим, что менеджер отдела имеет право изменять цену на предоставляемые услуги. Предположим, что цена задается в столбце COST таблицы Таb1. Тогда операция назначения привилегий пользователю user3 может измениться и выглядеть следующим образом:

GRANT SELECT. UPDATE (COST) ON Tab1 TO user3

GRANT ALL PRIVILEGES

TO user4 WITH GRANT OPTION

В этом случае пользователь user4 может сам назначать привилегии по работе с таблицей Таb1 в отсутствие владельца объекта пользователя user1. Поэтому в случае появления нового оператора пользователя user5 он может назначить ему права на ввод новых строк в таблицу командой

ON Tab1 TO user5

Если при передаче полномочий набор операций над объектом ограничен, то пользователь, которому переданы эти полномочия, может передать другому пользователю только те полномочия, которые есть у него, или часть этих полномочий. Поэтому если пользователю user4 были делегированы следующие полномочия:

GRANT SELECT. UPDATE. DELETE

TO user4 WITH GRANT OPTION,

то пользователь user4 не сможет передать полномочия на ввод данных пользователю user5, потому что эта операция не входит в список разрешенных для него самого.

Так как представления могут соответствовать итоговым запросам, то для этих представлений недопустимы операции изменения, и, следовательно, для таких представлений набор допустимых действий ограничивается операцией SELECT. Если же представления соответствуют выборке из базовой таблицы, то для такого представления допустимыми будут все 4 операции: SELECT, INSERT, UPDATE и DELETE.

Для отмены ранее назначенных привилегий в стандарте SQL определен оператор REVOKE. Оператор отмены привилегий имеет следующий синтаксис:

REVOKE {<список операций | ALL PRIVILEGES} ON <имя_объекта>

FROM {<список пользователей | PUBLIC } {CASCADE | RESTRICT }

Параметры CASCADE или RESTRICT определяют, каким образом должна производиться отмена привилегий. Параметр CASCADE отменяет привилегии не только пользователя, который непосредственно упоминался в операторе GRANT при предоставлении ему привилегий, но и всем пользователям, которым этот пользователь присвоил привилегии, воспользовавшись параметром WITH GRANT OPTION.

Например, при использовании операции:

REVOKE ALL PRIVILEGES - ON Tab1 TO user4 CASCADE

будут отменены привилегии и пользователя user5, которому пользователь user4 успел присвоить привилегии.

Параметр RESTRICKT ограничивает отмену привилегий только пользователю, непосредственно упомянутому в операторе REVOKE. Но при наличии делегированных привилегий этот оператор не будет выполнен. Так, например, операция:

REVOKE ALL PRIVILEGES ON Tab1 TO user4 RESTRICT

не будет выполнена, потому что пользователь user4 передал часть своих полномочий пользователю user5.

Поэтому корректным будет следующее использование оператора REVOKE:

REVOKE INSERT ON Tab! TO user2.user4 CASCADE

При работе с другими объектами изменяется список операций, которые используются в операторах GRANT и REVOKE.

По умолчанию действие, соответствующее запуску (исполнению) хранимой процедуры, назначается всем членам группы PUBLIC.

Если вы хотите изменить это условие, то после создания хранимой процедуры необходимо записать оператор REVOKE.

REVOKE EXECUTE ON COUNT_EX TO PUBLIC CASCADE И теперь мы можем назначить новые права пользователю user4.

GRANT EXECUTE ON COUNT_EX TO user4

Системный администратор может разрешить некоторому пользователю создавать и изменять таблицы в некоторой БД. Тогда он может записать оператор предоставления прав следующим образом:

GRANT CREATE TABLE. ALTER TABLE, DROP TABLE ON OB_LIB TO user1

В этом случае пользователь user1 может создавать, изменять или удалять таблицы в БД DB_LIB, однако он не может разрешить создавать или изменять таблицы в этой БД другим пользователям, потому что ему дано разрешение без права делегирования своих возможностей.

В некоторых СУБД пользователь может получить права создавать БД. Например, в MS SQL Server системный администратор может предоставить пользователю main_user право на создание своей БД на данном сервере. Это может быть сделано следующей командой:

GRANT CREATE DATABASE

ON SERVERJ) TO main user

По принципу иерархии пользователь main_user, создав свою БД, теперь может предоставить права на создание или изменение любых объектов в этой БД другим пользователям. В СУБД, которые поддерживают однобазовую архитектуру, такие разрешения недопустимы. Например, в СУБД Oracle на сервере создается только одна БД, но пользователи могут работать на уровне подсхемы (части таблиц БД и связанных с ними объектов). Поэтому там вводится понятие системных привилегий. Их очень много, 80 различных привилегий.

Для того чтобы разрешить пользователю создавать объекты внутри этой БД, используется понятие системной привилегии, которая может быть назначена одному или нескольким пользователям. Они выдаются только на действия и конкретный тип объекта. Поэтому- если вы, как системный администратор, предоставили пользователю право создания таблиц (CREATE TABLE), то для того чтобы он мог создать триггер для таблицы, ему необходимо предоставить еще одну системную привилегию CREATE TRIGGER. Система защиты в Oracle считается одной из самых мощных, но это имеет и обратную сторону -- она весьма сложная. Поэтому задача администрирования в Oracle требует хорошего знания как семантики принципов поддержки прав доступа, так и физической реализации этих возможностей.

данные в любой таблице для выборки и изменения должны быть доступны ограниченному кругу пользователей;

для некоторых таблицы необходимо обеспечить выборочный доступ к ее столбцам;

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

Схема доступа к данным в реляционных СУБД базируется на принципах:

СУБД от имени конкретного пользователя выполняет операции над базой данных в зависимости от того, обладает ли конкретный пользователь правами на выполнение конкретных операций над конкретным объектом БД.

Объекты доступа – это элементы БД, доступом к которым можно управлять (разрешать или запрещать). Конкретный пользователь обладает конкретными правами доступа к конкретному объекту.

Привилегии (priveleges) – это операции, которые разрешено выполнять пользователю над конкретными объектами.

2.5.4.2. Механизм ролей в СУБД

Способы определения групп пользователей:

один и тот же идентификатор используется для доступа к БД целой группы физических лиц (например, сотрудников одного отдела);

конкретному физическому лицу присваивается уникальный идеентификатор.

Применяется также смешанный способ, при котором хранится идентификатор группы и уникальный идентификатор пользователя. Чаще всего группа пользователей соответствует структурному подразделению организации. Привилегии устанавливаются не только для отдельных пользователей, но и для их групп.

2.5.5. Защита информации в сетях

2.5.5.1. Общая характеристика сетевых атак

Классификация удаленных атак выполняется по различным критериям:

1. По характеру воздействия:

Пассивные – внешние, никак не влияют на работу вычислительной системы и на передаваемые данные (например, простое прослушивание);

Активные – оказывают непосредственное влияние на работу системы (изменение конфигурации распределенной вычислительной системы (РВС), нарушение работоспособности и т. д.).

2. По цели воздействия:

Угроза раскрытия (утечки) информации, т.е. перехват информации без цели модификации;

Угроза целостности – несанкционированный доступ к информации и возможность ее модификации;

Угроза отказа в обслуживании – нарушение работоспособности системы.

3. По моменту начала атаки:

По запросу от атакуемого объекта (DNS,ARP– запросы);

По наступлению ожидаемого события на атакуемом объекте (например, разрыв TCPсоединения);

Безусловные атаки – осуществляются немедленно и безотносительно к состоянию системы и атакуемого объекта.

4. По наличию обратной связи:

С обратной связью (на некоторые запросы, переданные на атакуемый объект, атакующему требуется получить ответ);

Без обратной связи.

5. По расположению субъекта атаки (источника атаки):

Внутрисегментное расположение источника;

Межсегментное.

6. По уровню OSI(МВОС)

2.5.5.2. Типовые угрозы безопасности

Типовая удаленная атака – это удаленное информационное разрушающее воздействие, программно осуществляемое по каналу связи, характерное для любой распределенной вычислительной системы (РВС).

Приведем характеристики типовых угроз в соответствии с рассмотренной классификацией:

1. Анализ сетевого трафика – внутрисегментные пассивные угрозы раскрытия без обратной связи, применяемые на физическом или канальном уровне.

2. Подмена объекта вычислительной системы – при установлении виртуального соединения, активное воздействие, угроза раскрытия или угроза целостности. Выполняется по событию. Захватывает канальный, сетевой или транспортный уровни.

3. Внедрение ложного объекта:

а) навязывание ложного маршрута, возможно из-за наличия протоколов, позволяющих удаленно изменять маршрутизацию в Интернет (протоколы RIP, OSPF, ICMP, SNMP);

б) использование недостатков алгоритмов удаленного доступа (протокол TCP, DNS-запрос).

4. Отказ в обслуживании (DoS) - активное воздействие; безусловная; межсегментное и внутрисегментное; на транспортном и прикладном уровнях.

2.5.5.3. Типовые атаки в сетях TCP/IP

Анализ трафика (sniffing)

Sniffingпозволяет изучить логику работыPBC, позволяет перехватить потоки данных, которыми обмениваются объекты – несанкционированный доступ к сети без модификации данных.

Защита: шифрование данных; также можно шифровать файлы и обмениваться на файловом уровне; коммутация Ethernet (рисунок 7); выделенный канал связи между объектами РВС.

Ложный ARP сервер.

Связь между двумя удаленными хостами осуществляется путем передачи по сети сообщений, которые заключены в пакеты обмена. В поле данных помещаются либо непосредственно данные, либо другой пакет более высокого уровня OSI. Так, например, пакет транспортного уровня может быть вложен в пакет сетевого уровня, который, в свою очередь, вложен в пакет канального уровня. Спроецировав это утверждение на сетевую ОС, использующую протоколы TCP/IP, можно утверждать, что пакет TCP (транспортный уровень) вложен в пакет IP (сетевой уровень), который, в свою очередь, вложен в пакет Ethernet (канальный уровень). Таким образом, структура TCP-пакета выглядит так, как показано на рисунке 8.

Для получения Ethernetадреса служит протоколARP. Он ставит в соответствие адресу сетевой карты адрес конкретного компьютера. Он работает следующим образом:

а) ЭВМ посылает широковещательный (всем сразу) ARP-запрос с требуемымIP-адресом.

б) ЭВМ с затребованным адресом посылает на Ethernet-адрес автора запроса ответ с указанием своегоEthernet-адреса. Запрашиваемая ЭВМ получает ответ и записывает паруIPиEthernetадресов в свою локальнуюARPтаблицу.

Механизм атаки: hostатакующего посылает ложныйARPответ и в будущем будет получать все данные, адресованные на другой адрес (рисунок 9).

Ложный DNS-сервер

Ложный DNSработает следующим образом:

Hostпосылает запрос на определение адреса информационно поисковомуDNSсерверу.

Если домен локальный, то сервер сам отвечает на запрос, иначе отсылает запрос корневому DNSсерверу.

Корневой сервер определяет локальный сервер для домена и отсылает ответ ему.

На любом этапе ответы кэшируются сервером и клиентом.

Выделяют 3 сценария атаки:

1) Перехват запроса и попытка ложного ответа.

2) Шторм ложных DNS ответов от имени настоящего DNS сервера.

3) Шторм ложных DNS ответов на атакуемый DNS сервер.

Как видно из приведенных формулировок, идеи атак достаточно близки к идее ложного ARP-сервера. СлужбаDNSработает по протоколуUDP, который отличается отTCPтем, что не гарантирует установление соединения и доставку.

Первый сценарий проиллюстрирован рисунком 10. Атакующий должен находиться на пути основного трафика или в сегменте настоящего DNS сервера.

Рисунок 9. Атака путем использования ложного ARP-сервера

а – фаза ожидания ARP-запроса; б – фаза атаки; в – фаза приема, анализа, воздействия и передачи перехваченной информации на ложном ARP-сервере

Рисунок 10. Атака путем перехвата запроса к DNS-серверу

а – фаза ожидания DNS-запроса; б – фаза передачи атакующим ложного DNS-ответа; в – фаза приема, анализа, воздействия и передачи перехваченной информации на ложном DNS-сервере

Суть второго сценария в том, что ложные DNS-ответы генерируются атакующим хостом постоянно, и атакуемый хост, обратившись сDNS-запросом, сразу получаетDNS-ответ от атакующего. В нем в качествеIP-адреса хоста поставлен адрес атакующего. В результате все запросы атакуемый будет направлять на адрес атакующего (рисунок 11).

Третий сценарий состоит в организации направленного потока ответов на DNS-сервер, в результате чего один из этих ответов сервер воспринимает как ответ на свой запрос и заносит его результаты, т.е.IP-адрес атакующего хоста, в свой кэш (рисунок 12).

использование файла hosts. (неудобный способ для большого количества машин);

использование протоколов ТСР вместо UDP;

для защищенности сети стараются избегать применения DNS – службы вообще.

Защита от Интернет-атак:

фильтры на входе и на выходе из сети, контроль маршрутов;

фиктивные адреса и шлюзы (socks,proxy);

использования TCP, а неUDP(named,NFS);

статические ARPиDNS;

шифрование трафика (IPSEC,SKIP,SSL,SSH);

туннелирование с шифрованием;

избегание широковещательных технологий (коммутация Ethernet, отказ от радиодоступа и асимметричных спутниковых подключений);

контроль за сообщениями CERTиCIAC(американские центры по компьютерной безопасности:www.cert.org иwww.ciac.org );

применение антивирусных средств (на почтовых серверах и в браузерах);

использование средств автоматизированного контроля безопасности (SATAN,SAFEsuite,RealSecure,JohnTheRipper,Orge).

Кроме того, для защиты от проникновения путем использования Web-приложений применяют следующие решения:

отключение Javaи всех видов языков сценариев, кромеJavaScript(не будут работать многие страницы);

применение онлайновых антивирусов (AVP);

выделение специальной ЭВМ для доступа в Интернет.

На сегодняшний день из технологий динамических страниц более-менее безопасными для клиентской ЭВМ в Интернете можно назвать только DHTML(HTML4.0) иJavaScript. Все остальное лучше отключить.

Рисунок 11. Атака путем организации шторма DNS-ответов от ложного сервера

а – фаза организации шторма ложных DNS-ответов; б – фаза получения атакуемым хостом DNS-ответа на свой запрос; в – фаза приема, анализа, воздействия и передачи перехваченной информации на ложном DNS-сервере

Рисунок 12. Атака путем организации шторма DNS-ответов на атакуемый DNS-сервер

а – фаза ожидания атакующим DNS-запроса от DNS-сервера (для ускорения атакующий генерирует необходимый DNS-запрос); б – фаза передачи атакующим ложного DNS-ответа на DNS-сервер; в – DNS-сервер выдает IP-адрес атакующего хоста в ответ на запросы

Стандарт Х.800 описывает основы безопасности в привязке к эталонной семиуровневой модели. Стандарт предусматривает следующие сервисы безопасности:

аутентификация (имеются в виду аутентификация партнеров по общению и аутентификация источника данных);

управление доступом - обеспечивает защиту от несанкционированного использования ресурсов, доступных по сети;

конфиденциальность данных - в Х.800 под этим названием объединены существенно разные вещи - от защиты отдельной порции данных до конфиденциальности трафика;

целостность данных – данный сервис подразделяется на подвиды в зависимости от того, что контролируется - целостность сообщений или потока данных, обеспечивается ли восстановление в случае нарушения целостности;

неотказуемость - данный сервис относится к прикладному уровню, т. е. имеется в виду невозможность отказаться от содержательных действий, таких, например, как отправка или прочтение письма.

Стандарт Х.509 описывает процедуру аутентификации с использованием службы каталогов. Впрочем, наиболее ценной в стандарте оказалась не сама процедура, а ее служебный элемент - структура сертификатов, хранящих имя пользователя, криптографические ключи и сопутствующую информацию. Подобные сертификаты - важнейший элемент современных схем аутентификации и контроля целостности.

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

Базовые протоколы, наиболее полезные с точки зрения безопасности, включают в себя - Ipsec,DNSsec,S/MIME,X.509v3,TLSи ассоциированные с ними. Наиболее проработанными на сегодняшний день являются вопросы защиты наIP-уровне. Спецификации семействаIPsecрегламентируют следующие аспекты:

управление доступом;

контроль целостности на уровне пакетов;

аутентификация источника данных;

защита от воспроизведения;

конфиденциальность (включая частичную защиту от анализа трафика);

администрирование (управление криптографическими ключами).

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

Туннелирование может применяться как на сетевом, так и прикладном уровнях. Например, стандартизовано туннелирование для IР и двойное конвертование для почты Х.400.

На транспортном уровне аутентичность, конфиденциальность и целостность потоков данных обеспечиваются протоколом TLS(TransportLayerSecurity,RFC2246). Подчеркнем, что здесь объектом защиты являются не отдельные сетевые пакеты, а именно потоки данных (последовательности пакетов). Злоумышленник не сможет переупорядочить пакеты, удалить некоторые из них или вставить свои.

На основе TLSмогут строиться защищенные протоколы прикладного уровня. В частности, предложены спецификации для НТТР надTLS.

2.5.5.5. Архитектура механизмов защиты информации в сетях ЭВМ

В модели ВОС различают следующие основные активные способы несанкционированного доступа к информации:

маскировка одного логического объекта под другой, обладающий большими полномочиями (ложная аутентификация абонента);

переадресация сообщений (преднамеренное искажение адресных реквизитов);

модификация сообщений (преднамеренное искажение информационной части сообщения);

блокировка логического объекта с целью подавления некоторых типов сообщений (выборочный или сплошной перехват сообщений определенного абонента, нарушение управляющих последовательностей и т. п.).

Перечень видов услуг, предоставляемых по защите информации, которые обеспечиваются с помощью специальных механизмов защиты:

Аутентификация равнозначного логического объекта (удостоверение подлинности удаленного абонента-получателя). Для аутентификации требуется, чтобы лежащий ниже уровень обеспечивал услуги с установлением соединения.

Аутентификация источника данных - подтверждение подлинности источника (абонента-отправителя) сообщения.

Управление доступом (разграничение доступа) - обеспечивает защиту от несанкционированного доступа к ресурсам, потенциально доступным посредством ВОС.

Засекречивание соединения - обеспечивает конфиденциальность всех сообщений, передаваемых пользователями в рамках данного соединения.

Засекречивание в режиме без установления соединения - обеспечивает конфиденциальность всех данных пользователя в сообщении (единственном сервисном блоке данных), передаваемом в режиме без установления соединения.

Засекречивание поля данных - обеспечивает конфиденциальность отдельных полей данных пользователя на всем соединении или в отдельном сервисном блоке данных.

Засекречивание трафика - препятствует возможности извлечения информации из наблюдаемого графика.

Целостность соединения с восстановлением - позволяет обнаружить попытки вставки, удаления, модификации или переадресации в последовательности сервисных блоков данных. При нарушении целостности предпринимается попытка ее восстановления.

Целостность соединения без восстановления.

Целостность поля данных в режиме с установлением соединения - обеспечивает целостность отдельного поля данных пользователя во всем потоке сервисных блоков данных.

Целостность поля данных в режиме без установления соединения - позволяет обнаружить модификацию выбранного поля в единственном сервисном блоке данных.

Целостность блока данных в режиме без установления соединения - обеспечивает целостность единственного сервисного блока данных при работе без установления соединения и позволяет обнаружить модификацию и некоторые формы вставки и переадресации.

Информирование об отправке данных – позволяет идентифицировать отправителя информации на стороне ее получателя.

Информирование о доставке – предоставляет отправителю информацию о факте получения данных адресатом.

Теоретически доказано, а практика защиты сетей подтвердила, что все перечисленные услуги могут быть обеспечены криптографическими средствами защиты, в силу чего эти средства и составляют основу всех механизмов защиты информации в ВС. Центральными при этом являются следующие задачи:

взаимное опознавание (аутентификация) вступающих в связь абонентов сети;

обеспечение конфиденциальности циркулирующих в сети данных;

обеспечение юридической ответственности абонентов за передаваемые и принимаемые данные.

Решение последней из названных задач обеспечивается с помощью так называемой цифровой (электронной) подписи.

Защита информации в субд. Защита баз данных

Защита на уровне СУБД

2.5.5. Защита информации в сетях