
# Zero-Trust-Föderiertes Wissensgraph für Multi‑Tenant‑Fragebogen‑Automatisierung

## Einführung

Sicherheits‑ und Compliance‑Fragebögen stellen für SaaS‑Anbieter ein dauerhaftes Engpass‑Problem dar. Jeder Anbieter muss Hunderte von Fragen beantworten, die sich über mehrere Rahmenwerke erstrecken – [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2), [ISO 27001](https://www.iso.org/standard/27001), [GDPR](https://gdpr.eu/) und branchenspezifische Standards. Der manuelle Aufwand, Beweise zu finden, deren Relevanz zu prüfen und Antworten für jeden Kunden individuell zu formulieren, wird schnell zu einem Kostenfaktor.

Ein **föderiertes Wissensgraph (FKG)** – eine verteilte, schema‑reiche Darstellung von Nachweisen, Richtlinien und Kontrollen – bietet einen Weg, diesen Engpass zu beseitigen. Kombiniert man es mit **Zero‑Trust‑Sicherheit**, kann das FKG vielen Mandanten (verschiedenen Geschäftsbereichen, Tochtergesellschaften oder Partnerorganisationen) dienen, ohne jemals Daten preiszugeben, die einem anderen Mandanten gehören. Das Ergebnis ist ein **multi‑tenant, KI‑gesteuerter Fragebogen‑Automatisierungs‑Motor**, der:

* **Aggregiert** Nachweise aus disparaten Repositorien (Git, Cloud‑Speicher, CMDBs).  
* **Durchsetzt** strenge Zugriffspolicen auf Knoten‑ und Kantenebene (Zero‑Trust).  
* **Orchestriert** KI‑generierte Antworten via Retrieval‑Augmented Generation (RAG), die ausschließlich aus mandanten‑genehmigtem Wissen schöpfen.  
* **Verfolgt** Herkunft und Auditierbarkeit über ein unveränderliches Ledger.

In diesem Beitrag tauchen wir tief in die Architektur, den Datenfluss und die Implementierungsschritte ein, um ein solches System auf der **Procurize‑AI‑Plattform** zu bauen.

---

## 1. Kernkonzepte

| Konzept | Bedeutung für die Fragebogen‑Automatisierung |
|---|---|
| **Zero Trust** | „Nie vertrauen, immer verifizieren.“ Jede Anfrage an den Graphen wird authentifiziert, autorisiert und kontinuierlich anhand von Policys evaluiert. |
| **Föderiertes Wissensgraph** | Ein Netzwerk unabhängiger Graph‑Knoten (jeweils im Besitz eines Mandanten), die ein gemeinsames Schema teilen, aber ihre Daten physisch isoliert halten. |
| **RAG (Retrieval‑Augmented Generation)** | LLM‑gesteuerte Antwortgenerierung, die relevante Nachweise aus dem Graphen abruft, bevor sie eine Antwort formuliert. |
| **Unveränderliches Ledger** | Append‑only‑Speicher (z. B. blockchain‑ähnlicher Merkle‑Baum), der jede Änderung an Nachweisen protokolliert und Manipulationsnachweis liefert. |

---

## 2. Architektur‑Übersicht

Untenstehend ein hoch‑level Mermaid‑Diagramm, das die wichtigsten Komponenten und deren Interaktionen zeigt.

```mermaid
graph LR
    subgraph Tenant A
        A1[Policy Store] --> A2[Evidence Nodes]
        A2 --> A3[Access Control Engine<br>(Zero Trust)]
    end
    subgraph Tenant B
        B1[Policy Store] --> B2[Evidence Nodes]
        B2 --> B3[Access Control Engine<br>(Zero Trust)]
    end
    subgraph Federated Layer
        A3 <--> FK[Federated Knowledge Graph] <--> B3
        FK --> RAG[Retrieval‑Augmented Generation]
        RAG --> AI[LLM Engine]
        AI --> Resp[Answer Generation Service]
    end
    subgraph Audit Trail
        FK --> Ledger[Immutable Ledger]
        Resp --> Ledger
    end
    User[Questionnaire Request] -->|Auth Token| RAG
    Resp -->|Answer| User
```

**Wesentliche Erkenntnisse aus dem Diagramm**

1. **Mandanten‑Isolation** – Jeder Mandant betreibt seinen eigenen Policy Store und Evidence Nodes, doch die Access‑Control‑Engine vermittelt jede mandantenübergreifende Anfrage.  
2. **Föderierter Graph** – Der `FK`‑Knoten aggregiert Schema‑Metadaten, während rohe Nachweise verschlüsselt und isoliert bleiben.  
3. **Zero‑Trust‑Prüfungen** – Jede Zugriffsanfrage durchläuft die Access‑Control‑Engine, die Kontext (Rolle, Gerätezustand, Zweck) evaluiert.  
4. **KI‑Integration** – Die RAG‑Komponente holt nur jene Evidenz‑Knoten, die der Mandant sehen darf, und übergibt sie anschließend einem LLM zur Antwortsynthese.  
5. **Auditierbarkeit** – Alle Abrufe und generierten Antworten werden im Immutable Ledger für Compliance‑Auditoren festgehalten.

---

## 3. Datenmodell

### 3.1 Einheitliches Schema

| Entity | Attribute | Beispiel |
|---|---|---|
| **Policy** | `policy_id`, `framework`, `section`, `control_id`, `text` | `SOC2-CC6.1` |
| **Evidence** | `evidence_id`, `type`, `location`, `checksum`, `tags`, `tenant_id` | `evid-12345`, `log`, `s3://bucket/logs/2024/09/01.log` |
| **Relationship** | `source_id`, `target_id`, `rel_type` | `policy_id -> evidence_id` (evidence_of) |
| **AccessRule** | `entity_id`, `principal`, `action`, `conditions` | `evidence_id`, `user:alice@tenantA.com`, `read`, `device_trust_score>0.8` |

Alle Entitäten werden als **Property Graphs** (z. B. Neo4j oder JanusGraph) gespeichert und über eine GraphQL‑kompatible API bereitgestellt.

### 3.2 Zero‑Trust‑Policy‑Sprache

Eine leichte DSL (Domain Specific Language) drückt feinkörnige Regeln aus:

```
allow(user.email =~ "*@tenantA.com")
  where action == "read"
    and entity.type == "Evidence"
    and entity.tenant_id == "tenantA"
    and device.trust_score > 0.8;
```

Diese Regeln werden zur Laufzeit in echte Richtlinien kompiliert, die von der Access‑Control‑Engine durchgesetzt werden.

---

## 4. Ablauf: Von der Frage zur Antwort

1. **Frage‑Ingestion** – Ein Sicherheits‑Reviewer lädt einen Fragebogen (PDF, CSV oder API‑JSON) hoch. Procurize parsed ihn in einzelne Fragen und mappt jede zu einem oder mehreren Framework‑Controls.  
2. **Control‑Evidence‑Mapping** – Das System fragt das FKG nach Kanten, die das Ziel‑Control mit Evidenz‑Knoten des anfragenden Mandanten verbinden.  
3. **Zero‑Trust‑Autorisation** – Vor jedem Zugriff wird die Access‑Control‑Engine den Kontext (User, Gerät, Standort, Zeit) validieren.  
4. **Evidenz‑Abruf** – Autorisierte Evidenz wird an das RAG‑Modul gestreamt. RAG rankt die Evidenz nach Relevanz mittels einer hybriden TF‑IDF + Embedding‑Similarity‑Modell.  
5. **LLM‑Generierung** – Das LLM erhält die Frage, die abgerufene Evidenz und ein Prompt‑Template, das Ton und Compliance‑Sprache erzwingt. Beispiel‑Prompt:

   ```
   Du bist ein Compliance‑Spezialist für {tenant_name}. Beantworte das folgende Sicherheits‑Fragebogen‑Item ausschließlich mit den bereitgestellten Belegen. Erfinde keine Details.
   Frage: {question_text}
   Evidenz: {evidence_snippet}
   ```

6. **Antwort‑Review & Zusammenarbeit** – Die erzeugte Antwort erscheint in Procurizes Echtzeit‑Kollaborations‑UI, wo Fachexperten kommentieren, bearbeiten oder freigeben können.  
7. **Audit‑Logging** – Jeder Abruf, jede Generierung und jede Bearbeitung wird mit einem kryptografischen Hash, der auf die konkrete Evidenz‑Version verweist, dem Immutable Ledger hinzugefügt.

---

## 5. Sicherheitsgarantien

| Bedrohung | Gegenmaßnahme |
|---|---|
| **Datenleck zwischen Mandanten** | Zero‑Trust‑Access‑Control erzwingt `tenant_id`‑Übereinstimmung; alle Datenübertragungen sind Ende‑zu‑Ende verschlüsselt (TLS 1.3 + Mutual TLS). |
| **Komprimittierung von Zugangsdaten** | Kurzlebige JWTs, Geräte‑Attestierung und kontinuierliches Risiko‑Scoring (Verhaltens‑Analytics) invalidieren Tokens bei Anomalien. |
| **Manipulation von Evidenz** | Immutable Ledger verwendet Merkle‑Proofs; jede Änderung löst eine Fehlermeldung aus, die Auditoren sehen. |
| **Halluzination des Modells** | RAG beschränkt das LLM auf abgerufene Evidenz; ein Nach‑Generierungs‑Verifier prüft, ob Aussagen nicht unterstützt werden. |
| **Supply‑Chain‑Angriffe** | Alle Graph‑Erweiterungen (Plugins, Connectors) werden signiert und über eine CI/CD‑Gate‑Prüfung (static analysis, SBOM) freigegeben. |

---

## 6. Implementierungsschritte auf Procurize

1. **Mandanten‑Graph‑Knoten einrichten**  
   - Separate Neo4j‑Instanz pro Mandant bereitstellen (oder Multi‑Tenant‑DB mit Zeilen‑Sicherheits‑Policy).  
   - Bestehende Richtlinien‑Dokumente und Evidenz via Procurize‑Import‑Pipelines laden.  

2. **Zero‑Trust‑Regeln definieren**  
   - Mit dem Procurize‑Policy‑Editor DSL‑Regeln authoren.  
   - *Device‑Posture*‑Integration (MDM, Endpoint‑Detection) aktivieren für dynamische Risikoscores.  

3. **Föderierte Synchronisation konfigurieren**  
   - `procurize-fkg-sync` Micro‑Service installieren.  
   - So konfigurieren, dass Schema‑Updates in ein gemeinsames *Schema‑Registry* veröffentlicht werden, während Daten physisch verschlüsselt bleiben.  

4. **RAG‑Pipeline integrieren**  
   - `procurize-rag` Container bereitstellen (enthält Vektor‑Store, Elasticsearch und ein feinabgestimmtes LLM).  
   - RAG‑Endpoint mit der FKG GraphQL‑API verbinden.  

5. **Unveränderliches Ledger aktivieren**  
   - `procurize-ledger` Modul einschalten (nutzt Hyperledger Fabric oder ein leichtgewichtiges Append‑Only‑Log).  
   - Aufbewahrungsrichtlinien gemäß Compliance‑Anforderungen festlegen (z. B. 7‑Jahres‑Audit‑Trail).  

6. **Kollaborations‑UI aktivieren**  
   - Feature *Real‑Time Collaboration* einschalten.  
   - Rollenbasierte Ansicht‑Berechtigungen definieren (Reviewer, Approver, Auditor).  

7. **Pilot‑Durchlauf**  
   - Einen hochvolumigen Fragebogen (z. B. SOC 2 Type II) auswählen und messen:  
     - **Durchlaufzeit** (Baseline vs. KI‑unterstützt).  
     - **Genauigkeit** (Prozentsatz der Antworten, die Auditor‑Verifizierung bestehen).  
     - **Compliance‑Kostenreduktion** (gesparte FTE‑Stunden).  

---

## 7. Nutzen‑Zusammenfassung

| Geschäftlicher Nutzen | Technisches Ergebnis |
|---|---|
| **Geschwindigkeit** – Reduzierung der Antwortzeit von Tagen auf Minuten. | RAG holt relevante Evidenz in < 250 ms; LLM erzeugt Antworten in < 1 s. |
| **Risikominderung** – Eliminierung von menschlichen Fehlern und Datenlecks. | Zero‑Trust‑Durchsetzung und unveränderliches Logging garantieren, dass nur autorisierte Evidenz verwendet wird. |
| **Skalierbarkeit** – Unterstützung Hunderter von Mandanten ohne Datenreplikation. | Föderierter Graph isoliert Speicherung, während gemeinsames Schema bereichsübergreifende Analysen ermöglicht. |
| **Audit‑Readiness** – Bereitstellung einer prüfbaren Spur für Regulierungsbehörden. | Jede Antwort verlinkt mit einem kryptografischen Hash der genauen Evidenz‑Version. |
| **Kosten‑Effizienz** – Senkung des Compliance‑OPEX. | Automatisierung spart bis zu 80 % manuellen Aufwand und gibt Sicherheitsteams Raum für strategische Aufgaben. |

---

## 8. Zukünftige Erweiterungen

1. **Föderiertes Lernen für LLM‑Feinabstimmung** – Jeder Mandant kann anonymisierte Gradienten‑Updates beitragen, um das domänenspezifische LLM zu verbessern, ohne Rohdaten offenzulegen.  
2. **Dynamische Policy‑as‑Code‑Generierung** – Automatisches Erzeugen von Terraform‑ oder Pulumi‑Modulen, die dieselben Zero‑Trust‑Regeln in Cloud‑Infrastruktur durchsetzen.  
3. **Explainable‑AI‑Overlays** – Visualisierung des Entscheidungswegs (Evidenz → Prompt → Antwort) direkt in der UI mittels Mermaid‑Sequenzdiagrammen.  
4. **Zero‑Knowledge‑Proof‑Integration (ZKP)** – Nachweis gegenüber Auditoren, dass ein bestimmtes Control erfüllt ist, ohne die zugrunde liegende Evidenz zu offenbaren.  

---

## 9. Fazit

Ein **Zero‑Trust‑föderiertes Wissensgraph** verwandelt die mühselige, silo‑basierte Welt der Sicherheits‑Fragebogen‑Verwaltung in einen sicheren, kollaborativen und KI‑unterstützten Workflow. Durch die Kombination von mandanten‑isolierten Graphen, feinkörnigen Zugriffspolicen, Retrieval‑Augmented Generation und einer unveränderlichen Audit‑Spur können Organisationen Compliance‑Fragen schneller, genauer und mit voller regulatorischer Gewissheit beantworten.

Die Implementierung dieser Architektur auf der **Procurize‑AI‑Plattform** nutzt bestehende Ingestion‑Pipelines, Kollaborations‑Tools und Sicherheits‑Primitives – sodass Teams sich auf strategisches Risikomanagement statt auf repetitive Datensammlung konzentrieren können.

Die Zukunft der Compliance ist föderiert, vertrauenswürdig und intelligent. Nutzen Sie sie noch heute, um Auditors, Partnern und Regulierungsbehörden stets einen Schritt voraus zu sein.

---

## <span class='highlight-content'>Siehe</span> Also

* [Zero Trust Architecture – NIST SP 800‑207](https://csrc.nist.gov/publications/detail/sp/800-207/final)  
* [Federated Learning: Collaborative Machine Learning without Centralized Data](https://arxiv.org/abs/1902.01046)  
* [Retrieval‑Augmented Generation for Knowledge‑Intensive NLP Tasks (Paper)](https://arxiv.org/abs/2005.11401)