Политико-ориентированное управление

Наиболее известная архитектура политико-ориентированного управления была сформирована совместно IETF и DMTF. Она включает четыре основных функциональных элемента: инструмент управления политиками (Policy Management Tool, PMT), репозиторий политик (Policy Repository), точку принятия решений по политикам (Policy Decision Point, PDP) и точку применения политик (Policy Enforcement Point, PEP).

PMT используется администратором для определения или обновления политик, применяемых в управляемой сети. Полученные политики сохраняются в репозитории в форме, соответствующей информационной модели^[8], что обеспечивает совместимость между продуктами различных производителей. После добавления новых политик в репозиторий или изменения существующих PMT отправляет соответствующие уведомления PDP, который интерпретирует политики и передаёт их PEP. PEP — это компонент, работающий на узле с поддержкой политик и способный выполнять (применять) различные политики. Компоненты архитектуры могут взаимодействовать друг с другом с использованием различных протоколов. Предпочтительными средствами передачи решений о политике между PDP и сетевыми устройствами (PEP) выступают COPS или SNMP, а для связи PMT/PDP с репозиторием — LDAP.

Самый простой способ спецификации политик — последовательность правил, каждое из которых представляет собой пару «условие-действие». Архитектура IETF использует этот подход и рассматривает политики как правила, определяющие действия, выполняемые при выполнении заданных условий:

   if <условие(я)> then <действие(я)>

Условная часть правила может быть простой или составной, заданной в конъюнктивной или дизъюнктивной нормальной форме. Действующая часть правила определяет набор действий, которые должны быть выполнены при верности условий. IETF не определяет конкретный язык для описания сетевых политик, а разрабатывает универсальную объектно-ориентированную информационную модель для представления информации о политике. Эта модель является абстрактной и позволяет производителям реализовывать собственные условия и действия, используемые в правилах политики.

Как и любой программируемой системе, политико-ориентированному управлению могут быть присущи несогласованности из-за противоречивых правил, управляющих поведением системы. Такие ситуации называются конфликтами политик^[9] и возникают в результате ошибок спецификации, пропусков или противоречивых управляющих операций и в некоторых случаях могут иметь катастрофические последствия для работы управляемой системы. Их также сравнивают с ошибками программного обеспечения^[10], возникающими, когда одновременно активируются две и более политики, реализующие противоречащие друг другу управляющие воздействия.

Конфликты политик в целом делятся на независимые от области применения и специфичные для конкретных приложений^[11], где первые не зависят от сферы применения, а вторые определяются специфическими требованиями предметной области. В литературе примером прикладных областей выступают обеспечение качества обслуживания (QoS) в IP-сетях^[9][12], распределённые системы^[11][13], безопасность межсетевых экранов,^[14][15][16] а также управление вызовами в телекоммуникационных сетях^[17]. Конфликты политик можно также классифицировать по временным рамкам выявления: статические конфликты^[18] могут быть обнаружены при офлайн-анализе во время спецификации политики, в то время как динамические конфликты^[19] выявляются только при непосредственном применении политик, так как они зависят от текущего состояния управляемой системы. Например, конфликт может возникнуть между политикой динамического выделения ресурсов и политикой, устанавливающей лимиты для пользователей или классов обслуживания. Поэтому автоматизация является ключевым элементом механизмов анализа динамических конфликтов, чтобы минимизировать влияние конфликта на работу системы.

Для эффективного использования политик и согласованного управления системой необходимо проверять, не вступают ли новые политики в противоречие друг с другом или с уже внедрёнными политиками. Для этого процессы обнаружения используют информацию об условиях возникновения конфликтов и анализируют пространство политик, чтобы выявить политики, соответствующие критериям конфликта. На основе различных типов конфликтов, описанных в литературе и различных областях применения, исследователи разрабатывают механизмы и техники для их эффективного выявления. Простые конфликты (например, модальные конфликты) могут быть обнаружены синтаксическим анализом, однако для более сложных несогласованностей требуется чёткое определение условий конфликта, что иногда предполагает использование предметно-ориентированных знаний. Популярные подходы к выявлению конфликтов базируются на метаполитиках (правилах обнаружения),^[9][11][20] взаимосвязях политик^[14],^[15][16] пространствах применимости^[21], и информационных моделях^[22].

Разрешение является следующим этапом анализа политик и направлено на обработку обнаруженных несогласованностей, желательно автоматически, для восстановления согласованности политик. В процесс разрешения может входить отзыв, подавление, приоритизация, изменение политик или, в некоторых случаях, введение новой политики. Методика разрешения зависит прежде всего от типа политики и специфики прикладной области. Хотя в ряде ситуаций вмешательство человека неизбежно, многие исследования направлены на автоматизацию процесса разрешения. Наиболее распространёнными подходами являются метаполитики (правила разрешения)^[9][19][20], приоритеты^[11] упорядочивание политик,^[15][21], и предотвращение конфликтов^[23].

Временные рамки выявления конфликтов влияют на методологию анализа и требования к их обработке. Статические конфликты, как правило, обнаруживаются с помощью анализа, инициируемого вручную администратором, и разрешаются путем изменения политик^[9][18]. В отличие от них, конфликты времени выполнения должны выявляться процессом мониторинга выполнения политик и обнаружения неконсистентных ситуаций на этапе исполнения. В этом случае разрешение достигается автоматически, например, через применение специальных правил разрешения^[9][19]. Недостаток автоматизации в обработке таких конфликтов может привести к серьёзным последствиям, особенно при управлении QoS для приложений, критичных к задержкам.

В идеале система политико-ориентированного управления должна обеспечивать определение высокоуровневых управленческих целей, которые легко формулируются и понимаются человеком, их преобразование в низкоуровневые политики и отображение в команды конфигурации управляемых устройств. Тогда как высокоуровневые цели отражают бизнес-стратегию администратора, низкоуровневые политики отвечают за настройку устройств.

Декомпозиция (рефинемент) политик — это процесс трансформации абстрактных или высокоуровневых требований в конкретные, реализуемые политики, которые могут быть применены в управляемой системе. Основные задачи процесса уточнения:

• Определение ресурсов, необходимых для выполнения требований политики
• Перевод высокоуровневых целей в операционные политики, применяемые системой
• Проверка того, что низкоуровневые политики соответствуют исходной высокоуровневой цели

Для декомпозиции политик предложено множество подходов. Наиболее заметные из них основаны на линейной временной логике^[24], исчислении событий^[25], и утилитарных вычислениях^[26][27].