Все системы управления реляционными базами данных обеспечивают своего рода механизмы внутренней безопасности, разработанные для минимизации угроз потери данных, повреждения данных или кражи данных. Они варьируются от простой защиты пароля , предлагаемой Microsoft Access к сложной структуре пользователя / роли при поддержке передовых реляционными баз данных , таких как Oracle и Microsoft SQL Server. Некоторые механизмы безопасности являются общими для всех баз данных , которые реализуют Structured Query Language .
Безопасность на уровне пользователя
Серверные базы данных поддерживают концепцию пользователя, аналогичную используемой в компьютерных операционных системах. Если вы знакомы с иерархией пользователей / групп в 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 <permissions> , позволяет нам указать конкретные разрешения для таблиц, которые мы предоставляем. Это могут быть разрешения уровня таблицы (например, 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
Для DBA
С ГРАНТОВЫМ ВАРИАНТОМ
Обратите внимание, что мы включили строку WITH GRANT OPTION, чтобы наши администраторы баз данных могли назначать это разрешение другим пользователям.
Удаление разрешений
SQL включает команду REVOKE для удаления ранее предоставленных разрешений. Вот синтаксис:
ОТМЕНИТЬ [GRANT OPTION FOR] <разрешения>
ON <таблица>
ОТ <пользователь / роль>
Вы заметите, что синтаксис этой команды похож на синтаксис команды GRANT. Единственное отличие состоит в том, что WITH GRANT OPTION указывается в командной строке REVOKE, а не в конце команды. В качестве примера давайте представим, что мы хотим отозвать ранее предоставленное Мэри разрешение на удаление записей из базы данных клиентов. Мы бы использовали следующую команду:
ОТМЕНИТЬ УДАЛЕНИЕ
ПО клиентам
ОТ Мэри
Есть еще один механизм, поддерживаемый Microsoft SQL Server, о котором стоит упомянуть, — команда DENY. Эта команда может использоваться для явного отказа пользователю в доступе, который он мог бы получить в текущем или будущем членстве в роли. Вот синтаксис:
DENY <разрешения>
ON <таблица>
TO <пользователь / роль