Conteúdo


Segurança e Proteção de Dados do InfoSphere Guardium para MongoDB, Parte 1

Visão geral da solução e recomendações de segurança de dados

Proteja e dê segurança a uma nova geração de bancos de dados

Comments

Conteúdos da série:

Esse conteúdo é a parte # de # na série: Segurança e Proteção de Dados do InfoSphere Guardium para MongoDB, Parte 1

Fique ligado em conteúdos adicionais dessa série.

Esse conteúdo é parte da série:Segurança e Proteção de Dados do InfoSphere Guardium para MongoDB, Parte 1

Fique ligado em conteúdos adicionais dessa série.

Os autores deste artigo, da IBM, da 10gen e da The MongoDB Company colaboraram na certificação do InfoSphere Guardium para o MongoDB. Isso foi um ótimo exercício, já que aprendemos muito sobre os produtos e casos de uso de cada um. Queríamos realmente escrever algo que ajudasse as pessoas familiarizadas com bancos de dados relacionais e com o InfoSphere Guardium a entender melhor por que as organizações estão adotando o MongoDB para certos tipos de aplicativos. Sob o ponto de vista do InfoSphere Guardium, nossa infraestrutura foi estendida para cobrir diversos protocolos de mensagem do MongoDB, mas os administradores e a equipe de segurança de informações seguirão os mesmos procedimentos para ativar o MongoDB para auditoria, relatórios, etc.

Também esperamos ajudar os usuários do MongoDB a entender os recursos do InfoSphere Guardium, para ajudar as suas organizações a atingir os objetivos de auditoria e conformidade, proteger-se contra vazamentos de dados e ajudar a descobrir atividades de risco, como o uso de JavaScript no lado do servidor.

Atingir os objetivos foi interessante, mas também exigiu um conteúdo que não cabe em um único artigo. Sendo assim, para proporcionar uma cobertura ampla para alguns tópicos e instruções passo a passo para outros, criamos uma série com três artigos:

  • a Parte 1, este artigo, apresenta o MongoDB e o InfoSphere Guardium, descreve sucintamente as melhores práticas de segurança para o MongoDB e explica os benefícios da solução conjunta. O artigo também descreve a arquitetura e mostra as etapas do fluxo de dados para o InfoSphere Guardium e o seu processamento no dispositivo do InfoSphere Guardium.
  • A Parte 2 trata dos fundamentos da configuração do agente de monitoramento do InfoSphere Guardium para o MongoDB. Também mostra como usar políticas de segurança para realizar alguns casos de uso comuns, como o monitoramento o acesso de usuários privilegiados, alertas e logins repetidos com falha.
  • A Parte 3 descreve alguns dos recursos do InfoSphere Guardium que fazem dele uma solução bastante difundida de conformidade e segurança de dados para empresas, que inclui bloqueio, visualização e relatórios sobre dados de auditoria e criação de processos de auditoria para automatizar um fluxo de trabalho de conformidade.

Apresentando o MongoDB

A proliferação de dados provenientes de dispositivos de terminal, os volumes crescentes de usuários e novos modelos de computação — como nuvem, social business e Big Data — geraram demandas de acesso a dados e analítica que possam manipular essa enorme quantidade de dados. O valor dos bancos de dados NoSQL — uma classe em rápido crescimento — é a capacidade de manipular a velocidade muito mais alta e os volumes muito maiores de dados que essas tendências demandam e, ao mesmo tempo, proporcionar mais agilidade em esquemas dinâmicos. Os esquemas dinâmicos podem, por exemplo, permitir que as organizações reajam rapidamente às mudanças nos regulamentos.

O MongoDB, especificamente, oferece esses benefícios e, ao mesmo tempo, também fornece recursos ricos de consulta que são necessários para um armazenamento de dados operacionais de uso geral. Aumenta a produtividade dos desenvolvedores e a agilidade por meio de um modelo de documento; pode ser usado em situações adequadas para bancos de dados relacionais, bancos de dados NoSQL típicos ou totalmente novos.

A Figura 1 mostra um quadro geral da arquitetura do MongoDB e apresenta alguns conceitos-chave que você precisa entender se for responsável por configurar o InfoSphere Guardium para o MongoDB. (Essa figura representa um ambiente com shard. O MongoDB também pode ser usado de forma independente.) O MongoDB usa o sharding automático para a escalabilidade horizontal e conjuntos de réplica para alta disponibilidade. Os clientes se conectam ao processo do MongoDB (mongos em um ambiente com sharding), opcionalmente se autenticam, caso a segurança esteja habilitada, e realizam inserções, consultas e atualizações dos documentos no banco de dados. O mongos roteia a consulta para os shards adequados (mongod) para cumprir o comando específico.

Figura 1. A arquitetura do MongoDB fornece um ambiente escalável

Já que ele usa um modelo de dados de documento, o MongoDB é um tipo de banco de dados NoSQL chamado de banco de dados de documentos. Os documentos são modelados de forma hierárquica usando JSON (JavaScript Object Notation) — portanto, incluem simplesmente pares nome-valor. Os valores podem ser de tipo individual, um array ou os próprios documentos (e suas combinações) para corresponder a qualquer objeto que houver no aplicativo. Esse modelo pode fornecer consultas rápidas porque os dados podem ser armazenados lado a lado em um documento, e não espalhados em diversas tabelas, com necessidade de junção. A Listagem 1 mostra um exemplo de documento JSON.

Lista 1. Amostra de documento JSON
{
"_id" : 1,
"name" : { "first" : "John", "last" : "Backus" },
"contribs" : [ "Fortran", "ALGOL", "Backus-Naur Form", "FP" ],
"awards" : [
           {
             "award" : "W.W. McDowell Award",
             "year" : 1967,
             "by" : "IEEE Computer Society"
           },
           { "award" : "Draper Prize",
             "year" : 1993,
             "by" : "National Academy of Engineering"
           }
]
}

Essa estrutura de documento permite armazenar dados no MongoDB de forma semelhante à modelagem de objetos no seu aplicativo — portanto, oferece grandes benefícios em relação ao tempo de entrada no mercado e à agilidade (especialmente quando combinada com um esquema dinâmico, não predefinido).

Nos bastidores, os documentos são armazenados no formato JSON binário (BSON) para ganhar eficiência, mas você não precisa trabalhar com nada além dos documentos JSON.

A Tabela 1 compara os conceitos relacionais e os do MongoDB.

Correspondência entre os conceitos relacionais e o MongoDB

Conceito relacionalEquivalente do MongoDBComentário
Banco de dados/esquemaBanco de dadosContêiner para todo o restante
TabelaColeção
LinhaDocumento
ColunaCampoOs campos são definidos no nível do documento, não na coleção. Em outras palavras, não há um esquema predefinido, como o dos bancos de dados relacionais.
ÍndiceÍndice

O restante dos recursos do Mongo se destina a permitir o uso da estrutura de documento e sua linguagem de programação preferida sem passar muito tempo administrando o banco de dados. Alta disponibilidade, desempenho e sharding automático (particionamento) são desenvolvidos de forma que o aplicativo não tenha que se preocupar muito com isso, para que as equipes de desenvolvimento de aplicativos possam se concentrar em suprir as necessidades de negócios rapidamente.

Recomendações de segurança para o MongoDB

Conforme mais empresas procuram o MongoDB para suprir necessidades específicas de aplicativos, é provável que tenham que preencher os requisitos de segurança e conformidade que bancos de dados mais estabelecidos na organização também devem preencher.

O MongoDB tem um bom conjunto de melhores práticas de segurança, descritas em suas páginas da wiki. (É possível encontrar links em Recursos).) Além disso, para tratar de dificuldades fundamentais ligadas à segurança, o release 2.4 do MongoDB proporcionou os seguintes aprimoramentos à segurança:

  • Autenticação do Kerberos (somente Enterprise Edition) para empresas que precisam dessa abordagem para poder se integrar aos sistemas padrão de segurança
  • Sistema de controle de acesso baseado na função para proporcionar um controle mais granular
  • Aprimoramento dos requisitos de suporte de SSL para os clientes

Importante: atualmente, o InfoSphere Guardium não monitora a atividade quando o SSL é usado para o acesso de clientes.

Veja agora algumas melhores práticas de configuração de rede, autenticação, uso de funções e prevenção de ataques de injeção de JavaScript.

Configuração de rede

Para reduzir o risco de segurança do MongoDB, a recomendação é executar o MongoDB e todos os seus componentes em um ambiente confiável, com controles adequados de firewall, ligações fortes entre os componentes do MongoDB e portas de IP específicas. Quando você executa um cluster com sharding, o tráfego de consulta geralmente é roteado por meio de um processo separado conhecido como mongos. Obviamente, recomendamos o monitoramento de toda a atividade que passa pelo mongos.

Como mostra a Figura 2, usuários privilegiados e outros podem efetuar login diretamente nas instâncias do mongod nos shards. Por isso, recomendamos não só o uso de firewalls para bloquear o acesso aos shards tanto quanto possível, mas também a implementação do monitoramento do InfoSphere Guardium nos shards para capturar essa atividade. Como você verá na Parte 2 desta série de artigos, é possível configurar o Guardium nos shards para ignorar a atividade proveniente do mongos, pois essa atividade já será capturada pelo InfoSphere Guardium. Assim você poderá enviar de volta qualquer outra atividade que ocorra nos shards.

Na verdade, há muitas opções para configurar o monitoramento, mas esta é uma opção razoável em relação à eficiência e, ao mesmo tempo, fornece os recursos de monitoramento necessários para os administradores.

Figura 2. Uma configuração recomendada

Além disso, a execução com portas diferentes do padrão é uma melhor prática de segurança. Por uma questão de clareza, usamos as configurações padrão de porta (27017 para o mongos e 27018 para os servidores de shard), mas o InfoSphere Guardium funciona bem com a utilização de portas diferentes do padrão.

Autenticação

Evidentemente, é recomendável executar o MongoDB com a autenticação ativada. (Por padrão, a autenticação não está ativada.) A autenticação também é crítica sob o ponto de vista do monitoramento e da auditoria, para permitir que o InfoSphere Guardium capte o nome de usuário do banco de dados. Se a autenticação não está ativada, você verá a cadeia de caracteres "NO_AUTH" no campo de nome DB USER dos relatórios. (Raramente, também é possível ver NO_AUTH nos casos em que o InfoSphere Guardium começa a monitorar no meio da sessão e não capta o usuário do DB.)

Sob o ponto de vista do MongoDB, a autenticação anterior ao 2.4 se limita a uma autenticação básica usando o nome de usuário e senha, gerenciada somente no Mongo e não integrada aos sistemas de gerenciamento de usuários da empresa. Depois da autenticação, havia um número mínimo de funções — apenas somente leitura ou acesso total. No 2.4 Enterprise Edition, foram adicionados outros recursos, como o suporte para Kerberos

Funções e acesso baseado na função

No 2.4, o MongoDB suporta várias novas funções, cujos escopos podem ser divididos, de modo geral, em funções de servidor e funções no nível do banco de dados. Nos dois casos, há funções voltadas para a administração de usuários, administração de cluster e acesso aos aplicativos.

Já que algumas dessas funções basicamente são equivalentes a super usuário, é importante garantir que elas sejam distribuídas e monitoradas cuidadosamente.

Observe que, no InfoSphere Guardium, é possível monitorar e auditar mudanças na coleção system.users em relação ao ambiente ou qualquer banco de dados lógico — portanto, pode-se garantir que somente autorizações adequadas sejam exibidas. A Figura 3 mostra um exemplo de relatório no qual é possível ver que a usuária do banco de dados Indrani deu a função de leitura e gravação para Kathy e Sundari, e isso provoca inserções na coleção system.users no MongoDB.

Figura 3. Amostra de relatório de auditoria mostrando a concessão de funções (inserção de documentos em system.users)

Impedindo ataques de injeção de Javascript

Os ataques tradicionais do tipo injeção de SQL não são um problema significativo no MongoDB, já que ele usa BSON (JSON binário) em vez de cadeias de caracteres. No entanto, mesmo assim há casos que exigem cuidado, como o uso das operações a seguir, que permitem executar expressões arbitrárias de JavaScript diretamente no servidor:

  • $where
  • db.eval()
  • mapReduce
  • group

Existem formas de minimizar o risco (como desligar todos os scripts no lado do servidor), mas primeiro é necessário ter a capacidade de identificar onde essas operações são usadas. No InfoSphere Guardium, o JavaScript nessas operações é registrado e reportado como objetos. Isso é relevante porque permite configurar para que ocorram alertas ou violações de política sempre que eles forem acessados. Isso pode ser útil para testar ambientes com o objetivo de localizar e identificar os usos de risco e fazer as revisões de código necessárias antes da implementação na produção. A amostra de relatório da Figura 4 (veja a imagem ampliada) mostra que $eval está sendo relatado como objeto JavaScript. Você também verá o texto completo do comando, para poder ver seu uso dentro do contexto. Se você desejar monitorar isso ao longo do tempo, é possível criar um relatório planejado regularmente que indicaria sempre que ocorrer um novo uso de uma dessas operações.

Figura 4. O JavaScript de certas operações (como db.eval) é registrado no InfoSphere Guardium na forma de objetos

Benefícios do uso de usar o InfoSphere Guardium com MongoDB

O InfoSphere Guardium é um complemento vital e útil dos recursos nativos do MongoDB para qualquer organização interessada na auditoria verdadeira de bancos de dados e que talvez precisem preencher requisitos regulamentares como os da Payment Card Industry (PCI) ou da lei Sarbanes-Oxley (SOX). Assim como acontece em outros bancos de dados, os recursos nativos de segurança e autenticação do MongoDB não são muito adequados para lidar com os diversos regulamentos e requisitos de conformidade em vigor nos diversos países. A maioria desses requisitos exige uma prestação de contas mais robusta em termos da capacidade de registrar e verificar quem fez uma transação de banco de dados, o que foi feito e quando isso aconteceu.

O InfoSphere Guardium é implementado em organizações grandes e pequenas do mundo todo para lidar com as questões de proteção de dados e conformidade para uma ampla variedade de bancos de dados. A solução é flexível, eficiente e efetiva. Os usuários do MongoDB podem obter estes benefícios:

  • O InfoSphere Guardium registra informações muito detalhadas e granulares, como é possível ver no relatório de amostra apresentado na Figura 5 (veja a imagem ampliada), que inclui detalhes dos IPs de cliente e servidor, o programa de origem, o usuário do banco de dados (se a autorização está ativada) e a mensagem completa do comando (conforme ela passa pelo fio). No exemplo acima, o Kerberos está sendo usado como mecanismo de autenticação.

    Observe que partes da mensagem são analisadas e armazenadas como verbo (também conhecido como comando) e objeto — ou seja, essas entidades são itens que podem ser usados para especificar regras de política, como você verá na Parte 2 desta série. Por exemplo: é possível especificar uma regra que é acionada sempre que se emite uma localização ou uma que é acionada sempre que alguém mexe em um objeto do grupo de objetos de dados sensíveis.

    Figura 5. Exemplo de relatório de auditoria
  • É possível auditar condições de exceção de banco de dados — como autenticações com falha — que podem indicar um ataque de força bruta. A Parte 2 desta série mostra como configurar isso.
  • Opcionalmente, é possível registrar o número de documentos afetados em relação à atividade de leitura, e isso pode ser usado para alertar sobre números de downloads anormalmente altos. A Parte 2 desta série mostrará um exemplo disso.
  • É possível bloquear o acesso de usuários locais para impedir os casos em que o administrador lê o conteúdo de dados sensíveis. Você verá um exemplo disso na Parte 3 desta série.
  • É possível especificar alertas em tempo real para diversas condições. Você aprenderá a configurá-los na Parte 2 desta série. As organizações têm a responsabilidade de fazer o possível para evitar violações de dados embaraçosas ou danosas. A demonstração de conformidade cumpre isso parcialmente, mas, quando ocorrem violações, a capacidade de detectar e reagir rapidamente — dentro de minutos ou horas, e não dias ou semanas — pode fazer a diferença entre uma perda muito danosa e uma pequena inconveniência. Os alertas em tempo real ou alertas sobre violações de limite ajudam a detectar comportamento suspeito em segundos ou minutos — e não em dias, semanas ou até mais tempo.

    Esses alertas podem ser enviados por email ou por SNMP para outro sistema de monitor. Também se pode usar integração incorporada aos tipos de mensagem do IBM QRadar e HP ArcSight para encaminhar condições de alerta automaticamente, do syslog para esses sistemas.

  • As informações de auditoria devem ser armazenadas por um período de tempo definido, que às vezes pode envolver anos. O InfoSphere Guardium foi projetado levando em conta esse tipo de requisitos e fornece recursos de arquivamento seguro exatamente por esse motivo.
  • Por fim, a demonstração de conformidade pode ser demorada e trabalhosa, já que requer revisões e aprovações regulares. O InfoSphere Guardium não só permite criar os relatórios necessários para preencher os requisitos de auditoria, mas também tem um recurso de fluxo de trabalho robusto que se integra aos seus processos de negócios e salva todas as revisões e aprovações como parte da trilha de auditoria.

Arquitetura da solução

Com sua arquitetura não invasiva (veja a Figura 6), o InfoSphere Guardium fornece visibilidade total da atividade de dados e não requer mudanças na configuração do cluster do MongoDB.

Figura 6. Arquitetura geral

Os que estão familiarizados com o InfoSphere Guardium instalam os S-TAPs (agentes de software leves) em servidores do MongoDB. O S-TAP é um agente leve que é colocado no sistema operacional. Quando o servidor do Mongo recebe uma solicitação de dados de um cliente, o S-TAP copia o pacote de rede e o envia para um dispositivo de hardware ou software reforçado e à prova de violações, conhecido como coletor, para análise, parsing e criação de log no repositório do InfoSphere Guardium.

A verdadeira inteligência do sistema InfoSphere Guardium está no coletor. No coletor, a mensagem é dividida nas partes que a compõem e registrada em um repositório interno no coletor e as ações necessárias são realizadas, como gerar um alerta em tempo real, registrar a atividade ou bloquear um usuário local específico. Ao descarregar a maior parte da atividade (análise e registro) para um coletor reforçado, o impacto sobre o desempenho de aplicativos do Mongo é minimizado (em muitos casos, não mais do que 2-4%). Além disso, é possível instituir efetivamente a separação de obrigações.

O console da web baseada em função do InfoSphere Guardium fornece o gerenciamento centralizado de alertas, definições de relatório, processos do fluxo de trabalho de conformidade e configurações (como os planejamentos de arquivamento) sem o envolvimento dos administradores do MongoDB, fornecendo a separação de obrigações de que os auditores precisam e aperfeiçoando as atividades de conformidade.

Exemplo geral do fluxo de mensagens do cliente para o coletor do Guardium

Para as pessoas iniciantes no InfoSphere Guardium, a compreensão do fluxo de dados pelo sistema pode ajudar a entender e usar efetivamente outras partes do sistema, como configuração de política, relatórios e alertas.

Figura 7. Como o comando do MongoDB vai para o coletor do InfoSphere Guardium

Consulte a Figura 7 à medida que descrevemos o fluxo:

  1. (Não mostrado no gráfico.) Uma nova sessão começa quando um usuário ou aplicativo efetua logon no MongoDB. O InfoSphere Guardium sempre registra o início e final da sessão e, se a política exigir, a atividade que ocorre na sessão. (Na Parte 2 desta série, você aprenderá a configurar uma política de segurança para ignorar tudo entre o início e o fim de uma conexão confiável.)
  2. Um usuário ou aplicativo insere um comando do MongoDB.

    Observação:o cliente do MongoDB pode fazer algumas transformações nas coisas que são inseridas (açúcar sintático, etc). O InfoSphere Guardium coleta somente o que passa pelo fio. Neste exemplo, o usuário Joe está inserindo o comando a seguir:

    Lista 2. Comando do MongoDB mostrado no exemplo
    test.CreditCard.insert({
        "Name" : "Sundari",
         "profile" : [
            {"CCN" : "11999002"},
            {"log" : ["new", "customer"]}
        ],
        });
  3. A mensagem BSON vai para o servidor do Mongo (mongos, se for com sharding, e mongod, se for local) e inclui informações adicionais no pacote de rede, como o nome do usuário do banco de dados, o IP do cliente, o IP do servidor e um registro de data e hora.
  4. O S-TAP que fica no servidor mongo intercepta e copia a mensagem. A mensagem vai por TCP/IP para o coletor, que está recebendo na porta 16016.
  5. No coletor, o mecanismo de análise (também conhecido como "sniffer") reconhece que é uma mensagem do MongoDB e a analisa adequadamente. Na nossa instrução de amostra, as informações são registradas nas entidades a seguir.
    • Entidade cliente/servidor: Joe está conectado como usuário do DB
    • Entidade de comando: INSERT
    • Entidade de objeto: CreditCard
    • Entidade de campo: Name
    • Entidade de campo: profile.CCN
    • Entidade de campo: profile.log
    Esta é uma grande simplificação do que realmente ocorre no coletor, mas serve para proporcionar uma compreensão básica.

Resumo e próximos passos

Na primeira parte da série de artigos com três partes, abordamos o "alicerce" básico da solução conjunta, incluindo uma visão geral do MongoDB e do InfoSphere Guardium e de como o InfoSphere Guardium opera com o MongoDB para proporcionar um valor significativo em relação à proteção de dados e conformidade. Além disso, o InfoSphere Guardium fornece uma infraestrutura robusta e flexível para automatizar as tarefas de auditoria e conformidade para diminuir tanto quanto possível a carga de trabalho da equipe de TI.

Na Parte 2, abordaremos os fundamentos da configuração do S-TAP para o MongoDB e mostraremos como usar as políticas de segurança para realizar alguns casos de uso comuns, como acesso de administrador ao monitoramento, alertas e logins com falha repetidos.


Recursos para download


Temas relacionados


Comentários

Acesse ou registre-se para adicionar e acompanhar os comentários.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Information Management
ArticleID=950891
ArticleTitle=Segurança e Proteção de Dados do InfoSphere Guardium para MongoDB, Parte 1: Visão geral da solução e recomendações de segurança de dados
publish-date=11012013