Контроль доступа на основе атрибутов - Attribute-based access control

Контроль доступа на основе атрибутов (ABAC), также известный как управление доступом на основе политик за Я, определяет парадигму управления доступом, при которой права доступа предоставляются пользователям посредством использования политик, которые объединяют атрибуты вместе.[1] Политики могут использовать любой тип атрибутов (атрибуты пользователя, атрибуты ресурсов, объекты, атрибуты среды и т. Д.). Эта модель поддерживает булеву логику, в которой правила содержат утверждения «IF, THEN» о том, кто делает запрос, ресурс и действие. Например: ЕСЛИ инициатор запроса является менеджером, ТО разрешите доступ для чтения / записи к конфиденциальным данным. Структура NIST представляет основные концепции ABAC как его сущностей, то есть PAP (точка администрирования политики), PEP (точка применения политики), PDP (точка принятия решения) и PIP (точка информации о политике).[2][3]

В отличие от управления доступом на основе ролей (RBAC), в котором используются предварительно определенные роли, которые несут определенный набор связанных с ними привилегий и которым назначены субъекты, ключевым отличием от ABAC является концепция политик, которые выражают сложный набор логических правил. который может оценивать множество различных атрибутов. Значения атрибутов могут иметь многозначные или атомарные значения. Установленные атрибуты содержат более одного атомарного значения. Примеры роль и проект. Атрибуты с атомарными значениями содержат только одно атомарное значение. Примеры: зазор и чувствительность. Атрибуты можно сравнивать со статическими значениями или друг с другом, что позволяет управлять доступом на основе отношений.

Хотя сама концепция существовала в течение многих лет, ABAC считается моделью авторизации «следующего поколения», поскольку она обеспечивает динамический, контекстно-зависимый и интеллектуальный контроль доступа к ресурсам, позволяя использовать политики контроля доступа, которые включают определенные атрибуты из многих различных информационных систем. определены для разрешения авторизации и достижения эффективного соответствия нормативным требованиям, что позволяет предприятиям гибко внедрять решения на основе существующих инфраструктур.

Контроль доступа на основе атрибутов иногда называют управление доступом на основе политик (PBAC) или же управление доступом на основе утверждений (CBAC), который является специфическим термином Microsoft. Ключевые стандарты, которые реализуют ABAC: XACML и ALFA (XACML).[4]

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

ABAC можно рассматривать как:

  • Управление внешней авторизацией[5]
  • Динамическое управление авторизацией[6]
  • Контроль доступа на основе политик
  • Детальная авторизация

Составные части

Архитектура

ABAC поставляется с рекомендуемой архитектурой, которая выглядит следующим образом:

  1. PEP или точка применения политики: она отвечает за защиту приложений и данных, к которым вы хотите применить ABAC. PEP проверяет запрос и генерирует из него запрос на авторизацию, который отправляет PDP.
  2. PDP или точка принятия решения о политике - это мозг архитектуры. Это компонент, который оценивает входящие запросы по политикам, с которыми он был настроен. PDP возвращает решение о разрешении / отказе. PDP может также использовать PIP для получения недостающих метаданных.
  3. PIP или точка информации о политике связывает PDP с внешними источниками атрибутов, например LDAP или базы данных.

Атрибуты

Атрибуты могут относиться ко всему и к кому угодно. Они, как правило, делятся на 4 категории:

  1. Атрибуты субъекта: атрибуты, которые описывают пользователя, пытающегося получить доступ, например возраст, допуск, отдел, роль, должность ...
  2. Атрибуты действия: атрибуты, описывающие предпринимаемое действие, например читать, удалять, просматривать, утверждать ...
  3. Атрибуты объекта: атрибуты, которые описывают объект (или ресурс), к которому осуществляется доступ, например тип объекта (медицинская карта, банковский счет ...), отделение, классификация или чувствительность, местонахождение ...
  4. Контекстные (средовые) атрибуты: атрибуты, которые имеют дело со временем, местоположением или динамическими аспектами сценария управления доступом.[7]

Политики

Политики - это утверждения, которые объединяют атрибуты, чтобы выразить то, что может случиться, а что не разрешено. Политики в ABAC могут предоставлять или отклонять политики. Политики также могут быть локальными или глобальными и могут быть написаны таким образом, чтобы переопределять другие политики. Примеры включают:

  1. Пользователь может просматривать документ, если документ находится в том же отделе, что и пользователь.
  2. Пользователь может редактировать документ, если он является владельцем и если документ находится в режиме черновика
  3. Запретить доступ до 9 утра

С ABAC у вас может быть столько политик, сколько вам нужно, для множества различных сценариев и технологий.[7]

Другие модели

Исторически модели контроля доступа включали принудительный контроль доступа (MAC), дискреционный контроль доступа (DAC), а совсем недавно управление доступом на основе ролей (RBAC). Эти модели управления доступом ориентированы на пользователя и не принимают во внимание дополнительные параметры, такие как информация о ресурсах, взаимосвязь между пользователем (запрашивающим объектом) и ресурсом, а также динамическую информацию, например время дня или IP-адрес пользователя. ABAC пытается решить эту проблему, определяя управление доступом на основе атрибутов, которые описывают запрашивающий объект (пользователя), целевой объект или ресурс, желаемое действие (просмотр, редактирование, удаление ...), и экологическая или контекстная информация. Вот почему говорят, что управление доступом основано на атрибутах.

Реализации

Одним из стандартов, реализующих управление доступом на основе атрибутов и политик, является XACML, расширяемый язык разметки контроля доступа. XACML определяет архитектуру, язык политики и схему запроса / ответа. Он не обрабатывает управление атрибутами (назначение атрибутов пользователя, назначение атрибутов объекта, назначение атрибутов среды), которое оставлено традиционным Я инструменты, базы данных и каталоги.

Компании, включая все подразделения вооруженных сил США, начали использовать ABAC. На базовом уровне ABAC защищает данные с помощью правил «ЕСЛИ / ТО / И», а не назначает данные пользователям. Министерство торговли США сделало это обязательной практикой, и принятие распространяется среди нескольких правительственных и военных ведомств.[1][8]

Приложения

Концепция ABAC может применяться на любом уровне технологического стека и инфраструктуры предприятия. Например, ABAC можно использовать на уровне межсетевого экрана, сервера, приложения, базы данных и данных. Использование атрибутов обеспечивает дополнительный контекст для оценки законности любого запроса на доступ и информирования о решении предоставить или запретить доступ.

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

Безопасность API и микросервисов

ABAC можно использовать для применения детальной авторизации на основе атрибутов к методам или функциям API. Например, банковский API может предоставлять метод ApproveTransaction (transId). ABAC можно использовать для защиты вызова. С помощью ABAC автор политики может написать следующее:

  • Политика: менеджеры могут утверждать транзакции до их лимита утверждения
  • Используемые атрибуты: роль, идентификатор действия, тип объекта, сумма, лимит утверждения.

Поток будет следующим:

  1. Пользователь Алиса вызывает метод API ApproveTransaction (123).
  2. API принимает вызов и аутентифицирует пользователя.
  3. Перехватчик в API обращается к механизму авторизации (обычно называемому точкой принятия решения или PDP) и спрашивает: Может ли Алиса одобрить транзакцию 123?
  4. PDP получает политику ABAC и необходимые атрибуты.
  5. PDP принимает решение, например, Разрешить или запретить и возвращает его перехватчику API
  6. Если принято решение «Разрешить», вызывается базовая бизнес-логика API. В противном случае API возвращает ошибку или отказано в доступе.

Безопасность приложений

