S•U•S•I - Qualitätsmanagement für immoSoR

Fail-Closed · Strikter Systemschutz

Fail-Closed bedeutet: Fehlt eine zwingende Voraussetzung, wird die betroffene Handlung oder Wirkung abgewiesen. Ein unbekannter, widersprüchlicher oder nicht eindeutig gebundener Zustand wird niemals still als zulässig interpretiert.

Das System wartet nicht darauf, dass ein unsicherer Vorgang später fehlschlägt. Es verhindert ihn bereits am Eingang. Die Ablehnung erfolgt serverseitig, nachvollziehbar, ursachenbezogen und mit einem definierten Fehlerstatus.

Eine ausgeblendete Schaltfläche ist kein Fail-Closed-Schutz. Route, Middleware, Controller, Service und Datenzugriff müssen dieselbe Schutzentscheidung respektieren.

Mandantentrennung

Jede fachliche Handlung bleibt an den richtigen Mandanten gebunden. Die company_id beziehungsweise Organisationsbindung begrenzt Datenraum, Rollenbindung, Arbeitskontext, Ressourcen und Nachweise.

Ein Nutzer aus Mandant A darf keine Daten aus Mandant B erreichen. Fremde Mandantenwerte aus Request, URL, Session oder manipulierten Parametern werden nicht übernommen.

Ist der Mandant nicht eindeutig feststellbar, wird die Handlung abgewiesen. Ein früherer Tagesstatus aus einem anderen Mandanten darf nicht wiederverwendet werden.

Rollenbindung

Eine angemeldete Identität allein reicht nicht aus. Die aktive Rolle muss vorhanden, gültig, dem Mandanten zugeordnet, zeitlich wirksam und zum aktuellen Arbeitskontext passend sein.

Mehrfachrollen werden nicht zu einer gemeinsamen Vollmacht vereinigt. Für jeden Request gilt genau ein aktiver Rollen- und Arbeitskontext.

Nach einem Rollenwechsel werden sämtliche Capabilities und Scopes neu aufgelöst. Alte Tabs und Deep Links werden erneut geprüft. Fehlt die gültige Rollenbindung, wird der Zugriff verweigert.

Capability-Schutz

Eine Rolle beschreibt den Arbeitsbereich, aber noch nicht jede zulässige Handlung. Jede geschützte Funktion benötigt deshalb eine konkrete Capability.

Dazu können das Lesen eines Dashboards, das Bearbeiten eines eigenen Objekts, das Einreichen einer eigenen Empfehlung, das Lesen eines Audits oder das Ausführen eines kontrollierten Rollbacks gehören.

Eine unbekannte Capability wird abgewiesen. Eine sichtbare Funktion erzeugt keine Capability. Auch ein Super-Admin darf nicht pauschal als Rolle behandelt werden, die ohne weitere Prüfung alles ausführen darf.

Sensible Maßnahmen benötigen zusätzlich einen ausdrücklichen Mandantenkontext, gegebenenfalls Re-Authentifizierung und eine vollständige Auditspur.

Ressourcen- und Datenscope

Eine Capability allein genügt nicht. Auch die konkrete Ressource muss zum zulässigen Scope gehören.

Mögliche Scopes sind own, assigned, object, referral, case, company oder system.

Ein Makler darf nur eigene oder zugewiesene Objekte öffnen. Ein Empfehlungspartner darf nur eigene Empfehlungen und Nachweise sehen. Eine Assistenz darf nur gültig zugewiesene Vorgänge bearbeiten.

Fremde IDs führen zu HTTP 403 oder 404. Ein Service darf nicht nach einer erfolgreichen Routenprüfung ungebunden über eine frei übergebene ID auf fremde Ressourcen zugreifen.

Sichere Sitzung und Kontextbindung

Die Sitzung muss zum Nutzer, Mandanten und aktiven Arbeitskontext passen. Nach einem Rollen- oder Mandantenwechsel werden alte Sitzungsstände neu bewertet.

Manipulierte Sessionwerte dürfen keine Rechte erzeugen. Veraltete Fortsetzungsakten werden nicht übernommen. Ein fremder oder unklarer Fortsetzungszustand wird abgewiesen.

