На каком уровне могут быть определены права доступа к бд

Обновлено: 25.06.2024

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

Как работают базы данных и СУБД

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

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

Сервера могут отличаться друг от друга по следующим критериям:

  • технология предоставления доступа к данным;
  • каким образом осуществляется хранение информации;
  • каким образом пользователь получает нужные сведения с сервера при отправке соответствующего запроса.

Каждая из задач предусматривает использование определенного программного компонента:

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

Для того, чтобы обеспечить правильное взаимодействие всех перечисленных компонентов, они объединяются в единую cистему управления базами данных (СУБД).

Зачем нужны и какими бывают СУБД

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

Грамотно построенная система должна обеспечивать:

  • возможность сохранения всей необходимых данных на носители и ее извлечения по необходимости;
  • возможность взаимодействия с данными, расположенными в серверной оперативной памяти;
  • запись истории внесения корректировок в базу данных;
  • поддержание запросов пользователей.

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

По технологии поддержки баз данных системы делят на следующие категории:

  • сетевые;
  • реляционные;
  • иерархические;
  • объектно-реляционные;
  • объектно-ориентированные.

К числу последних относятся системы, которые позволяют управлять абстрактными объектами для выполнения каких-либо действий.

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

  • встраиваемые;
  • клиент-серверные;
  • файл-серверные.

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

Также СУБД отличаются друг от друга степенью распределения данных и по этому признаку делятся на локальные и распределенные. Последние предусматривают использование разных компьютеров для размещения клиента и сервера, в то время как локальные размещаются на одном компьютере.

Самые популярные системы управления базами данных

На данный момент рынок предлагает пользователям несколько сотен различных СУБД. Наиболее распространенными среди них являются следующие.

Oracle

Работает с 1970-х годов, отличается мощностью и практичностью, пользуется широким спросом. В ее преимущества входит следующее:

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

При этом Oracle имеет и некоторые недостатки, такие как:

  • высокая стоимость;
  • потребляет большое количество системных ресурсов;
  • сложные конфигурации (внедрение Oracle требует наличия в компании профессионального системного администратора с большим опытом).

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

MySQL

Золотой стандарт систем управления базами данных для организации работы веб-приложений, которые работают на основе Linux. Система отличается надежностью и скоростью обработки запросов, и при этом может использоваться бесплатно, но в этом случае не может реализовать все функции, необходимые для ведения бизнеса.

Среди преимуществ этой системы можно выделить следующие:

  • простой интерфейс;
  • возможность взаимодействия с различными таблицами;
  • минимальное потребление ресурсов;
  • возможность использования в комплексе с другими СУБД.

При этом СУБД имеет и несколько значительных минусов:

  • фрагментарное использование;
  • серьезные пробелы в безопасности;
  • платная техническая поддержка.

В связи с этим MySQL пользуется распространением среди компаний, которым требуется бесплатная система управления базой данных и обеспечения контроля доступа.

Microsoft SQL Server

Фирменная система, выпущенная компанией Microsoft и обеспечивающая одинаково эффективную работу с облачными и локальными серверами, которые по необходимости могут использоваться одновременно. При этом система работает и на Windows, и на Linux.

К ее преимуществам можно отнести следующие:

  • предельно простой интерфейс, в котором разберется большинство системных администраторов;
  • возможность удобной синхронизации с прочими программными продуктами разработчика;
  • высокая степень защиты данных;
  • хорошая масштабируемость.

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

PostgreSQL

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

Среди недостатков можно выделить высокий расход ресурсов, не самую лучшую техническую поддержку от разработчика, а также некоторые проблемы с обеспечением хостинга.

MongoDB

Абсолютно бесплатная система управления базами данных, которая поддерживает работу с несколькими языками программирования. В отличие от указанных ранее систем, не может взаимодействовать с реляционными базами, которые являются одними из наиболее распространенных.

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

Изучить принципы организации многопользовательской работы с базами данных на сервере MS SQL Server 2000.

Оглавление

