Medidas Técnicas e Organizacionais (TOM)

1. Âmbito e finalidade

Este documento descreve as medidas técnicas e organizacionais (TOM) implementadas pelo MousePlayer para garantir um nível de segurança adequado ao risco, conforme o art. 32 do GDPR. Aplica-se a todo tratamento de dados de Usuários Finais realizado em nome de um Controlador (Cliente).

Operador do serviço: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Łódź, Polônia · NIP PL7252266190.

2. Confidencialidade – controle de acesso

2.1 Acesso físico

O serviço é executado em hardware de nossa propriedade e operado por nós, localizado em Łódź, Polônia. Nenhum centro de dados, fornecedor de nuvem ou hospedagem de terceiros participa da operação em si. Os servidores são operados internamente, em instalações fechadas na Polônia. O acesso é reservado exclusivamente ao controlador. O local é fechado à chave e monitorado por vídeo; nenhuma outra pessoa — incluindo locadores ou serviços de limpeza — tem acesso (declaração do controlador, 17/08/2026). O endereço preciso é deliberadamente omitido aqui.

2.2 Acesso ao sistema

• O acesso à aplicação exige uma conta individual de usuário com senha; as senhas são armazenadas como hashes com salt, nunca em texto claro.
• As interfaces administrativas são separadas da aplicação voltada aos clientes e acessíveis apenas a superadministradores; a autorização é verificada no servidor.
• Solicitações que alteram estado na interface web autenticada são protegidas por tokens CSRF; interfaces de programação se autenticam com suas próprias chaves.
• A administração do servidor é realizada por SSH com autenticação baseada em chave.
• O login pode ser opcionalmente protegido por um segundo fator (códigos de uso único baseados em tempo, conforme RFC 6238). O segredo é armazenado criptografado e os códigos de recuperação apenas como hashes; um código já utilizado não é aceito uma segunda vez, e tentativas malsucedidas repetidas bloqueiam temporariamente o segundo fator da conta.
• Cada login é acompanhado individualmente (login_sessions). O titular da conta vê a lista nas configurações e pode revogar logins individuais ou todos os outros; a revogação também encerra uma sessão em andamento e um token armazenado para manter o login. Uma alteração de senha encerra todos os outros logins. Se uma conta fizer login a partir de um dispositivo desconhecido (impressão digital baseada em navegador, sistema operacional, tipo de dispositivo e faixa de rede /24 ou /48 do endereço IP), o titular recebe um e-mail.

2.3 Acesso aos dados (autorização)

• Um modelo de funções (owner, admin, viewer) rege o que um usuário pode ver e fazer dentro de um espaço de trabalho. Exclusão e compartilhamento são restritos a owner e admin; a restrição é imposta no servidor, não apenas na interface.
• Toda consulta a dados de sessão é vinculada ao espaço de trabalho da conta solicitante. Uma gravação de outro cliente não pode ser acessada nem com identificador conhecido.
• Links de compartilhamento (veja 4.3) são o único modo de acessar uma gravação sem conta. São criados deliberadamente por um usuário autorizado, podem ser revogados e podem ter uma data de expiração.

2.4 Separação

• Os dados de clientes são separados logicamente por espaço de trabalho e projeto (canal). Todo caminho de leitura e escrita aplica essa restrição.
• Desenvolvimento e produção são executados em instalações separadas, com bancos de dados separados.

3. Pseudonimização e minimização de dados

• Nenhum tratamento antes do consentimento. O script de rastreamento não realiza identificação, armazenamento, cookie ou conexão de rede até que exista um sinal de consentimento. A ausência de sinal é tratada como recusa, não como permissão.
• Global Privacy Control. Um sinal GPC do navegador é respeitado mundialmente e prevalece sobre qualquer outro sinal.
• Identificadores pseudônimos. Os visitantes são diferenciados por tokens gerados aleatoriamente. O próprio Serviço não coleta nomes, endereços de e-mail nem números de telefone.
• Endereços IP. O endereço IP completo de um visitante é usado na memória de trabalho do servidor de gravação para estabelecer a conexão, determinar país, cidade e provedor de rede e defender contra abusos; é gravado no banco de dados apenas de forma truncada (para IPv4 a.b.c.xxx), e o painel nunca exibe o endereço IP completo de um visitante. Exceções: para detectar excesso de conexões, um endereço é contado no Redis por dez segundos; se acionar o bloqueio automático, é mantido integralmente por até 24 h como registro de bloqueio no Redis (mp_autoban:), e essa instância Redis grava em disco por AOF. Acessos por links de compartilhamento são registrados com endereço IP completo (share_views) e excluídos com o link.
• Ocultação em URLs. Os valores de parâmetros que normalmente contêm dados pessoais ou credenciais de acesso (por exemplo ?email=, ?token=, ?code=) são removidos antes do armazenamento – tanto na string de consulta quanto após o #, onde os serviços de login colocam credenciais de acesso (por exemplo #access_token=). Rotas de aplicações de página única e âncoras internas da página são mantidas.
• Entradas de formulários – três níveis, o mais rigoroso por padrão. Mascaramento completo (o padrão) substitui cada caractere de cada entrada antes de sair do navegador. Mascaramento seletivo mantém nomes, endereços, e-mail, telefone, campos de pagamento e áreas de texto livre totalmente mascarados e substitui apenas dígitos nos demais locais, para que termos de pesquisa continuem utilizáveis. Sem mascaramento grava a entrada como digitada. Os dois níveis mais fracos não são de autoatendimento: cada um exige nossa aprovação por escrito para aquela propriedade específica, registrada com horário e pessoa que a concedeu. A aplicação é feita no servidor – um projeto cujo nível armazenado supera a aprovação é limitado ao nível aprovado antes de o valor chegar ao navegador, de modo que definir o campo diretamente não produz efeito.
• O patamar mínimo que nenhuma aprovação afasta. Campos reconhecidos como senhas ou dados de pagamento permanecem totalmente mascarados em todos os níveis. O reconhecimento lê os atributos name, id, type e autocomplete do campo e abrange termos em inglês, alemão e polonês. Nada disso alcança conteúdo que o próprio site renderiza na página; regiões marcadas com data-mp-mask são inteiramente excluídas da gravação.
• Lista de exclusão. O Controlador pode excluir caminhos inteiros (por exemplo, páginas de checkout ou conta) da gravação. A exclusão é imposta no servidor e também se aplica quando uma aplicação de página única navega para um caminho excluído sem abrir nova conexão.

4. Integridade – controle de transferência e entrada

4.1 Transporte

• As conexões provenientes da internet são criptografadas com TLS; o TLS termina no nginx no servidor. Solicitações não criptografadas na porta 80 são redirecionadas para HTTPS. O script de rastreamento se conecta por WSS por padrão (/mp_wss/). Se a conexão WebSocket não se estabelecer, recorre a um túnel HTTP por HTTPS (/mp_wst) que passa pelas mesmas verificações no servidor; capturas de página muito grandes são enviadas por HTTPS com token assinado de duração limitada (/mp_dom), e conexões WebSocket malsucedidas são contadas por um endpoint de medição sem identificador de visitante (/mp_wsfail). Atrás do nginx, o servidor WebSocket escuta apenas na interface de loopback do servidor, sem TLS.
• Dentro de nossa própria rede local, no mesmo local, as conexões com o banco de dados (MariaDB) e o cache (Redis) não são criptografadas; a criptografia de transporte dessas conexões não está configurada. Ambos têm acesso restrito e são alcançáveis apenas pela nossa própria rede local (sem encaminhamento de portas); a instância Redis da aplicação escuta apenas na interface de loopback.
• Os certificados são renovados automaticamente. Um certificado expirado da aplicação seria detectado pela verificação a cada minuto feita por uma segunda máquina (veja a seção 5), que consulta por HTTPS com verificação de certificado; não há monitoramento separado da validade dos certificados.

4.2 Controle de entrada

• Ações administrativas são registradas em um log de auditoria com conta, horário e ação.
• Cada mudança de estado de consentimento é escrita como registro próprio, junto com sua origem (API explícita, Consent Mode, TCF, adaptador CMP, GPC), para que o estado no momento da gravação continue verificável.

4.3 Transferência posterior

• O script de rastreamento transmite exclusivamente à infraestrutura do próprio MousePlayer. Nenhum terceiro é contatado durante a gravação normal.
• Interfaces opcionais (webhooks, BigQuery, sistemas de relacionamento com clientes, marketing por e-mail e tickets, planilhas e armazenamento de objetos, interfaces de conversão de redes de publicidade) são configuradas pelo Controlador; são executadas em sistemas escolhidos por ele, ficam inativas salvo se ele as habilitar e transmitem itens individuais; somente a exportação BigQuery pode, no plano Enterprise e mediante solicitação, incluir também os eventos brutos da gravação (mouse_events). Quando o Controlador ativa uma ponte para uma ferramenta que ele próprio incorporou em sua página (como chat, rastreamento de erros ou análise web), o script entrega a essa ferramenta no navegador itens individuais, como o link da gravação; o próprio script da ferramenta os transmite ao seu fornecedor. Os destinatários não são suboperadores do MousePlayer.
• Textos gerados são formulados por um modelo de linguagem em nossas próprias máquinas com placa de vídeo, na mesma rede local e no mesmo local do servidor. Elas obtêm os resultados calculados por HTTPS, cada solicitação assinada com seu próprio segredo; a própria gravação nunca chega a elas, e nada é enviado a um serviço externo de IA – nem enquanto uma dessas máquinas está parada para manutenção: as tarefas aguardam, e a interface mostra a versão calculada.
• Links de compartilhamento transferem dados apenas a quem possui o link. O Controlador decide se cria um.