Bei einer unsicheren Sitzung darf der Tagescheck keine grüne Gesamtstellungnahme erzeugen. Fehlende Sitzungssicherheit ist ein kritischer Schutzbefund.

Wirtschaftssperre

Während sämtlicher QM-Läufe bleibt die wirtschaftliche Wirkung gesperrt. Der Wirtschaftsmodus lautet:

LOCKED

Der Prüflauf erzeugt keine Forderung, keine Provision, keine Auszahlung, keine Rechnung, keine Gutschrift, keine wirtschaftliche Anerkennung und keine Produktivfreigabe.

Kann der Status LOCKED nicht bestätigt werden, wird der Prüfschritt nicht als erfolgreich gewertet. Wirtschaftliche Sicherheit arbeitet immer Fail-Closed.

Ein grüner technischer Befund ersetzt keine kaufmännische Freigabe.

Fail-Closed bei externer Wirkung

Auch externe Wirkungen benötigen einen kontrollierten Vertrag. Dazu gehören E-Mail, Push, Zustellung, öffentliche Veröffentlichung, Stripe, SEPA, Rechnung und Auszahlung.

Fehlende Idempotenz, unklare Zuordnung oder unvollständige Evidenz führen zum Abbruch. Es gibt keinen stillen Ersatzweg und keine verdeckte Teilfreigabe.

Die technische Regel bleibt eindeutig: Schlüssel, Mandant, Asset, Release und Freigabestatus müssen konsistent sein. Bei Fehlern wird geschlossen geantwortet.

Fail-Closed bedeutet nicht automatisch Gesamtsperre

Ein kritischer Befund soll möglichst auf die tatsächlich betroffene Funktion begrenzt bleiben.

Ist etwa eine Objektfreigabe unsicher, wird die Objektfreigabe gesperrt. Bleibt das allgemeine Dashboard sicher, kann es weiterhin erreichbar sein.

Das System unterscheidet betroffene Funktion, unbetroffene Arbeitsbereiche, technische Auswirkung und notwendige Maßnahme.

Fail-Closed schützt damit präzise und verhältnismäßig. Aus einem begrenzten Befund soll keine unnötige Vollsperre entstehen.

Fail-Open · Freiwilligkeit und Nutzbarkeit

Fail-Open gilt für das freiwillige Angebot des täglichen QM-Laufs. Wird der Test verschoben, für den Tag ausgeblendet oder nicht gestartet, bleibt die allgemeine Systemnutzung grundsätzlich möglich.

Der Nutzungsentscheid wird nicht als Fehler interpretiert. Es entsteht kein negativer Nutzerstatus. Die freiwillige Tagesprüfung ist eine Unterstützung und kein Zugangstor.

Der Nutzer behält die Entscheidung über Zeitpunkt und Teilnahme.

Die freiwillige Einladung

S•U•S•I bietet den Tagescheck freundlich und nicht alarmistisch an. Das Angebot erklärt Zweck, Dauer, Umfang, Neutralität und Nachweisform.

Der Nutzer kann zwischen Jetzt starten, Später erinnern und Heute nicht wählen.

Alle drei Möglichkeiten sind legitime Entscheidungen. Keine Option darf versteckt oder beschämend gestaltet werden. Die Auswahl wird nur so weit gespeichert, wie es für die Hinweissteuerung erforderlich ist.

Jetzt starten

Mit Jetzt starten eröffnet der Nutzer den Prüflauf ausdrücklich. Der Lauf wird an den aktuellen Tages-Key gebunden und erhält Run-ID, Mandant, Rolle, Nutzer sowie App- und Funktionsregister-Version.

Der Start ist freiwillig. Die Prüfbedingungen innerhalb des Laufs sind anschließend jedoch strikt.

Mandanten-, Rollen-, Scope- und Wirtschaftsschutz arbeiten während des gesamten Tests Fail-Closed. Fail-Open betrifft die Teilnahmeentscheidung, nicht die Qualität oder Sicherheit der Ausführung.

Später erinnern

Eine Verschiebung erlaubt die unmittelbare Fortsetzung der normalen Arbeit. Es erfolgt höchstens eine angemessene Erinnerung am selben Tag.

