Saltar para o conteúdo
BeryX

Segurança e Confiança

O que garantimos, o que ainda não temos e quando

O BeryX lê os teus dados para medir a qualidade — nunca os altera. Esta página mostra os controlos que existem hoje, com evidência no código, e o estado real de cada certificação.

Ainda não temos certificação ISO 27001 nem relatório SOC 2. O estado e as datas de cada uma estão abaixo, e mudam aqui quando mudarem na realidade.

Última revisão: 7 de outubro de 2026

Só leitura, em três caixas

Os dados saem das tuas fontes apenas para leitura, são medidos na UE e só chegam a um modelo de IA se a IA estiver ligada.

  1. 01

    As tuas fontes

    Bases de dados, warehouses e ferramentas SaaS. O BeryX só lê: metadados, agregados e amostras limitadas, com um utilizador de serviço só de leitura.

    Leitura apenas: as escritas são recusadas no código antes de chegarem à rede.

  2. 02

    BeryX (GCP, UE)

    Mede a qualidade e propõe correções em Google Cloud europe-west1. Credenciais cifradas, isolamento por workspace, registo de auditoria.

    Só o necessário para a análise pedida; o conteúdo gerado é sempre rotulado como IA.

  3. 03

    IA (opcional)

    Por omissão, só a Anthropic recebe dados, em amostras limitadas e anonimizáveis. Pode ser desligada, ou correr no Bedrock/Vertex da tua conta cloud.

Controlos em vigor

Encriptação

Em vigor
  • Credenciais das fontes e tokens de integração cifrados com Fernet antes de gravados, com rotação de chaves (MultiFernet) e re-cifra idempotente. Nunca são devolvidos pela API nem escritos em logs.
  • Em trânsito: TLS na app, na API, na base de dados e na mensageria (amqps). Nas fontes, as APIs HTTP, o Fabric e o SQL Server com Entra ID verificam sempre o certificado. PostgreSQL e MySQL verificam-no por omissão nas conexões novas. As exceções aparecem assinaladas na app: conexões anteriores a esta regra e ligações sem verificação confirmadas por um admin, que ficam na auditoria. Com autenticação SQL, o SQL Server é cifrado sem validar o certificado.
  • Em repouso: base de dados, segredos e imagens cifrados pela Google Cloud com chaves geridas pela Google. Ainda não oferecemos chaves geridas pelo cliente (CMEK).

Residência dos dados na UE

Parcial
  • Aplicação e base de dados em Google Cloud europe-west1 (Bélgica), com os backups na multi-região UE da Google. Mensageria em AWS eu-west-1 (Irlanda), só com identificadores internos.
  • Os logs da plataforma, com o IP e o browser de quem faz os pedidos, ficam no Cloud Logging em localização global: a Google pode guardá-los fora da UE. A correção é um bucket de logs em europe-west1, ainda por fazer.
  • Fornecedores nos EUA, com o mecanismo de transferência de cada um na lista de subprocessadores: Anthropic (pedidos de IA), Resend (email transacional), Sentry (erros da aplicação, sem emails nem IPs) e Stripe (faturação, com processamento nos EUA). Se um admin a ligar, também a Voyage AI, com texto anonimizado para embeddings.
  • A partir de 2026-11-16, o CRM da BeryxTech, Twenty, guarda em Frankfurt os pedidos de contacto e a relação comercial, mas a empresa é dos EUA e pode aceder-lhes a partir de lá, com cláusulas contratuais-tipo.
  • Os pedidos de IA à Anthropic são processados nos EUA, com cláusulas contratuais-tipo (art. 46.º RGPD). Para ficar na UE, a IA pode ser desligada ou correr no Amazon Bedrock (regiões eu-*) ou no Vertex AI (regiões europe-*) da tua conta — plano Enterprise.

Controlo de acessos e MFA

Parcial
  • Papéis por workspace (RBAC), SSO por OIDC, passwords com scrypt, limite de tentativas de login e sessões terminadas quando a password muda.
  • O suporte da BeryxTech só entra no teu workspace com o teu consentimento, em modo de leitura e no máximo 72 horas, e fica registado.
  • MFA por TOTP (app autenticadora) com códigos de recuperação de uso único nas contas com password. É obrigatória para os administradores de organização e para o staff da BeryxTech, e cada workspace pode exigi-la a todos os membros; no registo self-serve é opcional por omissão. As contas SSO usam o MFA do teu fornecedor de identidade.
  • Ainda sem aprovisionamento SCIM: as contas entram por convite ou no primeiro login SSO.

Registo de auditoria

Em vigor
  • Ações de administração (papéis, planos, conexões, credenciais, tokens, política de IA, acessos de suporte) gravadas na mesma transação da mudança.
  • Consultável e exportável em CSV pelos administradores do workspace. Os logs técnicos não contêm credenciais nem dados de clientes.

Backups e recuperação

Parcial
  • Backups diários e recuperação para um ponto no tempo (PITR) com 7 dias de retenção, verificados automaticamente em cada deploy.
  • Se a IA falhar, o produto continua a funcionar em modo offline — provado todas as noites por testes de caos.
  • Uma só região (europe-west1), ainda sem plano de recuperação multirregião.

