Descoberta, classificação e cobertura de dados | CCSP: segurança cloud, dados e operação

Segue os dados ao longo do serviço

Um serviço fictício de pagamentos mantém uma tabela operacional, logs JSON, anexos de pedidos de suporte e exportações para reconciliação. A tabela tem colunas conhecidas; o JSON pode acrescentar campos sem alterar o esquema central; um anexo pode conter texto, imagem ou conteúdo que exige extração. Começa por um inventário com localização, proprietário, finalidade, formato, acessos e cópias derivadas. Acrescenta backups, caches e destinos de observabilidade conforme o âmbito. O diagrama de rede sozinho não mostra que um identificador entra num campo de diagnóstico ou num ficheiro temporário. No handover, pede ao desenvolvimento exemplos sintéticos de fluxos de sucesso e erro. Um erro pode registar o payload completo quando o percurso normal guarda apenas um identificador.

Separa encontrar um padrão de decidir a classificação

Uma sequência numérica pode ser uma referência pública, um identificador de cliente ou um dado sintético de teste. O detector oferece um sinal; o proprietário aplica a política ao conteúdo e à utilização. A mesma informação pode exigir proteção mesmo sem nomes: posições de fundos ainda não publicadas podem ter valor comercial. Documenta critérios, responsável, data e mecanismo de contestação de um rótulo. Se duas fontes têm classificações diferentes, analisa o conjunto resultante e a possibilidade de ligação antes de baixar a proteção. Uma tag só altera acesso quando um controlo a interpreta. Testa a ligação entre rótulo e autorização com uma identidade permitida e uma recusada; não aceites o aspeto do catálogo como prova de enforcement.

Mede cobertura antes de interpretar ausência de resultados

A ficha contém quatro recursos: a tabela foi amostrada, os logs devolveram permission denied, os anexos ficaram fora do âmbito e a exportação aguarda proprietário. Zero findings nos logs não significa zero dados sensíveis, porque a leitura falhou. Regista recursos previstos, elegíveis, tentados, lidos e parcialmente processados, além do intervalo temporal e versão da configuração. A documentação Google recomenda começar com âmbito limitado e confirmar permissões; essa estratégia não autoriza declarar todo o inventário inspecionado. Avalia a amostra face a partições antigas, caminhos de erro e formatos raros. Uma extração de texto que ignora imagens também precisa de constar das limitações. Dá prioridade a dados desconhecidos amplamente acessíveis, com responsáveis e prazos para resolver lacunas.

Interpreta uma revisão com denominadores conhecidos

Na população fictícia de 100 registos todos revistos, há 18 positivos verdadeiros, 12 falsos positivos, 6 falsos negativos e 64 negativos verdadeiros. A precisão é 18/30, ou 60%; o recall é 18/24, ou 75%. Rever apenas alertas permite estimar a primeira medida nessa amostra, mas não a segunda sem conhecer os casos que escaparam. Um limiar mais exigente neste exercício dá 15 positivos verdadeiros, 3 falsos positivos, 9 falsos negativos e 73 negativos verdadeiros: precisão de cerca de 83,3% e recall de 62,5%. A redução de ruído tem um custo de cobertura. Estes números são uma ficha de cálculo, não resultados de um scanner cloud. Compara também consequências e tempo de tratamento antes de escolher a regra.

Entrega um plano utilizável por RUN

O entregável inclui inventário, classificação validada pelo responsável, evidência de cobertura, exceções e critérios de repetição. Uma alteração do formato de logs ou um novo destino de exportação deve desencadear revisão adequada. Mantém findings e exemplos sensíveis com acesso restrito; copiar tudo para um ticket amplamente visível cria outro destino a proteger. Define quem reage a uma deteção fora de horas e como preserva evidência sem alargar a exposição. Antes de encerrar o projeto, demonstra um fluxo sintético autorizado, um bloqueio esperado e uma condição de falha do scanner que gera aviso operacional. Resumo: descobrir localiza sinais, classificar decide tratamento, e validar controlos demonstra comportamento. Relaciona esta aula com retenção, IAM, observabilidade e gestão de mudanças.

FICHA FICTÍCIA, SEM EXECUÇÃO DE SCANNER
População totalmente revista: 100
TP=18 FP=12 FN=6 TN=64
Precisão=18/30=60%; recall=18/24=75%
Novo limiar: TP=15 FP=3 FN=9 TN=73
Precisão=15/18=83,33%; recall=15/24=62,5%
Inventário:
- payments-table: estruturado, amostrado
- support-logs: semi-estruturado, permission denied
- case-attachments: não estruturado, fora do âmbito
- archive-export: estruturado, pendente, proprietário por atribuir
Registar: âmbito, formatos, permissões, amostra, data, versão, exceções e responsável.

NA PRÁTICA

Dos 100 registos fictícios: precisão 18/(18+12)=60%; recall 18/(18+6)=75%. Logs sem permissão continuam por inspecionar.

Armadilhas comuns

Confundir zero findings com leitura bem-sucedida; rótulo com controlo; limiar mais alto com cobertura completa; alerta revisto com população completa.

Tópicos relacionados: Retenção, cópias e data lineage · IAM, observabilidade e mudanças

Leva esta ideia contigo

Distingue evidência de deteção, decisão de classificação e cobertura real do inventário.

Criar conta

Referência: Inspect Google Cloud storage and databases for sensitive data · CCSP examination outline effective 2026-08-01; January2026 V2 PDF