Acesso Delegado

Dê às pessoas exatamente o acesso de que precisam — e nada mais

Traga um desenvolvedor, entregue o faturamento ao seu contador, dê a um cliente uma janela somente leitura para os sites dele ou permita que nossa equipe de suporte analise um problema. Cada permissão concedida é uma função com permissões definidas, restritas a uma organização, aplicadas no banco de dados e registradas em um log de auditoria somente de inclusão.

  • 94permissões granulares
  • 12funções integradas
  • 8departamentos da equipe
  • +650.000sites hospedados no mundo todo

Acesso é uma assinatura, não uma senha compartilhada

Compartilhar um único login é onde o acesso à conta dá errado. Na Zinn Digital® cada pessoa tem sua própria identidade, e o acesso é uma assinatura — um usuário, uma organização e uma função — que você pode conceder, alterar ou revogar de forma independente.

Sua própria identidade, sempre

Cada colaborador faz login com sua própria conta por meio do Keycloak, nossa camada de identidade. Ninguém digita sua senha, ninguém compartilha uma sessão de navegador, e remover alguém é uma única ação, em vez de uma rotação de senha e uma correria para descobrir quem mais a conhecia.

Organizações formam uma árvore

As contas são hierárquicas — uma organização de revendedores contém organizações de clientes, e as organizações de clientes contêm sites. Uma associação se aplica a uma organização e a tudo o que está abaixo dela, permitindo que você dê a um cliente de agência o controle da própria organização sem nunca expor seus outros clientes.

Isolamento aplicado no banco de dados

A separação de locatários não é um filtro no código da aplicação que um bug possa ignorar. O Row-Level Security do Postgres limita o escopo de cada consulta à subárvore da organização do chamador, portanto, uma solicitação fora do seu escopo não tem nada para retornar.

Ausência invisível

Se você solicitar uma organização ou site fora do seu escopo, a API responderá com um erro simples de não encontrado em vez de um erro de permissão. Um erro de permissão confirmaria que o registro existe; o não encontrado não revela absolutamente nada a um invasor.

Quatro papéis de cliente, trinta e cinco permissões

As permissões são chaves granulares — módulo mais ação, como sites.restart ou billing.refund — e as funções as agrupam. Quatro funções cobrem os formatos de que as equipes reais precisam, e cada uma delas é dado que preenchemos, não lógica enterrada no código.

Proprietário

Controle total: crie organizações filhas, convide e remova membros, altere funções, gerencie chaves de API, crie, reinicie, limpe, suspenda e exclua sites, gerencie faturamento e faturas, abra chamados e leia o log de auditoria. A função que você mantém para si mesmo.

Gerente de Faturamento

Visualiza a organização, seus membros e o catálogo de planos, e gerencia faturas, métodos de pagamento e cobranças. Sem acesso para criar, alterar ou excluir um único site — exatamente o perfil que um contador externo deve ter.

Desenvolvedor

Visualiza e cria sites, reinicia serviços, limpa o cache, gerencia chaves de API e atende chamados. Excluídos deliberadamente: faturamento, faturas, métodos de pagamento, gerenciamento de membros, suspensão de sites e exclusão de sites. Um prestador de serviços pode construir sem poder cobrar de você ou destruir nada.

Somente leitura

Vê a organização, seus membros, seus sites, sua cobrança, o catálogo de planos, os tickets, o status de tradução e o registro de auditoria — e não pode alterar nada disso. A permissão ideal para um cliente que deseja visibilidade, um auditor ou uma parte interessada que só precisa consultar.

Faça login para que sua equipe não possa enfraquecer silenciosamente

