Proteger e Fortalecer o Dispositivo de Data Warehouse Netezza com o InfoSphere Guardium

Este artigo desenvolve os conceitos básicos de um ambiente Netezza sólido, monitorado e seguro. Para obter isso, o InfoSphere® Guardium®, a solução para monitoramento e auditoria da atividade do banco de dados será usada. A solidez do Netezza com o Guardium será apresentada como um processo de várias etapas. A primeira etapa trata da configuração inicial básica de uma perspectiva de gerenciamento de acesso de usuário e segurança. Será tratada a configuração de usuários, grupos e privilégios. A segunda etapa tira proveito do Guardium Vulnerability Assessment para varrer o ambiente quanto a configurações e privilégios inseguros específicos do Netezza. A terceira etapa detalha como tratar o teste de Vulnerability Assessment com falha fazendo ajustes apropriados na configuração do Netezza. A última etapa é assegurar que a configuração ideal dos privilégios integrados nos estágios primeiro e terceiro não estejam adulterados. O Guardium Entitlement Reports será usado para fazer auditoria do gerenciamento de usuário do Netezza.

Saeid Modares, Solution Specialist, A IBM

Saeid ModaresSaeid Modares é especialista de solução na equipe do InfoSphere Optim e Guardium Technology Ecosystem no laboratório da IBM em Toronto. Ele é líder técnico da Guardium com foco nas soluções de entrega aos novos clientes. Sua experiência inclui consultoria de vendas técnicas, prova de conceitos, implementação e ativação de parceiro de negócios para produtos do InfoSphere Guardium e InfoSphere Optim.



Benjamin Leonhardi, Software Engineer, A IBM

Photo of author Benjamin LeonhardiBenjamin Leonhardi é engenheiro de software na equipe do InfoSphere Warehouse e Netezza Technology Ecosystem no laboratório da IBM em Toronto. Anteriormente, ele era desenvolvedor de software para InfoSphere Warehouse no laboratório de pesquisa e desenvolvimento da IBM em Boeblingen, Alemanha. Ele foi desenvolvedor nas soluções de mineração de dados e texto e de relatórios de mineração.



30/Out/2012

Protegendo e Fortalecendo os Ambientes de Dados

Desenvolver um ambiente de dados seguro e sólido requer o tratamento de todos os aspectos da segurança do banco de dados. Limitar o acesso de dados usando privilégios do usuário e grupo é um exemplo da segurança do banco de dados que requer atenção de quaisquer ambientes de dados novos ou existentes. Similarmente, muitas configurações prontas para uso podem não fornecer a configuração mais ideal e segura para um ambiente de dados fornecido. Algumas dessas configurações são específicas da plataforma, exigindo conhecimento especializado para a melhor configuração. Em adição às alterações contínuas em um ambiente e vulnerabilidades de aplicativo de banco de dados frequentemente identificadas, uma avaliação de todos os componentes que afetam a segurança dos ambientes de dados é recomendada.

O InfoSphere Guardium Database Vulnerability Assessment oferece uma solução que detecta e recomenda correções de numerosas vulnerabilidades de banco de dados, incluindo a configuração insegura e privilégios de objeto, senhas fracas e correções perdidas. As atualizações regulares por meio do Database Protection Service asseguram que os testes estejam baseados nas últimas melhores práticas do segmento de mercado, incluindo CIS e STIG, e atualizações críticas liberadas pelo fornecedor.

O produto é baseado na arquitetura Guardium comprovada, e executa no dispositivo Guardium seguro e sólido. Os testes e resultados de avaliação são armazenados no dispositivo e acessados por meio de uma interface da web segura. A natureza independente não invasiva da solução elimina o impacto do desempenho no servidor de dados. Assegura também uma separação verdadeira de obrigações entre a segurança do banco de dados e as tarefas de administração de banco de dados.

Em adição à solução Vulnerability Assessment abrangente, o Guardium oferece Entitlement Reports para auditoria das autorizações do usuário e grupo sensíveis do Netezza. Esses relatórios fornecem uma captura instantânea dos privilégios de usuário e grupo, incluindo privilégios de acesso, privilégios de objeto e privilégios do sistema específicos a um ambiente de armazém de dados Netezza.

Um ambiente Netezza seguro exige uma configuração de segurança inicial de banco de dados e configurações de sistema operacional relevantes, e a criação de usuários e grupos junto com as designações privilegiadas de acesso. Esse processo deve ser baseado nas melhores práticas de segurança e nos resultados do Vulnerability Assessment e suas recomendações. Também há uma necessidade de recorrer ao teste e revisão das autorizações e configuração depois da configuração inicial. As alterações na autorização ou desvio da configuração bem ajustadas devem ser revistas e escaladas para correções.

O processo completo de proteger e fortalecer um ambiente de dados que será aplicado para um dispositivo de armazém de dados Netezza. Os detalhes da configuração do Netezza e Guardium serão explicados junto com exemplos dos cenários de amostra.


Conceitos Básicos da Segurança do Netezza

A segurança do Netezza é similar a outros bancos de dados e compartilha os mesmos conceitos básicos. Os principais desafios devem ser autenticar usuários e configurar privilégios de acesso de modo correto e seguro, para que os usuários possam apenas ver e modificar seus objetos de banco de dados. Esses dois problemas são resolvidos de modo similar a outros bancos de dados, mas com diferenças menores. Uma diferença entre o Netezza e outros bancos de dados é que ele é um dispositivo que inclui o hardware de servidor, o sistema operacional e o software de banco de dados, de modo que precisamos falar sobre todos os componentes.

Segurança do OS

O OS em um dispositivo de armazém de dados Netezza é um Red Hat Linux modificado ®. Normalmente, o usuário deve apenas fazer modificações pequenas no OS; o gerenciamento de pacotes é, por exemplo, manipulado pelo suporte do Netezza. Por padrão, um aplicativo Netezza tem dois usuários de OS:

  • ROOT — Deve apenas ser usado para o aplicativo do firmware do Netezza e correções de OS
  • NZ — O proprietário do software de banco de dados

É possível criar usuários adicionais, por exemplo, para desenvolvimento ou movimentação de dados. Nesse caso, as diretrizes de segurança básicas do Red Hat devem ser seguidas. É importante minimizar o acesso direto para o dispositivo.

Autenticação do usuário

Os usuários do banco de dados Netezza são gerenciados pelo banco de dados e não estão relacionados para os usuários do OS. Por padrão, a autenticação do usuário é manipulado pelo próprio software do banco de dados. É possível usar o LDAP, mas isso está além do escopo deste artigo. O software do banco de dados Netezza foi originalmente desenvolvido no PostgreSQL e compartilha um monte de características especialmente nos recursos administrativos como a segurança do usuário. O Netezza fornece uma variedade de recursos avançados para restringir acesso do usuário, alguns dos quais nós abordaremos.

Usuários e Grupos

Quando entregue, um dispositivo Netezza tem um único usuário, ADMIN, que é o superusuário do banco de dados, que tem todos os privilégios possíveis e algumas vantagens especiais como um conjunto reservado de recursos do sistema. O ADMIN deve ser usado apenas para configuração inicial e emergências. Em um dispositivo Netezza normal, você cria uma variedade de usuários. É possível criá-los com base nas suas tarefas, mas normalmente, eles devem estar associados às personalidades do mundo real para melhorar as possibilidades de auditoria.

O Netezza também suporta grupos usados para criar funções de usuário com conjuntos de privilégios específicos. Há um grupo especial (PUBLIC), a que cada usuário criado pertence. Ele está sempre presente e não pode ser eliminado. O grupo PUBLIC é um modo de atribuir privilégios a todos os usuários do banco de dados. Você deve ser restritivo com os privilégios dados ao grupo PUBLIC.

Bancos de Dados Netezza

Cada dispositivo Netezza tem uma única instância em execução do Netezza Performance Software (NPS), que é o software do banco de dados que suporta o dispositivo de armazém de dados Netezza. Mas ele pode ter vários bancos de dados. Em contraste com outros sistemas de banco de dados, os bancos de dados não estão relacionados a objetos físicos. Em vez disso, eles são agrupamentos lógicos de objetos de banco de dados para gerenciamento e definição de privilégios. Por exemplo, você teria um banco de dados associado com um aplicativo ou projeto. Cada sistema Netezza tem um banco de dados especial denominado SYSTEM. Esse banco de dados contém o catálogo do sistema, que é de certa forma um banco de dados global que se sustenta acima dos outros bancos de dados no sistema. Os usuários devem ter acesso mínimo ao banco de dados SYSTEM.

Privilégios de Acesso

Depois de um usuário ser autenticado com segurança, o sistema precisa assegurar que ele possa acessar e modificar apenas os objetos do banco de dados como é suposto que façam. Isso é feito similarmente para outros sistemas de banco de dados por meio de privilégios de acesso. Há dois tipos de privilégios de acesso em Netezza, privilégios administrativos e de objeto. Os privilégios administrativos estão associados às tarefas administrativas como gerenciamento de backup, restauração ou hardware. Eles não estão vinculados a um objeto de banco de dados específico. Os privilégios de objeto estão associados a objetos de banco de dados específicos.

Os privilégios podem ser concedidos a usuários ou grupos com o comando GRANT . Os privilégios são sempre aditivos, o que significa que cada usuário tem todos os privilégios concedidos diretamente para ele, em adição a todos os privilégios, que foram concedidos a todos os grupos a que eles pertencem. É possível remover um privilégio de um grupo ou usuário com o comando REVOKE , mas isso removerá os privilégios de todos os usuários que pertencem a esse grupo.

Os privilégios de acesso do Netezza podem ser locais a um banco de dados ou globais, significando que eles aplicam a cada banco de dados no sistema. Para atribuir um privilégio globalmente, é necessário conceder o privilégio enquanto conectado ao banco de dados SYSTEM. Para atribuir o privilégio apenas para um banco de dados específico, é necessário se conectar a esse banco de dados antes de executar GRANT.

Além de GRANT, há um segundo conceito no Netezza que concede privilégios: a propriedade do objeto. Cada objeto de banco de dados no Netezza tem um proprietário — por padrão, o criador do objeto. O proprietário tem todos os privilégios para o objeto. Isso é especialmente útil para bancos de dados porque o proprietário pode funcionar como um administrador para esse banco de dados sem afetar outros bancos de dados ou o banco de dados SYSTEM.


Configurando o Acesso e a Segurança do Usuário do Netezza

Quando você recupera um dispositivo Netezza, as configurações de segurança da camada do OS tem normalmente bons padrões, assim a única etapa crucial é alterar as senhas das contas do usuário do OS. No entanto, enfocaremos na configuração da segurança do banco de dados. Criaremos alguns usuários, grupos e privilégios iniciais, como você faz ao receber um novo dispositivo Netezza.

Os usuários e grupos no Netezza são objetos globais, assim eles podem ser vistos em cada banco de dados. Antes de criar tabelas e carregar dados, é necessário criar um banco de dados. Normalmente, um banco de dados fará referência a um projeto ou aplicativo no ambiente do warehousing. Nosso banco de dados será chamado REPORTDB, e conterá tabelas para um conjunto de relatórios de inteligência de negócios.

Criaremos três usuários:

  • MARK — Este usuário será o proprietário do banco de dados, o que faz dele o administrador do banco de dados.
  • MARIA — Esta usuária será capaz de modificar dados no banco de dados, obtendo todos os privilégios para carregar e modificar dados sem a capacidade de alterar os objetos do banco de dados.
  • KARL — Este usuário será de somente leitura. Por exemplo, ele pode ser usado para acessar de um software de relatórios como o IBM Cognos. Ele poderá ler dados do banco de dados, mas não poderá modificar nenhum objeto ou dado do banco de dados.

Em vez de conceder os privilégios diretamente para esses usuários, nós configuraremos dois grupos, assim poderemos adicionar ou remover usuários mais tarde. Como não previmos ter mais de um usuário administrativo para esse banco de dados, não criaremos um grupo especial para essa função.

Aqui, criaremos dois grupos:

  • REPORTRW — Este é o grupo de acesso de leitura-gravação desse banco de dados. Os membros podem modificar e ler dados nas tabelas do banco de dados.
  • REPORTRO — Este é o grupo de acesso somente leitura desse banco de dados. Os membros podem ler apenas os dados no banco de dados e não podem modificá-los.

Inicialmente, precisamos efetuar login com o usuário ADMIN. É possível ver o banco de dados conectado e o usuário com que efetuou login no prompt do console NZSQL. A primeira coisa que precisamos fazer é criar o REPORTDB:

SYSTEM(ADMIN)=> CREATE DATABASE REPORTDB;

Agora, criaremos os três usuários:

SYSTEM(ADMIN)=> CREATE USER MARK WITH PASSWORD 'markspass';
SYSTEM(ADMIN)=> CREATE USER MARIA WITH PASSWORD 'mariaspass';
SYSTEM(ADMIN)=> CREATE USER KARL WITH PASSWORD 'karlspass';

Depois disso, criaremos o grupo, incluindo usuários durante a criação. Podemos sempre modificar isso posteriormente com a instrução ALTER :

SYSTEM(ADMIN)=> CREATE GROUP REPORTRW WITH ADD USER MARIA;
SYSTEM(ADMIN)=> CREATE GROUP REPORTRO WITH ADD USER KARL;

Agora, podemos configurar os privilégios necessários. Primeiro, vamos fazer MARK o proprietário do banco de dados:

SYSTEM(ADMIN)=> ALTER DATABASE REPORTDB OWNER TO MARK;

MARK é agora o proprietário do REPORTDB e tem todos os privilégios no banco de dados e todos os objetos de banco de dados contidos. Esse é um modo conveniente de delegar responsabilidades administrativas. MARK pode manipular todas as tarefas administrativas desse banco de dados sem interferir com outros bancos de dados. É sempre possível usar os recursos de gerenciamento de carga de trabalho para reduzir a quantidade de recursos do sistema que um usuário ou grupo pode usar. Isso pode ser importante se você, por exemplo, quiser executar alguns bancos de dados de desenvolvimento no mesmo sistema que um banco de dados de produção.

Agora, incluiremos os privilégios necessários ao grupo somente leitura. Queremos que eles sejam capazes de ler as tabelas no banco de dados REPORTDB sem obter acesso a nenhum outro banco de dados. Para fazer isso, precisamos nos conectar ao banco de dados REPORTDB. Qualquer instrução GRANT executada enquanto conectado ao banco de dados SYSTEM será global, significando que ela se aplicará a todos os bancos de dados no dispositivo:

SYSTEM(ADMIN)=> \c REPORTDB

O Netezza tem um privilégio exclusivo, LIST, que permite que usuários vejam objetos e é necessário para se conectar aos bancos de dados. Todos os usuários que trabalham com um banco de dados precisam ter, pelo menos, o privilégio LIST nesse banco de dados:

REPORTDB(ADMIN)=> GRANT LIST, SELECT ON REPORTDB TO REPORTRW, REPORTRO;

Nossos grupos precisarão dos privilégios LIST e SELECT nas tabelas, visualizações e sinônimos no banco de dados. Os privilégios de objeto podem ser concedidos em um objeto de banco de dados específico como uma tabela do cliente ou nas classes de objeto como TABLE:

REPORTDB(ADMIN)=> GRANT LIST, SELECT ON TABLE, VIEW, SYNONYM TO REPORTRO, REPORTRW;

Como executamos o comando GRANT enquanto estávamos conectados ao REPORTDB, esse é um privilégio local. Isso significa que os membros dos grupos podem listar e selecionar todas as tabelas no banco de dados REPORTRD — não em outros bancos de dados. Se quisermos conceder esse privilégio globalmente para todos os bancos de dados, poderemos executar esse comando enquanto estamos conectados no banco de dados do sistema. Privilégios globais devem ser concedidos apenas moderadamente. Agora configuraremos os privilégios para o grupo REPORTRW:

REPORTDB(ADMIN)=> GRANT LIST, SELECT, UPDATE, DELETE, INSERT, TRUNCATE
                        ON TABLE TO REPORTRW;

Esse comando permite que os membros do grupo REPORTRW leiam e modifiquem livremente o conteúdo das tabelas REPORTDB sem alterar a estrutura da tabela.

Também concederemos os privilégios necessários para carregar dados. Carregar dados no Netezza requer a capacidade de criar tabelas externas. Algumas vezes, durante os processos de carga, é necessário criar tabelas temporárias para transformações de dados ELT, assim concederemos o privilégio de criar tabelas temporárias:

REPORTDB(ADMIN)=> GRANT CREATE EXTERNAL TABLE, CREATE TEMP TABLE TO REPORTRW;

Finalmente, permitiremos que nossos usuários de modificação de dados manipulem tabelas. Quando são atualizadas ou excluídas linhas no Netezza, elas não são imediatamente removidas do disco, mas excluídas logicamente. Essas versões da linha do histórico podem ser limpas com o comando GROOM . Essa é talvez a mais importante, mas não a única, tarefa do comando GROOM. Embora essa seja uma tarefa administrativa, faz sentido permitir que o usuário modifique o banco de dados para executar também o comando GROOM. Ela pode ocupar uma quantidade significativa de recursos do sistema, assim deve ser executada apenas por usuários entendidos:

REPORTDB(ADMIN)=> GRANT GROOM ON TABLE TO REPORTRW;

Nós concluímos nossa configuração de segurança básica para o banco de dados REPORTDB. Temos o proprietário do banco de dados, que é capaz de modificar os objetos do banco de dados; temos um grupo de usuários permitidos para modificar dados; e temos um grupo de usuários de somente leitura, que pode executar relatórios e analíticas. Essa é uma configuração clássica, mas depende das suas necessidades. O Netezza é um dispositivo de warehousing, assim as modificações de dados do usuário são normalmente executadas em um ambiente controlado por um número pequeno de usuários administrativos. Por exemplo, nas cargas semanais de dados transacionais ou por meio de scripts de alimentação por gotejamento automatizados. Isso é especialmente verdadeiro porque o Netezza é extremamente fácil de usar e apenas requer uma pequena quantidade de esforços administrativos. Assim, em muitas situações, o grupo de leitura-gravação não será necessário e a modificação de dados pode ser manipulada pelo proprietário do banco de dados.

Situações diferentes podem necessitar de configurações diferentes, o ambiente de desenvolvimento precisará, por exemplo, de um grupo de usuários avançados que possam modificar os objetos do banco de dados, criar procedimentos armazenados etc.

Finalmente, é uma boa ideia criar um usuário administrativo global com a maioria dos privilégios do ADMIN. O usuário ADMIN é, em muitos aspectos, especial e deve apenas ser usado em emergências. Ele tem, por exemplo, um conjunto reservado de recursos associados a ele. Assim, é uma boa prática criar um usuário com todos os privilégios administrativos e de objeto, e utilizá-lo, em vez do usuário ADMIN, para a maioria de tarefas. Essa etapa não é absolutamente necessária, embora:

SYSTEM(ADMIN)=> CREATE USER NEWADMIN WITH PASSWORD 'adminpass';
SYSTEM(ADMIN)=> GRANT ALL ON AGGREGATE, DATABASE, FUNCTION, GROUP, PROCEDURE,
                USER, TABLE, EXTERNAL TABLE, SYSTEM TABLE, SEQUENCE,
                SYSTEM VIEW, MANAGEMENT VIEW, MANAGEMENT TABLE, SYNONYM,
                VIEW, MATERIALIZED VIEW TO NEWADMIN WITH GRANT OPTION;
SYSTEM(ADMIN)=> GRANT all ADMIN TO NEWADMIN WITH GRANT OPTION;

Configurando e Executando o Vulnerability Assessment

O Vulnerability Assessment executa no dispositivo Guardium. O dispositivo pode ser implementado como um dispositivo de hardware ou virtual, como uma máquina virtual VMware. Isso não afeta a configuração ou funcionalidade do Vulnerability Assessment. Para obter detalhes sobre como instalar e implementar o dispositivo Guardium, consulte o guia de instalação.

É presumido que um dispositivo Guardium com configuração básica está disponível. Os conceitos básicos do Guardium, por exemplo, como acessar o dispositivo, também é presumido ser conhecido.

O Vulnerability Assessment pode ser acessado pela interface da web do dispositivo. Efetue login na interface da web e selecione a guia Assess/Harden , seguida pelo Vulnerability Assessment . Como mostrado na Figura 1, a configuração e os resultados da avaliação podem ser acessados por meio desse portal.

Figura 1. Interface do Vulnerability Assessment
Interface do Vulnerability Assessment

O Vulnerability Assessment avalia a configuração do banco de dados e autorização do usuário. As informações sobre esses aspectos do banco de dados estão disponíveis nas tabelas do sistema, ou arquivos e scripts acessíveis em um nível de OS. As informações armazenadas nas tabelas do sistema podem ser acessadas por uma conexão do banco de dados, desde que com as credenciais válidas. A configuração disponível por scripts e arquivos exigirá acesso em um nível de OS com privilégios elevados.

Para prover acesso ao nível de OS, o Configuration Audit System (CAS) é implementado. O cliente CAS, um agente de software pequeno instalado no servidor de dados, periodicamente executa polls nos arquivos de configuração relevantes ou na saída do script de OS e envia dados para o servidor CAS executando no dispositivo Guardium. Essas informações são usadas pelo Vulnerability Assessment para oferecer uma avaliação abrangente de um sistema de banco de dados.

O agente do cliente CAS tem uma instalação de linha de comandos simples. A instalação é executada chamando o script de instalação e fornecendo um caminho para o Java™ e diretórios de instalação. Observe que o Java Runtime Environment deve ser instalado no seu dispositivo Netezza. A instalação deve ser executada em uma conta raiz. A Figura 2 mostra um exemplo da instalação do agente do cliente CAS.

Figura 2. Instalação do CAS
Instalação do CAS

Depois da instalação, o arquivo de configuração guard_tap.ini precisa ser editado. Esse pode ser encontrado no diretório de instalação do CAS em %cas_install_dir%/etc/guard_tap.ini. Duas entradas devem ser editadas: sqlguard_ip, que é o endereço IP do dispositivo Guardium; e tap_ip, que é o endereço IP do dispositivo Netezza host. Esses parâmetros são inicialmente configurados para NULL. Na Figura 3, as entradas sqlguard_ip e tap_ip do guard_tap.ini são editadas para endereços IP válidos.

Figura 3. Editando o arquivo de configuração guard_tap.ini
Editando o arquivo de configuração guard_tap.ini

Para verificar o status do agente do cliente CAS, efetue login como admin e verifique o status do CAS em Local Taps no Administration Console. A Figura 4 mostra o status do agente do cliente CAS que foi instalado e configurado.

Figura 4. Status do CAS
Status do CAS

Passaremos agora a configurar o Vulnerability Assessment. Enquanto conectado como um usuário do Guardium, acesse o aplicativo Vulnerability Assessment clicando na guia Assess/Harden e, em seguida, Vulnerability Assessment, e defina que banco de dados você deseja avaliar.

No painel Security Assessment Finder, clique em New. Isso abre o Security Assessment Builder, como mostrado na Figura 5.

Figura 5. Security Assessment Builder
Security Assessment Builder

Insira uma descrição adequada. É possível ignorar os parâmetros de teste observados. Os testes observados usam os dados de auditoria, que estão disponíveis apenas se o monitoramento da atividade do banco de dados que está sendo executado usando o software S-TAP e uma política de segurança instalada adequadamente. Para esse cenário, é presumido que o Guardium Database Activity Monitoring (DAM) não seja implementado no dispositivo Netezza.

Para que avaliações de banco de dados sejam executadas, é necessária uma origem de dados com credenciais válidas. Para configurar a origem de dados, clique em Add Datasource. No painel Datasource Finder, clique em New. Insira as credenciais de banco de dados para um usuário com acesso às tabelas do sistema. O Guardium fornece um script que cria um usuário do Netezza com os privilégios exigidos necessários para executar os testes do Vulnerability Assessment. Esses scripts estão disponíveis para download como parte do pacote Database User Role Definitions. A Figura 6 mostra uma definição de origem de dados de amostra.

Figura 6. Definição da origem de dados
Definição da origem de dados

Em adição à conexão do banco de dados, precisamos especificar que banco de dados e objetos de OS devem ser monitorados pelo CAS. Os dados dos itens monitorados do CAS serão usados nos testes de avaliação. O Guardium fornece um conjunto de itens para cada ambiente de dados a ser monitorado pelo CAS. Esses conjuntos são conhecidos como modelos.

Para aplicar um modelo do CAS, clique em CAS Support no painel Security Assessment Builder. Com o CAS Assessment Support aberto, selecione UNIX/Netezza Assessments no menu suspenso Select a Template Set, e clique em Add. O conjunto de modelos será incluído na seção monitorada da instância atual, como mostrado na Figura 7. Clique em Save para salvar a configuração.

Figura 7. Suporte de avaliação do CAS
Suporte de avaliação do CAS

Neste estágio, estamos prontos para selecionar e configurar os testes a serem executados no dispositivo Netezza.

Há numerosos testes que podem ser selecionados para serem executados como parte da avaliação. Clicar em Configure Tests no Security Assessment Builder abrirá o painel Assessment Test Selections. Há conjuntos de testes para cada plataforma de banco de dados. Escolher um teste e clicar em Add Selection para incluir o teste na seção Tests for Security Assessment, na parte superior. A Figura 8 mostra todos os testes específicos do Netezza selecionados para avaliação.

Figura 8. Seleção de teste de avaliação
Seleção de teste de avaliação

Alguns testes podem ser ajustados para substituir a configuração padrão ou incluir exceções para a avaliação de privilégio usuário/grupo. Por exemplo, ajustar o privilégio de administrador Global concedido a usuários e/ou grupos oferece a opção de designar um grupo de exceções, como mostrado na Figura 9. Isso nos permite especificar uma lista de usuários que escolhemos para ter o privilégio de administrador global — neste exemplo, os Netezza Trusted Users. Esses usuários com privilégio de administrador global, no entanto, não acionarão uma reprovação do teste de avaliação.

Figura 9. Ajuste do teste de avaliação
Ajuste do teste de avaliação

Nós escolheremos a configuração padrão para todos os testes e executaremos a avaliação. Para executar a avaliação, selecione a avaliação de vulnerabilidade criada no Security Assessment Finder (mostrado na Figura 10) e escolha Run Once Now.

Figura 10. Executando avaliação
Executando avaliação

O status da avaliação é exibido em Guardium Job Queue, mostrado em um painel à direita do Security Assessment Finder. A Figura 11 mostra uma avaliação em andamento. O status alterará para "Complete" quando a avaliação estiver concluída.

Figura 11. Avaliação no Guardium Job Queue
Avaliação no Guardium Job Queue

Depois da avaliação ser concluída, selecione a avaliação no Security Assessment Finder e clique em View Results. A Figura 12 mostra um exemplo de relatório do Vulnerability Assessment.

Figura 12. Resultados da Avaliação
Resultados da Avaliação

Uma pontuação de aprovação é concedida com base no resultado da avaliação. Cada teste recebe uma aprovação ou reprovação, ou é rotulado como erro se o teste não puder ser concluído. Testes reprovados também incluem uma recomendação sobre como corrigir o problema que causa a reprovação do teste. Em seguida, trataremos do número desses testes reprovados para melhorar a segurança do dispositivo Netezza e reduzir sua vulnerabilidade.


Resolvendo as Vulnerabilidades do Dispositivo Netezza

Aqui, abordamos e resolvemos algumas das vulnerabilidades identificadas pelo Guardium Vulnerability Assessment. Dependendo do seu ambiente, talvez seja necessário resolver todas as vulnerabilidades encontradas e definir as exceções.

Comprimento da Senha

O primeiro problema de segurança que o Guardium está destacando é a ausência de um comprimento de senha mínima. Um dispositivo Netezza vem com configurações de segurança padrão, mas em um ambiente com um número grande de usuários e acesso mais amplo, pode ser necessário implementar um conjunto de controles de senha.

Figura 13. Comprimento da senha
Comprimento da senha

O Netezza fornece a capacidade de:

  • Impor o comprimento de senha mínimo
  • Impor a complexidade de senha
  • Bloquear uma conta de usuário depois de um número de tentativas de logins com falha
  • Impor uma alteração de senha depois de um período de tempo especificado
  • Restringir o acesso do usuário para especificar períodos de tempo

A autenticação do usuário também pode ser transferida para um servidor do LDAP — para ter controles de senha consistentes para todas as contas de usuário, por exemplo. Mas isso está além do escopo deste artigo.

Como abordado, o Netezza está integrado no banco de dados PostgreSQL, assim não é de admirar que você encontre muitas das mudanças necessárias nos arquivos de configuração do PostgreSQL. Para alterar o comprimento mínimo da senha, é necessário se conectar ao host Netezza como o usuário nz. Navegue para a pasta que contém os arquivos de configuração, arquivos de log, catálogo do sistema etc.: cd /nz/data.

Agora, precisamos modificar o arquivo postgresql.conf. Por exemplo, com o VI, você localizará o parâmetro próximo ao final do arquivo:

#password_length = 4      # minimum value is 4

Remova o comentário do parâmetro e configure o valor para um mínimo de 8 para satisfazer os requisitos do Guardium:

password_length = 8      # minimum value is 4

Depois de salvar o arquivo, é necessário reiniciar o software do banco de dados do Netezza para ativar a configuração:

[nz@netezza data]$ nzstop;nzstart

Tentativas Inválidas

A segunda configuração que o Guardium detecta como uma vulnerabilidade é a configuração de tentativas inválidas. Impor isso assegura que os usuários fiquem bloqueados depois de um número definido de tentativas de login erradas. Isso assegura que usuários com senhas inseguras não possam ser adivinhadas em um ataque de força bruta.

Figura 14. Tentativas Inválidas
Tentativas Inválidas

A configuração pode ser localizada no arquivo de configuração postgresql.conf, similar ao comprimento mínimo da senha. Por padrão, a configuração está desativada:

#invalid_attempts = 0     # zero - no limit

Remova o comentário da linha retirando o caractere # e altere o valor para 3 para satisfazer os requisitos do Guardium:

invalid_attempts = 3     # zero - no limit

Como antes, é necessário reiniciar o dispositivo Netezza para ativar essa configuração:

[nz@netezza data]$ nzstop;nzstart

Se um usuário inserir uma senha errada três vezes, a conta será bloqueada e precisa ser desbloqueada por um administrador com o seguinte comando:

SYSTEM(ADMIN)=> alter user %username% reset account;

A autenticação de senha não usa texto não criptografado

Figura 15. A autenticação de senha não usa texto não criptografado
A autenticação de senha não usa texto não criptografado

Essa descoberta é realmente mais complexa. O Netezza permite que você especifique tipos de conexão diferentes para faixas de IP diferentes. É possível especificar se as senhas devem ser transmitidas em texto não criptografado ou com hash, e especificar se uma faixa de IPs deve se conectar usando uma conexão SSL criptografada segura. Os tipos de conexão são armazenados no arquivo /nz/data/pg_hba.conf e podem ser editados diretamente lá. Mas isso não é incentivado. Em vez disso, você deve usar os comandos admin SQL que o Netezza fornece para gerenciar os tipos de conexão.

Para exibir as conexões definidas atualmente, é necessário se conectar ao dispositivo Netezza como um administrador. Execute o comando a seguir para exibir todos os tipos de conexão disponíveis:

SYSTEM(ADMIN)=> show connection;

Em um novo sistema, você deve ver algo como o que segue:

SYSTEM(ADMIN)=> show connection;
CONNID | CONNTYPE | CONNDB | CONNIPADDR |   CONNIPMASK    | CONNAUTH
-------+----------+--------+------------+-----------------+----------
     1 | local    | all    |            |                 | trust
     2 | host     | all    | 127.0.0.1  | 255.255.255.255 | password
     3 | host     | all    | 0.0.0.0    | 0.0.0.0         | md5
(3 rows)

É possível definir vários tipos de conexão para a mesma faixa de IPs. Nesse caso, a primeira entrada de ajuste será usada. No nosso exemplo, temos três tipos: um tipo de local interno, uma autenticação de senha de texto não criptografada para os usuários do host local e uma autenticação de hash md5 para usuários de fora da máquina.

É possível desconsiderar a conexão local visto que ela é usada internamente pelo Netezza. O Guardium está reclamando sobre a autenticação de texto não criptografado (senha) no localhost no tipo de conexão 2. Esse não é nenhum risco à segurança aparente já que nenhuma senha é transmitida pela rede. Podemos, no entanto, definir uma exceção para essa vulnerabilidade.

A alternativa é alterar o tipo da conexão 2 também para md5. Faremos isso para demonstrar como trabalhar com tipos de conexão. É importante manter a ordem das conexões em mente. A primeira conexão do alto que corresponda ao endereço IP da chamada de entrada será aplicada. É importante restringir mais os tipos de conexão primeiro. O segundo problema é que não há nenhum comando ALTER CONNECTION TYPE . Assim, não é possível atualizar o segundo tipo de conexão. Podemos apenas excluí-la e incluí-la novamente. Isso alterará a ordem das conexões.

Para manter a ordem das conexões e atualizar o tipo de conexão 2, precisamos descartar e recriar o tipo de conexão 3 para manter a ordem intacta. Descarte os tipos de conexão 2 e 3:

SYSTEM(ADMIN)=> drop connection 3;
SYSTEM(ADMIN)=> drop connection 2;

Agora recrie o tipo de conexão 2 com o parâmetro CONNAUTH alterado para md5:

SET CONNECTION HOST DATABASE 'all' IPADDR '127.0.0.1' IPMASK '255.255.255.255' AUTH md5;

E recrie o tipo de conexão 3 como ela era antes:

SET CONNECTION HOST DATABASE 'all' IPADDR '0.0.0.0' IPMASK '0.0.0.0' AUTH md5;

Agora você alterou a autorização para MD5 para todas as conexões — mesmo as locais.

Figura 16. Privilégios de objeto concedidos ao público
Privilégios de objeto concedidos ao público

O grupo PUBLIC no Netezza é um grupo de usuário especial que contém todos os usuários do sistema. Quaisquer privilégios incluídos nesse grupo estão disponíveis para todos os usuários. Normalmente, você deve ter o mínimo de privilégios possível associado ao grupo PUBLIC. Para ver que privilégios estão associados ao grupo PUBLIC, execute o seguinte comando em nzsql:

SYSTEM(ADMIN)=> \dpg PUBLIC
Group object permissions for group 'PUBLIC'
Database Name |           Object Name            | L S I U D T L A D B L G O E
C R X A | D G U T E X Q Y V M I B R C S H F A L P N S
---------------+----------------------------------+-----------------------------
--------+---------------------------------------------
 GLOBAL        | _V_JDBC_TABLETYPES2              | X X
        |
 GLOBAL        | _V_GROUP_PRIV                    | X X
        |
 GLOBAL        | _V_USER_PRIV                     | X X
                ...

É possível ver que, por padrão, um grande número de visualizações é legível pelo grupo PUBLIC. Algumas dessas parecem conter informações confidenciais como nomes de tabelas, privilégios de usuário e consultas executadas no sistema. Isso será uma violação clara da segurança, visto que as consultas podem conter informações confidenciais — nas condições WHERE , por exemplo. No entanto, quando você seleciona dados nas visualizações, o Netezza assegura que nenhum usuário tenha acesso às informações que ele não deve ver. As visualizações retornam informações diferentes para cada usuário e não mostrará informações às quais um usuário não deve ter acesso.

As visualizações são necessárias para a conexão com JDBC, ODBC etc. e para o uso do cliente do usuário gráfico NZAdmin e não deve ser removido do grupo PUBLIC. Nós incluiremos uma exceção para esses objetos para o Guardium VA. Isso é aconselhável, visto que ainda desejamos ser avisados sobre algum outro privilégio incluído no grupo PUBLIC e poder fornecer acesso às informações confidenciais para cada usuário.

Para visualizar a lista completa de objetos que falharam nesse teste, clique no título do teste Object privileges granted to public .

Figura 17. Privilégios de objeto concedidos ao público
Privilégios de objeto concedidos ao público

Para criar uma exceção para esses objetos, escolha o teste Assessment Test Tuning for the Object privileges granted to public (Netezza) na lista Assessment Test Selection . Selecione Netezza Allowed Grants to Public no menu suspenso do grupo Exception.

Figura 18. Ajuste de Teste
Ajuste de Teste

Clicar no ícone pequeno à direita do menu suspenso abre o editor de grupos. Inclua os objetos na lista mostrada na Figura 22 para esse grupo, como mostrado a Figura 24. Salve o giro de teste com o grupo de exceção incluído e execute novamente o teste Vulnerability Assessment. Os objetos incluídos no grupo serão excluídos no teste, mas outros objetos reprovados nesse teste serão sinalizados.

Figura 19. Grupo de Exceção
Grupo de Exceção

Vimos algumas das vulnerabilidades que o Guardium identifica em um sistema vazio. Algumas dessas podem ser facilmente corrigidas; outras não são vulnerabilidades reais e podem ser colocadas em uma lista de exceções. Depois dessas modificações iniciais, podemos executar o relatório de avaliação de vulnerabilidade em uma base regular e seremos notificados sobre qualquer vulnerabilidade incluída no sistema.


Fazendo Auditoria do Uso do Netezza de Alterações

O Vulnerability Assessment detecta autorizações de usuários inseguros e faz recomendações sobre como melhorar privilégios de usuário e grupo. No entanto, há uma necessidade de fazer auditoria continuamente nas autorizações do usuário. O Guardium Entitlement Reports simplifica a revisão e auditoria de diversos privilégios de usuário. Os relatórios de autorização podem ser acessados pela guia View .

Figura 20. Relatórios de Autorização de DB
Relatórios de Autorização de DB

A seguir, está uma lista de relatórios de autorização de DB específicos do Netezza:

  • Netezza Obj Privs Granted
  • Netezza Admin Privs by DB Username
  • Netezza Obj Privs by DB Username
  • Netezza Obj Privs by Group
  • Netezza Admin Privs Granted
  • Netezza Group/Role Granted to User
  • Netezza Global Admin Privs To Users and Groups
  • Netezza Global Obj Privs To Users and Groups
  • Netezza Admin Privs By DB Username Group
  • Netezza Admin Privs by Group

As informações de autorização estão baseadas nos dados das tabelas de sistema relevantes. Portanto, para preencher os relatórios de autorização, é necessária uma origem de dados com credenciais adequadas para acessar essas tabelas de sistemas. Para configurar o upload dos dados, abra a guia Build Reports na guia Monitor/Audit e clique em Custom table builder.

Figura 21. Opções de desenvolvimento de relatórios
Opções de desenvolvimento de relatórios

Selecione um relatório de autorização desejado na lista e clique em Upload Data.

Figura 22. Tabelas customizadas
Tabelas customizadas

Inclua uma origem de dados clicando em Add Datasource e selecionando uma origem de dados existente ou criando uma nova origem de dados inserindo credenciais com acesso a tabelas de sistemas relevantes. Use a ferramenta Scheduling para planejar a frequência de importação de dados, ou clique em Run Once Now para o upload de dados ad hoc. A figura abaixo apresenta uma amostra do painel Import Data configurado.

Figura 23. Atualizando Dados
Atualizando Dados

O relatório será preenchido com dados do dispositivo Netezza. A figura abaixo mostra um exemplo do relatório Netezza Group/Role Granted to User preenchido com os dados de autorização de amostra.

Figura 24. Relatório de autorização preenchido
Relatório de autorização preenchido

Agora somos capazes de fazer auditoria da configuração do usuário e assegurar que quaisquer alterações feitas sejam aceitáveis.


Conclusão e Ponto de Vista

Neste artigo, explicamos os conceitos básicos de proteção de um dispositivo Netezza com Guardium. Descrevemos o modelo de segurança básico do Netezza e fornecemos um exemplo de uma configuração de segurança inicial. Em seguida, configuramos e executamos um Guardium Vulnerability Assessment do dispositivo Netezza, e abordamos e resolvemos um número de vulnerabilidades identificadas. Finalmente, percorremos os relatórios de autorização do Guardium.

Juntos, as avaliações de vulnerabilidade e relatórios de autorização permitem que uma empresa monitore e identifique alterações potencialmente perigosas para configuração de segurança do Netezza que podem colocar informações confidenciais do cliente no risco. O artigo abordou os aspectos básicos de proteção de um dispositivo Netezza com Guardium. Tópicos mais avançados abordariam a implementação da autenticação do LDAP, a segurança no nível de linha ou criptografia SSL no Netezza e a implementação de auditoria e recursos do Guardium mais avançados, como S-GATE Termination para restringir o acesso às informações confidenciais.

Recursos

Aprender

Obter produtos e tecnologias

  • Crie seu próximo projeto de desenvolvimento com o software de teste IBM, disponível para download diretamente no developerWorks.
  • Agora é possível usar o DB2 gratuitamente. Faça o download do O DB2 Express-C, uma versão gratuita do DB2 Express Edition para a comunidade que oferece os mesmos recursos de dados centrais que o DB2 Express Edition e fornece uma base sólida para desenvolver e implementar aplicativos.

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=843370
ArticleTitle=Proteger e Fortalecer o Dispositivo de Data Warehouse Netezza com o InfoSphere Guardium
publish-date=10302012