Autenticação e criptografia de dados no Operations Manager

Importante

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

O System Center Operations Manager consiste em recursos como o servidor de gerenciamento, servidor de gateway, servidor de Relatórios, banco de dados Operacional, data warehouse de Relatórios, agente, console Web e console de Operações. Este artigo explica como a autenticação é executada e identifica os canais de conexão em que os dados são criptografados.

Autenticação com base em certificado

Quando um agente e um servidor de gerenciamento do Operations Manager estiverem separados por um limite não confiável de floresta ou grupo de trabalho, a autenticação baseada em certificados precisará ser implementada. As seções a seguir fornecem informações sobre estas situações, bem como procedimentos específicos para a obtenção e a instalação de certificados de autoridades de certificação com base no Windows.

Configurando a comunicação entre agentes e servidores de gerenciamento dentro do mesmo limite de confiança

Um agente e o servidor de gerenciamento usam a autenticação do Windows para se autenticarem mutuamente uns com os outros antes que o servidor de gerenciamento aceite dados do agente. O protocolo Kerberos versão 5 é o método padrão para fornecer essa autenticação. Para que a autenticação mútua baseada no Kerberos funcione, os agentes e o servidor de gerenciamento precisam estar instalados em um domínio do Active Directory. Se um agente e um servidor de gerenciamento estiverem em domínios separados, deverá haver uma confiança total entre esses domínios. Neste cenário, após a realização da autenticação mútua, o canal de dados entre o agente e o servidor de gerenciamento é criptografado. Nenhuma intervenção do usuário é necessária para que a autenticação e a criptografia possam ocorrer.

Configurando a comunicação entre agentes e servidores de gerenciamento entre limites de confiança

Um agente (ou agentes) pode estar implantado em um domínio (domínio B) à parte do servidor de gerenciamento (domínio A), sem que haja uma confiança bidirecional entre esses domínios. Como não há confiança entre os dois domínios, os agentes em um domínio não podem se autenticar com o servidor de gerenciamento no outro domínio usando o protocolo Kerberos. A autenticação mútua entre os recursos do Operations Manager dentro de cada domínio ainda ocorre.

Uma solução para esta situação é instalar um servidor gateway no mesmo domínio em que os agentes residem e depois instalar certificados nesse servidor gateway e no servidor de gerenciamento para obter a autenticação mútua e a criptografia de dados. O uso do servidor gateway significa que é necessário ter apenas um certificado no domínio B e uma porta através do firewall, como mostra a ilustração a seguir.

Configurando a comunicação entre um domínio – limite de grupo de trabalho

No seu ambiente, é possível que haja um ou dois agentes implantados em um grupo de trabalho dentro do firewall. O agente no grupo de trabalho não pode se autenticar com o servidor de gerenciamento no domínio usando o protocolo Kerberos. Uma solução para essa situação é instalar certificados tanto no computador que hospeda o agente quanto no servidor de gerenciamento ao qual esse agente se conecta, como mostra a ilustração a seguir.

Observação

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

Realize as etapas a seguir no computador que hospeda o agente e no servidor de gerenciamento, usando a mesma CA (autoridade de certificação) para cada um:

1. Solicite certificados da CA.
2. Aprove as solicitações de certificado na CA.
3. Instale os certificados aprovados nos repositórios de certificados dos computadores.
4. Use a ferramenta MOMCertImport para configurar o Operations Manager.

Observação

Não há suporte para certificados com KEYSPEC diferente de 1.

Essas são as mesmas etapas para instalar certificados em um servidor de gateway, exceto que você não instala ou executa a ferramenta de aprovação do gateway

Confirmando a instalação do certificado

Se você instalou corretamente o certificado, o evento a seguir será gravado no log de eventos do Operations Manager.

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

Durante a configuração de um certificado, você executa a ferramenta MOMCertImport. Ao final da execução dessa ferramenta, o número de série do certificado importado é gravado na seguinte subchave do Registro.

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

Cuidado

A edição incorreta do Registro pode danificar seriamente o sistema. Antes de alterar o Registro, faça backup de todos os dados importantes do computador.

Autenticação e criptografia de dados entre o servidor de gerenciamento, servidor Gateway e agentes