Одним из ключевых преимуществ ABAC является то, что политики и атрибуты авторизации могут быть определены технологически нейтральным способом. Это означает, что политики, определенные для API или баз данных, можно повторно использовать в пространстве приложения. Общие приложения, которые могут извлечь выгоду из ABAC:

  1. системы управления контентом
  2. ERP
  3. домашние приложения
  4. веб-приложения

Здесь также применяется тот же процесс и последовательность, что и описанные в разделе API.

Безопасность базы данных

Безопасность баз данных уже давно присуща только производителям баз данных: Oracle VPD, IBM FGAC и Microsoft RLS - все это средства для достижения детальной безопасности, подобной ABAC.

Примером может быть:

  • Политика: менеджеры могут просматривать транзакции в своем регионе
  • Переработанная политика с ориентацией на данные: пользователи с роль == менеджер может сделать действие == ВЫБРАТЬ в таблице == ТРАНЗАКЦИИ, если user.region == transaction.region

Безопасность данных

Безопасность данных обычно идет на шаг дальше, чем безопасность базы данных, и применяет управление непосредственно к элементу данных. Это часто называют безопасностью, ориентированной на данные. В традиционных реляционных базах данных политики ABAC могут управлять доступом к данным в таблице, столбце, поле, ячейке и подъячейке, используя логические элементы управления с условиями фильтрации и маскированием на основе атрибутов. Атрибуты могут быть данными, пользователем, сеансом или инструментами, обеспечивающими максимальный уровень гибкости при динамическом предоставлении / отказе в доступе к определенному элементу данных. В отношении больших данных и распределенных файловых систем, таких как Hadoop, ABAC, применяемый на уровне данных, управляет доступом к папке, подпапке, файлу, суб-файлу и другим элементам.

Безопасность больших данных

Управление доступом на основе атрибутов также может применяться к системам больших данных, таким как Hadoop. Политики, аналогичные тем, которые использовались ранее, могут применяться при извлечении данных из озер данных.[9][10]

Безопасность файлового сервера

Начиная с Windows Server 2012, Microsoft реализовала подход ABAC для управления доступом к файлам и папкам. Это достигается с помощью динамических списков управления доступом (DACL) и языка определения дескрипторов безопасности (SDDL). SDDL можно рассматривать как язык ABAC, поскольку он использует метаданные пользователя (утверждения) и файла / папки для управления доступом.

Смотрите также

Рекомендации

  1. ^ Отдел компьютерной безопасности, Лаборатория информационных технологий (2016-05-24). «Управление доступом на основе атрибутов | CSRC | CSRC». CSRC | NIST. Получено 2020-11-22.
  2. ^ NIST, ABAC (2014). «Руководство по определению и соображениям контроля доступа на основе атрибутов (ABAC)» (PDF).
  3. ^ NIST (2016). «Сравнение стандартов управления доступом на основе атрибутов (ABAC) для приложений службы данных» (PDF).
  4. ^ Сильва, Эдельберто Франко; Мучалуат-Сааде, Дебора Кристина; Фернандес, Наталья Кастро (01.01.2018). «ACROSS: общая структура для управления доступом на основе атрибутов с распределенными политиками для виртуальных организаций». Компьютерные системы будущего поколения. 78: 1–17. Дои:10.1016 / j.future.2017.07.049. ISSN  0167-739X.
  5. ^ «Обзор технологии для управления внешней авторизацией». www.gartner.com. Получено 2017-05-31.
  6. ^ «Компас лидерства: динамическое управление авторизацией - 71144». КуппингерКоул. Получено 2020-07-14.
  7. ^ а б «Альтернативы системам контроля доступа к ролям / претензиям». stackoverflow.com.
  8. ^ Коффи, Алиса (2019-03-28). «Управление доступом на основе атрибутов (ABAC) - Шифрование на стероидах». Сообщество Siemens PLM. Получено 2019-04-01.
  9. ^ «Динамическая детализированная авторизация защищает большие данные».
  10. ^ «Первый детализированный контроль доступа к данным на Hadoop».

внешняя ссылка