Explorando o SharePoint Protegendo as comunicações externas com o SharePoint

Pav Cherny

Sumário

Considerações de design de topologia
Autenticação
Site de configuração para suporte TLS
Configuração do IIS para certificados SSL
Configuração do ISA Server
Facilitar o problema

Criptografar o tráfego SharePoint em cenários acessível pela Internet usando TLS (Transport Layer Security) (Secure Sockets LAYER) é uma abordagem familiar para proteger a comunicação. Desde 1995 quando Netscape introduzido SSL como um meio de proteger dados por meio de criptografia implementada na parte superior do protocolo HTTP, comunicação cliente/servidor baseados na Web tem dependia muito certificados SSL. As tecnologias SharePoint aproveitam TLS através do IIS com. NET, que fornecem a plataforma de servidor Web compatíveis com TLS subjacente. No entanto, ativar o TLS para sites é apenas um aspecto de proteger a comunicação externa. Você também deve considerar outras facetas como baseado em host e firewalls, topologia de design e a base do Active Directory e dependências de rede física.

A coluna de julho de 2009, abordei opções para proteger a comunicação do servidor no ambiente interno aplicando diretivas de integridade através de (NAP) com IPSec e por seguintes gerais SharePoint as práticas recomendadas de segurança. Um das principais premissas de proteger a comunicação interna é saber a identidade de computadores e usuários internos e, com base nisso, criar diretivas para conceder e restringir o acesso. Este premissa é eficaz em um ambiente autenticado como um que usa o Active Directory e o Kerberos ou NTLM (NT LAN Manager), mas é incompleta em ambientes onde pelo menos alguns dos usuários são anônimos ou onde uma classe de usuários, como fornecedores ou parceiros, precisa diferentes diretivas aplicadas. Segurança no contexto de sites voltados para a Internet requer uma abordagem semelhante do uso de várias camadas.

Dentre os princípios subjacentes de proteção de comunicações externas está bloqueando acesso indesejado como início possível, tendo a capacidade de executar log de auditorias de segurança e para os usuários não autenticados e autenticados. A abordagem típica para atender a essa necessidade é usar, no mínimo, um firewall na borda da rede para usuário com monitoração de estado de autenticação e inspeção do tráfego HTTP. No entanto, o TLS representa um desafio para inspeção de pacotes com monitoração de estado, pois o firewall deve ser capaz de descriptografar os pacotes, inspecioná-los, recriptografá-los e passá-las para um servidor front-end para processamento. Além disso, o firewall (e qualquer solução de balanceamento de carga) devem preservar sessões HTTPS. Internet Security and Acceleration (ISA) Server 2006 e Server Intelligent Application Gateway (IAG) 2007 oferecem uma solução de firewall que funciona junto com o IIS e o SharePoint para fornecer um meio de TLS compatível de proteger a comunicação.

Noções básicas sobre comunicação TLS no SharePoint requer uma compreensão de como a arquitetura de hospedagem e topologia afetam a maneira como IIS e qualquer firewalls lidar com certificados SSL. Da mesma forma, há uma série de considerações para projetar e implantar soluções de SharePoint que são acessíveis pela Internet. A arquitetura do SharePoint inclui alguns aspectos de configuração um desafio ao IIS, SSL e firewall considerações, como mapeamentos de acesso alternativo (AAM), autenticação e as zonas do SharePoint.

Considerações de design de topologia

Desenvolvimento de várias camadas de segurança para sites começa com definindo a topologia física da rede. Se você pode reduzir ou eliminar o tráfego indesejado antes de ele atinge servidores front-end e back-end, você não apenas diminuir a carga do servidor mas também atenuar os riscos de vírus, spam e malware que acompanham o tráfego mal-intencionado.

A topologia de rede que acomoda TLS para SharePoint depende o cenário de uso necessário para sua organização. A Figura 1 mostra uma árvore de decisão com algumas considerações e decisões topologia relevantes.

Você pode simplificar as decisões mais separando as várias opções de topologia em três áreas:

  • Tráfego antes de ele acessa o firewall.
  • Tráfego entre o firewall e a rede interna.
  • Tráfego dentro da rede interna.

fig1.gif

Figura 1 Considerações sobre decisões topologias acessível pela Internet.

