KK/083 Rollen & Rechteverwaltung (ACP)

Für kom­plex in­ein­an­der ver­zahn­te »Workflows«, Bedarf es ei­ner in­tui­ti­ven Rollen & Rechteverwaltung. So will der Spielerin Abwesenheit, Zugänge und Voraussetzungen zu sei­nen »Ressourcen« und »Assets« sha­ren und kon­trol­lie­ren kön­nen. In Anlehnung an das »Mandatory Access Control« (MAC)Konzept, wer­den wir zur Kontrolle und Steuerung von Zugriffsrechten, mit die­ser Kernkompetenz, ei­ne auf spe­zi­fi­zier­ten Regeln ba­sie­ren­de »Zugriffskontrollstrategie« in das Asset Management vgl. »Asset Management & Achievement«, sys­tem­be­stim­mend im­ple­men­tie­ren. So wird das »Antares Access Control System« (A/ACS), Entscheidungenüber dy­na­mi­sche Zugriffsberechtigungen »mul­ti­la­te­ral« tref­fen können.

Core Engine Modul: Antarien Concept for Role & Rights Management (A/MMA/SC)

Abbildung 83.1: Integral Component (Core): Antarien Concept for Role & Rights Management (A/MMA/SC)

Zu die­sem Zweck wer­den spe­zi­fi­sche »Regeln« und »Kontingente« auf Basis von »Codes« (Wörter), »Labels« und »Kategorien« ge­bil­det, und auf den Charakter »Akteur« und Objekt »Asset« glei­cher­ma­ßen an­ge­wen­det. Dabei liegt die Besonderheit von »A/ACS«, in den »Prozessen« und »Ressourcen« von Antares Open World, be­reits ent­spre­chen­de »Kontroll und Zugriffsmechanismen«, im Design zu kap­seln. In ih­rer Anwendung kön­nen so »Zugriffe«, »Benutzung« und »Konvertierung«, aus­schliess­lich un­ter der »Antares Confidential Policy« (ACP), er­fol­gen. Ich möch­te noch ein­mal be­to­nen, dass un­ser »Sicherheitsmodell« pri­mär nicht aus­schließ­lich auf be­nut­zer­be­stimm­ba­re oder rol­len­ba­sier­te Standardmechanismen be­ruht. Wir grei­fen hier die ty­pi­sier­ten mul­ti­la­te­ra­len Militärstandards auf, um die »Sicherheit«, die »Vertraulichkeit«, so­wie die »Integrität« von Informationen, vor un­au­to­ri­sier­tem Zugriff sys­tem­tech­nisch zu er­zwin­gen und si­cher­zu­stel­len. Dabei ver­steht sich die »Vertraulichkeit«, dem ad­äqua­tem »Schutz« und »Zugriff« vor nicht au­to­ri­sier­ten Charakteren und Mechanismen.

Wir spre­chen von der »Geheimhaltung im ge­leb­tem Metagaming«. Die »Integrität« hin­ge­gen de­fi­niert in die­sem Zusammenhang, die Verhinderung vor »Manipulation«, so zum Beispiel für nicht au­to­ri­sier­te Eingriffe in die »Befehlskette« des ant­a­ria­ni­schen »Defense Command Systems« (A/DCS) vgl. »Kampfsystem«. Das Konzept der Kernkompetenz Sicherheitsbewertungen& Spionage, wird da­bei das »A/ACS« mit der glo­ba­len »Softwarearchitektur« in ho­ri­zon­ta­ler, so­wie ver­ti­ka­ler Ebene ver­schmel­zen las­sen. Dies be­deu­tet, das zu den ge­ne­ri­schen »Sicherheitslevel« (Schutzklassen)vertikale Gliederungsstufen, zu­dem ho­ri­zon­ta­le »Verbundstufen« (Lattice), be­stehend aus »Codewörtern« (Labels), in­te­griert wer­den müs­sen. Wobei Codewörter hier nicht als ma­nu­el­le Eingaben zu ver­ste­hen sind, son­dern viel­mehr als Schlüssel co­diert in den je­wei­li­gen Assets zu fin­den sind. Antares Open World wird in die­sem Zusammenhang ver­schie­de­ne Modelle von Schutzstufen im­ple­men­tie­ren, wel­che in Abhängigkeit der je­wei­li­gen Kernkompetenzen ih­re Anwendung fin­den werden.

Core Engine Modul: Antarien Encapsulated Accreditations Realm (A/EAR)

Abbildung 83.2: Integral Component (Core): Antarien Encapsulated Accreditations Realm (A/EAR)

Im kon­kre­tem Fall be­deu­tet dies, dass je­dem er­denk­li­chem zu­griffs­fä­hi­gem »Asset« in Antarien ei­ne »Schutzstufe« zu Teil wird. Die »Antares Confidential Policy« (ACP) ge­währ­leis­tet so, dass Informationen aus­schliess­lich auf glei­chen Schichten al­so ver­ti­kal, flies­sen dür­fen. Die ge­hei­me Information re­spek­ti­ve das »Asset« ver­lässt die »Sandbox« im Sinne des vom Zugriff ge­kap­sel­ten Raumes (Realm)Sandkasten im Sandkasten Prinzip, so­mit nie­mals. Dem »Dorfältesten«, »Gildenmeister, »Eigentümer«, etc., selbst, ob­liegt es so­dann, je­dem ver­trau­ens­wür­di­gem »Charakter« sei­nes or­ga­ni­sa­to­ri­schen Komplexes, eben­falls ei­ne Schutzstufe zu­zu­wei­sen. Dieser »Vertrauensbeweis« wird über die Ausgabe ei­ner per­sön­li­chen »Keycard«, wel­che mit ent­spre­chen­den Akkreditierungen ver­se­hen wird, über­trag­bar aus­ge­ge­ben wer­den kön­nen. Dabei bin­det sich die Keycard für die »Dauer der Gültigkeit«, an ih­rem Besitzer. Die aus­zu­ge­be­ne »Authority Clearance« (AC) kann so­dann, über die Möglichkeit der Weitergabe an Dritte spe­zi­fi­zie­ren, oder die­ses unterbinden.

