Segurança

Isolamento e trabalho verificado, desde a concepção.

Esta página descreve como a plataforma da Hostingsurge é realmente construída: a fronteira do banco de dados, a fronteira das sessões, o sandbox de build e o caminho dos pagamentos. Ela não lista nenhuma certificação ou auditoria, porque não existe nenhuma.

Leia a documentação Status ao vivo

Isolamento de tenants no banco de dados

O isolamento é aplicado onde os dados ficam, não apenas no código da aplicação.

Toda tabela sensível a tenants tem uma organização proprietária (organization_id ou uma fronteira de tenancy equivalente) com propriedade composta até os projetos.
A segurança em nível de linha (row-level security) é forçada nas tabelas de tenants, e os papéis de runtime são restritos: o papel de identidade não consegue ler dados de projetos ou de carteiras, e a fronteira das requisições rejeita papéis administrativos do PostgreSQL, de superusuário e com permissões de arquivo ou de servidor.
O contexto do tenant é definido por transação. Um identificador que chega de um navegador é uma solicitação, nunca uma autorização.
Gravações protegidas passam por funções que verificam de forma independente a sessão e a autoridade atual, e as gravações diretas dos papéis da aplicação são revogadas nessas tabelas.

Sessões e autoridade atual

A autenticação é verificada na entrada, e a autoridade é verificada de novo no momento em que é usada.

Os cookies de sessão são HttpOnly e SameSite=Lax, com prefixo __Host- em produção, e cada requisição associa a sessão a um usuário e a um tenant antes de qualquer outra coisa.
Requisições do navegador que alteram dados precisam vir da origem configurada, e os corpos das requisições são limitados (application/json, 16 KiB, prazo de cinco segundos).
Alterações sensíveis — mudanças de MFA, emissão de credenciais, compras, trocas de plano — exigem autenticação recente em vez de uma sessão de longa duração.
A MFA é TOTP com códigos de recuperação de uso único. Tokens e códigos são consumidos de forma atômica, então dois usos simultâneos não podem ter sucesso ao mesmo tempo.

Credenciais e aprovações de operações

Uma credencial é uma permissão delimitada e revogável — não uma chave permanente para a plataforma.

As credenciais de API e MCP são armazenadas com hash, vinculadas a uma organização, uma marca e um projeto, têm escopos explícitos e validade limitada e são exibidas exatamente uma vez.
Remover alguém de uma equipe revoga permanentemente as credenciais dessa pessoa, e uma redefinição de senha invalida as credenciais emitidas anteriormente.
Ações sensíveis e cobráveis exigem uma aprovação de curta duração vinculada ao usuário, à organização, ao projeto, à ação exata, ao alvo e ao digest canônico da entrada.
O consumo da aprovação, a admissão do job, a reserva de créditos, a auditoria e o registro no outbox são confirmados em uma única transação; se o callback confiável falhar, toda a admissão é revertida. Mudanças de papel ou de associação revogam permanentemente as aprovações pendentes.

Builds rodam isolados

O código dos clientes e o gerado por IA são tratados como não confiáveis, porque não são confiáveis.

Os builds rodam em um contêiner temporário sobre uma imagem base mínima, com a rede desativada, memória e CPU limitadas, limite de processos, sistema de arquivos raiz somente leitura, uma montagem temporária noexec limitada, sem socket do Docker e sem credenciais de produção, sob um tempo limite de execução.
Um artefato precisa passar pela verificação de digest e de tamanho e ser gravado por meio de um armazenamento atômico — gravar, fazer flush, reler, renomear de forma atômica, reler de novo — antes de um recibo de build ser registrado. Por isso, uma falha nunca pode deixar um estado pronto sem bytes persistidos.
Os recibos de build e de artefato são somente de acréscimo (append-only); uma atualização ou exclusão gera um erro de imutabilidade.
Um worker mantém uma concessão (lease) com fencing, renova-a enquanto trabalha e para se perder a posse. Os limites de código-fonte e de arquivo (1000 entradas, 256 KB por arquivo, 16 MB no total) são aplicados na entrada e na saída.
O conteúdo dos arquivos é entregue ao navegador como texto escapado: a marcação dentro de um arquivo salvo permanece inerte e nunca é executada.

Pagamentos verificados a partir de eventos assinados

O dinheiro só se move quando o provedor confirma — e a plataforma consegue provar isso.

Os webhooks de pagamento são verificados com checagem real de assinatura sobre o corpo bruto e limitado da requisição, com verificações de replay e de tempo e um escopo exato de conta e de modo test/live. O endpoint só confirma o recebimento depois que ele é persistido.
Os créditos só viram saldo depois que o pagamento é verificado junto ao provedor — fatura, payment intent e cobrança — e cada concessão é aplicada exatamente uma vez.
Os preços nunca são obtidos de um navegador: valores e unidades de crédito vêm de um catálogo no servidor, e um preço que não corresponda ao produto, valor, moeda e ciclo esperados é rejeitado.

Hospedagem na UE e reforço documentado

O que é verdade hoje, incluindo o que ainda não está pronto.

Os servidores ficam na UE e são gerenciados pela plataforma. Os clientes nunca recebem um painel de controle do provedor; tudo passa pela Hostingsurge.
No servidor de produção, as atualizações pendentes do sistema operacional foram instaladas (incluindo as de segurança), o firewall foi ativado preservando SSH, HTTP, HTTPS e HTTP/3, e a interface de administração do proxy reverso foi restrita ao localhost e verificada após a reinicialização.
O tráfego é terminado via TLS e um proxy reforçado; as interfaces administrativas não ficam expostas à internet.
O banco de dados de controle recebe backup a cada 24 horas em um armazenamento do próprio servidor, guardado por 14 dias. A cópia externa (off-site) criptografada já está pronta, mas o bucket de armazenamento dela ainda não foi conectado, então por enquanto os backups ficam no servidor — isso é dito aqui em vez de ficar subentendido.

O que esta página não afirma

Dito com clareza, porque uma página de segurança que exagera é pior do que nenhuma.

Não afirmado

Não há certificação SOC 2, ISO 27001 ou qualquer outra.

Não afirmado

Nenhuma auditoria de segurança independente foi realizada.

Não afirmado

Não existe relatório de teste de invasão feito por terceiros.

Não afirmado

Não é oferecido SLA de disponibilidade nem programa de bug bounty.

Não afirmado

Ainda não há um endereço publicado para relatar problemas de segurança. Até que haja, uma descoberta não tem um canal confirmado — e esta página vai informá-lo quando ele existir.

Leia os limites e depois decida.

A página para desenvolvedores documenta os endpoints reais e a autenticação deles. A documentação mostra, módulo por módulo, o que está implementado.

Desenvolvedores Leia a documentação

Tudo acima descreve a versão atual. Nenhuma certificação, auditoria ou SLA é afirmado em nenhum lugar deste site.