Autenticação e Encriptação de Dados para Computadores com o 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 em funcionalidades como o servidor de gestão, servidor de gateway, servidor de Relatórios, base de dados Operacional, armazém de dados de Relatório, agente, consola Web e consola de Operações. Esta secção explica como a autenticação é efetuada e identifica os canais de ligação em que 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. Por não existir fidedignidade entre os dois domínios, os agentes num domínio não podem autenticar-se junto do servidor de gestão no outro domínio utilizando 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.
.jpeg "Fidedignidade Entre Domínios")
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 pode autenticar-se com o servidor de gestão no domínio utilizando 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.
.jpeg "Confiança entre o Domínio e o Grupo de Trabalho")
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:
Pedir certificados da AC.
Aprovar os pedidos de certificado na AC.
Instale os certificados aprovados nos arquivos de certificados do computador.
Utilize a ferramenta MOMCertImport para configurar o Operations Manager.
Estes são os mesmos passos da instalação de certificados num servidor de gateway, mas não instala nem executa a ferramenta de aprovação da gateway.
Confirmar a Instalação do Certificado
Se instalou corretamente o certificado, o seguinte evento é escrito no registo de eventos do Operations Manager.
Tipo |
Origem |
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.
.jpeg "System_CAPS_caution"){kind=icon} Cuidado |
|---|
A edição incorreta do registo pode danificar gravemente o sistema. Antes de efetuar alterações no registo, deverá fazer uma cópia de segurança de todos os dados importantes do computador. |
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings
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. Após o servidor de gestão receber o alerta, o servidor de gestão desencripta a mensagem, encripta-a novamente utilizando o protocolo Kerberos e envia-a 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, Consola do Servidor 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, é efetuada outra tentativa utilizando o NTLM. Se a autenticação continuar a falhar, é pedido ao utilizador que forneça credenciais. Depois de a autenticação ter sido efetuada, a sequência de dados é encriptada como uma função do protocolo Kerberos ou SSL, se for utilizado o 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, consulte 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ório e o servidor de gestão estiverem separados por um limite de fidedignidade (por exemplo, cada um reside em domínios diferentes sem qualquer fidedignidade), 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.
.jpeg "System_CAPS_important") 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
Perfil Run As: Conta do Armazém de Dados
Conta Run As: Conta de Ação do Armazém de Dados
Credenciais: Conta de Escritor de Dados (especificada durante a configuração)
Perfil Run As: Conta de Autenticação do SQL Server do Armazém de Dados
Conta Run As: Conta de Autenticação do SQL Server do Armazém de Dados
Credenciais: Conta especial criada pelo Operations Manager (não alterar)
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 que crie.
Credenciais: Uma conta que crie.
O Serviço de Acesso a Dados do System Center e Armazém de Dados de Relatório
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ório e o servidor de gestão estiverem separados por um limite de fidedignidade (por exemplo, cada um reside em domínios diferentes sem qualquer fidedignidade), a Autenticação Integrada do Windows não funcionaria. 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 quaisquer alterações à conta que está associada ao Perfil Run As, Conta de Autenticação de SDK SQL Server de Relatórios. 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
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: Conta especial criada pelo Operations Manager (não alterar)
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 que crie.
Credenciais: Uma conta que crie.
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 utilizando a Autenticação do Windows. Os dados podem ser encriptados utilizando o canal SSL. Para mais informações sobre a utilização do SSL entre a consola 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 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 efetuar a mesma alteração à palavra-passe utilizando o Reporting Services Configuration Manager no SQL Server. Para mais informações sobre como repor esta palavra-passe, consulte Como alterar a senha de conta de execução relatórios do servidor. Os dados entre o Servidor de Relatórios e o Armazém de Dados de Relatórios não estão encriptados.