Привилегию какого типа выдает скрипт

Обновлено: 30.06.2024

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

В данной статье описывается реализация доступа на основе ролей (role based access control - RBAC). RBAC - модель системы разграничения прав доступа, в которой роли используются для выполнения различных задач, а разрешения на выполнение операций привязываются к ролям. Пользователь может получать одну или несколько ролей, которые ограничивают его полномочия на действия в системе.

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

Мы обсудим создание необходимых таблиц баз данных. Затем создадим два файла с классами: Role.php - для выполнения определенных задач по управлению ролями, и PrivilegedUser.php - для расширения класса пользователя. Затем приведем несколько примеров, как код может быть интегрирован в ваше приложение. Управление ролями и пользователями весьма похожи, поэтому у вас появится система для идентификации пользователей.

База данных

Нужно 4 таблицы для хранения ролей и информации о разрешениях: таблица roles содержит ID и имя роли, таблица permissions хранит ID и описание разрешения, таблица role_perm содержит соответствие ролей и разрешений, а таблица user_role содержит соответсвие ролей и пользователей.

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

Вот запрос CREATE TABLE для создания структуры в базе данных:

Обратите внимание, что последняя таблица user_role ссылается на таблицу users , которая определяется в другом месте. В нашем случае мы предполагаем, что user_id является основным ключом в таблице users .

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

Класс Role

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

Вот код класса, который содержится в файле Role.php :

Метод getRolePerms() создает новый объект Role на основе заданного ID роли. Затем использует выражение JOIN для комбинации таблиц role_perm и perm_desc . Каждое разрешение, связанное с ролью, хранится в виде описания в качестве ключа и значения true . Метод hasPerm() принимает описание разрешения и возвращает значение из текущего объекта.

Класс PrivilegedUser

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

Код класса в файле PrivilegedUser.php :

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

Метод initRoles() использует выражение JOIN для комбинирования таблиц user_role и roles для сбора информации о ролях для текущего пользователя. Каждая роль наполняется соответствующими разрешениями с помощью метода класса Role Role::getRolePerms() .

Метод hasPrivilege() получает описание разрешения и возвращает результат проверки его наличия у текущего пользователя.

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

Здесь имя пользователя хранится в активной сессии, и для него создается новый объект PrivilegedUser , для которого вызывается метод hasPrivilege() . В зависимости от информации, хранящейся в базе данных, объект может выглядеть следующим образом:

Организационные вопросы

Одним из преимуществ использования ООП для RBAC является возможность простого разделения логики и сервисных функций. Например, можно добавить следующие методы к классу Role для управления ролями (добавление, удаление, и так далее):

Также можно добавить подобные методы для класса PrivilegedUser :

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

Заключение

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

5 последних уроков рубрики "PHP"

Фильтрация данных с помощью zend-filter

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

Контекстное экранирование с помощью zend-escaper

Обеспечение безопасности веб-сайта — это не только защита от SQL инъекций, но и протекция от межсайтового скриптинга (XSS), межсайтовой подделки запросов (CSRF) и от других видов атак. В частности, вам нужно очень осторожно подходить к формированию HTML, CSS и JavaScript кода.

Подключение Zend модулей к Expressive

Expressive 2 поддерживает возможность подключения других ZF компонент по специальной схеме. Не всем нравится данное решение. В этой статье мы расскажем как улучшили процесс подключение нескольких модулей.

Совет: отправка информации в Google Analytics через API

Подборка PHP песочниц

Подборка из нескольких видов PHP песочниц. На некоторых вы в режиме online сможете потестить свой код, но есть так же решения, которые можно внедрить на свой сайт.

Без рубрики

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

Это краткое руководство покажет вам, как получить привилегированную информацию о пользователе, доступном на сервере.

Типы привилегий

Прежде чем мы продолжим запрашивать у PostgreSQL информацию о пользователях, давайте выделим различные разрешения и то, что они позволяют делать назначенному им пользователю.

Типы привилегий в СУБД PostgreSQL:

SELECT -привилегия select позволяет пользователю выбирать значения из любых столбцов любого табличного объекта. Табличные объекты в PostgreSQL включают таблицу, представление, материализованное представление и т.д.
INSERT -разрешение на вставку позволяет пользователю вставлять новые строки в таблицу. Вы также можете предоставить право вставки в определенный столбец, позволяющее вставлять строки только в заданные столбцы.
UPDATE -этот тип привилегии позволяет пользователю установки обновлять строки в любых столбцах таблицы или представления. Подобно разрешению на вставку, вы можете установить его для определенного столбца, чтобы пользователь мог обновлять строки только определенного столбца (столбцов).
DELETE-это позволит пользователю удалить / удалить строку из любого изменяемого табличного объекта. Для этого требуется, чтобы у пользователя было разрешение SELECT, поскольку ему необходимо ссылаться на столбцы таблицы, чтобы проверить строки, которые необходимо удалить.
CONNECT -разрешение на подключение позволяет пользователю подключаться к серверу. Этот тип разрешения проверяется при запуске соединения файлом pg_hba.conf.
CREATE -привилегия create позволяет пользователю создавать либо новую схему, либо таблицу в установленной базе данных. Это также может позволить пользователю устанавливать расширения в базе данных. Если это разрешение отозвано для пользователя, оно не удаляет все существующие объекты до точки завершения.
TRUNCATE -как следует из названия, он предоставляет пользователю разрешение на усечение таблицы.
TRIGGER -позволяет пользователю создавать триггер для табличных объектов.
ВРЕМЕННАЯ -позволяет пользователям создавать временную таблицу при подключении к установленной базе данных.
EXECUTE -разрешение на выполнение позволяет пользователю вызывать функции или процедуры. Это единственный тип разрешения, который может применяться к функциям / процедурам.
ССЫЛКИ -позволяет пользователю создавать ограничения внешнего ключа, которые ссылаются на таблицу или столбцы.

