Привилегии безопасности

Привилегии безопасности всегда выделяются конкретному пользователю (а не группе, роли или всем) во время его создания (оператором CREATE USER) или изменения характеристик (оператором ALTER USER). Таких привилегий пять:

· security - право управлять безопасностью СУБД и отслеживать действия пользователей. Пользователь с этой привилегией может подключаться к любой базе данных, создавать, удалять и изменять характеристики пользователей, групп и ролей, передавать права на доступ к базам данным другим пользователям, управлять записью регистрационной информации, отслеживать запросы других пользователей и, наконец, запускать INGRES-команды от имени других пользователей. Привилегия security необходима администратору сервера баз данных, а также лицу, персонально отвечающему за информационную безопасность. Передача этой привилегии другим пользователям (например, администраторам баз данных) увеличивает число потенциально слабых мест в защите сервера баз данных.

· createdb - право на создание и удаление баз данных. Этой привилегией, помимо администратора сервера, должны обладать пользователи, которым отводится роль администраторов отдельных баз данных.

· operator - право на выполнение действий, которые традиционно относят к компетенции оператора. Имеются в виду запуск и остановка сервера, сохранение и восстановление информации. Помимо администраторов сервера и баз данных этой привилегией целесообразно наделить также администратора операционной системы.

· maintain_locations - право на управление расположением баз администраторы сервера баз данных и операционной системы.

· trace - право на изменение состояния флагов отладочной трассировки. Данная привилегия полезна администратору сервера баз данных и другим знающим пользователям при анализе сложных, непонятных ситуаций.

Привилегии доступа

Привилегии доступа выделяются пользователям, группам, ролям или всем посредством оператора GRANT и изымаются с помощью оператора REVOKE. Эти привилегии, как правило, присваивает владелец соответствующих объектов (он же - администратор базы данных) или обладатель привилегии security (обычно администратор сервера баз данных).

Прежде чем присваивать привилегии группам и ролям, их (группы и роли) необходимо создать с помощью операторов CREATE GROUP и CREATE ROLE.

Для изменения состава группы служит оператор ALTER GROUP.

Оператор DROP GROUP позволяет удалять группы, правда, только после того, как опустошен список членов группы.

Оператор ALTER ROLE служит для изменения паролей ролей, а DROP ROLE - для удаления ролей.

Напомним, что создавать и удалять именованные носители привилегий, а также изменять их характеристики может лишь пользователь с привилегией security. При совершении подобных действий необходимо иметь подключение к базе данных iidbdb, в которой хранятся сведения о субъектах и их привилегиях. Привилегии доступа можно подразделить в соответствии с видами объектов, к которым они относятся. В СУБД INGRES таких видов пять:

· таблицы и представления

· процедуры

· базы данных

· сервер баз данных

· события

Присваивание привилегий доступа производится с помощью оператора GRANT. В самом общем виде оператор GRANT имеет следующий формат:

GRANT привилегии ON объекты TO кому;

Применительно к таблицам и представлениям можно управлять следующими правами доступа:

· SELECT - право на выборку данных

· INSERT - право на добавление данных

· DELETE - право на удаление данных

· UPDATE - право на обновление данных (можно указать определенные столбцы, разрешенные для обновления)

· REFERENCES - право на использование внешних ключей, ссылающихся на данную таблицу (можно указать столбцы)

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

Права доступа к базе данных как к единому целому может предоставлять ее администратор или пользователь с привилегией security. Эти "права" на самом деле устанавливают ряд ограничений на использование базы данных, то есть по сути являются запретительными. Имеется в виду ограничение на число операций ввода/вывода или число строк, возвращаемых одним запросом, ограничение права создания таблиц и процедур и т.п. По умолчанию пользователь не стесняется количественными лимитами и получает право на создание объектов в базе.

Отметим, что при создании базы данных указывается ее статус - общая или личная. Это влияет на подразумеваемые права доступа к базе. По умолчанию право на подключение к общей базе предоставляется всем. Право на подключение к личной базе нужно передавать явным образом. Право на подключение необходимо для выполнения всех прочих операций с базой и содержащимися в ней объектами. Привилегии (которые в данном случае точнее было бы назвать ограничениями) QUERY_IO_LIMIT и QUERY_ROW_LIMIT проверяются на основании оценок, выданных оптимизатором запросов. Если оптимизатор предсказывает, что запрос превысит отведенный лимит числа операций ввода вывода или возвращаемых строк, он (запрос) отвергается. Наложение подобных количественных ограничений препятствует монополизации сервера одним клиентом и может использоваться как один из инструментов поддержания высокой готовности.

Обратим внимание на следующее любопытное обстоятельство. По умолчанию все пользователи имеют право создавать процедуры в базах данных. Если бы они при этом автоматически получали права на выполнение, то смогли бы осуществить по существу любую операцию с данными, поскольку выполнение процедуры не требует прав доступа к обрабатываемым объектам. К счастью, для передачи привилегии доступа к объектам, и в, частности, для предоставления права на выполнение процедуры, надо быть не только владельцем объекта, но и администратором базы данных. Мы видим, насколько осторожно нужно относиться к предоставлению привилегий выполнения по отношению к новым, непроверенным процедурам. В принципе достаточно одного "троянского коня", чтобы скомпрометировать всю базу данных. Процедуры являются столь же гибким, но и столь же опасным средством, что и UNIX-программы с битом переустановки действующего идентификатора пользователя.

Отметим, что запретительные привилегии в принципе можно наложить на администратора базы данных или администратора сервера, однако они не будут иметь силы. Тем самым злоумышленник лишен возможности ограничить права доступа администраторов. В частности, он не может создать личную "секретную" базу данных, к которой не будет иметь доступ пользователь ingres. Правда, у подобного положения есть и оборотная сторона - компрометация пароля администратор сервера предоставляет злоумышленнику неограниченные права доступа ко всем базам данных.

Права доступа к серверу распространяются на все базы данных, обслуживаемые данным серверам. Набор этих прав тот же, что и для отдельных баз данных. Привилегии, явно определенные для отдельных баз, имеют приоритет над привилегиями сервера.

Механизм событий подробно рассмотрен в [1]. Здесь мы отметим лишь, что по отношению к событиям имеются две привилегии - RAISE и REGISTER. Первая позволяет возбуждать события, вторая - регистрироваться для их получения.

Оператор GRANT может содержать необязательную часть, принципиально важную для защиты СУБД.

Имеется в виду конструкция

GRANT...... WITH GRANT OPTION;

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

Для отмены привилегий, выданных ранее (как разрешительных, так и запретительных), служит оператор REVOKE.

Date: 2016-08-30; view: 447; Нарушение авторских прав