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

Автор работы: Пользователь скрыл имя, 29 Декабря 2012 в 22:11, дипломная работа

Краткое описание

Достижение поставленной цели и подтверждения гипотезы потребовало решения следующих задач:
Выявление угроз безопасности баз данных, последствия, реализация последствий;
Указать основные принципы обеспечения защиты информации;
Обеспечение безопасности данных;
Проанализировать защиту информации в среде MS SQL Server ЗАТО Александровск.

Содержание

ВВЕДЕНИЕ 3
ГЛАВА 1. ИСТОЧНИКИ ВОЗНИКНОВЕНИЯ И ПОСЛЕДСТВИЯ РЕАЛИЗАЦИИ УГРОЗ БАЗ ДАННЫХ 6
1.1. Классификация источников угроз 6
1.2. Воздействие вредоносных прорамм 9
1.3. Реализации возникновения угроз безопасности баз данных 12
Выводы по первой главе 14
ГЛАВА 2. ЗАЩИТА БАЗ ДАННЫХ И СИСТЕМА УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ 16
2.1. Основные понятия о базах данных 16
2.2. Методы и средства защиты информации 18
2.3. Особенности защиты информации в базах данных 22
Выводы по второй главе 27
ГЛАВА 3. ЗАЩИТА ДАННЫХ В СРЕДЕ MS SQL SERVER МУНИЦИПАЛЬНОГО ОБРАЗОВАНИЯ ЗАТО АЛЕКСАНДРОВСК 28
3.1. Защита и управление доступом 28
3.2. Администрирование системы безопасности 31
3.3. Предоставление и отмена предоставленных привилегий пользователю 33
Отмена предоставленных пользователям привилегий. 33
3.4. Реализация прав на доступ к объектам баз данных в среде MS SQL Server 35
Предоставление прав 37
Права на выполнение команд SQL 38
Выводы по третьей главе 40
ЗАКЛЮЧЕНИЕ 42
ГЛОССАРИЙ 45
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 47
СПИСОК СОКРАЩЕНИЙ 50
ПРИЛОЖЕНИЯ 51

Вложенные файлы: 1 файл

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

— 271.50 Кб (Скачать файл)

sp_addlogin ,    [@login=]   'учетная_запись'

[, [@password=]    'пароль') ]

[, [@defdb=]   'база_данных_по_умолчанию']

После завершения аутентификации и получения идентификатора учетной записи «login ID» пользователь считается зарегистрированным, и ему предоставляется доступ к серверу. Для каждой базы данных, к объектам которой он намерен получить доступ, учетная запись пользователя «login» ассоциируется с пользователем «user» конкретной базы данных, что осуществляется посредством процедуры:

sp_adduser    [@loginame=]   'учетная_запись'

[, [@name_in_db=]   'имя_пользователя']

[, [@grpname=]   'имя_роли']

Отобразить  учетную запись Windows 2003 в имя пользователя позволяет хранимая процедура:

sp_grantdbaccess   [@login=]   'учетная_запись'

[, [@name_in_db=]'имя_пользователя']

Пользователь, который создает объект в базе данных (таблицу, хранимую процедуру, просмотр), становится его владельцем. Владелец объекта (database object owner dbo) имеет все права доступа к созданному им объекту. Чтобы пользователь мог создать объект, владелец базы данных «dbo» должен предоставить ему соответствующие права. Полное имя создаваемого объекта включает в себя имя создавшего его пользователя.

Владелец объекта  не имеет специального пароля или  особых прав доступа. Он неявно имеет  полный доступ, но должен явно предоставить доступ другим пользователям. [5, 177]

SQL Server позволяет передавать права владения от одного пользователя другому с помощью процедуры:

sp_changeobjectowner   [@objname=]   'имя_объекта'

[@newowner=]   'имя_владельца'

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

В SQL Server реализовано два вида стандартных ролей: на уровне сервера и на уровне баз данных. При установке SQL Server создаются фиксированные роли сервера (например, «sysadmin» с правом выполнения любых функций SQL-сервера) и фиксированные роли базы данных (например, «db_owner» с правом полного доступа к базе данных или «db_accessadmin» с правом добавления и удаления пользователей). Среди фиксированных ролей базы данных существует роль «public», которая имеет специальное назначение, поскольку ее членами являются все пользователи, имеющие доступ к базе данных.

