Files
RichardandClaude Opus 4.8 5d732277b2 Supervisor S-2: OpenRouter-Agent, read-only Tool-Registry, Analyse-Chat
Der KI-Analyse-Agent (docs/konzepte/KONZEPT-Modul-Supervisor.md, Phase S-2):
- SupervisorToolRegistry (transport-agnostisch, spaeter auch MCP-Light): 7 read-only-Tools -
  query_decisions (inkl. Rejects+ReasonCodes), query_order_events, query_trades, get_dossier
  (Markdown-Kette), read_logs (JSONL je Tag, CID-Filter), get_kpis (TradeAnalytics),
  get_architecture_context. Ausfuehrung fehlertolerant (Exception -> Fehlertext, wirft nie).
  KEIN Tool kann handeln/schreiben.
- OpenRouterClient (IChatCompletionClient): OpenAI-kompatibles Chat-Completions-Schema inkl.
  Function-Calling; Request-Bau + Response-Parsing pur/testbar. API-Key GETRENNT vom Trading:
  env POLYTRADER_OPENROUTER_KEY oder gitignorierte openrouter.key (in .gitignore aufgenommen).
- SupervisorAgent: Function-Calling-Loop (max 8 Iterationen), System-Prompt = Arbeitsanweisung +
  eingebettetes Architektur-Kontext-Dokument (Context/ArchitectureContext.md, EmbeddedResource,
  mit dem Code versioniert - beschreibt Entscheidungswege, ReasonCodes, Leiter-Mechanik, Eigenheiten).
  Tool-Aufrufe werden gesammelt und in der UI transparent angezeigt.
- SupervisorMainForm: neuer Tab 'Analyse' (Chat, Modellwahl default openrouter/auto, Tool-Aufrufe
  live im Verlauf, Token-Zaehler) neben dem Dossiers-Tab.
- Sicherheitskonzept: OpenRouter als bewusst freigegebener Egress dokumentiert (nur Tool-Ergebnisse,
  nie Secrets; Spend-Limit je Key empfohlen).

Tests: +7 (Registry-Ausfuehrung/Fehler, Agent-Loop mit Tool-Rueckfluss, Iterationsgrenze,
Request-Body/Response-Parsing, eingebetteter Kontext). Build 0 Fehler, 351 Tests gruen,
--smoke-ui alle 5 Views gruen.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 18:06:28 +02:00

12 KiB
Raw Permalink Blame History

Software-Sicherheitskonzept — PolyTrader

Stand: 2026-07-14. Lebendes Dokument. Zweck: PolyTrader handelt mit Kryptowerten (potenziell in erheblicher Höhe) und hält dafür Wallet-Private-Keys. Dieses Konzept definiert Schutzgüter, Bedrohungen, den Soll-Zustand (Kontrollen) und eine wiederkehrende Audit-Checkliste, mit der wir die Software regelmäßig überprüfen. Abschnitt 4 hält den aktuellen Befundstand fest.


1. Schutzgüter (Assets), nach Kritikalität

  1. Wallet-Private-Keys (AccountState.PrivateKey) — Kontrolle über die Gelder. Höchste Priorität.
  2. API-Secrets (ApiKey/ApiSecret/ApiPassphrase je Account; Alchemy-Key; Threema-Key; Gitea-PAT).
  3. DB-Zugangsdaten (MySQL, remote gehostet).
  4. Handels-Integrität (keine unautorisierten/fehlerhaften Orders — siehe .agents/rules/clob.md).
  5. Verfügbarkeit & Datenintegrität (Ledger/PnL, Accounting-Belege).

2. Bedrohungsmodell (wesentliche Angriffs-/Verlustpfade)

  • Key-Diebstahl über: DB-Leak/Backup, kompromittierter Host, Hosting-Provider-Zugriff, lokaler Fremdprozess (Prozessliste), Log-/Crash-Dump, versehentlicher Git-Commit.
  • Supply-Chain: bösartiges/verwundbares NuGet-Paket oder vendored-Lib; typosquatting; kompromittiertes Build.
  • Secret-Leakage: Secrets im Quellcode/Git-History, in Logs, auf der Kommandozeile.
  • Unautorisierte/fehlerhafte Trades: Bug oder Manipulation im CLOB-Pfad.
  • Datenabfluss: ungewollte Telemetrie/Phone-Home an Dritte.
  • Transport/MITM: unverschlüsselte Verbindungen (DB, API).
  • Verlust: Ransomware, Hardware-Defekt, kein/kompromittiertes Backup.

3. Ergebnis der ersten Bestandsaufnahme (Lizenzen & Datenabfluss)

