Tenant trennt Organisationen und Daten. Project wählt Mitgliedschaft, Schema und Ausführungsscope innerhalb des Tenant. Das aktive Project ist eine signierte, servervalidierte Session-Entscheidung, kein kosmetischer Filter.
Sicherheit und Governance
Sicherheitsentscheidungen bleiben servereigen und scopegebunden.
Sichtbarkeit im Browser ist keine Autorisierungsgrenze. Geschützte Routen, Anwendungsdienste und Repository-Prädikate bewerten Identität, Tenant, Project und Berechtigungen dort erneut, wo die Operation es erfordert.
Sicherheit und Governance
Jede authentifizierte Anfrage muss zu einer aktiven, aktorgebundenen Registry-JTI, zum Tenant- und Nutzerstatus, zur Laufzeit der aktuellen Richtlinie, zum Inaktivitäts-Timeout und zum aktiven Project-Kontext passen. Registry-Fehler, fehlendes Signaturmaterial, Widerruf oder Identitätsabweichung führen fail-closed zum Abbruch statt zu einem anonymen oder veralteten Browserkontext.
Tenant-SAML-Metadaten, Login und ACS, externe Identitätsverknüpfung/JIT, Domain-Richtlinie und vom IdP bestätigte MFA-Nachweise sind implementiert. Die Endpoint-Erzeugung verwendet den serverseitigen öffentlichen Origin; die AuthnRequest-Korrelation nutzt kurzlebigen, signierten und an Provider sowie Anfrage gebundenen Status.
Analytics RLS ist servereigen und geschützt. Ein clientseitiger Runtime-Filter kann keine RLS-Origin-Metadaten fälschen; Cache-Identitäten enthalten Berechtigungs- und RLS-Scope und verlassen sich nicht nur auf SQL-Text.
Zugangsdaten, Tokens, Authorization Headers, private Schlüssel und Signed-URL-Material gehören nicht in öffentliche Metadaten, Chat-Prompts oder generische Audit-Payloads. Maskierter Text ist kein nutzbares Credential. Eine einmalige Offenlegung ist begrenzt, bei Transport und Speicherung konfigurationsgemäß verschlüsselt, kurzlebig und protokolliert; das Secret wird nicht in generischen Nachweisen persistiert.
Tenant und Project bilden den aktiven Sicherheitskontext.
Tenant trennt Organisationen und Daten. Project wählt Mitgliedschaft, Schema und Ausführungsscope innerhalb des Tenant. Das aktive Project ist eine signierte, servervalidierte Session-Entscheidung, kein kosmetischer Filter.
Die Session-Registry ist nach der Anmeldung maßgeblich.
Jede authentifizierte Anfrage muss zu einer aktiven, aktorgebundenen Registry-JTI, zum Tenant- und Nutzerstatus, zur Laufzeit der aktuellen Richtlinie, zum Inaktivitäts-Timeout und zum aktiven Project-Kontext passen. Registry-Fehler, fehlendes Signaturmaterial, Widerruf oder Identitätsabweichung führen fail-closed zum Abbruch statt zu einem anonymen oder veralteten Browserkontext.
Ein Project-Wechsel ist eine CSRF-geschützte Serveraktion, die den Kontext neu ausstellt, ohne die ursprüngliche Token- oder Richtlinienlaufzeit zu verlängern.
Logout ist ein CSRF-geschützter POST; Passwortänderung, Passwort-Reset und Kontolöschung widerrufen aktive Sessions.
JSON-Anfragen erhalten einen strukturierten Authentifizierungsfehler und Cookie-Löschung; Browsernavigation löscht den Kontext vor der Weiterleitung.
SAML wird mit expliziten Grenzen bereitgestellt.
Tenant-SAML-Metadaten, Login und ACS, externe Identitätsverknüpfung/JIT, Domain-Richtlinie und vom IdP bestätigte MFA-Nachweise sind implementiert. Die Endpoint-Erzeugung verwendet den serverseitigen öffentlichen Origin; die AuthnRequest-Korrelation nutzt kurzlebigen, signierten und an Provider sowie Anfrage gebundenen Status.
SAML erzeugt keine Project-Mitgliedschaft; der Nutzer benötigt weiterhin autorisierten Tenant- und Project-Zugriff.
TOTP auf Anwendungsebene, WebAuthn, Recovery-Challenges sowie eine vollständige Session-Inventar-/Revoke-all-Oberfläche gehören derzeit nicht zum Funktionsumfang.
Eine nicht unterstützte Passwort-MFA-Richtlinie wird abgewiesen, statt als unwirksame Kontrolle gespeichert zu werden.
RLS und Runtime-Filter sind nicht austauschbar.
Analytics RLS ist servereigen und geschützt. Ein clientseitiger Runtime-Filter kann keine RLS-Origin-Metadaten fälschen; Cache-Identitäten enthalten Berechtigungs- und RLS-Scope und verlassen sich nicht nur auf SQL-Text.
Secrets bleiben außerhalb generischer Nachweise.
Zugangsdaten, Tokens, Authorization Headers, private Schlüssel und Signed-URL-Material gehören nicht in öffentliche Metadaten, Chat-Prompts oder generische Audit-Payloads. Maskierter Text ist kein nutzbares Credential. Eine einmalige Offenlegung ist begrenzt, bei Transport und Speicherung konfigurationsgemäß verschlüsselt, kurzlebig und protokolliert; das Secret wird nicht in generischen Nachweisen persistiert.
Die aktuelle IAM-Stärke wird präzise benannt.
Modulspezifische Berechtigungsverträge bestehen, aber eine universelle persistierte Negativberechtigung und ein plattformweiter DENY-wins-Merge sind nicht vollständig. Application MFA und Step-up-Verhalten dürfen nicht über aktuelle Identity-Provider- und Session-Kontrollen hinaus behauptet werden.
Nächster Schritt
Beginnen Sie mit dem Datenfluss, der keine Unklarheit zulässt.
Bringen Sie die relevanten Systeme, Verantwortlichen, Regeln, Lieferverpflichtungen und Nachweisanforderungen ein.
Kritischen Datenfluss besprechen