BMC Client Management

(1)

-Referência técnica

(2)

Legal Notices

BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the property of their respective owners.

FootPrints is the exclusive property of Numara Software, Inc. and is registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other Numara Software trademarks, service marks, and logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the property of their respective owners.

Cisco and Cisco NAC are registered trademarks or trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.

IBM and IBM Domino are registered trademarks or trademarks of International Business Machines Corporation in the United States, other countries, or both.

IT Infrastructure Library®_{is a registered trademark of the Office of Government Commerce and is used here by BMC}

Software, Inc., under license from and with the permission of OGC.

ITIL®_{is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries.}

Linux is the registered trademark of Linus Torvalds.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

UNIX is the registered trademark of The Open Group in the US and other countries.

The information included in this documentation is the proprietary and confidential information of BMC Software, Inc., its affiliates, or licensors. Your use of this information is subject to the terms and conditions of the applicable End User License agreement for the product and to the proprietary and restricted rights notices included in the product documentation. Restricted rights legend

U.S. Government Restricted Rights to Computer Software. UNPUBLISHED—RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC SOFTWARE INC, 2101 CITYWEST BLVD, HOUSTON TX 77042-2827, USA. Any contract notices should be sent to this address.

BMC Software, Inc.

2101 CityWest Blvd, Houston TX 77042-2827, USA 713 918 8800

(3)

BMC Client Management | Sumário | 3

Sumário

Descoberta automática ...5

Estabelecendo a lista de descoberta automática... 6

Verificando endereços individuais... 8

Mesclando entradas de dispositivo...10

Purgando a lista de descoberta automática... 10

Descobrindo automaticamente a sua rede... 12

Configurando o módulo Descoberta automática... 12

Modificando parâmetros de configuração...12

Acessando localmente os resultados da descoberta automática...12

Lista de dispositivos...12

Exibindo as propriedades da Descoberta automática...13

Distribuição de agentes...13

Lista de dispositivos de descoberta automática no master...13

Objetos de descoberta automática... 13

Distribuição de agentes...15

Gerenciamento da largura de banda... 16

Portas do BCM... 18

Cronômetro... 21

Lista...21

Trabalhando com um Super Master...23

Conectando com um console do super master...23

Configurações globais... 23

Topologia do Super Master...24

Grupos de administradores...24 Grupos de dispositivos...24 Gerenciamento de patches... 24 Consultas... 25 Relatórios...25 Alertas e eventos... 25

Interface do agente do super master... 25

BMC Client Management e SSL...26

Usando SSL para conexões...26

Certificados...26

Exemplo...27

Registro do certificado em log... 29

Recomendações...30

SSL avançado e certificação... 30

SSL=2 e SSL=3...31

SSL=3 e a interface Console / Agent... 31

Gerando certificados com a ferramenta mtxcert.exe... 32

Opções de linha de comando:... 32

SSL=3 e o Console...36

Arquivos de log e depuração...37

Arquivo de log... 37

Parâmetros...37

Modificando os parâmetros de configuração...39

Arquivos de log através de acesso direto do console...39

Log principal do BCM Agent...39

(4)

4 | BMC Client Management | Sumário

Logs do Gerenciador de patches...41

Log de distribuição... 42

Log de Descoberta de recursos... 42

Arquivos de log não acessíveis no Console...43

Logs do console... 44

Arquivo de log de banco de dados...44

Arquivos de log de diagnósticos...44

(5)

BMC Client Management | Descoberta automática | 5

Descoberta automática

A topologia de dispositivos é uma hierarquia gerada automaticamente, que representa a lógica de vinculação dos servidores e clientes — ou seja, a arquitetura em cascata do próprio BMC Client Management.

O recurso Descoberta automática do BMC Client Management mantém a topologia da rede atualizada.

Todos os agentes se comunicam entre si através de uma conexão XML/RPC, o que significa que, diferentemente da arquitetura clássica, não há uma conexão permanente entre os agentes. Além disso, não existem módulos característicos que atuem como servidores e clientes. Cada agente pode desempenhar ambas as funções, de acordo com as exigências atuais, de modo que a arquitetura resultante é mais parecida com o tipo Ponto a Ponto. As consultas são estruturadas como XML e transferidas por meio do protocolo HTTP, que assegura uma comunicação padrão.

Um conceito chave do BMC Client Management é que, embora o servidor do master deva saber acessar um sistema cliente, isso não é uma regra fixa e pode evoluir dinamicamente se, por exemplo, um cliente mudar de um relay para outro. Isso é útil principalmente para os sistemas móveis que costumam mudar de um local para outro e, por conseguinte, devem ser gerenciados em um servidor de relay diferente.

O módulo Descoberta automática é utilizado pelo módulo Relay, pelo módulo Descoberta automática de outros dispositivos gerenciados e pela função Distribuição. Se o módulo Descoberta automática for desativado em um cliente com todos os outros módulos ainda funcionando separadamente, o cliente só conseguirá localizar o relay definido como seu pai durante o processo de instalação, ou no respectivo arquivo de configuração. Se o dispositivo gerenciado se movimentar — por exemplo, se for um laptop — ele não conseguirá localizar seu novo pai, porque a função de seleção automática não funcionará.

Uma regra básica da arquitetura em cascata é que um cliente esteja localizado apenas sob um relay e um relay só pode estar sob outro relay do servidor do master, garantindo, assim, que nenhum dispositivo tenha mais de um pai. O módulo Descoberta automática do BMC Client Management permite atualizações constantes da topologia da rede.

O recurso Descoberta automática estabelece e mantém uma lista local de endereços IP e os respectivos estados. Somente os módulos Relay, Descoberta automática e Distribuição de agente BCM usam a lista criada pela descoberta automática e mantida pelos outros agentes.

Os módulos de descoberta automática dos agentes podem intercambiar suas listas em intervalos regulares, o que mantém em um nível muito baixo a carga da rede e da CPU local. Na realidade, todos os endereços descobertos e as informações correspondentes são transferidos entre os módulos, evitando os desnecessários PINGs ou solicitações HTTP. Cada lista gerencia a diferença entre um endereço por ela controlado e todos os outros endereços criados através da apuração de outra lista.

(6)

6 | BMC Client Management | Descoberta automática

o relay escolhido para o agente local. Isso ocorre de acordo com as informações armazenadas na lista de descoberta automática, especificamente através do parâmetro RouterHopCount que mede a distância entre o cliente e o respectivo relay, e a velocidade com a qual ele responde.

Cada sistema do BMC Client Management, seja ele um master, relay ou cliente, dentro de um intervalo de endereços IP, pode

• descobrir a respectiva vizinhança e/ou os respectivos vizinhos • descobrir o respectivo servidor pai e

• reportar-se a e comunicar-se com o respectivo pai

• restringir a respectiva lista de descoberta automática à própria parte da rede.

Sempre que um sistema cliente detectar uma mudança própria de localização, ele deverá informar essa alteração ao respectivo pai mais próximo (a opção Seleção automática do relay deve estar definida com Sim) e assim por diante, até que o master seja notificado e atualize o respectivo banco de dados de topologias.

O módulo Descoberta automática executa as seguintes operações: • Estabelecendo a lista de descoberta automática

• Verificando endereços individuais • Mesclando entradas de dispositivo • Purgando a lista de descoberta automática

Estabelecendo a lista de descoberta automática

O trabalho do módulo Descoberta automática é centrado em uma lista de endereços IP e nomes de dispositivos continuamente atualizados e verificados. A lista contém as seguintes informações de cada entrada:

• Nome do dispositivo. Esse nome é obtido na API do Ambiente de rede Windows (Windows Network Neighbourhood) ou através de uma consulta do nome DNS utilizando o endereço IP. Se esses dois métodos não funcionarem, será definido um nome idêntico ao endereço IP.

• Endereço IP do dispositivo.

• Status da entrada (Não verificado, Verificando, Verificado, Aprendido, Inválido). • Porta HTTP utilizada para a comunicação com o agente no dispositivo.

