Skip to main content
Iru Identity ist ein Cloud-Dienst, der als vertrauenswürdiges Zentrum Ihres Zugriffs konzipiert ist. Im Folgenden wird beschrieben, wie der Dienst aufgebaut ist und was das für Zuverlässigkeit und Isolierung bedeutet.

​
Zwei Ebenen, nach Aufgabe getrennt

Die Plattform ist in zwei unabhängig bereitgestellte Dienste aufgeteilt, die sich einen gemeinsamen, geschichteten Kern teilen. Die Trennung der privilegierten Bereitstellung vom mandantenbezogenen Anfrageverkehr verringert die Auswirkungen eines Vorfalls auf beiden Seiten.

​
Ein disziplinierter, geschichteter Kern

Beide Dienste sind in Go auf einer geschichteten Architektur mit einer einseitig gerichteten Abhängigkeitsregel aufgebaut. Eine separat durchgesetzte Platform-Schicht liegt unter den Produkt- schichten und verantwortet Mandantenisolierung und Identitätsprimitive. Foundation bleibt frei von Abhängigkeiten für gemeinsame Infrastruktur-Hilfsmittel, die keinen Mandanten- kontext tragen.
1

Plattform

Mandantenisolierung und Identitäts-Rückgrat: Datenbankzugriff, Sitzungen, Auflösung von Mandant und Region, Akteur, Protokollierung und Verarbeitung öffentlicher URLs. Diese Schicht wird separat geprüft und durchgesetzt, damit die Isolierung nicht in gewöhnlichem Produkt- code liegt.
2

Fundament

Gemeinsame Infrastruktur-Hilfsmittel, die von nichts darüber abhängen (zum Beispiel Kryptografie und Tracing). Mandantenbezogene Belange liegen in Platform, nicht hier.
3

Domäne

Geschäftslogik pro Entität (Benutzer, Anwendungen, Richtlinien…). Hängt von Platform und Foundation ab, nicht von Usecase oder REST.
4

Anwendungsfall

Orchestriert mehrere Domain-Dienste für komplexe Abläufe.
5

REST

HTTP-Handler und Middleware, die einzige Schicht, die mit der Außenwelt kommuniziert.
Die Schichtung ist eine dokumentierte, durch Reviews durchgesetzte Konvention (gestützt durch Linting und Verzeichnisstruktur), keine vom Compiler garantierte Invariante. Wir weisen ehrlich darauf hin, statt zu viel zu versprechen.
Das Testen folgt derselben Disziplin: Reine Geschäftslogik wird ohne Mocks per Unit-Test geprüft, und das Verhalten wird durch Integrationstests gegen eine echte PostgreSQL-Datenbank validiert, sodass Tests dieselbe Row-Level Security und dasselbe Audit- Verhalten wie in der Produktion ausführen, nicht eine nachgebildete Annäherung.

​
Hosting und Härtung

Iru Identity läuft auf AWS mit einer sicherheitsgehärteten Bereitstellung:

Gehärtete Container

Dienste laufen auf AWS Fargate ohne Root-Rechte mit einem schreibgeschützten Root-Dateisystem, no-new-privileges und ohne jegliche Linux-Capabilities.

Keine dauerhaften Datenbankpasswörter

Die Anwendung verbindet sich mit verwaltetem PostgreSQL (Amazon RDS) über kurzlebige IAM-Authentifizierungstokens. Es gibt kein statisches DB-Passwort, das durchsickern könnte.

Secrets bleiben außerhalb des Codes

Anmeldeinformationen und Signaturschlüssel werden zur Laufzeit aus einem verwalteten Secret Store eingespeist, niemals in das Repository übernommen oder im Klartext in der Datenbank gespeichert.

Geprüfte Lieferkette

Container-Images werden in der CI-Pipeline auf Schwachstellen gescannt, bevor sie ausgeliefert werden können.
Statische Assets werden über ein CDN (Fastly) bereitgestellt, und kurzlebige Vorschau- umgebungen für Tests laufen auf Google Cloud Run.

​
Zwei Regionen, echte Datenresidenz

Iru Identity wird in zwei isolierten Regionen (Vereinigte Staaten us-east-2 und Europäische Union eu-central-1) betrieben, und die Residenz wird im Code durchgesetzt, nicht per Konvention.
  • Jeder Mandant ist an eine Region gebunden, die im Mandantendatensatz gespeichert ist.
  • Die Datenbankschicht hält separate Verbindungspools pro Region und leitet jede Transaktion anhand der Region des Mandanten weiter. Eine Anfrage, deren Region nicht aufgelöst werden kann, wird abgelehnt. Sie fällt niemals unbemerkt auf eine andere Region zurück.
  • Regionsspezifische Datenoperationen (etwa Seed-Daten) sind abgesichert, sodass sie nicht gegen die falsche Region ausgeführt werden können.
Das Ergebnis: Die Daten eines EU-Mandanten werden ausschließlich auf EU- Infrastruktur gelesen und geschrieben. Wie die Isolierung innerhalb jeder regionalen Datenbank fortgesetzt wird, erfahren Sie unter Mandantenisolierung.

​
Auf Verfügbarkeit und Beobachtbarkeit ausgelegt

Ein abhängigkeitsfreier Liveness-Endpunkt ermöglicht dem Orchestrator Prüfungen, ohne Datenbank oder Authentifizierung zu berühren. Beim Herunterfahren nehmen Dienste keinen Datenverkehr mehr an und leeren nacheinander Tracing, Fehlerberichte und Datenbankverbindungen.
Verbindungspools sind abgestimmt und begrenzt, pingen ihre Datenbank beim Start an und schlagen sofort fehl, wenn sie nicht erreichbar ist, statt fehlerhafte Anfragen zu bedienen.
Die Kontobereitstellung in Ihren Apps läuft über eine Outbox- und Abgleich- Schleife in abbruchfähigen Hintergrund-Workern, sodass nachgelagerte Änderungen so lange wiederholt werden, bis sie erfolgreich sind, statt verloren zu gehen.
Anfragen werden mit OpenTelemetry von HTTP über den Anwendungscode bis hinunter zur SQL-Abfrage verfolgt, und strukturierte Protokolle werden nach Mandant und Trace- ID korreliert. Fehler werden zentral mit Sampling erfasst, um Genauigkeit und Kosten auszubalancieren.
Schemaänderungen sind eingebettet, nach Version geordnet und per Prüfsumme verifiziert (eine geänderte, bereits angewendete Migration führt zu einem harten Fehler). Eine ständige Prüfung weist nach, dass das Audit-Journal jeder Tabelle mit ihrem Live-Schema synchron bleibt.

​
Nächste Schritte

Mandantenisolierung

Wie Row-Level Security und reine Anhänge-Audits die Daten jedes Mandanten getrennt und manipulationssicher halten.

Authentifizierungsarchitektur

Phishing-resistente Anmeldung, signierte Anfragen und wie SSO-Vertrauen hergestellt wird.

Sicherheit und Datenschutz

Die Garantien, die sich aus diesen Mechanismen ergeben.

Systemarchitektur

Die kundenseitige Sicht darauf, wie Identitäten und Anmeldung fließen.