Schnittstellen nach Rolle und Zugriff

1) Grundsätze

1. Sicherheit = UX-Aufgabe. Der Benutzer muss klar verstehen, was er ohne „Grauzonen“ tun kann und was nicht.
2. Erforderliche Mindestrechte. Von der Anzeige bis zu den Aktionen ist alles auf die Aufgaben der Rolle beschränkt.
3. Signal statt Verbot. Wenn es keinen Zugang gibt - wir erklären, warum und wie man (Anfrage, Anwendung, Training) erhält.
4. Duplizierung auf dem Server. UI-Guards ersetzen niemals Serverprüfungen.
5. Transparentes Audit. Jede sensible Handlung hinterlässt eine lesbare Spur.

2) Zugriffskontrollmodelle

RBAC (Role-Based): feste Rollen: Spieler, Sapport, Finanzen, Risiko/Compliance, Affiliate Manager, Moderator, Admin.
ABAC (Attribute-Based): Attributbasierte Richtlinie (Zuständigkeit, Marke, Zeitzone, VIP-Ebene, Team, Wechsel).
ReBAC (Relationship-Based): beziehungsbasierter Zugang (Spielerkurator, Ticketinhaber, Partner Manager).
SoD (Segregation of Duties): Trennung kritischer Aufgaben (erstellt ≠ genehmigt).

Praxis: RBAC als Basis, ABAC für Feinabstimmung (Marke/Region), SoD für Finanzen/Limits, ReBAC - punktuell (kuratierte Portfolios).

3) Feature Map nach Rolle (Beispiel iGaming)

4) UX-Muster für Rechte und Rollen

4. 1 Navigation und Sichtbarkeit

Verstecken Sie unzugängliche Abschnitte aus der Navigation (Geräuschreduzierung), aber zeigen Sie informative „leere“ Karten, wenn dies hilft, die Möglichkeiten zu verstehen.
Für vorübergehend nicht verfügbar - „Lock“ mit einem Hinweis: Grund, Anforderungen, CTA „Request Access“.

4. 2 Aktionszustände

Disabled + tooltip: "Die Rolle Finanzen ist erforderlich. Zugriff beantragen".
Read-only-Modus: Felder „unter Glas“, explizite Markierung „Nur lesen“.
Eskalation: Schaltfläche „Zur Genehmigung senden“ statt „Anwenden“.

4. 3 Maskieren und Bearbeiten

PII (E-Mail, Telefon, Adresse) - „user @“., „+ 380 90“ für fremde Einträge.
PAN/IBAN - nur Token/letzte 4.
Schalter „Vollständig anzeigen“ - nur für besitzende Rolle/nach Ereignis mit Prüfung.

5) Architektur der Berechtigungen in der Benutzeroberfläche

Policy-Kontext auf dem Client: Berechtigungscache (TTL kurz) + Update-Abonnement.
Route Guards: Unzugängliche Routen → 403-Seite mit Erklärung und CTA.
Komponenten-Wachen: 'Can ({action:' approve _ withdrawal', Ressource: 'payout'})'.
Ficheflags: experimentelle/saisonale Dinge - getrennt von Rechten.

tsx type Permission = string; // 'payout.approve', 'kyc.view_masked'
type Policy = { has:(p:Permission)=>boolean };
const PolicyCtx = React.createContext<Policy>({ has:()=>false });
export const Can: React.FC<{perm:Permission, children:React.ReactNode, fallback?:React.ReactNode}>
= ({perm, children, fallback=null}) => {
const { has } = React.useContext(PolicyCtx);
return has(perm)? <>{children}</>: <>{fallback}</>;
};

6) Server> Client

Jede Aktion wird vom Server durch ein Token mit Stempeln (Rolle, Attribute) bestätigt.
Die Richtlinien sind zentralisiert (PDP/OPA/Cedar/Zanzibar-like), die Benutzeroberfläche erhält nur eine Lösung.
Alle kritischen Operationen - Zwei-Faktor-Bestätigung + Audit.

7) Maskierung und rote Datenbereiche

• PII: Name, E-Mail, Telefon, Adresse, Geburtsdatum.
• Finanzen: PAN/IBAN/Krypto-Wallets, Beträge, Limits, Bonusguthaben.
• Dokumente: Pässe/ID/Selfie (KYC).
• Spiel: Geschichte der Wetten/Gewinne/Muster.

• Vollständig - Besitzende Rolle/Besitzer des Datensatzes.
• Maskiert - Sapport, Finanzen (nicht Eigentümer).
• Aggregiert - Analytik (ohne Bezeichner).

tsx function Redact({text, perm}:{text:string, perm:Permission}){
const { has } = React.useContext(PolicyCtx);
return <span>{has(perm)? text: text.replace(/.(?=.{4})/g,'•')}</span>;
}

8) Genehmigungsströme (Approvals) und SoD

Vier Augen: der Initiator ≠ der Bejahende.
Mehrstufige Routen (z.B. Summen> X → 2. Linie).
Gültigkeit der Anträge, SLA, Eskalation.
Magazin: Wer schuf, wer änderte, wer genehmigte wann und woher.

Beispiele: Bestätigung des Rückzugs, Änderung der Spielerlimits, KYC-Urteil, Aufhebung der Sanktionsflagge.

9) Die Besonderheiten von iGaming

Limits und Selbstausschluss: Änderung nur mit SoD und verbindlicher Benachrichtigung des Nutzers.
KYC/AML: Zugang zu Dokumenten - enge Rolle; Vorschau von Miniaturen, Vollformat - durch eine separate Aktion mit einem Protokoll.
Sanktions-/PP-Flaggen: sichtbar für das Risiko-Team; sapport - nur der Status „muss überprüft werden“.
Zahlungen/Schlussfolgerungen: „halten/ablehnen“ - nur Rolle Finanzen; Beträge über dem Schwellenwert - doppelte Bestätigung.
Wettprotokolle: Sapport liest, aber bearbeitet nicht; Anpassungen sind eine separate Funktion mit Untersuchung.

10) Lokalisierung, A11y, RTL

Die Texte „kein Zugriff“ sind lokalisiert und enthalten gültige Pfade (Bewerbung/Schulung).
Fokusmanagement: Übertragen Sie den Benutzer nicht ohne Erklärung auf eine „leere“ Seite.
Der RTL-Modus wird für Rollen in den jeweiligen Regionen unterstützt.
A11y: 'aria-disabled' + Erklärung, Tastaturverfügbarkeit der Eskalation.

11) Zustände und Fehler

403 (keine Rechte): freundliche Seite mit Rollenkontext und CTA „Zugriff anfordern“.
404 (keine Ressource): die Existenz von versteckten Objekten nicht offenbaren.
413/422 (zu viel/Validierung): keine Details der Politik zusammenführen, neutral formulieren.
Rate-Limits/Sperren: Erklären Sie den Timer/die Entsperrbedingung.

12) Metriken

Access Denied Rate: Anteil der Fehler nach Rolle/Bildschirm (Signal für schlechte IA oder Richtlinie).
Approval SLA: Median der Genehmigungszeit nach Threads (Output, Limits, KYC).
Mask Reveal Events: Häufigkeit der PII „Enthüllungen“ (erwartungsgemäß gering und gerechtfertigt).
Error-to-Resolution: Zeit von 403 bis zum erteilten Zugriff.
Least-Privilege Drift: Rollen mit redundanten Rechten (Nutzungsdetail).

13) Anti-Muster

Fehler unter „nichts ist passiert“ zu verbergen.
Leere Schaltflächen ohne Erklärung anzeigen.
Maskieren Sie den Besitzer seiner eigenen Daten.
Verlassen Sie sich auf UI-Wachen ohne Server-Richtlinien.
Mischen Sie Ficheflags mit Zugriffen (verschiedene Aufgaben).
Geben Sie dem Sapport aus Bequemlichkeit einen „Gott-Modus“.

