Sicherheitskonzept für externe Previews und Public Testing

Verbindliche Schutzmaßnahmen und Freigabekriterien für externe Interessenten, Dev-Instanzen und späteres Public Testing.

Zweck und Entscheidung

Dieses Konzept gilt, bevor externe Interessenten, Pilotpartner oder öffentliche Tester Zugriff auf Clapilot erhalten. Es trennt drei Schutzobjekte, die nicht durch dieselbe Maßnahme abgesichert werden können:

Quellcode und Betriebswissen: Repository, Build-Artefakte, Quellkarten, Logs, Fehlermeldungen und interne Dokumentation.
Instanz und Infrastruktur: Anwendung, ClapilotAICore, Datenbank, Workspace, Admin-Funktionen, Provider-Zugänge und ausgehende Kanäle.
Daten und Identitäten: Kunden-, Mitarbeiter- und Testdaten sowie die Aktionen, die ein eingeloggter Benutzer oder Agent ausführen darf.

Die Freigabeentscheidung lautet:

Externe Produktdemos und geschlossene Tests erfolgen über eine separate, kurzlebige Preview-Instanz mit synthetischen Daten und individuellen Nicht-Admin-Konten.
Ein normaler Tester erhält keinen Repository-, Host-, Container-, Datenbank- oder Admin-Zugang. Ein NDA ergänzt diese technischen Grenzen, ersetzt sie aber nicht.
Die produktive Instanz, produktive Backups, echte Postfächer, Kalender, Dokumente, OAuth-Verbindungen und Provider-Credentials werden nicht für Demos oder Tests verwendet.
Public Testing startet erst, wenn die zusätzlichen Muss-Kriterien in diesem Dokument nachweisbar erfüllt sind. Bis dahin bleibt der Zugang einladungsbasiert.

Bedrohungsmodell

Risiko	Beispiel	Auswirkung	Priorität	Primäre Kontrolle
Datenabfluss	Tester sieht fremde Dokumente, Erinnerungen, Chatverläufe oder Logs	Sehr hoch	Kritisch	isolierte Datenbank/Volumes, synthetische Daten, Autorisierungstests
Missbrauch von Agent-Rechten	Prompt oder UI löst Terminal-, Datei-, Versand- oder Integrationsaktionen aus	Sehr hoch	Kritisch	Hochrisiko-Tools und ausgehende Kanäle deaktivieren; kein Admin-Konto
Credential-Diebstahl	API-Key, OAuth-Token oder Session-Cookie gelangt über UI, Log oder Build zum Tester	Sehr hoch	Kritisch	eigene Preview-Secrets, minimale Scopes, Redaction, Rotation und kurze Laufzeit
Instanzübernahme	Brute Force, gestohlene Session oder ungepatchte Abhängigkeit	Hoch	Hoch	vorgeschaltete Zugangskontrolle, Login-Limits, sichere Cookies, Patch- und Scan-Gate
Quellcode-Offenlegung	Repository-Zugang, Source Maps, Stacktraces oder lesbares Image	Mittel bis hoch	Hoch	privates Repo, kein Repo-Zugang, Produktions-Build, keine öffentlichen Maps/Debug-Endpunkte
Ressourcen-/Kostenmissbrauch	ungebremste Modell-, Medien- oder E-Mail-Aufrufe	Hoch	Hoch	Nutzer-/IP-Limits, Budgets, Quoten, Alarmierung und Kill Switch
Nachahmung	Screenshots, Workflows oder Code werden kopiert	Geschäftlich relevant	Mittel	gestufte Offenlegung, NDA/Vertragsregeln, Wasserzeichen; technischer Vorsprung und Schutzrechte
Fehlende Nachvollziehbarkeit	Vorfall lässt sich keinem Nutzer zuordnen	Hoch	Hoch	Einzelkonten, Audit-Logs, Zeitstempel, Aufbewahrung und Incident-Ablauf

Nachahmung lässt sich durch Zugriffsschutz nur reduzieren, nicht verhindern: Browser liefern notwendigerweise HTML, JavaScript, API-Formen und sichtbare Produktabläufe aus. Vertraulich bleiben deshalb Servercode, Prompts, Betriebsdetails und nicht benötigte Funktionen; der sichtbare Nutzen darf nicht als Geschäftsgeheimnis allein abgesichert werden.

Bewertung des aktuellen Repository-Stands

