Autenticação e Encriptação de Dados no Operations Manager

Importante

Esta versão do Operations Manager chegou ao fim do suporte. Recomendamos que atualize para o Operations Manager 2022.

O System Center Operations Manager consiste em funcionalidades como o servidor de gestão, o servidor de gateway, o Servidor de relatórios, a base de dados Operacional, o armazém de dados de relatórios, o agente, a consola Web e a Consola de operações. Este artigo explica como a autenticação é executada e identifica os canais de ligação onde os dados são encriptados.

Autenticação Baseada em Certificados

Quando um servidor de gestão e agente do Operations Manager são separados por um limite de grupo de trabalho ou uma floresta não fidedigna, será necessário implementar uma autenticação com base em certificados. As secções seguintes fornecem informações sobre estas situações e procedimentos específicos para obter e instalar certificados de autoridades de certificação baseadas no Windows.

Configurar a Comunicação entre Agentes e Servidores de Gestão dentro do Mesmo Limite de Fidedignidade

Um agente e o servidor de gestão utilizam a autenticação do Windows para se autenticarem mutuamente entre si antes do servidor de gestão aceitar dados do agente. O protocolo Kerberos versão 5 é o método predefinido para fornecer autenticação. Para que a autenticação mútua baseada no Kerberos funcione, os agentes e o servidor de gestão devem ser instalados num domínio do Active Directory. Se um agente e um servidor de gestão estiverem em domínios separados, tem de existir fidedignidade total entre os domínios. Neste cenário, depois da realização da autenticação mútua, o canal de dados entre o agente e o servidor de gestão está encriptado. Não é necessária intervenção do utilizador para que sejam efetuadas a autenticação e a encriptação.

Configurar a Comunicação entre Agentes e Servidores de Gestão através de Limites de Fidedignidade

Um agente (ou agentes) pode ser implementado num domínio (domínio B) separado do servidor de gestão (domínio A) e não pode existir qualquer fidedignidade de dois sentidos entre os domínios. Uma vez que não existe confiança entre os dois domínios, os agentes num domínio não podem autenticar-se com o servidor de gestão no outro domínio com o protocolo Kerberos. Continua a ocorrer autenticação mútua entre as funcionalidades do Operations Manager dentro de cada domínio.

Uma solução para esta situação é instalar um servidor de gateway no mesmo domínio em que os agentes residem e, de seguida, instalar certificados no servidor de gateway e no servidor de gestão para alcançar a autenticação mútua e a encriptação de dados. A utilização do servidor de gateway significa que necessita apenas de um certificado no domínio B e apenas uma porta através da firewall, conforme apresentado na ilustração seguinte.

Configurar a Comunicação através de um Domínio – Limite do Grupo de Trabalho

No seu ambiente, poderá ter um ou dois agentes implementados num grupo de trabalho no interior da firewall. O agente no grupo de trabalho não consegue autenticar-se com o servidor de gestão no domínio com o protocolo Kerberos. Uma solução para esta situação é instalar certificados tanto no computador que aloja o agente, como no computador que aloja o servidor de gestão ao qual o agente se liga, conforme apresentado na ilustração seguinte.

Nota

Neste cenário, o agente deve ser instalado manualmente.

Execute os seguintes passos tanto no computador que aloja o agente, como no computador que aloja o servidor de gestão, utilizando a mesma autoridade de certificação (AC) para cada:

1. Pedir certificados da AC.
2. Aprovar os pedidos de certificado na AC.
3. Instale os certificados aprovados nos arquivos de certificados do computador.
4. Utilize a ferramenta MOMCertImport para configurar o Operations Manager.

Nota

Os certificados com o KEYSPEC diferente de 1 não são suportados.

Estes são os mesmos passos para instalar certificados num servidor de gateway, exceto se não instalar ou executar a ferramenta de aprovação do gateway

Confirmar a Instalação do Certificado

Se tiver instalado corretamente o certificado, o evento seguinte será escrito no registo de eventos do Operations Manager.

Tipo	Fonte	ID do Evento	Geral
Informações	Conector OpsMgr	20053	O Conector OpsMgr carregou com êxito o certificado de autenticação especificado.

Durante a configuração de um certificado, executa a ferramenta MOMCertImport. Quando a ferramenta MOMCertImport tiver concluído, o número de série do certificado que importou é escrito no registo na subchave seguinte.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings

Atenção

A edição incorreta do registo pode danificar gravemente o sistema. Antes de efetuar alterações no registo, deve criar uma cópia de segurança de todos os dados importantes existentes no computador.

