Capítulo 19 — Privacidade e proteção de dados: monitoramento
Mapa da aula
Aula 19 publicada. Mapa, exemplo, EX055.
flowchart TD
N0["19.1 O que monitorar"]
N1["19.2 Alertas"]
N2["19.3 Tendências"]
N3["19.4 Revisão"]
N0 --> N1 --> N2 --> N3
N3 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX055"]
Desenho lógico
flowchart LR
N0["19.1 O que monitorar"]
N1["19.2 Alertas"]
N2["19.3 Tendências"]
N3["19.4 Revisão"]
N0 --> N1 --> N2 --> N3 --> Q["EX055"]
[19.1 O que monitorar]
|
v
[19.2 Alertas]
|
v
[19.3 Tendências]
|
v
[19.4 Revisão]
|
v
[Exemplo resolvido] --> [Exercício EX055]
Objetivos de aprendizagem
Você vai (1) monitorar os controles de privacidade; (2) definir alertas; (3) analisar tendências.
19.1 O que monitorar
Aisha monitora a retenção do CFTV em todas as unidades, as mudanças de SDKs em cada versão do aplicativo, os prazos dos pedidos de acesso e as contas de ex-funcionários. Escolhe esses quatro sinais porque cada um já falhou uma vez ou tende a se desviar: a exclusão do CFTV falhou depois de uma atualização de firmware, os SDKs chegam com as versões, os prazos dos pedidos são obrigações legais e a rotatividade da equipe é alta. Ela evita monitorar tudo, porque um pequeno conjunto de sinais significativos, que cabe numa página, é mais fácil de usar do que um grande painel que ninguém lê.
19.2 Alertas
Aisha define os alertas: imagens com mais de trinta e cinco dias, qualquer SDK novo, pedidos a cinco dias do prazo e contas não removidas dois dias depois da saída. Os limites têm uma pequena margem, para que variações normais não disparem alertas. Os alertas do CFTV vão para o gerente da unidade e para a TI; os de SDK, para o líder do aplicativo e o encarregado; os de prazo, para a equipe de atendimento aos titulares; os de contas, para o RH e a TI. Cada mensagem de alerta diz o que fazer, e não só o que aconteceu, para que quem a recebe aja sem precisar perguntar.
19.3 Tendências
Depois de três meses, as contas de ex-funcionários caem de quarenta para duas, e todas as unidades cumprem a retenção do CFTV. Todos os pedidos de acesso são respondidos no prazo, embora as buscas nos fornecedores continuem sendo a etapa mais lenta. O alerta do CFTV de uma unidade dispara uma vez depois de outra atualização de firmware, e a correção leva um dia, em vez de seis semanas. As reclamações dos alunos sobre e-mails de marketing também caem a zero no período. Aisha observa que os dados de tendência mostram os controles funcionando, uma evidência mais forte do que a simples existência de uma política.
19.4 Revisão
Aisha revisa os alertas todo mês para eliminar o ruído. No primeiro mês, o alerta de SDK dispara a cada pequena atualização de biblioteca, então ela o muda para disparar só quando uma biblioteca envia dados a um domínio novo, e ele cai de quarenta por mês para dois. Ela registra cada mudança nas regras de alerta com uma justificativa, para que os revisores vejam se o monitoramento foi enfraquecido por conveniência ou melhorado em precisão. O Sr. Reilly observa que o monitoramento impede que as correções falhem em silêncio, como mostrou o problema do firmware do CFTV.
Exemplo resolvido
Aisha monitora quatro controles com alertas, vê as contas esquecidas caírem de quarenta para duas e todas as unidades cumprirem a retenção do CFTV.
Caso sintético. Os resultados são sintéticos.
Erros e limites
Alertas demais fazem as pessoas ignorá-los.
Exercícios
- EX055 — Alerta do CFTV. O que dispara o alerta do CFTV? Rubrica: 3 = imagens com mais de trinta e cinco dias;; 2 = parcialmente correto;; 1 = vago;; 0 = nenhuma.
- EX056 — Tendência das contas. Como mudaram as contas de ex-funcionários? Rubrica: 3 = de quarenta para duas;; 2 = parcialmente correta;; 1 = vago;; 0 = nenhuma.
- EX057 — Finalidade do monitoramento. Por que monitorar controles já corrigidos? Rubrica: 3 = as correções podem falhar em silêncio;; 2 = menciona falha;; 1 = vago;; 0 = nenhuma.
Continue estudando — aula 19 (capítulo 19 de 30)
← Capítulo 18 · Índice das aulas · Capítulo 20 →
Continue para a próxima aula já escrita.