Sicherheitsübersicht

Überblick

Ottili ONE ist plattformorientiert gebaut: Sicherheit ist keine nachträgliche Schicht, sondern Teil der gemeinsamen Steuerungsebene. Jedes Unternehmen arbeitet in einem eigenen, klar abgegrenzten Mandantenkontext, und sensible Aktionen werden nie ohne die richtige Berechtigung oder eine menschliche Freigabe ausgeführt. Dieser Artikel gibt einen übergeordneten Einblick in die Sicherheitsarchitektur — von der Mandanten-Isolation über die Authentifizierung bis zum Melden einer Schwachstelle.

Vertiefende Artikel zu den einzelnen Bereichen finden Sie am Ende unter [Verwandte Artikel](#verwandte-artikel).

Unternehmensbezogene Mandanten-Isolation

Ottili ONE ist mandantenbezogen (company-scoped). Jeder geschäftsrelevante Datensatz gehört zu genau einer verifizierten company_id. Ein Zugriff über Unternehmensgrenzen hinweg wird niemals aus einem Standardwert, einer ersten Mitgliedschaft oder einer Eingabe des Aufrufers abgeleitet.

• Fail-closed Prüfung:* Die gemeinsame Funktion assert_same_company() lehnt jede anfrage ohne oder mit falschem Unternehmenskontext ab. Eine vom Aufrufer mitgelieferte company_id wird niemals vertraut.
• Datenbank-Zeilensicherheit (Row-Level Security):* PostgreSQL filtert jede Plattformzeile nach der verifizierten company_id. Der Laufzeit-Standardzustand ist „verweigern" (deny-by-default).
• Eine Mandantengrenze:* PlatformContext ist die einzige Mandantengrenze. Ohne verifiziertes Unternehmen liefert validate(require_company=True) einen HTTP-403-Fehler.
• Verteilt über die Plattform:* Die Unified-API-Middleware extrahiert die verifizierte company_id pro Anfrage und aktiviert den RLS-Hook, sodass jede Transaktion unternehmensbezogen bleibt. Der Realtime-Bus nutzt geschützte Kanäle (co.{company_id}) und verweigert den Zugriff bei fehlendem Kontext oder Konflikt.
• Ein Berechtigungsmotor:* Es gibt genau eine Berechtigungs-Engine mit deny-by-default. Unbekannte Rolle, unbekannte Berechtigung, fehlendes Unternehmen oder fremder Mandant führen zur Verweigerung — ohne versteckten Admin-Umweg und ohne Platzhalter-Rechte (*).
• Unternehmensbezogene Suche:* Die globale Suche indiziert und liefert nur Dokumente des anfragenden Unternehmens. Dies hängt davon ab, dass der Indexierungsjob die company_id berücksichtigt (qualifiziert).

Identität und Authentifizierung (Ottili Auth)

Die Identität wird von Ottili Auth* bereitgestellt. Die wesentlichen, im Quellcode belegten Mechanismen:

• Passwörter:* Benutzerpasswörter werden mit Argon2id* gehasht. Ottili ONE speichert niemals Klartext-Passwörter.
• JWT-Zugriffstoken:* Ottili ONE stellt signierte JWT-Zugriffstoken (HS256*) aus und prüft sie bei jeder authentifizierten Anfrage.
• Refresh-Token-Rotation:* Refresh-Tokens werden nach einer zeitbasierten Richtlinie rotiert; die Wiederverwendung eines bereits rotierten Tokens wird erkannt und abgelehnt.
• Zweiter Faktor:* Wo aktiviert, fügen Passkeys (WebAuthn)* und Multi-Faktor-Authentifizierung (TOTP)* einen zweiten Verifizierungsschritt hinzu.
• Anmeldung:* Sie können sich mit E-Mail und Passwort, Google, Microsoft oder einem verbundenen Ottili-SSO-Produkt anmelden.
• Sitzungen:* Sitzungen laufen nach einer Idle-Zeit und einer absoluten Maximallebensdauer ab; beide sind durch Ihre Organisation konfigurierbar.

Für Schritt-für-Schritt-Aktionen (Konto erstellen, Passkeys aktivieren, Passwort zurücksetzen) siehe [Konto und Login](/docs/account-and-login) und [Konto- und Datensicherheit](/docs/account-and-data-security).

Zugriffskontrolle und Berechtigungen

Zugriff ist in Ottili ONE explizit: Personen und Automatisierungen erreichen nur das, wofür Sie eine Erlaubnis erteilt haben.

• Rollen und Berechtigungen:* Inhaber:in (Owner), Admin, Manager, Mitarbeiter:in (Employee) und Betrachter:in (Viewer) bestimmen, wer was sehen und tun darf. Sensible Vorgänge prüfen die Rolle, bevor sie ausgeführt werden.
• Genehmigungswarteschlange:* Bestimmte Aktionen werden über die Approval Queue freigegeben — auch KI-gestützte Aktionen laufen nur mit menschlicher Freigabe.
• Geteilte Berechtigungen und Entitlements:* Module, Funktionen und KI-Reichweite werden über ein gemeinsames Berechtigungsmodell gesteuert.
• Ottili Coder:* Auch die Coder-Umgebung folgt denselben Identitäts-, Secrets- und Audit-Regeln.

Mehr dazu in [Rollen und Berechtigungen](/docs/roles-and-permissions), [Geteilte Berechtigungen und Entitlements](/docs/shared-permissions-and-entitlements), [Approval Queue](/docs/approval-queue) und [Unternehmen, Team & Berechtigungen](/docs/company-and-team). Die Verwaltungsoberfläche finden Sie in [Die Ottili Console navigieren](/docs/navigate-ottili-console) und in [Coder-Sicherheit](/docs/coder-security).

Datenschutz und Verschlüsselung

• Im Ruhezustand (Backups):* Ottili ONE kann Backups im Ruhezustand mit AES-256-GCM* verschlüsseln, sofern die Backup-Verschlüsselung aktiviert und eine Passphrase konfiguriert ist. Diese Funktion ist optional/konfigurationsabhängig (qualifiziert).
• Bei der Übertragung:* Service-zu-Service-Verkehr prüft TLS/SSL-Zertifikate; ausgehender E-Mail-Versand nutzt STARTTLS, sofern aktiviert. Der öffentliche Webseiten-Traffic wird über das Plattform-Gateway (Caddy) abgesichert.
• Passwörter und Token:* Siehe [Konto- und Datensicherheit](/docs/account-and-data-security) — Argon2id und HS256 sind verifiziert.

Secrets-Management

• Reine Umgebungsvariablen:* Alle Konfigurations- und Integrations-Secrets (JWT, Sitzung, API-Keys, Webhooks, Zahlungen) werden über Umgebungsvariablen injiziert und beim Start mit einem Pydantic-Settings-Modell validiert. Kein Secret ist hart im Quellcode eingebettet.
• JWT-Signaturgeheimnis aus der Umgebung:* Zugriffs- und Refresh-Token werden mit einem aus der Umgebung geladenen Geheimnis signiert und verifiziert.
• Keine Preisgabe über öffentliche Endpunkte:* Gesundheits- und Status-Endpunkte geben nur das Vorhandensein einer Konfiguration aus, niemals den Secret-Wert selbst.
• Redaktion sensibler Felder:* Felder wie Passwort, Token, api_key, client_secret, private_key und encryption_key werden bei der Inhaltsprüfung maskiert.
• Nicht in der Versionskontrolle:* Secret-Material liegt in lokalen keys/*.env-Dateien oder im Deployment-Secret-Store und ist von der Versionskontrolle ausgeschlossen; nur .env.example-Vorlagen und der Secrets-Management-Code werden versioniert.

Audit und Rechenschaftspflicht

Wichtige Aktionen werden protokolliert und über Observability sichtbar. Zusammen mit der deny-by-default-Zugriffskontrolle und der unternehmensbezogenen Isolation ergibt das eine nachvollziehbare Spur über alle Module hinweg (Business Hub, LD3, Ottili Files, Flows, Coder).

Incident Response und Schwachstellen melden

Sicherheitslücken und Vorfälle nimmt Ottili ernst. Schwachstellen melden Sie verantwortungsvoll über den Disclosure-Kanal auf der [Sicherheitsübersicht](/security) oder an security@ottili.one*.

• Bestätigung:* Ottili bestätigt eine gut formulierte Meldung innerhalb von 72 Stunden*.
• Schweregradmodell:* Critical, High, Medium, Low — mit festen Reaktionszielen und Update-Rhythmus.
• Ablauf:* Erkennung & Triage → Eindämmung → Kommunikation (Statusseite + direkter Kontakt) → Lösung & Post-Incident-Review.
• Koordinierte Offenlegung:* Ottili stimmt die Offenlegung mit Meldenden ab, nennt keine Personen beim Namen und verfolgt Forschende nicht, die in gutem Glauben handeln.

Details und das Ziel der Meldung finden Sie in [Konto- und Datensicherheit](/docs/account-and-data-security).

Zertifizierungen und Compliance

Ottili ONE ist für den Datenschutz gebaut (DSGVO/GDPR). Der aktuelle, im Product-Truth-Register gepflegte Status:

• DSGVO (EU-Datenschutz):* Referenziert — Ottili ONE ist für die DSGVO konzipiert (Betroffenenrechte, Rechtsgrundlagen, Löschfristen, Subprozessor-Transparenz).
• SOC 2 Type II:* Geplant — noch keine Attestierung abgeschlossen; wir beanspruchen diese Zertifizierung nicht.
• ISO/IEC 27001:* Geplant — Ausrichtung ist geplant; Ottili ist noch nicht zertifiziert.
• ISO/IEC 27017:* Nicht gehalten — wir beanspruchen diese Zertifizierung nicht.

Aussagen, die noch nicht verifiziert sind, werden nicht als zertifiziert dargestellt.

Statusbegriffe

Ottili ONE unterscheidet klar zwischen Live, Beta, Private Beta, In Development, Planned und Concept. Was diese Begriffe bedeuten, beschreibt [Feature-Status-Labels verstehen](/docs/understand-feature-status-labels).

Verwandte Artikel

• [Konto- und Datensicherheit](/docs/account-and-data-security) — Authentifizierung, Sitzungen, Isolation, Audit, Schwachstellen melden.
• [Rollen und Berechtigungen](/docs/roles-and-permissions) — wer was darf.
• [Geteilte Berechtigungen und Entitlements](/docs/shared-permissions-and-entitlements) — das bereichsübergreifende Berechtigungsmodell.
• [Approval Queue](/docs/approval-queue) — menschliche Freigabe sensibler Aktionen.
• [Unternehmen, Team & Berechtigungen](/docs/company-and-team) — wie Rollen und Zugriff funktionieren.
• [Die Ottili Console navigieren](/docs/navigate-ottili-console) — wo Sie Einstellungen und Verwaltung finden.
• [Coder-Sicherheit](/docs/coder-security) — Identität, Secrets, Isolation und Audit für Ottili Coder.
• [Feature-Status-Labels verstehen](/docs/understand-feature-status-labels) — was die Statusbegriffe bedeuten.