Permissões Granulares em Organizações
Permissões granulares controlam o que cada membro pode ver ou alterar dentro de uma organização. Elas aumentam a segurança porque reduzem acessos amplos e permitem liberar somente as ações necessárias para cada pessoa.
Na prática, você pode permitir que um usuário visualize apenas um projeto, consulte logs sem alterar configurações, acione deploys sem acessar cobrança ou gerencie pagamentos sem tocar em variáveis de ambiente.
Modelo de acesso
O acesso combina três elementos:
| Elemento | Função |
|---|---|
| Papel | Define o nível base do membro: owner, assistant ou member |
| Recurso | Define a área afetada, como projeto, banco, GitHub, cobrança, chave de IA ou API key global |
| Ação | Define a operação permitida, como ler logs, alterar ambiente ou criar checkout |
O owner tem acesso completo à organização. Para assistant e member, as permissões podem ser mais amplas ou mais restritas, conforme o recurso e a ação.
Recursos protegidos
As permissões podem ser aplicadas a diferentes recursos da organização.
| Recurso | Exemplos de acesso |
|---|---|
| organization | Criar projetos, convidar membros, alterar permissões |
| project | Ver projeto, logs, métricas, variáveis, domínio, rede, instâncias e imagem |
| database | Ver status, acessar conexão, rotacionar senha e atualizar versão |
| github | Ver configuração, alterar integração, acionar deploy e consultar builds |
| ai_key | Criar, visualizar, excluir chaves e consultar uso de IA |
| api_key | Visualizar e revogar API keys globais da organização |
| billing | Consultar cobrança, transações, checkout e métodos de pagamento |
Algumas permissões são sensíveis e devem ser concedidas com cuidado. Acesso a variáveis de ambiente, conexão de banco, cobrança e alteração de deploy pode impactar operação, segurança ou custos.
Escopo por recurso
Permissões podem ser concedidas para todos os recursos de um tipo ou para um recurso específico. Por exemplo, um membro pode receber acesso somente ao projeto de homologação, sem visualizar projetos de produção.
Exemplos:
- acesso a logs e métricas de um único projeto;
- permissão para atualizar imagem de todos os projetos de uma organização;
- permissão para consultar conexão de um banco específico;
- permissão para revogar uma API key global específica;
- acesso de leitura à cobrança sem permissão para configurar pagamento;
- autorização para acionar deploy via GitHub sem alterar a integração.
Esse escopo evita que pessoas com responsabilidades limitadas tenham visibilidade ou controle sobre recursos que não fazem parte do trabalho delas.
Papéis recomendados
Use papéis como ponto de partida e ajuste permissões conforme a necessidade.
| Perfil | Configuração recomendada |
|---|---|
| Fundador ou administrador principal | owner, com revisão periódica dos membros |
| Líder técnico | assistant, com acesso operacional aos projetos necessários |
| Desenvolvedor de um serviço | member, com acesso ao projeto específico, logs, métricas e deploy |
| Analista financeiro | member, com leitura de billing e transações |
| Suporte | member, com leitura de logs e métricas, sem alteração de ambiente |
Evite transformar todos os colaboradores em assistant. Quanto mais amplo o papel, maior o impacto de erro humano, credenciais comprometidas ou alterações não planejadas.
Exemplos práticos
Desenvolvedor com acesso a um projeto
Conceda leitura do projeto, logs, métricas e deploy apenas no recurso específico. Se a pessoa também precisa alterar variáveis de ambiente, adicione essa ação explicitamente.
Responsável por cobrança
Conceda leitura de billing e transações. Só permita configurar pagamento ou criar checkout quando a pessoa realmente for responsável por métodos de pagamento.
Operador de banco
Conceda status e conexão do banco específico. Rotação de senha e atualização de versão devem ficar restritas a pessoas autorizadas.
Boas práticas de segurança
- aplique o princípio do menor privilégio;
- prefira acesso por projeto em ambientes críticos;
- revise permissões quando uma pessoa muda de função;
- remova membros que não participam mais da organização;
- limite acesso a billing, segredos e configuração de deploy;
- use contas individuais, nunca credenciais compartilhadas.
Permissões granulares são mais eficazes quando fazem parte de uma rotina de governança. Revise membros e permissões em intervalos definidos, principalmente em organizações com produção, dados sensíveis ou custos relevantes.
Próximos passos
- Entenda organizações na Zenifra
- Convide membros para uma organização
- Crie API keys da organização
- Configure a segurança da sua conta
FAQ
Owner precisa de permissões configuradas manualmente?
Não. O owner tem acesso completo à organização.
Posso permitir acesso a apenas um projeto?
Sim. Permissões podem ser aplicadas a recursos específicos, permitindo acesso limitado a um projeto ou banco.
Permissões substituem boas práticas de conta?
Não. Use permissões granulares junto com senha forte, 2FA, revisão de membros e remoção de acessos desnecessários.