Verificação Técnica de Conformidade com a Lei 152-FZ em Sites em 30 Segundos: Arquitetura do Scanner
Descubra como um scanner automatizado verifica a conformidade de sites com a Lei Federal 152-FZ sobre Dados Pessoais em apenas 30 segundos. O artigo detalha a arquitetura do scanner, abordando desde a detecção de formulários até a análise de políticas de privacidade, com foco em eficiência e precisão.
MundiX News·23 de junho de 2026·7 min de leitura·👁 1 views
Em 2025, as multas pela Lei 152-FZ (Lei Federal de Proteção de Dados Pessoais da Rússia) aumentaram significativamente, passando de 60 mil para 18 milhões de rublos (parte 8 do Artigo 13.11 do Código de Infrações Administrativas – vazamento repetido de dados pessoais com mais de 10 milhões de registros). Paralelamente, o Roskomnadzor (Serviço Federal de Supervisão de Comunicações, Tecnologias de Informação e Mídia de Massa) intensificou suas fiscalizações em sites, realizando 1.870 verificações em 2024 e aplicando multas totalizando 1,2 bilhão de rublos. A maioria das infrações identificadas são de natureza técnica, incluindo a ausência de HTTPS, falta de banner de cookies, formulários sem checkbox de consentimento e políticas de privacidade hospedadas em plataformas inadequadas como o Google Docs.
Enquanto advogados podem levar cerca de uma hora para identificar manualmente essas violações, foi desenvolvido um scanner capaz de realizar o mesmo processo em apenas 30 segundos. Este artigo explora a arquitetura desse scanner, o método de pontuação (scoring) para detecção de checkboxes de consentimento e os desafios encontrados na prática, como políticas hospedadas no Google Docs, checkboxes ocultos em plataformas como Tilda e formulários de agendamento em clínicas. O scanner é implementado em PHP 8, sem dependências externas, com aproximadamente 1.800 linhas de código.
O Que um Scanner 152-FZ Precisa Verificar?
A Lei 152-FZ estabelece nove obrigações para os operadores de dados pessoais (qualquer entidade que colete nome, e-mail ou telefone através de um formulário em um site). Deste total, oito obrigações podem ser verificadas tecnicamente externamente:
HTTPS (Artigo 19): A ausência de TLS (Transport Layer Security) é uma violação.
Política de Processamento de Dados Pessoais no Site do Operador (Artigo 18.1): Deve ser pública e conter sete seções específicas.
Consentimento para Processamento de Dados Pessoais em Cada Formulário (Artigos 6 + 9): Requer um checkbox separado, explícito e não pré-marcado.
Informação sobre o Uso de Cookies (Artigo 16 da Lei de Comunicações + 152-FZ + prática do Roskomnadzor): Necessita de um banner com duas opções de botão.
Registro no Registro do Roskomnadzor (Artigo 22): Obrigatório, a menos que o processamento se enquadre nas exceções da parte 2.
Localização do Banco de Dados (Parte 5 do Artigo 18): Bancos de dados de cidadãos russos devem estar localizados apenas na Rússia.
Contrato de Processamento (Parte 3 do Artigo 6): Se um serviço externo (como Tilda Forms, JivoSite, Bitrix24) for utilizado, um contrato é necessário.
Registro de Dados de Funcionários (Artigo 10.1): Se o site possuir uma página "Equipe" com nome completo, foto e cargo.
A nona obrigação, relacionada ao regime de processamento interno da empresa (ordem do operador, registro de sujeitos, responsável), não é visível externamente.
O scanner realiza todas as oito verificações em paralelo, agregando os resultados em um único relatório que inclui links para as normas violadas e o potencial valor da multa.
Arquitetura: Análise por Camadas
A arquitetura do scanner é dividida em camadas, começando com a requisição POST para /v1/p152/scan contendo a URL do site a ser verificado. Em seguida, as páginas principais, páginas de formulários e a política de privacidade são processadas em paralelo. Detectores (10 no total) e APIs externas (como o registro do Roskomnadzor e GeoIP do host) são utilizados para coletar informações. Finalmente, os resultados (Findings) são pontuados (Score) e apresentados em formato JSON.
O backend é construído em PHP 8.3, com Nginx e PostgreSQL 16, hospedado em uma máquina separada. O processo de escaneamento é iniciado pelo handler handlers/p152_scan.php, com a lógica principal localizada em api/lib/p152_quick_scan.php. O orçamento de tempo para escanear um único site é de 5 segundos (hard cap), com uma mediana real de 2.1 segundos em produção (sem cache). Escaneamentos subsequentes são quase instantâneos devido ao cache com TTL de 7 dias.
O Truque Principal: curl_multi para Tudo
Uma implementação ingênua baixaria os candidatos a páginas sequencialmente (página principal, depois /privacy, depois /policy, etc.), o que resultaria em mais de 30 segundos – um tempo inaceitável para a experiência do usuário. A solução é utilizar curl_multi_init para carregar um lote de URLs em paralelo. A função p152_fetch_urls_parallel gerencia múltiplas requisições simultâneas, com um timeout de 4 segundos por URL para evitar que um site lento comprometa todo o lote. Outras otimizações incluem MAXREDIRS 3 para lidar com redirecionamentos em cascata e CURLOPT_SSL_VERIFYPEER => false para contornar problemas com certificados SSL autoassinados ou expirados em sites menores. A normalização de IDN (Internationalized Domain Names) com p152_idn_url() garante a correta resolução de domínios como .рф.
Detector de Formulários: Pontuação em Vez de Binário
Uma abordagem simplista de verificar a presença de um <input type="checkbox"> próximo a um formulário resulta em cerca de 30% de falsos positivos. Isso ocorre porque sistemas como Bitrix renderizam o checkbox de consentimento em um <div> separado, longe do formulário, ou plataformas como Tilda utilizam display:none para o checkbox real, exibindo um rótulo customizado. Para superar isso, o scanner emprega um sistema de pontuação baseado em múltiplos sinais dentro de uma janela de aproximadamente 400 caracteres ao redor do formulário. Sinais como checkboxes visíveis, inputs com nomes relacionados a consentimento (acceptance, agreement), classes de plugins específicos, rótulos customizados, links para a política de privacidade e textos explícitos de consentimento contribuem para a pontuação. Uma pontuação igual ou superior a 6 indica consentimento válido; 3-5 sugere uma situação suspeita (informacional, sem multa); e 0-2 indica uma violação grave. Checkboxes ocultos por CSS deduzem pontos, marcando formulários que dependem exclusivamente deles como checkbox_hidden_only. Essa metodologia alcança cerca de 96% de precisão.
Detector de Política: Prioridades e Filtro de Conteúdo
A busca pela política de privacidade é realizada em três níveis de prioridade. O Nível 1 busca URLs com termos como privacy, privacy-policy, politika-konfidencialn ou textos de links que correspondam a padrões de "política de tratamento" ou "política de confidencialidade". O Nível 2 considera URLs e textos menos específicos. O Nível 3 identifica URLs relacionados a "consentimento" ou "oferta", que são retornados apenas como fallback e marcados como type='consent'. Após coletar os candidatos, um content-check é realizado, analisando os primeiros 30.000 caracteres do texto da página para confirmar a presença de frases como "política de tratamento de dados" ou "privacy policy".
A Nova Armadilha: Política no Google Docs
Um caso real envolveu a legalup.online, uma firma de advocacia cujas políticas estavam hospedadas no Google Docs. Embora os links tivessem âncoras corretas, o content-check falhava, pois o Google Docs carrega o conteúdo dinamicamente via API interna. A correção foi implementar uma verificação antecipada (early-return) se o host do candidato fosse um serviço de hospedagem SaaS conhecido, como docs.google.com. Isso é crucial porque uma política hospedada no Google Docs (EUA) constitui uma violação dupla: parte 5 do Artigo 18 (banco de dados fora da Rússia) e Artigo 18.1 (política deve estar no site do operador), com multas potenciais de até 6 milhões de rublos em caso de reincidência.
Integrações Externas: Registro do Roskomnadzor e GeoIP
O scanner consulta o registro de operadores de dados do Roskomnadzor (pd.rkn.gov.ru/operators-registry) usando o INN (Número de Identificação Fiscal) extraído do site para verificar o status de registro. Adicionalmente, utiliza o serviço GeoIP ip-api.com para determinar a localização geográfica do servidor de hospedagem. Se o servidor não estiver na Rússia, uma nota é adicionada ao relatório alertando sobre a possível violação da parte 5 do Artigo 18. Essas consultas são realizadas em paralelo com o escaneamento principal para não aumentar o tempo total.
Antipadrões que o Scanner Aprendeu a Ignorar
O scanner foi aprimorado para distinguir entre funcionalidades legítimas e violações. Formulários de busca (com role="search" ou action="/search") e campos honeypot (usados anti-spam) são ignorados. Registros de usuários são diferenciados de formulários de contato. A palavra checked é reconhecida apenas como um atributo booleano, evitando falsos positivos de classes CSS como is-checked. O consentimento implícito através de ações como clicar em um botão (comum em sistemas como Bitrix) é considerado uma zona cinzenta, mas aceitável para dados não sensíveis, contribuindo com pontos na pontuação.
Onde o Scanner Ainda é Fraco
Conteúdo renderizado via JavaScript (JS-rendered content) representa um desafio, pois o scanner baseado em curl só visualiza o HTML renderizado no servidor. Sites construídos com React, Vue ou Next.js sem Server-Side Rendering (SSR) podem ter até 90% do seu conteúdo não detectado. O plano é adicionar uma segunda passagem opcional utilizando um headless browser (como Chromium ou Playwright). Políticas em formato PDF também não são analisadas em profundidade; a intenção é integrar a ferramenta pdftotext para extrair o conteúdo e analisá-lo. A estimativa de multas é atualmente genérica; uma avaliação precisa exigiria considerar o faturamento da empresa, reincidência e volume de vazamento, o que transcende a capacidade de um scanner puramente técnico.
Conclusão
As violações técnicas da Lei 152-FZ são prevalentes em sites de pequenas e médias empresas. Dados do scanner indicam que 78% dos sites apresentam pelo menos uma violação grave, e 31% possuem três ou mais. As descobertas mais surpreendentes após seis meses de operação foram: a violação mais comum não é a ausência de política, mas sim checkboxes de consentimento ocultos em formulários Tilda, onde o usuário não tem a opção de desmarcá-los; e a segunda infração mais frequente é a hospedagem de políticas em domínios externos como Google Docs ou Notion, o que implica em violações de localização de dados e publicação inadequada.
Tags: 152-fz, pdn, scanner de site, curl_multi, roskomnadzor, 13.11 koap, política de tratamento de pdn
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Em 2025, as multas pela Lei 152-FZ (Lei Federal de Proteção de Dados Pessoais da Rússia) aumentaram significativamente, passando de 60 mil para 18 milhões de rublos (parte 8 do Artigo 13.11 do Código de Infrações Administrativas – vazamento repetido de dados pessoais com mais de 10 milhões de registros). Paralelamente, o Roskomnadzor (Serviço Federal de Supervisão de Comunicações, Tecnologias de Informação e Mídia de Massa) intensificou suas fiscalizações em sites, realizando 1.870 verificações em 2024 e aplicando multas totalizando 1,2 bilhão de rublos. A maioria das infrações identificadas são de natureza técnica, incluindo a ausência de HTTPS, falta de banner de cookies, formulários sem checkbox de consentimento e políticas de privacidade hospedadas em plataformas inadequadas como o Google Docs.
Enquanto advogados podem levar cerca de uma hora para identificar manualmente essas violações, foi desenvolvido um scanner capaz de realizar o mesmo processo em apenas 30 segundos. Este artigo explora a arquitetura desse scanner, o método de pontuação (scoring) para detecção de checkboxes de consentimento e os desafios encontrados na prática, como políticas hospedadas no Google Docs, checkboxes ocultos em plataformas como Tilda e formulários de agendamento em clínicas. O scanner é implementado em PHP 8, sem dependências externas, com aproximadamente 1.800 linhas de código.
O Que um Scanner 152-FZ Precisa Verificar?
A Lei 152-FZ estabelece nove obrigações para os operadores de dados pessoais (qualquer entidade que colete nome, e-mail ou telefone através de um formulário em um site). Deste total, oito obrigações podem ser verificadas tecnicamente externamente:
HTTPS (Artigo 19): A ausência de TLS (Transport Layer Security) é uma violação.
Política de Processamento de Dados Pessoais no Site do Operador (Artigo 18.1): Deve ser pública e conter sete seções específicas.
Consentimento para Processamento de Dados Pessoais em Cada Formulário (Artigos 6 + 9): Requer um checkbox separado, explícito e não pré-marcado.
Informação sobre o Uso de Cookies (Artigo 16 da Lei de Comunicações + 152-FZ + prática do Roskomnadzor): Necessita de um banner com duas opções de botão.
Registro no Registro do Roskomnadzor (Artigo 22): Obrigatório, a menos que o processamento se enquadre nas exceções da parte 2.
Localização do Banco de Dados (Parte 5 do Artigo 18): Bancos de dados de cidadãos russos devem estar localizados apenas na Rússia.
Contrato de Processamento (Parte 3 do Artigo 6): Se um serviço externo (como Tilda Forms, JivoSite, Bitrix24) for utilizado, um contrato é necessário.
Registro de Dados de Funcionários (Artigo 10.1): Se o site possuir uma página "Equipe" com nome completo, foto e cargo.
A nona obrigação, relacionada ao regime de processamento interno da empresa (ordem do operador, registro de sujeitos, responsável), não é visível externamente.
O scanner realiza todas as oito verificações em paralelo, agregando os resultados em um único relatório que inclui links para as normas violadas e o potencial valor da multa.
Arquitetura: Análise por Camadas
A arquitetura do scanner é dividida em camadas, começando com a requisição POST para /v1/p152/scan contendo a URL do site a ser verificado. Em seguida, as páginas principais, páginas de formulários e a política de privacidade são processadas em paralelo. Detectores (10 no total) e APIs externas (como o registro do Roskomnadzor e GeoIP do host) são utilizados para coletar informações. Finalmente, os resultados (Findings) são pontuados (Score) e apresentados em formato JSON.
O backend é construído em PHP 8.3, com Nginx e PostgreSQL 16, hospedado em uma máquina separada. O processo de escaneamento é iniciado pelo handler handlers/p152_scan.php, com a lógica principal localizada em api/lib/p152_quick_scan.php. O orçamento de tempo para escanear um único site é de 5 segundos (hard cap), com uma mediana real de 2.1 segundos em produção (sem cache). Escaneamentos subsequentes são quase instantâneos devido ao cache com TTL de 7 dias.
O Truque Principal: curl_multi para Tudo
Uma implementação ingênua baixaria os candidatos a páginas sequencialmente (página principal, depois /privacy, depois /policy, etc.), o que resultaria em mais de 30 segundos – um tempo inaceitável para a experiência do usuário. A solução é utilizar curl_multi_init para carregar um lote de URLs em paralelo. A função p152_fetch_urls_parallel gerencia múltiplas requisições simultâneas, com um timeout de 4 segundos por URL para evitar que um site lento comprometa todo o lote. Outras otimizações incluem MAXREDIRS 3 para lidar com redirecionamentos em cascata e CURLOPT_SSL_VERIFYPEER => false para contornar problemas com certificados SSL autoassinados ou expirados em sites menores. A normalização de IDN (Internationalized Domain Names) com p152_idn_url() garante a correta resolução de domínios como .рф.
Detector de Formulários: Pontuação em Vez de Binário
Uma abordagem simplista de verificar a presença de um <input type="checkbox"> próximo a um formulário resulta em cerca de 30% de falsos positivos. Isso ocorre porque sistemas como Bitrix renderizam o checkbox de consentimento em um <div> separado, longe do formulário, ou plataformas como Tilda utilizam display:none para o checkbox real, exibindo um rótulo customizado. Para superar isso, o scanner emprega um sistema de pontuação baseado em múltiplos sinais dentro de uma janela de aproximadamente 400 caracteres ao redor do formulário. Sinais como checkboxes visíveis, inputs com nomes relacionados a consentimento (acceptance, agreement), classes de plugins específicos, rótulos customizados, links para a política de privacidade e textos explícitos de consentimento contribuem para a pontuação. Uma pontuação igual ou superior a 6 indica consentimento válido; 3-5 sugere uma situação suspeita (informacional, sem multa); e 0-2 indica uma violação grave. Checkboxes ocultos por CSS deduzem pontos, marcando formulários que dependem exclusivamente deles como checkbox_hidden_only. Essa metodologia alcança cerca de 96% de precisão.
Detector de Política: Prioridades e Filtro de Conteúdo
A busca pela política de privacidade é realizada em três níveis de prioridade. O Nível 1 busca URLs com termos como privacy, privacy-policy, politika-konfidencialn ou textos de links que correspondam a padrões de "política de tratamento" ou "política de confidencialidade". O Nível 2 considera URLs e textos menos específicos. O Nível 3 identifica URLs relacionados a "consentimento" ou "oferta", que são retornados apenas como fallback e marcados como type='consent'. Após coletar os candidatos, um content-check é realizado, analisando os primeiros 30.000 caracteres do texto da página para confirmar a presença de frases como "política de tratamento de dados" ou "privacy policy".
A Nova Armadilha: Política no Google Docs
Um caso real envolveu a legalup.online, uma firma de advocacia cujas políticas estavam hospedadas no Google Docs. Embora os links tivessem âncoras corretas, o content-check falhava, pois o Google Docs carrega o conteúdo dinamicamente via API interna. A correção foi implementar uma verificação antecipada (early-return) se o host do candidato fosse um serviço de hospedagem SaaS conhecido, como docs.google.com. Isso é crucial porque uma política hospedada no Google Docs (EUA) constitui uma violação dupla: parte 5 do Artigo 18 (banco de dados fora da Rússia) e Artigo 18.1 (política deve estar no site do operador), com multas potenciais de até 6 milhões de rublos em caso de reincidência.
Integrações Externas: Registro do Roskomnadzor e GeoIP
O scanner consulta o registro de operadores de dados do Roskomnadzor (pd.rkn.gov.ru/operators-registry) usando o INN (Número de Identificação Fiscal) extraído do site para verificar o status de registro. Adicionalmente, utiliza o serviço GeoIP ip-api.com para determinar a localização geográfica do servidor de hospedagem. Se o servidor não estiver na Rússia, uma nota é adicionada ao relatório alertando sobre a possível violação da parte 5 do Artigo 18. Essas consultas são realizadas em paralelo com o escaneamento principal para não aumentar o tempo total.
Antipadrões que o Scanner Aprendeu a Ignorar
O scanner foi aprimorado para distinguir entre funcionalidades legítimas e violações. Formulários de busca (com role="search" ou action="/search") e campos honeypot (usados anti-spam) são ignorados. Registros de usuários são diferenciados de formulários de contato. A palavra checked é reconhecida apenas como um atributo booleano, evitando falsos positivos de classes CSS como is-checked. O consentimento implícito através de ações como clicar em um botão (comum em sistemas como Bitrix) é considerado uma zona cinzenta, mas aceitável para dados não sensíveis, contribuindo com pontos na pontuação.
Onde o Scanner Ainda é Fraco
Conteúdo renderizado via JavaScript (JS-rendered content) representa um desafio, pois o scanner baseado em curl só visualiza o HTML renderizado no servidor. Sites construídos com React, Vue ou Next.js sem Server-Side Rendering (SSR) podem ter até 90% do seu conteúdo não detectado. O plano é adicionar uma segunda passagem opcional utilizando um headless browser (como Chromium ou Playwright). Políticas em formato PDF também não são analisadas em profundidade; a intenção é integrar a ferramenta pdftotext para extrair o conteúdo e analisá-lo. A estimativa de multas é atualmente genérica; uma avaliação precisa exigiria considerar o faturamento da empresa, reincidência e volume de vazamento, o que transcende a capacidade de um scanner puramente técnico.
Conclusão
As violações técnicas da Lei 152-FZ são prevalentes em sites de pequenas e médias empresas. Dados do scanner indicam que 78% dos sites apresentam pelo menos uma violação grave, e 31% possuem três ou mais. As descobertas mais surpreendentes após seis meses de operação foram: a violação mais comum não é a ausência de política, mas sim checkboxes de consentimento ocultos em formulários Tilda, onde o usuário não tem a opção de desmarcá-los; e a segunda infração mais frequente é a hospedagem de políticas em domínios externos como Google Docs ou Notion, o que implica em violações de localização de dados e publicação inadequada.
Tags: 152-fz, pdn, scanner de site, curl_multi, roskomnadzor, 13.11 koap, política de tratamento de pdn
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
