Feature 01 / 04
Alicerce
Multi-tenant por design, não por retrofit
O Helpdash foi construído tenant-first. Cada consulta carrega uma fronteira de workspace na camada de dados; cada workspace é dono das suas linhas, prefixo de armazenamento, funções e registo de auditoria. Não há caminho — autenticado ou não — em que o âmbito de tenant seja opcional. Para equipas de engenharia e segurança: esta é a arquitetura que pediria numa revisão de compras.
Resultados
As garantias de isolamento que sobrevivem a uma auditoria
Multi-tenant não é um feature flag que entregamos. É o modelo de dados: âmbito ao nível de linha em cada leitura e escrita, RBAC ciente de equipa, armazenamento delimitado, registo de auditoria assinado. Compras, SOC 2, ISO 27001 — as respostas são as mesmas em cada formulário.
Feature 02 / 04
RBAC delimitado ao workspace
as funções vivem dentro de um tenant, as permissões nunca atravessam a fronteira
Feature 03 / 04
Prefixo de armazenamento por workspace com URLs de download assinados e de curta duração — sem bucket partilhado, sem path traversal cross-tenant
Feature 04 / 04
Registo de auditoria à prova de adulteração mantido para além da eliminação do workspace para cumprir janelas de retenção regulatórias
Dentro do modelo
Como o Helpdash torna a multi-tenancy aborrecida
Feature 01 / 03
Âmbito global de consulta
Um âmbito global em cada modelo filtra automaticamente pela chave do tenant. Esquecer a fronteira nos pontos de chamada é estruturalmente impossível; o framework liga-a na camada de dados.
Feature 02 / 03
RBAC ao nível de equipa
Funções e permissões são tenant-aware — a função de um agente no workspace A é invisível no workspace B. Sem transferência acidental de privilégios entre mesas.
Feature 03 / 03
Armazenamento por tenant
Os prefixos de sistema de ficheiros (tenants/{id}/) ligam cada upload ao seu workspace. URLs de download são assinados, de curta duração e verificados por tenant no momento da emissão.
FAQ
Frequently asked questions
Qual é o modelo de dados?
Um esquema único partilhado com uma chave de tenant em cada registo de negócio. Os modelos usam um trait BelongsToTenant que instala um âmbito global de consulta; leituras e escritas herdam automaticamente a fronteira de workspace. O acesso cross-tenant requer uma sobreposição explícita e auditada na camada de aplicação.
Como é resolvido o tenant em cada pedido?
As rotas autenticadas ignoram os cabeçalhos X-Tenant-Slug e host — a claim de workspace dentro do JWT assinado é autoritativa, ponto final. As rotas não autenticadas (login, docs públicas) resolvem via cabeçalho → subdomínio → query string, nessa prioridade, com uma lista de nomes reservados (ex.: www, api, admin) que previne colisões.
O que vê realmente um auditor?
Um registo de auditoria assinado e append-only por workspace, mantido para além da eliminação do tenant, exportável para o seu SIEM. Mais o âmbito ORM: uma prova de uma linha de que cada consulta é tenant-bound, normalmente suficiente para SOC 2 CC6.1 e ISO 27001 A.9.4.1.
Veja o modelo de isolamento no seu próprio workspace
Lance dois workspaces sob um login e veja-os nunca se verem — na API, na UI ou na camada de armazenamento. Plano gratuito, sem cartão de crédito.