• Data da descoberta, expressa em segundos a partir de meia-noite do dia 1º de janeiro de 1970 UTC (época). • Tempo de resposta para conexão com ping/TCP, em milissegundos.

• Número de saltos do roteador estabelecido através do ping. Esse número só pode conter os valores 1, 2, 4 ou 8. Relay ativado.

• Versão do agente.

O Status de entrada para cada endereço contido na lista de dispositivos pode ter um dos seguintes valores. O valor inteiro ao lado do nome é aquele utilizado no arquivo de banco de dadosAutodiscovery.sqlite:

Parâmetro Descrição

Não verificado - 0 O endereço IP de entrada não foi confirmado como um dispositivo realmente existente na rede. A verificação é processada através do nome da rede ou do endereço IP do dispositivo.

Verificando - 1 Verificando atualmente se este dispositivo existe na rede. Verificado - 2 O dispositivo existe na rede.

Aprendido - 3 A entrada foi absorvida de outro módulo Descoberta automática. Ao ler a lista de dispositivos em um módulo remoto, somente as entradas com status ‘Verificado’ ou ‘Aprendido’ serão retornadas. Portanto, quando uma entrada tem o status ‘Aprendido’, isso significa que sua validade foi confirmada em pelo menos mais um dispositivo existente na rede.

Inválido - 4 O endereço não respondeu a quaisquer comandos pings ou a outro tráfego da rede e, por conseguinte, não é um dispositivo válido na rede.

O módulo Descoberta automática atualiza o conteúdo da lista de dispositivos em três ocasiões possíveis, ao longo de sua operação:

(7)

1. Na inicialização do agente, após as verificações de ScanCount, e ao detectar um cliente executando o recurso Descoberta automática

O esquema da Descoberta automática exibido mais adiante neste capítulo descreverá esse processo em detalhes.

Na inicialização do agente

Quando inicializado em um dispositivo, o módulo Descoberta automática gera uma lista no respectivo banco de dados, utilizando três fontes distintas definidas através das configurações do módulo, no arquivo INI correspondente. Essas fontes são definidas por meio dos seguintes parâmetros:

Neighbours define o número de endereços IP do ambiente a serem adicionados à lista de dispositivos. A definição padrão é 10, o que significa que 5 endereços acima e 5 endereços abaixo dos dispositivos possuem endereço IP. Se definido com 0, nenhum endereço do ambiente é adicionado à lista.

AddressRange uma lista de endereços estáticos a serem adicionados à lista de dispositivos. Podem ser endereços individuais ou nomes de domínio de dispositivos ou intervalos de endereço separados por ‘,’. Por padrão, este parâmetro fica vazio.

UseNetworkNeighbourhood em uma máquina do Windows, use a API do Ambiente de rede para preencher a lista. O valor padrão dessa entrada é true. Em uma máquina do Unix/Linux, essa entrada não é utilizada.

Para restringir a lista, também é possível aplicar o seguinte parâmetro:

SameNetworkOnly _{esse valor especifica se a lista de clientes detectados e conhecidos está restrita aos} dispositivos localizados na mesma rede que o dispositivo em questão. Os possíveis valores são:

0 = Não existe um filtro aplicado a nenhum dos dispositivos descobertos, adicione todos eles

1 = Todos os dispositivos cliente descobertos devem estar na mesma rede.

2 = Todos os dispositivos descobertos, que possuem a função de relay ativada, devem estar na mesma rede.

3 = Todos os dispositivos descobertos devem estar na mesma rede.

O módulo Descoberta automática nunca adiciona duas vezes o mesmo endereço ou nome de dispositivo à respectiva lista. Se for detectada uma entrada duplicada em uma tentativa de adicionar um endereço à lista, as duas entradas serão mescladas.

Após as verificações de ScanCount

A lista de dispositivos da Descoberta automática é atualizada constantemente pelo módulo, ao confirmar o endereço mais antigo na lista. Sempre que uma entrada é confirmada como bem-sucedida ou não, sua hora de atualização é definida com a hora atual, o que a torna a entrada mais recente na lista. Dessa forma, todos os endereços são ocasionalmente confirmados em rodízio.

O módulo mantém um contador interno, incrementado sempre que uma entrada é confirmada. Quando esse contador atingue o valor configurado no parâmetro ScanCount, o conteúdo da lista é atualizado exatamente como ocorre na

(8)

ScanCount for definido com seu valor padrão 30, a lista será atualizada a cada 30 verificações. Convém observar que o conteúdo da lista atual não é excluído durante uma atualização.

Ao detectar um cliente executando o recurso Descoberta automática

Parte do processo de confirmação de um endereço abrange a verificação da existência de um agente BCM em execução no dispositivo remoto. Se um agente for encontrado e o parâmetro CanLearn dos agentes locais estiver ativado, o módulo detector tentará ler a lista de dispositivos do módulo remoto para integrá-la à sua própria lista. Considerando que o conteúdo da lista lida está sendo adicionado ao banco de dados local, todas as entradas são marcadas como 'Aprendido' para evitar a respectiva verificação posteriormente. Além disso, se uma nova entrada for encontrada na lista local, as duas entradas serão mescladas para evitar duplicatas.

Verificando endereços individuais

A principal tarefa em segundo plano do módulo Descoberta automática é verifcar periodicamente as entradas contidas na respectiva lista de dispositivos. A lista classificada pelo carimbo de hora da última atualização de cada entrada, o que posiciona as entradas atualizadas ou verificadas mais recentemente no final da lista. Para evitar a sobrecarga da rede e da CPU, é verificada apenas uma entrada de cada vez. O retardo entre a verificação das entradas consecutivas é definido pelo parâmetro VerifyInterva que, por padrão, tem o valor de 30 segundos. Para garantir que os endereços mais próximos ao dispositivo sejam verificados e confirmados logo no início, eles são adicionados à lista antes das entradas procedentes através do parâmetro Usar o Ambiente de rede. A verificação inicial é processada através das regras a seguir, e o esquema incluído no final do capítulo descreve essa operação com mais detalhes:

1. Selecione uma entrada mais antiga a ser verificada, no banco de dados. O tempo de permanência de uma entrada se baseia na hora de atualização da entrada, que representa sua última atualização ou última mesclagem com outra entrada.

2. Se a entrada a ser verificada tiver o status definido com Aprendido e ela não for um relay (RelayEnabled = 1), a verificação não ocorrerá. Sendo assim, as entradas aprendidas e já confirmadas por outros dispositivos não são verificadas novamente, a menos que sejam relays.

3. A primeira parte da verificação confirma se o endereço IP é válido, emitindo um comando ping. Para isso, o processo envia uma solicitação de eco ICMP e aguarda uma resposta. O tempo limite de espera por uma resposta é definido com o parâmetro Timeout do arquivo INI. O comando ping é utilizado não apenas para verificar a presença de um dispositivo em determinado endereço, como também para estabelecer o número de saltos do roteador para esse dispositivo e o respectivo tempo de resposta. Isso acontece ao usar o campo TTL padrão do IP na solicitação, que percorre esses valores em sequência:

(9)

• TTL = 1. Se o dispositivo estiver presente na mesma rede, uma resposta será recebida e o endereço verificado. Se nenhuma resposta for recebida, passe para a entrada seguinte.

• TTL = 8. A solicitação com TTL=1 não respondeu, o que indica que o dispositivo não existe, mas possa estar entre os vários saltos do roteador. O número máximo de saltos contados é 8 — portanto, envie uma nova solicitação com esse valor. Se nenhuma resposta for retornada, o endereço será considerado inválido. Se uma resposta for recebida, o endereço é válido e precisamos obter um valor de número de saltos mais exato.

• TTL = 4. A solicitação com TTL=8 obteve uma resposta, mas agora tente com 4. Se nenhuma resposta for recebida, o número de saltos para o endereço é 8 e não é necessário enviar outras solicitações. De outra forma, tente uma nova solicitação com um valor de TTL mais baixo.

• TTL = 2. Se uma resposta for recebida, será registrado para o endereço um número de saltos igual a 2. Uma nova solicitação com TTL=1 não é enviada porque certamente falhará. Se uma resposta for recebida, será registrado um número de saltos igual a 2.

4. Em alguns casos raros (como quando o agente não é executado como raiz no Unix), não é possível criar um soquete bruto necessário às operações do ICMP. Nessa situação, o endereço é, então, verificado, através de uma tentativa de conexão TCP com algumas portas comumente usadas. As portas utilizadas são definidas no arquivo de configuração, por meio do parâmetro TcpPortRange (os valores padrão são 23, 25, 139). O módulo percorrerá as portas até que uma delas estabeleça conexão ou até não existam mais portas restantes, em cujo caso o endereço será considerado inválido.

5. Se o comando ping ou a tentaitva de conexão via TCP obtiver êxito, isso indicará que o endereço IP realmente pertence a um dispositivo online já existente. Nesse caso, o módulo tenta detectar se existe um agente BCM em execução nesse dispositivo, enviando solicitações XML/RPC para as portas especificadas no parâmetro HttpPortRange (os valores padrão são 80, 1610, 8080). As chamadas executadas são as seguintes, nessa ordem:

• A ação de AgentIdentity é chamada em primeiro lugar, porque todos os agentes aceitam essa ação, independentemente de quais módulos estejam carregados. Se bem-sucedida, todas as informações lidas relacionadas ao cliente serão utilizadas para atualizar a entrada na lista de dispositivos. Se a chamada falhar, o endereço remoto não é um agente BCM e não será necessário chamar qualquer outra ação.

• Em seguida, a ação de RelayInfo é executada para detectar se o agente tem a função de relay ativada ou não. Isso é muito importante porque as informações serão integradas à lista de dispositivos e utilizadas posteriormente pelo módulo do Relay local, ao selecionar um dispositivo pai para se comunicar com o Master.

• Por último, se o parâmetro CanLearn for ativado, a ação de AutodiscoveryListDevices será chamada para recuperar a lista de dispositivos verificados da máquina contatada, a ser adicionada à lista do dispositivo atual. Todas as entradas lidas são marcadas como ‘Aprendido’, o que evita uma nova verificação das mesmas máquinas.

Assim que a lista for verificada e confirmada, o módulo Descoberta automática poderá iniciar um novo ciclo. Ele integrará os possíveis elementos novos, fornecidos pelo NetBIOS (Use o parâmetro Network Neighbourhood), e iniciará uma nova verificação a um ritmo de um elemento a cada 30 segundos.

(10)

Mesclando entradas de dispositivo

Quando um novo dispositivo é absorvido ou durante a atualização do conteúdo da lista, o módulo evita criar entradas duplicadas na lista. Para evitar duplicata e, ao mesmo tempo, manter o máximo de informações possível, duas entradas coincidentes são mescladas em uma só entrada que, a partir de então, é mantida na lista.

A correspondência de duas entradas, para confirmar se são cópias uma da outra, é realizada usando-se o nome do dispositivo e do endereço IP. Duas entradas serão consideradas representantes do mesmo dispositivo físico, se houver uma coincidência entre o endereço IP ou o nome do dispositivo e o endereço IP ou nome do outro. Isso significa que ocorrem 4 verificações e apenas uma delas deve ser satisfeita para que haja uma correspondência:

• Nome 1 = Nome 2? • Nome 1 = Endereço IP 2? • Endereço IP 1 = Nome 2? • Endereço IP 1 = Endereço IP 2?

Assim que duas entradas coincidirem, elas serão mescladas. O resultado da operação de mesclagem é uma entrada com valores de atributo derivados das duas entradas combinadas. As regras aplicadas para determinar qual dos dois possíveis valores deve ser usado são diferentes em cada atributo. A tabela abaixo mostra os atributos e como os respectivos valores mesclados são obtidos:

Atributo Valor mesclado

Nome do dispositivo Por ser utilizado para corresponder as 2 entradas, ele deve ser o mesmo. Se as entradas tiverem um nome em branco, será utilizado o valor não deixado em branco.

Endereço IP A mesma regra se aplica ao Nome do dispositivo.

Status da entrada Se uma das entradas tiver o status Verificado, o valor armazenado será

Verificado. De outra forma, se uma delas tiver o status Aprendido, o valor será Aprendido. Se nenhuma das opções acima for aplicável, será utilizado o status da entrada com a hora de descoberta mais tardia (mais recente).

Porta HTTP O mais alto dos dois valores é mantido.

Data de descoberta A data mais tardia (mais recente) das duas entradas é mantida.

Tempo de resposta O valor da entrada com a hora de descoberta mais tardia (mais recente) é utilizado. Contagem de saltos do

roteador

O valor da entrada com a hora de descoberta mais tardia (mais recente) é utilizado.

Nome do pai do Relay Se uma das entradas ficar vazia, será usado o valor não-vazio — de outra forma, será mantido o valor já existente no banco de dados, seja ele qual for.

Relay habilitado Se uma das entradas tiver o respectivo sinalizador Relay habilitado definido, o valor da entrada mesclada também será definido.

Versão do agente O informação da versão da entrada com a hora de descoberta mais tardia (mais recente) é utilizada.

Purgando a lista de descoberta automática

Para otimizar a manutenção da lista da Descoberta automática e evitar entradas antigas ou desatualizadas, o conteúdo da lista é purgado de acordo com as seguintes regras:

(11)

Inválido Todas as entradas que tiverem um status definido com Inválido serão removidas da lista quando ela estiver sendo atualizada, de acordo com as regras descritas anteriormente (Inicialização, ScanCount).

Tempo de vida útil Toda entrada que tiver um status 'Não verificado' será removida da lista, se seu tempo de permanência atingir o valor configurado no parâmetro MaxDeviceAge. Isso também ocorre quando o conteúdo da lista é atualizado.

Mudança do endereço IP do dispositivo

Se o endereço IP do dispositivo no qual o agente está em execução for alterado, o módulo Descoberta automática purgará TODAS as entradas contidas na respectiva lista e começará imediatamente a atualização do conteúdo. Isso acontece porque, geralmente, uma mudança de endereço implica uma conexão com uma nova rede e, por conseguinte, o conteúdo existente da lista de dispositivos certamente não é mais útil.

(12)

12 | BMC Client Management | Descobrindo automaticamente a sua rede

Descobrindo automaticamente a sua rede

A funcionalidade Descoberta automática do BCM permite verificar sua rede completa e localizar todos os dispositivos com algumas das respectivas informações disponíveis. Para descobrir a rede, devem ser executadas as seguintes etapas: 1. Configurar o módulo Descoberta automática

2. Executar uma descoberta automática em um dispositivo ou mais

3. Carregar todos os resultados de descoberta automática local no banco de dados do master

Configurando o módulo Descoberta automática

O módulo Descoberta automática é configurado para cada dispositivo individualmente por meio do respectivo nó, no nó Configuração do agente do dispositivo. Para configurar o módulo com as mesmas definições de parâmetros em vários dispositivos, você pode utilizar uma regra operacional, Configuração do módulo de Descoberta automática, explicada no manual Regras Operacionais.

Modificando parâmetros de configuração

Para modificar os parâmetros de qualquer aspecto da configuração do agente, faça o seguinte:

1. Selecione Grupos de dispositivos > Seu dispositivo gerenciado > Configuração do agente no painel da janela à

esquerda.

2. Selecione qualquer linha na tabela contida no painel da janela à direita do respectivo subnó. 3. Selecione Editar > Propriedades...

Será exibida a janela Propriedades,

4. Efetue as modificações necessárias nos valores individuais.

5. Clique no botão OK para confirmar as modificações efetuadas e fechar a janela. Todas as alterações implementadas já estão gravadas e aplicadas.

Acessando localmente os resultados da descoberta automática

Os resultados da descoberta automática podem ser acessados no console para cada dispositivo que executou essa operação. Os resultados são exibidos na guia Lista de dispositivos do nó do módulo Descoberta automática de cada dispositivo.

Lista de dispositivos

