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.
Ao adicionar um nó à célula, você herda automaticamente o registro de usuário e o mecanismo de autenticação da célula.
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.
- 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.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.
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.
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 .
- Repertório SSL para o conector JMX apropriado se o SOAP for especificado .
- Repertório SSL que é especificado em .
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.
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.