APRENDER. PRATICAR. EVOLUIR.Responsabilidades por serviço e por operação
Ao migrar uma aplicação de fundos para serviços geridos, substitui a frase o fornecedor trata da segurança por uma matriz concreta. Para cada serviço, identifica quem configura identidades, permissões, classificação, opções de cifragem, rede, logs, retenção e recuperação. A abstração pode transferir tarefas da plataforma para o fornecedor, mas não decide automaticamente quem deve ler os dados da organização. No exemplo de armazenamento gerido da AWS, o cliente continua responsável pela classificação e pelas permissões que aplica aos seus ativos. Escolhe ainda um proprietário para verificar a configuração depois de uma mudança. IaC pode tornar a revisão repetível, sem garantir que todas as alterações passam pelo repositório nem que o estado real corresponde ao plano. Compara configuração desejada, configuração observada e exceções autorizadas. Inclui contas de operação e de emergência na análise de acesso e regista como os logs chegam à equipa que responde. Num comité de projeto, uma tarefa só está concluída quando existe responsável, evidência e aceitação para o serviço selecionado. O laboratório deste bloco é local e não provisiona recursos AWS, Azure ou GCP; as decisões cloud são cenários fundamentados na documentação.
Classificação precisa de origem e de consequência
A classificação pública, interna ou confidencial descreve uma decisão sobre os dados; a etiqueta só produz proteção quando os controlos a utilizam. Identifica o responsável pela classificação, a regra aplicada a conjuntos derivados e quem pode alterar o valor. Um agregado pode revelar posições individuais se contiver grupos muito pequenos, mesmo que já não apresente nomes. A aprovação de publicação deve considerar esse risco e não depender apenas da extensão do ficheiro. No laboratório, um catálogo local associa facts a público e positions a confidencial. O cliente não pode acrescentar classification=public para substituir a origem autoritativa. Além disso, um marcador sintético sensível num conjunto público continua a ser bloqueado na saída pública. Esta combinação mostra que etiqueta e inspeção podem complementar-se, sem demonstrar um classificador completo. Para dados desconhecidos, define quarentena, revisão ou proibição conforme a finalidade; não assumes automaticamente a classe menos restritiva. Propaga decisões relevantes para cópias, exportações, índices de pesquisa e dados temporários. Durante a aceitação, verifica tanto a decisão de classificação como a ação no destino e a evidência que permite explicar uma exceção sem revelar o conteúdo confidencial no relatório.
DLP em observação e em bloqueio têm resultados diferentes
Uma política de DLP pode detetar, avisar, permitir uma exceção justificada ou impedir uma operação, conforme capacidades e localização. Antes de ativar bloqueio num serviço crítico, usa dados sintéticos e amostras autorizadas para avaliar falsos positivos, formatos suportados e impacto no negócio. No modo de observação do laboratório, o marcador proibido gera decisão deny no log, mas a transmissão é deliberadamente permitida; o recetor regista mais uma chegada. Ao voltar a enforce, o mesmo conteúdo recebe 403 e a contagem não aumenta. Um painel com alertas não demonstra prevenção. Também é preciso definir o tratamento de dados que não podem ser inspecionados. O exemplo recusa tipos não suportados e corpos declarados como comprimidos, em vez de os considerar limpos. Descobre ainda limites honestos: o padrão SYNTH ACCOUNT 1234, com espaços, passa pelo detetor estreito que só reconhece a forma com hífen. Esta observação negativa é mantida como limitação, não escondida por uma percentagem de sucesso. Para produção, escolhe controlos adequados a cada localização e ensaia codificações, canais alternativos, exceções e disponibilidade antes de afirmar cobertura.
Apagar o nome de um objeto não elimina todas as cópias
Uma equipa descomissiona um exportador e mostra um GET com resposta 404 como prova de eliminação. Num bucket S3 com versionamento ativo, uma eliminação simples sem versionId cria normalmente um marcador de eliminação; versões anteriores podem continuar presentes. O projeto deve inventariar versões, réplicas, backups, caches, cópias de suporte e obrigações de retenção antes de definir o estado final. Distingue deixar de apresentar a versão atual, eliminar uma versão específica e completar o tratamento de todas as cópias abrangidas pelo pedido. Configurações de lifecycle também têm regras distintas para versões atuais e não atuais. Um prazo de expiração não é evidência de que a execução já ocorreu. Define relatórios de inventário, confirmação do serviço e verificação posterior, com exceções justificadas quando uma retenção impede eliminação imediata. Para media físicos, sanitização exige método apropriado e validação segundo o risco; remover um ficheiro local de laboratório não demonstra esse processo. Na passagem a RUN, entrega um procedimento que identifica o objeto e as cópias, responsável, estado, data e prova de conclusão. Não uses a ausência de um resultado na interface como substituto de rastreabilidade do ciclo de vida.
Chaves, dados e remanência têm ciclos relacionados
Uma proposta pretende eliminar uma chave KMS para encerrar um conjunto de dados. Antes da decisão, identifica todos os dados cifrados, cópias da chave, chaves de dados em cache, réplicas e mecanismos externos envolvidos. Na AWS KMS, agendar eliminação de uma chave gerida pelo cliente inicia um período de espera de 7 a 30 dias; não significa destruição imediata. O estado pendente impede novas operações criptográficas com essa chave no serviço, mas aplicações podem conservar chaves de dados em claro obtidas anteriormente. Uma chave de um external key store também depende de material externo que a eliminação do objeto KMS não remove. Para avaliar eliminação criptográfica como sanitização, verifica se dados sensíveis foram guardados em claro anteriormente e se todas as cópias relevantes das chaves podem ser tratadas. Backups e escrow exigem análise própria. No projeto, separa o pedido aprovado, o agendamento, a confirmação final do serviço e a verificação do âmbito abrangido. Uma ação destrutiva mal planeada pode inviabilizar recuperação legítima sem satisfazer o objetivo de eliminação global. Esta aula não executa KMS nem certifica zeroização física; ensina a formular perguntas e evidência antes de aprovar o procedimento.
Integrar controlos e entregar evidência utilizável
Prepara uma ficha de aceitação para o exportador: classe dos dados, destinos permitidos, origem da política, identidade de transporte, capacidade, observabilidade, limites e responsável por operação. Liga cada decisão a uma observação concreta. Nos dois ensaios locais, 33 verificações por execução confirmam ligações TLS reais, recusas de certificados, aplicação da política, diferença entre observar e bloquear, mudança de versão, rollback e falha com o recetor encerrado. Cada execução cria material novo e termina com threads, listeners e chaves temporárias removidos. O relatório conserva hashes e dimensões das mensagens, evitando conteúdo sensível nos registos. Esse cuidado não prova anonimização universal: até metadados podem exigir controlo de acesso e retenção. O ensaio também mostra um padrão não reconhecido pelo detetor e explicita que não existem testes cloud, propagação distribuída, benchmark de carga ou sanitização de disco. Mantém essas lacunas no plano de projeto com responsável e condição de fecho. Antes de passar a produção, a equipa adapta o desenho ao serviço real, valida com utilizadores e operação e ensaia as falhas relevantes. Um laboratório concluído informa a decisão; não substitui a aceitação do ambiente onde o serviço vai funcionar.
# Original local loopback lab; synthetic data only. Requires Python 3 and openssl on PATH.
# Use a NEW directory: existing output directories are refused.
python3 content/labs/securityx-architecture-contracts/run.py --output /tmp/securityx-architecture-fresh-run
# Expected: 33 checks, 5 received synthetic exports; listeners/threads/temporary keys removed.
# No cloud, production DLP, fleet propagation, online revocation or disk sanitization.
Monitor regista deny e permite uma chegada; enforce bloqueia o mesmo marcador e a contagem do recetor não aumenta.
Armadilhas comuns
Confundir alerta com bloqueio, etiqueta com controlo, 404 com eliminação global e agendamento de chave com sanitização concluída.
Tópicos relacionados: Arquitetura e aceitação · Evidência e limites operacionais
Relaciona requisito, origem da decisão, aplicação no percurso e evidência com limites explícitos.
Referência: AWS Shared Responsibility Model · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17