Política GDPR

Todos os dados encriptados em trânsito (TLS 1.2+). Palavras-passe cifradas com bcrypt (12 rondas). O PostgreSQL Flexible Server utiliza encriptação de dados transparente em repouso. Azure Blob Storage encriptado em repouso. As imagens de cartas de condução e as assinaturas são encriptadas em repouso com AES-256 pelo Azure Storage e pelo Azure Database for PostgreSQL (chaves geridas pela Microsoft), e o acesso às mesmas é limitado por função e organização. Tokens JWT assinados criptograficamente (HS256). Segredos geridos via Azure Key Vault acedido pela identidade gerida do App Service — sem segredos em código, ficheiros de ambiente ou imagens de contentor.

Controlo de acesso baseado em funções (RBAC) em rotas autenticadas, com âmbito de tenant aplicado do lado do servidor. O isolamento de tenant é testado automaticamente antes de cada release: a varredura entre tenants da release gate chama a API como uma organização com os IDs de registo de outra organização, e a release é bloqueada se for possível ler ou alterar quaisquer dados dessa organização. Início de sessão único (SAML 2.0, Google, Microsoft); MFA com palavra-passe de utilização única baseada em tempo, obrigatório para administradores da plataforma e disponível para todos os utilizadores.

Registo de auditoria completo das ações dos utilizadores: identidade do utilizador, timestamp, endereço IP, verbo de ação, entidade afetada, valores antigos e novos. As ações relevantes para GMP são sinalizadas separadamente (is_gmp_relevant=1). Com deteção de adulteração e somente de acréscimo, aplicado na base de dados através de uma cadeia de hashes; as entradas relevantes para GMP são conservadas durante pelo menos 7 anos enquanto o contrato de serviço estiver em vigor, e as restantes entradas de auditoria durante 365 dias. Pseudonimizadas, mas não eliminadas, em caso de pedido de apagamento ao abrigo do Art. 17 (exceção por obrigação legal ao abrigo do Art. 17(3)(b)). No final do contrato, o cliente recebe uma exportação completa do seu registo de auditoria antes de este ser eliminado, salvo se a recusar por escrito ou não puder ser contactado após tentativas razoáveis; o YARDtwin só o conserva por mais tempo mediante instrução escrita do cliente, com exceção das cópias de segurança até estas expirarem e do seu próprio registo da entrega.

Alojado no Microsoft Azure (Sweden Central + Norway East, EEE). App Service em contentores implementado via Azure Container Registry com slot de staging e troca. O tráfego chega à aplicação através do Azure Front Door com uma Web Application Firewall em modo de Prevenção; a base de dados aceita ligações apenas de serviços Azure e de uma lista de permissões de IP de administrador. Application Insights com alerta de desvio de esquema para erros do Postgres "column / relation does not exist" (janela de 15 minutos). A sonda de ponta a ponta /health/db-write verifica que a aplicação consegue escrever e ler na base de dados a cada implementação.

Recolhemos apenas os dados necessários para a prestação do serviço. Os campos opcionais do condutor (telefone, e-mail) podem ser deixados em branco quando o processo do cliente o permite. O pessoal de portaria pode tirar uma fotografia do rosto do condutor como evidência de portaria. Quando um site ativa a comparação facial por IA, o nosso fornecedor de IA (Anthropic) compara essa fotografia individualmente com a fotografia da carta de condução ou com a fotografia armazenada do condutor, para ajudar o pessoal a confirmar a identidade do condutor. O resultado é uma recomendação: o pessoal de portaria decide e pode admitir um condutor que a comparação não confirmou, indicando um motivo. Cada comparação é registada nos nossos servidores com o respetivo resultado. Quando a comparação facial está desativada (predefinição), nenhuma fotografia do rosto é enviada ao fornecedor de IA e o pessoal compara o condutor com a fotografia da carta de condução; as imagens da carta de condução continuam a ser lidas por IA quando a leitura por IA está ativa. O YARDtwin não armazena modelos faciais e não realiza identificação de um-para-muitos. A newsletter recolhe apenas o e-mail e, opcionalmente, o nome da empresa.

Cada pull request deve passar por npm audit (vulnerabilidades de dependências), Semgrep (análise estática) e gitleaks (análise de segredos) antes de poder ser integrado, com uma análise de imagem de contentor Trivy como verificação consultiva; estas verificações também são executadas a cada push para master e diariamente, juntamente com uma análise de base OWASP ZAP consultiva (testes dinâmicos) do site de produção. Os alertas do Dependabot reportam vulnerabilidades recém-divulgadas nas nossas dependências.