Лекции по АБД. Лекция 8. Общая концепция безопасности
 Скачать 417.02 Kb.
|
|
Общая концепция безопасности Безопасность является одной из основных функций всех АИС. Поэтому многие из понятий, относящихся к безопасности, схожи в различных системах. На рис. 1 представлена базовая концепция безопасности. Она включает: защища- емые объекты (Securables); субъектов или участников (Principals) и разрешения (Permissions). Рис. 1. Общая концепция безопасности Защищаемые объекты в SQL Server. К защищаемым объектами относятся ресурсы, доступ к которым регули- руется системой авторизации компонента Database Engine. Некоторые защища- емые объекты могут храниться внутри других защищаемых объектов, создавая иерархии «областей», которые сами могут защищаться. К областям защищаемых объектов относятся сервер, база данных и схема. Иерархическая структура защи- щаемых объектов представлена на рис. 2. В SQL Server защищаемые объекты на верхнем уровне экземпляра называ- ются объектами уровня сервера. К ним относятся: имя входа (Logins), роль сер- вера (Server roles), база данных (database), конечная точка (Endpoints), группа доступности (Credentials) Защищаемые объекты уровня базы данных: схема, роль приложения, сборка, асимметричный ключ, сертификат, контракт, полнотекстовый каталог, привязка удаленной службы, тип сообщений; роль (база данных), маршрут, по- иск в списке свойств, служба, полнотекстовый список стоп-слов, симметричный ключ, пользователь. Защищаемые объекты уровня схемы: тип, коллекция схем XML, объект: таблица, представление, процедура, функция, статистика, синоним, очередь. Рис. 2 Защищаемые объекты на экземпляре SQL Server По определению и клиент, и сервер базы данных являются защищаемыми субъектами безопасности. Данные сущности могут пройти взаимную проверку подлинности перед установкой безопасного сетевого соединения. Некоторые за- щищаемые объекты являются также участниками. Например, имя входа является участником, который обеспечивает доступ к экземпляру SQL Server, но это также и защищаемый объект, потому что на нем могут быть выполнены действия (например, отключение или удаление), которые требуют разрешения. Участники в SQL Server Применительно к компоненту Database Engine Участники (или Субъекты) – это сущности, которые могут запрашивать ресурсы SQL Server. Наиболее часто в роли участников выступают имена входа и пользователи базы данных. Как и другие компоненты модели авторизации SQL Server, участников можно иерар- хически упорядочить. В табл. 1 перечислены участники безопасности, а иерар- хия субъектов представлена на рис. 3. Таблица 1 Структура участников SQL Server по области определения Иерархия Участники Уровня Windows Имя входа домена Windows Локальное имя входа Windows Уровня сервера Имя входа SQL Server Роль сервера Уровня базы данных Пользователь базы данных Роль базы данных Роль приложения Рис. 3 Субъекты безопасности на экземпляре SQL Server Область влияния субъекта зависит не только от области определения (Windows, сервер, база данных), но и от того, неделимый это субъект или коллек- тивный. Имя входа Windows является примером индивидуального (неделимого) субъекта, а группа Windows - коллективного. Каждый субъект имеет идентифи- катор безопасности (SID). Имя входа – это субъект безопасности, с помощью которого система без- опасности может проверить подлинность лица или сущности. Имя входа необхо- димо пользователю для соединения с SQL Server. SQL Server поддерживает два типа имен входа. - Имена входа Windows. Это учетные записи безопасности, управляемые с помощью Windows, например, пользователь или группа Windows. SQL Server не проверяет подлинность этих имен входа, а скорее доверяет Windows проверку их личности. По этой причине подключения к SQL Server с помощью имени входа Windows часто называют доверенные соединения. - Имена входа SQL Server. Это имена входа с учетными данными безопас- ности, которые определены в базе данных master. SQL Server проверяет подлин- ность этих имен входа путем проверки пароля. Существуют только для обратной совместимости с приложениями и пользователями, которым необходимо полу- чать доступ к SQL Server, используя явную учетную запись пользователя и па- роль. При использовании имен входа Windows важно отметить, что имя входа Windows в SQL Server может ссылаться на отдельного пользователя Windows (см. рис. 3), на глобальную группу домена, определенную в Active Directory (см. при- ложение 1 к данной лекции) или на локальную группу (локальная группа домена в Active Directory или локальная группа Windows Server, на котором находится SQL Server). Имя входа Windows, которое ссылается на группу, позволяет всем пользователям в этой группе получить доступ к экземпляру SQL Server. Исполь- зование имен входа групп Windows может значительно упростить администри- рование SQL Server. Пользователи Windows добавляются к глобальным группам в зависимости от их роли в организации, а глобальные группы добавляются в локальные группы на основе конкретных требований доступа к SQL Server. По мере появления новых пользователей, изменения статуса существующих поль- зователей или их ухода, доступ к SQL Server контролируется с помощью член- ства в группе Active Directory без необходимости внесения каких-либо измене- ний в SQL Server. Следует также отметить, что доступ, основанный только на именах входа групп Windows, может сделать более сложным решение вопросов тестирования и устранения неполадок в рамках SQL Server; но в целом можно на это пойти, чтобы получить долгосрочные преимущества. Роли сервера являются участниками безопасности, к которым можно до- бавлять имена входа, чтобы упростить управление разрешениями. SQL Server поддерживает два следующие типа ролей. - Фиксированные роли уровня сервера: системные (предопределенные) роли, которые автоматически получают необходимые разрешения для выполне- ния конкретных задач управления на уровне сервера. - Роли сервера, определяемые пользователем: роли, которые администра- торы могут создать для того, чтобы определить пользовательские группы управ- ления на уровне сервера. Участники уровня базы данных. Наличие доступа к серверу (само по себе) не означает, что имя входа имеет доступ к пользовательским базам данных на сервере. Чтобы логин имел доступ к базам данных, надо сопоставить имя входа (login) и пользователя базы данных (database user) в базе данных. Можно доба- вить пользователей базы данных к роли уровня базы данных (database-level roles) для упрощения управления разрешениями. Пользователь базы данных – участник уровня базы данных, который обычно сопоставляется с именем входа на уровне сервера. Пользователи базы данных часто имеют одинаковые имена с именами входа, с которыми сопостав- лены, но это необязательно. Даже можно сопоставить имена входа с разными именами пользователей в каждой базе данных. Наилучшим способом считается сопоставление имен входа именам пользователей базы данных. Существует одно исключение из этого правила: если база данных была настроена в качестве автономной базы данных. Автономные БД изолированы от других баз данных и от экземпляра SQL Server, на котором они размещены. Пол- ностью автономная база данных содержит все параметры и метаданные, необхо- димые для определения базы данных, а ее конфигурация не зависит от Database Engine. Поэтому пользователи автономной базы данных не сопоставляются с именами входа. Можно пользователей автономной БД сопоставить с учетной за- писью Windows, или настроить на проверку подлинности SQL Server на уровне базы данных. Можно добавить пользователей базы данных к ролям базы данных для упрощения управления разрешениями. SQL Server поддерживает следующие роли. - Фиксированные роли уровня базы данных: системные роли, которые ин- капсулируют разрешения, необходимые для выполнения общих задач. - Роли базы данных, определяемые пользователем: пользовательские роли, которые администраторы могут создать для группы пользователей с аналогич- ными требованиями к доступу. В среде, где все имена входа основаны на группах Windows, пользователи базы данных, основанные на этих учетных записях, ведут себя во многом так же, как роли, так что вы можете предоставлять разрешения для базы данных непо- средственно пользователям групп Windows вместо того, чтобы создавать пользо- вательские роли. Тем не менее, создание пользовательских ролей БД может быть полезно для объединения пользователей с аналогичными требованиями доступа при использовании имен входа Windows и имен входа SQL Server. Роль приложения – участник уровня базы данных, позволяющий приложе- нию выполняться в пределах базы данных со своими, подобными пользователь- ским, правами доступа. Когда роль приложения активна, SQL Server обеспечи- вает соблюдение прав доступа, которые применяются к роли приложения, а не пользователя базы данных. Роли приложений не содержат элементов и по умол- чанию находятся в неактивном состоянии. Роли приложений работают с обоими режимами проверки подлинности. Роли приложений активируются с помощью процедуры sp_setapprole, которая требует указания пароля. Так как роли прило- жений являются участниками на уровне базы данных, они имеют доступ к дру- гим базам данных только с разрешениями, предоставленными учетной записи пользователя guest в этих базах данных. Таким образом, любая база данных, в которой была отключена учетная запись пользователя guest, не будет доступна для ролей приложений в других базах данных. Разрешения в SQL Server Управление доступом к защищаемым объектам осуществляется путем предоставления или отзыва разрешений, либо путем добавления имен входа и пользователей к ролям, имеющим доступ. Архитектуры безопасности часто являются иерархическими, в первую оче- редь для того, чтобы упростить управление разрешениями. В архитектуре иерар- хической безопасности защищаемые объекты могут содержать другие защищае- мые объекты, и участники могут содержать другие сущности (Principal), напри- мер, пользователи могут быть добавлены в группу. Обычно разрешения наследуются как в иерархии защищаемых объектов, так и иерархиями участников. Для тонкой настройки доступа можно явно переопределить унаследован- ные разрешения на разных уровнях иерархии. Такая иерархическая организация упрощает управление разрешениями, а именно: - Меньшее количество индивидуальных разрешений должны быть предо- ставлены, что снижает риск неправильной конфигурации безопасности. Можно задать общие разрешения, которые требуются на самом высоком уровне в иерар- хии и только применять явные переопределения разрешения далее вниз по иерар- хии для обработки исключительных случаев. - После того, как были установлены разрешения, ими можно управлять с помощью членства в группе. Это облегчает управление разрешениями в средах, где приходят новые пользователи, а существующие пользователи уходят или ме- няют роль. При планировании конфигурации безопасности надо учитывать следую- щие рекомендации. - Предоставляйте каждому участнику только те разрешения, которые ему на самом деле нужны. - Используйте наследование прав доступа, чтобы минимизировать количе- ство неявных разрешений, которые должны быть установлены для того, чтобы обеспечить необходимый уровень доступа. - Используйте основные контейнеры, такие как группы или роли, чтобы создать уровень абстракции между участниками и разрешениями на доступ к за- щищаемым объектам. Затем используйте членство этих групп для управления доступом к ресурсам с помощью разрешений, которые вы определили. Кадровые изменения никогда не должны приводить к корректировке разрешений. Оператор GRANT Он предоставляет разрешения на выполнение действий на защищаемом объекте участникам. Субъект, который не получил разрешение, не может выпол- нить действие, связанное с разрешением. Общая структура оператора может быть условно представлена в следую- щем виде: GRANT < permissions > ON < securables > TO < principals >. Полное описание синтаксиса оператора GRANT достаточно сложное, т.к. зависит от многих факторов, а именно: на какие защищаемые объекты, какие раз- решения, кому даются (см. ПЗ). Например, защищаемыми объектами могут быть и OBJECT, и LOGIN, и DATABASE, и ROLE, и SCHEMA, и USER, причем состав участников, которым можно предоставлять разрешения, меняется в зависимости от защищаемого объекта. От защищаемых объектов зависят и допустимые раз- решения. Причем в одном операторе GRANT можно предоставить сразу не- сколько разрешений нескольким участникам на несколько объектов. При этом можно использовать параметр ALL: GRANT ALL ON < securables > TO < principals >. Этот параметр устарел и сохранен только для поддержки обратной совме- стимости. Но надо учитывать, что он не предоставляет все возможные разреше- ния: например, если защищаемым объектом является база данных, аргумент ALL относится только к разрешениям BACKUP DATABASE, BACKUP LOG, CREATE DATABASE, CREATE DEFAULT, CREATE FUNCTION, CREATE PROCEDURE, CREATE RULE, CREATE TABLE и CREATE VIEW. Разрешения могут быть предоставлены явным образом или могут быть унаследованы. Наследование разрешений применяется к основным иерархиям (например, если роль базы данных получает разрешение SELECT на схему, всем пользователям БД, которые являются членами этой роли, неявно предоставля- ется разрешение SELECT на эту схему). Также наследование разрешений приме- няется к защищаемым иерархиям (например, роль базы данных, которой было предоставлено разрешение SELECT на уровне схемы, неявно получает разреше- ние SELECT и на все объекты внутри схемы). Унаследованные разрешения явля- ются накопительными. Например, если роли базы данных было предоставлено разрешение SELECT на схему, и пользователю, который является членом этой роли, явным образом было предоставлено разрешение UPDATE для таблицы в схеме, то пользователь имеет и разрешение SELECT на таблицу (наследуется че- рез членство в роли), и разрешение UPDATE (непосредственно предоставленное пользователю). Если оператор GRANT используется с параметром WITH GRANT OPTION, то получающему разрешение субъекту безопасности будет дана возможность предоставлять указанное разрешение другим участникам (учетным записям без- опасности). Использовать эту опцию можно только применительно к объектным привилегиям и с большой осторожностью, т.к. можно потерять контроль над без- опасностью защищаемого объекта. Пример 1: пользователь БД WilJo получает разрешение SELECT на схему Person с правом предоставлять это разрешение другим пользователям БД: GRANT SELECT ON SCHEMA :: Person TO WilJo WITH GRANT OPTION Пример 2: роли предоставляется разрешение на выполнение процедуры (оператор выполняет database owner): GRANT EXECUTE ON TestProc TO TesterRole WITH GRANT OPTION; К роли добавляем еще одного пользователя User1: EXEC sp_addrolemember TesterRole, User1; Если новый пользователь попытается выполнить следующий оператор, то получит ошибку: GRANT EXECUTE ON TestProc TO User2; Это объясняется тем, что пользователь User1 не имеет разрешения на предоставление разрешений. Но оператор: GRANT EXECUTE ON TestProc TO User2 AS TesterRole; будет выполнен успешно, потому что User1 выполняет эту инструкцию, как член роли TesterRole. Оператор DENY С помощью оператора DENY может быть сделано исключение к совокуп- ным наследуемым разрешениям. Он явно запрещает конкретное разрешение участника на защищаемый объект и отменяет любые другие явные и наследуе- мые разрешения, которые могут быть предоставлены участнику. Формат DENY аналогичен формату GRANT: DENY < permissions > ON < securables > TO < principals >. Фактически это означает «ЗАПРЕТИТЬ (Отказать) субъектам безопасно- сти в выдаче разрешений на защищаемые объекты». Например, пользователь, который является членом роли базы данных, ко- торая в свою очередь имеет разрешение SELECT на схему, автоматически имеет разрешение SELECT на все таблицы и представления в этой схеме. Если схема содержит таблицу, к которой пользователь не должен иметь доступ, то можно запретить (забрать) разрешение SELECT для пользователя. В этом случае, даже если пользователь унаследовал разрешение SELECT через членство в роли базы данных (которая в свою очередь унаследовали разрешение SELECT от родитель- ской схемы), он не сможет запросить таблицу. Обратите внимание, что разрешения DENY наследуются и не могут быть переопределены вниз по иерархии. Например, если забрать (DENY) у пользова- теля разрешение SELECT на схему, предоставление (GRANT) разрешения SELECT на отдельную таблицу в схеме не позволит пользователю обратиться к этой таблице. Важно помнить, что разрешение DENY не может использоваться для предотвращения доступа к защищаемому объекту его владельца или члена сер- верной роли sysadmin. DENY следует использовать осторожно и нечасто. Необ- ходимость запрещать много разрешений, как правило, указывает на возможную проблему в схеме безопасности. Оператор REVOKE Чтобы удалить ранее предоставленные или запрещенные разрешения, можно использовать оператор REVOKE: REVOKE < permissions > ON < securables > FROM < principals > Обратите внимание, что REVOKE удаляет только явные разрешения, его нельзя использовать для переопределения наследуемых разрешений. Если выданное разрешение включало опцию WITH GRANT OPTION, то можно использовать REVOKE GRANT OPTION FOR, чтобы без отзыва самого разрешения отменить возможность предоставлять это разрешение другим. Совместно с параметром GRANT OPTION FOR можно использовать пред- ложение CASCADE для отзыва разрешения у других лиц, которым уже было предоставлено разрешение указанным участником. Распространенная ошибка – попытка удалить GRANT с помощью команды DENY вместо REVOKE. Это может повлечь за собой проблемы, если пользова- тель получает разрешения из нескольких источников, что часто встречается. Продемонстрируем этот принцип на следующем примере: Роль Sales полу- чает разрешения SELECT для доступа к таблице OrderStatus: GRANT SELECT ON OBJECT::OrderStatus TO Sales; Ted является членом роли Sales. Кроме того, ему предоставлено разреше- ние по его собственному имени пользователя посредством инструкции: GRANT SELECT ON OBJECT::OrderStatus TO Ted; Предположим, администратор хочет удалить разрешение GRANT для роли Sales. - Если администратор (правильно) выполняет инструкцию: REVOKE SELECT ON OBJECT::OrderStatus TO Sales; то пользователь Ted не утрачивает разрешение SELECT к таблице OrderStatus по своей собственной инструкции GRANT. - Если администратор (неправильно) выполняет инструкцию: DENY SELECT ON OBJECT::OrderStatus TO Sales; то пользователь Ted, как член роли Sales, утрачивает разрешение SELECT, так как команда DENY для роли Sales переопределяет его собственную инструкцию GRANT. Действующие разрешения. Действующие разрешения для участника на доступ к защищаемому объекту соблюдаются SQL сервером на основе: - явных разрешений, определенных для этого участника для данного объекта; - разрешений, унаследованных участником через роль или членство в группах; - разрешений, унаследованных от предков защищаемого объекта. Действующие разрешения для имен входа SQL Server и отдельных логи- нов Windows можно просмотреть двумя способами. - В среде SSMS просмотрите вкладку Разрешения диалогового окна свойств защищаемого объекта или вкладку Защищаемые объекты диалогового окна свойств участника. Здесь вы можете выбрать сочетание участника и защи- щаемого объекта, которое хотите просмотреть или отметить (галочкой) на вкладке Действующие панели разрешений. - Используя инструкцию EXECUTE AS для переключения контекста вы- полнения сеанса на заданное имя входа (на уровне сервера) или имя пользователя (на уровне базы данных), а затем запрос к системной функции sys.fn_my_permissions, указав защищаемый объект, для которого требуется про- смотреть действующие разрешения. В следующем примере кода показано, как выполнить просмотр действу- ющих разрешений для имени входа AdventureWorks\RosieReeves на таблицу dbo.Products: EXECUTE AS LOGIN = 'AdventureWorks \ RosieReeves' SELECT * FROM sys.fn_my_permissions ( 'dbo.Products' 'Object'.); REVERT Инструкция REVERT переключает (возвращает) контекст выполнения в контекст участника, вызывавшего последнюю инструкцию EXECUTE AS. Имена входа групп Windows и пользователей, основанных на группах Windows, нельзя использовать в инструкции EXECUTE AS (как нельзя использо- вать роль, сертификат, ключ или встроенную учетную запись). Таким образом, ни один из этих методов нельзя использовать для просмотра действующих раз- решений для имени входа на основе группы Windows. Каждый пользователь Windows может войти и запросить системную функцию sys.fn_my_permissions для себя, но так как пользователи Windows могут быть добавлены к более чем одной группе Windows, результаты для каждого пользователя могут различаться в зависимости от того, к каким группам они принадлежит. |