Как в управлении доступом на основе атрибутов (ABAC) моделировать атрибуты на основе отношения между субъектом и объектом?

Каков рекомендуемый способ моделирования атрибутов, возникающих из отношения между субъектом и объектом в управлении доступом на основе атрибутов (ABAC)?

Пример: медицинские записи как объекты и счета врачей / медсестер как субъекты. В простой обстановке, без прямой связи между субъектом и объектом, правило может указывать что-то вроде «Практикующие медсестры в Кардиологическом отделении могут Просмотр медицинские записи кардиологических пациентов "(пример из Технический документ NIST). Теперь представьте, что в базе данных медицинских записей каждая запись явно ссылается на учетную запись определенного врача как на его Лечащий врач. В правиле должно быть указано, что только лечащему врачу записи разрешено изменять некоторые важные свойства этой записи.

Как лучше всего смоделировать это в атрибутах?

В идеале уполномоченный субъект может иметь атрибут «Функция = Лечащий врач». Это упростило бы техническую формулировку правила, но также сделало бы построение субъектов объектно-зависимым, что звучит неправильно.

В качестве альтернативы объект может нести атрибут «Лечащий врач = (ID-учетной записи)», что звучит лучше, но тогда техническое выражение правила будет более сложным: «предоставить доступ, если значение атрибута ID учетной записи субъекта совпадает с << em> Лечащий врач значение атрибута ". (В реальной жизни отношения, вероятно, были бы более сложными и вложенными, а правила сложнее выразить простыми словами.)

Любые рекомендации или передовой опыт?

Спасибо, Джон


person ujay68    schedule 05.01.2018    source источник


Ответы (1)


да. В ABAC (и ALFA / XACML) вы должны написать политику в следующих строках:

  • Врач может просмотреть медицинскую карту.

Это базовый уровень без каких-либо отношений. Если вы хотите ввести отношения, например, отношения заботы, введите в смесь объект пациента. Запись принадлежит пациенту, и к пациенту назначен врач. Теперь политика выглядит следующим образом:

  • Врач может просматривать медицинскую карту пациента, с которым он заботится.

В переваренном формате это становится:

  • Пользователь с ролью == "врач" может выполнять действие == "просмотр" над объектом типа == "медицинская карта", если record.owner.assignedPhysician == user.userID.

Вот полный пример в ALFA.

namespace com.axiomatics.examples{

    import Attributes.*

    obligation breakTheGlass = "com.axiomatics.examples.breakTheGlass"
    obligation auditLog = "com.axiomatics.examples.auditLog"

    namespace user{
        attribute role{
            category = subjectCat
            id = "com.axiomatics.examples.user.role"
            type = string
        }
        attribute identifier{
            category = subjectCat
            id = "com.axiomatics.examples.user.identifier"
            type = string
        }
        attribute managerEmail{
            category = subjectCat
            id = "com.axiomatics.examples.user.manager.email"
            type = string
        }
    }
    namespace patient{
        attribute assignedDoctor{
            category = resourceCat
            id = "com.axiomatics.examples.user.assignedDoctor"
            type = string
        }
    }
    namespace record{
        attribute identifier{
            category = resourceCat
            id = "com.axiomatics.examples.record.identifier"
            type = string
        }
    }
    attribute actionId{
        category = actionCat
        id = "com.axiomatics.examples.actionId"
        type = string
    }
    attribute objectType{
        category = resourceCat
        id = "com.axiomatics.examples.objectType"
        type = string
    }
    attribute isEmergency{
        category = environmentCat
        id = "com.axiomatics.examples.isEmergency"
        type = boolean
    }
    attribute message{
        category = environmentCat
        id = "com.axiomatics.examples.message"
        type = boolean
    }
    /**
     * Control access to medical records
     */
    policy accessMedicalRecord{
        target clause actionId == "view" and objectType == "medical record"
        apply firstApplicable
        /**
         * Doctors can view medical records of patients they are assigned to
         */
        rule allowRegularAccess{
            target clause user.role == "doctor"
            condition patient.assignedDoctor == user.identifier
            permit
        }
        /**
         * Doctors can view any medical reason in the case of an emergency
         */
        rule allowBreakTheGlassAccess{
            target clause isEmergency == true
            permit
            on permit{
                obligation auditLog{
                    message = "A doctor has gotten access to a medical record by breaking the glass"
                    user.identifier = user.identifier
                    record.identifier = record.identifier
                    currentDateTime = currentDateTime
                }

            }
        }
        /**
         * Deny other accesses. If access is normally denied, tell doctors how
         * they can get access by "breaking the glass".
         */
        rule denyAccess{
            deny
            on deny{
                obligation breakTheGlass{
                    message = "You do not have access to this medical record. To be granted access, set the isEmergency flag to true."
                    record.identifier = record.identifier
                    currentDateTime = currentDateTime
                }
            }
        }
    }
}
person David Brossard    schedule 05.01.2018
comment
Дэвид, спасибо. Итак, в моем примере идентификатор учетной записи лечащего врача будет добавлен в набор атрибутов объекта (= медицинская карта). Или, в вашем примере, к набору атрибутов объекта. Это сохранит кэшируемые решения по политике: смена лечащего врача изменит либо объект (мой пример), либо субъект (ваш пример). - person ujay68; 23.01.2018
comment
Но все же кажется, что невозможно выразить правило доступа с помощью простого условия, такого как Function = Attain Physician, которое не использовало бы прямое сравнение идентификаторов. - person ujay68; 23.01.2018
comment
Лечащий врач больше не играет роли. Скорее вы сравните идентификатор врача, назначенного данному пациенту (и это часть вашей информационной модели), с идентификатором пользователя, который в настоящее время вошел в систему. - person David Brossard; 23.01.2018