Войти
Разделение механизма и политики - это принцип дизайна в информатике. В нем говорится, что механизмы (те части реализации системы, которые контролируют авторизацию операций и выделение ресурсов ) не должны диктовать (или чрезмерно ограничивать) политики, в соответствии с которыми принимаются решения. сделано о том, какие операции нужно авторизовать и какие ресурсы выделить.
Это чаще всего обсуждается в контексте механизмов безопасности (аутентификация и авторизация), но на самом деле применимо к гораздо более широкому кругу проблем распределения ресурсов (например, планирование ЦП, распределение памяти, качество обслуживания ), а также общий вопрос о хорошей абстракции объекта.
Пер Бринч Хансен представил концепцию разделения политики и механизма в операционных системах в системе мультипрограммирования RC 4000. Арси и Ливни в статье 1987 года обсуждали подход к разработке операционной системы, имеющий «крайнее разделение механизма и политики». В статье 2000 г. Червенак и др. описал принципы нейтральности механизма и нейтральности политики.
Разделение механизма и политики - это фундаментальный подход микроядра, который отличает его от монолитного. В микроядре большинство сервисов операционной системы предоставляется серверными процессами на уровне пользователя. Для операционной системы важно иметь гибкость, обеспечивающую адекватные механизмы для поддержки максимально широкого спектра реальных политик безопасности.
Практически невозможно представить себе все различные способы использования системы разными типами пользователей в течение срока службы продукта. Это означает, что любые жестко запрограммированные политики, вероятно, будут неадекватными или неподходящими для некоторых (или, возможно, даже большинства) потенциальных пользователей. Разделение реализаций механизма и спецификаций политик позволяет различным приложениям использовать одни и те же реализации механизма с разными политиками. Это означает, что эти механизмы, вероятно, будут лучше удовлетворять потребности более широкого круга пользователей в течение более длительного периода времени.
Если можно задействовать новые политики без изменения механизмов реализации, затраты и риски таких изменений политики могут быть значительно уменьшены. В первом случае это может быть достигнуто просто путем разделения механизмов и их политик на отдельные модули: путем замены модуля, который диктует политику (например, политику планирования ЦП), без изменения модуля, который выполняет эту политику (например, механизм планирования), мы может изменить поведение системы. Кроме того, в случаях, когда ожидается широкий или переменный диапазон политик в зависимости от потребностей приложений, имеет смысл создать некодовые средства для определения политик, т.е. политики не жестко запрограммированы в исполняемый код, а могут быть указаны как независимое описание.. Например, политики защиты файлов (например, пользователь / группа Unix / другое чтение / запись / выполнение ) могут быть параметризованы. В качестве альтернативы может быть разработан механизм реализации, включающий интерпретатор для нового языка спецификации политик. В обоих случаях системы обычно сопровождаются механизмом отложенного связывания (например, позднее связывание параметров конфигурации через файлы конфигурации или возможность программирования во время выполнения через API ), который позволяет включать в систему спецификации политики или заменять их другими после того, как они были доставлены заказчику.
Обычным примером разделения механизма / политики является использование карточных ключей для получения доступа к запертым дверям. Механизмы (считыватели магнитных карт, дистанционно управляемые замки, подключение к серверу безопасности) не накладывают никаких ограничений на политику входа (какие люди должны иметь право входить в какие двери и в какое время). Эти решения принимаются централизованным сервером безопасности, который (в свою очередь), вероятно, принимает решения, обращаясь к базе данных правил доступа в комнаты. Конкретные решения об авторизации можно изменить, обновив базу данных доступа к комнатам. Если схема правил этой базы данных окажется слишком ограниченной, можно заменить весь сервер безопасности, оставив основные механизмы (считыватели, блокировки и соединения) неизменными.
Сравните это с выдачей физических ключей: если вы хотите изменить, кто может открывать дверь, вы должны выдать новые ключи и изменить замок. Это связывает механизмы разблокировки с политиками доступа. Для отеля это значительно менее эффективно, чем использование ключей-карт.
| journal =() включен в книгу: Per Brinch Hansen, ed. (2001) [2001]. "1" (PDF). Классические операционные системы: от пакетной обработки до распределенных систем. Нью-Йорк: Springer-Verlag. С. 1–36. ISBN 978-0-387-95113-3.(стр.18)