Torne recursos do DB2 seguros usando o Tivoli Access Manager para Sistemas Operacionais

Aprenda como tornar seguros seus recursos do IBM® DB2® usando o Tivoli® Access Manager para Sistemas Operacionais (TAMOS). TAMOS é uma solução da IBM para tornar recursos seguros em sistemas operacionais UNIX® e Linux®. Este artigo o guiará através de dois cenários reais para mostrar como usar o TAMOS para definir políticas que protejam os recursos do DB2. É possível usar esses cenários como a fundação para a construção de uma solução de segurança corporativa para seu banco de dados.

Aditi Prasad, Associate Software Engineer, IBM

Aditi Prasad photoAditi Prasad é Engenheira de Software Associada. Ela trabalha atualmente com o Tivoli Security Products no IBM India Software Lab, em Pune.



Nishant Sinha, DB2 Advanced Technical Support Analyst, IBM

Sinha Nishant photoNishant Sinha é analista de suporte técnico avançado do DB2 no Laboratório de Software da IBM da Índia, em Pune. Seu principal foco é ajudar clientes do IBM DB2 no mundo todo.



11/Mai/2010

Introdução

Todo sistema de gerenciamento de banco de dados deve proteger dados contra o acesso e modificação não autorizados. Isso também se aplica ao IBM DB2 Database para Linux, UNIX e Windows® (DB2). O DB2 usa vários mecanismos, como autenticações, autorizações e privilégios para atender essa necessidade. No entanto, para proteger seus recursos (como processos, contêineres e arquivos de sistema), o DB2 confia, na maioria das vezes, no sistema operacional nativo.

O Tivoli Access Manager para Sistema Operacional (TAMOS) é uma solução da IBM que usa uma abordagem de gerenciamento de política centralizada para proteger recursos em sistemas operacionais UNIX ou Linux. Assim, é possível usá-lo para fornecer uma camada extra de segurança além da fornecida pelo sistema operacional nativo.

A seguir, uma visão geral dos tópicos cobertos por este artigo:

  • Introdução ao TAMOS e uma visão geral de como instalá-lo e configurá-lo
  • Como usar políticas de autorização para proteger recursos do DB2
  • Cenários reais que mostram potenciais brechas de segurança do sistema de gerenciamento de banco de dados e também do sistema operacional nativo no qual ele está instalado e como usar o TAMOS para fechar essas brechas
  • Como controlar e monitorar as operações contra processos DB2

O que é o TAMOS

Os sistemas operacionais UNIX e Linux apresentam várias preocupações com segurança a partir de uma perspectiva corporativa. O TAMOS trata dessas preocupações fornecendo controle de acesso no nível do sistema operacional para os sistemas operacionais UNIX e Linux. A técnica de gerenciamento de política centralizada do TAMOS evita o acesso não autorizado e monitora os acessos a dados sensíveis e recursos.

O TAMOS é implementado como uma série de daemons, extensões kernel e arquivos de controle para o sistema operacional UNIX ou Linux. As extensões kernel do TAMOS interceptam todas as chamadas do sistema. O daemon de autorização centralizada, chamado pdosd participa, então, de todas as decisões de autorização quando uma chamada do sistema é feita.

O fluxograma na Figura 1 demonstra como o TAMOS implementa a camada de segurança interceptando as chamadas do sistema no nível do kernel.

Figura 1. Fluxograma de exemplo para ilustrar a interceptação do kernel do TAMOS
file open > open mapped to pdos_open > TAMOS calls authorization > Is permitted? > if yes, real open and file descriptor; if no, denied

Há vários pré-requisitos de sistema que devem ser satisfeitos antes de começar a instalar e configurar o IBM TAMOS. No entanto, uma descrição detalhada desses pré-requisitos está fora do escopo deste artigo. Para detalhes sobre pré-requisitos, consulte o "Guia de Instalação do TAMOS," cujo link está na seção Recursos no final deste artigo.

