SEC-1c-3 Plan-Review — DB Least-Privilege (3-Rollen-Modell)

Projekt: Steve-TradingBot · Phase: SEC-1c-3 · Author: claude-opus-4-7[1m]
Generated: 2026-05-14 06:29 UTC · master HEAD: d351a3a
Status: NO CODE Plan-Review only — Operator-GO erforderlich vor jeder DB-Änderung.
Empfehlung: 3-Rollen-Modell (app / migrator / legacy-superuser), Split in 1c-3a (Laravel, no-Bot-Touch) + 1c-3b (Bot+Worker, mit Restart-Window)

0 — Executive Summary

Aktuelle DB-Situation (Live verifiziert 2026-05-14 06:29 UTC): tradingbot_gui ist die einzige DB-Rolle und hat SUPERUSER + Create role + Create DB + Replication + Bypass RLS. Sie wird von drei Clients gleichzeitig genutzt:

• Laravel-GUI (steve-tradingbot-gui-Container) via gui/.env DB_USERNAME=tradingbot_gui
• Bot (clawbot-Container) via GUI_DB_DSN=postgres://tradingbot_gui:…@gui-db:5432/tradingbot_gui
• Worker (clawbot-worker-Container) via GUI_DB_DSN + dedizierten GUI_DB_USER=tradingbot_gui

Das ist genau die strukturelle Schwachstelle, die der INCIDENT 2026-05-12 ausnutzbar gemacht hat: jeder kompromittierte App-Prozess (Laravel, Bot, Worker) kann DROP TABLE/DROP DATABASE/ALTER SYSTEM ausführen.

Ziel SEC-1c-3: Privilege-Separation in drei Rollen:

• tradingbot_gui_app — Runtime-Rolle für alle 3 Clients. NUR SELECT/INSERT/UPDATE/DELETE + USAGE/SELECT auf Sequenzen + TEMPORARY auf DB. Kein CREATE/ALTER/DROP.
• tradingbot_gui_migrator — Schema-Migrationen via php artisan migrate. CREATE/ALTER/DROP TABLE/INDEX/SEQUENCE + alle DML. NICHT im Runtime-Container.
• tradingbot_gui (legacy) — SUPERUSER bleibt erhalten als DBA-Notfall-Zugriff via SSH+psql (nie in `.env` eines App-Containers).

Split-Empfehlung wegen Restart-Boundary: SEC-1c-3 in 2 Sub-Phasen:

• SEC-1c-3a Laravel-Cutover (sicher, kein Bot-Touch): Rollen anlegen + GRANT + GUI .env-Wechsel + GUI-Container-Restart (~10s GUI-Downtime; Bot/Worker unbeeinflusst).
• SEC-1c-3b Bot+Worker-Cutover (erfordert Bot/Worker-Restart-Window): separate Phase, getrennter Operator-GO. Bot/Worker reconnect zu DB mit neuer App-Rolle.

1 — Live-State (Recon-Ergebnisse)

2 — Risk-Profil: vorher vs. nachher

3 — 3-Rollen-Modell (detailliert)

GRANT-Sequenz (Plan only)

-- AUSFÜHRUNG via `tradingbot_gui` (SUPERUSER) am Host:
-- docker exec -i steve-tradingbot-gui-db psql -U tradingbot_gui -d tradingbot_gui << SQL

-- Variant: Passwoerter werden NIEMALS in diesem SQL-Snippet stehen. Generation:
--    PW_APP=$(openssl rand -base64 24)
--    PW_MIG=$(openssl rand -base64 24)
-- via heredoc + WITH PASSWORD '$PW_APP' — Heredoc-Body wird NICHT geechoed.

-- 1. Rollen anlegen
CREATE ROLE tradingbot_gui_app WITH LOGIN PASSWORD <PW_APP> NOSUPERUSER NOCREATEDB NOCREATEROLE NOREPLICATION;
CREATE ROLE tradingbot_gui_migrator WITH LOGIN PASSWORD <PW_MIG> NOSUPERUSER NOCREATEDB NOCREATEROLE NOREPLICATION;

-- 2. Grants fuer App-User (ZUERST, sicher fuer existing tables)
GRANT CONNECT ON DATABASE tradingbot_gui TO tradingbot_gui_app;
GRANT TEMPORARY ON DATABASE tradingbot_gui TO tradingbot_gui_app;
GRANT USAGE ON SCHEMA public TO tradingbot_gui_app;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO tradingbot_gui_app;
GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO tradingbot_gui_app;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO tradingbot_gui_app;

