Segurança da conta
A segurança do servidor protege os sites. A segurança da conta protege as chaves de acesso a eles. Cada login do Zinn Digital® funciona em um sistema de identidade baseado em padrões — passkeys e WebAuthn, autenticação de dois fatores por TOTP, login por link mágico, SAML SSO para equipes corporativas e de agências — com funções granulares, chaves de API por organização e um registro de auditoria apenas para anexação nos bastidores.
A maioria das contas de hospedagem é apenas uma senha em um banco de dados vinculada a um painel de controle. A nossa é um sistema de identidade dedicado — o Keycloak, compatível com OIDC e SAML — que fica à frente de tudo: o painel do cliente, o console de administração da equipe, este site público e base de conhecimento, e seus chamados de suporte. Faça login uma única vez e você estará conectado em todos eles.
Por ser construída com base em padrões abertos em vez de um login proprietário, a camada de identidade pode ser substituída da mesma forma que qualquer outro componente da plataforma. Nenhuma parte do seu modelo de acesso fica presa ao produto de um fornecedor, e nenhuma autenticação da sua equipe depende de mantermos um único fornecedor. Esse é o mesmo princípio de ausência de dependência (no-lock-in) que aplicamos a contas de CDN, DNS e provedores de pagamento.
O login é localizado e a transição do site para a tela de acesso mantém o seu idioma — para que uma equipe distribuída por vários países não seja forçada a usar um login somente em inglês.
Quatro métodos, todos de primeira linha, todos configuráveis por pessoa. Ninguém é forçado a usar a opção mais fraca apenas por ser a única disponível.
Digite seu e-mail, clique no link e você está dentro. Nenhuma senha para sofrer phishing, ser reutilizada ou vazar em uma violação de dados. Esse é o caminho padrão para novas contas e, para a maioria das pessoas, é o único de que precisarão.
Registre uma chave de acesso — Touch ID, Face ID, Windows Hello ou uma chave de hardware como uma YubiKey — e faça login sem precisar de senha alguma. As chaves de acesso são vinculadas à origem, de modo que uma página de login clonada não pode capturá-las. A plataforma aceita autenticadores ES256 e RS256 e prioriza a verificação do usuário.
Faça login com o Google por meio de uma conexão padrão de provedor de identidade, para que uma conta herde os controles que seu Google Workspace já impõe. Outros provedores se conectam da mesma maneira — nada disso é uma integração sob medida.
Mantido para as pessoas e scripts que precisam dele e sujeito a uma política real: mínimo de doze caracteres, nunca seu nome de usuário ou endereço de e-mail, sem reutilização dos seus últimos três e com hash Argon2. Os endereços de e-mail são verificados antes que uma conta possa ser usada.
Os segundos fatores fazem parte do sistema de identidade, não são um complemento que você compra nem um plugin que você instala em seu próprio site.
Se a sua organização já utiliza um provedor de identidade — Okta, Entra ID, Google Workspace ou qualquer outro compatível com SAML —, basta conectá-lo e seus colaboradores poderão fazer login no Zinn Digital® com suas credenciais corporativas existentes. Não há uma segunda senha para a sua equipe gerenciar, nem um segundo checklist de desligamento para esquecer.
Isso é ainda mais importante na escala de agências e revendedores, onde a rotatividade de funcionários é um verdadeiro evento de segurança. Quando alguém sai e você desativa essa pessoa em seu diretório, você também desativa a rota de acesso dela à sua hospedagem. O acesso acompanha o vínculo empregatício de forma centralizada, em vez de precisar ser rastreado em uma dúzia de ferramentas SaaS.
O SAML funciona em paralelo com tudo o mais, em vez de substituir: prestadores de serviços ainda podem receber uma conta com link mágico dentro de uma função delimitada, enquanto funcionários permanentes acessam via SSO. Uma organização, um modelo de permissão, duas portas de entrada.
O acesso é delimitado à árvore da organização — da revenda ao cliente e ao site — e aplicado no próprio banco de dados por meio de segurança em nível de linha, não apenas no aplicativo. O acesso multilocatário não é uma política que pedimos para as pessoas respeitarem; é uma consulta que simplesmente não pode retornar linhas. Quatro funções de cliente abrangem a divisão realista de tarefas.
Controle total da organização e de suas subcontas: crie organizações secundárias, convide e remova membros, atribua funções, gerencie todos os sites, administre o faturamento e o envio de faturas, gerencie chaves de API e leia o registro de auditoria.
Faturas, assinaturas, formas de pagamento e o catálogo de planos — e nada mais. O responsável financeiro ou contador de sua empresa pode liquidar uma fatura sem jamais ter a capacidade de alterar, suspender ou excluir um site ativo.
Acesso a sites e API sem controle de faturamento: visualize e provisione sites, reinicie serviços, limpe caches, gerencie chaves de API e tíquetes de suporte. Deliberadamente sem acesso a métodos de pagamento, faturamento ou alterações de plano.
Somente visualização em toda a organização — sites, faturamento, planos, chamados, status da tradução e log de auditoria. A função ideal para um auditor, um cliente que deseja visibilidade ou um novo colaborador em sua primeira semana.
O painel é uma forma de acesso. A API, a CLI, o provedor Terraform e o servidor MCP são outras — e todos seguem o mesmo modelo de acesso, pois uma chave sem escopo definido ignora todas as funções que você acabou de configurar.
Uma chave de API é emitida para uma organização, não para uma pessoa individual, e possui seus próprios escopos. Trate-a como um material de credencial compartilhada: dê a ela um nome de acordo com sua finalidade, atribua os escopos mais restritos possíveis e alterne-a quando a pessoa que a criou se desligar.
A chave bruta é exibida para você apenas uma vez, no momento da criação. O que mantemos é um hash SHA-256 e um prefixo curto para pesquisa. Não podemos exibir uma chave novamente, e uma violação de banco de dados não entrega credenciais válidas a um invasor.
Cada chave possui escopos granulares vinculados ao mesmo catálogo de permissões usado pelas funções, registra quando foi usada pela última vez e pode ser revogada imediatamente no momento em que parecer inadequada. Chaves de sandbox separadas executam a API sem nenhum faturamento ou provisionamento real associado a elas.
O servidor MCP permite que qualquer agente compatível com MCP gerencie sua hospedagem — e ele se autentica por meio do OAuth 2.1, com escopo definido para sua organização e suas permissões de RBAC, com tokens revogáveis por ferramenta, confirmação em ações destrutivas, limites de gastos e registro completo de auditoria. Conectar um assistente de IA não significa entregar a ele as chaves de tudo.
Cada ação privilegiada grava um registro exclusivamente incremental — quem a realizou, o que realizou, em que a realizou, as evidências de suporte e o endereço IP de origem, com um registro de data e hora. Não se trata de uma conveniência para depuração; trata-se do rastro de evidências.
Não — e preferimos que você não faça isso. O login por link mágico por e-mail é o padrão, e você pode cadastrar uma chave de acesso (Touch ID, Face ID, Windows Hello ou uma chave de segurança física) e fazer login sem nunca ter definido uma senha. E-mail e senha continuam disponíveis como alternativa, com um mínimo de doze caracteres, proibição de reutilização das últimas três senhas e hash Argon2.
A autenticação de dois fatores por TOTP é integrada à camada de identidade e pode ser aplicada por política em toda a organização, em vez de ser deixada como opção individual para cada membro. As chaves de acesso (passkeys) são a opção mais segura onde os dispositivos da sua equipe forem compatíveis, pois eliminam a senha que um invasor tentaria obter por phishing.
Sim. A função de Gerente de Faturamento concede faturas, assinaturas, métodos de pagamento e o catálogo de planos, e nada mais — nenhuma capacidade de visualizar, provisionar, reiniciar, suspender ou excluir um site. O inverso também se aplica: a função de Desenvolvedor gerencia sites e acesso à API sem nenhum controle de faturamento. As funções são atribuídas por organização; portanto, uma função em uma organização não concede acesso a uma organização separada e não relacionada — embora uma função em uma organização mãe se aplique às organizações aninhadas sob ela.
Revogue-a no painel e ela deixará de funcionar imediatamente. A janela de danos é delimitada pelo que essa chave poderia fazer em primeiro lugar, e é por isso que as chaves possuem escopos granulares e registram um carimbo de data/hora do último uso — escopos restritos e um histórico de uso visível são o que transformam um vazamento em um incidente controlado, em vez de um comprometimento total da conta. Observe que as chaves são emitidas para a organização e não para um indivíduo, portanto, trate-as como credenciais compartilhadas e faça a rotação delas quando houver mudanças na equipe. Apenas um hash da chave é armazenado do nosso lado, portanto, um vazamento do nosso banco de dados não gera uma credencial funcional.
Sim. Cada ação privilegiada é gravada em um registro de auditoria somente de acréscimo com o agente, a ação, o destino, as evidências de suporte, o IP de origem e um carimbo de data/hora. As funções de proprietário e somente leitura podem lê-lo diretamente. As ações da equipe em sua conta são registradas na mesma trilha, e ações confidenciais ou destrutivas da equipe podem exigir autenticação adicional ou aprovação de duas pessoas primeiro.
Sim — O SAML SSO é compatível com contas corporativas e de agências, permitindo que seus colaboradores se autentiquem com as credenciais corporativas existentes e o desligamento em seu diretório também revogue o acesso deles aqui. Você pode combinar abordagens: SSO para funcionários permanentes, contas com magic link e escopo definido para prestadores de serviços, tudo dentro do mesmo modelo de permissões.
Não — as senhas deliberadamente não são migradas. Sua conta é importada sem senha e, no primeiro acesso, você pode usar um magic-link ou definir uma nova senha de acordo com a política atual. Portar hashes de senhas antigas traria antigas vulnerabilidades para um novo sistema, por isso não fazemos isso.
O período de avaliação Footprint-Free é de 14 dias, não exige cartão e cobre até cinco sites. Você tem acesso à camada completa de identidade durante a avaliação — chaves de acesso, autenticação de dois fatores, funções, chaves de API e o registro de auditoria não estão bloqueados em um plano pago.
Cadastre uma chave de acesso, convide sua equipe para as funções corretas e emita uma chave de API com escopo definido — tudo em um teste de 14 dias sem necessidade de cartão de crédito.
Comece grátis