Instalação

É possível instalar o TAMOS de quatro maneiras:

  • Instalação multiplataforma em modo GUI
  • Instalação multiplataforma em modo painel
  • Instalação multiplataforma em modo silencioso
  • Instalação nativa

O exemplo nesta seção descreve o primeiro tipo de instalação — como executar uma instalação em modo GUI do TAMOS e, especificamente, em um servidor Linux. Os exemplos nas seções seguintes deste artigo também consideram o uso do sistema operacional Linux.

Para iniciar uma instalação interativa em modo GUI, localize seu CD do TAMOS e execute o programa com o nome: install_amos_platform, onde platform representa o nome do seu sistema operacional. Este programa inicia o processo de instalação iniciando o assistente de instalação. Para a instalação de exemplo em um sistema Linux descrito neste artigo, o programa de instalação é ./install_amos_linux.

As Figuras 2 e 3 mostram capturas de tela de exemplo do assistente de instalação do TAMOS.

Figura 2. Tela de instalação do TAMOS
Welcome screen of the InstallShield Wizard for TAMOS
Figura 3. Configurações do Sistema Recomendadas
System check shows current memory, required memory, space requirements, and whether operating system is at supported level

Ao prosseguir pelo assistente, ele o guiará pela instalação e configuração do tempo de execução TAM, usando o servidor do LDAP adequado.

A instalação em modo silencioso usa arquivos de resposta para instalar de modo silencioso. A instalação nativa usa o utilitário de instalação de software nativo fornecido pelo sistema operacional. Novamente, é possível consultar o "Guia de Instalação do TAMOS," cujo link está na seção Recursos no final deste artigo para instruções detalhadas de instalação.

Configurando o TAMOS

Esta seção explica como configurar o TAMOS em um sistema operacional UNIX ou Linux após executar a instalação nativa. Ao usar a multiplataforma Installshield para a instalação, o TAMOS já está configurado como parte do processo de instalação. No entanto, caso execute uma instalação nativa, ainda é necessário configurar o TAMOS após a instalação.

O comando usado para configurar o TAMOS após uma instalação nativa é pdoscfg. A seguir estão as opções de configuração necessárias que devem ser especificadas na configuração inicial:

  • branch— ramificação da política na qual o sistema se inscreve
  • suffix— sufixo do registro do usuário sob o qual os usuários associados ao TAMOS são criados
  • registry_ssl_cacert— certificado do servidor do registro de usuário do TAM
  • admin_name— o nome do administrador do Tivoli Access Manager
  • admin_pwd— a senha do administrador do Tivoli Access Manager
Listagem 1. Comando de exemplo para a configuração do TAMOS
 [root@Server~]#pdoscfg -registry_ssl_cacert /ldapcert.arm -branch Server.in.ibm.com 
\ -suffix o=ibm,c=in -admin_name 
administrator -admin_pwd password

Para instruções de configuração detalhadas, consulte o "Guia de Administração do TAMOS", cujo link está na seção Recursos no final deste artigo.


Configurando políticas de autorização

O termo recursos do DB2 se refere a processos, contêineres, arquivos do sistema do DB2, etc. que estão presentes no sistema operacional onde o DB2 está instalado. O TAMOS usa vários controles de acesso, como Listas de Controle de Acesso (ACLs) e Políticas de Objetos Protegidos (POPs) para proteger esses recursos. Ele usa o modo estático de criação de objetos em um banco de dados da política para protegê-los. Todo recurso do DB2 que deve ser protegido deve ser explicitamente criado como um objeto no banco de dados da política e deve possuir um ACL/POP anexado a ele.

Banco de dados da política

Em um ambiente do Tivoli Access Manager (TAM) um banco de dados de política armazena os ACLs e POPs definidos em um objeto.

O exemplo a seguir demonstra como é possível usar os controles de acesso do TAMOS para proteger-se contra comportamentos fraudulentos.