Die detaillierte technische Bestandsaufnahme des jeweils aktuellen Repository- und Deployment-Stands wird intern gepflegt und ist nicht Teil dieser öffentlichen Dokumentation. Sie ist kein Penetrationstest und kein Nachweis der tatsächlich laufenden Infrastruktur; Deployment-Einstellungen, Edge-Konfiguration und externe Dienste werden im Freigabeprotokoll separat belegt.

Aktuelle Entscheidung: Die bestehende Dev- oder Standard-Compose-Instanz ist in dieser Form No-Go für direkten externen Zugriff. Für einen ersten externen Interessenten ist zunächst Stufe 0 (geführte Demo) zulässig. Stufe 1 wird erst nach Aufbau einer isolierten Preview und vollständig dokumentierter Go/No-Go-Prüfung freigegeben. Public Testing bleibt bis zum Nachweis der zusätzlichen Public-Test-Kriterien gesperrt.

Zugangsmodelle

Stufe	Zielgruppe	Erlaubter Zugang	Voraussetzungen
0 – Geführte Demo	Interessenten ohne Prüfbedarf	Bildschirmfreigabe durch Clapilot; keine Zugangsdaten	freigegebener Demo-Datensatz, keine sichtbaren Secrets oder internen Admin-Seiten
1 – Geschlossene Preview	namentlich bekannte externe Interessenten	zeitlich begrenztes persönliches Benutzerkonto auf isolierter Preview	NDA/Vertraulichkeit nach Bedarf, Zugangsgateway, alle Preview-Muss-Kriterien erfüllt
2 – Technische Due Diligence	benannte technische Prüfer	gezielt freigegebene Architekturunterlagen; Quellcode nur als ausdrücklich genehmigte Ausnahme	schriftlicher Scope, Need-to-know, separates Read-only-Repo oder Datenraum, Protokollierung, Entzugstermin
3 – Public Testing	unbekannte oder selbst registrierende Nutzer	mandantenfähige öffentliche Testumgebung	Public-Test-Muss-Kriterien, Datenschutz-/Nutzungsbedingungen, Abuse-Betrieb und Incident-Bereitschaft

Ein Stufenwechsel ist eine neue Freigabe. Insbesondere berechtigt ein Preview-Konto nicht zu Quellcodezugang.

Muss-Kriterien für eine geschlossene externe Preview

Isolation und Daten

Eigene Deployment-Umgebung, Datenbank, Workspace-Volumes, Object Storage, Cache und Backup-Ziel; keine Netzwerkroute zur Produktion außer ausdrücklich notwendiger, read-only betriebener Observability.
Ausschließlich synthetische oder dokumentiert anonymisierte Daten. Keine Kopie eines Produktions-Dumps, auch nicht „nur kurz“.
Ein reproduzierbarer Reset setzt die Preview auf einen bekannten Seed zurück. Reset und Löschfrist werden vor Freigabe getestet.
Preview-Backups sind standardmäßig aus oder kurz befristet und mit einem eigenen Schlüssel verschlüsselt.

Identität und Berechtigung

Zugang ist invite-only und zusätzlich am Edge eingeschränkt, beispielsweise per Identity-Aware Proxy, Access-Gateway oder VPN. Ein gemeinsames Passwort ist unzulässig.
Jeder Tester nutzt ein persönliches Konto mit Ablaufdatum und Rolle leserecht. Admin-, Service- und Entwicklerkonten bleiben intern.
MFA ist am vorgeschalteten Zugang verpflichtend. Falls die App selbst noch kein MFA erzwingt, ist das Edge-Gateway die kompensierende Kontrolle.
Login-Rate-Limiting ist aktiv. CLAPILOT_TRUST_PROXY_HEADERS wird nur gesetzt, wenn ausschließlich ein vertrauenswürdiger Proxy die Weiterleitungsheader überschreibt.
HTTPS ist erzwungen; Session-Cookies sind Secure, HttpOnly und angemessen SameSite-beschränkt. Das Secure-Flag ist nur wirksam, wenn der Reverse-Proxy https per x-forwarded-proto meldet; dieser Header wird derzeit ungeprüft vertraut. In der Preview wird deshalb SESSION_COOKIE_SECURE=true explizit gesetzt und das Cookie-Verhalten am externen Endpunkt verifiziert. AUTH_SECRET und System-Auth-Secrets sind preview-spezifisch und zufällig erzeugt.
Kontoanlage, Rollenwechsel, Secret-Verwaltung, Demo-Reset, Admin-Terminal, Runtime-Dateibrowser und Entwickler-/Modulwerkzeuge sind für Tester weder in Navigation noch über die zugehörigen APIs erreichbar. Die API-Autorisierung ist entscheidend; ausgeblendete UI allein genügt nicht.