-- 3. Default-Privileges fuer ZUKUENFTIGE Tabellen (= nach Migrationen automatisch)
ALTER DEFAULT PRIVILEGES FOR ROLE tradingbot_gui_migrator IN SCHEMA public
    GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO tradingbot_gui_app;
ALTER DEFAULT PRIVILEGES FOR ROLE tradingbot_gui_migrator IN SCHEMA public
    GRANT USAGE, SELECT ON SEQUENCES TO tradingbot_gui_app;
ALTER DEFAULT PRIVILEGES FOR ROLE tradingbot_gui_migrator IN SCHEMA public
    GRANT EXECUTE ON FUNCTIONS TO tradingbot_gui_app;

-- 4. Grants fuer Migrator-User
GRANT CONNECT ON DATABASE tradingbot_gui TO tradingbot_gui_migrator;
GRANT TEMPORARY ON DATABASE tradingbot_gui TO tradingbot_gui_migrator;
GRANT USAGE, CREATE ON SCHEMA public TO tradingbot_gui_migrator;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO tradingbot_gui_migrator;
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO tradingbot_gui_migrator;
GRANT ALL PRIVILEGES ON ALL FUNCTIONS IN SCHEMA public TO tradingbot_gui_migrator;

-- 5. Migrator MUSS Owner werden fuer existing tables damit er ALTER kann
--    (alternativ: GRANT REASSIGN OWNED BY tradingbot_gui TO tradingbot_gui_migrator)
--    Aber das macht den Migrator zum De-facto-Owner und nimmt SUPERUSER raus.
--    Pragmatischer: SUPERUSER bleibt Owner; Migrator kriegt ALL GRANTS.
--    Migration via Laravel testet sich vor Cutover (mit migrate --pretend).

-- 6. SUPERUSER NICHT vom Owner zurückziehen (sonst wird REASSIGN bei naechster
--    Migration nötig); SUPERUSER bleibt Owner aller 24 Tabellen + 18 Sequenzen.
--    Defense-in-Depth: SUPERUSER nicht mehr in Container.env

4 — Cutover-Strategy & Sub-Phase-Split

SEC-1c-3a — Laravel-Cutover (sicher, no-Bot-Touch)

Σ SEC-1c-3a: ~35 min, davon ~10s GUI-Container-Restart.

SEC-1c-3b — Bot+Worker-Cutover (eigene Phase, Operator-GO erforderlich)

Σ SEC-1c-3b: ~40 min, mit explizitem Bot/Worker-Restart-Window.

SEC-1c-3c (BACKLOG) — SUPERUSER-Lock-Down

Nach erfolgreichem 1c-3a + 1c-3b: ALTER USER tradingbot_gui WITH NOSUPERUSER NOCREATEDB NOCREATEROLE NOREPLICATION. SUPERUSER bleibt nur via psql-Direkt-Reconnect-mit-PW-Reset wieder aktivierbar. Mehr Defense, weniger DBA-Convenience — Operator-Decision.

5 — Test-Plan (vor Cutover)

Connect-Test (NACH GRANT, VOR Cutover)

# positive case (sollte alle gehen):
PGPASSWORD=<app-PW> psql -U tradingbot_gui_app -h gui-db -d tradingbot_gui -c "SELECT COUNT(*) FROM users;"
PGPASSWORD=<app-PW> psql -U tradingbot_gui_app -h gui-db -d tradingbot_gui -c "INSERT INTO audit_events (event, occurred_at) VALUES ('sec-1c-3a-test', NOW()); SELECT LASTVAL();"
PGPASSWORD=<app-PW> psql -U tradingbot_gui_app -h gui-db -d tradingbot_gui -c "DELETE FROM audit_events WHERE event='sec-1c-3a-test';"

# negative case (MUSS alle fehlschlagen mit permission denied):
PGPASSWORD=<app-PW> psql -U tradingbot_gui_app -h gui-db -d tradingbot_gui -c "CREATE TABLE leak_test (id int);"
PGPASSWORD=<app-PW> psql -U tradingbot_gui_app -h gui-db -d tradingbot_gui -c "DROP TABLE users;"
PGPASSWORD=<app-PW> psql -U tradingbot_gui_app -h gui-db -d tradingbot_gui -c "ALTER TABLE users ADD COLUMN leak text;"
PGPASSWORD=<app-PW> psql -U tradingbot_gui_app -h gui-db -d tradingbot_gui -c "TRUNCATE TABLE users;"
PGPASSWORD=<app-PW> psql -U tradingbot_gui_app -h gui-db -d tradingbot_gui -c "CREATE ROLE evil;"