Um usuário raiz que possui todas as permissões em uma máquina UNIX ou Linux tenta alterar sua identidade para um usuário da instância do DB2 (por exemplo, db2ins95) e corromper alguns processos do DB2. O TAMOS interferiria aqui para fornecer proteção. O TAMOS fornece uma maneira de proteger operações substitutas usando recursos substitutos. Comece criando um objeto.

A seguir, a sintaxe para criar um objeto:

Object create /OSSEAL/<Server name>/Resource "Description" <object type> ispolicyattachable yes|no

Por exemplo, no caso descrito acima, seria possível usar um comando como o da Listagem 2 para criar um objeto para o recurso substituto.

Listagem 2. Comando de exemplo para criar um objeto
 pdadmin sec_master> object create 
/OSSEAL/Server.in.ibm.com/Surrogate/User/db2ins95 \
"SurrogateUser" 0 ispolicyattachable yes

Então, seria possível usar um comando como o da Listagem 3 para criar uma política para proibir a raiz de alterar a identidade do usuário para db2ins95.

Listagem 3. Comando de exemplo para criar um ACL
 pdadmin sec_master> acl show surr-acl
ACL Name: surr-acl     
Description:     
Entries:         
User sec_master TcmdbsvaBRl
 User root T

O ACL acima mostra que não foi dado o bit de permissão "G" substituto para o usuário raiz. Agora é possível usar um comando como o da Listagem 4 para anexar a política ao objeto para o cumprimento.

Listagem 4. Comando de exemplo para anexar uma política a um objeto para o cumprimento
 pdadmin sec_master> acl attach 
/OSSEAL/Server.in.ibm.com/Surrogate/User/db2ins95
surr-acl

Agora, como mostra a Listagem 5, se o usuário raiz tentar alterar a identidade para um usuário da instância do DB2, não lhe será permitido fazer isso.

Listagem 5. Mudança de identidade para o usuário da instância do DB2 não permitida
 [root@Server ~]# whoami root 
[root@Server ~]# su - db2ins95 su: 
cannot set user id: Operation not permitted

O exemplo nesta seção mostrou como criar objetos e aplicar políticas a eles. Especificamente, mostrou como proteger recursos DB2 controlando se um usuário raiz pode mudar para um usuário de instância do DB2. Essa capacidade de controlar o uso da conta raiz é um dos principais recursos do TAMOS.


Cenários reais

Esta seção demonstra como o TAMOS pode ajudar a lidar com dois problemas reais enfrentados por clientes do DB2.

Caso 1

Alguns clientes do DB2 relataram ter passado por um travamento de instância devido ao fato de um sinal SIGKILL (kill -9) ter sido enviado ao processo db2sysc. Quando um sinal kill -9 é enviado ao db2sysc, um travamento de instância do DB2 é o comportamento esperado. No entanto, o travamento de instância de um sistema de produção pode ter um impacto de negócio significante. O exemplo descrito nesta seção ilustra esse tipo de cenário.

Suponha que você possua uma instância do DB2 chamada db2ins95. Para iniciar o cenário, emita um comando ps, como mostra a Listagem 6, para listar os processos do DB2 para sua instância db2ins95.

Listagem 6. Liste processos da instância do DB2
 [db2ins95@Server ~]$ ps -ef | grep db2 root