Agent, Integrationen und Egress

Admin-Terminal, beliebige Shell-/Codeausführung, Host-/Workspace-Dateizugriff, lokales Modul-Scaffolding sowie Installation fremder Module oder Skills sind deaktiviert oder ausschließlich internen Admins erlaubt.
E-Mail-, Kalender-, Slack-, Telegram-, WhatsApp-, Social-Media-, Telefonie-, Post- und andere ausgehende Integrationen sind nicht mit realen Konten verbunden. Wo eine Demo nötig ist, wird ein Sink-/Sandbox-Ziel mit Allowlist verwendet.
Agent-Aktionen bleiben im Draft-/Review-/Approval-Pfad. Versand, Veröffentlichung, Löschen und andere irreversible Mutationen werden zusätzlich serverseitig blockiert.
Modell- und Medienanbieter verwenden eigene Preview-Projekte/Keys mit minimalem Scope, harten Tagesbudgets und Alarmen. Subscription-/OAuth-Credentials persönlicher Entwickler werden nicht eingesetzt.
Ausgehender Netzwerkverkehr wird soweit betrieblich möglich auf notwendige Ziele beschränkt. Interne Runtime- und Datenbankports sind nicht öffentlich erreichbar.

Anwendung und Betrieb

Es läuft ein reproduzierbarer Release-/PR-Build, kein Hot-Reload-Dev-Server. Debug-Endpunkte, detaillierte Stacktraces, Verzeichnislisting und öffentlich abrufbare Browser-Source-Maps sind deaktiviert.
Response-Header setzen mindestens HSTS, eine getestete Content Security Policy, X-Content-Type-Options: nosniff, eine restriktive Referrer Policy und eine passende Frame-Policy (frame-ancestors). CORS erlaubt keine pauschalen fremden Origins mit Credentials.
Vor Freigabe sind Abhängigkeits-, Container- und Secret-Scans ohne offene kritische Findings abgeschlossen. Hohe Findings brauchen dokumentierte Risikofreigabe, Owner und Termin.
Benutzer- und IP-bezogene Limits schützen Login, Chat/Agent-Ausführung, Uploads, Mediengenerierung, Einladungen und kostenpflichtige Provider-Aufrufe.
Audit-Logs erfassen Login, fehlgeschlagene Authentifizierung, Rollen-/Konfigurationsänderungen, Agent-Mutationen, Exporte und ausgehende Aktionen. Logs enthalten keine Tokens, Prompts mit Secrets oder vollständige vertrauliche Payloads.
Ein benannter Owner überwacht Verfügbarkeit, Auth-Fehler, ungewöhnliche Kosten und Egress. Es gibt einen getesteten Kill Switch für Zugang und Provider-Keys.

Zusätzliche Muss-Kriterien vor Public Testing

Public Testing ist kein bloß größerer Preview-Test. Vor einer öffentlichen Freigabe müssen zusätzlich erfüllt sein:

nachgewiesene Mandantentrennung in Datenbankabfragen, Dateien, Suche/RAG, Memory, Chat/Team-Räumen, Jobs, Events, Exports und Agent-Tool-Aufrufen;
Selbstregistrierung mit E-Mail-Verifikation, Bot-/Abuse-Schutz, MFA-Angebot und sicherem Passwort-Reset oder ein externer Identity Provider;
serverseitige Quoten pro Nutzer und Mandant sowie globale Kostenobergrenzen; Upload-Typ-, Größen-, Malware- und Entpack-Limits;
aktueller externer Penetrationstest oder unabhängiger Security-Review der internetexponierten Auth-, Autorisierungs-, Upload-, Modul- und Agent-Pfade; kritische und hohe Findings sind geschlossen oder formal risikobehandelt;
dokumentierte Datenschutzinformationen, Nutzungsbedingungen, Auftragsverarbeitungs-/Unterauftragnehmerlage, Lösch- und Exportprozess sowie ein Kanal für Security-Meldungen;
belastbarer Incident-Response-Ablauf mit Rufbereitschaft, Kontaktliste, Beweissicherung, Meldeentscheidungen und getesteter Wiederherstellung;
definierte SLOs, Monitoring, Backup-Restore-Test und Kapazitäts-/Lasttest für die erwartete Nutzerzahl.

Solange eine dieser Bedingungen fehlt, bleibt die Instanz geschlossen und einladungsbasiert.

Quellcode-Schutz

