ГОСЫ / Administrirovanie

1. Основные задачи администрирования информационных систем Администратор

oуправляющая программа, организующая программа, диспетчер, программа управления oпрограмма или ответственное лицо

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

Администрирование – функциональная поддержка управления системным ресурсом и обеспечения его безопасной и бесперебойной работы

Администрирование ИС заключается:

1) в обеспечении безотказной работы системы и ее ресурсов в условиях многопользовательского режима в сочетании с удовлетворительным временем отклика на запросы пользователей

2)в управлении доступом (регистрация пользователей, назначение прав и ограничений)

3)в обеспечении доступности, безопасности и масштабируемости системы

КИС относятся: ОС, сетевые службы и протоколы, СУБД, Web-серверы, обслуживающие системы и т.п.

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

Кобязанностям системного администратора обычно относят следующие задачи:

подключение и настройка аппаратных устройств;

установка и обновление программного обеспечения;

запуск и настройка общесистемных сервисов (конфигурирование системы);

настройка сетевых протоколов;

обеспечение печати и отправки почты;

обеспечение файловых серверов, серверов приложений, web и ftp-серверов;

управление процессами – изменение их приоритета, принудительное завершение;

управление общесистемными ресурсами, такими, как дисковые разделы и файловые системы;

распределение ресурсов;

определение дисковых квот и управление ими;

регистрация и управление пользователями;

настройка групповых политик;

настройка политики безопасности;

обеспечение безопасности;

регистрация и анализ всех инцидентов, связанных с нарушение безопасности;

резервное копирование информационных ресурсов;

мониторинг системы в поисках любого возможного системного сбоя, узкого места или уязвимости в защите;

поиск неисправностей;

анализ производительности и надежности;

обеспечение защиты от ошибок пользователей

мониторинг действий пользователей;

мониторинг электронной почты;

мониторинг работы в Internet;

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

1

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

Управление пользователями включает такие функции:

oСоздание учетной записи пользователя; oИзменение пароля; oОтключение/включение учетной записи; oУдаление учетной записи пользователя.

Другая задача администрирования – управление группами. Управление группами включает в себя: oсоздание группы;

oдобавление пользователей в группу; oудаление группы.

К наиболее существенным элементам программного обеспечения безопасности в

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

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

Оборотной стороной богатых возможностей данной технологии является сложность распространения групповых политик и управления ими, а в ряде случаев некорректная установка параметров может привести к неожиданным последствиям для пользователей и приложений. Неполадки, которые возникают в процессе использования групповых политик, могут принимать различные формы. Чаще всего они проявляются в виде нарушений работы приложений на компьютерах пользователей. Либо это могут быть проблемы администрирования, возникающие у специалистов, обслуживающих эти компьютеры. Если говорить более определенно, то в большинстве случаев подобные проблемы связаны с двумя основными типами политик, а именно с политиками установки ограничений на компьютеры пользователей (desktop lockdown policies) и с политиками безопасности (security policies).

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

Групповые политики обладают весьма богатыми возможностями. Но если перед применением GPO (Group Policy Objects) не будут выполняться тестовые мероприятия, это может привести к

2

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

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

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

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

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

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

Готовностью системы называется время, в течение которого все пользователи в сети могут согласованно обращаться ко всем без исключения имеющимся в ней приложениям и данным. ИС с высокой готовностью в состоянии реагировать на ошибки без остановки работы, из-за чего и обладают высокой степенью отказоустойчивости. Это достигается путем применения избыточных компонентов, которые при возникновении неисправности поддерживают выполнение всех функций и поэтому минимизируют время отказа. На практике различают два вида системных отказов: запланированные и незапланированные. Действия по наращиванию системы, замене неисправного, но имеющего аналог компонента, обновлению программного обеспечения намечаются администратором заранее, а потому если и ведут к простоям, то запланированным. Стихийные бедствия, ошибки конфигурации или дефекты основной платы становятся причиной незапланированных отказов системы. Первым шагом по устранению таковых является целенаправленное организационное и техническое планирование.

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

3

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

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

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

4

4.Администрирование и система привилегий СУБД MySQL

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

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

Привилегия – это право определенного пользователя выполнять определенные действия над определенными объектами. Администратору СУБД (и не только) рекомендуется следовать принципу наименьших привилегий: пользователь или процесс должен обладать наименьшим уровнем привилегий, необходимым для выполнения назначенного задания. ЧТО НЕ РАЗРЕШЕНО, ТО ЗАПРЕЩЕНО.

СУБД MySQL использует специальную базу данных mysql для предоставления прав доступа к своим базам данных. Эти права могут базироваться на именах серверов и/или пользователей и предоставляться для одной или нескольких баз данных. Суперпользователь или администратор

