Segurança e Proteção de Dados do InfoSphere Guardium para MongoDB, Parte 2: Configuração e políticas

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®, incluindo 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. A Parte 2 mostra como configurar o InfoSphere Guardium para coletar o tráfego do MongoDB e descreve como criar regras de política de segurança para diversos casos de uso típicos de proteção de dados, como alertas sobre um número excessivo de logins com falha, monitoramento de usuários privilegiados e alertas sobre acesso não autorizado a dados sensíveis. 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.

Indrani Ghatare, Software Engineer, InfoSphere Guardium, Os compiladores 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.



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, 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.



01/Nov/2013

Introdução

A primeira parte desta série de artigos apresentou o MongoDB e o InfoSphere Guardium. Forneceu algumas informações sobre como o InfoSphere Guardium pode dar segurança à utilização do MongoDB em mais aplicativos por causa de sua capacidade de monitorar e auditar a atividade de dados minuciosamente. Você conheceu a arquitetura da solução e viu algumas recomendações sobre a proteção do MongoDB por meio de seus recursos nativos. Além disso, conheceu os benefícios que o InfoSphere Guardium proporciona.

Este segundo artigo detalha dois tópicos principais:

  • Configuração dos S-TAPs nos nós do MongoDB
  • Criação de políticas de segurança para diversos casos de uso típicos

A Parte 3 tratará de alguns recursos adicionais, como bloqueio de usuários, como gravar relatórios e acessar dados de auditoria e como a utomatizar revisões de conformidade.


Instalação e configuração

Esta seção descreve as etapas necessárias para começar a usar o software e a registrar atividade do MongoDB no coletor do InfoSphere Guardium.

  1. Instale o agente do S-TAP nos nós do MongoDB.
  2. Configure o mecanismo de inspeção do S-TAP com as portas corretas do MongoDB.
  3. Valide que você está vendo o tráfego do MongoDB.

Antes de iniciar

Este artigo pressupõe que um coletor do InfoSphere Guardium está instalado e configurado na rede. O monitoramento da atividade do MongoDB pelo InfoSphere Guardium requer o V9 GPU 50 ou releases posteriores. Se você é cliente do InfoSphere Guardium e tem direito ao V9.0, é possível primeiramente fazer o download do Guardium a partir do Passport Advantage e, em seguida, instalar o GPU, que pode ser obtido a partir do Fix Central.

Os releases suportados do MongoDB são 2.0, 2.2 e 2.4. Sob o ponto de vista da segurança de dados, é recomendável passar para o MongoDB 2.4 ou posterior, que fornece os aprimoramentos de segurança descritos na introdução. (O Kerberos requer a Enterprise Edition.)

Anote as informações a seguir, que serão necessárias para concluir a instalação e configuração da instalação:

  • endereço IP do coletor do InfoSphere Guardium e a porta usada para se conectar a eles (16016)
  • As portas usadas pelo mongod nos servidores de shard (o padrão é 27018) e os endereços IP
  • Porta usada pelos servidores de roteamento (mongos) (o padrão é 27017) e os endereços IP

Instale o agente do S-TAP nos nós do MongoDB

Como mostra a Figura 1, recomendamos a instalação dos S-TAPs nos shards do mongod e no servidor de roteamento para monitorar a atividade de administrador que possa ocorrer nos shards do mongod.

Figura 1. Os S-TAPS são configurados para receber nas portas do MongoDB

Os S-TAPs são específicos para o sistema operacional — portanto, é necessário instalar o Linux® S-TAP nos nós adequados. Há formas diferentes de fazer isso:

  • Use o Guardium Installation Manager (GIM). Com o GIM, na verdade você instala um agente do GIM junto com o S-TAP. Usando o GIM, os upgrades e as futuras instalações do S-TAP podem ser controlados a partir do console da web sem necessidade de acessar o servidor novamente. Isso é o que a maioria das empresas usa, por causa da simplicidade de gerenciamento e atualização. Consulte o centro de informações do InfoSphere Guardium para obter mais informações sobre o GIM. Consulte Recursos para obter o link.
  • Use o instalador de shell S-TAP que você obtém por download a partir do Fix Central. Isso pode ser feito de forma não interativa, para que você possa instalar em vários nós com o mesmo comando.