A guia Lista de dispositivos exibe a lista de dispositivos detectados pelo agente. Se um critério for modificado, os dispositivos recém detectados deverão ser adicionados à lista existente. Os dispositivos listados, que não mais atenderem aos critérios especificados, serão automaticamente excluídos da lista após determinado período de tempo. Essa lista de dispositivos pode conter qualquer dispositivo pertencente à rede específica, como impressoras, roteadores etc.

A tabela no painel da janela à direita apresenta as seguintes informações sobre os dispositivos detectados pela descoberta automática.

(13)

BMC Client Management | Descobrindo automaticamente a sua rede | 13

Nome do dispositivo O nome atribuído ao dispositivo listado e pelo qual ele é reconhecido na rede. Endereço IP O endereço IP atual do dispositivo específico.

Hora de descoberta Data e hora em que o arquivo foi detectado na rede.

Versu00e3o do agente O número da versão do agente instalado no dispositivo selecionado, ou `Nenhum` se nenhum agente estiver instalado.

Exibindo as propriedades da Descoberta automática

Para visualizar o Propriedades de um dispositivo descoberto, faça o seguinte:

1. Selecione o dispositivo cujas propriedades devem ser exibidas, na tabela contida no painel da janela à direita. 2. Selecione também o ícone Editar > Propriedades... , na barra de ferramentas.

Aparece a caixa de diálogo Propriedades que exibe todas as informações disponíveis sobre o dispositivo.

3. Clique no botão Fechar para fechar a janela.

Distribuição de agentes

Você pode selecionar nesta lista de dispositivos de descoberta automática alguns deles que não possuem ainda o agente BCM instalado, e criar uma nova configuração de distribuição do agente para instalá-lo imediatamente nesses dispositivos. Saiba que esse atalho só funcionará para os dispositivos nos quais nenhum agente está instalado, e que você não poderá atualizar o agente dessa maneira. Faça o seguinte:

1. Selecione o(s) dispositivo(s) de destino na tabela no painel da janela à direita.

2. Em seguida, selecione o ícone Editar > Distribuição de agentes , na barra de ícones. Será exibida a janela Assistente para distribuiu00e7u00e3o de agentes.

3. Siga as instruções no assistente e forneça as informações necessárias. Para obter mais detalhes sobre o assistente e os respectivos parâmetros, consulte o capítulo Distribuindo o agente BCM automaticamente por meio do Assistente, no manual Distribuição.

4. Clique em Concluir para confirmar todas as escolhas definidas no assistente e acionar a distribuição agendada.

Lista de dispositivos de descoberta automática no master

A lista de dispositivos de descoberta automática também está disponível no master. Essa lista agrega todas as informações fornecidas pelos agentes locais e os respectivos resultados. Para atualizar essa lista, as listas de resultados locais devem ser carregadas no master por meio da respectiva regra operacional, Carregar lista de descoberta automática, ou os parâmetros Intervalo de carregamento (s) e Carregar objeots de módulo da descoberta automática devem ser ativados e especificados.

Objetos de descoberta automática

Este nó apresenta a lista completa de todos os objetos detectados na rede pelo módulo de descoberta automática. Trata-se de uma compilação das listas de dispositivos descobertos automaticamente, encontrados por todos os clientes na rede. É possível filtrar a tabela dos Objetos de descoberta automática de acordo com os seguintes critérios:

(14)

14 | BMC Client Management | Descobrindo automaticamente a sua rede

Tipo de descoberta automática

Esta lista suspensa, na parte superior, permite que você defina o tipo de dispositivos de descoberta automática que devem ser exibidos na tabela abaixo.

Agente instalado Esse critério permite filtrar a lista de dispositivos de acordo com o status de instalação do dispositivo do BCM em cada um — por exemplo, se ele está instalado, não instalado ou se ele mostrará os dispositivos de ambos os casos.

A tabela do nó Objetos de descoberta automática fornece as seguintes informações sobre todos os dispositicos descobertos:

Nome Exibe o nome do dispositivo.

Endereço IP O endereço IP do dispositivo de descoberta automática.

Hora de descoberta Esta coluna informa a data e hora em que os dispositivos individuais foram descobertos pela primeira vez.

Nome do sistema operacional

Se o dispositivo descoberto for do tipo PC, este campo exibirá o respectivo sistema operacional, como Windows 2003 ou Solaris.

Nome do rede O nome de rede completo do dispositivo.

Versão do agente Esta coluna informa o número da versão do agente BCM, se ele já estiver instalado no dispositivo de descoberta automática.

Relay de carregamento Este campo informa o nome do relay que carregou o respectivo dispositivo. Tipo _{Exibe o tipo dos dispositivos descobertos automaticamente, que pode ser um dos}

seguintes: • PC

Se esta opção for selecionada, a lista exibirá todos os dispositivos do tipo PC, aqueles com e sem um agente BCM instalado.

• Impressora

Esta opção exibe todos os dispositivos descobertos automaticamente, que são impressoras.

• Switch

Esta opção exibe todos os dispositivos descobertos automaticamente, que são comutadores.

• Servidor

Esta opção exibe todos os dispositivos descobertos automaticamente, que são servidores.

• Firewall

Esta opção exibe todos os dispositivos descobertos automaticamente, que são firewalls.

• Outro

Exibe todos os dispositivos detectados na rede, com tipos diferentes daqueles listados anteriormente.

Notas Este campo pode mostrar informações adicionais sobre o dispositivo detectado automaticamente, se disponíveis.

(15)

BMC Client Management | Descobrindo automaticamente a sua rede | 15

Distribuição de agentes

Você pode selecionar nesta lista de dispositivos de descoberta automática alguns deles que não possuem ainda o agente BCM instalado, e criar uma nova configuração de distribuição do agente para instalá-lo imediatamente nesses dispositivos. Saiba que esse atalho só funcionará para os dispositivos nos quais nenhum agente está instalado, e que você não poderá atualizar o agente dessa maneira. Faça o seguinte:

1. Selecione o(s) dispositivo(s) de destino na tabela no painel da janela à direita.

2. Em seguida, selecione o ícone Editar > Distribuição de agentes , na barra de ícones. Será exibida a janela Assistente para distribuiu00e7u00e3o de agentes.

3. Siga as instruções no assistente e forneça as informações necessárias. Para obter mais detalhes sobre o assistente e os respectivos parâmetros, consulte o capítulo Distribuindo o agente BCM automaticamente por meio do Assistente, no manual Distribuição.

(16)

16 | BMC Client Management | Gerenciamento da largura de banda

Gerenciamento da largura de banda

Gerenciamento da largura de banda é um meio de alocar recursos de largura de banda em aplicativos críticos em uma rede. Sem o gerenciamento da largura de banda, um aplicativo ou um usuário pode assumir o controle de toda a largura de banda disponível e impedir que outros aplicativos ou usuários utilizem a rede.

No BMC Client Management, são necessárias duas operações para calcular quanta largura de banda deve ser usada para download por um único cliente:

1. Para medir a largura de banda atualmente disponível, alguns pacotes TCP/IP são enviados para a porta de gerenciamento de largura de banda (que, por padrão, é a 1609), a uma taxa definida por meio do parâmetro

Frequência de verificação de largura de banda (s), por padrão a cada 60 segundos, pelo período de tempo definido pelo parâmetro Duração de verificação de largura de banda (Bandwidth Check Duration), expresso em milissegundos, e o padrão é de 200 ms. Os dados são enviados uma vez por unidade de Frequência de verificação de largura de banda (s) durante o intervalo Duração de verificação de largura de banda (ms). A largura de banda atualmente disponível é calculada, dividindo-se a quantidade de dados enviados pela duração.

2. Para que os clientes se adaptem ao número total de downloads sendo atualmente executados, os clientes solicitam ao respectivo relay o número de segmentos (threads) de download atualmente em execução. Para isso, eles chamam uma ação específica no respectivo relay, no intervalo especificado pelo parâmetro Frequência de verificação de cliente (Client Check Frequency), e o intervalo padrão ocorre a cada 10 segundos.

