Was macht dieser Skill?
/pg-security ist ein Multi-Tool-Workflow, der vier Security-Tools in Sequenz aufruft und einen vollständigen Sicherheitsbericht erzeugt. Von der Transportverschlüsselung über Authentifizierungsregeln bis hin zu Berechtigungseskalation — der Skill deckt die gesamte Angriffsfläche einer PostgreSQL-Instanz ab.
Workflow-Phasen
- Phase 1 — SSL/TLS:
pg_ssl_auditprüft Zertifikate, Protokollversionen und Cipher-Suites - Phase 2 — pg_hba-Regeln:
pg_hba_analyzeidentifiziert unsichere Authentifizierungsregeln (trust, md5, offene Netzwerke) - Phase 3 — Passwortrichtlinien:
pg_password_policy_checkprüft Passwortanforderungen und ablaufende Passwörter - Phase 4 — Privilege Escalation:
pg_privilege_escalation_checkfindet Pfade, über die Rollen unbeabsichtigt Superuser-Rechte erlangen könnten - Phase 5 — Security Score: Alle Ergebnisse fließen in einen gewichteten Score von 0 bis 100
Wie wird er aufgerufen?
Verbindung herstellen
Jeder Skill beginnt mit einer Datenbankverbindung. Die Enterprise-Plattform unterstützt mehrere Profile — ideal für Multi-Cluster-Setups:
▶ Calling tools...
→ pg_connect { "profile": "production-db" }
{
"status": "connected",
"database": "mcp_test",
"version": "PostgreSQL 16.x",
"host": "db.example.com"
}
Claude CLI (natürliche Sprache)
▶ Calling tools...
→ Phase 1/5: pg_ssl_audit {}
SSL aktiviert: ✓
Protokoll: TLSv1.3, Cipher: TLS_AES_256_GCM_SHA384
Zertifikat: gültig bis 2027-01-15 (296 Tage)
Client-Zertifikate: nicht erzwungen
→ Phase 2/5: pg_hba_analyze {}
12 Regeln analysiert, 3 Probleme gefunden:
→ host all all 0.0.0.0/0 md5 — offener Netzwerkzugang mit schwacher Auth
→ local all postgres trust — Superuser ohne Passwort
→ host replication all 10.0.0.0/8 md5 — breiter Replikationszugang
→ Phase 3/5: pg_password_policy_check {}
8 Rollen geprüft:
→ 2 Rollen ohne Passwort-Ablauf (db_admin, db_analyst)
→ 1 Rolle mit Passwort älter als 180 Tage (app_service)
→ Phase 4/5: pg_privilege_escalation_check {}
1 Escalation-Pfad gefunden:
→ db_analyst → MEMBER OF db_admin → SUPERUSER
→ db_analyst kann über Rollenmitgliedschaft Superuser-Rechte erlangen
→ Phase 5/5: Security Score
╔══════════════════════════════════════════╗
║ Security Score: 61 / 100 ║
╠══════════════════════════════════════════╣
║ SSL/TLS : TLSv1.3 ✓ ║
║ pg_hba Probleme : 3 unsichere Regeln ║
║ Passwort-Policy : 3 Verstöße ║
║ Privilege Escal. : 1 Pfad ║
║ Bewertung : HANDLUNGSBEDARF ║
╚══════════════════════════════════════════╝
MCP Protocol (Skill-Definition)
const result = await client.callTool("/pg-security", {});
// Response:
{
"skill": "/pg-security",
"tools": [
"pg_ssl_audit",
"pg_hba_analyze",
"pg_password_policy_check",
"pg_privilege_escalation_check"
],
"phases": 5,
"output": {
"score": 61,
"ssl": { "enabled": true, "protocol": "TLSv1.3", "cert_days_remaining": 296 },
"hba_issues": 3,
"password_violations": 3,
"escalation_paths": 1,
"recommendations": [
"Replace md5 with scram-sha-256 in pg_hba.conf",
"Remove trust auth for local superuser",
"Restrict replication to specific IPs",
"Set password expiry for db_admin, db_analyst",
"Revoke db_analyst membership in db_admin"
]
}
}
Was passiert unter der Haube?
Der Skill durchläuft vier Audit-Tools und aggregiert die Ergebnisse in einem fünften Schritt:
Phase 1: SSL/TLS Audit
Prüft ssl-Parameter in pg_settings, liest Zertifikatsinformationen aus pg_stat_ssl und bewertet Protokollversion und Cipher-Stärke. TLSv1.2 mit ECDHE gilt als Minimum, TLSv1.3 als optimal.
Phase 2: pg_hba Analyse
Parsed die effektiven pg_hba.conf-Regeln aus pg_hba_file_rules (ab PG 15) und bewertet jede Regel nach Risiko: trust = kritisch, md5 = mittel, scram-sha-256 = sicher, cert = optimal.
Phase 3: Passwortrichtlinien
Prüft pg_authid auf Rollen ohne Passwort-Ablauf (rolvaliduntil IS NULL) und Rollen mit veralteten Passwörtern. Empfiehlt ALTER ROLE ... VALID UNTIL für alle Service-Accounts.
Phase 4: Privilege Escalation
Traversiert den Rollen-Graphen über pg_auth_members und findet Pfade, über die nicht-privilegierte Rollen transitiv Superuser-Rechte erlangen können. Jeder gefundene Pfad ist ein kritisches Finding.
Phase 5: Scoring
Gewichtete Formel:
- 25% — SSL/TLS (Protokoll, Cipher, Zertifikat)
- 30% — pg_hba (unsichere Regeln)
- 20% — Passwortrichtlinien (Ablauf, Stärke)
- 25% — Privilege Escalation (kritische Pfade)
Praxis-Tipp: Führen Sie den Security-Audit nach jedem pg_hba.conf-Change durch. Der trust-Modus für lokale Superuser-Verbindungen ist in Entwicklungsumgebungen üblich, aber in Produktion ein kritisches Risiko.
Was testet die Testsuite?
Die Testsuite validiert den gesamten Security-Workflow gegen eine PostgreSQL-Instanz mit typischer Enterprise-Konfiguration:
Test Files 1 passed (1)
Tests 1 passed (1)
Duration 1.4s
Testdaten-Szenario
Die Test-Instanz enthält:
- pg_hba.conf — 12 Regeln inklusive bewusst unsicherer Einträge (trust, md5, offene Netzwerke)
- SSL-Zertifikat — Self-signed für Testumgebung, TLSv1.3
- 8 Rollen — postgres (Superuser), db_admin, db_analyst, app_service, replicator, readonly, backup, monitoring
- Rollenmitgliedschaften — db_analyst als Mitglied von db_admin (Escalation-Pfad)
Zusammenfassung
/pg-security deckt die vier kritischsten Angriffsvektoren einer PostgreSQL-Instanz ab: Transport, Authentifizierung, Passwörter und Berechtigungen. Der Security Score macht Verbesserungen messbar — und der Skill liefert zu jedem Finding eine konkrete Empfehlung.