Как можно предоставить доступ пользователям к изменению набора таблиц
Обновлено: 02.07.2024
Изучить принципы организации многопользовательской работы с базами данных на сервере MS SQL Server 2000.
Оглавление
Задания
- Познакомиться с системой разграничения доступа и защиты данных на сервере MS SQL Server 2000.
- Изучить понятие роли и типы ролей, поддерживаемые сервером MS SQL Server 2000.
- Изучить порядок назначения ролей на сервере MS SQL Server 2000.
- Изучить порядок назначения прав пользователям при работе с конкретной базой данных и операторы SQL по назначению и изменению прав пользователей.
- Добавить пользователей в свою базу данных и назначить им разные права по работе с объектами базы данных. Проанализировать их работу.
- Подготовить отчет о проделанной работе в электронном виде.
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-аутентификации, таких как требование к сложности пароля, его изменение по прошествии определенного периода, время, в которое пользователь может входить в систему, и т. п.
Вопросы для самопроверки
- Какая из моделей проверки права пользователя устанавливать соединения с сервером принята в нашем институте?
- Какую модель проверки прав пользователей вы применили на своем домашнем MS SQL Server 2000?
- Какие проблемы могут возникнуть при переносе базы данных с вашего домашнего компьютера на институтский сервер и почему?
Для сервера существует несколько серверных ролей (табл. 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 и установить права на работу с отдельными атрибутами.
В этой статье мы пройдём с вами полный цикл от идеи, проектирования БД, написания PHP-Кода, и завершающей оптимизации. Постараюсь рассказать обо всем, как можно проще. Использовать для примеров буду PHP и Mysql. Заодно потренирую новичков :).
В этой статье я коснусь вопросов:
1. Идея ACL
2. Проектирование БД
3. Нормализация БД
4. Рефакторинг кода
5. Оптимизация рабочего кода
Статья является ответом на Бинарное распределение прав доступа в CMS. Пока автором пишется практическая часть, я хочу предоставить мой вариант, который я использую довольно давно.
То, что я сейчас расскажу, похоже на ACL.
Упрощенное описание идеи
Система прав доступа состоит из:
+ или -
Action — набор действий, которые пользователи с имеющимся могут делать. В нашей системе новостей можно использовать:
N — добавлять новую тему
D — удалять тему
E — редактировать тему
V — видеть тему
C — оставлять комментарий
B — удалять комментарий
± означает давать пользователю с такими правами или не давать (приоритетно) доступ к действию. Например: Users+VC, Users-C = Users+V.
Теперь рассмотрим пример прав доступа, для простого сайта новостей:
Объект MainNewsPage:
Users+VC, Moderator+NEDB, Admin+NEDB
Объект NewsMessage:
User1+ED (в принципе не нужно, если добавлять могут только модераторы)
Users-C (можно использовать, если нет желания оставлять комментарии)
Объект NewsComment:
User2+B (а здесь необходимо, так как комментарий может оставлять любой пользователь, но не все могут удалять их)
Упростим систему, для понимания идеи компьютером
Для начала, определим Базы данных, для работы с правами объектов.
Так как у нас получается список нескольких прав, то можно начать с такой БД:
RightsID — идентификатор списка прав.
Group — название группы.
Sign — знак группы.
Action — название действия.
Пример1 (права для MainNewsPage):
| ID | RightsID | Group | Sign | Action |
|---|---|---|---|---|
| 1 | 100 | Users | + | V |
| 2 | 100 | Users | + | C |
| 3 | 100 | Moderator | + | N |
| 4 | 100 | Moderator | + | E |
| 5 | 100 | Moderator | + | D |
| 6 | 100 | Moderator | + | B |
| 7 | 100 | Admin | + | N |
| 8 | 100 | Admin | + | E |
| 9 | 100 | Admin | + | D |
| 10 | 100 | Admin | + | B |
Пример2 (права для NewsMessage):
| ID | RightsID | Group | Sign | Action |
|---|---|---|---|---|
| 11 | 101 | User1 | + | D |
| 12 | 101 | User1 | + | E |
| 13 | 101 | Users | - | C |
Теперь, если мы запросим SELECT * FROM `rights_action` WHERE `RightsID`=100 , то получим все права, которые принадлежат необходимому нам объекту.
Нормализация таблиц. Добавляем права пользователя.
У пользователя, который будет просматривать нашу страницу, должны иметься права, которыми он владеет. Исходя из них, мы сможем знать, имеет ли пользователь право на действие.
Например: User2, Users, Moderator.
Для этого определим таблицу прав:
RightsID — идентификатор списка прав пользователя.
Group — название группы, в которой пользователь состоит.
Пример:
| ID | RightsID | Group |
|---|---|---|
| 1 | 10 | User1 |
| 2 | 10 | Users |
| 3 | 10 | Moderator |
В результате ID ключи отсеются, и мы получим 3 таблицы:
rights_action — права объекта
RightsID: integer (pk) — идентификатор списка прав.
GroupID: integer (pk) — название группы.
Sign: tinyint (1) — знак группы.
Action: enum (pk) — название действия.
rights_group — права пользователя
RightsID: integer (pk) — идентификатор списка прав пользователя.
GroupID: integer (pk) — идентификатор группы, в которой пользователь состоит.
rights_names — названия групп
GroupID: integer (pk) — идентификатор группы.
name — название группы.
Пример, что у нас получилось:
| rights_name | |||
|---|---|---|---|
| GroupID | name | ||
| 10 | Users | ||
| 11 | Moderator | ||
| 12 | Admin | ||
| 1001 | User1 | ||
| 1002 | User2 | ||
| 1003 | User3 | ||
| rights_group | |||
| RightsID | GroupID | ||
| 1 | 1001 | ||
| 1 | 10 | ||
| 1 | 11 | ||
| rights_action | |||
| RightsID | GroupID | Sign | Action |
| 100 | 10 | 0 | message_view |
| 100 | 10 | 0 | comment_create |
| 100 | 11 | 0 | message_create |
| 100 | 11 | 0 | message_edit |
| 100 | 11 | 0 | message_delete |
| 100 | 11 | 0 | comment_delete |
| 100 | 12 | 0 | message_create |
| 100 | 12 | 0 | message_edit |
| 100 | 12 | 0 | message_delete |
| 100 | 12 | 0 | comment_delete |
| 101 | 1001 | 0 | message_edit |
| 101 | 1001 | 0 | message_delete |
| 101 | 10 | 1 | comment_create |
Теперь мы можем добавить права любому объекту в таблице на любое действие. Действия теперь записываются в таблицу в виде ENUM (поле 'action'), что упрощает понимание и разработку проектов. Само действие как string и может называться, как угодно.
`rights_group` должна быть привязана к пользователям и говорит о тех правах, которыми пользователь обладает.
`rights_action` должна быть привязана к объектам и говорит, с каким правами, какие действия пользователь может выполнять.
Разработка библиотеки работы с правами доступа
А сейчас мы посмотрим, что необходимо, чтобы эти таблицы собрать воедино и произвести необходимую нам выборку результатов.
Алгоритм наших действий при проверке возможности действия:
1) Берем из БД выборку прав по необходимому объекту (объектам). (100: Users+VC, Moderator+NEDB, Admin+NEDB)
2) Выбираем необходимые нам действия (action). (V: Users+V)
3) Сравниваем права доступа пользователя и нашей выборки. (Users, User1 Users+)
4) Если результатов нет, тогда возвращаем false.
5) Если результаты есть, но состоят из минусов, возвращаем false. Иначе возвращаем true.
Пункт 2.
С выбором необходимого нам действия, тоже всё просто:
SELECT * FROM `rights_action` WHERE `action`= 'message_view'
Пункт 3.
А вот здесь придется объединить несколько SELECTов. Сначала выбираем права доступа пользователя, а затем сравниваем их с необходимыми нам. Если объединить эти действия в одно, получится:
SELECT * FROM `rights_action` WHERE `GroupID` IN ( SELECT `GroupID` FROM `rights_group` WHERE `RightsID` = 1)
Пункт 1-3.
Теперь всё вместе одним сложным запросом:
SELECT * FROM `rights_action` WHERE `RightsID` IN (100, 101) AND `action`= 'message_view' AND `GroupID` IN ( SELECT `GroupID` FROM `rights_group` WHERE `RightsID` = 1)
Пункт 1-5.
Вставим это в PHP реализацию и заодно добавим проверку:
function check( /*array(int,int. )*/ $obj_rights, /*integer*/ $user_rightsID, /*string*/ $action) $result = mysql_query( "SELECT * FROM `rights_action` WHERE `RightsID` IN (" . implode( "," ,$obj_rights) . ") AND `action`= '$action' AND `GroupID` IN (SELECT `GroupID` FROM `rights_group` WHERE `RightsID` = $user_rightsID)" );
if (!$result)
return false ;
$tmp=array();
while ($t = mysql_fetch_assoc($result)) //В каждую из найденных групп (Users, User1, Moderator) пользователей
//заполняем + (0) или - (1) (с приоритетом).
if (!isset($tmp[$t[ 'groupID' ]]))
$tmp[$t[ 'groupID' ]] = $t[ 'sign' ];
else
$tmp[$t[ 'groupID' ]] |= $t[ 'sign' ];
>
mysql_free_result($result);
if ($tmp)
//Если нашли + в любой из групп, возвращаем true. Иначе false.
return (array_search(0, $tmp) !== FALSE);
//Не нашли ни одного результата $tmp == false
return false ;
>
* This source code was highlighted with Source Code Highlighter .
Это лишь начало, первый шаг.
Создаём класс работы с правами доступа
Что нам необходимо?
Разработаем пример работы с нашим классом.
1) Во-первых, необходимо указать права пользователя, с правами которого нам надо работать. А сам класс необходимо привязать к конкретному пользователю.
2) Добавление в класс child-прав объектов с дополнением свойств.
3) Проверка доступа по различным действиям (action).
Замечания и мысли:
Права пользователя можно указать при создании класса в __construct.
При добавлении новых свойств, чтобы не терялись свойства в классе, необходимо будет делать новый класс (клонировать старый с добавлением свойств).
Давайте попробуем это всё реализовать:
class Rights private $usrID; //User rights ID
function __construct($user_rightsID) $ this ->usrID=$user_rightsID;
>
>
и использовать $UserRights в дальнейшей программе.
Рассмотрим добавление права объекта для проверки:
class Rights private $group=array(); //Сначала нет никаких объектов сравнения
function include_right($grp) $clone=clone $ this ; //Чтобы не запортить объект, клонируем его
$clone->group[]=$grp; //Добавляем права клону
return $clone;
>
Теперь перепишем нашу функцию check, введя её в класс, и посмотрим что получилось:
class Rights private $usrID; //User rights ID
private $group=array(); //Сначала нет никаких объектов сравнения
function __construct($user_rightsID) $ this ->usrID=$user_rightsID;
>
function include_right($grp) $clone=clone $ this ; //Чтобы не запортить объект, клонируем его
$clone->group[]=$grp; //Добавляем права клону
return $clone;
>
if (!$result)
return false ;
$tmp=array();
while ($t = mysql_fetch_assoc($result)) //В каждую из найденных групп (Users, User1, Moderator) пользователей
//заполняем + (0) или - (1) (с приоритетом).
if (!isset($tmp[$t[ 'groupID' ]]))
$tmp[$t[ 'groupID' ]] = $t[ 'sign' ];
else
$tmp[$t[ 'groupID' ]] |= $t[ 'sign' ];
>
mysql_free_result($result);
if ($tmp)
//Если нашли + в любой из групп, возвращаем true. Иначе false.
return (array_search(0, $tmp) !== FALSE);
//Не нашли ни одного результата $tmp == false
return false ;
>
>
* This source code was highlighted with Source Code Highlighter .
То, что мы сейчас с вами проделали (переделали функцию в класс, сделав её удобнее в использовании и универсальнее) называется Рефакторинг. (wiki)
Сейчас этот класс можно использовать вот так:
//Создаём права пользователя
$UserRights = new Rights($CurrentUser->rightsID);
//Добавляем права объекта, с которыми должен иметь дело пользователь.
$PageRights = $UserRights->include_right($MainPage->rightsID);
Оптимизация
Качеством и функциональностью библиотеки мы с вами довольны, но возникает вопрос производительности.
Для начала посмотрим, что от запроса к запросу не меняется и оптимизируем это.
SELECT * FROM `rights_action` WHERE `RightsID` IN ( .implode(",",$this-> group ). ) AND ` action `= '$action' AND `GroupID` IN ( SELECT `GroupID` FROM `rights_group` WHERE `RightsID` = .$this->usrID. )
Во-первых, каждый раз происходит запрос SELECT `GroupID` FROM `rights_group` WHERE `RightsID` = . . Давайте с него и начнем.
При объявлении UserRights проведем этот запрос один раз, а результат уже будем вставлять в наш SQL-запрос.
function __construct($grp) $result=mysql_query( "SELECT `group_rights`.groupID FROM `group_rights` WHERE `group_rights`.rightsID=$grp" );
$ this ->usrID=array();
while ($t=mysql_fetch_assoc($result)) $ this ->usrID[]=$t[ 'groupID' ];
>
mysql_free_result($result);
Теперь в $this->usrID лежит готовая строка, которую можно пряма вставлять в запрос вместо целого SELECTa.
Уже стало легче, но все равно происходит поиск по всей БД каждый запрос. Как нам от этого можно избавиться? Вероятнее всего, создать предварительный результат, зависящий только от action — потому что выборка `RightsID` и `GroupID` остается неизменной.
Когда добавляется группа объектов, считываем все результаты из БД в массив, который будет зависеть лишь от значений 'action'.
Далее, уже перебором по каждому 'action' в массиве, ищем необходимый элемент. При этом запросов в БД больше нет — до следующего объекта с новыми правами.
В результате оптимизации, наш класс будет выглядеть вот так:
class Rights private $group= "" ;
private $usrID=array();
private $temptable= "" ;
function include_right($grp) $clone=clone $ this ;
$clone->group[]=$grp;
$result=mysql_query( "SELECT * FROM `action_rights` WHERE `action_rights`.groupID IN (usrID>) AND `action_rights`.rightsID IN (" .implode( "," ,$clone->group). ")" );
$tmp=array();
while ($t=mysql_fetch_assoc($result)) $tmp[]=$t;
>
mysql_free_result($result);
function check($action) $tmp=array();
foreach ($ this ->temptable as $t) if ($t[ 'action' ]==$action) if (!isset($tmp[$t[ 'groupID' ]]))
$tmp[$t[ 'groupID' ]]=$t[ 'sign' ];
else
$tmp[$t[ 'groupID' ]]|=$t[ 'sign' ];
>
>
if ($tmp) return (array_search(0,$tmp)!==FALSE);
>
return false ;
>
function __construct($grp) $result=mysql_query( "SELECT `group_rights`.groupID FROM `group_rights` WHERE `group_rights`.rightsID=$grp" );
$ this ->usrID=array();
while ($t=mysql_fetch_assoc($result)) $ this ->usrID[]=$t[ 'groupID' ];
>
mysql_free_result($result);
$ this ->usrID=implode( "," ,$ this ->usrID);
>
>
* This source code was highlighted with Source Code Highlighter .
Можно ли ещё быстрее?
2) Правильно расставить индексы в таблицах `action_rights` и `group_rights`.
Тут я не уверен. Эксперты меня надеюсь, поправят. Лично сделал PK — 'rightsID', 'action', 'groupID', INDEX — 'groupID', 'rightsID'
3) После создания Temporary Table, добавлять в неё индекс по 'action': ALTER TABLE `temptable>` ADD INDEX ( `action` ) .
Правда я не уверен, что этот способ тоже действенен. Эксперты, посвятите пожалуйста. :)
4) Использовать кеш. Но это уже другая история :)
Работающий пример
Я думаю, что уже достаточно на сегодня кода. Вот как это работает:
работающий пример — извиняюсь за не наглядность.
test.php (рабочий пример) — здесь используются мои библиотеки, которые работают с SQL БД, не удивляйтесь. Уверен, что разберетесь.
rights.php — наша библиотека.
Расширяемость
Любые новые действия, которые вы будете использовать в вашем проекте добавляются в 'action' ENUM.
Если вы не хотите быть привязанным к конкретным действиям и добавлять их в реальном времени, то стоит заменить 'action' ENUM на integer и создать ещё одну таблицу соответствий actionID с action_name. (как мы сделали это с названиями Групп)
Общие проекты и режимы совместного редактирования текстовых материалов на страницах сервиса Google Docs появились уже давно. Достаточно поделиться доступом с гугл диска, и у вашего коллеги, сотрудника и даже случайных пользователей появится шанс вносить изменения в данные, оставлять комментарии и делиться мнением.
Уровни прав доступа к файлам и каталогам на Google Docs (и смежных сервисах — Drive, Sheets)
Перечисленные роли в сервисе Google Docs встречаются при каждой настройке режима совместного взаимодействия с материалами.
Важно! Не ошибиться в выборе уровня прав доступа к файлам, чтобы не столкнуться с ситуацией утечки конфиденциальной информации или потери данных.
Настройка прав доступа к документам по приглашению или ссылке на гугл диске
Способы разграничения контроля на гугл диске
Для разграничения контроля на гугл диске предусмотрено два способа.
Для появления дополнительных параметров на гугл диске вы можете кликнуть по шестеренке сверху в меню. Вам откроется поля выбора, связанные с возможностью изменять разрешения и параметры доступа или же скачивать, распечатывать и копировать документы. Выбор напрямую зависит от типа предоставляемых файлов и ценности содержимого.
- Кроме полноценного совместного доступа на сайте Google Docs контроль над материалами выдается и по ссылке.
Блокировка доступа к файлам на гугл диске
Если выданные сотрудникам, коллегам или друзьям права на просмотр, редактирование или копирование материалов, представленных в хранилище Google Docs, потеряли актуальность, тогда действовать нужно в обратном порядке:
Ограничение доступа к документам через Google Drive
Кроме индивидуальной настройки прав доступа к каждому конкретному файлу и материалу, предусмотрен и альтернативный путь решения проблемы, способный сэкономить массу времени. Речь о пакетной обработке информации из облачного хранилища Google Drive с помощью ручной сортировки и специального меню предпросмотра, разрешающего за пару минут посмотреть, кому и когда выданы полномочия редактора, читателя или комментатора, а вместе с тем – мгновенно заблокировать режим совместного взаимодействия на вашем гугл диске.
Ограничение доступа через Google Drive в три этапа:
-
Сортировка контента . Сервис распределяет файлы по цифровым папкам в зависимости от даты добавления, названия, назначения. Однако, предусмотренных Google Drive параметров недостаточно для полноценной сортировки. Поэтому можно воспользоваться специальной командой, ее нужно добавить в текстовую строку в верхней части интерфейса – type:document owner:e-mail. Перед вводом команду предстоит отредактировать – необходимо дописать вместо e-mail адрес электронной почты Google.
Сервис сразу отобразит, какие пользователи или группы способны редактировать данные в виде списка или – предложит перейти к настройке доступа по ссылкам на гугл диске.
Выводы
Также читайте другие статьи в блоге Webpromo:
И подписывайтесь на наш Telegram-канал про маркетинг.
Статья о разграничении прав доступа в операционных системах Windows: дискретном и мандатном. В статье рассматриваются разграничения прав доступа к папкам и файлам на уровне операционной системы Windows и с помощью Secret Net.
Дискретное разграничение прав доступа
Основные права доступа к папкам
В файловой системе NTFS в Windows XP существует шесть стандартных разрешений:
- Полный доступ;
- Изменить;
- Чтение и выполнение;
- Список содержимого папки;
- Чтение;
- Запись.
Выбор пользователя Список содержимого
По аналогии установите права для соответствующих папок.
После установки прав доступа проверьте их. Для этого войдите в операционную систему под пользователем, для которого устанавливали права, в моем случае это user.
Откройте каждую папку и проверьте, что разрешения выполняются.
Элементы разрешений на доступ
Каждое разрешение состоит из нескольких элементов, которые позволяют более гибко настраивать систему безопасности. Войдите в операционную систему под учетной записью администратора.
Поэкспериментируйте с элементами и проверьте, как они работаю.
Элементы разрешений на доступ для записи
Владелец файла
В файловой системе NTFS у каждого файла есть свой владелец. Владельцем файла является пользователь операционной системы. Он может управлять разрешениями на доступ к объекту независимо от установленных разрешений.
Наследование прав доступа
В файловой системе NTFS поддерживается наследование разрешений. Если вы устанавливаете разрешение на папку, то оно наследуется для всех вложенных файлов и папок.
При любых изменениях разрешений на родительскую папку они меняются в дочерних (вложенных) файлах и каталогах.
Запреты
Кроме установки разрешений в файловых системах можно устанавливать запреты. Например, вы можете разрешить чтение и выполнение, но запретить запись. Таким образом, пользователь для которого установлен запрет и разрешения сможет запустить исполняемый файл или прочитать текстовый, но не сможет отредактировать и сохранить текстовый файл.
Запреты на объекты в файловой системе NTFS
В дополнительных параметрах безопасности можно посмотреть действующие разрешения и для конкретного пользователя.
Разграничение прав доступа с помощью Secret Net (на примере версии 5.1)
При использовании Secret Net доступ к файлам осуществляется, в случае если пользователю присваивается соответствующий уровень допуска. В примере я использую Windows XP с установленным программным продуктом Secret Net 5.1.
Введите названия уровней. У меня это:
- Низший – Общедоступно.
- Средний – Конфиденциально.
- Высший – Секретно.
Настройка субъектов
Далее установите все флажки.
- Управление категориями конфиденциальности означает, что пользователь имеет право изменять категории конфиденциальности папок и файлов, а так же может управлять режимом наследования категорий конфиденциальности папок.
- Печать конфиденциальных документов означает, что пользователь может распечатывать конфиденциальные документы. Данная возможность появляется, если включен контроль печати конфиденциальных документов.
- Вывод конфиденциальной информации означает, что пользователь может копировать конфиденциальную информацию на внешние носители.
Настройка объектов
Та или иная категория конфиденциальности является атрибутом папки или файла. Изменения этих атрибутов производятся уполномоченными пользователями (в данном случае Администратором). Категория конфиденциальности может присваиваться новым файлам или папкам автоматически или по запросу.
При этом стоит учесть, что категории конфиденциальности могут назначаться только папка и файлам в файловой системе NTFS. В случае если у пользователя нет такой привилегии, он может только повысить категорию конфиденциальности и только не выше своего уровня.
В случае если категория допуска пользователя выше чем категория конфиденциальности объект, то пользователь имеет право на чтение документа, но не имеет права изменять и сохранять документ.
То есть пользователь не может работать с документами, у которых уровень конфиденциальности выше, чем у него.
Не стоит забывать, что конфиденциальные файлы нельзя копировать в общедоступные папки, чтобы не допустить их утечки.
Контроль потоков данных
Контроль потоков данных используется для того, что бы запретить пользователям возможность понижения уровня конфиденциальности файлов.
На этом все, если у вас остались вопросы задавайте их в комментариях.
Обучаю HTML, CSS, PHP. Создаю и продвигаю сайты, скрипты и программы. Занимаюсь информационной безопасностью. Рассмотрю различные виды сотрудничества.
Читайте также: