Explorando o SharePoint Proteção de segurança do SharePoint

Pav Cherny

Conteúdo

Dependências de segurança em um ambiente do SharePoint
Ativar proteção de acesso à rede
Estabelecer isolamento de domínio
Isolamento de implementação de servidor (e estação de trabalho)
Conclusão

Proteção de segurança do SharePoint requer uma abordagem de ponta a ponta que aborda o completo espectro de dependências de segurança e os riscos dentro e entre farms de servidor. Em particular, recentes inovações e tecnologias disponíveis fora da caixa com o Windows Server 2008, como (NAP) com a imposição Internet Protocol Security (IPsec), podem ajudar a aumentar a segurança do SharePoint. Ainda obter recomendações detalhadas Microsoft para proteção de segurança do SharePoint em um ambiente Windows Server 2008 são difíceis de localizar. O Windows Server 2008 Resource Center para produtos e tecnologias do SharePointnão inclui um guia de segurança. Além disso, a proteção de segurança guias para Windows SharePoint Services (WSS) 3.0e Microsoft Office SharePoint Server (MOSS) 2007ainda com base no Microsoft padrões e práticas que são datadas de junho de 2003 e foram atualizadas apenas parcialmente em janeiro de 2006 — que era ainda longo antes do lançamento do Windows Server 2008 e serviços de informações da Internet (IIS) 7.0, em qualquer caso.

Claramente, revisadas diretrizes são altamente atrasadas e não apenas porque temos tempo desde movidos do Windows 2000, o SQL Server 2000, o IIS 5.0 e o Microsoft .NET Framework 1.1, mas também porque as antigas maneiras de lidar com proteção de segurança comprovaram insuficientes vez e novamente. Simplesmente não é suficiente proteger um farm do SharePoint como uma ilha isolada do servidor, como se existirem farms do SharePoint em um vácuo. A realidade é que não uma segurança-proteção única etapa em um SharePoint farm é importante se a floresta do Active Directory é insegura, se o ambiente de intranet é infested com spyware e rootkits ou se os usuários inadvertida ou proposital violam as diretivas de segurança, por exemplo, baixar e instalar software de compartilhamento de arquivos de fontes questionáveis.

É possível resolver esses problemas usando a tecnologia Windows Server 2008. É a chave para alcançar um alto nível de segurança em um ambiente do SharePoint, ponta a ponta, dos computadores cliente totalmente para os servidores de banco de dados.

Neste artigo, Falarei sobre aspectos de segurança do SharePoint em um ambiente de intranet com base no Windows Server 2008. Esta discussão envolve analisando dependências de segurança gerais do SharePoint além dos limites de um farm individual e, em seguida, implantando NAP com imposição de IPsec com regras de segurança e isolamento correspondentes para atenuar os riscos. Para os administradores do SharePoint, uma vantagem óbvia de NAP é que ele pode parar de computadores cliente não gerenciado de acessar recursos do SharePoint e baixar documentos. Outro, talvez menos óbvia, vantagem é que você pode dividir sua intranet em redes lógicas separadas por meio de isolamento de domínio e servidor. Dessa forma, você pode proteger a comunicação de cliente para servidor e servidor-para-servidor entrada e saída e também limitar o tráfego para servidores front-end desejados. Assumindo que até 30 por cento de sites de uma empresa residem em farms departamentos não autorizados, inadequately protegidos e fora de controle do departamento de TI, os benefícios de restringir o tráfego de cliente não podem ser overemphasized. Como sempre, o material complementar inclui planilhas com instruções passo a passo para seguir minhas explicações em um ambiente de teste.

Dependências de segurança em um ambiente do SharePoint