MySQL имеет account (login) root.

Пользовательские account должны быть снабжены паролями. При обращении к базе данных, пароль шифруется/хэшируется (по умолчанию применяется однонаправленная функция Password – реализация MD5). То есть при соединении с сервером пароль передается по сети в шифрованном виде. Схема аутентификации MYSQL:

При установлении соединения сервер посылает случайное число клиенту.

Клиент шифрует пароль и вычисляет число из полученного с сервера случайного числа и зашифрованного пароля. Это число отсылается на сервер.

Сервер вычисляет число из сохраненного в зашифрованном виде пароля и сгенерированного случайного числа. Если это число совпадет с тем, которое прислал клиент, связь устанавливается.

Собственная система привилегий, которая обеспечивает безопасность и администрирование СУБДсервера, описывается 5-ю таблицами в специальной системной БД с названием mysql:

user, host, db, tables_priv, columns_priv.

1.user – содержит данные о пользователях и безопасности, относящиеся к СУБД-серверу в целом; предназначена для определения пользователя и возможности его подключения к серверу - ГЛОБАЛЬНЫЕ ПРИВИЛЕГИИ

2.host – содержит права доступа к серверу баз данных для удаленных компьютеров

3.db, tables_priv, columns_priv - управляют доступом к отдельным базам данных, таблицам и столбцам таблиц – ЛОКАЛЬНЫЕ ПРИВИЛЕГИИ.

Управление доступом в MySQL осуществляется в два этапа:

5

Этап 1: сервер проверяет, имеется ли у пользователя вообще разрешение на соединение с СУБДсервером – таблица user.

Этап 2: если таковое имеется, сервер проверяет каждый из пользовательских запросов, чтобы убедиться в том, что пользователь обладает достаточным уровнем привилегий для его выполнения.

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

ПРОЦЕСС ВЕРИФИКАЦИИ ЗАПРОСА ДОСТУПА к СЕРВЕРУ.

Для запросов на администрирование (SHUTDOWN, RELOAD, т.д.) сервер проверяет запись только в таблице user, т.к. это единственная таблица, которая определяет привилегии администрирования. Доступ предоставляется при условии, что выбранная запись разрешает затребованные операции, и запрещается в противном случае. Например, вы хотите завершить работу mysql с помощью mysqladmin shutdown, но ваша запись в таблице user не предоставляет вам привилегию SHUTDOWN. В этом случае в доступе будет отказано без дальнейшей проверки таблицы db и host (поскольку в них отсутствует столбец Shutdown_priv, в такой проверке нет необходимости).

В случае запросов, относящихся к базам данных (INSERT, UPDATE и т.д.), сервер сначала проверяет глобальные привилегии пользователя, просматривая запись в таблице user. Если эта запись разрешает затребованную операцию, доступ предоставляется. Если глобальные привилегии, указанные в таблице user, недостаточны, сервер проверяет таблицы db и host и определяет привилегии пользователя на уровне баз данных:

1.Сервер просматривает таблицу db в поисках записи с подходящими значениями в полях Host, Db и User. Поля Host и User сравниваются с именем подключающегося хоста и именем пользователя MySQL. Поле Db сравнивается с именем базы данных, к которой пользователь хочет получить доступ. Если запись с подходящими значениями в полях Host и User отсутствует, в доступе будет отказано.

2.Если же в таблице db имеется подходящая запись и значение в поле Host - не пустое, эта запись определяет привилегии пользователя, касающиеся базы данных.

3.Если же в подходящей записи, выбранной в таблице db, значение в поле Host пустое, это означает, что перечень хостов, которым разрешен доступ к требуемой базе данных, приведен в таблице host. В этом случае дальнейший поиск производится в таблице host, где ищется запись с подходящими значениями в полях Host и Db. Если ни одной подходящей записи в таблице host нет, в доступе будет отказано. Если такая запись имеется, привилегии пользователя на уровне базы данных вычисляются путем логического умножения (не логического сложения!) привилегий, найденных в записях, которые выбраны в таблицах db и host. Другими словами, пользователю назначаются те привилегии, для которых в обеих записях установлено значение 'Y'. (Этот способ можно использовать следующим образом: предоставить всеобщие привилегии в записи, хранящейся в таблице db, а затем выборочно ограничить их отдельно по каждому хосту, используя для этого записи в таблице host.)

