Benutzer-, Rechte- & Kundenverwaltung

Die Benutzer- und Rechteverwaltung ist das sicherheitskritischste Element auf Control-Plane-Ebene von Pterodactyl. Fehlerhafte Rollenmodelle, überprivilegierte Accounts oder schlecht verwaltete API-Tokens führen direkt zu Plattformkompromittierungen.

Diese Seite betrachtet das Thema strikt aus Hosting-, Admin- und Security-Sicht, nicht aus Endnutzer-Perspektive.

1. Benutzer-Typen in Pterodactyl

Pterodactyl unterscheidet grundsätzlich zwischen:

Administratoren (Panel-Ebene)

Server-Besitzern

Subusern

Diese Trennung ist hart und darf nicht aufgeweicht werden.

2. Administratoren (Control-Plane-Zugriff)

Administratoren besitzen Zugriff auf:

Nodes

Eggs & Images

Ressourcenlimits

Benutzerverwaltung

API-Keys

Ein Admin-Account entspricht faktisch:

Root-Zugriff auf die gesamte Plattform

2.1 Best Practices für Admin-Accounts

Minimale Anzahl

Kein täglicher Betrieb mit Admin-Rechten

Separate Wartungs-Accounts

Starke Passwort-Policies

Admin-Accounts sind primäre Angriffsziele.

3. Server-Besitzer (Kundenebene)

Der Server-Besitzer ist der primäre Nutzer eines Game-Servers.

Kein Zugriff auf Nodes

Kein Zugriff auf andere Server

Kein Plattform-Zugriff

Diese Isolation ist essenziell für Multi-Tenant-Betrieb.

4. Subuser & Rechtegranularität

Subuser ermöglichen delegierten Zugriff auf einzelne Server.

4.1 Rechtemodell

Rechte werden:

server-spezifisch

feature-basiert

nicht hierarchisch

Beispiele:

Start/Stop

Dateizugriff

Console

Backups

4.2 Sicherheitsfalle

Zu breite Rechtevergabe

Unklare Verantwortlichkeiten

Subuser-Rechte müssen strikt begrenzt werden.

5. API-Tokens (kritisch)

Pterodactyl ist API-First. API-Tokens sind kein Zusatzfeature, sondern Kernbestandteil.

5.1 Arten von API-Tokens

Application API Keys (global)

Client API Keys (serverbezogen)

Application Keys sind extrem privilegiert.

5.2 Sicherheitsimplikationen

Token = Passwort + Rechte

Kein IP-Binding

Kein Ablaufdatum (standardmäßig)

Ein geleakter Application-Key ist ein Plattform-GAU.

5.3 Best Practices für API-Keys

Minimal notwendige Rechte

Separate Keys pro Integration

Regelmäßige Rotation

Monitoring auf API-Nutzung

6. Kundenfähigkeit & Hosting-Realität

Pterodactyl ist kein vollständiges Hosting-System.

Fehlende Komponenten:

Abrechnung

Vertragsverwaltung

Mahnlauf

Kundensupport-Workflow

Pterodactyl ist:

reine technische Plattformsteuerung

7. Integration mit externen Systemen

Typische Integrationen:

WHMCS

Custom Billing-Systeme

Monitoring

Integrationen erfolgen ausschließlich über:

Direkte Datenbankzugriffe sind strikt abzulehnen.

8. Rechte-Eskalations-Risiken

Typische Angriffsvektoren:

Überprivilegierte API-Keys

Subuser mit Console + File-Rechten

Unsichere Eggs mit Shell-Zugriff

Rechte-Eskalation erfolgt meist indirekt, nicht offensichtlich.

9. Logging & Auditing

Pterodactyl bietet:

begrenztes internes Logging

Erforderlich im professionellen Betrieb:

Externe Log-Aggregation

API-Request-Logging

Admin-Aktivitäten dokumentieren

Ohne Auditing ist kein sicherer Plattformbetrieb möglich.

10. Typische Fehlkonfigurationen

Zu viele Admins

Ein API-Key für alles

Keine Subuser-Trennung

Panel als Kunden-Frontend missbraucht

11. Best Practices (Venasty Systems Standard)

Admins minimal halten

API-Keys strikt trennen

Keine Kunden mit Admin-Rechten

Pterodactyl nur als technische Control-Plane

Externe Systeme für Billing & Support

12. Fazit

Pterodactyl bietet ein solides, aber kompromissloses Rechtemodell.

Es schützt nicht vor:

schlechten Entscheidungen

überprivilegierten Nutzern

Sicherer Betrieb erfordert Disziplin, klare Prozesse und strikte Trennung von Verantwortlichkeiten.

Venasty Systems behandelt Benutzer- und Rechteverwaltung als sicherheitskritische Kernkomponente jeder Pterodactyl-Plattform.