Autenticação e criptografia de dados no Operations Manager

O System Center Operations Manager consiste em recursos como o servidor de gerenciamento, o servidor de gateway, o servidor de relatórios, o banco de dados operacional, o data warehouse de relatórios, o agente, o console da Web e o 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 do Operations Manager e um servidor de gerenciamento são separados por uma floresta não confiável ou limite de grupo de trabalho, a autenticação baseada em certificado 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.

Configurar 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.

Configurar 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 em 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.

Configurar a comunicação em um domínio – Limite do 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 o 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 de gateway

Confirmar 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, o servidor de gateway e os 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

A autenticação e a criptografia de dados entre o servidor de gerenciamento e o console de Operações, o servidor de console Web ou o servidor de Relatórios são realizadas usando a tecnologia Windows Communication Foundation (WCF). 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 NTLM. Se a autenticação falhar mesmo assim, será solicitado que o usuário forneça credenciais. Após a autenticação, o fluxo de dados é criptografado como uma função do protocolo Kerberos ou SSL se o NTLM for usado.

No caso de um servidor de relatórios e um servidor de gerenciamento, após a autenticação, uma conexão de dados é estabelecida entre o servidor de gerenciamento e o SQL Server Reporting 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 de relatórios e o servidor de gerenciamento estiverem 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 altera)

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 que você especificou durante a instalação.
   • Credenciais da conta: uma conta que você especificou durante a configuraçã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 dados do data warehouse de Relatórios e disponibilizá-los na Área de Parâmetros de Relatório, obtém a Autenticação Integrada do Windows executando como a conta do Serviço de Acesso a Dados e do Serviço de Configuração que foi definida durante a instalação do Operations Manager.

Se o data warehouse de relatórios e o servidor de gerenciamento estiverem 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 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, Conta de Autenticação do SQL Server do SDK de Relatórios. 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 altera)

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 que você especificou durante a instalação.
   • Credenciais da conta: uma conta que você especificou durante a configuraçã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 for alterada, você precisará fazer a mesma alteração de senha usando o Reporting Services Configuration Manager no SQL Server. Os dados entre o Servidor de Relatórios e o data warehouse de Relatórios não são criptografados.