Autenticação e criptografia de dados para computadores Windows

 

Aplica-se a: System Center 2012 R2 Operations Manager, System Center 2012 - Operations Manager, System Center 2012 SP1 - Operations Manager

O System Center 2012 – Operations Manager consiste de recursos, como o servidor de gerenciamento, servidor gateway, servidor de Relatórios, banco de dados operacional, data warehouse de Relatórios, agente, console Web e console de operações. Esta seção explica como a autenticação é realizada e identifica canais de conexão onde 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 com base 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 existe confiança entre os dois domínios, os agentes em um domínio não podem ser autenticados no servidor de gerenciamento do 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 nesse grupo de trabalho não consegue se autenticar no servidor de gerenciamento do 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:

• Solicite certificados da CA.

• Aprove as solicitações de certificado na CA.

• Instale os certificados aprovados nos repositórios de certificados dos computadores.

• Use a ferramenta MOMCertImport para configurar Operations Manager.

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

Confirmando a instalação do certificado

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

Tipo	Origem	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.

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

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

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. Depois de receber o alerta, o servidor de gerenciamento descriptografa a mensagem, volta a criptografá-la com o uso do protocolo Kerberos e a envia ao servidor de gerenciamento, que por sua vez descriptografa esse 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, será feita outra tentativa, dessa vez com o uso do NTLM. Se a autenticação falhar mesmo assim, será solicitado que o usuário forneça credenciais. Depois de realizada a autenticação, 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 SQL Server Reporting Services. 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 diferentes domínios 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

Perfil Executar como: Conta do Data Warehouse

     Conta Executar como: Conta de ação do Data Warehouse

          Credenciais: Conta do Gravador de Dados (especificada durante a configuração)

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

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

          Credenciais: Conta especial criada pelo Operations Manager (não alterar)

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ê criar.

          Credenciais: Uma conta que você criar.

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 do serviço de Acesso a Dados e 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 diferentes domínios 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 no 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

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: Conta especial criada pelo Operations Manager (não alterar)

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ê criar.

          Credenciais: Uma conta que você criar.

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 é realizada com o uso da Autenticação do Windows. Os dados podem ser criptografados com o uso do canal SSL. Para obter mais informações sobre como usar SSL entre o console de operações e o servidor de relatórios, consulte Como configurar o Console de operações para usar SSL ao conectar-se a um servidor de relatórios.

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 para a conta tiver que ser trocada, será necessário fazer a mesma troca de senha usando o Gerenciador de Configuração do Reporting Services no SQL Server. Para obter mais informações sobre como restaurar esta senha, consulte Como alterar a senha de conta de execução relatórios do servidor. Os dados entre o Servidor de Relatórios e o data warehouse de Relatórios não são criptografados.