Rollen & Rechteverwaltung (ACP) — Antarianisches Zugriffskontrollsystem

Dieses Kapitel beschreibt das antarianische Rollen- und Rechteverwaltungssystem in {{Antares Open World}}: Von Mandatory Access Control und der Antares Confidential Policy (ACP) über Keycards, Schutzstufen und Security Labels bis hin zu multilateraler Zugriffskontrolle, Codewörtern und dem Need-to-Know-Prinzip — ein vielschichtiges Sicherheits- und Zugriffskontrollsystem mit 31 Subsystemen in 2 Core-Engine-Modulen.

KK/083 — Rollen & Rechteverwaltung (ACP)

Für komplex ineinander verzahnte »Workflows«, Bedarf es einer intuitiven Rollen & Rechteverwaltung. So will der Spieler in Abwesenheit, Zugänge und Vorraussetzungen zu seinen »Ressourcen« und »Assets« sharen und kontrollieren können.

In Anlehnung an das »Mandatory Access Control« (MAC) Konzept, werden wir zur Kontrolle und Steuerung von Zugriffsrechten, mit dieser Kernkompetenz, eine auf spezifizierten Regeln basierende »Zugriffskontrollstrategie« in das Asset Management vgl. >>Asset Management & Achievement ab S.287 & ff.<<, systembestimmend implementieren. So wird das »Antares Access Control System« (A/ACS), Entscheidungen über dynamische Zugriffsberechtigungen »multilateral« treffen können. Zu diesem Zweck werden spezifische »Regeln« und »Kontingente« auf Basis von »Codes« (Wörter), »Labels« und »Kategorien« gebildet, und auf den Charakter »Akteur« und Objekt »Asset« gleichermaßen angewendet. Dabei liegt die Besonderheit von »A/ACS«, in den »Prozessen« und »Ressourcen« von {{Antares Open World}}, bereits entsprechende »Kontroll- und Zugriffsmechanismen«, im Design zu kapseln. In ihrer Anwendung können so »Zugriffe«, »Benutzung« und »Konvertierung«, ausschliesslich unter der »Antares Confidential Policy« (ACP), erfolgen.

83.1 — Multilaterale Sicherheitsarchitektur

Das antarianische Zugriffskontrollsystem (A/ACS) geht weit ueber typische MMO-Gildensysteme hinaus. Es implementiert echte militaerische Mandatory Access Control Mechanismen, bei denen Zugriffe nicht nur durch Rollen, sondern durch Schutzstufen, Codewörter und multilaterale Sicherheitsverbunde gesteuert werden — ein bislang einzigartiger Ansatz im MMO-Genre.

Ich möchte noch einmal betonen, dass unser »Sicherheitsmodell« primär nicht ausschließlich auf benutzerbestimmbare oder rollenbasierte Standardmechanismen beruht. Wir greifen hier die typisierten multilateralen Militärstandards auf, um die »Sicherheit«, die »Vertraulichkeit«, sowie die »Integrität« von Informationen, vor unautorisiertem Zugriff systemtechnisch zu erzwingen und sicherzustellen. Dabei versteht sich die »Vertraulichkeit«, dem adäquatem »Schutz« und »Zugriff« vor nicht autorisierten Charakteren und Mechanismen. Wir sprechen von der »Geheimhaltung im gelebtem Metagaming«. Die »Integrität« hingegen definiert in diesem Zusammenhang, die Verhinderung vor »Manipulation«, so zum Beispiel für nicht autorisierte Eingriffe in die »Befehlskette« des antarianischen »Defense Command Systems« (A/DCS) vgl. >>Kampfsystem ab S.355 & ff.<<.

Das Konzept der Kernkompetenz >>Sicherheitsbewertungen & Spionage ab S.343 & ff.<<, wird dabei das »A/ACS« mit der globalen »Softwarearchitektur« in horizontaler, sowie vertikaler Ebene verschmelzen lassen. Dies bedeutet, das zu den generischen »Sicherheitslevel« (Schutzklassen) -vertikale Gliederungsstufen-, zudem horizontale »Verbundstufen« (Lattice), bestehend aus »Codewörtern« (Labels), integriert werden müssen. Wobei Codewörter hier nicht als manuelle Eingaben zu verstehen sind, sondern vielmehr als Schlüssel codiert in den jeweiligen Assets zu finden sind.

83.2 — Schutzstufen und Keycards

