Защита баз данных

	Загрузить архив:
	Файл: ref-23573.zip (49kb [zip], Скачиваний: 242) скачать

Protection of                  databases

Содержание

                                              

1. Введение                                                        

2. Защита информации

                           

·Понятие защиты информации

·Защита ПК от несанкционированного доступа                   

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

3. Реализация защиты в некоторых СУБД        

·Архитектура защиты Microsoft Access              

·MS SQL Server

- Организация защиты

- Вопросы безопасности доступа

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

- Тип подключения к SQL Server

- Роли

·Безопасность данных в Oracle 7

-    Ограничение доступа

-    Использование пакетов

4. Юридическая защита авторских прав на базы данных

5. Заключение

6. Список использованной литературы             

                                      

Введение

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

· обеспечивать получение общих и/или детализированных отчетов по итогам работы;

· позволять легко определять тенденции изменения важнейших показателей;

· обеспечивать получение информации, критической по времени, без существенных задержек;

· выполнять точный и полный анализ данных.

Современные СУБД в основном являются приложениями Windows, так как данная среда позволяет более полно использовать возможности персональной ЭВМ, нежели среда DOS. Снижение стоимости высокопроизводительных ПК обусловил не только широкий переход к среде Windows, где разработчик программного обеспечения может в меньше степени заботиться о распределении ресурсов, но также сделал программное обеспечение ПК в целом и СУБД в частности менее критичными к аппаратным ресурсам ЭВМ. Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, MicrosoftAccess, BorlanddBase, BorlandParadox, MicrosoftVisualFoxPro, MicrosoftVisualBasic, а также баз данных MicrosoftSQLServer и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер».

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

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

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

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

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

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

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

Защита информации

Понятие защиты информации

Защита информации — комплекс мероприятий, направленных на обеспечение важнейших аспектов информационной безопасно­сти (целостности, доступности и, если нужно, конфиденциальности информации и ресурсов, используемых для ввода, хранения, обра­ботки и передачи данных) [1].

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

Очевидно, что абсолютно безопасных систем нет, и здесь речь идет о надежной системе в смысле «система, которой можно дове­рять» (как можно доверять человеку). Система считается надежной, если она с использованием достаточных аппаратных и программных средств обеспечивает одновременную обработку информации раз­ной степени секретности группой пользователей без нарушения прав доступа.

Основными критериями оценки надежности являются: политика безопасности и гарантированность.

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

Выбор конкретных механизмов обеспечения безопасности сис­темы производится в соответствии со сформулированной политикой безопасности.

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

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

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

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

Граница ДВБ образует периметр безопасности. Компоненты ДВБ, находящиеся внутри этой границы, должны быть надежными (следо­вательно, для оценки надежности компьютерной системы достаточ­но рассмотреть только ее ДВБ). От компонентов, находящихся вне периметра безопасности, вообще говоря, не требуется надежности. Однако это не должно влиять на безопасность системы. Так как сей­час широко применяются распределенные системы обработки дан­ных, то под «периметром безопасности» понимается граница владе­ний определенной организации, в подчинении которой находится эта система. Тогда по аналогии то, что находится внутри этой границы, считается надежным. Посредством шлюзовой системы, которая спо­собна противостоять потенциально ненадежному, а может быть даже и враждебному окружению, осуществляется связь через эту границу.

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

Защита ПК от несанкционированного доступа

Как показывает практика, несанкционированный доступ (НСД) представляет одну из наиболее серьезных угроз для злоумышленно­го завладения защищаемой информацией в современных АСОД. Как ни покажется странным, но для ПК опасность данной угрозы по сравнению с большими ЭВМ повышается, чему способствуют следующие объективно существующие обстоятельства:

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

2) многие ПК служат коллективным средством обработки ин­формации, что обезличивает ответственность, в том числе и за за­щиту информации;

3) современныеПК оснащенынесъемными  накопителями на ЖМД очень большой емкости, причем информация на них сохра­няется даже в обесточенном состоянии;

4) накопители на ГМД производятся в таком массовом количе­стве, что уже используются для распространения информации так же, как и бумажные носители;

5) первоначально   ПК   создавались   именно   как   персональное средствоавтоматизации   обработки   информации,   а   потому  ине оснащались специально средствами защиты от НСД.

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

Основные механизмы защиты ПК от НСД могут быть представ­лены следующим перечнем:

1) физическая защита ПК и носителей информации;

2) опознавание  (аутентификация)  пользователей   ииспользуемых компонентов обработки информации;

3) разграничение доступа к элементам защищаемойинформации;

4)криптографическое закрытие защищаемой информации, хранимой на носителях (архивация данных);

5)криптографическое   закрытие   защищаемой   информациив процессе непосредственной ее обработки;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[WITH GRANT OPTION ]

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

GRANT INSERT

ON Tab1

ТО user2 GRANT SELECT

ONTab1

TOuser3

Эти назначения означают, что пользователь 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 были делегированы следующие полно­мочия:

GRANTSELECT. UPDATE. DELETE

ON Tab1

TO user4 WITH GRANT OPTION,

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

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

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

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

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

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

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

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

REVOKE ALL PRIVILEGES -ON Tab1 TO user4 CASCADE

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

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

REVOKE ALLPRIVILEGES ON Tab1 TO user4 RESTRICT

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

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

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

REVOKEINSERT ON Tab! TO user2.user4 CASCADE

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

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

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

REVOKEEXECUTE ONCOUNT_EXTOPUBLICCASCADE И теперь мы можем назначить новые права пользователю user4.

GRANT EXECUTE ON COUNT_EX TO user4

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

GRANTCREATE TABLE. ALTER TABLE,  DROP TABLE ON OB_LIB TO user1

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

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

GRANT CREATE DATABASE

ON SERVERJ) TO main user

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

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

Реализация защиты в некоторых СУБД

Архитектура защиты Access

Если у вас имеется опыт работы с защитой, используемой на сервере или большой ЭВМ, структура защиты в Access покажется вам знакомой. Вы можете указать пользователей, которым предоставляется или, наоборот, не разрешается доступ к объектам базы данных. Кроме того, вы можете определить группы пользователей и назначить разрешения на уровне группы, чтобы облегчить построение защиты для большого числа пользователей. Пользователю достаточно быть членом группы, чтобы получить права доступа, установленные для неё.

Access хранит информацию о защите в двух местах. Во время установки программа Setup создаст в папке ProgramFilesMicrosoft Ofice