Exportar (0) Imprimir
Expandir Tudo
Expandir Minimizar

Configuração de pontos de acesso sem fio protegidos

Publicado em: 29/08/06

Nesta página

Introdução
Definição
Desafios
Soluções
Resumo

Introdução

Bem-vindo a este documento da coleção Guias de segurança de empresas de médio porte. A Microsoft espera que as informações a seguir ajudem a criar um ambiente de computação mais seguro e produtivo.

Sinopse

Redes locais sem fio (WLANs) são um assunto controverso no mundo dos negócios; a maioria das empresas já implantou algum tipo de WLAN ou pelo menos debateu os prós e contras da tecnologia sem fio. De qualquer forma, as empresas que implantaram redes sem fio normalmente têm várias preocupações sobre a segurança de sua solução, enquanto as empresas que se afastaram da tecnologia sem fio se preocupam com a economia óbvia de produtividade e infra-estrutura que podem ter deixado de fazer.

A maioria dos responsáveis pelas decisões de tecnologia se sente, e com razão, inquieta com a segurança da tecnologia sem fio no passado e, mesmo hoje em dia, a tecnologia sem fio tem o estigma de não se tornar segura nunca, porque falhas bastante divulgadas foram descobertas na primeira geração de protocolos de segurança WLAN IEEE 802.11. Embora muitas soluções alternativas tenham sido desenvolvida nesses anos, as soluções comuns oferecidas para tratar os problemas de segurança sem fio eram muito caras ou tinham suas próprias falhas internas.

Muitos desenvolvimentos foram feitos desde o início das redes sem fio, pois assim como a tecnologia se solidificou para permitir velocidades mais altas e maior confiabilidade, muitos padrões usados para proteger transmissões sem fio foram aperfeiçoados. Os protocolos de segurança sem fio mais recentes, WPA e WPA2, baseados no padrão IEEE 802.11i, ajudam a fornecer proteção poderosa para tráfego sem fio mesmo nos ambientes de segurança mais rigorosos. Esses padrões atuais, quando configurados corretamente, são muito mais seguros e podem ser usados com um nível maior de confiança no ambiente comercial de uma empresa de médio porte.

Visão geral

Este documento consiste em quatro seções que descrevem os detalhes necessários para projetar e implementar uma solução eficaz para proteger a rede sem fio de uma empresa de médio porte. Essas seções incluem:

  • Introdução. Esta seção oferece uma sinopse deste documento, além de uma visão geral da estrutura do documento e informações sobre o público-alvo recomendado para este documento.

  • Definição. Esta seção fornece alguns detalhes e definições que são úteis para entender a terminologia usada neste documento.

  • Desafios. Esta seção descreve alguns dos problemas comuns enfrentados por empresas de médio porte que consideram implantar redes sem fio e fornece um pano de fundo para a solução que este documento aborda.

  • Soluções. Esta seção apresenta os detalhes da orientação passo a passo que será usada para planejar, desenvolver, implantar e dar suporte a uma infra-estrutura sem fio segura. Desta forma, a seção de soluções divide-se em três subseções principais:

    • Avaliando a segurança de WLAN. Esta seção descreve informações de pré-requisito e opções possíveis para fornecer uma base de desenvolvimento de um plano de solução.

    • Desenvolvendo uma solução de WLAN segura. Esta seção usa as informações aprendidas na fase de avaliação para decidir um plano e criá-lo e para desenvolver a base da solução.

    • Implantação e gerenciamento. Esta seção apresenta a solução passo a passo real em detalhes, além de informações para ajudar no gerenciamento e validação da solução de rede sem fio segura descrita neste documento.

Quem deve ler este documento

Este documento destina-se aos funcionários técnicos, implementadores de tecnologia e gerentes técnicos de empresas de médio porte que considerem usar WPA (Wi-Fi Protected Access) ou WPA2 (Wi-Fi Protected Access 2) para proteger sua infra-estrutura sem fio. Este documento pressupõe que o leitor tenha conhecimentos técnicos gerais sobre dispositivos sem fio, conceitos de rede básicos, Microsoft® Windows Server™ 2003, Internet Authentication Service (IAS), Serviços de certificados, o serviço de diretório Active Directory® e a configuração e aplicação da Diretiva de grupo.


Definição

O leitor deve entender e estar familiarizado com os seguintes termos e conceitos usados neste documento.

AES. AES (Advanced Encryption Standard) usa uma técnica de criptografia de dados de blocos simétricos e faz parte de WPA2.

EAP. EAP (Extensible Authentication Protocol) é um padrão 802.1X que permite aos desenvolvedores passar dados de autenticação entre servidores RADIUS e pontos de acesso sem fio. EAP tem algumas variantes, incluindo: EAP MD5, EAP-TLS, EAP-TTLS, LEAP e PEAP.

EAP-TLS. EAP-TLS (EAP Transport Layer Security) foi desenvolvido pela Microsoft de acordo com o padrão 802.1X para usar certificados digitais para autenticação, e atualmente é o padrão do setor para a autenticação 802.11i.

IEEE 802.1X. O padrão IEEE 802.1X rege o processo de encapsulamento EAP que ocorre entre suplicantes (clientes), autenticadores (pontos de acesso sem fio) e servidores de autenticação (RADIUS).

IEEE 802.11. O padrão IEEE 802.11 rege comunicações de rede pelo ar e inclui diversas especificações que vão do padrão 802.11g, que fornece tráfego de 20+ Mbps na banda 2,4 GHz, ao padrão 802.11i, que rege a criptografia e autenticação de WPA2.

IEEE 802.11i. A emenda IEEE 802.11i ao padrão 802.11 especifica métodos de segurança (WPA2) que usam cifra de bloco AES para proteger processos de autenticação de origem (EAP) e tratar inadequações anteriores de padrões e especificações de segurança sem fio.

MS-CHAP v2. MS-CHAP v2 (Microsoft Challenge Handshake Authentication Protocol versão 2) é um protocolo de autenticação mútua de desafio-resposta e baseado em senha que usa criptografia MD4 e DES. Usado com PEAP (PEAP-MS-CHAP v2) para proteger comunicações sem fio.

PEAP. PEAP (Protected Extensible Authentication Protocol) é um tipo de comunicação EAP que trata problemas de segurança associados a transmissões EAP de texto não criptografado criando um canal seguro criptografado e protegido por TLS.

SSID. SSID (Service Set Identifier) é o nome dado a uma WLAN e usado pelo cliente para identificar as credenciais e configurações corretas necessárias para acesso a uma WLAN.

TKIP. TKIP (Temporal Key Integrity Protocol) é parte de um padrão de criptografia WPA de redes sem fio. TKIP é a próxima geração de WEP, que fornece a mistura de chaves por pacote para tratar falhas descobertas no padrão WEP.

WEP. WEP (Wired Equivalent Privacy) faz parte do padrão IEEE 802.11 e usa criptografia RC4 de 64 ou 128 bits. Foram encontradas falhas sérias no padrão WEP em 2001, em sua maior parte devidas ao vetor de inicialização da cifra de fluxo RC4, que permitia a decodificação passiva da chave RC4.

WLAN. Rede local sem fio.

WPA. Em resposta às falhas encontradas no padrão WEP, o WPA (Wi-Fi Protected Access) foi apresentado em 2003 como um subconjunto de especificações de segurança sem fio interoperável do padrão IEEE 802.11. Esse padrão fornece recursos de autenticação e usa TKIP para a criptografia de dados.

WPA2. WPA2 foi criado em setembro de 2004 pela Wi-Fi Alliance e é a versão certificada interoperável da especificação IEEE 802.11i completa ratificada em junho de 2004. Como seu antecessor, o WPA2 tem suporte para autenticação IEEE 802.1X/EAP ou tecnologia PSK, mas inclui um novo mecanismo de criptografia avançada que usa o protocolo CCMP (Counter-Mode/CBC-MAC), chamado AES (Advanced Encryption Standard).


Desafios

Muitas organizações reconhecem os benefícios de usar a tecnologia sem fio para melhorar a produtividade e a colaboração, mas hesitam em implementar essa tecnologia devido a preocupações compreensíveis sobre as vulnerabilidades que as redes sem fio aparentemente apresentam no ambiente da organização. Ainda mais confusa é a grande variedade de métodos sugeridos que podem ser usados para ajudar a proteger comunicações sem fio e os relatos contraditórios sobre a eficácia dessas medidas.

A tecnologia sem fio apresenta muitos desafios a uma empresa de médio porte, não só em relação à proteção da implantação, mas também se ela deve ser implantada. A seguir estão algumas das questões mais comuns relacionadas a redes sem fio que serão abordadas neste documento.

  • Decidir se uma WLAN deve ser implementada

  • Compreender os riscos da tecnologia sem fio e como reduzi-los

  • Determinar como proteger um ambiente WLAN

  • Selecionar as opções de segurança de WLAN corretas

  • Validar o nível de segurança de uma implementação de rede sem fio

  • Incorporar os ativos existentes a uma solução de segurança sem fio

  • Detectar e impedir conexões de dispositivos sem fio mal-intencionados


Soluções

Esta seção descreve o projeto, o desenvolvimento, a implementação e o suporte para soluções sem fio seguras que possam ser implantadas em ambientes de empresas de médio porte. Conforme já mencionado, existem muitas preocupações relacionadas ao uso da tecnologia sem fio. Cada uma será abordada para que os benefícios das redes sem fio possam ser aproveitados da forma mais eficaz e segura possível.

Avaliando a segurança de WLAN

Embora a tecnologia sem fio tenha amadurecido a ponto de ser rápida e segura o suficiente para ser implantada em uma empresa de médio porte, ainda há diversos fatores a considerar e inúmeros métodos disponíveis para proteger uma rede sem fio. Esta sessão analisa muitos métodos comuns usados para ajudar a proteger redes sem fio, oferece orientação para determinar a melhor solução para um ambiente específico e fornece argumentos a favor e contra cada abordagem.

Benefícios das redes sem fio

Os benefícios que podem ser obtidos com a implementação da tecnologia WLAN podem ser divididos em duas categorias: benefícios comerciais e benefícios operacionais. Benefícios operacionais incluem um baixo custo de gerenciamento e reduzidos gastos de capital, enquanto os benefícios comerciais incluem maior produtividade, processos comerciais mais eficientes e maior potencial de criação de novas funções comerciais.

Benefícios comerciais

A maioria dos benefícios comerciais fundamentais resultantes do uso de tecnologia WLAN vem do aumento da flexibilidade e mobilidade do funcionário. Ao usar redes sem fio, a força de trabalho deixa de ficar presa a uma mesa e pode se deslocar pelo escritório com relativa facilidade. Esse tipo de liberdade pode gerar os seguintes benefícios:

  • Os membros da força de trabalho móvel de uma empresa, como os vendedores, podem se deslocar sem problemas entre os escritórios ou chegar do campo e se conectar sem problemas à rede da empresa. A conectividade é quase instantânea e ocorre sem que seja preciso procurar uma porta de rede ou desenrolar cabos, economizando muito tempo e diminuindo os problemas associados às redes por cabo.

  • Os funcionários técnicos podem ficar em contato constante com os sistemas que gerenciam, onde quer que estejam no prédio, até mesmo durante reuniões ou quando estão longe de suas mesas. Com tecnologia portátil, como laptops, Tablet PCs ou computadores portáteis, a equipe de TI de uma empresa pode responder instantaneamente a qualquer necessidade.

  • As informações sempre estão disponíveis para todos. As reuniões deixam de sofrer atrasos porque alguém precisa fazer cópias ou pegar relatórios em sua mesa. As apresentações são compartilhadas no computador, em vez de por meio de um retroprojetor, e as reuniões podem usar tecnologias interativas para colaboração com escritórios remotos e funcionários externos.

  • A flexibilidade organizacional é bastante aprimorada, porque as alterações estruturais podem ser implementadas de forma fácil e rápida, e até mesmo escritórios inteiros podem ser reestruturados, já que o cabeamento de rede deixa de existir.

  • A tecnologia sem fio apresenta uma nova gama de aplicativos e soluções de tecnologia em um ambiente comercial. Dispositivos como PDAs e Tablet PCs podem ser integrados sem conflitos em um ambiente de rede. Funcionários e funções comerciais anteriormente fora do alcance de TI agora se beneficiam da conectividade de rede; refeitórios, áreas de montagem, salas de hospital, áreas de varejo, restaurantes a até mesmo o chão de fábrica podem alcançar níveis inéditos de ganhos de produtividade com soluções de tecnologia bastante acessíveis.

Benefícios operacionais

Os benefícios operacionais da tecnologia sem fio também são variados e dependem do tipo específico de empresa e dos recursos usados. Alguns desses benefícios incluem:

  • Os custos de fornecimento de rede são bastante reduzidos, porque a dependência de infra-estruturas de rede por cabo diminui. Áreas onde a conectividade de rede era pouco prática agora podem ser acessadas a um custo baixo por meio da tecnologia WLAN, incluindo áreas externas ou áreas do escritório distribuídas.

  • A escalabilidade da rede é mais proativa e eficiente em relação a níveis diversos de demandas, porque é muito mais fácil implantar ou mover pontos de acesso sem fio para outros locais e assim eliminar congestionamentos do que aumentar o número de portas de rede.

  • O capital comprometido com infra-estruturas de recursos é reduzido, porque os equipamentos de redes sem fio não são tão permanentes como a infra-estrutura de cabos de rede. Isso oferece mais flexibilidade de expansão ou de mudança de escritórios, seja qual for o motivo. Redes sem fio de alta velocidade (802.11a/g/n) também são uma alternativa econômica para substituir o antigo cabeamento Ethernet ou Token Ring de baixa velocidade.

Vulnerabilidades de redes sem fio

Para entender o nível de segurança oferecido pelas diversas soluções disponíveis para redes sem fio, é importante entender as ameaças comuns enfrentadas por redes sem fio. As vulnerabilidades e os perfis de ataque que as redes tradicionais devem enfrentar são amplamente conhecidos, mas as redes sem fio têm vulnerabilidades que vão além dos riscos tradicionais.

Tabela 1. Ameaças de segurança de WLAN comuns

Ameaça

Descrição

Divulgação de dados por espionagem

Ataques por espionagem em tráfego sem fio não-protegido podem causar a divulgação de dados confidenciais, a descoberta de credenciais de usuários e até mesmo levar ao roubo de identidades. Invasores sofisticados podem usar informações coletadas por espionagem para elaborar ataques a sistemas que de outra forma não estariam tão vulneráveis.

Interceptação e modificação de dados transmitidos

Um invasor que possa obter acesso a recursos de rede também é capaz de inserir sistemas mal-intencionados em uma rede para interceptar e modificar dados na rota entre dois sistemas legítimos.

Falsificação

O acesso a uma rede interna oferece a um invasor a oportunidade de forjar dados que parecem ser tráfego legítimo. Esses ataques podem incluir mensagens de email falsificadas nas quais os usuários internos confiariam mais rapidamente do que em comunicações externas, o que representaria uma plataforma para ataques de engenharia social e inserções de cavalos de Tróia.

Negação de serviço (DoS)

Independentemente da solução de segurança implementada, uma WLAN está especialmente suscetível a ataques de DoS, sejam eles intencionais ou acidentais. Essas interrupções podem resultar de algo simples, como um forno de microondas, ou de um dispositivo configurado para inundar a rede com tráfego indiscriminado.

Parasitismo
(roubo de recursos)

Alguns invasores podem estar atrás somente de acesso gratuito à Internet. Embora não sejam diretamente mal-intencionadas ou prejudiciais, essas atividades podem causar lentidão na rede para os usuários legítimos ou representar um vetor não gerenciado de ameaças de malware.

Ameaças acidentais e conexões não gerenciadas

Em ambientes WLAN não protegidos, qualquer visitante pode obter acesso à rede interna apenas inicializando um dispositivo que seja capaz de acessar redes sem fio. Esses dispositivos não gerenciados podem já estar comprometidos ou oferecer a um invasor um ponto de ataque vulnerável em uma rede.

Pontos de acesso WLAN mal-intencionados

Mesmo se uma empresa não tiver uma rede sem fio, ela ainda pode estar vulnerável a ameaças de segurança de redes sem fio não gerenciadas. O hardware sem fio é relativamente barato, e assim qualquer funcionário poderia configurar uma rede não gerenciada e não protegida em um ambiente.

Embora muitos desses riscos de segurança associados à transmissão de dados por ar estejam razoavelmente aparentes no ambiente atual particularmente sensível à segurança, essas preocupações não eram tão óbvias quando a primeira geração de tecnologia de segurança sem fio foi definida. Quando o WEP foi criado para proteger transmissões de dados sem fio, parecia haver pouca necessidade de compensar a falta de segurança inerente em comparação com a segurança inata da transmissão de dados por cabo, porque a tecnologia era tão nova que poucas pessoas consideraram as ameaças possíveis que essas redes poderiam enfrentar. À medida que os métodos usados por invasores evoluíram, ficou claro que a transmissão de dados por ar atravessava ambientes potencialmente hostis e que ela devia ser protegida contra isso, da mesma forma que comunicações de LAN por cabo.

Quando as falhas de segurança de WEP começaram a ser amplamente divulgadas, o ambiente de segurança de rede mudava rapidamente. Histórias a respeito de invasões de redes sem fio se destacavam na mídia, enquanto os governos implementavam leis para regulamentar a segurança de dados e identidades nos setores. Em resposta a esses desenvolvimentos, muitas empresas descartaram a tecnologia sem fio como impraticável e pouco segura ou desenvolveram soluções alternativas complexas para tratar as falhas inerentes ao padrão WEP.

Algumas dessas complexas soluções ainda são usadas e comercializadas hoje em dia. No entanto, como demonstram as seções a seguir, essas soluções complexas não são mais necessárias para proteger redes sem fio contra tais ameaças e podem até ser reavaliadas, porque a tecnologia sem fio amadureceu em resposta às mudanças do cenário de segurança.

Selecionando a solução de segurança de WLAN correta

Desde que as falhas tecnológicas da primeira geração de WLANs foram reveladas, houve muitos esforços para tratar as vulnerabilidades da tecnologia sem fio. Enquanto o setor de tecnologia sem fio, a Microsoft e outros fornecedores se concentravam em aperfeiçoar o padrão sem fio, muitos outros analistas, fornecedores de segurança de rede e outros tentavam descobrir meios de solucionar as falhas do padrão sem fio mais antigo. Isso levou a uma variedade de abordagens de como tratar problemas de segurança sem fio.

Exceto a abordagem mais comum, que é decidir não implementar a tecnologia WLAN, as principais alternativas são comparadas na tabela a seguir.

Tabela 2. Comparação de abordagens de segurança de WLAN

Recurso

WPA e WPA2

WEP estático

VPN

IPsec

Autenticação de alta segurança

(consulte Observação)

Sim

Não

Sim, somente quando não usa
autenticação de chave compartilhada

Sim, se usar autenticação Kerberos ou de certificados

Criptografia de dados de alta segurança

Sim

Não

Sim

Sim

Conexão e reconexão transparentes

Sim

Sim

Não

Sim

Autenticação do usuário

(consulte Observação)

Sim

Não

Sim

Não

Autenticação do computador

(consulte Observação)

Sim

Sim

Não

Sim

Protege tráfego de difusão e difusão ponto a ponto

Sim

Sim

Sim

Não

Dispositivos de rede adicionais necessários

Sim, servidores RADIUS

Não

Sim, VPN e servidores RADIUS

Não

Protege acesso à WLAN em vez de apenas aos pacotes

Sim

Sim

Não

Não

Observação   Em relação à autenticação de alta segurança, muitas implementações de VPN que utilizam o modo de túnel IPsec usam um esquema de autenticação de baixa segurança com chave compartilhada chamado XAuth.
As versões atuais do sistema operacional Windows não têm suporte para a autenticação de usuário de associações IPsec, mas essa funcionalidade estará disponível no Windows Vista e no Longhorn.
A autenticação de computador significa que o computador permanecerá conectado à WLAN e à LAN, mesmo quando nenhum usuário tiver efetuado logon ao computador. Esse recurso é necessário para que algumas funções baseadas em domínio, como perfis móveis, funcionem corretamente.

Como mostra essa tabela, existem vários fatores a considerar ao examinar-se as inúmeras possibilidades disponíveis para proteger redes sem fio. Essa avaliação envolve tudo, dos custos associados à implementação e gerenciamento à segurança geral da solução considerada. Cada abordagem tem benefícios e desvantagens, e assim cada solução requer um exame mais detalhado para garantir uma decisão bem-informada.

Para facilitar uma compreensão melhor das opções disponíveis para proteger implementações de WLAN, os seguintes tópicos são analisados em detalhes, organizados pelo grau de segurança que eles fornecem.

  • Não implantar a tecnologia WLAN

  • Usar WPA com EAP-TLS

  • Usar WPA com PEAP-MS-CHAP v2

  • Usar WPA com PEAP-MS-CHAP v2 e Serviços de certificados

  • Usar VPN

  • Usar IPsec

  • Usar WEP

  • Sem segurança de WLAN

Não implantar a tecnologia WLAN

Existe uma máxima conhecida entre profissionais de segurança: “O sistema mais seguro é aquele que nunca é ligado.” Assim, o método mais seguro de implantar qualquer tecnologia, incluindo redes sem fio, é nunca implantá-la. Claro que o problema dessa abordagem é que uma empresa que nunca use qualquer tecnologia pode descobrir que deixou de ser competitiva no mundo dos negócios de hoje em dia, no qual cada vantagem, especialmente em relação à tecnologia, faz diferença.

Como já mencionado, é importante que toda empresa avalie suas necessidades, sua tolerância a riscos e a quantidade de riscos envolvidos em qualquer tecnologia que possa vir a ser adotada, e com a tecnologia sem fio isso não é diferente. Existem muitas vantagens oferecidas por redes sem fio, mas elas podem ser pouco valorizadas ou não se aplicar a uma organização específica.

Ao avaliar a solução de segurança sem fio apropriada para uma empresa, considere todas as opções, incluindo a opção de não implantar uma solução sem fio. No entanto, se uma organização determinar que não está pronta para implantar uma WLAN, essa decisão deve ser parte de uma política da empresa aplicada ativamente para impedir que WLANs mal-intencionadas sejam implantadas por usuários finais, comprometendo assim a segurança da rede.

Usar WPA com EAP-TLS

WPA ou WPA2 com EAP-TLS (Extensible Authentication Protocol Transport Layer Security) com certificados de usuário e de computador é o método mais seguro de autenticação 802.1X com suporte nas versões atuais de clientes sem fio baseados em Windows. EAP-TLS usa certificados digitais para fornecer autenticação mútua, na qual o cliente sem fio autentica o servidor de autenticação e vice-versa. A autenticação EAP-TLS requer uma infra-estrutura de chave pública (PKI) para emitir certificados e mantê-los atualizados. Para o nível mais alto de segurança, a PKI deve ser configurada para emitir certificados de computador e de usuário para acesso sem fio.

Devido aos custos de implementação e à sobrecarga administrativa associados a PKIs, essa solução bastante segura costumava se limitar a empresas de médio ou grande porte, mas agora ela pode ser usada em ambientes de pequenas empresas, devido ao lançamento do Microsoft Small Business Server, que fornece os serviços de certificados subjacentes que a implementação de EAP-TLS requer.

Observação   Atualmente, não há GPOs de suporte para o padrão WPA2 que possam afetar a capacidade de implementar esse padrão com eficácia em ambientes maiores. No entanto, estão sendo desenvolvidas atualizações para Windows Server 2003 e Windows XP para adicionar suporte de GPO ao WPA2. A próxima geração do Windows, Vista e Longhorn, terá suporte nativo para o padrão WPA2.

Usar WPA com PEAP-MS-CHAP v2

WPA ou WPA2 com PEAP (Protected EAP) e MS-CHAP v2 (Microsoft Challenge Handshake Authentication Protocol versão 2) com requisitos de senha forte é a segunda implementação de segurança mais eficaz com suporte de versões atuais de clientes baseados em Windows. Se uma implantação de PKI não for possível, PEAP-MS-CHAP v2 será uma opção viável e segura para implantar uma rede sem fio confiável. PEAP é um esquema de autenticação unidirecional que usa TLS para criar um canal criptografado a partir do servidor de autenticação, pelo qual o cliente usa outro protocolo para se autenticar. Criado originalmente para acesso remoto discado e por VPN, MS-CHAP v2 pode dar suporte à autenticação baseada em senha forte de clientes sem fio, mas somente quando usado com diretivas de senha de usuário forte na rede.

Usar WPA com PEAP-MS-CHAP v2 e Serviços de certificado

É possível combinar o uso de serviços de certificados com uma solução de PEAP-MS-CHAP v2 baseada em senha para empresas que precisem de elementos de ambas as abordagens em sua solução. No entanto, usar PEAP-MS-CHAP v2 não adiciona qualquer outro benefício de segurança considerável à solução EAP-TLS, que já é razoavelmente segura, no momento em que este documento foi escrito. Na verdade, usar PEAP-MS-CHAP v2 com EAP-TLS retarda o processo de autenticação, porque cria dois canais TLS, um dentro do outro. Essa dupla criptografia não agrega valor.

Usar VPN

Quando as falhas de segurança de WEP foram descobertas, uma das primeiras soluções propostas por diversos especialistas de segurança e líderes do setor foi usar VPNs para proteger redes sem fio. A tecnologia VPN certamente é um método seguro e testado de proteger comunicações de rede que atravessam redes hostis, como a Internet, e esta solução para o problema de falhas de WEP ainda é usada em vários ambientes.

Embora pareça uma solução vantajosa do ponto de vista da segurança, ela tem falhas óbvias que a tornam pouco atraente quando comparada à flexibilidade oferecida por soluções que usam WPA, criadas especificamente para tratar ameaças de tecnologia sem fio. Embora seja possível implementar soluções WPA junto com a tecnologia VPN para ajudar a proteger uma rede sem fio, tal solução não tem vantagens sobre uma solução puramente baseada em WPA, especialmente considerando-se a camada de complexidade adicionada a uma rede sem fio quando uma solução VPN é acrescentada.

A usabilidade é outro aspecto a considerar ao decidir-se adicionar uma VPN como parte de uma solução de segurança de WLAN. Embora os requisitos de autenticação adicionais e os limites de tempo associados ao uso de VPN sejam esperados por usuários que se conectam à rede da empresa pela Internet, esses passos extras podem parecer onerosos a um usuário acostumado a se conectar facilmente a recursos de dentro da rede local.

Algumas empresas podem querer usar esta solução apenas por já terem uma solução de VPN instalada para usuários remotos e por sentirem ser necessário estimular seu uso para justificar os gastos. Nesse caso, deve-se considerar outros aspectos antes de escolher esse caminho, incluindo o seguinte:

  • Como é preciso estabelecer uma conexão de VPN para que a comunicação pelo túnel seja permitida, a Diretiva de grupo do computador não se aplicará se o usuário se conectar à VPN depois de fazer logon ao computador local. (Se o usuário selecionar Logon com rede dial-up ao fazer logon no computador, a conexão de VPN será completada primeiro, e a Diretiva de grupo será aplicada.)

  • A maioria dos servidores de VPN foi projetada para proteger conexões mais lentas, como tráfego discado ou de banda larga, e pode se tornar um gargalo de rede quando várias conexões de alta velocidade são estabelecidas.

  • Dependendo da configuração de VPN, os usuários podem enfrentar problemas ao passarem pelos pontos de acesso sem fio, porque as VPNs normalmente cancelam conexões mesmo após um tempo mínimo de desconexão, o que obriga o usuário a se autenticar manualmente mais uma vez toda vez que passar de um ponto de acesso para outro. O mesmo pode ocorrer quando o computador do usuário entra no modo de espera.

Usar IPsec

O uso de IPsec para proteger redes sem fio resultou da mesma necessidade de usar VPNs para proteger WLANs, como uma solução alternativa para as falhas de WEP. É claro que IPsec é uma forma confiável de proteger vários tipos específicos de tráfego de rede e que tem algumas vantagens para uso em WLANs, como sua transparência, sua independência de restrições de hardware de WLAN e sua baixa sobrecarga, porque não requer software e servidores adicionais para funcionar.

Entretanto, existem alguns problemas associados ao uso de IPsec para proteger redes sem fio, que incluem:

  • IPsec não é capaz de proteger tráfego de difusão ou difusão seletiva, porque só rege a comunicação entre duas partes que tenham sido mutuamente autenticadas e que tenham trocado chaves.

  • IPsec não protege a própria rede sem fio, somente os pacotes da rede.

  • Embora IPsec seja transparente ao usuário, não é totalmente transparente aos dispositivos de rede, porque opera na camada de rede em vez da camada MAC. Isso adiciona requisitos de regras de firewall.

  • Quaisquer dispositivos que não possam usar IPsec estarão vulneráveis a sondagem ou ataques de alguém capaz de monitorar o tráfego da WLAN.

  • O gerenciamento de diretivas de IPsec em ambientes maiores pode ficar complicado se o IPsec for usado para fornecer proteção ponta a ponta para outros aplicativos além do tráfego de rede sem fio.

Usar WEP

A forma mais básica de segurança baseada em 802.11 é o WEP estático, que usa uma chave compartilhada para controlar acesso e usa a mesma chave como base para criptografar o tráfego sem fio. A principal atração deste método é sua simplicidade e, embora forneça um pouco mais de segurança em uma configuração sem fio desprotegida, sofre dos mesmos problemas de gerenciamento e segurança, ou seja, pode levar de poucos minutos a algumas horas para descobrir-se a chave compartilhada e o SSID (se não for transmitido) em uma WLAN WEP e assim obter-se acesso a uma rede com um laptop comum e ferramentas simples disponíveis na Internet.

Uma forma de melhorar o WEP estático é configurar pontos de acesso para permitir que somente um grupo de clientes predefinido tenha acesso à rede usando filtragem MAC. No entanto, essa abordagem também é facilmente invadida usando-se ferramentas para descobrir e falsificar os endereços MAC de computadores conectados a uma WLAN.

É possível usar algumas combinações de tecnologias de segurança com WEP para aumentar um pouco a segurança em ambientes que não tenham suporte para WPA ou WPA2, mas mesmo essas configurações não são recomendadas, exceto para uso durante uma fase de transição entre uma implementação de WLAN não protegida e uma configuração protegida baseada em WPA. Esses métodos, na ordem do mais para o menos protegido, são:

  • WEP com autenticação 802.1X usando-se EAP-TLS com certificados de computador e de usuário e reautenticação periódica forçada.

  • WEP com autenticação 802.1X usando-se PEAP-MS-CHAP v2 com diretivas de senha de usuário forte e reautenticação periódica forçada.

Sem segurança de WLAN

Embora nunca seja recomendado implementar uma rede sem fio desprotegida em qualquer ambiente de empresa de médio porte, ainda existem algumas situações em que uma configuração de rede sem fio não protegida possa ser a melhor solução. Por exemplo, várias cidades consideraram ou mesmo implementaram zonas de acesso sem fio gratuitas, e nessa situação pode ser preferível usar uma rede de pontos de acesso sem fio não protegidos que só forneçam conexões diretas à Internet. No entanto, para todos os propósitos, deve ficar claro que redes sem fio não protegidas são extremamente vulneráveis a uma grande variedade de ataques.

WPA ou WPA2

Os protocolos WPA (Wi-Fi Protected Access) e WPA2 (Wi-Fi Protected Access 2) foram projetados especificamente para tratar as ameaças a redes sem fio baseadas em IEEE 802.11. No entanto, existem algumas diferenças entre os dois protocolos. O WPA foi desenvolvido em 2003 como resposta às falhas de segurança descobertas no padrão WEP e solucionava essas falhas satisfatoriamente, implementando suporte para autenticação mútua, usando TKIP para criptografia de dados e incorporando uma verificação de integridade de mensagem assinada para combater ataques de falsificação e repetição. O WPA2 melhora essa segurança, adotando AES em vez de TKIP para proteger o tráfego de rede, o que faz dele a opção preferível em relação ao padrão WPA.

Tanto WPA como WPA2 são muito mais seguros do que WEP e, quando protegidos corretamente, não há falhas de segurança conhecidas no momento em qualquer um dos protocolos. No entanto, WPA2 ainda é considerado mais seguro do que WPA e, quando possível, deve ser usado, desde que a infra-estrutura tenha suporte para ele e a sobrecarga de gerenciamento adicional possa ser atenuada.

A maioria dos dispositivos de acesso sem fio feitos hoje em dia é certificada para WPA2, como as mais recentes versões do Windows, especificamente Windows XP com Service Pack 2 (SP2) e Windows Server 2003 com SP1. Dispositivos sem fio e clientes com suporte para WPA2 também podem usar o padrão WPA mais antigo, caso alguns pontos de acesso sem fio ou clientes implantados em um ambiente não tenham suporte para WPA2.

Observação   Clientes baseados em Windows XP SP2 requerem um pacote de atualização adicional, a Atualização do Wi-Fi Protected Access 2 (WPA2)/Wireless Provisioning Services Information Element (WPS IE), para ativar o suporte à certificação WPA2. Para obter mais informações sobre esta atualização, consulte http://support.microsoft.com/kb/893357/pt-br.
Além disso, as versões atuais do Windows não oferece suporte de GPO a WPA2, o que é uma desvantagem de gerenciamento considerável que torna a implementação de WPA2 muito mais complexa do que a de WPA. Esse pode ser um fator determinante para escolher entre WPA ou WPA2, porque ambos os padrões são relativamente seguros.

Desenvolvendo uma solução de WLAN segura

A seção anterior ajudou a explicar parte do histórico das diferentes opções de segurança de WLAN disponíveis, além de uma explicação das ameaças comuns que as redes sem fio enfrentam e como cada abordagem trata essas ameaças ou está vulnerável a elas. Com essas informações, é possível tomar decisões fundamentadas sobre como cada opção pode ser aplicada a ambientes comerciais específicos.

Os aperfeiçoamentos de segurança mais recentes de padrões de redes sem fio com a implementação de WPA e WPA2 trataram falhas sérias no WEP, diminuindo assim a necessidade de usar soluções alternativas, como IPsec ou VPN, para proteger conexões sem fio. As opções de usar WEP dinâmico ou estático não são recomendadas sob qualquer forma, e não usar funcionalidade de segurança só é útil em algumas poucas situações. A partir dessas pressuposições, só há algumas opções a considerar na formulação de uma solução de segurança abrangente e eficaz para implementações de WLAN.

Esta seção destina-se a orientar os responsáveis por decisões pelas abordagens restantes recomendadas para proteger redes sem fio. Estas soluções recomendadas pela Microsoft são amplamente aceitas por analistas do setor, especialistas de segurança e fornecedores líderes como os métodos mais seguros de implementar uma rede sem fio segura e eficiente. Embora este documento se concentre no método mais adequado a um ambiente de empresa de médio porte, ainda é importante considerar todas as opções e respeitar o processo de decisão, porque sempre há exceções válidas a esta regra.

O processo de decisão da Microsoft para WLAN segura

Existem dois processos de segurança de WLAN recomendados, além de uma terceira abordagem mista. As duas soluções principais, organizadas por nível de segurança, são:

  • WPA2 com EAP-TLS usando Serviços de certificado

  • WPA2 com PEAP-MS-CHAPv2


Além do nível de segurança que cada uma fornece, o fator decisivo principal entre as duas abordagens reduz-se aos recursos necessários para implementar e oferecer suporte a cada solução.

WPA ou WPA2 com PEAP-MS-CHAPv2 tem menos requisitos de equipamentos e especialização técnica porque não requer uma infra-estrutura de certificados subjacente. Como todos os dispositivos à venda atualmente são certificados para WPA2 e não são muito caros, faz sentido usar dispositivos com suporte para WPA2 mesmo se WPA for usado devido à sua vantagem administrativa atual sobre WPA2. O método de criptografia de AES do WPA2 é reconhecido como mais seguro do que o TKIP do WPA, e com o lançamento previsto do suporte para GPO do WPA2, faz sentido ter a base para a futura implementação de WPA2.

Usar WPA ou WPA2 com EAP-TLS é a opção mais segura para proteger uma WLAN, mas tem custos de gerenciamento e implementação mais altos, devido à sua dependência da infra-estrutura de certificados subjacente. No entanto, muitos ambientes de empresas de médio porte já têm sistemas instalados que atendem aos requisitos necessários para WPA2 com EAP-TLS; assim, essa pode ser uma opção mais atraente para muitas empresas. Mesmo sem a tecnologia necessária instalada, muitas empresas têm necessidade da mesma tecnologia na qual se baseia esta solução, certificados e RADIUS; ou seja, pode haver alguns motivos técnicos e comerciais muito bons para a implementação desta solução.


Cc875845.SWCG1(pt-br,TechNet.10).gif

Figura 1. Árvore de decisão de WLAN da Microsoft

O fluxograma da Figura 1 foi usado em guias anteriores da Microsoft para ajudar as organizações a determinar qual abordagem de WLAN segura era mais adequada a seu ambiente e faz certas pressuposições da definição de uma empresa de grande porte. Ao usar este fluxograma, tenha em mente que grandes empresas devem ter mais de 500 funcionários, e uma equipe de TI de pelo menos cinco profissionais de tecnologia.

Como já explicado, a árvore de decisão é um pouco enganosa nesse caso, porque muitas empresas de tamanho médio, para as quais se destina este documento, têm os recursos e a capacidade de implementar WPA2 EAP-TLS com Serviços de certificados de forma fácil, já que a maioria delas tem pelo menos cinco profissionais de TI e pode dar suporte aos requisitos de infra-estrutura adicional para uma implementação básica de EAP-TLS (quatro servidores adicionais, um dos quais permanecerá desconectado da rede).

Com isso, fica claro que a melhor solução para a maioria das empresas de médio porte é WPA2 usando EAP-TLS com Serviços de certificado, e por isso esse será o foco deste documento. No entanto, sempre há exceções válidas à regra, e se uma organização exigir uma abordagem diferente, haverá vários guias para atender a essas necessidades. Por exemplo, se for preferível usar WPA com PEAP-MS-CHAP v2, pode-se encontrar informações adicionais em Protegendo LANs sem fio com PEAP e senhas em http://www.microsoft.com/brasil/security/guidance/lans/peap_1.mspx

Requisitos de servidor de EAP-TLS

Como já mencionado, EAP-TLS requer pelo menos quatro servidores (mais se forem necessários em um ambiente distribuído ou em ambientes maiores), dos quais dois serão usados como servidores IAS (Internet Authentication Service) redundantes (a implementação da Microsoft de um RADIUS (Remote Authentication Dial-in User Service)) e dois farão parte de uma infra-estrutura de certificados básica (PKI). Dos dois servidores de certificados, a autoridade de certificação raiz (CA) será autônoma e ficará fora da rede para proteger o certificado raiz.

Tabela 3. Requisitos de hardware sugeridos para o servidor da CA raiz

Componente

Requisito

CPU

Uma CPU de 733 MHz ou superior

Memória

256 MB de RAM

Interface de rede

Nenhuma (ou desativada)

Armazenamento em disco

Controlador RAID IDE ou SCSI.

2 x 18 GB HDD configurados como volume único RAID 1 (unidade C)

Armazenamento removível local para transferência de dados (certificado raiz).


Como mostra a tabela, os requisitos da CA raiz, baseados nos requisitos genéricos para Windows Server 2003 Standard Edition, não são muito grandes e podem ser projetados em uma plataforma mais antiga que não seja mais usada, ou podem ser criados como uma máquina virtual, se necessário. Muitos clientes acham eficaz usar um laptop porque ele pode ser protegido fisicamente em um cofre da sala de computadores. Independentemente da abordagem usada para criar a CA raiz, é importante garantir que, se necessário, o computador possa ser iniciado ou restaurado sem problemas.

Os requisitos de hardware da autoridade de certificação de emissão são semelhantes, mas existem requisitos de armazenamento adicionais, e o servidor precisa estar conectado à rede. Como esse servidor precisa armazenar todos os certificados emitidos, é recomendável que ele tenha um disco rígido com capacidade de pelo menos 2 GB para cada 1.000 usuários.

Os requisitos do servidor Radius são mais importantes, porque esses servidores são fundamentais para manter a funcionalidade da WLAN e devem ser capazes de tratar muitas tentativas de autenticação em curtos períodos de tempo. Assim, pode ser necessário usar uma plataforma de hardware mais robusta em ambientes que terão milhares de clientes sem fio. Além disso, embora as autoridades de certificação só precisem usar Windows Server 2003 Standard Edition, os servidores IAS podem precisar usar a Enterprise Edition, porque a Standard Edition só oferece suporte para até 50 clientes RADIUS.

Por todos esses motivos, é uma recomendação comum que o IAS seja instalado em controladores de domínio, porque isso reduz a necessidade de hardware de servidor adicional, aproveitando as robustas plataformas de servidor existentes exigidas pelos controladores de domínio; além disso, usar IAS em controladores de domínio na verdade aumenta o desempenho do IAS ao reduzir o tráfego de rede entre controladores de domínio e o IAS para autenticação de usuários.

Failover e redundância, além de considerações sobre locais remotos, também se destacam na determinação dos requisitos para servidores RADIUS. Embora o requisito mínimo recomendável seja dois servidores IAS, algumas empresas podem ter vários escritórios remotos e exigir servidores IAS em alguns desses locais. Algumas empresas também podem ter requisitos maiores para redundância de servidores ou balanceamento de carga.

Embora não haja recomendações contra o uso de servidores multifuncionais como servidores RADIUS, é importante considerar a carga adicional que pode ser colocada nesse servidor e a natureza dessas demandas. Um servidor RADIUS deve ser escalável para tratar uma situação em que todos os clientes sem fio tentem se conectar em um breve intervalo de tempo.

Certificados

Independentemente da abordagem de WPA usada para proteger uma WLAN, é necessário usar certificados, de alguma forma, como parte da solução. PEAP só exige certificados no servidor de autenticação, assim seria possível apenas usar um serviço de certificados de terceiros para fornecer os certificados necessários, o que significa que não seria necessário implementar PKI. Essa é a principal razão pela qual a abordagem PEAP é recomendável em organizações menores que possam não ter a experiência ou os recursos para implementar e dar suporte a uma infra-estrutura de certificados.

A implementação com suporte do Windows do EAP-TLS com Serviços de certificados não exige necessariamente que haja uma PKI subjacente para suporte à emissão de certificados, mas como cada cliente deve ter um certificado para estabelecer autenticação com o servidor RADIUS, o uso de certificados de terceiros pode ter um custo muito alto para empresas que não sejam muito pequenas. As mesmas considerações também são necessárias para usar a abordagem combinada de PEAP com Serviços de certificado.

Se uma organização já tiver uma PKI, o processo de decisão provavelmente será mais simples; afinal, se os componentes já estiverem instalados, a organização poderá usá-los para implementar a opção mais segura da solução de WLAN. Mesmo se não houver uma implementação de PKI estabelecida, uma empresa de médio porte ainda poderá achar útil investir em uma infra-estrutura de certificados, pois essas implementações podem ser usadas em outras aplicações, que incluem:

  • Assinatura de códigos

  • Serviço de mensagens de email seguro

  • Entrega de conteúdo da Web segura

  • Segurança de VPN

  • Serviços de arquivos criptografados


Considerando tudo isso, a abordagem de usar Serviços de certificados com EAP-TLS ou com PEAP é a mais adequada para empresas de médio porte, e é isso o foco deste documento.

Criando uma declaração das práticas de certificado

O planejamento inicial de uma PKI deve incluir a documentação de como os certificados serão usados no ambiente comercial. Embora essas decisões possam ser alteradas conforme a necessidade, é importante descrever essas decisões em uma declaração de diretivas de certificado formal.

Em termos formais, uma diretiva de certificado é um conjunto de regras que regula o funcionamento da PKI. Ela registra informações sobre a aplicabilidade de certificados a aplicativos ou grupos específicos da organização que tenham requisitos de segurança comuns. Uma declaração de práticas de certificado descreve as práticas usadas por uma empresa para gerenciar os certificados que emite. Ela descreve como a diretiva de certificado é interpretada no contexto da infra-estrutura de sistemas da empresa e das diretivas operacionais da organização. Embora uma diretiva de certificado seja um documento para toda a organização, a declaração das práticas de certificado é específica de uma CA, embora as CAs possam ter uma declaração comum, se executarem as mesmas tarefas.

Para algumas empresas, essas declarações são documentos jurídicos que devem ser elaborados de acordo com os requisitos regulamentares que regem os setores nos quais operam, exigindo assistência jurídica para sua criação. No entanto, mesmo se uma empresa não for regida por esses requisitos, ainda é uma boa idéia criar esses documentos.

Hierarquia de CAs

O projeto especificado neste guia usa um modelo de confiança hierárquica com uma única raiz interna. Existem algumas vantagens e desvantagens para essa abordagem, e assim uma análise mais detalhada pode ser necessária para determinar se essa abordagem específica é adequada na empresa onde deve ser implementada. Para obter mais informações sobre esse assunto, consulte o capítulo “Designing a Public Key Infrastructure” (Criando uma infra-estrutura de chave pública) (em inglês) do Windows Server 2003 Deployment Kit em http://technet2.microsoft.com/WindowsServer/en/library/b1ee9920-d7ef-4ce5-b63c-3661c72e0f0b1033.mspx.


Figura 2. Hierarquia de CAs

Figura 2. Hierarquia de CAs

Protegendo a CA raiz

A implementação da Microsoft de EAP-TLS não funcionará a menos que a CA raiz seja protegida “off the wire” (desconectada da rede). Existem alguns bons motivos de segurança para usar uma CA raiz autônoma como essa, em vez de uma CA raiz empresarial, e essa normalmente é a abordagem recomendada para qualquer implementação de PKI.

Como essa abordagem pode parecer um desperdício de recursos, existem alguns métodos que uma empresa pode usar para implantar novamente pelo menos uma parte do hardware usado para criar uma CA raiz que nunca ficará conectada à rede. Algumas das sugestões incluem:

  • Após criar e distribuir o certificado raiz para uma CA de emissão, os discos rígidos da CA raiz podem ser removidos e armazenados com segurança até serem necessários novamente. A desvantagem dessa abordagem é que, se a CA raiz tornar-se necessária, o hardware correspondente a essas unidades precisaria ser recuperado.

  • Após criar e distribuir o certificado raiz para uma CA de emissão, é possível obter uma imagem do servidor por backup e salvá-la em fitas ou outra mídia offline, permitindo reutilizar o hardware do servidor. Mais uma vez, existe o problema de que, se necessário, o hardware precisará ser recuperado.

  • Use um servidor virtual, PC virtual ou algum outro tipo de software de máquina virtual para criar a CA raiz; após a criação e distribuição do certificado raiz, a imagem da máquina virtual pode ser salva em armazenamento offline e arquivada, caso seja necessária novamente. Se uma plataforma genérica padrão (como o sistema de desktop padrão de sua organização, se atender aos requisitos de hardware) for usada para esta abordagem, será mais fácil recuperar o hardware usado caso a CA raiz seja novamente necessária.

  • Crie a CA raiz offline no laptop do ano passado e guarde-o em um cofre da sala de computadores. Isso aproveita um recurso de hardware que de outra forma provavelmente seria descartado.


Autenticação da Internet

O IAS (Internet Authentication Service) é a implementação da Microsoft de um servidor proxy e RADIUS. O IAS pode executar autenticação, autorização e estatísticas centralizadas para diversas conexões de rede. O IAS pode ser usado com outros servidores RADIUS como um encaminhador de autenticação, autorização e estatísticas, com outros servidores VPN como servidores de roteamento e acesso remoto ou com outra infra-estrutura de rede, como pontos de acesso sem fio.

Ao desenvolver um plano de implantação para uma infra-estrutura IAS, é importante tirar proveito do valor de uma infra-estrutura RADIUS baseada em IAS, porque ela não se destina a fornecer acesso a uma única rede isolada. Assim, o planejamento e a implantação de uma infra-estrutura IAS deve incluir uma decisão sobre usar ou não um serviço centralizado para o gerenciamento do acesso a rede, incluindo o uso de um banco de dados de contas centralizado, como o Active Directory, e deve garantir que as necessidades presentes e futuras da organização sejam atendidas. Em outras palavras, a implantação de uma infra-estrutura IAS deve ser estratégica, e não apenas tática.

Este guia trata apenas do planejamento e implantação de IAS na medida em que ele se relaciona a uma infra-estrutura segura de tecnologia sem fio. Para outras possibilidades e problemas de planejamento e implantação de IAS, consulte a seção "Deployment Resources" (em inglês) da página Internet Authentication Service em www.microsoft.com/technet/itsolutions/network/ias/default.mspx.

Implementações de RADIUS preexistentes

Embora esta solução possa ser integrada a implementações de RADIUS preexistentes, este guia não apresenta esse processo. Na maioria dos casos, é vantajoso usar IAS para os recursos descritos neste guia. Para conseguir isso, é possível atualizar plataformas mais antigas com o Windows 2003 Server para que funcionem como servidores RADIUS principais ou modificar servidores RADIUS existentes para o tráfego RADIUS proxy para novos servidores RADIUS com Windows Server 2003.

Para ver a orientação de planejamento detalhada para a migração de infra-estrutura RADIUS existente para servidores RADIUS baseados em Windows Server 2003, consulte a página IAS Technical Reference (em inglês) em http://technet2.microsoft.com/WindowsServer/en/Library/8f5c89d5-fdaf-430c-9ef4-318f8c15baf11033.mspx ou entre em contato com um representante de conta da Microsoft ou um profissional de serviços de consultoria Microsoft.

Failover e balanceamento de carga do servidor RADIUS

Como o RADIUS é um componente fundamental de qualquer solução de segurança sem fio 802.1X, a disponibilidade de uma rede sem fio depende da disponibilidade de servidores RADIUS. Assim, uma solução RADIUS que ofereça suporte a redes sem fio deve ser confiável, proativa e redundante para garantir a disponibilidade, e seu desempenho é equivalente a uma rede cabeada; por isso, é uma recomendação comum que o IAS seja instalado nos controladores de domínio existentes.

Antes de escolher uma estratégia de balanceamento de carga, é importante entender que o 802.1X implementa EAP no RADIUS (EAP-RADIUS) entre os pontos de acesso sem fio e o servidor RADIUS. Embora o RADIUS utilize UDP, EAP é um protocolo orientado por sessão que é encapsulado no RADIUS. Isso significa que vários pacotes EAP-RADIUS que abrangem uma única operação de autenticação devem voltar ao mesmo servidor RADIUS, caso contrário essa tentativa de autenticação falhará.

Existem duas abordagens disponíveis para o balanceamento de carga e failover em servidores IAS em relação a redes sem fio. A primeira é usar servidores proxy IAS com grupos de servidores RADIUS, e a outra é configurar servidores RADIUS primário e secundário usando as configurações de hardware dos pontos de acesso sem fio. A tabela a seguir lista as vantagens e desvantagens de cada abordagem.

Tabela 4. Failover e balanceamento de carga de RADIUS para EAP

Método

Vantagens

Desvantagens

Proxies IAS com grupos de servidores RADIUS

  • Detecção de falha do serviço RADIUS com failover e failback

  • Distribuição da carga de tráfego com base nas propriedades do tráfego

  • Mantém o estado da sessão do EAP ao balancear a carga

  • Distribuição configurável de solicitações aos servidores com base nas configurações de prioridade e peso


  • São necessários servidores IAS adicionais

  • Ainda requer configuração de endereços de servidores RADIUS proxy primário e secundário


Configurações dos servidores RADIUS primário e secundário em pontos de acesso sem fio

  • Configuração mais simples em ambientes menores

  • O ponto de acesso sem fio detecta a falha no tráfego e executa o failover

  • Usa funcionalidade nativa de pontos de acesso sem fio


  • Requer mais planejamento e o monitoramento de sobrecarga para a distribuição de tráfego do RADIUS primário e secundário

  • Alguns pontos de acesso sem fio ainda não têm suporte para a funcionalidade de failback, o que pode levar a cargas de tráfego sem balanceamento


Empresas maiores devem considerar o uso de proxies RADIUS configurados em grupos de servidores RADIUS para distribuir as cargas entre esses servidores. Isso oferece um alto grau de flexibilidade, ao permitir a distribuição de tráfego de acordo com alguns itens configuráveis, incluindo os atributos e o tipo de tráfego de RADIUS, além de valores ponderados e priorizados. Esse tipo de arquitetura também fornece o máximo de flexibilidade e escalabilidade para atender a solicitações de autenticação, ao mesmo tempo em que apresenta menos exigências administrativas.

A funcionalidade de failover de servidor RADIUS mais simples incorporada a pontos de acesso sem fio é capaz de fornecer um nível de resistência suficiente para a maioria das organizações, mas não é uma solução tão sofisticada quanto o uso de grupos de servidores proxy. No entanto, o caminho de migração dessa arquitetura para uma solução de failover e balanceamento de carga baseada em um servidor proxy RADIUS é relativamente simples, além de permitir expansão. Para empresas que considerem apenas uma cobertura sem fio mínima ou limitada, esta solução é eficaz e fácil de implementar; no entanto, o esforço de gerenciamento e implementação cresce junto com o tamanho e a complexidade da rede sem fio, porque cada dispositivo exige cuidadoso monitoramento e planejamento para manter um balanceamento de carga eficaz em todos os servidores.


Cc875845.SWCG3(pt-br,TechNet.10).gif

Figura 3. Métodos de failover e balanceamento de carga de WLAN RADIUS

O balanceamento de carga com a funcionalidade incorporada de pontos de acesso sem fio envolve a configuração de cerca de metade dos pontos de acesso em cada local para serem usados no servidor RADIUS primário, com outro conjunto como o secundário, enquanto que a outra metade dos pontos de acesso sem fio usa atribuições reversas nos campos primário e secundário, como mostrado na Figura 3. A grande sobrecarga torna-se aparente porque pode haver mais carga em alguns pontos de acesso do que em outros, então muito monitoramento é necessário para obter e manter um nível eficaz de balanceamento de carga.

Requisitos de log de RADIUS

Servidores IAS são capazes de registrar dois tipos de eventos:

  • Tentativas de autenticação falhas e bem-sucedidas.

  • Informações sobre autenticação e estatística do RADIUS


Eventos de autenticação são gerados por dispositivos e usuários que tentam acessar a WLAN, e são registrados pelo IAS no log de eventos do sistema do Windows Server 2003. Esses eventos são úteis para a solução de problemas e como parte de um sistema de detecção de invasões e auditoria de segurança. Esses eventos inicialmente devem estar ativados para evento de falha e de êxito, mas depois devem ser filtrados para evitar o estouro do log de eventos do sistema. O uso do log de solicitações de autenticação RADIUS pode tornar o uso desses eventos desnecessário para objetivos de segurança, se ativado.

Servidores IAS centralizados ou distribuídos

Uma arquitetura de servidor IAS centralizado deve ser considerada como um projeto de ponto de partida para a maioria das empresas de médio porte, já que a maioria dessas empresas tem conexões de WAN resistentes e de alta velocidade com recursos remotos, e o tráfego de RADIUS não consome muita largura de banda, pois foi projetado para funcionar em links WAN e conexões discadas. Um projeto centralizado também é mais econômico, desde que uma infra-estrutura subjacente de WAN redundante e de alta velocidade já esteja preparada.

Mesmo assim, é preciso ter cuidado ao analisar a capacidade atual dos links WAN existentes para determinar se essa é a melhor opção, porque outras comunicações, como o tráfego DHCP, podem ter seu tempo limite atingido enquanto aguardam que tentativas de autenticação 802.1X sejam completadas em conexões congestionadas. A conectividade de cliente não é a única preocupação ao considerar-se usar uma arquitetura de IAS centralizada, porque a comunicação entre servidores IAS e controladores de domínio requer conexões de rede robustas para evitar tempos limite durante a determinação de direitos de acesso à rede e participação em grupos.

Algumas empresas podem não estar em posição de tirar proveito de uma arquitetura centralizada devido aos custos associados a conexões de WAN redundantes de alta largura de banda e a equipamentos de rede sofisticados. Essas empresas escolherão usar um projeto de IAS distribuído, em especial se já houver uma infra-estrutura de servidor descentralizada.