Considerando a complexidade de soluções baseadas em SharePoint, o enorme volume de dados armazenados em sites e os requisitos de produtividade em uma empresa e freqüentemente contraditórias segurança pode ser difícil determinar como e onde começar a proteção de segurança do SharePoint. Talvez a primeira etapa é retirar a noção mantido longa que nosso intranets são ambientes amigáveis, suficientemente protegidos por meio de firewalls de perímetro e scanners de vírus. Firewalls e scanners não bloqueiam um usuário mal-intencionado de anexar um keylogger hardware PS2 ou USB a um computador cliente — não drivers necessários. Eles também não manterá um rootkit de zero-dia de transformar seus computadores móveis em zumbis enquanto estiver conectados a um ambiente protegido inadequately em casa, em hotéis ou aeroportos ou em sites de clientes. Pode parecer hostis, mas categorizar seu ambiente interno como hostil Ajuda em termos de reconhecer as dependências de segurança crítica dentro e entre farms do SharePoint.

Vamos ver quais problemas críticos, pode descobrir um laboratório de teste simples, como o descrito na Figura 1 e descritas a planilha complementar "Implantando um ambiente de teste com SharePoint vários farms e um servidor de diretiva de rede". Esse ambiente do SharePoint não é seguro. Na verdade, minha planilha implantação viola várias práticas recomendadas de segurança e ignora dependências importantes. Geralmente recebo fora com ele, supondo que não há nenhum requisitos de segurança nos laboratórios de teste. Obviamente, eu poderia ter feito pior instalando o SharePoint em um controlador de domínio ou concedendo segurança contas permissões administrativas, mas esses erros de configuração intencional não são necessários. Da perspectiva de segurança, meu ambiente de teste já está incorreto suficiente.

Figura 1 um ambiente de teste inseguro com SharePoint vários farms

Para os iniciantes, usar a conta Administrador de domínio para efetuar logon em todos os servidores e estações de trabalho e instalar todos os sistemas enquanto estivessem conectados à Internet. Isso é arriscado. É melhor evitar fazer logon em um computador não seguro usando uma conta de administrador de domínio. Da mesma forma, ele é uma prática recomendada para instalar e patches em computadores em um ambiente temporário separado e seguro antes para implantação. Kit de instalação automatizada (AIK) do Windows e o WDS (Serviços de implantação do Windows) oferecem uma boa solução, mas eu não aproveitar essas tecnologias meu laboratório de teste por motivos de complexidade. Como fizemos atalhos, meu ambiente do Active Directory já pode estar comprometida — e com ele todos os farms do SharePoint. O jogo é sobre antes mesmo iniciada! Um farm do SharePoint pode nunca ser mais seguro do que seu ambiente do Active Directory.

Contas de administrador de domínio são realmente muito confidenciais contas. Você está também em uma área confidencial quando você acessa recursos do SharePoint, como o site de Administração Central do SharePoint 3.0 e conjuntos de sites do SharePoint. Acessar um site do SharePoint implica a execução de código ASP.NET sob a identidade do usuário atual no servidor front-end. Caso seja um administrador de domínio, que o usuário atual o código será executado com privilégios administrativos. Você deve negar os administradores de domínio e servidor local Administradores acesso a aplicativos Web do SharePoint porque é possível explorar seus privilégios elevados, como extraindo contas de segurança e senhas, conforme explicado na coluna janeiro de 2009. Se um invasor pode enganar um administrador do SharePoint Implantando um componente mal-intencionado ou ativando o código do ASP.NET embutido, o invasor também poderá determinar as senhas de conta de segurança e, em seguida, obter acesso a todos os sites em todos os farms que usam essas contas.

Meu laboratório de teste, eu ignorada essas dependências de conta de segurança e administrativos riscos, configurado no farm do WSS e o farm de RH com as mesmas contas segurança e usado a conta Administrador de domínio para trabalhar com administração central do SharePoint 3.0 em ambos os farms. Compartilhamento de contas de segurança entre farms é uma boa idéia, especialmente se eles têm diferentes requisitos de segurança. Um farm que compartilha suas contas depende de outro farm para segurança — e pode, portanto, nunca alcançar um nível maior de segurança que de outro farm.

Usando contas de segurança separadas é uma prática recomendada importante, mas um farm comprometido ainda pode fornecer uma avenida para ataques em outros farms no mesmo ambiente do Active Directory. Por exemplo, ele não levar muito esforço para transformar um servidor SharePoint comprometido em uma plataforma de phishing internos. Um invasor pode ativar a autenticação básica ou obter um componente mal-intencionado em um farm do SharePoint estabelecido que envia um cabeçalho "WWW-Authenticate" para os usuários e intercepta as credenciais retornadas em texto sem formatação, como ilustrado na Figura 2 . Porque os usuários confiar em seus sites internos, é provável que eles inserirá as credenciais solicitadas sem hesitation — e o ataque tiver êxito.

Figura 2 um farm do SharePoint comprometido pode permitir ataques em outros farms.

Obviamente, é difícil comprometer um servidor SharePoint mantido corretamente, mas que não é o ponto. O ponto de está impedindo a violações de segurança em sistemas que não são mantidas adequadamente se espalhem para sistemas confidenciais com segurança de nível mais alto. Portanto, pelo menos para os recursos mais confidenciais do SharePoint, como um farm de RH com informações de identificação pessoal, você deve considerar essas dependências de acesso, que basicamente significa que um farm do SharePoint só pode ser tão seguro quanto os sites de proteger a menos que o administradores de farm, administradores de conjunto de site e os usuários do site podem acessar com suas contas de usuário.

Não se esqueça de incluir os computadores cliente na sua análise de dependências de acesso e uso. Novamente, meu ambiente de teste define um mau exemplo porque qualquer usuário pode usar qualquer estação de trabalho para acessar qualquer recurso, e os computadores não equipados com scanners de vírus ou os patches de segurança mais recentes. Imagine que um usuário com os direitos de um administrador de farm ou conjunto de sites fazer logon localmente em um computador cliente infested spyware ou em um computador em um escritório desbloqueado, onde um invasor pode anexar facilmente um keylogger de hardware. Farms e coleções de sites estão comprometidas assim que o invasor obtém acesso a uma conta de administrador e senha em qualquer computador em qualquer local. Software de compartilhamento de arquivos em computadores cliente também apresenta riscos de segurança, como computadores clientes tendem a armazenar conteúdo de sites localmente, manual ou automaticamente baixando que informações em arquivos temporários. Portanto, um farm do SharePoint pode nunca ser mais seguro do que os computadores cliente que os usuários usam para acessar recursos do farm.

Claro, há mais pontos fracos no meu ambiente de teste. Eu convidá-lo para estudar as seções relevantes nas guias de proteção de segurança do SharePoint e continuar esta revisão por conta própria. Você deve reconhecer pelo menos alguns problemas adicionais, como que os sites de Administração Central do SharePoint 3.0 e funções de pesquisa são hospedadas diretamente em servidores front-end que conteúdo do site, que não há nenhuma solução antivírus nos servidores de serviço, que o farm do WSS e o farm de RH compartilham um servidor de banco de dados desprotegido e comuns, que todos os computadores no ambiente de teste têm acesso direto ao servidor de banco de dados e que a comunicação de rede ocorre em texto sem formatação. Nada disso é desejável, portanto, vamos analisar alguns dos problemas de segurança.

Ativar proteção de acesso à rede

Há várias etapas para aumentar a segurança em um ambiente de SharePoint, como controlar o acesso físico a computadores e listas de rede, configurando vLANs e controle de acesso (ACLs) em roteadores e proteger servidores de infra-estrutura (DNS servidores, DHCP servidores, controladores de domínio e assim por diante) por meio de implantação do Microsoft Forefront Security para SharePoint e o Active Directory Rights Management Services (AD RMS). Controles de acesso físico e configurações de rede e roteador TCP/IP básicas estão além do escopo desta coluna e AD RMS foi discutida em colunas anteriores, para que isso nos deixa com NAP, o IPsec, o HTTP sobre SSL (Secure Sockets LAYER) e o Forefront Security como os próximo tópicos lógicos. Esta coluna se concentra na NAP e IPsec. O HTTP sobre SSL e o Forefront Security será abordado em colunas futuras.

NAP com o IPsec oferece pelo menos três vantagens principais para um ambiente interno do SharePoint:

• Você pode aplicar diretivas de integridade do sistema e corrigir automaticamente problemas de compatibilidade em computadores cliente que executam o Windows XP Service Pack 3 e Windows Vista;
• Você pode implementar uma camada adicional de segurança de rede através de IPsec e Firewall do Windows em toda a floresta do Active Directory;
• Você pode estabelecer canais de comunicação criptografada através de encapsulamento (Security PAYLOAD) dentro de um farm do SharePoint e entre servidores e computadores cliente.

Um bônus é a capacidade para gerenciar a comunicação de rede centralmente através da diretiva de grupo e auditar o acesso de rede. Em resumo, a NAP com o IPsec é um ativador importante de uma estratégia de segurança de ponta a ponta eficaz para SharePoint.

No núcleo, NAP com o IPsec depende de um mecanismo de distribuição inteligente para certificados X.509. No computador cliente, agentes de integridade do sistema (SHAs) informar o agente NAP seus status de conformidade por meio de documentos de declaração de integridade (SoH), que o agente NAP consolida na instrução sistema de integridade (SSoH). Ele passa a SSoH para o cliente de imposição NAP do IPsec (EC NAP) no computador cliente, que por sua vez passa o SSoH para o servidor de imposição de NAP (NAP ES). Esta é a autoridade de registro de integridade (HRA) que obtém certificados de integridade do sistema de uma autoridade de certificação (CA) para computadores compatíveis. a Figura 3 ilustra como um cliente NAP obtém um certificado de integridade.

Figura 3 comunicação cliente/servidor NAP para informações de integridade do Exchange e certificados

Para determinar se o computador solicitante é compatível com, ES NAP passa o SSoH em uma mensagem RADIUS para NPS (servidor de diretiva de rede). O NPS passa novamente o SSoH para o servidor de administração do NAP, que por sua vez extrai SoHs individuais do SSoH e encaminha o validadores de integridade de sistema correspondente (SHVs). Os SHVs analisam as informações de SoH e retornam uma resposta de declaração de integridade (SoHR), que consolida o NPS em uma resposta de sistema declaração de integridade (SSoHR) que o sistema NAP passa em seguida, volta para as SHAs no computador cliente. Por meio de SoH e SoHRs, SHVs se comunicar com suas contrapartes SHA correspondentes. Por exemplo, SoHR de SHV um antivírus pode instruir o SHA correspondente de antivírus para baixar a versão mais recente do arquivo de assinatura de um servidor remediação para trazer o computador cliente de volta em conformidade.

No lado do servidor, NAP também compara SoHRs as diretivas de integridade e de rede configurado e emitirá um certificado de integridade do sistema se o computador cliente é compatível com. O cliente NAP recebe o certificado de ES NAP e o armazena no seu armazenamento de certificado de computador. O certificado agora está disponível para a negociação IKE (Internet Key Exchange) estabelecer associações de segurança IPsec com parceiros de comunicação confiável. O cliente NAP renova o certificado de integridade do sistema sempre que ele está prestes a expirar ou quando uma SHA indica uma alteração de status de integridade para o agente NAP. A linha inferior é que computadores compatíveis recebem um certificado de integridade e não de computadores não compatíveis. Para obter detalhes técnicos profundos, É altamente recomendável o white paper" Arquitetura de plataforma de proteção de acesso de rede." A planilha complementar "Configurando proteção de acesso a rede" descreve as etapas para implantar uma infra-estrutura básica de NAP em um laboratório de teste.

Estabelecer isolamento de domínio

Mesmo em meu laboratório de teste pequeno humilde com funções NPS e HRA em um único servidor, você pode notar imediatamente os benefícios do NAP. Assim que você ativar NAP nos computadores cliente através de configurações de diretiva de grupo, NAP encoraja você instale um scanner de vírus e os patches de segurança mais recentes. O cliente NAP informa sobre componentes de segurança ausentes e o status da rede inclui uma notificação informando que o acesso de rede pode ser limitado até que o computador atende aos requisitos de integridade. Neste ponto, no entanto, computadores não compatíveis ainda terá acesso a todos os servidores na rede porque nós ainda não tiver configurado diretivas IPsec. Sem diretivas IPsec que solicitam ou exigir autenticação para conexões de entrada e saídas, a infra-estrutura NAP realmente não muito mais do que um mecanismo de distribuição do certificado de integridade. É preciso implementar o isolamento de domínio para NAP ser eficaz.

