В этой лекции вы узнаете, как управлять пользователями и системой безопасности в среде Microsoft SQL Server 2000. Вместе с планированием резервного копирования и восстановления, определением состава системы и управлением дисковым пространством управление системой безопасности является одной из наиболее характерных задач для администратора баз данных (
Эта лекция охватывает ряд тем, относящихся к управлению пользователями и системой безопасности. Вы узнаете о том, как создавать пользовательские login-записи* (пользовательские учетные записи подключения к SQL Server) и управлять ими, а также о режимах аутентификации; кроме того, вы узнаете об идентификаторах пользователей. Пользовательская login-запись (user login) используется для аутентификации доступа к SQL Server. Она может аутентифицироваться через систему Microsoft Windows NT, Windows 2000 или SQL Server. Идентификатор пользователя (user ID) используется, чтобы присваивать пользовательские полномочия для доступа к определенным объектам в отдельных базах данных. Идентификаторы пользователей связаны с пользовательскими учетными записями и могут содержать (или не содержать) одно и то же имя, как вы увидите далее. Вы также узнаете о типах полномочий, которые могут быть присвоены в SQL Server, а также об их использовании. Кроме того, вы узнаете, как использовать роли для более простого управления пользователями. И, наконец, вы узнаете о важном средстве в SQL Server 2000, которое называется делегированием учетной записи безопасности. К концу этой лекции вы получите знания, необходимые для управления пользовательскими login-записями и системой безопасности.
Начнем изучение средств управления пользователями и системой безопасности с рассмотрения пользовательских login-записей. В этом разделе мы опишем сначала, почему так важны login-записи, и рассмотрим методы аутентификации, которые можно использовать для поддержки login-записей. Затем мы рассмотрим три метода создания login-записей: использование SQL Server Enterprise Manager, использование Transact-SQL (T-SQL) и использование мастера создания учетных записей Create Login Wizard. И, наконец, мы увидим, как использовать Enterprise Manager и T-SQL для создания новых пользовательских login-записей.
Пользовательские login-записи позволяют вам защищать свои данные от преднамеренного или непреднамеренного модифицирования несанкционированными (неавторизованными) пользователями. С помощью пользовательских login-записей SQL Server может аутентифицировать отдельных авторизованных пользователей. Каждой пользовательской login-записи присваивается уникальное имя и пароль. Каждому пользователю присваивается его собственная учетная login-запись для входа в SQL Server. Без пользовательских login-записей для всех соединений с SQL Server использовался бы один и тот же идентификатор, а это означает, что вы не могли бы создавать различные уровни безопасности для тех, кто осуществляет доступ к базе данных.
Вы можете создавать различные уровни безопасности, предоставляя различным учетным login-записям различные полномочия для доступа к объектам и выполнения функций. Вы можете также шифровать определенные объекты базы данных, такие как хранимые процедуры и представления, чтобы скрывать их определения от неавторизованных пользователей. Кроме того, используя пользовательские login-записи, вы можете разрешать вставку и обновление информации в определенных таблицах базы данных только некоторым пользователям и предоставлять доступ к этим таблицам по чтению основной массе пользователей.
Чтобы увидеть, как осуществляется ограничение доступа к данным с помощью пользовательских login-записей, вернемся к примеру, впервые представленному в лекции 18, где показано использование представлений для ограничения доступа к критически важным данным. Предположим, что у нас имеется таблица Employee, содержащая информацию о сотрудниках, включая имя каждого сотрудника, номер телефона, номер офиса), должность, заработную плату, надбавку и т.д. Чтобы воспрепятствовать доступу определенных пользователей к конфиденциальным данным этой таблицы, сначала нужно создать представление, содержащее только общедоступные данные, такие как имена сотрудников, номера телефонов и номера офисов. Затем, реализуя пользовательские login-записи, вы можете ограничить доступ к исходной таблице, разрешив при этом доступ всех пользователей к представлению. Но если не использовать возможности пользовательских login-записей, то любой пользователь будет иметь доступ и к представлению, и к таблице, что лишает смысла использование этого представления.
Для доступа к SQL Server можно использовать два режима аутентификации: режим аутентификации Windows (Windows Authentication) и режим смешанной аутентификации (Mixed Mode Authentication). В первом случае аутентификация пользователя осуществляется операционной системой Windows. Затем SQL Server использует аутентификацию этой операционной системы, чтобы определить, какие пользовательские полномочия можно применять в каждом случае. В смешанном режиме аутентификацию пользователя осуществляют как Windows NT/2000, так и SQL Server. Для доступа к SQL Server вы должны в любом случае сначала осуществить вход по учетной записи Windows NT/2000, поэтому при выборе режима аутентификации вы должны решить, нужно ли вам использовать аутентификацию SQL Server в дополнение к аутентификации Windows. Рассмотрим каждый из этих режимов аутентификации более подробно. Ниже в этом разделе вы узнаете, как реализовать оба этих режима.
Как уже говорилось, при аутентификации с помощью Windows обеспечение безопасности для SQL Server осуществляет с помощью учетных записей система Windows NT/2000. При подсоединении пользователя к Windows NT/2000 эта система проверяет подлинность пользователя по его учетной записи. SQL Server "убеждается" в том, что пользователь был проверен системой Windows NT/2000, и разрешает доступ, основываясь на этой аутентификации. Для этого используется интеграция процесса проверки login-записей SQL Server с процессом проверки учетных записей в Windows. Атрибуты безопасности на уровне сети проверяются с помощью сложного процесса шифрования, обеспечиваемого в Windows NT/2000. После аутентификации операционной системой в этом режиме дальнейшая аутентификация для доступа к SQL Server уже не требуется. Для доступа к SQL Server вы должны только указать свой пароль доступа к Windows NT/2000.
Режим аутентификации Windows считается более надежным методом, чем режим смешанной аутентификации, за счет использования дополнительных средств безопасности. Это защищенная проверка и шифрование паролей, аудит, поддержка сроков действия паролей, минимальная длина паролей и автоматическое блокирование учетных записей после определенного количества безуспешных попыток входа.
В режиме смешанной аутентификации пользователи могут осуществлять доступ к SQL Server с помощью аутентификации в Windows или аутентификации в SQL Server. При соединении, осуществляемом в этом режиме из незащищенной системы, SQL Server аутентифицирует данные входа, проверяя, имеется ли учетная login-запись для пользователя, запрашивающего вход. SQL Server осуществляет аутентификацию по этой учетной login-записи путем сравнения имени и пароля пользователя, подсоединяющегося к SQL Server, с информацией учетной login-записи, хранящейся в базе данных. Если для этого пользователя не создана учетная login-запись или пользователь неверно указал имя или пароль, то SQL Server не разрешает доступ.
Режим аутентификации Windows недоступен, если SQL Server работает под управлением Windows 95/98, поэтому вы должны применять на этих платформах аутентификацию SQL Server (указывая режим смешанной аутентификации). Кроме того аутентификация SQL Server требуется для Web-приложений (с помощью Microsoft Internet Information Server), поскольку пользователи этих приложений, скорее всего, находятся не в том же домене, где сервер, и поэтому для них нельзя использовать систему безопасности Windows. Для других приложений также может потребоваться аутентификация SQL Server: некоторые разработчики предпочитают использовать для своих приложений систему безопасности SQL Server, поскольку это упрощает обеспечение безопасности их приложений. Если приложения используют систему безопасности SQL Server (в доверенной сети), то разработчики этих приложений не обязаны обеспечивать аутентификацию внутри самих приложений, что упрощает их работу.
Чтобы задать режим аутентификации, выполните следующие шаги.
(рис 34.1) Вкладка Security (Безопасность) окна SQL Server Properties В нескольких следующих разделах вы узнаете, как создавать login-записи и пользователей. Но прежде чем приступить к этому процессу, вы должны четко разобраться в таких понятиях, как учетные записи и пользователи. В этом разделе дается краткое описание этих двух терминов.
Как уже говорилось, пользовательская учетная запись Windows NT/2000 может потребоваться для подсоединения к базе данных. Независимо от используемого режима аутентификации (аутентификация Windows NT/2000 или режим смешанной аутентификации) учетная запись, которую вы используете для подсоединения к SQL Server, называется login-записью SQL Server (учетной записью подключения к SQL Server). Кроме этой учетной записи, каждая база данных имеет набор пользовательских учетных псевдозаписей, присвоенных этой базе данных. Эти учетные псевдозаписи являются
Вы можете выполнять большинство административных задач SQL Server, используя один из нескольких методов, и задача создания пользовательских login-записей не является исключением из этого правила. Как уже говорилось, вы можете создать login-запись, используя один из трех методов: с помощью Enterprise Manager, с помощью T-SQL или с помощью мастера создания login-записей Create Login Wizard. В этом разделе вы узнаете, как создавать login для SQL Server с помощью каждого их этих методов.
Чтобы создать login-запись для SQL Server с помощью Enterprise Manager, выполните следующие шаги.
(рис 34.3) Вкладка General окна SQL Server Login Properties(рис 34.2) Вкладка Server Roles (Роли сервера) окна SQL Server Login PropertiesДля создания login-записи с помощью T-SQL используется хранимая процедура sp_addlogin или хранимая процедура sp_grantlogin. Хранимая процедура sp_addlogin позволяет только добавлять аутентифицированного в SQL Server пользователя к базе данных SQL Server. Хранимая процедура sp_grantlogin позволяет добавлять пользователя, аутентифицированного в системе Windows NT/2000.
Хранимая процедура sp_addlogin имеет следующий синтаксис:
sp_addlogin [ @loginame = ] 'имя_login-записи'
[ , [ @passwd = ] 'пароль' ]
[ , [ @defdb = ] 'база данных' ]
[ , [ @deflanguage = ] 'язык' ]
[ , [ @sid = ] 'sid' ]
[ , [ @encryptopt = ] 'параметр_шифрования' ]
Используются следующие необязательные параметры.
NULL.master.sid обычно не генерируется пользователями, но администраторы используют sid в ряде ситуаций. Когда sid может потребоваться, чтобы определить проверяемую login-запись. Параметр sid является внутренним идентификатором для login-записи.NULL, означающее, что пароль будет шифроваться. Значение skip_encryption (пропустить шифрование) означает, что пароль не будет шифроваться. Если указать значение skip_encryption_old, то пароль, зашифрованный в более ранней версии SQL Server, не будет шифроваться еще раз. Вам следует изменять значение по умолчанию, только если вы хотите избежать шифрования пароля в системных таблицах.Ниже приводится простой пример добавления login-записи:
EXEC sp_addlogin 'PatB'
Не забудьте использовать ключевое слово EXEC перед именем хранимой процедуры.
Ниже приводится более сложный пример добавления login-записи:
sp_addlogin 'SharonR', 'mypassword', 'Northwind', 'us_english'
Эта команда создает пользователя с именем SharonR и паролем "mypassword." По умолчанию будет использоваться база данных Northwind, и язык по умолчанию – U.S. English. В обычном случае вы должны предоставить создание идентификатора безопасности (SID) SQL Server вместо самостоятельного создания этого идентификатора.
Хранимая процедура sp_grantlogin имеет следующий синтаксис:
sp_grantlogin 'имя_login-записи'
Ниже показан пример использования хранимой процедуры sp_grantlogin:
EXEC sp_grantlogin 'MOUNTAIN_DEW\DickB'
"DickB" –
Добавив эти login-записи, вы можете просматривать их в Enterprise Manager. Для этого щелкните на папке Logins в левой панели.
Чтобы создать login-запись для SQL Server с помощью мастера Create Login Wizard, выполните следующие шаги.
(рис 34.6) Окно Select Wizard(рис 34.5) Начальное окно мастера Create Login Wizard
(рис 34.8) Окно Select Authentication Mode for This Login (Выбор режима аутентификации для данной login-записи)(рис 34.7) Окно Authentication with SQL Server (Аутентификация с помощью Windows)
(рис 34.10) Окно Grant Access to Security Roles (Предоставление доступа ролям безопасности)(рис 34.9) Окно Grant Access to Databases (Предоставление доступа к базам данных)
(рис 34.11) Окно Completing the Create Login Wizard (Завершение работы мастера)Вы можете создавать пользователей SQL Server с помощью Enterprise Manager или T-SQL. (В SQL Server нет мастера, с помощью которого можно выполнять этот процесс.) В этом разделе вы узнаете, как использовать оба этих метода для создания пользователей SQL Server. Напомним, что пользователь SQL Server определяется для определенной базы данных, а полномочия доступа к этой базе данных присваиваются определенной пользовательской login-записи. Идентификатор пользователя (user ID) SQL Server можно рассматривать как аналог login-записи SQL Server, но они не обязательно имеют одинаковые имена.
В отличие от login-записей SQL Server, которые создаются из папки Security в Enterprise Manager, пользователи SQL Server создаются из папки определенной базы данных в левой панели Enterprise Manager. Для создания пользователей с помощью Enterprise Manager выполните следующие шаги.
Чтобы использовать T-SQL для создания sp_adduser. Эту хранимую процедуру можно запустить из ISQL или OSQL с использованием следующего синтаксиса:
sp_adduser [ @loginame = ] 'имя_login-записи'
[ , [ @name_in_db = ] 'пользователь' ]
[ , [ @grpname = ] 'группа' ]
Имя_login-записи – это имя учетной login-записи SQL Server, которое является обязательным параметром. Переменная пользователь – это имя нового пользователя, и группа – это группа или роль, к которой будет принадлежать новый пользователь. Если значение параметра пользователь не указано, то оно совпадает со значением параметра имя_login-записи.
С помощью следующей команды создается новый пользователь базы данных с именем JackR и учетной записью Windows NT или Windows 2000 FORT_WORTH\ DB_User:
sp_adduser 'FORT_WORTH\DB_User', 'JackR'
"FORT_WORTH" – имя системы или домена. "DB_User" –
Полномочия используются для управления доступом к объектам баз данных; они указывают, какие пользователи могут выполнять определенные операции с базой данных. Вы можете задавать полномочия на уровне сервера и на уровне базы данных. Полномочия на уровне сервера используются для того, чтобы администраторы баз данных (
Как уже говорилось, полномочия на уровне сервера присваиваются SHUTDOWN, и
Полномочия на уровне объектов базы данных – это класс полномочий, которые предоставляются для доступа к объектам базы данных. Полномочия доступа к объектам необходимы для доступа к таблице или представлению с помощью таких операторов, как SELECT, INSERT, UPDATE и DELETE. Полномочия доступа к объектам также требуются для использования оператора EXECUTE, который применяется для запуска хранимых процедур. Для присваивания полномочий доступа к объектам используются Enterprise Manager и операторы T-SQL.
Чтобы использовать Enterprise Manager для предоставления полномочий доступа к объектам базы данных, выполните следующие шаги.
SELECT, INSERT, UPDATE, DELETE, EXEC и DRI окна списка. ("DRI" – сокращение от "declarative Чтобы использовать T-SQL для присваивания какому-либо пользователю полномочий доступа к объектам, вы должны выполнить оператор
GRANT { ALL | полномочия }
[ колонка ON {таблица | представление} ] |
[ ON таблица(колонка) ] |
[ ON представление(колонка) ] |
[ ON { хранимая_процедура | расширенная_процедура } ]
TO учетная_запись_безопасности
[ WITH GRANT OPTION ]
[ AS { группа | роль } ]
Параметр учетная_запись_безопасности может быть представлен одним из следующих типов учетных записей:
Использование ключевого слова
Необязательный параметр AS указывает, кто имеет право на выполнение этого оператора
Ниже приводится пример использования оператора
GRANT SELECT, INSERT, UPDATE ON Customers TO MaryW WITH GRANT OPTION AS Accounting
Параметр AS Accounting используется потому, что роль Accounting имеет полномочия на предоставление полномочий по таблице Customers. Ключевое слово
GRANT Для отзыва полномочий какого-либо пользователя по объектам вы можете использовать оператор T-SQL
REVOKE [ GRANT OPTION FOR ]
{ ALL [ PRIVILEGES ] | полномочия }
[ колонка ON {таблица | представление} ] |
[ ON таблица(колонка) ] |
[ ON представление(колонка) ] |
[ ON { хранимая_процедура | расширенная_процедура } ]
{ TO | FROM } учетная_запись_безопасности
[ CASCADE ]
[ AS { группа | роль } ]
Параметр учетная_запись_безопасности может быть представлен одним из следующих типов учетных записей:
Ключевое слово
Ниже приводится пример использования оператора
REVOKE ALL ON Customers FROM MaryW
REVOKE Кроме полномочий доступа к объектам баз данных, вы можете также предоставлять полномочия на использование операторов. Полномочия доступа к объектам позволяют пользователям выполнять доступ к существующим объектам базы данных, в то время как полномочия на использование операторов позволяют им создавать объекты баз данных, включая базы данных и таблицы. Можно предоставлять следующие полномочия на использование операторов.
BACKUP DATABASE.BACKUP LOG Вы можете предоставлять полномочия на использование операторов с помощью Enterprise Manager или T-SQL.
Чтобы использовать Enterprise Manager для предоставления полномочий на использование операторов для баз данных какому-либо пользователю, выполните следующие шаги.
Для предоставления полномочий на использование операторов какому-либо пользователю с помощью T-SQL применяется оператор
GRANT { ALL | оператор }
TO учетная_запись_безопасности
Пользователю могут быть предоставлены полномочия на использование операторов CREATE TABLE пользовательской учетной записи JackR, используйте следующий оператор:
GRANT CREATE DATABASE, CREATE TABLE TO 'JackR'
Как видите, добавление полномочий на использование операторов в пользовательскую учетную запись не представляет каких-либо сложностей.
Вы можете использовать оператор T-SQL
REVOKE { ALL | оператор }
FROM учетная_запись_безопасности
Например, для удаления из учетной записи пользователя JackR только полномочий на использование оператора
REVOKE CREATE DATABASE FROM 'JackR'
Как видите, удаление полномочий на использование операторов из пользовательской учетной записи не представляет каких-либо сложностей.
Вы можете упростить задачу управления многими полномочиями для многих пользователей путем использования ролей для
Обычно роли создаются для определенных рабочих групп, классов работ или задач. При этом подходе новые пользователи могут становиться членами одной или нескольких ролей баз данных, исходя из заданий, которые они будут выполнять. Например, роли можно определять для классов работ, таких как счета кредиторов, проектирование и использование людских ресурсов. Если пользователь включается в один из этих отделов или групп, то он просто становится членом (участником) роли, созданной для этой группы. Пользователь может быть членом одной или нескольких ролей, но это не является обязательным требованием. Кроме участия в какой-либо роли
Для выполнения задач создания и модифицирования ролей баз данных используются те же средства, что и для выполнения большинства задач, относящихся к администрированию баз данных: Enterprise Manager или операторы T-SQL. (В SQL Server нет мастера для этих задач.) Используя любое из этих средств, вы должны выполнить следующие задачи при реализации роли.
Просматривая свойства роли, вы увидите как полномочия, предоставленные этой роли, так и пользователей, назначенных для этой роли.
Для создания ролей базы данных с помощью Enterprise Manager выполните следующие шаги.
В этом окне вы можете присваивать данной роли различные полномочия доступа к объектам базы данных, содержащей эту роль. Для этого установите нужные флажки в окне списка. Объекты базы данных приводятся в списке колонки Object. Вы можете использовать кнопки выбора вверху этого окна, чтобы включить в список все объекты (первая кнопка выбора) или только те объекты, к которым уже имеет полномочия доступа данная роль. Назначив данную роль какому-либо пользователю, вы предоставляете этому пользователю все полномочия, присвоенные данной роли.
После создания роли вы можете модифицировать ее в окне Database Role Properties. Чтобы модифицировать роль, выполните шаги, используемые для добавления полномочий к роли. Вы можете добавлять или удалять пользователей и полномочия в окне Database Role Properties.
Вы можете также создавать роли с помощью хранимой процедуры sp_addrole. Эта хранимая процедура имеет следующий синтаксис:
sp_addrole [ @rolename = ] ''роль'
[ , [ @ownername = ] 'владелец' ]
Например, добавить роль с именем readonly к базе данных Northwind, используйте следующий оператор T-SQL:
USE Northwind GO sp_addrole 'readonly' , 'dbo' GO
Оператор USE Northwind указывает Northwind как текущую базу данных. Если не указать базу данных, то роль будет создана в базе данных, принятой у вас по умолчанию.
Эта хранимая процедура только создает роль. Чтобы добавить полномочия к этой роли, используйте описанный выше оператор
Например, чтобы добавить в роль readonly полномочия типа SELECT по таблицам Employees, Customers и Orders, используйте следующий оператор
USE Northwind GO GRANT SELECT ON Employees TO readonly GO GRANT SELECT ON Customers TO readonly GO
Чтобы добавить пользователей к этой роли, используйте хранимую процедуру sp_addrolemember. Хранимая процедура sp_addrolemember имеет следующий синтаксис:
sp_addrolemember 'роль', 'учетная_запись_безопасности'
Следующий оператор добавляет пользователя к роли readonly:
USE Northwind GO sp_addrolemember 'readonly' , 'Guest' GO
Во время инсталляции SQL Server создается ряд заранее определенных ролей, которые применяются на уровне сервера. Эти фиксированные роли на сервере используются для предоставления полномочий
Присваивая пользовательские учетные записи фиксированным ролям на сервере, вы позволяете пользователям осуществлять административные задачи, полномочия на выполнение которых имеют эти роли. В зависимости от ваших потребностей это может оказаться предпочтительнее использования всеми
SQL Server 2000 использует средства безопасности Windows 2000 с помощью модели безопасности
Рассмотрим пример делегирования учетной записи безопасности. Предположим, что клиент подсоединяется к серверу ServerA как NTDOMAIN\AlexR, а ServerA подсоединяется к серверу ServerB. Тем самым ServerB "знает", что подсоединение осуществляется с помощью учетной записи системы безопасности NTDOMAIN\AlexR. Это позволяет клиенту обойтись без регистрации на сервере ServerB.
Если вы хотите использовать делегирование учетной записи безопасности, то все серверы, к которым вы подсоединяетесь, должны работать под управлением Windows 2000 с активизированной поддержкой
Прежде чем использовать делегирование учетных записей безопасности, вы должны сконфигурировать SQL Server, чтобы он допускал делегирование. Делегирование вызывает взаимную аутентификацию. Чтобы можно было использовать делегирование учетных записей безопасности, SQL Server 2000 должен иметь SPN-имя (Service Principal Name), назначенное администратором учетных записей домена Windows 2000. SPN-имя должно быть присвоено служебной учетной записи сервера SQL Server на данном компьютере. SPN-имя необходимо для проверки того, что SQL Server верифицирован на определенном сервере и по определенному адресу порта (socket) администратором учетных записей домена Windows 2000. Администратор вашего домена может задать SPN-имя для SQL Server с помощью утилиты Setspn, входящей в комплект Windows 2000 Resource Kit. Чтобы создать SPN-имя для SQL Server, запустите следующий оператор:
setspn -A MSSQLSvc/Host:port serviceaccount
Вот пример использования этого оператора:
setspn -A MSSQLSvc/MyServer.MyDomain.MyCompany.com sqlaccount
Setspn см. в документации Windows 2000.Чтобы использовать делегирование учетных записей безопасности, вы должны также использовать TCP/IP. Вы не можете использовать именованные каналы (named pipes), поскольку SPN-имя указывает определенный порт (socket) TCP/IP. Если вы используете несколько портов, то должны иметь SPN для каждого порта.
Вы можете активизировать делегирование с помощью учетной записи LocalSystem. SQL Server выполнит саморегистрацию при запуске службы и автоматически зарегистрирует SPN-имя. Этот вариант проще, чем активизация с помощью пользовательской учетной записи в домене. Однако при закрытии SQL Server SPN-имена будут лишены регистрации для учетной записи LocalSystem. Чтобы активизировать делегирование под учетной записью LocalSystem, выполните следующий оператор в утилите Setspn:
setspn -A MSSQLSvc/Host:port serviceaccount
В этой лекции вы узнали об управлении пользователями и системой безопасности SQL Server. Вы узнали, как используются учетные записи подключения (login-записи) и учетные записи
В этой лекции вы узнаете, как управлять пользователями и системой безопасности в среде Microsoft SQL Server 2000. Вместе с планированием резервного копирования и восстановления, определением состава системы и управлением дисковым пространством управление системой безопасности является одной из наиболее характерных задач для администратора баз данных (
Эта лекция охватывает ряд тем, относящихся к управлению пользователями и системой безопасности. Вы узнаете о том, как создавать пользовательские login-записи* (пользовательские учетные записи подключения к SQL Server) и управлять ими, а также о режимах аутентификации; кроме того, вы узнаете об идентификаторах пользователей. Пользовательская login-запись (user login) используется для аутентификации доступа к SQL Server. Она может аутентифицироваться через систему Microsoft Windows NT, Windows 2000 или SQL Server. Идентификатор пользователя (user ID) используется, чтобы присваивать пользовательские полномочия для доступа к определенным объектам в отдельных базах данных. Идентификаторы пользователей связаны с пользовательскими учетными записями и могут содержать (или не содержать) одно и то же имя, как вы увидите далее. Вы также узнаете о типах полномочий, которые могут быть присвоены в SQL Server, а также об их использовании. Кроме того, вы узнаете, как использовать роли для более простого управления пользователями. И, наконец, вы узнаете о важном средстве в SQL Server 2000, которое называется делегированием учетной записи безопасности. К концу этой лекции вы получите знания, необходимые для управления пользовательскими login-записями и системой безопасности.
Начнем изучение средств управления пользователями и системой безопасности с рассмотрения пользовательских login-записей. В этом разделе мы опишем сначала, почему так важны login-записи, и рассмотрим методы аутентификации, которые можно использовать для поддержки login-записей. Затем мы рассмотрим три метода создания login-записей: использование SQL Server Enterprise Manager, использование Transact-SQL (T-SQL) и использование мастера создания учетных записей Create Login Wizard. И, наконец, мы увидим, как использовать Enterprise Manager и T-SQL для создания новых пользовательских login-записей.
Пользовательские login-записи позволяют вам защищать свои данные от преднамеренного или непреднамеренного модифицирования несанкционированными (неавторизованными) пользователями. С помощью пользовательских login-записей SQL Server может аутентифицировать отдельных авторизованных пользователей. Каждой пользовательской login-записи присваивается уникальное имя и пароль. Каждому пользователю присваивается его собственная учетная login-запись для входа в SQL Server. Без пользовательских login-записей для всех соединений с SQL Server использовался бы один и тот же идентификатор, а это означает, что вы не могли бы создавать различные уровни безопасности для тех, кто осуществляет доступ к базе данных.
Вы можете создавать различные уровни безопасности, предоставляя различным учетным login-записям различные полномочия для доступа к объектам и выполнения функций. Вы можете также шифровать определенные объекты базы данных, такие как хранимые процедуры и представления, чтобы скрывать их определения от неавторизованных пользователей. Кроме того, используя пользовательские login-записи, вы можете разрешать вставку и обновление информации в определенных таблицах базы данных только некоторым пользователям и предоставлять доступ к этим таблицам по чтению основной массе пользователей.
Чтобы увидеть, как осуществляется ограничение доступа к данным с помощью пользовательских login-записей, вернемся к примеру, впервые представленному в лекции 18, где показано использование представлений для ограничения доступа к критически важным данным. Предположим, что у нас имеется таблица Employee, содержащая информацию о сотрудниках, включая имя каждого сотрудника, номер телефона, номер офиса), должность, заработную плату, надбавку и т.д. Чтобы воспрепятствовать доступу определенных пользователей к конфиденциальным данным этой таблицы, сначала нужно создать представление, содержащее только общедоступные данные, такие как имена сотрудников, номера телефонов и номера офисов. Затем, реализуя пользовательские login-записи, вы можете ограничить доступ к исходной таблице, разрешив при этом доступ всех пользователей к представлению. Но если не использовать возможности пользовательских login-записей, то любой пользователь будет иметь доступ и к представлению, и к таблице, что лишает смысла использование этого представления.
Для доступа к SQL Server можно использовать два режима аутентификации: режим аутентификации Windows (Windows Authentication) и режим смешанной аутентификации (Mixed Mode Authentication). В первом случае аутентификация пользователя осуществляется операционной системой Windows. Затем SQL Server использует аутентификацию этой операционной системы, чтобы определить, какие пользовательские полномочия можно применять в каждом случае. В смешанном режиме аутентификацию пользователя осуществляют как Windows NT/2000, так и SQL Server. Для доступа к SQL Server вы должны в любом случае сначала осуществить вход по учетной записи Windows NT/2000, поэтому при выборе режима аутентификации вы должны решить, нужно ли вам использовать аутентификацию SQL Server в дополнение к аутентификации Windows. Рассмотрим каждый из этих режимов аутентификации более подробно. Ниже в этом разделе вы узнаете, как реализовать оба этих режима.
Как уже говорилось, при аутентификации с помощью Windows обеспечение безопасности для SQL Server осуществляет с помощью учетных записей система Windows NT/2000. При подсоединении пользователя к Windows NT/2000 эта система проверяет подлинность пользователя по его учетной записи. SQL Server "убеждается" в том, что пользователь был проверен системой Windows NT/2000, и разрешает доступ, основываясь на этой аутентификации. Для этого используется интеграция процесса проверки login-записей SQL Server с процессом проверки учетных записей в Windows. Атрибуты безопасности на уровне сети проверяются с помощью сложного процесса шифрования, обеспечиваемого в Windows NT/2000. После аутентификации операционной системой в этом режиме дальнейшая аутентификация для доступа к SQL Server уже не требуется. Для доступа к SQL Server вы должны только указать свой пароль доступа к Windows NT/2000.
Режим аутентификации Windows считается более надежным методом, чем режим смешанной аутентификации, за счет использования дополнительных средств безопасности. Это защищенная проверка и шифрование паролей, аудит, поддержка сроков действия паролей, минимальная длина паролей и автоматическое блокирование учетных записей после определенного количества безуспешных попыток входа.
В режиме смешанной аутентификации пользователи могут осуществлять доступ к SQL Server с помощью аутентификации в Windows или аутентификации в SQL Server. При соединении, осуществляемом в этом режиме из незащищенной системы, SQL Server аутентифицирует данные входа, проверяя, имеется ли учетная login-запись для пользователя, запрашивающего вход. SQL Server осуществляет аутентификацию по этой учетной login-записи путем сравнения имени и пароля пользователя, подсоединяющегося к SQL Server, с информацией учетной login-записи, хранящейся в базе данных. Если для этого пользователя не создана учетная login-запись или пользователь неверно указал имя или пароль, то SQL Server не разрешает доступ.
Режим аутентификации Windows недоступен, если SQL Server работает под управлением Windows 95/98, поэтому вы должны применять на этих платформах аутентификацию SQL Server (указывая режим смешанной аутентификации). Кроме того аутентификация SQL Server требуется для Web-приложений (с помощью Microsoft Internet Information Server), поскольку пользователи этих приложений, скорее всего, находятся не в том же домене, где сервер, и поэтому для них нельзя использовать систему безопасности Windows. Для других приложений также может потребоваться аутентификация SQL Server: некоторые разработчики предпочитают использовать для своих приложений систему безопасности SQL Server, поскольку это упрощает обеспечение безопасности их приложений. Если приложения используют систему безопасности SQL Server (в доверенной сети), то разработчики этих приложений не обязаны обеспечивать аутентификацию внутри самих приложений, что упрощает их работу.
Чтобы задать режим аутентификации, выполните следующие шаги.
(рис 34.1) Вкладка Security (Безопасность) окна SQL Server Properties В нескольких следующих разделах вы узнаете, как создавать login-записи и пользователей. Но прежде чем приступить к этому процессу, вы должны четко разобраться в таких понятиях, как учетные записи и пользователи. В этом разделе дается краткое описание этих двух терминов.
Как уже говорилось, пользовательская учетная запись Windows NT/2000 может потребоваться для подсоединения к базе данных. Независимо от используемого режима аутентификации (аутентификация Windows NT/2000 или режим смешанной аутентификации) учетная запись, которую вы используете для подсоединения к SQL Server, называется login-записью SQL Server (учетной записью подключения к SQL Server). Кроме этой учетной записи, каждая база данных имеет набор пользовательских учетных псевдозаписей, присвоенных этой базе данных. Эти учетные псевдозаписи являются
Вы можете выполнять большинство административных задач SQL Server, используя один из нескольких методов, и задача создания пользовательских login-записей не является исключением из этого правила. Как уже говорилось, вы можете создать login-запись, используя один из трех методов: с помощью Enterprise Manager, с помощью T-SQL или с помощью мастера создания login-записей Create Login Wizard. В этом разделе вы узнаете, как создавать login для SQL Server с помощью каждого их этих методов.
Чтобы создать login-запись для SQL Server с помощью Enterprise Manager, выполните следующие шаги.
(рис 34.3) Вкладка General окна SQL Server Login Properties(рис 34.2) Вкладка Server Roles (Роли сервера) окна SQL Server Login PropertiesДля создания login-записи с помощью T-SQL используется хранимая процедура sp_addlogin или хранимая процедура sp_grantlogin. Хранимая процедура sp_addlogin позволяет только добавлять аутентифицированного в SQL Server пользователя к базе данных SQL Server. Хранимая процедура sp_grantlogin позволяет добавлять пользователя, аутентифицированного в системе Windows NT/2000.
Хранимая процедура sp_addlogin имеет следующий синтаксис:
sp_addlogin [ @loginame = ] 'имя_login-записи'
[ , [ @passwd = ] 'пароль' ]
[ , [ @defdb = ] 'база данных' ]
[ , [ @deflanguage = ] 'язык' ]
[ , [ @sid = ] 'sid' ]
[ , [ @encryptopt = ] 'параметр_шифрования' ]
Используются следующие необязательные параметры.
NULL.master.sid обычно не генерируется пользователями, но администраторы используют sid в ряде ситуаций. Когда sid может потребоваться, чтобы определить проверяемую login-запись. Параметр sid является внутренним идентификатором для login-записи.NULL, означающее, что пароль будет шифроваться. Значение skip_encryption (пропустить шифрование) означает, что пароль не будет шифроваться. Если указать значение skip_encryption_old, то пароль, зашифрованный в более ранней версии SQL Server, не будет шифроваться еще раз. Вам следует изменять значение по умолчанию, только если вы хотите избежать шифрования пароля в системных таблицах.Ниже приводится простой пример добавления login-записи:
EXEC sp_addlogin 'PatB'
Не забудьте использовать ключевое слово EXEC перед именем хранимой процедуры.
Ниже приводится более сложный пример добавления login-записи:
sp_addlogin 'SharonR', 'mypassword', 'Northwind', 'us_english'
Эта команда создает пользователя с именем SharonR и паролем "mypassword." По умолчанию будет использоваться база данных Northwind, и язык по умолчанию – U.S. English. В обычном случае вы должны предоставить создание идентификатора безопасности (SID) SQL Server вместо самостоятельного создания этого идентификатора.
Хранимая процедура sp_grantlogin имеет следующий синтаксис:
sp_grantlogin 'имя_login-записи'
Ниже показан пример использования хранимой процедуры sp_grantlogin:
EXEC sp_grantlogin 'MOUNTAIN_DEW\DickB'
"DickB" –
Добавив эти login-записи, вы можете просматривать их в Enterprise Manager. Для этого щелкните на папке Logins в левой панели.
Чтобы создать login-запись для SQL Server с помощью мастера Create Login Wizard, выполните следующие шаги.
(рис 34.6) Окно Select Wizard(рис 34.5) Начальное окно мастера Create Login Wizard(рис 34.8) Окно Select Authentication Mode for This Login (Выбор режима аутентификации для данной login-записи)(рис 34.7) Окно Authentication with SQL Server (Аутентификация с помощью Windows)(рис 34.10) Окно Grant Access to Security Roles (Предоставление доступа ролям безопасности)(рис 34.9) Окно Grant Access to Databases (Предоставление доступа к базам данных)(рис 34.11) Окно Completing the Create Login Wizard (Завершение работы мастера)Вы можете создавать пользователей SQL Server с помощью Enterprise Manager или T-SQL. (В SQL Server нет мастера, с помощью которого можно выполнять этот процесс.) В этом разделе вы узнаете, как использовать оба этих метода для создания пользователей SQL Server. Напомним, что пользователь SQL Server определяется для определенной базы данных, а полномочия доступа к этой базе данных присваиваются определенной пользовательской login-записи. Идентификатор пользователя (user ID) SQL Server можно рассматривать как аналог login-записи SQL Server, но они не обязательно имеют одинаковые имена.
В отличие от login-записей SQL Server, которые создаются из папки Security в Enterprise Manager, пользователи SQL Server создаются из папки определенной базы данных в левой панели Enterprise Manager. Для создания пользователей с помощью Enterprise Manager выполните следующие шаги.
Чтобы использовать T-SQL для создания sp_adduser. Эту хранимую процедуру можно запустить из ISQL или OSQL с использованием следующего синтаксиса:
sp_adduser [ @loginame = ] 'имя_login-записи'
[ , [ @name_in_db = ] 'пользователь' ]
[ , [ @grpname = ] 'группа' ]
Имя_login-записи – это имя учетной login-записи SQL Server, которое является обязательным параметром. Переменная пользователь – это имя нового пользователя, и группа – это группа или роль, к которой будет принадлежать новый пользователь. Если значение параметра пользователь не указано, то оно совпадает со значением параметра имя_login-записи.
С помощью следующей команды создается новый пользователь базы данных с именем JackR и учетной записью Windows NT или Windows 2000 FORT_WORTH\ DB_User:
sp_adduser 'FORT_WORTH\DB_User', 'JackR'
"FORT_WORTH" – имя системы или домена. "DB_User" –
Полномочия используются для управления доступом к объектам баз данных; они указывают, какие пользователи могут выполнять определенные операции с базой данных. Вы можете задавать полномочия на уровне сервера и на уровне базы данных. Полномочия на уровне сервера используются для того, чтобы администраторы баз данных (
Как уже говорилось, полномочия на уровне сервера присваиваются SHUTDOWN, и
Полномочия на уровне объектов базы данных – это класс полномочий, которые предоставляются для доступа к объектам базы данных. Полномочия доступа к объектам необходимы для доступа к таблице или представлению с помощью таких операторов, как SELECT, INSERT, UPDATE и DELETE. Полномочия доступа к объектам также требуются для использования оператора EXECUTE, который применяется для запуска хранимых процедур. Для присваивания полномочий доступа к объектам используются Enterprise Manager и операторы T-SQL.
Чтобы использовать Enterprise Manager для предоставления полномочий доступа к объектам базы данных, выполните следующие шаги.
SELECT, INSERT, UPDATE, DELETE, EXEC и DRI окна списка. ("DRI" – сокращение от "declarative Чтобы использовать T-SQL для присваивания какому-либо пользователю полномочий доступа к объектам, вы должны выполнить оператор
GRANT { ALL | полномочия }
[ колонка ON {таблица | представление} ] |
[ ON таблица(колонка) ] |
[ ON представление(колонка) ] |
[ ON { хранимая_процедура | расширенная_процедура } ]
TO учетная_запись_безопасности
[ WITH GRANT OPTION ]
[ AS { группа | роль } ]
Параметр учетная_запись_безопасности может быть представлен одним из следующих типов учетных записей:
Использование ключевого слова
Необязательный параметр AS указывает, кто имеет право на выполнение этого оператора
Ниже приводится пример использования оператора
GRANT SELECT, INSERT, UPDATE ON Customers TO MaryW WITH GRANT OPTION AS Accounting
Параметр AS Accounting используется потому, что роль Accounting имеет полномочия на предоставление полномочий по таблице Customers. Ключевое слово
GRANT Для отзыва полномочий какого-либо пользователя по объектам вы можете использовать оператор T-SQL
REVOKE [ GRANT OPTION FOR ]
{ ALL [ PRIVILEGES ] | полномочия }
[ колонка ON {таблица | представление} ] |
[ ON таблица(колонка) ] |
[ ON представление(колонка) ] |
[ ON { хранимая_процедура | расширенная_процедура } ]
{ TO | FROM } учетная_запись_безопасности
[ CASCADE ]
[ AS { группа | роль } ]
Параметр учетная_запись_безопасности может быть представлен одним из следующих типов учетных записей:
Ключевое слово
Ниже приводится пример использования оператора
REVOKE ALL ON Customers FROM MaryW
REVOKE Кроме полномочий доступа к объектам баз данных, вы можете также предоставлять полномочия на использование операторов. Полномочия доступа к объектам позволяют пользователям выполнять доступ к существующим объектам базы данных, в то время как полномочия на использование операторов позволяют им создавать объекты баз данных, включая базы данных и таблицы. Можно предоставлять следующие полномочия на использование операторов.
BACKUP DATABASE.BACKUP LOG Вы можете предоставлять полномочия на использование операторов с помощью Enterprise Manager или T-SQL.
Чтобы использовать Enterprise Manager для предоставления полномочий на использование операторов для баз данных какому-либо пользователю, выполните следующие шаги.
Для предоставления полномочий на использование операторов какому-либо пользователю с помощью T-SQL применяется оператор
GRANT { ALL | оператор }
TO учетная_запись_безопасности
Пользователю могут быть предоставлены полномочия на использование операторов CREATE TABLE пользовательской учетной записи JackR, используйте следующий оператор:
GRANT CREATE DATABASE, CREATE TABLE TO 'JackR'
Как видите, добавление полномочий на использование операторов в пользовательскую учетную запись не представляет каких-либо сложностей.
Вы можете использовать оператор T-SQL
REVOKE { ALL | оператор }
FROM учетная_запись_безопасности
Например, для удаления из учетной записи пользователя JackR только полномочий на использование оператора
REVOKE CREATE DATABASE FROM 'JackR'
Как видите, удаление полномочий на использование операторов из пользовательской учетной записи не представляет каких-либо сложностей.
Вы можете упростить задачу управления многими полномочиями для многих пользователей путем использования ролей для
Обычно роли создаются для определенных рабочих групп, классов работ или задач. При этом подходе новые пользователи могут становиться членами одной или нескольких ролей баз данных, исходя из заданий, которые они будут выполнять. Например, роли можно определять для классов работ, таких как счета кредиторов, проектирование и использование людских ресурсов. Если пользователь включается в один из этих отделов или групп, то он просто становится членом (участником) роли, созданной для этой группы. Пользователь может быть членом одной или нескольких ролей, но это не является обязательным требованием. Кроме участия в какой-либо роли
Для выполнения задач создания и модифицирования ролей баз данных используются те же средства, что и для выполнения большинства задач, относящихся к администрированию баз данных: Enterprise Manager или операторы T-SQL. (В SQL Server нет мастера для этих задач.) Используя любое из этих средств, вы должны выполнить следующие задачи при реализации роли.
Просматривая свойства роли, вы увидите как полномочия, предоставленные этой роли, так и пользователей, назначенных для этой роли.
Для создания ролей базы данных с помощью Enterprise Manager выполните следующие шаги.
В этом окне вы можете присваивать данной роли различные полномочия доступа к объектам базы данных, содержащей эту роль. Для этого установите нужные флажки в окне списка. Объекты базы данных приводятся в списке колонки Object. Вы можете использовать кнопки выбора вверху этого окна, чтобы включить в список все объекты (первая кнопка выбора) или только те объекты, к которым уже имеет полномочия доступа данная роль. Назначив данную роль какому-либо пользователю, вы предоставляете этому пользователю все полномочия, присвоенные данной роли.
После создания роли вы можете модифицировать ее в окне Database Role Properties. Чтобы модифицировать роль, выполните шаги, используемые для добавления полномочий к роли. Вы можете добавлять или удалять пользователей и полномочия в окне Database Role Properties.
Вы можете также создавать роли с помощью хранимой процедуры sp_addrole. Эта хранимая процедура имеет следующий синтаксис:
sp_addrole [ @rolename = ] ''роль'
[ , [ @ownername = ] 'владелец' ]
Например, добавить роль с именем readonly к базе данных Northwind, используйте следующий оператор T-SQL:
USE Northwind GO sp_addrole 'readonly' , 'dbo' GO
Оператор USE Northwind указывает Northwind как текущую базу данных. Если не указать базу данных, то роль будет создана в базе данных, принятой у вас по умолчанию.
Эта хранимая процедура только создает роль. Чтобы добавить полномочия к этой роли, используйте описанный выше оператор
Например, чтобы добавить в роль readonly полномочия типа SELECT по таблицам Employees, Customers и Orders, используйте следующий оператор
USE Northwind GO GRANT SELECT ON Employees TO readonly GO GRANT SELECT ON Customers TO readonly GO
Чтобы добавить пользователей к этой роли, используйте хранимую процедуру sp_addrolemember. Хранимая процедура sp_addrolemember имеет следующий синтаксис:
sp_addrolemember 'роль', 'учетная_запись_безопасности'
Следующий оператор добавляет пользователя к роли readonly:
USE Northwind GO sp_addrolemember 'readonly' , 'Guest' GO
Во время инсталляции SQL Server создается ряд заранее определенных ролей, которые применяются на уровне сервера. Эти фиксированные роли на сервере используются для предоставления полномочий
Присваивая пользовательские учетные записи фиксированным ролям на сервере, вы позволяете пользователям осуществлять административные задачи, полномочия на выполнение которых имеют эти роли. В зависимости от ваших потребностей это может оказаться предпочтительнее использования всеми
SQL Server 2000 использует средства безопасности Windows 2000 с помощью модели безопасности
Рассмотрим пример делегирования учетной записи безопасности. Предположим, что клиент подсоединяется к серверу ServerA как NTDOMAIN\AlexR, а ServerA подсоединяется к серверу ServerB. Тем самым ServerB "знает", что подсоединение осуществляется с помощью учетной записи системы безопасности NTDOMAIN\AlexR. Это позволяет клиенту обойтись без регистрации на сервере ServerB.
Если вы хотите использовать делегирование учетной записи безопасности, то все серверы, к которым вы подсоединяетесь, должны работать под управлением Windows 2000 с активизированной поддержкой
Прежде чем использовать делегирование учетных записей безопасности, вы должны сконфигурировать SQL Server, чтобы он допускал делегирование. Делегирование вызывает взаимную аутентификацию. Чтобы можно было использовать делегирование учетных записей безопасности, SQL Server 2000 должен иметь SPN-имя (Service Principal Name), назначенное администратором учетных записей домена Windows 2000. SPN-имя должно быть присвоено служебной учетной записи сервера SQL Server на данном компьютере. SPN-имя необходимо для проверки того, что SQL Server верифицирован на определенном сервере и по определенному адресу порта (socket) администратором учетных записей домена Windows 2000. Администратор вашего домена может задать SPN-имя для SQL Server с помощью утилиты Setspn, входящей в комплект Windows 2000 Resource Kit. Чтобы создать SPN-имя для SQL Server, запустите следующий оператор:
setspn -A MSSQLSvc/Host:port serviceaccount
Вот пример использования этого оператора:
setspn -A MSSQLSvc/MyServer.MyDomain.MyCompany.com sqlaccount
Setspn см. в документации Windows 2000.Чтобы использовать делегирование учетных записей безопасности, вы должны также использовать TCP/IP. Вы не можете использовать именованные каналы (named pipes), поскольку SPN-имя указывает определенный порт (socket) TCP/IP. Если вы используете несколько портов, то должны иметь SPN для каждого порта.
Вы можете активизировать делегирование с помощью учетной записи LocalSystem. SQL Server выполнит саморегистрацию при запуске службы и автоматически зарегистрирует SPN-имя. Этот вариант проще, чем активизация с помощью пользовательской учетной записи в домене. Однако при закрытии SQL Server SPN-имена будут лишены регистрации для учетной записи LocalSystem. Чтобы активизировать делегирование под учетной записью LocalSystem, выполните следующий оператор в утилите Setspn:
setspn -A MSSQLSvc/Host:port serviceaccount
В этой лекции вы узнали об управлении пользователями и системой безопасности SQL Server. Вы узнали, как используются учетные записи подключения (login-записи) и учетные записи
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.