chinux/theProx
0
0
Fork 0
Code Issues 40 Pull requests Projects Releases Packages Wiki Activity Actions

[MSP] Kundenblick: reduzierte Mandanten-Ansicht (Positivliste, nach #207) #224

New issue
Open
opened 2026-07-20 23:15:03 +00:00 by chinux · 1 comment
chinux commented 2026-07-20 23:15:03 +00:00
Owner
Copy link

Reduzierte Ansicht für den Mandanten selbst. RBAC ist vorhanden (UserTenantRole mit can_read/can_write), aber das Admin-UI ist nicht für Endkunden gedacht.

Warum

Das ist der Schritt vom internen Werkzeug zum verkaufbaren Bestandteil einer Dienstleistung. Ein Kunde, der jederzeit seine Systeme, Backups und Berichte sehen kann, fragt seltener nach und nimmt die Leistung überhaupt wahr. Und es ist ein Argument im Vertrieb, das ohne Erklärung funktioniert.

Umfang

Sichtbar: eigene Nodes und Guests mit Status, Backup-Übersicht mit letztem erfolgreichem Lauf, Verbrauchs- und Verfügbarkeitsberichte, Wartungsfenster und angekündigte Arbeiten, Ansprechpartner.

Nicht sichtbar: Terminal, SSH, RDP-Tunnel, Kommandoausführung, Update-Auslösung, Node-Provisionierung, Agent-Token, andere Mandanten, Logs anderer Systeme, interne Notizen.

Sicherheitliche Anforderung

Das ist die erste Oberfläche, die jemand außerhalb des eigenen Hauses zu sehen bekommt. Entsprechend:

  • Positivliste, keine Negativliste. Nicht „alles außer X ausblenden", sondern ausschließlich freigegebene Endpunkte erreichbar. Ausblenden im Frontend ist keine Zugriffskontrolle.
  • Mandantenfilterung serverseitig in jedem Endpunkt, nicht im Frontend. Ein Test je Endpunkt, der einen fremden Mandanten anfragt und 403/404 erwartet.
  • Eigener Login-Bereich und eigene Rolle, nicht ein abgespeckter Admin-Account.
  • 2FA für Kundenkonten erzwingbar (Mechanik ist in me_router.py vorhanden).
  • Rate Limiting und Audit für Kundenzugriffe.

Hinweis: Sinnvollerweise erst nach #207 (Security-Story / Threat-Model) angehen — eine extern erreichbare Kundenoberfläche verschiebt das Bedrohungsmodell erheblich.

Abhängigkeiten

  • #207, Verbrauchsreport-Issue, Vertrags-Issue, Wartungsfenster-Issue
Reduzierte Ansicht für den Mandanten selbst. RBAC ist vorhanden (`UserTenantRole` mit `can_read`/`can_write`), aber das Admin-UI ist nicht für Endkunden gedacht. ## Warum Das ist der Schritt vom internen Werkzeug zum verkaufbaren Bestandteil einer Dienstleistung. Ein Kunde, der jederzeit seine Systeme, Backups und Berichte sehen kann, fragt seltener nach und nimmt die Leistung überhaupt wahr. Und es ist ein Argument im Vertrieb, das ohne Erklärung funktioniert. ## Umfang **Sichtbar:** eigene Nodes und Guests mit Status, Backup-Übersicht mit letztem erfolgreichem Lauf, Verbrauchs- und Verfügbarkeitsberichte, Wartungsfenster und angekündigte Arbeiten, Ansprechpartner. **Nicht sichtbar:** Terminal, SSH, RDP-Tunnel, Kommandoausführung, Update-Auslösung, Node-Provisionierung, Agent-Token, andere Mandanten, Logs anderer Systeme, interne Notizen. ## Sicherheitliche Anforderung Das ist die erste Oberfläche, die jemand außerhalb des eigenen Hauses zu sehen bekommt. Entsprechend: - **Positivliste, keine Negativliste.** Nicht „alles außer X ausblenden", sondern ausschließlich freigegebene Endpunkte erreichbar. Ausblenden im Frontend ist keine Zugriffskontrolle. - Mandantenfilterung serverseitig in jedem Endpunkt, nicht im Frontend. Ein Test je Endpunkt, der einen fremden Mandanten anfragt und 403/404 erwartet. - Eigener Login-Bereich und eigene Rolle, nicht ein abgespeckter Admin-Account. - 2FA für Kundenkonten erzwingbar (Mechanik ist in `me_router.py` vorhanden). - Rate Limiting und Audit für Kundenzugriffe. **Hinweis:** Sinnvollerweise erst nach #207 (Security-Story / Threat-Model) angehen — eine extern erreichbare Kundenoberfläche verschiebt das Bedrohungsmodell erheblich. ## Abhängigkeiten - #207, Verbrauchsreport-Issue, Vertrags-Issue, Wartungsfenster-Issue
chinux commented 2026-07-20 23:15:04 +00:00
Author
Owner
Copy link

Teil des MSP-Themenblocks: #218, #219, #220, #221, #222, #223, #224, #225. Reihenfolge-Vorschlag: #218 (Datengrundlage) → #223 (Vertragsstatus) → #220 (Wartungsfenster) → #219 (Kundenbericht) → Rest.

Teil des MSP-Themenblocks: #218, #219, #220, #221, #222, #223, #224, #225. Reihenfolge-Vorschlag: #218 (Datengrundlage) → #223 (Vertragsstatus) → #220 (Wartungsfenster) → #219 (Kundenbericht) → Rest.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
fix/vm-agent-update-error
fix/bulk-update-autoclose
security/tenant-scope-108
refactor/dashboard-page-split
fix/rust-agent-parity-features
feat/rust-agent-parity
archive/python-node-agent
Labels
Clear labels   
agent
Node-/VM-Agent

  
bug
Funktionaler Defekt

  
frontend
Svelte/TS Frontend

  
refactor
Umbau ohne Verhaltensaenderung

  
tech-debt
Altlast / Aufraeumen

No labels
agent
bug
frontend
refactor
tech-debt
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
chinux/theProx#224
No description provided.