johnsmithCA-sta/privacy-audit

Auditoria de Desensibilização de Informações Pessoais (privacy-audit)

Propósito

Realizar uma auditoria de conformidade de desensibilização de informações pessoais em pacotes de skill locais, repositórios de código e diretórios de dados, gerando uma lista hierarquizada de problemas e um relatório de auditoria padronizado. Baseia-se na legislação chinesa: Lei de Proteção de Informações Pessoais (Decreto Presidencial nº 91), Lei de Segurança de Dados, Lei de Segurança Cibernética (Emenda de 2025), GB/T 35273-2020, GB/T 45574-2025 (em vigor a partir de 2025-11-01), GB/T 43697-2024, e "Medidas de Gestão de Auditoria de Conformidade de Proteção de Informações Pessoais" (em vigor a partir de 2025-05-01), entre outras. A auditoria segue um princípio rigoroso: qualquer processamento sem base explícita permissiva é tratado como "proibido".

Cenários de aplicação: verificação de segurança antes da publicação de Skills/IA, código/documentos; verificação de desensibilização antes do compartilhamento externo de conjuntos de dados; investigação de vazamento de logs e configurações; produção de relatórios de auditoria de conformidade. Diferenciação de posicionamento: Este skill é uma "ferramenta de auditoria" (detecção + classificação + recomendações de remediação + índice de referência), não é um "executor de desensibilização". Para cenários que exigem mascaramento/substituição direta de dados, use skills de ferramentas de desensibilização; este skill é responsável por determinar antecipadamente "se deve publicar, onde está a violação e com base em qual regulamento". Posicionamento comercial (v1.2.0): Voltado para o cenário de "autoverificação de conformidade antes da publicação de Skills/Aplicativos de IA", suporta o uso em plataformas de diálogo como o 扣子 (o usuário pode enviar anexos ou colar texto para escaneamento, sem necessidade de diretório local), podendo ser listado como um skill pago.

Palavras-chave de ativação

• auditoria de desensibilização / auditoria de privacidade / verificação de conformidade de privacidade / auditoria de conformidade / auditoria de proteção de privacidade / privacy audit / desensitization audit
• varredura de informações confidenciais / varredura de PII / PII scan / detecção de campos confidenciais / varredura de informações pessoais / investigação de vazamento de dados
• escaneie este diretório em busca de informações pessoais / escaneie este skill em busca de informações pessoais
• varredura de número de CPF / verificar se o código contém número de telefone / verificar se o código contém CPF / verificação de vazamento de número de cartão bancário
• o repositório contém chaves codificadas? / o log contém senhas em texto claro? / o arquivo enviado contém informações confidenciais?
• este skill vaza privacidade? / este skill pode ser publicado? / preciso desensibilizar antes de compartilhar? / verificação de desensibilização de conjunto de dados
• sugestões de remediação de desensibilização / emitir um relatório de auditoria de conformidade / verificação de segurança antes da publicação / revisão de conformidade antes da listagem

Preparação do Ambiente

# Dependências: Python 3.8+, biblioteca padrão apenas, sem dependências de terceiros
export SKILL_DIR=~/.workbuddy/skills/privacy-audit   # Caminho de instalação do skill
export TARGET_DIR=/path/to/diretório_a_auditar        # Diretório alvo (código/skill/dados)
export REPORT_DIR=/path/to/diretório_de_relatórios     # Recomenda-se fora do diretório de varredura para evitar auto-detecção

Fluxo de Execução

Primeiro Passo: Varredura Automática L1 (Primeiro a máquina, depois o humano)

# Varredura de diretório único + relatório JSON
python3 "$SKILL_DIR/scripts/privacy_audit.py" "$TARGET_DIR" \
  --rules "$SKILL_DIR/scripts/字段检测正则库.json" \
  --json "$REPORT_DIR/audit_result.json"

# v1.1.0 Varredura de múltiplos diretórios (auditoria combinada) + relatório HTML visual
python3 "$SKILL_DIR/scripts/privacy_audit.py" "$TARGET_DIR_A" "$TARGET_DIR_B" \
  --rules "$SKILL_DIR/scripts/字段检测正则库.json" \
  --json "$REPORT_DIR/audit_result.json" \
  --html "$REPORT_DIR/audit_result.html"

• Varredura de 17 tipos de campos confidenciais: Número de CPF / Número de telefone / Número de cartão bancário / E-mail / IP / Endereço exato / Coordenadas de localização precisas / Nome do médico / Nome da instituição hospitalar / Senha em texto claro / Informações de saúde / Informações de menores / Número da placa de veículo / Número do passaporte / ID do WeChat / Número QQ / Código de Crédito Social Unificado (novo na v1.1.0)
• Detecção de 5 tipos de credenciais codificadas: SkillHub key / GitHub token / OpenAI key / Tencent Cloud SecretId / COS credencial temporária
• Códigos de saída (integráveis em portões de CI): 0 = Aprovado; 1 = Atingido de alto risco (publicação proibida); 2 = Atingido de sensibilidade média (requer confirmação manual)
• --json: Relatório estruturado (contém scanned_roots/summary/verdict/findings, consumível por CI); --html: Relatório visual autocontido (cartão de resumo + gráfico de distribuição hierárquica + lista de ocorrências agrupada por arquivo, visualizável offline)
• --strict: Falha também em ocorrências de nível geral; --quiet: Apenas saída da linha de resultado

Varredura baseada em diálogo (novo na v1.2.0, adaptado para cenários de diálogo como o 扣子, sem necessidade de diretório local):

# Varredura de arquivo único (anexo enviado pelo usuário, como .py/.md/.json/.txt etc.)
python3 "$SKILL_DIR/scripts/privacy_audit.py" --file /path/to/uploaded.py \
  --rules "$SKILL_DIR/scripts/字段检测正则库.json" \
  --json "$REPORT_DIR/audit_result.json"

# Varredura de conteúdo de texto (código/texto colado pelo usuário)
python3 "$SKILL_DIR/scripts/privacy_audit.py" --text "conteúdo de texto a auditar" \
  --rules "$SKILL_DIR/scripts/字段检测正则库.json"

# Varredura de entrada padrão (pipe)
echo "texto a auditar" | python3 "$SKILL_DIR/scripts/privacy_audit.py" --stdin \
  --rules "$SKILL_DIR/scripts/字段检测正则库.json"

Segundo Passo: Auditoria Completa L2 (Verificação Manual em Seis Dimensões)

Use references/个人信息脱敏审查规范.md como base de execução e verifique dimensão por dimensão:

1. Identificação e Classificação: A lista de campos está completa? Os níveis de sensibilidade estão marcados? Risco de reidentificação por combinação? Marcação especial para menores?
2. Método e Cenário de Desensibilização: A escolha entre desidentificação e anonimização corresponde ao nível de sensibilidade? (Irreversível prioritário; reversível deve ter controle de chave)
3. Desensibilização em Nível de Campo: Verificar campo por campo nos quatro elos: armazenamento/exibição/transmissão/compartilhamento (foco: CPF e cartão bancário devem ser armazenados criptografados; interface deve ter mascaramento padrão; logs não devem conter texto claro)
4. Processo e Lista de Verificação: Marcar item por item da lista de 33 itens (A Pré-identificação 5 itens / B Armazenamento 6 itens / C Exibição 6 itens / D Log 4 itens / E Compartilhamento 5 itens / F Teste 2 itens / G Garantia Técnica 6 itens)
5. Investigação de Cenários de Violação: Investigar item por item os 15 cenários de alta frequência (armazenamento em texto claro, interface sem mascaramento, coleta excessiva, consentimento por padrão marcado, reconhecimento facial obrigatório, texto claro em logs, vazamento sem notificação, doxing/compra e venda, transferência internacional sem avaliação, etc.)
6. Verificação de Base de Conformidade: Os nomes/números/datas dos regulamentos e as referências dos padrões nacionais devem seguir a Parte 6 da especificação, sem alterações.

Terceiro Passo: Remediação e Verificação

• Itens de alto risco (P0) devem ser corrigidos: Remover credenciais codificadas → usar variáveis de ambiente/gerenciamento de chaves; dados confidenciais em texto claro → armazenamento criptografado + exibição mascarada
• Após a correção, execute novamente a varredura L1 e confirme que o código de saída caiu para 0 (ou apenas riscos baixos restantes)
• Itens de risco médio (P1) recomenda-se corrigir na próxima iteração; riscos baixos (P2) registrar para otimização futura

Quarto Passo: Relatório Padrão de Saída

Use references/审查报告模板.md como estrutura para gerar o relatório: Objeto da auditoria e perfil de dados → Visão geral dos resultados → Lista hierarquizada de problemas (P0/P1/P2) → Verificação de itens de conformidade → Prioridade de remediação → Tabela de verificação cruzada → Conclusão e isenção de responsabilidade.

Lista de Dependências

• Python 3.8+ (Bibliotecas padrão: argparse / json / os / re / sys)
• Nenhuma dependência de terceiros; --json opcional para saída de relatório estruturado consumível por CI

Limites e Segurança (Linhas Vermelhas)

1. Não constitui aconselhamento jurídico: As conclusões do relatório devem ser combinadas com o cenário de negócios específico; cenários de alta sensibilidade recomendam revisão manual + consulta a um advogado de conformidade
2. Saída do relatório para fora do diretório de varredura: Evitar que o relatório de auditoria seja escaneado novamente, e também evitar que o relatório caia nos artefatos a serem publicados
3. Totalmente local: Não chama nenhuma API de nuvem, não transmite o conteúdo auditado
4. Ignorar binários: .zip/.png/.pdf/.docx/.xlsx/.pyc etc. não são escaneados (se necessário, descompactar/converter para texto primeiro)
5. Proibido excluir: Este skill apenas relata, não exclui nem modifica nenhum arquivo auditado

Armadilhas Embutidas (Lições Aprendidas, Evite Repeti-las)

Armadilha	Causa Raiz	Solução (já embutida no script)
Constantes de coordenadas/números longos aleatórios falsamente detectados como CPF/cartão bancário	Regex puro corresponde apenas à "forma" sem validar "legitimidade"	Validação de checksum MOD 11-2 para CPF, algoritmo de Luhn para cartão bancário; se falhar na validação, é considerado falso positivo e ignorado
Números internos do CPF correspondidos novamente por regex de telefone/cartão bancário	Conflito de prioridade de regex	Deduplicação de intervalo: se o intervalo correspondido cair completamente dentro de uma correspondência de prioridade mais alta → ignorar (por exemplo, os 6 primeiros dígitos de um CPF começando com 110101 não serão falsamente detectados como número de telefone)
Substring de número longo (ex.: constante de coordenada 0.00669342162296594323) detectada como número de telefone	Regex de telefone sem limite	Adicionar limites de dígitos antes/depois no regex de telefone: (?<![0-9])…(?![0-9])
Relatório de auditoria escrito no diretório de varredura é escaneado novamente	O próprio relatório contém "amostras de correspondência"	Saída do relatório para fora do diretório de varredura (--json aponta para diretório externo)
Codificação de caracteres chineses confusa no Windows	O arquivo pode ser GBK em vez de UTF-8	read_text tenta UTF-8 primeiro, se falhar, decodifica com fallback baseado na proporção de caracteres imprimíveis
Diretórios grandes como node_modules/.git desaceleram a varredura	Nenhum filtro, varre tudo	SKIP_DIRS embutido (.git/pycache/node_modules/.venv/dist/build etc.)
Comportamento do script inconsistente após adicionar novo campo ao JSON de regras	Separação do arquivo de regras do script leva à dessincronização	O JSON de regras é a única fonte da verdade, o script o carrega dinamicamente; para adicionar um novo tipo de campo, primeiro altere o JSON e depois execute o script
Texto de definição de padrão no JSON de regras é detectado por si mesmo (ex.: "人民医院" aparece no regex de nome de hospital)	A própria definição de regra é uma amostra de palavra confidencial	Fenômeno normal; quando ocorrer, confirme manualmente que é uma definição de padrão e ignore (direção conservadora: prefira REVISAR a perder)
"北京市A12345" (nome de lugar + número) falsamente detectado como placa de veículo	Regex de placa sem limite, substring "京A12345" corresponde	Adicionar limites de caractere chinês/letra/dígito antes/depois no regex de placa: (?<!…)(?<![一-龥])…(?![…]); validador de estrutura (província+letra+comprimento7/8) como dupla proteção
Número aleatório de 18 dígitos tem cerca de 1/31 de chance de passar na validação GB 32100 de Código de Crédito Social Unificado	A validação do módulo 31 naturalmente deixa passar alguns números aleatórios	O USCC é classificado como "sensibilidade média" (REVIEW requer confirmação manual) em vez de alta sensibilidade, justamente para isso; teste de controle negativo usa um último dígito inválido real
A tag do caso de teste se autodetecta (ex.: "falso WeChat ID: xxx" é detectada pelo regex de WeChat ID)	A tag em si contém um prefixo gatilho + formato legal	Comportamento correto (no cenário real, "WeChat ID: xxx" deveria ser detectado); ao projetar casos de teste, evite replicar o prefixo gatilho na tag
Casos de evals/ contendo amostras confidenciais fictícias fazem com que preflight --strict relate avisos de phone/email	Casos de teste devem ter amostras de forma real para testar a capacidade de detecção, e o portão de publicação não distingue entre real e fictício	Ao fazer autoverificação para publicação, use --waive phone --waive email --reason "casos eval contêm amostras de teste fictícias, não são informações pessoais reais" para isentar e deixar registro; exclua .preflight-waiver.json antes da publicação; marque a primeira linha dos arquivos de amostra com "Dados de teste fictícios"
Número aleatório de 18 dígitos (ex.: timestamp+sequência) tem cerca de 1/11 de chance de passar na validação MOD 11-2 do CPF e ser detectado	A validação do checksum garante apenas a legitimidade, não a autenticidade; números aleatórios naturalmente têm uma probabilidade de passar	Limitação conhecida: ignore após confirmação manual como ID de sequência/timestamp/número de série; não afrouxe o regex por causa disso (prefira REVISAR a perder)

Exemplos de Uso (Simulação de Diálogo)

Usuário: Audite o diretório ~/projects/skill-demo para mim. Ele pode ser publicado?
Agente:
  1. Execute a varredura L1:
     python3 ~/.workbuddy/skills/privacy-audit/scripts/privacy_audit.py ~/projects/skill-demo \
       --rules ~/.workbuddy/skills/privacy-audit/scripts/字段检测正则库.json --json ~/reports/demo_audit.json
  2. Código de saída 1 → 2 ocorrências de alto risco (token GitHub codificado + CPF em texto claro) → Decisão: publicação proibida
  3. Verifique as seis dimensões L2 conforme o "Padrão de Auditoria": Armazenamento não criptografado, Exibição não mascarada, Log contém texto claro…
  4. Produza a lista hierarquizada de problemas (H-1 token codificado / H-2 CPF em texto claro / M-1 log em texto claro…)
  5. Sugestões de remediação + relatório padrão → Usuário corrige e executa novamente L1 → Código de saída 0 → Publicação permitida

Documentos de Referência

• references/个人信息脱敏审查规范.md: Especificação completa de seis dimensões (camadas L1/L2, lista de 33 itens, 15 cenários de violação, índice de 18 regulamentos + 6 padrões nacionais, apêndice de ferramentas) — a única fonte factual para execução da auditoria
• references/个人信息脱敏审查要点.md: Pontos-chave das seis dimensões (contexto regulatório e explicação detalhada das dimensões de julgamento; nível de origem: oficial = leis, regulamentos e padrões nacionais; consenso da comunidade = casos típicos públicos de execução judicial e prática do setor)
• references/审查报告模板.md: Template de estrutura de relatório padrão L2
• references/Changelog.md: Única fonte factual do histórico de versões (registro completo de alterações da versão 1.0.0 até a versão atual e explicação do escopo das versões)
• evals/: Conjunto de testes de regressão (10 casos de teste executáveis + conjunto de intenções de palavras-chave trigger_eval.json), execute após modificar este skill para verificar se não quebrou capacidades existentes; veja evals/README.md para instruções de execução

Versão e Fonte Factual

• O número da versão atual é baseado no version do frontmatter do SKILL.md; a tag de release, o resumo da versão no README e a entrada da versão atual em references/Changelog.md devem estar todos alinhados com ele.
• As alterações históricas têm references/Changelog.md como a única fonte factual. Os changelogs no SKILL.md e no README são apenas resumos das duas últimas versões + um link para esse arquivo; não mantenha um histórico de versões completo em vários lugares — três lugares com versões completas inevitavelmente divergirão.
• As marcações v1.1.0 novo / v1.2.0 novo no texto são anotações de pertencimento de funcionalidade: indicam em qual versão a funcionalidade apareceu pela primeira vez, são registros históricos e não mudam com o número da versão atual (a versão atual já é 1.3.0, as anotações permanecem as mesmas).
• "version": "1.1.0" em scripts/字段检测正则库.json é a versão do repositório de regras: independente da versão do skill, só incrementa quando o tipo de campo/regex/validador realmente muda. A versão 1.2.0 alterou apenas as entradas de varredura (--file/--text/--stdin), não as regras, portanto o repositório de regras permanece em 1.1.0 — este é o estado correto, não é um erro de digitação, não "alinhe por conveniência".

Changelog

O histórico completo das versões está em references/Changelog.md (fonte factual única); a tabela abaixo é um resumo das duas últimas versões.

Data	Versão	Tipo de Alteração	Conteúdo da Alteração	Fonte
2026-09-06	1.3.1	Otimização	Novas tags na plataforma (Proteção de Privacidade/Desensibilização/PII/Proteção de Informações Pessoais, 6 itens), sem alteração funcional	Otimização SkillHub
2026-08-29	1.3.0	Otimização	Cobertura de palavras-chave de 58% para 100% (novo conjunto de intenções evals/trigger_eval.json com 16 itens + cluster de palavras-chave expandido para 30 itens); descrição reduzida de 444 para 238 caracteres, detalhes movidos para o corpo do texto; novo conjunto de casos de teste executável evals/ com 10 itens (média de --run --aggregate de 1.00); novo references/Changelog.md; estabelecimento de duas fontes factuais para versão e histórico	Retificação de relatório de integridade
2026-08-19	1.2.0	Novo	Novas entradas de varredura --text/--stdin/--file para arquivo único/texto (adaptável para entrada em diálogo no 扣子, sem necessidade de diretório local); posicionamento convergido para "portão de conformidade pré-publicação"; nova descrição de posicionamento comercial	Adaptação para listagem no 扣子

(Entradas da 1.1.0 e anteriores em references/Changelog.md)

Isenção de Responsabilidade

Este skill foi gerado com assistência de IA, é apenas para referência, não constitui aconselhamento jurídico formal e não pode substituir um advogado qualificado. O julgamento de conformidade específico deve ser combinado com o cenário de negócios e consultar profissionais jurídicos, e deve basear-se nas leis e regulamentos mais recentes em vigor.