Служба Рассылок Городского Кота

#9

DBA И БЕЗОПАСНОСТЬ

ВНИМАНИЕ!!DANGER!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Microsoft выпустил заплату для обнаруженной недавно уязвимости
хранимых процедур SQL 7.0.
Согласно бюллетеню Microsoft (Q266766), в SQL 7.0 заданные
ограничения на права доступа к хранимым процедурам могут быть
обойдены при вызове хранимой процедуры из временной хранимой
процедуры.
Отсутствие проверки прав доступа могло позволить
несанкционированно выполнять хранимые процедуры, которые
обычному пользователю не  доступны. Уязвимость существует,
когда база данных и хранимая процедура принадлежат системному
администратору (sa), а пользователь, осуществляющий вторжение,
способен пройти аутентификацию и получить доступ к базе данных.
Intel: http://www.microsoft.com/Downloads/Release.asp?ReleaseID=22470
Alpha: http://www.microsoft.com/Downloads/Release.asp?ReleaseID=22469
ВНИМАНИЕ!!DANGER!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

СОВЕТ

По материалам: SWYNK.COM "SQL Server Tip Library"
Tip by: Lowell Smith (LowellS@fool.com)
http://www.swynk.com/sqlhome/tips/default.asp

Чтобы быстро просмотреть содержимое errorlog (файл регистрации
ошибок SQL Server), наберите в QA (анализатор запросов) следующий
текст на T-SQL:

USE MASTER
GO
EXEC SP_READERRORLOG
GO

Используя персональные средства, такие как Excel или Access, вы
можете связать их с этой хранимой процедурой и использовать их
преимущества для более удобного представления данных из errorlog.


ГОТОВИМСЯ К ТЕСТУ ПО 1139A

ШПАРГАЛКА #3  продолжение (обзор официального курса Microsoft)

Администрирование учe:тных записей

