Pular para o conteúdo
FortressFlag Docs

Papéis e segurança

O FortressFlag vem com quatro papéis e um conjunto de proteções de produção projetados em torno de uma ideia: andar rápido fora de produção deve ser sem esforço, e mudar produção deve exigir ou o papel certo ou uma segunda pessoa.

Os quatro papéis

Seção intitulada “Os quatro papéis”
Viewer Developer Admin Owner
Ver flags e time ✓ ✓ ✓ ✓
Mudar ambientes fora de produção ✓ ✓ ✓
Propor e aprovar mudanças em produção ✓ ✓ ✓
Mudar produção diretamente ✓ ✓
Ver chaves de SDK ✓ ✓ ✓
Criar e revogar chaves de SDK ✓ ✓
Gerenciar time, projetos e ambientes ✓ ✓
Ler e exportar o registro de auditoria ✓ ✓
Cobrança, uso e política da organização ✓

Algumas notas que a tabela não consegue carregar:

  • Viewers e Developers veem apenas os projetos que lhes foram concedidos.
  • Ninguém concede um papel acima do próprio. Um Admin pode convidar Developers, não Owners.
  • A matriz completa é publicada dentro do app, então o que você vê no painel sempre reflete o que o servidor realmente aplica.

Mudanças em produção: um segundo par de olhos

Seção intitulada “Mudanças em produção: um segundo par de olhos”

Developers não podem escrever diretamente em ambientes de classe de produção — mas também não precisam esperar por um Admin. Um Developer propõe uma mudança (um toggle, uma edição de regras), e qualquer segunda pessoa — outro Developer ou acima — revisa e aprova, o que a aplica.

A forma disso é deliberada, e vale entender como comprador:

  • É revisão por pares, não revisão hierárquica. Dois Developers juntos podem mudar produção. A questão é que nenhuma pessoa sozinha a muda, abaixo de Admin.
  • Autoaprovação é recusada, ponto final — por pessoa, não por papel. Nem um Admin pode aprovar a própria proposta.
  • O registro de auditoria nomeia as duas partes em toda proposta aplicada — quem propôs, quem aprovou.

Admins e Owners ainda podem escrever em produção diretamente; o caminho da proposta existe para que o resto do time tenha uma rota segura para entrar.

Mudanças agendadas

Seção intitulada “Mudanças agendadas”

O estado de uma flag booleana pode ser agendado: ligar holiday-banner às 09:00 UTC de sexta. A mudança entra em vigor exatamente na hora escolhida para todo leitor, e agendar em um ambiente exige a mesma permissão que escrever nele agora — um agendamento é só uma escrita com um timestamp, e é medido pela mesma régua.

O registro de auditoria

Seção intitulada “O registro de auditoria”

Toda mudança de estado cai em um registro de auditoria append-only: quem, o quê, quando, de onde, e os valores antes/depois. Admins e Owners podem navegá-lo dentro do app com filtros e exportá-lo como CSV — para uma revisão de incidente, uma solicitação de compliance ou um auditor. Veja Exporte o registro de auditoria para o passo a passo.

Para onde ir agora

Seção intitulada “Para onde ir agora”