Outra abordagem é uma combinação das duas, oferecendo um posicionamento estratégico de servidores IAS em locais que possam dar suporte à infra-estrutura e permitindo que esses servidores forneçam autenticação aos escritórios que não tenham uma base de servidores subjacente, como mostrado na figura a seguir.


Cc875845.SWCG4(pt-br,TechNet.10).gif

Figura 4. Abordagem de infra-estrutura mista de WLAN IAS

Este guia atende aos três modelos, fornecendo orientação para configurar grandes escritórios concentradores com dois servidores RADIUS que possam atender a solicitações locais e remotas e também para configurar grandes escritórios domésticos com opções de filiais de um só servidor.

Observação   O acesso WLAN em escritórios remotos sem uma infra-estrutura de servidor depende da disponibilidade de WAN.

Instalação do servidor IAS e considerações de localização conjunta

Para manter a acessibilidade a serviços de WLAN, deve haver pelo menos dois servidores RADIUS para cada floresta independente do Active Directory. Além desse requisito básico, existem alguns fatores que determinam quantos servidores são necessários e se eles podem ser usados para outras funções.

Em geral, a instalação de servidores IAS deve seguir a instalação dos controladores de domínio, ou seja, se um escritório já depender de um link WAN de alta velocidade com outro escritório para serviços de domínio, provavelmente ele deverá usar um servidor RADIUS remoto também. Escritórios maiores que já tenham seus próprios controladores de domínio provavelmente precisarão ter pelo menos um servidor RADIUS com um possível failover localizado em outro local, dependendo do link WAN disponível. É preciso ter cuidado para avaliar a capacidade do link WAN ao planejar a instalação de servidores RADIUS para a confiabilidade de autenticação de usuários locais e para a instalação de controladores de domínio usados para autenticação, devido ao tráfego extra gerado. Além disso, para melhorar o desempenho, os servidores RADIUS devem estar localizados no domínio raiz de uma floresta para otimizar operações de Kerberos.

Também deve-se considerar se é realmente possível instalar servidores adicionais em locais remotos quando isso parecer necessário, porque alguns escritórios menores podem não ter espaço ou infra-estrutura suficientes para dar suporte a hardware de servidor adicional. Para tratar esses problemas, é possível instalar um servidor IAS com um controlador de domínio do Active Directory. A tabela a seguir descreve algumas vantagens e desvantagens dessa abordagem.

Tabela 5. Considerações sobre a localização conjunta do IAS e dos controladores de domínio

Localização do IAS

Vantagens

Desvantagens

Localização conjunta no controlador de domínio

  • O desempenho da autorização e da autenticação de computadores e usuários aumenta.

  • Reduz a necessidade de hardware de servidor adicional.


  • Sem separação de grupos de administração do IAS e administradores do domínio.

  • Sem distinção inerente de problemas de falha ou desempenho associados a serviços com localização conjunta.


Servidores IAS independentes

  • Separação da administração do IAS dos administradores do domínio.

  • A carga e o comportamento do IAS não afetam o controlador do domínio.


  • Hardware de servidor adicional necessário.



Como mostra a tabela, existe um motivo pelo qual muitas organizações têm diretivas que isolam a funcionalidade do controlador de domínio em seus próprios servidores, porque eles são críticos para o ambiente de rede. Pode haver também questões de segurança associadas à instalação de serviços de IAS em um controlador de domínio quando existe uma separação de tarefas entre os dois grupos administrativos, porque não há distinção inerente entre a administração do IAS e funções de grupos administrativos locais do Windows. Essas questões devem ser consideradas antes de decidir-se pela possibilidade de localização conjunta de serviços de IAS, mas há alguns benefícios de desempenho ao fazer-se isso, além do benefício óbvio do custo, especialmente em locais remotos.

Para contrabalançar as considerações de custo envolvidas na adição de hardware de servidor em escritórios remotos, é possível usar controladores de domínio existentes, que já podem existir em locais remotos, como servidores IAS diretamente ou com a adição de uma máquina virtual ao controlador de domínio existente.

Estimando requisitos de hardware e carga do servidor

A abordagem de avaliação e planejamento de cargas potenciais do servidor deve usar cenários das piores possibilidades. Especificamente, o que aconteceria se todos os possíveis usuários da WLAN precisassem fazer autenticação em um breve período de tempo durante um evento de failover? É claro que o melhor projeto é aquele que implante o número mínimo de servidores necessários para resistência, ao mesmo tempo em que deixe espaço para crescimento futuro conforme necessário.

As informações a seguir devem ser consideradas no planejamento de requisitos e cargas do servidor IAS:

  • O número de usuários e dispositivos que precisam de autenticação e estatística.

  • As opções de autenticação, como o tipo EAP, e a freqüência da reautenticação.

  • Opções do RADIUS, como registro em log e monitoramento do software IAS.


Para esta solução, usando-se WPA ou WPA2 com serviços de certificados EAP-TLS, é importante observar que, ao contrário de WEP, WPA e WPA2 diminuem a necessidade de reautenticação forçada para atualizar chaves de sessão, o que causa menos sobrecarga nesse aspecto. É importante observar também que o EAP-TLS requer uma operação de chave pública que exige bastante da CPU na autenticação inicial, mas depois usa credenciais em cache para reconexão rápida em cada logon subseqüente até a expiração da credencial em cache, o que ocorre por padrão a cada 8 horas. Observe também que a reautenticação ocorrerá quando um cliente passar de um ponto de acesso sem fio que autentique em um servidor RADIUS para um ponto que autentique em outro servidor de autenticação; isso só ocorre uma vez por servidor de autenticação e é transparente para o usuário.

Ao estimar a capacidade do servidor IAS, é útil usar o número de autenticações por segundo como uma estimativa de cargas potenciais. A tabela a seguir mostra a capacidade de autenticação por segundo estimada de um servidor IAS com Active Directory em uma plataforma de CPU 2 GHz Intel Pentium 4.

Tabela 6. Autenticações por segundo

Tipo de autenticação

Autenticações por segundo

Novas autenticações EAP-TLS

36

Novas autenticações EAP-TLS com suporte para placa de descarga

50

Autenticações com reconexão rápida

166


Observação   As informações dessa tabela devem ser consideradas apenas como uma estimativa que pode ser usada como uma possível orientação para o planejamento.

A tabela sugere que um servidor pode ser capaz de processar 36 novas autenticações por segundo em caso de evento de failover ou alta demanda, e assim levaria 3 segundos para autenticar 100 usuários.

Outro fator a considerar é o efeito do log baseado em disco nos tempos de autenticação. Um subsistema de disco lento pode ter um impacto negativo nos tempos de autenticação quando o log detalhado é usado para controlar a atividade de autenticação. Lembre-se de usar um subsistema de disco rápido para manter um tempo de resposta razoável em cada servidor IAS.

Autenticação WPA 802.11

O uso de uma infra-estrutura de certificados e do RADIUS para proteger a comunicação sem fio ao fornecer autenticação de dispositivo e usuário foi abordado, e agora é hora de analisar como os dados transmitidos entre dispositivos sem fio são protegidos de sondagem e outros riscos.

O uso de transmissões de rádio sempre foi considerado menos seguro do que as comunicações por rede cabeada, porque é muito mais fácil interceptar dados transmitidos pelo ar do que acessar um cabo ou patch panel, especialmente quando a segurança de porta é usada. Para combater a natureza inerentemente insegura da comunicação sem fio, é necessário criptografar os dados para que uma interceptação não forneça informações facilmente legíveis a espiões potenciais.

As especificações iniciais de WEP para a criptografia sem fio foram consideradas inadequadas para essa tarefa, e assim o WPA foi criado como uma medida de proteção paliativa e um subconjunto da especificação 802.11i, que estava pendente na época. Finalmente, o WPA2 foi esboçado como a implementação completa do agora oficial padrão 802.11i. A principal diferença entre WPA e WPA2 está no método de criptografia, pois WPA usa TKIP e WPA2 usa o padrão mais seguro AES-CCMP.

Embora a solução fornecida neste guia possa ser usada para proteger WEP ou WPA, é recomendável usar WPA2 para garantir a forma mais extrema e confiável de segurança disponível para comunicações sem fio, quando isso for possível de uma perspectiva gerencial. Caso contrário, o uso do WPA com a solução fornecida neste guia também oferece um nível de segurança adequado.

Requisitos do cliente

A solução descrita neste guia foi criada para computadores clientes ativados para comunicação sem fio que usem Windows XP Professional com SP2 ou Windows XP Tablet Edition. Essas versões do sistema operacional Windows oferecem suporte incorporado para 802.1X e WLAN. Além disso, clientes baseados em Windows XP oferecem funcionalidade automática de renovação e registro de certificados, o que torna uma solução baseada em certificados como essa especialmente econômica quando unida a uma infra-estrutura de certificados.

Embora o Windows XP SP2 ofereça suporte incorporado para WPA, é necessário instalar uma atualização adicional para ativar o suporte para WPA2 IEEE 802.11i em clientes baseados em Windows XP SP2. Para obter mais informações sobre essa atualização adicional, além de instruções de download, consulte a Atualização do Wi-Fi Protected Access 2 (WPA2)/Wireless Provisioning Services Information Element (WPS IE)
para Windows XP com Service Pack 2
disponível em http://support.microsoft.com/kb/893357/pt-br.

Requisitos de infra-estrutura do servidor

Como analisado anteriormente, esta solução requer o uso dos componentes Serviços de certificados e IAS do Windows Server 2003. Existem alguns recursos incorporados com suporte da implementação do Windows Server 2003 para Serviços de certificados e IAS que são específicos de WLANs 802.1X. Embora IAS e Serviços de certificados possam ser implantados em versões mais antigas do Windows, este guia foi escrito especificamente para um ambiente Active Directory do Windows Server 2003.

Requisitos de pontos de acesso sem fio

Este guia se concentra no elemento de segurança de uma solução WLAN, e assim não há orientação para a implantação, posicionamento ou seleção de canais para hardware de pontos de acesso sem fio. Para obter mais informações sobre problemas, configurações ou orientação de posicionamento específicos de pontos de acesso sem fio, consulte o site ou material instrutivo do fornecedor.

Esta solução é a mais segura ao usar-se hardware de ponto de acesso sem fio que seja certificado para WPA2 IEEE 802.11i e que ofereça funcionalidade incorporada de failover/failback. É possível implementar essa solução usando equipamentos certificados para WPA sem muitas modificações desta orientação e ainda assim manter um alto nível de segurança. No entanto, embora também seja possível implementar esta solução com o padrão WEP, isso não é recomendado e não tem o suporte deste guia.

Implantação e gerenciamento

Embora esta seção inclua orientação passo a passo relacionada à instalação e configuração de servidores e serviços necessários para a solução, ela não inclui a instalação real e as etapas de configuração necessárias para sistemas operacionais como Windows Server 2003 e Windows XP Professional. Pressupõe-se que a maioria das empresas tenha estabelecido processos de construção e diretrizes de proteção.

Certificados

Embora esta seção ofereça orientação detalhada sobre a instalação de uma PKI, ela não inclui detalhes do processo de construção e proteção de servidor, porque pressupõe-se que já exista um processo padronizado estabelecido para esses procedimentos.

Também pressupõe-se que os servidores de CA já tenham sido configurados com uma imagem básica e tenham sido protegidos com um processo padrão da organização antes desta fase da solução.

Observação   Lembre-se de que a CA raiz nunca será conectada à rede, e assim quaisquer etapas do processo de construção e proteção de servidor da organização que envolvam uma conexão de rede deverão ser modificadas para acomodar essa exceção.

Pré-requisitos de informações de configuração definidas pelo usuário

A tabela a seguir lista parâmetros específicos da organização que devem ser coletados ou decididos antes do início da implantação da solução fornecida posteriormente neste guia. Em todo este guia haverá espaços reservados usados para descrever configurações que usam um formato semelhante ao nome da configuração. Por exemplo, o nome DNS de um domínio raiz da floresta do Active Directory pode ser mostrado como NomedoDominio.com.br. O valor listado em itálico deve ser substituído pelas informações específicas da organização coletadas durante esse processo.

Tabela 7. Informações de configuração definidas pelo usuário

Item de configuração

Referência

Configuração

Nome DNS da floresta do Active Directory



DN (Nome Distinto) da raiz da floresta

Pkiparams.vbs


Nome NetBIOS do domínio



Nome NetBIOS do grupo de trabalho da CA raiz



Nome de servidor da CA raiz



Nome de servidor da CA de emissão



CN X.500 da CA raiz



CN X.500 da CA de emissão



Nome do host totalmente qualificado do servidor Web usado para publicar certificados da CA

Pkiparams.vbs


Pré-requisitos de itens de configuração recomendados para a solução

As configurações identificadas na tabela a seguir não precisam ser alteradas a menos que uma configuração diferente seja necessária. Certifique-se de que quaisquer implicações que possam ocorrer e quaisquer dependências que possam ser alteradas com a modificação desses parâmetros sejam totalmente compreendidas antes de alterar as configurações listadas aqui.

Tabela 8. Itens de configuração recomendados pela solução

Item de configuração

Referência

Configuração

Grupos de Segurança com Função Administrativa



Administradores de recipiente de configuração de Serviços de Chave Pública.

ca_setup.wsf

Administradores de PKI Corporativa

Grupo administrativo com permissão para publicar CRLs e certificados de CA para o recipiente de configuração corporativo.

ca_setup.wsf

Editores de PKI Corporativa

Grupo administrativo que configura e mantém as CAs e controla a capacidade de atribuir todas as outras funções de CA e renovar o certificado da CA.

ca_setup.wsf

Administradores de CA

Grupo administrativo que aprova solicitações de revogação e registro de certificado (função do executivo da CA).

ca_setup.wsf

Gerenciadores de Certificados

Grupo administrativo que gerencia logs de segurança e auditoria de CA.

ca_setup.wsf

Auditores de CA

Grupo administrativo que gerencia o backup de CAs.

ca_setup.wsf

Operadores de Backup de CA

Configuração do IIS



Nome do diretório virtual IIS usado para publicar certificados de CA e informações de CRLs.

Pkiparams.vbs

pki

Caminho físico na CA de emissão que mapeia para o diretório virtual do IIS.

C:\CAWWWPub

Pkiparams.vbs

Parâmetros comuns de CA



Unidade e caminho para arquivos de solicitações dos Serviços de certificados

C:\CAConfig

Pkiparams.vbs

Unidade e caminho para logs do banco de dados dos Serviços de certificados.


%windir%\System32\CertLog

Configuração da CA raiz



Comprimento da chave da CA raiz (consulte Observação)

4096


Período de validade do certificado da CA raiz (anos)

Pkiparams.vbs

16

Período de validade máximo de certificados emitidos pela CA raiz (anos)

Pkiparams.vbs

8

Intervalo de publicação de CRL da CA raiz (meses)

Pkiparams.vbs

6

Período de sobreposição de CRLs (dias)

Pkiparams.vbs

10

Período de publicação de CRL Delta para CA raiz (horas, 0=desativar)

Pkiparams.vbs

0

Configuração da CA de emissão



Unidade e caminho do banco de dados dos Serviços de certificados.


D:\CertLog

Comprimento da chave da CA de emissão


2048

Período de validade do certificado da CA de emissão (anos)

Pkiparams.vbs

8

Período de validade máximo para certificados de CA de emissão (anos)

Pkiparams.vbs

4

Intervalo de publicação de CRL da CA de emissão (dias)

Pkiparams.vbs

7

Período de sobreposição de CRLs. (dias)

Pkiparams.vbs

4

Período de publicação de CRL Delta para CA de emissão (dias, 0=desativar)

Pkiparams.vbs

1

Período de sobreposição de CRL Delta. (dias)

Pkiparams.vbs

1

Diversos



Caminho de scripts de instalação


C:\MSSScripts


Observação   Usar chaves de 4096 bits de comprimento pode causar problemas de compatibilidade se forem usadas por alguns dispositivos ou por software mais antigo de outros fornecedores. Todos os aplicativos que possam vir a usar certificados emitidos pela CA raiz devem ser testados com chaves de certificado desse comprimento para garantir a funcionalidade correta. O comprimento de chave da CA raiz pode ser reduzido para 2048 bits se houver preocupação com a compatibilidade de comprimento da chave.

Instalando scripts de configuração nos servidores CA

Os scripts de suporte fornecidos com esta orientação destinam-se a ajudar na configuração da solução fornecida nas seções a seguir. Esses scripts devem ser instalados em cada servidor CA e não devem ser excluídos após o uso para ajudar na operação desses servidores. Para instalar esses scripts, primeiro crie uma pasta chamada C:\MSSScripts e copie os scripts para esse diretório.

Instalando e configurando IIS no servidor CA de emissão

O IIS (Internet Information Services) é usado como um ponto de download para que clientes que não são Windows recuperem certificados de CA e CRLs. A CA raiz não precisa fornecer esse serviço, especialmente porque ela não deve estar conectada a uma rede, mas a CA de emissão deve ter acesso a esse serviço.

O IIS também pode ser usado para hospedar as páginas de registro na Web para Serviços de certificados, embora elas não sejam usadas nesta solução. Se as páginas de registro na Web estiverem instaladas em um sistema diferente da CA de emissão, esse servidor deverá ser marcado como “Confiável para delegação” definindo-se essa propriedade no objeto de computador do servidor no Active Directory.

O IIS pode ser instalado usando-se o Gerenciador de Componentes Opcionais, acessado pelo item Adicionar ou Remover Componentes do Painel de Controle. A lista a seguir mostra os componentes que precisam ser instalados:

  • Servidor de Aplicativos

  • Ativar acesso ao COM+ de rede

  • Internet Information Services

  • Arquivos Comuns

  • Internet Information Services Manager

  • World Wide Web Service


Para instalar o IIS

  1. Execute o seguinte em um prompt de comando

    Sysocmgr /i:sysoc.inf /u:C:\MSSScripts\OC_AddIIS.txt
    
    

    Esse comando instrui o Gerenciador de Componentes Opcionais a usar as configurações do componente especificadas no arquivo de instalação automática C:\MSSScripts\OC_ AddIIS.txt, desta forma:

    [Components]
    complusnetwork = On
    iis_common = On
    iis_asp = On
    iis_inetmgr = On
    iis_www = On
    
    

    Observação    Active Server Pages (ASP) é ativado neste arquivo de configuração; porém, se as páginas de registro na Web de Serviço de certificados não forem necessárias, ASP deverá ser desativado excluindo-se a linha iis_asp = on antes de executar sysocmgr.exe. Essa configuração poderá ser ativada posteriormente, se necessário.

  2. Execute o Gerenciador de Componentes Opcionais novamente da forma a seguir e verifique se os componentes instalados correspondem aos listados anteriormente.

    sysocmgr /i:sysoc.inf
    
    

    Nenhum outro subcomponente do Servidor de Aplicativos é necessário e, portanto, não precisa ser selecionado.