Es gibt kein permanentes Pop-up, keinen Countdown-Zwang, keine wiederholte Unterbrechung und keine Eskalation.

Der Status ist eine Nutzungsentscheidung und kein gelber oder roter Systembefund. Rechte, Zugang und Datenprojektion bleiben unverändert.

Heute nicht

Mit Heute nicht wird die Einladung für den aktuellen Tageskontext beendet. Ein Seitenwechsel oder erneuter Login im selben Kontext aktiviert sie nicht erneut.

Der Zustand gilt nur für den gebundenen Nutzer, Mandanten, die aktive Rolle, das Datum und die maßgeblichen Versionen.

Es entstehen keine Zugangssperre, Leistungsbewertung, Anwesenheitsinterpretation oder wirtschaftliche Folge.

Heute nicht ist kein technischer Fehler.

Kein negativer Nutzerstatus

Aus einer freiwilligen Entscheidung dürfen keine personenbezogenen Bewertungen entstehen. Unzulässig sind Einstufungen wie Prüfung verweigert, unkooperativ, geringe Compliance, verspätet geprüft oder geringe Beteiligung.

Zulässig ist ausschließlich die sachliche Steuerinformation: angeboten, gestartet, später erinnern oder für heute ausgeblendet.

Diese Daten dienen nicht der Personalführung und dürfen nicht in Rankings, Vergütungsmodellen oder Anwesenheitsauswertungen verwendet werden.

Fail-Open hält den Arbeitsfluss offen

Das QM darf den Arbeitstag nicht blockieren, nur weil der Nutzer den freiwilligen Check nicht sofort ausführt. Aufgaben, Termine und Fachvorgänge bleiben grundsätzlich erreichbar.

S•U•S•I zieht sich nach der Entscheidung zurück. Der Nutzer wird nicht gezwungen, vor jeder fachlichen Handlung einen Test zu durchlaufen.

Damit bleibt das Qualitätsmanagement unterstützend und verhältnismäßig.

Freiwilliger Start, strenge Ausführung

Der Kernmechanismus lautet:

QM-Teilnahme → freiwillig und Fail-Open

Mandant, Rolle, Capability, Scope und Wirtschaft → zwingend und Fail-Closed

Der Nutzer entscheidet, ob der Tagescheck läuft. Das System entscheidet nicht frei darüber, ob Schutzregeln gelten.

Nach dem freiwilligen Start werden sämtliche technischen Grenzen strikt geprüft. Wird eine Grenze verletzt, wird die betroffene Handlung abgewiesen.

So verbinden sich Freiheit und Sicherheit ohne Widerspruch.

Kein Schutz durch Zwang

Ein erzwungener Tagescheck würde nicht automatisch mehr Systemsicherheit schaffen. Sicherheit entsteht durch serverseitige Guards, Capability-Prüfung, Scope-Bindung, sichere Sitzungen, neutrale Tests und Auditspuren.

Zwang gegenüber dem Nutzer ersetzt keine technische Architektur. Das QM-Angebot kann deshalb freiwillig bleiben, während die Schutzarchitektur strikt arbeitet.

Keine Freiheit durch gelockerte Sicherheit

Fail-Open darf nicht bedeuten, dass fremde Daten zugänglich werden, Rollenprüfungen entfallen, unklare Mandanten akzeptiert oder Wirtschaftssperren aufgehoben werden.

Nutzerfreiheit besteht innerhalb eines sicher begrenzten Arbeitsraums. Ein nicht gestarteter Tagescheck erweitert keine Berechtigung.

Das System bleibt in jedem Fall an seinen bestehenden Sicherheitsvertrag gebunden.

Unterschiedliche Reaktion auf Unsicherheit

Bei einer freiwilligen Entscheidung gilt:

Keine Auswahl oder Ablehnung → Zugang bleibt grundsätzlich offen

Bei einer unklaren Schutzbedingung gilt:

Mandant, Rolle, Capability oder Scope unklar → betroffene Handlung wird blockiert

Diese unterschiedliche Behandlung ist gewollt. Sie verhindert sowohl unnötigen Nutzungszwang als auch unsichere Freigaben.

Kritischer Befund trotz abgelehntem Tagescheck

Auch nach Heute nicht können unabhängig erkannte kritische Systemprobleme wirksam werden. Dazu gehören etwa bekannte Mandantenvermischung, abgelaufene Rollenbindung, unsichere Sitzung oder eine nicht bestätigte Wirtschaftssperre.

Die betroffene Funktion darf dann Fail-Closed gesperrt werden.

Dieser Hinweis ist keine wiederholte QM-Einladung, sondern eine direkte Reaktion auf einen realen Schutzbefund. Die Ursache muss verständlich benannt werden.

Rollenwechsel und Tagesentscheidung

Eine Fail-Open-Entscheidung gilt nur für den gebundenen Tageskontext. Wechselt der Nutzer den Mandanten, die Rolle oder eine relevante App- oder Registerversion, entsteht ein neuer Kontext.

Für diesen neuen Kontext kann erneut ein freiwilliges Angebot erscheinen. Die frühere Ablehnung wird nicht gelöscht oder negativ umgedeutet.

Rechte werden beim Wechsel vollständig neu aufgelöst.

Getrennte technische Zustandsmodelle

Nutzerentscheidung und technischer Prüfbefund dürfen nicht in einem einzigen Statusfeld vermischt werden.

Eine sinnvolle Trennung lautet:

invitation_status: offered · remind_later · dismissed_today · accepted

run_status: prepared · running · completed · failed · interrupted

security_status: safe · warning · critical

Dadurch wird eine Ablehnung niemals versehentlich als technischer Fehler dargestellt. Ebenso kann ein Schutzbefund unabhängig von der Nutzerentscheidung korrekt behandelt werden.

Governance und Datenschutz

Fail-Open schützt auch vor einer verdeckten Personenbewertung. Die Teilnahmehäufigkeit darf nicht als Leistungskriterium verwendet werden.

Fail-Closed schützt vor unzulässigem Datenzugriff und wirtschaftlicher Wirkung.

Gemeinsam unterstützen beide Prinzipien Zweckbindung, Datenminimierung, arbeitsrechtliche Neutralität und technische Nachvollziehbarkeit.

Das Arbeitsprotokoll dokumentiert den Systemzustand, nicht die Kooperationsbereitschaft des Nutzers.

Bedeutung für Cron und Agent

Hintergrund-QM, Cron und Agent arbeiten nicht automatisch nach demselben Fail-Open-Modell wie die freiwillige Einladung.

Automatische Prüfungen benötigen einen freigegebenen Betriebsvertrag, einen definierten Scope, ein versioniertes Register sowie Audit- und Rückfalllogik.

Bei unklarem Kontext starten sie nicht. Der Agent darf technische Läufe überwachen, aber keine Schutzgrenzen lockern.

Eine spätere persönliche Vor-Dienstbeginn-Automatik benötigt zusätzlich eine ausdrückliche Zustimmung.

Bedeutung für Oberfläche und Systemarchitektur

Die Oberfläche muss beide Prinzipien sichtbar respektieren.

Beim freiwilligen Angebot gelten ruhige Sprache, gleichwertige Wahlmöglichkeiten und der Verzicht auf Drohung oder manipulative Dringlichkeit.

Beim Schutzbefund müssen Ursache, betroffene Funktion, nachvollziehbare Sperre und nächste Maßnahme klar benannt werden.

Freiwilligkeit darf nicht wie ein Sicherheitsfehler aussehen. Eine Sicherheitssperre darf umgekehrt nicht als bloß optionale Empfehlung erscheinen.

Die technische Entscheidungskette lautet:

Identität → Mandant → aktiver Kontext → Rollenbindung → Capability → Ressourcenscope → zulässiger Zustand → Handlung → Audit

Alle sicherheitsrelevanten Glieder arbeiten Fail-Closed. Die vorgelagerte Entscheidung über den freiwilligen Tagescheck arbeitet Fail-Open.

Diese Trennung muss in Middleware, Services, Datenmodell, Statuslogik, Benutzeroberfläche und Audit nachvollziehbar bleiben.