5. Disponibilidade e resiliência

• Um backup completo do banco de dados, diretório da aplicação e – desde 06/10/2026 – arquivo de gravações é criado diariamente às 03:00; até 11/08/2026, era executado às 02:00.
• Retenção local de backups: 7 dias. A cópia local é mantida sem criptografia em uma unidade conectada; a criptografia ocorre quando a cópia é transferida para fora do local. Os dumps não criptografados do período anterior à transição foram removidos dali em 12/08/2026, de modo que a pasta local contém agora apenas os dumps feitos desde a transição, e essa retenção se aplica a eles. Além da cópia local, o backup diário é transferido para fora do local – desde 05/09/2026 para um bucket do Google Cloud Storage na região europe-central2 (Varsóvia); antes disso, para uma conta privada do Google Drive; as cópias mantidas ali foram excluídas em 06/09/2026, após a verificação de uma restauração a partir do novo destino. Retenção ali: cópias diárias por 7 dias, cópias semanais (domingos) por 364 dias. Ambos os valores são uma configuração, não uma constante em um script: o backup os lê da mesma linha de configuração citada nesta frase, de modo que a declaração publicada e o comportamento não possam divergir. A cópia contém o banco de dados completo. Após 7 dias, os eventos de uma gravação são transferidos do banco de dados para um arquivo. Desde 06/10/2026 esse arquivo faz parte do backup diário; antes disso, não era incluído no backup, e gravações com mais de 7 dias não tinham cópia de backup. O arquivo fica no mesmo disco do sistema; a cópia local em uma unidade separada e a cópia externa protegem contra falha desse disco. Desde 11/08/2026, ele é criptografado em nosso próprio servidor antes da transferência (rclone crypt); os nomes de arquivos e diretórios também são criptografados, de modo que o fornecedor mantenha apenas blocos sem significado discernível. As chaves são mantidas em dois arquivos em nosso próprio servidor, legíveis e graváveis apenas pelo proprietário (modo de arquivo 600); o fornecedor não as possui e não pode ler o conteúdo. A descriptografia de uma cópia desse tipo foi verificada. A antiga pasta de destino não criptografada, que continha as cópias completas anteriores a 11/08/2026, foi excluída em 12/08/2026. Desde 19/08/2026, o sucesso da transferência é monitorado automaticamente. O backup escreve seu resultado em um arquivo de status, e o processo de monitoramento consulta a última execução bem-sucedida, não apenas a última execução – um script que inicia toda noite e aborta toda noite tem um horário recente e nenhum backup. Quando não houver execução bem-sucedida por mais que o período configurado (36 horas por padrão, que permitem exatamente uma execução diária perdida), um aviso é enviado por e-mail, no máximo uma vez por dia.
• Dados excluídos no sistema em operação permanecem nos backups até a expiração do respectivo backup – no máximo 364 dias após a eliminação definitiva; depois disso, também não estão mais contidos em nenhum backup. Essa é uma consequência inevitável da própria existência de backups; solicitações de eliminação executadas pela administração retiram os dados do tratamento de imediato (arquivados, ocultos, sem novas gravações) e os eliminam definitivamente em no máximo 30 dias, sem espera quando isso for expressamente solicitado; uma solicitação feita na página de dados /my-data é executada sem arquivamento, em regra em minutos. Não é realizada eliminação seletiva dentro de um backup: uma cópia é um único arquivo selado cuja finalidade é ser uma imagem fiel de um momento específico, e abri-lo, alterá-lo e selá-lo novamente destruiria essa propriedade e a capacidade de demonstrar que ninguém o adulterou. Backups não servem a nenhuma finalidade além de restaurar o sistema após uma perda; não são pesquisados, analisados nem divulgados. Quando um backup é restaurado, as solicitações de eliminação registradas para usuários finais são executadas novamente antes de o sistema voltar a operar – o registro da solicitação sobrevive à eliminação precisamente para que ela possa ser repetida. Para uma conta de cliente excluída, a situação é diferente: sua exclusão deliberadamente não deixa registro que a identifique, de modo que uma cópia restaurada conteria uma conta excluída após a data dessa cópia.
• Monitoramento. Um processo de monitoramento verifica, a intervalos de um minuto, o banco de dados e o worker de eventos, o servidor WebSocket, o frontend web, a atualização do banco de geolocalização, a execução diária de exclusão, o sucesso do backup e o espaço livre nos volumes do sistema e do backup. Cada resultado é escrito no estado compartilhado e mostrado na área administrativa, e cada verificação malsucedida é comunicada por e-mail no máximo uma vez por dia – um monitor que envia e-mails a cada minuto é desligado e então também deixa de informar a falha real. Antes de 19/08/2026, apenas as cinco primeiras verificações eram realizadas e só a execução de exclusão gerava alerta; o restante era manual, e este documento informava isso.
• O que esse monitoramento não pode fazer, declarado em vez de implícito: ele é executado na máquina que monitora, por isso não pode informar a falha total dessa máquina. Desde 02/10/2026, uma segunda máquina no mesmo local verifica a cada minuto se a aplicação aceita gravações – banco de dados, cache, servidor WebSocket, processos em segundo plano, fila e script de rastreamento – e alerta pelo Telegram após duas verificações malsucedidas consecutivas. Acessa o servidor pela rede local: uma falha da conexão com a internet, do roteador ou do DNS não é detectada por ela e ainda é percebida por uma pessoa, não por um monitor. Tempo objetivo de recuperação (RTO): não mais de 24 horas. Testes de restauração: a recuperação a partir do backup externo foi testada em 05/09/2026 e 06/09/2026 e em 07/10/2026 (restauração completa dos dados); nenhum cronograma fixo foi estabelecido.
• Sobrecarga e ataques. O nginx limita solicitações e conexões simultâneas por endereço; um endereço que excede persistentemente o limite é rejeitado no firewall pelo fail2ban por uma hora. O servidor WebSocket bloqueia automaticamente por 24 h endereços que geram excesso de conexões; bloqueios definidos manualmente pelo operador do sistema são mantidos no banco de dados.

6. Procedimentos de revisão regular

• As medidas deste documento são revisadas quando o tratamento muda e, nos demais casos, no intervalo indicado na seção 10.
• Uma verificação de instalação confere para cada projeto de Cliente se o script está incorporado corretamente e se as gravações chegam com um registro de consentimento. Projetos sem esse registro são sinalizados no painel.
• Atualmente, nenhum teste externo de penetração é contratado e não há certificações de segurança. Isso é declarado aqui, não omitido: um documento TOM que silencia sobre esse ponto dá a entender que tais testes existem.
• O número de usuários finais observados em todos os clientes é medido diariamente e comparado com o limite em que a avaliação nos termos do art. 37 do GDPR deve ser repetida (100000 por mês; veja a seção 9 do Registro das Atividades de Tratamento). Essa quantidade é determinada pelo tráfego nos sites dos clientes, não por nós; deixá-la sem monitoramento significaria permitir que a avaliação se desatualizasse silenciosamente. A repetição anual é acompanhada pelo mesmo processo.

7. Suboperadores

O MousePlayer contrata suboperadores apenas com a autorização geral por escrito do Controlador nos termos do Acordo de Tratamento de Dados. A lista atual, incluindo finalidade, categorias de dados e local do tratamento, é publicada separadamente:

• Lista de suboperadores

Nenhum terceiro participa da gravação em si: o script de rastreamento transmite exclusivamente à infraestrutura do próprio MousePlayer. Para dados de usuários finais, existe um destinatário além disso: uma cópia diária externa do banco de dados completo e do arquivo de gravações — incluindo gravações de sessões — é armazenada no Google (Google Cloud Storage, bucket em Varsóvia). Ela é mantida ali criptografada desde 11/08/2026: a criptografia ocorre em nosso próprio servidor antes da transferência (rclone crypt) e abrange também nomes de arquivos e diretórios; as chaves são mantidas pelo MousePlayer. O Google não as recebe e não pode ler o conteúdo, mas continua sendo suboperador — a criptografia é uma medida técnica, não uma mudança de papel. A antiga pasta de destino não criptografada, que continha cópias anteriores a 11/08/2026, foi excluída em 12/08/2026.

8. Retenção e eliminação

A retenção de gravações de sessões depende do nível de assinatura do Cliente:

• Gratuito: 7 dias · Small: 30 dias · Business: 90 dias · Enterprise: conforme acordo contratual individual.
• Após uma mudança para plano inferior, aplica-se um período de carência de pelo menos 30 dias, durante o qual continua a retenção anterior mais longa. Uma mudança para plano superior nunca reduz a retenção.
• O log da aplicação é eliminado após 60 dias, os logs do servidor web após 14 dias e os logs de segurança após 72 horas.
• Para sessões identificadas como acesso automatizado, a gravação é removida após 1 dia e a sessão eliminada após 14 dias. Para uma conta no plano Gratuito marcada como suspeita de abuso, apenas parte das visitas é gravada, e as gravações são excluídas após 1 dia.
• O log de entrega das integrações é eliminado após 30 dias. Fica no Redis, não no banco de dados, e expira ali por conta própria; a lista também é limitada a 25 entradas por projeto. Portanto, também não faz parte do backup diário.
• A eliminação ao fim de um prazo de retenção ocorre automaticamente e sem supervisão; não precisa ser acionada manualmente.

No encerramento da conta do Cliente, todos os dados pessoais associados são eliminados em até 30 dias, salvo se o direito da União ou de um Estado-Membro exigir armazenamento adicional. A exclusão é iniciada pelo Cliente nas configurações da conta; não é necessária solicitação por e-mail. Primeiro, ela arquiva a conta: o acesso termina imediatamente, nada mais é gravado ou exibido e, por 30 dias, ainda podemos restaurá-la mediante solicitação caso a exclusão tenha sido um engano. Após esse prazo, ela é eliminada definitivamente; ao iniciar a exclusão, o Cliente também pode escolher a eliminação definitiva imediata. Um projeto ou espaço de trabalho que o Cliente exclui também é primeiro arquivado por 30 dias e pode ser restaurado no painel durante esse período. Três elementos são deliberadamente mantidos, porque a lei exige ou porque documentam uma decisão, não uma pessoa: o registro de aceitação destes documentos, o log de segurança e alterações (com a referência ao usuário removida) e as solicitações de suporte. Por exceção, uma conta no plano Gratuito sem uso por 24 meses é eliminada definitivamente, sem arquivamento prévio, 30 dias após uma notificação entregue.

Registros de consentimento são mantidos além da eliminação da própria gravação. Não contêm dados comportamentais, apenas o fato, horário e origem da decisão de consentimento, e existem para cumprir a obrigação de responsabilização nos termos do art. 5(2) do GDPR.

9. Violação de dados pessoais

O MousePlayer notifica o Controlador sem demora injustificada e, no máximo, em 48 horas após tomar conhecimento de uma violação de dados pessoais que afete os dados do Controlador. A notificação contém as informações de que o Controlador precisa para cumprir suas próprias obrigações nos termos do art. 33 do GDPR.

Endereço para comunicar problemas de segurança: office@mouseplayer.com

10. Situação e versão

• Versão: 1.5 · Vigência: 16/10/2026 · Próxima revisão: 19/08/2027 · substitui a versão 1.4 de 07/10/2026. Alterações: a seção 2.2 indica autenticação de dois fatores, a lista de logins ativos com revogação e o alerta de login; a seção 2.3 indica as funções owner, admin e viewer; a seção 3 indica as exceções para endereços IP completos; a seção 4.1 descreve os caminhos de transporte do script e as conexões não criptografadas na rede local, em vez de afirmar que não existe caminho não criptografado; a seção 4.3 indica as demais interfaces; a seção 5 registra que o arquivo de gravações está incluído no backup desde 06/10/2026 e indica os testes de restauração realizados e os limites de sobrecarga; a seção 8 acrescenta prazos de retenção e a exclusão de contas inativas. Além disso, a seção 2.2 informa o estado do login SSH, e a duração do bloqueio automático é dada como configuração. A versão 1.4 substituiu a versão 1.3 de 17/09/2026. Alterações: as seções 5 e 8 estabelecem que a eliminação primeiro arquiva os dados – retirados do tratamento de imediato – e os elimina definitivamente em no máximo 30 dias. A versão 1.3 substituiu a versão 1.2 de 19/08/2026. Alteração: a seção 4.3 indica as máquinas que executam o modelo de linguagem para textos gerados, como os resultados chegam até elas e o que acontece durante a manutenção. A versão 1.2 substituiu a versão 1.1 de 11/08/2026. Alterações: a seção 5 estabelece a retenção do backup como configuração, não como constante, descreve o que acontece às eliminações em uma restauração e registra que o sucesso do backup e o espaço em disco passam a ser monitorados automaticamente; a seção 6 acrescenta a medição do limite do art. 37.
• Em caso de divergência entre versões em diferentes idiomas, prevalece a versão em inglês.