Portanto, a quantidade total de dados enviados para um pacote na porta 1609 depende de: • Duração de verificação de largura de banda (ms)

• Largura de banda • Tamanho do pacote

• Frequência de verificação de largura de banda (s) • % Janela de transferência

Se o relay pai não responder — por exemplo, devido a problemas na rede — haverá duas opções possíveis: 1. Se as medições anteriores foram bem-sucedidas, esses dados serão utilizados no cálculo

2. Se nenhuma medição foi bem-sucedida, a transferência será bloqueada até que funcione novamente.

Se o parãmetro Frequência de verificação dos clientes (s) for definido com 0, ou seja, a verificação está desativada, cada cliente interpretará que se encontra sozinho na rede. Convém observar que o uso desse valor não funcionará com a unidade percentual de largura de banda global (% disponível) para a janela de transferência. Nesse caso, se, por exemplo, forem especificados 10% para a largura de banda disponível, o 1º cliente utilizará 10%, o 2º cliente também assumirá 10%, bem como o terceiro cliente, e assim, sucessivamente. No final, isso terminará com uma utilização muito superior a 10% em um único link da rede.

Exemplo de sintaxe:

Este exemplo descreve em detalhes o cálculo para os seguintes dados: • Duração de verificação de largura de banda (ms) = 200 ms • Largura de banda = 256 Kbps

• Tamanho do pacote = 1MB

• Frequência de verificação de largura de banda (s) = 60 s • % Janela de transferência = 30%

Para os dados fornecidos acima, uma estimativa bruta seria:

Largura de banda 256 * 1024 * 30% = 78643 bps

(17)

BMC Client Management | Gerenciamento da largura de banda | 17

Número de medições 1 no início do download + 1 após 60 s = 2 Quantidade de dados transferidos através da porta 1609 2 * 256 * 0,2 /8 = 12,8 KB

Evidentemente, esse cálculo é bastante teórico, uma vez que parâmetros, como a correlação entre a largura de banda e o número de clientes conectados, podem pesar no cálculo.

(18)

18 | BMC Client Management | Portas do BCM

Portas do BCM

Este capítulo apresenta uma lista das portas utilizadas pelo agente BCM para todos os diversos módulos do BMC Client Management, e fornece alguns detalhes sobre cada uma.

Legenda

Agente A porta de comunicação geral do agente configurada (o padrão é a 1610) Largura de

banda

Porta do gerenciamento da largura de banda (o padrão é a 1609)

MyApps Porta do MyApps (o padrão é a 1612)

TCP As portas TCP autodescobertas (o padrão é 23, 25, 139)

Multicast A porta do agente de transferência em multicast, configurada (o padrão é a 2500) LDAP Porta LDAP (o padrão é a 389)

Qualquer Iniciando porta

Notificações

São enviados pacotes XML-RPC entre os agentes de comunicação como notificações para execução de ações.

Direção Servidor pai Cliente Descrição

Parâmetro Qualquer Agente Notificação downstream Parâmetro Agente Qualquer Notificação upstream

Transferência de arquivos HTTP

A transferência de arquivos é executada por meio do protocolo HTTP e passa via FileStore — ela abrange todos os tipos de inventários, sincronização, pacotes, arquivos, atribuições, status etc.

Parâmetro Qualquer Agente Downstream (Pacote/Atribuir/Excluir/Scripts ...) Parâmetro Agente Qualquer Upstream (Status/Identidade/Inventários...) Parâmetro Qualquer Multicast Multicast

(19)

BMC Client Management | Portas do BCM | 19

Cálculo da largura de banda

Para medir a largura de banda atualmente disponível, alguns pacotes TCP/IP são enviados para a porta de gerenciamento da largura de banda a uma taxa definida, por padrão a cada 60 segundos, durante o período de tempo definido que, por padrão, é de 200 ms.

Parâmetro Largura de banda

Qualquer Dados enviados para calcular a largura de banda disponível

Parâmetro Qualquer Difusão Notificação de Wake-on-LAN

Wake-on-LAN

O recurso Wake-on-Lan envia um pacote mágico para os dispositivos de destino, para acordá-los.

Parâmetro Qualquer Difusão Notificação de Wake-on-LAN

Controle remoto

A comunicação do controle remoto se processa via imagens durante as conexões efetivas de controle remoto, e usa notificações para as verificações dos direitos de acesso.

Direção PC do

Console

Cliente Descrição

Parâmetro Qualquer Agente Transferência de imagens / ordens do teclado

Direção BCM Master Cliente Descrição

Parâmetro Qualquer Agente Notificação downstream para verificação de privacidade + resposta do cliente

Interface web do HCHL

A interface web do agente permite acessar os dados do agente através de um navegador.

Direção Navegador

web

Parâmetro Qualquer Agente Recursos gerais da interface web

Quiosque de aplicativos MyApps

(20)

20 | BMC Client Management | Portas do BCM

Direção Navegador

web

Parâmetro Qualquer Quiosque Interface web para o quiosque de aplicativos do usuário

Acesso direto

A funcionalidade Acesso direto dá acesso a áreas específicas (sistema de arquivos, Registro, serviços, Gerenciador de tarefas, ...) de um dispositivo através do console.

Direção PC do

Console

Parâmetro Qualquer Agente Funcionalidades de Acesso direto

Descoberta automática

A funcionalidade da Descoberta automática verifica se existe na rede qualquer tipo de itens de hardware (PCs, impressoras, servidores, firewalls, roteadores, ...).

Direção PC1 PC2 Descrição

Parâmetro Qualquer ICMP Ping

Parâmetro Qualquer TCP Verificação de portas TCP

Parâmetro Qualquer Agente Procure a presença do agente BCM (AgentGetIdentity) Parâmetro Qualquer Agente Peça a lista da Descoberta automática de outros

dispositivos, se o parâmetro CanLearn estiver ativado (AutodiscoveryListDevices)

Parâmetro Qualquer Agente Verifique se o dispositivo é um relay (RelayGetValue)

Sincronização do LDAP

O BCM master atua como um cliente para o servidor LDAP, com o objetivo de sincronizar os respectivos grupos com os do servidor LDAP — ou seja, dispositivos e usuários (convertidos no BCM em administradores e usuários).

Direção BCM Master Servidor

LDAP

Descrição

(21)

BMC Client Management | Cronômetro | 21

Cronômetro

O módulo Cronômetro é um módulo flexível, para todos os fins, utilizado para todas as funções de cronometragem no agente. O princípio funcional básico é o de uma lista de entradas do cronômetro onde cada uma chama uma ação quando o cronômetro “é disparado”. Existem várias aplicações internas para o agente, que precisam acessar um serviço de cronômetro, isso sem falar na necessidade de um agendador flexível para uso geral. Os tipos de ações englobam Hardware e carregamentos do Software, gerar Relatórios, gerenciar Alertas e eventos ou funções deRepositório de arquivos.

Lista

A guia Lista da tabela do módulo Cronômetro exibe a lista de todos os cronômetros existentes no momento, com as seguintes informações adicionais:

Nome O campo Nome especifica o nome atribuído a um Cronômetro específico.

Descrição A entrada Descrição é opcional. Se for utilizada, deve ser uma entrada descritiva sucinta do respectivo Cronômetro e do que ele representa.

Tipo de ativação Esta entrada define quando o cronômetro será ativado, e os possíveis valores são:

Parâmetro Nunca Se a entrada for definida com esse valor, o cronômetro nunca será ativado e seu valor de Status será automaticamente Desativado. Parâmetro Imediato Se a entrada for definida com esse valor, o cronômetro será ativado

imediatamente. Parâmetro Próximo

inicialização do agente

Por meio desse valor, o cronômetro será ativado na próxima inicialização do agente no cliente local.

Parâmetro A cada

inicialização do agente

Esse valor ativa o cronômetro em toda inicialização do agente no cliente local.

Parâmetro Data de ativação Se você selecionar esse valor, o cronômetro será habilitado ou ativado em uma data e hora definidas especificamente.

(22)

22 | BMC Client Management | Cronômetro