A comunicação entre estes recursos do Operations Manager começa com a autenticação mútua. Se houver certificados presentes em ambas as extremidades do canal de comunicações, estes certificados serão usados para autenticação mútua; caso contrário, o protocolo Kerberos versão 5 será usado. Se quaisquer dois recursos estiverem separados em um domínio não confiável, a autenticação mútua deverá ser realizada com o uso de certificados. Comunicações normais, como eventos, alertas e a implantação de um pacote de gerenciamento, ocorrem através deste canal. A ilustração anterior mostra um exemplo de alerta sendo gerado em um dos agentes que está direcionado ao servidor de gerenciamento. Do agente até o servidor gateway, o pacote de segurança Kerberos é usado para criptografar os dados, pois o servidor gateway e o agente se encontram no mesmo domínio. O alerta é descriptografado pelo servidor gateway e novamente criptografado com o uso de certificados para o servidor de gerenciamento. O servidor de gateway envia a mensagem criptografada para o servidor de gerenciamento onde o servidor de gerenciamento descriptografa o alerta. Uma parte da comunicação entre o servidor de gerenciamento e o agente pode incluir informações sobre credenciais; por exemplo, tarefas e dados de configuração. O canal de dados entre o agente e o servidor de gerenciamento acrescenta outra camada de criptografia além da criptografia de canal normal. Nenhuma intervenção do usuário é necessária.

Servidor de gerenciamento e console de Operações, servidor de console Web e servidor de Relatórios

O procedimento de autenticação e criptografia de dados entre o servidor de gerenciamento e o console de Operações, servidor de console Web ou servidor de Relatórios é realizado com o uso da tecnologia WCF (Windows Communication Foundation). A tentativa inicial na autenticação é feita com o uso das credenciais do usuário. Em primeiro lugar, é feita uma tentativa com o protocolo Kerberos. Se o protocolo Kerberos não funcionar, outra tentativa será feita usando o NTLM. Se a autenticação falhar mesmo assim, será solicitado que o usuário forneça credenciais. Depois que a autenticação ocorre, o fluxo de dados é criptografado como uma função do protocolo Kerberos ou do SSL se o NTLM for usado.

No caso de um servidor de Relatórios e de um servidor de gerenciamento, após a realização da autenticação, uma conexão de dados é estabelecida entre o servidor de gerenciamento e o Servidor de Relatórios do SQL Server. Este processo é realizado com o uso rigoroso do protocolo Kerberos; portanto, o servidor de gerenciamento e o Servidor de Relatórios devem residir em domínios confiáveis. Para obter mais informações sobre o WCF, consulte o artigo do MSDN What Is Windows Communication Foundation (O que é a Windows Communication Foundation).

Servidor de gerenciamento e data warehouse de Relatórios

Existem dois canais de comunicação entre um servidor de gerenciamento e o data warehouse de Relatórios:

• O processo do host de monitoramento gerado pelo Serviço de Integridade (serviço do System Center Management) em um servidor de gerenciamento
• Os serviços de Acesso a Dados do System Center no servidor de gerenciamento

Processo do host de monitoramento e data warehouse de Relatórios

Por padrão, o processo do host de monitoramento gerado pelo Serviço de Integridade, que é responsável por gravar eventos coletados e contadores de desempenho no data warehouse, obtém a Autenticação Integrada do Windows ao ser executado como a Conta do Gravador de Dados especificada durante a Instalação de Relatórios. A credencial dessa conta é seguramente armazenada em uma conta Executar como denominada Conta de Ação do Data Warehouse. Essa conta Executar como é membro de um perfil Executar como denominado Conta do Data Warehouse (que está associada às regras reais de coleta).

Se o data warehouse do Reporting e o servidor de gerenciamento forem separados por um limite de confiança (por exemplo, cada um reside em domínios diferentes sem confiança), a Autenticação Integrada do Windows não funcionará. Para solucionar essa situação, o processo do host de monitoramento pode se conectar ao data warehouse de Relatórios usando a Autenticação do SQL Server. Para fazer isso, crie uma nova conta Executar como (do tipo Conta Simples) com a credencial de conta SQL e torne-a um membro do perfil Executar como denominado Conta de Autenticação do SQL Server do Data Warehouse, tendo o servidor de gerenciamento como o computador de destino.

Importante

Por padrão, o perfil Executar como, Conta de Autenticação do SQL Server do Data Warehouse, foi atribuído a uma conta especial com o uso da conta Executar como que possui o mesmo nome. Nunca faça alterações na conta associada ao perfil Executar como, Conta de Autenticação do SQL Server do Data Warehouse. Em vez disso, crie sua própria conta e sua própria conta Executar como, transformando esta última em um membro do perfil Executar como, Conta de Autenticação do SQL Server do Data Warehouse, ao configurar a Autenticação do SQL Server.