Os detalhes desse processo estão fora do escopo deste artigo, mas é possível consultar o centro de informações do InfoSphere Guardium para obter mais informações.

Se os seus S-TAPs estão configurados adequadamente para se conectar ao coletor do InfoSphere Guardium, o System View no console de administração será exibido em verde, como mostra a Figura 2.

Figura 2. O System View mostra que os S-TAPs estão se comunicando com o coletor

Configure o mecanismo de inspeção

Em seguida, é necessário configurar o mecanismo de inspeção para cada S-TAP. Os mecanismos de inspeção são uma forma de definir o protocolo de S-TAP a ser usado para o monitoramento (MongoDB) e as portas a serem monitoradas. Por padrão, como mostra a Figura 1, a porta do mongos é 27017 e a do mongod (shards) é 27018. Suas portas podem ser diferentes.

Para configurar os mecanismos de inspeção, efetue login no InfoSphere Guardium como administrador e navegue para o console de administração. Na área de janela de menu à esquerda, selecione Local Tap s> S-TAP Control. Localize o S-TAP do servidor do Mongos, clique em Modify e, em seguida, selecione o menu suspenso Add Inspection engine .

Insira as informações de porta necessárias. A configuração do mecanismo de inspeção para o mongos deve ser semelhante à Figura 3.

Figura 3. Configuração do mecanismo de pesquisa do Mongos (servidores de roteador de consulta)

Nos shards, a configuração será ligeiramente diferente. Como você deve saber, a maior parte da atividade "normal" é roteada pelo mongos e, em seguida, para o mongods nos shards. Se você monitorasse todo o tráfego nos shards, o coletor do Guardium receberia a mesma mensagem do mongos e de todos os shards para o qual o comando foi roteado. Para evitar essa "contagem dupla" e, mesmo assim, poder monitorar o tráfego que desvia do mongos, configure os STAPs nos shards para excluir todo o tráfego do mongos.

Figura 4. Configuração do mecanismo de inspeção do mongod (shards)

Usando uma API para configurar mecanismos de inspeção

Se há muitos nós, é conveniente usar uma API do Guardium para incluir um mecanismo de inspeção em um S-TAP especificado. É possível modificar as configurações dos S-TAP somente a partir do host ativo do Guardium referente ao S-TAP e somente quando o S-TAP estiver online (aparecendo em verde em System Overview.)

Para o mongos:

grdapi create_stap_inspection_engine client=0.0.0.0/0.0.0.0 protocol=MongoDB 
ktapDbPort=27017 portMax=27017 portMin=27017 
stapHost=<ip of Mongos server where associated STAP is installed>

Para o mongod:

grdapi create_stap_inspection_engine protocol=MongoDB 
ktapDbPort=27018 portMax=27018 portMin=27018  
stapHost=<ip of mongod server where STAP is installed> 
client=0.0.0.0/0.0.0.0 excludeClient=<ip of Mongos>

Valide a captura do tráfego

Há várias formas de ver se o tráfego está sendo enviado para o coletor do Guardium. Usuários experientes do Guardium podem garantir a instalação de uma política que captura todo o tráfego e podem examinar um relatório.

  • Se você efetua login como usuário, verá na guia View um gráfico de barras chamado Number of db per type. É possível clicar duas vezes no relatório e realizar drill down para ver se há atividade.
    Figura 5. Drill down no relatório
  • Se a instalação do Guardium 9.0.0.50 for nova ou você fez um upgrade e instalou a nova política padrão chamada Default-Ignore Data Activity for Unknown Connections, não verá atividade detalhada. Em vez disso, é necessário acessar o relatório Connection Profile List, que mostra somente as informações gerais de sessão sobre conexões desconhecidas, inclusive as do MongoDB, que devem ser todas desconhecidas nesse momento. Como usuário, você encontra esse relatório na guia View sob DB Activities, como mostra a Figura 6.
    Figura 6. Connection Profile List

    Como administrador, você encontra esse relatório na guia Daily Monitor.

