Exemplo de design: implantação corporativa (SharePoint Server 2010)
Aplica-se a: SharePoint Foundation 2010, SharePoint Server 2010
Tópico modificado em: 2017-01-18
Este artigo descreve uma implementação prática de componentes de arquitetura lógica para se obter um design viável e foi concebido para uso junto com os seguintes exemplos de design:
Exemplo de design: Portal corporativo com autenticação clássica
Exemplo de design: Portal corporativo com autenticação baseada em declarações
Para baixar qualquer um desses modelos, consulte o artigo sobre Exemplos de design do SharePoint Server 2010: Portal corporativo com autenticação clássica ou com autenticação baseada em declarações (https://go.microsoft.com/fwlink/?linkid=196872&clcid=0x416).
Neste artigo:
Sobre os exemplos de design
Metas globais de design
Farms de servidores
Usuários, zonas e autenticação
Serviços
Alternativas de autoria e publicação
Sites de administração
Pools de aplicativos
Aplicativos Web
Conjuntos de sites
Bancos de dados de conteúdo
Zonas e URLs
Políticas de zonas
Os exemplos de design ilustram uma implantação corporativa genérica do Microsoft SharePoint Server 2010. Eles se aplicam a quase todos os componentes de arquitetura lógica e ilustram como esses componentes são incorporados no design global. Os dois exemplos ilustram os mesmos serviços e sites, mas incorporam métodos de autenticação diferentes, como se segue:
Autenticação clássica: esse exemplo de design representa um caminho para a atualização de sites do Microsoft Office SharePoint Server 2007 para o Microsoft SharePoint Server 2010. Ele incorpora a autenticação clássica, na qual são usados métodos de autenticação do Windows para acessar sites. É usada uma zona diferente para cada método de autenticação. Embora a autenticação do Windows seja usada para sites do SharePoint, um produto de firewall ou gateway pode ser configurado para usar a autenticação de formulários, com o objetivo de coletar credenciais do Windows que são encaminhadas para o SharePoint Server 2010. São adicionadas ao diretório corporativo contas de funcionários parceiros.
Autenticação de declarações: esse exemplo de design incorpora o novo modelo de autenticação de declarações. Vários provedores de autenticação e diferentes tipos de autenticação são implementados em uma única zona. A autenticação de declarações oferece suporte para a autenticação baseada em formulários, a autenticação baseada em tokens SAML e a autenticação do Windows. Esse exemplo de design adiciona empresas parceiras que usam autenticação baseada em tokens SAML para autenticação direta em diretórios de parceiros. Há diversas opções de provedores para contas de funcionários parceiros.
Use o exemplo de design que melhor representa seus requisitos de autenticação.
Este artigo descreve as metas de design para os exemplos e explica como essas metas serão alcançadas com o uso dos componentes de arquitetura lógica ilustrados nos exemplos.
Sobre os exemplos de design
Os exemplos de design ilustram uma implantação corporativa para uma empresa fictícia denominada Fabrikam, Inc. Essa implantação inclui dois farms de servidor. Um deles hospeda a intranet da empresa e o site do parceiro, e o outro hospeda o site da empresa (www.fabrikam.com). O restante desta seção descreve esses sites nível superior.
Intranet
A intranet corporativa inclui os seguintes sites:
Conteúdo publicado da intranet (como HRweb)
Sites de equipes colaborativos
Meus Sites
Juntos, estes são os sites de conteúdo e de colaboração que os funcionários usarão todos os dias. Individualmente, cada um desses aplicativos representa um tipo distinto de conteúdo. Cada tipo de conteúdo:
Enfatiza recursos diferentes do SharePoint Server 2010.
Hospeda dados com características diferentes.
Está sujeito a um perfil de utilização diferente.
Exige uma estratégia diferente de gerenciamento de permissões.
Consequentemente, as opções de design de cada um desses aplicativos destinam-se a otimizar o desempenho e a segurança.
O design de aplicativos de serviço reúne esses três aplicativos para fornecer:
Navegação entre os aplicativos
Pesquisa no âmbito da empresa
Metadados empresariais e dados de perfis compartilhados
O diagrama a seguir ilustra os três aplicativos que formam a intranet corporativa.
.gif "Sites de Intranet")
As URLs nessa ilustração referem-se ao exemplo de design de autenticação clássica.
Aplicativo Web do parceiro
O aplicativo Web do parceiro hospeda sites disponíveis externamente para colaboração segura com empresas parceiras e parceiros individuais. Esse aplicativo tem como objetivo facilitar para os funcionários a criação de sites para colaboração segura. Os parceiros não têm permissão de acesso a outros tipos de conteúdo hospedados no farm de servidores. O design de aplicativos de serviço e zonas está direcionado para essa meta.
No exemplo de design, o aplicativo Web do parceiro é hospedado pelo mesmo farm que hospeda o conteúdo da intranet.
Site da empresa na Internet
O site da empresa na Internet é a presença da empresa na Internet. O conteúdo é disponibilizado para clientes por meio da configuração do acesso anônimo com permissões somente leitura. Os principais fatores que determinam as opções de design desse aplicativo são:
Isolamento de conteúdo: os clientes não podem acessar nenhum outro tipo de conteúdo hospedado no farm de servidores.
Gerenciamento direcionado: o acesso autorizado é fornecido a funcionários que gerenciam o site por meio da execução de tarefas administrativas e de autoria.
Autoria e publicação de conteúdo seguro: um conjunto de sites separado é hospedado no Farm A, no aplicativo Web do parceiro, para autoria. Isso permite a colaboração segura e o desenvolvimento de conteúdo com funcionários internos e remotos e também com parceiros editoriais especializados no desenvolvimento de sites ou na autoria de conteúdo. A publicação de conteúdo é configurada de forma a publicar automaticamente o conteúdo do conjunto de sites de autoria do primeiro farm no conjunto de sites de produção do segundo farm. O diagrama a seguir ilustra o processo de publicação.
.gif "Sites publicados")
Metas globais de design
O exemplo de design fornece implementações práticas de recursos do SharePoint Server 2010 em vários tipos comuns de aplicativos. As implementações de design para cada um dos aplicativos individuais são abordadas neste artigo. As principais metas do exemplo de design incluem:
Usar a quantidade mínima de farms de servidores para hospedar os tipos mais comuns de sites geralmente exigidos por uma empresa; ou seja, sites de intranet, extranet e da Internet.
Criar uma estrutura para projetar um ambiente que possa se expandir. Decisões de design para aplicativos individuais não impedem o acréscimo de outros aplicativos. Por exemplo, uma implantação inicial pode incluir somente sites de equipes de colaboração ou apenas os três aplicativos que compõem uma intranet (sites de equipes, Meus Sites e conteúdo de intranet publicado). Usando um design de arquitetura lógica semelhante, você pode adicionar aplicativos à solução sem afetar o design dos aplicativos iniciais. Em outras palavras, o design não incorpora opções de design que limitam o uso do ambiente.
Fornecer acesso a diversos grupos de usuários sem comprometer a segurança do conteúdo nos diferentes tipos de sites. Usuários de diferentes zonas da rede (interna e externa) com fornecedores de autenticação diferentes podem participar da colaboração. Além disso, os usuários só podem acessar o conteúdo destinados a eles. Ao seguir um design de arquitetura lógica semelhante, você cria a oportunidade de fornecer acesso aos usuários em vários locais e com objetivos diferentes. Por exemplo, seu design inicial pode se destinar apenas a funcionários internos. Entretanto, com o uso de um design similar, você cria a oportunidade de também permitir acesso a funcionários remotos, funcionários parceiros, empresas parceiras e clientes.
Garantir que o design possa ser usado em um ambiente de extranet. São feitas opções de design deliberadas para garantir que os farms de servidores possam ser implantados com segurança em uma rede de perímetro.
O restante deste artigo discute cada componente lógico que aparece no exemplo de design (de cima para baixo), bem como as opções de design que são aplicadas ao exemplo de design. A finalidade dessa abordagem é demonstrar as diferentes maneiras de se configurar componentes da arquitetura lógica com base no aplicativo.
Farms de servidores
O exemplo de design incorpora o uso de dois farms de servidores. Esta seção descreve os requisitos de licenciamento que afetam o número de farms de servidores necessários em um ambiente corporativo e observa as topologias dos farms de servidor que são ilustradas no exemplo de design.
Requisitos de licenciamento
Para hospedar conteúdo de intranet e sites da Internet, são necessários pelo menos dois servidores para atender aos requisitos de licenciamento.
As duas licenças de servidor a seguir estão disponíveis para o SharePoint Server 2010:
Microsoft SharePoint Server 2010, licença de Servidor: esta é a licença apropriada para conteúdo de intranet colaborativo, exigindo o uso de CALs (Licenças de Acesso para Cliente). Se forem criados sites para colaboração de parceiros, será preciso garantir a aquisição do número necessário de CALs para funcionários parceiros.
Microsoft SharePoint Server 2010 for Internet sites: esta licença destina-se somente a sites voltados para a Internet, não exigindo o uso de CALs. Se você criar sites para colaboração de parceiros, não precisará adquirir outras CALs. Entretanto, não será possível criar sites destinados exclusivamente para uso por parte dos seus funcionários.
Observação
Essas licenças não podem ser combinadas no mesmo computador servidor, nem no mesmo farm de servidores.
Considerando-se as opções de licenciamento, a decisão de design mais crítica é determinar qual farm hospedará o aplicativo Web do parceiro. No exemplo de design, o primeiro farm hospeda o conteúdo da intranet, e o segundo hospeda o site da empresa na Internet. De acordo com as condições de licenciamento, qualquer um dos farms pode hospedar o aplicativo Web do parceiro.
Com uma opção dos dois farms, a diretriz de design geral para determinar qual farm deve hospedar o aplicativo Web do parceiro inclui:
Natureza da colaboração: se a principal finalidade de um site de extranet de parceiro for comunicar informações com segurança para vários parceiros, um farm de servidores da Internet será a opção mais econômica. Por outro lado, se a principal finalidade for trabalhar de modo colaborativo com um pequeno número de funcionários parceiros, um farm de servidores de intranet talvez seja uma escolha melhor. Escolha a opção com a qual você poderá otimizar seu farm de acordo com a função planejada.
Número de funcionários parceiros: se você colabora com muitos funcionários parceiros e considera importante reduzir os custos, é possível hospedar com segurança o conteúdo anônimo e colaborativo em um farm da Internet usando a licença de sites da Internet.
No exemplo de design, o aplicativo Web do parceiro destina-se à colaboração intensa com empresas parceiras, incluindo o desenvolvimento e a preparação do site da Internet da empresa. Colocar o aplicativo Web do parceiro no primeiro farm permite que a organização otimize cada um dos dois farms para o uso pretendido de cada um (conteúdo de colaboração versus conteúdo somente leitura). Porém, qualquer um dos farms pode hospedar o aplicativo Web do parceiro.
O exemplo de design inclui o Microsoft Office Web Apps. O Office Web Apps exige uma licença de cliente do O Microsoft Office 2010. Em outras palavras, se você disponibilizar o Office Web Apps para os parceiros, também deverá adquirir licenças de cliente do Office 2010 para eles.
Topologia dos farms de servidores
Cada farm de servidores no exemplo de design é composto por cinco servidores com esta topologia:
Dois servidores Web front-end
Um servidor de aplicativos
Dois servidores de banco de dados, clusterizados ou espelhados
O exemplo de design ilustra a arquitetura lógica do SharePoint Server 2010, mostrando que:
Todos os sites são espelhados nos servidores Web front-end.
O site da Administração Central está instalado em um servidor de aplicativos para ficar protegido contra o acesso direto dos usuários.
Na verdade, o número de computadores servidores e a topologia do farm de servidores não são importantes para a arquitetura lógica, exceto para aumentar a capacidade e o desempenho conforme necessário. A arquitetura lógica pode ser projetada independentemente da topologia do farm de servidores. O processo de planejamento do desempenho e da capacidade ajudará a dimensionar o farm de servidores de forma que ele atenda às suas metas de desempenho e de capacidade. Para obter mais informações, consulte Gerenciamento de desempenho e capacidade (SharePoint Server 2010).
Dimensionamento além de dois farms
Sua empresa pode precisar de mais do que os dois farms representados. Os sites que são candidatos a farm dedicado incluem:
Meus Sites: muitas organizações com grandes quantidades de funcionários ou alunos optam por hospedar Meus Sites em um farm de servidores dedicado.
Autoria e preparação de sites: se o conteúdo publicado for complexo ou extenso, o processo de autoria e preparação pode ser melhor otimizado com a hospedagem desses sites em um farm de servidor único dedicado, usando uma licença do Microsoft SharePoint Server 2010 for Internet Sites. Por exemplo, a publicação de um conteúdo que inclui metadados marcados aumenta a complexidade do exemplo de design de serviços entre o farm de autoria e o farm publicado, incluindo o compartilhamento do serviço entre os farms e a tomada de decisões sobre como esse serviço pode ser compartilhado em outros tipos de aplicativos Web em um farm multiuso.
Sites do parceiro: exigências de segurança e isolamento podem justificar um farm dedicado para colaboração de parceiros. Isto cria um isolamento físico entre o conteúdo exclusivamente interno e o conteúdo desenvolvido em colaboração com parceiros externos.
Usuários, zonas e autenticação
Ao criar um aplicativo Web no SharePoint Server 2010, é preciso escolher a autenticação baseada em declarações ou a autenticação clássica. O modo de autenticação determina como as contas são usadas internamente pelo SharePoint Server 2010. A tabela abaixo resume as duas abordagens.
Tipo de autenticação |
Descrição |
Recomendações |
Autenticação clássica |
As contas de usuário são tratadas pelo SharePoint Server 2010 como contas tradicionais do Windows Active Directory. Há suporte para os seguintes protocolos de autenticação: Kerberos, NTLM, Básica, Digest e anônimo. Não há suporte para a autenticação baseada em formulários. Apenas um método de autenticação pode ser configurado em uma zona. |
O modo clássico é recomendado para a atualização de ambientes do Microsoft Office SharePoint Server 2007, nos quais não é exigida a autenticação baseada em formulários. Você não precisará executar a migração de usuários se estiver atualizando e selecionar a autenticação no modo clássico. |
Autenticação baseada em declarações |
As contas de usuário são tratadas pelo SharePoint Server 2010 como identidades de declarações. Contas do Windows são automaticamente convertidas em identidades de declarações. Esse modo também oferece suporte para a autenticação baseada em formulários e para a autenticação em um provedor de identidade confiável. Podem ser configurados em uma única zona vários tipos de autenticação. |
A autenticação baseada em declarações é recomendada para novas implantações do SharePoint Server 2010. Ela é necessária para atualizar soluções do Office SharePoint Server 2007 que exigem a autenticação baseada em formulários. |
Os dois exemplos de design abordados neste artigo representam essas duas opções. As seções a seguir discutem especificamente como a autenticação é incorporada nesses dois exemplos de design.
Exemplo de design com autenticação no modo clássico
O exemplo de design que usa a autenticação no modo clássico incorpora a abordagem tradicional de autenticação de "uma zona por tipo" que foi assimilada na versão anterior. Por esse motivo, esse exemplo fornece um roteiro de atualização do Office SharePoint Server 2007 para o SharePoint Server 2010.
A única limitação é que a autenticação baseada em formulários não tem suporte no modo clássico. Ao se usar a autenticação no modo clássico, todas as contas autenticadas devem residir no AD DS (Serviços de Domínio Active Directory). A recomendação para os usuários que estejam acessando sites remotamente é utilizar a autenticação baseada em formulários no produto de firewall ou gateway para coletar as credenciais do Windows que são encaminhadas ao farm do SharePoint.
O exemplo no modo clássico ilustra quatro classes diferentes de usuários, cada uma delas atribuída a uma zona diferente. Em cada aplicativo Web, você pode criar até cinco zonas usando um dos nomes de zona disponíveis: Padrão, Intranet, Internet, Personalizada ou Extranet.
A tabela a seguir mostra as zonas, os usuários e o tipo de autenticação determinado pelo exemplo de design no modo clássico.
.gif "Tabela mostrando zonas, usuários e autenticação.")
A conta de rastreamento de pesquisa exige acesso a pelo menos uma zona usando autenticação NTLM. Se nenhuma das zonas de usuários for configurada para usar a autenticação NTLM, configure a zona personalizada para usar essa autenticação.
Exemplo de design com autenticação baseada em declarações
A autenticação baseada em declarações é recomendada para todas as novas implantações do SharePoint Server 2010 e é necessária para atualizar as soluções do Office SharePoint Server 2007 que exigem a autenticação baseada em formulários. Além de fornecer os métodos padrão de autenticação do Windows, a autenticação baseada em declarações permite a autenticação com base em outros diretórios, como o Windows Live ID, os Serviços de Federação Active Directory 2.0 ou um provedor de identidade de terceiros que ofereça suporte para tokens de SAML e o protocolo WS Federation.
No exemplo de design com autenticação baseada em declarações, a autenticação baseada em declarações é usada no farm colaborativo. Essa autenticação permite o uso de vários tipos de autenticação na mesma zona. O exemplo de design usa a zona Padrão para todos os tipos de autenticação. A tabela abaixo mostra as zonas, os usuários e o tipo de autenticação indicados por esse exemplo para o farm colaborativo.
.gif "Tabela mostrando zonas, usuários e autenticação.")
No exemplo de design, o site de conteúdo de intranet publicado, os sites de equipes e Meus Sites só podem ser acessados por funcionários, estejam eles dentro ou fora da rede. O exemplo de design implementa apenas uma URL (via SSL), que pode ser usada interna e externamente. São usadas contas do Active Directory. Se necessário, o LDAP pode ser usado com a autenticação baseada em formulários ou SAML, que requer configuração adicional.
No exemplo de design, o aplicativo Web do parceiro representa um site de extranet que pode ser acessado por funcionários parceiros e empresas parceiras. O uso da autenticação baseada em declarações neste cenário exige a definição de configurações de confiança com um ou mais STS (serviços de token de segurança) externos. Isso pode ser fornecido através de uma das abordagens a seguir:
O farm do SharePoint pode ser configurado para confiar em um STS externo, como o STS associado ao Windows Live (para a autenticação de parceiros individuais) ou o STS que reside em uma empresa parceira (para autenticação diretamente no diretório do parceiro).
O STS dentro do ambiente corporativo pode ser configurado para confiar em um STS externo. Essa relação deve ser estabelecida explicitamente pelos administradores nas duas organizações. Neste cenário, o farm do SharePoint é configurado para confiar apenas no STS que reside em seu próprio ambiente corporativo. Esse STS interno verifica o token que recebe do STS externo e depois emite um token que permite ao usuário parceiro acessar o farm do SharePoint. Esta é a abordagem recomendada.
Uma alternativa à implementação de um ambiente baseado em declarações para autenticar parceiros é usar a autenticação baseada em formulários e gerenciar essas contas usando um repositório separado, como um banco de dados.
Para obter mais informações sobre como implementar ambiente de autenticação baseada em declarações, consulte o white paper sobre identidade baseada em declarações para o Windows: introdução aos Serviços de Federação Active Directory 2.0, ao Windows CardSpace 2.0 e ao Windows Identity Foundation (https://go.microsoft.com/fwlink/?linkid=196776&clcid=0x416).
No exemplo de design com autenticação baseada em declarações, o farm publicado está configurado para usar a autenticação no modo clássico. Uma alternativa é usar a autenticação baseada em declarações também para o farm publicado, além de implementar uma zona separada para usuários anônimos. O elemento importante do design é o uso de uma zona separada para usuários anônimos, de forma a criar isolamento entre o ambiente somente leitura e o ambiente de leitura-gravação, independentemente de qual modo de autenticação esteja implementado. A tabela abaixo mostra as zonas, os usuários e o tipo de autenticação ilustrados para o farm publicado.
.gif "Tabela mostrando zonas, usuários e autenticação.")
Mais uma vez, a conta de rastreamento de pesquisa requer acesso a pelo menos uma zona usando a autenticação NTLM, que por sua vez pode ser adicionada a uma zona de autenticação por declarações, se necessário. No modo clássico, se nenhuma das zonas de usuários for configurada para usar a autenticação NTLM, configure a zona personalizada para usar essa autenticação.
Zonas
Quando você cria zonas, várias decisões são essenciais para o sucesso da implantação. Elas incluem decisões de projeto e de configuração para as seguintes zonas:
A zona Padrão
Zonas para acesso externo
As seções a seguir descrevem as decisões incorporadas no exemplo de design.
Requisitos de configuração da zona Padrão
A zona que merece a maior consideração é a zona Padrão. O SharePoint Server 2010 impõe os seguintes requisitos sobre a configuração da zona Padrão:
Quando uma solicitação de usuário não puder ser associada a uma zona, são aplicadas a autenticação e as políticas da zona Padrão. Consequentemente, a zona Padrão deve ser a mais segura.
Emails administrativos são enviados com links a partir da zona Padrão. Esses emails incluem mensagens para os proprietários de sites que estão atingindo limites de cota. Consequentemente, os usuários que recebem esses tipos de email e alerta devem poder acessar os links através da zona Padrão. Isso é especialmente importante para proprietários de sites.
Conjuntos de sites com nome de host só estão disponíveis através da zona Padrão. Todos os usuários que devem acessar conjuntos de sites com nome de host devem ter acesso através da zona Padrão.
Configurando zonas para um ambiente de extranet
Em um ambiente de extranet, o design de zonas é crítico pelos seguintes motivos:
As solicitações de usuários podem ser iniciadas em várias redes diferentes. No exemplo de design, os usuários iniciam solicitações na rede interna, na Internet e em empresas parceiras.
Os usuários consomem o conteúdo em vários aplicativos Web. No exemplo de design, a intranet é composta de três aplicativos Web diferentes. Além disso, os funcionários internos e remotos têm a possibilidade de contribuir e administrar o conteúdo em todos os aplicativos Web: intranet, o site do parceiro e o site da empresa na Internet.
Em um ambiente de extranet, verifique se os seguintes princípios de design estão sendo observados:
Configure zonas entre vários aplicativos Web de forma que elas sejam espelhos uma das outras. A configuração da autenticação e os usuários planejados devem ser idênticos. No entanto, as políticas associadas a zonas podem ser diferentes entre os aplicativos Web. Por exemplo, certifique-se de que a zona da Internet seja usada para os mesmos funcionários em todos os aplicativos Web. Em outras palavras, não configure a zona da Intranet para funcionários internos em um aplicativo Web e para funcionários remotos em outro aplicativo Web.
Configure mapeamentos de acesso alternativos de maneira apropriada e precisa para cada zona e cada recurso. Mapeamentos de acesso alternativos são criados automaticamente na ocasião em que a zona é criada. Entretanto, o SharePoint Server 2010 pode ser configurado para rastrear conteúdo em recursos externos, como em um compartilhamento de arquivos. Links para esses recursos externos devem ser criados manualmente para cada zona com o uso de mapeamentos de acesso alternativos.
Se as zonas nos aplicativos Web não se espelharem, e os links para recursos externos não forem adequados, os riscos serão os seguintes:
Nomes de servidores, nomes DNS (Domain Name System) e endereços IP poderão ficar expostos fora da rede interna.
Os usuários não conseguirão acessar sites e outros recursos.
Serviços
A arquitetura de serviços ilustrada mostra a opção mais complexa para implantar serviços nos três diferentes tipos de sites: intranet, site do parceiro e site da empresa na Internet. Serviços dedicados e particionados são implantados para o site do parceiro. Uma instância separada do aplicativo de serviço de Metadados Gerenciados é implantada para uso exclusivo do conjunto de sites de autoria e do site publicado na Internet.
Uma alternativa muito mais simples é implantar um conjunto de aplicativos de serviço e compartilhar cada serviço, conforme necessário, entre os sites. Essa arquitetura depende da filtragem de segurança para mostrar somente o conteúdo ao qual os usuários possuem acesso. O diagrama abaixo ilustra essa abordagem mais simples.
.gif "Arquitetura de serviços")
A principal decisão de design para implantar aplicativos de serviço é o quanto deve ser expandida a taxonomia organizacional. A arquitetura de serviços pode ser simplificada pelo compartilhamento de metadados gerenciados, do perfil de usuários e da pesquisa em todos os aplicativos Web e pela utilização da filtragem de segurança para gerenciar o acesso ao conteúdo. Na arquitetura simplificada descrita neste artigo, uma instância do serviço de Metadados Gerenciados é compartilhada em todos os sites. Contudo, com essa configuração, todos os usuários têm acesso à taxonomia corporativa. Os arquitetos de soluções devem decidir se serão ou não implementadas várias instâncias do serviço de Metadados Gerenciados. Eles também precisarão decidir em que medida compartilhar os dados de Perfil de Usuários.
Site do parceiro
Para o site do parceiro (grupo personalizado no Farm 1), os serviços mínimos indicados pelo exemplo de design são Pesquisa e Metadados Gerenciados. Se você adicionar o Office Web Apps ao grupo de serviços usados pelo site do parceiro, certifique-se de ter as licenças corretas para todos os usuários desse site, inclusive os parceiros. O aplicativo de serviço de Perfil de Usuários não é incluído pelo exemplo de design, para impedir que os usuários parceiros pesquisem dados pessoais na organização.
Na arquitetura simplificada, os parceiros têm acesso a toda a taxonomia corporativa e podem pesquisar dados pessoais na organização. Contudo, a pesquisa limita os resultados aos sites e ao conteúdo aos quais esses parceiros têm acesso.
Se os seus sites de parceiro exigem isolamento de conteúdo entre projetos, a implantação de aplicativos de serviço dedicados e particionados é uma boa escolha, conforme ilustrado no exemplo de design. Isso aumenta a complexidade da arquitetura de serviços, mas garante que os parceiros não tenham acesso a metadados associados ao conteúdo da Intranet ou mesmo a outros projetos dentro do site do parceiro.
Site da empresa na Internet
Na arquitetura de design simplificada, o aplicativo de serviços corporativos de Metadados Gerenciados também é compartilhado com o site publicado na Internet. No exemplo de design, é implantada uma instância dedicada do aplicativo de serviços de Metadados Gerenciados no farm de colaboração para uso exclusivo por parte do conjunto de sites de autoria e do farm publicado.
Se o farm publicado for anônimo e somente leitura, não haverá risco de se expor metadados gerenciados não associados ao conteúdo publicado. Os usuários anônimos têm acesso somente ao conteúdo publicado e não podem enviar classificações nem criar outros tipos de metadados.
O compartilhamento do aplicativo de serviços de Metadados Gerenciados na organização (conforme ilustrado na arquitetura simplificada deste artigo) permite que os autores utilizem a taxonomia corporativa. Por outro lado, implantar uma instância dedicada do serviço para autoria e publicação (conforme ilustrado no exemplo de design) garante o isolamento dos metadados gerenciados.
Uma instância dedicada do aplicativo de serviço de Pesquisa é implantada no farm que hospeda o site da empresa na Internet. Esta é a configuração recomendada para um site publicado na Internet.
Alternativas de autoria e publicação
No site da empresa na Internet, o exemplo de design ilustra um processo de publicação que inclui o uso do recurso de implantação de conteúdo para mover o conteúdo de um conjunto de sites de autoria para o farm de publicação. Uma alternativa mais simples a essa abordagem é criar diretamente no farm de publicação. Esse processo costuma ser chamado de autoria em produção.
A autoria no ambiente de produção simplifica consideravelmente a solução, consolidando os serviços em um farm e dispensando a necessidade de se implantar conteúdo. O exemplo de design inclui as zonas adicionais que podem ser usadas pelos autores para trabalhar com segurança sem prejudicar os usuários anônimos. Lembre-se de bloquear o acesso anônimo de entrada na porta associada às zonas usadas pelos autores. Se o seu site apresentar menos de 500 gravações por hora de atividade de autoria, é improvável que o desempenho do site publicado seja prejudicado durante o processo de autoria no ambiente de produção.
O SharePoint Server 2010 inclui recursos de publicação que podem ser usados neste cenário para garantir que o conteúdo não fique exposto aos usuários anônimos até que esteja pronto. Para obter mais informações, consulte os seguintes artigos:
Agendamento das datas de início e término para uma página publicada (https://go.microsoft.com/fwlink/?linkid=196777&clcid=0x416)
Aprovação ou rejeição de um envio pendente (https://go.microsoft.com/fwlink/?linkid=196778&clcid=0x416)
Definição de permissões para publicação (https://go.microsoft.com/fwlink/?linkid=196779&clcid=0x416)
Sites de administração
No exemplo de design, o site da Administração Central de cada farm de servidores é hospedado em um servidor de aplicativos. Isso protege o site do contato direto com os usuários. Se um afunilamento de desempenho ou o comprometimento da segurança afetar a disponibilidade dos servidores Web front-end, o site da Administração Central permanecerá disponível.
As URLs com carga balanceada para sites de administração não são mencionadas no exemplo de design ou neste artigo. As recomendações incluem:
Se números de porta forem usados em URLs administrativas, use portas não padrão. Números de porta são incluídos em URLs por padrão. Embora números de portas não costumem ser usados em URLs de clientes, seu uso para sites de administração pode aumentar a segurança ao limitar o acesso a esses sites a portas não padrão.
Crie entradas DNS separadas para sites de administração.
Além dessas recomendações, você tem a opção de balancear a carga do site da Administração Central em vários servidores de aplicativos para obter redundância.
Pools de aplicativos
Pools de aplicativos do IIS (Serviços de Informações da Internet) separados geralmente são implementados para se obter isolamento de processo entre conteúdos. Pools de aplicativos fornecem uma maneira para que vários sites sejam executados no mesmo computador servidor, mas ainda mantenham seus próprios processos de trabalho e identidade. Isso reduz a exploração em um site que fornece uma oportunidade para que um invasor introduza código no servidor para atacar outros sites.
Em termos práticos, considere o uso de um pool de aplicativos dedicado para cada um destes cenários:
Para separar o conteúdo autenticado do conteúdo anônimo.
Para isolar aplicativos que armazenam senhas e interagem com aplicativos empresariais externos (embora o Serviço de Repositório Seguro possa ser usado para essa finalidade).
Para isolar aplicativos nos quais os usuários tenham grande liberdade para criar e administrar sites e colaborar no conteúdo.
O exemplo de design usa pools de aplicativos da seguinte maneira:
Cada site de administração é hospedado em um pool de aplicativos dedicado. Este é um requisito dos Produtos do SharePoint 2010.
O conteúdo de intranet é dividido em dois pools de aplicativos diferentes. O conteúdo colaborativo (Meus Sites e sites de equipes) é hospedado em um pool de aplicativos. O conteúdo de intranet publicado é hospedado em um pool de aplicativos separado. Essa configuração fornece isolamento de processos para o conteúdo de intranet publicado, no qual o uso de conexões de dados empresariais é mais provável.
O aplicativo Web do parceiro é hospedado em um pool de aplicativos dedicado.
O site da empresa na Internet é hospedado em um pool de aplicativos dedicado no segundo farm. Se esse farm também tiver que hospedar conteúdo para colaboração de parceiro, esses dois tipos de conteúdo (Internet e parceiro) serão hospedados em dois pools de aplicativos diferentes.
Aplicativos Web
Um aplicativo Web é um site do IIS criado e usado pelos Produtos do SharePoint 2010. Cada aplicativo Web é representado por um site diferente no IIS.
Em termos gerais, use aplicativos Web dedicados para:
Separar o conteúdo anônimo do conteúdo autenticado. No exemplo de design, o site da empresa na Internet fica hospedado em um aplicativo Web dedicado e em um pool de aplicativos.
Isolar usuários. No exemplo de design, o site do parceiro fica hospedado em um aplicativo Web dedicado e em um pool de aplicativos, para garantir que os parceiros não tenham acesso ao conteúdo da intranet.
Impor permissões. Um aplicativo Web dedicado fornece a oportunidade de impor permissões por meio de políticas, usando a página Política para Aplicativo Web na Administração Central. Por exemplo, você pode criar uma política para negar explicitamente o acesso de gravação a um ou mais grupos de usuários. As políticas para um aplicativo Web são impostas independentemente das permissões configuradas em sites ou em documentos individuais no aplicativo Web.
Otimizar o desempenho. Os aplicativos apresentarão melhor desempenho se forem colocados em aplicativos Web com outros aplicativos de características de dados similares. Por exemplo, as características de dados de Meus Sites incluem um grande número de sites pequenos. Em contraste, sites de equipe normalmente englobam um número menor de sites muito grandes. Ao colocar esses dois tipos diferentes de sites em aplicativos Web separados, os bancos de dados resultantes serão compostos por dados com características similares, otimizando assim seu desempenho. No exemplo de design, Meus Sites e sites de equipe não têm requisitos exclusivos de isolamento de dados: eles compartilham o mesmo pool de aplicativos. Entretanto, Meus Sites e sites de equipe foram colocados em aplicativos Web separados para otimizar o desempenho.
Otimizar a capacidade de gerenciamento. Como a criação de aplicativos Web separados resulta em sites e bancos de dados separados, é possível implementar diferentes limites de site (lixeira, expiração e tamanho) e negociar diferentes contratos de nível de serviço. Por exemplo, você poderá conceder mais tempo para a restauração do conteúdo de Meus Sites se este não for o tipo mais essencial de conteúdo da sua organização. Isso permite restaurar o conteúdo mais crítico antes da restauração do conteúdo de Meus Sites. No exemplo de design, Meus Sites estão inseridos em um aplicativo Web separado para permitir que os administradores gerenciem o crescimento de maneira mais intensa em comparação a outros aplicativos.
Conjuntos de sites
O conjunto de sites abrange a arquitetura lógica e a arquitetura de informações. As metas de design para conjuntos de sites, no exemplo de design, são atender aos requisitos para o design de URLs e criar divisões lógicas de conteúdo.
Para atender aos requisitos de design de URLs, cada aplicativo Web inclui um único conjunto de sites de nível raiz. Caminhos gerenciados são usados para incorporar uma segunda camada de conjuntos de sites de nível superior. Para obter mais informações sobre requisitos de URL e sobre o uso de caminhos gerenciados, consulte "Zonas e URLs", mais adiante neste artigo. Além da segunda camada de conjuntos de sites, cada site é um subsite.
O diagrama a seguir ilustra a hierarquia de Sites de Equipe.
.gif "Sites de equipe")
Devido à necessidade de um conjunto de sites de nível raiz, as decisões de design enfatizam a segunda camada de conjuntos de sites. O exemplo de design incorpora opções baseadas na natureza do aplicativo.
Conteúdo de intranet publicado
A suposição para o aplicativo Web de conteúdo de intranet publicado é que várias divisões na empresa hospedarão o conteúdo publicado. No exemplo de design, o conteúdo de cada divisão fica hospedado em um conjunto de sites separado. Isso proporciona as seguintes vantagens:
Cada divisão pode gerenciar e conceder permissão para o respectivo conteúdo de maneira independente.
O conteúdo de cada divisão pode ser armazenado em um banco de dados dedicado.
As desvantagens de se usar vários conjuntos de site incluem:
Não é possível compartilhar páginas mestras, layouts de página, modelos, Web Parts e a navegação entre conjuntos de sites.
É necessário mais esforço para coordenar as personalizações e a navegação entre conjuntos de sites.
Dependendo da arquitetura de informações e do design do aplicativo de intranet, o conteúdo publicado pode ser exibido ao usuário como um único aplicativo. De modo alternativo, cada conjunto de sites pode ser exibido como um site separado.
Meus Sites
Meus Sites têm características distintas, e as recomendações para a implantação desse recurso são objetivas. No exemplo de design, o aplicativo Meu Site incorpora um site de nível superior com a URL de http://my. O primeiro conjunto de sites de nível superior que é criado usa o modelo Host de Meu Site. Um caminho gerenciado é incorporado (usando a inclusão de curinga), o que permite um número indefinido de sites criados pelo usuário. Todos os sites abaixo do caminho gerenciado são conjuntos de sites independentes, que herdam o modelo Host de Meu Site. O nome de usuário é anexado à URL no formato http://my personal/nomedeusuário. A seguinte ilustração mostra Meus Sites.
.gif "Meus Sites")
Sites de equipe
Você pode usar qualquer uma das seguintes abordagens para projetar conjuntos de sites em um aplicativo de Site de Equipe:
Permitir que as equipes criem conjuntos de sites por meio da criação de sites pessoais. A vantagem dessa abordagem é que as equipes podem criar facilmente um site, conforme necessário, sem a assistência de um administrador. Porem, abordagem apresenta várias desvantagens, entre elas:
Não é possível implementar uma taxonomia ponderada.
O aplicativo pode ficar difícil de gerenciar.
Sites são facilmente abandonados.
Não é possível compartilhar modelos e navegação entre projetos ou equipes que, de outra forma, poderiam compartilhar um conjunto de sites.
Criar um número específico de conjuntos de sites para a sua organização com base no seu modo de operação. Nessa abordagem, conjuntos de sites são criados pelo administrador do SharePoint. Depois de criado o conjunto de sites, as equipes podem criar sites nesse conjunto de acordo com as suas necessidades. Essa abordagem possibilita implementar uma taxonomia ponderada que fornece estruturação para a forma como os sites de equipe são gerenciados e ampliados. Também há maior oportunidade de compartilhar modelos e navegação entre projetos e equipes que compartilham um conjunto de sites.
O exemplo de design incorpora a segunda abordagem, o que resulta em uma hierarquia similar de conjunto de sites para os sites de equipe no que se refere ao conteúdo de intranet publicado. O desafio para os arquitetos de informações é criar uma segunda camada de conjuntos de sites que faça sentido para a organização. A tabela a seguir mostra sugestões para vários tipos de organizações.
| Tipo de organização | Taxonomias sugeridas de conjunto de sites |
|---|---|
Implantação de produtos |
|
Pesquisa |
|
Instituição de ensino superior |
|
Escritório legislativo estadual |
|
Escritório jurídico corporativo |
|
Fabricação |
|
Aplicativo Web de parceiro
O objetivo do aplicativo Web do parceiro é ser utilizado para colaboração com parceiros externos em projetos com escopos ou durações específicos. Por padrão, os sites no aplicativo Web do parceiro não devem estar relacionados. Os requisitos desse aplicativo incluem assegurar que:
Os proprietários de projetos possam criar sites facilmente para colaboração dos parceiros.
Parceiros e outros contribuidores tenham acesso apenas ao projeto em que trabalham.
As permissões sejam gerenciadas por proprietários de sites.
Os resultados de pesquisa em um projeto não exponham o conteúdo de outros projetos.
Os administradores possam identificar facilmente os sites que não estão mais em uso e excluí-los.
Para atender a esses requisitos, o exemplo de design incorpora um conjunto de sites para cada projeto. Dessa forma, os seguintes benefícios são obtidos:
Conjuntos individuais de sites fornecem o nível adequado de isolamento entre projetos.
A criação de sites pessoais pode ser implementada.
O aplicativo Web do parceiro também hospeda os conjuntos de sites de desenvolvimento de conteúdo para o site da empresa na Internet e, por isso, conjuntos de sites separados são criados para autoria e preparação.
Site da empresa na Internet
O site da empresa na Internet incorpora um único conjunto de sites de nível raiz. Todos os sites subordinados a esse conjunto são subsites. Essa estrutura simplifica as URLs de páginas do site. O diagrama a seguir ilustra a arquitetura do site da empresa na Internet.
.gif "Site da empresa na Internet")
Bancos de dados de conteúdo
Você pode usar estas duas abordagens para incorporar bancos de dados de conteúdo ao design (o exemplo de design incorpora as duas abordagens):
Estabeleça tamanhos de destino para os bancos de dados de conteúdo com avisos adequados de limite máximo. Crie um novo banco de dados quando os limites máximos de tamanho forem atingidos. Com essa abordagem, conjuntos de sites são adicionados automaticamente ao banco de dados ou aos bancos de dados disponíveis com base exclusivamente nos destinos de tamanho. Essa é a abordagem de uso mais comum.
Associe conjuntos de sites a bancos de dados de conteúdo específicos. Essa abordagem permite que você posicione um ou mais conjuntos de sites em um banco de dados dedicado que pode ser gerenciado independentemente de outros bancos de dados.
Se optar por associar conjuntos de sites a bancos de dados de conteúdo específicos, você poderá usar um destes métodos:
Use o Windows PowerShell para criar um conjunto de sites em um banco de dados específico.
Designe um banco de dados a um único conjunto de sites aplicando as seguintes configurações de capacidade de banco de dados:
Número de sites antes de um evento de aviso ser gerado = 1
Número máximo de sites que podem ser criados neste banco de dados = 1
Adicione um grupo de conjuntos de sites a um banco de dados dedicado executando as seguintes etapas:
No aplicativo Web, crie o banco de dados e defina seu status como Pronto.
Defina o status de todos os outros bancos de dados como Offline. Enquanto os bancos de dados de conteúdo estiverem offline, não será possível criar novos conjuntos de sites. Entretanto, aqueles já existentes em bancos de dados offline continuarão acessíveis para operações de leitura e gravação.
Crie os conjuntos de sites. Eles são automaticamente adicionados ao banco de dados.
Defina o status de todos os outros bancos de dados como Pronto.
Conteúdo de intranet publicado
Para o conteúdo de intranet publicado, o exemplo de design incorpora um único banco de dados para facilitar o gerenciamento. Adicione bancos de dados com base nas metas de tamanho de destino, se necessário.
Meus Sites
Para Meus Sites, o exemplo de design obtém eficiência de dimensionamento ao gerenciar bancos de dados quanto ao tamanho máximo de destino. As configurações a seguir são definidas para se atingir essa meta:
Limite máximo de armazenamento do site: essa configuração, definida na página Modelos de Cota da Administração Central, limita o tamanho de um site pessoal.
Lixeira de segundo estágio: essa configuração, definida na página Definições Gerais do Aplicativo Web, determina a quantidade de espaço adicional que é alocada para a lixeira de segundo estágio.
Número máximo de sites que podem ser criados neste banco de dados: essa configuração é definida quando você cria um banco de dados. Calcule o tamanho total permitido usando os números que você especificar para os dois valores anteriores. Em seguida, com base na meta de tamanho para cada banco de dados, determine quantos sites caberão no banco de dados.
O exemplo de design fornece as seguintes definições de exemplo de tamanho, com base no tamanho de um banco de dados de destino, que corresponde a 200 GB, e no tamanho de Meu Site de destino, que é de 1 GB:
Limites de tamanho por site = 1 GB
Tamanho de destino do banco de dados = 175 GB
Reservado para lixeira de segundo estágio = 15%
Número máximo de sites = 180
Aviso de nível do site = 150
Quando o aviso de nível do site for alcançado, crie um novo banco de dados. Depois de criar o novo banco de dados, um novo recurso Meus Sites será adicionado alternadamente ao novo banco de dados e ao banco de dados existente até ser alcançado o número máximo de sites de um dos bancos de dados.
Sites de equipe
Para sites de equipe, o exemplo de design obtém novamente eficiência de dimensionamento ao gerenciar bancos de dados quanto ao tamanho máximo de destino. Os sites de equipe da maioria das organizações tendem a ser muito maiores do que Meus Sites. O exemplo de design fornece definições de banco de dados com base em um limite de 30 GB para conjuntos de sites. Escolha o limite adequado aos sites de equipe da sua organização.
Outra abordagem para organizações cujas equipes requerem amplo espaço de armazenamento é designar um único banco de dados para cada conjunto de sites de equipe de nível superior.
Web do parceiro
Semelhante ao recurso Meus Sites, a Web do parceiro obtém eficiência de dimensionamento ao gerenciar bancos de dados quanto ao tamanho máximo de destino. Porém, no exemplo de design, a Web do parceiro também hospeda o conjunto de sites de autoria para o site da empresa na Internet. Consequentemente, o design do banco de dados incorpora as duas abordagens:
O conjunto de sites de autoria fica hospedado em um banco de dados dedicado.
As configurações de banco de dados e tamanho são definidas para gerenciar todos os outros sites e bancos de dados.
Como a Web do parceiro fica hospedada em um aplicativo Web dedicado, você pode criar limites de tamanho mais adequados aos tipos de sites que são criados. A amostra de design fornece as seguintes configurações de tamanho de exemplo:
Tamanho de destino do banco de dados = 200 GB
Cota de armazenamento por site = 5 GB
Número máximo de sites = 40
Conjunto de sites de autoria hospedado em um banco de dados dedicado
Site da empresa na Internet
Usando um único conjunto de sites no design do site da empresa na Internet, você utiliza um único banco de dados para esse aplicativo Web.
Zonas e URLs
O exemplo de design ilustra como coordenar URLs entre vários aplicativos em uma implantação corporativa.
Metas de design
As metas a seguir influenciam as decisões de design para URLs:
Convenções de URL não limitam as zonas através das quais o conteúdo pode ser acessado.
As portas padrão HTTP e HTTPS (80 e 443) podem ser usadas em todos os aplicativos no exemplo de design.
Números de porta não são incluídos nas URLs. Na prática, esses números de porta não costumam ser usados em ambientes de produção.
Princípios de design
Para atingir essas metas de design, os seguintes princípios de design são aplicados:
Conjuntos de sites com nome de host não são usados. Observe que esses tipos de conjuntos são diferentes dos cabeçalhos de host do IIS. Conjuntos de sites com nome de host não trabalham com o recurso de mapeamentos de acesso alternativos. Esse recurso é necessário para acessar o mesmo conteúdo em várias URLs de domínio. Consequentemente, quando sites com nome de host são usados, eles ficam disponíveis somente através da zona Padrão.
Cada aplicativo incorpora um único conjunto de sites raiz. Essa é uma exigência para o uso de mapeamentos de acesso alternativos. Se vários conjuntos de sites raiz forem necessários em um aplicativo Web, e você pretende usar somente a zona Padrão para o acesso dos usuários, conjuntos de sites com nome de host serão uma boa opção.
Para os aplicativos que incluem vários conjuntos de sites de alto nível, nos quais cada conjunto de sites representa uma equipe ou um projeto de nível superior (por exemplo, sites de equipe), o exemplo de design incorpora caminhos gerenciados, que fornecem maior controle sobre as URLs desses tipos de site.
Compensações de design
Atingir as metas de design implica algumas compensações, entre elas:
As URLs são mais longas.
Conjuntos de sites com nome de host não são usados.
Projetando URLs com carga balanceada
Ao criar um aplicativo Web, escolha uma URL com carga balanceada a ser atribuída ao aplicativo. Além disso, crie uma URL com carga balanceada para cada zona criada em um aplicativo Web. A URL com carga balanceada inclui protocolo, esquema, nome de host e porta, se for utilizada. Essa URL deve ser exclusiva em todos os aplicativos Web e zonas. Consequentemente, cada aplicativo e cada zona em cada aplicativo exigem uma URL exclusiva no exemplo de design.
Intranet
Cada um dos três aplicativos Web que compõem a intranet exige uma URL exclusiva. No exemplo de design, o público-alvo pretendido para o conteúdo de intranet é formado por funcionários internos e remotos. No exemplo de design de autenticação por declarações, os funcionários usam as mesmas URLs de cada um desses aplicativos, independentemente de trabalharem no local ou remotamente. Embora essa abordagem adicione uma camada de segurança ao design do SharePoint (todo o tráfego ocorre via SSL), ela exige o roteamento do tráfego interno por meio do produto de firewall ou de gateway junto com o tráfego remoto ou a definição de um ambiente DNS dividido para resolver solicitações internas na rede interna.
Para o exemplo de design de autenticação clássica, as URLs são diferentes para funcionários internos e remotos. A tabela a seguir mostra as URLs de funcionários internos e remotos para acessar cada aplicativo no exemplo de design de autenticação clássica.
| Aplicativo | URL de funcionário interno | URL de funcionário remoto |
|---|---|---|
Conteúdo de intranet publicado |
http://fabrikam |
https://intranet.fabrikam.com |
Sites de equipe |
http://teams/ |
https://teams.fabrikam.com |
Meus Sites |
http://my |
https://my.fabrikam.com |
Site de parceiro
No exemplo de design, o site do parceiro é acessado por funcionários internos, remotos e por funcionários parceiros. No exemplo de design de autenticação por declarações, cada um desses usuários insere a mesma URL, independentemente do método de autenticação. No exemplo de design de autenticação clássica, cada tipo diferente de usuário insere uma URL distinta. Embora os funcionários remotos e os funcionários parceiros acessem externamente o site do parceiro via SSL (HTTPS), cada grupo exige uma URL diferente para aplicar os benefícios do uso de zonas separadas (ou seja, diferentes métodos de autenticação e diferentes políticas de zona). A tabela a seguir mostra as URLs que funcionários internos, remotos e parceiros usam para acessar o site do parceiro, conforme mostrado no exemplo de design de autenticação clássica.
| Zona | URL |
|---|---|
URL de funcionário interno |
http://partnerweb/ |
URL de funcionário remoto |
https://remotepartnerweb.fabrikam.com |
URL de parceiro |
https://partnerweb.fabrikam.com |
Site da empresa na Internet
O site da empresa na Internet é um site público e pode ser acessado por qualquer usuário através da URL padrão, http://www.fabrikam.com. As políticas da zona Internet são aplicadas (ou seja, acesso anônimo e negar gravação).
Entretanto, para oferecer suporte a tarefas de administração e autoria no site público, o exemplo de design incorpora URLs para funcionários internos e remotos. Você pode usar políticas para que essas zonas garantam o acesso adequado aos grupos de segurança pretendidos para tarefas de autoria e manutenção. Os exemplos de design de autenticação clássica e de autenticação por declarações usam a mesma abordagem para esse farm. A tabela a seguir mostra as URLs de cada zona.
| Zona | URL |
|---|---|
URL de funcionário interno |
http://fabrikamsite/ |
URL de funcionário remoto |
https://fabrikamsite.fabrikam.com |
URL de cliente |
http://www.fabrikam.com |
Usando inclusões explícitas e de curinga para caminhos de URL
A definição de caminhos gerenciados permite que você especifique quais caminhos no namespace da URL de um aplicativo Web são usados para conjuntos de sites. Você pode especificar que um ou mais conjunto de sites existam em um caminho distinto abaixo do site raiz. Sem caminhos gerenciados, todos os sites criados abaixo do conjunto de sites raiz fazem parte desse conjunto.
É possível criar os dois tipos de caminhos de gerenciamento a seguir:
Inclusão explícita: um conjunto de sites com a URL explícita atribuída por você. Uma inclusão explícita é aplicada somente a um conjunto de sites. É possível criar várias inclusões explícitas abaixo de conjunto de sites raiz. Um exemplo de URL para um conjunto de sites criado com o uso desse método é http://fabrikam/hr. Como existe um impacto de desempenho para cada caminho explícito adicionado, convém limitar a 20 o número de conjuntos de sites criados com uma inclusão explícita.
Inclusão de curinga: um caminho adicionado à URL. Esse caminho indica que todos os sites especificados logo após o nome do caminho são conjuntos de sites exclusivos. Essa opção é geralmente usada para conjuntos de sites com suporte para a criação de sites pessoais; por exemplo, Meus Sites. Um exemplo de URL de um conjunto de sites criado por meio desse método é http://my/personal/user1.
O exemplo de design incorpora o uso dos dois tipos, conforme descrito nas seções a seguir.
Inclusões explícitas: conteúdo de intranet publicado
No exemplo de design, o aplicativo Web de intranet publicado incorpora o uso de inclusões explícitas.
Conteúdo de intranet publicado
No aplicativo Web de conteúdo de intranet publicado, uma inclusão explícita é usada para cada subsite; por exemplo, RH, Instalações e Compras. Cada um desses conjuntos de sites pode ser associado a outro banco de dados de conteúdo, se necessário. O uso de inclusões explícitas, neste exemplo, pressupõe que nenhum outro tipo de site tenha sido criado no aplicativo Web, nem mesmo inclusões de curinga.
O limite recomendado para sites criados com uma inclusão explícita é de aproximadamente 20. Se a organização precisar de um número maior de conjuntos de sites, considere o uso de uma inclusão de curinga ou o uso de conjuntos de sites com nome de host.
No exemplo de design de autenticação clássica, o uso de inclusões explícitas resulta nas URLs mostradas na tabela a seguir.
| Funcionário interno (zona da Intranet) | Funcionário remoto (zona Padrão) |
|---|---|
http://fabrikam |
https://intranet.fabrikam.com |
http://fabrikam/hr |
https://intranet.fabrikam.com/hr |
http://fabrikam/facilities |
https://intranet.fabrikam.com/facilities |
http://fabrikam/purchasing |
https://intranet.fabrikam.com/purchasing |
Nesse exemplo, o conjunto de sites raiz, http://fabrikam, representa a home page padrão da intranet. O objetivo desse site é hospedar conteúdo para usuários.
Inclusões de curinga: Sites de Equipe, Meus Sites e Web do Parceiro
Sites de Equipe, Meus Sites e o aplicativo Web do parceiro incorporam o uso de uma inclusão de curinga. Esse tipo de inclusão é ideal para aplicativos que permitem aos usuários criar seus próprios conjuntos de sites e para aplicativos Web que incluem muitos conjuntos de sites. Uma inclusão de curinga indica que o próximo item após o curinga é um site raiz de um conjunto de sites.
Sites de equipe
No aplicativo de Sites de Equipe, a inclusão de curinga é usada para cada conjunto de sites de equipe. Boas práticas de governança recomendam que você mantenha o número de sites de equipe de nível superior em um intervalo gerenciável. Além disso, a taxonomia de sites de equipe deve ser lógica em relação ao modo de operação dos seus negócios.
No exemplo de design de autenticação clássica, o uso de inclusões de curinga resulta nas URLs mostradas na tabela a seguir.
| Funcionário interno (zona da Intranet) | Funcionário remoto (zona Padrão) |
|---|---|
http://teams//sites/Team1 |
https://teams.fabrikam.com/sites/Team1 |
http://teams//sites/Team2 |
https://teams.fabrikam.com/sites/Team2 |
http://teams//sites/Team3 |
https://teams.fabrikam.com/sites/Team3 |
Nesse exemplo, o conjunto de sites raiz, http://team, não hospeda necessariamente o conteúdo para usuários.
Meus Sites
O recurso Meus Sites oferece a criação de sites pessoais. Quando um usuário navegando na intranet clica primeiro em Meu Site, esse elemento é automaticamente criado para o usuário. No exemplo de design, Meus Sites apresentam uma inclusão de curinga denominada /personal (http://my/personal). O recurso Meu Site anexa automaticamente o nome de usuário à URL.
No exemplo de design de autenticação clássica, isso resulta em URLs no formato mostrado na tabela a seguir.
| Funcionário interno (zona da Intranet) | Funcionário remoto (zona Padrão) |
|---|---|
http://my/personal/user1 |
https://my.fabrikam.com/personal/user1 |
http://my/personal/user2 |
https://my.fabrikam.com/personal/user2 |
http://my/personal/user3 |
https://my.fabrikam.com/personal/user3 |
Aplicativo Web do parceiro
O aplicativo Web do parceiro foi projetado para permitir que os funcionários criem facilmente sites seguros para colaboração com parceiros externos. Para contribuir com essa meta, a criação de sites pessoais é permitida.
No exemplo de design de autenticação clássica, o aplicativo Web do parceiro apresenta uma inclusão de curinga denominada /sites (http://partnerweb//sites). Isso resulta em URLs no formato mostrado na tabela a seguir.
| Funcionário interno (zona da Intranet) | Funcionário remoto (zona Padrão) |
|---|---|
http://partnerweb//sites/project1 |
https://remotepartnerweb.fabrikam.com/sites/project1 |
http://partnerweb//sites/project2 |
https://remotepartnerweb.fabrikam.com/sites/project2 |
http://partnerweb//sites/project3 |
https://remotepartnerweb.fabrikam.com/sites/project3 |
Os contribuidores parceiros podem acessar os sites de parceiros usando as URLs listadas na tabela a seguir.
| Parceiro (zona da Extranet) |
|---|
https://partnerweb.fabrikam.com/sites/project1 |
https://partnerweb.fabrikam.com/sites/project2 |
https://partnerweb/fabrikam.com/sites/project3 |
A exceção para o aplicativo Web do parceiro, conforme ilustrado nos exemplos de design, é o conjunto dedicado à criação do conteúdo para o site da empresa na Internet. Para esse conjunto de sites, uma inclusão explícita é usada. Isso fornece um exemplo de uso de inclusões explícitas e de curinga no mesmo aplicativo Web.
Políticas de zonas
É possível criar uma política para que um aplicativo Web imponha permissões no nível do aplicativo Web. Uma política pode ser definida para o aplicativo Web em geral ou somente para uma zona específica. Uma política impõe permissões em todo o conteúdo existente no aplicativo Web ou na zona. As permissões da política substituem todas as outras definições de segurança configuradas para sites e conteúdo. Você pode configurar a política com base em usuários ou em grupos de usuários, mas não em grupos do SharePoint. Se adicionar ou alterar uma política de zona, a pesquisa precisará rastrear novamente os sites para obter as novas permissões.
Políticas não são usadas no exemplo de design de autenticação por declarações para o farm colaborativo, no qual vários tipos de autenticação estão habilitados em uma única zona. Elas são implementadas no exemplo de design de autenticação clássica e no farm publicado do exemplo de design de autenticação por declarações no qual a autenticação do Windows está prescrita. No farm publicado, o uso de políticas acrescenta uma camada adicional de segurança entre usuários anônimos e usuários com acesso para gerenciar sites.
Os exemplos de design fornecem exemplos de várias políticas para obter o seguinte:
Negar acesso de gravação no conteúdo publicado.
Garantir que autores e testadores tenham o acesso apropriado ao conteúdo publicado.