O que é necessário saber sobre segurança antes de instalar ou fazer upgrade do servidor

Editar on-line

Revise informações sobre os recursos de segurança aprimorados no servidorIBM Storage Protect e os requisitos para atualização de seu ambiente.

Antes de iniciar

Começando na Versão 8.1.2, aprimoramentos foram incluídos aIBM Storage Protect que impõem configurações de segurança mais rígidas. Antes de instalar ou fazer upgradeIBM Storage Protect, conclua as etapas a seguir:
  • Em IBM Documentation, no tópico What's New (Novidades), examine as informações nas seções Security (Segurança) para saber mais sobre as atualizações de segurança de cada versão.
  • Se você tiver versões anteriores do servidor em seu ambiente, revise as restrições e os problemas conhecidos na nota técnica 562939 Para evitar essas restrições e aproveitar os aprimoramentos de segurança mais recentes, planeje atualizar todos os servidoresIBM Storage Protect e clientes de backup-archive em seu ambiente para a versão mais recente.
  • Verifique se você fez o backup dos diretórios e arquivos a seguir, que são necessários para restaurar o servidor:
    • Arquivo de opções do servidor (dsmserv.opt).
    • Arquivo de configuração do dispositivo (por exemplo, devconf.dat)
    • Arquivo histórico de volume (por exemplo, volhist.dat)
    • Arquivos de chave mestra de criptografia (dsmkeydb.kdb ou dsmkeydb.sth)
    • Certificado de servidor e arquivos de chaves privadas (cert.kbd ou cert.sth)

Aperfeiçoamentos de Segurança

Os aprimoramentos de segurança a seguir foram incluídos a partir da V8.1.2:
Protocolo de segurança que usa Segurança da Camada de Transporte (TLS)

OIBM Storage Protect V8.1.2 e software posterior possui um protocolo de segurança melhorado que usa TLS Versão 1.2 ou psterior para autenticação entre o servidor, agente de armazenamento e clientes de backup-archive.

Começando com IBM Storage ProtectV8.1.11, é possível ativar o protocolo TLS 1.3 para proteger as comunicações entre servidores, clientes e agentes de armazenamento. Para usar o TLS 1.3, ambas as partes na sessão de comunicação devem usar o TLS 1.3. Se uma das partes usar o TLS 1.2, ambas usarão o TLS 1.2 por padrão.

Configuração e distribuição automáticas de certificados do Secure Sockets Layer (SSL)
Os servidores, agentes de armazenamento e clientes que usam o software V8.1.2 ou mais recente são configurados automaticamente para autenticação entre si usando TLS.

Usando o novo protocolo, cada servidor, agente de armazenamento e cliente tem um certificado autoassinado que é usado para autenticar e permitir conexões TLS. Os certificados autoassinados do IBM Storage Protect permitem a autenticação segura entre as entidades, permitem a criptografia avançada para transmissão de dados e distribuem automaticamente as chaves públicas para os nós clientes. Os certificados são trocados automaticamente entre todos os clientes, agentes de armazenamento e servidores que usam o software V8.1.2 ou mais recente. Não é necessário configurar manualmente o TLS nem instalar manualmente os certificados para cada cliente. Os novos aprimoramentos de TLS não requerem mudanças de opções e os certificados são transferidos para os clientes automaticamente na primeira conexão, a menos que você esteja usando um único ID de administrador para acessar múltiplos sistemas.

Por padrão, os certificados autoassinados são distribuídos, mas é possível opcionalmente usar configurações, como certificados que são assinados por uma autoridade de certificação. Para obter mais informações sobre o uso de certificados, consulte Comunicação de Secure Sockets Layer e Segurança da Camada de Transporte.

Combinação dos protocolos TCP/IP e TLS para garantir uma comunicação segura e um impacto mínimo no desempenho
Em versões anteriores do software IBM Storage Protect, você tinha que escolher o TLS ou o TCP/IP para criptografar toda a comunicação. O novo protocolo de segurança usa uma combinação de TCP/IP e TLS para proteger a comunicação entre servidores, clientes e agentes de armazenamento. Por padrão, o TLS é usado somente para criptografar autenticação e metadados, enquanto o TCP/IP é usado para transmissão de dados. Como a criptografia TLS é usada principalmente somente para autenticação, o desempenho para operações de backup e restauração não é afetado.

