Estou prestes a escrever as diretrizes da empresa sobre o que nunca deve aparecer nos logs (rastreamento de um aplicativo). De fato, alguns desenvolvedores tentam incluir o máximo de informações possível no rastreamento, tornando arriscado armazenar esses logs e extremamente perigoso enviá-los , especialmente quando o cliente não sabe que essas informações estão armazenadas, porque nunca se importou com isso. e nunca leia a documentação e / ou mensagens de aviso.
Por exemplo, ao lidar com arquivos, alguns desenvolvedores são tentados a rastrear os nomes dos arquivos . Por exemplo, antes de anexar o nome do arquivo a um diretório, se rastrearmos tudo com erro, será fácil perceber, por exemplo, que o nome anexado é muito longo e que o bug no código foi esquecido de verificar o tamanho do arquivo. sequência concatenada. É útil, mas são dados confidenciais e nunca devem aparecer nos logs .
Do mesmo jeito:
- Senhas ,
- Endereços IP e informações de rede (endereço MAC, nome do host etc.) ¹,
- Acessos ao banco de dados,
- Entrada direta do usuário e dados corporativos armazenados
nunca deve aparecer no rastreio.
Então, que outros tipos de informações devem ser banidos dos logs? Existem diretrizes já escritas que eu possa usar?
Vious Obviamente, não estou falando de coisas como logs do IIS ou Apache. O que estou falando é o tipo de informação que é coletada com a única intenção de depurar o aplicativo em si, não para rastrear a atividade de entidades não confiáveis.
Edit: Obrigado por suas respostas e seus comentários. Como minha pergunta não é muito precisa, tentarei responder às perguntas feitas nos comentários:
- O que estou fazendo com os logs?
Os logs do aplicativo podem ser armazenados na memória, o que significa tanto em disco rígido no host local, em um banco de dados, novamente em disco ou em Eventos do Windows. Em todos os casos, a preocupação é que essas fontes não sejam suficientemente seguras. Por exemplo, quando um cliente executa um aplicativo e esse aplicativo armazena logs em um arquivo de texto sem formatação no diretório temporário, qualquer pessoa que tenha acesso físico ao PC pode ler esses logs.
Os logs do aplicativo também podem ser enviados pela internet. Por exemplo, se um cliente tiver um problema com um aplicativo, podemos solicitar que ele execute esse aplicativo no modo de rastreamento completo e nos envie o arquivo de log. Além disso, alguns aplicativos podem enviar automaticamente o relatório de falha para nós (e mesmo se houver avisos sobre dados confidenciais, na maioria dos casos, os clientes não os lêem).
- Estou falando de campos específicos?
Não. Estou trabalhando apenas em aplicativos comerciais gerais, portanto, os únicos dados confidenciais são dados comerciais. Não há nada relacionado à saúde ou outros campos cobertos por regulamentos específicos. Mas obrigado por falar sobre isso, eu provavelmente deveria dar uma olhada nesses campos para obter algumas dicas sobre o que posso incluir nas diretrizes.
- Não é mais fácil criptografar os dados?
Não. Isso tornaria cada aplicativo muito mais difícil, especialmente se queremos usar o diagnóstico e o C # TraceSource. Também seria necessário gerenciar autorizações, o que não é o mais fácil de se pensar. Por fim, se estivermos falando sobre os logs enviados a nós por um cliente, precisamos poder ler os logs, mas sem ter acesso a dados confidenciais. Portanto, tecnicamente, é mais fácil nunca incluir informações confidenciais nos logs e nunca se preocupar com como e onde esses logs são armazenados.
debugum nome de arquivo, mas não parainfoum nome de arquivo.