Em termos de configurar TLS, fazer essa distinção é vital porque você deve configurar regras de roteamento e firewall para ponte conexões HTTPS entre servidores front-end do IIS e solicitações de Internet, configurar o IIS para servir aplicativos do SharePoint e garantir que os recursos internos estão protegidos. Dependendo da topologia da tráfego TLS talvez precise ser capaz de percorrer todas essas três áreas através de vários roteadores e firewalls. Vamos dar uma olhada três opções de topologia de sites acessível pela Internet e considerar como as topologias afetam tráfego TLS. Figura 2 mostra básico "margem"topologia com um firewall protegendo servidores internos.

fig2.gif

Figura 2 Borda básica topologia com um firewall único.

Na topologia de borda, um firewall de rede único significa entre sites internos e usuários externos. Ele tem a vantagem de usar um único ambiente do Active Directory para usuários internos e externos, que simplifica a manutenção e administração. Para proteger o tráfego por meio de TLS, configure o firewall para atuar também como um proxy reverso. O conceito de um proxy reverso integrado, como o ISA Server é fundamental para proteger sites voltados para a Internet, porque o proxy reverso intercepta as solicitações de entrada, pode autenticar os usuários externos, descriptografa o tráfego TLS, inspeciona-acordo com a regras de firewall e encaminha solicitações para servidores front-end. URLs públicas podem diferir do URLs internas, portanto, o proxy reverso deve ter um meio para executar a tradução de links para converter URLs externas em URLs internas. IAG Server fornece recursos de segurança adicionais, como pontos de extremidade, autorização com base em integridade através de uma diretiva de acesso com base no usuário integridade do computador cliente e de identidade e a capacidade de traduzir links para URLs internas do SharePoint quando estiver usando o Outlook Web Access.

Para adicionar uma camada adicional à topologia do e exercer controle mais granular sobre comunicação entre servidores, você pode criar uma rede de perímetro que hospeda os servidores do SharePoint. Em uma rede de perímetro, os servidores do SharePoint são isolados da Internet por um firewall e da rede interna por um firewall. Isso é uma topologia em frente e verso, como mostrado no figura 3.

fig3.gif

Figura 3 Uma topologia “ em frente e verso ” com dois firewalls.

Obviamente, você não está limitado a apenas dois firewalls em uma topologia em frente e verso. Você pode implementar as camadas adicionais separadas por firewalls ou roteadores para outras separam as funções do SharePoint. Por exemplo, você pode usar uma abordagem de três camadas, colocando cada camada em um DMZ, onde os servidores front-end estão primeiro, seguido pelo servidor de aplicativo, banco de dados e/índice de pesquisa e concluída por servidores Active Directory/DNS. Você também pode personalizar uma topologia em frente e verso para incluir um ambiente de teste interno em um farm separado e publicá-lo do farm na rede de perímetro. Outra opção é dividir o farm do SharePoint entre a rede de perímetro e a rede interna para criar uma topologia de divisão em frente e verso, conforme mostrado no figura 4. Acompanhando a abordagem de usar camadas de segurança a topologia, os servidores front-end residem na rede de perímetro e os servidores back-end executando o SQL Server residem na rede interna. As funções restantes, como índice, pesquisa e administração central, podem estar em qualquer rede.

fig4.gif

Figura 4 em uma topologia em frente e verso “ dividir ”, funções de servidor podem ser configuradas no DMZ ou a rede interna.

Coloque o servidor de pesquisa na rede interna para pesquisa ideal e rastreamento de desempenho. Você pode dedicar o servidor de pesquisa para rastreamento. Tenha em mente que a topologia em frente e verso divisão requer uma confiança unidirecional entre o perímetro e interno e ambientes de AD para dar suporte à comunicação.

Resources

Site Produtos e tecnologias do SharePoint

TechCenter do Windows SharePoint Services

Windows SharePoint Services Developer Center

Blog da equipe de Produtos e Tecnologias do Microsoft SharePoint

Autenticação

Determinar a configuração de autenticação adequado para proteger a comunicação externa rapidamente pode se tornar difícil, devido às opções disponíveis e os níveis de topologia na qual autenticação e autorização ocorrerá.

Por exemplo, seu ambiente pode oferecer suporte a RSA SecureID, incorporar NPS (servidor de diretivas de rede) ou usar um diretório personalizado com base no protocolo LDAP. No final, os aspectos de autenticação relevantes de proteger a comunicação externa do SharePoint incluem autenticação de usuários internos e externos e autenticação do IIS para sites.

