Segurança e privacidade desde o desenho

Começar por aquilo que precisa de proteção

Um ativo é algo cujo valor precisamos preservar: código, credenciais, disponibilidade ou dados. Uma ameaça descreve um evento capaz de causar dano. Uma fronteira de confiança separa regiões com permissões ou garantias diferentes. Na Oficina Caracol, o navegador de quem visita o catálogo está fora da confiança do servidor. Um valor enviado pelo navegador continua sendo uma entrada a validar, mesmo que a interface oficial costume enviar valores corretos.

O projeto utiliza dados de exemplo e não exige cadastro. Essa escolha reduz a coleta, mas ainda precisamos pensar em arquivos de configuração, mensagens de erro e registros operacionais. Privacidade pergunta por que coletar um dado, quem pode acessá-lo e por quanto tempo conservá-lo. O SSDF orienta a incorporação de práticas seguras ao desenvolvimento; o ASVS organiza requisitos verificáveis para aplicações [S03, práticas PO.1 e PO.4; S05, visão geral sobre requisitos verificáveis de segurança web]. Nenhum desses referenciais certifica automaticamente o método.

Modelo de ameaça preenchido

Transformar ameaça em trabalho verificável

• Desenhe o caminho da entrada até o efeito e identifique onde a confiança muda. Inclua caminhos de erro e configuração.
• Para cada ameaça pertinente, defina consequência, controle e teste. Validação verifica o contrato da entrada; autorização decide se a ação é permitida. Uma não substitui a outra.
• Decida quais dados são indispensáveis. Registre finalidade, acesso, retenção e descarte dos registros operacionais antes de habilitá-los.
• Teste os controles com dados artificiais. Registre também o que o teste não consegue demonstrar e quais ameaças permanecem.
• Submeta o risco residual, isto é, o risco que sobra após os controles, à autoridade responsável pela liberação. Resultado desconhecido exige investigação, não aceitação automática.

O que fazer quando um segredo aparece

Suponha que uma credencial fictícia de integração tenha sido incluída em um commit do exercício. Na situação real correspondente, apagar a linha do arquivo atual não impede o uso de uma credencial que já tenha sido copiada. A resposta começa por identificar o serviço, o alcance e a exposição. A credencial exposta deve ser revogada ou rotacionada conforme o serviço. Em seguida, investigam-se acessos pertinentes e corrige-se o fluxo para evitar reincidência [S13, seção sobre exposição de credenciais e remoção de dados sensíveis].

A limpeza do histórico, quando necessária, exige coordenação: cópias, referências e clones podem continuar contendo o valor. Não se publica o segredo em um relatório de incidente para provar que ele existiu. A evidência usa identificadores seguros, horários, alcance e confirmação da revogação. Para treinar, o aluno escreve o roteiro com um marcador artificial; não cria uma credencial real para provocar um vazamento.

Erros e condição de avanço

Sanitizar tudo com uma função genérica mistura problemas distintos. O reparo depende do contexto: validar formato na entrada, tratar a saída conforme o local de uso e aplicar autorização quando houver uma ação protegida. Registrar todo o conteúdo recebido também pode transformar o log em nova exposição. Reduza os campos ao necessário e defina quem consegue consultá-los.

O gate de segurança exige controles pertinentes implementados, resultados avaliados e aceitáveis, e riscos residuais não impeditivos explicitamente aceitos por autoridade identificada. A simples existência de ameaça, controle e teste numa planilha não satisfaz essa condição. Uma exposição de credencial ativa sem contenção continua impeditiva para o cenário afetado.

Exercício e solução comentada

Dados do exercício: um log de falha contém horário, nome completo fictício, texto livre enviado pelo visitante e código técnico de erro. O suporte precisa saber a frequência de falhas e correlacionar uma tentativa com o diagnóstico. Escolha os campos a manter e proponha uma verificação.