7970  7929  0 12:32 pts/2
00:00:00 su - db2ins95 db2ins95
7971  7970  0 12:32 pts/2
00:00:00 -bash db2ins95  8380
1  0 12:39 pts/2    
00:00:00 /home/db2ins95/sqllib/bin/db2bp 
7971A2077 5 A root      8587     1  0 12:45 pts/2
00:00:00 db2wdog 0 db2ins95  8588  8587  0 12:45 pts/2 
00:00:00 db2sysc 0 root      8589  8588  0 12:45 pts/2
00:00:00 db2ckpwd 0 root      8590  8588  0 12:45 pts/2 
00:00:00 db2ckpwd 0 root      8591  8588  0 12:45 pts/2 
00:00:00 db2ckpwd 0 root      8592  8588  0 12:45 pts/2 
00:00:00 db2pmd 0 db2ins95  8593  8588  0 12:45 pts/2   
00:00:00 db2gds 0 db2ins95  8594  8588  0 12:45 pts/2   
00:00:00 db2licc 0 db2ins95  8595  8588  0 12:45 pts/2  
00:00:00 db2ipccm 0 db2ins95  8596  8588  0 12:45 pts/2  
00:00:00 db2resync 0 db2ins95  8598  8588  1 12:45 pts/2 
00:00:00 db2acd 
0 ,0,0,0,1,0,0,0,897d44 ,
14,1e014,2,0,1,11fd0,0x11f90000,0x11f90000,1610000,100004,2,478009
db2ins95  8617  7971  0 12:45 pts/2  
00:00:00 ps -ef db2ins95  8618  7971  0 12:45 pts/2 
00:00:00 grep db2 root     14366     1  0 Mar19 ?  
00:00:25 /opt/ibm/db2/V9.1/bin/db2fmcd

Em seguida, conecte os usuários ao banco de dados SAMPLE, como mostra a Listagem 7.

Listagem 7. Conecte usuários ao banco de dados SAMPLE
		     [db2ins95@Server ~]$ db2  "connect to sample" 
Database Connection Information   Database server 
= DB2/LINUX 9.1.5  SQL authorization ID   = DB2INS95
Local database alias   = SAMPLE  
[db2ins95@Server ~]$ db2 list tables  Table/View   
Schema         
Type  
Creation time
------------------------------- --------------- ----- --------------------------
ACT                            
DB2INS95        T     2010-03-22-12.37.09.890866 ADEFUSR                        
DB2INS95        S     2010-03-22-12.37.13.858864 CL_SCHED         
DB2INS95        T     2010-03-22-12.37.09.641766 DEPARTMENT         
DB2INS95        T     2010-03-22-12.37.09.654181 DEPT                 
DB2INS95        A     2010-03-22-12.37.09.716163 EMP                
DB2INS95        A     2010-03-22-12.37.09.749817 EMPACT             
DB2INS95        A     2010-03-22-12.37.09.887997 EMPLOYEE           
DB2INS95        T     2010-03-22-12.37.09.717494 EMPMDC             
DB2INS95        T     2010-03-22-12.37.15.079208 EMPPROJACT        
DB2INS95        T     2010-03-22-12.37.09.876485

A Listagem 8 mostra kill -9 sendo emitido contra o processo db2sysc e o travamento da instância do DB2.

Listagem 8. kill -9 contra db2sysc causa um travamento de instância
	 [db2ins95@Server ~]$ kill -9 8588
[db2ins95@Server ~]$ db2 list tables SQL1224N  
The database manager is not able to accept new requests,
has terminated all requests in progress, or has terminated your particular
request due to a problem with your request.  SQLSTATE=55032  
[db2ins95@Server ~]$ db2 connect to SAMPLE SQL1032N 
No start database manager command was issued.  SQLSTATE=57019

A Listagem 9 é um exemplo das entradas resultantes no arquivo db2diag.log após o travamento da instância. Essas entradas indicam que o travamento da instância ocorreu devido a emissão de SIGKILL feita por um usuário ou aplicativo.

Listagem 9. Entradas db2diag.log de exemplo
			 2010-03-22-12.49.14.993973-300 I39299G722