Delegar acesso só é seguro se as contas para as quais você delega forem difíceis de invadir. A autenticação passa pelo Keycloak para cada pessoa na conta, em todas as superfícies.

  • Chaves de acesso e WebAuthn para login resistente a phishing, além de autenticação de dois fatores TOTP imposta para todos por política — não uma configuração opcional que um membro da equipe pode ignorar.
  • Login por e-mail com link mágico como padrão, com e-mail e senha como alternativa, e login social pelo Google, Microsoft, GitHub e outros.
  • Logon único (SSO) SAML para clientes corporativos e de agências, para que novos funcionários e desligamentos sejam gerenciados pelo seu provedor de identidade, e não manualmente.
  • Uma sessão unificada no painel do cliente, no site público, na base de conhecimento e nos tickets de suporte: faça login uma vez e revogue uma vez.
  • Políticas de sessão, autenticação em duas etapas para ações confidenciais e listas de permissão de IP opcionais por organização para contas que desejam acesso vinculado a redes conhecidas.
  • Todo e-mail de cadastro é validado antes que uma conta seja criada, portanto, endereços inválidos, descartáveis e de funções são bloqueados logo na entrada, em vez de se tornarem membros órfãos mais tarde.

Quando nossa equipe precisa de acesso, ele é delimitado e registrado

O trabalho de suporte às vezes significa olhar dentro da sua conta. Esse acesso é regido pelo mesmo modelo de permissão de todo o resto — a equipe simplesmente fica em uma organização de funcionários, organizada em departamentos com concessões restritas.

Departamentos, não admin geral

A equipe é dividida em Suporte, Cobrança e Finanças, Abuso e Confiança e Segurança, Vendas, Onboarding, Engenharia e Operações, Marketing e Gestão. Cada função concede módulos e ações específicos, para que um agente veja a parte do painel de administração exigida pelo seu trabalho e não o resto.

O limite real de um agente de suporte

A função de Agente de Suporte concede exatamente isto: visualizar clientes, visualizar e responder a tickets, visualizar sites, reiniciar um site e purgar o seu cache. Ela não inclui nenhuma configuração de faturamento, reembolsos, edição de planos e nem gerenciamento de frota. A remediação que um agente pode executar é limitada pela função, e não por boas intenções.

O acesso como cliente é rigidamente controlado

A permissão customer.impersonate não faz parte da função de Gerente — ela pertence apenas ao Super Administrador. Quando uma sessão estiver sendo executada em seu nome, o painel exibirá um banner persistente de personificação para que nunca haja ambiguidade sobre quem está agindo.

Tudo o que tem privilégios é anotado

Todas as ações privilegiadas e administrativas são adicionadas a um log de auditoria somente de inclusão que registra o autor, a ação, o destino, os metadados de suporte, o endereço IP e o carimbo de data/hora — particionado por tempo em produção. Proprietários e membros com acesso somente leitura podem ler o log da própria organização por conta própria.

Portas de aprovação para trabalhos destrutivos

Ações sensíveis e destrutivas da equipe podem exigir autenticação reforçada ou aprovação de duas pessoas antes de serem executadas, e novos departamentos e funções são configurados em vez de exigirem uma alteração de código.

As máquinas também recebem acesso delegado

Scripts, pipelines de CI, a CLI, o provedor Terraform e agentes de IA se autenticam usando o mesmo modelo de permissão de pessoas — sem credenciais humanas compartilhadas, sem segredos de longa duração colados em um build.

As chaves de API são por organização e possuem escopo definido

As chaves pertencem a uma organização e possuem escopos granulares vinculados às mesmas permissões de RBAC: somente leitura, cobrança e provisionamento. Conceda a um pipeline o escopo restrito de que ele precisa, em vez de toda a conta de um membro.

As chaves de sandbox são separadas das de produção

As chaves de modo de teste e de modo de produção são distintas, portanto, uma integração em desenvolvimento não pode acessar dados de produção por acidente ou devido a uma variável de ambiente copiada.

Apenas o hash é armazenado

Armazenamos um hash SHA-256 do segredo e um prefixo de busca — nunca a chave pura. Você vê uma chave apenas uma vez, na criação. Cada chave rastreia quando foi usada pela última vez e pode ser revogada individualmente, sem afetar nenhuma outra.

