Все реляционные системы управления базами данных обеспечивать своего рода внутренние механизмы безопасности, предназначенные для минимизации угроз потери данных, повреждения данных или кражи данных. Они варьируются от простой защиты паролем, предлагаемой Microsoft Access к сложной структуре пользователей / ролей, поддерживаемой расширенными реляционными базами данных, такими как Oracle а такжеMicrosoft SQL Сервер. Некоторые механизмы безопасности являются общими для всех баз данных, реализующихСтруктурированный язык запросов.
Безопасность на уровне пользователя
Серверные базы данных поддерживают Пользователь концепция аналогична той, что используется в компьютерных операционных системах. Если вы знакомы с иерархией пользователей / групп, найденной в Майкрософт Виндоус NT и Windows 2000, вы обнаружите, что группы пользователей / ролей, поддерживаемые SQL Server и Oracle, похожи.
Создайте индивидуальные учетные записи пользователей базы данных для каждого человека, имеющего доступ к вашей базе данных.
Избегайте создания общих учетных записей, доступных нескольким разным людям. Во-первых, такая практика исключает индивидуальную ответственность - если пользователь вносит изменения в вашу базу данных (скажем, подняв себе зарплату в размере 5000 долларов), вы не сможете отследить это до конкретного человека с помощью аудита. журналы. Во-вторых, если конкретный пользователь покидает вашу организацию, и вы хотите удалить его или ее доступ к базе данных, вы должны изменить пароль, на который полагаются все пользователи.
Способы создания учетных записей пользователей различаются от платформы к платформе, и вам придется обращаться к документации вашей СУБД, чтобы узнать точную процедуру. Пользователи Microsoft SQL Server должны изучить возможность использования sp_adduser хранимая процедура. Администраторы баз данных Oracle найдут СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ команда полезная. Вы также можете изучить альтернативные схемы аутентификации. Например, Microsoft SQL Server поддерживает использование встроенной безопасности Windows NT. Согласно этой схеме, пользователи идентифицируются в базе данных по их учетным записям пользователей Windows NT, и им не требуется вводить дополнительный идентификатор пользователя и пароль для доступа к базе данных. Этот подход популярен среди администраторов баз данных, потому что он перекладывает бремя учетной записи. управление персоналом сетевого администрирования, и это обеспечивает простоту единого входа в конечный пользователь.
Безопасность на уровне ролей
Если вы находитесь в среде с небольшим количеством пользователей, вы, вероятно, обнаружите, что для ваших нужд достаточно создания учетных записей пользователей и назначения им разрешений. Однако, если у вас много пользователей, вам будет сложно поддерживать учетные записи и соответствующие разрешения. Чтобы облегчить это бремя, реляционные базы данных поддерживают роли. Роли базы данных работают аналогично группам Windows NT. Учетные записи пользователей назначаются ролям, а разрешения затем назначаются роли в целом, а не отдельным учетным записям пользователей. Например, вы можете создать роль администратора базы данных, а затем добавить к этой роли учетные записи пользователей вашего административного персонала. После этого вы можете назначить конкретное разрешение для всех нынешних (и будущих) администраторов, просто назначив разрешение для роли. Опять же, процедуры создания ролей различаются от платформы к платформе. Администраторы MS SQL Server должны изучить sp_addrole хранимая процедура, в то время как администраторы баз данных Oracle должны использовать СОЗДАТЬ РОЛЬ синтаксис.
Предоставление разрешений
Теперь, когда мы добавили пользователей в нашу базу данных, пора приступить к усилению безопасности путем добавления разрешений. Нашим первым шагом будет предоставление нашим пользователям соответствующих прав доступа к базе данных. Мы добьемся этого с помощью оператора SQL GRANT.
Вот синтаксис оператора:
ГРАНТ.
[НА.
К.
[С ОПЦИЕЙ ПРЕДОСТАВЛЕНИЯ]
Теперь давайте посмотрим на этот оператор построчно. Первая строка, ГРАНТ , позволяет нам указать конкретные разрешения для таблиц, которые мы предоставляем. Это могут быть разрешения на уровне таблицы (такие как SELECT, INSERT, UPDATE и DELETE) или разрешения базы данных (например, CREATE TABLE, ALTER DATABASE и GRANT). В одном операторе GRANT можно предоставить более одного разрешения, но разрешения на уровне таблицы и разрешения на уровне базы данных нельзя объединять в одном операторе.
Вторая строка, НА
Наконец, четвертая строка, С ОПЦИЕЙ ГРАНТА, не является обязательным. Если эта строка включена в оператор, затронутый пользователь также может предоставить такие же разрешения другим пользователям. Обратите внимание, что параметр WITH GRANT OPTION нельзя указать, когда разрешения назначены роли.
Пример грантов для базы данных
Давайте посмотрим на несколько примеров. В нашем первом сценарии мы недавно наняли группу из 42 операторов ввода данных, которые будут добавлять и поддерживать записи о клиентах. Они должны получить доступ к информации в таблице «Клиенты», изменить эту информацию и добавить новые записи в таблицу. У них не должно быть возможности полностью удалить запись из базы данных.
Сначала мы должны создать учетные записи пользователей для каждого оператора, а затем добавить их всех в новую роль, Ввод данных. Затем мы должны использовать следующий оператор SQL, чтобы предоставить им соответствующие разрешения:
ПРЕДОСТАВИТЬ ВЫБОР, ВСТАВИТЬ, ОБНОВИТЬ.
ПО Клиенты.
К DataEntry.
Теперь давайте рассмотрим случай, когда мы назначаем разрешения на уровне базы данных. Мы хотим разрешить членам роли DBA добавлять новые таблицы в нашу базу данных. Кроме того, мы хотим, чтобы они могли предоставлять другим пользователям право делать то же самое. Вот инструкция SQL:
ГРАНТ СОЗДАТЬ ТАБЛИЦУ.
DBA.
С ОПЦИЕЙ ГРАНТА.
Обратите внимание, что мы включили строку WITH GRANT OPTION, чтобы наши администраторы баз данных могли назначать это разрешение другим пользователям.
Удаление разрешений
SQL включает команду REVOKE для удаления ранее предоставленных разрешений. Вот синтаксис:
ОТЗЫВАТЬ [ОПЦИЯ ПРЕДОСТАВЛЕНИЯ]
НА.
ИЗ.
Вы заметите, что синтаксис этой команды похож на синтаксис команды GRANT. Единственное отличие состоит в том, что WITH GRANT OPTION указывается в командной строке REVOKE, а не в конце команды. В качестве примера представим, что мы хотим отозвать ранее предоставленное Мэри разрешение на удаление записей из базы данных клиентов. Мы бы использовали следующую команду:
ОТМЕНА УДАЛИТЬ.
ПО Клиенты.
ОТ Мэри.
Есть еще один дополнительный механизм, поддерживаемый Microsoft SQL Server, о котором стоит упомянуть - команда DENY. Эту команду можно использовать для явного отказа пользователю в разрешении, которое в противном случае он мог бы получить через текущее или будущее членство в роли. Вот синтаксис:
ОТКАЗЫВАТЬСЯ ОТ.
НА.
К.