Microsoft Windows Server 2008 R2: Os certificados garantem a segurança do RDS

  • Artigo

Certificados desempenham um papel enorme em proteger conexões entre clientes e hosts de serviços de área de trabalho remota.

Kristin Griffin

Perguntar quais funções usam certificados é uma pegadinha. A verdadeira resposta é "todos eles." É importante compreender onde você deve usar certificados em implantações de serviços de área de trabalho remota (RDS), e por que usá-los com cada serviço específico para a função RDS.

A maioria das funções que você precisará configurar, mas alguns deles que você não vai (como o servidor de licenças de área de trabalho remota). Por padrão, você precisará de certificados SSL (x. 509) em todas as fases de se conectar a uma sessão ou hospedado máquina virtual (VM). Você vai usá-los para três objetivos principais: para proteger a comunicação entre cliente e servidor, para confirmar a identidade do servidor ou do Web site para que o cliente está se conectando e sinal de Remote Desktop Protocol (RDP) arquivos para que seus usuários saibam o arquivo RDP vem de uma fonte confiável e não foi alterado.

Aqui estão alguns exemplos de como o RDS usa certificados:

  • Servidores Host de Sessão RD utilizam certificados para provar a sua identidade. Isso é chamado de autenticação de servidor.
  • Servidores Host de Sessão RD e servidores Host de Virtualização RD usam certificados para configurar uma ligação segura entre o cliente e servidor com TLS 1.0.
  • Servidores de Host de Sessão RD utilizar certificados para autenticação de cliente necessária para a autenticação de nível de rede (NLA), Single Sign-On (SSO) e execução SSO da Web.
  • Servidores Host de Sessão RD e o agente de conexão RD usam um certificado SSL para assinar arquivos RemoteApps e VM RDP, garantindo aos usuários que eles estão lançando um arquivo confiável.
  • Gateway RD servers usam certificados para criptografar comunicações com clientes usando TLS 1.0.
  • Você pode proteger o site do acesso via Web RD com um certificado SSL para assegurar que as pessoas estão indo para um site confiável (HTTPS).

Habilitar funcionalidade RDS depende de tecnologias específicas para suporte o uso de certificados (ver Figura 1).

Enabling RDS functionality brings into play certain security technologies

Figura 1 leva a funcionalidade RDS permitindo a desempenham determinadas tecnologias de segurança.

Proteger o canal de

O TLS é o padrão da Internet Engineering Task Force (IETF) com base em SSL versão 3, publicado pela Netscape. Alguns dos aprimoramentos para TLS incluem novos alertas de mensagem, a capacidade de Cadeia de certificados para um certificado intermediário de autoridade de certificação (CA) em vez do certificado da CA raiz e ligeiramente diversos algoritmos de criptografia de SSL.

Embora TLS é baseado em SSL, os dois são incompatíveis. TLS pode, no entanto, implementar um mecanismo pelo qual ele pode cair de volta para SSL versão 3 se necessário. Para estabelecer um canal de comunicação seguro entre um cliente e um servidor usando o protocolo TLS, o cliente e o servidor passam por um processo de mensagens, resposta e criptografia (ver Figura 2).

The two-way encryption process for establishing a secure channel.

Figura 2 o processo de criptografia bidirecional para estabelecer um canal seguro.

Há dois requisitos para que este processo funcione corretamente.

  • O cliente deve confiar o CA que assina o certificado do servidor SSL.
  • A conexão entre servidor e cliente deve usar alto nível (por padrão) ou encriptação Federal Information Processing Standard (FIPS). Criptografia de baixo nível só criptografa o tráfego do cliente para o servidor, não servidor para o cliente, portanto, não é uma forma segura de enviar recursos de segurança ou os segredos compartilhados.

