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

Voltar para parte superior

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.

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.

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

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

Voltar para parte superior

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.

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.

 			 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.

  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.

  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.

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

Voltar para parte superior

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.

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

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

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

			 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.

 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.

 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.

 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.

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

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

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

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

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

 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.

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

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

 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.

 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.

 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.

 [root@Server ~]# rm -rf /test/cont1 rm: cannot 
 remove `/test/cont1': Permission denied 			

Voltar para parte superior

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.

 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.

 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.

 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.

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

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

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

Voltar para parte superior

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

• O "Guia de Instalação do TAMOS" contém instruções detalhadas para instalar e configurar o TAMOS 6.0 em várias plataformas.
  
  
• O "Guia de Administração do TAMOS", contém informações sobre recursos e políticas protegidos pelo TAMOS.
  
  
• O Centro de Informações do DB2 descreve como usar o DB2 e seus recursos.
  
  
• O Redpaper Auditing UNIX/Linux System Use with Tivoli Access Manager for Operating Systems and Tivoli Compliance Insight Manager fornece detalhes sobre a auditoria dos sistemas Linux e UNIX com o TAMOS.
  
  

Discutir

• Participar do fórum de discussão.
  
  
• Conheça os blogs do developerWorks e faça parte da comunidade do developerWorks.
  
  

Sobre os autores

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

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

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• O que é o TAMOS
• Configurando políticas de autorização
• Cenários reais
• Auditoria e rastreio
• Conclusão
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais