O passaporte é uma promessa.
É assim que a cumprimos.

As funções de servidor da aplicação são executadas em Frankfurt (fra1), junto ao armazenamento de dados principal, um cluster Postgres gerido na AWS eu-central-1 (Frankfurt). O conteúdo dos clientes, os registos dos tenants e os registos de auditoria são armazenados aí. As funcionalidades de IA enviam o texto sobre o qual trabalham para a API Gemini da Google, que o trata nos EUA.

Os recursos estáticos e as páginas públicas dos passaportes são servidos a partir de uma rede edge global, a partir do ponto mais próximo do leitor; apenas recursos públicos e não sensíveis (logótipos, textos de marketing, HTML das páginas do resolver) ficam em cache aí. Por política, as respostas autenticadas da API não passam pela cache.

Os domínios personalizados dos tenants (por exemplo dpp.brand.com) são servidos pela mesma plataforma. Não mantemos nenhuma infraestrutura de reserva que desloque dados armazenados para fora da UE.

Todas as ligações ao resolver, à administração do tenant e à API terminam em TLS 1.2 ou superior. O HSTS é imposto com max-age de dois anos e preload ativado. As páginas são servidas com X-Frame-Options SAMEORIGIN e Referrer-Policy strict-origin-when-cross-origin; uma Content-Security-Policy funciona em modo report-only.

Em repouso, os volumes de armazenamento Postgres são cifrados com AES-256 pelo fornecedor. As credenciais de integração (Akeneo, Centra, Shopify, inriver, Delogue, tokens REST personalizados) ficam num cofre cifrado por tenant; a chave de cifragem é guardada fora da base de dados. As chaves de API de LLM fornecidas pelos tenants (BYOK) são cifradas da mesma forma.

O início de sessão suporta magic link por e-mail e Google. As sessões são mantidas em cookies Secure, SameSite=Lax, limitados ao nosso domínio.

Todas as tabelas com conteúdo de clientes estão protegidas por Row-Level Security na base de dados. Um utilizador de um tenant nunca pode ler dados pertencentes a outro tenant — a restrição é imposta na camada da base de dados, não apenas no código da aplicação. O acesso da equipa é delimitado separadamente através de uma tabela staff_users e exige um motivo operacional registado no registo de auditoria.

As funções dentro de um tenant são admin, editor e viewer — um admin gere os membros e tudo o que está abaixo, um editor trabalha em passaportes e dados mas não pode alterar quem tem acesso, um viewer lê. A par destas existem funções orientadas para os reguladores no passaporte público (economic-operator, distributor, refurbisher, recycler, market-surveillance, competent-authority). A personificação por parte da equipa só é possível através de um fluxo assinado e auditado.

Os segredos da aplicação ficam exclusivamente em variáveis de ambiente cifradas da plataforma. Nenhum segredo é incluído no controlo de código-fonte, nenhum segredo é registado em logs, e as chaves de API coladas num chat são tratadas como comprometidas e substituídas de imediato.

Quando um tenant se integra com um sistema externo, a credencial é guardada por tenant no cofre cifrado descrito acima. As rotações, expirações e alterações de âmbito são mostradas no painel Integrações; as falhas de acesso ficam registadas no registo de auditoria do tenant.

A base de dados principal tem cópia de segurança contínua com recuperação para um ponto no tempo dentro de uma janela móvel. São conservados instantâneos diários cifrados segundo um calendário adequado ao plano do tenant; a conservação de longo prazo está disponível a pedido para as categorias regulamentadas.

Para os clientes que precisam de um anfitrião de cópia de segurança independente (segundo a EN 18221 §4.5), mantemos uma escrita paralela para um nível de armazenamento separado, para que o passaporte continue resolúvel mesmo que a aplicação principal esteja indisponível. A especificação do fornecedor do anfitrião de cópia de segurança está disponível para potenciais clientes mediante NDA.

O estado da infraestrutura em tempo real — disponibilidade, incidentes e manutenção programada — é publicado em status.dppagent.com. Os incidentes anteriores incluem o que aconteceu, o que mudámos e o que detetámos da vez seguinte.

Aceitamos comunicações de divulgação responsável em security@dppagent.com. As comunicações são triadas no prazo de um dia útil e corrigidas segundo um calendário por gravidade. Os investigadores de boa-fé estão protegidos contra ações judiciais, são creditados a pedido e não precisam de assinar um NDA para comunicar.

Para incidentes confirmados com impacto nos clientes, seguimos um procedimento documentado de resposta a incidentes: primeiro a contenção, notificação do proprietário do tenant dentro do prazo definido no contrato, relatório pós-incidente publicado na página de estado e correção da causa principal acompanhada até ao encerramento.

O runtime do DPP Agent e o que produz são construídos segundo o conjunto de normas CEN/CENELEC JTC 24 (EN 18216 acesso, EN 18219 identificadores, EN 18221 ciclo de vida e continuidade, EN 18223 estrutura e interoperabilidade), o perfil de referência CIRPASS-2 e os requisitos ao nível dos campos do ESPR (Regulamento 2024/1781) e do Regulamento Baterias da UE (2023/1542). Os dados dos passaportes estão em conformidade com o GS1 Digital Link, com os identificadores de aplicação GTIN, lote, CPV e número de série.

Enquanto responsável pelo tratamento / subcontratante a operar a partir da UE, estamos sujeitos ao RGPD e disponibilizamos um Acordo de Tratamento de Dados normalizado a pedido. Os fluxos de dados dos clientes estão documentados na nossa lista de Subcontratantes, que é alterada com 30 dias de pré-aviso no caso de alterações relevantes.

Atualmente não temos certificação SOC 2 nem ISO 27001. Quando obtivermos uma certificação, publicaremos aqui o relatório e o âmbito da auditoria. Os clientes Enterprise podem pedir, mediante NDA, o pacote atual de análise de segurança, o resumo do teste de intrusão e a lista de controlos internos.