CronSpec _{O campo CronSpec informa a frequência de execução de cada Cronômetro específico.} A especificação do cronômetro é uma string ao estilo crontab, composta pelos seguintes intervalos:

[segundos][minutos][horas][dias][meses][dias da semana]

Cada conjunto de intervalos pode ser precedido por um símbolo de % que mudará o significado, de número absoluto para relativo. Por exemplo, se [segundos] forem iguais a 29, o cronômetro será acionado sempre que o tempo absoluto terminar com um número de segundos igual a 29 (por exemplo, 11:43:29) enquanto %20 significa a cada 20 segundos em cada minuto, por exemplo, às 13:25:00, 13:25:20, 13:25:40, 13:26:00 etc.

Intervalos são listas separadas por vírgulas. Um intervalo é formado por um número seguido ocasionalmente por um sinal de '-' e por outro número ou um sinal de '*' de qualquer valor. O número de segundos pode variar de 0 a 59 (resolução máx. de 5 segundos).

O número de minutos pode variar de 0 a 59. O número de horas pode variar de 0 a 23. O número de dias pode variar de 1 a 31.

O número de meses pode variar de 1 a 12 (1 representa janeiro).

O número de dias da semana pode variar de 1 a 6 (0 representa o domingo). Exemplos:

A cada 30 segundos: %30 * * * * *

Em todo 31 de dezembro às 0:00: * 0 0 31 12 * Às 8:15 e ao 12:15, toda segunda-feira: * 15 8,12 * * 1 O cronômetro dispara todos os dias à meia-noite. 0 0 0 * * *

O cronômetro dispara todo mês ímpar, ao meio dia, durante a semana: 0 0 12 * 1,3,5,7,9,11 1-5.

(23)

BMC Client Management | Trabalhando com um Super Master | 23

Trabalhando com um Super Master

Um super master é limitado quanto à sua funcionalidade e aos objetos por ele fornecidos no Console através do respectivo banco de dados, porque ele só consolida e informa os dados fornecidos pelos masters locais, que executarão todas as tarefas de gerenciamento da rede na parte correspondente da infraestrutura da organização. O super master armazena os dados do inventário carregados em intervalos regulares pelos servidores do master ’normal’, em diferentes locais da organização, e depois pode gerar os relatórios baseados nesses dados.

Dependendo da configuração dos masters locais, uma parte ou todos os seguintes tipos de dados de inventário podem ser consolidados no banco de dados do super master, e os dados serão carregados pelos masters locais imediatamente depois de sua integração ao banco de dados local:

• Informações dos dispositivos (nome, endereço IP, nome de domínio etc.) da lista de dispositivos de descoberta automática • Inventário de hardware • Inventário de software • Inventário personalizado • Inventário de patches • Inventário de segurança

Em si mesmo, o super master é totalmente autônomo, ou seja, ele pode criar as próprias configurações para alguns objetos específicos:

• objetos necessários para a criação de relatórios: consultas, grupos de dispositivos, grupos de patches e relatórios • configurações de dispositivo, como quando um cliente é perdido.

Conectando com um console do super master

A conexão com um console para um super master funciona exatamente da mesma maneira que a conexão para um servidor do master local. Contudo, assim que o console abrir a tela, os objetos exibidos serão limitados àqueles que você costuma ver, porque o super master é restrito em sua licença e, por conseguinte, nas funcionalidades.

O painel exibe somente os elementos necessários ao super master, ou seja, nenhum dispositivo verificado na Distribuição de Dispositivos, nenhum assistente e, evidentemente, a caixa da licença contém a licença do super master.

São exibidos os seguintes nós superiores que, mais uma vez, exibem apenas um número reduzido de seus subnós regulares: • Pesquisar • Configurações globais • Topologia de dispositivos • Grupos de dispositivos • Gerenciamento de patches • Consultas • Relatórios • Eventos

Configurações globais

O nó Configurações globais dá acesso a um número restrito de subnós, e para obter informações sobre esses tópicos, consulte os respectivos capítulos no manual básico do BCM:

(24)

24 | BMC Client Management | Trabalhando com um Super Master

Esse nó dá acesso à funcionalidade total. • Objetos de descoberta automática

As listas de objetos de descoberta automática serão carregadas pelos masters locais e disponibilizadas ao super master.

• Achados e perdidos

A funcionalidade de achados e perdidos está totalmente disponível. • Variáveis do sistema

O nó Variáveis do sistema fornece ao administrador de um super master acesso a todas as funcionalidades necessárias, como Segurança, Gerenciamento de eventos e Gerenciamento de conexões.

• Licenças

Esse nó também dá acesso à funcionalidade total.

Topologia do Super Master

Assim como em um master normal, o super master pode exibir sua topologia por meio do gráfico, exceto pelo fato de que, nesse caso, os masters normais aparecerão como relays em vez de masters, uma vez que são considerados relays pelo dispositivo pai correspondente.

O gráfico exibido mostrará a estrutura completa da empresa inteira, ou seja, começando com o super master e o primeiro nível de ’relays’ — isto é, os masters locais e, mais abaixo, a hierarquia na rede de cada master local.

A funcionalidade de topologia de dispositivos está quase totalmente disponível, e faltam apenas os objetos atribuídos. Contudo, entre as funcionalidades disponíveis para o super master constam a configuração de agentes, acesso remoto a qualquer dispositivo na rede, via acesso direto ou controle remoto. Além disso, assim como para os grupos de dispositivos, todos os tipos de inventário estão disponíveis.

Grupos de administradores

As semelhanças e diferenças dos grupos de administradores em relação aos masters locais são:

• Os grupos de administradores podem ser criados, excluídos e manipulados exatamente como em qualquer outro master.

• Os respectivos membros serão exibidos através dos subnós, exatamente como em um master local.

• Os grupos de administradores podem ser preenchidos manual ou dinamicamente através de consultas e servidores de diretórios.

• Os grupos sincronizados em um master NÃO são sincronizados no servidor do master.

Grupos de dispositivos

Os grupos de dispositivos são necessários para a geração de relatórios e, por conseguinte, estão disponíveis de modo restrito para essa finalidade. Semelhanças e diferenças em relação aos masters locais:

• Os grupos de dispositivos podem ser criados, excluídos e manipulados exatamente como em qualquer outro master. • Os respectivos membros serão exibidos através dos subnós, exatamente como em um master local.

• Os grupos de dispositivos podem ser preenchidos manual ou dinamicamente através de consultas e servidores de diretórios.

• Todos os tipos de inventário estão disponíveis.

• Nenhum objeto atribuído está disponível para os grupos de dispositivos.

• Os grupos sincronizados em um master NÃO são sincronizados simultaneamente no servidor do master.

Gerenciamento de patches

Os grupos de patches e as funcionalidades de gerenciamento de patches são necessários para a geração de relatórios e, por conseguinte, estão disponíveis de modo restrito para essa finalidade. Semelhanças e diferenças em relação aos masters locais:

• O nó Gerenciador de patches exibe a lista de todos os dispositivos definidos como Gerenciador de patches dentro da infraestrutura completa, incluindo o super master. O próprio super master não pode atualizar os ConfigFiles, mas

(25)

BMC Client Management | Trabalhando com um Super Master | 25

sempre que um master local atualizar o respectivo banco de dados, ele também atualizará automaticamente o do super master se ainda não estiver atualizado.

• O Download dinâmico está disponível de forma restrita, ou seja, quaisquer ferramentas de download existentes carregadas pelos masters locais poderão ser usadas e editadas, mas não será possível criar novas ferramentas. • Os grupos de patches podem ser criados, excluídos e manipulados exatamente como qualquer outro master ou

gerenciador de patches.

Consultas

O nó superior Consultas de um super master dá acesso à funcionalidade completa, sem quais restrições. Para obter mais informações sobre as consultas, consulte o respectivo capítulo no manual Objetos Básicos do BCM.

Relatórios

O nó superior Relatórios de um super master dá acesso à funcionalidade completa, sem quais restrições. Para obter mais informações sobre os relatórios, consulte o respectivo capítulo no manual Objetos Básicos do BCM.

