Jump to content

Разделение механизма и политики

Разделение механизма и политики [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 . Проверено 5 февраля 2016 г.
  3. ^ Миллер, М.С., и Дрекслер, К.Э. (1988). «Рынки и вычисления: агорические открытые системы» . В Хубермане, бакалавр искусств (ред.). (1988), стр. 133–176. Экология вычислений . Северная Голландия.
  4. ^ Artsy, Yeshayahu et al. , 1987.
  5. ^ Chervenak 2000 p.2
  6. ^ Рафаэль Финкель , Майкл Л. Скотт , Артси Ю. и Чанг, Х. [www.cs.rochester.edu/u/scott/papers/1989_IEEETSE_Charlotte.pdf Опыт работы с Charlotte: простота и функциональность в распределенной операционной системе]. IEEE Транс. Программное обеспечение Engng 15:676-685; 1989. Расширенный тезис, представленный на семинаре IEEE по принципам проектирования экспериментальных распределенных систем, Университет Пердью; 1986.
  7. ^ Р. Спенсер, С. Смолли, П. Лоскокко, М. Хиблер, Д. Андерсен и Дж. Лепре. Архитектура безопасности Flask: системная поддержка различных политик безопасности в материалах восьмого симпозиума по безопасности USENIX, страницы 123–139, Август 1999 года.
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: ff61cdfecb588e15972e3a48140f93f5__1717776420
URL1:https://arc.ask3.ru/arc/aa/ff/f5/ff61cdfecb588e15972e3a48140f93f5.html
Заголовок, (Title) документа по адресу, URL1:
Separation of mechanism and policy - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)