Externe Pakete / Lizenzen: Alle aktuell genutzten Pakete sind permissiv lizenziert (MIT bzw. Apache-2.0) — kein Copyleft/GPL, keine Umsatzschwellen-Lizenz: Nethereum.Web3 (MIT), Pomelo.EntityFrameworkCore.MySql (MIT), Microsoft.* EF/Extensions/Test.Sdk (MIT), Newtonsoft.Json (MIT), xunit / xunit.runner (Apache-2.0), Sodium.Core (MIT), Microsoft.Win32.Registry (MIT).

  • QuestPDF bewusst NICHT einführen (Community-Lizenz kostenlos nur < 1 Mio USD Umsatz) → für PDF stattdessen PDFsharp/MigraDoc (MIT).
  • Offen: Lizenzdatei der vendored Threema-Lib (libs/Threema-MsgApi-Net-Core, Community-Port) bestätigen (F4).

Datenabfluss (welche Server erhalten App-Daten?): Kein Telemetrie-/Analytics-/AI-/Tracking-Paket gefunden. Ausgehende Verbindungen (Code-Audit der URLs):

  • Polymarket (data-api, clob, gamma-api) — betriebsnotwendig.
  • Polygon-RPC: Alchemy-WSS + öffentliche Fallbacks (polygon-rpc.com, polygon.llamarpc.com, rpc.ankr.com) — betriebsnotwendig (On-Chain). Hinweis: öffentliche RPCs sehen Wallet-Adresse und gebroadcastete Transaktionen.
  • Eigene MySQL-DB (remote gehostet) — eigene Infrastruktur, kein Dritt-Dienst im engeren Sinn.
  • Mullvad VPN — bewusstes Datenschutz-Tool (Routing).
  • Threema Gateway (msgapi.threema.ch) — App-Inhalte: unsere Benachrichtigungstexte. Bewusstes Feature; end-to-end-verschlüsselt.
  • OpenRouter (openrouter.ai, seit S-2 Supervisor-Modul) — bewusst freigegebener externer Datenempfänger für die KI-Analyse: Es werden ausschließlich die Ergebnisse der read-only-Analyse-Tools gesendet (Entscheidungsjournal, Order-Events, Trades, Log-Auszüge, KPIs, Architektur-Doku) — niemals Secrets/Keys (Logs sind per F6 secret-frei). API-Key getrennt vom Trading (env POLYTRADER_OPENROUTER_KEY bzw. gitignorierte openrouter.key); Spend-Limit je Key bei OpenRouter setzen. Der Agent ist strikt read-only (keine Handels-Tools). → Keine versteckte Datenweitergabe — jede neue ausgehende Verbindung wird hier dokumentiert.

4. Aktuelle Befunde (Audit 2026-07-14)

# Schweregrad Befund Ort Maßnahme
F1 🔴 kritisch Wallet-Private-Keys + API-Secrets als Klartext in MySQL (remote gehostet). DB-Leak/Backup/Hoster-Zugriff = vollständiger Fund-Diebstahl. CoreDbContext.cs:31-33 (PrivateKey/ApiSecret/ApiPassphrase nur HasMaxLength) Keys verschlüsselt at-rest ODER ganz aus der DB (lokaler geschützter Store: Windows DPAPI/ProtectedData, oder OS-Keystore/KMS). Mind.: App-seitige Verschlüsselung mit Schlüssel außerhalb der DB. Danach Keys rotieren (waren im Klartext).
F2 🔴 kritisch Private-Key + Secrets als Kommandozeilen-Argument an redeem_markets.py → für jeden lokalen Prozess in der Prozessliste sichtbar; landet ggf. in Shell-History/Logs. TraderMonitorService.cs:1027 Secrets nicht über argv übergeben — via stdin/Umgebungsvariable/temporär-geschützte Datei, oder Redeem in .NET (Nethereum) statt Python. (Pfad ist ggf. deaktiviert — prüfen und absichern, bevor er live geht.)
F3 🟠 hoch Hardcodierte Secrets im Quellcode (in Git-History): Alchemy-API-Key und Mullvad-Account-ID als Defaults. ServerSettings.cs:74 (Alchemy-Key), :53 (Mullvad-Account) Aus dem Code entfernen → in server_settings.xml/Config (bereits gitignored); beide Secrets rotieren (sind in der History); ggf. History bereinigen.
F4 🟠 hoch Verwundbares/veraltetes Dependency: Newtonsoft.Json 11.0.2 (Advisory NU1903, high) sowie generell alter Stack der vendored Threema-Lib (EF Sqlite 2.1.1, Config 2.1.1, Sodium.Core 1.2.0 — Baujahr ~2018). libs/Threema-MsgApi-Net-Core/…csproj Newtonsoft auf 13.0.x heben; Threema-Lib-Deps modernisieren oder die Threema-Anbindung schlanker neu fassen; Lizenz der Lib bestätigen.
F5 🟡 mittel DB-Transportverschlüsselung zur Remote-MySQL nicht verifiziert. Connection-String (appsettings.Local.json) SslMode=Required (oder VerifyCA/VerifyFull) erzwingen; Server-Zertifikat prüfen.
F6 🟡 mittel Secret-Leakage in Logs nicht ausgeschlossen (Logs liegen als *.log auf Platte; Payload-/Debug-Logs). DebugOrderPayloadLog, diverse _logger Sicherstellen, dass Keys/Secrets nie geloggt werden (Redaction); Log-Zugriff/Retention regeln.
F7 🟡 mittel Öffentliche RPC-Fallbacks sehen Wallet-Adressen + gebroadcastete Tx (Privatsphäre/Metadaten). PolymarketApiService.cs:250 Bewusst akzeptieren oder auf eigene/authentifizierte RPCs beschränken.

