BTP-Subaccount-Trennung DEV/QAS/PRD als Datenschutz-Architektur
Drei Subaccounts mit eigenen XSUAA-, HDI- und Audit-Log-Instanzen sind keine Stage-Verteilung – sie sind die strukturelle Datenschutz-Architektur. Was die Trennung wirklich blockiert, wo Cross-Account-Operations nötig sind, und welcher Service in welche Subaccount gehört.
Warum Subaccount-Trennung mehr ist als drei Stages
Viele BTP-Setups haben drei Subaccounts „weil man das so macht“. Bei BAMVP ist die Trennung die Datenschutz-Architektur – nicht eine Konvention, sondern die strukturelle Durchsetzung von Isolation.
```mermaid
flowchart TD
subgraph DEV["Subaccount DEV"]
DEV_XS[XSUAA DEV]
DEV_HDI[HDI Container DEV
~50 synthetic rows]
end
subgraph QAS["Subaccount QAS"]
QAS_XS[XSUAA QAS]
QAS_HDI[HDI Container QAS
anonymisiert]
ANON[Space anonymizer
Tech-User: BAMVP_ANON_RO]
end
subgraph PRD["Subaccount PRD"]
PRD_XS[XSUAA PRD]
PRD_HDI[HDI Container PRD
LIVE]
SS[HANA Secure Store
Salt]
AL[Audit Log Service
7-Jahre]
end
ANON -.->|JDBC Read-Only
via Trust| PRD_HDI
ANON -.->|Bulk INSERT| QAS_HDI
style PRD fill:#fecaca,stroke:#b91c1c style QAS fill:#fed7aa,stroke:#c2410c style DEV fill:#bbf7d0,stroke:#15803d ```
Was die Trennung blockiert
Block 1 – Token-Wiederverwendung
Jeder Subaccount hat eine eigene XSUAA-Instanz. Ein JWT, der in DEV gültig ist, ist in QAS und PRD nicht gültig. Cross-Account-Auth braucht expliziten Trust und ist eine bewusste Entscheidung, kein Versehen.
Ein Entwickler, der versehentlich einen DEV-Token in einem PRD-Skript verwendet, bekommt 401. Strukturell, nicht durch Disziplin.
Block 2 – DB-Zugriffs-Isolation
Jeder Subaccount hat einen eigenen HDI-Container. Auf HANA-Ebene sind das separate Schemas mit separaten DB-Usern. Cross-Schema-Reads brauchen explizite Grants, die im normalen Setup nicht existieren.
Ein DEV-CAP-Service kann den PRD-HDI-Container technisch nicht erreichen. Selbst wenn jemand versuchen würde, die Connection-String hardzucoden – fehlt der DB-User-Grant, Connection refused.
Block 3 – Audit-Log-Pflicht
Audit Log Service läuft nur im PRD-Subaccount. 7-Jahre-Retention. DEV und QAS haben keinen Audit Log Service – was dort passiert, ist nicht audit-pflichtig (und könnte technisch sein wenn jemand will, aber es ist keine Compliance-Anforderung).
Diese Trennung erlaubt schnelle Iteration in DEV ohne Compliance-Overhead.
Block 4 – HANA Secure Store
Der HMAC-Salt liegt in einem HANA Secure Store, der nur im PRD-Subaccount existiert. DEV und QAS haben keine Salt-Instanz. Selbst wenn jemand auf der DEV-DB-Instanz Salt-Daten generiert – sie haben keine Kraft, weil der Anonymizer nur in der QAS-Subaccount-Pipeline läuft und dort den PRD-Salt holt.
Welcher Service in welche Subaccount
| Service | DEV | QAS | PRD |
|---|---|---|---|
| Approuter | ✅ | ✅ | ✅ |
| CAP Backend | ✅ | ✅ | ✅ |
| HDI Container | ✅ (synthetic) | ✅ (anonymisiert) | ✅ (LIVE) |
| XSUAA | ✅ | ✅ | ✅ |
| Destination Service | ✅ | ✅ | ✅ |
| Job Scheduler | – | ✅ (Anonymizer) | ✅ (KPI-Refresh) |
| Audit Log Service | – | – | ✅ |
| HANA Secure Store | – | – | ✅ (Salt) |
| Anonymizer | – | ✅ | – |
Cross-Account-Operations
Es gibt nur eine Cross-Account-Operation: Anonymizer in QAS-Subaccount liest aus PRD-Subaccount. Diese ist:
- Über JDBC mit dem Tech-User BAMVP_ANON_RO
- Read-Only-Scope
- Audit-pflichtig (jeder Read wird im PRD Audit Log Service gestempelt)
- Trust-Konfiguration explizit in BTP Cockpit dokumentiert
Alle anderen Operations laufen innerhalb einer Subaccount.
Was die Trennung nicht blockiert
- Logischer Bug: wenn der Anonymizer-Code falsch konfiguriert ist und PRD-Daten als Klartext in QAS landen, hilft Subaccount-Trennung nicht. Validator-Stage ist die Verteidigung.
- Personen-bedingte Risiken: ein Privacy-Lead mit malicious intent könnte zwischen Subaccounts mit JIT-Approval einiges anrichten. 4-Augen-Prinzip ist die Verteidigung.
- Cross-System-Daten-Leakage: wenn eine PRD-Datei manuell auf einen Public-Share kommt, ist das Subaccount-irrelevant.
Operations-Aufwand der Trennung
- Subaccount-Setup initial: 1-2 Tage Senior-DevOps
- Trust-Konfiguration zwischen QAS-Anon und PRD: 0.5 Tage
- Pro neuer CDS-Schema-Änderung: Schema-Sync zwischen Subaccounts (10-20 Min via mta-deploy)
- Quartalsweises Review der Subaccount-Konfiguration: 2-4 Stunden
Total: ~1-2 % FTE für Subaccount-Operations bei einem mittleren Setup.
Wer das prüfen lassen will
Ein Architektur-Review (30 Min) prüft Ihre Subaccount-Trennung gegen die vier Block-Mechanismen und identifiziert Schwachstellen. Konkrete Action-Items, kein Folien-Workshop.
Stand: 2026-05-10
