Ruoli e sicurezza

FortressFlag arriva con quattro ruoli e un insieme di salvaguardie per la produzione progettati attorno a un’idea: muoversi veloci fuori dalla produzione deve essere senza sforzo, e cambiare la produzione deve richiedere o il ruolo giusto o una seconda persona.

I quattro ruoli

	Viewer	Developer	Admin	Owner
Vedere flag e team	✓	✓	✓	✓
Modificare gli ambienti non di produzione		✓	✓	✓
Proporre e approvare modifiche di produzione		✓	✓	✓
Modificare la produzione direttamente			✓	✓
Vedere le chiavi SDK		✓	✓	✓
Generare e revocare chiavi SDK			✓	✓
Gestire team, progetti e ambienti			✓	✓
Leggere ed esportare il log di audit			✓	✓
Fatturazione, utilizzo e policy dell’organizzazione				✓

Alcune note che la tabella non può contenere:

Viewer e Developer vedono solo i progetti che sono stati loro concessi.
Nessuno concede un ruolo superiore al proprio. Un Admin può invitare Developer, non Owner.
La matrice completa è pubblicata nell’app, così quello che vedi nella dashboard riflette sempre ciò che il server applica davvero.

Modifiche di produzione: un secondo paio di occhi

I Developer non possono scrivere direttamente negli ambienti di classe produzione — ma non devono nemmeno aspettare un Admin. Un Developer propone una modifica (un interruttore, una modifica alle regole), e una qualsiasi seconda persona — un altro Developer o superiore — la esamina e la approva, il che la applica.

La forma di tutto questo è voluta, e vale la pena capirla quando acquisti:

È revisione tra pari, non revisione gerarchica. Due Developer insieme possono cambiare la produzione. Il punto è che nessuna singola persona la cambia da sola da sotto Admin.
L’autoapprovazione è rifiutata, punto — per persona, non per ruolo. Nemmeno un Admin può approvare la propria proposta.
Il log di audit nomina entrambe le parti su ogni proposta applicata — chi ha proposto, chi ha approvato.

Admin e Owner possono comunque scrivere direttamente in produzione; il percorso delle proposte esiste perché il resto del team abbia una via d’accesso sicura.

Modifiche pianificate

Lo stato di un flag booleano può essere pianificato: attiva holiday-banner alle 09:00 UTC di venerdì. La modifica ha effetto esattamente all’ora scelta per ogni lettore, e pianificare in un ambiente richiede lo stesso permesso di scriverci adesso — una pianificazione è solo una scrittura con un timestamp, ed è tenuta allo stesso standard.

Il log di audit

Ogni cambiamento di stato finisce in un log di audit append-only: chi, cosa, quando, da dove, e i valori prima/dopo. Admin e Owner possono sfogliarlo nell’app con i filtri ed esportarlo come CSV — per una revisione di un incidente, una richiesta di compliance o un auditor. Vedi Esporta il log di audit per la procedura.

Prossimi passi

Richiedi l’approvazione per le modifiche di produzione — il flusso, passo dopo passo
Pianifica una modifica — imposta un interruttore per dopo
Invita il tuo team — i ruoli si assegnano sull’invito