Regelfall

Das Haupt-Repository bleibt privat. Tester erhalten keine GitHub-Organisations- oder Repository-Mitgliedschaft, keine CI-Logs und keine Registry-Berechtigung.
Container-Images und Artefakte bleiben in privaten Registries. Externe Nutzer greifen nur auf den laufenden Dienst zu; Images werden nicht verteilt.
Build-Metadaten dürfen eine Commit-ID zur Nachvollziehbarkeit enthalten, aber keine Secrets, internen Pfade oder Zugangsdaten. Öffentliche Source Maps und Debug-Bundles werden vor Freigabe geprüft.
Interne Architektur-, Prompt-, Runbook- und Sicherheitsdokumente werden nur nach Need-to-know geteilt. Screenshots und Demo-Exporte werden auf Metadaten, Tokens, Namen und interne URLs geprüft.

Ausnahme: Quellcodeprüfung

Wenn eine Due Diligence Quellcode erfordert, entscheidet ein benannter Repository-Owner schriftlich über Scope und Dauer. Bevorzugt wird zuerst ein synchroner Review oder Datenraum. Falls Repository-Zugang notwendig ist:

separates, minimiertes Read-only-Repository ohne Historie außerhalb des Scopes, Secrets, Produktionskonfiguration, Kundendaten, CI-Deploy-Schlüssel und interne Sicherheitsdetails;
persönliche Identität mit MFA, kürzestmögliche Berechtigungsdauer und protokollierter Owner;
vertragliche Zweckbindung, Vertraulichkeit, Weitergabeverbot und Rückgabe-/Löschpflicht;
sofortiger Entzug nach dem Review sowie Prüfung der Audit-Ereignisse;
Annahme, dass gelesener oder geklonter Code technisch nicht „zurückgeholt“ werden kann. Besonders schützenswerte Komponenten werden daher nur gezeigt, wenn der geschäftliche Nutzen dieses Restrisiko rechtfertigt.

Freigabeprozess und Evidenz

Für jede Preview wird ein Freigabeprotokoll mit Instanzname, Commit-SHA, Zeitraum, Testern, Owner und Datenklassifikation angelegt. Folgende Nachweise werden verlinkt oder angehängt:

Architektur-/Netzskizze, die getrennte Datenbank, Volumes, Secrets und nicht öffentliche Runtime-Ports zeigt;
Rollen- und Endpoint-Tests für einen externen leserecht, insbesondere negative Tests gegen Admin, Settings, Terminal, Runtime-Dateien, Demo-Reset und Modul-/Skill-Installation;
Seed-/Reset-/Löschtest und Bestätigung, dass keine Produktionsdaten oder -Backups vorliegen;
Konfigurationsauszug ohne Secret-Werte für Edge-Auth, HTTPS/Cookies, Rate Limits, Provider-Budgets und deaktivierte Integrationen;
Ergebnisse der Secret-, Dependency- und Container-Scans sowie offene Risikofreigaben;
manueller Test der zentralen erlaubten Nutzerabläufe und der serverseitigen Sperren für ausgehende oder irreversible Aktionen;
Ablaufdatum der Konten und Instanz sowie zuständiger Incident-Kontakt.

Die Freigabe erfordert vier Augen: Product/Business bestätigt Zielgruppe und offengelegte Funktionen; Engineering/Security bestätigt die technischen Muss-Kriterien. Eine Abweichung von einem Muss-Kriterium braucht eine dokumentierte, befristete Risikofreigabe durch beide Rollen. Für Produktionsdaten, geteilte Admin-Konten, öffentlich erreichbare interne Ports oder wiederverwendete Produktions-Secrets gibt es keine Ausnahme.

Offboarding und Vorfall

Am Enddatum werden Edge- und App-Konten deaktiviert, Sessions widerrufen, Einladungen geschlossen und Preview-Secrets/Provider-Keys rotiert oder gelöscht. Daten, Volumes, Logs und Backups werden gemäß der festgelegten Frist gelöscht; der Abschluss wird dokumentiert.

Bei Verdacht auf Missbrauch: Zugang und Egress sperren, Preview isolieren, betroffene Keys/Sessions widerrufen, Logs beweissicher exportieren, Umfang und Datenbezug bewerten und die interne Incident-Kette aktivieren. Die Instanz wird erst nach Ursachenbehebung und neuer Vier-Augen-Freigabe wieder geöffnet.

Go/No-Go-Checkliste für den ersten externen Zugang

Ein nicht markierter Punkt bedeutet No-Go.