Segurança, audit trail e cumprimento RGPD

O FIRO opta deliberadamente por mecanismos de autenticação que não passam por passwords:

Magic link

• Utilizador insere o email; recebe link único.
• Token gerado, hash guardado em base, com expiração.
• Tentativas de uso registam IP e user agent.
• Após uso, token é invalidado.

Google OAuth

Alternativa para todos os fluxos (user, staff, customer, admin). Reaproveita a segurança da conta Google do utilizador.

Vantagens

• Sem passwords reutilizadas em vários serviços.
• Sem ataques de credential stuffing eficazes.
• Sem reset-de-password em massa quando há fugas em outras plataformas.

Tudo o que é sensível é cifrado em base de dados via Laravel encryption (protected $casts = ['... ' => 'encrypted']):

• Tokens OAuth Google Calendar (refresh_token, access_token) — cifrados.
• Magic link tokens — guardados como hash, nunca em claro.
• Passwords (quando existem em fluxos opcionais) — bcrypt nativo do Laravel.

A chave de cifragem está fora da base, no APP_KEY do ambiente. Quem só tem acesso ao backup da BD não consegue ler tokens.

A separação entre tenants é feita em três camadas defensivas:

• Middleware tenant.active — resolve o tenant do request a partir do domínio antes de qualquer controller correr.
• Global Scope TenantScope — aplicado automaticamente a queries Eloquent de models tenant-scoped, garantindo que nunca uma query devolve dados de outro tenant.
• Verificações explícitas em controllers — para operações sensíveis, validação adicional de ownership.

Customer e magic links são modelos globais — mas marcações, transações, notas, transações são tenant-scoped por design.

O sistema mantém histórico de mudanças em três modelos críticos:

• BookingChangeLog — todas as alterações em marcações: quem, o quê, quando.
• CustomerAuditLog — alterações em dados de cliente (campos antes/depois).
• NotificationLog — todos os emails e SMS enviados, com estado e erros.

Este trail resolve litígios típicos:

• "O meu telefone foi alterado, quem fez?"
• "A marcação foi cancelada por mim?"
• "O cliente diz que não recebeu o lembrete."

Endpoints sensíveis têm throttle aplicado:

• Verificação de slug no signup (throttle:60,1) — 60 req/min por IP.
• Magic link — limites no envio para evitar spam.
• Verificação de PIN — limites no número de tentativas.

Validação de input

• Form Requests para validar todas as mutações.
• Eloquent / Query Builder em vez de SQL raw — protecção contra injection.
• Escape automático em Blade — protecção contra XSS.
• CSRF token em todas as mutações via formulário.

O modelo SecurityAlert regista eventos potencialmente suspeitos para revisão da administração da plataforma. Casos típicos:

• Tentativas de login com IP inesperado.
• Erros 500 em rotas críticas.
• Padrões anormais de tráfego.

Os alertas alimentam o dashboard de admin para acção rápida.

O FIRO suporta os direitos básicos de RGPD via GdprRequest + GdprController:

Direito de acesso (exportação)

• Cliente abre o pedido pelo portal /minha-conta.
• Sistema produz um pacote com perfil + marcações + transações + comunicação.
• Endpoint /gdpr/export entrega o pacote.

Direito ao apagamento

• Cliente pede via portal.
• Após confirmação, dados são apagados (hard delete).
• Histórico anonimizado mantém-se onde necessário para integridade contabilística.

Outros direitos

Direito de rectificação é coberto pela edição directa no portal /minha-conta (perfil) e via backoffice do tenant. Consentimento de marketing é explícito e revogável.

Conformidade não é só um modelo de dados; é prática:

• Secrets apenas em variáveis de ambiente, nunca em código.
• Passwords nunca registadas em logs.
• Mensagens de erro ao utilizador não expõem internals (stacktrace, queries).
• Erros 500 são capturados em SecurityAlert mas o utilizador vê uma mensagem amigável.