{{Antares Open World}} wird in diesem Zusammenhang verschiedene Modelle von Schutzstufen implementieren, welche in Abhängigkeit der jeweiligen Kernkompetenzen ihre Anwendung finden werden. Im konkretem Fall bedeutet dies, dass jedem erdenklichem zugriffsfähigem »Asset« in Antarien eine »Schutzstufe« zu Teil wird. Die »Antares Confidential Policy« (ACP) gewährleistet so, dass Informationen ausschliesslich auf gleichen Schichten -also vertikal-, fliessen dürfen. Die geheime Information respektive das »Asset« verlässt die »Sandbox« im Sinne des vom Zugriff gekapselten Raumes (Realm) -Sandkasten im Sandkasten Prinzip-, somit niemals.

Dem »Dorfältesten«, »Gildenmeister«, »Eigentümer«, etc., selbst, obliegt es sodann, jedem vertrauenswürdigem »Charakter« seines organisatorischen Komplexes, ebenfalls eine Schutzstufe zuzuweisen. Dieser »Vertrauensbeweis« wird über die Ausgabe einer persönlichen »Keycard«, welche mit entsprechenden Akkreditierungen versehen wird, übertragbar ausgegeben werden können. Dabei bindet sich die Keycard für die »Dauer der Gültigkeit«, an ihrem Besitzer. Die auszugebene »Authority Clearance« (AC) kann sodann, über die Möglichkeit der Weitergabe an Dritte spezifizieren, oder dieses unterbinden. Aus dessen Konsequenz, darf nur die »Clearance« eines Charakters auf eine identische oder niedrigere Schutzstufe zugreifen (Zugriffssicherheit).

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

83/ACCESS — Mandatory Multilateral Access Security Control Subsystem

83/SSHARE — Services Share Control Framework Subsystem

83/RSHARE — Ressources Share Control Framework Subsystem

83/ASHARE — Assets Share Control Framework Subsystem

83/PSHARE — Participants Share Control Framework Subsystem

83/APC — Access Privileges Control Framework Subsystem

83/ACL — Access Control List Framework Subsystem

83/POLICY — Confidential Policy Framework Subsystem

83/CODES — Codes/Codewords Framework Subsystem

83/LABELS — Security Labels Framework Subsystem

83/SCTGRS — Security Categories Framework Subsystem

83/CLASS — Security Access Class Framework Subsystem

83/MSLM — Metadata Security Lattice Mechanism Subsystem

83/SRVLNC — Multilaterally Surveillance Control Subsystem

83/QUOTAS — Contingents/Quotas Framework Subsystem

83/SEGMENTS — Segments Framework Subsystem

83/CATEGORIES — Categories Framework Subsystem

83/PRIVACY — Privacy Guidelines Framework Subsystem

83/INTEGRITY — Integrity Guidelines Framework Subsystem

83/SAFETY — Safety Guidelines Framework Subsystem

83/LEVEL — Safety Level Vertical Layering Subsystem

83/LATTICE — Lattice Horizontal Layering Subsystem

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

83.3 — Codewörter, Kategorien und Security Labels

In Abhängigkeit deklarierter Codewörter werden nun zudem erweiterte Zugriffsrechte auf Basis von Segmenten gegeben. Dabei gehört jedes Codewort einer »Kategorie« an, welche wiederum aus mehren Schutzstufen und Codewörtern besteht (Metadaten Security Verband). Dabei wird das Konzept für jedes »Asset«, freidefinierbare »Security Labels« ermöglichen. Die Schutzstufen selber werden hier, ebenfalls als Labels abgebildet. In Systematik ergibt sich somit ein horizontales auf Schichten basierendes Zugriffssystem mit Codewörtern, welche zugleich die vertikalen Schutzstufen bedingen. Um die Erfordernisse des multilateralen Zugriffs zu gewähren, muss die ausgegebene »Zugriffsklasse« (Klassifizierung) der »Keycard« stimmen und alle »Schutzstufen« und »Codewörter« müssen zudem in Übereinstimmung gebracht worden sein.

Ein Beispiel wird nötig. Ein Charakter möchte den Zeitpunkt der Fertigstellung eines Bauabschnittes unser allgemein bekannten Kirche in Erfahrung bringen. Unser Bauherr hatte die Bauphasen (Prozesse), also die Zugriffsklasse »Bauphasen«, auf eine gültige Signatur vgl. >>Signaturen ab S.161 & ff.<< auf den ausgegebenen Keycards »multilateral« beschränkt. Wenn nun ein Charakter mit persönlicher Keycard einen »Lesezugriff« auf die Zugriffsklasse »Bauphasen« initiiert, kann er prinzipiell auf diese Informationen zugreifen. Da der Bauherr jedoch zusätzlich ein »Sicherheitslevel« von mindestens der Stufe »6«, für die Anzeige von Informationen, die Aufschluss auf den Termin der Fertigstellung geben installiert hat, muss nun der Träger der Keycard, ebenfalls für die Vertrauensebene »6« akkreditiert sein. Unser Beispielcharakter hat diese Freigabe zwar, aber dennoch kann er die gewünschten Informationen nicht oder nur beschränkt einsehen. Der Grund liegt im fehlendem Codewort »Chiro« für das »Asset« -genau dieser Kirche (Objekt)-, sowie einem weiterem Codewort »Caiman« für den Bauprozess der in Phase »10«, befindlichen Fertigstellung. Kurz um, die Definition »Antares Confidential Policy« (ACP) erlaubt die Abfrage dieser Information nicht. Erst wenn alle Zugriffskriterien, also in der Keycard, die »Zugriffsklasse«, das »Sicherheitslevel«, sowie beide »Schlüssel« codiert wären, würden diese Information preisgegeben und abgerufen werden können.

83.4 — Verbundstufen und das Need-to-Know-Prinzip

Das Need-to-Know-Prinzip stellt sicher, dass Charaktere nur die Zugriffsrechte erhalten, die sie fuer ihre aktuelle Dedizierung tatsaechlich benoetigen. Ein Schmied braucht keinen Zugang zu diplomatischen Geheimdokumenten, und ein Spion benoetigt keine Bauphasen-Informationen — diese Trennung schuetzt nicht nur vor Spionage, sondern reduziert auch die Angriffsflaeche bei kompromittierten Keycards.

Aus diesem Aspekt heraus, ergeben sich somit unendlich viele »Verbundstufen«. Die Zugriffsflexibilität, kann so individuell wie das Vertrauen selbst akkreditiert werden. Anmerken möchte ich noch die »Kategorisierung des Informationsflusses« nach dem Prinzip des »notwendigem Wissens« (Need to know Principle). Hierbei werden einzelnen Charakteren nur die »Zugriffsrechte« eingeräumt, welche sie für die »Ausübung ihrer Dedizierung«, auch wirklich tatsächlich benötigen vgl. >>Berufsorientierte Spielweise (Dedizierung) ab S.231 & ff.<<.

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

83/REALM — MMA/SC Interface Security Model Sandbox Realm Subsystem

83/TRITENESS — Defense Command Interplay Systems Subsystem

83/CNCLMNT — Metagaming Concealment Control Subsystem

83/VOTE — Vote of Confidence Framework Subsystem

83/KEYCARD — Virtual Keycard Framework Subsystem

83/CLEARANCE — Authority Clearance Framework Subsystem

83/COMMAND — Command Chain Surveillance Subsystem

83/NTKPF — Need to Know Principle Framework Subsystem

83/WRKFLW — Workflows Rules Framework Subsystem

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

83.5 — Mandatory Access Control im MMO

So ist dieses A/ACS Modell, durch die Möglichkeiten die {{Antares Open World}}, auf dem Gebiet der inGame Community Security bieten wird, in all seinen Nuancen und sicherheitsrelevanten Aspekten, erstmals in einem MMO, mit Mandatory Access Control Schnittstellen, für die Spielmechanik im Gameplay konzipiert. Die Chance »Sicherheitslücken« auszunutzen, werden somit auf die Komponenten des Vertrauens im Metagaming reduziert. {{Antares Open World}} bietet hier multilaterale Instrumente der Steuerung für die Politik des Informationsflusses.

Siehe auch

DSGN_051_SIGNATURES.md — Signaturen
DSGN_068_PROFESSION_ORIENTED_GAMEPLAY_CORE.md — Berufsorientierte Spielweise (Dedizierung)
DSGN_080_ASSET_MANAGEMENT_ACHIEVEMENT.md — Asset Management & Achievement
DSGN_094_SECURITY_ASSESSMENTS.md — Sicherheitsbewertungen & Spionage
DSGN_097_COMBAT_SYSTEM_CORE_MECHANICS.md — Kampfsystem

Module: Ase Docs 00.16.32 [feat] Author: Jan Ohlmann (antarien.com@gmail.com) Co-Author: Claude Code (Anthropic) Created: 2026-02-21 Updated: 2026-02-22 Status: Kuratierte Version — Rollen & Rechteverwaltung (PortalViewer DSL)