← CCNP Security: núcleo SCOR e operação
18 / 25 · 55 MIN

DLP e guardrails: âmbito e aceitação

Constrói um plano de validação com tráfego sensível e benigno, exceções e métricas interpretáveis.

1. Desenhar a matriz de cobertura

Numa equipa fictícia de operações de fundos, pretende-se usar um assistente para preparar resumos técnicos sem enviar dados de clientes. Começa por identidade, aplicação de destino, sentido do tráfego, tipo de ficheiro e classificação. Para AI guardrails em Secure Access, verifica inspeção HTTPS aplicável à mesma identidade e os workflows suportados. A inspeção configurada para outra equipa não demonstra cobertura desta. Usa apenas dados sintéticos nos ensaios: um número com formato reconhecível pode ser suficiente, sem copiar registos de produção. A ficha anexa é um plano por executar num tenant autorizado; não apresenta resultados reais de uma plataforma Cisco nem procedimentos internos de qualquer banco.

2. Separar correspondência, ação e resultado

Um evento de classificação diz que houve uma correspondência observada. Para concluir prevenção, confirma a ação Block aplicável e o resultado do envio no fluxo suportado. Monitor permite observar sem oferecer a mesma conclusão de bloqueio. A severidade atribuída ajuda na priorização, mas não substitui a ação. Uma notificação também não prova que o destino deixou de receber os dados. Na revisão de política, inspeciona inclusões e exclusões da regra; uma identidade excluída não deve ser contada como protegida por essa mesma regra. Isto não permite concluir que todas as outras políticas a deixam passar. Regista cada camada e evita extrapolar uma decisão local para o serviço inteiro.

3. Exercitar fronteiras e exceções

Planeia pares de ensaios: prompt sensível e prompt benigno, identidade incluída e excluída, interface web e outra integração utilizada pelo negócio. Confirma suporte antes de atribuir a mesma proteção à API de uma aplicação. Se a regra se destina apenas a respostas, não a contes como proteção dos prompts. Na classificação de ficheiros, distingue nomes técnicos de labels de texto de apresentação e inclui documentos sem label; ausência de label não significa informação pública. O limite documentado de inspeção de conteúdo deixa de fora texto além dos primeiros 50 MB. Um filtro de tamanho mais amplo não demonstra inspeção integral. Mantém esses casos na matriz e define tratamento alternativo para o risco residual.

4. Interpretar qualidade sem esconder falhas

A ficha inventa cem casos classificados manualmente: vinte sensíveis e oitenta benignos. O mecanismo hipotético deteta dezoito sensíveis, falha dois e assinala quatro benignos. Recall é 18/20, ou 90%; precision é 18/22, cerca de 81,8%; falsos positivos são 4/80, ou 5% dos benignos. Accuracy é 94/100, mas esse número oculta duas perdas de dados possíveis. Não são resultados medidos da Cisco. Investiga o tipo e gravidade dos casos falhados antes de aceitar a mudança. Repete positivos e negativos após afinar identificadores ou limiares. Uma exceção precisa de motivo, âmbito, responsável, prazo e controlo compensatório, com revisão posterior em vez de exclusão indefinida.

5. Entregar operação e limites de proteção

Distingue proteção em linha de análise de ficheiros armazenados por API SaaS. Iniciar um discovery scan não significa que todos os ficheiros ficaram inspecionados; permissões, âmbito, filas, formatos e limites do serviço influenciam o resultado. No handover, entrega o inventário de destinos suportados, matriz de ensaios executados, métricas por classe, exceções e responsável por triagem. Um classificador de conteúdo sensível não garante que a resposta de um LLM é verdadeira nem resolve todas as formas de prompt injection. Para o resumo técnico, conserva revisão humana e restringe ferramentas e dados segundo o caso de uso. Resumo: a aceitação exige cobertura demonstrada, efeito observado e risco residual assumido pelo responsável adequado.

NA PRÁTICA

18 deteções corretas, 2 falhas e 4 falsos alertas: recall 90%, precision 81,8%. São valores fictícios para interpretar, não um benchmark.

Armadilhas comuns

Monitor como bloqueio; evento como prevenção; ausência de label como público; accuracy isolada; descoberta iniciada como cobertura completa.

Tópicos relacionados: SSE e inspeção HTTPS · Classificação de dados · Risco de IA

Leva esta ideia contigo

DLP deve ser aceite pelo fluxo e resultado demonstrados, com limitações e exceções explícitas.

Criar conta

Referência: Add an AI Guardrails Rule to the Data Loss Prevention Policy · 350-701 SCOR v2.0, effective 2026-08-27; core component of CCNP Security

CCNP® e Cisco® são marcas registadas da Cisco Systems, Inc. e/ou das suas afiliadas. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por Cisco. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.