Как показать права пользователя

Перечислить привилегии пользователей просто. В psql используйте запрос \ du +, как показано в выводе ниже:

Приведенный выше вывод показывает пользователей Postgres и temp с соответствующими разрешениями.

Другой способ сделать это — использовать схему information_schema и запросить таблицу table_privileges следующим образом:

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

Заключение

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

На первый взгляд, в MS SQL нестандартная система учетных записей. В ней существуют логины и пользователи.

Логины - это понятие всего сервера SQL. У них могут быть права на какие-то административные задачи (например бэкап). Им можно дать права на какие-то действия с базой или таблицой. Для того что бы у логина были права на базу на основе него создается пользователь. Они могут быть как SQL логином, так и созданные на основе существующих пользователя Windows или AD. Например тот пользователь, который устанавливал MS SQL так же добавился в список логинов. Рекомендуется использовать логины на основе Windows или AD, а не SQL логины.

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

Оба типа учетных записи можно создать как в графике, так и с помощью запроса T-SQL

T-SQL CREATE USER, CREATE LOGIN

Перейдем в базу данных, в которой мы работаем:

Для создания логина SQL выполним:

Anton - имя логина. Password1910 - пароль. У этого логина уже будут права на вход.

Посмотреть что этот логин создался можно так:

Под номером 3 - это кнопка обновления. Может понадобится т.к. в графике изменения происходят не моментально.

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

Отмечу, что пользователь создасться в той базе, откуда мы выполняем запрос.

Что бы просто создать пользователя нужно:

Где JustUser - просто пользователь

Созданных пользователей можно увидеть так:

Пользователи создаются без каких либо прав на базу.

T-SQL GRANT

GRANT в пер. "Разрешение" дает права на какое-то действие.

Что бы дать пользователю право получать данные из какой-то таблицы нужно выполнить:

Если мы хотим зайти под созданным пользователем нам нужно выполнить ряд действий. Дело в том, что по умолчанию аутентификация по логинам SQL отключена (разрешена только Windows). Для этого зайдем в свойства сервера:

Затем в "Безопасность" и включи аутентификация SQL

Теперь мы сможем зайти под логином SQL. Для этого сделаем следующее - откроем новое окно запросов Ctr + N или нажмем кнопку:

Важно сделать так, что бы у нас было 2 окошка для запросов до того как мы сменем пользователя. Благодаря этому у нас каждое окно будет работать под разными пользователями

Затем окно подключения пользователя:

Меняем тип подключени на SQL и вводим логин/пароль. Я создавал логин Anton, с паролем Password1910.

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

Перейдем к базе, на которую мы давали права. В моем случае это база pubs

Я давал права на SELECT для таблицы dbo.authors. Проверем работу:

Запрос дожен пройти успешно.

Для другой таблицы, на которую мы не давали прав:

The SELECT permission was denied on the object 'titles', database 'pubs', schema 'dbo'.

Что бы отозвать разрешение на SELECT нужно заменить GRANT на REVOKE (не забудьте переключится на окно у которого есть разрешение или переключится на предыдущего пользователя):

Разрешений, которые мы можем выдать пользователю достаточно много. Это основные:

Мы можем так же явно запретить пользователю выполнять определенные запросы. Для этого есть DENY:

Что ба дать разрешение на создание таблиц:

Теперь создадим логин через графический интерфейс. Нажмем следующие кнопки:

В новом окне мы должны заполнить логин (1) и пароль (3). Под цифрой 2 мы можем увидеть выбор способа аутентификации. В случае Windows мы должны будем выбрать локального пользователя или пользователя AD. Перейдем на закладку Server Roles (4).

Перед нами находятся роли уровня сервера. Все эти роли это просто набор прав. В Microsoft SQL мы так же можем создать и свои группы. Public - роль по умолчанию для всех, кому разрешено вход. Из всех созданных ролей только public можно изменять.

Приведу описание самых популярных ролей:

Перейдем на следующую вкладку (2)

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

Коротко о нескольких ролях баз данных:

Роль public, в отличии от всех остальных, можно изменять. Т.е. можно дать роли public разрешение на SELECT и тогда все пользователи с логином смогут это делать. По умолчанию эта ролько может делать запросы типа:

БД от Percona обладает дополнительными функциями, направленными на повышение производительности. Многие дистрибутивы (например, Red Hat) перешли на MariaDB из-за предсказуемой лицензионной политики. В своих проектах автор использует MariaDB.

Есть несколько способов работы с БД MySQL: через графические phpMyAdmin, MySQL WorkBench и т.д.

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

Для этого понадобится минимум — консольный клиент mysql. Запускать его можно на своей рабочей станции (mysql —host= [—user= ] [—password=

] [database]) или через ssh на самом сервере (в случае ОС Linux).

Зачем нужны пользователи

После установки MySQL технически мы можем подключаться из нашего ПО от имени root’а, но это не безопасно. Работая с информационными системами, мы всегда должны помнить и соблюдать принцип наименьших привилегий. Для более безопасной работы и создаются пользователи БД. Привилегии должны быть предоставлены пользователю строго только те, что действительно необходимы.

Пользователи MySQL

Имя пользователя MySQL

В MySQL имя пользователя состоит из 2-х частей: имени пользователя (обязательно) и хоста (может быть опущена, тогда она означает ‘%’):

‘someuser’@’somehost’, аналогично, почтовому адресу.

Поняв это правило, посмотрим, как по умолчанию выглядит суперпользователь. На самом деле полностью учетка записывается трижды: ‘root’@’localhost’, ‘root’@’127.0.0.1’ и ‘root’@’::1’ с одинаковым парольным хешем.

В хостовой части могут использоваться DNS-имена, IP-адреса и символ подстановки %, обозначающий любой (любые) символы.

Примеры записи хоста:

Примечание: имена и адреса следует указывать в том формате, в каком возвращает системный DNS resolver сервера.

Просмотр всех пользователей

Давайте проверим, какие пользователи есть в нашей БД. Выведем основную информацию о пользователях:

Когда список получается большим, мы можем добавить фильтр (в примере — по хостам, начинающимся с msk):

Или использовать в конце модификатор \G, оптимизирующий вывод для отображения в консоли:

Создание нового пользователя MySQL

Новый пользователь в MySQL добавляется командой:

Теперь давайте создадим нашего первого пользователя:

Полезная возможность — добавление комментария:

FLUSH PRIVILEGES

Удаление пользователя MySQL

Для удаления пользователя используется команда

На нашем предыдущем примере:

Создание дополнительного суперпользователя

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

Теперь пользователь root безопасно хранится у нас, а для административной работы с БД мы можем передать коллегам или партнерам учетную запись admin.

Отзыв полномочий у пользователя

Команда отзыва привилегий функционально обратна GRANT, “TO” заменяется на “FROM”:

Смена пароля

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

Предоставление доступа пользователю MySQL

Доступ предоставляется командой:

Допустим, наше ПО использует базу данных test_db. Для его работы мы создали пользователя test_user, а FQDN хоста, где работает ПО — наш локальный хост (localhost). Наше приложение только считывает данные из БД — выполняет SELECT.

Создадим пользователя и БД (часто БД называют схемой, в терминах MySQL):

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

Наследование привилегий

В предыдущем примере наш пользователь сможет только читать данные из базы test_db, но передать свои права другому пользователю не сможет. Используя GRANT OPTION, мы можем позволить ему сделать это. Тогда пользователь получит возможность передавать другим то, что разрешено ему самому.

В этом примере some_user может поделиться правами на SELECT, INSERT, UPDATE, DELETE для базы some_db.

Из соображений безопасности использовать GRANT OPTION небезопасно! В случае компрометации учетной записи злоумышленник сможет не только получить доступ к данным, но и сделать закладку в виде копии учетной записи.

Доступ к таблице

Примеры выше дают доступ ко всей БД. Часто доступ должен быть ограничен строго определенным набором таблиц:

Выполнение команды приведет к ошибке, т.к. этой таблицы еще нет.

и повторим предоставление доступа:

Доступ к столбцу

Предоставляется перечислением столбцов:

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

Просмотр привилегий пользователей MySQL

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

Проверка текущих полномочий пользователя

Нам пригодится команда:

Проверка полномочий к данным

Через read-only БД information_schema доступно множество метаданных — системной информации. Информация о доступе на БД (схемы), таблицы и столбцы доступны в таблицах schema_privileges, table_privileges и column_privileges. Работа с ними — обычные SQL-запросы:

Просмотр привилегий через системную БД mysql

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

Информация о пользователях:

Привилегии на базы данных:

Права, назначенные на таблицы:

Просмотр глобальных привилегий

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

Заключение

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

При выдаче прав избегайте избыточности. Права не нужно выдавать с запасом, часто выполнение GRANT ALL PRIVILEGES ON *.* TO ‘myUser’@’%’ — не лучший выход. Другой важный момент, часто упускаемый из виду новичками, — наличие в имени хостовой части. Игнорирование хоста может привести к ошибкам.

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