O relatório é semelhante à Figura 7. Inclui o nome do banco de dados, IP do cliente e toda a "tupla" de informações de conexão, como IP do cliente, aplicativo de origem, nome do usuário do banco de dados, IP do servidor e nome do serviço.

Figura 7. Connection Profile List

Se você tem certeza de que a política está configurada corretamente e, mesmo assim, não está vendo o tráfego, certifique-se de que os intervalos de data e hora dos relatórios estejam corretos. Se o problema não for esse, pode ser que alguma configuração do S-TAP ou dos mecanismos de inspeção esteja errada — como números de porta incorretos.


Crie grupos para serem usados em políticas e relatórios

Criar grupos é um exercício de planejamento importante e um meio de aumentar a produtividade. Por exemplo: pode-se criar um grupo de usuários administradores (privilegiados), um grupo de objetos de dados sensíveis e grupos de certos comandos, como comandos que designam usuários e privilégios e praticamente qualquer outra coisa. Neste artigo, examinaremos alguns casos de uso de monitoramento e veremos como criar regras de política para lidar com esses casos de uso. Quase todas essas regras requerem o uso de grupos. A Tabela 1 é um resumo das regras que serão criadas e dos grupos que são usados em cada regra.

Regras e grupos usados para criar as amostras de regras de política

Ordem da regraDescrição da regraGrupos usados na regra
1Alerta sobre o número excessivo de logins com falha por usuário por banco de dados em três minutosNão há necessidade. Consulte Alerta em tempo real sobre um número excessivo de falhas de autenticação.
2Ignorar a atividade detalhada do ID funcional do usuárioUse o construtor de grupos de "tupla" para o campo ClientIP/Src App./DB User/Server IP/Svc.Name field no editor de regras de política. Consulte Ignorar a atividade de usuários funcionais para obter detalhes.
3Comandos internos SkipMongoDB MongoDBSkipCommands (grupo pré-preenchido; é possível incluir outros conforme a necessidade, com base no tráfego observado). Consulte Filtrar comandos de ruído para obter detalhes.
4 Registrar detalhes completos da atividade de usuários administradores Usuários administradores - crie os seus ou modifique o grupo Admin existente. Neste artigo, criamos o nosso grupo. Consulte Monitoramento detalhado de usuários privilegiados.
5Alertar quando usuários privilegiados acessam dados sensíveis. Usuários administradores
Objetos sensíveis do MongoDB – Crie o seu

Opcional: inclua um grupo de comandos específicos sobre os quais você deseja ser alertado. Criamos um grupo chamado MongoDB WatchCommands. Consulte Alerta em tempo real quando usuários privilegiados acessam dados sensíveis.
6Alerta sobre comandos de controle de acesso do MongoDBNão há necessidade de grupo. Registrar o acesso à coleção system.users. Consulte Alerta em tempo real sobre comandos de controle de dados.
7Registrar a violação de política referente à mudanças na coleçãoComandos de mudança do MongoDB - Crie o seu

Opcional: Inclua um grupo de objetos (coleções) que estão na produção ou perto dela e para os quais uma mudança na coleção ou seu descarte pode afetar um aplicativo. Consulte Registrar violações de política referentes a mudanças na coleção que podem afetar aplicativos.
8Número excessivo de documentos sensíveis lidos Objetos sensíveis do MongoDB – Crie o seu
Consulte Alerta em tempo real: o acesso de leitura a dados sensíveis excede o limite.

Na Parte 3 desta série de artigos, abordaremos um recurso avançado adicional no qual é possível usar regras de política para bloquear o acesso em tempo real. Esse recurso requer uma licença referente ao monitoramento de atividade avançado.

Para criar um grupo, acesse o Group Builder. Se você está conectado como administrador, clique na guia Tools e, na área de janela do menu à esquerda, selecione Config & Control > Group Builder. Mais detalhes sobre a interface do Group Builder são descritos em um de nossos exemplos de regra de política.


Configure uma política de segurança

Políticas de segurança baseadas em regras são a parte mais importante do trabalho do InfoSphere Guardium. Por meio dessas regras, você especifica para o InfoSphere Guardium o tráfego a ser registrado, as condições que geram alertas e até mesmo as conexões a serem bloqueadas.

Uma nova instalação do InfoSphere Guardium 9.0.0.50 incluirá uma política padrão que ignora todo o tráfego. Esse padrão ajuda a protege a rede contra sobrecarga quando o S-TAP é ativado e começa a monitorar o banco de dados.

Não é possível abordar neste artigo todos os tipos de regra de política e seu comportamento. Em vez disso, optamos por selecionar alguns casos de uso comuns de monitoramento e mostrar como configurar regras de política para esses casos de uso. Abrangeremos esses casos de uso na próxima seção do artigo.

Agora, vamos criar uma nova política que pode ser usada para começar a incluir regras.

  1. Clique na guia Tools e, na área de janela do menu à esquerda, selecione Config & Control > Policy Builder.
  2. No Policy Finder, clique em New.
    Figura 8. Create a new policy
  3. Forneça uma descrição da política e clique em Apply.
    Figura 9. Forneça uma descrição da política

    Opcional: clique em Roles para associar às funções que podem usar essa nova política. Por exemplo: se você seleciona admin, todas as pessoas com a função de administrador podem trabalhar com essa política no sistema.

  4. Clique em Back.

Agora é possível editar a política incluindo as regras necessárias. Descrevemos algumas regras "típicas" na próxima seção. Instale essa nova política somente quando estiver pronto para validar o comportamento de uma nova regra ou conjunto de regras.


Casos de uso de monitoramento

Nesta seção, incluiremos regras de política adicionais que englobam mais casos de uso que podem ser adequados (ou não) para a sua organização, mas dão uma ideia de como começar.

Se você nunca trabalhou com o InfoSphere Guardium, é importante entender que uma política pode conter várias regras. Cada regra tem uma descrição, critérios (para avaliar a atividade monitorada) e uma ação que é realizada quando a regra é acionada.

Há três tipos de regra:

  • Acesso: usado para a interação entre o cliente do banco de dados e o servidor.
  • Exceção: usado para exceções retornadas para o cliente pelo servidor do banco de dados. Observe que, se você usar write concern =0 ou -1 (não é seguro) para conexões do MongoDB, não poderá registrar e relatar condições de erro retornadas por inserções, atualizações ou remoções (exclusões).
  • Extrusão: aplicado aos conjuntos de dados retornados. É um recurso avançado que não será abordado neste artigo.

Alerta em tempo real sobre um número excessivo de falhas de autenticação

Um requisito comum para proteger contra hackers que talvez estejam gerando senhas por meio de algoritmos é emitir um alerta quando o número de tentativas com falha dentro de uma sessão excede um limite que você define — por exemplo: mais de 5 tentativas em 3 minutos.

Nesta regra, você definirá uma regra de exceção.

  1. Selecione a nova política no Policy Finder e clique em Edit Rules.
    Figura 10. Edite as regras da nova política
  2. Na parte inferior da página Policy Rules, clique em Add Exception Rule..
  3. Preencha os critérios da política para especificar LOGIN_FAILED no menu suspenso, no campo Excpt. Type. Inclua a contagem mínima (nesse caso, 5) e o intervalo de reconfiguração (nesse caso, 3 minutos).
    Figura 11. Especifique os critérios para acionar a regra de falha de login
  4. Na parte inferior da página, clique em Add Action e selecione ALERT ONCE PER SESSION no menu suspenso. Esta ação irá gerar um alerta por sessão quando alguém não consegue se autenticar com êxito mais de 5 vezes em 3 minutos.
    Figura 12. Selecione uma vez por sessão
  5. Selecione um tipo de notificação. No nosso caso, escolhemos SYSLOG e o modelo de mensagem padrão. Clique em Add e, em seguida, clique em Apply.
    Figura 13. Selecione o tipo de notificação

Amostra de alerta: A Figura 14 mostra um exemplo de alerta na guia Incident Management quando está conectado como administrador.

Figura 14. Alerta de logins com falha (saída parcial)

Ignorar a atividade de usuários ou conexões funcionais

Algumas organizações têm tarefas autorizadas periódicas que realizam ações como carregamento ou atualização em lote e são executadas à noite ou em janelas de lote especificadas. Geralmente, esses aplicativos são verificados com cuidado e executam sob um ID funcional de usuário. Para evitar a "inundação" do coletor do InfoSphere Guardium com atividades irrelevantes para a auditoria, algumas organizações usam uma ação de regra de acesso chamada "Ignore S-TAP session."

Observe que, mesmo assim, as informações de início e fim de sessão são registradas (ou seja, registro de data e hora, IP do cliente, IP do servidor, nome de usuário, etc.). Essa regra significa apenas que a atividade detalhada do comando será ignorada.

Planejando políticas

O InfoSphere Guardium permite planejar instalações de políticas — ou seja, é possível ativar conjuntos de regras diferentes à noite e durante o dia. É possível incluir essa regra em outra cópia da política, que você planeja automaticamente para ser instalada à noite — um período no qual você sabe que uma tarefa de manutenção está executando.

Recomendação:é possível criar um grupo de usuários funcionais e ignorar a atividade deles, mas, se você deseja reduzir a possibilidade de deixar passar alguma atividade suspeita, pode usar as informações de conexão para especificar a regra. Por exemplo: é conveniente ignorar a atividade do usuário funcional FUNC1234 proveniente do IP de cliente 1.22.222.222, mas, se esse ID do usuário está acessando o sistema de qualquer outro IP, convém registrar a atividade.

Por isso, criaremos um grupo chamado "Functional MongoDB User Connections" que será usado em nossa regra de política. Mostramos tanto o modo manual de preencher o grupo quanto uma forma de automatizar o preenchimento do grupo usando o relatório Connection Profile List.

O nome do campo da regra de acesso é muito adequado: Client IP/SrcApp/DB User/Server IP/Svc.Name. Esse campo específico com diversos componentes é conhecido no Guardium como uma "tupla".

É possível usar curingas para qualquer parte dessas informações de conexão. Vamos ver como funciona.

  1. Selecione a nova política no Policy Finder e clique em Edit Rules.
  2. Na parte inferior da página Policy Rules, clique em Add Access Rule.
    Figura 15. Add Access Rule
  3. Dê um nome à nova regra e, em seguida, clique no ícone do construtor de grupo referente ao campo da tupla (Client IP/SrcApp/DB User/Server IP/Svc.Name), como mostra a Figura 16.
    Figura 16. Clique no construtor de grupo referente ao campo da tupla de conexão da regra de política
  4. Preencha os atributos de cada componente da tupla. É possível usar curingas para indicar que tudo irá se qualificar. Nesse caso, temos uma convenção de nomenclatura para IDs de usuário funcional, que está sendo utilizada. Além disso, sabemos que o trabalho desses IDs de usuário sempre vem de um IP de cliente específico — portanto, também incluímos isso.
    Figura 17. Inclua uma tupla como membro do grupo
  5. Clique em Add quando tiver preenchido os atributos de um membro. O grupo deve se parecer com a Figura 18.
    Figura 18. A tupla foi incluída no grupo
  6. Quando terminar de incluir membros, clique em Back.
  7. Selecione este grupo a partir do campo da tupla na regra de política.
  8. Clique em Add Action e escolha IGNORE S-TAP SESSION no menu suspenso Clique em Apply. Agora a regra é semelhante à Figura 19.
    Figura 19. Ignorando sessões de S-TAP para conexões de usuários funcionais (confiáveis)
    Observação: cancelamos a seleção de Cont. to next rule. Fizemos isso porque não há motivo para esta sessão ir para a próxima regra, já que optamos por ignorar toda a atividade do usuário e da conexão.
  9. Clique em Save.

Sugestão: automatizar o processo de preenchimento do grupo Functional User Connections

Se o tráfego do MongoDB já está sendo monitorado, é possível automatizar esse processo usando o relatório integrado Connection Profile List. Se você está conectado como administrador, volte para a guia Daily Monitor e clique em Connection Profiling List na área de janela de menu à esquerda.

Você verá um relatório semelhante à Figura 20.

Figura 20. Exemplo de Connection Profile List

Na parte inferior do relatório, clique no ícone de Invoke () para chamar a API create_member_to_group_by_desc. Na janela pop-up, mude o campo desc para o nome do grupo em que você deseja incluir essa conexão e clique em Invoke now, como mostrado na Figura 21.

Figura 21. Exemplo de Connection Profile List

Filtrar comandos de ruído

Essa regra filtra alguns comandos de "ruído" que o MongoDB está emitindo internamente, como verificações de funcionamento e comunicação entre servidores. Usa um grupo integrado chamado MongoDB Skip Commands.

  1. Selecione a política no Policy Finder e clique em Edit Rules.
  2. Na parte inferior da página Policy Rules, clique em Add Access Rule.
  3. Na seção da regra de política chamada Command, escolha o grupo MongoDB Skip Commands no menu suspenso de grupos, como mostra a Figura 22.
    Figura 22. Selecione MongoDB Skip Commands no menu suspenso Group
  4. Cancele a seleção de Cont. to next rule, se ainda não tiver feito isso. (Isso poupa tempo, já que não há outras ações que possam acontecer com qualquer comando desse grupo.)
  5. Na parte inferior da regra de política, escolha a ação SKIP LOGGING e clique em Apply.
  6. Salve a regra.

Monitoramento detalhado de usuários privilegiados

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.

Algumas organizações exigem que qualquer atividade de usuários administrativos (privilegiados) sejam monitorados detalhadamente. A ação de regra de política para fazer isso é LOG FULL DETAILS. Sempre que precisar usar LOG FULL DETAILS, você irá capturar registros de data e hora exatos e detalhes completos de cada ação. Certifique-se de ter dimensionado adequadamente o repositório interno do InfoSphere Guardium e o tamanho do buffer no dispositivo para manipular essa carga de trabalho, principalmente se os usuários privilegiados estiverem lendo ou gravando muitos documentos.

Pré-requisito: Crie um grupo de usuários administradores do MongoDB (incluindo todos os considerados "privilegiados"), conforme o descrito acima.

Acesse a política do MongoDB e, em seguida, clique em Add Access Rule.

Inclua uma descrição e o seu próprio grupo de usuários administradores no campo DB User da regra, como mostra a Figura 23.

Figura 23. Extrato da regra de política focada dos critérios de DB User

Já que incluiremos um alerta em algumas atividades de usuários administradores como a próxima regra, certifique-se de marcar a caixa de seleção Cont.to next rule e selecione a ação LOG FULL DETAILS, como mostra a Figura 24.

Figura 24. "Continue to next rule" garante que o Guardium processe a próxima regra mesmo quando essa é acionada

Se você deseja testar as regras de política, deve instalar isso. Acesse Tools > Policy Builder > Install and override.

Alerta em tempo real quando usuários privilegiados acessam dados sensíveis

Campos sensíveis

No MongoDB, também é possível emitir alertas sobre atividades no nível do campo. Por exemplo: é conveniente fazer isso se você sabe que a coleção de documentos foi preenchida esparsamente com dados sensíveis, como números de carteira de habilitação, e não deseja emitir alertas sobre todos os outros acessos a documentos na coleção. Observe que, se um campo está aninhado a mais de um nível de profundidade no documento, o caminho de notação de ponto para o campo será registrado.

db.CreditCard.insert({ "Name" : "Sundari Voruganti", "code" : "WM2001_0", "product" : "Gold Card", "profile" : [ {"CCN" : "11999002"}, {"log" : ["new", "customer", "for", "now"]} ], "otherinfo" : "Contact Bob Saget" });

No exemplo acima, o Guardium armazenaria um objeto de CreditCard e os seguintes campos: Name, code, product, profile.CCN, profile.log, otherinfo.

É possível configurar um alerta contendo %CCN% (referente a um campo de cartão de crédito) e %DLN%, referente a um campo de carteira de habilitação, e um alerta ligado ao acesso a esses campos.

Os alertas são uma forma excelente de obter alertas quase em tempo real sobre atividades suspeitas ou sem conformidade. Os alertas são gravados na guia Incident Management da UI (assim como as outras violações de política), mas também podem ser enviadas para emails ou gravados no Syslog. Se forem gravados no Syslog, é possível encaminhar alertas para os sistemas de inteligência de segurança e gerenciamento de eventos, como o IBM QRadar ou o HP Arcsight, para que a equipe de segurança possa manipulá-los e investigá-los adequadamente.

Pré-requisito: essa regra de política se baseia na existência de dois grupos, chamados "MongoDBAdmins" e "MongoDB Sensitive objects." Se você deseja restringir a emissão de alertas a certos comandos, também é possível adicionar um grupo contendo comandos específicos, como find e CopyCollection. Criaremos e usaremos esse grupo opcional chamado "MongoDB WatchCommands." Contém vários comandos que desejamos acompanhar, como find, update, insert, delete, cloneCollection e mapreduce.

Figura 25. Grupo de objetos sensíveis. No MongoDB, uma coleção é um objeto
Figura 26. Um grupo de comandos específicos que desejamos monitorar quando são usados com dados sensíveis

Para criar uma regra de política, selecione a política no Policy Finder, clique em Edit Rulese, em seguida, clique em Add Access Rule.

A nossa é semelhante à Figura 27.

Figura 27. Essa política emite um alerta quando usuários privilegiados usam comandos específicos para acessar dados sensíveis

Para testar a nova regra, certifique-se de reinstalar a política.

A Figura 28 mostra como é a nossa política.

Figura 28. O alerta é acionado quando um usuário privilegiado usa um dos comandos desaprovados para acessar dados sensíveis (extrato do alerta)

Alerta em tempo real sobre comandos de controle de dados

Monitorar quaisquer comandos que dão acesso aos usuários é um requisito comum. No MongoDB, os administradores podem criar e incluir usuários; no MongoDB 2.4, há funções adicionais que podem ser dadas aos usuários. Consulte Recursos para obter links para mais informações sobre a segurança e as funções do MongoDB.

As credenciais e as informações de usuários privilegiados são armazenadas na coleção system.users.

Sendo assim, por exemplo, pressuponha que alguém crie um novo usuário da seguinte forma: db.addUser({user:"sundari",pwd:"guardium",roles:["readWrite"]}).

Como mostra o relatório da Figura 29, o InfoSphere Guardium irá registrar essa atividade como uma inserção na coleção system.users. A atividade terá dois objetos: o nome do novo usuário e a coleção system.users.

Figura 29. Extrato de um relatório de auditoria que mostra o acesso na coleção system.users

No caso da nossa regra de política, é conveniente visualizar com facilidade qualquer atividade na coleção system.users. Para fazer isso, é possível incluir uma nova regra de acesso na política, que registra o acesso à coleção system.users. A Figura 30 é a nossa regra de política, na qual simplesmente incluímos system.users como objeto e Log Only somo ação — isso irá incluí-lo também na guia Incident Management da UI.

Figura 30. Regra de política para registrar mudanças em system.users, para que fiquem visíveis na guia de gerenciamento de incidentes

A Figura 31 mostra a saída parcial de um incidente.

Figura 31. O administrador incluiu Sundari como usuária, e isso aparece na guia de gerenciamento de incidentes da UI do Guardium

Observação: registrar no gerenciamento de incidentes é bom para obter registros em tempo real dos eventos. Entretanto, se a atividade requer uma revisão periódica, é conveniente criar um relatório dela e roteá-lo para os revisores.

Registrar as violações de política referentes a mudanças na coleção que podem afetar aplicativos

É possível que os administradores e proprietários de aplicativos em algumas organizações queiram ter um registro das mudanças no banco de dados que podem afetar a lógica ou o desempenho do aplicativo, como descartar ou renomear uma coleção, ou descartar um índice ou banco de dados. É possível criar um grupo que contém os comandos que você deseja controlar. Observe que os métodos auxiliares provavelmente passam pelo fio de forma diferente. Os comandos que queremos controlar são:

  • deleteIndexes
  • drop (para capturar o descarte de coleções
  • dropDatabase
  • renameCollection

Também é necessário incluir um grupo de objetos "congelados", caso você queira evitar acionar essa regra para qualquer atividade de QA ou teste que possa gerar vários descartes e renomeações.

Figura 32. Grupo de comandos que queremos registrar

Em seguida, é possível acessar uma regra de política que inclui o grupo e escolher uma ação a ser realizada quando a regra é acionada. No nosso caso, estamos registrando a violação de política, mas sem gerar um alerta.

Figura 33. Extrato da ocorrência do comando de mudança na guia Incident Management

Alerta em tempo real: o acesso de leitura a dados sensíveis passa do limite

Muitas organizações proíbem seus funcionários (e hackers) de recuperar uma quantidade excessiva de dados potencialmente sensíveis e desejam ser alertadas caso isso ocorra, para poder investigar rapidamente e determinar se houve uma violação grave.

Uma das formas de fazer isso é criar um limite baseado nos "registros afetados" na regra de acesso da sua política do MongoDB.

Pré-requisitos:

  1. crie um grupo de dados sensíveis sobre os quais você deseja ser alertado.
  2. Certifique-se de que a configuração do sistema esteja com Inspect Returned Data e Log Records Affected ativados em todos os mecanismos de inspeção. Para fazer isso, acesse a guia Administration Console e, em seguida, selecione Configuration > Inspection Engines e marque as caixas de seleção correspondentes, como mostra a Figura 34.
Figura 34. Configure o Guardium para relatar o número de documentos lidos

A Figura 35 mostra a regra de política que criamos, que emitirá um alerta quando o número de documentos lidos por qualquer usuário do banco de dados em um objeto de dados sensíveis é maior que 200. Certifique-se de colocar um ponto no campo DB User para contar os registros afetados por usuário de banco de dados, e não por todos os usuários de banco de dados.

Figura 35. Definição da regra de alerta sobre um número excessivo de localizações

Observação: essa regra irá gerar um alerta sempre que um determinado usuário acessar mais de 200 documentos cumulativamente em todas as coleções do grupo em uma sessão. Se você deseja configurar limites específicos para cada coleção, use uma regra diferente para cada um.

O alerta na Figura 36 mostra que um usuário não identificado fez download de mais de 200 documentos da coleção de cartão de crédito.

Figura 36. Alerta sobre um número excessivo de localizações

Resumo e próximos passos

Nesta segunda parte da série de três artigos, fornecemos alguns detalhes sobre como configurar a solução, inclusive como configurar mecanismos de inspeção específicos para os roteadores de consultas e para os shards. Proporcionamos algumas recomendações sobre como validar que o S-TAP está capturando o tráfego do MongoDB e enviando-o para o coletor. Por fim, fornecemos amostras de regras de política que você pode usar em seu próprio ambiente, dependendo dos requisitos normativos e de segurança da sua organização.

Na Parte 3, descrevemos um recurso avançado — o bloqueio — bem como relatórios, navegação na auditoria e automatização da aprovação e revisão dos relatórios de auditoria.

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=950934
ArticleTitle=Segurança e Proteção de Dados do InfoSphere Guardium para MongoDB, Parte 2: Configuração e políticas
publish-date=11012013