Задания

  1. Познакомиться с системой разграничения доступа и защиты данных на сервере MS SQL Server 2000.
  2. Изучить понятие роли и типы ролей, поддерживаемые сервером MS SQL Server 2000.
  3. Изучить порядок назначения ролей на сервере MS SQL Server 2000.
  4. Изучить порядок назначения прав пользователям при работе с конкретной базой данных и операторы SQL по назначению и изменению прав пользователей.
  5. Добавить пользователей в свою базу данных и назначить им разные права по работе с объектами базы данных. Проанализировать их работу.
  6. Подготовить отчет о проделанной работе в электронном виде.

1. Система разграничения доступа и защита данных на сервере

Защита данных в SQL Server 2000 реализована на нескольких уровнях:

  • проверка права пользователя устанавливать соединение с сервером;
  • проверка права пользователя осуществлять доступ к конкретной базе данных;
  • проверка права пользователя манипулировать объектами в базе данных;
  • шифрование трафика между клиентом и сервером.

1.1. Право устанавливать соединение

SQL Server 2000 поддерживает две модели проверки права пользователя устанавливать соединения с сервером:

  • Windows only — интегрированная модель, при которой регистрация пользователя производится на основе его текущего доменного идентификатора или идентификатора пользователя компьютера — в случае, если вход был осуществлен не в домен, а на локальный компьютер. Соответственно, при таком доступе могут использоваться только trusted-соединения.
  • SQL Server and Windows — смешанная модель, когда допускается использование входа как на основе идентификатора пользователя Windows, так и на основе логина и пароля, передаваемого непосредственно SQL-серверу.

Выбор конкретной модели производится на этапе установки и затем может быть изменен, например, через SQL Enterprise Manager.

После того как соединение с сервером установлено, каждому пользователю, независимо от принятой модели, ставится в соответствие учетная запись (Login). Не следует путать Login и имя учетной записи, которое вводится вместе с паролем при соединении к серверу. То, что вводится вместе с паролем, — это символьное имя учетной записи (Login name). Более универсальным идентификатором учетной записи является SID (Securty Identifier). SID — это бинарное значение размером до 85 байт. В свою очередь, Login name — это символьное имя, которое ему сопоставлено.

На одном сервере не может быть двух одинаковых имен учетной записи. Однако, если на разных серверах существуют учетные записи с одинаковыми именами, то это не значит, что им будут сопоставлены одинаковые идентификаторы SID. В связи с этим часто возникают проблемы при переносе базы данных с одного сервера на другой. Лишь стандартные учетные записи имеют фиксированные (то есть всегда одинаковые) идентификаторы SID. Для всех остальных учетных записей SID генерируются при создании.

Хорошей практикой при задании прав подключения является использование Windows Authentification и объедениение пользователей в группы. Это позволяет экономить время при перемещении пользователя из группы в группу и тонко настраивать набор привилегий каждого конкретного члена группы. Кроме того, данный принцип позволяет использовать весь набор преимуществ Windows-аутентификации, таких как требование к сложности пароля, его изменение по прошествии определенного периода, время, в которое пользователь может входить в систему, и т. п.

Вопросы для самопроверки

  1. Какая из моделей проверки права пользователя устанавливать соединения с сервером принята в нашем институте?
  2. Какую модель проверки прав пользователей вы применили на своем домашнем MS SQL Server 2000?
  3. Какие проблемы могут возникнуть при переносе базы данных с вашего домашнего компьютера на институтский сервер и почему?

Для сервера существует несколько серверных ролей (табл. 1). Набор серверных ролей фиксирован: нельзя ни добавить новые роли, ни удалить существующие. Каждая из этих ролей имеет свой набор прав для работы с сервером. В роли могут быть включены любые учетные записи. Члены любой роли также могут добавлять в свою роль другие учетные записи.

1.2. Специальные учетные записи

В MS SQL Server существуют две специальные учетные записи. Эти записи создаются при установке: Builtin\Administrators и sa. Первая из них — администраторы домена (или компьютера), на котором установлен SQL Server. Вторая учетная запись использует SQL Server-аутентификацию. Обе эти учетные записи включены после инсталляции сервера в серверную роль sysadmin.

Если члены роли Builtin\Administrators не должны иметь административных прав на сервер базы данных, то рекомендуется исключить ее из sysadmin. Однако стоит отметить, что невозможно сделать настоящую защиту от администратора компьютера, на котором установлен сервер. Пользователя sa рекомендуется удалять из соображений безопасности (предоставив предварительно администраторские права какому-либо другому пользователю). Как минимум, требуется, чтобы его пароль был непустым, иначе безопасность вашего сервера окажется под угрозой.


