|
|
| Строка 1: |
Строка 1: |
| − | <blockquote>''[[:Категория:Евгений Мяченков (Статьи)|Евгений Мяченков]], наш ведущий разработчик, опубликовал в корпоративном блоге на [http://habrahabr.ru/ «Хабрахабре»] статью, посвященную вопросу контроля доступа в компании. Какие существуют подходы к контролю доступа? В чем заключаются достоинства и недостатки ролевого подхода? Какие преимущества по сравнению с ним предоставляет подход, основанный на атрибутах? Ответы на эти вопросы — в материале[http://habrahabr.ru/company/custis/blog/248649/ «Подходы к контролю доступа: RBAC vs. ABAC»].''</blockquote> | + | <blockquote>''[[:Категория:Евгений Мяченков (Статьи)|Евгений Мяченков]], наш ведущий разработчик, опубликовал в корпоративном блоге на [http://habrahabr.ru/ «Хабрахабре»] статью, посвященную вопросу контроля доступа в компании. Какие существуют подходы к контролю доступа? В чем заключаются достоинства и недостатки ролевого подхода? Какие преимущества по сравнению с ним предоставляет подход, основанный на атрибутах? Ответы на эти вопросы — в материале[http://habrahabr.ru/company/custis/blog/248649/ «Подходы к контролю доступа: RBAC vs. ABAC»].''</blockquote> |
| | === Введение === | | === Введение === |
| | | | |
| Строка 6: |
Строка 6: |
| | [[Image:RBAC Схема 1.jpg|thumb|450px|center]] | | [[Image:RBAC Схема 1.jpg|thumb|450px|center]] |
| | | | |
| − | Если компания успешна и объемы работы растут, то наступает момент, когда один человек перестает справляться. И тогда в компанию нанимаются новые сотрудники. | + | Если компания успешна и объемы работы растут, то наступает момент, когда один человек перестает справляться. И тогда в компанию нанимаются новые сотрудники. |
| | | | |
| | [[Image:RBAC Схема 2.jpg|thumb|450px|center]] | | [[Image:RBAC Схема 2.jpg|thumb|450px|center]] |
| | | | |
| − | Но когда число сотрудников в компании увеличивается, появляются другие проблемы, например: | + | Но когда число сотрудников в компании увеличивается, появляются другие проблемы, например: |
| | | | |
| − | * каждый сотрудник должен выполнять только свои бизнес-задачи и не иметь доступа к чужим; | + | * каждый сотрудник должен выполнять только свои бизнес-задачи и не иметь доступа к чужим; |
| | | | |
| | * каждый сотрудник должен видеть только связанную со своими бизнес-задачами информацию; | | * каждый сотрудник должен видеть только связанную со своими бизнес-задачами информацию; |
| Строка 18: |
Строка 18: |
| | * у каждой задачи должен быть ответственный за ее выполнение сотрудник. | | * у каждой задачи должен быть ответственный за ее выполнение сотрудник. |
| | | | |
| − | Если не решить эти проблемы, фирма может понести финансовые потери из-за: | + | Если не решить эти проблемы, фирма может понести финансовые потери из-за: |
| | | | |
| | * неэффективного выполнения чужих задач в силу некомпетентности; | | * неэффективного выполнения чужих задач в силу некомпетентности; |
| | | | |
| − | * умышленных или неумышленных ошибок в чужих задачах; | + | * умышленных или неумышленных ошибок в чужих задачах; |
| | | | |
| | * раскрытия информации посторонним лицам. | | * раскрытия информации посторонним лицам. |
| | | | |
| − | Чтобы решить эти проблемы и правильно разграничить доступ, нужно понимать, кто из сотрудников хочет выполнить действие (аутентификация) и может ли он это сделать (авторизация). | + | Чтобы решить эти проблемы и правильно разграничить доступ, нужно понимать, кто из сотрудников хочет выполнить действие (аутентификация) и может ли он это сделать (авторизация). |
| | | | |
| | [[Image:RBAC Схема 3.jpg|thumb|450px|center]] | | [[Image:RBAC Схема 3.jpg|thumb|450px|center]] |
| Строка 32: |
Строка 32: |
| | Самой сложной является проблема авторизации. Существует несколько подходов к ее решению, но наибольшее распространение на сегодняшний день получил контроль на основе ролей (role-based access control, RBAC). | | Самой сложной является проблема авторизации. Существует несколько подходов к ее решению, но наибольшее распространение на сегодняшний день получил контроль на основе ролей (role-based access control, RBAC). |
| | | | |
| − | === Role-based access control (RBAC) === | + | === Role-based access control (RBAC) === |
| | | | |
| | Суть подхода заключается в создании ролей, повторяющих бизнес-роли в компании, и присваивание их пользователям. На основе этих ролей проверяется возможность выполнения пользователем того или иного действия. | | Суть подхода заключается в создании ролей, повторяющих бизнес-роли в компании, и присваивание их пользователям. На основе этих ролей проверяется возможность выполнения пользователем того или иного действия. |
| Строка 42: |
Строка 42: |
| | [[Image:RBAC Схема 5.jpg|thumb|450px|center]] | | [[Image:RBAC Схема 5.jpg|thumb|450px|center]] |
| | | | |
| − | Но бизнес-правила неизбежно усложняются и становятся многомерными. Это приводит к тому, что одного атрибута (роли) для выражения бизнес-правил становится недостаточно и начинают добавляться другие атрибуты (город, страна, филиал, день недели, владелец, лимит). | + | Но бизнес-правила неизбежно усложняются и становятся многомерными. Это приводит к тому, что одного атрибута (роли) для выражения бизнес-правил становится недостаточно и начинают добавляться другие атрибуты (город, страна, филиал, день недели, владелец, лимит). |
| | | | |
| | Чтобы справиться с этой сложностью, необходимо создавать дополнительные роли, число которых равно числу различных комбинаций всех атрибутов. | | Чтобы справиться с этой сложностью, необходимо создавать дополнительные роли, число которых равно числу различных комбинаций всех атрибутов. |
| Строка 50: |
Строка 50: |
| | [[Image:RBAC Схема 7.jpg|thumb|450px|center]] | | [[Image:RBAC Схема 7.jpg|thumb|450px|center]] |
| | | | |
| − | После каждого добавления нового значения атрибута придется добавлять новые роли. То есть, если появится филиал «Г», придется добавить новые роли, такие как "Администратор филиала «Г», "Менеджер филиала «Г», "Бухгалтер филиала «Г» и т. п., после чего присвоить всем требуемым сотрудникам новые роли. Все это порождает много рутинного ручного труда. | + | После каждого добавления нового значения атрибута придется добавлять новые роли. То есть, если появится филиал «Г», придется добавить новые роли, такие как "Администратор филиала «Г», "Менеджер филиала «Г», "Бухгалтер филиала «Г» и т. п., после чего присвоить всем требуемым сотрудникам новые роли. Все это порождает много рутинного ручного труда. |
| | | | |
| | Кроме этого, появляются и другие проблемы: | | Кроме этого, появляются и другие проблемы: |
| | | | |
| − | * одно бизнес-правило «размазывается» среди множества ролей и становится неочевидным, что усложняет понимание такого правила и его поддержку; | + | * одно бизнес-правило «размазывается» среди множества ролей и становится неочевидным, что усложняет понимание такого правила и его поддержку; |
| | | | |
| − | * начинается взрывной рост числа ролей, что значительно усложняет управление ими. | + | * начинается взрывной рост числа ролей, что значительно усложняет управление ими. |
| | | | |
| − | А бизнес-правила, в которых используются атрибуты, значения которых заранее не известны и вычисляются в процессе работы, вообще невозможно выразить с помощью ролевой модели. | + | А бизнес-правила, в которых используются атрибуты, значения которых заранее не известны и вычисляются в процессе работы, вообще невозможно выразить с помощью ролевой модели. |
| | | | |
| | [[Image:RBAC Схема 8.jpg|thumb|450px|center]] | | [[Image:RBAC Схема 8.jpg|thumb|450px|center]] |
| Строка 66: |
Строка 66: |
| | [[Image:RBAC Схема 9.jpg|thumb|450px|center]] | | [[Image:RBAC Схема 9.jpg|thumb|450px|center]] |
| | | | |
| − | Чтобы реализовать поддержку таких бизнес-правил, придется использовать другие инструменты, что только удорожает и усложняет внедрение и сопровождение системы контроля доступа. | + | Чтобы реализовать поддержку таких бизнес-правил, придется использовать другие инструменты, что только удорожает и усложняет внедрение и сопровождение системы контроля доступа. |
| | | | |
| − | Получается, что как только бизнес-правила становятся многомерными или требуют контроля данных, ролевая модель не только не решает текущие проблемы контроля доступа, но и создает новые. | + | Получается, что как только бизнес-правила становятся многомерными или требуют контроля данных, ролевая модель не только не решает текущие проблемы контроля доступа, но и создает новые. |
| | | | |
| − | === Attribute-based access control (ABAC) === | + | === Attribute-based access control (ABAC) === |
| | | | |
| − | Чтобы справиться с нерешаемыми в рамках RBAC проблемами, был создан другой подход, который основывается на атрибутах. | + | Чтобы справиться с нерешаемыми в рамках RBAC проблемами, был создан другой подход, который основывается на атрибутах. |
| | | | |
| − | Основное отличие этого подхода в том, что каждая ситуация оценивается не с точки зрения роли пользователя и действия, которое он хочет совершить, а с точки зрения атрибутов, которые к ним относятся. | + | Основное отличие этого подхода в том, что каждая ситуация оценивается не с точки зрения роли пользователя и действия, которое он хочет совершить, а с точки зрения атрибутов, которые к ним относятся. |
| | | | |
| | Бизнес-правило, по сути, представляет собой набор условий, в которых различные атрибуты должны удовлетворять предъявляемым к ним требованиям. | | Бизнес-правило, по сути, представляет собой набор условий, в которых различные атрибуты должны удовлетворять предъявляемым к ним требованиям. |
| Строка 82: |
Строка 82: |
| | [[Image:RBAC Схема 10.jpg|thumb|450px|center]] | | [[Image:RBAC Схема 10.jpg|thumb|450px|center]] |
| | | | |
| − | Для выполнения авторизации значения всех атрибутов берутся в момент проверки прав и сравниваются с ожидаемыми значениями. Выполнение всех условий обеспечивает доступ к ресурсу. | + | Для выполнения авторизации значения всех атрибутов берутся в момент проверки прав и сравниваются с ожидаемыми значениями. Выполнение всех условий обеспечивает доступ к ресурсу. |
| | | | |
| | Простые правила описываются простыми условиями. | | Простые правила описываются простыми условиями. |
| Строка 92: |
Строка 92: |
| | [[Image:RBAC Схема 12.jpg|thumb|450px|center]] | | [[Image:RBAC Схема 12.jpg|thumb|450px|center]] |
| | | | |
| − | При добавлении новых значений атрибутов условия бизнес-правила меняться не будут. То есть если появится филиал «Г», в условиях бизнес-правила ничего менять не придется. Все, что потребуется, — это добавить нужным сотрудникам значение атрибута «Филиал» — «Филиал «Г». | + | При добавлении новых значений атрибутов условия бизнес-правила меняться не будут. То есть если появится филиал «Г», в условиях бизнес-правила ничего менять не придется. Все, что потребуется, — это добавить нужным сотрудникам значение атрибута «Филиал» — «Филиал «Г». |
| | | | |
| | Таким образом, ABAC позволяет избежать проблем, которые появляются в RBAC: | | Таким образом, ABAC позволяет избежать проблем, которые появляются в RBAC: |
| | | | |
| − | * бизнес-правило не «размазывается» по системе, что делает его понимание и поддержку достаточно простыми; | + | * бизнес-правило не «размазывается» по системе, что делает его понимание и поддержку достаточно простыми; |
| − | * не происходит взрывного роста числа условий, что упрощает их сопровождение. | + | * не происходит взрывного роста числа условий, что упрощает их сопровождение. |
| | | | |
| − | Но самое главное, ABAC позволяет решить проблемы, которые невозможно решить с помощью RBAC, поскольку в этом подходе нет ограничений на сложность бизнес-правил. | + | Но самое главное, ABAC позволяет решить проблемы, которые невозможно решить с помощью RBAC, поскольку в этом подходе нет ограничений на сложность бизнес-правил. |
| | | | |
| − | Бизнес-правила любой сложности, в том числе с использованием заранее неизвестных атрибутов, не создают новых проблем и просты в сопровождении. | + | Бизнес-правила любой сложности, в том числе с использованием заранее неизвестных атрибутов, не создают новых проблем и просты в сопровождении. |
| | | | |
| | [[Image:RBAC Схема 13.jpg|thumb|450px|center]] | | [[Image:RBAC Схема 13.jpg|thumb|450px|center]] |
| | | | |
| − | Представления бизнес-правила в виде набора условий удобно использовать для фильтрации данных. Часть условий можно вычислить еще до обращения к ресурсу, а оставшиеся условия становятся фильтром для выбора данных. | + | Представления бизнес-правила в виде набора условий удобно использовать для фильтрации данных. Часть условий можно вычислить еще до обращения к ресурсу, а оставшиеся условия становятся фильтром для выбора данных. |
| | | | |
| | [[Image:RBAC Схема 14.jpg|thumb|450px|center]] | | [[Image:RBAC Схема 14.jpg|thumb|450px|center]] |
| | | | |
| − | Первые три условия можно проверить еще до обращения к данным. А последнее условие можно использовать в качестве предиката для получения только разрешенных данных. | + | Первые три условия можно проверить еще до обращения к данным. А последнее условие можно использовать в качестве предиката для получения только разрешенных данных. |
| | | | |
| − | === Сравнение ABAC и RBAC === | + | === Сравнение ABAC и RBAC === |
| | | | |
| | [[Image:RBAC Схема 15.jpg|thumb|450px|center]] | | [[Image:RBAC Схема 15.jpg|thumb|450px|center]] |
| | | | |
| − | Как видно из сравнения, RBAC хорошо подходит только для реализации простых бизнес-правил. С увеличением сложности правил целесообразность использования RBAC уменьшается из-за растущей стоимости поддержки системы контроля доступа, а начиная с определенного уровня сложности правил этот подход вообще не дает результата. | + | Как видно из сравнения, RBAC хорошо подходит только для реализации простых бизнес-правил. С увеличением сложности правил целесообразность использования RBAC уменьшается из-за растущей стоимости поддержки системы контроля доступа, а начиная с определенного уровня сложности правил этот подход вообще не дает результата. |
| | | | |
| − | ABAC, в свою очередь, не ограничивает сложность бизнес-правил. Благодаря более понятному бизнесу и компактному выражению этот подход позволяет не увеличивать стоимость поддержки при реализации более сложных правил, а также дает возможность обеспечивать контроль доступа не только к действиям, но и к данным. | + | ABAC, в свою очередь, не ограничивает сложность бизнес-правил. Благодаря более понятному бизнесу и компактному выражению этот подход позволяет не увеличивать стоимость поддержки при реализации более сложных правил, а также дает возможность обеспечивать контроль доступа не только к действиям, но и к данным. |
| | | | |
| | === Полезные ссылки === | | === Полезные ссылки === |
| Строка 135: |
Строка 135: |
| | [[Категория:Евгений Мяченков (Статьи)]] | | [[Категория:Евгений Мяченков (Статьи)]] |
| | [[Категория:Хабрахабр (Публикации)]] | | [[Категория:Хабрахабр (Публикации)]] |
| − |
| |
| | [[Категория:2015 год (Статьи)]] | | [[Категория:2015 год (Статьи)]] |
| | | | |
| | {{replicate-from-custiswiki-to-lib}} | | {{replicate-from-custiswiki-to-lib}} |
Когда компания состоит из одного человека, то внутренних секретов в ней нет. Единственному сотруднику доступны любые действия и любая информация.
Если компания успешна и объемы работы растут, то наступает момент, когда один человек перестает справляться. И тогда в компанию нанимаются новые сотрудники.
Но когда число сотрудников в компании увеличивается, появляются другие проблемы, например:
Чтобы решить эти проблемы и правильно разграничить доступ, нужно понимать, кто из сотрудников хочет выполнить действие (аутентификация) и может ли он это сделать (авторизация).
Самой сложной является проблема авторизации. Существует несколько подходов к ее решению, но наибольшее распространение на сегодняшний день получил контроль на основе ролей (role-based access control, RBAC).
Суть подхода заключается в создании ролей, повторяющих бизнес-роли в компании, и присваивание их пользователям. На основе этих ролей проверяется возможность выполнения пользователем того или иного действия.
Если бизнес-правила одномерны и все действия можно разбить по ролям (бухгалтер, менеджер, администратор и т. п.), такого подхода будет достаточно. Тогда одному бизнес-правилу будет соответствовать одна роль.
Но бизнес-правила неизбежно усложняются и становятся многомерными. Это приводит к тому, что одного атрибута (роли) для выражения бизнес-правил становится недостаточно и начинают добавляться другие атрибуты (город, страна, филиал, день недели, владелец, лимит).
Чтобы справиться с этой сложностью, необходимо создавать дополнительные роли, число которых равно числу различных комбинаций всех атрибутов.
После каждого добавления нового значения атрибута придется добавлять новые роли. То есть, если появится филиал «Г», придется добавить новые роли, такие как "Администратор филиала «Г», "Менеджер филиала «Г», "Бухгалтер филиала «Г» и т. п., после чего присвоить всем требуемым сотрудникам новые роли. Все это порождает много рутинного ручного труда.
А бизнес-правила, в которых используются атрибуты, значения которых заранее не известны и вычисляются в процессе работы, вообще невозможно выразить с помощью ролевой модели.
Существуют также бизнес-правила, которые ограничивают доступ не к действиям, а к данным. Такие бизнес-правила также невозможно выразить с помощью ролевой модели.
Чтобы реализовать поддержку таких бизнес-правил, придется использовать другие инструменты, что только удорожает и усложняет внедрение и сопровождение системы контроля доступа.
Получается, что как только бизнес-правила становятся многомерными или требуют контроля данных, ролевая модель не только не решает текущие проблемы контроля доступа, но и создает новые.
Чтобы справиться с нерешаемыми в рамках RBAC проблемами, был создан другой подход, который основывается на атрибутах.
Основное отличие этого подхода в том, что каждая ситуация оценивается не с точки зрения роли пользователя и действия, которое он хочет совершить, а с точки зрения атрибутов, которые к ним относятся.
Бизнес-правило, по сути, представляет собой набор условий, в которых различные атрибуты должны удовлетворять предъявляемым к ним требованиям.
Для выполнения авторизации значения всех атрибутов берутся в момент проверки прав и сравниваются с ожидаемыми значениями. Выполнение всех условий обеспечивает доступ к ресурсу.
При добавлении новых значений атрибутов условия бизнес-правила меняться не будут. То есть если появится филиал «Г», в условиях бизнес-правила ничего менять не придется. Все, что потребуется, — это добавить нужным сотрудникам значение атрибута «Филиал» — «Филиал «Г».
Но самое главное, ABAC позволяет решить проблемы, которые невозможно решить с помощью RBAC, поскольку в этом подходе нет ограничений на сложность бизнес-правил.
Бизнес-правила любой сложности, в том числе с использованием заранее неизвестных атрибутов, не создают новых проблем и просты в сопровождении.
Представления бизнес-правила в виде набора условий удобно использовать для фильтрации данных. Часть условий можно вычислить еще до обращения к ресурсу, а оставшиеся условия становятся фильтром для выбора данных.
Первые три условия можно проверить еще до обращения к данным. А последнее условие можно использовать в качестве предиката для получения только разрешенных данных.
Как видно из сравнения, RBAC хорошо подходит только для реализации простых бизнес-правил. С увеличением сложности правил целесообразность использования RBAC уменьшается из-за растущей стоимости поддержки системы контроля доступа, а начиная с определенного уровня сложности правил этот подход вообще не дает результата.
ABAC, в свою очередь, не ограничивает сложность бизнес-правил. Благодаря более понятному бизнесу и компактному выражению этот подход позволяет не увеличивать стоимость поддержки при реализации более сложных правил, а также дает возможность обеспечивать контроль доступа не только к действиям, но и к данным.
