CC BY
113
Анализ возможностей языка XACML
по управлению доступом
О.Р. Лапонина, МГУ им. Ломоносова, ф-т ВМК, научный сотрудник, [email protected]
Аннотация
В работе выполнен анализ возможностей языка eXtensible Access Control Markup Language (XACML). Определены основные требования к языку описания политик доступа к сетевым ресурсам. Рассмотрен подход XACML к обеспечению безопасности и архитектура языка XACML. Описаны основные термины, используемые в языке XACML. Описаны алгоритмы комбинирования политик и набора политик. Рассмотрены типы компонент, обеспечивающих реализацию управления доступом -Policy Enforcement Point (PEP) и принятия решения о доступе - Policy Decision Point (PDP).
Базовые понятия и актуальность
Производители ПО создают программные продукты с самыми разными функциями, которые могут использоваться для самых разных целей. По умолчанию эти продукты имеют максимально возможные привилегии по доступу к данным и выполнению ПО. Это дает возможность использовать их в максимально большом количестве окружений, включая те, в которых нет жестких требований к политике безопасности. Если необходима политика безопасности, ограничивающая привилегии, которые были установлены по умолчанию, для каждого приложения должно быть выполнено собственное конфигурирование.
Политика безопасности большого предприятия может иметь много компонентов и много точек, в которых она должна применяться. Компоненты политики могут определяться отделом информационных систем, отделом кадров, юридическим или финансовым отделами. Политика безопасности может определяться для локальной сети, почты, доступа в Интернет, систем удаленного доступа и других приложений, каждое из которых имеет свои собственные конфигурационные параметры и принципы конфигурирования.
Текущая практика состоит в том, чтобы в каждом случае управлять конфигурацией независимо, реализуя соответствующую политику безопасности. В этом случае невозможно иметь общий взгляд на политику безопасности. В то же время существует возрастающее желание потребителей продемонстрировать им «best practice» по защите информационных ценностей.
Поэтому существует необходимость в разработке общего языка описания политики безопасности. Естественным выбором для такого языка является XML.
Язык написания политики безопасности информационной системы должен обеспечивать следующие возможности:
• Предоставлять возможность комбинирования отдельных правил и
политик в одно множество политик, которое будет применяться при каждом запросе о возможности предоставления доступа.
• Предоставлять возможность нескольких способов комбинирования
правил и политик.
• Предоставлять возможность определять атрибуты для различных
элементов правил.
• Предоставлять множество логических и математических операторов
над атрибутами субъекта, ресурса и окружения.
Подход XACML к управлению доступом
Рис. 5. Принципы управления доступом с использованием XACML
Язык eXtensible Access Control Markup Language (XACML) определяет PEP (Policy Enforcement Point) и PDP (Policy Decision Point) в
качестве основных компонент, обеспечивающих реализацию управления доступом.
Любой запрос доступа пользователя к ресурсу должен прерываться системной сущностью, называемой Policy Enforcement Point (PEP).
PEP создает запрос в формате XACML и посылает его PDP.
Policy Decision Point (PDP) - системная сущность, которая принимает решение о доступе на основе политики безопасности. Решением о доступе может быть «Разрешено», «Запрещено», «Не определено» и множество обязательств (obligations), которые должен выполнить РЕР вместе с выполнением решения о доступе.
Политика (Policy) - это множество Правил (Rule), алгоритмов комбинирования правил и политик и, возможно, множество обязательств. Политика может быть компонентом других политик. Правило состоит из Цели, Результата и Условия и является компонентом политики. Каждый элемент правила может иметь Атрибуты, которые хранятся в хранилище, называемом Policy Information Point (PIP).
РЕР выполняет управление доступом, основываясь на ответах, полученных от PDP. РЕР может быть реализован в виде единого целого с приложением, существовать как отдельный объект в том же контейнере, что и защищаемое приложение, или быть доступным в виде сетевого ресурса.
Для описания процесса создания правил и политик вводится понятие Точки администрирования политики (Policy Administration Point - PAP) - системной сущности, с помощью которой создается одна или несколько политик.
Для преобразования запросов в исходном формате к формату XACML и конвертировании решения по авторизации в формат XACML к исходному формату запроса вводится понятие Обработчика запросов (Context handler).
Потоки данных между системными сущностями, участвующими в принятии решения, показаны на рисунке 2 (см [1]).
Рис. 6. Модель потока данных
Принципы управления доступом следующие:
133.РАР создает политики, определяет алгоритмы комбинирования политик и делает их доступными для PDP. Эти политики должны быть предназначены для конкретных целей и созданы заранее.
134. Приложение посылает запрос на доступ к РЕР.
135.РЕР посылает запрос на доступ к обработчику запросов в формате, который определен в приложении, возможно добавляя атрибуты субъектов, ресурса, действия и окружения.
136. Обработчик создает запрос в формате XACML и посылает его к PDP.
137.PDP запрашивает любые дополнительные атрибуты субъекта, ресурса, действия и окружения от обработчика контекста.
138. Обработчик перенаправляет запрос атрибутов к PIP.
139.PIP получает запрошенные атрибуты, возможно из различных источников.
140.PIP возвращает запрошенные атрибуты обработчику.
141. Обработчик может добавить содержимое ресурса.
142. Обработчик посылает запрошенные атрибуты и, возможно, ресурс к PDP. PDP оценивает политику.
143.PDP возвращает ответ, содержащий решение о возможности доступа обработчику.
144. Обработчик преобразует ответ в исходный формат, полученный от РЕР и возвращает его РЕР.
145.РЕР обеспечивает управление доступом и выполнение обязательств.
Типы РЕР
Различают следующие типы РЕР:
Базовый РЕР
146. Если решение в ответе PDP «Permit», то РЕР должен разрешить доступ. Если решение сопровождает обязательство, то РЕР должен разрешить доступ, только если он понимает и может выполнить это обязательство.
147.Если решение в ответе PDP «Deny», то РЕР должен запретить доступ. Если решение сопровождает обязательство, то РЕР должен запретить доступ, только если он понимает и может выполнить это обязательство.
148.Если решение в ответе PDP «Не применимо», то поведение РЕР не определено.
149.Если решение в ответе PDP «Не определено», то поведение РЕР не определено.
Основанный на Deny РЕР
Отличается от базового РЕР тем, что если РЕР не понимает какое-либо из обязательств, или ответ от РЕР «Не применимо» или «Не определено», то доступ запрещается.
Основанный на Permit РЕР
Отличается от базового РЕР тем, что доступ запрещается только в том случае, если ответ PDP есть «Deny», во всех остальных случаях доступ разрешен.
Комбинирование Правил и Политик
Политика, применяемая к конкретному запросу о возможности доступа, может быть составлена из нескольких правил и политик. Например, владелец персональной информации может определить одни условия доступа, а организация, в которой он работает, может определить другие условия доступа. Следовательно, необходимо иметь возможность комбинировать несколько отдельных политик для создания единой политики, применяемой к запросу.
XACML определяет три элемента верхнего уровня: <Rule>, <Policy>, <PolicySet>. Элемент <Rule> содержит булевское выражение, которое
может быть вычислено самостоятельно. Предполагается, что <Rule> существует только как базовый элемент в элементах <Policy> и <PolicySet>, и, следовательно, существует только в PAP, где он может являться основным блоком управления и повторно использоваться в нескольких политиках.
Элемент <Policy> содержит множество элементов <Rule> и определяет способ их комбинирования. Он является базовым блоком политики, используемой PDP, и таким образом предполагается, что он формирует основу для решения по авторизации.
Элемент <PolicySet> содержит множество элементов <Policy> или других <PolicySet> и определяет способ их комбинирования.
XACML определяет несколько алгоритмов комбинирования, которые определяются атрибутами RuleCombiningAlgId или PolicyCombiningAlgId в элементах <Policy> или <PolicySet> соответственно. Алгоритм комбинирования правила определяет процедуру принятия решения по авторизации на основании решения о доступе, которое принимает отдельное правило или политика в множестве. Стандартными алгоритмами комбинирования являются: 36. Deny-перекрывает. Если существует хотя бы один элемент <Rule> или <Policy>, возвращающий «Deny», то результат будет «Deny».
11. Permit-перекрывает. Если существует хотя бы один элемент, возвращающий «Permit», то результат будет «Permit».
12. Применяется первый. Результат тот же самый, что и результат первого элемента в списке правил, чья цель соответствует цели в запросе решения.
13. Применяется только один. Данный алгоритм комбинирования используется только в политиках. Результат этого алгоритма комбинирования гарантирует, что существует только одна политика или набор политик, применимая к данной цели. Если никакой политики или набора политик не существует, то результат есть «Не применимо».
Допускается определение своего собственного алгоритма комбинирования правил и политик.
Политики управления доступом могут содержать ссылки на несколько субъектов. Например, политика управления выполнением финансовых транзакций может требовать одобрения нескольких индивидуумов, имеющих определенные компетенции. Для этого в XACML допускается наличие более одного субъекта, относящегося к запросу решения. Возможно определение атрибутов типа «категория субъекта», используемых для того, чтобы отличить типы субъектов, действующих с разными полномочиями. Определены некоторые стандартные значе-
ния для данного атрибута, пользователи могут определить дополнительные значения.
Определение доступа на основе атрибутов субъекта и ресурса
Другое общее требование состоит в том, что решение по авторизации может быть основано на некоторых характеристиках субъекта, отличных от его идентификации. Наиболее общим описанием этой идеи является подход, определенный в RBAC. XACML предоставляет возможности для поддержки данного подхода.
XACML предоставляет способ указывать атрибуты, определенные в спецификациях LDAP. Считается, что производители будут использовать стандартные идентификаторы атрибутов для наиболее часто используемых атрибутов субъектов.
Другим требованием является то, что решение по авторизации может быть основано на некоторых характеристиках ресурса, а не его идентификации. XACML также предоставляет возможность поддерживать данный подход. Значение атрибутов сожжет быть указано как в виде URN, так и в виде выражения XPath.
Атрибуты, имеющие несколько значений
Большинство атрибутов LDAP, XPath, SAML и т.п. может иметь нескольких значений. Следовательно, PDP может получать на свой запрос несколько значений атрибута. Набор таких значений называется мешок (bag). Мешок отличается от набора тем, что он может содержать дублирующие значения, в то время как набор не может. В некоторых случаях данная ситуация должна считаться ошибкой.
XACML предоставляет набор функций, которые позволяют создавать политики, в которых четко определено, как PDP должен обрабатывать атрибуты с несколькими значениями.
Политики, основанные на содержимом ресурса
Во многих приложениях требуется, чтобы решение по авторизации основывалось данных, содержащихся в информационном ресурсе, к которому запрашивается доступ. Например, часто политика, обеспечивающая защиту частной информации, требует, чтобы владелец информации сам разрешал читать записи, в которых он является субъектом. Тем самым политика должна определять субъект, находящейся в информационном ресурсе.
XACML предоставляет такую возможность, если информационный ресурс является XML документом. Для этого используется соответствующий атрибут, значением которого может быть XPath выражение.
Операторы
Политики информационной безопасности определяются для атрибутов, субъектов, ресурса, действия и окружения. Для получения решения по доступу могут сравниваться или вычисляться атрибуты разных типов. Например, в финансовом приложении доступный индивидууму кредит может быть вычислен исходя из значения его кредитного лимита и баланса счета. Затем результат может сравниваться со значением транзакции. Это приводит к необходимости арифметических операций над атрибутами субъекта (баланс счета и лимит кредита) и ресурса (значение транзакции).
В другом случае политика может определять набор ролей, которым разрешено выполнять конкретное действие. Соответствующая операция определяет проверку, является ли непустым пересечение набора ролей, которым принадлежит субъект, и набора ролей, определенных в политике.
XACML определяет встроенные функции и метод добавления новых функций. Эти функции могут комбинироваться для создания сложных выражений. Это достигается с помощью элемента <Apply>. Элемент <Apply> имеет XML атрибут, называемый FunctionId, который определяет функцию, применяемую к содержимому элемента. Каждая стандартная функция определена для конкретной комбинации типов данных аргументов и возвращает данные определенного типа. Согласованность типов данных политики может быть проверена как при написании политики, так и при ее обработки. Типы значений данных, находящиеся в запросе, могут сравниваться со значениями, имеющимися в политике.
Дополнительно определены операции над аргументами, являющимися датой, временем и интервалом времени.
Также определены операторы сравнения для чисел, имен в формате Х.500, строк, URIs и т.п.
Существуют также операции над булевыми типами данных, в результате чего возможна комбинация предикатов в правиле. Например, правило может содержать утверждение, что доступ может быть предоставлен в рабочее время и с определенного терминала.
Возможные уязвимости
Рассмотрим возможные уязвимости, которые могут существовать при реализации основанной на XACML системы.
Будем предполагать, что противник имеет доступ к информационному каналу между участниками XACML и может просматривать, вставлять, повторять ранее переданные сообщения, удалять и модифицировать сообщения или части сообщений.
Результат «Не применимо»
Результат «Не применимо» означает, что PDP не может найти политику, чья цель соответствует информации в запросе решения. В общем случае рекомендуется, чтобы вместо «Не применимо» возвращался результат «Deny».
Однако в некоторых случаях, например, в случае веб доступа, решение по доступу «Не применимо» считается эквивалентным «Permit».
Если «Не применимо» трактуется как «Permit», важно, чтобы алгоритмы, находящие соответствующие элементы в запросе, понимали синтаксис данных, используемый приложением, которое создало запрос. Если совпадение не будет найдено, то результат будет «Не применимо», что будет трактоваться как «Permit». Тем самым случайная ошибка при разборе синтаксиса может привести к непреднамеренному доступу.
Приложения, взаимодействующие по протоколу http, допускают различный синтаксис для эквивалентных выражений. Элементы URL могут быть представлены как в виде символов, так и в виде 16-ричных значений. Путь типа «/./» также позволяет несколькими способами указать одно и тоже значение. Если алгоритм не обрабатывает различные варианты, может быть предоставлен непреднамеренный доступ.
Считается, что трактовка «Не применимо» как «Permit» возможна только в закрытых окружениях, где все приложения, которые создают запрос, гарантированно используют точно такой же синтаксис, что и в политиках. В более открытом окружении, когда запросы решений могут посылаться от приложений, которые используют любой допустимый синтаксис, настоятельно рекомендуется, чтобы «Не применимо» НЕ трактовалось как «Permit», и при этом правила определения соответствия были тщательно разработаны, чтобы соответствие находилось для всех возможных входных данных, не зависимо от вариантов синтаксиса.
Негативные правила
Негативным правилом будем называть правило, основанное на предикате, который возвращает значение «False». Типичное использование негативных правил состоит в запрете доступа индивидууму или подгруппе, когда они являются членом большей группы, членам которой разрешен доступ. В противном случае потребовалось бы создавать две группы, что не всегда удобно. Негативные правила могут быть очень эффективны в некоторых случаях, поэтому они включены в XACML.
Негативные правила могут привести к нарушениям политики в двух случаях: когда запрещены атрибуты и когда изменена базовая группа. Примером запрещенных атрибутов может служить политика, которая разрешает доступ, за исключением субъекта, у которого конкретный атрибут имеет определенное значение. Если возможна ситуация, что это
атрибут может быть по некоторым причинам неизвестен PDP, то результатом может быть неавторизованный доступ. Это возможно, если этот атрибут запрещен субъектом к опубликованию, или сервер или репозиторий, которые содержат информацию, могут быть случайно или преднамеренно недоступны.
Пример изменения базовой группы состоит в том, что, если существует политика, при которой любой из отдела, за исключением секретарей, может изменить исходный код ПО. Предположим теперь, что отдел был переведен в другой отдел, и при этом продолжает поддерживаться та же самая политика. Однако новый отдел также имеет сотрудников, обладающих теми же правами, что и секретари. Если политика не изменена, им будет разрешено изменять исходный код ПО. Проблем данного типа легко избежать, если один человек администрирует все политики, но когда администрирование является распределенным, что предполагает XACML, такие ситуации следует стремиться избегать.
Необходимые сервисы безопасности
Аутентификация
Аутентификация предоставляет способы одному участнику транзакции определить идентификацию другого участника транзакции. Аутентификация может быть как однонаправленной, так и взаимной.
Понимая чувствительную природу систем управления доступом, важно для РЕР аутентифицировать PDP, к которому он посылает авторизационные запросы. В противном случае существует риск, что нарушитель может предоставить ложные или недействительные авторизационные решения, приводящие к нарушению политики.
Также важно для PDP аутентифицировать РЕР и оценить уровень доверия для определения того, какие чувствительные данные можно передавать. Следует помнить, что даже простые ответы «Permit» или «Deny» могут быть использованы в интересах нарушителя, если он может делать любые запросы к PDP.
Для обеспечения аутентификации может использоваться такие технологии, как общий секрет и цифровые подписи. Аутентификация может также выполняться как часть коммуникационного протокола и выполняться как на уровне сообщения, так и на уровне сессии.
Администрирование политики
Если содержание политик может быть доступно вне системы управления доступом, потенциальные нарушители могут использовать данную информацию для определения того, как получить неавторизованный доступ.
Для предотвращения данной угрозы для репозитория, используемого для хранения политик, может также требоваться управление доступом.
Кроме того, в языке политики определен специальный элемент <Status>, который должен использоваться для возвращения значений атрибутов только тогда, когда раскрытие идентификаций этих атрибутов не компрометирует безопасность.
Конфиденциальность
Механизмы конфиденциальности гарантируют, что содержимое сообщения может быть прочитано только нужными получателями, и никто другой, перехвативший сообщение при передачи, не сможет его причитать. Конфиденциальность может обеспечиваться на уровне всей транзакции и на уровне отдельных элементов транзакции.
Конфиденциальность транзакции
В некоторых окружениях считается хорошей практикой использовать конфиденциальность для всех данных внутри системы управления доступом. В других окружениях считается, что политики могут доступны для свободного распространения, анализа и аудита. В первом случае нарушитель не имеет возможность понять, какие шаги могут привести к успешному получению неавторизованного доступа. Независимо от выбранного подхода безопасность системы управления доступом не должна зависеть от секретности политики.
Конфиденциальность коммуникаций может обеспечиваться таким механизмом, как SSL.
Конфиденциальность уровня утверждения
В некоторых случаях разработчик может захотеть зашифровать только части элемента <Policy>.
Для шифрования всего или части XML документа может использоваться стандарт W3C «Синтаксис и обработка XML Encryption». Даная спецификация рекомендована для использования с XACML.
Для хранения чувствительных данных должен использоваться безопасный репозиторий.
Целостность политики
Написанная на языке XACML политика является основой при принятии решения о предоставлении доступа. Следовательно, поддержка ее целостности особенно важна. Существуют два аспекта, касающиеся поддержки целостности политики. Один состоит в гарантировании того, что элементы <Policy> не изменены после того, как они созданы РАР. Другой состоит в гарантировании целостности набора политик.
Во многих случаях оба аспект обеспечиваются гарантированием целостности на уровне сессии. Если политика распространяется между организациями, чтобы быть задействованной в дальнейшем, или когда политика передается вместе с защищаемым ресурсом, бывает полезно подписать политику. В этих случаях рекомендуется использовать стан-
дарт W3C «Синтаксис и обработка XML Signature». Способ проверки подписи зависит от развернутой инфраструктуры открытых ключей.
Уникальность идентификаторов политики
Так как на политику можно ссылаться по идентификаторам, РАР должен гарантировать уникальность этих идентификаторов. Конфликт идентификаторов может привести к неправильной идентификации применяемой политики. В спецификации XACML не говорится, должен ли РАР создавать новый идентификатор, когда политика модифицируется, или может использоваться тот же самый идентификатор в модифицированной политики. Это относится к практике администрирования. Если идентификатор используется повторно, существует опасность, что другие политики или наборы политик, которые ссылаются на данную, могут быть изменены нежелательным образом. Наоборот, если используется новый идентификатор, эти политики могут продолжать использовать предыдущую политику, если она не удалена. Литература
1. extensible Access Control Markup Language (XACML) Version 2.0, OASIS Standard, 2005, с.141.
2. XML Digital Signature profile of XACML v2.0, OASIS Standard, 2005, с.8.
3. Hierarchical resource profile of XACML v2.0, OASIS Standard, 2005, с.18.
4. Core and hierarchical role based access control (RBAC) profile of XACML v2.0, OASIS Standard, 2005, с.23.
5. SAML 2.0 profile of XACML v2.0, OASIS Standard, 2005, с.21.
