Разделение механизма и политики - Separation of mechanism and policy

В разделение механизма и политики[1] это дизайн принцип в Информатика. В нем говорится, что механизмы (те части реализации системы, которые контролируют разрешение операций и распределение ресурсов ) не должны диктовать (или чрезмерно ограничивать) политики, в соответствии с которыми принимаются решения о том, какие операции разрешать и какие ресурсы выделять.

Это чаще всего обсуждается в контексте механизмов безопасности (аутентификация и авторизация), но на самом деле применимо к гораздо более широкому кругу проблем распределения ресурсов (например, Планирование ЦП, выделение памяти, качество обслуживания ) и общий вопрос о хорошей абстракции объекта.

Пер Бринч Хансен представила концепцию разделения политики и механизма в операционных системах в Мультипрограммная система RC 4000.[2] Арси и Ливни в статье 1987 года обсуждали подход к разработке операционной системы, имеющий «крайнее разделение механизма и политики».[3][4] В статье 2000 г. Червенак и др. описал принципы механизм нейтральности и политический нейтралитет.[5]

Обоснование и последствия

Разделение механизма и политики - фундаментальный подход микроядро что отличает его от монолитный один. В микроядре большинство сервисов операционной системы предоставляется серверными процессами на уровне пользователя.[6] Это важно для Операционная система иметь гибкость, предоставляя адекватные механизмы для поддержки самого широкого спектра реальных политик безопасности.[7]

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

Если будет возможно внедрить новые политики без изменения механизмов реализации, затраты и риски таких изменений политики можно будет значительно снизить. В первом случае это может быть достигнуто просто путем разделения механизмов и их политик на отдельные модули: путем замены модуля, который диктует политику (например, политику планирования ЦП), без изменения модуля, который выполняет эту политику (например, механизм планирования), мы может изменить поведение системы. Кроме того, в случаях, когда ожидается широкий или переменный диапазон политик в зависимости от потребностей приложений, имеет смысл создать некодовые средства для определения политик, т.е. политики не жестко запрограммированы в исполняемый код, а могут быть указаны как независимое описание. . Например, политики защиты файлов (например, Unix пользователь / группа / другое чтение / запись / выполнение ) могут быть параметризованы. В качестве альтернативы может быть разработан механизм реализации, включающий интерпретатор для нового языка спецификации политик. В обоих случаях системы обычно сопровождаются механизмом отложенного связывания (например, позднее связывание вариантов конфигурации через файлы конфигурации, или возможность программирования во время выполнения через API ), который позволяет включать спецификации политик в систему или заменять их другими после того, как они были доставлены заказчику.

Обычным примером разделения механизма и политики является использование карточные ключи чтобы получить доступ к запертым дверям. Механизмы (считыватели магнитных карт, дистанционно управляемые замки, подключение к серверу безопасности) не накладывают никаких ограничений на политику входа (какие люди должны иметь право входить в какие двери и в какое время). Эти решения принимаются централизованным сервером безопасности, который (в свою очередь), вероятно, принимает решения, обращаясь к базе данных правил доступа в комнаты. Конкретные решения об авторизации можно изменить, обновив базу данных доступа к комнатам. Если схема правил этой базы данных окажется слишком ограниченной, можно заменить весь сервер безопасности, оставив основные механизмы (считыватели, блокировки и соединения) неизменными.

Сравните это с выдачей физических ключей: если вы хотите изменить, кто может открывать дверь, вы должны выдать новые ключи и изменить замок. Это связывает механизмы разблокировки с политиками доступа. Для отеля это значительно менее эффективно, чем использование ключей-карт.

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

Примечания

  1. ^ Батлер В. Лэмпсон и Говард Э. Стерджис. Размышления о дизайне операционной системы [1] Сообщения ACM 19 (5): 251-265 (май 1976 г.)
  2. ^ "Пер Бринч Хансен • Компьютерное общество IEEE". www.computer.org. Получено 2016-02-05.
  3. ^ Миллер, М.С., и Дрекслер, К.Е. (1988). «Рынки и вычисления: Агорические открытые системы». В Хубермане, Б.А. (Ред.). (1988), стр. 133–176. Экология вычислений. Северная Голландия.
  4. ^ Артистич, Йешаягу и другие., 1987.
  5. ^ Червенак 2000 ч.2
  6. ^ Рафаэль Финкель, Майкл Л. Скотт, Арти Й. и Чанг Х. [www.cs.rochester.edu/u/scott/papers/1989_IEEETSE_Charlotte.pdf Опыт работы с Шарлоттой: простота и функциональность в распределенной операционной системе]. IEEE Trans. Software Engng 15: 676-685; 1989. Расширенная аннотация, представленная на семинаре IEEE по принципам проектирования экспериментальных распределенных систем, Университет Пердью; 1986 г.
  7. ^ Р. Спенсер, С. Смолли, П. Лоскокко, М. Хиблер, Д. Андерсен и Дж. Лепро Архитектура безопасности Flask: поддержка системой разнообразных политик безопасности В материалах восьмого симпозиума по безопасности USENIX, страницы 123–139, август 1999 г.

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

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