Isolamento de domínio implementação significa dividir a rede interna em segmentos de restrita, limite e redes seguras por meio de diretivas de aplicação de IPsec. O objetivo é impedir que computadores não compatíveis acessem qualquer servidores na rede interna — com exceção dos servidores que os computadores não compatíveis devem ser capazes de acessar para ficar compatível com e obter um certificado de integridade. Na Figura 4 , isso aborda o servidor NAP NPS01. A diferença entre o segmento de limite e o segmento seguro é que a diretiva IPsec para o segmento de limite de solicitações de autenticação para conexões de entrada e de saída e, portanto, permite que o fallback para comunicação de texto sem formatação com computadores não compatíveis, enquanto o segmento seguro requer autenticação para conexões de entrada, que proíbe o retorno para texto sem formatação e bloqueia computadores não compatíveis. Você pode usar a planilha complementar "Configurando diretivas de integridade imposição de IPsec" para implementar essa segmentação.

Figura 4 restritos, limite e redes seguras para NAPNAP

O controlador de domínio na Figura 4 é um caso especial. Você pode solicitar ou requer comunicação protegida pelo IPsec entre membros do domínio e controladores de domínio se os computadores executarem o Windows Vista ou Windows Server 2008 (consulte a planilha complementar "Configurando IPSec para o domínio controlador comunicação"), mas não há suporte para essa configuração para o Windows Server 2003 e Windows XP. Se você decidir não usar IPsec para comunicação de controlador de domínio, DC01 se tornará parte da rede restrita; solicitando que IPSec move o controlador de domínio para o segmento de limite e exigir que IPSec faz o controlador de domínio com um membro do segmento seguro. A configuração depende de sua situação específica e necessidades. Se possível, É recomendável usar o IPsec.

Isolamento de implementação de servidor (e estação de trabalho)

Estabelecer NAP com isolamento de domínio e imposição IPsec serve como a primeira etapa significativa para proteção de segurança. Todos os computadores cliente agora devem atender integridade razoável critérios antes de poder acessar quaisquer recursos internos do SharePoint. Em seguida, você pode focalizar segmentando o ambiente do SharePoint em várias camadas para atingir um fino nível de controle de comunicação, ponta a ponta, incluindo a comunicação de computadores cliente. a Figura 5 ilustra uma estratégia de segmentação possíveis com base na função de cada computador na rede interna.

Figura 5 um ambiente de teste aprimorado com vários farms do SharePoint

Como você observará na Figura 5 , o meu ambiente de teste inclui sistemas adicionais agora. Entre outras coisas, Alterei a configuração dos farms WSS e RH e especificado contas de segurança separadas, movido a configuração de RH e bancos de dados de conteúdo para um servidor separado do SQL e implantado computadores separados para Administração Central do SharePoint 3.0 e a função de pesquisa do SharePoint em ambos os farms. Confira várias planilhas no material complementar, que ilustram como realizar essas etapas.

Protegendo a comunicação entre as camadas agora é um processo simples, graças ao nosso NAP com trabalho de preparação do IPsec. Através da diretiva de grupo, você pode gerenciar centralmente todas as regras para Firewall do Windows com segurança avançada para bloquear a comunicação de entrada e saída em clientes e servidores para os níveis mais restritivos. É recomendável desativar regra de mesclagem na diretiva de grupo para impedir que administradores locais aplicando conflitante firewall e regras de segurança de conexão em qualquer membro do domínio. Por exemplo, você pode bloquear UDP e TCP porta 1434 nos servidores de banco de dados, abrir uma porta TCP personalizada para a instância do SQL Server padrão, criptografar o tráfego, abra somente as portas TCP que seus aplicativos da Web usam nos servidores front-end e bloquear todos os computadores não-RH acessar qualquer servidor ou computador cliente no departamento de RH.

