Войти
Управление доступом на основе атрибутов (ABAC ), также известное как управление доступом на основе политик для IAM, определяет парадигму управления доступом, при которой права доступа предоставляются пользователям посредством использования политик, которые объединяют атрибуты вместе. Политики могут использовать любой тип атрибутов (атрибуты пользователя, атрибуты ресурсов, объекты, атрибуты среды и т. Д.). Эта модель поддерживает логическую логику, в которой правила содержат утверждения «ЕСЛИ, ТОГДА» о том, кто делает запрос, ресурс и действие. Например: ЕСЛИ инициатор запроса является менеджером, ТО разрешите доступ для чтения / записи к конфиденциальным данным. Структура NIST представляет основные концепции ABAC как его сущностей, то есть PAP (точка администрирования политики), PEP (точка применения политики), PDP (точка принятия решения) и PIP (точка информации о политике).
В отличие от роли управления доступом (RBAC), в котором используются предварительно определенные роли, которые несут определенный набор связанных с ними привилегий и которым назначены субъекты, ключевым отличием от ABAC является концепция политик, которые выражают сложный набор логических правил, который может оценить множество различных атрибутов. Значения атрибутов могут иметь многозначные или атомарные значения. Установленные атрибуты содержат более одного атомарного значения. Примеры - ролевые и проектные. Атрибуты с атомарными значениями содержат только одно атомарное значение. Примеры: зазор и чувствительность. Атрибуты можно сравнивать со статическими значениями или друг с другом, что позволяет управлять доступом на основе отношений.
Хотя сама концепция существовала много лет, ABAC считается моделью авторизации «следующего поколения», поскольку она обеспечивает динамический, контекстно-зависимый и интеллектуальный контроль доступа к ресурсам, позволяющий использовать политики контроля доступа, которые включают определенные атрибуты из необходимо определить множество различных информационных систем для разрешения авторизации и достижения эффективного соответствия нормативным требованиям, что позволит предприятиям гибко внедрять их на основе существующих инфраструктур.
Управление доступом на основе атрибутов иногда называют управлением доступом на основе политик (PBAC ) или управлением доступом на основе утверждений (CBAC ), это термин, специфичный для Microsoft. Ключевыми стандартами, реализующими ABAC, являются XACML и ALFA (XACML).
ABAC можно рассматривать как :
ABAC поставляется с рекомендуемой архитектурой, которая выглядит следующим образом:
Атрибуты могут относиться ко всему и обо всем. Они, как правило, делятся на 4 разные категории или функции (как в грамматической функции)
Политики - это утверждения, которые объединяют атрибуты, чтобы выразить то, что может произойти, а что не разрешено. Политики в ABAC могут предоставлять или отклонять политики. Политики также могут быть локальными или глобальными и могут быть написаны таким образом, чтобы переопределять другие политики. Примеры включают:
С ABAC у вас может быть столько политик, сколько вам нужно, которые подходят для множества различных сценариев и технологий.
Исторически сложилось так, что модели управления доступом включены обязательный контроль доступа (MAC), дискреционный контроль доступа (DAC) и, совсем недавно, управление доступом на основе ролей (RBAC). Эти модели управления доступом ориентированы на пользователя и не принимают во внимание дополнительные параметры, такие как информация о ресурсах, взаимосвязь между пользователем (запрашивающим объектом) и ресурсом, а также динамическую информацию, например время суток или IP пользователя. ABAC пытается решить эту проблему, определяя управление доступом на основе атрибутов, которые описывают запрашивающую сущность (пользователя), целевой объект или ресурс, желаемое действие (просмотр, редактирование, удаление...), а также информацию о среде или контексте. Вот почему говорят, что управление доступом основано на атрибутах.
Одним из стандартов, реализующих управление доступом на основе атрибутов и политик, является XACML, расширяемый язык разметки управления доступом. XACML определяет архитектуру, язык политики и схему запроса / ответа. Он не обрабатывает управление атрибутами (назначение атрибутов пользователя, назначение атрибутов объекта, назначение атрибутов среды), которое остается на усмотрение традиционных инструментов IAM, баз данных и каталогов.
Компании, включая все подразделения вооруженных сил США, начали использовать ABAC. На базовом уровне ABAC защищает данные с помощью правил «ЕСЛИ / ТО / И», а не назначает данные пользователям. Министерство торговли США сделало это обязательной практикой, и эта практика распространяется среди нескольких правительственных и военных ведомств. [1]
Концепция ABAC может применяться на любом уровне стек технологий и инфраструктура предприятия. Например, ABAC можно использовать на уровне межсетевого экрана, сервера, приложения, базы данных и данных. Использование атрибутов обеспечивает дополнительный контекст для оценки законности любого запроса на доступ и информирования о решении предоставить или запретить доступ.
Важным моментом при оценке решений ABAC является понимание их потенциальных накладных расходов на производительность и их влияния на взаимодействие с пользователем. Ожидается, что чем более детализированы элементы управления, тем выше накладные расходы.
ABAC может использоваться для применения детальной авторизации на основе атрибутов к методам или функциям API. Например, банковский API может предоставлять метод ApproveTransaction (transId). ABAC можно использовать для защиты вызова. С помощью ABAC автор политики может написать следующее:
Последовательность действий будет следующей:
Одним из ключевых преимуществ ABAC является то, что политики и атрибуты авторизации могут быть определены технологически нейтральным способом. Это означает, что политики, определенные для API или баз данных, можно повторно использовать в пространстве приложения. Общие приложения, которые могут извлечь выгоду из ABAC:
Тот же процесс и последовательность операций, что и тот, который описан в разделе API, применим и здесь.
Безопасность баз данных давно присуща только производителям баз данных: Oracle VPD, IBM FGAC и Microsoft RLS - все это средства для достижения детальной безопасности, подобной ABAC.
Примером может быть:
ролью == менеджерможет выполнить действие == SELECT для таблицы == TRANSACTIONS, если user.region == transaction.regionБезопасность данных обычно идет на шаг дальше безопасности базы данных и применяет управление непосредственно к элемент данных. Это часто называют безопасностью, ориентированной на данные. В традиционных реляционных базах данных политики ABAC могут управлять доступом к данным в таблице, столбце, поле, ячейке и подъячейке, используя логические элементы управления с условиями фильтрации и маскированием на основе атрибутов. Атрибуты могут быть данными, пользователем, сеансом или инструментами, основанными на обеспечении максимального уровня гибкости при динамическом предоставлении / отказе в доступе к определенному элементу данных. В отношении больших данных и распределенных файловых систем, таких как Hadoop, ABAC, применяемый на уровне данных, контролирует доступ к папке, подпапке, файлу, суб-файлу и другим элементам.
Управление доступом на основе атрибутов также может применяться к системам больших данных, таким как Hadoop. При извлечении данных из озер данных могут применяться политики, аналогичные тем, которые использовались ранее.
Начиная с Windows Server 2012, Microsoft реализовала подход ABAC для управления доступом к файлам и папкам.. Это достигается с помощью динамических списков управления доступом (DACL) и языка определения дескрипторов безопасности (SDDL). SDDL можно рассматривать как язык ABAC, поскольку он использует метаданные пользователя (утверждения) и файла / папки для управления доступом.