Определив привилегии на уровне базы данных, предоставляемые записями в таблицах db и host, сервер добавляет их к глобальным привилегиям, заданным в таблице user. Если в результате привилегий оказывается достаточно для выполнения затребованной операции, доступ предоставляется. В противном случае сервер проверяет по таблицам tables_priv и columns_priv привилегии пользователя на уровне таблиц и столбцов и добавляет их к уже имеющимся привилегиям. В зависимости от полученного результата доступ либо предоставляется, либо нет.

РЕКОМЕНДАЦИЯ: наиболее правильно заводить рядовых пользователей в таблице user вообще без прав, то есть только их регистрировать, чтобы они могли подключиться к СУБД-серверу. Остальные права назначать для каждого пользователя в таблицах db и host исходя из его потребностей.

6

Кпредоставлению некоторых из привилегий следует относиться особенно внимательно:

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

Привилегия ALTER может быть использована для переименования таблиц и разрушения таким образом всей системы привилегий.

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

Привилегия SHUTDOWN может использоваться злонамеренно для полного прекращения работы сервера и, таким образом, полного запрещения обслуживания других пользователей.

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

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

Есть вещи, которые система привилегий MySQL делать не может:

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

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

Сервер mysqld считывает содержимое таблиц привилегий единожды, при его запуске.

Когда сервер замечает, что были внесены изменения в таблицы назначения привилегий, он обрабатывает установленные соединения клиентов следующим образом:

Изменения привилегий таблиц и столбцов вступают в силу при следующем запросе клиента

Изменения привилегий баз данных вступают в силу при следующем использовании команды USE db_name

Изменения глобальных привилегий и изменения пароля вступают в силу при следующем подсоединении пользователя.

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

Пользователей можно добавлять двумя различными способами - при помощи команды GRANT или напрямую в таблицы назначения привилегий MySQL (команда INSERT INTO имя_таблицы(список_столбцов) VALUES(список_значений) ). Предпочтительнее использовать команду GRANT - этот способ проще и дает меньше ошибок.

GRANT privileges [columns] ON item TO ‘user_name’@’host’ IDENTIFIED BY ‘user_password’

[WITH GRANT OPTION] [необязат. параметры] PRIVILEGES – список наименований привилегий через запятую.

ALL PRIVILEGES – все, USAGE PRIVILEGES - никаких привилегий сolumns – по каким столбцам

item – БД или таблица (*.* - все БД, все таблицы) Если таблица – Dbname.Tablename

WITH GRANT OPTION – если указано, то пользователю дано право передавать свои привилегии другим пользователям

GRANT ALL PRIVILEGES ON *.* TO ‘user_name’@’host’ IDENTIFIED BY ‘user_password’; GRANT USAGE PRIVILEGES ON *.* TO ‘user_name’@’host’ IDENTIFIED BY ‘user_password’;

7

Отнять все привилегии – REVOKE ALL PRIVILEGES ON item FROM 'user_name’@’host';

Служебное слово PRIVILEGES можно опустить при наборе команды.

Привилегии вступят в силу или при следующем соединении или в текущем сеансе только после обновления состояния системных таблиц, это делает команда FLUSH PRIVILEGES.

Просмотреть набор текущих привилегий пользователя

SHOW GRANTS FOR 'user_name'@'host';

Окончательно удалить пользователя следует командой типа

DELETE FROM TABLE where User=’user_name’ and Host=’host’;

удаляя соответствующие записи из всех системных таблиц: user, host, db, tables_priv, columns_priv. После этого следует выйти из монитора и перезагрузить системные таблицы командой

shell> mysqladmin reload –u user -p

Этот сервис доступен только пользователю с полномочиями RELOAD.

Изменять пароли других пользователей могут только пользователи с правом записи/обновления базы данных mysql.

UPDATE mysql.user SET Password=password(‘newpass’) WHERE User=’modify_user’ AND Host=’host’;

Все обычные пользователи могут модифицировать только свой собственный пароль при помощи команды set password

SET PASSWORD FOR user@’localhost’ = Password(‘newpass’);

Ограничение ресурсов пользователя

Начиная с MySQL версии 4.0.2 можно ограничивать определенные ресурсы, выделяемые пользователям.

До этой версии единственным возможным методом ограничения использования ресурсов сервера MySQL была установка переменной запуска max_user_connections в значение, отличное от нуля. Но этот метод действует только на глобальном уровне и не позволяет управлять отдельными пользователями.

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

Количество всех запросов в час: все команды, которые может запускать пользователь.

Количество всех обновлений в час: любая команда, которая изменяет таблицу или базу данных.

Количество соединений, сделанных за час: новые соединения, открытые за час.

Пользователь в упомянутом выше контексте представляет собой отдельную запись в таблице user, которая уникальным образом идентифицируется своими столбцами User и Host.

