MongoDB Oplog Security

4

Estamos usando um conjunto de réplicas do MongoDB para compartilhar sessões e outros dados (potencialmente confidenciais) em um web farm.

Todos os dados que armazenamos usam índices TTL para expirar documentos após um período de tempo relativamente curto (digamos, uma hora) parcialmente por motivos de segurança.

No entanto, ocorreu-me que mesmo que os dados sejam excluídos de uma coleção do MongoDB, o oplog usado para replicação ainda conterá todos os documentos criados (e depois excluídos); todos os dados que expiraram podem ser facilmente lidos no oplog.

Dependendo do tamanho alocado para o oplog, os dados nele podem ser bastante antigos.

Minha pergunta é: qual é a melhor prática aqui? Existe algo que possamos fazer, além de reduzir severamente o tamanho do oplog, para impedir que dados antigos sejam acessados?

    
por Kazar 22.04.2015 / 12:01

1 resposta

2

Dados confidenciais em registros são iguais aos dados confidenciais em qualquer lugar. Dependendo da criticidade que você desejará -

  • permite apenas que aqueles autorizados o visualizem para ter acesso aos dados (geralmente feito por meio de funções ou associação a grupos).

  • Se os dados contiverem informações relacionadas a problemas externos ou regulamentados (PCI, HIPAA, etc.), você deve tratá-los adequadamente e fazer a dança de conformidade

  • ative o registro e o monitoramento (na rede e no host) para 11 (ou o que for apropriado)

  • esp. log e auditoria de acesso a dados e tentativas

  • mantenha os logs apenas pelo tempo necessário

  • criptografar quando não estiver sendo usado ativamente, se possível

  • não o mantenha disperso, consolide e defenda

  • se chegar a um certo nível de preocupação, você pode proteger o servidor mongodb e tratá-lo como um sistema crítico (hack de segurança: se você lida com PCI ou outros tipos de dados relacionados à conformidade, pode fingir que tem dados e ops tratá-lo com os mesmos padrões / políticas / etc você aplicar a eles, em vez de descobrir uma nova maneira de lidar com tudo isso)

No caso do mongo, você pode -

  • envie-o (criptografado!) para um servidor de log central, idealmente marcado como sensível ou com um nível de gravidade mais alto

  • ou não armazena os logs localmente, ou, se necessário para depuração / o que quer que seja, os rotaciona para o esquecimento (por exemplo, jogue-os fora) após o menor tempo possível (um dia, semana, 30 dias)

  • se eles existirem localmente, certifique-se de que eles sejam de propriedade do usuário root / priv e do modo 0400 (ou o que quer que funcione para o seu SO)

  • se você for realmente paranóico, pode usar algo parecido com auditd (8) para ver quando alguém tenta acessar os logs (e novamente, enviando os logs auditd para o servidor de log central!)

  • se você é realmente paranóico, você vai querer usar armazenamento criptografado onde quer que os logs sejam mantidos, para que eles não possam ser apagados da remoção do disco

  • alguns dados podem exigir armazenamento de longo prazo por motivos de conformidade, portanto, certifique-se de não eliminar nada prematuramente

  • o acesso ao servidor de log central deve ter as mesmas restrições do servidor local, porque ... data

Nada realmente empolgante, mesmo ol ', mesmo ol', apenas não perca nada, pregue tudo, limite o acesso e monitore tudo que se move.

    
por 26.11.2015 / 16:43