Контроль доступа для пользователей и роли в SQL

Безопасность имеет первостепенное значение для администраторов баз данных, стремящихся защитить свои гигабайты важных бизнес-данных от посторонних глаз посторонних лиц и инсайдеров, пытающихся превысить свои полномочия. Все системы управления реляционными базами данных предоставляют своего рода механизмы внутренней безопасности, предназначенные для минимизации этих угроз. Они варьируются от простой защиты паролем, предлагаемой Microsoft Access, до сложной структуры пользователя/роли, поддерживаемой продвинутыми реляционными базами данных, такими как Oracle и Microsoft SQL Server. В этой статье рассматриваются механизмы безопасности, общие для всех баз данных, которые реализуют язык структурированных запросов (или SQL). Вместе мы пройдем через процесс усиления контроля доступа к данным и обеспечения безопасности ваших данных.

пользователей

Все серверные базы данных поддерживают концепцию пользователя, аналогичную используемой в компьютерных операционных системах. Если вы знакомы с иерархией пользователей/групп в Microsoft Windows NT и Windows 2000, вы обнаружите, что группы пользователей/ролей, поддерживаемые SQL Server и Oracle, очень похожи.

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

Способы создания учетных записей пользователей варьируются от платформы к платформе, и вам нужно будет обратиться к документации по конкретной СУБД для точной процедуры. Пользователи Microsoft SQL Server должны исследовать использование хранимой процедуры sp_adduser. Администраторы базы данных Oracle сочтут полезной команду CREATE USER. Вы также можете изучить альтернативные схемы аутентификации. Например, Microsoft SQL Server поддерживает использование встроенной безопасности Windows NT. В соответствии с этой схемой пользователи идентифицируются в базе данных по их учетным записям Windows NT, и им не требуется вводить дополнительный идентификатор пользователя и пароль для доступа к базе данных. Этот подход чрезвычайно популярен среди администраторов баз данных, поскольку он переносит бремя управления учетными записями на персонал сетевого администрирования и обеспечивает простоту единого входа для конечного пользователя.

Роли

Если вы находитесь в среде с небольшим количеством пользователей, вы, вероятно, обнаружите, что создание учетных записей пользователей и назначение им разрешений непосредственно для вас достаточно. Однако, если у вас большое количество пользователей, вы, скорее всего, будете перегружены бременем обслуживания учетных записей и надлежащих разрешений. Чтобы облегчить это бремя, реляционные базы данных поддерживают понятие ролей. Роли базы данных функционируют аналогично группам Windows NT. Учетные записи пользователей назначаются роли (-ям), а затем разрешения назначаются роли в целом, а не отдельным учетным записям пользователей. Например, мы могли бы создать роль DBA, а затем добавить учетные записи пользователей нашего административного персонала к этой роли. Сделав это, мы можем назначить конкретное разрешение всем нынешним (и будущим) администраторам, просто назначив разрешение роли. Еще раз, процедуры для создания ролей варьируются от платформы к платформе. Администраторы MS SQL Server должны исследовать хранимую процедуру sp_addrole, в то время как администраторы баз данных Oracle должны использовать синтаксис CREATE ROLE.

Предоставление разрешений

Теперь, когда мы добавили пользователей в нашу базу данных, пришло время начать усиление безопасности, добавив разрешения. Нашим первым шагом будет предоставление соответствующих прав доступа к базе данных нашим пользователям. Мы сделаем это с помощью оператора SQL GRANT.

Вот синтаксис утверждения:

 GRANT 
 [ON ] 
 TO 
 [С ПОДАРОЧНЫМ ВАРИАНТОМ] 

Теперь давайте посмотрим на это утверждение построчно. Первая строка, GRANT, позволяет нам указать конкретные разрешения для таблиц, которые мы предоставляем. Это могут быть разрешения уровня таблицы (например, SELECT, INSERT, UPDATE и DELETE) или разрешения базы данных (например, CREATE TABLE, ALTER DATABASE и GRANT). В одном операторе GRANT может быть предоставлено более одного разрешения, но разрешения на уровне таблицы и разрешения на уровне базы данных нельзя объединять в одном операторе.

