Разделение механизма и политики
Разделение механизма и политики [1] — это принцип проектирования в информатике . В нем говорится, что механизмы (те части реализации системы, которые контролируют авторизацию операций и распределение ресурсов ) не должны диктовать (или чрезмерно ограничивать) политики, в соответствии с которыми принимаются решения о том, какие операции разрешать и какие ресурсы выделять. .
Хотя чаще всего обсуждается в контексте механизмов безопасности (аутентификация и авторизация), разделение механизма и политики применимо к диапазону распределения ресурсов. проблемы (например, планирование ЦП , распределение памяти , качество обслуживания ), а также проектирование абстракций программного обеспечения . [ нужна ссылка ]
Пер Бринч Хансен представил концепцию разделения политики и механизмов в операционных системах в мультипрограммной системе RC 4000 . [2] Арци и Ливни в статье 1987 года обсудили подход к разработке операционной системы, предусматривающий «крайнее разделение механизмов и политик». [3] [4] В статье 2000 года Червенак и др. описал принципы нейтральности механизма и нейтральности политики . [5]
Обоснование и последствия
[ редактировать ]Разделение механизма и политики — это фундаментальный подход микроядра , отличающий его от монолитного . В микроядре большинство служб операционной системы предоставляются серверными процессами пользовательского уровня. [6] важно Для операционной системы иметь гибкость, обеспечивающую адекватные механизмы для поддержки максимально широкого спектра реальных политик безопасности. [7]
Практически невозможно представить все возможные способы использования системы разными типами пользователей на протяжении всего срока службы продукта. Это означает, что любые жестко запрограммированные политики, скорее всего, окажутся неадекватными или неподходящими для некоторых (или, возможно, даже большинства) потенциальных пользователей. Отделение реализации механизма от спецификаций политики позволяет различным приложениям использовать одни и те же реализации механизма с разными политиками. Это означает, что эти механизмы, вероятно, будут лучше удовлетворять потребности более широкого круга пользователей в течение более длительного периода времени.
Если возможно реализовать новую политику без изменения механизмов ее реализации, затраты и риски таких изменений политики могут быть значительно снижены. В первом случае это может быть достигнуто просто путем разделения механизмов и их политик на отдельные модули: заменяя модуль, который диктует политику (например, политику планирования ЦП), не меняя модуль, который выполняет эту политику (например, механизм планирования), мы может изменить поведение системы. Кроме того, в случаях, когда ожидается широкий или переменный диапазон политик в зависимости от потребностей приложений, имеет смысл создать некоторые некодовые средства для определения политик, т.е. политики не жестко закодированы в исполняемом коде, а могут быть указаны как независимое описание. . Например, политики защиты файлов (например, в Unix пользователь/группа/другие операции чтения/записи/выполнения ) могут быть параметризованы. В качестве альтернативы механизм реализации может быть спроектирован так, чтобы включать интерпретатор нового языка спецификации политики. В обоих случаях системы обычно сопровождаются механизмом отсроченного связывания (например, позднее связывание параметров конфигурации через файлы конфигурации или программирование во время выполнения через API ), что позволяет включать спецификации политики в систему или заменять их другими после их доставки клиенту.
Повседневным примером разделения механизма и политики является использование карточных ключей для получения доступа к запертым дверям. Механизмы (считыватели магнитных карт, замки с дистанционным управлением, подключение к серверу безопасности) не накладывают никаких ограничений на политику входа (какие люди в какие двери и в какое время должны быть допущены). Эти решения принимаются централизованным сервером безопасности, который (в свою очередь), вероятно, принимает свои решения, сверяясь с базой данных правил доступа в помещения. Конкретные решения по авторизации могут быть изменены путем обновления базы данных доступа к помещениям. Если схема правил этой базы данных окажется слишком ограничивающей, можно будет заменить весь сервер безопасности, оставив без изменений фундаментальные механизмы (считыватели, блокировки и соединения).
Сравните это с выдачей физических ключей: если вы хотите изменить того, кто может открыть дверь, вам придется выдать новые ключи и сменить замок. Это переплетает механизмы разблокировки с политиками доступа. Для отеля это существенно менее эффективно, чем использование карт-ключей.
См. также
[ редактировать ]Примечания
[ редактировать ]- ^ Батлер В. Лэмпсон и Говард Э. Стерджис. Размышления о конструкции операционной системы [1] Сообщения ACM 19 (5): 251-265 (май 1976 г.)
- ^ «Пер Бринч Хансен • Компьютерное общество IEEE» . www.computer.org . Проверено 5 февраля 2016 г.
- ^ Миллер, М.С., и Дрекслер, К.Э. (1988). «Рынки и вычисления: агорические открытые системы» . В Хубермане, бакалавр искусств (ред.). (1988), стр. 133–176. Экология вычислений . Северная Голландия.
- ^ Artsy, Yeshayahu et al. , 1987.
- ^ Chervenak 2000 p.2
- ^ Рафаэль Финкель , Майкл Л. Скотт , Артси Ю. и Чанг, Х. [www.cs.rochester.edu/u/scott/papers/1989_IEEETSE_Charlotte.pdf Опыт работы с Charlotte: простота и функциональность в распределенной операционной системе]. IEEE Транс. Программное обеспечение Engng 15:676-685; 1989. Расширенный тезис, представленный на семинаре IEEE по принципам проектирования экспериментальных распределенных систем, Университет Пердью; 1986.
- ^ Р. Спенсер, С. Смолли, П. Лоскокко, М. Хиблер, Д. Андерсен и Дж. Лепре. Архитектура безопасности Flask: системная поддержка различных политик безопасности в материалах восьмого симпозиума по безопасности USENIX, страницы 123–139, Август 1999 года.
Ссылки
[ редактировать ]- Пер Бринч Хансен (2001). «Эволюция операционных систем» (PDF) . Проверено 24 октября 2006 г. включено в книгу: Пер Бринч Хансен, изд. (2001) [2001]. «1» (PDF) . Классические операционные системы: от пакетной обработки к распределенным системам . Нью-Йорк: Springer-Verlag. стр. 1–36. ISBN 978-0-387-95113-3 . (стр. 18)
- Вульф, В .; Э. Коэн; В. Корвин; А. Джонс; Р. Левин; К. Пирсон; Ф. Поллак (июнь 1974 г.). «ГИДРА: ядро многопроцессорной операционной системы» . Коммуникации АКМ . 17 (6): 337–345. дои : 10.1145/355616.364017 . ISSN 0001-0782 . S2CID 8011765 .
- Хансен, Пер Бринч (апрель 1970 г.). «Ядро мультипрограммной системы» . Коммуникации АКМ . 13 (4): 238–241. CiteSeerX 10.1.1.105.4204 . дои : 10.1145/362258.362278 . ISSN 0001-0782 . S2CID 9414037 . (стр. 238–241)
- Левин Р.; Э. Коэн; В. Корвин; Ф. Поллак; В. Вульф (1975). «Разделение политики и механизмов в Гидре» . Материалы пятого симпозиума по принципам операционных систем - СОСП '75 . Том. 9. стр. 132–140. дои : 10.1145/800213.806531 . ISBN 9781450378635 . S2CID 10524544 .
- Червенак и др. Сетка данных [ постоянная мертвая ссылка ] Журнал сетевых и компьютерных приложений, том 23, выпуск 3, июль 2000 г., страницы 187–200.
- Арси, Йешаягу и Ливни, Мирон , Подход к проектированию полностью открытых вычислительных систем (Университет Висконсина / Мэдисон, март 1987 г.), Технический отчет по компьютерным наукам № 689.