Ferramentas de IA se conectam sob suas permissões

Nosso servidor MCP permite que qualquer agente compatível com MCP gerencie sua hospedagem em linguagem natural, autenticado com OAuth 2.1 e com escopo limitado à sua organização e função RBAC, com tokens revogáveis por ferramenta, confirmação em ações destrutivas, limites de gastos e registro completo de auditoria.

Acesso aos próprios sites

O acesso à conta e o acesso ao servidor são problemas diferentes. As credenciais em nível de site são gerenciadas no painel, emitidas com privilégio mínimo e isoladas para que o shell de um colaborador seja o shell de um único site.

  • SSH com shell restrito, além de SFTP e FTP — o isolamento do CageFS significa que cada cliente vê apenas seus próprios arquivos.
  • wp-cli pelo terminal do painel e via SSH, para as operações que os desenvolvedores realmente querem automatizar com scripts.
  • Um editor VS Code completo no navegador via code-server — extensões, terminal integrado e git, editando os arquivos do site diretamente no painel.
  • phpMyAdmin e Adminer integrados para bancos de dados, além de um gerenciador de arquivos integrado, ambos com acesso único (single-sign-on) a partir do painel, em vez de exigirem um segundo conjunto de credenciais.
  • As chaves de acesso e as credenciais são criadas, listadas, rotacionadas e revogadas no painel, emitidas com privilégio mínimo, e o uso delas é registrado em logs de auditoria.
  • O ambiente de staging com clone e push-to-live mantém trabalhos arriscados fora da produção, garantindo que a primeira alteração de um novo colaborador nunca vá direto para um site ativo.

Como estruturar o acesso para a maneira como você realmente trabalha

Um operador solo mantém uma única organização e uma assinatura de proprietário, e adiciona uma função de Desenvolvedor quando um prestador de serviços entra para um projeto. Quando o projeto termina, a assinatura é removida e o acesso dele para de funcionar imediatamente — nenhuma credencial compartilhada é deixada para trás para ser rotacionada.

Uma agência usa a árvore de organizações. Cada cliente recebe sua própria organização filha, que abriga os sites desse cliente, e as pessoas do próprio cliente recebem associações lá — somente leitura para um stakeholder que deseja visibilidade, proprietário para um cliente que deseja autonomia. Sua equipe possui associações mais acima na árvore e vê o portfólio; um cliente vê apenas o seu próprio ramo, e a Segurança a Nível de Linha é o que torna isso uma realidade, e não apenas uma promessa.

Um revendedor funciona da mesma maneira, um nível acima: uma organização de revenda abriga organizações de clientes, cada uma com seus próprios membros, visão de faturamento e sites. O mesmo princípio alimenta subcontas, equipes de agências e hierarquias de revendedores — não há um mecanismo separado e inferior para nenhum deles.

Tudo está disponível no teste de 14 dias sem necessidade de cartão. Cadastre-se sem dados de pagamento, convide um colega, veja o que cada função pode e não pode acessar e leia seu próprio log de auditoria.

Perguntas frequentes

Posso dar a alguém acesso a apenas um site?

Hoje, uma associação concede sua função em toda a organização e em tudo o que está abaixo dela na árvore, portanto, a maneira de separar conjuntos de sites é separar as organizações — coloque esses sites em sua própria organização filha e conceda a associação lá. É um modelo limpo para agências e revendedores, onde cada cliente já deseja seu próprio limite. A delimitação de recursos por associação, fixando uma única associação a sites nomeados dentro de uma organização, é um refinamento planejado, e não algo disponível no momento.

Um desenvolvedor que eu convidar pode excluir um site ou publicar em produção?

A função de Desenvolvedor não inclui a exclusão ou suspensão de sites — essas chaves pertencem à função de Proprietário. Ela concede permissão para visualizar e criar sites, reiniciar serviços, limpar o cache, gerenciar chaves de API e trabalhar em tickets. As permissões de implantação e envio para produção (push-to-live) também não fazem parte da concessão de Desenvolvedor, portanto, a promoção para produção permanece com o proprietário da conta. Combine isso com o ambiente de homologação (staging) para que o trabalho de desenvolvimento aconteça fora do site ativo desde o início.

O que a equipe da Zinn Digital® pode ver na minha conta?

Isso depende inteiramente da função da equipe, e cada função possui um conjunto restrito de chaves de permissão. Um Agente de Suporte, por exemplo, pode visualizar sua conta e seus sites, visualizar e responder aos seus chamados, reiniciar um site e limpar o cache dele — mas não pode mexer na configuração de faturamento, reembolsos, planos ou na frota. Entrar como cliente é uma permissão separada concedida apenas ao Super Administrador, e quando isso acontece, o painel exibe um banner persistente de personificação. Cada ação privilegiada é registrada no log de auditoria com o ator, a ação, o alvo, o IP e o registro de data e hora, e você mesmo pode ler o log da sua organização.

Como faço para revogar o acesso rapidamente se alguém sair da empresa?

Remova a associação e o acesso deles a essa organização será encerrado — eles ainda terão a própria identidade, mas sem nenhuma função e, portanto, sem permissões na sua conta. As chaves de API são revogadas individualmente, portanto, uma chave de pipeline pode ser cortada sem perturbar mais nada. Se você usa o logon único (SSO) SAML, o desprovisionamento no seu provedor de identidade gerencia o acesso de forma centralizada. As credenciais em nível de site, como chaves SSH, são revogadas no painel, e a própria remoção é registrada no log de auditoria.

Os membros da equipe compartilham minhas chaves de API?

Não — mas vale a pena ser preciso sobre o motivo. As chaves de API pertencem à organização, não a um membro individual, e possuem seus próprios escopos granulares vinculados ao mesmo catálogo de permissões. Portanto, em vez de entregar uma chave a uma pessoa, você cria uma chave para a função que ela desempenha com o escopo mais restrito que essa função precisa, e revoga essa chave quando a função termina. Apenas um hash do segredo é armazenado, e cada chave registra quando foi usada pela última vez, facilitando a localização e a desativação de chaves não utilizadas.

Posso conectar um agente de IA sem dar a ele acesso total a tudo?

Sim. Nosso servidor MCP autentica agentes com OAuth 2.1 e os restringe à sua organização e à sua função de RBAC, com tokens revogáveis por ferramenta, para que você conceda uma capacidade específica em vez de acesso total. Ações destrutivas exigem confirmação, limites de gastos se aplicam e cada ação é registrada no mesmo log de auditoria da atividade humana.

O que impede que um inquilino acesse os dados de outro inquilino?

A Segurança a Nível de Linha do Postgres restringe as consultas à subárvore da organização do chamador no próprio banco de dados, com o filtro em nível de aplicação atuando como defesa em profundidade em vez de ser a única linha de defesa. Solicitações de registros fora do escopo retornam "não encontrado" em vez de um erro de permissão, de modo que nada seja revelado sobre o que existe. No lado do servidor, o isolamento por site através do CageFS mantém o shell e os arquivos de cada locatário restritos ao seu próprio site.

Posso testar isto antes de pagar?

Sim. O teste gratuito de 14 dias não exige cartão — sem dados de pagamento, sem compromisso — e inclui o Footprint-Free Hosting com até cinco sites. É o suficiente para convidar um colega, atribuir uma função e confirmar se os limites se comportam da maneira que você precisa antes de se comprometer.

Delegue com um limite que você pode apontar

Inicie o teste de 14 dias sem cartão de crédito, convide alguém e veja o modelo de permissão fazer o trabalho dele — funções que você pode nomear, escopos que você pode revogar e um registro de auditoria que diz exatamente quem fez o quê.

Comece grátis