Безопасность баз данных

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

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

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

Microsoft Access – это полнофункциональная реляционная СУБД. В ней предусмотрены все необходимые средства для определения и обработки данных, а так же для управления ими при работе с большими объемами информации.

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

Access хранит информацию о защите  в двух местах. Во время установки  программа Setup создаст в папке  \Program Files\Microsoft Ofice\0ffice стандартный файл  рабочей группы (System.mdw), который впоследствии  используется по умолчанию при  запуске Access. Этот файл содержит  информацию обо всех пользователях  и группах. При создании базы  данных Access сохраняет сведения о  правах, предоставляемых конкретным  пользователям и группам, в  файле базы данных.

Общая структура защиты Access отображена на рисунке 1. Учётные записи пользователей  и групп хранятся в файле рабочей  группы. Разрешение на доступ к конкретным объектам сохраняются в файле базы данных.

                                                                                                                       Рис. 1

Расположение текущего файла рабочей  группы хранится в реестре Windows. Можно  использовать служебную программу Wrkadm.exe (администратор рабочих групп) для изменения текущего или определения  нового файла рабочей группы. Кроме  того, можно выбирать нужный файл рабочей  группы во время выполнения приложения, задав соответствующий параметр командной строки в ярлыке запуска. Если вам приходится часто запускать  в сети совместно используемое защищенное приложение, нужно позаботиться о том, чтобы системный администратор задал вашу рабочую группу, используемую по умолчанию, как общий файл в сетевой папке.

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

Вряд ли существует абсолютно  надежная компьютерная система защиты. Хотя средства защиты Microsoft Access считаются одними из лучших для персональных компьютеров.

2.2 Microsoft SQL Server

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