Opcionalmente, é possível usar o TLS para criptografar a transmissão de dados usando a opção do cliente SSL para comunicação cliente-para-servidor e o parâmetro SSL no comando UPDATE SERVER para comunicação servidor-para-servidor.

A compatibilidade com versões anteriores facilita o planejamento de upgrades em lotes
Versões atualizadas de servidores e clientes IBM Storage Protect podem continuar a se conectar a versões mais antigas quando o parâmetro SESSIONSECURITY é configurado como TRANSITIONAL.

Não é necessário atualizar clientes de backup e archive para a V8.1.2 ou mais recente antes de fazer upgrade de servidores. Depois que você fizer upgrade de um servidor para a V8.1.2 ou mais recente, os nós e os administradores que estiverem usando versões anteriores do software continuarão se comunicando com o servidor usando o valor TRANSITIONAL até que a entidade atenda aos requisitos para o valor STRICT. Da maneira similar, é possível fazer o upgrade de clientes de backup-archive para V8.1.2 ou posterior antes de fazer upgrade seus servidores IBM Storage Protect, mas não é necessário que você faça upgrade dos servidores primeiro. A comunicação entre servidores e clientes que estão usando versões diferentes não é interrompida. No entanto, você não terá os benefícios dos aprimoramentos de segurança até que tanto os clientes quanto os servidores sejam submetidos a upgrade.

Cumprir a segurança estrita com o parâmetro SESSIONSECURITY
Para usar o novo protocolo de segurança, as entidades de servidor, nó cliente ou administrador devem estar usando o software IBM Storage Protect que suporta o parâmetro SESSIONSECURITY . A segurança de sessão é o nível de segurança que é usado para comunicação entre os nós clientesIBM Storage Protect, clientes administrativos e servidores. É possível especificar os valores a seguir para esse parâmetro:
STRICT
Reforça o mais alto nível de segurança para comunicação entre servidores IBM Storage Protect, nós e administradores, que atualmente é o TLS 1.2.
TRANSITIONAL
Especifica que o protocolo de comunicação existente (por exemplo, TCP/IP) é usado até que você atualize o seu softwareIBM Storage Protect para a versão V8.1.2 ou posterior. Esse é o padrão. Quando SESSIONSECURITY=TRANSITIONAL, configurações de segurança mais estritas são aplicadas automaticamente quando versões mais altas do protocolo TLS são usadas e quando o software é atualizado para a V8.1.2 ou mais recente. Depois que um nó, um administrador ou um servidor atender aos requisitos do valor STRICT, a segurança de sessão será atualizada automaticamente para o valor STRICT e a entidade não poderá mais ser autenticada usando uma versão anterior do cliente ou protocolos anteriores do TLS.
Se SESSIONSECURITY=TRANSITIONAL e o servidor, o nó ou o administrador nunca tiverem atendido aos requisitos do valor STRICT, o servidor, o nó ou o administrador continuarão sendo autenticados usando o valor TRANSITIONAL. No entanto, depois que o servidor, o nó ou o administrador atenderem aos requisitos do valor STRICT, o valor do parâmetro SESSIONSECURITY será atualizado automaticamente de TRANSITIONAL para STRICT. Em seguida, o servidor, o nó ou o administrador não poderão mais ser autenticados usando uma versão do cliente ou um protocolo SSL/TLS que não atenda aos requisitos de STRICT.
Restrição: depois que um administrador é autenticado com sucesso com um servidor usando o software IBM Storage Protect V8.1.2 ou posterior ou o software Tivoli Storage Manager V7.1.8 ou posterior, o administrador não pode mais se autenticar com o mesmo servidor usando versões de cliente ou servidor anteriores a V8.1.2 ou V7.1.8. Essa restrição também se aplica ao servidor de destino quando você usa funções como roteamento de comandos, exportação de servidor para servidor que se autentica com o servidor de destino IBM Storage Protect como um administrador de outro servidor, conexões de administrador usando o Operations Center e conexões do cliente da linha de comandos administrativo
Para sessões administrativas e do cliente, as sessões de roteamento do comando administrativo poderão falhar, a menos que o ID do administrador já tenha adquirido certificados para todos os servidores aos quais o ID do administrador se conectará. Administradores autenticados usando o comando dsmadmc, o comando dsmc ou o programa dsm não poderão ser autenticados usando uma versão anterior depois de serem autenticados usando a V8.1.2 ou mais recente. Para resolver problemas de autenticação para administradores, consulte as seguintes dicas:
  • Certifique-se de que todos os softwaresIBM Storage Protect que a conta de administrador usa para efetuar logon tiveram upgrade para V8.1.2 ou posterior. Se uma conta de administrador efetuar logon em vários sistemas, assegure-se de que o certificado do servidor esteja instalado em cada sistema.
  • Se necessário, crie uma conta do administrador separada para usar somente com clientes e servidores que estão usando o software V8.1.1 ou anterior.

