Segurança da plataforma

Segurança

Versão 1.2.0 · Vigente desde 2026-08-27 · Atualizado em 2026-08-27

Âmbito público vs políticas internas; isolamento de inquilinos; sem ISO/SOC 2/pentest.

1A. Âmbito desta página pública

Esta página é um resumo público de controlos implementados. Políticas internas (ISP, SSDLC, IR, retenção detalhada) não são certificações nem SLA. Não se afirma pentest, ISO 27001 ou SOC 2.

1. HTTPS e transporte

Todo o tráfego da aplicação é servido sobre HTTPS/TLS. Cookies de sessão utilizam atributos de segurança adequados ao ambiente de produção.

2. Autenticação

A autenticação assenta em Firebase Authentication, com sessões de servidor e controlos de verificação de email quando aplicável. Recomendamos palavras-passe fortes e gestão cuidadosa de dispositivos. MFA para contas owner é um requisito de governação e não está documentada nesta página como controlo já implementado.

3. Controlo de acessos

A plataforma aplica controlo de acessos baseado em funções (RBAC), segregação por empresa (multi-tenant) e rotas protegidas no middleware. Administradores de empresa gerem permissões internas.

4. Cópias de segurança

Dados críticos são protegidos por mecanismos de backup e retenção definidos na infraestrutura cloud e nos subprocessadores, com restauro em cenários de incidentes graves. Esta página não afirma um RPO/RTO, encriptação em repouso da Floworks, nem certificação ISO/SOC 2.

5. Ficheiros e classificação

Os novos carregamentos de documentos de colaboradores e de anexos de ausências utilizam entrega autenticada na Cloudinary, identificadores opacos e APIs same-origin da Floworks. O URL assinado é gerado no servidor (validade curta) e os bytes são transmitidos pela aplicação; a resposta HTTP não inclui o URL Cloudinary. Fotografias de perfil, logótipos e imagens de inventário permanecem, por conceção, em entrega pública.

  • Categoria A (pública por conceção): perfil, logótipo, inventário
  • Categorias C/D (confidencial / altamente sensível): documentos e anexos de ausências — arquitetura autenticada para novos objetos
  • Objetos históricos podem ter sido carregados como públicos; a migração é operacional e não está concluída neste documento
  • Esta página não garante que todos os objetos multimédia são privados

Questões de segurança de ficheiros: [email protected].

6. Acesso privilegiado e break-glass

O proprietário da plataforma não acede a dados de colaboradores do Cliente apenas por ser owner, nem constitui personificação. O acesso justificado de suporte exige, na configuração atual, autenticação do owner, indicação da empresa, um motivo, o âmbito quando aplicável, e registo em owner_access_logs.

  • O acesso de emergência deve ser excecional, necessário, proporcional, limitado ao pedido, registado e revistável
  • Não existe, no produto atual, uma sessão break-glass com expiração automática multi-pedido. Uma duração máxima de concessão, se for criada, será [MAXIMUM BREAK-GLASS DURATION — TO BE CONFIRMED]
  • MFA para owner é um requisito de governação e não está documentada como controlo já implementado

7. Registos de auditoria (visão pública)

A plataforma mantém trilhas de auditoria em áreas da aplicação (incluindo documentos, staffing, inventário, localizações e pedidos de IA) e um diário de acesso justificado do proprietário (owner_access_logs). Os clientes gestores podem ver audit_logs do seu inquilino segundo as regras de segurança. Os registos do owner não são visíveis no cliente.

  • Os logs de auditoria do inquilino não são editáveis nem apagáveis pelo cliente na configuração atual das regras
  • Não existe, nesta página, um prazo único de conservação — [PERÍODO DE RETENÇÃO — A CONFIRMAR] (exceção técnica identificada: location_audit com purge a 365 dias)
  • Pedidos de IA registam a ação, não o texto completo do prompt
  • Login/logout e downloads de ficheiros pelo Cliente nas APIs de ficheiros não estão documentados como eventos de audit_logs nesta versão — não se afirma cobertura total de todos os eventos de segurança

8. Prestadores e subprocessadores

Os prestadores confirmados na aplicação (Firebase Auth/Firestore/FCM, Gemini via Genkit quando a IA é usada, Cloudinary, Stripe) constam do DPA. O alojamento da aplicação e o SMTP não estão identificados como factos DPA verificados; a configuração de implementação referencia Railway e SMTP_HOST. Não foram identificados SDK de análise de audiências nem APM de terceiros.

9. Monitorização

O estado operacional publicado em /status é first-party. Existem trilhas de auditoria em áreas da plataforma. Esta página não afirma um APM de terceiros (Sentry, Datadog ou equivalente) porque não foi identificado no produto.

10. Divulgação responsável

Se identificar uma vulnerabilidade, reporte de forma responsável para [email protected] com descrição, passos de reprodução e impacto potencial. Não explore dados de terceiros nem realize ataques disruptivos. Comprometemo-nos a acusar a receção e a tratar o relatório com prioridade.

11. Limitações desta página

Esta página descreve controlos. Não é um SLA, não é certificação RGPD/ISO/SOC 2, não garante ausência de incidentes, e não afirma que todos os objetos Cloudinary históricos de documentos/ausências são privados. O texto candidato «nenhum documento privado é publicamente acessível» só poderá ser publicado após o checklist de migração legado.

12. Isolamento de inquilinos

O identificador de inquilino é o companyId. A autorização combina RBAC de produto (admin, gestor, secretariado, colaborador) com regras Firestore e controlos de API. O owner da plataforma não é administrador silencioso do inquilino. As permissões podem evoluir com o produto; esta página não congela uma matriz contratual.