Vamos simplificar esses aspectos mais rastreando o caminho de comunicação das solicitações de usuários externos para sites do SharePoint para ver como a autenticação e autorização acontecem.

  1. Um usuário externo faz uma solicitação que é roteada para o firewall. Se o firewall é um ISA Server configurado para usar autenticação baseada em formulários (FBA), o usuário é apresentado com um formulário de logon e autenticado. Em seguida, a solicitação é enviada para um servidor front-end.
  2. IIS no servidor front-end aceita a solicitação;Determina o site associado com a URL;verifica a configuração de autenticação para o site;autentica o tráfego;e o passa para o SharePoint para autorização.
  3. SharePoint executa autorização. As permissões de site do SharePoint e autorização são fora do escopo deste artigo, porque TLS está configurado para cada site no nível do IIS. Para obter mais informações sobre autenticação e autorização do SharePoint, consulte plano autenticação métodos (Office SharePoint Server).

Site de configuração para suporte TLS

SharePoint depende muito IIS e a topologia subjacente e configuração de autenticação para fornecer a funcionalidade necessária para oferecer suporte a TLS. Quando o tráfego será roteado para o SharePoint, ele já tem passado através do firewall e sido tratado pelo IIS. Configurando sites para oferecer suporte a TLS é mais uma tarefa de informando SharePoint do ambiente subjacente para cada site que diretamente especificando certificados SSL, criar conta de serviço e assim por diante. Ainda assim, é importante considerar dois detalhes específicos do SharePoint ao implantar o TLS: zonas e mapeamento de acesso alternativo (AAM). Ambos são configurados no site Administração Central em gerenciamento de aplicativos.

Ao criar ou estender um aplicativo da Web, você pode especificar as zonas e insira os detalhes sobre o ambiente SharePoint usa para criar um conjunto inicial de AAMs (consulte figura 5). As principais considerações de uma perspectiva de segurança são o provedor de autenticação e se o ISA Server usa o TLS para se comunicar com o servidor front-end, ou encerra as solicitações HTTPS do usuários externos no firewall e se comunique via HTTP.

fig5.gif

Figura 5 SSL e outras opções de guration confi para um site do SharePoint.

Embora usando TLS para comunicação do ISA Server para servidores front-end cria adicional processamento de sobrecarga, ele fornece uma solução de ponta a ponta criptografada e é meu método preferido. Encerrar TLS no ISA Server também pode quebrar alguns cenários de uso, como quando usando Web Parts personalizados que armazenam URLs em um banco de dados SQL Server. O processo é semelhante para enabeing um site existente para TLS. Você deve verificar o botão de opção usar SSL (Secure Sockets Layer), configurar outras opções e em seguida, navegue para as configurações do AAM e verificar que eles estão configurados corretamente.

Configuração de zona e AAM inter-relacionada. SharePoint usa a idéia de zonas para permitir que lógico distinções entre partes de sua topologia, como Internet, extranet e intranet e as URLs disponíveis para as partes. Definições do AAM especificam como o cabeçalho do URL deve procurar os usuários de várias zonas quando a URL for diferente do URL interna. Se a URL interna é a mesma como uma URL pública que usa um nome de domínio totalmente qualificado (FQDN), você não precisa configurar AAM;SharePoint faz isso automaticamente. Para outros cenários, configure AAMs para seus sites do SharePoint. Troy Starr lançada uma visão geral abrangente de AAMs para SharePoint no blog da equipe do SharePoint, você pode encontrar em que cada administrador do SharePoint precisa saber sobre mapeamentos alternativos de acesso (parte 1 de 3). Vale bem uma aparência;Configuração incorreta do AAM é uma das causas mais comuns dos problemas do cenário de extranet.

Configuração do IIS para certificados SSL

Como mencionado, habilitando o SSL para um site do SharePoint é feita no nível do IIS. No IIS7, certificados SSL são configurados por meio de certificados de servidor. Eles estão localizados sob a página Propriedades do servidor IIS. A Microsoft já publicou instruções, considerações e cenários de uso para ter em mente ao ativar sites do IIS para usar o SSL;Lembre-se de que autoridade de certificação e IP endereço/porta ligação são especialmente relevantes para proteger sites acessível pela Internet. Há várias opções para gerar um certificado SSL. Você pode usar selfssl.exe, implante uma PKI com uma confiáveis Windows autoridade de certificação (CA) ou usar um provedor comercial. Para fins de desenvolvimento e ambientes de laboratório, um certificado auto-assinado funciona bem, mas você pode executar para problemas do usuário para ambientes de produção. A menos que os usuários aceitar o certificado em seus navegadores, eles serão solicitados ao acessar um site SSL habilitado que o certificado vem de uma fonte não confiável. Isso pode levar a oferecer suporte a chamadas e confusão, tornando mais fácil implantar um certificado de produção de uma autoridade de certificação raiz.