As informações a seguir descrevem a relação das diversas credenciais de conta, contas Executar como e perfis Executar como para a Autenticação Integrada do Windows e a Autenticação do SQL Server.

Padrão: Autenticação Integrada do Windows

1. Perfil Executar como: Conta do Data Warehouse

   • Conta Executar como: Ação do Data Warehouse
   • Credenciais da conta: Conta do Gravador de Dados (especificada durante a configuração)

2. Perfil Executar como: Conta de Autenticação do SQL Server do Data Warehouse

   • Conta Executar como: Autenticação do SQL Server do Data Warehouse
   • Credenciais da conta: conta especial criada pelo Operations Manager (não altere)

Opcional: Autenticação do SQL Server

1. Perfil Executar como: Conta de Autenticação do SQL Server do Data Warehouse
   • Conta Executar como: uma conta Executar como especificada durante a instalação.
   • Credenciais da conta: uma conta especificada durante a instalação.

O serviço de Acesso a Dados do System Center e o Data Warehouse de relatórios

Por padrão, o serviço de Acesso a Dados do System Center, que é responsável por ler os dados do data warehouse de Relatórios e por disponibilizá-lo na área Parâmetros do Relatório, obtém a Autenticação Integrada do Windows ao ser executado como a conta de serviço de Acesso a Dados e de Configuração que foi definida durante a instalação do Operations Manager.

Se o data warehouse do Reporting e o servidor de gerenciamento forem separados por um limite de confiança (por exemplo, cada um residirá em domínios diferentes sem confiança), a Autenticação Integrada do Windows não funcionará. Para solucionar esta situação, o serviço de Acesso a Dados do System Center pode se conectar ao data warehouse de Relatórios usando a Autenticação do SQL Server. Para fazer isso, crie uma nova conta Executar como (do tipo Conta Simples) com a credencial de conta SQL e torne-a um membro do perfil Executar, chamado de Conta de Autenticação no SQL Server do SDK de Relatórios, tendo o servidor de gerenciamento como o computador de destino.

Importante

Por padrão, o perfil Executar como, Conta de Autenticação no SQL Server do SDK de Relatórios, foi atribuído a uma conta especial com o uso da conta Executar como que possui o mesmo nome. Nunca faça alterações na conta associada ao Perfil Executar como, relatando o SDK SQL Server Conta de Autenticação. Em vez disso, crie sua própria conta e sua própria conta Executar como, tornando esta última em um membro do perfil Executar como, Conta de Autenticação no SQL Server do SDK de Relatórios, ao configurar a Autenticação do SQL Server.

As informações a seguir descrevem a relação das diversas credenciais de conta, contas Executar como e perfis Executar como para a Autenticação Integrada do Windows e a Autenticação do SQL Server.

Padrão: Autenticação Integrada do Windows

1. Conta do serviço de Acesso a Dados e de Configuração (definida durante a instalação do Operations Manager)

   • Perfil Executar como: Conta de Autenticação no SQL Server do SDK de Relatórios
   • Conta Executar como: Conta de Autenticação no SQL Server do SDK de Relatórios
   • Credenciais da conta: conta especial criada pelo Operations Manager (não altere)

2. Opcional: Autenticação do SQL Server

   • Perfil Executar como: Conta de Autenticação do SQL Server do Data Warehouse
   • Conta Executar como: uma conta Executar como especificada durante a instalação.
   • Credenciais da conta: uma conta especificada durante a instalação.

Console de Operações e Servidor de Relatórios

O console de Operações se conecta ao Servidor de Relatórios na porta 80 via HTTP. A autenticação é executada usando a Autenticação do Windows. Os dados podem ser criptografados com o uso do canal SSL.

Servidor de Relatórios e data warehouse de Relatórios

A autenticação entre o Servidor de Relatórios e o data warehouse de Relatórios é feita com o uso da Autenticação do Windows. A conta que foi especificada como a Conta do Leitor de Dados durante a configuração de Relatórios se torna a Conta de Execução no Servidor de Relatórios. Se a senha da conta precisar ser alterada, você precisará fazer a mesma alteração de senha usando o Reporting Services Configuration Manager em SQL Server. Os dados entre o Servidor de Relatórios e o data warehouse de Relatórios não são criptografados.