Konzeptkarte

GSTACK — Governance-Disziplin für SAP-Analytics-Berater

Stand 2026-07-23

Redaktion: Cédric-Olivier Mâry, 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 GSTACK — Governance-Disziplin für SAP-Analytics-Berater?

GSTACK benennt drei Governance-Disziplinen, die ein Berater in jedes Projekt mitbringt — Threat-First-Architektur, eine Control-Ownership-Map mit benannter Person und Bus-Factor-Kennzeichnung sowie Secure-by-Default-Muster je SAP-Schicht.

Die drei Disziplinen

GSTACK ist kein Produkt, kein Tool, keine Zertifizierung. Es ist eine Methodik-Abkürzung, die drei Governance-Disziplinen benennt, die ein SAP-Analytics-Berater in jedes Engagement mitbringt:

1. Threat-First-Architektur (T)

Bevor auch nur eine Zeile modellbauenden Codes geschrieben wird, kartiert der Berater:

Was schiefgehen kann — den Angriffsbaum auf den Datenfluss (Datasphere-Replikation → SAC-Story → eingebetteter Export). Was kontrolliert ein Angreifer? Wo liegen Vertrauensgrenzen?
Was bereits schiefgeht — die Vorfallhistorie bei diesem Kunden. Vergangene Datenlecks, Feststellungen der Aufsichtsbehörde, interne Audit-Berichte.
Schadensradius — der Worst Case, wenn der BW/4HANA-Extraktor kompromittiert ist, wenn SAC-Sharing falsch gescopt ist, wenn die Datasphere Intelligent-Lookup-View über Row-Level-Security-Lücken PII preisgibt.

Der kanonische Analytics-Legends-Skill ist security-threat-model.

2. Control-Ownership-Map (O)

Für jede identifizierte Kontrolle (RLS-Policy, Verschlüsselung im Ruhezustand, Log-Aufbewahrung, wer eine Story veröffentlichen darf, wer Zugriff auf ein Modell erneut gewähren darf) hält der Berater fest:

Owner — Name + Rolle + E-Mail (KEIN Team-Alias; ein Mensch, der ans Telefon geht)
Runbook — Confluence-/Notion-/Wiki-Link mit den operativen Schritten
Bus-Faktor — Kennzeichnung, wenn der Owner N=1 ist
Recovery Time Objective (RTO) — wie lange bis zur Wiederherstellung, wenn der Owner nicht erreichbar ist

Der kanonische Analytics-Legends-Skill ist security-ownership-map.

3. Secure-by-Default-Implementierung (S)

Der Berater wendet konkrete Muster an, statt jedes Mal von Grund auf neu zu argumentieren:

Datasphere: standardmäßig Row-Level-Security AN; standardmäßig Consumption-Only-Rollen; standardmäßig keine öffentlichen Links
BDC: standardmäßig gestufte Iceberg-Writes mit Provenance-Metadaten; standardmäßig Joule-Guardrails für Enterprise-Agenten
SAC: standardmäßig privater Story-Workspace bis zur Prüfung; standardmäßig kein eingebetteter Export ohne Wasserzeichen
BW/4HANA: standardmäßig TLS für jeden RFC; standardmäßig Audit-Log bei jedem InfoProvider-Lesezugriff

Warum es zählt

Jede Kontrolle (RLS-Policy, Verschlüsselung, Log-Aufbewahrung, Veröffentlichungsrechte) braucht einen benannten Owner — keinen Team-Alias — plus ein Runbook, eine Bus-Factor-Kennzeichnung und ein Recovery Time Objective.
Threat-First-Architektur kartiert, was schiefgehen kann, was bereits schiefgegangen ist (Vorfallhistorie, Feststellungen der Aufsichtsbehörde), und den Worst-Case-Schadensradius, bevor auch nur eine Zeile modellbauenden Codes geschrieben wird.
Secure-by-Default-Muster ersetzen das jedesmalige Argumentieren von Grund auf durch konkrete Standardeinstellungen je Plattform — Datasphere, BDC, SAC, BW/4HANA.

Kernpunkte

GSTACK = Threat-First-Architektur × Control Ownership × Secure-by-Default — drei Disziplinen, angewendet als eine Linse.
Bildet auf drei kanonische Skills ab: security-threat-model, security-ownership-map, security-best-practices.
Jedes Finding wird mit der Attribution [domain · <skill> · <severity>] ausgeliefert — der Audit-Trail-Contract.
Immer aktiv: Pre-Deploy + Post-Deploy + Threat-Gespräche + Ownership-Fragen + Compliance-Reviews + Governance-Commits.
Die Standing Order des Betreibers ist die Governance-Charta der Plattform — bei jedem Session-Start zu lesen.
„GSTACK — Governance-Disziplin für SAP-Analytics-Berater“ ist erst dann beherrscht, wenn es eine benannte Käuferentscheidung verändert.
Beginnen Sie mit dem semantischen Vertrag und dem Kontrollmodell, bevor Sie das Tool demonstrieren.
Verwenden Sie aktuelle SAP-, Analysten-, Studien-, Wissensgraph- und Nachrichtensignale als Beleg, nicht als Dekoration.
Trennen Sie verifizierte Fakten von richtungsweisenden Trends und modellierten Annahmen.
Definieren Sie Owner, Kennzahl, Schwellenwert, Support-Pfad und Rollback, bevor Sie skalieren.

Begriffe auf dieser Seite

Bedrohungsbaum: Hierarchische Zerlegung der Ziele eines Angreifers gegen eine SAP-Analytics-Oberfläche (z. B. Datasphere → SAC → Embed).
Bus-Faktor: Anzahl der Personen, die verschwinden müssten, bevor eine Kontrolle unbetreut bleibt. Bus-Faktor 1 = Single Point of Failure.
Schadensradius: Menge der Nutzer/Daten/Dienste, die betroffen sind, wenn eine gegebene Vertrauensgrenze verletzt wird. Kleiner = besser.
RTO: Recovery Time Objective — maximal akzeptable Ausfallzeit, wenn ein Kontroll-Owner nicht verfügbar ist.
Secure-by-default: Implementierungsmuster, bei denen die sichere Wahl der Weg des geringsten Widerstands ist (z. B. RLS standardmäßig AN, öffentliches Teilen standardmäßig AUS).
Entscheidungsinhaber: Die verantwortliche Person, die den Kompromiss akzeptiert und die nächste Maßnahme finanziert.
Semantischer Vertrag: Die gemeinsame Definition von Geschäftsbegriffen, Kennzahlen, Entitäten und Zugriffsregeln, die von Tools und Teams verwendet wird.
Kontrollebene: Die Schicht, die Richtlinien, Zugriff, Herkunftsnachweis, Monitoring und Eskalation über das Betriebsmodell hinweg durchsetzt.

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.

In der App öffnen →