Autenticação e encriptação de dados entre o servidor de gestão, o servidor de Gateway e agentes

A comunicação entre estas funcionalidades do Operations Manager começa com a autenticação mútua. Se existirem certificados em ambas as extremidades do canal de comunicações, os certificados serão utilizados para autenticação mútua; caso contrário, é utilizado o protocolo Kerberos versão 5. Se duas funcionalidades estiverem separadas através de um domínio não fidedigno, a autenticação mútua deve ser efetuada utilizando certificados. As comunicações normais, tal como eventos, alertas e implementação de um pacote de gestão, ocorrem através deste canal. A ilustração anterior mostra um exemplo de um alerta a ser gerado num dos agentes que é encaminhado para o servidor de gestão. Do agente para o servidor da gateway, o pacote de segurança do Kerberos é utilizado para encriptar os dados, porque o servidor da gateway e o agente estão no mesmo domínio. O alerta é desencriptado pelo servidor da gateway e encriptado novamente utilizando certificados para o servidor de gestão. O servidor de gateway envia a mensagem encriptada para o servidor de gestão onde o servidor de gestão desencripta o alerta. Alguma comunicação entre o servidor de gestão e o agente pode incluir informações de credencial; por exemplo, tarefas e dados de configuração. O canal de dados entre o agente e o servidor de gestão adiciona outra camada de encriptação para além da encriptação de canal normal. Não é necessária a intervenção do utilizador.

Servidor de gestão e consola de Operações, servidor da consola Web e servidor de Relatórios

A autenticação e a encriptação de dados entre o servidor de gestão e a consola de Operações, o servidor da consola Web ou o servidor de Relatórios são alcançadas através da tecnologia do Windows Communication Foundation (WCF). A tentativa inicial de autenticação é efetuada utilizando as credenciais do utilizador. O protocolo Kerberos é a primeira tentativa. Se o protocolo Kerberos não funcionar, será feita outra tentativa com o NTLM. Se a autenticação continuar a falhar, é pedido ao utilizador que forneça credenciais. Após a autenticação, o fluxo de dados é encriptado como uma função do protocolo Kerberos ou SSL se for utilizado NTLM.

No caso de um servidor de Relatórios e de um servidor de gestão, após a autenticação, é estabelecida uma ligação de dados entre o servidor de gestão e o Servidor de Relatórios do SQL Server. Isto é conseguido utilizando estritamente o protocolo de Kerberos. Por conseguinte, o servidor de gestão e o Servidor de Relatórios têm de residir em domínios fidedignos. Para obter mais informações sobre o WCF, veja o artigo da MSDN What Is Windows Communication Foundation (O que é o Windows Communication Foundation).

Servidor de gestão e armazém de dados de Relatórios

Existem dois canais de comunicação entre um servidor de gestão e o armazém de dados de Relatórios:

• O processo anfitrião de monitorização gerado pelo serviço de integridade (serviço de Gestão do System Center) num servidor de gestão
• Os serviços de Acesso a Dados do System Center no servidor de gestão

Processo Anfitrião de Monitorização e Armazém de Dados de Relatórios

Por predefinição, o processo anfitrião de monitorização gerados pelo Serviço de Integridade, que é responsável pela escrita de eventos recolhidos e contadores de desempenho no armazém de dados, alcança a Autenticação Integrada do Windows sendo executada como a Conta do Escritor de Dados especificado durante a Configuração do Relatório. A credencial de conta é guardada seguramente numa Conta Run As denominada Conta de Ação do Armazém de Dados. Esta Conta Run As é membro de um Perfil Run As denominada Conta do Armazém de Dados (que é associada com as regras de recolha atuais).

Se o armazém de dados de Relatórios e o servidor de gestão estiverem separados por um limite de fidedignidade (por exemplo, cada um reside em domínios diferentes sem confiança), a Autenticação Integrada do Windows não funcionará. Para contornar esta situação, o processo anfitrião de monitorização pode ligar-se ao armazém de dados de Relatório utilizando a autenticação do SQL Server. Para isto, crie uma nova Conta Run As (do tipo Conta Simples) com a credencial da conta SQL e torne-a membro do Perfil Run As designado por Conta de Autenticação do SQL Server do Armazém de Dados, com o servidor de gestão como o computador de destino.

Importante

Por predefinição, o Perfil Run As, à Conta de Autenticação do SQL Server do Armazém de Dados foi atribuída uma conta especial através da utilização da Conta Run As com o mesmo nome. Nunca efetue quaisquer alterações à conta que está associada ao Perfil Run As, Conta de Autenticação do SQL Server do Armazém de Dados. Em vez disso, crie a sua própria conta e a sua própria Conta Run As e torne a Conta Run As um membro do Perfil Run As, Conta de Autenticação do SQL Server do Armazém de Dados ao configurar a Autenticação do SQL Server.