Как посмотреть свою серверную роль? Для этого надо выбрать свой логин в списке логинов папки Security , щелчком правой кнопки вызвать контекстное меню, выбрать в нем пункт Свойства и перейти на закладку Server roles (рис. 2).


1.3. Права на доступ к базе данных

Факт установления соединения с сервером еще не дает пользователю права осуществлять манипуляции с объектами сервера.

Для каждой базы данных SQL Server хранит независимый набор пользователей и групп, в которые они входят. По умолчанию в каждой базе существует пользователь dbo — владелец базы данных, и группа public, к которой принадлежат все имена пользователей этой базы. Каждое имя пользователя может дополнительно принадлежать еще и к другим группам. Выделяются фиксированные роли базы данных, обладающие стандартным набором прав. Также могут быть созданы дополнительные группы, и им назначены права. Набор фиксированных ролей баз данных приведен в табл. 2.

Каждой роли и/или каждому пользователю БД могут быть назначены права на любой из объектов БД (чтение, запись, изменение, удалении данных, выполнение ссылочной целостности и выполнение процедур). Если имеется несколько пользователей с одинаковыми правами, то их следует объединять в группы и назначать права этой группе.

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

Если ваша учетная запись не сопоставлена никакому пользователю БД, вы, тем не менее, можете получить доступ к объектам БД, если в ней заведен специальный пользователь — guest. Под этим именем доступ к объектам БД получают те, чья учетная запись не сопоставлена конкретному пользователю.

Надо отметить, что учетные записи, входящие в серверную роль sysadmin, всегда сопоставляются с пользователем dbo, даже в том случае, если базу создавал какой-либо другой пользователь сервера. Кроме того, пользователям, применяющим Windows-authentification, могут быть предоставлены права на объекты БД напрямую, без предварительного сопоставления с пользователем БД. Однако делать этого не рекомендуется.

Посмотреть текущее состояние ролей вашей базы данных можно, выбрав в объектах базы данных Roles и щелкнув на любой роли в правом окне. Вы увидите список пользователей, которые принадлежат к данной роли в вашей базе данных (рис. 3).


Одновременно в данном интерфейсе можно добавить к роли нового пользователя. Однако необходимо помнить, что этот пользователь уже должен иметь право на подключение к серверу базы данных, то есть быть легальным пользователем сервера MS SQL Server 2000, на котором установлена ваша база данных, и быть пользователем самой базы данных. Сделать любого пользователя домена пользователем сервера баз данных вы не можете, потому что не обладаете соответствующими правами. А какова должна быть роль пользователя, чтобы он мог разрешить другому пользователю доступ к серверу?

1.4. Права на доступ к объектам базы данных

Следующий уровень безопасности — это разрешения на уровне объектов базы данных. Существует несколько видов разрешений на объекты базы данных.

  • Во-первых, это разрешения на операции Select , Update , Insert и Delete (операции выборки, изменения, вставки и удаления). Эти разрешения применимы только для таблиц и представлений.
  • Для хранимых процедур и определенных пользователями функций существует разрешение на выполнение ( Execute ). Если в отношении некоторой процедуры или функции для пользователя предоставлено такое разрешение, то он может ее выполнять, иначе — нет.
  • Наконец, существует разрешение на декларативную целостность (DRI). Такие разрешения допускаются для таблиц, представлений и пользовательских функций. Если пользователь имеет разрешение на DRI для некоторой таблицы, это означает, что он может создавать в других таблицах связи, ссылающиеся на ту таблицу, для которой пользователь имеет это разрешение.

Кроме того, забегая немного вперед, скажем, что при создании представления можно указать, что это представление привязано к схеме данных. Это позволяет отслеживать попытки изменения объектов, на основе которых строится представление или функция. Например, если представление строится на основе таблицы Students и используется привязка этого представления к схеме, то будет невозможно удалить таблицу Students , пока такая привязка существует. Также будет невозможно изменить ту часть таблицы (столбцы), которая присутствует в описании представления. Для того чтобы осуществить привязку представления или функции к схеме, необходимо, чтобы на все ссылающиеся объекты для пользователя, создающего или изменяющего данное представление или функцию, имелись разрешения типа DRI.

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

Предоставление и запрещение доступа

В MS SQL Server существует три состояния возможности доступа: разрешение ( GRANT ), запрет ( DENY ) и неявное отклонение доступа ( REVOKE ).

Оператор GRANT имеет следующий синтаксис:

  • Список действий определяет набор действий из общедопустимого перечня действий над объектом данного типа.
  • Опция ALL PRIVILEGES указывает, что разрешены все действия из допустимых для объектов данного типа.
  • задает имя конкретного объекта: таблицы, представления, хранимой процедуры, триггера.
  • или PUBLIC определяет, кому предоствляются данные привилегии.
  • Опция WITH GRANT OPTION является необязательной. Она определяет режим, при котором передаются не только права на указанные действия, но и право передавать (делегировать) эти права другим пользователям. Передавать права в этом случае пользователь может только в рамках разрешенных ему действий.

Для отмены ранее назначенных привилегий в стандарте SQL определен оператор REVOKE . Оператор отмены привилегий имеет следующий синтаксис:

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

С разрешением и запретом все интуитивно понятно: происходит либо предоставление некоторых прав пользователю, либо выставление запретов. Что касается неявного отклонения доступа, можно считать, что это удаление ранее предоставленного разрешения или запрета для данного пользователя. Если бы не было возможности неявного отклонения доступа, то для некоторого конкретного пользователя можно было бы либо дать разрешение, либо выставить запрет на некоторый конкретный объект базы данных. С помощью же неявного отклонения доступа можно убрать как явное разрешение, так и явное отклонение доступа, то есть, другими словами, установить неопределенность.

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

Тогда возникает вопрос: в чем разница между явным и неявным запретом? Дело в том, что для одного и того же объекта на одну и ту же операцию пользователь может иметь сразу несколько разрешений (или запретов). То есть непосредственно пользователю, конечно, может быть выдано только одно разрешение. Однако, вспомним, что пользователь может входить в множество различных ролей базы данных. Например, для базы данных института можно рассмотреть роли Преподаватели, Студенты, Сотрудники деканата, Сотрудники профсоюза, Лаборанты, Системные администраторы. Один пользователь может входить сразу в несколько ролей. Для некоторого объекта на одну операцию (например, операцию удаления) могут быть выставлены и запреты, и разрешения. Кроме того, они могут быть выставлены еще дополнительно непосредственно для каждого пользователя.

Таким образом, каждый пользователь базы данных может иметь разрешения, предоставленные непосредственно ему или посредством вхождения в роли. Причем может получиться, что эти разрешения и запреты будут противоречить друг другу. Например, операция удаления будет запрещена для роли Студенты, но разрешена для роли Лаборанты. Если учесть, что некоторый пользователь может входить в обе роли, как будет определяться возможность или невозможность выполнить ту или иную операцию в таких случаях? Наиболее весомым считается запрет, из тех соображений, что главное — не допустить (по ошибке) несанкционированного доступа к данным. Если же кто-либо из пользователей недополучит каких-либо прав, то он обратится к администратору и тот предоставит ему необходимые права. То есть считается, что лучше недодать прав, чем дать их слишком много. В этом и состоит разница между REVOKE и DENY : если пользователю одновременно даны разрешение ( GRANT ) и запрет ( DENY ), то результатом будет запрет, а если же дополнительно к разрешению дано неявное отклонение доступа, то результатом будет разрешение.

Интерпретация двойных разрешений приведена в табл. 3. Здесь видно, что будет происходить при наличии разных разрешений.

Иерархия прав доступа

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

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

Назначение прав пользователям базы данных, также как и большинство функций администрирования, может быть выполнено с использованием графического интерфейса Enterprise Manager. Для этого необходимо установить курсор на конкретного пользователя — или на пользовательскую роль в вашей базе данных, если надо предоставить одинаковые права всем членам данной роли, — и нажать кнопку Permissions .


Перечень доступных операций зависит от типа объекта. Если требуется еще более тонко дифференцировать права доступа, то можно воспользоваться кнопкой Columns и установить права на работу с отдельными атрибутами.

