Konzeptkarte

Threat-First SAP Analytics Architecture (das T in GSTACK)

Stand 6. Oktober 2026

Redaktion: Cédric Mary, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist Threat-First SAP Analytics Architecture (das T in GSTACK)?

Der Threat Tree führt jeden SAP-Analytics-Flow durch vier Schritte — Asset-Klassifizierung, Vertrauensgrenzen von ECC bis zur externen Freigabe, STRIDE-light je Grenze und Blast-Radius-Bewertung — und erzeugt so ein einseitiges Dokument pro Flow.

Der vierstufige Bedrohungsbaum für SAP-Analytics-Flows

Wird auf jeden kritischen Datenfluss im Engagement angewendet. Das Ergebnis ist ein Dokument von einer Seite pro Flow.

Schritt 1 — Asset-Inventar

Welche Daten transportiert dieser Flow? Klassifizierungsstufen:

Public — Zählungen, KPIs auf Länderebene, anonymisierte Buyer-Persona
Internal — länderweise gruppierter Umsatz, Partnerbeziehungen, namentlich genannte Kundenlogos
Confidential — kundenbezogene Transaktionsdaten, individuelle Mitarbeiterdaten, Gehaltsabrechnung, MNPI
Restricted — PII, die natürliche Personen identifiziert, Gesundheitsdaten, Zahlungskartendaten

Je höher die Klassifizierung, desto kleiner der akzeptable Schadensradius.

Schritt 2 — Vertrauensgrenzen

Den Flow vom Ursprung bis zum Konsum durchlaufen. Bei jedem Übergang eine Grenze einzeichnen:

ECC-Quelle → Datasphere-Replikation (Grenze: SAP-RFC-Trust)
Datasphere → BDC-Iceberg-Lakehouse (Grenze: Lakehouse-Object-Store-ACLs)
BDC → SAC-Live-Modell (Grenze: SAC-Rolle + Space)
SAC-Story → eingebetteter Export nach Office (Grenze: SAC-Export-Policy)
SAC-Story → geteilt mit externem Prüfer (Grenze: öffentlicher SAC-Link)

Bei jeder Grenze benennen, was der Angreifer kompromittieren müsste, um sie zu überqueren.

Warum es zählt

Die Datenklassifizierung (public, internal, confidential, restricted) legt den akzeptablen Schadensradius fest, bevor eine Kontrolle entworfen wird — je höher die Klassifizierung, desto kleiner muss dieser Radius sein.
Jeder Vertrauensgrenzen-Übergang (ECC zu Datasphere, Datasphere zu BDC Iceberg, BDC zu SAC-Live-Modell, SAC zu externem Prüfer) benennt genau, was ein Angreifer kompromittieren müsste, um ihn zu überqueren.
STRIDE-light, angewendet je Grenze, fördert SAP-spezifische Angriffsvektoren zutage — Wiederverwendung von S-Usern, RLS-Umgehung über SAC-Drill-through, ein Joule-Agent, der Service-Account-Scope erbt.

Kernpunkte

Pro Datenfluss anwenden, nicht pro Projekt — jeder Flow erhält einen einseitigen Bedrohungsbaum.
4 Schritte: Asset-Inventar · Vertrauensgrenzen · STRIDE-light je Grenze · Schadensradius-Bewertung.
SAP-analytics-spezifische Grenzliste: ECC→Datasphere, Datasphere→BDC, BDC→SAC, SAC→Export, SAC→öffentlicher Link.
Output: eine Zeile [GSTACK · threat-model · Pn] pro Finding, eingespeist ins Engagement-Risikoregister.
Verbunden mit der Ownership-Map (C306) — jedes Finding erhält einen benannten Owner.
Sobald ein Joule-Agent oder eine Grounding-Pipeline im Fluss sitzt, eine LLM-Inferenz-Grenze hinzufügen — ihr Spoofing-Blatt ist Prompt-Injection, ihr Informationsoffenlegungs-Blatt ist Grounding-Abfrage, die Row-Level-Security umgeht.
Den Schadensradius um einen dritten Faktor bewerten, wenn ein Blatt einen handlungsfähigen Agenten speist: Ist die nachgelagerte Aktion reversibel — eine selbstverstärkende Offenlegung über die eigene Schreibaktion eines Agenten übertrifft ein statisches Leck.
Grounding-Bypass-Lecks auf der Data-Product-Ebene (Datasphere DAC) beheben, nicht innerhalb von Joule Studio — eine reine Joule-Lösung lässt jeden anderen Konsumenten desselben Data Products weiterhin exponiert.

Begriffe auf dieser Seite

Vertrauensgrenze: Ein Punkt in der Architektur, an dem angreiferkontrollierte Eingabe auf privilegierten Code oder privilegierte Daten trifft.
STRIDE: Microsofts Bedrohungsklassifizierungs-Framework: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
Datenklassifizierung: Kennzeichnung von Daten mit einer Sensitivitätsstufe (public/internal/confidential/restricted), die zur Abgrenzung des akzeptablen Schadensradius verwendet wird.
Asset-Inventar: Der erste Schritt jedes Threat-Modells — was schützen wir? Wird dieser übersprungen, ist der Rest Theater.
LLM-Inferenz-Grenze: Der Vertrauensgrenztyp, der eingeführt wird, sobald ein Fluss einen LLM-Aufruf enthält — der Punkt, an dem governte Daten in einen Prompt übergehen, mit eigenen Spoofing- (Prompt-Injection) und Informationsoffenlegungs-Ausfallmodi (Grounding-Leckage).
Grounding-Abfrage: Der Document- oder Datenbank-Grounding-Schritt in SAPs Orchestration Service, der Kontext vor einem LLM-Aufruf abruft; läuft historisch unter einer Service-Identität, was die Row-Level-Security des anfragenden Nutzers still umgehen kann, sofern nicht ausdrücklich anders konfiguriert.
Reversibilitätsfaktor: Eine dritte Bewertungsdimension, die dem Schadensradius-Rang hinzugefügt wird, sobald ein Bedrohungsbaum-Blatt einen handlungsfähigen Agenten speist: ob die nachgelagerte Aktion des Agenten reversibel ist, da eine irreversible Aktion eine Offenlegung zu einem selbstverstärkenden Vorfall macht.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →

Offene SAP-Projekte

Aktuelle SAP-Analytics-Projekte und Stellen im DACH-Raum: SAP-Analytics-Projekte im DACH-Raum.