Alertas e eventos

O nó superior Alertas e eventos de um super master dá acesso à funcionalidade completa, sem quais restrições. Para obter mais informações sobre os eventos, consulte o respectivo capítulo no manual básico do BCM.

Interface do agente do super master

A intergace do agente está disponível com suas guias básicas, à exceção das funcionalidades de manutenção e MyApps, assim como a página de criação de tarefas. A página de distribuição também não está acessível, mas é possível chamar o portal de relatórios.

(26)

26 | BMC Client Management | BMC Client Management e SSL

BMC Client Management e SSL

O BMC Client Management usa o protocolo SSL (Secure Sockets Layer) para transmitir qualquer tipo de dado. O SSL utiliza um sistema criptográfico que emprega duas chaves para criptografar dados — uma chave pública conhecida por todos e uma chave privada ou secreta conhecida somente pelo destinatário da mensagem. Ele cria uma conexão protegida entre o cliente e o servidor, através da qual é possível enviar qualquer quantidade de dados, de modo seguro. O agente BCM pode atuar como cliente e servidor. O cliente inicia a comunicação (estabelece a conexão), enquanto o servidor fornece um serviço (aceita a conexão).

Usando SSL para conexões

Se for necessário utilizar o SSL para conexões entre os agentes do BCM, isso deverá ser definido na instalação dos respectivos agentes. No processo de instalação, defina também o tipo de conexão SSL utilizado, por meio do seguinte parâmetro e das respectivas opções. Esse parâmetro também se aplica à conexões entre o console do BCM e o respectivo servidor:

Comunicação segura

Este parâmetro define se o agente se comunicará em formato seguro. Os possíveis valores são:

Parâmetro Não (0) Com esta opção, o agente aceita a comunicação com e sem segurança, mas ele só enviará comunicações sem segurança. Parâmetro Envio seguro,

receber ambos (1)

Este valor indica que o agente aceita comunicações com e sem segurança, mas ele só enviará comunicações com segurança. Parâmetro Sim (2) Com esta opção selecionada, o agente só se comunicará no modo

seguro, isto é, ele só receberá e enviará comunicações protegidas. Parâmetro Sim, com

autenticação mútua (3)

Com esta opção, o agente se comunicará no medo seguro e, além disso, ocorrerá uma autenticação mútua via SSL.

Este parâmetro é definido durante a instalação dos componentes ou, no caso do console, quando ele for acionado. Contudo, ele pode ser modificado a qualquer momento através das configurações de parâmetros do agente no Console ou nos respectivos arquivos de configuração. O modo como o console se conecta ao servidor poderá ser redefinido sempre que uma conexão for estabelecida.

Se todos os agentes se comunicarem apenas no modo seguro (modo SSL=2 ou SSL=3), o console também deverá ser ativado com o protocolo SSL ao se conectar com um dispositivo, marcando a caixa correspondente na janela de abertura do console. De outra forma, se uma conexão não-SSL for estabelecida entre o console e o agent, ela será imediatamente encerrada de novo pelo agente.

Certificados

O padrão SSL é utilizado habitualmente na autenticação do servidor. Durante uma conexão com um servidor web seguro por meio de um navegador (HTTPS em vez de HTTP), geralmente é exibido um pop-up com uma mensagem porque o certificado recebido não é confiável. Sendo assim, é necessário decidir se a conexão deve ser aceita ou o se o handshake (aperto de mãos) deve ser cancelado. Isso acontece porque um servidor protegido é responsável por enviar o respectivo

(27)

BMC Client Management | BMC Client Management e SSL | 27

certificado de servidor, no início do handshake de SSL. Em seguida, o cliente é responsável por permitir ou não a conexão, dependendo do emissor do certificado. O emissor do certificado é a autoridade que assinou (concedeu) a certificação. Se uma autoridade for confiável, todos os certificados assinados por essa autoridade serão confiáveis.

As próprias conexões SSL entre os agentes são gerenciadas por certificados. Esses certificados permitem que o agente tenha acesso a todos os outros agentes que ele precisa acessar. Contudo, através desses certificados, também é possível isolar totalmente uma parte da rede — por exemplo, uma sub-rede ou até mesmo a rede inteira.

Os seguintes tipos diferentes de certificados são usados para a comunicação do agente: • Certificate Authority (CertAuth)

A autoridade de certificação assina o certificado do agente (servidor BCM do cliente). • Trusted Certificates (CertTrusted)

Ao solicitar uma conexão com outro agente, um agente aceitará essa conexão se o certificado foi assinado por uma das autoridades confiáveis listadas no respectivo parâmetro de certificados confiáveis. Se o certificado retornado estiver assinado por uma autoridade desconhecida, o agente solicitante abandonará a conexão.

Esses certificados são especificados por meio dos respectivos parâmetros, na seção Security (Segurança) do arquivo de configuração do agente (mtxagent.ini). Se nenhum certificado estiver definido, os certificados padrão da BMC serão estabelecidos como autoridade, e usados na certificação. Os parâmetros devem ser modificados individualmente nos agentes dos dispositivos, no arquivo .ini, ou podem ser alterados em massa através da regra operacional que permite modificar um arquivo de configuração.

O gráfico acima mostra um exemplo com duas sub-redes que possuem autoridades de certificação distintas, Asia e Europe. Os agentes na sub-rede podem contatar todos os outros agentes na respectiva sub-rede, mas NÃO aqueles do restante da rede.

Exemplo

Se o exemplo apresentado acima for dividido em suas partes individuais, as seguintes autoridades e certificados deverão ser estabelecidos para permitir a comunicação correta dentro das sub-redes e da rede inteira:

A rede tem três autoridades de certificação: MasterServer, Asia e Europe.

• Para se conectar com todos os seus filhos,o servidor do master deverá ter os seguintes certificados: CertAuth: MasterServer

CertTrusted: MasterServer, Asia, Europe

• No exemplo abaixo, o console só pode se conectar com o servidor do master, com os respectivos certificados: CertAuth: MasterServer

(28)

Se o console também precisar se comunicar com outros dispositivos via controle remoto ou acesso direto, ele também deverá confiar nas outras autoridades — caso contrário, esses dispositivos não poderão ser acessados por meio das funcionalidades mencionadas anteriormente. Portanto, ele exige os seguintes certificados:

CertAuth: MasterServer

CertTrusted: MasterServer, Asia, Europe

• Para se comunicarem entre si, todos os dispositivos localizados na sub-rede Asia devem ter os seguintes certificados: CertAuth: Asia

CertTrusted: Asia

• Para se comunicarem entre si, todos os dispositivos localizados na sub-rede Europe devem ter os seguintes certificados:

CertAuth: Europe CertTrusted: Europe

• Para se comunicar com todos os respectivos filhos e com o pai direto (o servidor do master), o principal relay Asia deve ter os seguintes certificados:

CertAuth: Asia

CertTrusted: Asia, MasterServer

Além disso, para se comunicar com o principal relay europeu (e, portanto, com os respectivos filhos), a entrada confiável deverá conter as seguintes entradas:

CertTrusted: Asia, MasterServer, Europe.

Isso significa que o relay Asia pode contatar qualquer dispositivo existente na sub-rede Europe, mas não vice-versa — ou seja, os dispositivos presentes nessa sub-rede não poderão contatar o relay asiático.

• Para se comunicar com todos os respectivos filhos e com o pai direto (o servidor do master), o principal relay Europe deve ter os seguintes certificados:

CertAuth: Europe

CertTrusted: Europe, MasterServer

Para isolar totalmente uma sub-rede —por exemplo, a França (France) da sub-rede europeia — é necessário criar outra autoridade para o principal servidor francês: France.

O relay francês e todos os respectivos filhos terão a seguinte configuração de certificado, de modo que não conseguirão contatar qualquer outro dispositivo que estiver fora de sua sub-rede:

(29)

BMC Client Management | BMC Client Management e SSL | 29

CertAuth: France CertTrusted: France

