Considerações de Segurança ao Incluir um Nó do Application Server Base no WebSphere Application Server, Network Deployment

Você talvez decida centralizar a configuração de seus servidores de aplicativos de base independentes incluindo-os em uma célula do WebSphere Application Server, Network Deployment. Se o servidor de aplicativos base estiver atualmente configurado com segurança, algumas questões devem ser consideradas. A principal questão ao incluir um nó na célula é se os registros de usuários entre o servidor de aplicativos base e o gerenciador de implementação são os mesmos.

[IBM i][AIX Solaris HP-UX Linux Windows]Ao adicionar um nó à célula, você herda automaticamente o registro de usuário e o mecanismo de autenticação da célula.

[z/OS]Ao incluir um nó em uma célula, o nó recém-federado automaticamente herda o registro do usuário (S.O. Local, LDAP ou Customizado), o mecanismo de autenticação (LTPA) e a configuração de autorização (ligações do WebSphere ou perfis EJBROLE do System Authorization Facility (SAF)) da célula existente do WebSphere Application Server, Network Deployment.

Para a segurança distribuída, todos os servidores da célula devem utilizar o mesmo registro de usuário e mecanismo de autenticação. Para recuperar-se de uma mudança no registro do usuário, você deve modificar os aplicativos para que os mapeamentos de usuário e grupo para as funções estejam corretos para o novo registro do usuário. Consulte o arquivo sobre Atribuindo usuários e grupos a funções.

Outra consideração importante é a infraestrutura de chave pública do SSL (Secure Sockets Layer). Antes de executar o comando addNode com o gerenciador de implementação, verifique se o comando addNode pode se comunicar como um cliente SSL com o gerenciador de implementação. Essa comunicação requer que o armazenamento de confiança addNode configurado no arquivo sas.client.props tenha o certificado signatário do certificado pessoal do gerenciador de implementação, conforme localizado no armazenamento de chave e especificado no console administrativo.

As questões a seguir devem ser levadas em consideração ao executar o comando addNode com segurança:
  • Ao tentar executar os comandos de gerenciamento do sistema, como o comando addNode, você precisa especificar explicitamente as credenciais administrativas para executar a operação. O comando addNode aceita os parâmetros -username e -password para especificar o ID do usuário e a senha, respectivamente. O ID do usuário e senha especificados devem ser para um usuário administrativo; por exemplo, um usuário que seja membro dos usuários do console com privilégios de Administrador ou o ID do usuário administrativo configurado no registro do usuário. Segue um exemplo do comando addNode:

    addNode CELL_HOST 8879 -includeapps -username user -password pass.

    O parâmetro -includeapps é opcional, mas essa opção tenta incluir os aplicativos do servidor no Gerenciador de Implementações. O comando addNode pode falhar se os registros de usuários usados pelo WebSphere Application Server e o gerenciador de implementação não forem os mesmos. Para corrigir esse problema, faça dos registros dos usuários os mesmos ou desligue a segurança. Se você alterar os registros de usuários, lembre-se de verificar se os mapeamentos de usuários para funções e grupos para funções estão corretos. Consulte Comando addNode para obter informações adicionais sobre a sintaxe de addNode.
    [z/OS]Nota: Também é possível executar o comando addNode utilizando o WebSphere z/OS Profile Management Tool ou o comando zpmt. Se você emitir o comando addNode com a segurança ativada usando o WebSphere z/OS Profile Management Tool ou o comando zpmt, deverá usar um ID de usuário com autoridade e especificar as opções -user e -password.
  • A inclusão de um nó remoto protegido por meio do Administrative Console não é suportada. É possível desativar a segurança no nó remoto, antes de executar a operação, ou executar a operação a partir da linha de comandos utilizando o script addNode.
  • [IBM i][AIX Solaris HP-UX Linux Windows]Antes de executar o comando addNode, você deve verificar se os arquivos truststore nos nós podem se comunicar com os arquivos de armazenamento de chaves a partir do gerenciador de implementação e vice-versa. Ao utilizar o padrão DummyServerKeyFile e DummyServerTrustFile, você não deverá ver esse problema , já que esses já podem se comunicar. Entretanto, nunca use esses arquivos fictícios em um ambiente de produção.
  • [z/OS]Antes de executar o comando addNode, você deve verificar se os arquivos truststore nos nós se comunicam com os arquivos de armazenamento de chaves e o anel de chaves do SAF (System Authorization Facility) de propriedade do gerenciador de implementação e vice-versa. Se você gerar os certificados para o gerenciador de implementação utilizando a mesma autoridade de certificação que utilizou para o processo de agente do nó, obterá êxito. As configurações SSL a seguir devem conter armazenamentos de chaves e armazenamentos confiáveis que possam interoperar:
    • Repertório SSL do Sistema que é especificado no console administrativo usando Administração do Sistema > Gerenciador de Implementação > Transportes HTTP > sslportno > SSL.
    • Repertório SSL para o conector JMX apropriado se o SOAP for especificado Administração do Sistema > dmgr > Serviços de Administração > Conectores JMX > SOAPConnector > Propriedades Customizadas > sslConfig.
    • Repertório SSL que é especificado em Administrador do Sistema NodeAgent > Agentes do Nó > Servidor NodeAgent > Serviços de Administração > Conectores JMX > SOAPConnector > Propriedades Customizadas > sslConfig.
    Nota: O WebSphere Application Server para z/OS define domínios de segurança usando prefixos de perfil do SAF (referidos anteriormente como domínios de segurança do z/OS) na WebSphere z/OS Profile Management Tool ou no comando zpmt. Preste atenção ao incluir um nó em uma configuração do Deployment Manager que define um domínio de segurança diferente.
  • Quando um cliente de uma liberação anterior tenta usar o comando addNode para federar-se a um gerenciador de implementação 7.0, primeiro o cliente deve obter assinantes para um handshake bem-sucedido. Para obter mais informações, veja Obtendo assinantes para clientes e servidores a partir de uma liberação anterior no artigo sobre Instalação segura para recuperação de assinante de cliente em SSL.
  • Após executar o comando addNode, o servidor de aplicativos está em um novo domínio SSL. Ele pode conter as configurações SSL que apontam para os arquivos de armazenamento de chaves e de armazenamento confiável que não estejam preparados para interoperar com outros servidores do mesmo domínio. Considere quais servidores estão se comunicando entre si e assegure que os servidores sejam confiáveis em seus arquivos truststore.
O entendimento adequado das interações de segurança entre os servidores distribuídos reduz muito os problemas encontrados com comunicações seguras. A segurança inclui complexidade, porque funções adicionais precisam ser gerenciadas. A segurança precisa ser considerada em detalhes durante o planejamento da infraestrutura. Este documento ajuda a reduzir os problemas que podem ocorrer devido a interações de segurança inerentes.

Quando tiver problemas de segurança relacionados ao ambiente do WebSphere Application Server, Network Deployment, consulte Resolvendo Problemas de Configurações de Segurança para localizar informações adicionais sobre o problema. Quando o rastreio é necessário para solucionar um problema porque os servidores são distribuídos, frequentemente é necessário reunir rastreio de todos os servidores simultaneamente durante a recriação do problema. Esse rastreio pode ser ativado dinâmica ou estaticamente, dependendo do tipo de problema que está ocorrendo.


Ícone que indica o tipo de tópico Tópico de Referência



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rsec_ewac
Nome do arquivo: rsec_ewac.html