Неролевая безопасность?

Question

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

Учебный подход к безопасности - это «ролевая безопасность». Каждый экран, отчет или другая задача привязана к одной или нескольким ролям; каждому пользователю назначена одна или несколько ролей; и тогда каждый пользователь может использовать экраны и т. д., которые соответствуют его ролям и ничему другому. Правильно?

Несколько лет назад я руководил командой, разрабатывающей систему управления военно-техническими руководствами. У каждого руководства был «менеджер технического контента», лицо, ответственное за его написание или редактирование; «менеджер по запасам», ответственный за отслеживание копий и их отправку; и «административный менеджер», ответственный за бюджет и который поэтому решил, как часто будет пересматриваться книга, сколько экземпляров будет напечатано и так далее. Конечно, в каждой книге было много людей, которые заказывали копии и читали ее. (Поскольку это были военные, вы должны были получить разрешение на то, чтобы получить в руки книгу, документы о безопасности и все такое.) Обычно мы беспокоились не о реальных читателях, а о людях на каждой базе, которые управляли библиотеками. , но здесь это не совсем актуально.

Итак ... это очевидные "роли", но роль была привязана к конкретной книге. Один человек может быть менеджером технического контента для книги А, административным менеджером для книги Б и читателем 50 других книг. Таким образом, мы не могли сказать, что у пользователя была «роль». У каждого пользователя были разные роли для каждой книги.

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

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

Персона (person_id, имя и т. Д.)

Technical_Manual (manual_id, title, admin_manager_person_id, stock_manager_person_id, content_manager_person_id и т. Д.)

Authorized_Reader (manual_id, person_id и т. Д.)

Пользователь (user_id, admin_role и т. Д.)

Я был не очень доволен этой схемой, поскольку она означала, что безопасность была разделена на три таблицы: таблица technical_manual, таблица authorized_reader и таблица user. Но ... был ли более чистый способ, которым мы могли бы сделать это? Есть идеи получше?

Answer 1

То, как я недавно сделал нечто похожее на это, выглядит так:

Person (person_id, name, etc)

Role (role_id, name [admin manager, stock manager, content manager, authorized reader, etc])

Technical_Manual (manual_id, title, etc)

Technical_Manual_Role (manual_id, person_id, role_id)

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

Answer 2

Просто хотел добавить больше с точки зрения концепции. Несмотря на то, что RBAC (управление доступом на основе ролей), похоже, находится в моде, существует множество моделей, таких как DAC, MAC, которые доступны для решения проблемы контроля доступа в течение более длительного времени (RBAC фактически был оформлен где-то в 1995 году, в то время как другие модели были вокруг намного дольше и использовались военными). Как вы объяснили требования, я вижу несколько моделей в использовании

1. RBAC - используется в случае "системных ролей", о которых вы говорили.
2. Управление доступом на основе атрибутов / политик - используется для всех частей, связанных с руководством.
3. MAC - используется для управления доступом к руководствам на базе, т. Е. Каждому руководству и пользователю присвоен уровень чувствительности, и они должны соответствовать на основе определенных критериев, чтобы иметь возможность доступа.

Эти модели могут быть выражены с использованием стандартов, таких как XACML (и оценены во время выполнения с использованием реализаций механизма политики), которые могут описывать политику. Например, в вашем случае политика будет выглядеть примерно так:

(на основе атрибутов)

Разрешить "всем" редактировать "руководство", если userId = manual.technical_content_manager

Разрешить "всем" отправлять "вручную", если userId = manual.stock_manager

(RBAC) * * тысяча двадцать-один

Разрешить «HelpDesk» «просматривать» «ручную информацию», «ручную»

Разрешить «Администратору» «просматривать», «редактировать», «отправлять» «вручную»

(MAC)

Разрешить "всем" просматривать "руководство", если userId.level> = manual.level

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

Answer 3

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

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

Скажем, есть три таких различающих фактора, каждый из которых имеет диапазон из семи возможных значений (7 различных диапазонов суммы кредита). Тогда вам нужно будет определить 7 * 7 * 7 = 343 роли. Затем для каждого отдельного пользователя вашей системы вам нужно будет назначить полное подмножество всех ролей, которые может выполнять этот пользователь. Если пользователь уполномочен принимать решение по кредитной заявке в 50 000 000, то вполне вероятно (но опять же, не совсем точно!), Что он также имеет право принять решение по кредитной заявке в размере 5 000 000.

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

Answer 4

Прокомментируйте ответ Хаоса:

Мне приходит в голову, что роли «системного уровня» могли бы соответствовать одной и той же схеме, если для manual_id для таких вещей можно было бы установить значение null или какое-либо магическое значение. Да, я знаю, у некоторых есть сильное отвращение к нулям, но это работает здесь. Тогда будет единственная таблица «безопасности», и все будет чисто.

У меня было много проблем с тремя полями менеджера. У нас было несколько запросов типа «За какие книги отвечает Боб?», Которые требовали большого ИЛИ для всех трех полей. Это означало, что нам нужно три индекса. Позже я понял, что было бы лучше разбить это на отдельный стол. Но бросить авторизованных читателей в ту же таблицу ... многое навести порядок. Добавьте сюда системный уровень и ... мне это нравится. Становится легко спросить: «Какие права имеет Мэри Джонс?» а также «У кого есть права на руководство по авионике F-15?», «Кто все наши технические менеджеры контента?» и т.д.

Answer 5

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

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

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

Answer 6

Я знаю, это может показаться немного глупым, НО ВЫ МОЖЕТЕ сделать что-то вроде этого:

Roles(role_id, etc)

Technical_Manual(manual_id, acceptable_roles, etc), где acceptable_roles - список с разделителями

Затем в вашей программе разделите список с разделителями. Я не говорю, что это ЛУЧШИЙ способ, но он будет работать. Хотя я не знаю, будет ли это лучше всего для военного применения:)