Separation av mekanism och policy
Separationen av mekanism och policy är en designprincip inom datavetenskap . Det sägs att mekanismer (de delar av en systemimplementering som kontrollerar auktorisering av operationer och allokering av resurser ) inte bör diktera (eller alltför begränsa) de policyer enligt vilka beslut fattas om vilka operationer som ska auktoriseras och vilka resurser som ska allokeras .
Även om det oftast diskuteras i samband med säkerhetsmekanismer (autentisering och auktorisering), är separation av mekanism och policy tillämplig på en rad resursallokeringsproblem (t.ex. CPU- schemaläggning , minnestilldelning , tjänstekvalitet ) såväl som designen av mjukvaruabstraktioner . [ citat behövs ]
Per Brinch Hansen introducerade konceptet med separation av policy och mekanism i operativsystem i multiprogrammeringssystemet RC 4000 . Artsy och Livny diskuterade i en artikel från 1987 ett tillvägagångssätt för en operativsystemdesign med en "extrem separation av mekanism och policy". I en artikel från 2000, Chervenak et al. beskrev principerna för mekanismneutralitet och policyneutralitet .
Bakgrund och konsekvenser
Separationen av mekanism och policy är det grundläggande tillvägagångssättet för en mikrokärna som skiljer den från en monolitisk . I en mikrokärna tillhandahålls majoriteten av operativsystemtjänsterna av serverprocesser på användarnivå. Det är viktigt för ett operativsystem att ha flexibiliteten att tillhandahålla adekvata mekanismer för att stödja det bredaste möjliga spektrumet av verkliga säkerhetspolicyer.
Det är nästan omöjligt att föreställa sig alla olika sätt på vilka ett system kan användas av olika typer av användare under produktens livslängd. Detta innebär att alla hårdkodade policyer sannolikt är otillräckliga eller olämpliga för vissa (eller kanske till och med de flesta) potentiella användare. Att frikoppla mekanismimplementeringarna från policyspecifikationerna gör det möjligt för olika applikationer att använda samma mekanismimplementeringar med olika policyer. Detta innebär att dessa mekanismer sannolikt kommer att bättre möta behoven hos ett bredare spektrum av användare, under en längre tidsperiod.
Om det är möjligt att möjliggöra nya policyer utan att ändra genomförandemekanismerna, kan kostnaderna och riskerna med sådana policyändringar reduceras avsevärt. I första hand skulle detta kunna åstadkommas enbart genom att separera mekanismer och deras policyer i distinkta moduler: genom att ersätta modulen som dikterar en policy (t.ex. CPU-schemaläggningspolicy) utan att ändra modulen som exekverar denna policy (t.ex. schemaläggningsmekanismen), vi kan ändra systemets beteende. Vidare, i de fall där ett brett eller varierande antal policyer förväntas beroende på applikationernas behov, är det vettigt att skapa några icke-kodmedel för att specificera policyer, dvs policyer är inte hårdkodade till körbar kod utan kan specificeras som en oberoende beskrivning . Till exempel kan filskyddspolicyer (t.ex. Unixs användare/grupp/annan läs/skriv/kör ) parametriseras. Alternativt skulle en genomförandemekanism kunna utformas för att inkludera en tolk för ett nytt policyspecifikationsspråk. I båda fallen åtföljs systemen vanligtvis av en uppskjuten bindningsmekanism (t.ex. sen bindning av konfigurationsalternativ via konfigurationsfiler , eller körtidsprogrammerbarhet via API :er) som tillåter policyspecifikationer att inkorporeras i systemet eller ersättas av en annan efter att den har levererats till kunden.
Ett vardagligt exempel på separation av mekanism/policy är användningen av kortnycklar för att få tillgång till låsta dörrar. Mekanismerna (magnetkortläsare, fjärrstyrda lås, anslutningar till en säkerhetsserver) sätter inga begränsningar för entrépolicyn (vilka personer som ska få gå in i vilka dörrar, vid vilka tidpunkter). Dessa beslut fattas av en centraliserad säkerhetsserver, som (i sin tur) förmodligen fattar sina beslut genom att konsultera en databas med regler för rumsåtkomst. Specifika behörighetsbeslut kan ändras genom att uppdatera en databas för rumsåtkomst. Om regelschemat för den databasen visade sig vara för begränsande kunde hela säkerhetsservern ersättas samtidigt som de grundläggande mekanismerna (läsare, lås och anslutningar) lämnades oförändrade.
Jämför detta med att ge ut fysiska nycklar: om du vill ändra vem som kan öppna en dörr måste du utfärda nya nycklar och byta lås. Detta sammanflätar upplåsningsmekanismerna med åtkomstpolicyerna. För ett hotell är detta betydligt mindre effektivt än att använda nyckelkort.
Se även
Anteckningar
- Per Brinch Hansen (2001). "Utvecklingen av operativsystem" (PDF) . Hämtad 2006-10-24 . ingår i bok: Per Brinch Hansen, red. (2001) [2001]. "1" (PDF) . Klassiska operativsystem: från batchbearbetning till distribuerade system . New York: Springer-Verlag. s. 1–36. ISBN 978-0-387-95113-3 . (sid. 18)
- Wulf, W .; E. Cohen; W. Corwin; A. Jones; R. Levin; C. Pierson; F. Pollack (juni 1974). "HYDRA: kärnan i ett multiprocessoroperativsystem" . Kommunikation från ACM . 17 (6): 337–345. doi : 10.1145/355616.364017 . ISSN 0001-0782 . S2CID 8011765 .
- Hansen, Per Brinch (april 1970). "Kärnan i ett multiprogrammeringssystem" . Kommunikation från ACM . 13 (4): 238–241. CiteSeerX 10.1.1.105.4204 . doi : 10.1145/362258.362278 . ISSN 0001-0782 . S2CID 9414037 . (s. 238–241)
- Levin, R.; E. Cohen; W. Corwin; F. Pollack; W. Wulf (1975). "Policy/mekanismseparation i Hydra" . ACM Symposium on Operating Systems Principles / Proceedings of the Fifth ACM Symposium on Operating Systems Principles . 9 (5): 132–140. doi : 10.1145/800213.806531 . S2CID 10524544 .
- Chervenak et al. Datagrid [ permanent död länk ] Journal of Network and Computer Applications, Volym 23, Issue 3, juli 2000, Sidorna 187-200
- Artsy, Yeshayahu och Livny, Miron , An Approach to the Design of Fully Open Computing Systems (University of Wisconsin/Madison, mars 1987) Datavetenskap teknisk rapport #689.