Referências

	Rede site Access Protection go.Microsoft.com/fwlink/?LinkId=69752
	Site SharePoint Products and Technologies Microsoft.com/SharePoint
	TechCenter do Windows SharePoint Services TechNet.Microsoft.com/WindowsServer/SharePoint
	Windows SharePoint Services Developer Center msdn2.Microsoft.com/SharePoint
	Blog da equipe tecnologias de produtos do Microsoft SharePoint e blogs.msdn.com/SharePoint

Uma questão interessante é se você também deve bloquear computadores confidenciais acessando computadores nonsensitive — por exemplo, deve você manter RH os clientes acessem servidores não RH SharePoint no farm WSS. Este é um exemplo onde requisitos de segurança e produtividade entrarem em conflito. Por motivos de produtividade, Acho que é impossível recusar o acesso a toda a empresa sites do SharePoint, como sites no meu farm do WSS, que implica que o farm do WSS deve sigam os padrões de segurança mesmo como o farm de RH pessoas de RH. Portanto, em ambos os farms, eu tive que mover os sites de Administração Central do SharePoint 3.0 e pesquisar funções para um computador separado e aplicar regras de segurança de conexão e firewall. É claro, você também deve designar contas dedicadas, sem privilégios de administração do SharePoint em ambos os farms e aplicar mais etapas de proteção de segurança. Joel Oleson tiver lançado uma grande lista resumida de etapas de proteção de segurança em sua Blog SharePoint terrestre. É altamente recomendável conselhos de seguinte Joel uma infra-habilitados para IPsec estrutura que fornece uma base sólida de rock para proteção de segurança do SharePoint de ponta a ponta.

Conclusão

Farms do SharePoint não existem no vácuo. Eles existem em um ambiente que inclui computadores clientes, servidores de infra-estrutura e equipamento de rede. Isso significa que você deve participar a esses componentes se desejar obter melhor segurança por meio do SharePoint protegendo-proteção. É impossível proteger um farm do SharePoint em um ambiente Active Directory inseguro. É impossível proteger um farm do SharePoint se os computadores cliente são infested com spyware. É impossível proteger um farm do SharePoint se um invasor pode highjack contas de usuário, contas de administrador ou contas de segurança em qualquer lugar.

A tecnologia do Windows Server 2008 fornece a base para converter uma ampla segurança net através de uma floresta do Active Directory por meio de proteção de acesso à rede com imposição de IPSec, Firewall do Windows com segurança avançada e gerenciamento de diretiva de grupo. Aproveitar essas tecnologias em um ambiente do SharePoint é definitivamente vale a pena o esforço. Você pode controlar e proteger a comunicação entre controladores de domínio, servidores e estações de trabalho; você pode aplicar padrões de integridade do sistema; você pode implementar o isolamento de domínio; e você pode aplicar camadas separadas no ambiente do SharePoint interno. Através da participação em grupos de segurança ou unidades organizacionais, o Active Directory determina automaticamente as configurações de diretiva que se aplicam a cada membro do domínio, incluindo computadores cliente, servidores de banco de dados, servidores front-end e servidores de camada intermediária para administração e outras finalidades. Você pode estabelecer diretivas gerais para cada camada e diretivas específicas para cada função de servidor e tipo de computador. Você pode impedir que usuários que hospeda o SharePoint em computadores cliente bloqueando todas as conexões de entrada, e você pode impedir que os departamentos de hospedagem não aprovadas e inseguros farms do SharePoint que podem fornecem caminhos para ataques em outros farms na rede interna.

Mas não exceda com restrições. Tenha em mente que muitos processos de negócios departamental dependem de implantações do SharePoint fora do Centro de dados. Afinal, o SharePoint é uma plataforma de colaboração de negócios críticos da empresa.

Pav Cherny é especialista em IT 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 em operações de TI e administração do sistema. Pav é presidente da Biblioso Corporation, uma empresa especializada em serviços de documentação gerenciada e localização.