Antes de fazer upgrade

Antes de fazer upgrade de um servidor, revise as diretrizes na lista de verificação a seguir.
Tabela 1. Planejando a lista de verificação
Diretriz descrição
Faça backup dos seguintes arquivos do servidor:
  • Bancos de dados de chaves (cert.kdb e dsmkeydb.kdb)
  • Arquivos stash (cert.sth e dsmkeydb.sth)

Começcando com aIBM Storage Protect Versão 8.1.2, uma chave mestra de criptografia é gerada automaticamente ao iniciar o servidor se a chave mestra de criptografia não existia anteriormente.

A chave mestra de criptografia é armazenada em um banco de dados de chaves, dsmkeydb.kdb. Os certificados do servidor ainda são armazenados no banco de dados de chaves cert.kdb e acessados pelo arquivo stash cert.sth. Deve-se proteger os bancos de dados de chaves (cert.kdb e dsmkeydb.kdb) e os arquivos stash (cert.sth e dsmkeydb.sth) que fornecem acesso a cada um dos bancos de dados de chaves. Por padrão, o comando BACKUP DB protege a chave mestra de criptografia da mesma maneira em que o histórico do volume e os arquivos devconfig são protegidos. É necessário lembrar-se da senha de backup de banco de dados para restaurar o banco de dados. O arquivo IBM Storage Protect server dsmserv.pwd , que foi usado para armazenar a chave mestra de criptografia em liberações anteriores, não é mais usado..
Planejar upgrades com cuidado para IDs de administrador Identifique todos os sistemas que as contas do administrador usam para efetuar login para propósitos de administração.
Depois de uma autenticação bem-sucedida para o software V8.1.2 ou posterior, os administradores não podem autenticar em versões anteriores do softwareIBM Storage Protect no mesmo servidor. Se um único ID de administrador é usado para efetuar login em múltiplos sistemas, planeje fazer upgrade de todos esses sistemas com o software V8.1.2 ou mais recente para assegurar que o certificado seja instalado em todos os sistemas nos quais o administrador efetua login.
Dica: Você não será bloqueado de um servidor se o parâmetro SESSIONSECURITY para todos os seus IDs de administrador for atualizado para o valor STRICT. É possível importar manualmente o certificado público do servidor para um cliente do qual você emite o comando dsmadmc .
Se você estiver usando o TLS com versões anteriores do cliente que usam o certificado TSM Server SelfSigned Key (cert.arm), atualize seus clientes para a V8.1.4 ou mais recente. Em liberações anteriores a V7.1.8, o certificado padrão era rotulado chave autoassinada do servidor TSM e possuia uma assinatura MD5, que não suporta o protocolo TLS 1.2 ou posterior que é necessário por padrão para V8.1.2 ou clientes posteriores e o Operations Center. Para resolver esse problema, conclua uma das etapas a seguir:
  • Faça upgrade do servidor para a V8.1.4 ou mais recente. A partir do V8.1.4, servidores que utilizam o certificado MD5-signed como padrão são atualizados automaticamente para usar um certificado padrão com uma assinatura SHA que é rotulada TSM Server SelfSigned SHA Key. Uma cópia do novo certificado padrão é armazenada no arquivo cert256.arm, que está localizado no diretório de instância do servidor.
    Dica: antes de atualizar o servidor para usar o novo certificado padrão com uma assinatura SHA, distribua o arquivo cert256.arm para clientes para evitar falhas de backup do cliente. Cada cliente deve obter e importar o novo certificado antes de poder se conectar a um servidor que estiver usando o novo certificado SHA padrão. Não é necessário remover certificados prévios.
  • Para atualizar manualmente o seu certificado padrão, siga as instruções na nota técnica 562939

O que fazer a seguir