Considerações de Segurança ao Registrar um Nó Base do Servidor de Aplicativos no Agente Administrativo
É possível optar por centralizar o controle de seus servidores de aplicativos base independentes, registrando-os no agente administrativo. Se o seu servidor de aplicativos base estiver atualmente configurado com segurança, algumas questões requerem consideração. Essas considerações de segurança aplicam-se ao uso do comando registerNode e do comando deregisterNode.
O objetivo do comando registerNode é assumir um nó base independente e convertê-lo em um que seja gerenciado pelo agente administrativo. O parâmetro principal do comando registerNode é profilePath, que especifica onde na máquina local o agente administrativo pode localizar o nó. O parâmetro portsFile contém chaves para determinar em quais portas o agente administrativo atenderá em nome do nó base. O formato é o mesmo que aquele da linha de comandos manageProfiles.
O comando registerNode é executado a partir do próprio agente administrativo. Ele é utilizado para registrar um nó em um agente administrativo. O agente administrativo precisa estar no mesmo sistema que o nó que está sendo registrado. O comando registerNode só é válido em um nó base. Se um nó tiver sido associado a um gerenciador de implementação, o comando registerNode falhará com um erro.
Primeiramente, o processo de troca de signatários do registro de perfil processa a configuração padrão de Secure Sockets Layer (SSL), na qual obtém os signatários do certificado raiz do NodeDefaultRootStore do agente administrativo e os armazena no NodeDefaultTrustStore do perfil de destino. Em seguida, o processo obtém os signatários do certificado raiz do NodeDefaultRootStore dos perfis de destino e os armazena no NodeDefaultTrustStore do agente administrativo. Os assinantes são armazenados no truststore dos perfis de destino usando o prefixo de alias "agent_signer", e são armazenados no truststore dos agentes administrativos usando o prefixo de alias "<profileName>_signer".
Em seguida, o processo de troca de signatários do registro de perfil processa a configuração de autenticação de RSAToken, na qual obtém os signatários do certificado raiz do NodeRSATokenRootStore do agente administrativo e os armazena no NodeRSATokenTrustStore do perfil de destino. Em seguida, o processo obtém os signatários do certificado raiz do NodeRSATokenRootStore dos perfil de destino e os armazena no NodeRSATokenTrustStore do agente administrativo. Os assinantes são armazenados no truststore do perfil de destino usando o prefixo de alias "agent_signer", e são armazenados no truststore dos agentes administrativos usando o prefixo de alias "<profileName>_signer".
Além disso, o processo de registro armazena todos os signatários do certificado raiz (SSL e RSAToken) do agente administrativo no armazenamento de confiança do cliente do perfil de destino (ClientDefaultTrustStore, por padrão).
O comando deregisterNode ativa o processo de remoção de registro, que remove todos os signatários trocados durante o processo de registro do agente administrativo e do perfil de base. A configuração do nó base é retida, exceto que ele é marcado como não registrado com um agente administrativo. Esse comando só é válido para um nó base registrado anteriormente.
- Ao tentar executar os comandos de gerenciamento de sistemas, como o comando registerNode,
você precisará especificar explicitamente as credenciais administrativas para executar a operação. O comando registerNode 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 registerNode:
registerNode -profilePath /WebSphere/AppServer/profiles/default -host localhost -connType SOAP -port 8877 -username WSADMIN -password ADMINPWD
- Antes de registrar-se em um agente administrativo, um nó deve ter a segurança administrativa ativada ou desativada.
- Quando um nó for registrado, não será possível ativar ou desativar a segurança administrativa desse nó (ou de qualquer outro nó registrado) até o registro do nó ser removido.
Perguntas gerais e respostas que podem ajudar a usar registerNode com segurança
- A configuração de segurança de um nó pode ser mudada após ser registrada em um agente administrativo?
- A segurança administrativa deve ser ativada no agente administrativo e em todos os nós registrados -ou- ser desativada no agente administrativo e em todos os nós registrados. Além disso, os nós registrados e o agente administrativo podem ter outras configurações de segurança diferentes antes ou após o nó ser registrado. No entanto, a configuração de segurança administrativa deve ser consistente entre o agente administrativo e os nós registrados.
- A configuração de segurança do agente administrativo pode ser mudada após ele registrar um nó?
- Não. Veja a pergunta e resposta anteriores. A configuração de segurança administrativa não seria consistente entre os agentes administrativos e os nós registrados.
- Um nó precisa ter a segurança ativada se o agente administrativo tiver a segurança ativada?
- Sim. Um nó precisa ter a segurança administrativa ativada se o agente administrativo tiver a segurança administrativa ativada.
- O agente administrativo e o nó podem ter configurações e valores de segurança diferentes antes de o nó ser registrado?
- Sim, exceto para o valor de segurança administrativa.
- Qual é o uso adequado para os parâmetros: -username username / -password password e -nodeusername node_user_name / -nodepassword node_password no comando registerNode?
- username / password refere-se a um usuário
administrativo e uma senha definidos no agente administrativo. nodeusername / nodepassword refere-se ao usuário
administrativo e a senha definidos no nó a ser registrado. Nota: nodeusername / nodepassword são necessários somente quando a segurança administrativa é ativada no agente administrativo e no nó a ser registrado.Exemplo de uso de RegisterNode:
${WAS_ROOT}/profiles/AA_1/bin/registerNode.sh -connType SOAP -port ${soap} -username $SUSER -password $SPASS -profilePath ${WAS_ROOT}/profiles/AS_1_1 -nodeusername $SUSER2 -nodepassword $SPASS2
![[z/OS]](../images/ngzos.gif)
Quando um registro local do System Authorization Facility (SAF) é usado para segurança administrativa, o ID do usuário que é usado para chamar os comandos registerNode.sh e deregisterNode.sh deve ter privilégios administrativos para o agente administrativo e deve também estar conectado ao grupo de configurações do UNIX System Services para o agente administrativo e seu(s) servidor(es) de aplicativos.