Microsoft SQL Server — система управления реляционными базами данных (СУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов — Transact-SQL, создан совместно Microsoft и Sybase. Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприятия; конкурирует с другими СУБД в этом сегменте рынка.

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

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

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

• Дискреционный
• Обязательный
• Ролевой

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

Система безопасности SQL Server имеет несколько уровней безопасности:

• операционная система;

• SQL Server;

• база данных;

• объект базы данных.

С другой стороны механизм безопасности предполагает существование  четырех типов пользователей:

• системный администратор, имеющий неограниченный доступ;

• владелец БД, имеющий полный доступ ко всем объектам БД;

• владелец объектов БД;

• другие пользователи, которые  должны получать разрешение на доступ к объектам БД.

Модель безопасности SQL Server включает следующие компоненты:

• тип подключения к  SQL Server;

• пользователь базы данных;

• пользователь (guest);

• роли (roles).

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

При подключении (и в зависимости  от типа подключения) SQL Server поддерживает два режима безопасности:

• режим аутентификации Windows NT;

• смешанный режим аутентификации.

В режиме аутентификации Windows NT используется система безопасности Windows NT и ее механизм учетных записей. Этот режим позволяет SQL Server использовать имя пользователя и пароль, которые определены в Windows, и тем самым обходить процесс подключения к SQL Server. Таким образом, пользователи, имеющие действующую учетную запись Windows, могут подключиться к SQL Server, не сообщая своего имени и пароля. Когда пользователь обращается к СУБД, последняя получает информацию об имени пользователя и пароле из атрибутов системы сетевой безопасности пользователей Windows (которые устанавливаются, когда пользователь подключается к Windows).

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

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

В критических для бизнеса приложениях, когда сервер СУБД должен быть постоянно  доступен для клиентов, большинство  профилактических работ по поддержке  базы данных приходится выполнять фактически в режиме on - line. MS SQL Server обладает возможностями  динамического резервного копирования  данных, т. е. даже когда эти данные используются и изменяются клиентами. В случае сбоя оборудования, отключения питания и т. д. механизм автоматического  восстановления MS SQL Server восстанавливает  все базы данных до их последнего целостного состояния без вмешательства  администратора. Все завершенные, но не отраженные в базе транзакции из журнала транзакций применяются  к базе данных (это фактически то, что происходит при событии chekpoint), а незавершенные транзакции, т. е. те, которые были активными на момент сбоя, вычищаются из журнала.

Говоря о симметричной архитектуре, операции резервного копирования и  восстановления могут распараллеливаться на несколько потоков и выполняться  одновременно, используя преимущества асинхронного ввода/вывода. На каждое резервное устройство отводится  свой поток. Параллельное резервное  копирование поддерживает до 32 одновременных  резервных устройств (backup devices), что  позволяет быстро создавать страховочные копии баз данных даже очень большой емкости. Возможность резервного копирования и восстановления отдельных таблиц, о чем мы упоминали, рассматривая Transact-SQL, позволяет экономить место и время, не выполняя копирование всей базы ради только некоторых ее объектов. Однако резервное копирование отдельной таблицы требует наложения на нее блокировки exclusive в отличие от резервного копирования всей базы или журнала транзакций, которые могут выполняться независимо от степени активности пользователей. Резервным копиям может быть назначен предельный срок хранения или дата утраты актуальности, до наступления которой место, занятое на устройстве этими копиями, не может использоваться для размещения других резервных копий при инициализации устройства. В качестве резервных устройств могут также применяться временные устройства, не входящие в состав базы и не имеющие записей в системной таблице sysdevices:

DECLARE @tomorrow char(8)

SELECT @tomorrow = CONVERT(char(8), DATEADD(dd, 1, GETDATE()) ,1)

DUMP DATABASE pubs

TO DISK = '\\ntalexeysh\disk_d\sql_experiments\pubs.dmp'

WITH INIT, EXPIREDATE=@tomorrow, STATS

Для небольшой базы данных ее журнал транзакций обычно хранится на том  же устройстве, что и сама база, и  архивируется вместе с ней. Журналирование транзакций ведется по принципу write-ahead, что означает, что любое изменение  сначала отражается в журнале  транзакций и лишь потом попадает собственно в базу.  В случае нахождения журнала транзакций на отдельном устройстве существует возможность отдельного резервного копирования журнала транзакций. Как правило, резервное копирование базы данных организуется с меньшей частотой, чем журнала транзакций. Например, сохранение журнала транзакций выполняется ежедневно, а страховая копия всей базы может делаться раз в неделю, так как архивирование журнала транзакций происходит значительно быстрее по времени и занимает меньше места, чем дамп целой базы. В отличие от резервирования базы данных дамп журнала транзакций очищает его неактивную часть, т. е. все завершившиеся (зафиксированные или абортированные) с момента последнего дампа транзакции, если только не использована опция NO_TRUNCATE. Команда DUMP TRANSACTION TRUNCATE_ONLY, очищающая журнал транзакций, полезна в случае его переполнения, которое можно контролировать, например, оператором DBCC SQLPERF (LOGSPACE). Если степень переполнения журнала очень высока, можно при его очистке отказаться от журналирования факта самого этого события: DUMP TRANSACTION NO_LOG. Если резервное копирование транзакций не представляет интереса, можно включить опцию очистки последних завершенных транзакций в базе по наступлению события checkpoint. Cмысл механизма checkpoint состоит в периодической записи данных из кэша на диск, чтобы не допускать грязных данных. Такого рода события постоянно генерируются MS SQL Server или возникают по инициативе пользователя. Включенная опция truncate log on checkpoint гарантирует выполнение с определенной частотой обработчиком события действий, приблизительно эквивалентных команде DUMP TRANSACTION TRUNCATE_ONLY.

При восстановлении журнала транзакций соответствующие транзакции применяются  к базе данных. Это означает, что  если в начале недели была сделана  резервная копия всей базы, а потом  ежедневно архивировались транзакции за каждый день, то при необходимости  восстановления поднимается состояние  базы на начало недели и на него последовательно  накатываются дампы журнала транзакций за все дни, предшествующие моменту  восстановления. MS SQL Server 6.5 имеет возможность  восстановления данных из журнала транзакций на произвольный момент времени (разумеется, отраженный в журнале) при помощи команды LOAD TRANSACTION STOPAT <t> или в окне database backup and restore выбором опции until time. Все содержащиеся в этом дампе транзакции, отмеченные завершившимися после этого момента, будут откачены.

Возможность планирования задач резервного копирования во времени и отсылки  сообщений по e-mail в случае успешного/неуспешного  завершения рассматривалась нами при  обсуждении SQL Executive.

MS SQL Server 6.5 предусматривает возможность  зеркалирования устройств, переключения  на зеркальные устройства в  качестве основных, выключения зеркалирования  и уничтожения зеркального устройства  также "на лету", т. е. без  остановки штатной работы сервера  по обслуживанию пользовательских  запросов. Зеркалирование и дуплексирование  устройств для работы с MS SQL Server может быть также выполнено  средствами Windows NT, а также на аппаратном  уровне (поддержка различных RAID-систем  и т. д.). По-видимому, следует предполагать, что реализация первого этапа  кластерной технологии WolfPack будет  поддерживать MS SQL Server 6.5 в отказоустойчивых  кластерах из двух узлов. Появление  следующей версии MS SQL Server должно  обеспечить работу серверов в  кластере как единого виртуального  сервера.

Transfer Manager используется для экспорта/импорта  объектов и данных БД на MS SQL Server между разными аппаратными  платформами, например между процессорами Intel и Alpha, а также между разными  версиями MS SQL Server, в частности из  более ранних в более поздние  или между равноценными (имеются  в виду 4.х и 6.х). Очень часто  проектирование объектов базы  ведется с помощью различных  графических средств, но проектная  документация может требовать  структуру объектов с точностью  до операторов DDL. Для получения  скриптов, описывающих создание  отдельного объекта базы данных, можно использовать команду transfer из контекстного меню объекта  или выбрать соответствующий  класс и имя объекта в Transfer Manager. Кроме этого, содержимое данных может быть выгружено/загружено при помощи утилиты bcp.