Den Scope eng halten
Schreibt ein Fremdsystem nur Aufgaben, geben Sie weder Löschen noch Einladen. Ontra speichert die Rechteliste am Schlüssel; später eng machen geht, weiten braucht einen neuen Schlüssel. `api_keys.manage` ist ein Rollenrecht, nicht jeder Members Job. „Alles mit einem Schlüssel“ wird in sechs Monaten zum Leck. Ein Fremd-Scheduler lebt von `tasks.write`. Die Mitgliederliste ist ein anderer Schlüssel.
Den Schlüssel benennen, nicht „test“ lassen. Ungenutzte widerrufen. Ein eigener, enger Schlüssel für CI. Logs zeigen, welcher Schlüssel wann lief. Ein verlorener Schlüssel wird rotiert; der alte fällt sofort. Der Erstellschirm zeigt das Geheimnis einmal. Der Screenshot landet nicht im Wiki. Der Wert geht in einen Secret Store, nicht in den Chat.
- Fremdsystemen weder Löschen noch Einladen geben
- Schlüssel nicht „test“ nennen lassen
- Ein verlorener Schlüssel wird rotiert; der alte fällt
- Logs zeigen, welcher Schlüssel wann lief
- Ein eigener, enger, benannter Schlüssel für CI
Integrationsszenarien
Schreibt ein Nachtjob offene Aufgaben in ein Fremd-ERP, reichen Lesen plus enges Schreiben. Öffnet ein Chat-Bot Karten, reicht `tasks.create`; kein Projekt-Löschen. Einen Report ins Fremd-BI zu ziehen ist ein Schlüssel begrenzt auf `reports.read`, kein Admin. Jedes Szenario will einen eigenen Schlüssel. Ein geteilter „Integrations-Admin“ ist grober Zugriff in API-Form.
Ein Schlüssel wird wie ein Sitz geprüft: wessen, wofür, noch nötig? Ungenutzte fallen im Quartalsaudit. Ein geleakter Schlüssel rotieren ist ein Runbook, kein Heldentum. Sie retten den Workspace nicht mit „alles neu bauen“; enger Scope verkleinert den Radius. Darum braucht Weiten einen neuen Schlüssel — den alten Wert aufzublähen ist leicht, ihn zurückzunehmen schwer.
Wohin das Geheimnis nicht gehört
Repo, Wiki, Slack, Screenshot, Mail, eine „vorübergehende“ Notiz. Nichts davon ist ein Secret Store. Eine CI-Variable, ein Vault, eine Env-Datei die nicht in Git geht. Der Schlüssel wird einmal gezeigt, weil ein zweites Zeigen zur Gewohnheit wird. Wer ihn verliert, rotiert. Diese Regel bestraft Menschen nicht; sie verkleinert die Leckfläche.
Schlüsselinventar und Radius
Jede Integration will einen eigenen Schlüssel. Ein Nachtjob der Aufgaben ins ERP schreibt braucht enges Schreiben. Ein Chat-Bot der Karten öffnet braucht `tasks.create`. BI das einen Report zieht braucht `reports.read`. Ein geteilter „Integrations-Admin“ ist grober Zugriff in API-Form. `api_keys.manage` ist nicht jeder Members Job. Weiten braucht einen neuen Schlüssel; den alten Wert aufzublähen ist leicht, ihn zurückzunehmen schwer. Enger Scope verkleinert den Radius. Sie retten den Workspace nicht indem Sie alles neu bauen.
Der Erstellschirm zeigt das Geheimnis einmal. Der Screenshot landet nicht im Wiki. Der Wert geht in ein Vault, nicht in Slack. Der Name bleibt nicht „test“. CI ist ein eigener, enger, benannter Schlüssel. Logs zeigen welcher Schlüssel wann lief. Verlust wird rotiert, der alte fällt. Quartalsrunde: wessen, wofür, noch nötig? Ungenutztes wird widerrufen. Repo, Mail, „vorübergehende Notiz“ sind kein Secret Store.
Ein geleakter Schlüssel rotieren ist ein Runbook, kein Heldentum. Erstens: alten Schlüssel fallen lassen. Zweitens: einen noch engeren neuen ausstellen. Drittens: letzte Nutzung im Log lesen. Viertens: wo das Geheimnis landete (Repo, Chat, Schirm) reinigen. Fünftens: „warum war alles an einem Schlüssel?“ ins Quartal schreiben. Die Scope-Politik geschrieben halten, damit es sich nicht wiederholt.
Der Lebenszyklus eines Schlüssels
Jede Integration will einen eigenen Schlüssel. ERP-Nachtjob bekommt enges Schreiben. Ein Bot bekommt tasks.create. BI bekommt reports.read. Integrations-Admin ist grober Zugriff in API-Form. api_keys.manage ist nicht jeder Members Job. Weiten braucht einen neuen Schlüssel. Enger Scope verkleinert den Radius. Sie retten sich nicht indem Sie alles neu bauen.
Das Geheimnis wird einmal gezeigt. Es landet nicht im Wiki. Es geht in ein Vault. Der Name ist nicht test. CI ist ein eigener enger benannter Schlüssel. Das Log zeigt wann. Verlust wird rotiert der alte fällt. Quartal: wessen wofür noch nötig. Ungenutztes widerrufen. Repo Mail vorübergehende Notiz sind kein Secret Store.
Leck-Runbook: Alten fallen lassen, engeren neuen ausstellen, Log lesen, Landestelle reinigen, warum alles an einem Schlüssel ins Quartal schreiben. Politik geschrieben halten. Fremdsystemen weder Löschen noch Einladen geben.
Ein Schlüssel wird wie ein Sitz geprüft. Ein vergessener Test-Schlüssel läuft sechs Monate später in Production. Ein vergessener Praktikumssitz lässt auch ein Recht. Es ist dieselbe Disziplin. Die Quartalsrunde fragt beides.
Ein Integrationsszenario
Schreibt ein Fremd-Scheduler nur Aufgaben, reicht `tasks.write`. Die Mitgliederliste ist ein anderer Schlüssel. „Alles mit einem Schlüssel“ wird in sechs Monaten zum Leck.
Weitere Beiträge
Produkt
Wenn Aufgabe und Dokument denselben Datensatz teilen, zerfällt die Arbeit nicht
Liste, Board und Roadmap sind Sichten desselben Datensatzes. Eine Entscheidung fällt einmal und jede Fläche zeigt dieselbe Wahrheit. Dieser Text erklärt, wie ein Toolhaufen die Lieferung verzögert und wie Ontra einen Datensatz bindet.
Sicherheit
Feinteilige Rechte lassen das Team aufatmen
Nicht jede Person braucht jedes Projekt. Kommen Projekt-, Ordner- und Listenrechte zur Rolle hinzu, wird Privatsphäre zum Standard. In Agenturen und Holdings ist das Leck selten Absicht — es ist die zu große Abkürzung „Admins sehen alles“.
Einrichtung
Im 7-Tage-Demo den Workspace fertigmachen, nicht die Tool-Tour
Keine Kreditkarte. Ist das Demo vorbei, schließt die App, Daten bleiben. Laden Sie in Woche eins echte Arbeit statt Bildschirme zu besichtigen: Projekt, Rollen, aktiver Sprint, Dokumentenbaum, erster Report. Die Schaufenster-Tour wählt kein Tool; der sitzende Datensatz tut es.