Modelo de arquitetura lógica: implantação corporativa
Atualizado em: 2009-04-23
Neste artigo:
Sobre o modelo
Metas gerais do projeto
Farms de servidores
Usuários, zonas e autenticação
SSPs
Sites de administração
Pools de aplicativos
Aplicativos Web
Conjuntos de sites
Bancos de dados de conteúdo
Zonas e URLs
Diretivas de zona
Este artigo descreve uma implementação prática dos componentes de arquitetura lógica para conseguir um design funcional. Este artigo deve ser usado junto com o modelo de Amostra de design: arquitetura lógica de implantação corporativa (em inglês) (https://go.microsoft.com/fwlink/?linkid=82151\&clcid=0x416) (em inglês).
O modelo ilustra uma implantação corporativa genérica do Microsoft Office SharePoint Server 2007. O modelo se aplica à quase totalidade dos componentes da arquitetura lógica e ilustra como eles são incorporados no design global. Esse artigo descreve as metas de design do modelo e explica como essas metas são atingidas com o uso de componentes da arquitetura lógica ilustrados no modelo.
Sobre o modelo
O modelo ilustra uma implantação corporativa para uma empresa fictícia chamada Fabrikam, Inc. A implantação abrange dois farms de servidores. Um deles hospeda a intranet corporativa e o site parceiro. O segundo farm hospeda o site da empresa (www.fabrikam.com).
Intranet
A intranet corporativa inclui os seguintes aplicativos:
Conteúdo da intranet publicado (como HRweb)
Sites de equipe de colaboração
Meus Sites
Juntos, eles compõem os sites de conteúdo e de colaboração que os funcionários usarão diariamente. Individualmente, cada um desses aplicativos representa um tipo de conteúdo distinto. Cada tipo de conteúdo:
Enfatiza diferentes recursos do Office SharePoint Server 2007.
Hospeda dados com diferentes características.
Está sujeito a um perfil de uso diferente.
Requer uma estratégia de gerenciamento de permissões diferente.
Consequentemente, as opções de design de cada um desses aplicativos destinam-se a otimizar o desempenho e a segurança de cada um deles.
O uso de um único SSP (provedor de serviços compartilhados) reúne esses três aplicativos para fornecer:
Navegação entre os aplicativos.
Pesquisa em toda a empresa.
Dados de perfil compartilhado.
A figura a seguir mostra os três aplicativos que compõem a intranet corporativa.
.jpg "Arquitetura lógica para modelo corporativo")
Partner Web
O aplicativo Partner Web hospeda sites disponíveis externamente para colaboração segura com os funcionários de empresas parceiras. Esse aplicativo tem o objetivo de facilitar a criação de sites pelos funcionários, para colaboração segura. Os principais fatores que orientam as opções de design desse aplicativo incluem:
**Isolamento de conteúdo **Os parceiros não podem acessar outros tipos de conteúdo hospedados no farm de servidores. Além disso, com um SSP dedicado, você pode isolar ainda mais o conteúdo das seguintes maneiras:
Definindo o escopo da pesquisa somente no nível de site.
Não permitindo a navegação nos conjuntos de sites.
Não disponibilizando dados de perfil nos conjuntos de sites.
**Autenticação separada das contas de parceiros **As contas de parceiros são gerenciadas por meio da autenticação de formulários. Essas contas não são adicionadas ao diretório corporativo.
**Gerenciamento de permissões **Os proprietários de sites individuais gerenciam permissões para seus sites, convidando somente os participantes necessários para colaborar.
No modelo, o aplicativo Partner Web é 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 os clientes por meio da configuração de acesso anônimo com permissões somente leitura. Os principais fatores que orientam as opções de design desse aplicativo incluem:
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 autenticado é fornecido aos funcionários que gerenciam o site, inclusive tarefas administrativas e de criação.
Criação e publicação de conteúdo seguro Conjuntos de sites separados são hospedados no Farm A, no aplicativo Partner Web, para criação e preparo. Isso permite segurança na colaboração e no desenvolvimento de conteúdo com funcionários internos e remotos, bem como com parceiros editoriais especializados no desenvolvimento de sites ou na criação de conteúdo. A publicação de conteúdo é configurada para publicar automaticamente o conteúdo do conjunto de sites de criação no conjunto de sites de preparo (no Farm A) e do conjunto de sites de criação no Farm A no conjunto de sites de produção no Farm B. A figura a seguir mostra o processo de publicação.
.jpg "Arquitetura de farm lógica - modelo de publicação")
Metas gerais de design
O modelo ilustra uma implementação prática dos recursos do Office SharePoint Server 2007 em vários tipos de aplicativos comuns. As implementações de design de cada um dos aplicativos individuais são abordadas neste artigo. As principais metas de design incluem:
Usar o número mínimo de farms de servidores para hospedar os tipos mais comuns de sites, geralmente necessários por uma corporação: intranet, extranet e Internet.
Criar uma estrutura para desenvolver um ambiente que possa crescer. As decisões relativas ao design dos aplicativos individuais não impedem a inclusão de outros aplicativos. Por exemplo, uma implantação inicial pode incluir somente sites de equipe de colaboração ou somente os três aplicativos que compõem uma intranet (sites de equipe, 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 limitem o uso do ambiente.
Fornecer acesso para várias classes de usuários, sem comprometer a segurança do conteúdo existente nos aplicativos diferentes. Os usuários de diferentes zonas da rede (interna e externa) com diferentes provedores de autenticação podem participar da colaboração. Além disso, os usuários só podem acessar o conteúdo destinado a eles. Seguindo um design de arquitetura lógica semelhante, você cria a oportunidade para fornecer acesso a usuários de vários locais e com diferentes objetivos. Por exemplo, o design inicial pode ser destinado somente ao acesso de funcionários internos. No entanto, usando um design semelhante, você pode criar a oportunidade para também permitir o acesso de funcionários remotos, funcionários de parceiros e clientes.
Garantir que o design possa ser usado em um ambiente de extranet. As opções de design deliberadas são feitas para garantir que os farms de servidores possam ser implantados com segurança em uma rede de perímetro.
O restante deste artigo aborda cada um dos componentes lógicos que aparecem no modelo (de cima para baixo) e discute as opções de design que são aplicadas ao modelo. O objetivo desta abordagem é demonstrar as diferentes maneiras de configurar os componentes da arquitetura lógica com base no aplicativo.
Farms de servidores
O modelo 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 servidores ilustradas no modelo.
Requisitos de licenciamento
Dica
Os requisitos de licenciamento anteriores especificavam que no mínimo dois servidores eram necessários para a hospedagem de conteúdo da intranet e de sites da Internet (um servidor para cada tipo de licença). Isso não é mais obrigatório. Esta seção foi atualizada para refletir os novos requisitos de licenciamento implementados em setembro de 2008.
Existem duas licenças de servidor disponíveis para o Office SharePoint Server 2007. Essas licenças podem ser combinadas no mesmo computador servidor ou no mesmo farm de servidores:
Microsoft Office SharePoint Server 2007, Licença de Servidor Esta é a licença adequada para o conteúdo da intranet. Essa licença requer o uso de CALs (licenças de acesso para cliente). Se você criar sites para colaboração de parceiros, deverá adquirir o número necessário de CALs para os funcionários dos parceiros.
**Microsoft Office SharePoint Server 2007 para sites da Internet **Esta licença destina-se apenas aos sites da Internet. Ela não requer CALs. Se você criar sites para colaboração de parceiros, não precisará adquirir CALs adicionais. No entanto, não poderá criar sites destinados exclusivamente ao uso dos seus funcionários.
Se você planeja implantar conteúdo interno para a sua organização e conteúdo voltado para a Internet para pessoas que não sejam funcionários a partir do mesmo farm, deverá adquirir ambos os tipos de licença para o farm. Como uma adaptação para possíveis cenários de implantação, os clientes que desejarem consolidar suas necessidades de Office SharePoint Server 2007 uma única implantação podem adquirir licenças para os dois produtos, atribuir essas licenças ao mesmo servidor e usar a mesma instância de execução do software simultaneamente em ambas as licenças. No entanto, os clientes devem adquirir CALs conforme exigido sob os direitos para usuários do Office SharePoint Server 2007 e dispositivos acessando conteúdo de qualquer maneira não permitida no Office SharePoint Server 2007 para direitos de uso de sites da Internet.
Para obter mais informações sobre como os requisitos de licenciamento afetam o número de farms de servidores necessários, consulte Planejar farms de servidores.
Embora somente um farm de servidores seja necessário, o modelo ilustra o uso de dois farms de servidores: um para conteúdo interno e o outro para conteúdo voltado para o cliente. Se você optar por implementar dois farms separados, a opção de design mais crítica é decidir que farm hospedará o aplicativo Partner Web. No modelo, o Farm de Servidores A hospeda o conteúdo da intranet e o Farm de Servidores B hospeda o site da empresa na Internet. De acordo com os termos de licenciamento, qualquer um dos farms pode hospedar o Partner Web.
Com uma opção de dois farms, a orientação geral do design para determinar qual farm deve hospedar um aplicativo Partner Web inclui o seguinte:
Natureza da colaboração Se o objetivo principal de um site de extranet de parceiro for comunicar informações com segurança para muitos parceiros, um farm de servidores da Internet é a opção mais econômica. Por outro lado, se o objetivo principal for a colaboração no trabalho, com um pequeno número de funcionários parceiros, um farm de servidores da intranet pode ser uma opção melhor. Escolha a opção que permita otimizar o farm para sua função pretendida (ou seja, colaboração vs. conteúdo somente leitura).
Número de funcionários parceiros Se você colabora com muitos funcionários parceiros e minimizar o custo é importante, poderá hospedar com segurança tanto o conteúdo de colaboração quanto o anônimo em um farm da Internet com a licença de sites da Internet.
No modelo, o Partner Web destina-se à colaboração intensiva com empresas parceiras, incluindo o desenvolvimento e o preparo do site da empresa na Internet. Colocar a Web do Parceiro no Farm A permite que a organização otimize cada um dos dois farms para seu uso pretendido (colaboração vs. conteúdo somente leitura).
Para obter mais informações sobre como escolher o número de farms adequado à sua organização, inclusive mais detalhes sobre os requisitos de licenciamento, consulte Planejar farms de servidores.
Topologia dos farms de servidores
Cada farm de servidores do modelo é composto de cinco servidores com a seguinte topologia:
Dois servidores Web front-end
Um servidor de aplicativos
Dois servidores de banco de dados, agrupados ou espelhados.
O modelo ilustra a arquitetura lógica do Office SharePoint Server 2007 mostrando que:
Todos os sites são espelhados nos servidores Web front-end.
O site Administração Central é instalado em um servidor de aplicativos para protegê-lo contra o acesso direto dos usuários.
Na realidade, 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 criada independentemente da topologia do farm de servidores. O processo de planejamento de desempenho e capacidade ajudará você a dimensionar o farm de servidores para atender aos objetivos de desempenho e capacidade. Para obter mais informações, consulte Planejar o desempenho e a capacidade (Office SharePoint Server).
Usuários, zonas e autenticação
O modelo ilustra cinco classes diferentes de usuários, cada uma atribuída a uma zona diferente. Em cada aplicativo Web é possível criar até cinco zonas usando um dos nomes de zona disponíveis: Padrão, Intranet, Internet, Personalizada ou Extranet. Um farm que hospede mais de um aplicativo Web pode dar suporte às solicitações do usuário de mais de cinco zonas da rede (até cinco zonas por aplicativo Web). No entanto, o modelo mostra somente cinco zonas.
Usuários e autenticação
O modelo mostra usuários de diferentes zonas da rede ou, no caso de administradores, usuários que têm requisitos de permissões amplamente diferentes. O modelo demonstra como a autenticação é aplicada aos usuários. A tabela a seguir lista a maneira como os usuários são autenticados em cada zona.
| Zona | Usuários | Autenticação |
|---|---|---|
Personalizada |
Administradores |
Kerberos (Integrada do Windows) |
Intranet |
Funcionários internos |
NTLM (Integrada do Windows) |
Padrão |
Funcionários remotos |
NTLM (Integrada do Windows) ou autenticação de formulários com o protocolo LDAP. |
Extranet |
Funcionários de parceiros |
Autenticação de formulários |
Internet |
Clientes |
Anônima |
No modelo, nem todos os usuários recebem acesso aos dois farms de servidores. Em consequência, nenhum dos farms utiliza todas as cinco zonas.
Administradores
A zona Personalizada é usada para acesso administrativo seguro aos sites. Essa abordagem dá oportunidade para:
Implementar um conjunto independente de URLs e diretivas. Por exemplo, os administradores podem usar URLs associadas à zona Personalizada para executar tarefas administrativas de acordo com as diretivas da zona. Eles podem usar as URLs da intranet para todas as outras tarefas, de acordo com as diretivas configuradas para os aplicativos que compõem a intranet. Essa abordagem separa os dois contextos e garante que as permissões de diretivas não entrem em conflito.
Implementar um método mais seguro de autenticação para os administradores. Isso dá mais segurança à solução como um todo.
Autenticar em relação a um provedor diferente, em cenários nos quais o suporte aos sites é dado por um fornecedor externo.
O modelo considera que os administradores sejam funcionários da Fabrikam e que tenham acesso interno à rede. O modelo incorpora o uso da autenticação Integrada do Windows para administradores (ou seja, autenticação Kerberos ou NTLM).
Funcionários internos
A zona Intranet é usada para acesso de funcionários internos. A autenticação Integrada do Windows é usada.
Funcionários remotos
A zona Padrão é usada para acesso de funcionários remotos. As metas de design no modelo são:
Autenticar em relação ao ambiente interno do serviço de diretório do Active Directory.
Simplificar o gerenciamento de permissões usando autenticação do Windows tanto para funcionários internos quanto remotos. Essa meta é importante porque, se os usuários se conectarem a sites por meio de dois provedores de autenticação diferentes, o Office SharePoint Server 2007 criará duas contas diferentes para cada usuário, e cada uma das duas contas deverá ter permissões.
O modelo apresenta duas opções diferentes para autenticar funcionários remotos. Com a primeira opção (autenticação Integrada do Windows usando NTLM), as duas metas de design são atingidas. A segunda opção (autenticação de formulários) satisfaz a primeira meta, mas não a segunda. Consequentemente, a primeira opção é o método preferido.
A tabela a seguir resume as diferenças entre essas duas abordagens.
| Esse método de autenticação | Autenticação Integrada do Windows usando NTLM | Autenticação de formulários usando um provedor LDAP |
|---|---|---|
Como funciona |
Este método usa o ISA (Internet Security and Acceleration) Server 2006 ou o Intelligent Application Gateway (IAG 2007) para autenticar usuários e enviar as credenciais do usuário ao Office SharePoint Server 2007. Esses servidores usam a autenticação de formulários para autenticar usuários em relação ao ambiente do Active Directory. Em seguida, eles encaminham as credenciais do Windows para o Office SharePoint Server 2007. Para obter mais informações, consulte os seguintes recursos:
Como a zona é a Padrão, a autenticação NTLM é usada para satisfazer um requisito do componente de índice. Para obter mais informações, consulte "Requisitos de configuração da zona Padrão", mais adiante neste artigo. |
O Office SharePoint Server 2007 utiliza a autenticação de formulários com um provedor LDAP para autenticar funcionários remotos em relação ao ambiente interno do Active Directory. Se este método for escolhido, verifique se o componente de índice pode autenticar por meio de uma zona alternativa. Para obter mais informações, consulte "Requisitos de configuração da zona Padrão", mais adiante neste artigo. |
Vantagens |
O Office SharePoint Server 2007 não cria duas contas diferentes para usuários que trabalham interna e remotamente. Isso simplifica bastante o gerenciamento de permissões. |
Não requer um servidor proxy para autenticar usuários e encaminhar credenciais. |
Desvantagens |
Requer coordenação adicional do ISA Server 2006, bem como sua configuração, ou outro produto de servidor proxy. |
Se os usuários se conectarem ao Office SharePoint Server 2007 interna e remotamente, serão criadas duas contas de usuário diferentes no Office SharePoint Server 2007. Consequentemente, as duas contas requerem permissões para sites e documentos. Os funcionários podem criar potencialmente dois Meus Sites. Os funcionários precisarão gerenciar as permissões de seus próprios sites e documentos para as duas contas de usuário, caso pretendam trabalhar na rede interna e remotamente. |
Funcionários de parceiros
Os funcionários de parceiros acessam a rede por meio da zona Extranet e são autenticados com o uso da autenticação de formulários. Isso requer um diretório e provedor separados, como o banco de dados e o provedor do Microsoft SQL Server, para armazenar contas de parceiro na extranet. Vantagens dessa abordagem: você pode gerenciar contas de parceiro separadamente, e não é necessário adicionar contas de parceiro ao diretório de funcionários internos.
Como alternativa, você pode usar o SSO (logon único) da Web para autenticar em relação ao diretório próprio de um parceiro. No entanto, essa abordagem requer uma zona separada para cada diretório de parceiro.
Como o modelo considera que a Fabrikam está trabalhando com parceiros de várias empresas diferentes no mesmo aplicativo de parceiro, a autenticação de formulários é utilizada. O diretório e o provedor não são especificados.
Clientes
A zona Internet é usada para acesso do cliente. Ela é configurada para permitir o acesso anônimo com permissões somente leitura.
Zonas
Quando você cria zonas, várias decisões importantes são críticas para o sucesso da implantação. Essas decisões incluem decisões de criação e configuração das seguintes zonas:
A zona Padrão.
Zonas para acesso externo.
As seções a seguir descrevem as decisões que são incorporadas no modelo.
Requisitos de configuração da zona padrão
A zona que envolve a maior consideração é a zona Padrão. O Office SharePoint Server 2007 estabelece os seguintes requisitos para a maneira como a zona Padrão é configurada:
Quando uma solicitação do usuário não puder ser associada a uma zona, a autenticação e as diretivas da zona Padrão serão aplicadas. Portanto, a zona Padrão deve ser a mais segura.
O componente de índice requer acesso ao conteúdo por meio de pelo menos uma zona, para rastrear o conteúdo. Por padrão, o componente de índice usa a autenticação NTLM. O administrador de SSP pode configurar as regras de rastreamento para que usem a autenticação Básica ou um certificado de cliente ao rastrear um determinado intervalo de URLs. Consequentemente, para rastrear o conteúdo, pelo menos uma das zonas deve estar configurada para usar a autenticação NTLM, a autenticação Básica ou os certificados. Além disso, o rastreador sondará as zonas na seguinte ordem, até encontrar uma que ele possa autenticar: zona padrão, zona intranet, zona Internet, zona personalizada, zona extranet. No entanto, se o rastreador encontrar primeiro uma zona que esteja configurada para usar a autenticação Kerberos, ele não autenticará e não tentará acessar a próxima zona. Portanto, verifique se a configuração de zonas que utilizam a autenticação Kerberos não impede que o componente de índice rastreie o conteúdo. Para obter mais informações sobre os requisitos de autenticação relacionados ao rastreamento de conteúdo, consulte Planejar métodos de autenticação (Office SharePoint Server).
Um email administrativo é enviado com links da zona Padrão. Inclui email para proprietários de sites que estejam para atingir limites de cota. Consequentemente, os usuários que receberem esse tipo de email e alertas devem poder acessar links através da zona Padrão. Isso é importante principalmente para os proprietários de site.
Conjuntos de sites nomeados pelo host só estão disponíveis por meio da zona Padrão. Todos os usuários que devem ter acesso aos conjuntos de sites nomeados pelo host devem ter acesso por meio da zona Padrão.
No modelo, a zona Padrão é usada para acesso de funcionários remotos pelos seguintes motivos:
Os funcionários podem acessar links em emails administrativos, independentemente da sua localização.
Nomes de servidor e URLs internos são protegidos contra exposição quando a zona associada a uma solicitação de usuário não pode ser determinada. Como a zona Padrão já está configurada para funcionários remotos, as URLs não expõem dados confidenciais quando essa zona é aplicada.
Configurando zonas para um ambiente de extranet
Em um ambiente de extranet, o design das zonas é crítico pelos seguintes motivos:
As solicitações do usuário podem ser iniciadas em várias redes diferentes. No modelo, os usuários iniciam as solicitações na rede interna, na Internet e em empresas parceiras.
Os usuários consomem conteúdo por meio de vários aplicativos Web. No modelo, a intranet é composta de três aplicativos Web diferentes. Além disso, os funcionários internos e remotos potencialmente podem fazer contribuições de conteúdo e administrá-lo em todos os aplicativos Web: intranet, Partner Web e o site corporativo na Internet.
Em um ambiente de extranet, verifique se os seguintes princípios de design são seguidos:
Configurar zonas em vários aplicativos Web para espelhar uns aos outros. A configuração da autenticação e dos usuários pretendidos deve ser igual. No entanto, as diretivas associadas às zonas podem ser diferentes nos aplicativos Web. Por exemplo, verifique se a zona intranet é usada para os mesmos funcionários em todos os aplicativos Web. Ou seja, não configure a zona Intranet para funcionários internos em um aplicativo Web e para funcionários remotos em outro.
Configurar mapeamentos de acesso alternativo de forma adequada e precisa para cada zona e cada recurso.
No modelo, a zona Padrão de cada aplicativo Web está configurada de forma idêntica para acesso de funcionários remotos. Além disso, a zona Intranet está configurada de forma idêntica em todos os aplicativos Web para acesso de funcionários internos. As zonas Extranet e Internet estão configuradas para apenas um aplicativo Web.
Os mapeamentos de acesso alternativo são criados automaticamente quando você cria a zona. No entanto, o Office SharePoint Server 2007 pode ser configurado para rastrear conteúdo em recursos externos, como um compartilhamento de arquivos. Os links para esses recursos externos devem ser criados manualmente para cada zona com o uso de mapeamentos de acesso alternativo. Por exemplo, um compartilhamento de arquivos pode ser exposto aos usuários internos com uma URL interna (arquivo://). O mesmo compartilhamento de arquivos pode ser exposto como um link FTP aos usuários externos (ftp://). Isso garante que esses recursos estejam disponíveis para os usuários de acordo com o contexto de sua zona. Quando os usuários recebem links para esses recursos nos resultados de pesquisa, os links estão acessíveis.
Se as zonas nos aplicativos Web não espelharem umas às outras e os links para recursos externos não forem adequados, os riscos incluem:
Os nomes de servidor, nomes DNS (sistema de nomes de domínio) e endereços IP podem ser potencialmente expostos fora da rede interna.
Os usuários talvez não possam acessar sites e outros recursos.
SSPs
Um SSP fornece um conjunto de serviços comuns e dados de serviço para um agrupamento lógico de aplicativos Web e seus sites associados. Os serviços e os dados de serviço incluem:
Serviços de personalização
Públicos-alvo
Catálogo de Dados Corporativos
Serviços do Excel
Office SharePoint Server Search
Relatório de uso do portal
O critério mais importante que determina se é necessário mais de um SSP na arquitetura lógica é se você precisa isolar o conteúdo. Por exemplo, se o farm de servidores hospedar aplicativos para mais de uma classe de usuários, SSPs separados poderão ajudar a criar o isolamento entre essas classes de usuários.
O modelo incorpora um SSP separado para cada um dos seguintes aplicativos:
Intranet
Partner Web
Site do cliente na Internet
.gif "Modelo de SSP para implantação corporativa")
Intranet
Os três aplicativos individuais que compõem a intranet — conteúdo de intranet publicado, Meus Sites e sites de equipe — são reunidos por um SSP. O aplicativo de intranet ilustrado no modelo fornece um exemplo de balanceamento de isolamento seguro com a necessidade de a empresa compartilhar informações e usar dados de perfil nos aplicativos.
Os aplicativos individuais são isolados por aplicativos Web e pools de aplicativos. Os pools de aplicativos separados fornecem isolamento do processo. Os aplicativos Web dedicados dão a oportunidade de implementar diferentes diretivas de permissão para cada tipo de conteúdo.
A unificação dos três aplicativos em um SSP fornece personalização e pesquisa em toda a empresa em todos os aplicativos.
.jpg "Arquitetura de Provedor de Serviços Compartilhados")
Partner Web
A utilização de um SSP separado para o aplicativo Partner Web garante que os usuários parceiros não possam pesquisar ou acessar informações confidenciais no ambiente de intranet. O SSP pode ser configurado para isolar ainda mais o conteúdo entre conjuntos de sites das seguintes formas:
Limitar os escopos de pesquisa aos conjuntos de site individuais.
Usar públicos-alvo para direcionar conteúdo para determinados grupos de usuários.
Usar a ferramenta de linha de comando Stsadm para configurar o People Picker para exibir somente usuários que sejam membros do conjunto de sites. Nessa configuração, você poderá adicionar qualquer usuário do diretório, se souber o nome do usuário; no entanto, apenas os usuários que já foram adicionados ao conjunto de sites são exibidos no People Picker. Isso evita que usuários parceiros naveguem no diretório de usuários por meio do People Picker.
Use o comando a seguir para ativar essa configuração;
Stsadm.exe -o setproperty –url https://server –pn “peoplepicker-onlysearchwithinsitecollection” –pv yes
Use o comando a seguir para desativar essa configuração;
Stsadm.exe -o setproperty –url https://server –pn “peoplepicker-onlysearchwithinsitecollection” –pv no
Além da configuração de serviços no SSP para conseguir o isolamento, considere configurar permissões das seguintes formas:
Limitar o acesso aos sites a usuários ou grupos específicos.
Usar grupos do SharePoint para autorizar o acesso ao conteúdo.
Site da empresa na Internet
No modelo, o site da empresa na Internet está disponível para usuários anônimos. Os sites destinados aos usuários anônimos sempre devem ser separados dos sites destinados aos usuários autenticados. O modelo usa os seguintes métodos de isolamento para o site da empresa na Internet:
Pools de aplicativos separados garantem o isolamento do processo.
Aplicativo Web separado dá a oportunidade de direcionar diretivas.
SSP dedicado garante que os resultados da pesquisa sejam limitados ao aplicativo anônimo.
Sites de administração
No modelo, cada site de administração é hospedado dentro de um pool de aplicativos dedicado e um aplicativo Web. A lista a seguir descreve cada um dos sites de administração:
Sites de administração de serviços compartilhados O modelo ilustra um site de administração dedicado para cada SSP. Os sites de administração de serviços compartilhados não podem ser isolados em um único servidor ou conjunto de servidores. Esses sites são automaticamente espelhados em todos os servidores Web front-end.
Sites da Administração Central No modelo, o site Administração Central de cada farm de servidores é hospedado em um servidor de aplicativos. Isso protege o site contra o contato direto do usuário. Se um afunilamento no desempenho ou um comprometimento da segurança afetar a disponibilidade dos servidores Web front-end, o site Administração Central continuará disponível.
As URLs com balanceamento de carga dos sites de administração não são articuladas no modelo ou neste artigo. As recomendações incluem:
Se forem usados números de porta em URLs administrativas, use portas não-padrão. Os números de porta são incluídos nas URLs por padrão. Embora esses números em geral não sejam usados em URLs voltadas para o cliente, o seu uso em sites de administração pode aumentar a segurança limitando o acesso a esses sites às portas não-padrão.
Permitir o acesso aos sites de administração somente a partir de um domínio administrativo.
Criar entradas de DNS separadas para sites de administração.
Além dessas recomendações, você pode equilibrar a carga do site da Administração Central em vários servidores de aplicativos para conseguir redundância.
Pools de aplicativos
Os pools de aplicativos separados dos Serviços de Informações da Internet (IIS) em geral são implementados para conseguir o isolamento de processos entre o conteúdo. Os pools de aplicativos fornecem uma maneira de executar vários sites no mesmo computador servidor, porém mantendo seus próprios processos de trabalho e a sua identidade. Isso reduz uma exploração em um site que dê oportunidade para um invasor injetar código no servidor para atacar outros sites.
Na prática, considere usar um pool de aplicativos dedicado em cada um dos seguintes cenários:
Para separar o conteúdo autenticado do conteúdo anônimo.
Para isolar aplicativos que armazenem senhas para aplicativos de negócios externos ou que interajam com eles (por exemplo, conexões com o Catálogo de Dados Corporativos).
Para isolar aplicativos nos quais os usuários têm grande liberdade para criar e administrar sites e para colaborar no conteúdo.
O modelo usa pools de aplicativos da seguinte forma:
Cada site de administração é hospedado em um pool de aplicativos dedicado. Esse é um requisito do Office SharePoint Server 2007.
O conteúdo da intranet é dividido em dois pools de aplicativos diferentes. O conteúdo de colaboração (Meus Sites e sites de equipe) é hospedado em um pool de aplicativos. O conteúdo da 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 as conexões de dados corporativos são mais provavelmente utilizadas. Por exemplo, muitos sites de RH (recursos humanos) utilizam conexões de dados corporativos para permitir que os funcionários acessem seus dados pessoais.
O aplicativo Partner Web é hospedado em um pool de aplicativos dedicado.
O site da empresa na Internet é hospedado em um pool de aplicativos dedicado no Farm B. Se esse farm também precisasse hospedar conteúdo para colaboração de parceiros, esses dois tipos de conteúdo (Internet e parceiro) seriam hospedados em dois pools de aplicativos diferentes.
Aplicativos Web
O aplicativo Web é um site do IIS criado e utilizado pelos Produtos e Tecnologias do SharePoint. Cada aplicativo Web é representado por um site diferente no IIS. Você atribui a cada aplicativo Web um único nome de domínio, o qual ajuda a evitar ataques de script entre sites.
Em geral, use os aplicativos Web para:
Separar o conteúdo anônimo do conteúdo autenticado. No modelo, o site da empresa na Internet é hospedado em um aplicativo Web e um pool de aplicativos dedicados.
Isolar usuários. No modelo, o Partner Web é hospedado em um aplicativo Web e um pool de aplicativos dedicados para garantir que os parceiros não tenham acesso ao conteúdo da intranet.
Impor permissões. Um aplicativo Web dedicado dá a oportunidade de impor permissões por diretivas através da utilização da página Política para aplicativos Web na da Administração Central. Por exemplo, é possível criar uma diretiva no site da empresa na Internet para negar explicitamente o acesso de gravação a um ou mais grupos de usuários. As diretivas de um aplicativo Web são impostas independentemente das permissões configuradas nos sites ou documentos individuais no aplicativo Web.
Otimizar o desempenho. Os aplicativos conseguem ter um desempenho melhor se forem colocados em aplicativos Web com outros aplicativos que tenham características de dados semelhantes. Por exemplo, as características de dados de Meus Sites incluem um grande número de sites de tamanho pequeno. Por outro lado, os sites de equipe em geral abrangem um número menor de sites muito grandes. Colocando esses dois tipos de sites diferentes em aplicativos Web separados, os bancos de dados resultantes são compostos de dados com características semelhantes, o que otimiza o desempenho do banco de dados. No modelo, Meus Sites e os sites de equipe não têm requisitos de isolamento de dados exclusivos — eles compartilham o mesmo pool de aplicativos. Apesar disso, Meus Sites e os sites de equipe são colocados em aplicativos Web separados para otimizar o desempenho.
Otimizar a flexibilidade de gerenciamento. Como a criação de aplicativos Web separados resulta em sites e bancos de dados separados, você pode implementar diferentes limites de site (lixeira, vencimento e tamanho) e negociar diferentes acordos de serviço. Por exemplo, é possível permitir mais tempo para restaurar o conteúdo do Meu Site se esse não for o tipo de conteúdo mais crítico da sua organização. Isso permite que você restaure o conteúdo mais crítico antes de restaurar o conteúdo do Meu Site. No modelo, Meus Sites são colocados em um aplicativo Web separado para permitir que os administradores gerenciem de forma mais agressiva o crescimento, em comparação com outros aplicativos.
Conjuntos de sites
Os conjuntos de sites ligam a arquitetura lógica e a arquitetura de informação. As metas de projeto dos conjuntos de sites no modelo são: satisfazer os requisitos de design de URL e criar divisões lógicas de conteúdo.
Para satisfazer os requisitos de design de URL, cada aplicativo Web inclui um único conjunto de sites no nível raiz. Os caminhos gerenciados são usados para incorporar uma segunda camada de conjuntos de sites de nível superior. Para obter mais informações sobre os requisitos de URL e sobre como usar caminhos gerenciados, consulte "Zonas e URLs", mais adiante neste artigo. Além da segunda camada de conjuntos de sites, cada site é um subsite.
A figura a seguir mostra a hierarquia de Sites de Equipe.
.jpg "Arquitetura lógica para sites de colaboração")
Devido ao requisito de um conjunto de sites no nível raiz, as decisões de design giram em torno da segunda camada de conjuntos de sites. O modelo incorpora opções baseadas na natureza do aplicativo.
Conteúdo da intranet publicado
A pressuposição para o aplicativo de conteúdo da intranet publicado é que várias divisões da empresa hospedarão o conteúdo publicado. No modelo, o conteúdo de cada divisão é hospedado em um conjunto de sites separado. Isso permite as seguintes vantagens:
Cada divisão pode gerenciar e permitir seu conteúdo de forma independente.
O conteúdo de cada divisão pode ser armazenado em um banco de dados dedicado.
Entre as desvantagens de usar vários conjuntos de sites estão:
Páginas mestras, layouts de página, modelos, Web Parts e navegação não podem ser compartilhados entre os conjuntos de sites.
Dá mais trabalho coordenar as personalizações e a navegação entre os conjuntos de sites.
Dependendo da arquitetura e do design das informações do aplicativo de intranet, o conteúdo publicado pode aparecer para o usuário como um aplicativo de conexão contínua. Como alternativa, cada conjunto de sites pode aparecer como um site separado.
Meus Sites
Meus Sites têm características distintas e as recomendações para implantar Meus Sites são simples. No modelo, o aplicativo Meu Site incorpora um site de nível superior com a URL http://my. O primeiro conjunto de sites de nível superior criado utiliza o modelo Host de Meu Site. Um caminho gerenciado é incorporado (usando inclusão de caracteres 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 do usuário é anexado à URL, na forma http://my personal/nome_do_usuário. A figura a seguir ilustra Meus Sites.
.jpg "Arquitetura de rede lógica para Meus Sites")
Para obter mais informações sobre como criar um aplicativo Meus Sites, consulte Criar a arquitetura de Meus Sites.
Sites de equipe
Você pode usar uma destas duas abordagens para criar conjuntos de sites em um aplicativo Site de Equipe:
Permitir que as equipes criem conjuntos de sites por meio da criação de site pessoal. A vantagem dessa abordagem é que as equipes podem criar um site com facilidade, conforme necessário, sem precisar da ajuda de um administrador. No entanto, são muitas as desvantagens, incluindo:
Você perde a oportunidade de implementar uma taxonomia atenciosa.
O aplicativo pode se tornar difícil de gerenciar.
Os sites são abandonados facilmente.
Você não pode compartilhar modelos e navegação entre projetos ou equipes que, de outra forma, poderiam compartilhar um conjunto de sites.
Criar um número finito de conjuntos de sites para a sua organização, com base na maneira como ela opera. Nesta abordagem, os conjuntos de sites são criados por um administrador do SharePoint. Depois da criação de um conjunto de sites, as equipes podem criar sites no conjunto de sites com base em suas necessidades. Essa abordagem dá a oportunidade de implementar uma taxonomia atenciosa, que fornece a estrutura para a maneira como os sites de equipe são gerenciados e se desenvolvem. Além disso, há mais oportunidades de compartilhar modelos e navegação entre projetos e equipes que compartilham um conjunto de sites.
O modelo incorpora a segunda abordagem, que resulta em uma hierarquia de conjuntos de sites semelhante para sites de equipe, como ocorre para o conteúdo da intranet publicado. O desafio para os arquitetos da informação é criar uma segunda camada de conjuntos de sites que faça sentido para a organização. A tabela a seguir lista as sugestões para diferentes tipos de organizações.
| Tipo de organização | Sugestões de taxonomias para os conjuntos de sites |
|---|---|
Desenvolvimento de produtos |
|
Pesquisa |
|
Instituição de educação superior |
|
Agência de legislação estadual |
|
Escritório jurídico corporativo |
|
Fabricação |
|
Partner Web
O Partner Web destina-se ao uso na colaboração com parceiros externos em projetos com escopos ou durações finitos. Pelo design, os sites existentes no aplicativo Partners Web não devem ser relatados. Os requisitos para o Partner Web incluem a garantia de que:
Os proprietários de projeto possam criar sites com facilidade para colaboração com parceiros.
Os parceiros e outros colaboradores tenham acesso somente ao projeto em que estão trabalhando.
As permissões sejam gerenciadas pelos proprietários dos sites.
Os resultados de pesquisa oriundos de um projeto não exponham conteúdo de outros projetos.
Os administradores possam identificar facilmente os sites que não são mais usados e excluí-los.
Para atender a esses requisitos, o modelo incorpora um conjunto de sites para cada projeto. Dessa maneira, ocorrem os seguintes benefícios:
Os conjuntos de sites individuais fornecem o nível adequado de isolamento entre projetos.
A criação de site pessoal pode ser implementada.
Como o aplicativo Partner Web também hospeda os conjuntos de sites para desenvolvimento de conteúdo para o site da empresa na Internet, são criados conjuntos de sites separados para criação e preparo.
Site da empresa na Internet
O site da empresa na Internet incorpora um único conjunto de sites no nível raiz. Todos os sites abaixo desse conjunto de sites são subsites. Essa estrutura simplifica as URLs de páginas no site. A figura a seguir mostra a arquitetura do site da empresa na Internet.
.jpg "Arquitetura de implantação lógica")
Bancos de dados de conteúdo
Você pode usar estas duas abordagens para incorporar bancos de dados de conteúdo no design (o modelo incorpora as duas abordagens):
Estabelecer tamanhos de destino para os bancos de dados de conteúdo com limites de aviso de tamanho adequados. Criar um novo banco de dados quando esses limites forem atingidos. Com essa abordagem, os conjuntos de sites são adicionados automaticamente a um ou mais bancos de dados disponíveis, com base apenas nos tamanhos de destino.
Associar conjuntos de sites a bancos de dados de conteúdo específico. Essa abordagem permite colocar um ou mais conjuntos de sites em um banco de dados dedicado que possa ser gerenciado independentemente do restante.
Ao optar por associar conjuntos de sites a bancos de dados de conteúdo específico, você poderá usar os seguintes métodos para isso:
Usar a ferramenta de linha de comando Stsadm para criar um conjunto de sites em um banco de dados específico.
Dedicar 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 que um evento de aviso seja gerado = 1
Número máximo de sites que podem ser criados no banco de dados = 1
Adicionar um grupo de conjuntos de sites a um banco de dados dedicado executando as seguintes etapas:
No aplicativo Web, criar o banco de dados e definir o seu status como Pronto.
Definir o status de todos os outros bancos de dados como Offline. Enquanto os bancos de dados de conteúdo estiverem offline, novos conjuntos de sites não poderão ser criados. No entanto, os conjuntos de sites existentes nos bancos de dados offline ainda poderão ser acessados para operações de leitura e gravação.
Criar os conjuntos de sites. Eles são adicionados automaticamente ao banco de dados.
Definir o status de todos os outros bancos de dados como Pronto.
Conteúdo da intranet publicado
Para conteúdo da intranet publicado, o modelo incorpora um banco de dados dedicado para cada um dos conjuntos de sites de departamento.
Essa abordagem permite que cada departamento gerencie seu conteúdo de forma independente.
Meus Sites
Para Meus Sites, o modelo consegue eficiência de escala gerenciando bancos de dados até o tamanho de destino máximo. As seguintes configurações são definidas para atingir esse objetivo:
Limitar o armazenamento do site a no máximo Esta configuração, que você define na página Modelos de Cota na Administração Central, limita o tamanho de um site pessoal.
Lixeira de Segundo Estágio Esta configuração, que você define na página Configurações Gerais do Aplicativo Web, determina a quantidade de espaço adicional que é alocado para a lixeira de segundo estágio.
Número máximo de sites que podem ser criados neste banco de dados Esta configuração é definida quando você cria um banco de dados. Calcule o tamanho total permitido para sites usando os números que você especificou para os dois valores anteriores. Em seguida, com base no tamanho de destino de cada banco de dados, determine quantos sites caberão no banco de dados.
O modelo fornece as seguintes configurações de tamanho de exemplo, com base em um tamanho de destino de banco de dados de 100 gigabytes (GB) e um tamanho de destino do Meu Site de 500 megabytes (MB):
Limites de tamanho por site = 500 MB
Tamanho de destino do banco de dados = 100 GB
Número máximo de sites = 200
Aviso do Nível de Site = 150
Quando o aviso do nível de site for atingido, crie um novo banco de dados. Depois de ter criado o novo banco de dados, novos Meus Sites serão adicionados alternadamente ao novo banco de dados, e ao banco de dados existente, até que o número máximo de sites de um dos bancos de dados seja atingido.
Para obter mais informações sobre como criar configurações de banco de dados para Meus Sites, consulte Criar a arquitetura de Meus Sites.
Sites de equipe
Para sites de equipe, o modelo incorpora um banco de dados dedicado para cada um dos conjuntos de sites de equipe. Essa abordagem permite gerenciar o banco de dados de cada equipe independentemente para backup, restauração e migração. Além disso, quando um projeto tiver sido concluído, você poderá arquivar facilmente o banco de dados associado ao projeto.
Partner Web
Assim como em Meus Sites, o Partner Web consegue eficiência na escala gerenciando bancos de dados até o tamanho de destino máximo. Porém, no modelo, o Partner Web também hospeda os conjuntos de sites de criação e preparo do site da empresa na Internet. Consequentemente, o design do banco de dados incorpora as duas abordagens:
A criação e o preparo de conjuntos de sites são hospedados 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 o Partner Web é hospedado em um aplicativo Web dedicado, você pode criar limites de tamanho que sejam mais adequados aos tipos de tamanhos criados. O modelo fornece as seguintes configurações de tamanho de exemplo:
Tamanho de destino do banco de dados = 100 GB
Cota de armazenamento por site = 5 GB
Número máximo de sites = 20
Criação e Preparo de conjuntos de sites hospedados em bancos de dados dedicados
Site da empresa na Internet
Usando um único conjunto de sites no design do site da empresa na Internet, você usa um único banco de dados para esse aplicativo Web.
Zonas e URLs
O modelo ilustra como coordenar URLs em vários aplicativos de uma implantação corporativa.
Metas de design
As seguintes metas influenciam as decisões do design de URLs:
As convenções de URL não limitam as zonas por meio das quais o conteúdo pode ser acessado.
As portas HTTP e HTTPS padrão (80 e 443) podem ser usadas em todos os aplicativos do modelo.
Os números de porta não são incluídos nas URLs. Na prática, em geral eles não são utilizados em ambientes de produção.
Princípios de design
Para atingir as metas de design, os seguintes princípios de design são aplicados:
Conjuntos de sites com nomes do host não são usados. Observe que esses conjuntos de sites são diferentes dos cabeçalhos de host do IIS. Os conjuntos de sites com nomes do host não funcionam com o recurso de mapeamentos de acesso alternativo. Esse recurso é necessário para acessar o mesmo conteúdo por meio de várias URLs de domínio. Consequentemente, quando os sites com nome do host são usados, eles só estão disponíveis por meio da zona Padrão. O recurso de mapeamento de acesso alternativo também dá suporte para terminação externa do protocolo SSL, permitindo que os cenários de acesso de funcionários remotos e acesso de parceiros utilizem SSL (https).
Cada aplicativo incorpora um único conjunto de sites raiz. Esse é um requisito para usar mapeamentos de acesso alternativo. Se forem necessários vários conjuntos de sites raiz em um aplicativo Web e se você tiver a intenção de usar somente a zona Padrão para acesso do usuário, os conjuntos de sites com nome do host sã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 modelo incorpora os caminhos gerenciados. Esses caminhos proporcionam um controle maior sobre as URLs desses tipos de sites.
Compensações do design
O cumprimento das metas de design resulta em algumas compensações, inclusive as seguintes:
URLs mais longas.
Conjuntos de sites com o nome do host não são usados.
Criando URLs com balanceamento de carga
Ao criar um aplicativo Web, você deve escolher uma URL com balanceamento de carga para atribuir a ele. Além disso, é necessário criar uma URL com balanceamento de carga para cada zona que você criar no aplicativo Web. A URL com balanceamento de carga inclui protocolo, esquema, nome do host e porta, se usada. Essa URL deve ser exclusiva entre todos os aplicativos Web e zonas. Consequentemente, cada aplicativo e cada zona dentro de cada aplicativo requer uma URL exclusiva no modelo.
Intranet
Cada um dos três aplicativos que compõem a intranet requer uma URL exclusiva. No modelo, o público-alvo do conteúdo da intranet são os funcionários internos e remotos. A tabela a seguir lista as URLs para que os funcionários internos e remotos acessem cada aplicativo.
| Aplicativo | URL de funcionário interno | URL de funcionário remoto |
|---|---|---|
Conteúdo da 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 |
Partner Web
No modelo, o Partner Web é acessado por funcionários internos, remotos e de parceiros. Embora tanto os funcionários remotos quanto os funcionários de parceiros acessem o Partner Web externamente usando SSL (https), cada um requer uma URL diferente para aplicar os benefícios da utilização de zonas separadas — isto é, diferentes métodos de autenticação e diretivas de zona diferentes. A tabela a seguir lista as URLs que os funcionários internos, remotos e parceiros utilizam para acessar o Partner Web.
| 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 é público e pode ser acessado por qualquer usuário com a utilização da URL padrão: http://www.fabrikam.com. As diretivas da zona Internet são aplicadas (isto é, acesso anônimo e negar gravação).
No entanto, para dar suporte às tarefas de administração e criação no site público, o modelo incorpora URLs para funcionários internos e remotos. As diretivas dessas zonas limitam permissões acima de acesso de leitura para grupos de segurança de destino. A tabela a seguir lista 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 caractere curinga para caminhos de URL
Ao definir caminhos gerenciados, você pode especificar quais caminhos no namespace de URL de um aplicativo Web são usados para conjuntos de sites. É possível especificar que existe um ou mais conjuntos de sites em um caminho distinto abaixo do site raiz. Sem os caminhos gerenciados, todos os sites criados abaixo do site raiz fazem parte do conjunto de sites raiz.
Você pode criar estes dois tipos de caminhos gerenciados:
Inclusão explícita Um conjunto de sites com a URL explícita que você atribuir. Uma inclusão explícita é aplicada a apenas um conjunto de sites. Você pode criar muitas inclusões explícitas abaixo de um conjunto de sites raiz. Exemplo de URL para um conjunto de sites criado com esse método: http://fabrikam/hr.
Inclusão de caractere curinga Um caminho adicionado à URL. Ele indica que todos os sites especificados diretamente depois do nome do caminho são conjuntos de sites exclusivos. Essa opção geralmente é usada para aplicativos que dão suporte à criação de site pessoal, como Meus Sites. Exemplo de URL para um conjunto de sites criado com esse método: http://my/personal/user1.
O modelo incorpora o uso dos dois tipos, conforme descrito nas próximas seções.
Inclusões explícitas: Sites de equipe e conteúdo da intranet publicado
No modelo, tanto o aplicativo de sites de equipe quanto os aplicativos de conteúdo da intranet publicado incorporam o uso de inclusões explícitas.
Sites de equipe
No aplicativo Sites de Equipe, uma inclusão explícita é usada para cada conjunto de sites de equipe. O limite de escala em conjuntos de sites criados com uma inclusão explícita é de 100 sites. As boas práticas de gerenciamento recomendam que você mantenha o número de sites de equipe de nível superior dentro de um limite gerenciável. Além disso, a taxonomia dos sites de equipe deve ser lógica para o modo de operação da sua empresa. Muitas organizações se adaptam bem à recomendação de 100 sites. Caso a sua empresa precise de uma escala maior para sites de equipe, utilize uma inclusão de caractere curinga.
No modelo, o uso de inclusões explícitas resulta nas URLs da tabela a seguir.
| Funcionário interno (zona intranet) | Funcionário remoto (zona Padrão) |
|---|---|
http://team/Team1 |
https://team.fabrikam.com/Team1 |
http://team/Team2 |
https://team.fabrikam.com/Team2 |
http://team/Team3 |
https://team.fabrikam.com/Team3 |
Nesse exemplo, o conjunto de sites raiz, http://team, não hospeda necessariamente o conteúdo dos usuários.
Conteúdo da intranet publicado
No aplicativo de conteúdo da intranet publicado, uma inclusão explícita é usada para cada subsite: RH, Instalações e Compras. Isso permite que cada um desses sites seja gerenciado de forma independente. Cada um desses conjuntos de sites pode ser associado a um banco de dados de conteúdo diferente, se necessário, para gerenciar o crescimento e dar oportunidade para fazer backup e restaurar esses sites separadamente.
No modelo, o uso de inclusões explícitas resulta nas URLs da tabela a seguir.
| Funcionário interno (zona 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 |
Neste exemplo, o conjunto de sites raiz, http://fabrikam, representa a home page padrão da intranet. O objetivo desse site é hospedar conteúdo para os usuários.
Inclusões de caractere curinga: Partner Web e Meus Sites
Tanto o Partner Web quanto Meus Sites incorporam o uso de uma inclusão de caractere curinga. Essas inclusões são ideais para aplicativos que permitem aos usuários criar seus próprios conjuntos de sites. Uma inclusão de caractere curinga indica que o item após o caractere curinga é um site raiz de um conjunto de sites.
Meus Sites
Meus Sites oferece a criação de site pessoal. Quando um usuário que está navegando na intranet clica pela primeira vez em Meu Site, um Meu Site é criado automaticamente para ele. No modelo, Meus Sites adiciona uma inclusão de caractere curinga chamada /personal (http://my/personal). O recurso Meu Site anexa automaticamente o nome do usuário à URL.
Isso resulta em URLs no formato listado na tabela a seguir.
| Interno (zona Intranet) | Funcionário remoto (zona Padrão) |
|---|---|
http://my/sites/user1 |
https://my.fabrikam.com/personal/user1 |
http://my/sites/user2 |
https://my.fabrikam.com/personal/user2 |
http://my/sites/user3 |
https://my.fabrikam.com/personal/user3 |
Partner Web
A Partner Web é criada para permitir que os funcionários criem sites seguros com facilidade para colaboração com parceiros externos. Para dar suporte a esse objetivo, a criação de site pessoal é permitida.
No modelo, a Partner Web adiciona uma inclusão de caractere curinga chamada /sites (http://partnerweb/sites). Isso resulta em URLs no formato listado na tabela a seguir.
| Funcionário interno (zona 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 colaboradores parceiros podem acessar sites do Partner Web usando as URLs listadas na tabela a seguir.
| Parceiro (zona Extranet) |
|---|
https://partnerweb.fabrikam.com/sites/project1 |
https://partnerweb.fabrikam.com/sites/project2 |
https://partnerweb/fabrikam.com/sites/project3 |
A exceção para Partner Web, conforme ilustra o modelo, são os dois conjuntos de sites dedicados à criação e ao preparo de conteúdo para o site da empresa na Internet. Para esses dois conjuntos de sites, uma inclusão explícita é usada. Isso fornece um exemplo de uso de inclusões explícitas e de inclusões de caractere curinga no mesmo aplicativo Web.
URLs de administração
A tabela a seguir lista as URLs da zona de administração de cada um dos aplicativos hospedados no farm de servidores.
| Aplicativo | URL |
|---|---|
Conteúdo da intranet publicado |
http://fabrikam.admin |
Sites de equipe |
http://teams.admin |
Meus Sites |
http://my.admin |
Partner Web |
http://partnerweb.admin |
Site da empresa na Internet |
http://fabrikamsite.admin |
O modelo pressupõe que os administradores tenham acesso interno à rede corporativa.
Diretivas de zona
Você pode criar uma diretiva para um aplicativo Web para impor permissões no nível de aplicativo Web. Uma diretiva pode ser definida para o aplicativo Web em geral ou apenas para uma zona específica. A diretiva impõe permissões em todo o conteúdo do aplicativo Web ou da zona. As permissões de diretiva substituem todas as outras configurações de segurança definidas para sites e conteúdo. Você pode configurar a diretiva com base nos usuários ou grupos de usuários, mas não em grupos do SharePoint.
O modelo fornece exemplos de várias diretivas para realizar o seguinte:
Permitir aos administradores o acesso a todo o conteúdo.
Negar o acesso de gravação ao conteúdo publicado.
Garantir que os autores e testadores tenham acesso adequado ao conteúdo publicado.
Baixar este manual
Este tópico está incluído no seguinte manual baixável para facilitar a leitura e a impressão:
Consulte a lista completa de manuais disponíveis na página de download de conteúdo do Office SharePoint Server 2007.