Pular para o conteúdo
Saiku Cloud

Postura de segurança e confiança

Times de procurement enterprise precisam saber onde um fornecedor está em segurança antes mesmo de olhar o produto. Esta página é a versão honesta — o que já está no lugar, o que está em andamento e o que deliberadamente ainda não fizemos. Mantida atual; revisada pela última vez em julho de 2026.

Atestações de terceiros

AtestaçãoStatusNotas
SOC 2 Type IAlvo Q4 2026Scoping completo; auditor selecionado. Remediação de gaps pré-auditoria em andamento.
SOC 2 Type IIAlvo Q3 2027Segue o Type I uma vez que a janela de observação esteja completa.
ISO 27001Não no roadmap atualRepriorizar sob solicitação para grandes contratos europeus.
HIPAA BAASob solicitaçãoAssinado numa base por-cliente para deployments de saúde.
DPA (GDPR)Sob solicitaçãoDPA padrão disponível; emendas de cliente consideradas.

Nós não publicamos atestações que não temos. Se você vê “SOC 2 compliant” na página de um fornecedor sem uma data de relatório, peça o relatório — vários concorrentes distribuem o rótulo sem a papelada.

Tratamento de dados

Onde seus dados vivem.

  • O Saiku Cloud roda em infraestrutura europeia (Scaleway, Holanda). Regiões dos EUA disponíveis sob solicitação para tenants com requisitos de residência de dados.
  • Os dados do warehouse em si nunca deixam seu warehouse. O Saiku é uma camada semântica — queries são compiladas para SQL e despachadas para seu banco; resultados transitam pela nossa plataforma para renderizar na UI mas não são persistidos server-side por default.
  • Metadados que SÃO armazenados: definições de cubo, workbooks salvos, histórico de query para auditoria, contas de usuário, info de assinatura. Todos escopados por tenant (veja Isolamento de tenant).

Criptografia.

  • Em trânsito: TLS 1.3 para todos os endpoints voltados ao cliente (cloud.saiku.bi, demo.saiku.bi, api.saiku.bi). HSTS imposto com um max-age de um ano.
  • Em repouso: volumes de banco criptografados no nível do provider de cloud (equivalente a LUKS / dm-crypt). Credenciais de warehouse criptografadas com chaves por-tenant.
  • Secrets: secrets de operador (API keys, senhas de DB) nunca escritos em logs. Veja o log de auditoria para o que É registrado.

Retenção e deleção.

  • Eventos de auditoria: 90 dias no plano default, até 7 anos no Enterprise.
  • Workbooks + queries salvas: retidos até você deletá-los; hard delete no fechamento de conta dentro de 30 dias.
  • Cache de resultado de query: default 30 minutos, configurável por tenant.
  • Backups: full noturno + incremental horário; retidos 30 dias; criptografados em repouso.

Controle de acesso

  • SSO — SAML 2.0 suportado no plano Team e acima. OIDC / OAuth 2.0 no plano Enterprise.
  • MFA — imposto para a conta do operador (root admin). Admins de tenant podem impor para seus próprios membros.
  • Acesso baseado em role — veja Membros e roles. Row-level security (RLS) no nível do cubo é distribuído no Saiku 4.6.
  • Gerenciamento de sessão — timeout configurável; re-auth forçado após 24 horas por default.
  • Service accounts / API keys — escopados, revogáveis e aparecem no log de auditoria.

Segurança de aplicação

  • Scanning de vulnerabilidades: todo push para development roda Snyk contra a árvore de dependências; todo release roda OWASP Dependency-Check via mvn -P security verify. Achados acima de CVSS 7.0 bloqueiam o release.
  • Scanning de secrets: GitHub secret scanning habilitado em cada branch; commit hooks rejeitam qualquer coisa que case padrões comuns de credencial.
  • Segurança de CI: builds rodam em runners efêmeros hospedados pelo GitHub; sem secrets persistentes fora dos GitHub Actions secrets. A chave de assinatura para publicação de artefatos vive em um ambiente endurecido separado.
  • Higiene de dependências: toda dependência adicionada a um POM passa pelo Sonatype OSS Index para vulnerabilidades conhecidas + detecção de pacotes maliciosos antes do merge.

Resposta a incidentes

  • On-call: horário comercial (UK) para o plano Team; 24/7 para Enterprise.
  • Alvo de notificação: clientes Enterprise notificados dentro de 24 horas de violação de dados confirmada; plano Team notificado dentro de 72 horas.
  • Status page: status.saiku.bi — assinável via email ou RSS.
  • Post-mortems: publicados para qualquer incidente durando

    30 minutos nos planos Enterprise. Post-mortems públicos redigidos para incidentes mais amplos no changelog.

A história do self-hosted

Para clientes que não podem enviar dados através de nenhuma plataforma hospedada, o Saiku distribui um build self-hosted sob a mesma licença Apache 2.0 da versão Cloud. A postura de segurança lá é responsabilidade do operador, mas o Saiku vem com:

  • Defaults fail-closed (veja o guard AiPolicy — produção default para schema-only nos endpoints de AI)
  • Recusa de credencial de admin não-default (o Saiku se recusa a servir em produção enquanto as credenciais admin/admin distribuídas não forem rotacionadas)
  • OpenTelemetry opt-in para que eventos de segurança fluam para seu SIEM existente
  • Sem phone-home; sem telemetria saindo da caixa a menos que você configure

Veja o guia de self-hosting para conselhos de hardening.

O que deliberadamente não fizemos

Transparência sobre as lacunas vale mais que uma check-list de marketing.

  • FedRAMP: Sem planos. Não é um mercado que servimos.
  • PCI-DSS: Não certificado. O Saiku é uma plataforma de camada semântica, não um processador de pagamentos — não armazenamos dados de portador de cartão. Se seu caso de uso de BI toca dados de portador de cartão, você precisa de um controle compensatório do lado do warehouse.
  • Localização de dados GDPR para regiões edge: Só-EU hoje. Ásia Pacífico + regiões dos EUA disponíveis sob solicitação mas não o default.
  • Bug bounty: Não rodando um atualmente. Divulgação responsável tratada diretamente via security@saiku.bi.

Contato