Überblick
Ottili ONE nimmt Sicherheitslücken ernst. Wenn Sie eine Schwäche in der Ottili-ONE-Plattform oder einer öffentlichen Ottili-Oberfläche entdecken, erklärt dieser Artikel, wie Sie sie verantwortungsvoll melden und was danach passiert.
Das Melden ist vom Incident-Response-Prozess getrennt: Diese Seite beschreibt, *wie Sie es uns melden*; die Schritte Erkennung, Eindämmung und Lösung sind in [Incident Response](/docs/incident-response) beschrieben. Die übergeordnete Sicherheitsarchitektur (Mandanten-Isolation, Authentifizierung, Berechtigungen, Verschlüsselung, Secrets-Management, Audit) finden Sie in der [Sicherheitsübersicht](/docs/security-overview).
Eine Schwachstelle melden
Ottili betreibt einen koordinierten Disclosure-Kanal für Sicherheitsforscher:innen und Kund:innen.
- Disclosure-Kanal:* Berichte richten Sie an security@ottili.one*. Das ist die einzige, kanonische Adresse für Schwachstellenmeldungen.
- Bestätigung:* Ottili bestätigt eine gut formulierte Meldung innerhalb von 72 Stunden* (Acknowledgment-SLA).
- Verschlüsselte Berichte (optional):* Berichte können verschlüsselt eingereicht werden. Derzeit ist kein PGP-Fingerprint veröffentlicht; diese Seite blendet keinen PGP-Block ein, anstatt einen erfundenen Fingerabdruck anzuzeigen.
- Direkter Kontakt:* Kund:innen mit einer aktiven Betreuung können Sicherheitsbedenken auch über ihr Account-Team äußern; die Meldung wird in dieselbe Security-Queue geleitet.
Was Ihre Meldung enthalten sollte
Eine gute Meldung hilft uns bei der schnellen Triage. Geben Sie so viel wie möglich an:
- Eine klare Beschreibung der Schwachstelle und des betroffenen Produkts oder der betroffenen Oberfläche.
- Schritte zur Reproduktion oder — falls vorhanden — ein Proof-of-Concept.
- Die von Ihnen identifizierte potenzielle Auswirkung.
- Eventuelle mildernde Faktoren oder vorgeschlagene Korrekturen (optional).
- Ihre Kontaktdaten (optional, damit wir Rückfragen klären und Sie nennen können).
Geltungsbereich
- Im Geltungsbereich:* die Ottili-ONE-Plattform und die öffentlichen Ottili-Oberflächen (Website, Statusseite, öffentliche Docs). Ottili Auth und die öffentliche Grenze der Unified API.
- Außerhalb des Geltungsbereichs:* Social-Engineering-Angriffe gezielt auf Ottili-Mitarbeiter:innen; physische Sicherheit von Ottili-Büros oder -Einrichtungen; Drittanbieter-Dienste außerhalb von Ottilis Kontrolle.
Verhaltensregeln
Bitte tun Sie nicht* Folgendes:
- Führen Sie keine hochintensiven automatisierten Scanner gegen die Produktion aus.
- Greifen Sie nicht auf Kundendaten zu, ändern oder löschen Sie diese.
- Veröffentlichen Sie die Schwachstelle nicht öffentlich, bevor sie behoben ist.
Bleiben Sie innerhalb der Grenzen autorisierter Tests und bringen Sie niemals Kundendaten in Gefahr.
Schweregrad-Einstufung
Bei Ihrer Meldung weisen wir einen Schweregrad zu, damit der Reaktionsaufwand zur Auswirkung passt. Das Modell entspricht dem aus dem Incident Response:
| Schweregrad | Beschreibung | Reaktionsziel | Update-Rhythmus |
|---|---|---|---|
| Critical* | Aktive Ausnutzung, Datenoffenlegung oder Verlust der Verfügbarkeit eines Kern-Dienstes. | Erkennen und mit der Eindämmung beginnen innerhalb von 1 Stunde. | Status-Updates mindestens alle 4 Stunden bis zur Lösung. |
| High* | Ernsthafte Schwachstelle mit plausiblem Ausnutzungsweg oder Teilausfall eines Kern-Dienstes. | Erkennen innerhalb von 4 Stunden und mit der Eindämmung beginnen. | Status-Updates mindestens zweimal täglich bis zur Lösung. |
| Medium* | Begrenzte Auswirkung oder Ausnutzung erfordert spezifische Bedingungen. | Erkennen innerhalb von 1 Werktag. | Tägliche Status-Updates bis zur Lösung. |
| Low* | Minimale Auswirkung, Härtung oder Defense-in-Depth-Verbesserung. | Erkennen innerhalb von 2 Werktagen. | Updates entsprechend dem Fortschritt der Arbeit. |
Nach Ihrer Meldung
Jede Meldung durchläuft denselben Pfad:
1. Triage* — wir bestätigen den Eingang, reproduzieren nach Möglichkeit und weisen einen Schweregrad zu.
2. Updates* — bei aktiven Problemen veröffentlichen wir den Status auf der [Ottili-Statusseite](https://status.ottili.one) und kontaktieren betroffene Unternehmen direkt.
3. Lösung* — wir beheben die Grundursache und teilen — wo angemessen — eine transparente Post-Incident-Review mit den betroffenen Kund:innen.
Sie erhalten mindestens eine Rückmeldung zum Bestätigungseingang; bei höheren Schweregraden können Sie mit dem oben genannten Rhythmus rechnen.
Safe Harbor und koordinierte Offenlegung
- Wir stimmen die Offenlegung mit den Meldenden ab und nennen keine Personen beim Namen.
- Wir leiten keine rechtlichen Schritte gegen Forschende ein, die in gutem Glauben handeln und sich an die Verhaltensregeln halten.
- Wir nennen Forschende, die genannt werden möchten, in der Anerkennung.
Statusbegriffe
Das Schwachstellen-Disclosure-Programm und die öffentliche Seite /security sind Live (General Availability)*. 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
- [Sicherheitsübersicht](/docs/security-overview) — die gesamte Sicherheitsarchitektur im Überblick.
- [Incident Response](/docs/incident-response) — wie Ottili reagiert, sobald eine Schwachstelle bestätigt ist.
- [Secrets-Management](/docs/secrets-management) — wie Konfigurations- und Integrations-Secrets geschützt werden.
- [Mandantenisolation](/docs/tenant-isolation) — wie Ihr Unternehmen von anderen getrennt bleibt.
- [Konto- und Datensicherheit](/docs/account-and-data-security) — Authentifizierung, Sitzungen, Isolation, Audit.
- [Rollen und Berechtigungen](/docs/roles-and-permissions) — wer was darf.
- [Support-Eskalation](/docs/support-escalation) — wie Sie den Support eskalieren.
- [Feature-Status-Labels verstehen](/docs/understand-feature-status-labels) — was die Statusbegriffe bedeuten.
- [Audit-Logs](/docs/audit-logs) — Nachvollziehbarkeit über alle Module hinweg.
War dieser Artikel hilfreich?