LEVEL: Error PID     : 8587
TID  : 3086112448
PROC : db2wdog 0 0
INSTANCE: db2ins95
NODE : 000 FUNCTION: DB2 UDB, oper system services, sqlossig, probe:10
MESSAGE : Sending SIGKILL to the following process id
DATA #1 : signed integer, 4 bytes -8588
CALLSTCK:   [0] 0x0276568D sqlossig + 0x117
[1] 0x0132313A sqloWatchDogMain + 0x20E
[2] 0x0132192A sqloRunInstance + 0xCE
[3] 0x0804D450 DB2main + 0x6DC
[4] 0x0804CD6C main + 0x24 
[5] 0x04938DF3 __libc_start_main + 0xD3
[6] 0x0804CCB1 _Z21sqlePdbProcessRequestP11sqkfChannelPv + 0x1C1
[7] 0x00000000 ?unknown + 0x0
[8] 0x00000000 ?unknown + 0x0
[9] 0x00000000 ?unknown + 0x0

O TAMOS entra em ação!

Agora, veremos como o TAMOS pode ajudar a prevenir o cenário descrito acima.

Primeiro, crie um objeto para o processo db2sysc como um recurso do arquivo no espaço de objeto do TAMOS, como mostra a Listagem 10.

Listagem 10. Crie um objeto
 pdadmin sec_master> object create
 /OSSEAL/Server.in.ibm.com/File/home/db2ins95\ 
 /sqllib/adm/db2sysc "Db2 process" 3 ispolicyattachable yes

Em seguida, como mostra a Listagem 11, crie uma política que não dê ao usuário db2ins95 da instância do DB2 e ao usuário raiz a permissão para interromper o processo.

Listagem 11. Crie uma política
 pdadmin sec_master> 
 acl create db2-acl pdadmin sec_master>
 acl modify db2-acl set user root T[OSSEAL] pdadmin sec_master>
 acl modify db2-acl set user db2ins95 T[OSSEAL]

Agora o ACL está definido para não dar ao usuário db2ins95 da instância do DB2 e ao usuário raiz o bit de permissão para interromper (ou seja, o "k"). A última etapa é impor a política ao objeto, como mostra a Listagem 12.

Listagem 12. Imponha a política ao objeto
 pdadmin sec_master> 
 acl attach /OSSEAL/Server.in.ibm.com/File/home/db2ins95\   
 /sqllib/adm/db2sysc db2-acl

Emita o comando ps novamente para listar os processos do DB2 que estão sendo executados. Compare a saída de exemplo na Listagem 13 à da Listagem 6.

Listagem 13. Liste processos da instância do DB2
 [db2ins95@Server root]$ ps -ef | grep db2 root     14366     1  0 Mar19 ?        
 00:00:29 /opt/ibm/db2/V9.1/bin/db2fmcd root     28330 28278  0 23:42 pts/1    
 00:00:00 su db2ins95 db2ins95 28331 28330  0 23:42 pts/1    
 00:00:00 bash root     28426     1  0 23:42 pts/1    
 00:00:00 db2wdog 0 db2ins95 28427 28426  0 23:42 pts/1    
 00:00:00 db2sysc 0 root     28428 28427  0 23:42 pts/1    
 00:00:00 db2ckpwd 0 root     28429 28427  0 23:42 pts/1    
 00:00:00 db2ckpwd 0 root     28430 28427  0 23:42 pts/1   
 00:00:00 db2ckpwd 0 root     28431 28427  0 23:42 pts/1    
 00:00:00 db2pmd 0 db2ins95 28432 28427  0 23:42 pts/1   
 00:00:00 db2gds 0 db2ins95 28433 28427  0 23:42 pts/1   
 00:00:00 db2licc 0 db2ins95 28434 28427  0 23:42 pts/1    
 00:00:00 db2ipccm 0 db2ins95 28435 28427  0 23:42 pts/1  
 00:00:00 db2resync 0 db2ins95 28437 28427  0 23:42 pts/1  
 00:00:00 db2acd 
 0 ,0,0,0,1,0,0,0,897d44 
 ,14,1e014,2,0,1,11fd0,0x11f90000,0x11f90000,1610000,130003,2,590009
 db2ins95 28629 28434  0 23:47 pts/1    
 00:00:00 db2agent (idle) 0 db2ins95 28951 28331  0 23:52 pts/1   
 00:00:00 ps -ef db2ins95 28952 28331  0 23:52 pts/1
 00:00:00 grep db2

