Rollen und Sicherheit
FortressFlag kommt mit vier Rollen und einem Satz Produktionsschutzmaßnahmen, entworfen um eine Idee: Schnell zu sein außerhalb der Produktion soll mühelos sein, und die Produktion zu ändern soll entweder die richtige Rolle oder eine zweite Person erfordern.
Die vier Rollen
Abschnitt betitelt „Die vier Rollen“| Viewer | Developer | Admin | Owner | |
|---|---|---|---|---|
| Flags und Team sehen | ✓ | ✓ | ✓ | ✓ |
| Nicht-Produktionsumgebungen ändern | ✓ | ✓ | ✓ | |
| Produktionsänderungen vorschlagen & genehmigen | ✓ | ✓ | ✓ | |
| Produktion direkt ändern | ✓ | ✓ | ||
| SDK-Schlüssel sehen | ✓ | ✓ | ✓ | |
| SDK-Schlüssel erstellen & widerrufen | ✓ | ✓ | ||
| Team, Projekte & Umgebungen verwalten | ✓ | ✓ | ||
| Audit-Log lesen & exportieren | ✓ | ✓ | ||
| Abrechnung, Nutzung & Organisationsrichtlinie | ✓ |
Ein paar Hinweise, die die Tabelle nicht tragen kann:
- Viewers und Developers sehen nur die Projekte, die ihnen zugeteilt wurden.
- Niemand vergibt eine Rolle über der eigenen. Ein Admin kann Developers einladen, keine Owners.
- Die vollständige Matrix ist in der App veröffentlicht, sodass das, was du im Dashboard siehst, immer dem entspricht, was der Server tatsächlich durchsetzt.
Produktionsänderungen: ein zweites Paar Augen
Abschnitt betitelt „Produktionsänderungen: ein zweites Paar Augen“Developers können Umgebungen mit Produktionsklasse nicht direkt schreiben — aber sie müssen auch nicht auf einen Admin warten. Ein Developer schlägt eine Änderung vor (ein Umschalten, eine Regelbearbeitung), und irgendeine zweite Person — ein anderer Developer oder höher — prüft und genehmigt sie, was sie anwendet.
Die Form davon ist Absicht und lohnt sich, als Käufer zu verstehen:
- Es ist Peer-Review, kein Hierarchie-Review. Zwei Developers zusammen können die Produktion ändern. Der Punkt ist, dass keine einzelne Person sie allein von unterhalb Admin ändert.
- Selbstgenehmigung wird verweigert, Punkt — pro Person, nicht pro Rolle. Selbst ein Admin kann den eigenen Vorschlag nicht genehmigen.
- Das Audit-Log nennt beide Beteiligten bei jedem angewendeten Vorschlag — wer vorgeschlagen, wer genehmigt hat.
Admins und Owners können die Produktion weiterhin direkt schreiben; der Vorschlagspfad ist da, damit der Rest des Teams einen sicheren Weg hinein hat.
Geplante Änderungen
Abschnitt betitelt „Geplante Änderungen“Der Zustand eines Boolean-Flags lässt sich planen: Schalte holiday-banner am Freitag um
09:00 UTC an. Die Änderung wird für jeden Leser genau zur gewählten Zeit wirksam, und eine
Umgebung zu planen erfordert dieselbe Berechtigung wie sie jetzt zu schreiben — ein Zeitplan
ist nur ein Schreibzugriff mit Zeitstempel, und er wird an derselben Latte gemessen.
Das Audit-Log
Abschnitt betitelt „Das Audit-Log“Jede Zustandsänderung landet in einem Audit-Log, das nur angehängt wird: wer, was, wann, von wo, und die Werte vorher/nachher. Admins und Owners können es in der App mit Filtern durchsehen und als CSV exportieren — für eine Incident-Nachbereitung, eine Compliance-Anfrage oder einen Auditor. Siehe Exportiere das Audit-Log für die Anleitung.
Wie geht es weiter?
Abschnitt betitelt „Wie geht es weiter?“- Verlange eine Freigabe für Produktionsänderungen — der Ablauf, Schritt für Schritt
- Plane eine Änderung — eine Umschaltung für später setzen
- Lade dein Team ein — Rollen werden auf der Einladung vergeben