Secrets-Management

Überblick

Secrets-Management beschreibt, wie Ottili ONE die vertraulichen Konfigurations- und Integrationsdaten Ihres Unternehmens schützt — JWT-Schlüssel, Sitzungs-Secrets, API-Keys, Webhook- und Zahlungs-Secrets. Der Leitsatz lautet: kein Secret ist hart im Quellcode eingebettet*. Alle Secrets werden über Umgebungsvariablen injiziert und beim Start über ein Pydantic-Settings-Modell validiert. Dieser Artikel beschreibt die im Quellcode belegte Secrets-Haltung von Ottili ONE, unterscheidet klar zwischen verifiziert und qualifiziert und verknüpft die einzelnen Mechaniken mit den passenden vertiefenden Artikeln.

Die übergeordnete Sicherheitsarchitektur finden Sie in der [Sicherheitsübersicht](/docs/security-overview); Mandantenisolation und Berechtigungen werden in [Mandantenisolation](/docs/tenant-isolation) und [Rollen und Berechtigungen](/docs/roles-and-permissions) behandelt.

Umgebungsbasierte Secrets-Konfiguration (verifiziert)

Ottili ONE injiziert alle Konfigurations- und Integrations-Secrets — JWT, Sitzung, API-Keys, Webhooks und Zahlungen — über Umgebungsvariablen und validiert sie beim Start mit einem Pydantic-Settings-Modell. Jedes Secret ist ein erforderliches, umgebungsgebundenes Feld*; es gibt keinen Quellcode-Literalwert für ein Secret.

Konkret sind folgende Secrets umgebungsgebunden (alle verifiziert gegen libs/common/config_manager_v1.py):

• Ottili Auth:* jwt_access_secret / jwt_secret (Mindestlänge erzwungen).
• Ottili LD3:* session_secret.
• Ottili Coder (Integration):* api_key_secret, internal_secret, encryption_key.
• Stripe (Zahlungen):* secret_key, webhook_secret.
• Shopify:* api_secret.
• eBay:* client_secret.

Jede dieser Komponenten lädt ihr Secret aus der Konfiguration, niemals aus einem hartkodierten Wert. Das bedeutet: ein Deployment ohne die entsprechende Umgebungsvariable startet nicht — das Secret wird nicht durch einen Standardwert ersetzt.

JWT-Signaturgeheimnis aus der Umgebung (verifiziert)

Ottili ONE signiert und prüft Zugriffs- und Refresh-Token mit einem HS256-Algorithmus, dessen Schlüssel aus der Umgebung geladen wird (OTTILI_AUTH_JWT_ACCESS_SECRET / jwt_access_secret). Die Signaturfunktion in libs/common/auth_helper.py dekodiert und validiert das Token mit dem aus der Konfiguration stammenden, geteilten Secret — nicht mit einem im Code hinterlegten Wert.

Das hält die Token-Signatur konsistent über alle authentifizierten Anfragen hinweg und verhindert, dass ein Signaturgeheimnis im Repository landet.

Keine Preisgabe über öffentliche Endpunkte (verifiziert)

Öffentliche Gesundheits- und Status-Endpunkte (z. B. GET /api/health) geben nur das Vorhandensein einer Konfiguration* aus — nie den Secret-Wert selbst. Die Antwort liefert lediglich Boolean-Flags wie configured, mode oder webhookConfigured.

Zusätzlich setzt der Endpunkt Cache-Control: no-store und X-Robots-Tag: noindex, sodass die Antwort weder zwischengespeichert noch von Suchmaschinen indexiert wird. Selbst ein öffentlich erreichbarer Endpoint verrät also kein Secret.

Redaktion sensibler Felder (verifiziert)

Wenn Datei- oder Antwortinhalte gescannt werden, maskiert der Sicherheits-Layer von Ottili ONE gezielt Felder, die Secrets tragen. Die kuratierte Liste _SENSITIVE_FIELDS (services/platform_api/file_system_security_layer.py) umfasst unter anderem:

• password
• token
• api_key
• client_secret
• private_key
• credentials
• encryption_key

Dadurch wird die versehentliche Preisgabe von Secrets aus gescannten Dateien oder API-Antworten verhindert — auch wenn ein solches Feld einmal in einem Dokument auftaucht.

Secrets nicht in der Versionskontrolle (qualifiziert)

Secret-Material liegt in lokalen keys/*.env-Dateien oder im Secret-Store des Deployments und ist von der Versionskontrolle ausgeschlossen. Die .gitignore schließt .env, .env.*, keys/.env, keys/*.env, *.secret und secrets/ aus, während der eigentliche Secrets-Management-Code (services/secrets/*.py) und .env.example-Vorlagen versioniert bleiben. Entwickler:innen kopieren lokal keys/.env.example nach keys/.env.

Ehrliche Einstufung:* Dieser Punkt ist *qualifiziert*, keine unbedingte Garantie. Er hängt davon ab, dass auch der eingesetzte Deployment-Secret-Store dieselbe Ausschlussregel einhält. Die Quellcode-Seite ist sauber — echte Secret-Werte werden nie committet —, aber die Gesamtgarantie erstreckt sich nur so weit wie der Deployment-Store.

Empfehlungen für Administrator:innen

• Deployment-Secret-Store nutzen:* Hinterlegen Sie Secrets in Ihrem Secret-Store (z. B. Umgebungsvariablen des Hosts oder einem verwalteten Secret-Service), nicht in der .env im Repository.
• Nie echte `.env` committen:* Nur .env.example-Vorlagen gehören in die Versionskontrolle.
• Rotation:* Tauschen Sie Secrets regelmäßig und bei Verdacht auf Kompromittierung; ungültige Secrets führen zum kontrollierten Startfehler, nicht zu einem stillen Fallback.
• Minimalprinzip:* Gewähren Sie jedem Dienst nur die Secrets, die er benötigt.

Status und Verfügbarkeit

Ottili ONE unterscheidet klar zwischen Live, Beta, Private Beta, In Development, Planned und Concept. Für das Secrets-Management gilt:

• Verifiziert (Live):* umgebungsbasierte Secrets-Injektion mit Pydantic-Validierung, JWT-Signatur aus der Umgebung (HS256), keine Secret-Preisgabe über öffentliche Gesundheits-/Status-Endpunkte, Redaktion sensibler Felder bei der Inhaltsprüfung.
• Qualifiziert:* der Ausschluss von Secret-Material aus der Versionskontrolle hängt vom Deployment-Secret-Store ab.

Was die Statusbegriffe bedeuten, beschreibt [Feature-Status-Labels verstehen](/docs/understand-feature-status-labels).

Verwandte Artikel

• [Sicherheitsübersicht](/docs/security-overview) — die gesamte Sicherheitsarchitektur im Überblick.
• [Konto- und Datensicherheit](/docs/account-and-data-security) — Authentifizierung, Sitzungen, Isolation, Audit.
• [Mandantenisolation](/docs/tenant-isolation) — wie Ihr Unternehmen von anderen getrennt bleibt.
• [Rollen und Berechtigungen](/docs/roles-and-permissions) — wer Secrets verwalten darf.
• [Approval Queue](/docs/approval-queue) — menschliche Freigabe sensibler Aktionen.
• [Coder-Sicherheit](/docs/coder-security) — Identität, Secrets, Isolation und Audit für Ottili Coder.
• [Geteilte Berechtigungen und Entitlements](/docs/shared-permissions-and-entitlements) — das bereichsübergreifende Berechtigungsmodell.
• [Feature-Status-Labels verstehen](/docs/understand-feature-status-labels) — was die Statusbegriffe bedeuten.