Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Базы данных. Лекции по курсу. В 4 частях. Ч.4. Учебное пособие
.pdf
4. УПРАВЛЕНИЕ ДОСТУПОМ К ДАННЫМ
Защита данных является одной из главных функций СУБД. Защита
данных может рассматриваться с нескольких точек зрения.
1. Защита для обеспечения секретности, связанная с разрешением
использования данных, хранящихся в базе данных, только тем пользователям, которые имеют на это право. Решение этой задачи обеспечивается применением Login-процедур, а также использованием представлений.
В отдельных случаях для повышения уровня секретности используются собственные форматы хранения данных и сырое дисковое пространство.
2. Защита от несанкционированного доступа определяет права
на выполнение только разрешенных пользователю операций с базой
данных. В современных СУБД эта задача решается в рамках дискреционной, ролевой или мандатной модели безопасности. Решение первых
двух задач помогает решать и функция аудита.
3. Защита от разрушения базы данных при сбоях оборудования.
Для решения этой задачи используются функция резервного копирования, журнализации и восстановления данных.
Получение доступа к ресурсам Информационной системы предусматривает выполнение трех процедур: идентификации, аутентификации и авторизации.
4.1. LOGIN-ПРОЦЕДУРЫ
Процедуры идентификации и аутентификации являются
обязатель-
ными процедурами, обеспечивающими первую линию защиты любой
автоматизированной системы, в том числе Информационной системы
баз данных. Часто процедуры идентификации и аутентификации в автоматизированных системах называют Login-процедурами.
31
Сущность процедуры идентификации состоит в присвоении субъек-
там и объектам доступа уникального идентификатора.
Сущность процедуры аутентификации состоит в подтверждении
подлинности пользователя, представившего идентификатор. Процедура позволяет проверить, тот ли это человек (или устройство), за которого он себя выдает. Если некто, идентифицирующий себя как Вася,
переводит со счета на счет 5 тыс
. долларов, то неплохо было бы иметь
способ установить, что это действительно Вася, а не его брат-близнец
Петя.
Процедуры идентификации и аутентификации позволяют выпол-
нять следующие функции:
установление подлинности субъекта при его допуске в систему;
контролирование установленных полномочий в процессе сеанса
работы;
регистрацию действий и др.
Различные
СУБД позволяют по-разному задавать и хранить информацию об уникальном идентификаторе пользователя. Подсистема безопасности Oracle позволяет создавать пользователей базы данных посредством предложения:
CREATE USER IDENTIFIED пользователь BY пароль
Подсистема безопасности IBM DB2 может использовать идентификаторы пользователей ОС; ее синтаксис SQL не содержит предложения,
аналогичного предложению CREATE USER. СУБД Microsoft SQL Server
может использовать аутентификацию как пользователей баз данных,
так и пользователей ОС.
СУБД PostgreSQL использует концепцию ролей для управления разрешениями на доступ к базе данных. Концепция ролей включает в себя
концепцию пользователей (users) и групп (groups). Роль можно рассматривать как пользователя базы данных или как группу пользователей в
зависимости от того, как роль настроена. Роли могут владеть объектами
базы данных
(например, таблицами и функциями) и выдавать другим
ролям разрешения на доступ к этим объектам.
Для создания роли используется команда SQL CREATE ROLE:
CREATE ROLE имя [ [ WITH ] параметр [...]]
32
Существует также команда CREATE USER, которая является синонимом команды CREATE ROLE:
CREATE USER имя [[WITH ] параметр [...]]
У каждого подхода есть достоинства и недостатки, но все они позволяют строить корректные схемы определения подлинности пользователей.
В любой СУБД есть пользователь, который имеет неограниченные
привилегии. В PostgreSQL – это пользователь «postgres», в других СУБД
это может быть пользователь
«root». Учетные данные этих пользователей должны быть известны только администраторам сервера баз данных, защищены надежными паролями и использоваться исключительно
в задачах администрирования сервера баз данных.
Сущность процедуры авторизации состоит в определении перечня
конкретных информационных ресурсов, с которыми аутентифицированному пользователю разрешена работа.
Процедуры идентификации, аутентификации и авторизации обязательны
для любой защищенной Информационной системы.
Существует три типа схем, лежащих в основе конкретных процедур
аутентификации:
аутентификация, основанная на знании (пользователь обладает
некоторым конфиденциальным знанием);
аутентификация, основанная на наличии (пользователь обладает
некоторым конфиденциальным предметом);
аутентификация, основанная на проверке характеристик (пользо-
ватель предъявляет некоторые уникальные характеристики).
I. Аутентификация, основанная на
знании
Этот метод предполагает парольную защиту. При этом идентификатор пользователя выступает как заявка на идентификацию, а пароль –
подтверждение этой заявки.
Соответствующие процедуры с давних пор применялись в неавтоматизированном контуре. Например, это взаимное опознавание с помощью пароля и отзыва в военных и пограничных караулах. Достоинство –
простота, но она же
является и недостатком: пароль может быть не
только украден, подсмотрен, перехвачен, но и угадан.
33
Простейшей атакой противника на систему с фиксированными паролями является перебор всех возможных вариантов до тех пор, пока
истинный пароль не будет найден. Ниже перечислены методы, уменьшающие угрозу компрометации паролей.
1. Ограничение срока действия пароля
Как правило, максимальный срок действия пароля 30…60 дней; минимальный срока действия пароля – один-два дня,
после чего доступ за-
крывается.
2. Ограничение на содержание пароля: ограничение на длину па-
роля, наличие определенных видов символов и пр.
3. Блокирование терминала
В случае превышения максимально допустимого числа неудачных
попыток с одного терминала терминал блокируется.
4. Блокирование пользователя
Метод отличается от предыдущего тем, что блокируется не терминал, а учетная
запись.
5. Разовый пароль
Пароль автоматически меняется после каждого успешного входа в
систему.
II. Аутентификация, основанная на наличии
Предметами, аутентифицирующими владельца, могут быть смарткарты, электронные ключи, e-токены и пр.
Основная проблема при такой схеме в том, что аутентифицирующий
предмет может быть похищен или потерян. Поэтому обычно в Информационной системе
используется комплексная процедура, состоящая из
двух этапов. На первом этапе пользователь системы предъявляет предмет: электронный ключ, смарт-карту или e-токен, которые вводятся в
соответствующее устройство считывания. На втором этапе пользователь вводит свой персональный идентификационный номер (PIN) для
доказательства того, что он действительно владеет предметом и имеет
право доступа
к определенным информационным ресурсам.
III. Аутентификация, основанная на биометрических
характеристиках
Аутентификация, основанная на проверке биометрических характе-
ристик человека, предполагает использование отпечатков пальцев,
34
рисунка радужной оболочки глаза, почерка, которые уникальны. Преимущество технологии – аутентифицирующий предмет не может быть
потерян. В то же время, несмотря на многочисленные заявления о широком использовании этой методики, эйфория, связанная с нахождением «философского камня» аутентификации, представляется неоправданной. Основания для этого:
пользователем может быть и устройство, у
которого нет биологи-
ческих характеристик;
при двух последовательных входах биологические характери-
стики человека в точности никогда не совпадают;
большинство биологических характеристик человека меняется со
временем;
биологические характеристики могут испытывать кратковремен-
ные изменения (порезал палец);
требуется дорогостоящая аппаратура.
Не стоит впадать и в другую крайность, полностью отвергая
использование биометрических технологий для аутентификации пользователей Информационной системы. Эффективная система аутентификации
пользователей Информационной системы должна строиться на экономически оправданной комбинации всех трех основных схем.
4.2. МОДЕЛИ УПРАВЛЕНИЯ ДОСТУПОМ
Модель управления доступом определяет правила, по которым объекты базы данных доступны пользователям. В основу управления доступом могут быть
положены следующие принципы:
принцип минимальных привилегий: в соответствии с этим прин-
ципом каждый процесс, пользователь или программа должны иметь доступ к такой информации, которая минимально необходима для успешного выполнения его задач;
принцип открытой или закрытой системы: в открытой системе
разрешен доступ к тем объектам, для которых явно
нет запрета, в закрытой системе доступ к объекту разрешен только при наличии явного разрешения;
принцип централизованного и децентрализованного администри-
рования, отвечающий на вопрос, кто управляет привилегиями в модели
35
управления доступом: в случае централизованного администрирования
привилегий доступа один-единственный субъект контролирует доступ
ко всем объектам, в децентрализованной системе различные субъекты
контролируют доступ к различным объектам.
В современных системах баз данных разграничение доступа в СУБД
выполняется в рамках одной из трех моделей безопасности: дискреци-
онной (избирательной, Discretionary Access Control, DAC), ролевой (Role
Based Access Control, RBAC)
и мандатнай (Mandatory Access Control,
МАС). Возможны также комбинации этих политик.
4.2.1. ДИСКРЕЦИОННАЯ МОДЕЛЬ БЕЗОПАСНОСТИ
Дискреционная модель является простейшей одноуровневой моделью безопасности данных, которая строится на основе дискреционного
(избирательного) принципа разграничения доступа. Доступ к объектам
осуществляется на основе множества разрешенных отношений доступа
в виде троек: «субъект доступа – тип доступа – объект доступа».
Объектом защиты может быть таблица, представление, хранимая
процедура и т. д. (подробный список
объектов защиты имеется в доку-
ментации к используемой СУБД).
Субъектом защиты может быть пользователь, группа пользователей, роль, а также хранимая процедура. При этом хранимая процедура
имеет «двойной статус», поскольку она может быть и объектом защиты,
и субъектом защиты, и нужно очень внимательно рассмотреть возможные модели нарушителей разграничения прав доступа
.
Наглядным способом формализованного представления дискреционного доступа является матрица доступа, устанавливающая перечень
пользователей (субъектов) и перечень разрешенных операций (процессов) по отношению к каждому объекту базы данных (таблицы, запросы,
формы, отчеты).
В приведенной ниже таблице субъект доступа «Иванов» имеет право
читать объект доступа «Объект1» и право на создание, чтение, изменение и удаление объектов доступа «Объект2» и «Объект4».
36
Субъект
доступа
Иванов Ч ЧМСУ ЧМСУ Ч – чтение
Петров ЧСМ ЧМСУ ЧСМ М – модифи-
Сидоров ЧМСУ С – создание
Попов ЧМСУ ЧМСУ ЧМСУ ЧМ У – удаление
……….
Объект1
(продажи)
Объект2
(выплаты)
Объект3 Объект4 Объект5 Операция
кация
К объектам доступа «Объект3» и «Объект5» этот субъект доступа
прав не имеет. Субъект доступа «Сидоров» имеет право доступа на создание, чтение, изменение и удаление только к объекту доступа «Объект1».
4.2.2. РОЛЕВАЯ МОДЕЛЬ БЕЗОПАСНОСТИ
При работе c базой данных сотни пользователей могут проводить
над базой данных одни и те же операции. Каждому зарегистрированному пользователю группы могут быть заданы одни и те же привилегии
доступа к требуемым объектам базы данных. Однако схема авторизации
доступа при этом становится очень сложной (рис. 4.1).
Ролевая модель определяет особый тип политики
, основанный
на компромиссе между гибкостью управления доступом, характерным
для дискреционной модели, и жесткостью правил контроля доступа,
присущей мандатной модели. В ролевой модели классическое понятие
«субъект» разделяется на две части: пользователь и роль.
Пользователь – субъект, работающий с системой и выполняющий
определенные служебные обязанности. Роль идентифицирует динамически образуемую группу пользователей, каждый
из которых обладает,
во-первых, привилегией на исполнение этой роли и, во-вторых, всеми
привилегиями данной роли для доступа к объектам базы данных.
37
Рис. 4.1. Определение привилегий пользователей
В отличие от дискреционной модели привилегии доступа определяются не для субъектов, а для ролей, а субъекты могут принадлежать различным ролям. Множества субъектов, ролей и привилегий связаны по
типу «многие ко многим», что позволяет сформулировать следующие
утверждения, характеризующие ролевую модель:
один субъект может иметь несколько ролей;
одну роль
могут иметь несколько субъектов;
одна роль может иметь несколько привилегий;
одна привилегия может принадлежать нескольким ролям.
Как отмечалось выше, создание роли может быть выполнено пользователем, имеющим системную привилегию CREATE ROLE.
CREATE ROLE идентификатор_роли IDENTIFIED BY пароль_роли
Параметр IDENTIFIED BY пароль_роли указывает на то, что при использовании роли проводится аутентификация
4.2.3. УПРАВЛЕНИЕ ПРИВИЛЕГИЯМИ В ДИСКРЕЦИОННОЙ
И РОЛЕВОЙ МОДЕЛИ БЕЗОПАСНОСТИ
при помощи пароля.
Привилегиями доступа называют разрешение на использование
определенной услуги управления данными для доступа к объекту данных (создание, чтение, запись, исполнение, удаление), предоставляемое
38
идентифицированному пользователю. Предоставление и изъятие прав
р
на защищаемый объект зарегистрированному пользователю или созданной роли осуществляется с помощью SQL-операторов GRANT
и REVOKE:
GRANT привилегия [ON объект] TO субъект [WITH GRANT OPTION]
REVOKE привилегия [ON объект] FROM субъект
Различают два подхода к управлению доступом:
добровольное управление доступом;
принудительное управление доступом.
Добровольное управление доступом заключается в том, что права
на
доступ к объектам определяют их владельцы. Права владения объектами могут передаваться. В результате добровольный способ реализует
полностью децентрализованный принцип организации и управления
процессом разграничения доступа. Такой подход обеспечивает гибкость
настраивания системы разграничения доступа к базе данных, но делает
довольно сложным общий контроль и аудит состояния безопасности
данных в
системе.
При принудительном подходе к управлению доступом в базе данных
выделяется специальный доверенный субъект (администратор), который
определяет привилегии на доступ всех остальных субъектов к объектам
базы данных. Принудительный способ обеспечивает более жесткое централизованное управление доступом, вместе с тем он менее гибкий.
На практике в большинстве случаев применяется комбинированный
способ
управления доступом, когда определенная часть полномочий на
доступ к объектам устанавливается администратором, а другая часть –
владельцами объектов.
Все привилегии разделяются на две группы: системные привилегии,
используемые в случае принудительного способа управления доступом,
и привилегии доступа к объекту, используемые в случае добровольного
способа управления доступом.
Системные п
Create [any] table
Drop/Alter/ any table
Insert/Update/Select any table
Lock any table
ивилегии Привилегии доступа к объекту
Insert ON объект
Update ON объект
Delete ON объект
Execute ON объект
39
Create [any] view
Create/Drop/Execute/Alter any procedure
Create/Drop/Execute/Alter any trigger
Index ON объект
………………………………
Create/Drop/Alter user
Create/Drop/Execute/Alter any index
…………………………………….
С помощью системных привилегий (принудительное управление доступом) администратор дает разрешение пользователям выполнять
те или иные операции (право создавать таблицы, выполнять операции
с ними (I, U, D), создавать и уничтожать процедуры, триггеры, any –
в любой схеме), с помощью привилегий доступа к объекту владелец
объекта может передавать права на выполнение
операции с объектом
(on объект) другому пользователю (добровольное управление доступом).
Неотъемлемое право удалять объект имеет только его владелец.
Объекту можно назначить нового владельца с помощью команды
ALTER для соответствующего типа объекта, например:
ALTER TABLE имя_таблицы OWNER ТО новый_владелец
В общем случае набор привилегий и правила работы с ними зависят
от
реализации СУБД и определяются производителем.
Ниже приведено несколько примеров, написанных в диалекте СУБД
Oracle, иллюстрирующих принцип минимальных привилегий.
Пример 1. Работа с системными привилегиями
Созданы два пользователя u1 и u2. Пользователю u1 предоставлена
системная привилегия CREATE TABLE. Команда создания таблицы
Tab1 в собственной схеме проходит успешно, но создать таблицу
в схеме пользователя u2
не удается.
SQL> CONNECT adm/admpsw;
Соединено.
SQL> create user u1 identified by ulpsw default tablespace users;
Пользователь создан.
SQL> grant connect to u1;
Привилегии предоставлены.
40
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]