Configurando o IIS para a publicação de AIA e CDP CRL na CA de emissão

É preciso criar um diretório virtual no IIS para ser usado como local HTTP para pontos de certificado de CA e publicação de CRL (chamados de AIA - Acesso a Informações da Autoridade e CDP (Ponto de Distribuição de CRL, respectivamente).

Para criar um diretório virtual no IIS

  1. Faça logon no servidor de IIS com privilégios de administrador local.

  2. Crie uma pasta chamada C:\CAWWWPub que conterá os certificados da CA e CRLs.

  3. Defina a segurança na pasta de acordo com a seguinte tabela:

    Tabela 9. Permissões do diretório virtual

    Usuário/Grupo

    Permissão

    Permitir/Negar

    Administradores

    Controle total

    Permitir

    Sistema

    Controle total

    Permitir

    Proprietários Criadores

    Controle Total (apenas subpastas e arquivos)

    Permitir

    Usuários

    Leitura e Listar Conteúdo da Pasta

    Permitir

    IIS_WPG

    Leitura e Listar Conteúdo da Pasta

    Permitir

    Conta de Convidado da Internet

    Gravar

    Negar

  4. Use o console de gerenciamento do IIS para criar um novo diretório virtual sob o site padrão:

    • Nomeie o diretório virtual pki

    • Especifique C:\CAWWWPub como o caminho.


  5. Limpe a opção Executar scripts nas permissões de acesso do diretório virtual.

  6. Certifique-se de que a autenticação anônima esteja ativada para o diretório virtual.


Escolhendo um alias DNS para o ponto de publicação de HTTP

Um alias DNS genérico (CNAME) deve ser criado para resolver o servidor IIS que hospeda CDP e AIA. Esse alias DNS deve ser usado ao configurar-se os caminhos de CDP e AIA para as CAs nas seções subseqüentes. Com aliases, os pontos de publicação de CA podem ser movidos com facilidade para outros servidores ou locais da rede sem a necessidade de emitir certificados de CA novamente.

Outros itens de componentes de sistema operacional e configuração

Além das etapas de configuração descritas até agora, existem outros itens recomendados que podem exigir atenção, incluindo:

  • Serviço Atualizar Certificados Raiz. O serviço Atualizar Certificados Raiz deve ser desativado porque não é vantajoso ter a confiabilidade de raiz das CAs atualizada automaticamente. Para remover esse serviço, execute o seguinte comando em um prompt de comando:

    sysocmgr /i:sysoc.inf /u:C:\MSSScripts\OC_RemoveRootUpdate.txt
    
    

    O arquivo OC_RemoveRootUpdate.txt file contém as linhas a seguir:

    [Components]
    rootautoupdate = off
    
    

  • Certifique-se de que a CA raiz não tenha conectividade de rede e que a CA de emissão não tenha conectividade de Internet de entrada ou saída.

  • Verifique se há service packs e atualizações adicionais que possam ser necessários por o IIS ter sido instalado.

  • Instale Ferramentas de Suporte do Windows Server 2003; embora não seja necessário, é útil ter essas ferramentas disponíveis para certas operações de CA e solução de problemas em geral.

  • Instale o CAPICOM. CAPICOM 2.1 é necessário na CA raiz e na CA de emissão para alguns dos scripts de gerenciamento e instalação que acompanham este guia. Para obter mais informações sobre CAPICOM e um link para o local de download, visite http://www.microsoft.com/downloads/details.aspx?displaylang=pt-br&FamilyID=860ee43a-a843-462f-abb5-ff88ea5896f6.

Preparando o Active Directory para a PKI

Os requisitos fundamentais para uma infra-estrutura de domínio do Active Directory que são descritos nesta seção baseiam-se em uma arquitetura de Active Directory do Microsoft Windows Server 2003. Se a implementação do Active Directory em uso for baseada em Windows 2000, outros requisitos poderão ser necessários. Para obter mais informações sobre requisitos adicionais para uma estrutura de domínios baseada em Windows 2000, consulte o artigo sobre como aumentar os níveis funcionais de domínio e floresta no Windows Server 2003 (a página pode estar em inglês) em http://support.microsoft.com/kb/322692.

Esta solução também requer um nível funcional mínimo de domínio no Modo Nativo do Windows 2000, pelo menos para o domínio onde os servidores CA serão instalados. Este requisito é necessário porque a solução usa grupos universais do Active Directory, disponíveis no Modo Nativo do Windows 2000 e posterior.

Criando grupos de administração de CA e PKI

Esta solução define vários grupos de segurança correspondentes a funções administrativas separadas. Esta abordagem fornece bastante controle sobre a delegação para a administração de CAs, junto com os princípios de segurança de menos privilégios. No entanto, não existe outro motivo para usá-los, se não corresponderem a qualquer modelo administrativo específico da organização.

Para criar grupos de administração de CAs em um domínio

  1. Faça logon em um computador membro do domínio com uma conta que possa criar objetos de usuário e de grupo no recipiente Usuários.

  2. Execute o seguinte comando para criar os grupos de gerenciamento da CA do domínio:

    Cscript //job:CertDomainGroups C:\MSSScripts\ca_setup.wsf
    
    

    Este script criará os grupos de segurança listados na tabela a seguir. Esses grupos são criados como grupos universais no recipiente Usuários do domínio e podem ser movidos para uma UO apropriada, o que pode ser exigido por diretivas usadas na organização.

    Tabela 10. Nomes de grupos e objetivos

    Nome do grupo

    Objetivo

    Administradores de PKI Corporativa

    Administradores do recipiente de configuração de Serviços de Chave Pública.

    Editores de PKI Corporativa

    Têm permissão para publicar CRLs e certificados de CA para o recipiente de configuração corporativo.

    Administradores de CA

    Têm capacidade administrativa total sobre a CA, incluindo a capacidade de determinar a participação de membros de outras funções.

    Gerenciadores de Certificados

    Gerenciar a emissão e revogação de certificados

    Auditores de CA

    Gerenciar dados de auditoria para CA

    Operadores de Backup de CA

    Têm permissão para fazer backup e restaurar chaves e dados de CA.


Os procedimentos de configuração no restante deste documento exigem o uso de contas que sejam membros dos grupos Administradores de PKI Corporativa, Editores de PKI Corporativa e Administradores de CA, e assim esses grupos devem estar preenchidos com as contas apropriadas para que seja possível continuar. Se houver apenas uma pessoa responsável por todas as funções relacionadas à CA, uma única conta poderá ser atribuída a todos os grupos; no entanto, a maioria das empresas tem algum grau de separação de funções e tarefas entre os funcionários, embora não de forma tão complexa como aquela citada na tabela anterior. Para as empresas que tenham uma separação simplificada de tarefas, o gráfico a seguir lista divisões de responsabilidade comuns.

Tabela 11. Modelo de administração simplificado

Função administrativa

Membros do grupo

Administrador de CA

Administradores de PKI Corporativa, Administradores de CA, Gerenciadores de Certificados, Administradores

Auditor de CA

Auditores de CA, Administradores

Operador de Backup de CA

Operadores de Backup de CA

Estrutura de UO do domínio sugerida

Existem inúmeras contas de grupos e usuários que serão associadas ao gerenciamento e operação de uma PKI. Dependendo das diretrizes estabelecidas, pode ser necessário organizar esses grupos e usuários em uma estrutura de UO específica. Como essa estrutura pode ser ditada por orientações já existentes na empresa, é oferecida abaixo uma sugestão que pode ser modificada conforme necessário.

Para criar uma hierarquia de UO de Serviços de certificados

  1. Faça logon usando uma conta que tenha permissões para criar UOs e para delegar permissões nessas UOs.

  2. Crie uma estrutura de UO com base na tabela a seguir:

    Tabela 12. Exemplo de estrutura de UO

    Unidade organizacional

    Objetivo

    Serviços de certificados

    UO pai

    \-Administração de serviços de certificados

    Contém grupos administrativos para o gerenciamento de CAs e configuração da PKI corporativa.

    \-Gerenciamento de modelos de certificados

    Contém grupos para gerenciar modelos de certificados individuais.

    \-Registro de modelos de certificados

    Contém grupos que tenham permissões de Registro ou Registro Automático em modelos com o mesmo nome. O controle desses grupos pode ser delegado ao pessoal apropriado, sem modificação dos próprios modelos.

    \-Usuários de teste de serviços de certificados

    Contém contas de teste temporárias.

  3. Conceda permissões ao grupo Administradores de PKI Corporativa para criar e excluir grupos na UO de Serviços de certificados e seus recipientes filhos.


Concedendo permissões ao recipiente de Serviços de Chave Pública

A segurança do recipiente de Serviços de Chave Pública deve ser alterada para permitir que Administradores de PKI Corporativa instalem CAs corporativas e configurem modelos de certificados sem exigir que as contas do grupo sejam membros do grupo Administradores de Empresa. Isso também é necessário para permitir que Editores de PKI Corporativa publiquem listas de revogação de certificados e certificados de CA sem precisar de direitos de Administradores de Empresa.

Para fazer as alterações a seguir, é preciso usar uma conta equivalente a Administrador de Empresa do Active Directory.

Para conceder permissões a Administradores de PKI Corporativa

  1. Faça logon como membro do grupo de segurança Administradores de Empresas.

  2. No snap-in Serviços e Sites do Active Directory do MMC, exiba o nó Serviços no menu Exibir e, em seguida, navegue até o sub-recipiente Serviços de Chave Pública e abra suas propriedades.

  3. Na guia Segurança, adicione o grupo de segurança Administradores de PKI Corporativa e conceda Controle Total a esse grupo.

  4. Na exibição Avançada, edite as permissões desse grupo para garantir que o Controle Total se aplique a este objeto e a todos os objetos filhos.

  5. Selecione o recipiente Serviços e abra suas propriedades.

  6. Na guia Segurança, adicione o grupo de segurança Administradores de PKI Corporativa e conceda Controle Total a esse grupo.

  7. Na exibição Avançada, edite as permissões desse grupo para garantir que o Controle Total se aplique somente a este objeto.


Para conceder permissões a Editores de PKI Corporativa

  1. Faça logon como membro do grupo de segurança Administradores de Empresas.

  2. No snap-in Serviços e Sites do Active Directory do MMC, exiba o nó Serviços e abra as propriedades do recipiente de Serviços de Chave Pública\AIA.

  3. Na guia Segurança, adicione o grupo de segurança Administradores de PKI Corporativa e conceda as seguintes permissões a esse grupo:

    • Ler

    • Gravar

    • Criar todos os objetos filhos

    • Excluir todos os objetos filhos


  4. Na exibição Avançada, edite as permissões desse grupo para garantir que as permissões se apliquem a este objeto e a todos os objetos filhos.

  5. Repita as etapas 2-4 para os seguintes recipientes:

    • Serviços de Chave Pública\CDP

    • Serviços de Chave Pública\Autoridades de Certificação



Concedendo permissões ao grupo Editores de Certificados

Todas as contas de computador da CA corporativa no domínio residirão no grupo de segurança Editores de Certificados. Esse grupo será usado para aplicar permissões a objetos de computador e de usuário, e a objetos no recipiente CDP mencionado no procedimento anterior. Sempre que uma CA é instalada, sua conta de computador precisa ser adicionada a esse grupo.

Para permitir que membros do grupo Administradores de PKI Corporativa instalem CAs corporativas, as permissões desse grupo devem ser alteradas.

Para conceder as permissões para modificar membros do grupo em Editores de Certificados

  1. Faça logon como membro de Admins do Domínio para o domínio no qual as CAs de emissão serão instaladas.

  2. Abra o snap-in Usuários e Computadores do Active Directory do MMC.

  3. No menu Exibir do MMC, verifique se Recursos Avançados está selecionado.

  4. Localize o grupo Editores de Certificados (por padrão no recipiente Usuários) e exiba as propriedades do grupo.

  5. Na guia Segurança, adicione o grupo Administradores de PKI Corporativa e clique no botão Avançado.

  6. Selecione Administradores de PKI Corporativa do grupo na lista e clique no botão Editar.

  7. Selecione a guia Propriedades e verifique se Apenas este Objeto está selecionado na caixa Aplicar em.

  8. Role para baixo e clique na caixa Gravar Membros na coluna Permitir.

  9. Salve as alterações e feche cada caixa de diálogo clicando em OK para cada uma.

  10. Reinicie o servidor da CA de emissão antes de instalar o componente Serviços de certificados. O reinício permite que o servidor selecione o novo membro de grupo em seu token de acesso.


Concedendo permissões de restauração ao grupo Administradores de PKI Corporativa

O processo de instalação de Serviços de certificados requer o direito de usuário Restaurar arquivos e pastas para o domínio em que a CA corporativa será colocada. Especificamente, esse direito é necessário para permitir que descritores de segurança nos modelos e outros objetos do diretório sejam mesclados, concedendo assim as permissões corretas aos objetos PKI do domínio. Os grupos de domínio internos Administradores, Operadores de Servidores e Operadores de Backup têm esse direito por padrão.

Como o grupo Administradores de PKI Corporativa serão usados para instalar a CA, o direito de usuário Restaurar arquivos e pastas deverá ser concedido a esse grupo.

Para conceder os direitos Restaurar ao grupo Administradores de PKI Corporativa

  1. Faça logon como membro de Admins do Domínio para o domínio no qual a CA de emissão será instalada.

  2. Abra o snap-in Usuários e Computadores do Active Directory do MMC.

  3. Selecione a UO Controladores de Domínio e abra as propriedades dessa UO.

  4. Na guia Diretiva de grupo, selecione GPO de Diretiva de Controladores de Domínio Padrão e clique em Editar.

  5. Navegue até Configuração do Computador\Configurações do Windows\Configurações de Segurança\Diretivas Locais\Atribuição de Direitos de Usuário e clique duas vezes em Restaurar Arquivos e Pastas.

  6. Adicione o grupo Administradores de PKI Corporativa à lista mostrada.

  7. Feche a caixa de diálogo e o MMC de edição do GPO.

    Observação   Se houver outros GPOs que definam o direito de usuário Restaurar Arquivos e Pastas nos controladores de domínio, esse procedimento deverá ser executado no GPO de prioridade mais alta, em vez de em Diretiva de Controladores de Domínio Padrão. As configurações dos direitos de usuário não são cumulativas, e apenas o último GPO aplicado que tenha esse direito definido entrará em vigor.

Implantando um servidor de CA raiz

Como já mencionado, este guia não oferece instruções passo a passo para instalar o Windows Server 2003, porque a maioria das empresas já tem um processo de construção de servidor documentado. No entanto, servidores de CA raiz são um pouco diferentes de outros servidores, pois nunca devem ser conectados a uma rede para garantir que não sejam comprometidos.

Assim, é importante garantir que o servidor de CA raiz não esteja conectado à rede durante o processo de construção e que em algum momento os adaptadores de rede sejam desativados para garantir que nunca haja uma conexão acidental. Também é importante observar que, como o servidor não será anexado à rede, ele residirá em um grupo de trabalho, e o nome desse grupo deverá ser escolhido e documentado antes da instalação.

Observação   Embora a CA raiz seja construída e mantida offline, é importante que seu nome seja exclusivo no ambiente de rede.

Arquivo CAPolicy.inf

Após obter o hardware de servidor necessário para um servidor de CA raiz e instalar o sistema operacional, a próxima etapa será a criação de um arquivo capolicy.inf. O arquivo capolicy.inf é necessário para criar uma CA raiz porque ele especifica as características do certificado de CA raiz assinado automaticamente, como o comprimento da chave e o período de validade do certificado.

As informações sobre CRL e AIA não são necessárias para um certificado da CA raiz, e assim os parâmetros CRLDistributionPoint e AuthorityInformationAccess são definidos como Empty no arquivo capolicy.inf.

Para criar um arquivo CAPolicy.inf

  1. Usando um editor de texto, como o Bloco de Notas, crie um arquivo de texto sem formatação com o texto a seguir:

    [version]
    Signature=”$Windows NT$”
    
    [Certsrv_server]
    RednewalKeyLength=4096
    RenewalValidityPeriod=Years
    RenewalValidityPeriodUnits=16
    
    [CRLDistributionPoint]
    Empty=true
    
    [AuthorityInformationAccess]
    Empty=true
    
    

  2. Se houver uma declaração das práticas de certificado (CPS) definida para esta CA, inclua as informações a seguir no arquivo capolicy.inf, substituindo os valores em itálico por aqueles específicos desta implementação:

    [CAPolicy]
    Policies=company CPS name
    
    [company CPS name]
    OID=the.company.OID
    URL=”http://www.companyurl.com/cpspagename.htm”
    
    

  3. Salve este arquivo de texto como %windir%\Capolicy.inf (substitua %windir% com o caminho absoluto da pasta em que o Windows está instalado, por exemplo, C:\Windows). Um administrador ou uma conta com permissões equivalentes será necessário para salvar o arquivo na pasta Windows e completar esta etapa.


Instalando os componentes do software Serviços de certificados

Use o Assistente de Componentes do Windows para instalar os componentes de software da CA. Observe que a mídia de instalação do Windows Server 2003 deverá estar disponível para completar esta instalação.

Para instalar os Serviços de certificados

  1. Faça logon como um membro do grupo local Administradores e execute o Gerenciador de Componentes Opcionais, ou, no Painel de Controle, use Adicionar ou Remover Programas/Componentes do Windows.

    sysocmgr /i:sysoc.inf
    
    

  2. Selecione o componente Serviços de certificados (clique em Sim para descartar o aviso de renomeação).

  3. Selecione o tipo de CA como Autoridade de Certificação Raiz Autônoma, certificando-se de que a caixa Usar as configurações personalizadas esteja marcada.

  4. Deixe as configurações com os valores padrão na caixa de diálogo Par de Chaves Pública e Particular exceto pelo campo comprimento da chave, que deve ser definido como 4096, e Tipo de provedor de serviços de criptografia, que deve ser definido como Microsoft Strong Cryptographic Provider.

  5. Digite as informações de identificação da CA conforme coletadas na fase de pré-requisitos para os campos a seguir:

    • Nome comum da CA:

    • Sufixo de nome distinto:

    • Período de validade: 8 anos


    Neste momento, o CSP gera o par de chaves, que é gravado no armazenamento de chaves do computador local.

    Observação   Se uma CA tiver sido instalada anteriormente neste sistema, uma caixa de diálogo avisará sobre a substituição da chave particular da instalação anterior. Antes de continuar, verifique se essa chave nunca será necessária novamente.

  6. Mantenha os valores padrão do banco de dados de certificados, dos logs de bancos de dados e da pasta de configuração. Neste momento, o Gerenciador de Componentes Opcionais instalará componentes de Serviços de certificados e a mídia de instalação do Windows Server 2003 será necessária.

  7. Clique em OK para ignorar avisos sobre o IIS e continuar a instalação até sua conclusão.


Configurando as propriedades da CA raiz

Alguns parâmetros específicos de ambiente serão usados para configurar a CA raiz conforme descrito nesta seção. Esses parâmetros devem ter sido coletados conforme descrito anteriormente na seção de informações de pré-requisito deste guia para que seja possível continuar.

Para configurar as propriedades da CA raiz

  1. Faça logon no Servidor CA como membro do grupo local Administrador.

  2. Personalize o script C:\MSSScripts\pkiparams.vbs para incluir o seguinte:

    • Altere o valor da configuração AD_ROOT_DN para que corresponda ao DN do domínio raiz da floresta do Active Directory.

    • Altere a configuração HTTP_PKI_VROOT para que corresponda ao caminho HTTP para o diretório virtual do IIS configurado anteriormente.


  3. Execute o script a seguir:

    Cscript //job:RootCAConfig C:\MSSScripts\ca_setup.wsf
    
    


Configurando funções administrativas

Os grupos de segurança criados anteriormente deverão ser mapeados para funções administrativas, como auditor e gerenciador de certificados, para serem usados.

Observação   Embora a maioria das empresas de médio porte provavelmente use o modelo de delegação simplificado mencionado anteriormente neste guia, o modelo mais flexível é mostrado aqui caso mais separação seja necessária.

Para configurar funções administrativas da CA raiz

  1. Clique em Propriedades no Console de Gerenciamento da CA.

  2. Clique na guia Segurança e adicione os grupos de segurança listados na tabela a seguir, adicionando a permissão mostrada para cada um.

    Tabela 13. Entradas de permissões da CA

    Grupo

    Permissão

    Permitir/Negar

    Administradores de CA

    Gerenciar CA

    Permitir

    Gerenciadores de Certificados

    Emitir e gerenciar certificados

    Permitir

  3. Outras funções de segurança da CA para este servidor já foram definidas através da diretiva de segurança aplicada anteriormente.


Transferindo a CRL e o certificado da CA raiz para o disco

A CRL e o certificado da CA raiz devem ser copiados da CA para que possam ser publicados no Active Directory e no servidor de publicação de CRL e certificados do IIS. Embora este exemplo mencione o uso de um disco, qualquer mídia portátil poderá ser usada, incluindo unidades USB.

Para copiar a CRL e o certificado da CA raiz para o disco

  1. Faça logon na CA raiz como membro do grupo Administradores de CA local e insira a mídia portátil no servidor.

  2. Execute o seguinte script para copiar o certificado da CA para o disco:

    Cscript //job:GetCACerts C:\MSSScripts\CA_Operations.wsf
    
    

  3. Execute o seguinte script para copiar a CRL da CA para o disco:

    Cscript //job:GetCRLs C:\MSSScripts\CA_Operations.wsf
    
    

  4. Etiquete, date e guarde o disco para uso posterior.

Publicando as informações da CA raiz

Antes da instalação da CA de emissão, o certificado da CA raiz deverá ser publicado no armazenamento de raiz confiável do Active Directory, e a CRL de raiz deverá ser publicada no recipiente CDP do Active Directory. Esse processo fará com que todos os membros do domínio importem o certificado da CA raiz para seus próprios armazenamentos de raiz confiável, o que permitirá que eles verifiquem o status de revogação de todos os certificados emitidos pela CA raiz.

É melhor usar a CA de emissão para executar esse procedimento, porque ela tem as bibliotecas necessárias Certutil.exe, certadm.dll e certcli.dll instaladas, mas qualquer servidor membro pode ser usado, desde que os arquivos certutil.exe e as DLLs de suporte estejam instalados naquele sistema baseado em Windows Server 2003.

Para publicar a CRL e o certificado da CA raiz no Active Directory

  1. Faça logon em um computador membro do domínio que atenda aos requisitos anteriores como membro do grupo Administradores de PKI Corporativa e insira o disco criado para armazenar a CRL e o certificado da CA raiz.

  2. Execute o seguinte script para publicar o certificado da CA no Active Directory:

    Cscript //job:PublishCertstoAD C:\MSSScripts\CA_Operations.wsf
    
    

  3. Execute o seguinte script para publicar a CRL no Active Directory:

    Cscript //job:PublishCRLstoAD C:\MSSScript\CA_Operations.wsf
    
    


Publicando a CRL e o certificado da CA raiz no servidor Web

Essa tarefa é necessária porque as versões HTTP das URLs CDP e AIA são especificadas nas extensões dos certificados emitidos por esta CA. Se essas extensões estiverem presentes, deverão ser respeitadas por meio da publicação de CRLs e certificados nas URLs configuradas nelas.

Observação   Esse procedimento não depende de o servidor Web de publicação de CDP e AIA estar na CA de emissão; no entanto, ele pressupõe que o diretório virtual corresponda àquele instalado anteriormente para configurar o IIS (C:\CAWWWPub). Se um caminho diferente tiver sido escolhido, o valor de WWW_LOCAL_PUB_PATH no script PKIParams.vbs deverá ser modificado.

Para publicar a CRL e o certificado da CA raiz na URL da Web

  1. Faça logon no servidor Web como administrador local ou use uma conta equivalente.

  2. Certifique-se de que o disco da CRL e do certificado da CA raiz seja inserido.

  3. Execute o seguinte script para publicar o certificado da CA na pasta do servidor Web:

    Cscript //job:PublishRootCerttoIIS
    C:\MSSScripts\CA_Operations.wsf
    
    

  4. Execute o seguinte script para publicar as CRLs da CA na pasta do servidor Web:

    Cscript //job:PublishRootCRLstoIIS
    C:\MSSScripts\CA_Operations.wsf
    
    

Implantando um servidor de CA de emissão

Agora que a CA raiz foi instalada e seus certificados foram publicados, o servidor da CA de emissão pode ser implantado. Instalar Serviços de certificados envolve um conjunto complexo de interações entre a CA de emissão, a CA raiz, o Active Directory e o servidor Web. Pode ficar mais fácil compreender essas interações usando o diagrama a seguir como referência.


Cc875845.SWCG5(pt-br,TechNet.10).gif

Figura 5. Processo de instalação de certificados

As interações numeradas mostradas neste diagrama são:

  1. Publicar a CRL e o certificado da CA raiz no Active Directory usando mídia removível.

  2. Publicar a CRL e o certificado da CA raiz no servidor Web usando mídia removível.

  3. Instalar o software Serviços de certificados, que gera uma solicitação de certificado que deverá ser entregue à CA raiz usando mídia removível para que um certificado seja emitido com base nessa solicitação.

  4. Instalar o certificado da CA de emissão correspondente usando mídia removível.

  5. Publicar a CRL e o certificado da CA de emissão no servidor Web.


    x.   Esta etapa ocorre automaticamente durante a rotina de instalação da CA Corporativa.

Preparando o arquivo Capolicy.inf para a CA de emissão

Embora um arquivo CAPolicy.inf não seja necessário para a CA de emissão, ele será necessário se o tamanho da chave usada pela CA precisar ser alterado. Esse arquivo deve ser criado antes que a CA de emissão seja configurada, embora seja possível adicioná-lo posteriormente e depois renovar o certificado da CA, se necessário.

Para criar um arquivo CAPolicy.inf

  1. Faça logon no servidor da CA de emissão como Administrador local ou use uma conta equivalente.

  2. Usando um editor de texto, como o Bloco de Notas, crie um arquivo de texto sem formatação com as informações a seguir:

    [Version]
    Signature= “$Windows NT$”
    
    [Certsrv_Server]
    RenewalKeyLength=2048
    
    

  3. Se houver uma CPS definida para esta CA, inclua as linhas abaixo no arquivo Capolicy.inf:

    [CAPolicy]
    Policies=policyname
    
    [policyname]
    OID=the.org.oid
    URL=”http://the.org.url/TheCPSPage.htm”
    
    

    Observação   Os itens em itálico precisarão ser substituídos por informações específicas da organização.

  4. Salve o arquivo como %windir%\Capolicy.inf (substitua %windir% com o caminho absoluto da pasta de instalação do Windows, por exemplo, C:\Windows).


Instalando os componentes do software Serviços de certificados

Como ocorreu na instalação de serviços de certificados na CA raiz, esta etapa também exigirá o uso da mídia de instalação do Windows Server 2003, além do uso do Assistente de Componentes do Windows.

Para instalar os Serviços de certificados

  1. Faça logon na CA de emissão como membro do grupo local Administradores ou equivalente e execute o Gerenciador de Componentes Opcionais:

    sysocmgr /i:sysoc.inf
    
    

  2. Selecione o componente Serviços de certificados e clique em OK para ignorar a caixa de mensagem de aviso de renomeação.

  3. Selecione o tipo de CA como Autoridade de certificação subordinada corporativa, certificando-se de que a caixa Usar as configurações personalizadas esteja marcada.

  4. Mantenha as configurações padrão na caixa de diálogo Par de Chaves Pública e Particular exceto por:

    • Comprimento da chave – 2048 bits

    • Tipo de provedor de serviços de criptografia – Microsoft Strong Cryptographic Provider


  5. Insira as informações de identificação da autoridade de certificação desta maneira:

    • Nome comum da CA

    • Sufixo de nome distinto

    • Período de validade: (como determinado pela CA pai)


  6. Neste momento, o CSP gera o par de chaves e o grava no armazenamento de chaves do computador local.

  7. Insira os locais do banco de dados de certificados, do logs do banco de dados e da configuração como sugerido abaixo:

    • Banco de dados de certificados: D:\CertLog

    • Log do banco de dados de certificados: %windir%\System32\CertLog

    • Pasta compartilhada: Desativado


    O banco de dados e os logs da CA devem ser armazenados em volumes separados fisicamente, se possível, por motivos de desempenho e resiliência. O banco de dados de certificados e os logs dos bancos de dados devem estar em unidades locais formatadas com NTFS.

  8. Neste momento, é gerado um arquivo de solicitação de certificado que deve ser copiado em disco. Em seguida, o Gerenciador de Componentes Opcionais instala os componentes de Serviços de certificados que exigem acesso à mídia de instalação do Windows Server 2003.

  9. Clique em OK para ignorar o aviso sobre o ISS e continuar a instalação até o término. O assistente de instalação exibe um aviso de que é necessário um certificado da CA pai para que seja possível continuar.


Enviando a solicitação de certificado para a CA raiz

Neste momento, a solicitação de certificado da CA de emissão deve ser levada para a CA raiz para que seja assinada e para que um certificado seja emitido para a CA de emissão.

Para enviar a solicitação de certificado para a CA raiz

  1. Faça logon na CA raiz com uma conta de membro do grupo Gerenciadores de Certificados.

  2. Verifique se o disco usado para armazenar o arquivo de solicitação de certificado está na unidade.

  3. No menu Tarefas da CA do console de gerenciamento Autoridade de certificação, selecione Enviar nova solicitação e, em seguida, envie a solicitação transferida da CA de emissão.

  4. Localize o certificado recém-emitido no recipiente Certificados emitidos e abra-o.

  5. Verifique se os detalhes do certificado estão corretos e, em seguida, clique em Copiar para arquivo para exportar o certificado para um arquivo. Salve o arquivo em disco como um arquivo PKCS#7 e selecione a opção de incluir todos os certificados possíveis da cadeia.


Atualizando as informações de certificado na CA de emissão

O certificado da CA raiz já foi publicado no armazenamento de raiz confiável do Active Directory e agora deve-se verificar se a CA de emissão baixou essas informações e colocou o certificado em seu próprio armazenamento de raiz.

Para atualizar e verificar as informações de certificados confiáveis na CA de emissão

  1. Faça logon na CA de emissão como administrador local ou use uma conta equivalente.

  2. Execute o seguinte em um prompt de comando:

    certutil –pulse
    
    

    Esse comando forçará a CA a baixar as novas informações de raiz confiável do diretório e colocar o certificado da CA raiz em seu próprio armazenamento de raiz confiável. Embora esta etapa não seja necessária, ela verifica se as etapas de publicação anteriores tiveram êxito antes de prosseguir.

  3. Execute mmc.exe e adicione o snap-in Certificados.

  4. Selecione Conta de computador como o armazenamento de certificado a ser gerenciado.

  5. Certifique-se de que o certificado da CA raiz esteja na pasta Autoridades de certificação de raiz confiável.


Instalando o certificado na CA de emissão

A resposta assinada da CA raiz foi criada como um pacote de certificado PKCS#7 e agora está pronta para ser instalada na CA de emissão. Para publicar o certificado da CA no armazenamento NTAuth do Active Directory, que identifica a CA como uma CA Corporativa, o certificado da CA deve ser instalado usando-se uma conta que seja membro do grupo Administradores de PKI Corporativa e também do grupo local Administradores na CA de emissão. O primeiro grupo tem direitos para instalar o certificado da CA no diretório, e o segundo para instalar o certificado no servidor CA. Se o modelo de administração simples mencionado anteriormente estiver em uso, a função CAAdmin já será um membro de ambos os grupos.

Para instalar o certificado da CA de emissão

  1. Faça logon na CA de emissão usando uma conta que seja membro do grupo Administradores de PKI Corporativa e do grupo local Administradores.

  2. Insira o disco com o certificado assinado emitido pela CA raiz.

  3. Selecione Instalar certificado no menu Tarefas da CA no console de gerenciamento da Autoridade de certificação para instalar o certificado da CA de emissão a partir do disco.

    Neste momento a CA deve ser inicializada.


Configurando as propriedades da CA de emissão

O procedimento a seguir configura os parâmetros específicos de ambiente coletados durante a seção de pré-requisitos na CA de emissão. Antes de continuar esta etapa, é importante garantir que as informações específicas da organização que foram coletadas nas etapas de pré-requisito foram inseridas no arquivo C:\MSSScripts\pkiparams.vbs na CA raiz e que essas alterações também foram transferidas para a CA de emissão.

Para configurar as propriedades da CA de emissão

  1. Faça logon no servidor CA de emissão como um membro do grupo local Administradores.

  2. Verifique se as alterações feitas ao arquivo C:\MSSScripts\pkiparams.vbs correspondem às configurações específicas de ambiente descritas anteriormente nesta seção.

  3. Execute o script a seguir:

    Cscript //job:IssCAConfig C:\MSSScripts\ca_setup.wsf
    
    


Configurando as funções administrativas da CA de emissão

Para usar as funções administrativas descritas neste guia, elas devem ser mapeadas para grupos de segurança. Como já mencionado, embora as funções simplificadas sejam suficientes para a maioria das empresas de médio porte, este processo implementará as funções detalhadas criadas para um máximo de flexibilidade e separação de responsabilidades.

Para configurar as funções na CA de emissão

  1. Faça logon no servidor CA de emissão como um membro do grupo local Administradores.

  2. Clique em Propriedades no console de gerenciamento Autoridade de certificação para editar as propriedades da CA.

  3. Clique na guia Segurança e adicione os grupos de segurança do domínio listados na tabela a seguir e adicione a permissão mostrada para cada um.

    Tabela 14. Permissões da CA de emissão

    Grupo

    Permissão

    Permitir/Negar

    Administradores de CA

    Gerenciar CA

    Permitir

    Gerenciadores de Certificados

    Emitir e gerenciar certificados

    Permitir

  4. O grupo Auditores de CA deve ser adicionado ao grupo local Administradores, embora esse grupo já tenha sido parcialmente definido por meio da diretiva de segurança aplicada anteriormente.

Publicando as informações da CA de emissão

Embora certificados e CRLs sejam publicados automaticamente da CA de emissão no Active Directory, a publicação do certificado da CA e das CRLs nos caminhos CDP e AIA HTTP não é automática. Para automatizar a publicação do certificado da CA nos caminhos CDP e AIA HTTP, deve haver um trabalho agendado para executar a tarefa.

Certificados de CA são atualizados muito raramente, e assim podem ser publicados no AIA manualmente, por meio do processo descrito a seguir.

Para publicar o certificado da CA de emissão

  1. Faça logon na CA de emissão com uma conta que tenha permissão para gravar na pasta publicada do servidor Web.

  2. Atualize o parâmetro WWW_REMOTE_PUB_PATH do arquivo C:\MSSScripts\PKIParams.vbs para corresponder ao caminho de destino da pasta do servidor Web.

    1. Se o servidor Web estiver em um servidor remoto, certifique-se de que a pasta do servidor Web seja compartilhada e registre o caminho UNC da pasta compartilhada.

    2. Se o servidor Web estiver no mesmo servidor que a CA, registre o caminho local para a pasta. (o padrão é o caminho local C:\CAWWWPub)


  3. Execute o seguinte script para publicar o certificado da CA no servidor Web:

    Cscript //job:PublishIssCertsToIIS 
    C:\MSSScripts\CA_Operations.wsf
    
    

    Observação   Este procedimento foi projetado com servidores Web internos em mente. Se os certificados forem publicados em um servidor Web conectado à Internet, etapas adicionais serão necessárias porque esta solução depende do compartilhamento de arquivos de rede do Windows, que normalmente é bloqueado em firewalls de Internet.


CRLs são publicadas com mais freqüência do que certificados de CA, e assim um método automatizado de publicação no servidor Web torna-se necessário.

Para automatizar a publicação de CRLs

  1. Faça logon na CA de emissão com uma conta que seja membro do grupo local Administradores.

  2. Certifique-se de que a pasta do servidor Web seja acessível a este servidor.

  3. Se o servidor Web for remoto, a CA de emissão exigirá direitos de gravação à pasta do sistema de arquivos (permita acesso Modificar) e ao compartilhamento (permita acesso Alterar). Se o servidor Web remoto for membro da floresta, o grupo Editores de Certificados do domínio deverá ser usado para conceder acesso para garantir que qualquer CA Corporativa possa publicar certificados e CRLs.

  4. Crie um trabalho agendado para copiar as CRLs executando o comando a seguir:

    Observação   Algumas partes do trecho de código a seguir foram exibidas em várias linhas somente para facilitar a leitura. Elas devem ser inseridas como uma única linha.

    schtasks /creat /tn “Publish CRLs” /tr “cscript.exe //job:PublishIssCRLsToIIS C:\
    MSSScripts\CA_Operations.wsf” /sc Hourly /ru “System”
    
    


Removendo modelos não desejados da CA de emissão

Normalmente, a melhor prática é remover modelos que correspondam a qualquer tipo de certificado que não será usado, para evitar que sejam emitidos acidentalmente. Esses modelos podem ser recriados facilmente se necessário, já que sempre estão disponíveis no diretório.

Para remover modelos não desejados da CA de emissão

  1. Faça logon como membro do grupo do domínio Administradores de CA.

  2. Selecione o recipiente Modelos de certificado no console de gerenciamento Autoridade de certificação.

  3. Remova os seguintes tipos de modelos:

    • Agente de Recuperação EFS

    • EFS Básico

    • Servidor Web

    • Computador

    • Usuário

    • Autoridade de Certificação Subordinada

    • Administrador



Autenticação da Internet

Esta seção fornece informações detalhadas que ajudarão na implementação de uma infra-estrutura RADIUS para dar suporte à solução de WLAN segura fornecida por este guia. A infra-estrutura RADIUS implementada neste guia baseia-se nos servidores IAS do Windows Server 2003.

Projeto da infra-estrutura RADIUS

As tabelas a seguir podem ser usadas como planilhas para coletar as informações de pré-requisito que serão mencionadas em todo o guia. Algumas dessas informações são definidas usando-se scripts fornecidos com esta orientação ou manualmente, como listado nas seções apropriadas quando aplicável.

Pré-requisitos de informações de configuração definidas pelo usuário

A tabela a seguir lista informações que são específicas de cada organização. Certifique-se de que as informações sejam coletadas, escolhidas e registradas antes de prosseguir.

Tabela 15. Configurações definidas pelo usuário

Item de configuração

Configuração

Nome DNS do domínio raiz da floresta do Active Directory


Nome NetBIOS do domínio


Nome do servidor IAS primário


Nome do servidor IAS secundário


Pré-requisitos de informações de configuração definidas pela solução

A tabela a seguir lista configurações que não precisam ser alteradas a menos que haja uma necessidade específica para isso. Certifique-se de que as implicações e dependências causadas por quaisquer alterações sejam completamente compreendidas e planejadas antes de alterar qualquer um desses parâmetros, incluindo alterações de script que possam ser necessárias.

Tabela 16. Configurações definidas pela solução

Item de configuração

Configuração

Nome completo do grupo administrativo que controla a configuração do IAS

Administradores de IAS

Nome completo do grupo que analisa os logs de autenticação do IAS e de solicitações de estatísticas

Auditores de Segurança do IAS

Caminho para scripts de instalação

C:\MSSScripts

Arquivo de lote de exportação da configuração do IAS

IASExport.bat

Arquivo de lote de importação da configuração do IAS

IASImport.bat

Arquivo de lote de exportação da configuração do cliente RADIUS do IAS

IASClientExport.bat

Arquivo de lote de importação da configuração do cliente RADIUS do IAS

IASClientImport.bat

Caminho para arquivos de backup de configuração

D:\IASConfig

Local dos logs de solicitações de autenticação e auditoria do IAS

D:\IASLogs

Nome do compartilhamento dos logs de solicitações RADIUS

IASLogs

Implantação do servidor IAS

A solução detalhada em seções subseqüentes inclui dois servidores IAS localizados centralmente configurados como servidores RADIUS para controle do acesso a WLAN. Com isso em mente, as tarefas a seguir devem ser concluídas para que seja possível prosseguir.

  • O hardware do servidor deve ser alocado e configurado.

  • O sistema operacional do servidor deve ser instalado e configurado de acordo com os procedimentos estabelecidos na organização.

  • O Active Directory deve estar instalado e funcionando normalmente.

  • Os procedimentos de proteção de servidor da organização e os aplicativos adicionais exigidos por diretivas estabelecidas devem estar prontos.


Instalando os scripts de configuração

Foram fornecidos diversos scripts de suporte com esta solução para ajudar a simplificar sua implementação. Esses scripts devem ser instalados em cada servidor para que seja possível continuar, e nunca devem ser excluídos, mesmo após a conclusão das etapas descritas neste guia.

Para instalar os scripts de configuração

  1. Crie uma pasta chamada C:\MSSScripts

  2. Copie os scripts da origem de distribuição para a pasta criada acima.


Requisitos adicionais de software do servidor

Além do sistema operacional do servidor e de quaisquer outros aplicativos que possam ser exigidos por uma diretiva de construção de servidor estabelecida, o executável CAPICOM 2.1 e a biblioteca DLL de suporte devem ser instalados para dar suporte aos scripts fornecidos por este guia.

Para obter mais informações sobre CAPICOM, incluindo o local de download e instruções de instalação, visite http://www.microsoft.com/downloads/details.aspx?displaylang=pt-br&FamilyID=860ee43a-a843-462f-abb5-ff88ea5896f6.

Configurando grupos de administração do IAS

O comando de script a seguir criará os grupos de segurança Administradores de IAS e Auditores de Segurança do IAS:

Cscript //job:CreateIASGroups C:\MSSScripts\IAS_Tools.wsf


Em ambientes de vários domínios esses grupos deverão ser criados no mesmo domínio em que os servidores IAS residirão.

Após os grupos necessários terem sido criados, eles deverão ser configurados para executar tarefas de configuração do IAS desta forma:

  • Adicione o grupo global de domínio Administradores de IAS ao grupo local Administradores em cada servidor IAS.

  • Se o IAS estiver instalado em controladores de domínio, o grupo Administradores de IAS deverá ser adicionado ao grupo Administradores do domínio.

  • Os grupos Administradores de IAS e Auditores de Segurança de IAS devem ser preenchidos com as contas de usuários apropriadas.


Definindo configurações de segurança do sistema do servidor

Como já mencionado, este guia pressupõe que a maioria das empresas de médio porte estabeleceu diretivas e procedimentos de proteção de servidor. Por esse motivo, não há instruções detalhadas sobre o processo de proteção de servidores exigido por esta solução. Se não houver diretivas ou procedimentos estabelecidos para a proteção de servidor, ou se mais informações sobre a proteção de servidores IAS forem necessárias, consulte o Guia de Segurança do Windows 2003 em http://go.microsoft.com/fwlink/?LinkId=14846.

Instalando e configurando o IAS

A seção a seguir descreve como instalar o IAS em servidores. É importante que cada etapa de instalação e configuração seja executada como listado em cada servidor IAS.

O IAS é instalado selecionando-se o componente Serviços de rede – Serviço de autenticação da Internet no Gerenciador de Componentes Opcionais do Windows (acessível pelo item Adicionar ou remover componentes no Painel de controle). Para simplificar esse processo, use o seguinte script:

sysocmgr /i:sysoc.inf /u:C:\MSSScripts\OC_AddIAS.txt


Registrando o IAS no Active Directory

Para registrar os servidores IAS em cada domínio, torne a conta de computador de cada servidor IAS um membro do grupo de segurança Servidores RAS e IAS dentro de cada domínio em que serão necessários para autenticação. A participação nesses grupos garante que os servidores IAS tenham permissão para ler as propriedades de acesso remoto de todas as contas de usuário e computador nos domínios.

Para registrar o IAS no Active Directory

  1. Faça logon em cada servidor com uma conta que tenha privilégio de Admins. do Domínio para os domínios onde o servidor IAS precise ser registrado.

  2. Para o domínio padrão, execute o seguinte em um prompt de comando:

    netsh ras add registeredserver
    
    

  3. Para domínios diferentes do padrão, execute o seguinte em um prompt de comando:

    netsh ras add registeredserver domain = DomainName
    
    

    Observação   Como alternativa, o objeto de computador do servidor IAS pode ser adicionado ao grupo de segurança Servidores RAS e IAS usando-se o snap-in Usuários e Computadores do Active Directory do MMC.


Criando e protegendo diretórios de dados do IAS

Existem alguns requisitos de diretório para armazenar dados de configuração e log em servidores IAS. Para facilitar o processo de configuração para criar e proteger esses diretórios, o seguinte arquivo de lote pode ser usado no prompt de comando:

C:\MSSScripts\IAS_Data.bat


Observação   Pode ser necessário editar e substituir as entradas %DomainName% para refletir o nome de domínio NETBIOS do ambiente específico neste arquivo de lote antes de executá-lo.

Configurando o servidor IAS primário

O servidor escolhido para funcionar como o servidor IAS primário deverá ser configurado antes de qualquer outro servidor IAS do ambiente, porque ele funcionará como modelo para definir as configurações em todos os servidores IAS subseqüentes.

Registrando em log as solicitações de autenticação e estatísticas

Por padrão, o IAS registra em log as solicitações de autenticação e estatísticas do RADIUS, mas ambas devem estar ativadas para garantir que os eventos de segurança sejam registrados e possam ser usados caso uma investigação seja necessária.

Para configurar o registro em log de solicitações de autenticação e estatísticas

  1. Selecione Log de acesso remoto no snap-in MMC do IAS e exiba as propriedades do método de registro Arquivo local.

  2. Selecione Solicitações de estatísticas e Solicitações de autenticação.

  3. Certifique-se de que o diretório do arquivo de log seja definido como D:\IASLogs e que o formato Compatível com banco de dados seja selecionado. (isso permite que os logs sejam importados diretamente para bancos de dados como Microsoft SQL Server™).


Autenticação WLAN 802.1X

Esta seção descreve o processo de implementação da segurança de WLAN com a especificação do protocolo 802.1X como baseado em plataformas Windows Server 2003 e Windows XP SP1. Estas instruções incluem informações relacionadas à configuração de grupos do Active Directory, implantação de certificados X.509, modificação de configurações do servidor IAS e implantação da Diretiva de grupo de WLAN, além de algumas dicas de configuração de pontos de acesso sem fio para suporte à implementação de EAP-TLS 802.1X na qual se baseia este guia.

Preparando o ambiente para uma WLAN segura

Agora que as infra-estruturas subjacentes de certificados e RADIUS estão prontas, as etapas de configuração reais específicas do 802.1X podem ser implementadas. As tabelas de configurações de pré-requisito a seguir podem ajudar no processo de coleta de informações que deve ocorrer antes da implementação real. Algumas dessas configurações são ativadas manualmente e outras fazem parte dos scripts fornecidos com este guia.

Pré-requisitos de configurações definidas pelo usuário

A tabela a seguir lista parâmetros específicos da organização que devem ser coletados ou definidos para que seja possível prosseguir com esta fase da implementação de WLAN segura. O espaço fornecido pode ser usado para registrar as configurações necessárias para cada ambiente específico.

Tabela 17. Pré-requisitos de configurações definidas pelo usuário

Item de configuração

Configuração

Nome DNS do domínio raiz da floresta do Active Directory


Nome de domínio NetBIOS


Nome do servidor IAS primário


Nome do servidor IAS secundário


Pré-requisitos de configurações definidas pela solução

A tabela a seguir lista configurações que não precisam ser alteradas a menos que haja uma necessidade específica para isso. Certifique-se de que as implicações e dependências causadas por quaisquer alterações sejam completamente compreendidas e planejadas antes de alterar qualquer um desses parâmetros, incluindo alterações de script que possam ser necessárias.

Tabela 18. Configurações definidas pela solução

Item de configuração

Configuração

Grupo global do Active Directory que controla a implantação dos certificados de autenticação de usuário 802.1X

Registro Automático de Autenticação de Cliente – Certificado de Usuário

Grupo global do Active Directory que controla a implantação dos certificados de autenticação de computador 802.1X

Registro Automático de Autenticação de Cliente – Certificado de Computador

Grupo global do Active Directory com servidores IAS que exigem certificados de autenticação 802.1X

Registro Automático de Certificado de Autenticação do Servidor IAS e RAS

Grupo global do Active Directory que contém usuários com permissão de acesso à rede sem fio

Diretiva de Acesso Remoto - Usuários sem Fio

Grupo global do Active Directory que contém computadores com permissão de acesso à rede sem fio

Diretiva de Acesso Remoto - Computadores sem Fio

Grupo universal do Active Directory que contém o grupo Usuários sem Fio e o grupo Computadores sem Fio

Diretiva de Acesso Remoto – Acesso sem Fio

Grupo global do Active Directory com computadores que exigem configuração das propriedades de rede sem fio

Diretiva de Rede sem Fio - Computador

Modelo de certificado usado para gerar certificados para a autenticação de cliente do usuário

Autenticação de cliente - Usuário

Modelo de certificado usado para gerar certificados para a autenticação de cliente do computador

Autenticação de cliente - Computador

Modelo de certificado usado para gerar certificados para a autenticação de servidor para IAS

Autenticação do Servidor IAS e RAS

Caminho para scripts de instalação

C:\MSSScripts

Caminho para arquivos de backup de configuração

D:\IASConfig

Caminho para logs de autenticação e auditoria do IAS

D:\IASLogs

Nome da diretiva

Permitir acesso sem fio

Nome do GPO do Active Directory

Diretiva de rede sem fio

Diretiva de rede sem fio dentro do GPO acima

Configuração sem fio para computador cliente

Criando os grupos do Active Directory necessários para acesso a WLAN

O script a seguir deve ser executado com uma conta que tenha permissão para criar grupos de segurança do Active Directory porque ele cria os grupos necessários para implementar o registro de certificados de autenticação sem fio, a diretiva de acesso remoto e a Diretiva de grupo de rede sem fio:

Cscript //job:CreateWirelessGroups C:\MSSScripts\wl_tools.wsf


Observação   Para ambientes de floresta com vários domínios, esses grupos devem ser criados no mesmo domínio que os usuários sem fio.

Verificando configurações de DHCP

Para acomodar redes sem fio, os servidores DHCP devem ser configurados com escopos específicos de redes sem fio e tempos de concessão de endereço IP menores do que as de outros clientes cabeados. Consulte os administradores dos servidores DHCP para garantir que o DHCP tenha sido configurado corretamente. Para obter mais informações sobre o planejamento de DHCP para LANs sem fio, consulte o Windows Server 2003 Deployment Kit em www.microsoft.com/windowsserver2003/techinfo/reskit/deploykit.mspx.

Configurando certificados de autenticação de WLAN

Para implementar a segurança de WLAN baseada em EAP-TLS conforme detalhado neste guia, é necessário criar e implantar os seguintes tipos de certificado:

  • Autenticação de cliente - Computador

  • Autenticação de cliente - Usuário

  • Autenticação do Servidor IAS e RAS


Criando um modelo de certificado para autenticação de servidor IAS

Servidores IAS exigem um certificado de servidor para autenticar computadores para clientes durante o handshake do protocolo EAP-TLS. O administrador de Serviços de certificados deve executar as etapas a seguir para criar um modelo de certificado de autenticação de servidor para uso pelos servidores IAS.

Para criar um modelo de certificado para autenticação de servidor

  1. Faça logon na CA de emissão com uma conta de grupo administrativo de CA e execute o MMC Modelos de certificados.

  2. Duplique o modelo de certificado de Servidor RAS e IAS. Na guia Geral das propriedades do novo modelo, no campo Nome para exibição do modelo, digite Autenticação do servidor RAS e IAS.

  3. Na guia Extensões, verifique se as diretivas de emissão incluem apenas Autenticação do servidor (OID 1.3.6.1.5.5.7.3.1).

  4. Ainda na guia Extensões, edite as diretivas de emissão para adicionar a diretiva Média garantia.

  5. Na guia Nome do assunto, selecione Criar com base nas informações do Active Directory. Além disso, verifique se Formato de nome de entidade está definido como Nome comum e se somente Nome DNS está selecionado em Incluir esta informação no Nome alternativo para a entidade.

  6. Na guia Tratamento da solicitação, clique no botão CSPs, verifique se Um dos seguintes provedores está selecionado e se somente Microsoft RSA SChannel Cryptographic Provider está selecionado.

  7. Na guia Segurança, adicione o grupo de segurança Registro Automático de Certificado de Autenticação do Servidor IAS e RAS com permissões Ler, Registro ou Registro Automático e remova quaisquer outros grupos que possam ter permissões para registrar ou registrar automaticamente este modelo de certificado.

    Observação   Pode ser vantajoso definir este certificado para que exija a aprovação do Gerenciador de Certificados porque considera-se que ele tenha um valor de segurança relativamente alto. Ativar esse valor ajuda a garantir que um servidor IAS mal-intencionado não seja registrado, mas exigirá a aprovação manual depois que os certificados forem emitidos e enviados automaticamente pelo servidor IAS.


Criando um modelo de certificado para autenticação de usuário

Os usuários finais precisam ter certificados de usuário para serem autenticados no servidor IAS durante o processo de handshake do EAP-TLS. Mais uma vez, as etapas a seguir devem ser executadas pelo titular da conta indicado como um administrador de Serviços de certificados.

Para criar um modelo de certificado de autenticação de usuário

  1. Inicie o snap-in do MMC Modelos de certificado no servidor CA de emissão.

  2. Duplique o modelo Sessão autenticada, na guia Geral do novo modelo, no campo Nome para exibição do modelo, digite Autenticação do cliente – Usuário.

  3. Na guia Tratamento de solicitação, selecione CSPs e desmarque as caixas de seleção Provedor de Criptografia Microsoft Base DSS.

  4. Na guia Nome do assunto, verifique se Criar com base nas informações do Active Directory está selecionado. Em Formato de nome de entidade, selecione Nome comum. Certifique-se de que Nome principal do usuário (UPN) seja a única opção selecionada em Incluir esta informação no nome de entidade alternativo.

  5. Na guia Extensões, verifique se somente Autenticação de cliente (OID 1.3.6.1.5.5.7.3.2) está incluído em Diretivas de aplicativo. Edite também as diretivas de emissão e adicione a diretiva Baixa garantia.

  6. Na guia Segurança, adicione o grupo de segurança Registro Automático de Autenticação de Cliente – Certificado de Usuário com permissões para Leitura, Registro e Registro Automático. Além disso, qualquer outro grupo com permissões de registro ou registro automático deve ser removido.


Criando um modelo de certificado para autenticação de computador

Este certificado é usado por computadores na autenticação do servidor IAS durante o handshake do EAP-TLS. Mais uma vez, o administrador de Serviços de certificados deve executar as tarefas a seguir.

Para criar um modelo de certificado de autenticação de computador

  1. Inicie o snap-in do MMC Modelos de certificado na CA de emissão.

  2. Duplique o modelo Autenticação de Estação de Trabalho. Na guia Geral do novo modelo, no campo Nome para exibição do modelo, digite Autenticação de cliente - Computador.

  3. Na guia Nome do assunto, verifique se Criar com base nas informações do Active Directory está selecionado. Em Formato de nome de entidade, selecione Nome comum. Certifique-se de que Nome DNS seja a única opção selecionada em Incluir esta informação no nome de entidade alternativo.

  4. Na guia Extensões, edite as diretivas de aplicativo e verifique se somente Autenticação de cliente (OID 1.3.6.1.5.5.7.3.2) está incluído. Edite também as diretivas de Emissão e adicione a diretiva Baixa garantia.

  5. Na guia Segurança, adicione o grupo de segurança Registro Automático de Autenticação de Cliente – Certificado de Computador com permissões para Leitura, Registro e Registro Automático. Quaisquer outros grupos com permissões devem ser removidos.


Adicionando certificados de autenticação de WLAN à CA

Agora que os modelos de certificado foram configurados, eles devem ser adicionados à CA para ativar o registro. Para isso, o administrador de Serviços de certificados deverá executar as seguintes tarefas.

Para adicionar modelos de certificado à CA

  • Na CA de emissão, inicialize o snap-in do MMC Autoridade de Certificação e clique com o botão direito na pasta Modelos de certificado, clique em Novo e clique em Modelo de certificado a ser emitido. Selecione os seguintes certificados e clique em OK:

    • Autenticação de cliente - Computador

    • Autenticação de cliente - Usuário

    • Autenticação do Servidor IAS e RAS



Registrando o certificado de servidor IAS

A implantação de certificados de autenticação de servidor nos servidores IAS é relativamente simples e automática.

Para registrar um servidor IAS

  1. Inicialize o snap-in Usuários e Computadores do Active Directory do MMC para adicionar contas de computador do IAS ao grupo de segurança Certificado de Autenticação de Servidor RAS e IAS de Registro Automático.

  2. Reinicie o servidor IAS e faça logon como membro do grupo local Administradores.

  3. Em um prompt de comando, GPUPDATE /force

  4. Abra o MMC e adicione o snap-in Certificados. Quando solicitado, selecione a opção Conta do computador e depois selecione Computador local.

  5. Selecione Certificados (Computador local) na árvore do console, selecione Todas as Tarefas no menu Ação e clique em Registrar certificados automaticamente.

    Observação   Se a opção de exigir a aprovação do Gerenciador de Certificados tiver sido ativada, o administrador da CA precisará verificar a validade dessa solicitação e emitir o certificado.


Adicionando usuários e computadores a grupos de registro automático

Usuários e computadores que precisem de conectividade de WLAN precisarão de certificados de usuário e computador para que possam se autenticar e acessar a rede por meio de uma conexão sem fio. O processo de emitir e renovar esses certificados é transparente para o usuário final, devido aos grupos de registro automático que foram configurados anteriormente.

Para adicionar usuários e seus computadores aos grupos de registro automático, basta usar o snap-in Usuários e Computadores do Active Directory do MMC para adicionar as contas de usuário ao grupo Registro Automático de Autenticação de Cliente – Certificado de Usuário e adicionar seus computadores ao grupo Registro Automático de Autenticação de Cliente – Certificado de Computador. Quando isso tiver sido feito, esses usuários receberão seus certificados de usuário e computador depois de reiniciarem seus computadores e fazerem logon na rede novamente.

Observação   Esta solução usa grupos personalizados para controlar quais usuários e computadores podem receber certificados. Se o ambiente exigir que todos os usuários e computadores usem certificados, basta adicionar Usuários do domínio ao grupo Registro Automático de Autenticação de Cliente – Certificado de Usuário e Computadores do domínio ao grupo Autenticação de Cliente de Registro Automático - Certificado de Computador.

Configurando a infra-estrutura de acesso a WLAN

O servidor IAS primário deve ser configurado com uma diretiva de acesso remoto e configurações de solicitação de conexão que determinem a autenticação e a autorização de clientes sem fio para a WLAN. Essas configurações devem ser duplicadas em outros servidores IAS e então cada servidor IAS deve ser configurado de forma exclusiva para aceitar conexões de clientes RADIUS, como pontos de acesso sem fio. Depois disso, os próprios pontos de acesso sem fio devem ser configurados para usar o servidor IAS como origem de autenticação e autorização para a rede sem fio 802.1X.

Criando uma diretiva de acesso remoto a IAS para WLANs

Use the snap-in Serviço de Autenticação da Internet do MMC no servidor IAS primário para configurar o IAS com uma diretiva de acesso remoto da forma descrita a seguir.

Para criar uma diretiva de acesso remoto

  1. Clique com o botão direito do mouse na pasta Diretivas de acesso remoto e clique em Criar nova diretiva de acesso remoto.

  2. Dê à nova diretiva o nome Permitir acesso sem fio e instrua o assistente a configurar Uma diretiva típica para uma situação comum.

  3. Escolha Sem fio como método de acesso.

  4. Conceda acesso com base em grupos e use o grupo de segurança Diretiva de Acesso Remoto - Acesso sem Fio.

  5. Escolha o tipo Smart Card ou outro certificado como tipo de EAP e selecione o certificado de autenticação de servidor instalado para o IAS.

  6. Conclua e saia do assistente.

  7. Abra as propriedades da diretiva Permitir acesso sem fio e clique em Editar perfil.

  8. Na guia Avançado, adicione o atributo Ignore-User-Dialin-Properties, defina-o como True e depois adicione o atributo Termination-Action e defina-o como RADIUS Request.

    Observação   A diretiva Permitir acesso sem fio pode co-existir com outras diretivas criadas pelo usuário ou com diretivas de acesso padrão, mas a diretiva de acesso remoto padrão deve ser listada após a diretiva Permitir acesso sem fio na pasta Diretivas de acesso remoto para funcionar corretamente.


Adicionando clientes RADIUS ao IAS

Pontos de acesso sem fio e proxies RADIUS devem ser adicionados ao IAS como clientes RADIUS para que possam usar serviços de autenticação e estatística por meio do protocolo RADIUS.

Para adicionar clientes RADIUS ao IAS

  1. Inicie o snap-in Servidor de Autenticação da Internet do MMC.

  2. Clique com o botão direito do mouse na pasta Clientes RADIUS e clique em Novo cliente RADIUS.

  3. Digite o nome amigável e endereço IP do ponto de acesso sem fio.

  4. Selecione Padrão RADIUS como o atributo cliente-fornecedor e insira o segredo compartilhado para este ponto de acesso sem fio específico. Depois selecione o atributo A solicitação deve conter o atributo de autenticador de mensagem.

    Observação   Este processo deve ser repetido em cada servidor IAS para garantir que cada servidor tenha um conjunto exclusivo de Clientes e Segredos compartilhados de pontos de acesso sem fio. Para facilitar esse processo, este guia contém um script que pode ser usado para gerar segredos compartilhados que podem ser armazenados em local seguro caso seja necessária uma restauração do sistema. Para usar esse script, execute o seguinte em um prompt de comando:

    Cscript //job:GenPWD C:\MSSScripts\wl_tools.wsf /client:ClientName
    
    

Implantando configurações em vários servidores IAS

Depois que os itens a seguir estiverem configurados no servidor IAS primário, eles poderão ser exportados para arquivos de texto usando-se o comando netsh. Depois de exportados, esses arquivos de texto podem ser importados para cada servidor IAS que tenha uma função semelhante no ambiente, o que garante que exista uma configuração comum em todo o ambiente.

As configurações que podem ser exportadas incluem:

  • Configurações do servidor

  • Configuração de log

  • Diretivas de acesso remoto

  • Clientes RADIUS

  • Configuração completa


Cada servidor IAS deve conter sua própria lista exclusiva de clientes e segredos compartilhados do RADIUS, e assim essas informações devem ser configuradas individualmente em cada servidor e devem ter backup separado. Além disso, um despejo da configuração completa contém informações confidenciais que devem ser muito bem protegidas, pois podem ser usadas para oferecer acesso à rede sem fio caso sejam roubadas.

Exportando a configuração do servidor IAS primário

Os tipos a seguir de configuração devem ser exportados para arquivos de texto para duplicação em outros servidores IAS.

  • Configuração do servidor

  • Configurações de log

  • Diretiva de acesso remoto

  • Diretivas de solicitação de conexão


Para facilitar esse processo, este guia é fornecido com arquivos de lote que contêm os comandos netsh, que podem exportar as informações de configuração comuns para arquivos de texto no diretório D:\IASConfig emitindo-se o seguinte em um prompt de comando.

C:\MSSScripts\IASExport.bat


Importando informações de configuração do servidor IAS primário

Como já mencionado, o IAS usa o comando netsh para transferir estados de configuração entre servidores. Esse processo torna a implantação mais eficaz, enquanto reduz as chances de erro durante o processo de configuração. Agora que as informações de configuração do servidor IAS primário foram exportadas, os servidores IAS secundários podem importar o estado de configuração.

Para importar o estado de configuração do IAS primário para outros servidores IAS

  1. Copie todos os arquivos de configuração da pasta D:\ConfigIAS no servidor IAS primário para a pasta D:\ConfigIAS correspondente nos outros servidores IAS.

  2. Use o seguinte arquivo de lote (incluído neste guia) em uma linha de comando nos servidores secundários para importar o estado de configuração:

    C:\MSSScripts\IASImport.bat
    
    


Clientes e pontos de acesso sem fio

O procedimento de configuração de pontos de acesso sem fio pode variar muito, dependendo da marca e modelo do dispositivo. Entretanto, em geral os fornecedores de pontos de acesso sem fio fornecem instruções detalhadas para a configuração de dispositivos com os seguintes detalhes necessários:

  • Configurações de rede 802.1X

  • Configurando o endereço do servidor RADIUS primário

  • Configurando o endereço do servidor RADIUS secundário

  • Segredo compartilhado do RADIUS com o servidor RADIUS primário

  • Segredo compartilhado do RADIUS com o servidor RADIUS secundário


Para obter instruções de configuração de uma marca ou modelo específico de equipamento sem fio, consulte as instruções do fornecedor ou seu site de suporte.

Implantando certificados de autenticação de WLAN

Esta seção descreve algumas tarefas de configuração importantes necessárias para ativar o registro automático de certificados para clientes baseados em Windows XP. Embora seções anteriores tenham tratado da ativação de diretivas e modelos para dar suporte ao registro automático de certificados na infra-estrutura de certificados, o suporte do Windows XP para essa funcionalidade está desativado por padrão. Para ativar o suporte ao registro automático de certificados, as configurações corretas devem ser configuradas usando-se Diretiva de grupo. Ao usar-se grupos de segurança para controlar o registro automático, esse recurso pode ser ativado para todos os usuários e computadores de um domínio, e os grupos de segurança podem determinar quem recebe os certificados de cada tipo.

Para ativar o registro automático para todos os usuários e computadores em um domínio

  1. Faça logon com uma conta que tenha permissões para criar GPOs e vincule os GPOs ao domínio.

  2. Em Usuários e Computadores no Active Directory, selecione e clique com o botão direito do mouse no objeto de domínio e então clique em Propriedades.

  3. Na guia Diretiva de grupo, clique em Novo e então digite um nome para o GPO (por exemplo, Diretivas de PKI do domínio).

  4. Clique em Editar e vá até Diretivas de chave pública sob Configuração do Computador\Configurações do Windows\Configurações de Segurança.

  5. No painel Detalhes, clique duas vezes em Configurações de registro automático.

  6. Certifique-se de que os seguintes itens estejam selecionados:

    • Registrar certificados automaticamente

    • Renovar certificados expirados, Atualizar certificados pendentes e Remover certificados revogados

    • Atualizar certificados que usam modelos de certificado


  7. Repita as etapas 5 e 6 para Configurações de registro automático do usuário em Configurações do Usuário\Configurações do Windows\Configurações de Segurança\Diretivas de Chave Pública

  8. Feche o GPO

  9. Certifique-se de que o GPO tenha prioridade maior que o GPO da Diretiva padrão do domínio.

  10. Repita esse processo para cada domínio em que o registro automático de certificado esteja ativado, no caso de uma floresta com vários domínios.

    Observação   Se os usuários não usarem perfis móveis e o registro automático estiver universalmente permitido, os certificados serão emitidos para os usuários para todos os computadores nos quais façam logon. Isso pode não ser adequado se usuários administrativos fizerem logon em servidores. Para impedir isso, é recomendado que um GPO seja criado para os servidores para desativar o registro automático. Além disso, se for desvantajoso ativar o registro automático para todos os usuários, um GPO poderá ser vinculado a UOs que contenham o subconjunto de usuários que precisam de registro automático.

Ativando o acesso a WLAN para usuários e computadores

As etapas finais para ativar usuários e computadores para acesso seguro à WLAN inclui ações devem ser executadas em objetos do Active Directory. Essas ações incluem modificar permissões de contas e permissões de grupos e implementar configurações da Diretiva de grupo para a WLAN.

Adicionando usuários a grupos de diretiva de acesso remoto

A diretiva de acesso remoto do IAS usa grupos de segurança baseados no Active Directory para determinar se os usuários e os computadores estão autorizados a estabelecer conexões à WLAN. Esses grupos de segurança criados em seções anteriores incluem:

  • Diretiva de Acesso Remoto - Usuários sem Fio

  • Diretiva de Acesso Remoto - Computadores sem Fio

  • Diretiva de Acesso Remoto – Acesso sem Fio


Para adicionar usuários e computadores aos grupos de acesso à WLAN

  1. Abra o snap-in Usuários e Computadores do Active Directory do MMC.

  2. Adicione o grupo Diretiva de Acesso Remoto - Usuários sem Fio e o grupo Diretiva de Acesso Remoto - Computadores sem Fio ao grupo Diretiva de Acesso Remoto – Acesso sem Fio.

  3. Adicione os usuários com permissão de acesso à WLAN ao grupo Diretiva de Acesso Remoto - Usuários sem Fio.

  4. Adicione os computadores com permissão de acesso à WLAN ao grupo Diretiva de Acesso Remoto - Computadores sem Fio.

    Observação   Se for decidido que é preferível permitir que todos os usuários e computadores acessem a WLAN por padrão, os grupos Usuários do domínio e Computadores do domínio poderão ser adicionados aos seus grupos de diretiva correspondentes para simplificar a administração.


Criando a diretiva de grupo WLAN do Active Directory

A Diretiva de grupo pode ser usada para automatizar e aplicar as configurações de WLAN do computador cliente, já que o MMC Diretiva de grupo no Windows Server 2003 contém configurações Diretiva de rede sem fio que se relacionam aos padrões 802.1X e 802.11.

Para criar uma Diretiva de grupo de rede sem fio

  1. Abra o snap-in Usuários e Computadores do Active Directory do MMC em um servidor ou estação de trabalho baseado em Windows Server 2003 com as ferramentas de Administração do Windows Server 2003 instaladas.

  2. Selecione as propriedades do objeto de domínio e, na guia Diretiva de grupo, clique em Novo e dê o nome de Diretiva de rede sem fio ao GPO.

  3. Clique no botão Propriedades e, na guia Segurança, conceda permissões Leitura e Aplicar diretiva de grupo ao grupo de segurança Diretiva de Rede sem Fio - Computador. Além disso, remova permissões Aplicar diretiva de grupo dos Usuários autenticados no GPO.

  4. Na guia Geral, selecione Desativar configurações do usuário no objeto de diretiva e selecione Sim para qualquer mensagem de aviso que seja exibida. Aplique as alterações e feche a janela.

  5. Clique no botão Editar e navegue até \Configuração do Computador\Configurações do Windows\Configurações de Segurança\Diretivas de Rede sem Fio (IEEE 802.11).

  6. Selecione o objeto Diretivas de rede sem fio (IEEE 802.11) no painel de navegação e selecione Criar diretiva de rede sem fio no menu Ação. Use o assistente para nomear a diretiva Configuração sem fio para computador cliente. Deixe a opção Editar propriedades selecionada e clique em Concluir para fechar o assistente.

  7. Na diretiva Configuração sem fio para computador cliente, na guia Redes preferenciais, selecione Adicionar e digite o Nome de rede ou SSID (identificador de conjunto de serviços) da rede sem fio.

  8. Clique na guia IEEE 802.1x e abra as configurações para o Tipo de EAP Smartcard ou outro certificado. Em Autoridades de certificação de raiz confiável, selecione o certificado da CA raiz para a PKI que emitiu os certificados de servidor do IAS.

  9. Feche as propriedades de Configuração de rede sem fio de computador cliente e o Editor de objeto de diretiva de grupo.

    Observação   Atualmente WPA2 não é aplicável usando-se GPO. No entanto, prevê-se o suporte de GPO para WPA2 com o lançamento do Windows Vista e Longhorn e são planejadas atualizações para tratar a questão também nos lançamentos atuais do Windows.


Adicionando computadores a grupos de segurança para a Diretiva de grupo da WLAN

Os grupos de segurança com base no Active Directory são usados para determinar que computadores têm diretivas de Rede sem fio aplicadas para definir automaticamente configurações necessárias de 802.11 e 802.1X. Essas configurações devem ser implantadas antes de definir-se as configurações de 802.1X em quaisquer pontos de acesso sem fio e de ativar-se a WLAN. Essa abordagem garante que os computadores clientes tenham uma oportunidade adequada de baixar e aplicar a Diretiva de grupo com base no computador, mesmo que só se conectem ocasionalmente à rede cabeada.

As configurações de Diretiva de grupo podem até ser aplicadas antes da instalação de uma placa de rede (NIC) WLAN porque ela irá recuperar e aplicar automaticamente as configurações corretas de Diretiva de grupo de rede sem fio.

Para adicionar computadores aos grupos da Diretiva de grupo de rede sem fio, use o snap-in Usuários e Computadores do Active Directory do MMC para adicionar os objetos de computador autorizados para o grupo Diretiva de Rede sem Fio - Computador.

Observação   As configurações do GPO de Rede sem fio serão atualizadas nos computadores clientes durante o próximo intervalo de atualização da Diretiva de grupo. Para forçar uma atualização, basta emitir o comando GPUPDATE /force.

Requisitos de cliente de WPA2

A solução descrita neste guia foi criada para computadores clientes ativados para comunicação sem fio que usem Windows XP Professional com SP2 ou Windows XP Tablet Edition. Essas versões do Windows oferecem suporte incorporado para 802.1X e WLAN. Além disso, clientes baseados em Windows XP oferecem funcionalidade automática de renovação e registro de certificados, o que torna uma solução baseada em certificados como essa especialmente econômica quando unida a uma infra-estrutura de certificados.

Embora o Windows XP com SP2 ofereça suporte incorporado para WPA, é necessário instalar uma atualização adicional para ativar o suporte para WPA2 IEEE 802.11i em clientes baseados em Windows XP com SP2. Para obter mais informações sobre essa atualização adicional, além de instruções de download, consulte a Atualização do Wi-Fi Protected Access 2 (WPA2)/Wireless Provisioning Services Information Element (WPS IE)
para Windows XP com Service Pack 2
disponível em http://support.microsoft.com/kb/893357/pt-br.


Resumo

Após a análise das diversas soluções disponíveis para tratar falhas conhecidas de padrões de segurança sem fio mais antigos e de como os padrões do setor tornaram essas soluções alternativas obsoletas, a solução para aperfeiçoar a segurança de redes sem fio em um ambiente de empresa de médio porte ficou mais clara. Agora, empresas de médio porte podem implementar com eficácia essa valiosa tecnologia para tirar proveito de grandes aperfeiçoamentos de produtividade de forma confiável e com mais segurança usando a solução EAP-TLS WPA ou WPA2 com Serviços de certificados fornecida por este guia. Após seguir as etapas detalhadas e usar as ferramentas que este documento oferece, uma empresa de médio porte pode ter uma solução sem fio mais segura e confiável que aumenta a produtividade sem qualquer interrupção para o usuário final da rede.


Download

Obtenha o documento Configuração de pontos de acesso sem fio protegidos


Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
Mostrar:
© 2014 Microsoft