Modèle d’architecture logique : déploiement d’entreprise
Mise à jour : 2009-04-23
Dans cet article :
À propos du modèle
Objectifs de la conception globale
Batteries de serveurs
Utilisateurs, zones et authentification
Fournisseurs de services partagés
Sites d’administration
Pools d’applications
Applications Web.
Collections de sites
Bases de données de contenu
Zones et URL
Stratégies de zone
Cet article décrit une implémentation pratique des composants de l’architecture logique en vue d’obtenir une conception exploitable. Cet article est destiné à être utilisé conjointement avec le modèle suivant, Exemple de conception : architecture logique du déploiement en entreprise (en anglais) (https://go.microsoft.com/fwlink/?linkid=82151&clcid=0x40C) (en anglais) .
Le modèle illustre un déploiement d’entreprise générique de Microsoft Office SharePoint Server 2007. Il s’applique à presque tous les composants de l’architecture logique et illustre comment ceux-ci sont intégrés à la conception globale. Cet article décrit les objectifs conceptuels du modèle et explique comment ces objectifs sont atteints à l’aide des composants de l’architecture logique illustrés dans le modèle.
À propos du modèle
Le modèle illustre un déploiement d’entreprise pour une société fictive appelée Fabrikam, Inc. Le déploiement englobe deux batteries de serveurs. Une batterie de serveurs héberge l’intranet d’entreprise et le site Web partenaire. La deuxième batterie de serveurs héberge le site Web de la société (www.fabrikam.com).
Intranet
L’intranet d’entreprise comprend les applications suivantes :
contenu intranet publié (tel que HRweb) ;
sites d’équipe de collaboration ;
Mes sites.
Ces applications constituent les sites de contenu et de collaboration que les employés utiliseront sur une base quotidienne. Individuellement, chacune de ces applications représente un type distinct du contenu. Chaque type de contenu :
met en valeur différentes fonctionnalités d’Office SharePoint Server 2007 ;
héberge des données présentant différentes caractéristiques ;
est associé à un profil d’utilisation spécifique ;
nécessite une stratégie de gestion des autorisations spécifique.
Par conséquent, les choix conceptuels pour chacune de ces applications visent à optimiser les performances et la sécurité de chacune d’elles.
L’utilisation d’un seul fournisseur de services partagés (SSP, Shared Services Provider) associe ces trois applications de manière à fournir :
une navigation dans les applications ;
une recherche à l’échelle de l’entreprise ;
des données de profil partagées.
La figure suivante illustre les trois applications qui composent l’intranet d’entreprise.
.jpg "Architecture logique pour modèle d’entreprise")
Web partenaire
L’application Web partenaire héberge des sites disponibles de manière externe pour la collaboration sécurisée avec les employés de sociétés partenaires. Cette application permet aux employés de créer facilement des sites en vue d’une collaboration sécurisée. Les facteurs clés qui déterminent le choix de cette application sont les suivants :
**Isolation de contenu **Les partenaires ne sont pas autorisés à accéder aux autres types de contenu hébergés sur la batterie de serveurs. En outre, à l’aide d’un fournisseur SSP dédié, vous pouvez davantage isoler le contenu en :
limitant l’étendue de la recherche au seul niveau du site ;
n’autorisant pas la navigation dans les collections de sites ;
ne rendant pas accessibles les données de profil dans les collections de sites.
**Authentification distincte des comptes des partenaires **Les comptes des partenaires sont gérés par le biais de l’authentification par formulaires. Ils ne sont pas ajoutés à l’annuaire d’entreprise.
**Gestion des autorisations **Les différents propriétaires de sites gèrent les autorisations sur leurs sites, en invitant à collaborer uniquement les participants nécessaires.
Dans le modèle, l’application Web partenaire est hébergée par la batterie de serveurs qui héberge par ailleurs le contenu intranet.
Site Internet de la société
Le site Internet de la société matérialise la présence de celle-ci sur Internet. Vous mettez le contenu à la disposition des clients en configurant l’accès anonyme avec des autorisations de lecture seule. Les facteurs clés qui déterminent le choix de cette application sont les suivants :
Isolation de contenu Les clients ne peuvent accéder à aucun autre type de contenu hébergé sur la batterie de serveurs.
Gestion ciblée L’accès authentifié est fourni pour les employés qui gèrent le site Web, notamment en ce qui concerne les tâches d’administration et de création.
Création et publication de contenu sécurisées Des collections de sites distinctes sont hébergées sur la batterie de serveurs A dans l’application Web partenaire pour la création et le test. Cela permet une collaboration et un développement de contenu sécurisés avec à la fois les employés internes et les employés distants, ainsi qu’avec les partenaires éditoriaux spécialisés dans le développement de sites Web ou la création de contenu. La publication de contenu est configurée de manière à ce que le contenu soit automatiquement publié depuis la collection de sites de création vers la collection de sites de test (dans la batterie de serveurs A) et depuis la collection de sites de test dans la batterie de serveurs A vers la collection de sites de production dans la batterie de serveurs B. La figure suivante illustre le processus de publication.
.jpg "Architecture de batterie de serveurs logique : modèle de publication")
Objectifs de la conception globale
Le modèle illustre une implémentation pratique des fonctionnalités d’Office SharePoint Server 2007 dans plusieurs types d’applications courants. Cet article décrit la mise en œuvre des concepts de chacune des applications. Les objectifs conceptuels clés du modèle sont les suivants :
Utiliser le moins de batteries de serveurs possible pour l’hébergement des types de sites Web les plus courants généralement requis par une entreprise : sites Intranet, extranet et Internet.
Créer un cadre permettant de concevoir un environnement susceptible de croître. Les décisions conceptuelles pour les différentes applications n’empêchent pas l’ajout d’autres applications. Par exemple, un déploiement initial peut n’inclure que des sites d’équipe de collaboration ou que les trois applications qui composent un intranet (sites d’équipe, Mes sites et contenu intranet publié). À l’aide d’un modèle d’architecture logique semblable, vous pouvez ajouter des applications à la solution sans affecter la conception des applications initiales. En d’autres termes, la conception n’incorpore pas de choix conceptuels qui limitent l’utilisation de l’environnement.
Accorder l’accès à plusieurs classes d’utilisateurs sans compromettre la sécurité du contenu dans les différentes applications. Les utilisateurs provenant de différentes zones réseau (internes et externes) auxquelles sont associés différents fournisseurs d’authentification peuvent participer à la collaboration. En outre, les utilisateurs peuvent uniquement accéder au contenu qui les concerne. En suivant une conception d’architecture logique similaire, vous pouvez accorder l’accès à des utilisateurs situés à différents endroits et poursuivant des objectifs différents. Par exemple, votre conception initiale peut être conçue uniquement pour l’accès des employés internes. Toutefois, à l’aide d’un modèle semblable, vous pouvez également accorder l’accès aux employés distants, aux employés partenaires et aux clients.
Faire en sorte que la conception soit utilisable dans un environnement extranet. Des choix conceptuels réfléchis sont effectués afin que les batteries de serveurs puissent être déployées en toute sécurité dans un réseau de périmètre.
Le reste de cet article décrit chacun des composants logiques qui apparaissent dans le modèle (du haut vers le bas), ainsi que les choix conceptuels appliqués au modèle. Cette approche vise à montrer les différentes façons de configurer les composants de l’architecture logique en fonction de l’application.
Batteries de serveurs
Le modèle comprend l’utilisation de deux batteries de serveurs. Cette section décrit les critères de licences qui affectent le nombre de batteries de serveurs requises dans un environnement d’entreprise et mentionne les topologies des batteries de serveurs illustrées dans le modèle.
Critères de licences
.gif "Note") Remarque : |
|---|
Les conditions de licence précédentes spécifiaient un minimum de deux serveurs pour héberger à la fois le contenu de l’intranet et les sites Internet (un serveur pour chaque type de licence). Ce n’est plus une obligation. Cette section a été mise à jour pour tenir compte des nouvelles conditions de licence implémentées en septembre 2008. |
Deux licences serveur sont disponibles pour Office SharePoint Server 2007. Ces licences peuvent être combinées sur le même serveur ou sur la même batterie de serveurs :
Microsoft Office SharePoint Server 2007, licence serveur Il s’agit de la licence appropriée pour le contenu intranet. Cette licence nécessite l’utilisation de licences d’accès client (CAL). Si vous créez des sites en vue d’une collaboration avec des partenaires, vous devez acheter le nombre requis de licences d’accès client pour les employés partenaires.
**Microsoft Office SharePoint Server 2007 pour sites Internet **Cette licence est destinée uniquement aux sites Web Internet. Elle ne requiert pas de licences d’accès client. Si vous créez des sites en vue d’une collaboration avec des partenaires, vous n’avez pas besoin d’acheter de licences d’accès client supplémentaires. Toutefois, vous ne pouvez pas créer de sites exclusivement destinés à être utilisés par vos employés.
Si vous envisagez de déployer du contenu interne pour votre organisation et du contenu Internet pour les utilisateurs autres que les employés à partir de la même batterie de serveurs, vous devez acheter les deux types de licences pour cette batterie de serveurs. Pour être en mesure de prendre en charge certains scénarios de déploiement, les clients qui souhaitent regrouper leurs besoins Office SharePoint Server 2007 sous un déploiement unique peuvent acquérir des licences pour les deux produits, affecter ces licences au même serveur, puis utiliser la même instance en cours d’exécution du logiciel sous les deux licences simultanément. Toutefois, les clients doivent acquérir les licences d’accès client nécessaires au regard des droits d’utilisation Office SharePoint Server 2007 pour les utilisateurs et les périphériques qui accèdent au contenu d’une manière interdite par les droits d’utilisation Office SharePoint Server 2007 pour les sites Internet.
Pour plus d’informations sur la manière dont les critères de licences affectent le nombre de batteries de serveurs nécessaires, voir Planifier des batteries de serveurs.
Bien qu’une seule batterie de serveurs soit nécessaire, le modèle illustre l’utilisation de deux batteries de serveurs : l’une est destinée au contenu interne et l’autre au contenu présenté au client. Si vous optez pour l’implémentation de deux batteries de serveurs distinctes, le choix conceptuel le plus important consiste à décider quelle batterie de serveurs doit héberger l’application Web partenaire. Dans le modèle, la batterie de serveurs A héberge le contenu intranet, tandis que la batterie de serveurs B héberge le site Internet de la société. Conformément aux termes de licence, les deux batteries de serveurs peuvent héberger l’application Web partenaire.
Lorsque les deux batteries de serveurs sont éligibles, les éléments conceptuels généraux suivants permettent de déterminer laquelle doit héberger une application Web partenaire :
Nature de la collaboration Si l’objectif principal d’un site extranet partenaire est de communiquer en toute sécurité des informations à plusieurs partenaires, une batterie de serveurs Internet est le choix plus économique. En revanche, si l’objectif principal est de collaborer avec un petit nombre d’employés partenaires, une batterie de serveurs intranet peut constituer un meilleur choix. Choisissez l’option qui vous permet d’optimiser la batterie de serveurs en fonction du rôle qu’elle doit jouer (collaboration ou contenu en lecture seule).
Nombre d’employés partenaires Si vous collaborez avec de nombreux employés partenaires et que la réduction des coûts au minimum est importante, la licence de sites Internet vous permet d’héberger en toute sécurité à la fois du contenu de collaboration et du contenu anonyme sur une batterie de serveurs Internet.
Dans le modèle, l’application Web partenaire est conçue pour une collaboration intensive avec les sociétés partenaires, y compris en ce qui concerne le développement et le test du site Internet de la société. Le fait de placer l’application Web partenaire sur la batterie de serveurs A permet à l’organisation d’optimiser chacune des deux batteries de serveurs en fonction de l’usage prévu de celles-ci (collaboration ou contenu en lecture seule).
Pour plus d’informations sur le choix du nombre approprié de batteries de serveurs pour votre organisation, notamment sur les critères de licences, voir Planifier des batteries de serveurs.
Topologie des batteries de serveurs
Chaque batterie de serveurs du modèle est composée de cinq serveurs présentant la topologie suivante :
deux serveurs Web frontaux ;
un serveur d’applications ;
deux serveurs de base de données en cluster ou en miroir.
D’après le modèle qui illustre l’architecture logique d’Office SharePoint Server 2007 :
tous les sites sont mis en miroir sur les serveurs Web frontaux ;
le site Administration centrale est installé sur un serveur d’applications afin qu’il ne soit pas directement accessible aux utilisateurs.
En réalité, le nombre d’ordinateurs serveurs et la topologie de la batterie de serveurs ne sont pas importants pour l’architecture logique, sauf lorsqu’il s’avère nécessaire d’augmenter la capacité et les performances. L’architecture logique peut être conçue indépendamment de la topologie de la batterie de serveurs. Le processus de planification des performances et de la capacité facilite le dimensionnement de la batterie de serveurs en fonction des objectifs en termes de performances et de capacité. Pour plus d’informations, voir Planifier les performances et la capacité (Office SharePoint Server).
Utilisateurs, zones et authentification
Le modèle illustre cinq classes d’utilisateurs différentes, chacune affectée à une zone spécifique. Dans chaque application Web, vous pouvez créer jusqu’à cinq zones à l’aide de l’un des noms de zone disponibles : Par défaut, Intranet, Internet, Personnalisée ou Extranet. Une batterie de serveurs qui héberge plus d’une application Web peut prendre en charge les demandes utilisateur provenant de plus de cinq zones réseau (jusqu’à cinq zones par application Web). Toutefois, le modèle montre uniquement cinq zones.
Utilisateurs et authentification
Le modèle montre des utilisateurs appartenant à différentes zones réseau ou, dans le cas des administrateurs, des utilisateurs qui ont des besoins très variés en matière d’autorisations. Le modèle illustre l’application de l’authentification aux utilisateurs. Le tableau suivant indique comment les utilisateurs sont authentifiés pour chaque zone.
| Zone | Utilisateurs | Authentification |
|---|---|---|
Personnalisée |
Administrateurs |
Kerberos (Windows intégrée) |
Intranet |
Employés internes |
NTLM (Windows intégrée) |
Par défaut |
Employés distants |
NTLM (Windows intégrée) ou authentification par formulaires avec LDAP (Lightweight Directory Access Protocol) |
Extranet |
Employés partenaires |
Authentification par formulaires |
Internet |
Clients |
Anonyme |
Dans le modèle, tous les utilisateurs ne disposent pas d’un accès à ces deux batteries de serveurs. Par conséquent, aucune batterie de serveurs n’utilise la totalité des cinq zones.
Administrateurs
La zone Personnalisée permet de sécuriser l’accès administratif aux sites. Cette approche offre la possibilité :
d’implémenter un ensemble indépendant d’URL et de stratégies. Par exemple, les administrateurs peuvent utiliser des URL associées à la zone Personnalisée pour effectuer des tâches administratives en fonction des stratégies de la zone. Les administrateurs peuvent utiliser les URL intranet pour toutes les autres tâches en fonction des stratégies configurées pour les applications qui constituent l’intranet. Cette approche sépare les deux contextes et garantit que les autorisations accordées par la stratégie n’entrent pas en conflit ;
d’implémenter une méthode d’authentification plus sûre pour les administrateurs. Cette fonctionnalité offre une plus grande sécurité pour la solution globale ;
d’effectuer l’authentification auprès d’un fournisseur différent lorsque la prise en charge des sites est assurée par un fournisseur externe.
Le modèle suppose que les administrateurs sont des employés de Fabrikam et qu’ils bénéficient d’un accès interne au réseau. Le modèle comprend l’utilisation de l’authentification Windows intégrée pour les administrateurs (autrement dit, l’authentification Kerberos ou NTLM).
Employés internes
La zone Intranet est utilisée pour l’accès des employés internes. L’authentification Windows intégrée est utilisée.
Employés distants
La zone Par défaut est utilisée pour l’accès des employés distants. Les objectifs conceptuels du modèle sont les suivants :
Effectuer l’authentification auprès de l’environnement de service d’annuaire Active Directory interne.
Simplifier la gestion des autorisations en utilisant l’authentification Windows pour les employés internes et les employés distants. Cet objectif est important parce que si les utilisateurs se connectent aux sites par le biais de deux fournisseurs d’authentification différents, Office SharePoint Server 2007 crée deux comptes différents pour chaque utilisateur, et chacun des deux comptes doit disposer d’autorisations.
Le modèle présente deux options pour l’authentification des employés distants. Avec la première option (authentification Windows intégrée avec utilisation de NTLM), les deux objectifs conceptuels sont atteints. La deuxième option (authentification par formulaires) satisfait le premier objectif, mais pas le second. Par conséquent, la première option est la méthode recommandée.
Le tableau suivant résume les différences entre ces deux approches.
| Méthode d’authentification | Authentification Windows intégrée avec utilisation de NTLM | Authentification par formulaires avec utilisation d’un fournisseur LDAP |
|---|---|---|
Fonctionnement |
Cette méthode repose sur l’utilisation de Microsoft Internet Security and Acceleration (ISA) Server et Intelligent Application Gateway (IAG) 2007 pour l’authentification des utilisateurs, puis pour l’envoi de leurs informations d’identification à Office SharePoint Server 2007. Ces serveurs utilisent l’authentification par formulaires pour authentifier les utilisateurs auprès de l’environnement Active Directory. Ils transmettent ensuite les informations d’identification Windows à Office SharePoint Server 2007. Pour plus d’informations, voir les ressources suivantes :
Étant donné que la zone est la zone Par défaut, l’authentification NTLM permet de satisfaire un besoin du composant d’index. Pour plus d’informations, voir « Contraintes liées à la configuration de la zone Par défaut » plus loin dans cet article. |
Office SharePoint Server 2007 utilise l’authentification par formulaires avec un fournisseur LDAP pour authentifier les employés distants auprès de l’environnement Active Directory interne. Si vous choisissez cette méthode, assurez-vous que le composant d’index peut s’authentifier via une autre zone. Pour plus d’informations, voir « Contraintes liées à la configuration de la zone Par défaut » plus loin dans cet article. |
Avantages |
Office SharePoint Server 2007 ne crée pas deux comptes différents pour les utilisateurs qui travaillent à la fois en interne et à distance. Cela simplifie considérablement la gestion des autorisations. |
Ne requiert pas un serveur proxy pour l’authentification des utilisateurs et le transfert des informations d’identification. |
Inconvénients |
Requiert une coordination supplémentaire avec ISA Server 2006 ou avec un autre produit de serveur proxy ou une configuration supplémentaire d’ISA Server 2006 ou d’un autre produit de serveur proxy. |
Si les utilisateurs se connectent à Office SharePoint Server 2007 à la fois en interne et à distance, deux comptes d’utilisateurs différents sont créés dans Office SharePoint Server 2007. Par conséquent, les deux comptes requièrent des autorisations sur les sites et les documents. Les employés peuvent, dans l’absolu, créer deux sites Mon site. Ils doivent gérer les autorisations sur leurs propres sites et documents pour les deux comptes d’utilisateurs s’ils envisagent de travailler à la fois depuis le réseau interne et à distance. |
Employés partenaires
Les employés partenaires accèdent au réseau via la zone Extranet et sont authentifiés à l’aide de l’authentification par formulaires. Cela requiert un annuaire et un fournisseur distincts, tels qu’une base de données et un fournisseur Microsoft SQL Server, pour le stockage des comptes des partenaires dans l’extranet. Les avantages de cette approche sont que vous pouvez gérer les comptes des partenaires séparément et que vous n’avez pas besoin de les ajouter à l’annuaire des employés internes.
Si vous préférez, vous pouvez utiliser l’authentification Web unique pour effectuer l’authentification auprès de l’annuaire d’un partenaire. Toutefois, cette approche nécessite une zone distincte pour chaque annuaire du partenaire.
Étant donné que le modèle implique que Fabrikam fonctionne avec des partenaires de plusieurs sociétés différentes dans la même application partenaire, l’authentification par formulaires est utilisée. L’annuaire et le fournisseur ne sont pas spécifiés.
Clients
La zone Internet est utilisée pour l’accès des clients. Cette zone est configurée pour autoriser l’accès anonyme avec autorisations de lecture seule.
Zones
Lorsque vous créez des zones, plusieurs décisions fondamentales déterminent la réussite du déploiement. Ces décisions concernent la conception et la configuration des zones suivantes :
zone Par défaut ;
zones pour l’accès externe.
Les sections suivantes décrivent les décisions qui caractérisent le modèle.
Exigences liées à la configuration de la zone Par défaut
La zone qui implique la plus grande attention est la zone Par défaut. Office SharePoint Server 2007 impose les contraintes suivantes quant à la configuration de la zone Par défaut :
Lorsqu’une demande utilisateur ne peut pas être associée à une zone, l’authentification et les stratégies de la zone Par défaut sont appliquées. Par conséquent, la zone Par défaut doit être la zone la plus sécurisée.
Le composant d’index doit pouvoir accéder au contenu via au moins une zone pour analyser celui-ci. Par défaut, le composant d’index utilise l’authentification NTLM. L’administrateur SSP peut configurer des règles d’analyse afin que soit utilisé l’authentification de base ou un certificat client lors de l’analyse d’une plage d’URL spécifique. Par conséquent, pour que le contenu soit analysé, au moins une des zones doit être configurée de manière à utiliser l’authentification NTLM, l’authentification de base ou des certificats. En outre, le robot interroge les zones dans l’ordre suivant jusqu’à ce qu’il rencontre une zone via laquelle il peut s’authentifier : zone par défaut, zone intranet, zone Internet, zone personnalisée, zone extranet. Toutefois, si le robot rencontre d’abord une zone configurée pour utiliser l’authentification Kerberos, il ne s’authentifie pas et ne tente pas d’accéder à la zone suivante. Par conséquent, assurez-vous que la configuration de zones utilisant l’authentification Kerberos n’empêche pas le composant d’index d’analyser le contenu. Pour plus d’informations sur les conditions d’authentification requises pour l’analyse du contenu, voir Planifier des méthodes d’authentification (Office SharePoint Server).
Des messages électroniques d’administration contenant des liens sont envoyés à partir de la zone Par défaut. Ces messages comprennent des courriers envoyés aux propriétaires de sites qui approchent les limites de quota. Par conséquent, les utilisateurs qui reçoivent ces types de messages électroniques et d’alertes doivent pouvoir accéder aux liens via la zone Par défaut. Cela est particulièrement important pour les propriétaires de sites.
Les collections de sites nommées par l’hôte sont uniquement disponibles via la zone Par défaut. Tous les utilisateurs susceptibles d’accéder aux collections de sites nommées par l’hôte doivent avoir accès à la zone Par défaut.
Dans le modèle, la zone Par défaut est utilisée pour l’accès des employés distants pour les raisons suivantes :
Les employés peuvent accéder aux liens contenus dans les messages électroniques d’administration indépendamment de l’endroit où ils se trouvent.
Les URL et les noms de serveurs internes sont protégés contre une exposition éventuelle lorsque la zone associée à une demande utilisateur ne peut pas être déterminée. Étant donné que la zone Par défaut est déjà configurée pour les employés distants, les URL n’exposent pas de données sensibles lorsque cette zone est appliquée.
Configurer les zones pour un environnement extranet
Dans un environnement extranet, la conception de zones est essentielle pour les deux raisons suivantes :
Les demandes des utilisateurs peuvent être émises à partir de plusieurs réseaux différents. Dans le modèle, les utilisateurs émettent les demandes à partir du réseau interne, d’Internet et de sociétés partenaires.
Les utilisateurs consomment le contenu à travers plusieurs applications Web. Dans le modèle, l’intranet est composé de trois applications Web différentes. En outre, les employés internes et distants peuvent potentiellement contribuer au contenu et l’administrer à travers toutes des applications Web : intranet, Web partenaire et site Internet de l’entreprise.
Dans un environnement extranet, assurez-vous que les principes de conception suivants sont suivis :
Configurez les zones dans différentes applications Web de façon à les mettre en miroir mutuellement. La configuration de l’authentification et les utilisateurs prévus doivent être identiques. Toutefois, les stratégies associées aux zones peuvent différer d’une application Web à l’autre. Par exemple, assurez-vous que la zone intranet est utilisée pour les mêmes employés dans toutes les applications Web. En d’autres termes, ne configurez pas la zone Intranet pour les employés internes dans une application Web et pour les employés distants dans une autre.
Configurez les mappages des accès de substitution de manière appropriée et avec précision pour chaque zone et chaque ressource.
Dans le modèle, la zone Par défaut pour chacune des applications Web est configurée de manière identique pour l’accès des employés distants. En outre, la zone Intranet est configurée de manière identique pour toutes les applications Web pour l’accès des employés internes. La zone Extranet et la zone Internet sont chacune configurées pour une seule application Web.
Des mappages des accès de substitution sont automatiquement générés lorsque vous créez la zone. Toutefois, Office SharePoint Server 2007 peut être configuré de manière à analyser le contenu des ressources externes, telles qu’un partage de fichiers. Des liens vers ces ressources externes doivent être créés manuellement pour chaque zone à l’aide de mappages des accès de substitution. Par exemple, un partage de fichiers peut être exposé aux utilisateurs internes avec une URL interne (file://). Le même partage de fichiers peut être exposé sous la forme d’un lien FTP aux utilisateurs externes (ftp://). Cela garantit que ces ressources sont disponibles pour les utilisateurs en fonction du contexte de leur zone. Lorsque les utilisateurs reçoivent des liens vers ces ressources dans les résultats de la recherche, les liens sont accessibles.
Si les zones entre les applications Web ne sont pas mises en miroir mutuellement et que les liens vers les ressources externes ne sont pas appropriés, les risques sont les suivants :
Les noms de serveurs, les noms DNS (Domain Name System) et les adresses IP peuvent éventuellement être exposées à l’extérieur du réseau interne.
Les utilisateurs peuvent ne pas avoir accès aux sites Web et aux autres ressources.
Fournisseurs de services partagés
Un fournisseur SSP fournit un ensemble commun de services et de données de service à un regroupement logique d’applications Web et à leurs sites associés. Les services et les données de service sont les suivants :
services de personnalisation ;
audiences ;
catalogue de données métiers ;
services Excel ;
service Recherche Office SharePoint Server ;
rapports d’utilisation du portail.
Le critère le plus important qui détermine si vous devez recourir à plus d’un fournisseur SSP dans votre architecture logique est la nécessité éventuelle d’isoler le contenu. Par exemple, si votre batterie de serveurs héberge des applications pour plus d’une classe d’utilisateurs, différents fournisseurs SSP permettent d’isoler ces classes d’utilisateurs les unes des autres.
Le modèle comprend un fournisseur SSP distinct pour chacune des applications suivantes :
intranet ;
Web partenaire ;
site Web Internet client.
.gif "Modèle SSP pour déploiement d’entreprise")
Intranet
Les trois applications distinctes qui composent l’intranet, en l’occurrence le contenu intranet publié, Mes sites et les sites d’équipe, sont rassemblées par un même fournisseur SSP. L’application intranet illustrée dans le modèle fournit un exemple de point d’équilibre entre une isolation sécurisée et la nécessité pour l’entreprise de partager les informations et d’exploiter les données de profil dans l’ensemble des applications.
Les différentes applications sont isolées par des applications Web et des pools d’applications. Différents pools d’applications permettent d’isoler les processus. Des applications Web dédiées permettent d’implémenter différentes stratégies d’autorisation pour chaque type de contenu.
L’unification des trois applications sous un même fournisseur SSP permet de personnaliser la totalité des applications et d’effectuer des recherches à l’échelle de l’entreprise sur l’ensemble de celles-ci.
.jpg "Architecture de fournisseur de services partagés")
Web partenaire
Grâce à l’utilisation d’un fournisseur SSP distinct pour l’application Web partenaire, les utilisateurs partenaires ne peuvent pas effectuer de recherche sur les informations sensibles au sein de votre environnement intranet, ni accéder à celles-ci. Vous pouvez, des manières suivantes, configurer le fournisseur SSP afin qu’il isole davantage le contenu entre les collections de sites :
Limitez les zones de recherche à des collections de sites spécifiques.
Utilisez des audiences pour cibler le contenu sur certains groupes d’utilisateurs.
Utilisez l’outil en ligne de commande Stsadm pour configurer le Sélecteur de personnes afin qu’il affiche uniquement les utilisateurs membres de la collection de sites. Dans cette configuration, vous pouvez ajouter n’importe quel utilisateur à partir de l’annuaire si vous connaissez son nom ; toutefois, seuls les utilisateurs déjà ajoutés à la collection de sites sont affichés dans le Sélecteur de personnes. Cela empêche les utilisateurs partenaires de parcourir votre annuaire d’utilisateurs par le biais du Sélecteur de personnes.
Utilisez la commande suivante pour activer cette configuration :
Stsadm.exe -o setproperty –url https://server/ –pn “peoplepicker-onlysearchwithinsitecollection” –pv yes
Utilisez la commande suivante pour désactiver cette configuration :
Stsadm.exe -o setproperty –url https://server/ –pn “peoplepicker-onlysearchwithinsitecollection” –pv no
Outre configurer les services dans le fournisseur SSP pour mettre en œuvre l’isolation, envisagez de configurer les autorisations des manières suivantes :
Limitez l’accès aux sites à des utilisateurs ou groupes spécifiques.
Utilisez des groupes SharePoint pour autoriser l’accès au contenu.
Site Internet de la société
Dans le modèle, le site Internet de la société est disponible pour les utilisateurs anonymes. Les sites destinés aux utilisateurs anonymes doivent toujours être séparés des sites destinés aux utilisateurs authentifiés. Le modèle utilise les méthodes d’isolation suivantes pour le site Internet de la société :
Un pool d’applications distinct garantit l’isolation des processus.
Une application Web distincte permet de cibler les stratégies.
Un fournisseur SSP dédié permet de limiter les résultats de la recherche à l’application anonyme.
Sites d’administration
Dans le modèle, chaque site d’administration est hébergé dans un pool d’applications et une application Web dédiés. La liste suivante décrit chacun des sites Web d’administration :
Sites Web d’administration des services partagés Le modèle illustre un site d’administration dédié pour chaque fournisseur SSP. Les sites d’administration de services partagés ne peuvent pas être isolés sur un seul serveur ou sur un ensemble de serveurs. Ces sites sont automatiquement mis en miroir sur tous les serveurs Web frontaux.
Sites Web Administration centrale Dans le modèle, le site Administration centrale pour chaque batterie de serveurs est hébergé sur un serveur d’applications. Cela protège le site d’un contact direct avec l’utilisateur. Si un goulot d’étranglement au niveau des performances ou un risque pour la sécurité affecte la disponibilité des serveurs Web frontaux, le site Administration centrale demeure disponible.
Les URL avec équilibrage de la charge réseau pour les sites d’administration ne sont pas détaillées dans le modèle ou dans cet article. Les recommandations sont les suivantes :
Si des numéros de port sont utilisés dans les URL d’administration, utilisez des ports non standard. Par défaut, des numéros de port sont inclus dans les URL. Bien que les URL destinées aux clients ne comportent généralement pas de numéro de port, l’utilisation de numéros de port pour les sites d’administration peut renforcer la sécurité en limitant l’accès à ces sites aux ports non standard.
Accordez l’accès aux sites d’administration uniquement à partir d’un domaine d’administration.
Créez des entrées DNS distinctes pour les sites d’administration.
En complément de ces recommandations, vous pouvez éventuellement équilibrer la charge du site Administration centrale sur plusieurs serveurs d’applications à des fins de redondance.
Pools d’applications
En règle générale, différents pools d’applications IIS (Internet Information Services) sont implémentés afin que les processus soient isolés d’un contenu à l’autre. Les pools d’applications permettent à plusieurs sites de s’exécuter sur le même ordinateur serveur tout en disposant de leurs propres processus de traitement et identité. Cela permet de réduire le risque d’une attaque sur un site par injection de code sur le serveur en vue d’attaquer d’autres sites.
D’un point de vue pratique, envisagez d’utiliser un pool d’applications dédié pour chacun des scénarios suivants :
pour séparer le contenu authentifié du contenu anonyme ;
pour isoler les applications qui stockent les mots de passe des applications métiers externes et interagissent avec celles-ci (par exemple, les connexions au catalogue de données métiers) ;
pour isoler les applications qui offrent aux utilisateurs de nombreuses possibilités pour créer et administrer des sites et pour collaborer au contenu.
Le modèle utilise des pools d’applications de la manière suivante :
Chaque site d’administration est hébergé dans un pool d’applications dédié. Il s’agit d’une exigence d’Office SharePoint Server 2007.
Le contenu intranet est réparti sur deux pools d’applications différents. Le contenu de collaboration (Mes sites et sites d’équipe) est hébergé dans un seul pool d’applications. Le contenu intranet publié est hébergé dans un pool d’applications distinct. Cette configuration assure l’isolation des processus pour le contenu intranet publié dans lequel des connexions aux données métiers sont plus susceptibles d’être utilisées. Par exemple, de nombreux sites de ressources humaines (RH) utilisent des connexions aux données métiers pour permettre aux employés d’accéder à leurs données personnelles.
L’application Web partenaire est hébergée dans un pool d’applications dédié.
Le site Internet de la société est hébergé dans un pool d’applications dédié sur la batterie de serveurs B. Si cette batterie de serveurs était également destinée à héberger le contenu relatif à la collaboration avec le partenaire, ces deux types de contenu (Internet et partenaire) seraient hébergés dans deux pools d’applications différents.
Applications Web
Une application Web est un site Web IIS qui est créé et utilisé par les produits et technologies SharePoint. Chaque application Web est représentée par un site Web différent dans IIS. Vous affectez à chaque application Web un nom de domaine unique, ce qui facilite la prévention des attaques de script entre sites.
En règle générale, utilisez des applications Web dédiées pour effectuer les opérations suivantes :
Séparer le contenu anonyme du contenu authentifié. Dans le modèle, le site Internet de la société est hébergé dans une application Web et un pool d’applications dédiés.
Isoler les utilisateurs. Dans le modèle, l’application Web partenaire est hébergée dans une application Web et dans un pool d’applications dédiés afin que les partenaires n’aient pas accès au contenu intranet.
Appliquer des autorisations. Une application Web dédiée permet d’appliquer des autorisations par stratégies à l’aide de la page Stratégie de l’application Web de l’Administration centrale. Par exemple, vous pouvez créer une stratégie sur le site Internet de la société pour refuser explicitement l’accès en écriture à un ou plusieurs groupes d’utilisateurs. Les stratégies d’une application Web sont appliquées indépendamment des autorisations configurées sur les différents sites ou documents au sein de l’application Web.
Optimiser les performances. Les applications obtiennent de meilleures performances si elles sont placées dans les applications Web en compagnie d’autres applications présentant des caractéristiques de données similaires. Par exemple, les caractéristiques de données des sites Mon site englobent un nombre élevé de sites de petite taille. En revanche, les sites d’équipe comprennent généralement un nombre réduit de sites très volumineux. Lorsque ces deux types différents de sites sont placés dans des applications Web distinctes, les bases de données obtenues sont composées de données qui présentent des caractéristiques similaires, ce qui optimise les performances des bases de données. Dans le modèle, les sites Mon site et les sites d’équipe ne présentent pas des exigences uniques en matière d’isolation des données ; ils partagent le même pool d’applications. Néanmoins, les sites Mon site et les sites d’équipe sont placés dans des applications Web distinctes afin que les performances soient optimisées.
Optimiser la facilité de gestion. Étant donné que la création d’applications Web distinctes aboutit à des sites et à des bases de données distincts, vous pouvez implémenter des limites de site différentes (Corbeille, expiration et taille de chaque site) et négocier différents contrats de niveau de service. Par exemple, vous pouvez accorder plus de temps pour la restauration du contenu du site Mon site s’il ne s’agit pas du type de contenu le plus important au sein de votre organisation. Cela vous permet de restaurer le contenu plus important avant le contenu du site Mon site. Dans le modèle, les sites Mon site sont placés dans une application Web distincte afin que les administrateurs puissent gérer la croissance de manière plus dynamique par rapport aux autres applications.
Collections de sites
Les collections de sites relient l’architecture logique et l’architecture des informations. Dans le modèle, les objectifs conceptuels des collections de sites consistent à satisfaire les contraintes liées à la conception des URL et à créer des divisions de contenu logiques.
Pour satisfaire les contraintes liées à la conception des URL, chaque application Web comprend une collection de sites de niveau racine unique. Les chemins d’accès gérés permettent d’incorporer un second niveau de collections de sites de niveau supérieur. Pour plus d’informations sur les contraintes liées aux URL et sur l’utilisation des chemins d’accès gérés, voir « Zones et URL » plus loin dans cet article. Au-delà du deuxième niveau de collections de sites, chaque site est un sous-site.
La figure suivante illustre la hiérarchie de site des sites d’équipe.
.jpg "Architecture logique pour des sites de collaboration")
Étant donné la nécessité d’une collection de sites de niveau racine, les décisions en matière de conception sont articulées autour du second niveau de collections de sites. Le modèle intègre des choix basés sur la nature de l’application.
Contenu intranet publié
Dans le cas de l’application de contenu intranet publié, l’hypothèse est que plusieurs divisions au sein de la société hébergent du contenu publié. Dans le modèle, le contenu de chaque division est hébergé dans une collection de sites distincte. Cela offre les avantages suivants :
Chaque division peut gérer son contenu et y associer des autorisations indépendamment.
Le contenu de chaque division peut être stocké dans une base de données dédiée.
L’utilisation de plusieurs collections de sites présente les inconvénients suivants :
Les pages maîtres, les mises en page, les modèles, les composants WebPart et la navigation ne peuvent pas être partagés entre les collections de sites.
Davantage d’effort est nécessaire pour coordonner les personnalisations et la navigation entre les collections de sites.
En fonction de la conception et de l’architecture des informations, le contenu publié peut être une application transparente aux yeux de l’utilisateur ou chaque collection de sites peut apparaître sous la forme d’un site Web distinct.
Mes sites
Les applications Mes sites présentent des caractéristiques distinctes et les recommandations pour leur déploiement sont simples. Dans le modèle, l’application Mon site comprend un site de niveau supérieur doté de l’URL http://my/. La première collection de sites de niveau supérieur qui est créée utilise le modèle Hôte de sites Mon site. Un chemin d’accès géré est incorporé (à l’aide d’une inclusion générique), ce qui autorise un nombre illimité de sites créés par l’utilisateur. Tous les sites sous le chemin d’accès géré sont des collections de sites indépendantes qui héritent le modèle Hôte de sites Mon site. Le nom d’utilisateur est ajouté à l’URL sous la forme http://my/ personal/nom_utilisateur. La figure suivante illustre l’application Mes sites.
.jpg "Architecture de réseau logique pour Mes sites")
Pour plus d’informations sur la conception d’une application Mes sites, voir Concevoir l’architecture de Mes sites.
Sites d’équipe
Vous pouvez utiliser l’une ou l’autre des deux approches suivantes pour concevoir des collections de sites au sein d’une application Site d’équipe :
Permettre aux équipes de créer des collections de sites via la création de sites libre-service. L’avantage de cette approche est que les équipes peuvent facilement créer un site, selon les besoins, sans l’aide d’un administrateur. Toutefois, cette approche présente plusieurs inconvénients, notamment les suivants :
Vous perdez l’opportunité d’implémenter une taxonomie réfléchie.
L’application peut devenir difficile à gérer.
Les sites sont facilement abandonnés.
Vous ne pouvez pas partager les modèles et la navigation entre des projets ou des équipes qui pourraient par ailleurs partager une collection de sites.
Créer un nombre fini de collections de sites pour votre organisation basé sur le mode de fonctionnement de celle-ci. Dans cette approche, les collections de sites sont créées par un administrateur SharePoint. Une fois la collection de sites créée, les équipes peuvent créer des sites dans la collection de sites en fonction de leurs besoins. Cette approche permet d’implémenter une taxonomie réfléchie qui structure la gestion et la croissance des sites d’équipe. En outre, il est plus facile de partager les modèles et la navigation entre des projets et des équipes qui partagent une collection de sites.
Le modèle intègre la deuxième approche, ce qui aboutit à une hiérarchie de collection de sites similaire pour les sites d’équipe et pour le contenu intranet publié. Le défi pour les concepteurs du système d’information consiste à créer un deuxième niveau de collections de sites qui soit logique pour l’organisation. Le tableau suivant répertorie des suggestions pour différents types d’organisations.
| Type d’organisation | Taxonomies de collections de sites suggérées |
|---|---|
Développement de produits |
|
Recherche |
|
Établissement d’enseignement supérieur |
|
Bureau des affaires législatives |
|
Cabinet d’avocats en droit des sociétés |
|
Production |
|
Web partenaire
L’application Web partenaire est destinée à être utilisée pour la collaboration avec des partenaires externes sur des projets dont l’étendue ou la durée est arrêtée. En raison de leur conception, les sites au sein de l’application Web partenaire ne sont pas destinés à être liés. L’application Web partenaire doit répondre aux exigences suivantes :
Les propriétaires de projets peuvent facilement créer des sites pour la collaboration avec des partenaires.
Les partenaires et les autres collaborateurs ont accès uniquement au projet sur lequel ils travaillent.
Les autorisations sont gérées par les propriétaires de sites.
Les résultats d’une recherche au sein d’un projet n’exposent pas le contenu d’autres projets.
Les administrateurs peuvent facilement identifier les sites qui ne sont plus utilisés et les supprimer.
Pour satisfaire à ces exigences, le modèle comprend une collection de sites par projet. Cette configuration présente les avantages suivants :
Les différentes collections de sites fournissent le niveau d’isolation approprié entre les projets.
La création de sites libre-service peut être implémentée.
Étant donné que l’application Web partenaire héberge également les collections de sites qui permettent de développer du contenu pour le site Internet de la société, des collections de sites distinctes sont créées pour la création et le test.
Site Internet de la société
Le site Internet de la société comprend une collection de sites de niveau racine unique. Tous les sites rattachés à cette collection de sites sont des sous-sites. Cette structure simplifie les URL des pages au sein du site. La figure suivante illustre l’architecture du site Internet de la société.
.jpg "Architecture de déploiement logique")
Bases de données de contenu
Vous pouvez utiliser les deux méthodes suivantes pour inclure des bases de données de contenu dans la conception (le modèle intègre les deux approches) :
Établissez les tailles cibles des bases de données de contenu en définissant des seuils d’avertissement correspondants appropriés. Créez une nouvelle base de données lorsque ces seuils sont atteints. Grâce à cette approche, des collections de sites sont automatiquement ajoutées à la base de données ou aux bases de données disponibles, en fonction des tailles cibles uniquement.
Associez les collections de sites à des bases de données de contenu spécifiques. Cette approche vous permet de placer une ou plusieurs collections de sites dans une base de données dédiée qui peut être gérée indépendamment des autres.
Si vous choisissez d’associer les collections de sites à des bases de données de contenu spécifiques, vous pouvez utiliser les méthodes suivantes pour effectuer cette opération :
Utilisez l’outil en ligne de commande Stsadm pour créer une collection de sites dans une base de données spécifique.
Dédiez une base de données à une collection de sites unique en appliquant les paramètres de capacité de la base de données suivants :
Nombre de sites avant qu’un événement d’avertissement ne soit généré : 1
Nombre maximal de sites pouvant être créés dans cette base de données : 1
Ajoutez un groupe de collections de sites à une base de données dédiée en procédant comme suit :
Dans l’application Web, créez la base de données et définissez son état sur Prêt.
Définissez l’état de toutes les autres bases de données sur Déconnecté. Tant que les bases de données de contenu sont déconnectées, aucune collection de sites ne peut être créée. Toutefois, les collections de sites existantes dans les bases de données déconnectées demeurent accessibles en lecture et en écriture.
Créez les collections de sites. Celles-ci sont automatiquement ajoutées à la base de données.
Définissez de nouveau l’état de toutes les autres bases de données sur Prêt.
Contenu intranet publié
Pour le contenu intranet publié, le modèle comprend une base de données dédiée par collection de sites de service.
Cette approche permet à chaque service de gérer son contenu de manière indépendante.
Mes sites
Pour les applications Mes sites, le modèle optimise la mise à l’échelle en gérant les bases de données en fonction de la taille cible maximale. Les paramètres suivants sont configurés pour atteindre cet objectif :
Limiter le stockage du site à une valeur maximale de Ce paramètre, que vous configurez dans la page Modèles de quotas de l’Administration centrale, limite la taille d’un site personnel.
Corbeille secondaire Ce paramètre, que vous configurez dans la page Paramètres généraux de l’application Web, détermine la quantité d’espace supplémentaire allouée à la corbeille secondaire.
Nombre maximal de sites pouvant être créés dans cette base de données Ce paramètre est configuré lorsque vous créez une base de données. Calculez la taille autorisée totale des sites à partir des valeurs que vous avez définies pour les deux paramètres précédents. Ensuite, en fonction de l’objectif de taille pour une base de données spécifique, déterminez le nombre de sites que celle-ci pourra accueillir.
Le modèle fournit les exemples de paramètres de taille suivants, en prenant pour référence une taille de base de données cible de 100 gigaoctets (Go) et d’une taille cible pour le site Mon site de 500 mégaoctets (Mo) :
Taille de site limite par site = 500 Mo
Taille cible de la base de données = 100 Go
Nombre maximal de sites = 200
Avertissement relatif au niveau du site = 150
Lorsque l’avertissement relatif au niveau du site est atteint, créez une nouvelle base de données. Ensuite, de nouveaux sites Mon site sont ajoutés alternativement à la nouvelle base de données et à la base de données existante jusqu’à ce que le nombre maximal de sites pour l’une des bases de données soit atteint.
Pour plus d’informations sur la conception de paramètres de base de données pour les sites Mon site, voir Concevoir l’architecture de Mes sites.
Sites d’équipe
Pour les sites d’équipe, le modèle comprend une base de données dédiée par collection de sites d’équipe. Cette approche vous permet de gérer la base de données de chaque équipe de manière indépendante pour les opérations de sauvegarde, de restauration et de migration. En outre, lorsqu’un projet est terminé, vous pouvez facilement archiver la base de données associée à celui-ci.
Web partenaire
Similaire à l’application Mes sites, l’application Web partenaire optimise la mise à l’échelle en gérant les bases de données en fonction de la taille cible maximale. Dans le modèle, toutefois, l’application Web partenaire héberge également les collections de sites de création et de test associées au site Internet de la société. Par conséquent, la conception des bases de données intègre les deux approches :
Les collections de sites de création et de test sont chacune hébergées dans une base de données dédiée.
Les paramètres de base de données et de taille sont configurés pour gérer la totalité des autres sites et bases de données.
Étant donné que l’application Web partenaire est hébergée dans une application Web dédiée, vous pouvez créer des limites de taille plus appropriées pour les types de tailles générés. Le modèle fournit les exemples de paramètres de taille suivants :
Taille cible de la base de données = 100 Go
Quota de stockage par site = 5 Go
Nombre maximal de sites = 20
Collections de sites de création et de test hébergées dans des bases de données dédiées
Site Internet de la société
En recourant à une seule collection de sites dans la conception du site Internet de la société, vous utilisez une seule base de données pour cette application Web.
Zones et URL
Le modèle illustre la façon de coordonner les URL entre plusieurs applications dans un déploiement d’entreprise.
Objectifs conceptuels
Les objectifs suivants déterminent les décisions conceptuelles prises pour les URL :
Les conventions d’URL ne limitent pas les zones d’accès au contenu.
Les ports HTTP et HTTPS standard (80 et 443) peuvent être utilisés pour toutes les applications dans le modèle.
Les numéros de port ne sont pas inclus dans les URL. Dans la pratique, ils ne sont généralement pas utilisés dans les environnements de production.
Principes conceptuels
L’application des principes conceptuels suivants permet d’atteindre ces objectifs conceptuels :
Les collections de sites nommées par l’hôte ne sont pas utilisées. Notez qu’elles diffèrent des en-têtes d’hôte IIS. Les collections de sites nommées par l’hôte sont incompatibles avec la fonctionnalité des mappages des accès de substitution. Cette fonctionnalité permet d’accéder au même contenu via plusieurs URL de domaine. Par conséquent, lorsque des sites nommés par l’hôte sont utilisés, ces sites sont disponibles uniquement via la zone Par défaut. En outre, la fonctionnalité de mappage des accès de substitution prend en charge l’arrêt de SSL (Secure Sockets Layer) hors ordinateur, ce qui permet aux scénarios d’accès des employés distants et d’accès des partenaires d’utiliser SSL (https).
Chaque application comprend une collection de sites racine unique. Cela est indispensable pour utiliser les mappages des accès de substitution. Si plusieurs collections de sites racines sont nécessaires dans une application Web et que vous envisagez d’utiliser uniquement la zone Par défaut pour l’accès des utilisateurs, le recours à des collections de sites nommées par l’hôte constitue un choix adéquat.
Dans le cas des applications qui comprennent plusieurs collections de sites de niveau supérieur et dans lesquelles chaque collection de sites représente une équipe ou un projet de niveau supérieur (par exemple, des sites d’équipe), le modèle comporte des chemins d’accès gérés. Ceux-ci permettent de mieux contrôler les URL de ces types de sites.
Compromis conceptuels
La satisfaction des objectifs conceptuels aboutit à certains compromis, notamment les suivants :
Les URL sont plus longues.
Les collections de sites nommées par l’hôte ne sont pas utilisées.
Concevoir des URL avec équilibrage de la charge réseau
Lorsque vous créez une application Web, vous devez choisir l’URL avec équilibrage de la charge réseau à affecter à l’application. En outre, vous devez créer une URL avec équilibrage de la charge réseau pour chaque zone que vous créez dans une application Web. L’URL avec équilibrage de la charge réseau inclut le protocole, le schéma, le nom d’hôte et le numéro de port, si celui-ci est utilisé. L’URL avec équilibrage de la charge réseau doit être unique sur l’ensemble des applications Web et des zones. Par conséquent, chaque application et chaque zone au sein de chaque application requièrent une URL unique dans le modèle.
Intranet
Chacune des trois applications qui composent l’intranet nécessite une URL unique. Dans le modèle, l’audience cible du contenu intranet est constituée des employés internes et des employés distants. Le tableau suivant répertorie les URL qui permettent aux employés internes et aux employés distants d’accéder à chaque application.
| Application | URL pour les employés internes | URL pour les employés distants |
|---|---|---|
Contenu intranet publié |
http://fabrikam |
https://intranet.fabrikam.com/ |
Sites d’équipe |
http://teams/ |
https://teams.fabrikam.com/ |
Mes sites |
http://my/ |
https://my.fabrikam.com/ |
Web partenaire
Dans le modèle, l’application Web partenaire est accessible aux employés internes, aux employés distants et aux employés partenaires. Bien que les employés distants et les employés partenaires accèdent à l’application Web partenaire de manière externe à l’aide de SSL (https), les uns comme les autres nécessitent une URL spécifique pour tirer parti de l’utilisation de zones distinctes, ce qui suppose l’utilisation de méthodes d’authentification et de stratégies de zone distinctes. Le tableau suivant répertorie les URL que les employés internes, les employés distants et les partenaires utilisent pour accéder à l’application Web partenaire.
| Zone | URL |
|---|---|
URL pour les employés internes |
http://partnerweb/ |
URL pour les employés distants |
https://remotepartnerweb.fabrikam.com/ |
URL pour les partenaires |
https://partnerweb.fabrikam.com |
Site Internet de la société
Le site Internet de la société est un site public, accessible à tout utilisateur par le biais de l’URL par défaut https://www.microsoft.com/fr/fr/default.aspx. Les stratégies de la zone Internet sont appliquées (c’est-à-dire, accès anonyme et refus d’écriture).
Toutefois, pour prendre en charge les tâches d’administration et de création sur le site public, le modèle comprend des URL pour les employés internes et pour les employés distants. Les stratégies de ces zones limitent les autorisations supérieures à l’accès en lecture à des groupes de sécurité ciblés. Le tableau suivant répertorie les URL pour chaque zone.
| Zone | URL |
|---|---|
URL pour les employés internes |
http://fabrikamsite/ |
URL pour les employés distants |
https://fabrikamsite.fabrikam.com |
URL pour les clients |
https://www.microsoft.com/fr/fr/default.aspx |
Utiliser des inclusions explicites et des inclusions génériques pour les chemins d’URL
En définissant des chemins d’accès gérés, vous pouvez spécifier quels chemins d’accès dans l’espace de noms d’URL d’une application Web sont utilisés pour les collections de sites. Vous pouvez spécifier l’existence d’une seule collection de sites ou de plus d’une collection de sites sur un chemin d’accès distinct sous le site racine. En l’absence de chemins d’accès gérés, tous les sites créés sous la collection de sites racine font partie de celle-ci.
Vous pouvez créer les deux types de chemins d’accès gérés suivants :
Inclusion explicite Collection de sites à laquelle est associée l’URL explicite que vous attribuez. Une inclusion explicite est appliquée à une seule collection de sites. Vous pouvez créer de nombreuses inclusions explicites sous une collection de sites racine. Un exemple d’URL pour une collection de sites créée à l’aide de cette méthode est http://fabrikam/hr.
Inclusion générique Chemin d’accès ajouté à l’URL. Ce chemin d’accès indique que tous les sites spécifiés directement après le nom du chemin d’accès sont des collections de sites uniques. Cette option est généralement utilisée pour les applications qui prennent en charge l’autocréation de sites, tels que les sites Mon site. Un exemple d’URL pour une collection de sites créée à l’aide de cette méthode est http://my//Personal/User1.
Le modèle intègre l’utilisation de ces deux types, comme le décrivent les sections suivantes.
Inclusions explicites : sites d’équipe et contenu intranet publié
Dans le modèle, l’application des sites d’équipe et les applications de contenu intranet publié intègrent l’utilisation d’inclusions explicites.
Sites d’équipe
Dans l’application Sites d’équipe, une inclusion explicite est utilisée pour chaque collection de sites d’équipe. La limite de mise à l’échelle sur les collections de sites créées avec une inclusion explicite est d’environ 100 sites. Il est recommandé de maintenir le nombre de sites d’équipe de niveau supérieur en deçà d’un nombre gérable. Par ailleurs, la taxonomie des sites d’équipe doit être logique par rapport au fonctionnement de votre entreprise. De nombreuses organisations s’accommodent facilement de la limite recommandée de 100 sites. Si votre organisation requiert une mise à l’échelle supérieure pour les sites d’équipe, utilisez plutôt une inclusion générique.
Dans le modèle, l’utilisation d’inclusions explicites aboutit aux URL indiquées dans le tableau suivant.
| Employé interne (zone Intranet) | Employé distant (zone Par défaut) |
|---|---|
http://team/Team1 |
https://team.fabrikam.com/Team1 |
http://team/Team2 |
https://team.fabrikam.com/Team2 |
http://team/Team3 |
https://team.fabrikam.com/Team3 |
Dans cet exemple, la collection de sites racine, http://team, n’héberge pas nécessairement de contenu pour des utilisateurs.
Contenu intranet publié
Dans l’application de contenu intranet publié, une inclusion explicite est utilisée pour chaque sous-site : hr, facilities et purchasing. Cela permet de gérer chacun de ces sites de manière indépendante. Le cas échéant, chacune de ces collections de sites peut être associée à une base de données de contenu distincte, afin qu’il soit possible de gérer la croissance et de sauvegarder et de restaurer ces sites séparément.
Dans le modèle, l’utilisation d’inclusions explicites aboutit aux URL indiquées dans le tableau suivant.
| Employé interne (zone Intranet) | Employé distant (zone Par défaut) |
|---|---|
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 |
Dans cet exemple, la collection de sites racine, http://fabrikam, représente la page d’accueil par défaut de l’intranet. Ce site est destiné à héberger du contenu pour les utilisateurs.
Inclusions génériques : applications Web partenaire et Mes sites
Les applications Web partenaire et Mes sites intègrent l’utilisation d’une inclusion générique. Les inclusions génériques sont idéales pour les applications qui permettent aux utilisateurs de créer leurs propres collections de sites. Une inclusion générique indique que l’élément situé juste après le caractère générique est un site racine d’une collection de sites.
Mes sites
L’application Mes sites offre la fonction de création de sites libre-service. Lorsqu’un utilisateur qui parcourt l’intranet clique sur Mon site, un site Mon site est automatiquement créé. Dans le modèle, l’application Mes sites comprend une inclusion générique nommée /personal (http://my//personal). La fonctionnalité Mon site ajoute automatiquement le nom de l’utilisateur à l’URL.
Cela se traduit par des URL dont le format est indiqué dans le tableau suivant.
| Employé interne (zone Intranet) | Employé distant (zone Par défaut) |
|---|---|
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 |
Web partenaire
L’application Web partenaire est conçue pour permettre aux employés de créer facilement des sites sécurisés en vue d’une collaboration avec des partenaires externes. Pour que cet objectif puisse être atteint, la création de sites libre-service est autorisée.
Dans le modèle, l’application Web partenaire comprend une inclusion générique nommée /sites (http://partnerweb//sites). Cela se traduit par des URL dont le format est indiqué dans le tableau suivant.
| Employé interne (zone Intranet) | Employé distant (zone Par défaut) |
|---|---|
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 |
Les collaborateurs partenaires peuvent accéder aux sites Web partenaires à l’aide des URL répertoriées dans le tableau suivant.
| Partenaire (zone Extranet) |
|---|
https://partnerweb.fabrikam.com/sites/project1 |
https://partnerweb.fabrikam.com/sites/project2 |
https://partnerweb/fabrikam.com/sites/project3 |
L’exception pour l’application Web partenaire, comme l’illustre le modèle, est constituée des deux collections de sites dédiées à la création et au test du contenu du site Internet de la société. Pour ces deux collections de sites, une inclusion explicite est utilisée. Cela illustre l’utilisation à la fois d’inclusions explicites et d’inclusions génériques dans une même application Web.
URL d’administration
Le tableau suivant répertorie les URL de la zone d’administration de chacune des applications hébergées sur la batterie de serveurs.
| Application | URL |
|---|---|
Contenu intranet publié |
http://fabrikam.admin/ |
Sites d’équipe |
http://teams/.admin/ |
Mes sites |
http://my/.admin |
Web partenaire |
http://partnerweb/.admin/ |
Site Internet de la société |
http://fabrikamsite/.admin/ |
Le modèle suppose que les administrateurs disposent d’un accès interne au réseau d’entreprise.
Stratégies de zone
Vous pouvez créer une stratégie pour une application Web afin d’appliquer des autorisations au niveau de celle-ci. Une stratégie peut être définie pour l’application Web en général ou uniquement pour une zone spécifique. Une stratégie applique des autorisations à la totalité du contenu au sein de l’application Web ou de la zone. Les autorisations d’une stratégie substituent tous les autres paramètres de sécurité qui sont configurés pour les sites et le contenu. Vous pouvez configurer la stratégie en fonction des utilisateurs ou des groupes d’utilisateurs, mais pas en fonction des groupes SharePoint.
Le modèle fournit des exemples de plusieurs stratégies aux fins suivantes :
Permettre aux administrateurs d’accéder à tout le contenu.
Refuser l’accès en écriture au contenu publié.
Faire en sorte que les auteurs et les testeurs disposent d’un accès approprié au contenu publié.
Télécharger ce livre
Cette rubrique est incluse dans le livre à télécharger suivant pour une lecture et une impression plus faciles :
Vous trouverez la liste complète des livres disponibles sur Livres à télécharger pour Office SharePoint Server 2007.