Вторая строка, ON

, используется для указания уязвимой таблицы для разрешений на уровне таблицы. Эта строка опущена, если мы предоставляем разрешения на уровне базы данных.В третьей строке указывается пользователь или роль, которым предоставляются разрешения.

Наконец, четвертая строка, с GRANT OPTION, является необязательной. Если эта строка включена в оператор, затронутому пользователю также разрешается предоставлять такие же разрешения другим пользователям. Обратите внимание, что параметр WITH GRANT OPTION нельзя указать, когда разрешения назначены роли.

Примеры

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

 GRANT SELECT, INSERT, UPDATE 
 ПО клиентам 
 TO DataEntry 

И это все, что нужно сделать! Теперь давайте рассмотрим случай, когда мы назначаем разрешения на уровне базы данных. Мы хотим разрешить членам роли DBA добавлять новые таблицы в нашу базу данных. Кроме того, мы хотим, чтобы они могли предоставлять другим пользователям разрешение делать то же самое. Вот оператор SQL:

 GRANT CREATE TABLE 
 TO DBA 
 с опцией GRANT 

Обратите внимание, что мы включили строку WITH GRANT OPTION, чтобы наши администраторы баз данных могли назначать это разрешение другим пользователям.

Удаление разрешений

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

 ОТМЕНИТЬ [GRANT OPTION FOR] 
 ON 
 ОТ 

Вы заметите, что синтаксис этой команды похож на синтаксис команды GRANT. Единственное отличие состоит в том, что WITH GRANT OPTION указывается в командной строке REVOKE, а не в конце команды. В качестве примера давайте представим, что мы хотим отозвать ранее предоставленное Мэри разрешение на удаление записей из базы данных клиентов. Мы бы использовали следующую команду:

 ОТМЕНИТЬ УДАЛИТЬ 
 ПО клиентам 
 ОТ Мэри 

И это все, что нужно сделать! Есть еще один механизм, поддерживаемый Microsoft SQL Server, о котором стоит упомянуть, – команда DENY. Эта команда может использоваться для явного отказа пользователю в доступе, который он мог бы получить в текущем или будущем членстве в роли. Вот синтаксис:

 DENY 
 ON 
 TO <пользователь/роль 

Примеры

Возвращаясь к нашему предыдущему примеру, давайте представим, что Мэри также была членом роли Менеджеров, у которых также был доступ к таблице «Клиенты». Предыдущего оператора REVOKE было бы недостаточно, чтобы лишить ее доступа к таблице. Это приведет к удалению разрешения, предоставленного ей посредством заявления GRANT, предназначенного для ее учетной записи пользователя, но не повлияет на разрешения, полученные благодаря ее членству в роли Менеджеров. Однако, если мы используем оператор DENY, это заблокирует ее наследование разрешения. Вот команда:

 DENY DELETE 
 ПО клиентам 
 TO Mary 

Команда DENY по сути создает «отрицательное разрешение» в элементах управления доступом к базе данных. Если позже мы решим дать Мэри разрешение на удаление строк из таблицы Customers, мы не сможем просто использовать команду GRANT. Эта команда будет немедленно отменена существующим DENY. Вместо этого мы сначала использовали бы команду REVOKE, чтобы удалить запись с отрицательным разрешением следующим образом:

 ОТМЕНИТЬ УДАЛИТЬ 
 ПО клиентам 
 ОТ Мэри 

Вы заметите, что эта команда точно такая же, как та, которая использовалась для удаления положительного разрешения. Помните, что команды DENY и GRANT работают одинаково - обе они создают разрешения (положительные или отрицательные) в механизме контроля доступа к базе данных. Команда REVOKE удаляет все положительные и отрицательные разрешения для указанного пользователя. Как только эта команда будет выполнена, Мэри сможет удалить строки из таблицы, если она является членом роли, обладающей этим разрешением. В качестве альтернативы можно выполнить команду GRANT, чтобы предоставить разрешение DELETE непосредственно ее учетной записи.

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

Оцените статью
Solutics.ru
Добавить комментарий