ЛЕКЦИЯ 5. АДМИНИСТРИРОВАНИЕ СЕРВЕРА

Основными задачами администратора Microsoft SQL Server являются пе­ речисленные ниже группы действий:

1.Создание учетных записей пользователей.

2.Привязка учетных записей пользователей к конкретным БД.

3.Распределение ролей на уровне сервера.

4.Контроль за активностью пользователей.

5.Выявление попыток несанкционированных подключений.

6.Удаление неактуальных учетных записей.

7.Создание и размещение новых БД.

8.Создание резервных копий БД (полных, действий, расписание).

9.Восстановление БД из резервных копий.

10.Генерация SQL-скриптов по требованию разработчиков.

11.Плановая перегрузка сервера (профилактика размера БД tempdb).

12.Настройка служб оповещения (в случае ошибок - email или пейджер).

13.Создание и выполнение DTS-пакетов (импорт и трансформация данных).

14.Контроль за свободными ресурсами и производительностью сервера.

15.Мониторинг ошибок блокировки (синхронные транзакции).

16.Регистрация удаленных и связанных серверов.

17.Передача прав владения БД и ее объектами.

Часть этих функций дублируется на уровне администраторов БД:

1.Создание пользователей БД.

2.Наделение пользователей БД привилегиями доступа к объектам.

3.Контроль над полномочиями пользователей.

4.Программное создание резервных копий БД.

5.Программное восстановление БД.

6.Генерация SQL-скриптов программно созданных объектов.

5.1. Разграничение прав доступа

При работе сервера на диске (или дисках) компьютера создается мно­ жество временных файлов, необходимых для эффективной работы пользо­ вателей с БД. Для корректной работы Microsoft SQL Server требуется, что­ бы приложения (все процессы Microsoft SQL Server) имели полный доступ к ресурсам компьютера, то есть установку Microsoft SQL Server можно вы­ полнить только в статусе администратора. Сервер БД работает под управ­ лением ОС Windows NT и может обращаться к файлам файловой системы NTFS (не рекомендуется FAT), которая и выполняет разграничение доступа на уровне файлов.

терфейсом) позволяют наделять пользователей привилегиями не из командной строки SQL, а с помощью диалогового интерфейса.

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

Существуют два уровня привилегий: 1 -й - привилегии доступа к системе; 2-й - привилегии доступа к объектам.

5.2.2. Привилегии доступа к системе

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

Несмотря на серьезные различия реализаций SQL, список основных при­ вилегий остается неизменным:

-CREATE DATABASE - создание БД;

-ALTER DATABASE - модификация БД;

-CREATE TABLE - создание таблицы;

-CREATE ANY TABLE - создание любой таблицы;

-ALTER TABLE - модификация структуры таблицы;

-DROP TABLE - удаление таблицы;

-CREATE USER - создание учетной записи;

-ALTER USER - изменение учетной записи;

-DROP USER - удаление учетной записи;

-SELECT ANY TABLE - выборка из любой таблицы; -BACKUP ANY TABLE - создание резервной копии.

5.2.3. Привилегии доступа к объектам

Привилегии доступа к объектам - это уровни полномочий пользователей по отношению к объектам БД. Стандарт SQL определяет следующий ряд при­ вилегий:

-USAGE - разрешение использования области;

-SELECT - разрешение выборки из таблицы;

-INSERT - добавление записей в таблицу;

-INSERT(CTOJIEEIJ) - добавление в указанный столбец;

-UPDATE - модификация записей таблицы;

-ЦРОАТЕ(СТОЛБЕЦ) - изменение в указанном столбце;

-REFERENCES - позволяет сослаться на столбец таблицы.

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

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

5.2.3.1. Команда GRANT

Эта команда используется для предоставления привилегий как на уровне системы, так и на уровне объектов. Правами могут наделяться только пользо­ ватели, чьи учетные записи имеются в БД.

Синтаксис классического оператора прост:

GRANT Привилегия^ Привелегия2...

ON Объект ТО Список_Имен_Пользователей;

Рассмотрите следующие примеры:

GRANT SELECT ON Т1 ТО USER1;

GRANT SELECT, INSERT ON T2 TO USER2;

GRANT SELECT ON T1 TO USER3, USER4;

В некоторых реализациях SQL после выполнения соответствующих опе­ раторов GRANT появляется сообщение «Grant succeeded» (Oracle), в то время как другие модификации SQL никаких сообщений не выдают.

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

5.2.3.2. Директива GRANT OPTION

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

GRANT SELECT ON Т1 ТО USER1 WITH GRANT OPTION;

После выполнения этого оператора USER1 может наделять правом досту­ па к данным (только чтения из таблицы Т1) других пользователей.

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

GRANT SELECT ON Т1 ТО USER1 WITH ADMIN OPTION;

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

5.2.3.4. Доступ к отдельным столбцам

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

GRANT UPDATE(NAME) ON T_FIO TO USER1;

Такой прием будет очень эффективным при администрировании БД, с которой работают пользователи, выполняющие узкоспециализированные действия.

Пользовательское имя PUBLIC объединяет всех пользователей БД. Если привилегии предоставляются этому имени, это значит, что они предоставляют­ ся всем пользователям БД. Разумеется, при отмене привилегии PUBLIC она от­ меняется у всех пользователей, которые не были наделены ей индивидуально.

GRANT SELECT ON T_FIO TO PUBLIC;

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

5.2.3.5. Команда REVOKE

Команда REVOKE отменяет ранее предоставленные привилегии. В клас­ сическом SQL существуют две ее разновидности - RESTRICT и CASCADE, которые выполняют «осторожное» и «каскадное» удаление прав доступа.

Синтаксис классического оператора:

REVOKE Привилегия1, Привелегия2...

ON Объект FROM Имя_Пользователя;

Синтаксис расширенного оператора:

REVOKE Привилегия!, Привелегия2...

[GRANT OPTION FOR] ON Объект

FROM Имя_Пользователя

RESTRICT или CASCADE;

При возникновении спорной ситуации именно опции RESTRICT и CASCADE определяют характер отмены привилегий. Например, админист­ ратором БД пользователь USER1 был наделен правом просмотра таблицы Т1, которым он поделился (директивой GRANT OPTION) с другим пользователем USER2. После того как администратор БД получил указание «отключить» поль­ зователя USER1 от БД, отменив его привилегии, возникла неоднозначная ситуа­ ция с полномочиями пользователя USER2.

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

Мы рассмотрели пример простейшей конфликтной ситуаций, хотя при ра­ боте с реальной БД все может оказаться значительно сложней. Кстати, в чем недостаток отмены привилегии USER1 по вставке данных в таблицу Т1?

REVOKE INSERT ON Т1 FROM USER1;

5.2.4. Команда CREATE ROLE

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

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

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

CREATE ROLE ИМЯ.РОЛИ;

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

Например, наделим пользователя USER1 правами выборки и вставки дан­ ных в таблицу XI, используя созданную администратором роль:

CREATE ROLE MY.ROLE;