Защита информации. Обобщенная архитектура СУБД
Защита информации в БД В современных СУБД поддерживается один из двух наиболее общих подходов к вопросу обеспечения безопасности данных: Ø избирательный подход и Ø обязательный подход. В обоих подходах единицей данных или "объектом данных", для которых должна быть создана система безопасности, может быть как вся база данных целиком, так и любой объект внутри базы данных.
Отличия подходов Ø При избирательном подходе некоторый пользователь обладает различными правами (привилегиями или полномочиями) при работе с данными объектами. Разные пользователи могут обладать разными правами доступа к одному и тому же объекту. Это даёт значительную гибкость. Ø В случае обязательного подхода, наоборот, каждому объекту данных присваивается некоторый классификационный уровень, а каждый пользователь обладает некоторым уровнем допуска. При таком подходе доступом к определенному объекту данных обладают только пользователи с соответствующим уровнем допуска.
Отличия подходов Ø При избирательном подходе в БД вводится новый тип объектов БД — это пользователи (users). Каждому пользователю в БД присваивается уникальный идентификатор. Для дополнительной защиты каждый пользователь кроме уникального идентификатора снабжается уникальным паролем, причем если идентификаторы пользователей в системе доступны системному администратору, то пароли пользователей хранятся чаще всего в специальном кодированном виде и известны только самим пользователям.
Группы пользователей Ø Пользователи могут быть объединены в специальные группы (groups). Один пользователь может входить в несколько групп. В стандарте вводится группа PUBLIC, для которой должен быть определен минимальный стандартный набор прав. По умолчанию, каждый вновь создаваемый пользователь, если специально не указано иное, относится к группе PUBLIC. Ø Привилегии или полномочия пользователей или групп — это набор операций, которые они могут выполнять над объектами БД.
Роли Ø В ряде СУБД появилось понятие "роли". Роль (role) — это поименованный набор полномочий. Существует ряд стандартных ролей (гость, администратор), которые определены в момент установки сервера баз данных. Можно создавать новые роли, группируя в них произвольные полномочия. Введение ролей позволяет упростить управление привилегиями пользователей, структурировать этот процесс. Кроме того, введение ролей не связано с конкретными пользователями, поэтому роли могут быть определены и сконфигурированы до того, как определены пользователи системы.
Объекты БД, подлежащие защите Ø Пользователю может быть назначена одна или несколько ролей. Ø Объектами БД, которые подлежат защите, являются все объекты, хранимые в БД: q таблицы, q представления, q хранимые процедуры и q триггеры. Для каждого типа объектов есть свои действия, поэтому для каждого типа объектов могут быть определены разные права доступа.
Две концепции защиты Ø Аутентификация – проверка подлинности, т. е. подтверждение личности пользователя (login + parole), - даёт право на доступ к объектам БД. Ø Авторизация – проверка полномочий, процесс подтверждения определённых прав и разрешений пользователя. Самыми высокими правами и полномочиями обладает системный администратор или администратор сервера БД. Традиционно только этот тип пользователей может создавать других пользователей и наделять их определенными полномочиями.
Операторы GRANT и REVOKE В SQL определены два оператора: GRANT и REVOKE - предоставления и отмены привилегий. Оператор предоставления привилегий GRANT имеет следующий формат: GRANT {<список действий> | ALL PRIVILEGES } ON <имя_объекта> TO {<имя_пользователя> | PUBLIC } [WITH GRANT OPTION ] • Параметр ALL PRIVILEGES указывает, что разрешены все действия из допустимых для объектов данного типа.
Оператор GRANT • <имя_объекта> — задает имя конкретного объекта: таблицы, представления, хранимой процедуры, триггера. • <имя_пользователя> или PUBLIC определяет, кому предоставляются данные привилегии. • Параметр WITH GRANT OPTION является необязательным и определяет режим, при котором передаются не только права на указанные действия, но и право передавать эти права другим пользователям. Передавать права в этом случае пользователь может только в рамках разрешенных ему действий.
Оператор GRANT Для объекта типа таблица полным допустимым перечнем действий является набор из четырех операций: SELECT, INSERT, DELETE, UPDATE. При этом операция обновление может быть ограничена несколькими столбцами. Формат оператора GRANT для объекта типа таблица будет иметь следующий синтаксис: GRANT {[SELECT] [, INSERT] [, DELETE] [, UPDATE (<список столбцов>)]} ON <имя_таблицы> TO {<имя_пользователя> | PUBLIC } [WITH GRANT OPTION ]
Отмена привилегий REVOKE {<список операций> | ALL PRIVILEGES} ON <имя_объекта> FROM {<список пользователей> | PUBLIC } {CASCADE | RESTRICT } Параметры CASCADE или RESTRICT определяют, каким образом производится отмена привилегий. Параметр CASCADE отменяет привилегии не только пользователя, который непосредственно упоминался в операторе GRANT, но и всем пользователям, которым были присвоены привилегии с использованием параметра WITH GRANT OPTION.
Пример работы с оператором GRANT Пусть существуют три пользователя БД с именами user 1, user 2 и user 3. user 1 создал объект Tab 1, он является владельцем этого объекта и может передать права на работу с ним другим пользователям. user 2 является оператором, который должен вводить данные в Tab 1 (например, таблицу новых заказов), а пользователь user 3 является менеджером отдела, который должен регулярно просматривать введенные данные.
Пример работы с оператором GRANT Тогда задаём: GRANT INSERT ON Tab 1 TO user 2 GRANT SELECT ON Tab 1 TO user 3 Эти назначения означают, что user 2 имеет право только вводить новые строки в отношение Tab 1, а user 3 имеет право просматривать все строки в таблице Tab 1. Если менеджер отдела имеет право изменять цену (COST) на предоставляемые услуги, тогда операция GRANT выглядит так: GRANT SELECT, UPDATE (COST) ON Tab 1 TO user 3
Пример работы с оператором GRANT Если user 1 предполагает, что пользователь user 4 может его замещать, то он может предоставить этому пользователю все права по работе с созданной таблицей Tab 1. GRANT ALL PRIVILEGES ON Tab 1 TO user 4 WITH GRANT OPTION В этом случае user 4 может сам назначать привилегии по работе с таблицей Tab 1 в отсутствие владельца объекта user 1. Поэтому в случае появления нового оператора - user 5, пользователь user 4 может назначить ему права на ввод новых строк в таблицу: GRANT INSERT ON Tab 1 TO user 5
Пример работы с оператором GRANT Если при передаче полномочий набор операций над объектом ограничен, то пользователь, которому переданы эти полномочия, может передать другому пользователю только те полномочия, которые есть у него, или часть этих полномочий. Поэтому если user 4 были делегированы следующие полномочия: GRANT SELECT, UPDATE, DELETE ON Tab 1 TO user 4 WITH GRANT OPTION то пользователь user 4 не сможет передать полномочия на ввод данных пользователю user 5, потому что эта операция не входит в список разрешенных для него самого.
Пример работы с оператором REVOKE ALL PRIVILEGES ON Tab 1 FROM user 4 CASCADE В этом случае будут отменены привилегии и пользователя user 5, которому user 4 успел присвоить привилегии. Параметр RESTRICT ограничивает отмену привилегий только пользователю, непосредственно упомянутому в операторе REVOKE. Посредством оператора REVOKE можно отобрать все или только некоторые из ранее присвоенных привилегий по работе с конкретным объектом.
Представления Кроме назначения прав по работе с таблицами эффективным методом защиты данных может быть создание представлений, которые будут содержать только необходимые столбцы для работы конкретного пользователя и предоставление прав на работу с данным представлением пользователю. Поскольку представления могут соответствовать итоговым запросам, то в этом случае недопустимы операции изменения, и, => для таких представлений можно выполнять только оператор SELECT. Если представления соответствуют выборке из базовой таблицы, то допустимыми будут все 4 операции: SELECT, INSERT, UPDATE и DELETE.
Представления (VIEW) Представления – это таблицы, содержимое которых заимствовано из других таблиц, сами по себе VIEW не содержат данных. Представление – это запрос, который выполняется каждый раз, когда в операторе встречается ссылка на данное представление. На представления можно ссылаться в операторах SELECT, INSERT и др. CREATE VIEW London_staff AS SELECT snum, sname, city, comm FROM Salespeople WHERE city = ‘London’; Никакие данные не выводятся, создается лишь новый объект базы данных. Теперь можем к нему обратиться: SELECT * FROM London_staff;
Этапы жизненного цикла БД Жизненный цикл базы данных (ЖЦ БД) — это совокупность этапов, которые проходит база данных на своём пути от создания до окончания использования. Элементы данных более стабильны, чем выполняемые функции системы. Создание правильной структуры данных требует сложного анализа данных и отношений между ними. Если построить логичную схему БД, то в дальнейшем можно создать любое количество функциональных систем, использующих эту схему. Такой подход называется «ориентированный на данные» .
Этапы ЖЦ БД Этапы проектирования БД
Этапы проектирования БД 1. Системный анализ и словесное описание информационных объектов предметной области. 2. Инфологическая модель предметной области частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах ER-модели. 3. Даталогичеcкое проектирование БД, - описание БД в терминах принятой даталогической модели данных. 4. Физическое проектирование БД, - выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.
Транзакции и параллелизм Транзакция (transaction) – это логическая единица работы с БД, должна быть либо полностью выполнена, либо отменена. Параллелизм (concurrency) – механизм, с помощью которого СУБД предотвращает взаимное влияние операций, одновременно выполняемых над одними и теми же данными разными пользователями. Оператор COMMIT делает все изменения, выполняемые в ходе транзакции, постоянными. Оператор ROLLBACK – отменяет их (откат). После каждого из этих операций начинается новая транзакция. Оператор SAVEPOINT (точка сохранения) предназначена для установки в транзакции особых точек, куда в дальнейшем может быть произведен откат (при этом отката всей транзакции не происходит).
Типовые проблемы параллелизма 1. Потерянное обновление (lost update)
2. Преждевременное чтение (dirty read)
3. Неповторяющееся чтение (non-repeatable read)
4. Фантомная вставка (phantom insert)
Управление параллелизмом Все эти ситуации возникли из-за того, что транзакция #2 имеет доступ к промежуточным данным, формированным транзакцией #1. Механизмы, которые SQL использует для управления параллелизмом, называются блокировками (locks): • Пессимистические блокировки (pessimistic locks) – предотвращают доступ к данным при одновременных транзакциях. • Оптимистические блокировки (optimistic locks) – отслеживают возникновение конфликтов и при необходимости выполняют откат.
Свойства транзакции • Атомарность (atomicity) требует, чтобы все операции (части) транзакции были завершены. В противном случае транзакция отменяется. • Долговечность (durability) указывает на непрерывность устойчивого состояния БД. После завершения транзакции БД должна переходить в устойчивое состояние и это состояние не должно нарушаться даже при сбоях системы. • Сериализуемость (serializability) представляет собой возможность одновременного, точнее последовательного, выполнения нескольких транзакций. Это свойство имеет большое значение в многопользовательских и распределенных БД, где несколько транзакций с большой долей вероятности могут выполняться параллельно. • Изолированность (isolation) означает, что данные, использующиеся в одной транзакции, не могут использоваться другой транзакцией до тех пор, пока первая не будет завершена.
Управление транзакциями с помощью SQL Транзакция выполняется до тех пор, пока не произойдет одно из следующих четырех событий: 1. Достигнут оператор COMMIT. В этом случае все изменения записываются в БД. Оператор COMMIT автоматически завершает SQL-транзакцию. 2. Достигнут оператор ROLLBACK. В этом случае все изменения отменяются, и база данных возвращается в предыдущее устойчивое состояние. 3. Достигнут конец программы. В этом случае все изменения записываются в БД для постоянного хранения. Это событие эквивалентно выполнению оператора COMMIT. 4. Выполнение программы неожиданно прервано. В этом случае все изменения отменяются, и БД возвращается в предыдущее устойчивое состояние. Это событие эквивалентно выполнению оператора ROLLBACK.
Ограничения реляционных СУБД Современные СУБД идеально походят для таких традиционных приложений, как системы резервирования билетов или банковских систем, но их применение в системах автоматизации проектирования, интеллектуальных системах обучения и других системах, основанных на знаниях, часто является затруднительным. Ø Плоские нормализованные отношения универсальны и теоретически достаточны для представления данных любой предметной области. Однако в нетрадиционных приложениях в БД появляются сотни, иногда тысячи таблиц, над которыми постоянно выполняются операции соединения, необходимые для воссоздания сложных структур данных, присущих предметной области.
Ограничения реляционных СУБД Ø Другим серьезным ограничением реляционных систем являются их относительно слабые возможности по части представления семантики приложения. Самое большее, что обеспечивают реляционные СУБД, - это возможность формулирования и поддержки ограничений целостности данных. Исследователи в области БД выполняют многочисленные проекты, основанные на идеях, выходящих за пределы реляционной модели данных. Тематика современных исследований, относящихся к базам данных, исключительно широка. Рассмотрим короткий обзор наиболее важных направлений.
Три направления в области СУБД следующего поколения Ø Направление Postgres. Основная характеристика: максимальное следование (насколько это возможно с учетом новых требований) известным принципам организации СУБД. Ø Направление Exodus/Genesis. Основная характеристика: создание собственно не системы, а генератора систем, наиболее полно соответствующих потребностям приложений. Решение достигается путем создания наборов модулей со стандартизованными интерфейсами.
Три направления в области СУБД следующего поколения Ø Направление Starburst. Основная характеристика: достижение расширяемости системы к нуждам конкретных приложений путем использования стандартного механизма управления правилами. По сути дела, система представляет собой некоторый интерпретатор системы правил и набор модулей-действий, вызываемых в соответствии с этими правилами. Можно изменять наборы правил (существует специальный язык задания правил) или изменять действия, подставляя другие модули с тем же интерфейсом.
Скачать презентацию Защита информации Обобщенная архитектура СУБД Защита информации
Л9_Последняя лекция.ppt