Se o nível de criptografia e conexão atender a esses dois requisitos, o cliente e o servidor estabeleçam comunicação da seguinte forma:

  1. O cliente envia uma mensagem de saudação juntamente com um valor aleatório de comprimento fixo. O servidor responde com um valor aleatório de comprimento fixo. Durante essa troca, o cliente informa ao servidor, os métodos de compressão, cifras e hashes suporta. Ele também envia sua versão de protocolo e um ID de sessão para o servidor. A ID de sessão identifica a comu­canal de cátion — esta não é a ID de sessão em um servidor Host de Sessão RD.
  2. O servidor seleciona o método de criptografia mais alto que ambos suportam e uma função de cifra e hash da lista do cliente. Em seguida, ele informa o cliente que um se tem cho­sen. Se não houver um nível mínimo definido para o servidor e o cliente não pode cumprir esse mínimo, a conexão falhará.
  3. O servidor envia seu certificado digital para o cliente. Este certificado contém o nome do servidor, a autoridade de certificação confiável que assinou o certificado e a chave pública do servidor.
  4. O cliente verifica que o certificado é válido e confiável. O certificado usado para assinar o certificado do servidor será no armazenamento de autoridades de certificação raiz confiáveis do cliente. Em seguida, cria um segredo pré-masterização, criptografa-o com a chave pública do servidor e envia para o servidor.
  5. O servidor recebe e decifra o segredo pré-masterização com sua chave privada. Este servidor é o único que pode fazer isso porque é o único servidor com a chave privada correspondente.
  6. O servidor e o cliente tem o segredo pré-masterização e números aleatórios trocados no início do processo. Eles usam esses valores para gerar o segredo mestre de 48 bytes (também conhecido como o segredo compartilhado). Depois de gerar o segredo principal, eles eliminar o segredo pré-masterização.
  7. Cliente e servidor, em seguida, o segredo mestre de 48 bytes de hash e usá-lo para gerar o segredo de MAC (a chave de sessão usado para hash) e a tecla de gravação (a chave de sessão usada para criptografia). Estas chaves de criptografar e descriptografar comunicação para esta sessão. Após a sessão, as chaves serão descartadas.

Se qualquer etapa dessa seqüência não funciona, a conexão não tenha sido totalmente protegida. O que acontece então depende das configurações de guia Avançado sobre o Remote Desktop Connec­tion (RDC) cliente. Em caso de falha de autenticação, um usuário pode escolher fazer qualquer um dos seguintes procedimentos:

  • Conecte assim mesmo sem notificar o cliente havia um problema no servidor de autenticação.
  • Avisar o cliente, mas ainda permitir que a conexão (configuração padrão).
  • Nega a conexão se não puder ser verificado.

A exceção é se o servidor requer um nível de segurança mínimo. Se esse for o caso e o cliente não pode atender ao nível mínimo, a conexão falhará. Por padrão, o cliente e o servidor irão negociar e usar as configurações de conexão mais seguras que os dois oferecem suporte.

Credencial de cache com CredSSP

O cache de credenciais foi introduzido com o Windows Vista e Windows Server 2008. Isso permite que dois recursos — um que ajuda o usuário e que ajuda a proteger o servidor.

O cache de credenciais ajuda os usuários ao armazenar credenciais para uma conexão específica, portanto eles não precisarão fornecê-los sempre que se conectam a esse servidor (isto é SSO). Isto acelera a conexão. Caso contrário, uma conexão agenciada deve ser verificada em cada etapa.

No lado do servidor, o cache de credenciais fornece credenciais para o servidor antes de estabelecer uma sessão. Isso evita a sobrecarga de uma sessão se o usuário não está autorizado (isto é NLA).

A peça que faz o trabalho o cache de credencial é o provedor de serviços de segurança de credenciais (CredSSP). Isso é suportado pelo Windows 7, Windows Vista, Windows Server 2008 e Windows XP SP3. Ele não está vinculado a versão da RDC que está sendo usado porque o CredSSP é parte do sistema operacional. CredSSP executa as seguintes funções:

  • Para NLA, CredSSP fornece a estrutura que autentica um usuário a um servidor Host de Sessão RD antes de totalmente estabelecer a conexão.
  • Para reconectar a uma sessão em um farm, CredSSP acelera o processo de passar a conexão para o servidor correto, permitindo que o servidor Host de Sessão RD ver quem está fazendo logon sem ter que criar uma sessão inteira. Isso usa NLA em um cenário um pouco diferente.
  • De SSO, CredSSP armazena as credenciais do usuário e passa-los para o servidor Host de Sessão RD para automatizar o início de sessão.

CredSSP permite autenticação mútua do cliente e servidor (ver Figura 3).

Authenticating both the server and client requires a secure channel.

Figura 3 autenticar o servidor e o cliente requer um canal seguro.