Можно включить любую учетную запись SQL Server «login» или учетную запись Windows 2003/XP в любую роль сервера.

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

В роль базы данных можно включить пользователей SQL Server, роли SQL Server, пользователей Windows 2003/XP.

Различные действия по отношению к роли осуществляются при помощи специальных процедур:

  • создание новой роли:

sp_addrole    [@rolename=]   'имя_роли'

[, [@ownername=]   'имя_владельца']

  • добавление пользователя к роли:

sp_addrolemember  (@rolename=]   'имя_роли',

[@membername=]   'имя_пользователя'

  • удаление пользователя из роли:

sp_droprolemember  [@rolename=]   'имя_роли',

[@membername=]   'имя_пользователя'

  • удаление роли:

sp_droprole  [@rolename=]   'имя_роли'

    1. Предоставление и отмена предоставленных привилегий пользователю

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

<предоставление_привилегий>:: =

GRANT  {<привилегия>[,...n]   |   ALL PRIVILEGES}

ON имя_объекта

ТО {<идентификатор_пользователя>  [,...п] |   PUBLIC}

[ WITH GRANT OPTION]

Параметр <привилегия> представляет собой:

<привилегия>::=

{SELECT   |   DELETE   |   INSERT   [(имя_столбца[,...n])]

|  UPDATE  [(имя_столбца[,...n])]}

|   REFERENCES   [(имя_столбца[,...n])]   |   USAGE   }

Из соображений  упрощения в операторе GRANT можно указать ключевое слово «ALL PRIVILEGES», что позволит предоставить указанному пользователю все существующие привилегии без необходимости их перечисления. Кроме того, в этом операторе может указываться ключевое слово PUBLIC, означающее предоставление доступа указанною типа не только всем существующим пользователям, но также и всем тем, кто будет определен в базе данных впоследствии.

Параметр «имя_объекта» может использоваться как имя таблицы базы данных, представления, домена, набора символов, проверки.

Благодаря параметру «WITH GRANT OPTION», указанные в операторе «GRANT» пользователи имеют право передавать все предоставленные им в отношении указанного объекта привилегии другим пользователям, которые, в свою очередь, будут наделены точно таким же правом передачи своих полномочий. Если данный параметр не будет указан, получатель привилегии не сможет передать свои права другим пользователям. Таким образом, владелец объекта может четко контролировать, кто получил право доступа к объекту и какие полномочия ему предоставлены.

Отмена предоставленных пользователям  привилегий.

В языке SQL для  отмены привилегий, предоставленных  пользователям посредством оператора «GRANT», используется оператор «REVOKE». С помощью этого оператора могут быть отменены все или некоторые из привилегий, полученных указанным пользователем раньше. Оператор «REVOKE» имеет следующий формат:

<отмена_привилегий>::=

REVOKЕ [GRANT OPTION FOR]   {<привилегия>[, ...n]

|   ALL   PRIVILEGES}

ON имя_объекта

FROM {<идентификатор_пользователя> [,...n] | PUBLIC}

[RESTRICT   |   CASCADE]

Ключевое слово «ALL PRIVILEGES» означает, что для указанного пользователя отменяются все привилегии, предоставленные ему ранее тем пользователем, который ввел данный оператор. Необязательная фраза «GRANT OPTION FOP» позволяет для всех привилегий, переданных в исходном операторе «GRANT» фразой «WITH GRANT OPTION», отменять возможность их передачи независимо от самих привилегий.

Если в операторе  указано ключевое слово «RESTRICT», успешное выполнение команды «REVOKE» возможно лишь в том случае, когда перечисленные в операторе привилегии не могут послужить причиной появления у каких-либо других пользователей так называемых «оставленных» привилегий. С помощью параметра «CASCADE» удаляются все привилегии, которые иначе могли бы остаться у других пользователей.

«Оставленными» являются привилегии, сохранившиеся у пользователя, которому они в свое время были предоставлены с помощью параметра «GRANT OPTION».

