Хочу описать свои текущие знания по схемам контроля доступа к объектам, с тем чтобы помочь начинающим разработчика проще ориентироваться в этом вопросе.
В программных продуктах, которые используют несколько пользователей, как правило, возникает вопрос, как алгоритмически описать, какой пользовать, какую операцию может или не может выполнять над определённым ресурсом.
Первое что приходит в голову, это сделать некую табличку, где будут для каждого пользователя и для каждого ресурса указаны наборы операций, которые данный пользователь может делать над данным объектом. К сожалению, данная таблица очень быстро разрастается и в итоге становится практически не управляемой, ведь при добавлении нового ресурса надо указать всех пользователей и операции, которые им разрешены.
Как попытку упрощения данной схемы можно рассмотреть объединение пользователей в группы пользователей и объединение ресурсов в группы ресурсов и задание разрешенных операций уже над группами пользователей и группами ресурсов. При этом иногда ресурсы группируют просто по типу, тогда правила доступа можно задавать на уровне какие операции данная группа пользователей может делать над данным типом ресурсов.
По мере роста количества разного рода пользователей или типов ресурсов, может начинать расти количество соответствующих групп и в итоге опять возникает проблема сложной поддержки данной схемы контроля доступа.
Операции над ресурсами только с точки зрения кода являются независимыми, а с точки зрения конечного пользователя очень неудобно, для разрешения операции на создание файла, разрешать доступ к жесткому диску, потом разрешать изменение директории, где будет лежать файл и разрешать запись на диск. Поэтому есть смыл на этапе проектирования системы предусмотреть некое количество типичных ролей пользователей близких к реальным должностям пользователей и под них настроить такое поведение системы, которое ожидается для пользователя в этой должности.
Так если пользователь в роли администратор, то ему разрешены все операции по администрированию системы.
Из этого не следует, что роли нельзя создавать или настраивать, но, по сравнению с группами пользователей, сам подход настройки безопасности изменяется от настройки списка операций для групп потребителем продукта в сторону наличия неких шаблонов безопасности, без необходимости описывать и управлять каждой операцией пользователя.
Когда ресурсы можно выстроить в некие иерархии отношения родитель-потомок, бывает удобно задавать права не каждый ресурс, а на некий корень иерархии и для всех вложенных ресурсов права вычислять на базе прав на корневой ресурс. Так если у вас роль «директор» какой-то компанией, то у вас, по умолчанию, будут права увольнять любого сотрудника в этой фирме.
При этом для разных операций иерархии могут быть разными. В том же примере с директором, право на увольнение определяется иерархией сотрудников в компании, где работает сотрудник, но право на проверку уплаты налогов определяется территориальная принадлежность данного сотрудника определенной налоговой.
Данная схема является упрощением идеи корневой безопасность, в том смысле, что права на ресурсы определяются не через принадлежность какой-то иерархии родитель-потомок, а вхождение ресурса в некий крупный объект, называемый периметром безопасности. Тогда права определяются между пользователем и этим периметром. В качестве примера можно привести системы управления муниципалитетами – права сотрудника муниципалитета над школой определяются вхождением данной школы в нужный муниципалитет.
Claims это некие утверждения о пользователе. Их можно рассматривать как некие атрибуты пользователя: его email, организация, отдел и должность где он работает и т.п. Соответственно можно рассмотреть возможность формулировать права пользователя на основе этих атрибутов. Так к документам на внутреннем сервере компании должны иметь доступ только пользователи, у которых в claim «организация» указана нужная организация.
XACML является языком описания правил доступа к ресурсу на основании claim пользователя, атрибутов ресурса, текущей операции и дополнительной информации окружения. По сути это XML файл, в котором написан некий алгоритм с проверкой предоставленных атрибутов пользователя, ресурса, требуемой операции и окружения и принятия решения разрешать ли эту операцию в таких условиях. На пример, там можно написать «если пользователь главный бухгалтер в такой-то организации (claims), хочет выполнить операцию «чтение документа» с корпоративного сервера (ресурс), и сейчас рабочее время (окружение) то разрешить». Кроме как разрешить/запретить операцию, можно наложить дополнительные обязательства (obligations), так например можно разрешить, но условием что у пользователя переспросят его пароль ещё раз.
Тут смысл в том, что в данной нотации можно описать практически любую бизнес схему прав с стандартной форме. Минусом является достаточно медленное принятие решений, так как надо собирать дополнительную информацию, с чем приходится бороться через умное кэширование вердиктов и использование корневой безопасности.
Введение
В программных продуктах, которые используют несколько пользователей, как правило, возникает вопрос, как алгоритмически описать, какой пользовать, какую операцию может или не может выполнять над определённым ресурсом.
Permissions
Первое что приходит в голову, это сделать некую табличку, где будут для каждого пользователя и для каждого ресурса указаны наборы операций, которые данный пользователь может делать над данным объектом. К сожалению, данная таблица очень быстро разрастается и в итоге становится практически не управляемой, ведь при добавлении нового ресурса надо указать всех пользователей и операции, которые им разрешены.
Группы
Как попытку упрощения данной схемы можно рассмотреть объединение пользователей в группы пользователей и объединение ресурсов в группы ресурсов и задание разрешенных операций уже над группами пользователей и группами ресурсов. При этом иногда ресурсы группируют просто по типу, тогда правила доступа можно задавать на уровне какие операции данная группа пользователей может делать над данным типом ресурсов.
По мере роста количества разного рода пользователей или типов ресурсов, может начинать расти количество соответствующих групп и в итоге опять возникает проблема сложной поддержки данной схемы контроля доступа.
Роли
Операции над ресурсами только с точки зрения кода являются независимыми, а с точки зрения конечного пользователя очень неудобно, для разрешения операции на создание файла, разрешать доступ к жесткому диску, потом разрешать изменение директории, где будет лежать файл и разрешать запись на диск. Поэтому есть смыл на этапе проектирования системы предусмотреть некое количество типичных ролей пользователей близких к реальным должностям пользователей и под них настроить такое поведение системы, которое ожидается для пользователя в этой должности.
Так если пользователь в роли администратор, то ему разрешены все операции по администрированию системы.
Из этого не следует, что роли нельзя создавать или настраивать, но, по сравнению с группами пользователей, сам подход настройки безопасности изменяется от настройки списка операций для групп потребителем продукта в сторону наличия неких шаблонов безопасности, без необходимости описывать и управлять каждой операцией пользователя.
Корневая безопасность
Когда ресурсы можно выстроить в некие иерархии отношения родитель-потомок, бывает удобно задавать права не каждый ресурс, а на некий корень иерархии и для всех вложенных ресурсов права вычислять на базе прав на корневой ресурс. Так если у вас роль «директор» какой-то компанией, то у вас, по умолчанию, будут права увольнять любого сотрудника в этой фирме.
При этом для разных операций иерархии могут быть разными. В том же примере с директором, право на увольнение определяется иерархией сотрудников в компании, где работает сотрудник, но право на проверку уплаты налогов определяется территориальная принадлежность данного сотрудника определенной налоговой.
Периметр безопасности
Данная схема является упрощением идеи корневой безопасность, в том смысле, что права на ресурсы определяются не через принадлежность какой-то иерархии родитель-потомок, а вхождение ресурса в некий крупный объект, называемый периметром безопасности. Тогда права определяются между пользователем и этим периметром. В качестве примера можно привести системы управления муниципалитетами – права сотрудника муниципалитета над школой определяются вхождением данной школы в нужный муниципалитет.
Claim-based безопасность
Claims это некие утверждения о пользователе. Их можно рассматривать как некие атрибуты пользователя: его email, организация, отдел и должность где он работает и т.п. Соответственно можно рассмотреть возможность формулировать права пользователя на основе этих атрибутов. Так к документам на внутреннем сервере компании должны иметь доступ только пользователи, у которых в claim «организация» указана нужная организация.
XACML
XACML является языком описания правил доступа к ресурсу на основании claim пользователя, атрибутов ресурса, текущей операции и дополнительной информации окружения. По сути это XML файл, в котором написан некий алгоритм с проверкой предоставленных атрибутов пользователя, ресурса, требуемой операции и окружения и принятия решения разрешать ли эту операцию в таких условиях. На пример, там можно написать «если пользователь главный бухгалтер в такой-то организации (claims), хочет выполнить операцию «чтение документа» с корпоративного сервера (ресурс), и сейчас рабочее время (окружение) то разрешить». Кроме как разрешить/запретить операцию, можно наложить дополнительные обязательства (obligations), так например можно разрешить, но условием что у пользователя переспросят его пароль ещё раз.
Тут смысл в том, что в данной нотации можно описать практически любую бизнес схему прав с стандартной форме. Минусом является достаточно медленное принятие решений, так как надо собирать дополнительную информацию, с чем приходится бороться через умное кэширование вердиктов и использование корневой безопасности.