> ## Documentation Index
> Fetch the complete documentation index at: https://docs.iru.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Plattformarchitektur

> Wie Iru Identity aufgebaut ist: eine Dienstarchitektur mit zwei Ebenen über isolierte Regionen hinweg, ausgelegt auf Datenresidenz, Zuverlässigkeit und Beobachtbarkeit.

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.

```mermaid theme={null}
flowchart TB
  subgraph cp["Steuerungsebene"]
    tprov["Mandantenlebenszyklus<br/>(erstellen / löschen)"]
    jwks["Veröffentlichung öffentlicher Schlüssel (JWKS)"]
    tmpl["Synchronisierung der App-Vorlagen"]
  end
  subgraph tp["Mandanten-API"]
    iam["Mandantenbezogene IAM-API"]
    work["Hintergrund-Worker für die Bereitstellung"]
  end
  cp -->|"stellt bereit"| tp
  people["Ihre Administratoren und Mitarbeitenden"] --> tp
  apps["Ihre Apps"] --> tp
```

| Ebene | Verantwortung | Warum getrennt |
| - | - | - |
| **Steuerungsebene** | Erstellen und Löschen von Mandanten, Veröffentlichen von Signaturschlüsseln, Synchronisieren des Katalogs der Anwendungsvorlagen. | Eine kleine, privilegierte Oberfläche, die vom Anfrageverkehr der Kunden ferngehalten wird. Mandantenoperationen erfordern ein Token, das in konstanter Zeit verglichen wird; die Anmeldeinformation für die Vorlagensynchronisierung wird pro Anfrage aus einem verwalteten Secret Store abgerufen, sodass Rotationen sofort wirksam werden. |
| **Mandanten-API** | Die kundenseitige Identitäts- und Zugriffs-API sowie Hintergrund-Worker, die Konten in Ihren Apps bereitstellen. | Die stark frequentierte Oberfläche, die Ihre Mitarbeitenden und Apps tatsächlich nutzen, wobei die Bereitstellung außerhalb des Anfragepfads erfolgt, sodass eine langsame nachgelagerte App nie die Anmeldung blockiert. |

## 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.

<Steps>
  <Step title="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.
  </Step>

  <Step title="Fundament">
    Gemeinsame Infrastruktur-Hilfsmittel, die von nichts darüber abhängen (zum
    Beispiel Kryptografie und Tracing). Mandantenbezogene Belange liegen in Platform, nicht
    hier.
  </Step>

  <Step title="Domäne">
    Geschäftslogik pro Entität (Benutzer, Anwendungen, Richtlinien…). Hängt von
    Platform und Foundation ab, nicht von Usecase oder REST.
  </Step>

  <Step title="Anwendungsfall">
    Orchestriert mehrere Domain-Dienste für komplexe Abläufe.
  </Step>

  <Step title="REST">
    HTTP-Handler und Middleware, die einzige Schicht, die mit der Außenwelt kommuniziert.
  </Step>
</Steps>

<Note>
  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.
</Note>

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:

<CardGroup cols={2}>
  <Card title="Gehärtete Container" icon="cubes">
    Dienste laufen auf AWS Fargate ohne Root-Rechte mit einem **schreibgeschützten Root-Dateisystem**,
    **no-new-privileges** und ohne jegliche Linux-Capabilities.
  </Card>

  <Card title="Keine dauerhaften Datenbankpasswörter" icon="key">
    Die Anwendung verbindet sich mit verwaltetem **PostgreSQL (Amazon RDS)** über
    kurzlebige **IAM-Authentifizierungstokens**. Es gibt kein statisches DB-Passwort, das
    durchsickern könnte.
  </Card>

  <Card title="Secrets bleiben außerhalb des Codes" icon="vault">
    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.
  </Card>

  <Card title="Geprüfte Lieferkette" icon="magnifying-glass">
    Container-Images werden in der CI-Pipeline auf Schwachstellen gescannt, bevor sie
    ausgeliefert werden können.
  </Card>
</CardGroup>

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.

```mermaid theme={null}
flowchart LR
  req["Anfrage"] --> mw["Mandant aus<br/>Subdomain auflösen"]
  mw --> reg{"Region des<br/>Mandanten?"}
  reg -->|"US"| usdb[("US-Datenbank")]
  reg -->|"EU"| eudb[("EU-Datenbank")]
  reg -->|"unbekannt"| rej["Abgelehnt"]
```

* 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](/de/identity/security/multi-tenant-isolation).

## Auf Verfügbarkeit und Beobachtbarkeit ausgelegt

<AccordionGroup>
  <Accordion title="Health Checks und geordnetes Herunterfahren" icon="heart-pulse">
    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.
  </Accordion>

  <Accordion title="Robuster Datenzugriff" icon="database">
    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.
  </Accordion>

  <Accordion title="Letztendlich konsistente Bereitstellung" icon="arrows-rotate">
    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.
  </Accordion>

  <Accordion title="Durchgängiges Tracing" icon="diagram-project">
    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.
  </Accordion>

  <Accordion title="Überprüfbare Migrationen und Audits" icon="file-shield">
    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.
  </Accordion>
</AccordionGroup>

## Nächste Schritte

<CardGroup cols={2}>
  <Card title="Mandantenisolierung" icon="database" href="/de/identity/security/multi-tenant-isolation">
    Wie Row-Level Security und reine Anhänge-Audits die Daten jedes Mandanten
    getrennt und manipulationssicher halten.
  </Card>

  <Card title="Authentifizierungsarchitektur" icon="signature" href="/de/identity/security/authentication-architecture">
    Phishing-resistente Anmeldung, signierte Anfragen und wie SSO-Vertrauen hergestellt wird.
  </Card>

  <Card title="Sicherheit und Datenschutz" icon="lock" href="/de/identity/security/security-and-privacy">
    Die Garantien, die sich aus diesen Mechanismen ergeben.
  </Card>

  <Card title="Systemarchitektur" icon="sitemap" href="/de/identity/getting-started/system-architecture">
    Die kundenseitige Sicht darauf, wie Identitäten und Anmeldung fließen.
  </Card>
</CardGroup>