Поскольку наличие  привилегии необходимо для создания определенных объектов, вместе с ее удалением можно лишиться права, за счет использования которого был образован тот или иной объект (подобные объекты называются «брошенными»). Если в результате выполнения оператора «REVOKE» могут появиться брошенные объекты (например, представления), оно будет отменено при условии, что в нем не указывается ключевое слово «CASCADE». Если ключевое слово «CASCADE» в операторе присутствует, то для любых брошенных объектов, возникающих при выполнении исходного оператора «REVOKE», будут автоматически выданы операторы «DROP». [5, 243]

    1. Реализация прав на доступ к объектам баз данных в среде MS SQL Server

Предоставление прав

Для управления разрешением пользователя на доступ к объектам базы данных используется команда:

<предоставление_привилегий>::=

GRANT  {  ALL   [   PRIVILEGES]   |   <привилегия>   [,...n]}

{   [ ( имя_столбца  [, …n])]  ON { имя_таблицы |

имя_просмотра}   |  ON {имя_таблицы |

имя_просмотра  }   ([имя_столбца   [,…n])]

|   ON  {имя_хранимой_процедуры   |

имя_внешней_процедуры}}

TO { имя_пользователя   |  имя_группы  |

имя_роли}   [, ...n]

[WITH GRANT OPTION  ]

[AS   {имя_группы   |   имя_роли   } ]

Параметр <привилегия> представляет собой следующую конструкцию:

<привилегия>::=

{SELECT | DELETE | INSERT | UPDATE | EXECUTE | REFERENCES }

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

Необязательный  параметр AS {имя_группы | имя_роли} позволяет указать участие пользователя в роли, обеспечивающей предоставление прав другим пользователям.

Единственное  право доступа, которое может  быть предоставлено для хранимой процедуры, - право на ее выполнение «EXECUTE». Естественно, кроме этого владелец хранимой процедуры может просматривать и изменять ее код.

Для функции  можно выдать право на ее выполнение, а кроме того, выдать право «REFERENCES», что обеспечит возможность связывания функции с объектами, на которые она ссылается. Такое связывание позволит запретить внесение изменений в структуру объектов, способных привести к нарушению работы функции.

Права на выполнение команд SQL

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

<предоставление_права_выполнения>::=

GRANT  {ALL   |   <команда>[,...n]}

ТО  {имя_пользователя   |   имя_группы   |   имя_роли}   [,...п]

Параметр <команда> представляет собой следующую конструкцию:

<команда>::=

{CREATE'DATABASE   |   CREATE TABLE   |   CREATE VIEW   | CREATE  DEFAULT   |   CREATE  RULE   |   CREATE   PROCEDURE |   BACKUP DATABASE   |

BACKUP LOG   |   ALL  )

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

Неявные права

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

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

Запрещение  доступа

Система безопасности SQL Server имеет иерархическую структуру, и поэтому роли базы данных включают в себя учетные записи и группы Windows 2003/ХР, пользователей и роли SQL Server. Пользователь же, в свою очередь, может участвовать в нескольких ролях и одновременно иметь разные права доступа для разных ролей. Когда одна из ролей, в которых состоит пользователь, имеет разрешение на доступ к данным, он автоматически имеет аналогичные права. Тем не менее, если возникает необходимость, пользователю можно запретить доступ к данным или командам, тогда аннулируются все разрешения на доступ, полученные им на любом уровне иерархии. При этом гарантируется, что доступ останется запрещенным независимо от разрешений, предоставленных на более высоком уровне. [7, 287]

Для запрещения доступа к объектам базы данных используется команда:

<запрещение_доступа>:: =

DENY   {ALL   [PRIVILEGES) |   |   <привилегия>   [,…n]}

{   ((имя_столбца  [,...n])] ON { имя_таблицы  |

имя_просмотра}

| ON {имя_таблицы  |  имя_просмотра  }

[имя_столбца  [, . . .n])]

|  ON {имя_хранимой_процедуры  |

имя_внешней_процедуры)}

TO {имя_пользователя  |  имя_группы | имя_роли}  [,...:.]

[CASCADE ]

Параметр «CASCADE» позволяет отзывать права не только у конкретною пользователя, но также и у всех тех. кому он предоставил аналогичные права.

Для запрещения выполнения команд SQL применяется оператор:

<запрещение_выполнения>: : =

DENY   {ALL   |   <команда>[,...n]}

ТО {имя_пользователя  |   имя_группы  |

имя_роли}   [,…n]

Неявное отклонение доступа

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

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