Права доступа — набор правил, разграничивающий доступ различных пользователей/групп пользователей (ролей) к данным и элементам интерфейса любого программного продукта, разработанного на платформе TMAPlatform (далее платформа). Обычно эти правила зависят от должности и вида деятельности разных сотрудников, работающих с программным продуктом.

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

Пример настройки прав доступа

Рассмотрим пример настройки прав доступа пользователя Иванов к модулю Амортизация. Откроем пункт меню Файл->Настройка прав доступа. И увидим форму настройки следующего вида


Рис.1 Форма настройки прав доступа при первом открытии

В этой форме мы видим все программные модули редактора. Для добавления пользователя необходимо сделать следующие шаги: если у вас нет таблицы пользователей в редакторе, то необходимо ее создать: создадим таблицу sysWorkers (название произвольное), в которой должны быть следующие поля: Логин, ФИО, Роль, Пароль. И укажем эти поля в св-вах программы


Рис.2 Указываем таблицу пользователей в св-вах программы

Для настройки прав доступа ролей необходимо создать роли в соответствующем разделе дерева редактора и выбрать роль в настройках прав доступа. Далее при нажатии кнопки Добавить пользователя/роль в настройках прав доступа выбираем пользователя/роль, права которых мы будем настраивать. После добавления пользователя Иванов (для примера):


Рис.3 Форма настройки прав доступа после добавления в нее пользователя

Нам остается только пройтись по метаданным редактора и отметить нужные нам позиции, к которым пользователь будет иметь доступ.

Внимание: Перед настройкой прав доступа, надо проверить процедуру OnCreate модуля Global, которая запускается автоматически при запуске программы, и учесть используемые в ней объекты метаданных, которые надо разрешить пользователю для запуска программы. Например, в нашем случае в процедуре OnCreate модуля Global идет проверка на актуальность загруженных курсов валют, следовательно, надо дать право пользователю на таблицу курсов валют, чтобы он смог зайти в программу. Также для запуска программы пользователю необходимы права на чтение таблицы пользователей (в нашем случае вышеуказанная таблица sysWorkers)

Следует также отметить важный факт — от настройки прав доступа на уровне клиента (формы и справочники) будет зависеть вид главного меню, т. е. видимость соответствующих пунктов будет аналогична правам пользователя на объекты, которые вызываются через главное меню программы.

Настроим таблицы, программные модули и элементы интерфейса на примере модуля Амортизация:


Рис.4 Пример настройки прав на таблицу БД

Автоматически раздаваемые права — в случае наличия в таблице полей подстановки (далее lookup-полей), на которые даются права, система автоматически даст права на чтение первичного ключа подстановочной таблицы (по умолчанию в платформе это поле называется id) и поля описания этой таблицы (по умолчанию — Name). О чем выведутся соответствующие предупреждения. Например: Мы хотим дать пользователю Иванову право на чтение таблицы Справочник валют (dirCurr):


Рис.5 Пример автоматически раздаваемых прав на уровне СУБД

Как видно из рисунка 5, пользователю Иванов даны права на чтение всех полей таблицы dirCurr. Однако при отображении данной таблицы элементами интерфейса платформы, поле IsoCode, являющееся lookup-полем, заменяется значение поля Name из таблицы rctCurr (классификатор валют), что видно в редакторе (тип поля IsoCode — *rctCurr):


Рис.6 Редактор платформы (показана связь, по которой платформа автоматически дает права)

Соответственно для корректной работы интерфейса программного продукта, разработанного на платформе, необходимо, чтобы пользователю было разрешено чтение полей Id и Name таблицы rctCurr, что за нас автоматически сделает платформа и выведет предупреждение вида:

Автоматически разрешены для пользователя 1 (Иванов) поля rctCurr. Id, rctCurr. Name

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

Ограничение прав на уровне записей

Для всех таблиц БД, права доступа к которым мы настраиваем, можно ограничить определенного пользователя/роль набором фильтров, которые доступны нам в окне настройки прав в разделе Фильтровать записи (см. рис.4 и рис.5). Мы можем интерактивно выбрать значения фильтров для lookup-полей, а также задать абсолютно любое условие фильтрации записей на внутреннем языке запросов в разделе SQL фильтр записей. Например, мы хотим давать пользователю право на просмотр документов амортизации только определенного способа начисления:


Рис.7 Пример настройки фильтров для разграничения прав на уровне записей

В случае применения показанного на рисунке фильтра, пользователь Иванов будет видеть только документы амортизации, в которых выбран линейный способ начисления. Аналогично можно разграничить права в документах между пользователями по контрагентам и т. п. Опция исключить — пользователь будет видеть все документы, в которых способ амортизации не равен выбранному. Если нам нужны более сложные условия фильтрации для разграничения прав на уровне записей, следует использовать SQL фильтр, который описывается на внутреннем языке запросов. Например, если нам надо показывать пользователю только записи, которые он сам создал, то в sql фильтре следует написать:

user_id = user(), где user_id — это имя поля, которое заполняется функцией user() при создании записи, а user() — функция встроенного языка, которая возвращает идентификатор пользователя из таблицы пользователей программы, про которую упоминалось выше.


Есть разные способы показать пользователю только те данные, которые ему нужны. Row level security — один из самых универсальных, простых и надежных. Прочитав эту статью, ты поймешь, что это несложно, и научишься организовывать разграничение доступа к записям средствами самой БД без особого ущерба для производительности.

Механизм row level security позволяет реализовать разграничение доступа к данным средствами базы данных прозрачно для работающих с ней приложений. Даже если злоумышленник получил прямой доступ к базе, например под учетной записью владельца схемы с данными, RLS может не дать ему увидеть защищенную информацию. Политики RLS позволяют убирать строки из выборки целиком или скрывать значения столбцов для строк, к которым пользователь не имеет доступа. В этом отличие от обычного управления правами в БД, которые можно выдать только на объект целиком.

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

Плюс в том, что предикаты работают для любых запросов, в том числе сделанных через инструменты администрирования (SQL Developer, Toad, PgAdmin и так далее) и даже при экспорте дампов. Это единый механизм управления доступом для всех приложений на уровне ядра СУБД. Почему он не так часто используется на практике? Вот несколько причин.

  • Людей, которые умеют работать с базами на достаточном уровне, много меньше, чем обычных программистов. Часто проще и дешевле реализовать механизмы контроля доступа в слое приложения.
  • Прозрачность. Если RLS выключен, это может обнаружиться не сразу. Приложения продолжат работать нормально, но будут выдавать данных больше, чем нужно. Само по себе это не страшно, но при плохих процессах и в сочетании с предыдущим пунктом чревато проблемами.
  • Дополнительный расход ресурсов на выполнение запроса. Обычно этот фактор не играет решающей роли. Если RLS действительно нужен, его включают и принимают чуть более медленную работу как данность. Но при неумелом применении можно тратить на RLS в разы больше, чем на полезную работу.

В общем, row level security — это инструмент для централизованного управления доступом к данным. Он реализован во многих современных СУБД — например, Oracle, PostgreSQL и MS SQL Server. В этой статье я покажу, как это работает в первых двух.

Oracle

Начнем с реализации RLS в Oracle и сразу нырнем в практику.

Пример для Oracle

Мы попробуем реализовать простую политику на стандартной схеме HR. Обычный пользователь может видеть только свои данные. Руководитель департамента может видеть все данные по департаменту. Для этого нам понадобится:

  • определить, какому сотруднику соответствует сессия;
  • создать функцию, вычисляющую для него предикат;
  • настроить политику, связывающую функцию с таблицей.

Мы будем считать, что приложение подключается к базе под учетной записью пользователя HR и в этой программе есть инструмент аутентификации, который позволяет понять, какой именно из сотрудников с ней работает. Данные о том, какой сотрудник подключен, мы будем сохранять в контексте — специальном key-value хранилище атрибутов, управляющих приложениями. Можно использовать стандартный CLIENT_IDENTIFIER , но мы создадим свой собственный. Для этого придется создать и пакет, который будет с ним работать.

Для начала создадим от имени привилегированного пользователя контекст и сразу укажем, какой пакет может его менять:

Создаем пакет для работы с контекстом:

Теперь p_sec_context.set_employee будет использоваться приложением, чтобы задать код сотрудника в таблице EMPLOYEES , который работает в этой сессии БД.

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

При использовании CLIENT_IDENTIFIER вместо p_sec_context.set_employee нужно указать dbms_session.set_identifier .

Продолжение доступно только участникам

Читайте также: