Monitore a Atividade do Banco de Dados para os Usuários dos Aplicativos com o Guardium e o WebSphere Application Server

Uma abordagem para monitorar a atividade do banco de dados para os usuários dos aplicativos em ambientes de conexões agrupadas sem alterar o aplicativo

Certos requisitos de auditoria exigem que a atividade específica do banco de dados possa ser rastreada até o usuário que é responsável por ela. Isso é particularmente desafiador em cenários de aplicativos em que as conexões agrupadas com o banco de dados são usadas e o aplicativo em si é responsável pela autenticação e autorização. Este artigo apresenta uma abordagem geral para aplicativos do WebSphere® Application Server que permite que as soluções de monitoramento da atividade do banco de dados, como o InfoSphere® Guardium® , atribuam de forma confiável o usuário do aplicativo à atividade do banco de dados sem precisar alterar os respectivos aplicativos.

Sven Herschel, Certified Guardium Technical Sales Professional, IBM

Photo of authorCom nove anos de experiência como IT Specialist, arquiteto de software e engenheiro de requisitos com uma formação sólida em bancos de dados, desenvolvimento da web e certificados digitais, Sven Herschel passou a fazer parte da IBM como Profissional Técnico Cliente para o InfoSphere Guardium. É responsável por todo o ciclo pré-vendas, desde o primeiro contato até as provas de conceito no site. Nessa função, possui experiência prática com os requisitos do cliente relacionados à segurança do banco de dados e conformidade.



Marc Schwind, Software engineer, IBM

Photo of authorMarc Schwind é engenheiro de software no Laboratório de Pesquisa e Desenvolvimento IBM em Boeblingen, Alemanha. Tem nove anos de experiência como desenvolvedor nas áreas de J2EE, WebSphere Application Server, integração de negócios e gerenciamento de processos de negócios. Durante a carreira de desenvolvedor, foi membro da equipe de gerenciamento de processos de negócios da SWAT, assessorando os clientes sobre melhores práticas e prestando suporte vital em situações críticas para clientes do mundo todo. Desde 2011, é líder de uma equipe de desenvolvimento para a oferta de BPM da IBM e atualmente trabalha com a integração de sistemas de Enterprise Content Management. Marc é formado em Engenharia da Tecnologia da Informação e passou a fazer parte da IBM em 2003.



17/Set/2012

Visão geral

Vários requisitos de conformidade, como o PCI-DSS e o SOX, exigem que as atividades específicas no banco de dados da empresa sejam auditadas e possam ser atribuídas à pessoa responsável pela respectiva atividade. Ao mesmo tempo, os aplicativos atuais vêm assumindo cada vez mais a responsabilidade de autenticar e autorizar os próprios usuários, em vez de deixar essa tarefa para o banco de dados. Nessa situação, é praticamente impossível, no nível do banco de dados, rastrear ações individuais no banco de dados até o usuário do aplicativo responsável por uma determinada atividade. As abordagens já existentes — e geralmente proprietárias — baseiam-se em recursos do banco de dados como reautenticação ou contextos confiáveis, que permitem que o aplicativo alterne o usuário que é proprietário do banco de dados e, portanto, possibilita o monitoramento adequado.

Geralmente, tanto a reautenticação quanto os contextos confiáveis são específicos para o fornecedor e frequentemente exigem que o usuário reautenticado seja conhecido pelo banco de dados. Com números cada vez maiores de usuários de aplicativos, principalmente nos aplicativos da web que podem ter grandes quantidades de usuários, essa abordagem se torna cada vez menos prática e, conforme o indicado acima, é cada vez menos usada no desenvolvimento de aplicativos.

Este artigo apresenta uma abordagem geral para todos os aplicativos do WebSphere Application Server que não requer mudanças nos aplicativos já existentes, permite que as ferramentas de monitoramento de banco de dados, como o InfoSphere Guardium, correspondam de forma confiável o usuário do frontend do aplicativo à atividade do banco de dados correspondente, deixa a autenticação e a autorização para o aplicativo ou contêiner do aplicativo, respectivamente, e finalmente, funciona com ligeiras modificações em todos os grandes sistemas de gerenciamento de bancos de dados relacionais.

O desafio

Em aplicativos típicos, como os de J2EE, o contêiner mantém um grupo de conexões com o banco de dados que são autenticadas por meio de um usuário técnico do aplicativo em execução. O usuário do aplicativo só se autentica para o aplicativo, não para o banco de dados; consequentemente, as informações sobre o usuário do aplicativo são perdidas em qualquer abordagem de criação de log ou monitoramento do banco de dados que reside no servidor do banco de dados, como mostra a Figura 1.

Figura 1. Topologia típica do aplicativo, em que as informações do usuário do aplicativo são perdidas na camada do banco de dados
Topologia típica do aplicativo, em que as informações do usuário do aplicativo são perdidas na camada do banco de dados

Por que isso é importante?

Vários regulamentos de conformidade, como o PCI-DSS e o SOX, incluem requisitos voltados para o controle de dados e podem exigir que o monitoramento seja habilitado nos bancos de dados para ver quais dados foram acessados, quando e por quem. Além disso, requisitos internos podem exigir que os usuários privilegiados sejam monitorados para proteger os dados contra o acesso não autorizado e deixar o trabalho do DBA mais transparente.

No cenário do PCI-DSS, o foco do monitoramento é o acesso às informações de cartão de crédito. Para monitorar o acesso às informações de cartão de crédito por meio de aplicativos que usam conexões agrupadas, é necessário determinar o usuário real do aplicativo por trás do usuário técnico que se conecta ao banco de dados. Com o desacoplamento do acesso a dados e do gerenciamento de usuários, conforme o descrito anteriormente, essa tarefa se torna arbitrariamente complexa.


A abordagem deste artigo

Visão geral

A abordagem deste artigo é transmitir as informações do usuário do aplicativo para o banco de dados como metadados, para que as ferramentas de monitoramento da atividade do banco de dados possam pegar essas informações.

Ao mesmo tempo, essas metainformações transmitidas são ignoradas pelo sistema de gerenciamento de banco de dados (DBMS), de modo que nem o DBMS (incluindo a atividade do DB, seu sistema de permissões e o esquema de autorização e autenticação) nem o WebSphere Application Server (incluindo o seu recurso de agrupamento de conexões) são afetados e funcionarão com a mesma eficiência de antes. Além disso, não é necessário alterar o aplicativo em si, porque essa abordagem não é invasiva para o aplicativo.

Isso é feito implementando uma classe DataStoreHelper customizada que intercepta cada transação e é responsável por identificar o usuário do aplicativo e transmiti-lo para o sistema Guardium para monitoramento e avaliação.

Pré-requisitos

Para que essa abordagem funcione, os requisitos a seguir devem ser preenchidos.

  1. O aplicativo deve usar o conjunto de conexões do WebSphere que é configurado dentro do WAS e fornecido para o aplicativo por meio de um nome JNDI. Isso garante que o DataStoreHelper desenvolvido posteriormente possa ser incluído de forma não invasiva no aplicativo.
  2. O aplicativo usa a segurança de aplicativos do WebSphere porque o código se baseia no usuário do aplicativo recuperado estatisticamente a partir da API da classe com.ibm.websphere.security.auth.WSSubject .

Implementação

Ao configurar uma origem de dados para usar com o seu aplicativo, o WebSphere Application Server permite especificar uma classe auxiliar de armazenamento de dados.

Esse auxiliar faz a ponte entre o código específico do fornecedor do banco de dados e a interface genérica javax.sql.DataSource . Tipicamente, não é necessário especificar uma classe auxiliar customizada, já que o WebSphere Application Server fornece classes auxiliares padrão de armazenamento de dados para os bancos de dados mais utilizados.

No caso deste artigo, isso representa um ponto de plugue perfeito para transmitir a identidade do usuário do aplicativo para o sistema Guardium, já que a interface DataStoreHelper define um método doConnectionSetupPerTransaction(...) , permitindo que você intercepte a conexão por transação antes que ela seja usada. A ideia é recuperar o nome do usuário conectado no momento e incluí-lo em uma instrução SQL especial executada na conexão antes que ela seja usada para executar as instruções reais relacionadas ao aplicativo.

A instrução SQL simulada a seguir pode ser monitorada facilmente pelo sistema Guardium e possibilita a correlação de uma conexão e um usuário do aplicativo responsável pelas instruções executadas na transação atual, como mostra a Listagem 1.

Lista 1. Transmitindo o nome do usuário atual do aplicativo por transação
public void doConnectionSetupPerTransaction(Subject subject, String user,
                                            Connection conn, boolean reauth,
                                            Object properties) throws SQLException {
                
    StringBuffer sql = new StringBuffer();
    sql.append("SELECT 'GuardAppEvent:Start','GuardAppEventUserName:");
    sql.append(WSSubject.getCallerPrincipal());
    sql.append("' FROM SYSIBM.SYSDUMMY1");
    Statement stmt = conn.createStatement();
    stmt.execute(sql.toString());
}

À primeira vista, pode parecer estranho recuperar o nome do principal a partir do encadeamento por meio de uma chamada estática para WSSubject, porque já há um sujeito e até mesmo um nome de usuário passado. Entretanto, olhando para ele novamente, esse é o sujeito usado pela camada do J2C (sujeito do usuário técnico) para se autenticar para o banco de dados.

O usuário que é passado é NULL na maioria dos casos. Ele só é configurado nos casos em que o aplicativo usa a autenticação baseada em componentes que fornece o nome do usuário e a senha diretamente — o qual seria, novamente, o usuário técnico.

Ao implementar doConnectionCleanup(Connection conn), você também pode informar o sistema Guardium sempre que a conexão associada ao usuário atual é liberada. A única diferença é que a instrução SQL simulada envia 'GuardAppEvent:Released' em vez de 'GuardAppEvent:Start', como mostra a Listagem 2.

Lista 2. Transmitindo o nome do usuário atual do aplicativo na limpeza da conexão
public boolean doConnectionCleanup(Connection conn) throws SQLException {
                
StringBuffer sql = new StringBuffer();
sql.append("SELECT 'GuardAppEvent:Released','GuardAppEventUserName:");
sql.append(WSSubject.getCallerPrincipal());
sql.append("' FROM SYSIBM.SYSDUMMY1");
                
Statement stmt = conn.createStatement();
stmt.execute(sql.toString());
return super.doConnectionCleanup(conn); 
}

Configuração

  1. Depois de compilar e compactar o DataStoreHepler, coloque o arquivo JAR na pasta /lib da sua instalação do WAS
  2. Efetue login no console administrativo do WAS
  3. Na página de configuração da origem de dados, selecione Specify a user defined data store helper e, em seguida, forneça o pacote completo e o nome de classe da sua classe DataStoreHelper, como mostra a Figura 2.
    Figura 2. Especificando uma classe DataSourceHelper customizada
    Especificando uma classe DataSourceHelper customizada
  4. Salve as suas configurações e reinicie o WebSphere Application Server. O auxiliar de DataStore está configurado e pronto para usar.

Resultado

Para este artigo, a configuração foi testada abrindo duas janelas de navegador, e foi efetuado o login no aplicativo com dois usuários diferentes, chamados marc e sven. O aplicativo em si é conectado ao banco de dados por meio de um usuário técnico porque, de modo geral, na maioria dos cenários, não é recomendável conectar o aplicativo ao banco de dados usando o proprietário da instância. Em seguida, o aplicativo consulta uma tabela sensível. Como é possível ver na Figura 3, todas as consultas vêm da mesma sessão do banco de dados (3719), utilizando o mesmo usuário técnico.

Figura 3. Log de atividades do Guardium atribuindo o usuário final do frontend às consultas de banco de dados
Log de atividades do Guardium atribuindo o usuário final do frontend às consultas de banco de dados

Além disso, observe que o usuário do frontend/aplicativo é marcado claramente na coluna Event User Name e são atribuídas a ele as instruções que ele executou em sua sessão (de aplicativo). Missão cumprida.

Possíveis extensões

Os metadados atuais que estão sendo transferidos para o banco de dados se aplicam a um sistema de banco de dados DB2, já que a seleção simulada é emitida com relação a SYSIBM.SYSDUMMY1. Em outros sistemas de banco de dados, essa instrução teria que ser adaptada para refletir a tabela que vem com o respectivo DBMS. Estes são alguns exemplos:

  1. DB2: SELECT 'GuardAppEvent:Start','GuardAppEventUserName:[insira o nome do usuário]' FROM SYSIBM.SYSDUMMY1
  2. Oracle: SELECT 'GuardAppEvent:Start','GuardAppEventUserName:[insira o nome do usuário]' FROM DUAL
  3. MS-SQL: SELECT 'GuardAppEvent:Start','GuardAppEventUserName:[insira o nome do usuário]'
  4. PostgreSQL: SELECT 'GuardAppEvent:Start','GuardAppEventUserName:[insira o nome do usuário]'

Soluções alternativas

É possível usar as seguintes soluções alternativas para esse desafio.

  • Criação de log do aplicativo.
  • Reautenticação/contextos confiáveis
  • Coleta de logs e mesclagem baseada no registro de data e hora.

Criação de log do aplicativo

Já que o aplicativo se autentica e autoriza todo o acesso ao aplicativo, parece que o aplicativo em si seria um bom local para monitorar e registrar todo o acesso a dados.

Entretanto, essa abordagem tem muitas desvantagens. Primeiro, o log do aplicativo deve ser consistente. Por exemplo, se, durante o desenvolvimento, os requisitos de log mudarem ou se o desenvolvimento omite acidentalmente um processo de criação de log, o log resultante não é tão útil. Além disso, registrar exatamente as coisas que precisam de auditoria não é uma tarefa trivial, porque cada acesso ao banco de dados registrado teria que incluir o usuário do aplicativo, e o aplicativo teria que determinar sozinho qual acesso ao banco de dados precisa de auditoria.

Em segundo lugar, deixar o monitoramento da atividade do banco de dados para uma solução dedicada diretamente no servidor do banco de dados tem a vantagem adicional de que o acesso que ocorre fora do aplicativo, como o acesso pelo console por meio de usuários privilegiados ou o acesso por meio de pontes JDBC ou ODBC, ainda seria monitorado por essas soluções baseadas em agentes. A maioria dos regulamentos de conformidade exige uma solução abrangente de auditoria que monitora 100% de todos os acessos ao banco de dados.

Reautenticação e contexto confiável

Os sistemas de banco de dados atuais suportam mecanismos para configurar o proprietário efetivo de uma conexão com o banco de dados. No DB2, o desenvolvedor pode escolher entre reautenticar uma conexão (que normalmente é muito mais eficiente do que abrir uma nova conexão) ou aproveitar os chamados contextos confiáveis, como a capacidade do banco de dados de confiar no proprietário da conexão (anterior) para autenticar um usuário diferente e substituí-lo por esse usuário diferente.

As duas abordagens preencheriam o requisito da rastreabilidade da atividade do banco de dados até um determinado usuário, porque são específicas para o fornecedor e geralmente incorrem em gerenciamento e configuração adicionais. Frequentemente isso não é viável, nem com aplicativos menores.

Coleta de log e mesclagem baseada no registro de data e hora

Essa abordagem tem o objetivo de consolidar a atividade procedente de diversas origens, como o banco de dados e o servidor do aplicativo, comparando os registros de data e hora.

Já que essa abordagem só pode ser heurística, ela não poderá correlacionar as origens com 100% de confiança. Portanto, este artigo não detalhará as suas vantagens e desvantagens, já que não é uma abordagem viável para o cenário de conformidade rigorosa descrito anteriormente.

As desvantagens descritas para as diversas abordagens justificam outro método ajustado especificamente ao cenário de conformidade, como a transmissão do usuário do aplicativo na forma de metadados para o banco de dados por transação.

Esses metadados são ignorados pelo banco de dados e não afetam o seu sistema de gerenciamento nem o conjunto de conexões com banco de dados no servidor do aplicativo. Entretanto, mesmo assim, isso monitorado pelos sistemas de gerenciamento de atividade do banco de dados, como o InfoSphere Guardium Database Activity Monitor.


Conclusão

Este artigo mostrou a você uma abordagem geral para aplicativos do WebSphere Application Server que permitem que as soluções de monitorado da atividade do banco de dados, como o InfoSphere Guardium, atribuam de forma confiável um usuário do aplicativo à atividade do banco de dados sem precisar alterar os respectivos aplicativos.


Download

DescriçãoNomeTamanho
Sample source code for this tutorialSampleGuardiumDataStoreHelper.zip10KB

Recursos

Aprender

Obter produtos e tecnologias

Discutir

  • Participe da comunidade do My developerWorks. Entre em contato com outros usuários do developerWorks, enquanto explora blogs, fóruns, grupos e wikis orientados a desenvolvedores.

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=834671
ArticleTitle=Monitore a Atividade do Banco de Dados para os Usuários dos Aplicativos com o Guardium e o WebSphere Application Server
publish-date=09172012