Данные ограничения могут быть наложены только при помощи глобальной команды GRANT (*.*)

сиспользованием следующего синтаксиса:

GRANT ... WITH MAX_QUERIES_PER_HOUR N1 MAX_UPDATES_PER_HOUR N2 MAX_CONNECTIONS_PER_HOUR N3;

Можно указать любое сочетание приведенных выше ресурсов. N1, N2 и N3 являются целыми числами, представляющими собой значения количеств запросов/обновлений/соединений в час.

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

Текущие значения для всех пользователей сбрасываются, если производится перезагрузка привилегий (на сервере или при использовании команды mysqladmin reload) или если выполняется команда FLUSH USER_RESOURCES.

Задание паролей

В большинстве случаев для задания пользователей и их паролей следует пользоваться командой

GRANT.

8

Не рекомендуется указывать пароль таким образом, чтобы его могли увидеть и подобрать другие пользователи. Используйте параметр -p или --password (без указания самого значения your_password). В этом случае программа mysql запрашивает пароль с терминала:

shell> mysql -u user_name -p

Enter password: ********

Ваш пароль будет представлен символами *. Вводить пароль таким образом намного безопаснее, чем из командной строки, поскольку он невидим для остальных пользователей. Тем не менее, этот метод подходит только для тех SQL-программ, которые пользователь запускает самостоятельно. Если требуется выполнить запрос из скрипта, то возможности ввести пароль с терминала не будет.

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

Исходя из всего сказанного выше, самыми безопасными методами указания пароля являются запрос программы клиента mysql на ввод пароля с терминала.

Таблицы db и host

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

Эта таблица во многом похожа на user, основное отличие – вместо Password столбец Db. Совпадающие привилегии, уже присвоенные пользователю в user, перекрывают назначенные в db. Например, если пользователь имеет право INSERT, то он сможет выполнить эту операцию в отношении любой БД сервера, несмотря на запрет этой же операции в отношении какой-либо БД, указанной в таблице db.

host дополняет db: Пустое поле Host в db вынуждает MySQL искать запись, соответствующую имени узла пользователя, в таблице host. Если такой записи не найдено, сервер отказывает в доступе. Если соответствие найдено, то MySQL определяет права как пересечение прав, определяемых в db и host, то есть в обеих записях разрешение должно иметь значение Y, иначе – отказ.

host позволяет создать разрешения на межкомпьютерном уровне.

Таблицу host можно использовать еще для одной цели - для поддержки списка надежных серверов. tables_priv

columns_priv

tables_priv и columns_priv уточняют данные, имеющиеся в db. Право на любую операцию сначала проверяется в db, затем в tables_priv и columns_priv. Операция разрешается, если одна из записей имеет значение Y. С помощью этих таблиц сужается область действия разрешений до уровня таблиц БД и даже столбцов таблицы.

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

9

5.Ролевое управление доступом РОЛИ

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

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

MS SQL Server имеет предопределенный набор серверных ролей:

	Полное имя		Имя		Описание
	Bulk Insert Administrators		bulkadmin		Может выполнять операции вставки типа "bulk insert"
	(Администраторы сплошной				(групповая или потоковая вставка) - только
	вставки данных)				профессиональный администратор
	Database Creators (Создатели		dbcreator		Может создавать, изменять или удалять базы данных –
	баз данных)				одна из основных ролей (только профессиональный
					администратор)
	Disk Administrators		diskadmin		Может управлять файлами диска (команды типа ALTER
	(Администраторы диска)				DATABASE – изменение начального размера БД, квот
					приращений)

Process Administrators

(Администраторы процесса)

processadmin Может управлять процессами, запущенными в SQL Server, основная задача членов этой роли – уничтожение процессов, заблокировавших ресурсы БД

Security Administrators

(Администраторы безопасности)

securityadmin Может управлять учетными записями и разрешениями CREATE DATABASE, а также просматривать (читать) журнал ошибок (только профессиональный администратор) – одна из основных ролей

	Server Administrators		serveradmin		Может управлять конфигурированием всего сервера и
	(Администраторы сервера)				выключать его (только профессиональный
					администратор)
	Setup Administrators		setupadmin		Может управлять связанными серверами: создавать их,
	(Администраторы настройки)				удалять и конфигурировать; может назначать хранимые
					процедуры, автоматически выполняемые при запуске
					SQL Server
	System Administrators		sysadmin		Может выполнять любые действия в SQL Server –самая
	(Системные администраторы)				важная серверная роль (только профессиональный
					администратор)

При подключении к SQL Server рекомендуется использовать ту учетную запись, которая предоставляет необходимый минимум полномочий для выполнения текущей работы, а учетную

10