NewSec Focus
SaaS de telemetria de produtividade para estações Windows, vendido a empresas clientes.
Agente nativo de baixo consumo, backend multiempresa e painel web com hierarquia
empresa → equipe → pessoa.
newsecfocus/
├── agente/ Agente Windows em C# (.NET 8): serviço supervisor + coletor de sessão
├── supabase/ Schema SQL, RLS, migrations, agregados e Edge Functions
├── dashboard/ Painel Next.js 15 (App Router, Tailwind, Supabase) — pronto para a Vercel
└── documentos/ Conformidade LGPD, termo de ciência e guia de instalação
Como as peças conversam
flowchart LR
subgraph Estacao["Estação Windows"]
direction TB
Coletor["Coletor (sessão do usuário)\nhooks, foreground, idle, domínio"]
Servico["Serviço supervisor (SYSTEM, Sessão 0)\nlança o coletor + sincroniza"]
SQLite[("telemetry.db\nSQLCipher")]
Coletor -- "1 registro/min" --> SQLite
Servico -- "lê lote" --> SQLite
Servico -- "CreateProcessAsUser" --> Coletor
end
Servico -- "POST lote (a cada 1h)" --> Edge["Supabase Edge Functions"]
Edge --> DB[("PostgreSQL + RLS")]
DB --> Agregados[("resumo_horario\nresumo_diario\nresumo_app_diario")]
Agregados --> Dash["Painel Next.js (Vercel)"]
A decisão de arquitetura mais importante do agente
A especificação pede hooks WH_MOUSE_LL/WH_KEYBOARD_LL, GetForegroundWindow e
GetLastInputInfo num serviço rodando como NT AUTHORITY\SYSTEM. Isso não funciona num
único processo. Desde o Windows Vista, serviços rodam na Sessão 0, isolada da área de
trabalho interativa:
- um hook de baixo nível instalado na Sessão 0 nunca recebe eventos do usuário;
GetForegroundWindow retorna NULL;GetLastInputInfo reflete o ócio da Sessão 0, não o do usuário.
Por isso o agente é dividido em dois processos:
| Processo | Conta | Sessão | Função |
|---|
| Telemetria.Servico | SYSTEM | 0 | Windows Service. Lança o coletor em cada sessão ativa (WTSQueryUserToken + CreateProcessAsUser), sincroniza o buffer com o Supabase e cuida da matrícula. |
| Telemetria.Coletor | usuário logado | interativa | Instala os hooks, lê foreground/idle/domínio e grava 1 registro por minuto no buffer local. |
Os dois compartilham o mesmo telemetry.db (SQLCipher) em C:\ProgramData, com a chave
protegida por DPAPI de máquina.
A decisão de arquitetura mais importante do backend
A atividade crua tem 1 linha por minuto por estação: 1.440 por dia, mais de 26 milhões
por ano num cliente de 50 estações. Nenhuma consulta do painel lê essa tabela. Três
agregados — por hora, por dia e por aplicativo/dia — são consolidados de forma incremental
a cada 10 minutos, com a classificação de produtividade já resolvida. É o que permite
filtrar "2026 inteiro" sem varrer a base, e o que sustenta a retenção: a atividade
minuto a minuto expira no prazo contratado, os resumos ficam para sempre.
Modelo do produto
Plataforma (revenda)
└── Empresa cliente organizations — plano, limite de estações, fuso, retenção
└── Equipe teams — pertence a 1 empresa
└── Colaborador employees — pertence a 1 equipe
└── Atividade
Papéis de acesso: OWNER e MANAGER (empresa inteira, administram), TEAM_LEAD
(apenas a própria equipe, imposto pelo RLS) e VIEWER (leitura).
O operador da plataforma administra contas — criar empresa, plano, licenças, suspensão —
e não tem acesso de leitura à telemetria dos clientes. Não é convenção de tela: não
existe política de RLS que permita isso.
Privacidade desde o desenho (LGPD)
O agente coleta apenas metadados. Nunca registra:
- ❌ conteúdo digitado (só a contagem de teclas — nenhuma tecla é lida);
- ❌ capturas de tela;
- ❌ conteúdo de mensagens (apps de mensageria têm o título omitido);
- ❌ URL completa (só o domínio, sem caminho nem query).
Além disso: título de janela higienizado (e-mails e números longos removidos), ícone de
bandeja informando o usuário, janela de coleta configurável, retenção por empresa e termo
de ciência pronto em documentos/. Ver
documentos/CONFORMIDADE-LGPD.md.
Passo a passo
- Banco — suba o Supabase e aplique as migrations: veja supabase/README.md.
- Painel — configure
.env.local e rode/deploy: veja dashboard/README.md.
- Agente — publique e instale como serviço: veja agente/README.md.
Guia unificado em documentos/GUIA-INSTALACAO.md.
Estado de validação
| Componente | Situação |
|---|
supabase/ | aplicado num projeto real (PostgreSQL 17.6, região São Paulo): 7 migrations, 12 tabelas, 3 jobs de pg_cron ativos |
dashboard/ | compila e roda contra o banco real; tsc --noEmit e next lint limpos |
agente/ | compila, publica e coleta — o coletor gravou atividade real numa estação Windows |
Validado com 23.300 minutos de atividade sintética (5 pessoas, 3 equipes, 14 dias):
- os KPIs do painel batem exatamente com a contagem no dado cru (minutos ativos,
minutos parados, teclas e número de pessoas);
- a consolidação comprimiu 23.300 linhas brutas em 393 baldes de hora e 50 de dia,
em 4,3 segundos;
- o isolamento por RLS funciona: um líder de equipe enxergou 2 das 5 pessoas e
7.001 dos 17.869 minutos, sem que nenhuma consulta precisasse saber disso.
As 5 Edge Functions estão publicadas e testadas em produção (02/09/2026):
registrar-dispositivo, ingestao-lote, validar-codigo, provisionar-empresa,
convidar-usuario. O ciclo completo foi provado por chamada HTTP direta, sem precisar
instalar o agente numa máquina: validar-codigo reconheceu o código real e devolveu o
nome da empresa; registrar-dispositivo matriculou uma estação de teste e devolveu
device_id, token e a configuração remota; ingestao-lote aceitou um registro de
atividade com esse token, resolveu o colaborador automaticamente
(teste.ponta-a-ponta → "Teste Ponta-A-Ponta") e gravou a linha em activity_logs
vinculada a ele. Os dados de teste foram apagados depois de confirmados.
Falta para o ciclo completo:
- Instalar o agente como serviço numa estação de verdade (o
Instalar.bat guiado
existe e está publicado, mas a instalação em si exige um clique humano na
confirmação do Windows — não testável nesta sessão automatizada).
- O serviço propagar ao coletor a pausa de coleta quando a conta está suspensa; o
servidor já devolve
collection_enabled na resposta de ingestão.
Instalador — decisão: sem MSI assinado
Sem certificado de assinatura de código, o MSI ficava bloqueado por SmartScreen e
antivírus de qualquer forma — então a distribuição para cliente passou a ser um
instalador guiado em agente/instalador-cliente/:
Instalar.bat — clique duplo, abre um PowerShell com interface própria (moldura,
cores, checklist de progresso), pede só o código de instalação numérico (gerado no
painel, em Administração › Empresa) e faz o resto sozinho: copia os binários, grava a
identidade da empresa no registro, cria e inicia o serviço Windows.Desinstalar.bat — remove o serviço; preserva o buffer local por padrão.publicar-cliente.bat — gera o pacote publicado (auto-contido, sem exigir .NET
instalado no cliente) pronto para zipar e enviar.
O Instalar.ps1 tenta validar o código contra o servidor antes de instalar (mostrando o
nome da empresa), mas segue mesmo se a validação falhar — a matrícula de verdade
acontece no primeiro boot do serviço, contra o banco.
Continua faltando assinatura de código para o SmartScreen parar de alertar; o MSI
(WiX, em agente/instalador/) fica como opção pronta se um certificado for adquirido
depois — hoje é caminho secundário, não o entregue ao cliente.
Stack
- Agente: C# / .NET 8 (Worker Service + WinForms), SQLCipher, Win32 P/Invoke, UI Automation.
- Backend: Supabase (PostgreSQL, RLS, Edge Functions em Deno/TypeScript, pg_cron).
- Painel: Next.js 15 (App Router, React 18), Tailwind CSS, Recharts,
@supabase/ssr, ExcelJS.
