Ein Angriff darf nicht erst dann zum Sicherheitsproblem werden, wenn Daten bereits gelesen, gebündelt oder übertragen werden. immo.quick setzt zwei unabhängige Grenzen: eine vor dem Eintritt in die relevante Governance-Logik und eine unmittelbar vor dem realen Effekt.
Klassische Sicherheitsmodelle beantworten sehr gut, wer sich authentifiziert hat, welche Rolle ein Konto besitzt und ob ein Ereignis auffällig wirkt. Die entscheidende Frage liegt jedoch tiefer: Kann ein technisch erreichbarer Pfad tatsächlich eine produktive Wirkung erzeugen? immo.quick trennt Zugang, Autorität und Ausführung bewusst voneinander.
Vor der eigentlichen Governance- und Compliance-Pipeline steht ein eigener fail-closed Access Guardian. Ein Request muss die geforderten Eintrittsbedingungen vollständig erfüllen, bevor nachgelagerte Entscheidungslogik überhaupt erreichbar wird. Fehlende Pflichtinformationen, nicht frische Zustände oder nicht valide kryptografische Herkunft führen zur Verweigerung vor der Pipeline.
Am Edge muss ein Client zunächst kryptografisch nachweisen, dass er für die angefragte Surface registriert und aktuell legitimiert ist. Erst danach folgen Governance-Gates und Execution Rights. Selbst ein erfolgreich attestierter Client erhält damit noch keine freie Ausführungsautorität. Wirkung setzt ein gültiges, aktuelles, scope-konformes Execution Right und eine daraus abgeleitete gültige Capability voraus.
Eine erfolgreiche Authentifizierung beweist eine Identität oder einen Client-Zustand. Sie autorisiert nicht automatisch jede nachgelagerte Handlung.
Dass eine Ressource technisch erreichbar ist, bedeutet nicht, dass der aktuelle Request oder die aktuelle Capability sie nutzen darf.
Lesen ist nicht Exportieren. Einzelzugriff ist nicht Bulk-Transfer. Administration ist nicht Exfiltration. Jede Wirkung bleibt an ihren eigenen zulässigen Umfang gebunden.
immo.quick setzt nicht voraus, dass ein Analyst einen Angriff rechtzeitig erkennt, bevor Schaden entsteht. Wo eine ungültige Eintritts- oder Ausführungsbedingung festgestellt wird, ist die primäre Reaktion die Verweigerung. Forensische Erfassung, Rekonstruktion und interne Incident-Prozesse dokumentieren anschließend, was versucht wurde und an welcher Grenze der Vorgang endete.
Detection bleibt wertvoll. Sie ist aber nicht die letzte Autorität darüber, ob ein Effekt stattfinden darf.
Keine Architektur kann seriös garantieren, dass kein Angreifer jemals einen technischen Kontaktpunkt erreicht, keine Zugangsdaten gestohlen werden oder keine Zero-Day-Schwachstelle existiert. immo.quick behauptet deshalb nicht, allgemeine Netzwerk-, Endpoint- oder organisatorische Cybersicherheit zu ersetzen.
Der überprüfbare Architekturanspruch ist enger und stärker: ungültige Requests sollen die relevante Governance-Logik nicht erreichen; und Zugang allein soll keinen realen Effekt autorisieren. Wo erforderlicher Zustand fehlt, veraltet, widerrufen, außerhalb des Scopes oder über einen nicht zugelassenen Pfad kommt, wird fail-closed verweigert.
Es beschreibt zwei getrennte Sicherheitsgrenzen: Eine vorgelagerte Admission Boundary soll ungültige Requests stoppen, bevor relevante Governance-Logik erreicht wird. Eine davon unabhängige Execution-Rights-Boundary soll verhindern, dass Zugang allein einen realen Effekt autorisiert.
Authentifizierung, Rolle oder technische Erreichbarkeit reichen in der Architektur nicht automatisch für Ausführung. Ein realer Effekt setzt eine aktuell gültige, scope-gebundene Ausführungsgrundlage voraus.
Ausschließlich die Architektur der immo.quick Serverless Edition wurde dem BSI am 28.07.2026 nachweislich zur technischen Befassung übergeben. immo.quick Core wurde dem BSI nicht vorgelegt. Daraus folgt keine BSI-Prüfung, Zertifizierung oder Anerkennung.
Nein. Netzwerk-, Endpoint-, Identitäts- und organisatorische Sicherheit bleiben erforderlich. Der zusätzliche Architekturanspruch ist, unzulässigen Eintritt zu begrenzen und Zugang nicht automatisch in ausführbare Autorität zu übersetzen.
Core und Serverless Edition sind eigenständige Architekturen. Beide folgen demselben institutionellen Grundsatz: technische Erreichbarkeit, Identität und Privileg erzeugen für sich allein keine ausführbare Autorität.
Core ansehen →Serverless Edition ansehen →Execution Rights vertiefen →