Definições curtas de termos usados na documentação e na configuração do Data Boar. Ajuda novos leitores e tradutores. Os nomes na primeira coluna seguem o inglês canônico de config/código quando aplicável; entre parênteses, glossário em português do Brasil.
Locale (pt-BR): O texto explicativo usa português do Brasil (pt-BR), no mesmo padrão da documentação do produto para clientes e integradores — arquivo, usuário, implementação, etc. A primeira coluna mantém o termo em inglês quando esse é o nome usado em config, código e relatórios: não é mistura aleatória; serve para cruzar com a documentação EN e com a interface.
English: GLOSSARY.md
Como usar esta página: Leia a tabela de temas abaixo e vá direto à seção que combina com o seu papel (ex.: normas vs APIs vs ML). Cada linha é um parágrafo curto com ponteiro para a documentação longa—serve para desfazer siglas, não substitui o guia completo.
Os termos estão agrupados por tema (produto, fluxo de varredura, conformidade, APIs etc.). Dentro de cada grupo, as linhas seguem ordem alfabética na primeira coluna — mais fácil de navegar do que uma única lista A–Z quando convivem siglas de domínios diferentes (direito, transporte, ML). A decisão de expandir o glossário e manter essa estrutura está em ADR 0022.
| Tema (seção) | O que cobre |
|---|---|
| Identidade do produto e pano de dados | Nome, apelido do painel, metáforas data soup / ingredientes ocultos (disfarce de extensão, bases legadas, senha, metadados de mídia, esteganografia, trackers / “pixels” de marketing, migalhas de escopo — capacidades delimitadas) |
| Sessão, alvos, conectores e saídas | Execução de varredura, fontes, módulos de código, Excel/heatmap, amostragem, scan_manifest |
| Achados, tags, overrides e níveis | Resultados de detecção, rótulos, regex (linguagem de padrões), regex override, recomendações, sensibilidade, FP/FN |
| Risco e quasi-identificadores | Análise de risco combinado e reidentificação; dados de crianças e adolescentes e salvaguardas reforçadas (obrigação organizacional de contextualizar) |
| Leis e papéis em proteção de dados | Normas, autoridades, controlador/operador, base legal, controles nas recomendações do relatório, categorias de dados (PII, sensíveis, PHI, dados de cartão), encaminhamento em saúde nos EUA (ex.: Stark Law), pessoa jurídica vs dado pessoal (varredura) e papéis organizacionais (DPO, CISO) |
| Engenharia: confiabilidade, supply chain e registros | SRE, toil (trabalho operacional manual repetitivo vs automação), CI/CD, SBOM, ADRs, SAST, CVE / higiene de dependências, cultura de entrega, postura de segurança (Zero Trust, privilégio mínimo, secure by design, shift-left) |
| APIs, autorização e transporte | REST, OpenAPI, OAuth2, OIDC (OpenID Connect), TLS, CSP / HSTS (cabeçalhos), RBAC, CDN, WAF, DoS/DDoS, tempos limite de conexão/leitura (timeouts), paralelismo (scan.max_workers), limite de taxa de varreduras (rate_limit), limite de tamanho do corpo POST — controles para reduzir carga indevida nos ambientes do cliente |
| Tecnologia de detecção | Regex + ML/DL supervisionado (confiança reprodutível sobre dados amostrados); contraste com LLMs generativos; sinais avançados de inventário (quasi-identificadores, menores, dicas de jurisdição) como estrutura de relatório, não chat; contexto histórico (sem hype): AI_EVOLUTION_PRIMER.pt_BR.md |
| Posicionamento de conformidade e artefatos | GRC (governança, risco e conformidade), relatórios só com metadados, amostras, transferências internacionais, dicas de jurisdição / tensão (heurística, não lei aplicável), princípios (minimização), cadeia de operadores; SOC 2 (atestação AICPA — ver linha na tabela abaixo); VBA (value-based agreement — vocabulário farma/pagador; não o VBA do Office); Corporate-Entity-C/WRB e Google Gemini (ferramentas de revisão/chat do mantenedor — processo, não dependência do motor em produção) |
| ISO/IEC e ABNT NBR (normas de sistemas de gestão) | SGSI, gestão de privacidade (PIMS) e gestão de risco em segurança da informação — títulos curtos + links para o catálogo ISO; PDCA, SGSI, SoA |
| Governança de TI e gerenciamento de serviços | Governança de TI, ITSM, EDM, retroalimentação de governança, SVS / SVC (ITIL 4), SLA / SLO / OLA, maturidade organizacional, cocriação de valor, melhoria contínua |
| Licenciamento, open core e assinaturas | Modelo pretendido de open core, linha de base OSS vs módulos comerciais, JWT de licença, direitos de assinatura (rascunhos de política) |
| Governança de dados (DMBOK e ciclo de vida) | Dados, gestão de dados, governança de dados, GGD, Data Steward / Data Owner, linhagem de dados, qualidade de dados, DMBOK—vocabulário DAMA-DMBOK + ISO/IEC 25012 |
| Orquestração de lab: Maestro, completão e homelab | Maestro (regente), handler (termo canônico para Handle-*.ps1), persona, completão, bench track, vocabulário do lab-op; capo di sezione como metáfora narrativa apenas |
Ingredientes ocultos — como este grupo se encaixa: A história da sopa de dados é de propósito: raramente a organização enxerga todos os ingredientes de uma vez. Ingredientes ocultos não são um único detector — são o fio narrativo que agrupa capacidades delimitadas do produto (parte já entregue, parte roadmap ou opt-in). O javali fuça onde você aponta (alvos + config); não varre a floresta inteira por mágica (amostragem, ética, sem vigilância encoberta).
| Termo | Definição |
|---|---|
| Audit Trail (trilha de auditoria) | Registro imutável de uma sessão de scan e seus findings — timestamps, conectores usados, padrões de detecção acionados e artefatos de saída. Funciona como evidência de compliance de que o scan ocorreu, o que cobriu e o que encontrou. Armazenado em SQLite por sessão e exportável sob demanda. Diferente de logs de auditoria de OS. Metáfora: cada apresentação completa do javali deixa uma partitura que pode ser consultada; a trilha é o registro permanente do que o javali cheirou. Veja session, report; no contexto do lab Maestro veja §12. |
| Cloaked file (arquivo disfarçado) | Arquivo cuja extensão do nome não bate com o formato real (ex.: PDF renomeado para .txt). O motor usa magic bytes / sniffing de conteúdo para seguir o tipo verdadeiro — metáfora: ingrediente na prateleira com rótulo de outro. Veja PLAN_CONTENT_TYPE_AND_CLOAKING_DETECTION.md. Diferente de esteganografia (carga escondida dentro de um arquivo que já parece correto). |
| dashBOARd | Apelido opcional do painel web (UI no navegador com API por trás). Útil em rótulos tipo nav/Sobre; mantenha Data Boar como nome principal no pitch, jurídico e README. Veja README.md, USAGE.pt_BR.md. |
| Data Boar | Nome de exibição do produto. O javali fuça os dados; a ferramenta descobre e mapeia dados pessoais e sensíveis em várias fontes para conformidade (LGPD, GDPR, CCPA etc.). O id da distribuição PyPI é data-boar — veja CONTRIBUTING.pt_BR.md. |
| Data Sniffing | Rótulo opcional em materiais de POC, decks e docs técnicos de conformidade para o passo de descoberta e amostragem do motor sobre os alvos configurados: conectores descobrem estrutura, leem trechos delimitados e rodam detecção (regex / ML / DL opcional)—achados só com metadados, sem exfiltração. Textos informais em planos (“farejar mais”, “deep sniffing”) são a mesma ideia. Use Data Sniffing quando quiser um termo estável em deck ou doc estruturado; o pitch executivo do README.md prefere linguagem cotidiana (farejando com critério) sem exigir esse rótulo. Veja também: data soup, hidden ingredients, COMPLIANCE_FRAMEWORKS.pt_BR.md. |
| Deep Boring | Rótulo opcional em POC e material técnico para o lado de artefato de relatório estruturado da mesma execução: pastas Excel (planilhas de achados, texto de Recomendações / controles, alinhamento de norm_tag), heatmap opcional e recommendation overrides — “mergulhar na planilha chata de conformidade” que o produto ajuda a gerar como evidência, não como conclusão jurídica. Não é um segundo motor de varredura; em uso de deck/glossário, complementa o Data Sniffing. Veja também: report, compliance sample, COMPLIANCE_FRAMEWORKS.pt_BR.md. |
| data soup (sopa de dados) | O conjunto de fontes de dados que você varre—bancos, arquivos, APIs, Power BI, Dataverse, compartilhamentos etc. O Data Boar ingere e digere essa sopa: descobre estruturas, amostra valores e reporta onde há PII ou dados sensíveis. |
| hidden ingredients (ingredientes ocultos) | Metáfora de produto (vai junto com data soup): formas de evidência fáceis de ignorar em acervos reais — arquivos disfarçados, contêineres trancados por senha, bases legadas, texto de superfície em mídia rica, esteganografia opcional, strings de rastreadores embutidos e migalhas de escopo vindas de exportações de outras ferramentas (importação de escopo a partir de exportações — ver docs/plans/completed/PLAN_SCOPE_IMPORT_FROM_EXPORTS.md). Metáfora: a descoberta fica delimitada aos alvos configurados e ao roadmap (vocabulário de deck: Data Sniffing); não é visibilidade total nem operação encoberta. Narrativa guarda-chuva: formatos adicionais da data soup (docs/plans/completed/PLAN_ADDITIONAL_DATA_SOUP_FORMATS.md); dicas opcionais de rede: dicas de porta em rede com opt-in (docs/plans/PLAN_OPT_IN_NETWORK_PORT_SERVICE_HINTS.md). |
| legacy or abandoned data (dados legados ou abandonados) | Bancos, compartilhamentos ou árvores de arquivos que sobreviveram a dono ou documentação claros. Se estiverem nos alvos, o motor amostra o que for alcançável — o produto não “certifica” órfão. Metáfora: panela antiga no fundo da cozinha (ainda entra na sopa se você apontar o javali para lá). Inventário e retenção são decisões da organização. |
| password-protected archive or document (arquivo ou compactado protegido por senha) | Compactados (ex.: ZIP, 7z) ou documentos (ex.: PDF, Office) que exigem senha para descriptografar. Pode haver listas de senhas fornecidas pelo operador para arquivos onde isso estiver implementado (PLAN_COMPRESSED_FILES.md); sem o segredo, o miolo fica invisível na varredura — espere falsos negativos. Metáfora: tampa que você não tem; o javali não prova através dela. Não é quebrador de senha. |
| rich-media metadata (metadados de mídia rica) | Texto obtido de imagens, áudio, vídeo por canais laterais que não são o payload bruto de pixel/áudio: EXIF/XMP, tags estilo ID3, tags de contêiner de vídeo, legendas em arquivos parceiros — em geral opt-in (scan_rich_media_metadata, OCR opcional). Metáfora: aroma na borda da tigela; não alega extração de carga invisível. Mais leve que esteganografia. Veja PLAN_ADDITIONAL_DATA_SOUP_FORMATS.md Tier 3. |
| Safe-Hold (suspenção segura) | Estado operacional em que o produto interrompe o scan e reporta claramente em vez de continuar com evidência insuficiente ou ausente — ex.: autenticação do conector falha, alvo inacessível ou chave de config obrigatória ausente. O javali não pula silenciosamente e produz resultado parcial; ele expõe a lacuna para que o operador decida. Metáfora: o javali pausa no meio da escavação quando o terreno está inseguro — não desaparece. Veja também: Audit Trail, false negative. No contexto do lab Maestro veja §12. |
| steganography (esteganografia) | Esconder uma carga secreta dentro de um arquivo cobertura (imagem/áudio/vídeo) que ainda parece normal. Peso alto no roadmap, opcional — muito CPU/I/O frente a metadados. Não confunda com pixel / beacon de marketing (veja tracking references) nem com extensão disfarçada. Veja PLAN_ADDITIONAL_DATA_SOUP_FORMATS.md e Steganography em PLAN_CONTENT_TYPE_AND_CLOAKING_DETECTION.md. Em segurança, “pixels ocultos” costuma significar carga nos dados de imagem (truques estilo LSB) — fica aqui, não em analytics web. |
| tracking references (embedded) (referências de rastreamento incorporadas) | Hits heurísticos para URLs ou hostnames de rastreadores de terceiros em metadados ou texto (ex.: Tier 3b — telemetria / web beacon / string de marketing pixel em exportações). Sinal adjacente à privacidade para governança; não substitui detecção de PII. Não confunda com esteganografia em imagem. PLAN_ADDITIONAL_DATA_SOUP_FORMATS.md, seção Tier 3b. |
| Termo | Definição |
|---|---|
| connector (conector) | O código que fala com um tipo de target: descobre schema ou listagem, amostra dados, executa detecção de sensibilidade e grava findings. Novos conectores são adicionados conforme ADDING_CONNECTORS.pt_BR.md. |
| heatmap | Visualização (PNG e/ou planilha no relatório Excel) de sensibilidade/risco: em geral linhas = tabelas ou arquivos, colunas = nível de sensibilidade ou categorias, cor = risco. Ajuda DPOs e conformidade a ver áreas “quentes” de relance. |
| report (relatório) | Pacote principal de saída da sessão: em geral planilha Excel (abas de achados, recomendações, heatmap opcional) e metadados no SQLite. Caminhos e nomes vêm do config report.* (ex.: report.output_dir). Veja USAGE.pt_BR.md. |
| sampling (amostragem) | Uso de linhas ou trechos representativos do target (não necessariamente cópia integral de cada linha ou arquivo) para detecção dentro de limites de tempo e recurso. Profundidade depende de conector e configuração; se nada corresponder na amostra, isso não prova que não exista dado sensível no restante do alvo. Veja USAGE.pt_BR.md, SENSITIVITY_DETECTION.pt_BR.md. |
| scan (varredura) | Execução do motor sobre um ou mais targets dentro de uma sessão (CLI pontual, POST /scan na API ou dashboard). Em documentação em português costuma aparecer como varredura. |
| scan_manifest | Artefato YAML ao lado do Excel (scan_manifest_<prefixo_da_sessão>.yaml): produto/versão, id da sessão, janela de tempo, amostragem/timeouts, recorte de escopo, contagens de achados e config_scope_hash. Rastreabilidade para auditorias — não é cadeia de custódia jurídica completa. Veja USAGE.pt_BR.md; FORENSICS_AND_EVIDENCE_PRIMER.pt_BR.md. |
| session (sessão) | Uma execução de varredura. Cada scan via CLI ou API cria uma sessão (UUID + timestamp). Achados e falhas ficam associados a essa sessão; o relatório Excel e o heatmap são gerados por sessão. |
| SQLite | Motor de banco SQL embutido usado pelo produto para persistir metadados de sessão, achados e dados operacionais relacionados (ex.: insumos de Rastro de Auditoria (Audit Trail)) em disco—caminhos e retenção seguem config e implantação do operador. Não é um tipo de target de varredura de dados do cliente no sentido de conector; é o armazenamento local da aplicação. Veja USAGE.pt_BR.md, TECH_GUIDE.pt_BR.md. |
| target (alvo) | Uma fonte de dados configurada para varredura: ex. um banco (SQL/NoSQL), um caminho de filesystem, uma API REST, um share (SMB, NFS, SharePoint, WebDAV), Power BI ou Dataverse. Definido em targets no config. |
| Termo | Definição |
|---|---|
| false negative / false positive (falso negativo / falso positivo) | Falso positivo: marca como sensível quando não é (ou está fora do escopo). Falso negativo: dado sensível existe, mas não foi detectado (regras, amostragem, codificação de caracteres, formato de arquivo). Ajuste padrões e use revisão sugerida para casos ambíguos. Veja SENSITIVITY_DETECTION.pt_BR.md. |
| finding (achado) | Um resultado de detecção: um local (ex.: tabela.coluna, caminho de arquivo ou campo de API/CRM), o pattern_detected, o sensitivity level e opcionalmente o norm_tag. Armazenado como metadado no SQLite e exibido no relatório Excel (ex.: “Database findings”, “Filesystem findings”, “Application findings”). |
| norm_tag | Rótulo que associa um achado a uma regulamentação ou framework (ex.: LGPD Art. 5, GDPR Art. 4(1), CCPA). Definido pelos padrões embutidos ou em regex overrides e recommendation overrides para que os relatórios mostrem a “Base legal” e “Relevante para” corretos por framework. |
| pattern_detected | Nome da regra que deu match: um padrão embutido (ex.: LGPD_CPF, EMAIL, CCPA_SSN) ou um nome customizado do regex_overrides_file. Usado nos relatórios e nos recommendation overrides (ex.: norm_tag_pattern). |
| recommendation override (override de recomendação) | Bloco de config (report.recommendation_overrides) que personaliza a linha “Recomendações” do Excel para um norm_tag ou pattern_detected: base legal, risco, texto de recomendação, prioridade e “relevante para”. Permite alinhar a linguagem do relatório a UK GDPR, PIPEDA, POPIA, APPI, PCI-DSS ou normas internas sem mudar código. |
| regex (expressão regular) | Regular expression (regex): linguagem compacta de padrões para casar texto—literais, classes de caracteres, quantificadores (*, +, ?, {m,n}), âncoras (^, $), grupos e flags; neste repositório vale em geral a semântica do Python re, salvo nota em contrário. O detector aplica regex a texto amostrado e a nomes de coluna para reconhecer identificadores estruturados (ex. CPF, e-mail). Padrões embutidos vêm no produto; extras entram por regex override. Padrões mal calibrados aumentam falsos positivos/negativos. Veja também: regex override, pattern_detected; SENSITIVITY_DETECTION.pt_BR.md. |
| regex override (override de regex) | Padrão regex customizado definido no regex_overrides_file (ou inline). Cada entrada tem name, pattern e opcionalmente norm_tag. O detector aplica o padrão a nomes de colunas e texto amostrado; um match gera um finding com esse nome e norm_tag. Veja regex_overrides.example.yaml e SENSITIVITY_DETECTION.pt_BR.md. Baseado no conceito regex (entrada anterior nesta seção). |
| sensitivity level (nível de sensibilidade) | Um de HIGH, MEDIUM, LOW. Indica o quão sensível é o dado detectado (ex.: identificadores diretos → HIGH; quasi-identificadores ou só contexto → MEDIUM/LOW). Usado para filtrar (report.min_sensitivity), abas do relatório e o heatmap. |
| suggested review (revisão sugerida) | Linha ou coluna do relatório (ex. Excel Suggested review (LOW)) onde colunas “tipo ID” ou ambíguas em LOW são marcadas para revisão humana—em geral via detection.persist_low_id_like_for_review e opções relacionadas. Veja SENSITIVITY_DETECTION.pt_BR.md. |
| Termo | Definição |
|---|---|
| aggregated identification (identificação agregada) | Análise que olha risco em conjunto: o relatório destaca tabelas/arquivos onde vários sinais tipo quasi-identificador (e categorias relacionadas) aparecem juntos, não só matches célula a célula. Config, nomes de abas e texto acompanham SENSITIVITY_DETECTION.pt_BR.md e releases do produto. |
| minor (children's and adolescents' data) (menores — crianças e adolescentes) | Em risco e governança, dados pessoais sobre crianças e adolescentes em geral exigem proteção reforçada e análise contextual (ex.: LGPD art. 14 — melhor interesse da criança; regras do GDPR para serviços voltados a crianças; COPPA e leis estaduais nos EUA sobre privacidade de menores em programas com foco americano — mapear com assessoria). A organização precisa interpretar o contexto (faixas etárias, consentimento, setor) e aplicar limites de acesso, retenção e finalidade mais rígidos que para adultos. O Data Boar pode sinalizar padrões tipo DATE ou identificação agregada; não define idade, base legal nem consentimento parental — isso é política e jurídico. Veja também: identificação agregada, quasi-identifier, counsel; MINOR_DETECTION.pt_BR.md. |
| quasi-identifier (quasi-identificador) | Dado que, sozinho ou em combinação com outros, pode contribuir para reidentificar uma pessoa (ex.: gênero, cargo, faixa etária, CEP). Com identificação agregada habilitada, o relatório sinaliza tabelas/arquivos onde várias categorias de quasi-identificadores aparecem juntas (LGPD Art. 5, GDPR Recital 26). |
| Termo | Definição |
|---|---|
| ANPD | Autoridade Nacional de Proteção de Dados: autarquia de fiscalização da LGPD—orientações, processos, sanções. Não substitui assessoria jurídica sobre fatos concretos. Site oficial: gov.br/anpd. |
| cardholder data (dados do portador do cartão) | Cardholder data (CHD) e sensitive authentication data (SAD) no PCI-DSS: ex. PAN, nome do portador, validade, dados de trilha/chip completos, CVC onde a norma proíbe armazenar. Escopo cartão/pagamento, não o mesmo que PII genérico. PCI SSC; amostra no repositório: compliance-sample-pci_dss.yaml. |
| CCPA (California Consumer Privacy Act) | Lei estadual da Califórnia (EUA), alterada pela CPRA (California Privacy Rights Act): rege o tratamento de informações pessoais de consumidores por muitas empresas; inclui direitos de transparência, exclusão, correção e opção de não participar de venda ou de certo compartilhamento (com limiares de porte/setor e exceções). O Data Boar usa CCPA em norm_tag e padrões embutidos (ex.: CCPA_SSN); mapeamento e amostras: COMPLIANCE_FRAMEWORKS.pt_BR.md. Não substitui assessoria jurídica. Visão geral: Procuradoria da Califórnia — CCPA. Veja também: PII (terminologia vs personal data do GDPR). |
| CISO (Chief Information Security Officer) | Chief Information Security Officer (CISO; às vezes CSO em organizações menores): executivo responsável pelo programa de segurança da informação—tratamento de risco, alinhamento de controles à política, preparo para incidentes e articulação com operações de TI. Há sobreposição com privacidade em vazamentos e salvaguardas, mas não é a mesma função normativa do Encarregado / DPO (LGPD art. 41). Leitor típico de inventários, heatmap e evidência técnica de onde há dados sensíveis—não substitui teste de invasão nem assessoria jurídica. Veja também: DPO. |
| CPML | Rótulo dependente de contexto—não é termo codificado na LGPD/GDPR. Em compliance comercial EUA (life sciences), os mesmos programas citam regras CMS (Stark, Anti-Kickback), relatórios Sunshine / transparência e FDA (promoção ou qualidade CGMP; manuais CPGM)—planilhas internas podem usar códigos como CPML junto de campos HCP; confirme no dicionário de dados. Não assuma CPML = CGMP ou CPGM sem prova na fonte. Em engenharia, CPML ainda pode ser convolutional perfectly matched layer (simulação). O Data Boar não traz padrão “CPML”; use regex overrides. Veja também: HCP, Stark Law. |
| controller / processor (controlador / operador) | Controlador define finalidades e meios do tratamento; operador trata em nome do controlador (GDPR arts. 4(7)–(8)). LGPD: controlador / operador (art. 5º). Afeta contratos e responsabilidade; o produto mostra onde há dados—não diz quem é controlador ou operador em sentido jurídico. Veja também: processor (operador). GDPR art. 4; LGPD: Lei 13.709/2018. |
| controls (report recommendations) (controles nas recomendações do relatório) | Na planilha Excel Recomendações, expressões como “controles” na coluna de texto referem-se a medidas organizacionais e técnicas que as equipes podem adotar—ex.: restrição de acesso, criptografia, minimização, prazo de retenção, pseudonimização. É texto orientativo para DPO, CISO, segurança e compliance, não matriz automática de controles nem certificação. Recommendation overrides e compliance samples ajustam a redação. Diferente de controles de postura em engenharia (seção Engenharia neste glossário). Veja também: recommendation override; ADR 0025. |
| data subject (titular de dados) | Titular de dados (LGPD, art. 5º, II): pessoa natural a quem se referem os dados pessoais objeto de tratamento. No GDPR, o termo é data subject (art. 4(1)). Vai além de rótulos de “cliente” ou “usuário” em um só sistema. Direitos do titular na LGPD (art. 18, em resumo): confirmação de tratamento, acesso, correção, anonimização/bloqueio/eliminação, portabilidade, informação sobre compartilhamento e decisões automatizadas, revisão de decisões, revogação do consentimento, petição à ANPD, entre outros. GDPR (Cap. III, em resumo): acesso, retificação, apagamento, limitação, portabilidade, oposição, decisão automatizada. HIPAA fala em individual (não “titular”): direitos de acesso, retificação e prestação de contas sobre divulgações de PHI—norma e escopo diferentes dos do LGPD/GDPR. O Data Boar apoia mapeamento/evidência para governança; não atende pedidos do titular por si só. LGPD arts. 5º e 18; GDPR art. 4(1) · Cap. III; HHS — direitos do indivíduo (HIPAA). |
| DPO (Data Protection Officer) | Data Protection Officer; na LGPD, Encarregado (art. 41)—ponto de contato com titulares e autoridade. Leitor típico de relatórios de varredura. LGPD art. 41. Veja também: CISO (programa de segurança da informação; papel distinto). |
| GDPR | General Data Protection Regulation (UE 2016/679). Texto de referência: gdpr-info.eu. Mapeamento no produto: COMPLIANCE_FRAMEWORKS.pt_BR.md. |
| HCP (health care professional / profissional de saúde) | Sigla em inglês muito usada em indústria farmacêutica, life sciences e TI em saúde para profissionais de saúde habilitados ou qualificados (médicos, enfermeiros, farmacêuticos, etc.), em contraste com pacientes. Programas de CRM, amostragem e consentimento costumam tratar dados pessoais desses profissionais. O Data Boar não traz um padrão próprio chamado “HCP”; use regex overrides, norm_tag / recommendation overrides e identificação agregada (ex. categorias ligadas a saúde) quando a política da organização exigir. Veja também: data subject, PHI, sensitive personal data / special category data. |
| HHS (Department of Health and Human Services) | Departamento de Saúde e Serviços Humanos dos Estados Unidos: departamento federal que abriga o CMS (Medicare/Medicaid, incluindo administração de programas como Stark) e a FDA (medicamentos, dispositivos, biológicos), e publica as regras do HIPAA com fiscalização da OCR. Costuma aparecer junto de PHI e materiais para consumidores sobre HIPAA. Não confunda com HSS — outros contextos usam HSS (ex.: nomes institucionais, siglas distintas); confira o contexto. HHS.gov. Veja também: PHI, HIPAA, Stark Law. |
| legal basis (base legal) | Fundamento que autoriza, na lei, tratar dado pessoal: LGPD, art. 7º (incisos I a X—ex.: consentimento, obrigação legal, estudos por órgão de pesquisa, legítimo interesse quando cabível); GDPR, art. 6º (lawful basis). No relatório, a coluna Base legal (base_legal em recommendation overrides) traz citações ou resumos alinhados ao norm_tag—apoio à análise humana, não conclusão automática de que aquele fundamento vale para o seu caso. Veja também: norm_tag, recommendation override; COMPLIANCE_AND_LEGAL.pt_BR.md. |
| legal entity and personal data (scanning) (pessoa jurídica e dado pessoal na varredura) | Na LGPD/GDPR, dados pessoais referem-se a pessoas naturais. CNPJ (ou equivalente) e razão social identificam pessoa jurídica; isso não faz o motor “ignorar” e-mails, telefones, CPF ou nomes de sócios, representantes ou contatos comerciais quando a amostra casa com padrões—muitas vezes identificam indivíduos. O Data Boar aplica regex e ML/DL a nomes de coluna e texto de amostra; não há regra “tabela só de empresas, logo não é LGPD”. Colunas CNPJ acionam LGPD_CNPJ; campos de contato podem gerar EMAIL, PHONE ou outros HIGH/MEDIUM. A qualificação jurídica é de assessoria e política; o produto expõe achados para revisão (amostragem e ajustes ainda permitem falsos negativos). Veja também: PII, finding. |
| LGPD | Lei Geral de Proteção de Dados (Lei nº 13.709/2018). Texto legal: Planalto. Amostras e rótulos: COMPLIANCE_FRAMEWORKS.pt_BR.md. |
| PHI | Protected Health Information (EUA, HIPAA, Privacy Rule): informação de saúde identificável, mantida ou transmitida por entidade coberta ou business associate, em qualquer meio (oral, papel, eletrônico). O subconjunto eletrônico é ePHI (ver também a entrada ePHI mais adiante neste glossário). Categoria jurídica dos EUA—não confundir com só “dado sensível” da LGPD sem assessoria. HHS — visão geral HIPAA/privacidade. |
| PII | Personally identifiable information—informação relacionada a pessoa natural identificada ou identificável (alinhado a dado pessoal LGPD/GDPR). Guarda-chuva mais amplo que dado pessoal sensível, PHI ou dados de cartão; esses têm regras específicas por norma. O motor expõe via findings, sensitivity level e quasi-identifier. Terminologia: o GDPR usa personal data (dado pessoal, art. 4º); CCPA/CPRA usa personal information (informação pessoal)—em muitos casos o conjunto se sobrepõe, mas os textos legais não são idênticos em abrangência nem em exclusões (detalhes com assessoria). PII é jargão comum em inglês americano (segurança/compliance); não use a sigla IP para “informação pessoal” do CCPA — conflita com Internet Protocol e intellectual property. Veja COMPLIANCE_AND_LEGAL.pt_BR.md. Veja também: CCPA. |
| processor (operador) | Operador (LGPD, art. 5º): pessoa natural ou jurídica que realiza o tratamento de dados pessoais em nome do controlador, segundo instruções documentadas (contrato, cláusulas contratuais, instrumento equivalente)—ex.: nuvem que hospeda o banco do cliente, folha de pagamento terceirizada, suboperador contratado. Não é o mesmo que “operador de TI” ou “quem roda o scanner” nos textos de implantação (sentido técnico). Quem é controlador ou operador em cada base é questão jurídica; o produto mapeia onde os dados aparecem. Veja também: controller / processor; GDPR art. 4(8); LGPD art. 5º. |
| SAR (Subject Access Request / pedido de acesso do titular) | Subject Access Request — em muitos textos também DSAR (Data Subject Access Request): pedido do titular para exercer acesso e direitos de transparência correlatos — ex.: GDPR art. 15 (confirmação de tratamento, cópia dos dados pessoais); UK GDPR no mesmo espírito. Na LGPD, o art. 18 traz confirmação de existência, acesso e outros direitos do titular — costuma ser tratado em fluxos de privacidade/jurídico semelhantes. O Data Boar ajuda a mapear onde dados pessoais podem estar para inventário e triagem; não automatiza nem conclui o atendimento ao SAR/DSAR e não substitui processo do DPO ou assessoria. Veja também: data subject. GDPR art. 15. |
| sensitive personal data / special category data (dados pessoais sensíveis / categorias especiais) | LGPD, art. 5º, II — dado pessoal sensível: origem racial ou étnica, convicção religiosa, opinião política, filiação sindical ou a organização de caráter religioso, filosófico ou político, dado sobre saúde ou vida sexual, dado genético ou biométrico quando vinculado a pessoa natural. GDPR, art. 9 — categorias especiais: lista em grande parte sobreposta (saúde, biometria para identificação, genética, etc.), com condições e vedações. Não é automaticamente o mesmo conjunto que PHI ou dados PCI—finalidade e norma mudam. Tratamento costuma exigir base mais estrita. LGPD art. 5º; GDPR art. 9. |
| Stark Law (Lei Stark / autoencaminhamento de médicos) | Lei federal dos EUA (Ethics in Patient Referrals Act, 42 USC §1395nn): restringe encaminhamentos Medicare para certos serviços de saúde designados quando o médico referidor (ou familiar imediato) tem relação financeira com a entidade receptora, com exceções e regulamentação CMS. Costuma aparecer junto do Anti-Kickback Statute—são normas de fraude e abuso / encaminhamento, distintas da privacidade HIPAA sobre PHI. Útil ao inventariar bases saúde EUA ou textos de compliance que citam Stark. O Data Boar mapeia onde há dados; não conclui conformidade Stark. CMS — physician self-referral (Stark). Veja também: PHI, HCP. |
| Termo | Definição |
|---|---|
| boar_fast_filter | Módulo de extensão em Rust (compilado via PyO3) que fornece uma passagem de pré-filtro de alto desempenho antes do pipeline de detecção em Python. Quando disponível, descarta trechos que não podem conter dados sensíveis mais rapidamente que regex puro em Python, reduzindo uso de CPU e melhorando o throughput. Avaliado contra o caminho Python puro em runs de completao A/B (--bench-compare). Veja TECH_GUIDE.md; build: |
| ust/boar_fast_filter/. Contrato de performance: o delta medido entre tracks stable e �eta é o sinal principal para confirmar uma correção no PyO3 ou no núcleo Rust. | |
| ADR | Registro de decisão de arquitetura (Architecture Decision Record): documento curto que registra uma decisão técnica relevante, contexto e consequências. O repositório mantém ADRs em [docs/adr/](adr/ADR-0000-project-origin-and-adr-baseline.md), a partir da linha de base 0000. O conceito tem origem em Michael Nygard (2011); este repositório formaliza sua linhagem MADR como UMADR (ADR 0045). Guia de onboarding: DECISION_RECORDS_PRIMER.pt_BR.md. |
| MADR | Markdown Any Decision Records: template e convenção em Markdown amplamente usados para escrever ADRs (adr.github.io/madr), construído sobre o conceito de ADR de Michael Nygard (2011). Raiz do formato de ADR deste repositório. Veja também: ADR, UMADR. |
| UMADR | Unified MADR: a constituição de ADRs deste repositório (ADR 0045) — raízes MADR/Nygard mais U = Human-in-the-Loop (curador mantenedor único), date de gênese imutável (histórico Git como trilha de auditoria), enum de status estendido (incl. Quarantined, Obsolete, Superseded) e prosa apenas en_US. Veja também: ADR, MADR. |
| Agile Manifesto | Manifesto Ágil (Manifesto for Agile Software Development, 2001): valores como software em funcionamento, colaboração e responder a mudanças. Pode aparecer em texto de cultura de manutenção; não é recurso do produto. |
| CI/CD | Integração contínua / entrega ou implantação contínua (Continuous Integration / Continuous Delivery or Deployment): pipelines automáticos de build, teste e deploy; relevante para disciplina de release e checagens de supply chain. |
| container (contêiner) | Imagem empacotada e executável (em geral compatível com OCI—ex.: imagem Docker gerada pelo Dockerfile do repositório, publicada como fabioleitao/data_boar no Docker Hub) que inclui a aplicação e o runtime. Monte o arquivo de config no caminho documentado (ex.: /data/config.yaml) e use a mesma config YAML/JSON que em instalação “bare metal”. Veja DEPLOY.pt_BR.md, USAGE.pt_BR.md (início rápido com Docker). |
| CVE | Common Vulnerabilities and Exposures: identificadores públicos de vulnerabilidades conhecidas em componentes de software. Atualizações de dependência e varreduras no CI (ex.: alertas do GitHub Dependabot) referenciam CVEs; o SECURITY.pt_BR.md e o fluxo chore(deps) tratam isso como insumo para triagem de risco—não é recurso do produto. Veja também: SBOM; SECURITY.pt_BR.md. |
| defense in depth (defesa em profundidade) | Controles em camadas: pressupor que qualquer camada pode falhar; combinar rede, identidade, aplicação e monitoramento para que falhas não virem exposição total. Alinha com secure by design e Zero Trust; não é recurso do produto—operador define arquitetura na implantação. |
| DevSecOps | Práticas que integram segurança ao desenvolvimento e à operação (pipeline, dependências, segredo). Notas de alinhamento não invasivas: OBSERVABILITY_SRE.pt_BR.md. |
| external connectivity evaluation (avaliação de conectividade externa) | Playbook de laboratório do mantenedor (LAB_EXTERNAL_CONNECTIVITY_EVAL.pt_BR.md): exercitar conectores REST e banco de dados contra APIs HTTP públicas, bases somente leitura de terceiros quando o ToS permitir e alvos de falha intencional — complementa LAB_SMOKE_MULTI_HOST.pt_BR.md e o CI; não substitui release nem HOMELAB_VALIDATION sozinho. Token de sessão external-eval. ADR 0028. |
| least privilege (privilégio mínimo) | Conceder só o mínimo de acesso, escopo e duração necessários ao papel, conta ou processo (humanos e serviços). Complementa Zero Trust e RBAC; veja SECURITY.pt_BR.md e escolhas de implantação (api.require_api_key, proxy reverso). |
| pipeline | Em entrega de software, um pipeline automatizado é a cadeia ordenada de etapas (lint, teste, build, varreduras de segurança, publicação) executada no CI/CD—por exemplo os workflows do GitHub Actions neste repositório (veja .github/workflows/). Em dados, “pipeline” também pode designar fluxo ETL ou de processamento da fonte à saída; se o texto não disser o contrário, a documentação de manutenção usa o termo no sentido de automação em torno do código. |
| privacy by design (privacidade desde a concepção) | Incorporar proteção de dados por padrão no desenho do sistema (medidas técnicas e organizacionais, estilo GDPR art. 25). Relacionado a secure by design; escolhas do Data Boar (achados só com metadados, limites de amostragem) refletem essa postura—não substituem programa de privacidade nem assessoria. GDPR art. 25. |
| SBOM | Software Bill of Materials (lista de materiais de software): inventário legível por máquina dos componentes do software (ex.: CycloneDX). Roadmap: ADR 0003. |
| provenance (proveniência) | Registro verificável de como, onde e a partir de quê um artefato foi construído (sistema de build, commit de origem, insumos) — a evidência que o consumidor confere antes de confiar em um binário. Base das attestations de SLSA. Veja também: SBOM, attestation, SLSA. |
| attestation (atestação) | Declaração assinada e verificável por máquina sobre um artefato (ex.: um predicate in-toto / SLSA) que vincula a provenance ou um SBOM a um digest de assunto. Veja também: Sigstore, provenance. |
| SLSA | Supply-chain Levels for Software Artifacts (OpenSSF) — framework graduado (níveis L1-L3+) para integridade do pipeline de build e provenance resistente a adulteração. Veja também: provenance, SBOM, CVE. |
| in-toto | Framework CNCF para integridade ponta a ponta da supply chain: cada etapa do pipeline emite uma attestation assinada, verificada contra um layout declarado. Veja também: attestation, SLSA. |
| Sigstore | Assinatura de artefatos / attestations sem chave persistente, com log público de transparência (cosign, Fulcio, Rekor); combina com provenance e SBOM para supply chains verificáveis. Veja também: attestation, SBOM. |
| SAST | Static Application Security Testing (teste estático de segurança de aplicação): análise do código-fonte (e às vezes bytecode) sem executar o app inteiro—ex.: CodeQL, Semgrep, Bandit no CI. Complementa revisão manual e testes dinâmicos; não garante ausência de falhas. O repositório roda ferramentas selecionadas nos pipelines; veja SECURITY.pt_BR.md e .github/workflows/. Veja também: CVE, shift-left security. |
| Bandit | Linter SAST de Python para problemas comuns de segurança (subprocess, eval, criptografia fraca). O gate estrito de CI do Data Boar roda bandit -r . -c pyproject.toml -ll -ii (severidade e confiança MEDIUM+). Veja também: SAST, CI/CD. |
| CodeQL | Motor de análise semântica de código do GitHub: consulta o código como banco de dados para achar padrões de segurança. O workflow avançado deste repositório é .github/workflows/codeql.yml (push / PR / semanal). O default setup do GitHub (dynamic/github-code-scanning/codeql) não pode rodar ao mesmo tempo — o GitHub recusa o SARIF avançado com o default setup ligado. Veja também: SAST, Semgrep; TESTING.pt_BR.md. |
| Semgrep | SAST rápido baseado em padrões, multilíngua. O Data Boar roda o conjunto OSS p/python na CI. Veja também: SAST, CodeQL. |
| zizmor | Linter de segurança para workflows do GitHub Actions (escopo de token, injeção de script, actions sem pin). O job de CI falha por padrão (issue #732; opt-out: variável ZIZMOR_ENFORCE=false). Não é check obrigatório de merge. Roda em todo push/PR (sem filtro de path). Etapa local opcional de pre-commit via scripts/workflow-security-lint. Veja também: SAST, CI/CD, least privilege. |
| Gitleaks | Ferramenta de varredura de segredos que sinaliza credenciais e chaves commitadas na árvore de trabalho e no histórico Git. Roda como gate de CI dedicado. Veja também: SAST, CI/CD. |
| SonarQube / SonarCloud | Plataforma contínua de qualidade de código e hotspots de segurança; gate de CI condicionado a token, acompanhando manutenibilidade, confiabilidade e achados de segurança. Veja também: SAST, CI/CD. |
| pip-audit | Audita dependências Python instaladas contra avisos de vulnerabilidade conhecidos (CVE / PyPI); o gate de auditoria de dependências na CI. Veja também: CVE, SBOM. |
| Ruff | Linter e formatador de Python rápido; o gate de estilo/lint no pre-commit e no job Lint da CI (ruff, ruff format). Veja também: CI/CD. |
| Syft | Gerador de SBOM (Anchore) que inventaria uma imagem construída em JSON CycloneDX; complementa o SBOM baseado no lockfile. Veja também: SBOM, provenance. |
| DAST | Dynamic Application Security Testing: sonda uma aplicação em execução (contraste com SAST sobre o código-fonte). Listado para completude — o pipeline do Data Boar hoje enfatiza SAST mais varredura de dependências, segredos e workflows. Veja também: SAST. |
| secure by design (seguro por desenho) | Requisitos e controles de segurança desde a arquitetura, não só após o release. Complementa DevSecOps, shift-left security e defesa em profundidade. Veja SECURITY.pt_BR.md. |
| shift-left security (segurança antecipada no ciclo) | Tratar segurança mais cedo no ciclo (desenho, código, portões no CI) e não só em produção. Sobreposição com DevSecOps; parte disso está no repositório via lint, testes e pre-commit—não é, por si só, certificação de maturidade. |
| SLI / SLO / SLA | Indicador de nível de serviço (SLI — o que medir), objetivo (SLO — meta interna de confiabilidade) e acordo (SLA — compromisso contratual, em geral derivado de SLOs). Explicado em OBSERVABILITY_SRE.pt_BR.md (seção 2 do documento). |
| SRE | Site Reliability Engineering (Engenharia de Confiabilidade de Sites): disciplina para operar software em produção com confiabilidade (orçamentos de erro, SLOs, runbooks). Alinhamento discutido em OBSERVABILITY_SRE.pt_BR.md. |
| TAMPERED (adulterado) | Estado de integridade ativado quando módulos críticos de comportamento (a allowlist com hash em core/integrity_anchor.py — main.py, core/detector.py, core/engine.py, core/licensing/guard.py, api/routes.py) divergem da integrity anchor SQLite validada na reverificação de inicialização, ou quando a política de build digest / manifesto de release falha. Em licensing.mode: enforced o runtime falha fechado (fail-closed): o tier efetivo é limitado a Community e recursos Pro/Enterprise são negados; em modo open registra CRITICAL e continua. Dispara o rótulo de confiança -alpha. Evidência de adulteração, não prova de adulteração (tamper-evident, not tamper-proof). Veja também: TINTED / -alpha, Safe-Hold; ADR 0066, INTEGRITY_CHECK_ALPHA_LOGIC.pt_BR.md. |
TINTED / -alpha (confiança degradada) |
Nível de confiança degradado (trust_level=adulterated) que o runtime aplica a si mesmo quando a integrity anchor detecta o estado TAMPERED: toda superfície visível ao usuário (aba Info do report, rodapé do dashboard, GET /about, GET /status, /health, logs de inicialização) exibe o sufixo -alpha — "development / not CI-validated" (desenvolvimento / não validado por CI) — e nunca se passa por um release estável. Veja também: TAMPERED, Safe-Hold; INTEGRITY_CHECK_ALPHA_LOGIC.pt_BR.md, ADR 0066. |
| toil (toil / trabalho operacional repetitivo) | Na prática de SRE (definição comum estilo Google): trabalho operacional manual, repetitivo e automatizável que tende a crescer com o parque — fila de chamados, copiar/colar, scripts ad hoc e “arqueologia em planilha” que não gera desenho durável. Equipes saudáveis reduzem toil em favor de automação e ferramentas de produto. O Data Boar ataca toil de governança de dados para empresas e equipes de entrega: descoberta via conectores, amostragem, achados estruturados, relatório Excel e heatmap em vez de greps intermináveis e inventário só manual — ainda assim humanos seguem donos de normas, limites de amostragem e risco de falso negativo. Veja também: SRE, sessão, report, compliance toil. |
| stale data (compliance context) (dado desatualizado) | Resultados de scan ou evidência de conformidade tratados como atuais quando só refletem um estado pontual que já não bate com o ambiente. Falha comum de war room: decidir sobre um scan de meses. O Data Boar mitiga com delta de sessão (findings_count novo vs. resolvido) e findings sink opcional (GitHub #552). Distinto de toil (processo) — stale data é problema de qualidade da informação. Em docs informais de lab: dado stale; em conformidade formal, preferir dado desatualizado. |
| war room | Contexto de resposta a incidente em que times convergem para conter e investigar. Falha comum: não haver baseline confiável da exposição de dados sensíveis antes do evento. O Audit Trail e o manifest por sessão existem para responder: "qual era o estado antes disso?" |
| Zero Trust (confiança zero) | Modelo de segurança: não presumir confiança só pelo lugar na rede; verificar de forma explícita (identidade, dispositivo, privilégio mínimo, validação contínua). Referência comum: NIST SP 800-207. TLS, chaves de API e segmentação são escolhas do operador—o produto não implementa arquitetura ZT completa sozinho. NIST SP 800-207. |
| Termo | Definição |
|---|---|
| CDN (rede de distribuição de conteúdo) | Content Delivery Network: rede periférica geograficamente distribuída que faz cache de conteúdo estático e atende tráfego perto dos usuários—em geral junto de TLS, absorção de DDoS em escala e entrega mais rápida de scripts e recursos. O Data Boar não é uma CDN; colocar um painel público atrás de CDN → WAF → proxy reverso é decisão de arquitetura do operador, não recurso do produto. Veja também: DoS / DDoS, WAF; DEPLOY.pt_BR.md, SECURITY.pt_BR.md. |
| CSP (política de segurança de conteúdo) | Content Security Policy: cabeçalho HTTP (Content-Security-Policy) que diz ao navegador de onde podem vir scripts, estilos e conexões—reduz XSS e cargas de terceiros inesperadas. O Data Boar define um CSP padrão para o painel; perfis mais rígidos costumam ir no proxy reverso—veja SECURITY.pt_BR.md, USAGE.pt_BR.md (API e segurança). Veja também: HSTS; WAF. |
| connect and read timeouts (timeouts de conexão e leitura) | Configuração **timeouts** (global e por alvo): limites de conexão e leitura (segundos) delimitam quanto o motor espera ao abrir conexões e ler dados em bases, APIs, compartilhamentos etc. Evita que um alvo travado ou muito lento bloqueie a sessão inteira sem fim e limita espera/carga de saída; valores baixos demais geram falha por tempo esgotado em rede ocupada ou em janelas de manutenção. Parâmetros por alvo ajudam quando só uma fonte é lenta. Veja USAGE.pt_BR.md (seção Timeouts para conexões com fontes de dados). |
| DoS / DDoS (negação de serviço / distribuída) | Denial of Service (DoS): padrão de ataque ou abuso que degrada ou bloqueia disponibilidade (CPU, memória, conexões, largura de banda) para prejudicar o uso legítimo. DDoS coordena muitas origens contra um alvo—ameaça clássica em rede e camada de aplicação. Dois ângulos para o Data Boar: (1) Entrada no painel/API—inundação, disparos repetidos de varredura ou corpos de requisição enormes contra o serviço Data Boar. No produto: HTTP 413 para corpo grande demais, **rate_limit** opcional (limita varreduras concorrentes e impõe intervalo mínimo entre inícios; HTTP 429 ao exceder), **api.require_api_key** opcional. Na implantação: proxy reverso, TLS, política de rede—veja SECURITY.pt_BR.md, DEPLOY.pt_BR.md (endurecimento da implantação). (2) Saída do Data Boar para bases, APIs e compartilhamentos do cliente—configuração agressiva pode sobrecarregar esses alvos por engano (“auto-DoS” do target). Mitigação: **rate_limit**, **scan.max_workers** conservador, **timeouts**, ajustes em USAGE.pt_BR.md. O produto não substitui serviço especializado de mitigação de DDoS na borda nem CDN; WAF, anti-DDoS do provedor e firewall ficam com cliente/operador. |
| HSTS | HTTP Strict Transport Security: cabeçalho de política (Strict-Transport-Security) que manda o navegador usar só HTTPS para o host por um tempo. Faz sentido quando o app ou o proxy reverso serve TLS e os cabeçalhos forwarded refletem o esquema do cliente—veja TECH_GUIDE.pt_BR.md. Veja também: TLS / HTTPS; SECURITY.pt_BR.md. |
| JSON | JavaScript Object Notation: formato de texto para dados estruturados (objetos, vetores, strings, números, booleanos, null). O Data Boar usa JSON nas respostas da API (GET /health, /status, /about/json), em corpos opcionais de **POST /scan**, na saída de **--export-audit-trail** e pode carregar **config.json** legado (normalizado para o mesmo formato da config em YAML). Para editar config à mão, em geral prefira YAML—veja YAML. USAGE.pt_BR.md. |
| OAuth2 | OAuth 2.0: framework de autorização. Usado para acesso máquina-a-máquina em alguns targets de API (ex.: client credentials). Não equivale, por si só, a “login social” salvo que esteja assim configurado. Veja USAGE.pt_BR.md. |
| OIDC (OpenID Connect) | OpenID Connect (OIDC): camada de identidade sobre o OAuth 2.0 — forma padronizada de obter tokens de ID (em geral JWT) e userinfo para login no navegador ou em app nativo. Diferente de fluxos só com OAuth2 client credentials para acesso serviço a serviço em targets de API. Na implantação, proxy reverso ou IdP pode terminar OIDC para acesso humano ao painel — isso é integração do operador, não o mesmo papel da autenticação de target do varredor. Veja também: JWT (outro uso: seção 11, rascunho de licenciamento). |
| OpenAPI | Especificação OpenAPI (antes Swagger): descrição legível por máquina das rotas REST, parâmetros e respostas. O Data Boar expõe documentação interativa (ex.: /docs) gerada a partir do schema OpenAPI—útil para integradores e testes de contrato; veja USAGE.pt_BR.md, TESTING.pt_BR.md. |
| RBAC | Controle de acesso baseado em papéis: autorização em que o acesso a rotas ou recursos depende do papel ou grupo do usuário. O dashboard HTML do Data Boar hoje depende da implantação (rede, proxy reverso, chave de API global opcional em api.require_api_key); RBAC mais fino para relatórios está na issue #86 do GitHub. Mantenedores alinham sequência de entrega no backlog interno (docs/plans/, entrada em README.md). |
rate limiting (rate_limit) (limitação de taxa) |
Limites opcionais na API: máximo de varreduras concorrentes e intervalo mínimo entre novos inícios de varredura. Endpoints que disparam varredura podem responder HTTP 429 ao estourar o limite. Reduz abuso de entrada ao serviço Data Boar e espaça o disparo de trabalho de saída contra sistemas do cliente. Combine com **scan.max_workers** e **timeouts**; em produção, mantenha padrões conservadores. Veja USAGE.pt_BR.md (seção Rate limiting e segurança contra abuso). |
| REST | REST (Representational State Transfer): estilo de API HTTP. O Data Boar pode varrer targets REST com autenticação configurada (Bearer, Basic, OAuth2 client credentials etc.); veja a seção de APIs em USAGE.pt_BR.md. |
| request body size limit (limite de tamanho do corpo) | A API recusa corpos acima de 1 MB em POST relevantes (ex.: config e disparo de varredura) com HTTP 413 Payload Too Large, limitando abuso em camada de aplicação por payloads enormes. Veja SECURITY.pt_BR.md (recomendações a técnicos). |
| reverse proxy (proxy reverso) | Servidor HTTP intermediário (nginx, Traefik, Caddy, load balancer em nuvem, OAuth2 Proxy etc.) à frente da aplicação: em geral termina TLS, encaminha requisições ao Data Boar e pode impor autenticação, WAF, limites extras de taxa e cabeçalhos de resposta. Configure **X-Forwarded-Proto: https** (e cabeçalhos forwarded relacionados) para o comportamento de HTTPS / HSTS bater com o esquema visto pelo cliente—veja TECH_GUIDE.pt_BR.md. Operação básica atrás de NAT, balanceador ou proxy reverso sem mudança de código—veja DEPLOY.pt_BR.md. Veja também: TLS / HTTPS; SECURITY.pt_BR.md. |
scan parallelism (scan.max_workers) (paralelismo de varredura) |
Dentro de uma sessão, quantos alvos são tratados em paralelo (scan.max_workers: 1 = sequencial; maior = I/O concorrente). Valores menores significam menos conexões simultâneas e menos carga concorrente em bases, APIs e servidores de arquivos do cliente—preferível em rede frágil, infra compartilhada ou em manutenção. Combine com amostragem (seção Sessão, alvos, conectores e saídas neste glossário) para ler só parte dos dados por alvo na detecção. Veja USAGE.pt_BR.md (bloco scan na configuração e seção Timeouts e carga). |
| TLS / HTTPS | TLS (Transport Layer Security) criptografa HTTP (HTTPS). O painel/API pode usar certificados PEM (api.https_* ou CLI) ou TLS terminado no proxy reverso; veja USAGE.pt_BR.md e SECURITY.pt_BR.md. |
| WAF (firewall de aplicação web) | Web Application Firewall: filtro que entende HTTP(S), em geral no proxy reverso, balanceador ou borda em nuvem, que inspeciona requisições/respostas e bloqueia ou limita taxa de abusos comuns (ex.: tentativas de injeção, caminhos suspeitos, inundação automatizada) com regras e assinaturas. Complementa mitigações no app (rate_limit, api.require_api_key), mas não as substitui. O Data Boar não traz WAF embutido—configure à frente do serviço quando exposto à Internet. Veja também: CDN, reverse proxy, DoS / DDoS; SECURITY.pt_BR.md, DEPLOY.pt_BR.md. |
| YAML | YAML Ain’t Markup Language: texto estruturado com indentação para configuração. O único arquivo de config do operador no Data Boar é YAML ou JSON (--config, CONFIG_PATH, padrão config.yaml); fragmentos de amostra de conformidade ficam em compliance-samples/ e são fundidos ao config; exemplos de regex override usam .yaml; a rota **/config** do painel edita o mesmo arquivo em YAML. Por que YAML: diffs legíveis e comentários facilitam revisão por DPO/operador; o loader aceita JSON com as mesmas chaves se preferir. USAGE.pt_BR.md, entrada compliance sample (seção 9 deste glossário). |
| Termo | Definição |
|---|---|
| deterministic detection stack (product) (pilha de detecção determinística — produto) | O motor entregue combina regex e padrões nomeados, checagens estruturais opcionais e ML/DL supervisionado (seus termos de treino, random_state fixo) para emitir pontuações repetíveis de sensibilidade e achados com foco em metadados sobre dados já amostrados—não geração em linguagem natural aberta. Sinais avançados de inventário (agregação de quasi-identificadores, detecção de menores, enquadramento de âncora operacional, dicas de jurisdição / tensão) seguem o mesmo contrato auditável (continuam heurísticas para oficinas, não assessoria). Contraste: linha LLM abaixo; narrativa: TECH_GUIDE.pt_BR.md, COMPLIANCE_FRAMEWORKS.pt_BR.md, docs/ops/LLM_AGENT_EDITING_CAUTION.pt_BR.md. Evoluções supervisionadas opcionais ficam em material de plano para mantenedores com o nome de arquivo PLAN_ADDITIONAL_DETECTION_TECHNIQUES_AND_FN_REDUCTION.md (índice de caminhos: README.pt_BR.md Internal and reference / Interno e referência). |
| LLM (Large Language Model / modelo de linguagem de grande porte) | Modelo neural de linguagem em grande escala (em geral transformers) treinado em muito texto para gerar continuações, respostas ou código a partir de um prompt—saída aberta, em geral não determinística, e sujeita a alucinação (texto plausível, mas falso). É outro paradigma do que o ML/DL supervisionado desta seção. O produto não usa LLMs generativos na detecção de sensibilidade. Veja também: deterministic detection stack (product), language model (LM) (§8b), ML / DL, TF-IDF, Random Forest; detalhes em SENSITIVITY_DETECTION.pt_BR.md; história e limites: AI_EVOLUTION_PRIMER.pt_BR.md. |
| ML / DL | No discurso comum, “IA”; aqui é pontuação supervisionada com seus termos e texto amostrado—não geração como em LLM (veja LLM acima). Regex cobre padrões determinísticos (ex. CPF, e-mail). ML usa TF-IDF + Random Forest; DL (opcional) usa embeddings e classificador pequeno com sentence-transformers—veja TF-IDF, Random Forest e SENSITIVITY_DETECTION.pt_BR.md. Saída: confiança (0–100); **random_state fixo**; só pontua evidência já presente no alvo. Falsos positivos/negativos seguem possíveis; ajuste limiares. |
| Random Forest (Random Forest / floresta aleatória) | Método supervisionado em conjunto (ensemble): várias árvores de decisão, cada uma treinada com amostragem com reposição das linhas e subconjunto aleatório de atributos; a predição combina votos (ou média de probabilidades), em geral mais estável que uma árvore só. No ML do produto, um RandomForestClassifier (ex.: scikit-learn) consome vetores TF-IDF a partir dos pares (texto, rótulo) e do texto amostrado de colunas/células; **random_state fixo** mantém a confiança reprodutível. Veja também: TF-IDF, ML / DL; SENSITIVITY_DETECTION.pt_BR.md. |
| TF-IDF | Term Frequency–Inverse Document Frequency: representação clássica de texto que pesa o quanto um termo (palavra ou n-gram) é característico de um documento em relação ao corpus—termos muito frequentes em tudo recebem peso baixo, termos mais distintivos, peso maior. Transforma texto em vetor numérico esparso para ML “clássico”. Aqui alimenta a camada Random Forest junto com os termos de treino de sensibilidade. Veja também: Random Forest, ML / DL; SENSITIVITY_DETECTION.pt_BR.md. |
Âncoras curtas para a narrativa sem hype em AI_EVOLUTION_PRIMER.pt_BR.md (canónico em inglês: AI_EVOLUTION_PRIMER.md). Décadas e “invernos” são rótulos aproximados de ensino, não séries económicas precisas.
| Termo | Definição |
|---|---|
| AI winter (inverno da IA) | Período de menor financiamento e expectativa em torno da IA depois que ciclos de hype prometeram demais; vários ocorreram a partir dos anos 1970. Serve como história, não como prova de que uma técnica “falhou para sempre”. Veja: AI_EVOLUTION_PRIMER.pt_BR.md. |
| deep reinforcement learning (DRL) (aprendizado por reforço profundo) | Aprendizado por reforço em que políticas, funções de valor ou modelos são implementados com redes neurais profundas (ex.: DQN, actor–critic com backbones CNN/MLP). O DL fornece o aproximador de função dentro do ciclo de RL—não é um “quarto paradigma” separado de ML/DL/RL, e sim RL + redes profundas. Acrônimo: em inglês, DRL é o mais usado em artigos e produtos; “RDL” não é rótulo canônico e costuma confundir. Pontos fortes/limites: soma os de RL (desenho de recompensa, exploração, segurança em implantação) com os de DL (dados/compute, falhas pouco transparentes). Veja também: reinforcement learning (RL); AI_EVOLUTION_PRIMER.pt_BR.md. |
| expert system (sistema especialista) | Programas com base de regras e de conhecimento que codificam lógica de domínio (em geral se–então) para tarefas estreitas (configuração, listas de diagnóstico). Pontos fortes: lógica transparente, mais auditável quando as regras estão documentadas. Limites: frágeis fora do domínio modelado; caros de manter. É outro paradigma do chat LLM moderno. Veja: AI_EVOLUTION_PRIMER.pt_BR.md. |
| language model (LM) (modelo de linguagem) | Modelo que atribui probabilidade (ou escores relacionados) a sequências de palavras—de n-grams a LMs neurais. LMs menores alimentaram muitos componentes de PLN pré-transformer (ex.: pipelines de fala). LLM costuma designar a mesma família em escala muito maior e arquitetura transformer. Veja também: LLM (§8); AI_EVOLUTION_PRIMER.pt_BR.md. |
| Lisp machine | Estações de trabalho dos anos 1980 otimizadas para Lisp e P&D em IA; símbolo da onda simbólica / sistemas especialistas. Declinaram com hardware de propósito geral mais barato e ROI em mudança—não são um veredito sobre todo método futuro. Veja: AI_EVOLUTION_PRIMER.pt_BR.md. |
| reinforcement learning (RL) (aprendizado por reforço) | Aprendizado por tentativa e erro com recompensas: a política melhora a partir de interação (jogos, robótica, em alguns stacks re-ranking em recomendação). Pontos fortes: forte quando há simulação ou recompensa clara. Limites: pouco eficiente em amostras, recompensa mal especificada, segurança em implantação open-loop. Quando redes neurais implementam a política ou a cabeça de valor em escala, veja deep reinforcement learning (DRL). Não é o motor de sensibilidade do Data Boar. Veja também: deep reinforcement learning (DRL); AI_EVOLUTION_PRIMER.pt_BR.md. |
| symbolic AI (IA simbólica) | Lógica, busca, regras e representações estruturadas (a “GOFAI” dos primeiros tempos). Pontos fortes: passos interpretáveis, provas em domínios minúsculos. Limites: gargalo de aquisição de conhecimento, fraco em texto não estruturado em escala web. Complementa (em vez de substituir) o ML estatístico em muitos sistemas. Veja: AI_EVOLUTION_PRIMER.pt_BR.md. |
| transformer (arquitetura transformer) | Modelo neural de sequência baseado em autoatenção; base da maioria dos LLMs desde ~2017. Pontos fortes: treino paralelizável, forte encaixe amplo de linguagem (e cruzado com outros modais) quando escalado. Limites: fome de dados/compute, não determinismo na inferência salvo restrições rígidas—não substitui varredura de conformidade centrada em evidência. Veja também: LLM (§8); AI_EVOLUTION_PRIMER.pt_BR.md. |
| Termo | Definição |
|---|---|
| anonymization / pseudonymization (anonimização / pseudonimização) | Pseudonimização: substitui identificadores de modo que, sem chave adicional, não se atribui o dado a uma pessoa (GDPR art. 4(5))—em geral ainda é dado pessoal. Anonimização: irreversível; deixa de ser dado pessoal só se não for razoavelmente possível reidentificar. O produto ajuda a localizar identificadores e quasi-identificadores; não certifica anonimização. GDPR art. 4(5); órgão europeu de referência (EDPB): edpb.europa.eu. |
| anchor jurisdiction (âncora operacional) | Não é escolha de lei no código: é o lar operacional e de política que o time usa para interpretar uma varredura (onde o motor roda, onde ficam os sistemas sob inventário, qual deck de política corporativa vale). Complementa drifted data persona em oficinas multinacionais. Veja JURISDICTION_COLLISION_HANDLING.pt_BR.md (EN), ADR 0038. |
| chain of custody (cadeia de custódia) | Trilha documentada de quem manuseou o artefato, quando (fuso), com qual ferramenta/versão e onde está guardado. Hash de arquivo sozinho não é custódia. O scan_manifest pode entrar nesse pacote; não substitui os arts. 158-A–F do CPP nem um lacre de evidência. Primer: FORENSICS_AND_EVIDENCE_PRIMER.pt_BR.md. |
| compliance sample (amostra de conformidade) | Fragmento YAML em compliance-samples/ fundido ao config: norm_tag, termos, recommendation overrides. Veja COMPLIANCE_FRAMEWORKS.pt_BR.md. |
| compliance toil (toil de conformidade) | Trabalho de compliance manual e repetitivo que não escala — rastreio em planilha, coleta ad hoc de evidência, auditorias pontuais sem delta. Contraste com toil de SRE. O Data Boar reduz com artefatos estruturados, com timestamp e comparáveis por sessão. Veja COMPLIANCE_FRAMEWORKS.pt_BR.md. |
| counsel (assessoria jurídica) | Assessoria jurídica que aplica normas aos fatos do caso. O produto fornece evidência técnica; não substitui advogados. Texto completo do posicionamento: ADR 0025 (inglês, no repositório). |
| data minimization (minimização de dados) | Princípio: tratar só o adequado, pertinente e limitado às finalidades (GDPR art. 5(1)(c); LGPD art. 6º, III). Varreduras mostram onde pode haver excesso ou legado; retenção/exclusão é decisão de negócio e jurídica. GDPR art. 5. |
| drifted data persona (dados em deriva / de passagem) | Rótulo narrativo para linhas que parecem estrangeiras ou multipaís em relação à operação ancorada (ex.: manifesto de tripulante, passaportes, IDs de RH offshore num sistema no país anfitrião). O produto não classifica deriva automaticamente; hints e achados trazem sinais para oficinas com assessoria. Veja JURISDICTION_COLLISION_HANDLING.pt_BR.md, use-cases/README.pt_BR.md (hub de storyboards; inclui logística portuária). |
| DPIA | Data Protection Impact Assessment (estilo GDPR arts. 35–36). No Brasil, processo comparável: RIPD (LGPD art. 38). Saídas informam a análise; o produto não conclui nem “aprova”. GDPR art. 35. |
| DFIR | Digital forensics and incident response — prática combinada de investigar artefatos digitais e conter/restaurar incidentes. O Data Boar é insumo de inventário para DFIR, não uma suíte DFIR. Primer: FORENSICS_AND_EVIDENCE_PRIMER.pt_BR.md. |
| digital evidence (evidência digital) | Artefatos que podem sustentar (ou refutar) uma afirmação técnica em auditoria, IR ou processo. As saídas do produto são achados só com metadados mais manifests de sessão — não laudo pericial oficial. ADR 0025. |
| e-discovery (ESI) | Processo de identificar, preservar, coletar, processar e produzir informação eletronicamente armazenada (ESI) para processos legais. Distinto da terminologia própria de descoberta/scan do Data Boar (Data Sniffing) — termo de processo jurídico, não recurso do produto. ISO/IEC 27050-1:2019. |
| ePHI | electronic Protected Health Information (EUA, HIPAA): informação de saúde identificável em meio eletrônico. Categoria EUA; no Brasil use dado sensível (LGPD art. 5º, II) com assessoria. HHS HIPAA; COMPLIANCE_AND_LEGAL.pt_BR.md. |
| FCPA | Foreign Corrupt Practices Act (EUA): regras federais de anticorrupção (anti-bribery) e de livros contábeis / controles contábeis internos para pessoas cobertas — fiscalização DOJ / SEC. O produto não detecta suborno nem conclui violações; a amostra compliance-sample-us_fcpa_internal_policy_pack.yaml acrescenta léxico de política para inventário. Veja também: COMPLIANCE_AND_LEGAL.pt_BR.md; ADR 0025. |
| forensic volatility (volatilidade forense) | Quão rápido uma fonte de evidência digital pode desaparecer (RAM, logs que rotacionam, contêineres efêmeros). A ordem de coleta deve ser documentada. Campo opcional volatility_class (HIGH/MEDIUM/LOW/STATIC) em itens de plugin de padrão registra isso por fonte — ver ADR 0052, config/plugin_schema.yaml (#687). Primer: FORENSICS_AND_EVIDENCE_PRIMER.pt_BR.md. |
| GRC | Governança, risco e conformidade (Governance, risk, and compliance): termo guarda-chuva para programas que alinham governança organizacional (políticas, supervisão), gestão de risco (identificar, avaliar, tratar) e obrigações regulatórias / de conformidade. O Data Boar apoia evidência técnica no GRC relacionado a dados—inventário, achados, relatórios só com metadados, heatmap—não é plataforma corporativa de GRC nem assessoria jurídica. Veja também: controls, RoPA, DPIA, counsel; COMPLIANCE_AND_LEGAL.pt_BR.md; contrato JSON de matriz de risco executiva GRC_EXECUTIVE_REPORT_SCHEMA.pt_BR.md. |
| Governance Lens | Capacidade Pro / Enterprise que traduz achados técnicos (pattern_name, target_context) para linguagem de controle de governança (ex.: mapear detecção de CPF a COBIT APO13.01 ou LGPD Art. 46 quando rotulado). Gera relatório paralelo ao Excel técnico. Pro cobre em geral COBIT / ISO 27001 / ISO 27014 / ISO 38500 / ITIL 4; Enterprise pode adicionar módulos curados BACEN / FEBRABAN / PCI-DSS. Sequência no PMO do mantenedor (docs/plans/, entrada pelo README.pt_BR.md Interno e referência). Veja ITSM_GOVERNANCE_ALIGNMENT.pt_BR.md. |
| jurisdiction hint (dica de jurisdição) | Texto opcional na Report info quando report.jurisdiction_hints (e/ou opt-in por sessão) pontua metadados com possível relevância a regimes nomeados (hoje: heurísticas US-CA, US-CO, JP no código). Só heurística—alto risco de falso positivo/negativo; não é lei aplicável. Veja também: jurisdiction tension, scent origin; ADR 0026, JURISDICTION_COLLISION_HANDLING.pt_BR.md. |
| jurisdiction tension (tensão / sobreposição de pistas) | Quando duas ou mais dicas de jurisdição disparam na mesma sessão, ou quando norm tags e tokens de caminho “puxam” para regimes diferentes—estresse de inventário, não veredito de software. A organização pode adotar salvaguardas provisórias mais exigentes até a assessoria; o produto não codifica “vale a lei mais restritiva”. ADR 0038. |
| HIPAA | Health Insurance Portability and Accountability Act (EUA): regras sobre PHI/ePHI. Não substitui a LGPD para operações com vínculo ao Brasil. Página oficial: HHS HIPAA; rótulos no produto: COMPLIANCE_FRAMEWORKS.pt_BR.md. |
| integrity hash (hash de integridade) | Impressão digital de tamanho fixo (ex.: SHA-256) gerada a partir de um arquivo ou artefato; qualquer mudança na origem produz um hash diferente, tornando adulteração detectável. Um hash sozinho não substitui chain of custody — é um elemento de um processo mais amplo de rastreabilidade. NIST SP 800-86 §3.1. |
| KYC | Conheça seu cliente (Know Your Customer): identidade e risco (em geral setor financeiro). O produto não verifica identidade nem consulta listas (sanções, PEP etc.); pode localizar onde há PII de cadastro de clientes na sopa de dados. COMPLIANCE_AND_LEGAL.pt_BR.md. |
| metadata-only finding (achado só com metadados) | Achado com onde e qual padrão casou—sem valores pessoais no pacote por padrão. Veja COMPLIANCE_AND_LEGAL.pt_BR.md. |
| PEP | Pessoa politicamente exposta (Politically Exposed Person). O produto não consulta listas; pode localizar PII em arquivos. COMPLIANCE_AND_LEGAL.pt_BR.md. |
| privacy SLA (SLA de privacidade) | Compromissos mensuráveis de nível de serviço nas operações de privacidade: taxa de cobertura do scan, tempo até detectar novo dado sensível, tempo até notificar o DPO, limiar de regressão de falso negativo, SLA de ticket de remediação P0/P1. Veja COMPLIANCE_FRAMEWORKS.pt_BR.md; primer na issue #555. Veja também: SLA (seção ITSM). |
| RIPD | Relatório de Impacto à Proteção de Dados (LGPD art. 38): relatório do controlador quando há risco elevado; a ANPD pode regulamentar detalhes. Finalidade análoga à DPIA europeia; texto jurídico não é idêntico. Evidência técnica para informar o relatório—não protocola nem aprova. ANPD; LGPD art. 38. |
| RoPA | Registro das atividades de tratamento (estilo GDPR art. 30). Inventário técnico alimenta o RoPA; não substitui o registro organizacional. GDPR art. 30. |
| scent origin (origem do faro, metáfora) | Narrativa opcional para dicas de jurisdição: vários sinais geográficos fracos nos metadados funcionam como vários cheiros ao mesmo tempo—útil em oficinas, não é certeza jurídica. Veja JURISDICTION_COLLISION_HANDLING.pt_BR.md; ADR 0038. |
| SCC | Cláusulas contratuais-tipo para transferências internacionais (instrumento UE). Assinatura e adequação ficam fora do produto; varreduras informam quais categorias existem onde. Textos no EUR-Lex (ex.: busca SCC 2021/914). |
| SOE | Empresa estatal ou entidade com participação estatal (State-Owned Enterprise): pessoa jurídica com vínculo governamental; alguns programas de PLD/AML exigem diligência reforçada em relações com SOE — distinto de PEP (pessoas físicas). O produto não classifica status de SOE nem consulta listas; pode localizar PII e artefatos de onboarding na sopa de dados. Veja também: PEP, KYC; COMPLIANCE_AND_LEGAL.pt_BR.md. |
| SOC 2 | Service Organization Control 2 (AICPA): relatório de atestação sobre controles em uma organização prestadora de serviços, em geral alinhado aos Trust Services Criteria (segurança; opcional: disponibilidade, integridade do processamento, confidencialidade, privacidade). Tipo I avalia o desenho dos controles em um instante; Tipo II avalia a eficácia operacional ao longo de um período. O Data Boar não realiza exame SOC 2 nem emite relatório; descoberta e mapeamento de onde há dados pessoais/sensíveis e saídas só com metadados apoiam o desenho de controles e a preparação para auditoria dos sistemas que você colocar no escopo. Veja Normas auditáveis e de gestão (papel de suporte) em COMPLIANCE_FRAMEWORKS.pt_BR.md. |
| SOX | Sarbanes-Oxley Act de 2002 (EUA): controles sobre informação financeira; ITGC e evidência em sistemas que tocam demonstrações. Não é auditoria financeira; o produto mapeia campos sensíveis para evidência de governança. SEC — SOX. |
| subprocessor (suboperador) | Operador contratado por outro operador (GDPR art. 4(17)); cadeia deve estar contratualmente amarrada. LGPD: figura de suboperador na cadeia. O produto não gerencia contratos; mapeia onde há dados para diligência de fornecedores. GDPR art. 4(17). |
| TIA | Transfer Impact Assessment em transferências transfronteiriças (muitas vezes com SCCs). O produto apoia mapeamento de dados; não substitui a conclusão jurídica. Orientações do EDPB: edpb.europa.eu. |
| VBA (value-based agreement) | Em farma, life sciences e contextos de pagadores (em geral EUA), VBA costuma significar value-based agreement ou value-based contract (acordo/contrato baseado em valor): arranjo comercial em que preço, reembolso ou acesso dependem de resultados acordados, utilização ou evidências — não só preço de tabela. Não é recurso do produto: o motor não modela contratos nem calcula métricas de outcome; ainda pode apoiar governança ao mapear onde dados pessoais ou de saúde relacionados aparecem na sopa de dados. Desambiguação: não confunda com VBA = Visual Basic for Applications (macros do Office) — muito comum em TI; verifique o contexto. Veja também: HCP, PHI, Stark Law. |
| vestige (vestígio) | Rastro deixado por um tratamento (linha de log, exportação esquecida, cópia órfã). A descoberta pode mostrar vestígios nos alvos configurados; não reconstrói a linha do tempo completa das ações do usuário. |
| visum et repetum | Cautela clássica da perícia: separar o que foi observado do que se infere, e deixar registro suficiente para outro examinador repetir o olhar. No produto: declarar limites de amostragem, cifra e lacunas de Safe-Hold nos relatórios. |
| Corporate-Entity-C / WRB | Vocabulário interno de manutenção para o parceiro externo de revisão e os ciclos de e-mail WRB (Corporate-Entity-C Review Briefing) — blocos para colar e caminhos estáveis no repositório em Corporate-Entity-C_IN_REPO_BASELINE.md. Não é módulo entregue do produto nem identificador público de API. Veja também: Corporate-Entity-C_REVIEW_REQUEST_GUIDELINE.md. |
| Google Gemini (ferramenta do mantenedor) | Produtos de chat do Google (consumidor/pro) usados fora do motor de sensibilidade para rascunhos delimitados, transcrições longas e revisão de pacotes screenshot-first — mesmo papel de processo que Corporate-Entity-C/WRB (disciplina de evidência, não dependência em tempo de execução das varreduras do cliente). Trate a saída como não verificada até cruzar com a verdade do repositório; não substitui achados determinísticos. Veja também: Corporate-Entity-C / WRB; GEMINI_PUBLIC_BUNDLE_REVIEW.pt_BR.md; LLM_AGENT_EDITING_CAUTION.pt_BR.md; OPERATOR_SESSION_CAPTURE_GUIDE.pt_BR.md. |
Os títulos abaixo seguem a redação ISO/IEC; no Brasil o mesmo conteúdo técnico é adotado como ABNT NBR ISO/IEC … (aquisição via ABNT ou ISO). O Data Boar apoia evidência técnica (inventário, achados só com metadados, categorias na sopa de dados); não certifica, audita nem substitui avaliação por organismo acreditado.
| Termo | Definição |
|---|---|
| ISO/IEC 27001 | Segurança da informação, cibersegurança e proteção da privacidade — Sistemas de gestão de segurança da informação — Requisitos. Base para um SGSI. Certificação e escopo são organizacionais; as varreduras ajudam a mostrar onde há dados pessoais e sensíveis para inventário de ativos/processos e tratamento de risco. Brasil: em geral ABNT NBR ISO/IEC 27001. Detalhes: catálogo ISO. |
| ISO/IEC 27005 | Orientações para o gerenciamento dos riscos de segurança da informação (edições anteriores: Gestão de riscos de segurança da informação). Estrutura atividades para identificar, analisar e tratar risco de segurança da informação (orientação iterativa — não é ferramenta de checklist). Não confundir com ISO/IEC 27701 (extensão de privacidade sobre 27001/27002). Brasil: ABNT NBR ISO/IEC 27005. O Data Boar fornece evidência de descoberta para riscos envolvendo bases de dados pessoais. Detalhes: catálogo ISO. |
| ISO/IEC 27701 | Técnicas de segurança — Extensão das ISO/IEC 27001 e 27002 para gestão de informações de privacidade — Requisitos e diretrizes (PIMS). Controladores e operadores alinham controles de privacidade e regulamentos declarados (ex.: LGPD, GDPR) aos anexos da norma. Brasil: ABNT NBR ISO/IEC 27701. Alinhamento do produto: COMPLIANCE_FRAMEWORKS.pt_BR.md (ISO/IEC 27701). Detalhes: catálogo ISO. |
| PDCA (SGSI) | Ciclo Plan–Do–Check–Act aplicado a um SGSI / ISMS. Definido na ABNT NBR ISO/IEC 27001 (edição ISO atual: ISO/IEC 27001:2022). Não reproduza a tabela normativa na íntegra — cite o catálogo ISO 27001 e o Catálogo ABNT. O Data Boar mapeia Plan → config.yaml (escopo, padrões, limiares); Do → sessão Data Sniffing + Deep Boring; Check → delta de sessão, manifest, Audit Trail; Act → remediação P0/P1, atualização de padrões, Safe-Hold. |
| SGSI | Sistema de Gestão de Segurança da Informação — equivalente a ISMS. Definido na ABNT NBR ISO/IEC 27001. Políticas, processos e controles para gerir risco de segurança da informação. Veja também: PDCA (SGSI), EDM. |
| SoA — Statement of Applicability (Declaração de Aplicabilidade) | Documento da ISO/IEC 27001 que lista quais controles do Anexo A a organização selecionou, com justificativa de inclusões e exclusões. Achados do Data Boar podem informar o mapeamento (ex.: A.8 gestão de ativos, A.5.12 classificação); não completam a SoA. |
| Termo | Definição |
|---|---|
| EDM | Evaluate–Direct–Monitor (Avaliar–Dirigir–Monitorar) — ciclo de governança na ISO/IEC 38500, também usado na ISO/IEC 27014 e no COBIT 2019: o órgão de governança avalia necessidades, dirige políticas e monitora resultados. O Data Boar principalmente operacionaliza Avaliar para dados sensíveis (achados + exposição) e pode alimentar Dirigir (config de escopo) e Monitorar (delta de sessão). Veja também: IT governance, PDCA (SGSI), Governance Lens. |
| governance feedback (retroalimentação de governança) | Fluxo de informação de baixo para cima (execução → estratégia): evidências operacionais que permitem à alta direção ajustar diretrizes. As sessões de descoberta são um mecanismo de retroalimentação da exposição de dados sensíveis — não um motor de workflow GRC. |
| IT governance (governança de TI) | Práticas e estruturas que mantêm valor, risco e responsabilização da TI alinhados à estratégia — distinto da operação cotidiana de TI. Pontos de partida: ISO/IEC 38500, COBIT. |
| ITSM | IT Service Management (gerenciamento de serviços de TI): como serviços são planejados, entregues, monitorados e aprimorados. Referências comuns: ITIL 4, ISO/IEC 20000. O Data Boar é insumo dessas práticas, não um service desk. |
| SVS — Service Value System | Modelo ITIL 4 de como os componentes da organização trabalham juntos para facilitar a criação de valor (princípios, governança, cadeia de valor, práticas, melhoria contínua). Visão pública: Axelos — ITIL. Cada sessão Data Boar é um insumo ao SVS — os achados não são artefato terminal. |
| SVC — Service Value Chain | Atividades ITIL 4 (Plan, Improve, Engage, Design & Transition, Obtain/Build, Deliver & Support) que transformam insumos em valor. Saídas do Data Boar (manifest, relatório, delta) alimentam Deliver & Support e Improve. |
| SLA — Service Level Agreement (ANS) | Acordo formal de expectativas mensuráveis de serviço. Em operações de privacidade: cobertura, tempo até detecção, tempo até notificação, taxa de falso negativo, SLA de remediação — inclusive cadência de scans. Contexto ITSM: ITIL / ISO/IEC 20000. Veja também: SLO, toil, privacy SLA. |
| SLO — Service Level Objective | Alvo mensurável dentro de um SLA (ex.: “99% dos achados P0 vinculados a ticket ITSM em 48h”). SLOs são o instrumento operacional; SLAs são o acordo. |
| OLA — Operational Level Agreement (ANO) | Acordo interno entre times que sustentam um SLA externo (ex.: segurança revisa P0 em 4h para o DPO cumprir notificação em 24h). |
| organisational maturity (maturidade organizacional) | Grau em que processos estão definidos, geridos, medidos, controlados e melhorados. O Data Boar fornece evidência para autoavaliação de maturidade (recurso Pro no FEATURE_TIER_MAP); sequência PMO em docs/plans/ via README.pt_BR.md Interno e referência. |
| value co-creation (cocriação de valor) | Princípio ITIL 4: o valor não é entregue unilateralmente; é cocriado com o cliente. Achados são insumos que DPO, segurança e negócio tratam juntos — o scan sozinho não cria conformidade. |
| continual improvement (melhoria contínua) | Prática ITIL 4 e princípio ISO 20000: melhoria sistemática e contínua. No Data Boar, o baseline de uma sessão vira o alvo de comparação da seguinte. |
Rascunhos de política e ganchos técnicos—não substituem assessoria jurídica; veja os documentos linkados.
| Termo | Definição |
|---|---|
| JWT | JSON Web Token: payload compacto e assinado (em geral Authorization: Bearer) com claims (identidade, expiração, escopo). O rascunho de licenciamento comercial pode usar JWT assinados para direitos de assinatura—veja LICENSING_SPEC.md. Não confunda com respostas JSON do painel, salvo se você configurar fluxos OAuth2 / IdP externos. Veja também: subscription level, open core. |
| open core (núcleo aberto) | Padrão de negócio e licenciamento: o núcleo do produto (motor de varredura, painel, conectores de base) permanece código aberto sob licença OSS permissiva ou copyleft (hoje BSD 3-Clause no LICENSE; opções futuras no texto de política), enquanto complementos comerciais ou source-available podem exigir assinatura e token de licença assinado. Visão geral (EN): LICENSING_OPEN_CORE_AND_COMMERCIAL.md; detalhes técnicos: LICENSING_SPEC.md. |
| OSS (software de código aberto) | Software de código aberto: software distribuído sob licença que concede uso, modificação e redistribuição nas condições do texto; licenças aprovadas pela OSI são referência comum para a linha de base do open core. Outro sentido na doc do detector: “OSS Markdown” descreve nomes de arquivo típicos de README/contribuição em projetos públicos ao calibrar sensibilidade em filesystem—veja SENSITIVITY_DETECTION.pt_BR.md. |
| subscription level (nível de assinatura) | Termo informal para o nível comercial ou direito associado a cliente pagante ou parceiro (ex.: trial, parceiro, enterprise—nomes e SKUs a definir). O rascunho de política vincula uso em produção de certos módulos source-available a assinatura válida e JWT de licença assinado; claims futuros podem codificar o tier no token—veja LICENSING_OPEN_CORE_AND_COMMERCIAL.md (tiers futuros), LICENSING_SPEC.md. Veja também: open core. |
Vocabulário de gestão e governança de dados (DAMA-DMBOK 2.ed.; modelo de qualidade ISO/IEC 25012). Público: DPOs, data stewards e líderes de governança que posicionam a saída de descoberta do Data Boar dentro de um programa mais amplo de governança de dados.
| Termo | Definição |
|---|---|
| Dados (data) | Fatos e representações (valores, registros, sinais) que viram informação em contexto—a matéria-prima que o Data Boar descobre e classifica; PII e dados sensíveis são subconjuntos. Base: DAMA-DMBOK. |
| Gestão de dados (data management) | A disciplina DAMA-DMBOK de planejar, controlar e entregar ativos de dados ao longo do ciclo de vida (arquitetura, modelagem, armazenamento, segurança, qualidade, metadados). O Data Boar apoia as funções de segurança e qualidade via descoberta e achados. Veja também: Governança de dados, DMBOK. |
| Governança de dados (data governance) | O exercício de autoridade, direitos de decisão e responsabilização sobre ativos de dados (política, padrões, stewardship)—a camada de "quem decide e responde" no centro da roda do DMBOK, acima da gestão de dados. Veja também: Data Steward, Data Owner. |
| GGD | Termo guarda-chuva em português Gestão e Governança de Dados: o programa combinado que une a execução de gestão de dados à supervisão de governança de dados. |
| Data Steward (curador de dados) | Papel responsável pela qualidade, pelas definições e pelo uso correto de um domínio de dados no dia a dia—as mãos operacionais da governança de dados. Veja também: Data Owner. |
| Data Owner (dono de dados) | Autoridade responsável por um ativo ou domínio de dados (classificação, política de acesso, aceitação de risco); distinto do Data Steward que executa. |
| Data Lineage (linhagem de dados) | Origem e transformações documentadas dos dados conforme fluem entre sistemas (origem -> transformação -> consumo); apoia análise de impacto e auditoria. Distinto da provenance de build de artefatos de software. |
| Data Quality (qualidade de dados) | Adequação dos dados ao uso pretendido, medida por dimensões (acurácia, completude, consistência, tempestividade, validade, unicidade); formalizada na ISO/IEC 25012. Os achados do Data Boar expõem lacunas que afetam qualidade e risco. |
| DMBOK | Data Management Body of Knowledge (DAMA International): o framework de referência que organiza as funções de gestão de dados em torno de um núcleo de governança. Ponto de partida: dama.org. Não é norma ISO de sistema de gestão. |
Veja também: COMPLIANCE_FRAMEWORKS.pt_BR.md (regulamentações e extensibilidade), USAGE.pt_BR.md (config e API), SENSITIVITY_DETECTION.pt_BR.md (padrões e ML/DL), TECH_GUIDE.pt_BR.md (pilha determinística vs hype de LLM), AI_EVOLUTION_PRIMER.pt_BR.md (história da IA e famílias de método—sem hype), OBSERVABILITY_SRE.pt_BR.md (/health, /status). Índice completo: README.md · README.pt_BR.md.
Termos usados na camada de orquestração de lab Maestro e no ritual de validação completão. Este vocabulário é voltado ao operador (não ao usuário do produto) e se aplica ao ambiente de homelab utilizado para testes de integração e confiança de release. Referência completa: docs/ops/MAESTRO_ARCHITECTURE_AND_ROADMAP.pt_BR.md.
Hierarquia da metáfora musical (do design do Maestro — sabor narrativo, não taxonomia formal): Maestro (regente) → handler (chefe de seção, chamado informalmente de capo di sezione na metáfora) → Nó do lab (músico) → Persona (instrumento) → lab-completao-host-smoke.sh (a música executada). O termo técnico canônico para scripts Handle-*.ps1 é sempre handler.
| Termo | Definição |
|---|---|
| Audit Trail | No contexto do Maestro: o stream de eventos JSONL e os artefatos de log coletados em docs/private/homelab/reports/ após cada completão — a evidência durável e legível pelo operador de cada apresentação. Corresponde ao Audit Trail canônico do Data Boar (registro imutável de sessão e findings); na orquestração de lab, o trail cobre resultados de smoke-test, métricas de benchmark e telemetria do ambiente do host. |
| bench track | Tag de isolamento (stable ou beta) aplicada a um run de benchmark A/B. Cada track tem seu próprio workdir efêmero no host do lab (/tmp/databoar_bench/<track>/) e uma porta de contêiner dedicada, evitando contaminação cruzada de métricas entre as duas versões sob comparação. Configurado via --bench-track no lab-completao-host-smoke.sh ou -BenchTrack no Maestro.ps1. |
| Capo | Do italiano: capo di sezione (chefe de seção) — usado aqui como metáfora musical para o papel do handler, não como termo de taxonomia formal. Nos docs narrativos, um handler pode ser descrito como Capo para evocar a metáfora da orquestra: cada handler lidera sua seção de instrumento sem que o Maestro precise conhecer detalhes de implementação. O termo técnico canônico é handler. Veja handler, persona. |
| completão | Gíria brasileira para "a obra toda feita direito" / "o negócio completo". Um run de completão exercita todos os nós do lab configurados, em todas as personas declaradas, contra todas as superfícies de alvo disponíveis — o equivalente de lab de um ensaio geral antes do release. Contrastada com CI/pytest (controlado, sintético, hospedado no GitHub) e com o gate do dev PC (check-all). Palavra-chave de sessão: completao. Runbook: LAB_COMPLETAO_RUNBOOK.pt_BR.md. |
| handler | Script PowerShell (handlers/Handle-<persona>.ps1 no clone DataBoar/maestro) que implementa a lógica de orquestração para uma persona. Os handlers são os Capos do sistema Maestro: cada um recebe contexto do Maestro.ps1 (nó, ref, flags de benchmark) e é totalmente responsável pela performance da sua seção. Handlers existentes: baremetal, docker, dockerswarm, podman, microk8s, lxd, web, target_postgres, target_mariadb, target_mongodb, target_nfs, target_sshfs, target_cifs. Roadmap: target_oracle, loadtest. |
| inventário | O manifesto JSON privado (docs/private/homelab/data/inventory.json) que mapeia cada nó do lab para suas credenciais SSH, caminho do repo e personas declaradas. Esta é a partitura que o Maestro lê antes de despachar. Nunca rastreado no Git público (PII: hostnames reais, IPs, contas de usuário). |
| lab-op | O ambiente de homelab utilizado para testes de integração do Data Boar — um conjunto de hosts Linux (bare-metal e VMs) acessíveis via SSH do dev PC Windows do operador. Distinto do CI (runners hospedados no GitHub) e dos ambientes de deploy de cliente. |
| Maestro | O orquestrador central, orientado por inventário (core/Maestro.ps1 em DataBoar/maestro; wrappers do consumidor resolvem via MAESTRO_ROOT ou sibling ../maestro). Como um regente de orquestra, o Maestro tem a visão geral: lê o inventário (a partitura), verifica quais nós estão acessíveis, constrói e distribui artefatos, despacha cada Capo em sequência e coleta evidências. Não sabe como Docker ou PostgreSQL funcionam — esse é o domínio do Capo. |
| persona | O papel de capacidade declarado de um nó do lab, listado no inventário. Um único nó pode ter múltiplas personas (ex.: ["docker", "web", "target_postgres"]). Personas são os instrumentos na metáfora: definem o que o nó toca, não quem o nó é. O Maestro despacha o handler correspondente para cada persona em ordem (personas de contêiner primeiro, web por último). |
| Safe-Hold | No contexto do Maestro: o comportamento de interromper a orquestração e reportar claramente quando um pré-requisito necessário está ausente — ex.: arquivo de inventário não encontrado (saída hard com exit 1), SSH INATIVO num nó (pular com aviso). Corresponde ao Safe-Hold canônico do Data Boar (scan suspenso por evidência ausente ou insuficiente). |
| sentinel file | Sinal de conclusão escrito pelo lab-completao-host-smoke.sh ao final de um run bem-sucedido (.completao_done_$RUN_ID). A fase -Collect verifica esse arquivo para sincronizar a coleta de artefatos com a execução assíncrona no tmux. Previne a race condition onde -Collect roda antes do smoke terminar de escrever as métricas. Ver PLAN_MAESTRO_BENCHMARK_METRICS_AND_FIX.md Slice 2. |