Para o exemplo acima, o principal relay europeu precisará agora de outra autoridade confiável para conseguir contatar essa sub-rede — caso contrário, não será possível qualquer comunicação entre a sub-rede France e o restante da rede: CertTrusted: Europe, France

Da forma como as conexões são apresentadas no gráfico acima, a rede francesa pode ser contatada por um único dispositivo, o relay europeu, e nem mesmo o servidor do master poderá contatar essa sub-rede. Para que o servidor do master possa fazer isso, a sub-rede francesa também deverá ser adicionada à lista correspondente de autoridades confiáveis:

CertTrusted: MasterServer, Asia, Europe, France

Registro do certificado em log

O log do agente, mtxagent.log, também protocola as autoridades e os certificados criados. A aparência de uma entrada seria como a seguinte, que representa a certificação padrão da BMC, o nome gerado da autoridade é BMC, a única autoridade confiável é a BMC:

Autoridade de certificação:

2008/01/21 14:39:03 AgentSecurity I Cert[000] Root : certs/auth/ 2008/01/21 14:39:03 AgentSecurity I Cert[000] Name : Numara_ca

2008/01/21 14:39:03 AgentSecurity I Cert[000] Home : fde4b4e9dbd690bd2c56d60f061598da 2008/01/21 14:39:03 AgentSecurity I Cert[000] Hash : f061c793e7f33e6d04f12cf8c2c9cec3 2008/01/21 14:39:03 AgentSecurity I Cert[000] Issuer : <emailAddress=info@Numarasoftware.com; CN=Numara CA; OU=Numara AMP; O=Numara Software; L=Sophia Antipolis; ST=PACA; C=FR>

2008/01/21 14:39:03 AgentSecurity I Cert[000] Subject: <emailAddress=info@Numarasoftware.com; CN=Numara CA; OU=Numara AMP; O=Numara Software; L=Sophia Antipolis; ST=PACA; C=FR>

2008/01/21 14:39:03 AgentSecurity I Cert[000] Valid : Yes 2008/01/21 14:39:03 AgentSecurity I Cert[000] Active : No

Certificado do servidor:

2008/01/21 14:39:03 AgentSecurity I Cert[001] Root : certs/server/ 2008/01/21 14:39:03 AgentSecurity I Cert[001] Name : Numara_agent

2008/01/21 14:39:03 AgentSecurity I Cert[001] Home : d862892c0c275bd377ff77d2b83c4345 2008/01/21 14:39:03 AgentSecurity I Cert[001] Hash : dd8d10f9bc9c4cc5b1bff423072848b0 2008/01/21 14:39:03 AgentSecurity I Cert[001] Issuer : <emailAddress=info@Numarasoftware.com; CN=Numara CA; OU=Numara AMP; O=Numara Software; L=Sophia Antipolis; ST=PACA; C=FR>

2008/01/21 14:39:03 AgentSecurity I Cert[001] Subject: <CN=192.168.1.229; O=Numara Software; L=Sophia Antipolis; ST=PACA; C=FR>

2008/01/21 14:39:03 AgentSecurity I Cert[001] Valid : Yes 2008/01/21 14:39:03 AgentSecurity I Cert[001] Active : Yes

Certificado confiável:

2008/01/21 14:39:03 AgentSecurity I Cert[002] Root : certs/trusted/ 2008/01/21 14:39:03 AgentSecurity I Cert[002] Name : Numara_ca

2008/01/21 14:39:03 AgentSecurity I Cert[002] Home : 33c402d87af0a0359db2c73339b013e4 2008/01/21 14:39:03 AgentSecurity I Cert[002] Hash : f061c793e7f33e6d04f12cf8c2c9cec3

2008/01/21 14:39:03 AgentSecurity I Cert[002] Issuer : <emailAddress=info@Numarasoftwaren.com; CN=Numara CA; OU=Numara AMP; O=Numara Software; L=Sophia Antipolis; ST=PACA; C=FR>

2008/01/21 14:39:03 AgentSecurity I Cert[002] Subject: <emailAddress=info@Numarasoftware.com; CN=Numara CA; OU=Numara AMP; O=Numara Software; L=Sophia Antipolis; ST=PACA; C=FR>

2008/01/21 14:39:03 AgentSecurity I Cert[002] Valid : Yes 2008/01/21 14:39:03 AgentSecurity I Cert[002] Active : Yes

(30)

Recomendações

Ao utilizar o SSL e, por conseguinte, os certificados, a BMC Software recomenda enfaticamente que você planeje com cuidado a estratégia de autoridades e certificados antes de efetivamente colocá-la em prática. Você também pode fazer alterações posteriormente, mas se não tiver MUITO cuidado, toda a comunicação poderá ser interrompida.

Se todos os componentes forem instalados com o SSL ativado, eles serão iniciados com a autoridade padrão e os certificados da BMC; por padrão, a distribuição do agente não contém quaisquer certificados personalizados. Assim que você efetuar alterações em um único agente, é bem possível que nenhum agente consigar se comunicar mais. Portanto, é recomendável preparar sua instalação completa do SSL. Isso significa:

• preparar todas as regras operacionais através do Atualizar arquivo INI, modificando a seção [Security] dos arquivos mtxagent.ini de TODOS os dispositivos da rede para as novas autoridades e certificados correspondentes • criar as consultas e os grupos necessários para enviar e executar essas regras operacionais

• criar os pacotes para distribuir os novos arquivos de certificado e

• atribuir a esses grupos as regras operacionais com uma agenda comum, para garantir que a maioria das regras, ou seja, as modificações dos arquivos ini, sejam executadas praticamente ao mesmo tempo. Isso limitará o tempo de paralisação na comunicação o máximo possível.

Assim que as regras operacionais forem acionadas, dê tempo para que o sistema as receba e execute — portanto, durante algum tempo, uma parte ou toda a rede pode não funcionar através dos agentes do BCM, até que todas as regras sejam executadas em todos os dispositivos. Dependendo do funcionamento dos dispositivos, é possível que partes da rede ainda não estejam acessíveis até se reconectarem para, em seguida, receber e migrar para o novo esquema.

SSL avançado e certificação

Você encontrará a seguir informações mais avançadas sobre a combinação do SSL com a certificação no BMC Client Management.

Parâmetro CertAuth

No BMC Client Management, uma autoridade do agente pode ser substituída. O parâmetro CertAuth no arquivo de configuração do agente (mtxagent.ini) contém o nome da autoridade de certificação a ser utilizada para assinar o certificado do agente.

Ao iniciar, o agente verifica esse diretório e instala qualquer certificado novo como novas autoridades disponíveis. Todos os arquivos devem ter o mesmo nome comum (apenas a extensão é diferente). Esse nome comum é usado no arquivo de configuração para eleger a nova autoridade.

Para trocar a autoridade de certificação, os arquivos necessários devem ser movidos primeiramente para o diretório ${AGENT_BIN}/certs/auth. Esses arquivos são:

• o certificado X509 da autoridade (extensão .crt) • a respectiva Chave Privada RSA anexada (extensão .key)

• um arquivo opcional Key Encrypted Password (extensão .kep — Senha Criptografada por Chave)

O arquivo KEP (Key Encrypted Password) é um recurso oferecido pela BMC, capaz de cifrar a Chave Privada RSA (RSA Private Key) com uma senha que não precisa ser implantada, e o agente BCM pode recuperar a senha, dependendo dos diversos elementos. A geração automática de senha se baseia em diferentes fragmentos de informações, como os nomes de arquivos. Portanto, não será possível renomear qualquer um dos arquivos quando a funcionalidade KEP estiver em uso.

Parâmetro CertTrusted

O agente BCM deve reconhecer as autoridades confiáveis, de modo que o segundo parâmetro, CertTrusted, no arquivo de configuração do agente (mtxagent.ini) contém uma lista separada por vírgulas de certificados de autoridades confiáveis. Aqui também, é necessário instalar um certificado antes de ser mencionado na configuração. Diferentemente da autoridade, é necessário apenas o certificado X509 (extensão .crt) para que uma autoridade seja confiável.