Die 🔴-Befunde (F1, F2) betreffen direkt die Kontrolle über die Gelder und sollten vor dem Live-Betrieb mit nennenswerten Beträgen behoben werden.

Status (2026-07-14)

  • F1 behoben AES-256-GCM at-rest (SecretProtection + EF-Converter), portabler Master-Key außerhalb der DB, selbstheilende Migration. Aktivierung im Zielland: POLYTRADER_MASTER_KEY setzen (zufälliger 32-Byte-Base64-Key, separat sichern Verlust = kein Key-Zugriff mehr) + Migration EncryptAccountSecretsWidenColumns anwenden.
  • F2 behoben toter Private-Key-als-argv-Code entfernt; Sicherheitshinweis fürs künftige Auto-Redeem.
  • F3 behoben (Code) Secrets aus dem Quellcode. Offen (deinerseits): Alchemy-Key + Mullvad-Account ROTIEREN (lagen in der Git-History).
  • F4 behoben Newtonsoft.Json 11.0.2 → 13.0.4 (Vuln weg). Follow-up: übriger Threema-Lib-Stack (Sodium/EF-Sqlite) modernisieren.
  • 🟡 F5 TLS-Startwarnung ergänzt; eure Connection enthält bereits SslMode (Warnung blieb aus) → ok.
  • 🟢 F6 geprüft sauber: keine Secret-Werte in Logs (nur Vorhandensein-Flags/Fehlermeldungen). Beibehalten.
  • 🟡 F7 öffentliche RPC-Fallbacks: bewusst akzeptiert oder später auf authentifizierte RPCs beschränken.

5. Kontrollen & Richtlinien (Soll-Zustand)

5.1 Secrets- & Key-Management (Herzstück)

  • Kein Private-Key/Secret im Klartext — weder in DB, Quellcode, Config-Commit, Log noch auf der Kommandozeile. Verschlüsselung at-rest mit Schlüssel außerhalb des verschlüsselten Speichers.
  • Keys idealerweise nicht in der zentralen DB (Blast-Radius): lokaler, maschinengebundener, geschützter Store (DPAPI/ProtectedData, OS-Keystore) oder dedizierter Signer/KMS.
  • Least Privilege: DB-User nur mit nötigen Rechten; getrennte Read-only-Zugänge fürs Reporting.
  • Rotation: nach jeder möglichen Exposition; regelmäßig; dokumentiert.
  • Kein Secret in Git: .gitignore deckt server_settings.xml, appsettings.*.json, .gitea-token ab — bei jeder neuen Secret-Art prüfen.

5.2 Supply-Chain / Dependencies

  • Vor jeder neuen Abhängigkeit: Lizenz (permissiv?), Wartung (aktiv? letzte Version?), Reputation/Downloads, Alternativen prüfen.
  • dotnet list package --vulnerable und --outdated regelmäßig (siehe Checkliste §6).
  • Versionen pinnen; vendored Libs (Threema) wie eigenen Code behandeln (Updates verfolgen).
  • Keine Pakete, die Telemetrie/Phone-Home betreiben, ohne bewusste Entscheidung.

5.3 Datenabfluss (Egress)

  • Allowlist bekannter Ziele (Polymarket, Polygon-RPC, Mullvad, Threema, eigene DB). Jede neue ausgehende Verbindung ist eine bewusste Entscheidung und wird hier dokumentiert.
  • Keine Kundendaten/Secrets an Dritte; Threema erhält nur bewusste Benachrichtigungstexte.

