Nível: Introdutório Masahiro Ohkawa, Yamato Software Development Laboratory (YSL), IBM Japan
Soh Kaijima, Yamato Software Development Laboratory (YSL), IBM Japan
Gou Nakashima, Yamato Software Development Laboratory (YSL), IBM Japan
Asuka Tokunaga, Yamato Software Development Laboratory (YSL), IBM Japan
02/Jul/2009 O IBM® Database Encryption Expert fornece recursos para criptografar
e controlar o acesso aos dados gravados em imagens de backup de sistemas de arquivos e banco de dados. Começando com a Versão 1.1 Fix Pack 3, o produto suporta o DB2® e o Informix® Dynamic
Server (IDS). Este artigo descreve alguns dos principais recursos e mecanismos do Encryption Expert, e mostra como eles devem ser
usados.
Introdução
O IBM Database Encryption Expert (também chamado de Encryption Expert ou DEE) protege dados
usando um sistema baseado em políticas.
As políticas que o Encryption Expert usa contêm uma ou mais chaves de criptografia, e uma ou
mais regras de controle de acesso.
Existem dois tipos de políticas:
-
Uma política on-line é usada para criptografar dados gravados em um sistema de arquivos,
e para proteger dados com controle de acesso.
Quando uma política on-line é aplicada a um diretório, a política controla o acesso aos arquivos e diretórios
sob o diretório.
A ação de aplicar uma política on-line a um diretório
é chamada Guarda FS (Sistema de Arquivos), o diretório é chamado de Ponto de Guarda,
e os dados lidos de ou gravados no sistema de arquivos são chamados de Dados On-line.
Qualquer aplicativo com acesso autorizado pela política pode acessar os arquivos que estão sob os pontos
de guarda, contanto que o aplicativo use bibliotecas do sistema para acessar os arquivos.
Os dados são automaticamente criptografados na gravação e decriptografados na leitura,
com base na política.
A criptografia é transparente para o aplicativo, e não é preciso fazer nenhuma mudança no
aplicativo em si.
-
Uma política off-line é usada para proteger imagens de backup de banco de dados.
A política off-line é aplicada à máquina usada para fazer o backup e restaurar imagens de
banco de dados.
A política off-line controla os comandos de backup e restauração, e a criptografia e decriptografia
das imagens de backup do banco de dados.
A ação de aplicar uma política off-line a uma máquina é chamada de Guarda DB (Backup de Banco de Dados).
A Figura 1 mostra uma visão geral da arquitetura do Encryption Expert.
Ela consiste em um ou mais servidores de segurança e em um ou
mais agentes.
O servidor de segurança tem as informações de configuração, como as políticas on-line e
off-line, e os logs de auditoria dos agentes.
Os dados das informações de configuração e logs de auditoria são armazenados no DB2,
que faz parte do pacote do Encryption Expert.
Figura 1. Visão geral da arquitetura do IBM Database Encryption Expert
Um agente do Encryption Expert é instalado na máquina onde os dados são protegidos (a máquina host). As
políticas mantidas no servidor de segurança são enviadas ao agente (empurradas),
ou recuperadas pelo agente (puxadas) conforme necessário.
O agente consiste em um agente FS (Sistema de Arquivos) que guarda o FS,
e um agente DB (Backup de Banco de Dados) que guarda o DB.
Os logs de auditoria, para casos como violações de acesso, são enviados ao servidor de segurança por padrão.
O servidor de segurança fornece uma interface baseada na web chamada Console de
Gerenciamento, que pode ser usada para tarefas como configurar políticas e pesquisar
logs de auditoria.
Para usar o Console de Gerenciamento, abra um navegador Web e vá para o seguinte URL:
https://hostname:8445
A Figura 2 é uma captura de tela do painel do Console de Gerenciamento do Encryption Expert, tal
como exibido em um navegador com idioma japonês.
Figura 2. Console de Gerenciamento do Encryption Expert
É possível configurar o servidor de segurança em múltiplas máquinas para permitir o uso de servidores primários e de failover. Os servidores de failover são somente leitura, e são preenchidos por replicação do servidor primário.
O servidor primário atua como Autoridade de Certificação (CA) e publica certificados X.509 para os servidores e agentes de segurança. Os certificados X.509 são usados para autenticação. O protocolo Secure Socket Layer (SSL) é usado para comunicação entre o servidor de segurança e cada agente, e entre o servidor primário e cada servidor de failover.
Configuração de alta disponibilidade
Dois recursos do Encryption Expert que ajudam a assegurar alta disponibilidade são o uso de servidores de failover e o armazenamento em cache da chave de criptografia.
Servidores de failover Como mencionado na introdução, é possível configurar servidores de failover que podem assumir em caso de falha no servidor de segurança primário. Usando a tecnologia de replicação SQL fornecida pelo Encryption Expert, é possível sincronizar a configuração dos servidores de failover com a configuração do servidor primário. Com a replicação de SQL, o programa de captura (asncap) recupera os registros de mudança do log do banco de dados e os armazena em tabelas de migração de dados. O programa de aplicação (asnapply) recupera os dados das tabelas de migração de dados a cada minuto, e aplica as mudanças nos servidores de failover. Ambos os programas rodam no servidor primário. Logs de auditoria não são replicados. Cada servidor de failover pode receber um log de auditoria dos agentes e armazená-lo independentemente dos outros servidores de segurança.
Quando o servidor de failover está configurado, o agente pode acessá-lo (somente leitura). A Figura 3 mostra como o agente escolhe um servidor de segurança para se comunicar. Cada agente de FS e DB tem seu próprio arquivo de configuração, chamado agent.conf. É possível editar o arquivo agent.conf para configurar a ordem na qual o servidor de segurança é escolhido. Se o agente não puder se comunicar com o primeiro servidor ele passa para o próximo, e assim por diante.
Para obter mais informações, consulte a seção "Instalando e configurando o Servidor de Failover do Encryption Expert" no "Capítulo 3: Instalando, removendo e atualizando o Encryption Expert" no Guia do Usuário do IBM Database Encryption Expert, cujo link encontra-se na seção de Recursos.
Figura 3. Mecanismo do servidor de failover
Armazenamento em cache da chave de criptografia no host Cada chave de criptografia de dados on-line tem uma opção chamada Armazenamento em Cache no Host. Se uma chave de criptografia for criada com esta opção, a chave de criptografia é armazenada no disco do agente com proteção de senha. Como resultado, o agente pode trabalhar corretamente mesmo se o servidor de segurança não estiver funcionando corretamente desde a inicialização do agente. Isto é descrito em mais detalhes na próxima seção.
Protegendo dados on-line O Encryption Expert usa algoritmos de criptografia simétricos (3DES, AES128, AES256) para criptografar dados on-line. A Figura 4 mostra uma visão geral de como isto funciona. Uma política on-line tem uma ou mais chaves de criptografia e regras de controle de acesso. É possível usar a mesma chave de criptografia, ou diferentes chaves de criptografia, para arquivos e diretórios sob o ponto de guarda. As regras de controle de acesso são configuradas como Regras de Segurança. As chaves de criptografia são configuradas como Regras de Seleção de Chave. Ao aplicar uma política on-line a um diretório de um host usando o Console de Gerenciamento, a política é salva no servidor de segurança e enviada ao agente FS no host.
Figura 4. Protegendo dados on-line
O agente FS consiste em processos vmd e secfsd. O processo vmd se comunica com o servidor de segurança. O processo secfsd contém políticas on-line, e criptografa e decriptografa dados com controle de acesso. Estes processos ficam no sistema como daemons. Quando um processo secfsd é iniciado, todas as políticas relacionadas ao host são recuperadas do servidor de segurança por um processo vmd, e as políticas são armazenadas no cache de memória. Se o processo não conseguir recuperar as políticas, ele continua tentando recuperá-las a cada 5 segundos. Ao aplicar uma política on-line a um diretório, o servidor de segurança envia a política ao agente, e o agente armazena a política no cache de memória.
Se um aplicativo tentar acessar um ponto de guarda com uma chave de criptografia que usa a opção Armazenamento em Cache no Host, e a tentativa for feita quando o agente não tiver armazenado a chave de criptografia do ponto de guarda no cache de memória porque o servidor de segurança não estava funcionando corretamente desde a inicialização do agente, então o aplicativo travará. Neste caso, use o comando mostrado na Lista 1 (seguido da senha predefinida) para fazer o aplicativo retomar seu funcionamento correto. Depois disso, qualquer aplicativo que acessar um ponto de guarda no host vai funcionar corretamente, sem travar, se a chave de criptografia do ponto de guarda estiver configurada com a opção de Armazenamento em Cache no Host.
Listing 1. Retrieve encryption keys stored on the disk of the host
# vmsec passwd
Please enter password: xxxxxxxx
OK passwd
#
|
A Figura 5 mostra um exemplo das Regras de Segurança. Neste exemplo, se um usuário db2admin acessar o ponto de guarda, os dados são criptografados na gravação e decriptografados na leitura. Se o usuário raiz ler os dados no ponto de guarda, os dados não são decriptografados, e a ação é registrada no log de auditoria. Outros pedidos de acesso ao ponto de guarda são negados, e a ação é registrada no log de auditoria.
Figura 5. Exemplo de Regras de Segurança
Configurações do Host A condição de ID do Usuário pode ser contida nas Regras de Segurança. Outra configuração relacionada com o ID de Usuário é chamada Configuração do Host. Use a Configuração do Host para identificar quais métodos de login são permitidos, que processos são permitidos não importa qual método de login seja usado, e assim por diante. Por exemplo, se você quiser permitir que certos usuários acessem os pontos de guarda só se fizerem login via ssh e telnet, adicione |authenticator| em frente dos processos de login, como mostrado na Lista 2.
Listing 2. Example of Host Settings that allow
user authentication only when logging in via ssh and telnet
|authenticator|/usr/bin/login
/usr/bin/su
|authenticator|/usr/sbin/sshd
/usr/sbin/ftpd
/usr/dt/bin/dtlogin
/usr/bin/sh
|
Como mostrado acima, su também podem ser controlados de forma que o Encryption Expert impeça até mesmo o usuário raiz de acessar os pontos de guarda fingindo ser algum outro usuário. Para obter mais informações, consulte a seção "Configurando as definições de host" no "Capítulo 6: Configurando hosts" no Guia do Usuário do IBM Database Encryption Expert, cujo link encontra-se na seção de Recursos.
A lista 3 mostra um exemplo de um Usuário não Autenticado ou erro de FAKED USER que ocorre se você roda um programa para acessar um ponto de guarda depois de fazer login com um método de login não autorizado.
Listing 3. Example of a User Not Authenticated error
EET2604E: [SecFS, 0] [ALARM] Policy[db2admin_online_policy1]
User[db2admin,uid=222 (User Not Authenticated)] Process[/usr/bin/ls]
Action[read_dir_attr] Res[/home/db2admin/guard/] Effect[DENIED Code
(1U,2M)]
|
Transformação de dados O Encryption Expert fornece um recurso para transformar dados criptografados por uma chave de criptografia, ou dados não criptografados em dados criptografados por meio de outra chave de criptografia. Isto é chamado dataxform. Um exemplo de quando você usaria isto seria o caso de um arquivo não criptografado existir em um diretório ao qual uma política on-line está sendo aplicada. Se a política exige que o arquivo seja criptografado, é necessário criptografar o arquivo antes de aplicar a política. Para tanto, use uma das seguintes soluções:
- Use o dataxform para transformar os dados antes de aplicar a política ao diretório.
- Mova o arquivo para um diretório não guardado antes de aplicar a política ao diretório. Depois de aplicar a política ao diretório, mova o arquivo de volta para o diretório. Ao você mover o arquivo de volta, ele será automaticamente criptografado com base na política que você aplicou.
Para obter mais informações, consulte a seção “Usando o dataxform" no "Capítulo 10: Mudando chaves de criptografia" no Guia do Usuário do IBM Database Encryption Expert, cujo link encontra-se na seção de Recursos. Comandos O Encryption Expert fornece comandos que podem ser usados para obter informações do agente. Por exemplo, para obter informações do ponto de guarda, é possível digitar o comando mostrado na Lista 4.
Listing 4. Example of command to obtain
guard point information
# secfsd -status guard
GuardPoint Policy Type ConfigState Status Reason
---------- ------ ---- ----------- ------ ------
/home/db2admin/guard1 db2admin_policy1 local guarded guarded N/A
/home/db2admin/guard2 db2admin_policy2 local guarded guarded N/A
|
É possível usar os processos secfsd e vmd como comandos especificando as opções. Para obter mais informações sobre estes e outros comandos do Encryption Expert, consulte o "Capítulo 16: Mantendo o Encryption Expert" no Guia do Usuário do IBM Database Encryption Expert, cujo link encontra-se na seção de Recursos.
Protegendo imagens de backup do banco de dados
O Encryption Expert usa um algoritmo de criptografia híbrido para criptografar imagens de backup de banco de dados. Uma chave simétrica é criada dinamicamente, e usada para criptografar uma imagem de backup de banco de dados. A própria chave simétrica é criptografada por uma ou mais chaves assimétricas (chaves públicas). Como algoritmos de criptografia simétricos, é possível usar o AES128 ou o AES256. Como algoritmos de criptografia assimétricos, é possível usar o RSA1024, o RSA2048 ou o RSA4096.
É possível importar chaves públicas criadas por outros servidores de segurança do Encryption Expert. Ao fazê-lo, uma imagem de backup do banco de dados criptografada por um agente DB e administrada por um servidor de segurança pode ser restaurada para outro agente DB administrado por outro servidor de segurança.
A Figura 6 mostra uma visão geral de como o Encryption Expert fornece proteção para uma imagem de backup do banco de dados. A figura mostra agentes de backup para o IDS e DB2, mas não é possível usar ambos os agentes na mesma máquina. Uma política off-line que contenha múltiplas regras de backup e restauração pode ser aplicada a uma máquina. As operações de backup e restauração com o agente DB são registradas no log de auditoria e enviadas ao servidor de segurança por padrão.
Figura 6. Proteger a imagem de backup do banco de dados
Integração com o backup e restauração do DB2 É possível emitir o comando de backup do DB2 com um módulo externo como opção. Isto permite usar o módulo do agente DB2 com um backup, o que permite criptografar uma imagem de backup do banco de dados comunicando-se com o servidor de segurança. A imagem de backup do banco de dados contém o módulo do agente DB2 e as informações necessárias para sua decriptografia. O comando de restauração do DB2 invoca o agente DB2 contido na imagem de backup do banco de dados, e o agente DB2 o decriptografa comunicando-se com o servidor de segurança.
Você também pode emitir o comando de restauração do DB2 com um módulo externo como opção. Quando um módulo externo é especificado, ele é usado em vez do módulo contido na imagem de backup do banco de dados. Se o agente DB2 for atualizado depois do backup do banco de dados e você quiser usar o módulo atualizado, especifique o módulo com o comando de restauração do DB2.
A Lista 5 contém um exemplo de comando de backup do DB2 usando o módulo do agente DB2.
Listing 5. DB2 backup command example
% DB2 BACKUP DB dbname compress comprlib
/opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/db2/lib/libeetdb2.so
|
É possível usar outras opções com a sintaxe acima, como USE TSM para especificar o uso do Tivoli Storage Manager (TSM).
A Lista 6 contém um exemplo de comando de restauração do DB2 usando o módulo do agente DB2.
Listing 6. DB2 restore command example
Integração com o backup e restauração do IDS Há dois tipos de backup no IDS: ontape e onbar. Em ambos os casos, é possível especificar o módulo executável do agente IDS no arquivo de configuração $INFORMIXDIR/etc/$ONCONFIG. O módulo executável do agente IDS precisa de um arquivo de atributos que descreve como lidar com os dados. Use a opção -f para identificar o arquivo de atributos.
A lista 7 mostra um exemplo de arquivo de configuração.
Listing 7. IDS configuration file example
BACKUP_FILTER '/opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/ids/bin/eetidsagt -f /home/info
rmix/attr.w'
RESTORE_FILTER '/opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/ids/bin/eetidsagt -f /home/inf
ormix/attr.r'
|
A lista 8 mostra um exemplo de arquivo de atributos de backup (attr.w).
Listing 8. Example of a IDS agent attribute file for backup
ENV=INFORMIXSERVER, SERVERNUM
OPERATION=write
|
No exemplo da Lista 8, o arquivo de atributos especifica que:
- as variáveis de ambiente INFORMIXSERVER e SERVERNUM são usadas para avaliar as condições da política.
- Isto para o backup.
A lista 9 mostra um exemplo de arquivo de atributos de restauração (attr.r).
Listing 9. Example of IDS agent attribute file for restore
ENV=INFORMIXSERVER, SERVERNUM
OPERATION=read
|
No exemplo da Lista 9, o arquivo de atributos especifica que:
- as variáveis de ambiente INFORMIXSERVER e SERVERNUM são usadas para avaliar as condições da política.
- Isto para a restauração.
As Listas 10 e 11 mostram exemplos de comandos de backup do IDS.
Listing 10. Example of IDS backup command (onbar)
Listing 11. Example of IDS backup command (ontape)
% ontape -v -s -L 0 -t STDIO > /.../backup.000
|
As Listas 12 e 13 mostram exemplos de comandos de restauração do IDS.
Listing 12. Example of IDS restore command (onbar)
Listing 13. Example of IDS restore command (ontape)
% onmode -ky
% cat /.../backup.000 | ontape -r -t STDIO -v
|
Para backups IDS ontape, também há a opção de especificar o módulo do agente IDS como um comando que recebe a saída do comando de backup ou restauração. As Listas 14 e 15 mostram exemplos de comandos com esta opção.
Listing 14. Example of IDS backup
command (ontape) specifying the IDS agent module
% ontape -v -s -L 0 -t STDIO |
/opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/ids/bin/eetidsagt -f
/home/informix/attr.w > /.../backup.000
|
Listing 15. Example of IDS restore
command (ontape) specifying the IDS agent module
% cat /.../backup.000 |
/opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/ids/bin/eetidsagt -f
/home/informix/attr.r | ontape -r -t STDIO -v
|
Para obter mais informações sobre backup e restauração do IDS, consulte o "Capítulo 12: Fazendo backup e restauração de bancos de dados IDS" no Guia do Usuário do IBM Database Encryption Expert, cujo link encontra-se na seção de Recursos.
Configurando o log de auditoria Use o Console de Gerenciamento para configurar os parâmetros do log de auditoria. Cada host e cada agente (o agente FS, o agente DB2 e o agente IDS) têm sua própria configuração. Por exemplo, é possível especificar se o log é enviado ao servidor de segurança, quantos logs são enviados imediatamente, e o número mínimo e máximo de segundos que o agente deve esperar antes de enviar os logs.
Se for feita uma tentativa de enviar um log quando nenhum servidor de segurança estiver funcionando corretamente, o log é armazenado em um arquivo temporário no agente. Novas tentativas são feitas após o intervalo de tempo mínimo especificado para o envio dos logs. Isto não afeta a capacidade do aplicativo de acessar os pontos de guarda.
Para obter mais informações sobre a configuração do log de auditoria, consulte o "Capítulo 15: Preferências de configuração" no Guia do Usuário do IBM Database Encryption Expert, cujo link encontra-se na seção de Recursos.
Mantendo certificados X.509 Cada certificado X.509 publicado pelo servidor primário tem uma data de validade. O prazo de validade dos certificados X.509 para o CA e o servidor primário é de 10 anos. O prazo de validade dos outros certificados é de 4 anos.
A seguinte lista mostra os diretórios nos quais os certificados X.509 ficam. Os certificados do CA são criados no servidor primário. Os certificados do CA são copiados para os servidores de failover e para os agentes ao criar e registrar os certificados.
- Servidor de segurança (primário e failover)
/opt/IBM/DB2TOOLS/LUWEncrptionExpert/server/pem - FS agent
/opt/IBM/DB2TOOLS/LUWEncrptionExpert/agent/vmd/pem - Agente DB2
/opt/IBM/DB2TOOLS/LUWEncrptionExpert/agent/db2/pem - Agente IDS
/opt/IBM/DB2TOOLS/LUWEncrptionExpert/agent/ids/pem
A Lista 16 mostra um exemplo do comando que é possível usar para ver um certificado X.509. Um exemplo de por que você poderia querer fazer isto seria para verificar a data de validade de um certificado.
Listing 16. Command syntax for browsing X.509 certificate
openssl x509 -in filename -noout -text
|
No comando, filename é o nome do arquivo do certificado X.509 sob o diretório, como mostrado na lista acima.
A lista 17 mostra um exemplo das informações que são retornadas do comando para ver um certificado X.509.
Listing 17. X.509 certificate example
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
0c:82:d5:ad:e7:f2:b0:fd:d7:22:14:e2:9f
Signature Algorithm: sha1WithRSAEncryption
Issuer: CN=EET CA (S) on srv1.yamato.ibm.com, OU=I, O=IBM, L=Yamato, ST=Kanagawa,
C=JP // Issuer: Certificate Authority (CA)
Validity
Not Before: Dec 14 06:52:41 2008 GMT
Not After : Dec 14 06:52:41 2012 GMT // Expiration date
Subject: OU=This agent certificate was automatically generated, CN=EET FS_VMD Agent
on host1.yamato.ibm.com // Subject: primary server, failover server, or agent
.....
|
Para verificar a data de validade de cada componente do Encryption Expert, verifique os arquivos do certificado X.509 mostrados na Tabela 1. A tabela mostra o nome de arquivo do certificado e o prazo de validade de cada componente do Encryption Expert.
Tabela 1. Informações sobre o certificado X.509
| Componente do Encryption Expert (Assunto) | Arquivo do certificado X.509 (um deles) | Prazo de Validade |
|---|
| CA | donkey_signer-cert.pem | 10 anos | | Servidor primário | donkey_server_hostname-cert.pem | 10 anos | | Servidor de failover | donkey_server_hostname-cert.pem | 4 anos | | Agente | agent-cert.pem | 4 anos |
A lista 18 mostra o comando para renovar os certificados X.509 do CA. Emita o comando no servidor primário.
Listing 18. Command to renew the CA's X.509 certificates
# /opt/IBM/DB2TOOLS/LUWEncryptionExpert/server/bin/re_gen_cert_auth
|
Ao renovar os certificados X.509 do CA, os outros certificados X.509 são invalidados. Portanto, também é preciso renovar os certificados X.509 para o servidor primário, os servidores de failover e os agentes.
A lista 19 mostra os dois comandos que é possível usar para renovar os certificados X.509 do servidor primário.
Listing 19. Commands to renew the primary
server's X.509 certificates (use one or the other)
# /opt/IBM/DB2TOOLS/LUWEncryptionExpert/server/bin/re_gen_cert
# /opt/IBM/DB2TOOLS/LUWEncryptionExpert/server/bin/re_sign_cert
|
O comando re_gen_cert recria a chave. O comando re_sign_cert reutiliza a chave.
A lista 20 mostra os dois comandos que é possível usar para renovar os certificados X.509 do servidor de failover.
Listing 20. Commands to renew the failover
server's X.509 certificates (use one or the other)
# /opt/IBM/DB2TOOLS/LUWEncryptionExpert/server/bin/re_gen_failover_cert
# /opt/IBM/DB2TOOLS/LUWEncryptionExpert/server/bin/re_sign_failover_cert
|
O comando re_gen_failover_cert recria a chave.
O comando re_sign_failover_cert reutiliza a chave.
Para renovar os certificados X.509 do agente, faça o seguinte: - Na máquina do agente, emita os seguintes comandos para excluir os certificados X.509 apropriados do agente.
Para excluir o certificado X.509 do agente FS:
# /opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/vmd/bin/register_host clean
|
Para excluir os certificados do agente DB2:
# /opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/db2/bin/register_host clean
|
Para excluir os certificados do agente IDS:
# /opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/ids/bin/register_host clean
|
- Selecione o host no Console de Gerenciamento. Desmarque as caixas de seleção Registro Permitido e clique em Aplicar. Como resultado, a Impressão Digital do Certificado fica vazia.
- No Console de Gerenciamento, marque as caixas de seleção Registro Permitido.
- Na máquina do agente, emita os seguintes comandos para registrar os certificados X.509 apropriados do agente.
Para registrar os certificados do agente FS:
# /opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/vmd/bin/register_host
|
Para registrar os certificados do agente DB2:
# /opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/db2/bin/register_host
|
Para registrar os certificados do agente IDS:
# /opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/ids/bin/register_host
|
- Selecione novamente o host no Console de Gerenciamento.
Marque as caixas de seleção Comunicação Habilitada e clique em Aplicar.
- Se os servidores de failover estiverem configurados, cadastre novamente os pontos de acesso nos arquivos agent.conf nos seguintes diretórios do host:
- Agente FS
/opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/vmd/etc - Agente DB2
/opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/db2/etc - Agente IDS
/opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/ids/etc
Para obter mais informações, consulte a seção "Configurando um agente para usar Servidores de Segurança" no "Capítulo 6: Configurando hosts" no Guia do Usuário do IBM Database Encryption Expert, cujo link encontra-se na seção de Recursos.
Conclusão O IBM Database Encryption Expert protege os dados com uma política que contém uma ou mais chaves de criptografia e uma ou mais regras de controle de acesso. As políticas são administradas centralmente pelo servidor de segurança, e são enviadas aos agentes que protegem os dados conforme necessário. Os logs de auditoria para eventos como violações de acesso também podem ser administrados pelo servidor de segurança. Para assegurar requisitos de alta disponibilidade, é possível instalar múltiplos servidores de segurança.
O agente FS fornece um recurso para criptografar e decriptografar dados gravados em ou lidos de sistemas de arquivos.
Qualquer aplicativo com acesso autorizado pela política pode acessar os arquivos que estão sob os pontos de guarda, contanto que o aplicativo use bibliotecas do sistema para acessar os arquivos. Os dados são automaticamente criptografados na gravação e decriptografados na leitura, com base na política. A criptografia é transparente para o aplicativo, e não é preciso fazer nenhuma mudança no aplicativo em si.
Se a opção de Armazenamento em Cache no Host for habilitada com uma chave de criptografia, a chave de criptografia é armazenada no disco da máquina do agente FS com proteção de senha. Como resultado, o agente FS pode trabalhar corretamente mesmo se todos os servidores de segurança não estiverem funcionando corretamente desde a inicialização do agente FS.
O processo do agente FS recupera todas as políticas on-line relacionadas no momento da inicialização e as armazena no cache de memória. Portanto, depois disso o agente FS funciona corretamente mesmo se todos os servidores de segurança ficarem indisponíveis, independentemente da opção Armazenamento em Cache no Host estar habilitada ou não.
O agente DB fornece um recurso para criptografar e decriptografar imagens de backup de bancos de dados DB2 e IDS com comandos de controle de backup e restauração. O agente DB se comunica com o servidor de segurança para ler a política sempre que um comando de backup ou restauração é emitido com o agente DB.
O protocolo SSL é usado para comunicação entre o servidor de segurança e cada agente, e entre o servidor primário e cada servidor de failover. Os certificados X.509 são usados para autenticação. Os certificados X.509 têm data de validade, assim é preciso renová-los antes de seu vencimento.
Recursos Aprender
Discutir
Sobre os autores  | 
| | Masahiro Ohkawa é membro da equipe de desenvolvimento de conjuntos de ferramentas para banco de dados no Laboratório de Desenvolvimento de Software Yamato (YSL), na IBM Japão. |
| 
| | Soh Kaijima é membro da equipe de desenvolvimento de conjuntos de ferramentas para banco de dados no Laboratório de Desenvolvimento de Software Yamato (YSL), na IBM Japão. |
| 
| | Gou Nakashima é membro da equipe de desenvolvimento de conjuntos de ferramentas para banco de dados no Laboratório de Desenvolvimento de Software Yamato (YSL), na IBM Japão. |
| 
| | Asuka Tokunaga é membro da equipe de desenvolvimento de conjuntos de ferramentas para banco de dados no Laboratório de Desenvolvimento de Software Yamato (YSL), na IBM Japão. |
Avalie esta página
| 
