Roles y seguridad
FortressFlag viene con cuatro roles y un conjunto de salvaguardas de producción diseñadas alrededor de una idea: moverse rápido fuera de producción debería no costar nada, y cambiar producción debería exigir o bien el rol adecuado o bien una segunda persona.
Los cuatro roles
Sección titulada «Los cuatro roles»| Viewer | Developer | Admin | Owner | |
|---|---|---|---|---|
| Ver flags y equipo | ✓ | ✓ | ✓ | ✓ |
| Cambiar entornos que no son de producción | ✓ | ✓ | ✓ | |
| Proponer y aprobar cambios en producción | ✓ | ✓ | ✓ | |
| Cambiar producción directamente | ✓ | ✓ | ||
| Ver claves SDK | ✓ | ✓ | ✓ | |
| Emitir y revocar claves SDK | ✓ | ✓ | ||
| Gestionar equipo, proyectos y entornos | ✓ | ✓ | ||
| Leer y exportar el registro de auditoría | ✓ | ✓ | ||
| Facturación, uso y política de la organización | ✓ |
Unas notas que la tabla no puede llevar:
- Los Viewers y los Developers ven solo los proyectos que se les han concedido.
- Nadie concede un rol por encima del suyo. Un Admin puede invitar Developers, no Owners.
- La matriz completa se publica dentro de la app, así que lo que ves en el panel refleja siempre lo que el servidor aplica de verdad.
Cambios en producción: un segundo par de ojos
Sección titulada «Cambios en producción: un segundo par de ojos»Los Developers no pueden escribir directamente en entornos de clase producción — pero tampoco tienen que esperar a un Admin. Un Developer propone un cambio (un cambio de estado, una edición de reglas), y cualquier segunda persona — otro Developer o superior — lo revisa y lo aprueba, lo que lo aplica.
La forma de esto es deliberada, y vale la pena entenderla como comprador:
- Es revisión entre pares, no revisión jerárquica. Dos Developers juntos pueden cambiar producción. La idea es que ninguna persona sola la cambie por debajo de Admin.
- La autoaprobación se rechaza, sin excepciones — por persona, no por rol. Ni siquiera un Admin puede aprobar su propia propuesta.
- El registro de auditoría nombra a ambas partes en cada propuesta aplicada — quién propuso, quién aprobó.
Los Admins y los Owners pueden seguir escribiendo en producción directamente; la vía de las propuestas está ahí para que el resto del equipo tenga una ruta segura de entrada.
Cambios programados
Sección titulada «Cambios programados»El estado de un flag booleano se puede programar: activar holiday-banner a las 09:00 UTC
del viernes. El cambio entra en vigor exactamente a la hora elegida para todos los lectores,
y programar un entorno requiere el mismo permiso que escribir en él ahora — una programación
es solo una escritura con una marca de tiempo, y se le exige el mismo listón.
El registro de auditoría
Sección titulada «El registro de auditoría»Cada cambio de estado acaba en un registro de auditoría de solo anexado: quién, qué, cuándo, desde dónde, y los valores de antes y después. Los Admins y los Owners pueden consultarlo dentro de la app con filtros y exportarlo como CSV — para una revisión de incidente, una solicitud de cumplimiento o un auditor. Mira Exporta el registro de auditoría para el recorrido paso a paso.
¿Por dónde seguir?
Sección titulada «¿Por dónde seguir?»- Exige aprobación para los cambios en producción — el flujo, paso a paso
- Programa un cambio — deja un cambio de estado para más tarde
- Invita a tu equipo — los roles se asignan en la invitación