5.4 Trading-/CLOB-Integrität

  • .agents/rules/clob.md gilt: Rollback-Punkt, pure getestete Preis-/Zustandslogik, mehrfache Prüfung.
  • Harte Limits (MaxPerMarket/-Cluster/-Exposure), Kill-Switches, ExitPending-Guards — als Schutz gegen fehlerhafte/exzessive Orders. Änderungen am Geld-Pfad immer mit Tests.

5.5 Netzwerk & Transport

  • TLS überall (DB SslMode=Required, HTTPS/WSS-APIs). VPN (Mullvad) für das Routing.
  • Host-Firewall; nur nötige Ports; Fernzugriff abgesichert.

5.6 Build-/Deploy-Integrität

  • Build aus sauberem, kontrolliertem Environment; keine Secrets in Artefakten (*.dll/*.exe gitignored).
  • Reproduzierbare Releases; Abhängigkeits-Stand je Release festgehalten.

5.7 Logging, Monitoring & Reconciliation

  • Redaction: nie Keys/Secrets loggen. Log-Retention/-Zugriff geregelt.
  • Balance-Anker / Reconciliation (Accounting-Modul, GetUsdcBalanceAsync): Soll-Ist-Abgleich als Frühwarnung für unerwartete Mittelbewegungen/Manipulation.
  • Threema-Alerts für kritische Ereignisse (Auto-Pause, Floor, Fehler).

5.8 Backup & Recovery

  • Verschlüsselte DB-Backups; Key-Backup getrennt vom DB-Backup aufbewahren (sonst wandert der Klartext-Key mit). Restore regelmäßig testen.

5.9 Zugriffskontrolle

  • Wer hat Zugriff auf Host, DB, Backups, Keys? Dokumentiert, minimal, mit MFA wo möglich.

5.10 Incident Response (Key-Kompromittierung)

  • Sofort: Gelder auf neue Wallet(s) bewegen, kompromittierte Keys außer Betrieb, alle betroffenen Secrets rotieren, Ursache analysieren, Ledger/Reconciliation prüfen. Runbook vorhalten.

6. Wiederkehrende Audit-Checkliste (bei jedem Release + mind. quartalsweise)

Dependencies

  • dotnet restore + dotnet list package --vulnerable --include-transitive → 0 offene Advisories (F4).
  • dotnet list package --outdated gesichtet; sicherheitsrelevante Updates eingeplant.
  • Neue/aktualisierte Pakete: Lizenz permissiv? Wartung aktiv? Kein Phone-Home?

Secrets & Keys

  • Secret-Scan über Repo (git grep nach Key-Mustern, 0x…, API-Keys) → keine Secrets im Code/History (F3).
  • Private-Keys/Secrets verschlüsselt at-rest, nicht in der DB im Klartext (F1).
  • Keine Secrets über Kommandozeile/Prozess-Argumente (F2).
  • .gitignore deckt alle Secret-Dateien; kein versehentlich getracktes Secret.

Datenabfluss

  • Egress-Allowlist (§5.3) mit dem Code abgeglichen — keine neue, unerklärte ausgehende Verbindung.
  • Keine neue Telemetrie/Analytics/AI-Anbindung ohne bewusste Freigabe.

Transport & Zugriff

  • DB-Verbindung TLS-erzwungen (F5); API/WSS über HTTPS/WSS.
  • DB-User least-privilege; Backups verschlüsselt + Restore getestet; Key-Backup getrennt.

Logs & Trading

  • Stichprobe Logs: keine Keys/Secrets enthalten (F6).
  • Geld-Pfad-Änderungen seit letztem Audit: Tests grün, clob.md eingehalten.
  • Balance-Reconciliation (Accounting) ohne unerklärte Abweichungen.

Prozess

  • Diese Datei aktualisiert (Befunde F1F7 Status; neue Befunde ergänzt).
  • Optional: /security-review über den aktuellen Diff laufen lassen.

7. Priorisierte Sofort-Empfehlung

  1. F1 + F2 vor Live-Betrieb mit Beträgen beheben (Keys aus Klartext-DB und aus der Kommandozeile).
  2. F3: hardcodierte Secrets entfernen + rotieren.
  3. F4: Newtonsoft 11.0.2 ablösen (verwundbar), Threema-Lib-Stack modernisieren.
  4. Rest (F5F7) zeitnah, dann in den Quartals-Rhythmus überführen.