É possível usar o mesmo endereço IP ou a mesma porta para vários sites habilitados para SSL. A maneira simples é usar um endereço IP fixo e a mesma porta para cada site, portanto, o IIS pode acoplar o site para o endereço IP e porta. Como alternativa, se sua configuração usa um domínio raiz e vários subsites, você pode usar uma certificado curinga ou um certificado com vários nomes alternativos de site (SANs). O processo é principalmente o mesmo para um certificado regular, mas você não pode configurá-lo na tela de 7e IIS em ligações de site. Em vez disso, use appcmd e execute o seguinte comando para vincular o SSL para o site e definir o cabeçalho do host: C:\Windows\System32\inetsrv\appcmd definir /site do site. nome: < CustomSiteName >/ + ligações. [protocolo = 'https', o bindingInformation = ' *: 443: < FQDN >]. Se feito corretamente, você verá uma ligação SSL com o cabeçalho de host especificado em ligações de site.

Configuração do ISA Server

Independentemente de se você deseja proteger um site do SharePoint novo ou existente com TLS, você deve garantir que o tráfego pode atravessar o firewall. O ISA Server fornece vários mecanismos que funcionam com o SharePoint e possibilitam a passagem: FBA, HTTPS ponte, tradução de links por meio de proxy reverso e SharePoint as regras de publicação.

ISA Server usa um Assistente para ajudar a publicar sites. Este assistente cria um ouvinte e um "Permitir"regra para permitir tráfego do SharePoint. Antes de executar o assistente, exporte o certificado SSL instalado por meio do IIS no servidor front-end que hospeda o site e importá-lo para o ISA Server usando o snap-in do MMC de certificados. Importe o certificado no armazenamento pessoal de conta do computador local. Isso permite que o ouvinte, você cria no ISA Server para descriptografar o tráfego de entrada, inspecioná-lo e recriptografá-lo. Para obter mais detalhes sobre como configurar o ISA Server para SharePoint, consulte autenticação no ISA Server 2006 e configurar ISA 2006 para o SharePoint 2007.

No momento em que você configurar o ISA Server para publicar seus sites do SharePoint SSL habilitado, internos e URLs externos forem puder ser resolvidos por meio do DNS;contas de usuário e permissões tem sido configuradas;Zonas do SharePoint e AAMs são configurados;e você ter instalado o certificado SSL para o site através do IIS. Neste ponto, insira os detalhes relevantes no ISA Server. Quando você configura o ouvinte e regra de publicação, tenha em mente o seguinte:

  • AAM: Para mapeamento de acesso alternativo funcione corretamente, você deve configurar a regra de publicação para encaminhar o cabeçalho do host original. Além disso, certifique-se de que você especificar os endereços FQDN corretos para as URLs internas e externas.
  • FBA: Verifique se que você selecionou autenticação de formulário HTML e do Windows (Active Directory) na guia autenticação, a menos que você esteja usando Kerberos ou uma solução autenticação personalizada.
  • Negar acesso de usuários não autenticados. Para aumentar a segurança, verifique se que você adicionar todos os usuários autenticados. Alternativelyr Selecione usuários específicos em conjuntos de usuário e verifique se todos os usuários é removido.

Facilitar o problema

Protegendo seus sites do SharePoint usando TLS pode ser cheia de problemas. Seu firewall corretamente pode direcionar o tráfego como um proxy reverso ou pode fazer um trabalho ruim de tradução de links. A configuração de roteamento não pode ser configurada corretamente em topologias mais complexas. Ou as configurações do AAM e zona não podem corresponder às configurações de firewall ou DNS. A boa notícia é que, se abordar segurança externa com uma abordagem multi-layer, você pode isolar problemas e resolvê-los. Você pode facilitar sua vida mesmo se você usar ISA Server com autenticação FBA e do Windows. Escolher a topologia apropriada, configurar o site no SharePoint, habilitá-lo para SSL no IIS, colocá-lo todos juntos com o ISA Server e você tiver protegido comunicação externa por meio de TLS.

Pav Cherny é especialista em TI e autor especializado em tecnologias Microsoft para colaboração e comunicação unificada. Entre suas publicações estão white papers, manuais de produto e livros com foco nas operações de TI e na administração do sistema. Pav é presidente da Biblioso Corporation, empresa especializada em serviços de documentação gerenciada e de localização.