Управление ACL / ролями: управление пользователями с несколькими ролями и конфликтующие разрешения

Question

Логическая точка застревания.Я строю простой ACL, и я просто в замешательстве.Я просто пытаюсь сделать это правильно.

Возьмем пример простой ACL на основе модели.

Таблица управления пользователями tbl_user

id | userid |
-------------
1  | nabin  |
2  | suman  |

Другая таблица для управления группами tbl_group

id | groupname |
-----------------
1  | admin     |
2  | member    |
3  | editor    |
4  | moderator |

Еще одна таблица для ведения групп и пользователей.tbl_roles

id | userid | groupid
-----------------------
1  | 1      | 1
2  | 1      | 2
3  | 2      | 2
4  | 2      | 3
5  | 2      | 4

Теперь таблица для управления доступом tbl_acl

id | groupid | appresourceid
----------------------------
1  | 3       | 1

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

Теперь, согласно примеру groupid:3 (editor), было отказано в ресурсе 1 (предположим, что это область администрирования).

Но, если вы берете userid: 2(suman), тогда они editor и moderator.Согласно правилу tbl_acl, editor должно быть отказано, тогда как moderator должно быть разрешено.

Должен ли он иметь доступ к ресурсу или ему должно быть отказано? Разрешено ПЕРВЫЙ или Запрещено ПЕРВЫЙ.Какой из них должен быть приоритетным?

Некоторые способы просмотра этого

1. Хотя пользователю отказано в качестве редактора, ему как модератору разрешен доступ кarea.
2. Несмотря на то, что модератору разрешен доступ к ресурсу, все редакторы ограничены.
3. Не забывайте, что пользователь тоже member.Так что, если мы расставляем приоритеты над разрешением над отказом.Участник будет иметь доступ в качестве модератора.Если только член не заблокирован тоже

_{PS Мне хорошо известно, что эта тема является дискуссионной.Таким образом, факты будут оценены (не говоря не) за мнения и догадки.}

Answer 1

Вы столкнулись с этой дилеммой, потому что вы приняли довольно нестандартный подход, позволяющий доступ к ресурсам по умолчанию. Гораздо более стандартный подход состоит в том, чтобы запретить доступ по умолчанию, предоставить доступ через одну или несколько записей ACL «разрешить» и переопределить любые записи «allow» даже через одну запись «deny». При таком подходе любая «запрещенная» запись превосходит все «разрешенные» записи. (т. е. приложение должно сначала искать отказы и, если оно находит, ему даже не нужно проверять разрешения).

Если вам нужно убедить, что «предотвращать по умолчанию» - лучшая модель, чем «разрешать по умолчанию», вот несколько основных отличий:

1. Как правило, лучше подходит для ментальной модели разрешений управление осуществляется большинством администраторов разрешений, будь они ИТ-персонал или администраторы бизнес-приложений. (Предоставляется, это по крайней мере частично из-за того, что большинство других систем они придется использовать эту модель, но это не делает его менее актуально.)

2. Человеческая ошибка с меньшей вероятностью приведет к ненадлежащему предоставлению разрешение. (т. е. если администратор забывает добавить «разрешить» запись в режиме предотвращения по умолчанию, ни один пользователь не может получить доступ ресурсы, к которым он не должен был прикоснуться.)

3. Когда в систему добавляется новое разрешение, никто без специальных права администратора могут получать доступ к целевым ресурсам (ресурсам) до явного Добавлены «разрешающие» записи.

# 3 особенно убедителен. Представьте, что вы развертываете новую версию приложения HR с новым разрешением «просматривать зарплаты». Считаете ли вы приемлемым позволить всем пользователям получать это разрешение до тех пор, пока кто-нибудь не добавит «запрещающие» записи в ваши списки ACL?

Answer 2

Я думаю, что мысленный образ здания будет уместен 2 сценария:

Сценарий «разрешить по умолчанию»:

• Вход в здание открыт
• Комнаты здания открыты
• Любой шкаф в комнатах открыт

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

• Джону запрещен вход в комнату A
• Джон подходит к комнате A
• Кто-то должен проверить, Джон ли это
• что кто-то должен иметь право отказать Джону войти в комнату
• что кто-то закрывает дверь перед лицом Иоанна

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

Как это практично?

Сценарий «отклонить по умолчанию»:

• Вход в здание закрыт и заперт
• Комнаты здания закрыты и заперты
• Любой шкаф в комнатах закрыт и заперт

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

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

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

Answer 3

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

Answer 4

Для меня «allow» должно выиграть от «deny» при наличии конфликтующих разрешений.Как правило, у вас есть роли, охватывающие широкий набор функций, но с ограниченными разрешениями (например, гостевая) на роли с большей ответственностью.Вы сможете использовать общие роли только тогда, когда разрешите переопределить «отказано».

Пример разрешений:

1.

deny members all
allow members to view articles

Разрешить отменяет запрет.

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