Objetivos de recuperação

RPO
Proposto: minutos (dentro da janela de PITR); até 24 h sem PITR · não medido
RTO
Por definir — ainda não houve ensaio de restauro que o meça · não medido

Desenvolvimento seguro e Factory

Parcial
  • Cada alteração passa por CI obrigatório: testes, lint, tipos, avaliações dos prompts de IA e migrações de base de dados versionadas. O deploy valida a produção de ponta a ponta.
  • Análise de dependências Python e npm e das imagens (Trivy) em cada PR; falha em crítico/alto sem exceção registada; SBOM CycloneDX por deploy; relatório mensal de vulnerabilidades. DAST semanal (OWASP ZAP baseline, só passivo) ao site, à app e à API, com relatório semanal.
  • Na Factory, o código escrito por agentes de IA só chega à main com revisão por um segundo agente (revisor ≠ executor), gate de segurança quando toca superfície sensível e aprovação do owner para abrir o trabalho.
  • Aprovação humana de cada deploy (ambiente GitHub production com o owner como revisor), proteção da main, CODEOWNERS e assinatura das imagens com cosign definidos como código; a proteção e o ambiente ainda não têm evidência de aplicação no GitHub. Ainda sem pen test externo.

IA e AI Act

Em vigor
  • Por omissão, só a Anthropic recebe dados de clientes. Outro fornecedor só recebe metadados ou amostras já anonimizadas (Presidio, com reconhecedores para NIF, NISS, IBAN e Cartão de Cidadão).
  • Política de IA por workspace: desligar a IA, restringir modelos por tarefa, usar a tua chave, ou correr o Claude na tua conta Bedrock/Vertex. Se essa rota falhar, degrada para offline — nunca para a conta da BeryxTech.
  • Art. 50.º do AI Act: todo o conteúdo gerado por IA diz que o é, que modelo e fornecedor responderam, e que está sujeito a revisão humana. Exportamos o dossiê do art. 10.º para clientes com sistemas de risco elevado.

Subprocessadores

A lista pública diz, para cada fornecedor, a finalidade, a região, a base legal, o mecanismo de transferência e o DPA. Um fornecedor novo ou uma mudança de região é anunciada com 30 dias de antecedência, e durante esse prazo um fornecedor de IA novo não recebe dados.

Ver lista de subprocessadores

Certificações: estado real

Planeada, em preparação, auditoria agendada ou obtida. Um relatório SOC 2 Type I nunca se apresenta como Type II.

  • SOC 2 Type I

    Planeada

    Primeiro marco do programa (ADR 0010, aceite pelo owner a 2026-09-28). Fase 0 em curso: ferramenta GRC (Probo, self-host na UE) a provisionar e políticas a assinar; auditor por escolher.

    desde 28 de setembro de 2026

  • ISO/IEC 27001:2022

    Planeada

    Fase 2 do programa, depois do SOC 2 Type I. Políticas do SGSI em rascunho, por aprovar.

    desde 25 de setembro de 2026

  • SOC 2 Type II

    Planeada

    Exige uma janela de observação de pelo menos 6 meses, a começar depois do Type I.

    desde 25 de setembro de 2026

  • ISO/IEC 27701

    Planeada

    Extensão de privacidade; só depois da ISO 27001 (fase 3).

    desde 25 de setembro de 2026

  • ISO/IEC 42001

    Planeada

    Sistema de gestão de IA; só depois da ISO 27001 (fase 3).

    desde 25 de setembro de 2026

Acordo de tratamento de dados (DPA)

O modelo de DPA (art. 28.º RGPD) está redigido, mas ainda não foi revisto por um jurista. Pede-o por email: enviamo-lo depois dessa revisão, com a lista de subprocessadores em anexo.

Pedir o DPA

Divulgação responsável

  • Reporta vulnerabilidades por email para o contacto de segurança. Confirmamos a receção em 3 dias úteis e enviamos um primeiro diagnóstico em 5; o prazo-alvo de correção é o da nossa política de vulnerabilidades (7, 30 e 90 dias para crítica, alta e média).
  • Testa só contra a tua própria conta e o teu workspace. Não acedas a dados de terceiros, não faças testes de carga ou negação de serviço e não uses engenharia social.
  • Não temos programa de bug bounty pago. Agradecemos publicamente a quem o pedir, depois da correção.

Contacto de segurança: seguranca@praxis.lbostuff.tech · security.txt

Política completa: âmbito, prazos e porto seguro

Pen test externo

Ainda não fizemos um pen test externo. O âmbito, as contas de teste e as regras estão preparados; falta contratar o fornecedor. Está planeado antes da auditoria SOC 2 Type I e depois anual; o sumário é publicado aqui.

Downloads

  • Resposta-padrão de segurança (BeryX)
  • Políticas de segurança (14)Pendente

    Em rascunho, a aguardar aprovação. Publicamos cada política quando for aprovada.

  • Sumário do pen testPendente

    Publicado depois do primeiro pen test externo.

Política de Privacidade