4.1. Как
проверяются
разрешения
4.2. Стоимость
изменений разрешений
4.3.
Переименование
пользователя Windows или учетной записи
группы
4.4. Выведена
из обращения системная таблица
sysprocedures
4.5. Опция
WITH GRANT
4.6. Системная
таблица sysusers
4.6.1. Столбец
hasdbaccess
4.7. Системная
таблица sysmembers
4.8.
Системная
таблица
syspermissions
4.9. Системная
таблица sysprotects
4.10. Безопасность
подключения по именованным каналам и по
мультипротоколу
4. Реализация безопасности на
уровне объектов
4.1. Как проверяются
разрешения
SQL Server 2000 использует SID для идентификации
пользователей и групп Windows. Однако, из-за большой длины SID
(до 85 байтов), SQL Server 2000 в таблице sysusers привязывает
SID к ID пользователя для каждой базы данных. ID пользователя
используется в таблице sysobjects для обозначения владельца
таблиц. Также он используется в таблице syspermissions, чтобы
зафиксировать разрешения на объекты и в таблице systypes для
обозначения владельца определяемых пользователем
типов.
Когда пользователь подключается к SQL Server 2000,
сервер создает в памяти структуру состояния процесса (Process
Status Structure - PSS), которая включает SID пользователя,
SID группы и другую информацию о безопасности и состоянии. Эта
структура является фиксированной во время пользовательского
соединения и не обновляется. Она существует в рамках сеанса
подключения к серверу каждого пользователя, и для каждого
сеанса будет своя PSS.
Когда пользователь подключается к
базе данных, SQL Server проверяет таблицу sysusers, чтобы
установить, был ли пользователь лишён доступа напрямую или
через включающие его группы. Если пользователь лишён доступа,
всё для него заканчивается, иначе таблица sysusers проверяется
снова, но на это раз собираются все относящиеся к пользователю
id для того, что бы его квалифицировать. После того, как это
сделано, что бы пользователю был предоставлен доступ к базе
данных, просматривается таблица sysmembers, чтобы выяснить, в
какие роли включён пользователь. Например, пользователь может
быть членом роли, членом группы Windows или переопределён на
другого пользователя. Пользовательские id всех имеющихся у
него ролей анализируются, чтобы можно было применить все
соответствующие ему разрешения. В отличие от структуры PSS,
эта информация не сохраняется.
Когда пользовательские
запросы обращаются к объектам базы данных, его разрешения
определяются из таблицу syspermissions для записей с
соответствующим id пользователя (как описано ранее). Сначала
проверяется Deny, и если оно найдено, пользователь не получить
доступ к объекту. Однако, если Deny не найдены, и записи
разрешающие пользователю запрашиваемый им доступ существуют,
доступ будет предоставлен. Для повышения эффективности,
разрешения на доступ будут кэшированы, чтобы при повторном
доступе к тем же самым объектам того же пользователя снизить
стоимость проверки разрешений доступа.
[В
начало]
4.2. Стоимость
изменений разрешений
Как сказано ранее, SQL Server 2000 кэширует разрешения на
объекты в рамках одного сеанса, чтобы снизить стоимость
проверки разрешений для повторного доступа к тем же самым
объектам. В отличие от PSS, который не изменяет информацию о
безопасности после того, как он создан, кэш разрешений всегда
актуален, что обеспечивает версионный метод. Когда
первоначальная проверка разрешений завершена, устанавливается
номер версии. Когда разрешения на объекты изменены, SQL Server
2000 увеличивает счетчик версии. Всякий раз, когда происходит
обращение к объекту, версия счетчика разрешений проверяется, и
если она отличается от счетчика в кэше, контент кэша
отвергается, и восстанавливаются действующие на этот момент
разрешения.
Кэширование безопасности используется всегда,
когда обращаются к объекту, и если значение счетчика версии не
изменилось. Если счетчик изменился, для текущей операции будет
затрачено немножко больше ресурсов.
[В
начало]
4.3. Переименование
пользователя Windows или учетной записи группы
В SQL Server 2000 можно предоставить пользователям и
группам Windows разрешение обращаться непосредственно к
объектам в базе данных. В этом случае, SID и имя пользователя
или группы Windows будут сохранены в таблице sysusers. Когда
системный администратор переименовывает группу или
пользователя Windows, это изменение имени не будет отражено в
SQL Server 2000.
Несмотря на то, что это выглядит как
проблема, это способствует уменьшению возможных проблем,
вызванных изменением имён.
В SQL Server 2000, как и в более
ранних версиях, администраторы и разработчики создают
множество хранимых процедур, скриптов Transact-SQL, триггеров
и так далее. Предположим, что пользователь Susie Jones создала
таблицу в базе данных. Имя логина Susie - SUSIEJ и её таблица
называется SUSIEJ.SALESDEMO. Susie предоставляет разрешения
для других пользователей, чтобы они могли обращаться к её
таблице и несколько её коллег создают представления и хранимые
процедуры, основанные на её таблице. Когда Susie вышла замуж
за Bob Taylor, её имя пользователя переименовали в SUSIET.
Если бы SQL Server 2000 перенял эти изменения, таблица Susie
была бы переопределена, как SUSIET.SALESDEMO, став при этом
совершенно другим объектом. Представления, хранимые процедуры
и любой другой код, который был написан, чтобы обращаться к
этой таблице, перестал бы работать.
В целях обеспечения
стабильности, SQL Server 2000 не переименовывает автоматически
учетные записи пользователей, если реальная учетная запись
пользователя в каталоге Windows была переименована.
[В
начало]
4.4. Выведена из
обращения системная таблица sysprocedures
В SQL Server 6.5 и более ранних версиях, когда создавалась
хранимая процедура, текст определяющего её запроса сохранялся
в системной таблице syscomments а нормализованное дерево
запроса сохранялось в системной таблице sysprocedures. Процесс
нормализации анализирует инструкции SQL и преобразует их в
более эффективные формы, а также переводит все вызываемые
объекты в их внутренние представления. После исполнения
процедуры, дерево запрашивалось из таблицы sysprocedures и
использовалось в качестве основы для оптимизации плана
исполнения, который сохранялся в кэше процедур.
Может
показаться, что нет никакой связи между описанным процессом и
безопасностью. Однако, необходимость рассмотрения безопасности
основана на том факте что некоторые разработчики, в попытке
защитить исходные тексты процедур, удаляли его из syscomments.
В большинстве случаев, исходный текст действительно не
использовался повторно, пока сервер не был модернизирован до
более поздней версией SQL Server или пока не был применён
очередной сервисный пакет обновления. В настоящее время
разработчики имеют механизм для скрытия исходного текста
процедур от пользователей, которые не должны иметь к нему
доступа, и обеспечивается это опцией WITH ENCRYPTION,
появившейся в версии SQL Server 6.0. Эта опция шифрует
исходный текст после создания хранимой процедуры.
В SQL
Server 7.0 или 2000, любой администратор, который удалит
соответствующие записи из таблицы syscomments, обнаружит, что
хранимая процедура перестанет выполняться. Это произойдёт
потому, что таблица sysprocedures была удалена из SQL Server
2000, который теперь получает тексты процедур до выполнения и
непосредственно из таблицы syscomments.
[В
начало]
4.5. Опция WITH
GRANT
Опция WITH GRANT является дополнением синтаксиса инструкции
GRANT. Эта опция применяется для предоставления возможности
пользователю, получившему разрешения через инструкцию GRANT,
передавать эти разрешения другим пользователям.
Например,
если Боб предоставил Джейн разрешение на SELECT и использовал
WITH GRANT OPTION, Джейн сможет предоставлять разрешение на
SELECT другим пользователям.
Когда Боб отменит разрешение
на SELECT для Джейн, он может использовать опцию CASCADE,
чтобы отменить разрешения на SELECT и тем пользователям,
которым Джейн предоставила разрешение на SELECT.
[В
начало]
4.6. Системная
таблица sysusers
В некотором смысле, таблица sysusers в базе данных,
выполняет аналогичные функции таблицы sysxlogins для всего
сервера. Таблица sysusers существует в каждой базе данных, и
содержит информацию о том, кому предоставляется или
запрещается доступ к базе данных.
[В
начало]
4.6.1. Столбец
hasdbaccess
Столбец hasdbaccess используется аналогично столбцу
hasaccess в таблице sysxlogins. Если для относящейся к
пользователю записи этот флаг установлен в ноль, значит ему
при создании не были явно предоставлены права для обращения к
базе данных, но он или создал объекты или получил явно
разрешения или был явно добавлен в роль. Объекты, созданные
пользователем, принадлежат ему всегда и не могут принадлежать
группе, через которую пользователю был предоставлен доступ к
базе данных. Исключением является тот случай, когда
пользователь, состоящий в роли или в группе Windows, явно
указывает роль или группу как владельца объекта при его
создании. В этом случае, запись пользователя должна
существовать в таблице sysusers, иначе, объект не сможет иметь
назначенного для него владельца. Запись будет создана
автоматически, но пользователь не получит явного доступа к
базе данных, потому что флаг hasaccess у него установлен в
ноль.
Ролям, которые также присутствуют в таблице sysusers,
значение в столбце hasdbaccess всегда устанавливается в
ноль.
[В
начало]
4.7. Системная
таблица sysmembers
Системная таблица sysmembers является одной из самых
маленьких таблиц. Она содержит два столбца, и используется для
включения пользователей в роли базы данных. Для каждого члена
роли базы данных заводится одна строка.
Для повышения
эффективности обслуживания ролей, SQL Server 2000 помещает
первую роль, в которую включён пользователь, в столбец gid
относящейся к этому пользователю записи таблицы sysusers.
Таким образом, когда SQL Server 2000 идентифицирует все роли,
к которым принадлежит пользователь, он не станет просматривать
таблицу sysmembers, если столбец gid таблицы sysusers содержит
ноль. Если значение в этом столбце не равно нулю (тогда оно
определяет одну из ролей), таблица sysmembers будет
просмотрена, что бы определить полный список всех ролей, к
которым принадлежит пользователь.
[В
начало]
4.8. Системная
таблица syspermissions
Имеющаяся в каждой базе данных системная таблица
syspermissions была введена в SQL Server 7.0. В более ранних
версиях, чтобы обслуживать разрешения использовалась системная
таблица sysprotects. Таблица syspermissions используется,
чтобы зафиксировать разрешения, которые были предоставлены или
отклонены пользователям.
Эта таблица включает всего
несколько столбцов. Столбец id является ссылкой на id объекта,
для которого предоставляются или отклоняются разрешения. Для
операторных разрешений, значение этого столбца устанавливается
в ноль.
Назначение столбцов grantee и grantor очевидно по
названиям. Значениями этих столбцов являются id ролей и
пользователей или групп Windows, которые можно найти в таблице
sysusers.
Столбец actadd указывает на положительное
разрешение (на предоставленные разрешения) для всех столбцов
(в случае таблицы) объекта, в то время как столбец actmod
указывает для такого же объекта на отсутствие (отклонение)
разрешений.
Оставшиеся столбцы используются только для
разрешений уровня столбца. Столбец seladd для разрешений на
SELECT, и является маской столбцов, к которым относится это
разрешение. Поскольку такая схема позволяет никогда не
использовать ID столбец повторно, использование маски
положительно сказывается на эффективности. Столбец selmod
предназначен для отклонения разрешений на SELECT.
Следующие
два столбца по смыслу очень похожи на предыдущие два, за
исключением того, что они оперируют разрешениями на
UPDATE.
Последние два столбца оперируют разрешениям на
REFERENCES, и используются таким же образом, как и предыдущие
четыре столбца.
[В
начало]
4.9. Системная
таблица sysprotects
Назначение системной таблицы sysprotects изменилось, по
сравнению с более ранними версиями. В SQL Server 6.5 и в
ранних версиях, таблица sysprotects хранила разрешения на
объекты. В SQL Server 7.0 и SQL Server 2000 эта информация
теперь хранится в таблице syspermissions.
Для большинства
системных таблиц, назначение которых изменилось по отношению к
старым версиям, были введены специальные представления,
которое обеспечивают обратную совместимость. Например, в базе
master существует таблица sysxlogins, а представление на её
основе с именем syslogins обеспечивает обратную
совместимость.
Однако, в случае системной таблицы
sysprotects, изменения в основывающей её таблице были
настолько велики, что представление не способно полностью
обеспечить обратную совместимость. По этой причине, пришлось
отказаться от создания представления sysprotects, а создана
была специальная таблица sysprotects, являющаяся обычной
системной таблицей, но в реальности создаваемая динамически,
когда это необходимо.
Поэтому таблица sysprotects несколько
напоминает представление, поскольку она фактически не
сохраняется в виде страниц данных. Однако, как и у
представлений, её поведение определяется на уровне движка базы
данных, и поэтому объект sysprotects виден в sysobjects как
таблица.
[В
начало]
4.10. Безопасность
подключения по именованным каналам и по
мультипротоколу
При обсуждении безопасности SQL Server 2000, важно указать
одну из ключевых для неё концепций, которую часто пропускают.
Это не является новшеством для SQL Server 2000, но упоминается
в этой статье для полноты картины.
Сетевая библиотека Named
Pipes использует механизм inter process communications (IPC),
который обращается к Windows ресурсу IPC$. Таким образом,
когда клиент подключается к SQL Server используя Named Pipes,
подключение осуществляется к ресурсу IPC$, и происходит
стандартная в этом случае аутентификация Windows. Это было
упомянуто при обсуждении новшеств безопасности. После того,
как операционная система подтвердила подлинность клиента
(таким же образом, как и при подключении к любому другому
ресурсу), устанавливается сеанс по именованному каналу с
ресурсом IPC$. Это произойдёт до того, как будет предпринята
попытка подключения к SQL Server.
Важно, что все
подсоединяющиеся к SQL Server по Named Pipes пользователи
должны иметь права в Windows для обращения к IPC$. Если Вы не
хотите, чтобы имел место этот тип аутентификации, переключите
их на другую сетевую библиотеку, например на сокет TCP/IP или
на мультипротокол, поскольку они не проверяются Windows NT как
подключение к ресурсу IPC$. Также, обратите внимание, что
сокет TCP/IP является в SQL Server 2000 заданной по умолчанию
сетевой библиотекой.
При использовании сетевой библиотеки
Multiprotocol NET-Library, аутентификация в Windows также
выполняется до того, как SQL Server 2000 получит подключение.
Это происходит потому, что сервис remote procedure call (RPC)
также требует подтверждения подлинности клиента, когда он
требует подключения. Аналогично Named Pipes, сетевая
библиотека Multiprotocol требует авторизации учетной записи
Windows.
Обратите внимание, что сетевая библиотека
мультипротокола не может использоваться для подключения к
именованному экземпляру SQL Server 2000, и она не может
использоваться при организации шифрованных соединений.
Имеющаяся в Windows учетная запись guest может использоваться
теми пользователями, которые не имеют в Windows собственной
учётной записи, но хотят подключиться через сетевую библиотеку
мультипротокола или по именованным каналам. Когда такие
пользователи запрашивают сеанс, они могут подключится к
Windows используя учетную запись guest, и затем пытаться
подключится к SQL Server. Поскольку не заблокированная учетная
запись guest делает Windows менее безопасной, это делать не
рекомендуется, и упоминается здесь только как крайний
случай.