Какая система контроля доступа подходит для динамической многоуровневой проверки безопасности?

У меня есть RESTful API и микросервисная архитектура. Такие как -

  • Служба аутентификации
  • Пользовательское обслуживание
  • Сервисное обслуживание продуктов
  • Более ...

В настоящее время я проверяю запрос через токен JWT, который можно получить из службы Auth. Теперь пришло время внедрить систему контроля доступа.

Это внутреннее инструментальное приложение (довольно сложное), и моей основной мыслью было использовать RBAC (управление доступом на основе ролей), но это приложение не было традиционным. В приложении пользователь A может объединиться в пару с другим пользователем B, и после завершения объединения в соответствии с настройками пользователя B пользователь A может выполнять различные действия.

Таким образом, разрешения не статичны и основаны на других переменных. Так следует ли мне использовать систему ABAC / PBAC? Какие-либо предложения?

Мысли об ABAC

  • Субъекты - Кто отправляет запрос, например, Пользователь A
  • Объект - доступ к чему? например, модуль A
  • Действия - читать или писать? например, прочитать запрос GET
  • Среда - условие, например, для какого пользователя? (Пользователь B)

person HADI    schedule 10.02.2019    source источник


Ответы (1)


Мой предвзятый ответ: да, вам следует :-) (я работаю в Axiomatics, и все, что мы делаем, это PBAC / ABAC и делали это уже 15 лет).

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

Основное преимущество управления доступом на основе атрибутов для вас (abac) заключается в том, что это даст вам свободу адаптировать политики контроля доступа с течением времени без необходимости переписывать приложение. Фактически, вы отделяете / отделяете авторизацию от приложения.

Ниже показан базовый архитектурный поток в ABAC, посредством которого компонент (PEP) перехватывает бизнес-поток и преобразует его в поток авторизации (Может ли Алиса просматривать запись 123?).

Архитектура управления доступом на основе атрибутов

Политики могут быть написаны в xacml или alfa. Я предпочитаю второй вариант, поскольку его синтаксис очень легкий (подробнее см. В Википедии).

Например, вы можете написать:

namespace com.acme{
    /**
     * Tutorial 101 - a flat approach using 4 rules
     */
     policyset recordsAccess{
         apply firstApplicable
         /**
          * Records access control
          */
          policy records{
              target clause object.objectType == "record"
              apply firstApplicable
              /**
               * R1 - A manager can view any records
               */
               rule managersView{
                   target clause user.role == "manager" and action.actionId == "view"
                   permit
               }
              /**
               * R2 - An employee can view a record in their own department
               */
               rule employeesView{
                   target clause user.role == "employee" and action.actionId == "view"
                   condition user.department == record.department
                   permit
               }
              /**
               * R3 - An employee can edit a record they own, if it is in draft mode
               */
               rule employeeEdit{
                   target clause user.role == "employee" and action.actionId == "edit" and record.status == "draft"
                   condition  com.acme.record.owner == com.acme.user.employeeId 
                   permit
               }
              /**
               * R4 - A manager can publish a record if the record is in final 
               * mode and it belongs to a employee below that manager.
               */
               rule managerPublish{
                   target clause user.role == "manager" and action.actionId == "publish"
                   condition stringIsIn(stringOneAndOnly(com.acme.record.owner),com.acme.user.subordinate)
                   permit
               }
          }
     }
}
person David Brossard    schedule 12.02.2019