Quais estratégias podem ser empregadas para proteger dados confidenciais em arquivos de log?

O trabalho em ambientes altamente regulamentados é classificado de diferentes maneiras, dependendo da sensibilidade. Em alguns casos, isso é legalmente imposto e deve ser tratado de maneira diferente.

Exemplos de uma política de classificação de dados são:

• Dados altamente restritos , como senhas, chaves privadas, tokens SAML e números de cartão de crédito.
• Dados restritos , como nomes de usuário e IDs de clientes.
• Dados irrestritos , praticamente qualquer outra coisa.

Esta classificação vem com certas obrigações:

• Quaisquer dados altamente restritos nunca devem ser disponibilizados no arquivo de log em nenhuma circunstância.

• Dados restritos podem ser disponibilizados nos arquivos de log sob condições específicas. Por exemplo, se um incidente ocorrer com um serviço, o engenheiro de plantão poderá adotar um procedimento Break-Glass para acessar esses dados e diagnosticar o problema. O procedimento Break-Glass, por sua vez, acionaria uma revisão, uma auditoria e, possivelmente, a revogação temporária de privilégios desse engenheiro.

Quais estratégias podem ser empregadas para alcançar esse objetivo, principalmente considerando que existe uma ampla gama de ferramentas de registro, monitoramento e instrumentação disponíveis no mercado que não fornecem uma resposta direta a esse problema?

Por exemplo, o Splunk e o AppDynamics têm a capacidade de impor diferentes controles de acesso em condições de exposição da telemetria; isso significa que você pode criar um filtro que oculte <customerId>NNNNNNNNNNNN</customerId>. No entanto, nenhuma dessas ferramentas oferece a capacidade de identificar automaticamente números de cartão de crédito e mascará-los automaticamente.

Nota : Acredito que isso esteja relacionado ao DevOps porque, em um modelo tradicional de suporte em camadas, um grupo relativamente pequeno de pessoas pode ter acesso aos dados e filtrá-los manualmente, devolvendo a responsabilidade das plataformas operacionais às equipes de desenvolvimento. Maior audiência.

Eu acho que a solução se resume a um amplo espectro de abordagens que garante a proteção de dados:

• Classificação dos dados : A estratégia técnica mais eficiente é categorizar os dados no ponto de criação rigorosamente. Na essência, os desenvolvedores são responsáveis ​​por garantir que todas as informações registradas sejam atribuídas a uma categoria. A categorização pode, por exemplo, ser obtida através dos Metadados do Splunk , que, por sua vez, podem ser usados ​​para direcionar entradas de log para diferentes buckets com base na categorização dos dados.

• Particionamento de Eventos : Geralmente, existe o desejo de registrar informações confidenciais ao lado de informações não sensíveis. Por exemplo, se um novo usuário se inscrever, você poderá registrar:

  • ID do cliente (restrito)
  • Tipo de cliente (restrito)
  • Fonte de Aquisição (Irrestrita)
  • ID de correlação (irrestrito)

  É possível dividir esse "Evento" em duas partes, uma contendo as informações restritas e outra contendo as informações irrestritas . Isso se alinha ao primeiro ponto, permitindo que as regras de filtragem direcionem para diferentes buckets.

• Mascaramento de dados : em circunstâncias específicas, pode não ser possível categorizar os dados na origem, na minha experiência, as soluções de log permitem que as regras de mascaramento excluam dados confidenciais. No exemplo vinculado, um sedcomando é usado para aplicar uma expressão regular a todos os dados de uma fonte específica. Depois que os dados restritos tiverem sido ocultados, o evento poderá ser considerado irrestrito. É necessário ter cuidado com a regra para garantir que as informações críticas para um evento como um ID de correlação não correspondam à Expressão Regular usada para corresponder a dados confidenciais.

• Filtragem de eventos : como último recurso, pode ser necessário filtrar todos os eventos de um tipo ou fonte específico em um intervalo separado se eles contiverem dados confidenciais que não podem ser categorizados ou mascarados. Nesse caso, as informações em um bucket restrito só poderiam ser acessadas por meio de um mecanismo Break-Glass para ignorar os controles de acesso sob as provisões de um incidente.

Com cada uma dessas soluções, o teste é essencial para garantir que nada deslize pelas fendas. O registro e o gerenciamento de eventos devem ser considerados como um requisito não funcional de primeira classe com o mesmo nível de rigor de desenvolvimento aplicado a uma solução - incluindo revisão por pares e testes para garantir que os dados sejam categorizados e particionados corretamente na ferramenta de sua escolha.

Depende do que você quer dizer com "arquivos de log", eu supunha. Se você quer dizer que os dados de telemetria usados ​​para verificar se o seu sistema está funcionando corretamente, eu diria "Não registrar campos confidenciais". Você não precisa desse tipo de informação para alertá-lo sobre taxas de transação altas ou baixas, tempos de resposta para seus serviços dependentes etc.

Se você quer dizer dados para fins de cobrança ou auditoria, sugiro que você estabeleça um pipeline somente de gravação em que os dados sejam gravados, mas não possam ser lidos pelo gravador. Então, seu pipeline de cobrança e auditoria entra em ação e você tem os controles para auditar quem examinou registros individuais.

No final, a segurança se resume a processos documentados com seus próprios arquivos de log seguros, etc. Em algum momento, você precisa confiar em alguém ou em algum processo, pois todos os dados são gravados para que possam ser lidos posteriormente.