Безопасность баз данных. 5
Негосударственное образовательное учреждение высшего профессионального образования Московский технологический институт «ВТУ» |
Факультет Техники и современных
технологий
КУРСОВАЯ РАБОТА
по дисциплине База данных
« Безопасность баз данных »
Уровень образования бакалавриат
Направление Информатика и вычислительная техника 230100
Профиль Программное обеспечение вычислительной техники и автоматизированных систем
Выполнил (а):
Студент (ка) 3 курса
Форма обучения Экстернат
Москва 2013
Оглавление
ВВЕДЕНИЕ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1. Защита информации. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Понятие защиты информации. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- Защита ПК от несанкционированного доступа . . . . . . . . . . . . . . . . . . . . . . 6
- Защита информации в базах данных. . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
2. Реализация защиты в некоторых СУБД. . . . . . . . . . . . . . . . . . . . . . . . . . .17
2.1 Архитектура защиты Microsoft Access. . . . . . . . . . . . .. . . . . . . . . . . . . .17
2.2 Microsoft SQL Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . .19
-Управление доступом . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .19
- Тип подключения к SQL Server. . . .. . . . . . . . . . .. . .. . . . . . . . .. . . . . .. . .21
- Организация защиты.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
- Пользователи базы данных и их роли. . . . . . . . . . . . . . . . . . . . . . . . . . . .27
2.3 Безопасность данных в Oracle 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
- Ограничение доступа. . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
- Использование пакетов. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3. Юридическая защита авторских прав на базы данных. . . . . . . . . . . . . . .36
ЗАКЛЮЧЕНИЕ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ . . . . . . . . . . . . . . . . . . . . . . 42
ПРИЛОЖЕНИЯ. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . 43
1 Защита информации
1.1 Понятие защиты информации
Защита информации — комплекс мероприятий, направленных на обеспечение важнейших аспектов информационной безопасности (целостности, доступности и, если нужно, конфиденциальности информации и ресурсов, используемых для ввода, хранения, обработки и передачи данных).
В то время как информационная безопасность — это общее понятие для защиты информационной среды, защита информации представляет собой деятельность по предотвращению утечки защищаемой информации, несанкционированных и непреднамеренных воздействий на защищаемую информацию.
Система называется безопасной, если она, используя соответствующие аппаратные и программные средства, управляет доступом к информации так, что только должным образом авторизованные лица или же действующие от их имени процессы получают право читать, писать, создавать и удалять информацию.
Не секрет, что абсолютно
безопасных систем не существует, и
речь идет о надежной системе на
которую можно положиться. Система
считается надежной, если она с
использованием достаточных аппаратных
и программных средств
Степень доверия, или надежность систем, оценивается по двум основным критериям: политика безопасности и гарантированность.
Активным компонентом
защиты, включающим в себя анализ возможных
угроз и выбор мер
В зависимости от
сформулированной политики
Гарантированность это мера
доверия, которая может быть оказана
архитектуре и реализации системы.
Гарантированность может
Гарантированность показывает,
насколько уместны механизмы, отвечающие
за проведение в жизнь политики безопасности.
Гарантированность можно
Важным средством обеспечения
безопасности является механизм подотчетности
(протоколирования). Надежная система
должна фиксировать все события,
касающиеся безопасности. Ведение протоколов
должно дополняться аудитом, то есть
анализом регистрационной информации.
Компоненты вне вычислительной базы могут быть и не надежными, однако это не должно влиять на безопасность системы в целом. В итоге, для оценки надежности компьютерной системы достаточно рассмотреть только ее вычислительную базу. Так как на данном этапе времени широко применяются распределенные системы обработки данных, то под «периметром безопасности» понимается область владений определенной организации, в подчинении которой находится эта система. Тогда по аналогии то, что находится внутри этой области, считается надежным. Посредством шлюзовой системы, которая способна противостоять потенциально ненадежному, осуществляется связь через границу.
Главным назначением надежной вычислительной базы является выполнение функции монитора обращений, то есть контроль допустимости выполнения субъектами определенных операций над объектами. Монитор контролирует каждое обращение пользователя к программам или данным на предмет согласованности со списком действий, допустимых для пользователя.
В следствии монитора
обращений требуется
- Полнота. Монитор должен вызываться при каждом обращении, не должно быть способов его обхода;
- Верифицируемость. Монитор должен быть компактным, чтобы его можно было проанализировать и протестировать, будучи уверенным в полноте тестирования;
- Изолированность. Монитор должен быть защищен от отслеживания своей работы.
Ядром безопасности называется реализация монитора обращений. Это основа, на которой строятся все защитные механизмы.Кроме перечисленных выше свойств монитора обращений, ядро должно гарантировать собственную неизменность.
1.2 Защита ПК от несанкционированного доступа
Можно наблюдать из практики , несанкционированный доступ (НСД) представляет одну из главных угроз для злоумышленного завладения защищаемой информацией в современных АСОД. Злоумышленник – это нарушитель, намеренно идущий на нарушение. Внешний нарушитель может осуществлять НСД следующими способами:
- через автоматизированные рабочие места, подключенные к сетям общего пользования или сетям международного обмена (например, Интернет);
- с помощью программного воздействия на защищаемую информацию (программные закладки, вирусы и др.);
- через элементы автоматизированной системы, которые побывали за пределами контролируемой зоны (например, съемные носители информации);
По сравнению с большими
ЭВМ для ПК опасность данной
угрозы повышается, чему способствуют
следующие объективно
- первоначально ПК создавались именно как персональное средство автоматизации обработки информации, а потому и не оснащались специально средствами защиты от НСД;
- современные ПК оснащены несъемными накопителями на ЖД очень большой емкости, причем информация на них сохраняется даже в обесточенном состоянии;
- многие ПК служат коллективным средством обработки информации, что обезличивает ответственность, в том числе и за защиту информации;
- подавляющая часть ПК располагается непосредственно в рабочих комнатах специалистов, что создает благоприятные условия для доступа к ним посторонних лиц;
- накопители на ГД производятся в таком массовом количестве, что уже используются для распространения информации так же, как и бумажные носители.
В итоге всего следует те пользователи
, которые хотят сохранить
Главными механизмами защиты ПК от несанкционированного доступа могут быть представлены следующими пунктами:
- регистрация всех обращений к защищаемой информации. Ниже излагаются общее содержание и способы использования перечисленных механизмов;
- криптографическое закрытие защищаемой информации в процессе непосредственной ее обработки;
- разграничение доступа к элементам защищаемой информации;
- опознавание (аутентификация) пользователей и используемых компонентов обработки информации;
- физическая защита ПК и носителей информации.
- криптографическое закрытие защищаемой информации, хранимой на носителях (архивация данных);
Что касается данных, то очень важно, чтобы их могли обрабатывать только уполномоченные лица. Для предотвращения мер несанкционированного доступа к данным, вы можете использовать следующие средства:
- пароль первое в истории и наиболее распространенное средство защиты от несанкционированного использования компьютера; хороший пароль должен быть длинным и сложным, содержать большие и маленькие буквы, цифры, и отсутствующие в обычном алфавите знаки;
- физические ресурсы позволяют ограничить реальный доступ к носителям данных;
- шифрование обеспечивает конфиденциальность, что делает возможным обработку данных, только доверенным лицом (лицами). В результате шифрования, читаемая форма информации меняется в нечитаемую. Вы можете ограничить доступ, как к файлам, средствам массовой информации, так и к носителям данных;
- биометрические устройства предоставляют доступ к данным, по отпечаткам пальцев и сканируя радужную оболочку глаз.
1.3 Защита информации в базах данных
Основной формой организации информационных массивов в ИС являются базы данных. Базу данных можно определить как совокупность взаимосвязанных хранящихся вместе данных при наличии такой минимальной избыточности, которая допускает их использование оптимальным образом для одного или нескольких приложений. В отличие от файловой системы организации и использования информации , БД существует независимо от конкретной программы и предназначена для совместного использования многими пользователями. Такая централизация и независимость данных в технологии БД потребовали создания соответствующих СУБД - сложных комплексов программ, которые
обеспечивают выполнение операций корректного размещения данных, надежного их хранения, поиска, модификации и удаления.
В настоящее время СУБД поддерживается один из двух наиболее общих подходов к вопросу обеспечения безопасности данных: избирательный и обязательный подход. В таких подходах единицей данных или «объектом данных», для которых должна быть создана система безопасности, может быть как любой объект внутри базы данных, так и вся база данных целиком.
Два данных подхода имеют
следующие отличительные
- В случае избирательного управления, наоборот, каждому объекту данных присваивается некоторый классификационный уровень, а каждый пользователь обладает некоторым уровнем допуска. При таком подходе доступом к определенному объекту данных обладают только пользователи с соответствующим уровнем допуска.
- В случае избирательного управления некоторый пользователь обладает различными правами (привилегиями или полномочиями) при работе с данными объектами. Разные пользователи могут обладать разными правами доступа к одному и тому же объекту. Избирательные права характеризуются значительной гибкостью.
Следующие методы предусмотрены для реализации изберательного принципа. Для реализации избирательного принципа предусмотрены следующие методы. В базу данных вводится новый тип объектов БД — это пользователи. Каждому пользователю в БД присваивается уникальный идентификатор. Для дополнительной защиты каждый пользователь кроме уникального идентификатора снабжается уникальным паролем, причем если идентификаторы пользователей в системе доступны системному администратору, то пароли пользователей хранятся чаще всего в специальном кодированном виде и известны только самим пользователям.
Пользователи могут быть объединены в специальные группы пользователей. Один пользователь может входить в несколько групп. В стандарте вводится понятие группы PUBLIC, для которой должен быть определен минимальный стандартный набор прав. По умолчанию предполагается, что каждый вновь создаваемый пользователь, если специально не указано иное, относится к группе PUBLIC.
Набор действий (операций), которые
они могут выполнять над
В последних версиях ряда
коммерческих СУБД появилось понятие
«роли». Ролью является поименованный
набор полномочий. Существует ряд
стандартных ролей, которые определены
в момент установки сервера баз
данных. И имеется возможность
создавать новые роли, группируя
в них произвольные полномочия. Введение
ролей позволяет упростить
Пользователю может быть присвоена одна или несколько ролей.Объектами БД, которые подлежат защите, являются все объекты, хранимые в БД: таблицы, представления, хранимые процедуры и триггеры. Для каждого типа объектов есть свои действия, поэтому для каждого типа объектов могут быть определены разные права доступа.
Самыйe элементарные уровни концепции обеспечения безопасности баз данных исключительно просты. Необходимо поддерживать два фундаментальных принципа: проверку полномочий и проверку подлинности.
Проверка полномочий состоит в том, что каждому пользователю или процессу информационной системы соответствует набор действий, которые он может выполнять по отношению к определенным объектам. Проверка подлинности означает достоверное подтверждение того, что пользователь или процесс, пытающийся выполнить санкционированное действие, действительно тот, за кого он себя выдает.
Система назначения полномочий имеет в некотором роде иерархический характер. Самыми высокими правами и полномочиями обладает системный администратор или администратор сервера БД. Традиционно только этот тип пользователей может создавать других пользователей и наделять их определенными полномочиями.
СУБД в своих системных каталогах сохраняет как данные самих пользователей, так и описание их привилегий по отношению ко всем объектам.
В последующем схема
В ряде СУБД вводится следующий уровень
иерархии пользователей — это
администратор БД. В этих СУБД один
сервер может управлять множеством
СУБД (например, MS SQL Server, Sybase). В СУБД
Oracle применяется однобазовая
В стандарте SQL определены два оператора: GRANT и REVOKE соответственно предоставления и отмены привилегий.
Оператор предоставления привилегий имеет следующий формат:
GRANT {<список действий | ALL PRIVILEGES }
ON <имя_объекта> ТО (<имя_пользователя> ] PUBLIC } [WITH GRANT OPTION ]
Здесь список действий определяет набор действий из общедопустимого перечня действий над объектом данного типа.
Параметр ALL PRIVILEGES указывает, что разрешены все действия из допустимых для объектов данного типа.
<имя_обьекта> — задает
имя конкретного объекта:
<имя_пользователя> или PUBLIC определяет, кому предоставляются данные привилегии.
Параметр WITH GRANT OPTION является необязательным и определяет режим, при котором передаются не только права на указанные действия, но и право передавать эти права другим пользователям. Передавать права в этом случае пользователь может только в рамках разрешенных ему действий.
Рассмотрим пример, пусть
у нас существуют три пользователя
с абсолютно уникальными
User1 создал объект Таb1, он является владельцем этого объекта и может передать права на работу с эти объектом другим пользователям. Допустим, что пользователь user2 является оператором, который должен вводить данные в Таb1 (например, таблицу новых заказов), а пользователь user 3 является большим начальником (например, менеджером отдела), который должен регулярно просматривать введенные данные.
Для объекта типа таблица полным допустимым перечнем действий является набор из четырех операций: SELECT, INSERT, DELETE, UPDATE. При этом операция обновление может быть ограничена несколькими столбцами.
Общий формат оператора назначения
привилегий для объекта типа таблица
будет иметь следующий
GRANT {[SELECT][.INSERT][,DELETED[.
ТО {<имя_пользователя> PUBLIC }
[WITH GRANT OPTION ]
Тогда резонно будет выполнить следующие назначения:
GRANT INSERT
ON Tab1
ТО user2 GRANT SELECT
ON Tab1
TO user3
Эти назначения означают, что пользователь user2 имеет право только вводить новые строки в отношение Таb1> а пользователь user3 имеет право просматривать все строки в таблице Таb1.
При назначении прав доступа на операцию модификации можно уточнить, значение каких столбцов может изменять пользователь. Допустим, что менеджер отдела имеет право изменять цену на предоставляемые услуги. Предположим, что цена задается в столбце COST таблицы Таb1. Тогда операция назначения привилегий пользователю user3 может измениться и выглядеть следующим образом:
GRANT SELECT. UPDATE (COST) ON Tab1 TO user3
Если наш пользователь user1 предполагает, что пользователь user4 может его замещать в случае его отсутствия, то он может предоставить этому пользователю все права по работе с созданной таблицей Таb1.
GRANT ALL PRIVILEGES
ON Tab1
TO user4 WITH GRANT OPTION
В этом случае пользователь user4 может сам назначать привилегии по работе с таблицей Таb1 в отсутствие владельца объекта пользователя 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 TO user4 CASCADE
будут отменены привилегии и пользователя user5, которому пользователь user4 успел присвоить привилегии.
Параметр RESTRICKT ограничивает отмену привилегий только пользователю, непосредственно упомянутому в операторе REVOKE. Но при наличии делегированных привилегий этот оператор не будет выполнен. Так, например, операция:
REVOKE ALL PRIVILEGES ON Tab1 TO user4 RESTRICT
не будет выполнена, потому что пользователь user4 передал часть своих полномочий пользователю user5.
Посредством оператора REVOKE можно отобрать все или только некоторые из ранее присвоенных привилегий по работе с конкретным объектом. При этом из описания синтаксиса оператора отмены привилегий видно, что можно отобрать привилегии одним оператором сразу у нескольких пользователей или у целой группы PUBLIC.
Поэтому корректным будет
следующее использование
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 различных привилегий.

- Безопасность баз данных
- Безопасность баз данных
- Безопасность базы данных
- Безопасность буровых работ
- Безопасность в АПК
- Безопасность в гостиницах
- Безопасность в гостинице
- Безопасное управление автомототранспортом
- Безопасности труда
- Безопасность
- Безопасность IP-телефонии
- Безопасность автомобиля
- Безопасность баз данных
- Безопасность баз данных