Agora, como mostrado na Listagem 14, não é permitindo ao usuário db2ins95 ou usuário raiz interromper o processo db2sysc pois o TAMOS foi usado para colocar os controles e políticas adequadas em prática.

Listagem 14. kill -9 não permitida
 [db2ins95@Server root]$ kill -9 28427 
 bash: kill: (28427) - Operation not permitted

O TAMOS também pode ajudá-lo a controlar quem realmente emitiu o comando de interrupção, que pode levar a identificar o real culpado. Essa funcionalidade de controle é discutida mais adiante no artigo.

Caso 2

O suporte do DB2 também documentou vários relatos de problemas nos quais um cliente excluiu contêineres de espaço de tabela acidentalmente ao executar atividades de manutenção do sistema operacional. Em alguns casos, isso resultou na perda de quantidades de dado significativas. Esse tipo de cenário também resulta na inacessibilidade do espaço de tabela. O exemplo descrito nesta seção ilustra esse tipo de cenário.

Como no Caso 1, para este exemplo, suponha que você possua uma instância do DB2 chamada db2ins95. Para iniciar o cenário, conecte os usuários ao banco de dados SAMPLE, como mostra a Listagem 15.

Listagem 15. Conecte usuários ao banco de dados SAMPLE
 [db2ins95@Server root]$ db2  "connect to sample" 
 Database Connection Information

Como mostra a Listagem 16, crie um espaço de tabela com um contêiner chamado cont1.

Listagem 16. Crie um espaço de tabela
 [db2ins95@Server root]$ 
 db2 "create tablespace tbsp1 managed by database \ 
 using (file '/test/cont1' 1000)" DB20000I  The SQL command completed successfully.

Crie uma tabela chamada table1 no espaço de tabela cont1 como mostra a Listagem 17.

Listagem 17. Crie as tabelas
 [db2ins95@Server root]$ db2
 "create table table1(id int, name varchar(10)) in tbsp1" DB20000I
 The SQL command completed successfully.

Então, como mostra a Listagem 18, insira alguns dados de amostra na tabela.

Listagem 18. Insira dados de amostra
 db2ins95@Server root]$ db2 
 "insert into table1 values(1,'a'),(2,'b'),(3,'c')" DB20000I 
 The SQL command completed successfully. [db2ins95@Server root]$
 db2 "select * from table1"  ID          NAME
 ----------- ----------           
 1 a           2 b           3 c   
 3 record(s) selected.  [db2ins95@Server test]$ db2
 connect reset DB20000I  The SQL command completed successfully.

Para simular o que aconteceria se um espaço de tabela fosse acidentalmente excluído, emita um comando rm, como mostra a Listagem 19.

Listagem 19. Exclua o contêiner do espaço de tabela
 [root@Server ~]# rm -rf /test/cont1

Agora, como mostra a Listagem 20, quando os usuários se conectarem novamente ao banco de dados e tentarem acessar a tabela, eles recebem um erro.

Listagem 20. Tentativa de acesso retorna um erro
 [db2ins95@Server test]$ db2 connect to sample
 Database Connection Information   
 Database server        = DB2/LINUX 9.1.5  
 SQL authorization ID   = DB2INS95  
 Local database alias   = SAMPLE  
 [db2ins95@Server test]$ db2 "select * from table1"  ID
NAME ----------- ---------- 
SQL0290N  Table space access is not allowed.
SQLSTATE=55039

O espaço de tabela tornou-se inacessível pois seu contêiner foi excluído e todos os dados inseridos na tabela foram perdidos!

O TAMOS entra em ação!

Agora mostraremos como o TAMOS pode ajudá-lo no tipo de situação descrita acima prevenindo que usuários removam os contêineres e, por meio disso, tornando seu sistema seguro contra potenciais perdas de dado.

Neste exemplo, o contêiner, que é simplesmente um recurso do arquivo no sistema operacional, está no diretório /test. Como mostra a Listagem 21, crie um objeto para /test/cont1 sob o recurso do arquivo.

Listagem 21. Crie um objeto
 pdadmin sec_master> object create /OSSEAL/Server.in.ibm.com/File/test/cont1 \  
 "Containers" 2 ispolicyattachable yes

Em seguida, crie uma política para proteger contra usuários capazes de remover esse objeto, como mostra a Listagem 22.

Listagem 22. Crie uma política
 pdadmin sec_master> 
 acl create cont-acl pdadmin sec_master> 
 acl modify cont-acl set user root T[OSSEAL]rwx pdadmin sec_master>
 acl show cont-acl    
 ACL Name: cont-acl   
 Description:     
 Entries:        
 User sec_master TcmdbsvaBRl    
 User root T[OSSEAL]rwx

Agora, o ACL está definido para dar ao usuário raiz permissões de leitura, gravação e execução, mas não o bit de permissão de exclusão (ou seja, o "d"). A última etapa é impor a política ao objeto, como mostra a Listagem 23.

Listagem 23. Imponha a política ao objeto
 pdadmin sec_master> 
 acl attach /OSSEAL/Server.in.ibm.com/File/test/cont1 cont-acl

Agora, como mostra a Listagem 24, o usuário raiz não terá permissão para remover o contêiner. O TAMOS acabou de prevenir a perda de dados acidental provocada pela exclusão do contêiner.

