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

Esta série de artigos descreve como monitorar e proteger os dados do MongoDB usando o IBM InfoSphere® Guardium®. A Parte 1 descreve uma visão geral da solução, a arquitetura e os benefícios do uso do InfoSphere Guardium com o MongoDB. O valor dos bancos de dados NoSQL — uma classe em rápido crescimento — como o MongoDB é a capacidade de manipular alta velocidade e altos volumes de dados e, ao mesmo tempo, proporcionar mais agilidade em esquemas dinâmicos. Muitas organizações estão apenas começando a usar o MongoDB. Agora é a hora de dar segurança ao ambiente para poupar tempo e evitar violações e violações de conformidade. Esta série de artigos descreve a configuração da solução, casos de uso de amostras de monitoramento e recursos adicionais, como procura rápida de dados de auditoria e desenvolvimento de um fluxo de trabalho de conformidade usando um processo de auditoria.

Matt Kalan, Senior Solutions Architect, 10gen

Photo of Matt KalanMatt Kalan é arquiteto de soluções senior na 10gen, sediada em Nova York, com ampla experiência com a assistência a mais de 200 clientes de serviços financeiros e outros segmentos de mercado a resolver problemas de negócios com tecnologia. Antes da 10gen, Matt promoveu o crescimento do negócio da Apama Algorithmic Trading and Complex Event Processing (CEP) Platform da Progress Software na América do Norte e posteriormente vendeu soluções de inteligência operacional mais amplas para empresas de serviços financeiros. Anteriormente, trabalhou para a Caplin Systems vendendo soluções de fluxo de dados de mercado em tempo real pela web para portais FX e FI. Trabalhou também para a Sapient, prestando serviços de consultoria para clientes que incluídos na lista Global 2000.



Sundari Voruganti, QA Specialist, InfoSphere Guardium, Os compiladores IBM

Sundari Voruganti photoSundari Voruganti é membro da equipe de QA do InfoSphere Guardium no Laboratório da IBM no Vale do Silício. Sundari trabalha na IBM há mais de uma década e tem um histórico diversificado, baseado em funções de engenharia e capacitação de clientes. Apaixonada por tecnologia, ela aprecia o desafio de aprender e trabalhar com novas tecnologias e ajudar os clientes a entender e implementar soluções de IM. Sundari tem mestrado duplo em Ciência da Computação pela Universidade de Bangalore e pela Universidade de Alberta.



Kathryn Zeidenstein, InfoSphere Guardium Evangelist, IBM

Photo of Kathryn ZeidensteinKathy Zeidenstein trabalha na IBM há muitos anos. Atualmente, atua como divulgadora de tecnologia para a atividade de monitoramento de dados do InfoSphere Guardium e trabalha no Laboratório do Vale do Silício. Anteriormente, atuava como gerente de desenvolvimento de informações para as ferramentas de ciclo de vida de dados InfoSphere Optim. Desempenhou funções de capacitação técnica, gerenciamento de produtos e marketing de produtos nas organizações de Information Management e ECM da IBM.



Indrani Ghatare, Software Engineer, InfoSphere Guardium, IBM

Indrani GhatareIndrani Ghatare é desenvolvedora de software na IBM há mais de 12 anos. Atualmente, Indrani é membro da equipe de Pesquisa e Desenvolvimento do InfoSphere Guardium Collector. Indrani trabalhou no desenvolvimento do analisador do MongoDB e no componente criador de logs do Guardium Collector.



01/Nov/2013

Introdução

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.

O que há de novo no InfoSphere Guardium?

Embora o foco deste artigo seja o suporte do MongoDB, o InfoSphere Guardium 9.0 GPU 50 inclui muitos recursos adicionais, tais com:

  • Expandir o monitoramento da atividade de dados às plataformas de Big Data e NoSQL, novas e em expansão, como MongoDB, Greenplum HD e Greenplum DB e Hortonworks Data Platform
  • Melhorar os recursos de relatório para acelerar os relatórios corporativos e o uso de um novo recurso de consulta federada para melhorar o desempenho de processos de auditoria em ambientes federados
  • Reduzir o tempo de descoberta com uma procura facetada rápida em atividades do banco de dados, exceções e violações de política
  • Detectar mais atividades suspeitas com mais visualizadores de melhores práticas (relatórios) integrados
  • Suportar os dispositivos do Guardium na arquitetura de 64 bits para melhorar a escalabilidade (cuja entrega está planejada em uma imagem de instalação completa após a entrega da correção)
  • Consolidar todos os agentes (S-TAP, Guardium Installation Manager e Discovery) em um único instalador para simplificar implementações e reduzir o tempo necessário para começar a funcionar normalmente
  • Simplificar a automação e a manutenção com a designação da API aos relatórios com três cliques
  • Levar o Guardium com você no dispositivo móvel para gerenciar as suas listas de pendências e ficar de olho no funcionamento da segurança

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.

Por que ele mostra títulos de SQL nos relatórios?

Os títulos padrão de relatórios realmente usam a terminologia SQL. Como o InfoSphere Guardium é heterogêneo, vários bancos de dados diferentes usarão as mesmas políticas e relatórios na empresa. Entretanto, se você tem relatórios específicos do MongoDB e não deseja incluir SQL no título do relatório, é possível customizar os títulos dos relatórios como quiser.

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

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


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