# Migrator-Test (sollte alle gehen):
PGPASSWORD=<mig-PW> psql -U tradingbot_gui_migrator -h gui-db -d tradingbot_gui -c "CREATE TABLE _sec_1c_3_canary (id int); DROP TABLE _sec_1c_3_canary;"

Laravel-Tests via Safe-Runner (NACH 1c-3a cutover)

bash gui/scripts/run_tests_safe.sh
# Erwartet: 856/856 ✅ wie zuvor.
# Safe-Runner nutzt SQLite in-memory — DB-Wechsel beeinflusst Tests nicht.

6 — Operator-Decision-Points (vor GO 1c-3a)

1. Sub-Phase-Split: 1c-3a (Laravel-only, kein Bot/Worker-Touch) jetzt, 1c-3b später? Empfehlung: JA, weil Bot/Worker-Restart-Window bewusst getrennt.
2. Migrator-Owner-Strategie: SUPERUSER bleibt Owner; Migrator hat ALL PRIVILEGES — OK? (Empfehlung: ja, vermeidet REASSIGN-Komplexität)
3. SEC-1c-3c (SUPERUSER lock-down): jetzt mit-planen oder als BACKLOG für später? Empfehlung: BACKLOG bis 1c-3a/1c-3b live + 1 Woche stabil.
4. PW-Speicherort: /root/.secrets/<phase>.SECRET-READ-ONCE mode 600 + Operator-Shred nach PW-Manager-Import. Standard-Pattern, OK?
5. Migration-CLI-Vereinfachung: ein Wrapper-Script /projekte/Steve-TradingBot/gui/scripts/run_migrate_safe.sh der automatisch zwischen App-User (Runtime) und Migrator-User (Migrations) wechselt? Empfehlung: ja, BACKLOG nach 1c-3a.
6. Filament-Tinker-Zugriff: nutzt php artisan tinker die App-User-Connection oder soll es eine separate Read-Only-Rolle dafuer geben? Empfehlung: bleibt App-User für jetzt; Read-Only-Rolle Optional BACKLOG.

7 — Stop-Regeln

• STOP: positive-case-Test mit App-User schlägt fehl (z. B. SELECT auf users) → GRANT inkomplett, Rollback
• STOP: negative-case-Test mit App-User klappt (z. B. CREATE TABLE) → Defense kaputt, sofortiger Rollback
• STOP: nach .env-Wechsel + Container-Restart kann GUI sich nicht zu DB connecten → sofortiger Revert auf alten tradingbot_gui-User
• STOP: Filament-Login schlägt fehl nach Cutover → Rollback
• STOP: Bot/Worker-PID ändert sich während 1c-3a (Bot ist explizit out-of-scope)
• STOP: irgendwelche Secret-Werte (App-PW, Migrator-PW) erscheinen im Output / Memory / Commit / PDF
• STOP: Mainnet-Toggle, Bot-Code-Touch, runtime_config-touch, managed_state-touch

8 — Rollback-Pfade

9 — NO-GO-Bedingungen

• NO-GO ohne pg_dump-Backup vor 3a.3
• NO-GO ohne .env-Backup vor 3a.7
• NO-GO ohne erfolgreichen positive+negative Connect-Tests (3a.4 + 3a.5)
• NO-GO Bot/Worker-Touch innerhalb 1c-3a
• NO-GO Bot/Worker-Restart innerhalb 1c-3a
• NO-GO Mainnet-Toggle
• NO-GO docker cp auf clawbot
• NO-GO Secret-Werte im Output / Memory / PDF / Commit-msg / Logs
• NO-GO Push (Closure rein host-side: nur DB + .env, kein Repo-File)

10 — Boundaries (Plan-Review-End)

11 — Phasen-Einordnung & Empfehlung

Empfehlung

GO SEC-1c-3a atomic Block (35 min, kein Bot/Worker-Touch). Danach STOP und Operator-Verifikation auf gui.gewerbespeicher-rechner.de bevor Operator-GO für SEC-1c-3b ausgesprochen wird.

Status

PLAN-REVIEW Plan fertig. Warte auf:

• Antworten auf Decision-Points 1–6 (mind. 1, 2 nötig; 3-6 haben sinnvolle Defaults)
• GO für SEC-1c-3a (13-Step-Block, ~35 min)

Kein Code geschrieben. Keine DB-Rollen-Änderung. Keine .env-Änderung. Pure analysis only.