Мы уже знаем, что существует два пути создания учe:тных записей: с
помощью средств NT и непосредственно в SQLS7. Таким образом, для
SQLS7 могут существовать одновременно записи пользователей и групп
NT, собственные (созданные администратором) записи SQLS7 и
установленные по умолчанию (такие, как SA, BUILTIN\Administrator и
guest). Все эти записи хранит системная таблица syslogins. Для новой
записи права назначаются к установленной по умолчанию базе данных.
Полные права имеют записи SA и BUILTIN\Administrator, причe:м под
второй подключаются все администраторы NT.
Проще всего добавить новую запись или установить права учe:тной
записи NT с помощью SQL SEM. Однако, если вы сисадмин или
администратор безопасности SQLS7, Вы можете использовать
непосредственно системные хранимые процедуры, для
администрирования учe:тных записей:
Sp_grantlogin {"имя домена \ учe:тная запись NT" до 128 символов}
- подключение записи/группы NT к SQLS7;
Sp_revokelogin {...} - удаляет подключение записи/группы NT к SQLS7;
Sp_denylogin {...} - запрещает подключение записи/группы NT к SQLS7.
Используя систему аутентификации Windows NT, Вы в полной мере
сможете насладиться теми возможностями и сервисам, которые
предоставляет связка этой ОС с SQLS7. Например, использование одной
записи для группы NT позволяет свободно менять состав этой группы
средствами администрирования домена даже не обращаясь к средствам
SQLS7. После подключения группы или записи к SQLS7, соответствующие
записи в таблице syslogins можно удалить только средствами SQLS7.
Порядок удаления записей такой: вначале удаляем пользователя или
группу NT, а потом убираем запись в SQLS7. Получить имя учe:тной записи
NT и домена, к которому она приписана можно с помощью функции
SUSER_SNAME.
Для добавления в SQLS7 учe:тной записи, не входящей в домен или
входящей, но требующей уникальных прав не сопоставимых ни с одной
из групп NT, можно использовать системную хранимую процедуру:
Sp_addlogin {"имя учe:тной записи SQLS7" до 128 символов, не пустое,
не SA и без "\"}.
Изменение пароля пользователей SQLS7 можно осуществить с помощью:
Sp_password. Обычные пользователи могут сменить только свои пароли,
а DBA может всe: (вместо старого пароля вводится NULL).

Сопоставление учe:тных записей ролям и пользователям

Используя доверительное подключение групп NT к SQLS7 Вы, тем
самым, уже получаете возможность регулирования прав доступа к
объектам SQLS7. Но, поскольку NT не единственный источник
пользователей, сам SQLS7 имеет обширный набор возможностей для
разграничения прав доступа зарегистрированных в таблице sysusers
пользователей к своим объектам. Одной из главных задач DBA по
обеспечению безопасности данных является грамотное сопоставление
учe:тных записей подключения пользователям и ролям. Данные о каждом
пользователе/группе NT, каждом пользователе SQLS7 и о каждой роли в
базе данных записываются в sysusers, а права доступа для них хранятся в
каждой базе данных в таблице sysprotects.
Кроме SQL SEM, добавить любую из зарегистрированных учe:тных записей
SQLS7 к базе данных можно с помощью системной процедуры:
Sp_grantdbaccess {"имя учe:тной записи"} [, "имя в базе данных"]
Таким образом, Вы не только можете использовать назначенную
пользователю учe:тную запись SQLS7, но и задать любое подходящее для
него имя в базе данных. Поскольку указанная процедура затрагивает
жизненно - важные области базы данных, исполнить еe: может либо
владелец базы, либо имеющий права администратора пользователь.
Естественно, кроме добавления возможно и удаление (Sp_revokedbaccess)
и изменение (Sp_change_user_login).
Что бы наглядно рассмотреть сопоставление учe:тных записей
пользователей учe:тным записям подключения, давайте обратимся к двум
учe:тным записям, всегда присутствующим в вашем SQLS7, это
DBO и GUEST.
DBO всегда сопоставляется SA и членам роли sysadmin
(System Administrators). Кроме того, что dbo не может быть удалена, она
ещe: и владелец для всех баз данных, которые были, есть и будут созданы
в будущем.
В отличие от dbo, учe:тная запись guest может быть удалена из всех баз
данных, кроме master и tempdb. Иногда бывает удобно, что бы к SQLS7
могли подключиться "гости" или, что бы пользователь имел доступ к
SQLS7, но для некоторых баз данных он всe: равно оставался "гостем".

Роли SQLS7

Для сложных, многопрофильных приложений баз данных большую помощь
в разграничении полномочий между пользователями и/или
администраторами SQLS7 может предоставить механизм ролей. Когда
необходимо выстроить многоуровневую иерархическую схему
взаимодействия с набором баз данных исходя из должностных обязанностей
пользователей и разграничения прав доступа администраторов приложений
и различных баз данных, Вы в полной мере можете рассчитывать на
возможности SQLS7 с помощью ролей решать поставленную задачу.
Фиксированные роли сервера и баз данных, а также пользовательские роли
баз данных помогут Вам оперировать не правами доступа каждого
пользователя SQLS7, а понятием роли в смыли набора должностных функций
или прав доступа применительно к группе пользователей, которые, в сою
очередь, могут входить (или не входить вообще) в разные группы NT,
числится в разных доменах, работать на платформе отличной от Windows,
подключаться к серверу через коммуникационные каналы, относится к
разным структурным подразделениям вашей организации и т.д. и т.п.
В виду того, что допускается вложение ролей друг в друга (кроме
рекурсивного), Вы можете строить иерархию ролей по доменной схеме.
В нижних ярусах будут роли с элементарными наборами прав, а в вершине
пирамиды окажутся состоящие из наборов элементарных ролей роли
старших менеджеров и администраторов баз данных и приложений. Принцип
достаточно прост: если учe:тная запись входит во многие роли, то в
результате
права доступа являются объединением предусмотренных этими ролями
прав (исключением является только запрет доступа, который имеет более
высокий приоритет над остальными правами).Такой подход позволит
значительно облегчить изменение прав доступа пользователей в связи с
кадровыми перестановками, а также облегчит Вам работу, если потребуется
вносить изменения в состав прав доступа группы технологически
связанных пользователей, если назрела необходимость преобразования
их должностных функций/технологий. Не стоит только сильно злоупотреблять
вложением ролей друг в друга, да бы не пострадала производительность
сервера.
Фиксированные роли сервера в первую очередь направлены на
разграничение функций администрирования SQLS7. Местом их дислокации
является таблица syslogins базы master. Как обычно, кроме SQL SEM,
включить пользователя в фиксированную роль можно с помощью
Sp_addsrvrolemember {учe:тная запись, фикс. серв. роль}, при условии,
что вы член этой фиксированной роли (Sp_dropsrvrolemember - для удаления).
Поскольку роли фиксированные, Вам не удастся их удалить, изменить
или добавить. Также Вы не сможете выполнять указанную выше
системную хранимую процедуру в рамках запущенной пользователем
транзакции. Названия фиксированных серверных ролей говорят сами
за себя: sysadmin, dbcreator, diskadmin, processadmin (только относящихся
к SQLS7), serveradmin, setupadmin (настройка репликаций), securityadmin
(подключения к SQLS7 и аудит).
Такими же бессмертными являются фиксированные роли баз данных.
Если для серверных ролей объектом доступа был сам SQLS7, то для
фиксированных ролей баз данных объектом являются базы данных и
всe:, что их составляет. Кроме того, эти роли хранятся непосредственно
в базах, причe:м каждая база данных содержит только относящийся к
ней набор ролей. Для больших не любителей SQL SEM, существует
системная хранимая процедура Sp_addrolemember {роль, учe:тная запись},
которой правда могут воспользоваться только те пользователи, которые
уже являются участниками соответствующей роли. Естественно
обратный процесс можно запустить с помощью Sp_droprolemember. Роль
баз данных бывают как разрешительные, так и запретительные.
Например, роли db_datareader и db_datawriter разрешают соответственно
чтение / добавление + изменение + удаление данных из всех таблиц базы.
В то же время роли db_denydatareader и db_denydatawriter несут
полностью противоположный смысл. Пять ролей несут
администраторские привилегии: db_accessadmin (управление
пользователями, группами и ролями), db_ddladmin (управление
объектами БД), db_securityadmin (доступ к операторам и объектам),
db_backupoperator (резервное копирование), db_owner (владелец всей
базы данных). Как и большинство систем оперирующих понятием
"пользователь", SQLS7 содержит специфическую фиксированную
роль баз данных - public. Любой пользователь SQLS7 автоматический
становится участником этой роли и будет там состоять, пока его
полностью не удалят. Абсолютно все базы SQLS7 имеют у себя эту
роль. Назначение этой роли понятно, существует целый ряд операций,
которые должны быть доступны абсолютно всем пользователям SQLS7
(печать, оповещения и т.п.). Поскольку все пользователи, группы и роли
 непременным образом входят в эту роль, добавление этой роли кому
бы - то ни было не имеет смысла и посему невозможно. Прелесть роли
public в том, что даже не имеющий никаких прав пользователь,
подключившись к SQLS7 уже может выполнять операторы или другие
задачи, которые не требуют специального разрешения (например,
оператор PRINT). Он может видеть содержание системных таблиц и даже
выполнять некоторые системные хранимые процедуры, а заодно, для тех
баз где этой роли определe:н Вами некий вариант доступа, он может
работать с пользовательскими базами, воспользовавшись учe:тной
записью guest.
К сожалению набор фиксированных ролей не в состоянии охватить все
возможные задачи группировки прав пользователей к ресурсам сервера
баз данных. Наверняка Вам придe:тся воспользоваться пользовательскими
ролями баз данных. Тем более, что у Вас просто не будет другого выхода,
если группы SQLS7 и NT не совпадают по составу пользователей или вы
не можете администрировать учe:тные записи NT. Для ярых не любителей
SQL SEM я бы всe: же рекомендовал использовать при работе с
пользовательскими ролями именно его, потому что эти роли являются
смертными и системных процедур для них придумано больше. Кроме того,
Вам придe:тся помнить, какие фиксированные роли могут создавать те
или иные пользовательские роли. Например, только db_securityadmin и
db_owner могут воспользоваться системной хранимой процедурой
Sp_addrole {роль, владелец}, которая в таблице sysusers текущей базы
создаст запись для Вашей новой пользовательской роли. Но когда Вам
потребуется добавить пользователя в эту новую роль, выяснится, что
кроме уже указанных двух фиксированных ролей баз данных, к ролям
способным это сделать добавится sysadmin, а процедурой будет всe: та
же Sp_addrolemember. Те же лица могут выполнять и обратные
действия с помощью; Sp_droprole и Sp_droprolemember.

Продолжение  следует.

РАБОТА ДЛЯ DBA (ТОЛЬКО ПОШЛИТЕ РЕЗЮМЕ)

POSITION ID: GBNYC319  EMAIL: Gregory.BondaRiva@rcmt.com
WEB: http://www.rcmt.com

POSITION ID: JT1771  EMAIL: jutaylor@mercdatasys.com
WEB: http://www.mercdatasys.com

Open Job Positions on swynk.com!
http://www.swynk.com/discuss_jobs


=====================================================
Пишите на: msSQLhelp@pisem.net
для Саши.