Listagem 24. Exclusão do contêiner não permitida
 [root@Server ~]# rm -rf /test/cont1 rm: cannot 
 remove `/test/cont1': Permission denied

Auditoria e rastreio

Esta seção descreve como é possível usar o TAMOS para monitorar e controlar operações executadas contra processos e recursos do DB2.

Por exemplo, no cenário descrito no Caso 1 acima, um kill -9 foi emitido contra o processo db2sysc. Se uma situação dessas ocorresse, você provavelmente gostaria de saber quem foi o responsável pela ação. O nível de precisão e granular de auditoria fornecido pelo TAMOS pode ajudá-lo nisso.

O TAMOS fornece três níveis de auditoria:

  • Usuário
  • Recurso
  • Global

O exemplo a seguir ilustra a auditoria no nível do recurso. Suponha que, como descrito no Caso 1, as políticas mostradas na Listagem 25 estão em ação para seu sistema.

Listagem 25. Políticas do Caso 1
 pdadmin sec_master> object show 
 /OSSEAL/Server.in.ibm.com/File/home/db2ins95\ 	
 /sqllib/adm/db2sysc 
 Name: /OSSEAL/Server.in.ibm.com/File/home/db2ins95/sqllib/adm/db2sysc    
 Description:    
 Type: 3 (Executable)
 Is Policy Attachable: Yes  
 Extended Attributes:  
 Attached ACL: db2-acl  
 Attached POP:    
 Attached AuthzRule:   
 Effective Extended Attributes: 
 Effective ACL: db2-acl   
 Effective POP:    
 Effective AuthzRule:

Com as políticas acima, o ACL db2-acl protege o db2sysc de ser interrompido.

Agora, como mostra a Listagem 26, crie um POP com uma especificação para que todas as ações em objetos protegidos sejam auditoradas. Isso faz com quem o TAMOS controle quando um SIGKILL é emitido contra o recurso, independente do fato de o usuário ter ou não permissão para interromper o processo db2sysc.

Listagem 26. Crie um POP para realizar a auditoria de todas as ações
 pdadmin sec_master> 
 pop create track-user pdadmin sec_master>
 pop modify track-user set audit-level all

Imponha a política no objeto anexando o POP ao objeto, como mostra a Listagem 27.

Listagem 27. Imponha a política ao objeto
 pdadmin sec_master>
 pop attach /OSSEAL/Server.in.ibm.com/File/home/db2ins95\
 /sqllib/adm/db2sysc track-user

Emita o comando ps para listar os processos do DB2 que estão sendo executados, como mostra a Listagem 28.

Listagem 28. Liste processos da instância do DB2
 [db2ins95@Server root]$ ps -ef | grep db2 root     14366     1  0 Mar19 ?     
 00:00:33 /opt/ibm/db2/V9.1/bin/db2fmcd root     19969 18669  0 11:59 pts/2
 00:00:00 su db2ins95 db2ins95 19970 19969  0 11:59 pts/2 
 00:00:00 bash db2ins95 20051 19970  0 11:59 pts/2 
 00:00:00 ps -ef db2ins95 20052 19970  0 11:59 pts/2  
 00:00:00 grep db2 db2ins95 29476     1  0 00:05 ?     
 00:00:00 /home/db2ins95/sqllib/bin/db2bp 29389A2077
 root     30183     1  0 00:14 ?     
 00:00:00 db2wdog 0                        db2ins95 30184 30183  0 00:14 ?      
 00:00:00 db2sysc 0                        root     30185 30184  0 00:14 ?      
 00:00:00 db2ckpwd 0                       root     30186 30184  0 00:14 ?    
 00:00:00 db2ckpwd 0                       root     30187 30184  0 00:14 ?    
 00:00:00 db2ckpwd 0

Agora, como mostra a Listagem 29, um usuário tenta interromper o processo db2sysc, mas a operação não é permitida.

Listagem 29. kill -9 não permitida
		 [db2ins95@Server root]$ kill -9 30184 
 bash: kill: (30184) - Operation not permitted

A Listagem 30 é um exemplo das entradas resultantes no arquivo audit.log após a tentativa de emitir kill -9. Apesar de não ter sido permitido ao usuário interromper o processo, a ação é controlada e não passa despercebida. Também seria possível usar o utilitário pdosaudview fornecido pelo TAMOS para visualizar o relatório de auditoria.

Listagem 30. Captura instantânea do audit.log
	 			*** START OF NEW RECORD *** 
 Timestamp                                
 Tue 23 Mar 2010 11:59:25 AM EST Audit Event      
 An authorization decision was made. Audit View      
 Deny Audit Reason                     
 Resource Audit Audit Resource Type    
 File Accessor Name                    
 root Accessor Effective Name        
 db2ins95 Audit Action               
 Check Access Audit Permissions       
 kill Audit Qualifier                 
 Checking resource access control policy. Policy Branch Name   
 Server.in.ibm.com Protected Object Name             
 File/home/db2ins95/sqllib/adm/db2sysc System Resource Name     
 /home/db2ins95/sqllib/adm/db2sysc Accessor Process ID    
 19970 Running Program System Resource Name   
 /bin/bash Audit Outcome                      
 Success Audit Uniqifier                    
 0

O registro acima mostra que um kill foi emitido contra o recurso do sistema, /home/db2ins95/sqllib/adm/db2sysc. O campo Accessor Effective mostra que o usuário que emitiu o kill foi db2ins95.


Conclusão

Este artigo introduziu a solução IBM Tivoli Access Manager para Sistemas Operacionais (TAMOS). Ele forneceu uma visão geral de como é possível instalar e configurar o TAMOS e mostrou como ele pode ser usado para proteger processos e recursos do DB2 em sistemas operacionais UNIX e Linux. Ao entender os conceitos do TAMOS, você terá melhores condições de fornecer segurança a seus recursos de sistema além da segurança fornecida pelo sistema operacional nativo.

Recursos

Aprender

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=Tivoli, Information Management
ArticleID=489698
ArticleTitle=Torne recursos do DB2 seguros usando o Tivoli Access Manager para Sistemas Operacionais
publish-date=05112010