Разделение механизма и политики [1] является принципом проектирования в информатике . В нем говорится, что механизмы (те части реализации системы, которые контролируют авторизацию операций и распределение ресурсов ) не должны диктовать (или чрезмерно ограничивать) политики, в соответствии с которыми принимаются решения о том, какие операции разрешать и какие ресурсы выделять. .
Хотя разделение механизма и политики чаще всего обсуждается в контексте механизмов безопасности (аутентификация и авторизация), оно применимо к ряду проблем распределения ресурсов (например, планирование ЦП , распределение памяти , качество обслуживания ), а также к проектированию программных абстракций. . [ нужна цитата ]
Пер Бринч Хансен представил концепцию разделения политики и механизмов в операционных системах в мультипрограммной системе RC 4000 . [2] Арци и Ливни в статье 1987 года обсудили подход к проектированию операционной системы, имеющий «крайнее разделение механизма и политики». [3] [4] В статье 2000 года Червенак и др. описал принципы нейтральности механизма и нейтральности политики . [5]
Разделение механизма и политики — это фундаментальный подход микроядра, отличающий его от монолитного . В микроядре большинство служб операционной системы предоставляются серверными процессами пользовательского уровня. [6] Для операционной системы важно иметь гибкость, обеспечивающую адекватные механизмы для поддержки максимально широкого спектра реальных политик безопасности. [7]
Практически невозможно представить себе все возможные способы использования системы разными типами пользователей на протяжении всего срока службы продукта. Это означает, что любые жестко запрограммированные политики, скорее всего, окажутся неадекватными или неподходящими для некоторых (или, возможно, даже большинства) потенциальных пользователей. Отделение реализации механизма от спецификаций политики позволяет различным приложениям использовать одни и те же реализации механизма с разными политиками. Это означает, что эти механизмы, вероятно, будут лучше удовлетворять потребности более широкого круга пользователей в течение более длительного периода времени.
Если возможно реализовать новую политику без изменения механизмов ее реализации, затраты и риски таких изменений политики могут быть значительно снижены. В первом случае это может быть достигнуто просто путем разделения механизмов и их политик на отдельные модули: заменяя модуль, который диктует политику (например, политику планирования ЦП), не меняя модуль, который выполняет эту политику (например, механизм планирования), мы может изменить поведение системы. Кроме того, в случаях, когда ожидается широкий или переменный диапазон политик в зависимости от потребностей приложений, имеет смысл создать некоторые некодовые средства для определения политик, т.е. политики не жестко закодированы в исполняемом коде, а могут быть указаны как независимое описание. . Например, политики защиты файлов (например, пользователь/группа/другие операции чтения/записи/выполнения в Unix ) могут быть параметризованы. В качестве альтернативы механизм реализации может быть спроектирован так, чтобы включать интерпретатор нового языка спецификации политики. В обоих случаях системы обычно сопровождаются механизмом отложенного связывания (например, позднее связывание параметров конфигурации через файлы конфигурации или программирование во время выполнения через API ), который позволяет включать спецификации политики в систему или заменять их другими после того, как они были доставлены. заказчику.
Повседневным примером разделения механизма и политики является использование карточных ключей для получения доступа к запертым дверям. Механизмы (считыватели магнитных карт, замки с дистанционным управлением, подключение к серверу безопасности) не накладывают никаких ограничений на политику входа (какие люди в какие двери и в какое время должны быть допущены). Эти решения принимаются централизованным сервером безопасности, который (в свою очередь), вероятно, принимает свои решения, сверяясь с базой данных правил доступа в помещения. Конкретные решения по авторизации могут быть изменены путем обновления базы данных доступа к помещениям. Если схема правил этой базы данных окажется слишком ограничивающей, можно будет заменить весь сервер безопасности, оставив без изменений фундаментальные механизмы (считыватели, блокировки и соединения).
Сравните это с выдачей физических ключей: если вы хотите изменить того, кто может открыть дверь, вам придется выдать новые ключи и сменить замок. Это переплетает механизмы разблокировки с политиками доступа. Для отеля это существенно менее эффективно, чем использование карт-ключей.