Aus des­sen Konsequenz, darf nur die »Clearance« ei­nes Charakters auf ei­ne iden­ti­sche oder nied­ri­ge­re Schutzstufe zu­grei­fen (Zugriffssicherheit). In Abhängigkeit de­kla­rier­ter Codewörter wer­den nun zu­dem er­wei­ter­te Zugriffsrechte auf Basis von Segmenten ge­ge­ben. Dabei ge­hört je­des Codewort ei­ner »Kategorie« an, wel­che wie­der­um aus meh­re­ren Schutzstufen und Codewörtern be­steht (Metadaten Security Verband). Dabei wird das Konzept für je­des »Asset«, frei­de­fi­nier­ba­re »Security Labels« er­mög­li­chen. Die Schutzstufen sel­ber wer­den hier, eben­falls als Labels ab­ge­bil­det. In Systematik er­gibt sich so­mit ein ho­ri­zon­ta­les auf Schichten ba­sie­ren­des Zugriffssystem mit Codewörtern, wel­che zu­gleich die ver­ti­ka­len Schutzstufenbedingen. Um die Erfordernisse des mul­ti­la­te­ra­len Zugriffs zu ge­wäh­ren, muss die aus­ge­ge­be­ne »Zugriffsklasse« (Klassifizierung) der »Keycard« stim­men und al­le »Schutzstufen« und »Codewörter« müs­sen zu­dem in Übereinstimmung ge­bracht wor­den sein.

Ein Beispiel wird nö­tig. Ein Charakter möch­te den Zeitpunkt der Fertigstellung ei­nes Bauabschnittes un­ser all­ge­mein­be­kann­ten Kirche in Erfahrung brin­gen. Unser Bauherr hat­te die Bauphasen (Prozesse), al­so die Zugriffsklasse »Bauphasen«, auf ei­ne gül­ti­ge Signatur vgl. »Signaturen« auf den aus­ge­ge­be­nen Keycards »mul­ti­la­te­ral« be­schränkt. Wenn nun ein Charakter mit per­sön­li­cher Keycard ei­nen »Lesezugriff« auf die Zugriffsklasse »Bauphasen« in­iti­iert, kann er prin­zi­pi­ell auf die­se Informationen zu­grei­fen. Da der Bauherr je­doch zu­sätz­lich ein »Sicherheitslevel« von min­des­tens der Stufe »6«, für die Anzeige von Informationen, die Aufschluss auf den Termin der Fertigstellunggeben in­stal­liert hat, muss nun der Träger der Keycard, eben­falls für die Vertrauensebene »6« ak­kre­di­tiert sein. Unser Beispielcharakter hat die­se Freigabe zwar, aber den­noch kann er die ge­wünsch­ten Informationen nicht oder nur be­schränkt ein­se­hen. Der Grund liegt im feh­len­dem Codewort »Chiro« für das »Asset« ge­nau die­ser Kirche (Objekt), so­wie ei­nem wei­te­rem Codewort »Caiman« für den Bauprozess der in Phase »10«, be­find­li­chen Fertigstellung. Kurzum, die Definition »Antares Confidential Policy« (ACP) er­laubt die Abfrage die­ser Information nicht. Erst wenn al­le Zugriffskriterien, al­so in der Keycard, die »Zugriffsklasse«, das »Sicherheitslevel«, so­wie bei­de »Schlüssel« co­diert wä­ren, wür­den die­se Information preis­ge­ge­ben und ab­ge­ru­fen wer­den können.

Aus die­sem Aspekt her­aus, er­ge­ben sich so­mit un­end­lich vie­le »Verbundstufen«. Die Zugriffsflexibilität, kann so in­di­vi­du­ell wie das Vertrauen selbst ak­kre­di­tiert wer­den. Anmerken möch­te ich noch die »Kategorisierung des Informationsflusses« nach dem Prinzip des »not­wen­di­gem Wissens« (Need to know Principle). Hierbei wer­den ein­zel­nen Charakteren nur die »Zugriffsrechte« ein­ge­räumt, wel­che sie für die »Ausübung ih­rer Dedizierung«, auch wirk­lich tat­säch­lich be­nö­ti­gen vgl. »Berufsorientierte Spielweise (Dedizierung)«.

So ist die­ses A/ACS Modell, durch die Möglichkeiten die »Antares Open World«, auf dem Gebiet der inGame Community Security bie­ten wird, in all sei­nen Nuancen und si­cher­heits­re­le­van­ten Aspekten, erst­mals in ei­nem MMO, mit Mandatory Access Control Schnittstellen, für die Spielmechanik im Gameplay kon­zi­piert. Die Chance »Sicherheitslücken« aus­zu­nut­zen, wer­den so­mit auf die Komponenten des Vertrauens im Metagaming re­du­ziert. Antares Open World bie­tet hier mul­ti­la­te­ra­le Instrumente der Steuerung für die Politik des Informationsflusses.