Esse processo de autenticação usa as seguintes etapas.

  1. O cliente inicia um canal seguro com o servidor usando o protocolo TLS. O servidor passa voltar o certificado com seu nome, a CA e a chave pública. Somente o servidor é identificado. O cliente permanece anônimo neste momento.
  2. Quando a sessão for estabelecida e uma chave de sessão criada, CredSSP usa o protocolo simples e Protected GSS-API Negotiation (SPNEGO) para mutuamente authenti­cate o servidor e o cliente. Basicamente, este mecanismo permite que o cliente e o servidor chegar a acordo sobre um mecanismo de autenticação que ambos oferecem suporte, como o Kerberos ou o Windows NT LAN Manager (NTLM).
  3. Após a conclusão da autenticação mútua, o CredSSP no lado do cliente criptografa o certificado do servidor com a chave de sessão criada durante a etapa 2 e envia para o servidor. O servidor recebe o certificado criptografado, descriptografa-lo com sua chave privada e, em seguida, adiciona uma para o bit mais significativo do número de certificado. Ele, em seguida, criptografa o resultado e envia de volta para o cliente. Garante que a Último operação que ninguém pode interceptar o intercâmbio entre cliente e servidor e falsificar o servidor.
  4. O cliente analisa o certificado criptografado recebido do servidor e com­pares-lo para seu próprio certificado.
  5. Supondo que os resultados correspondam, CredSSP no lado do cliente envia as credenciais do usuário para o servidor.

Autenticar a identidade do servidor

Um perigo de se comunicar com um computador remoto que requer que você forneça suas credenciais é que o servidor pode não ser o que você pensa. Se for um servidor invasor representando um confiável, inadvertidamente digite suas credenciais para o servidor errado. Isto daria os invasores tudo o que precisam para se conectar ao seu servidor ou domínio.

RDP inclui criptografia, mas o protocolo não tem qualquer meio para autenticar o servidor. Que é onde entram os TLS e CredSSP. Autenticação do servidor verifica o nome que introduzir no cliente RDC (ou arquivo RDP) contra o nome emitido o certificado especificado na ferramenta de configuração de área de trabalho remota no servidor Host de Sessão RD ao qual ele está conectado.

Assinar arquivos RDP

Você pode usar certificados para assinar digitalmente os arquivos RemoteApp como arquivos RDP usados para conectar para um pool ou pessoais VM (VDI). Assinar esses arquivos garante o usuário que foram criados por uma fonte confiável. Ele também protege o arquivo RDP contra violação.

Assinatura de RemoteApp arquivos também é necessário para implementar SSO da Web. Isso permite que usuários assinar em outra vez para o site do acesso via Web RD. Então eles podem lançar RemoteApps de qualquer farm sem ter que fornecer suas credenciais novamente.

CredSSP não pode passar as credenciais para acesso via Web RD. O usuário deve primeiro faça o login site da Web para armazenar suas credenciais. Então eles não precisam autenticar novamente para iniciar os programas do RemoteApp. Para este trabalho, os RemoteApps deve ser assinado e o usuário deve confiar o certificado usado para assinar o RemoteApp.

Arquivos RDP criados quando um usuário inicia uma conexão RDP na guia RD Web Access Desktops são criados em tempo real. Os arquivos não estão assinados. Por conseguinte, SSO da Web não vai funcionar ao conectar-se a ambientes de trabalho. O usuário terá que efetuar login ao ponto de extremidade quando a conexão é estabelecida. SSO da Web também não funcionará para conexões com VMs em pool ou pessoais.

Protegendo conexões

Gateway de RD usa TLS 1.0 para comunicações seguras entre o Gateway de RD e clientes de desktop remotos, normalmente localizados fora da rede corporativa (pela Internet). TLS, conforme descrito anteriormente, requer um certificado SSL. Você também pode proteger as comunicações entre clientes e o servidor de acesso via Web RD usando um certificado digital para criptografar as sessões de site da Web (HTTPS).

Os certificados são uma peça essencial de uma implantação de RDS. RDS utiliza certificados para proteger as comunicações e os recursos que permitem que eles. No mês que vem, eu vou cobrir criação de serviços de função RDS para usar esses certificados.

Raymond Chen

Kristin Griffin é um MVP de serviços de Desktop remoto. Ela modera um fórum da Microsoft dedicado a ajudar a Comunidade computação baseada em servidor (Remote Desktop Services) e mantém um blog RDS no blog.kristinlgriffin.com. Ela é um colaborador "Mastering Windows Server 2008" de Mark Minasi (Sybex, 2008) e "Dominando o Windows Server 2008 R2" (Sybex, 2010). Ela também co-autor de "Microsoft Windows Server 2008 Terminal Services Resource Kit" (Microsoft Press, 2008) e "Microsoft Windows Server 2008 R2 Remote Desktop Services Resource Kit" (Microsoft Press, 2010) com Christa Anderson.

Conteúdo relacionado