Todos os fornecedores de analytics dizem que os teus dados estão isolados. É a única afirmação que um cliente quase nunca consegue verificar, por isso é a que vale a pena provar em vez de afirmar.

O Event Horizon Data é multi-tenant: os dados de muitos clientes vivem em infraestrutura partilhada, e todo o valor do produto assenta em nenhum cliente ver as linhas de outro. Eis como isso se aguenta, em concreto, e mais importante, onde o podes verificar tu.

Duas camadas, não uma

O isolamento é imposto duas vezes, de propósito. As duas camadas não são iguais, e o que interessa dizer-te é qual delas aguenta o peso.

O choke-point aplicacional. Toda a leitura que põe dados à frente de alguém passa por uma função que recusa, fail-closed, qualquer query que não carregue o âmbito do próprio tenant autenticado. Uma leitura que não consegue nomear de quem são os dados não compila. Não há caminho de código que a contorne.
A row policy da base de dados. Por baixo disso, o próprio motor confina cada leitura às linhas do tenant através de uma row policy sob a qual a query corre. É uma segunda camada, e não é independente. A identidade de leitura tem de conseguir receber o contexto do seu tenant em cada pedido, e essa é a mesma porta que um override dentro da query usaria, que foi exatamente o que o nosso red-team encontrou e o que fechámos depois no choke-point acima. A row policy levanta a fasquia por baixo da camada aplicacional em vez de se aguentar sozinha, e o choke-point é o controlo pelo qual te pedimos que nos julgues.

A ligação de leitura é least-privilege por construção: não consegue ler as tabelas do próprio servidor, não alcança sistemas externos, e não escreve. Atravessar a fronteira de um tenant exigiria escrever um novo cliente de base de dados, não esquecer um argumento.

Fazemos red-team ao nosso próprio isolamento, e publicamo-lo

As afirmações envelhecem mal. Por isso corremos um teste adversarial à fronteira entre tenants contra o sistema em produção, tentamos derrotá-la pelas vias de um atacante, e escrevemos o que encontrámos, incluindo os limites honestos. E repetimo-lo sempre que há uma superfície nova: o editor de SQL e a API de notebooks foram atacados no dia seguinte ao que entraram, numa corrida só deles. Entre as duas corridas mais recentes, sete achados, todos fechados no dia em que foram encontrados, e nenhum deles uma forma de ler os dados de outro cliente. Esse relatório, as medições de escala e um questionário de segurança pré-preenchido vivem na nossa página de segurança pública. Lê-o antes de confiares em nós, não depois.

É essa a postura toda: verificar, não só acreditar.

As superfícies novas tiveram o mesmo tratamento

Lançámos há pouco duas formas de correr o teu próprio SQL sobre os teus dados: um editor SQL na app, e uma API HTTP para notebooks (Python/R/Jupyter). Ambas foram construídas para a mesma fronteira:

Escreves SQL contra as tuas tabelas lógicas, cego a como o warehouse guarda as coisas de facto. O teu texto nunca corre tal-e-qual: é parseado, validado e reconstruído no servidor, sempre trancado ao teu tenant.
Toda a query é verificada em custo antes de correr (como o dry-run do BigQuery): uma que leria demasiado é recusada à cabeça, com a estimativa à frente. Por cima disso, o tempo, a memória, o tamanho do join e o número de tabelas juntadas estão limitados, e o SQL ad-hoc cede a prioridade aos dashboards, para que uma query pesada se degrade a si própria em vez de degradar o warehouse.
A API de notebook autentica com um token revogável, ao qual se pode dar data de validade; o tenant vem do token, nunca do pedido. Um token de uma conta não consegue pedir dados de outra, e o teste que o prova faz falhar o build se isso alguma vez mudar.

O que não fingimos

Somos uma equipa pequena, não uma organização de cem pessoas com um muro SOC 2. Dizemo-lo. O que oferecemos em troca é um pacote de garantia interino que os clientes boutique aceitam de facto: o red-team publicado, um relatório de escala, um DPA, uma lista de subcontratantes, e um plano de continuidade de negócio (backups, restore automatizado, exportação de dados à saída), mais um fundador do outro lado da linha. O SOC 2 chega quando a procura o justificar.

Se avalias fornecedores pela verificabilidade das afirmações de segurança, começa na página de segurança. O argumento arquitetural mais longo está no whitepaper.