A seguir descreve-se a relação das credenciais das várias contas, Contas Run As e Perfis Run As para a Autenticação Integrada do Windows e para a Autenticação do SQL Server.

Predefinição: Autenticação Integrada do Windows

1. Perfil Run As: Conta do Armazém de Dados

   • Conta Run As: Ação do Armazém de Dados
   • Credenciais da conta: Conta de Escritor de Dados (especificada durante a configuração)

2. Perfil Run As: Conta de Autenticação do SQL Server do Armazém de Dados

   • Conta Run As: Autenticação do SQL Server do Armazém de Dados
   • Credenciais de conta: conta especial criada pelo Operations Manager (não altere)

Opcional: Autenticação do SQL Server

1. Perfil Run As: Conta de Autenticação do SQL Server do Armazém de Dados
   • Conta Run As: Uma conta Run As especificada durante a configuração.
   • Credenciais da conta: Uma conta especificada durante a configuração.

O serviço de Acesso a Dados do System Center e armazém de dados de Relatórios

Por predefinição, o serviço de Acesso a Dados do System Center, responsável pela leitura de dados do armazém de dados de Relatórios e respetiva disponibilização na Área de Parâmetros de Relatório, alcança Autenticação Integrada do Windows sendo executada como o Serviço de Acesso a Dados e conta de Serviço de Configuração que foi definida durante a configuração do Operations Manager.

Se o armazém de dados de Relatórios e o servidor de gestão estiverem separados por um limite de fidedignidade (por exemplo, cada um reside em domínios diferentes sem confiança), a Autenticação Integrada do Windows não funcionará. Para contornar esta situação, o serviço de Acesso a Dados do System Center pode ligar-se ao armazém de dados de Relatório utilizando a autenticação do SQL Server. Para isto, crie uma nova Conta Run As (do tipo Conta Simples) com a credencial da conta SQL e torne-a membro do Perfil Run As designado por Conta de Autenticação de SDK SQL Server de Relatórios, com o servidor de gestão como o computador de destino.

Importante

Por predefinição, o Perfil Run As, à Conta de Autenticação de SDK SQL Server de Relatórios foi atribuída uma conta especial através da utilização da Conta Run As com o mesmo nome. Nunca efetue alterações à conta associada ao Perfil Run As, ao SDK de Relatórios SQL Server Conta de Autenticação. Em vez disso, crie a sua própria conta e a sua própria Conta Run As e torne a Conta Run As um membro do Perfil Run As, Conta de Autenticação de SDK SQL Server de Relatórios ao configurar a Autenticação do SQL Server.

A seguir descreve-se a relação das credenciais das várias contas, Contas Run As e Perfis Run As para a Autenticação Integrada do Windows e para a Autenticação do SQL Server.

Predefinição: Autenticação Integrada do Windows

1. Serviço de Acesso a Dados e a Conta de Serviço de Configuração (definidos durante a configuração do Operations Manager)

   • Perfil Run As: Conta de Autenticação de SDK SQL Server de Relatórios
   • Conta Run As: Conta de Autenticação de SDK SQL Server de Relatórios
   • Credenciais de conta: conta especial criada pelo Operations Manager (não altere)

2. Opcional: Autenticação do SQL Server

   • Perfil Run As: Conta de Autenticação do SQL Server do Armazém de Dados
   • Conta Run As: Uma conta Run As especificada durante a configuração.
   • Credenciais da conta: Uma conta especificada durante a configuração.

Consola de Operações e servidor de Relatórios

A consola de Operações liga ao Servidor de Relatórios na porta 80 utilizando HTTP. A autenticação é efetuada com a Autenticação do Windows. Os dados podem ser encriptados utilizando o canal SSL.

Servidor de Relatórios e armazém de dados de Relatórios

A autenticação entre o Servidor de Relatórios e o Armazém de Dados de Relatórios é efetuada utilizando a Autenticação Windows. A conta que foi especificada como a Conta do Leitor de Dados durante a configuração dos Relatórios torna-se a Conta de Execução no Servidor de Relatórios. Se a palavra-passe da conta for alterada, terá de fazer a mesma alteração de palavra-passe com o Configuration Manager do Reporting Services no SQL Server. Os dados entre o Servidor de Relatórios e o armazém de dados de Relatórios não são encriptados.