14) Design-System-Token (Beispiel)

json
{
"access": {
"badge": { "viewer":"#607D8B", "editor":"#4CAF50", "approver":"#FF9800", "admin":"#9C27B0" },
"lockColor": "#9E9E9E",
"maskChar": "•"
},
"states": {
"noAccess": { "bg":"var(--bg-elev)", "border":"var(--border)", "icon":"#9E9E9E" },
"approval": { "pending":"#FFC107", "approved":"#4CAF50", "rejected":"#F44336" }
},
"a11y": { "ariaDisabled": true, "explainDenial": true }
}

15) UI Snippets

tsx import { Navigate, Outlet } from 'react-router-dom';
function GuardedRoute({perm}:{perm:Permission}){
const { has } = React.useContext(PolicyCtx);
if (has(perm)) return <Outlet/>;
return <Navigate to={`/403?perm=${encodeURIComponent(perm)}`} replace/>;
}

html
<article class="no-access">
<h3>Недостаточно прав</h3>
<p>Доступ к разделу «Выплаты» доступен ролям: Финансы/Админ.</p>
<button class="btn" data-open-request>Запросить доступ</button>
</article>

json
{
"ts": "2025-11-03T18:45:12Z",
"actor": "u_5412",
"action": "payout.approve",
"target": "withdraw#w_91822",
"ip": "194...12",
"result": "success"
}

16) QS-Checkliste

Navigation und IA

• Unzugängliche Abschnitte machen im Menü keinen Lärm.
• Es gibt klare Seiten/„ no access “Karten mit CTA.

Aktionen und Wachen

• Schaltflächen ohne Rechte - 'deaktiviert' + tooltip/Text.
• Die Routes sind geschützt; Direkte URL → 403 mit Erklärung.
• Der Server bestätigt jede Aktion.

Daten

• PII/PAN/KYC werden durch die Politik maskiert.
• Die Protokolle der „Enthüllungen“ werden geschrieben und gebrüllt.
• Export/Berichte entsprechen der Rolle (Aggregate für Analysen).

SoD/Approvals

• Der Initiator kann seinen Antrag nicht genehmigen.
• Schwellenwerte → mehrstufige Routen.

A11u/Lokalisierung

• „Kein Zugriff“ ist lokalisiert; Tastaturnavigation funktioniert.
• Kontrast/Fokusringe entsprechen AA.

Zuverlässigkeit

• Cache von Genehmigungen mit kurzer TTL; Behinderung beim Rollenwechsel.
• PDP → UI-Drop arbeitet im Modus „Default-Safe“.

17) Dokumentation im Konstruktionssystem

Компоненты: `GuardedRoute`, `Can`, `NoAccessCard`, `ApprovalBanner`, `Redact`.
Richtlinien: Rollen-/Aktionsmatrix, SoD-Regeln, Maskierungsebenen.
Prozess: Zugriffsanfrage, Rollentraining/Zertifizierung, Rechteüberprüfung alle N Wochen.
Do/Don 't-gallery: "leere Buttons ohne Grund", "Masking the Owner", "UI ohne Server-Checks" gegen "erklärte Einschränkungen und CTAs'.

Kurze Zusammenfassung

Rollenschnittstellen sind eine verständliche Informationsarchitektur + strenge Richtlinien + freundliche Erklärungen. Zeigen Sie nur das, was Sie brauchen, maskieren Sie sensible Daten, schützen Sie Routen und Aktionen der Wachen, erfassen Sie jedes kritische Ereignis im Audit und teilen Sie Verantwortlichkeiten dort auf, wo es Geld und Compliance betrifft. Bei iGaming reduziert dies nicht nur die Risiken, sondern macht auch die Arbeit der Teams schneller und entspannter.