Este manual de arquitetura descreve os mecanismos de segurança aplicados no código-fonte do **EZYX Logistics** para garantir o isolamento estrito de dados multi-tenant, a conformidade de acesso baseada em perfis e a integridade de APIs.

1. Modelo de Isolamento Lógico (Multi-Tenancy)

O EZYX opera em um modelo de **banco de dados compartilhado com isolamento lógico estrito** (Shared Database, Logical Tenant Isolation). Isso significa que, embora múltiplos clientes compartilhem a mesma infraestrutura física do Firebase Firestore, barreiras de segurança impedem completamente o vazamento de dados inter-empresas.

2. Regras de Acesso no Banco de Dados (Firestore Security Rules)

As regras de segurança declaradas no arquivo `firestore.rules` são avaliadas de forma nativa e automática nos servidores do Firebase a cada requisição direta feita pelo cliente web ou móvel.

• Filtro Nativo de Claims: A validação compara o `companyId` do documento consultado com o contido no token JWT criptograficamente assinado do usuário autenticado (`request.auth.token.companyId`).
• Regras Restritas: Não existem regras genéricas ou curingas (match /{collection}/{docId}). Cada coleção possui suas regras restritas de leitura e escrita detalhadas.
• Isolamento de Contas: Usuários sem o papel de administrador ou operador do tenant não possuem permissão de leitura sobre a coleção geral de `/orders`, `/drivers` ou `/users`.

3. Isolamento de Arquivos e Anexos (Firebase Storage Rules)

Para garantir a total conformidade no tratamento de assinaturas digitais, canhotos fiscais e imagens de comprovação de entrega:

• Estruturação Física por Tenant: Os arquivos são gravados fisicamente em caminhos estruturados contendo o ID da empresa: /tenants/{companyId}/orders/{orderId}/signatures/proof.jpg
• Validação Estrita: As políticas em `storage.rules` rejeitam qualquer tentativa de upload ou download de arquivos cujos caminhos na URL de armazenamento não correspondam ao `companyId` contido no token JWT do usuário autenticado.
• Arquivos Privados: Por padrão, todos os canhotos e anexos operacionais são configurados como privados, sem URLs públicas de livre acesso na internet.

4. Proteção contra Vazamento de Dados em Links de Rastreamento (OWASP A3 & A5)

Para permitir que terceiros (como destinatários de encomendas que não possuem conta no sistema EZYX) acompanhem a localização em tempo real de uma entrega, o EZYX utiliza uma **arquitetura de barreira via Server Actions**:

1. O destinatário abre a URL pública de rastreamento `/track/orderId`.
2. A aplicação desativa listeners diretos do Firestore do lado do cliente (bloqueando consultas indevidas).
3. A requisição invoca a Server Action `getPublicOrderTimeline`, que roda em ambiente seguro no servidor utilizando o Firebase Admin SDK.
4. Sanitização Cirúrgica de Payload: O servidor remove do objeto final todas as informações sensíveis de negócios, como custos operacionais, salários de motoristas, margens de lucro e notas fiscais internas.
5. Apenas o status da linha do tempo e a localização do veículo são retornados de forma sanitizada para o navegador.

5. Segurança Física e Resiliência da Nuvem

Toda a plataforma usufrui das defesas globais dos datacenters do Google Cloud Platform (GCP), que incluem firewalls lógicos integrados, mitigação de ataques de negação de serviço (DDoS), segurança de perímetro em múltiplas camadas e controle físico estrito.