Guide de référence sur Microsoft Internet Data Center

Sur cette page

Microsoft Internet Data Center : Guide de référence Microsoft Internet Data Center : Guide de référence
Résumé Résumé
Résumé général Résumé général
Objectifs architecturaux Objectifs architecturaux
Objectifs majeurs Objectifs majeurs
Évolutivité Évolutivité
Mise à l'échelle verticale Mise à l'échelle verticale
Mise à l'échelle horizontale Mise à l'échelle horizontale
Disponibilité Disponibilité
Élimination de la dépendance des différents composants Élimination de la dépendance des différents composants
Disponibilité dans la conception des systèmes Disponibilité dans la conception des systèmes
Sécurité Sécurité
Gestion Gestion
Surveillance et alertes Surveillance et alertes
Gestion du contenu Gestion du contenu
Gestion à distance Gestion à distance
Sauvegarde et restauration Sauvegarde et restauration
Éléments architecturaux Éléments architecturaux
Clients Internet Clients Internet
Réseau de périmètre Réseau de périmètre
Zone démilitarisée Zone démilitarisée
Pare-feu interne Pare-feu interne
Réseau interne Réseau interne
Infrastructure de sécurité Infrastructure de sécurité
Infrastructure de gestion Infrastructure de gestion
Introductions aux chapitres Introductions aux chapitres
Chapitre 2 - Conception de l'infrastructure réseau Chapitre 2 - Conception de l'infrastructure réseau
Chapitre 3 - Conception de pare-feu Chapitre 3 - Conception de pare-feu
Chapitre 4 - Infrastructure de sécurité Chapitre 4 - Infrastructure de sécurité
Chapitre 5 - Conception de bases de données SQL Server Chapitre 5 - Conception de bases de données SQL Server
Chapitre 6 - Conception de la solution de gestion Chapitre 6 - Conception de la solution de gestion
Chapitre 7 - Conception de BizTalk Server Chapitre 7 - Conception de BizTalk Server
Chapitre 8 - Conception de Commerce Server Chapitre 8 - Conception de Commerce Server
Chapitre 9 - Élaboration de vos procédures de test Chapitre 9 - Élaboration de vos procédures de test
Portée de la documentation Portée de la documentation
Public concerné Public concerné
Conventions de style Conventions de style

Microsoft Internet Data Center : Guide de référence

Résumé

Cette introduction à la documentation Microsoft® Internet Data Center fournit une présentation des différents chapitres, un résumé général des composants et des objectifs de l'architecture, le contenu de la documentation, le public concerné par cette documentation et les conventions utilisées par ce guide.

Résumé général

Les entreprises sont de plus en plus sollicitées pour fournir des services Internet de manière sécurisée et contrôlée. Ces services doivent être disponibles de manière ininterrompue et pouvoir s'adapter à l'évolution des besoins commerciaux de l'entreprise. Pour atteindre ces objectifs, de plus en plus d'organisations mettent en place des centres de données Internet en tant que réseaux intermédiaires entre le réseau Internet, ouvert à tous, et l'environnement privé de l'entreprise. La documentation Microsoft® Internet Data Center présente une architecture de référence qui permet aux clients de mettre en place un environnement évolutif, fiable, sûr et facile à gérer en utilisant un ensemble recommandé d'outils, de technologies et de processus. En suivant les recommandations de cette documentation Internet Data Center, une organisation peut construire rapidement et efficacement des applications Internet qui répondent à ses besoins à long terme liés à Internet.

Les guides d'instructions composant cette documentation Internet Data Center fournissent des recommandations de configuration logicielle et matérielle pour mettre en place cette infrastructure dans un environnement de production. Plusieurs exemples de cette architecture ont été testés et validés avec du matériel de différents fournisseurs afin de garantir que les exigences en matière de performances, d'évolutivité, de disponibilité, de gestion et de sécurité sont remplies.

La conception logique met en exergue l'importance de la simplicité et de la flexibilité de la conception de l'infrastructure et de la structure des opérations quotidiennes. Cela permet à l'architecture IDC de prendre en charge une grande variété d'architectures d'applications tout en offrant une gestion simple.

Objectifs architecturaux

Les sites des grandes entreprises sont des modèles d'évolution dynamique : ils sont généralement de petite taille au début et croissent de manière exponentielle avec la demande. Ils évoluent d'un côté sur le plan du nombre de visiteurs (dont l'augmentation peut être extrêmement rapide) et de l'autre sur le plan de la complexité et de l'intégration des services offerts aux utilisateurs. Les investisseurs de nombreuses sociétés à vocation technologique font de soigneuses études des prévisions commerciales de ces entreprises et ont établi une projection selon toute vraisemblance d'un taux de croissance de 10-100x. Les sites commerciaux qui ont effectivement du succès atteignent ce taux et s'adaptent en augmentant de manière incrémentielle le nombre de serveurs fournissant des services logiques à leurs clients. Pour cela, elles créent plusieurs instances de serveurs (clones) ou elles partagent la charge de travail entre plusieurs serveurs et créent des services qui s'intègrent à leurs systèmes informatiques existants. Cette augmentation se base sur de solides fondations architecturales, qui supportent un taux élevé de disponibilité, une infrastructure sécurisée et une infrastructure de gestion. Ces fondations architecturales doivent répondre à différents objectifs majeurs de conception.

Objectifs majeurs

Les objectifs majeurs en matière d'architecture Internet Data Center comprennent :

  • Évolutivité. Tous les composants de l'architecture doivent être évolutifs afin de permettre une croissance continue et répondre aux besoins des utilisateurs et de l'entreprise.

  • Disponibilité. Les composants de l'architecture doivent fournir une redondance ou une spécificité fonctionnelle afin de limiter les pannes.

  • Sécurité. L'architecture doit fournir un modèle de sécurité de bout en bout pour protéger les données et l'infrastructure contre des attaques ou le vol.

  • Gestion. Simplicité de la configuration, contrôle continu de la santé du système et détection des pannes sont des éléments essentiels pour atteindre nos objectifs de disponibilité, d ‘évolutivité et de sécurité et doivent être compatibles avec la croissance de l'environnement.

Remarque : Tous les composants de l'architecture IDC ont été conçus en tenant compte de ces objectifs de conception. Les autres chapitres de ce guide de conception vous fournissent toutes les informations concernant la conception et expliquent comment ces objectifs architecturaux sont atteints pour chaque composant.

De plus, la solution doit être rentable, tout en atteignant ces objectifs aussi efficacement que possible. Chaque fois que cela a été possible, sans mettre en péril les objectifs de conception susmentionnés, les périphériques utilisés dans l'architecture Internet Data Center ont été choisis pour leur rentabilité et leur simplicité d'utilisation. L'utilisation de ces périphériques offre l'avantage de la redondance sans nécessiter un matériel complet de redondance. Par exemple, les commutateurs du réseau sont configurés de manière à favoriser la répartition du trafic réseau mais ils assurent tout de même une protection contre les interruptions du trafic réseau.

Évolutivité

Il s'agit ici de la capacité d'un système à traiter un nombre croissant de demandes tout en conservant un niveau acceptable de performances. Pour être évolutifs et pour augmenter leur niveau de sécurité, les sites Web commerciaux sont souvent divisés en au moins deux parties : le système frontal (accessible au client) et le système dorsal. Les systèmes frontaux ne contiennent généralement pas d'informations durables, celles-ci sont contenues dans le système dorsal (principal). L'architecture Internet Data Center s'adapte au nombre d'utilisateurs individuels pris en charge en clonant ou en dupliquant les systèmes frontaux, ainsi qu'en instaurant un système d'équilibrage de la charge sans état afin de répartir la charge sur les clones disponibles. Les serveurs Web présents dans un ensemble cloné constituent une ferme Web. Le partitionnement du contenu en ligne sur plusieurs systèmes dorsaux favorise également l'évolutivité. Un système d'équilibrage de la charge avec état ou sensible au contexte route ensuite les requêtes vers les systèmes dorsaux appropriés.

Les principaux composants devant être évolutifs sont les composants du réseau, les composants Web frontaux, les composants d'infrastructure/d'application, les composants de données dorsaux, les composants de stockage et les composants de gestion.

Différents éléments doivent être adaptés pour chaque composant. Il s'agit de la bande passante pour le support réseau, de la puissance de traitement pour les serveurs Web et de la taille et l'E/S disque pour le stockage.

Pour mettre à l'échelle un système de manière efficace, il est essentiel d'identifier la nature de la demande croissante et son impact sur les différents composants. Après qu'un composant devenu un goulet d'étranglement a été identifié, il est possible de choisir une stratégie de mise à l'échelle verticale ou horizontale.

Mise à l'échelle verticale

La mise à l'échelle verticale est une stratégie qui consiste à augmenter la capacité d'un composant afin qu'il puisse traiter la charge. Par exemple, l'acquisition une UC plus puissante peut permettre de mettre à l'échelle un serveur Web. Un composant réseau peut être mis à l'échelle en lui permettant de passer d'un trafic de 100 méga-octets (Mo) à un trafic de 1 giga-octets (Go).

Mise à l'échelle horizontale

La mise à l'échelle horizontale est la stratégie par laquelle le nombre de composants similaires est accru, permettant ainsi d'augmenter la capacité cumulée de ces composants. Le clonage et le partitionnement, ainsi que certains services aux fonctionnalités spécialisées, permettent à ces systèmes de bénéficier d'un excellent niveau d'évolutivité en développant séparément chaque service. Par exemple, le serveur Web frontal peut être mis à l'échelle en ajoutant des serveurs. Il est possible de mettre à l'échelle la bande passante du réseau en partitionnant différents types de trafic sur différents réseaux locaux virtuels (VLAN).

Disponibilité

La disponibilité dépend largement de la rigueur informatique au niveau de l'entreprise, notamment les contrôles de modifications, des tests rigoureux et des mécanismes rapides de mise à niveau et de repli.

La clé de la disponibilité consiste à isoler les fonctions de services des défaillances des différents composants. Ceci est possible en supprimant les dépendances, en termes d'espace et de temps, du service par rapport aux différents composants architecturaux. L'approche générale à avoir de la disponibilité est donc de prévoir les défaillances possibles.

Élimination de la dépendance des différents composants

Chaque composant architectural du système est analysé afin de vérifier qu'il n'est pas dépendant d'un élément matériel exécutant une fonction spécifique ou donnant accès à des informations spécifiques. L'architecture nécessite donc à la fois des composants redondants et des mécanismes de routage redondants, de sorte que les requêtes puissent toujours être traitées par un composant sain, même en cas de défaillance.

Disponibilité dans la conception des systèmes

Les systèmes frontaux sont rendus extrêmement disponibles et évolutifs grâce à différents serveurs clonés, dont la charge est ensuite équilibrée à l'aide du service Équilibrage de la charge du système d'exploitation Microsoft Windows® 2000 Advanced Server. Les systèmes dorsaux sont plus difficiles à rendre parfaitement disponibles, principalement en raison des données ou de l'état qu'ils renferment. Ils sont rendus disponibles en utilisant un basculement de clusters pour chaque partition de données. Le basculement de clusters présuppose qu'une application peut reprendre sur un autre ordinateur disposant de l'accès au sous-système de disque du système défaillant. Le basculement de partition a lieu lorsque le nœud principal prenant en charge les requêtes sur la partition n'est plus opérationnel et que les requêtes sur cette passent automatiquement à un nœud secondaire. Ce nœud secondaire doit avoir accès aux mêmes capacités de stockage que le nœud défaillant, cette capacité de stockage doit également être dupliquée. Un réplica peut aussi augmenter la disponibilité d'un site s'il se trouve à un autre emplacement géographique.

Sécurité

Gérer les risques en assurant une protection adéquate des informations de confidentialité, de vie privée et d'intégrité est essentiel au succès d'une site commercial. La clé de l'implémentation réussie de la sécurité est de suivre une stratégie de défense en profondeur, qui définit plusieurs couches sécurisées et qui ne dépende pas d'un seul élément pour sécuriser parfaitement l'infrastructure.

Pour implémenter cette stratégie de défense en profondeur, l'architecture est séparée en différents réseaux ou segments de réseaux physiques. Cela permet de compartimenter le système de manière à ce qu'un problème sur une partie du système n'entraîne pas de perte de données.

L'effort de sécurité se concentre sur deux domaines distincts :

  • Sécurité du réseau

  • Sécurité basée sur les hôtes

La sécurité du réseau est généralement implémentée en divisant le réseau en plusieurs segments et en protégeant chacun de ces segments contre les attaques en utilisant différents périphériques réseau, notamment des routeurs avec restrictions de port, ou des pare-feu dédiés.

La sécurité basée sur les hôtes consiste à assurer à chaque serveur de l'architecture autant de sécurité inhérente que possible, de sorte que ces hôtes ne dépendent pas entièrement du réseau en ce qui concerne leur protection.

Un modèle adéquat de sécurité est essentiel dans un réseau e-business puisque le réseau de périmètre est accessible à tous sur Internet. Tout site e-business exécutant des transactions financières et renfermant des informations sensibles, telles que des références de cartes de crédit, devient la cible privilégiée d'actions malveillantes qui peuvent nuire gravement à une entreprise si des données confidentielles sont détournées.

Gestion

La gestion et les opérations se rapportent largement à l'infrastructure, aux technologies et aux processus requis pour maintenir l'état de santé d'un environnement d'application Internet et de ses services. Les objectifs d'un système global de gestion pour cette version de l'architecture IDC ont été classifiés dans les domaines clés suivants :

  • Surveillance et alertes. Conserve une trace des événements clés survenant dans le système et aide à identifier les goulots d'étranglement dans le système.

  • Gestion du contenu. Permet au système d'évoluer de manière contrôlée en accord avec l'évolution des exigences.

  • Gestion à distance. Permet de gérer le système d'emplacements distants, ce qui contribue à améliorer le degré de support du système.

  • Sauvegarde et restauration. Permet de sauvegarder les différents systèmes de manière exhaustive. Il est ensuite possible de restaurer un système quelconque ou tous les systèmes de l'architecture en fonction des besoins.

Il existe souvent une synergie considérable entre la gestion et les autres objectifs de l'architecture IDC. La raison en est qu'une infrastructure de gestion efficace fournit les outils nécessaires pour atteindre les autres objectifs de la conception. Sans infrastructure de gestion efficace, il est impossible d'atteindre tous les objectifs de conception. C'est la raison pour laquelle l'architecture Internet Data Center est largement basée sur ces quatre domaines de gestion.

Surveillance et alertes

Il est impossible de maintenir la disponibilité de l'environnement sans mécanisme de surveillance et d'alerte. Il est impératif que toute défaillance soit immédiatement signalée à l'administrateur du système de manière à être rectifiée. Dans le cas contraire, l'infrastructure peut se dégrader lentement, jusqu'à affecter les performances du site Web.

La surveillance et les alertes sont également essentielles au succès d'une stratégie de sécurité. Cette architecture Internet Data Center comprend un niveau élevé d'audit sur les principaux éléments du système. Le processus de surveillance et d'alerte est conçu pour générer des alertes en cas de détection d'événements inhabituels d'audit.

L'évolutivité peut également profiter de l'infrastructure de surveillance et d'alertes. La définition d'alertes basées sur l'usage du système permet d'agir de manière préventive et d'opérer des modifications du système avant que les utilisateurs ne soient affectés. Par exemple, une alerte peut être déclenchée lorsque l'utilisation du processeur des serveurs Web dépasse constamment la limite prédéfinie. Cela peut être l'indice qu'il est nécessaire d'installer davantage de serveurs ou de mettre à niveau le matériel des serveurs.

Gestion du contenu

L'infrastructure de gestion du contenu de l'architecture IDC garantit que les applications sont déployées sur plusieurs serveurs de manière contrôlée et cohérente et aussi rapidement que possible. Elle garantit également que les applications sont installées correctement et réduit les temps d'immobilisation provoqués par une configuration incorrecte. Cette infrastructure permet également d'augmenter le nombre de serveurs sans que la durée d'installation d'une application augmente de façon proportionnelle à ce nombre, ce qui favorise grandement l'évolutivité de l'environnement.

Gestion à distance

Le degré de support de l'ensemble de l'infrastructure est largement amélioré lorsqu'il est possible d'accéder à l'architecture à distance et de manière sécurisée et que les tâches administratives requises peuvent être exécutées en utilisant une connexion à distance. Il n'est plus nécessaire d'assurer une couverture sur site 24 heures sur 24 pour garantir la disponibilité ininterrompue du site Web de l'organisation. Combinées à l'infrastructure de surveillance et d'alertes, les technologies d'accès distant utilisées dans l'architecture IDC permettent au personnel de support de réagir à pratiquement toutes les situations, sans devoir être physiquement présent sur le site où se trouve l'équipement.

Sauvegarde et restauration

Une solution complète de sauvegarde et de restauration est cruciale pour la disponibilité de l'architecture. Cette solution doit répondre à toutes les exigences de sauvegarde et de restauration de chaque ordinateur de l'architecture Internet Data Center. Cette solution doit fournir des procédures détaillées de récupération de chaque système ainsi qu'un plan complet de récupération d'architecture. Ce plan de récupération doit s'accompagner d'un planning de récupération qui soit compatible avec les spécifications générales du système.

Éléments architecturaux

Il est important de comprendre les composants logiques qui constituent l'architecture Internet Data Center. La Figure 1 représente les concepts et les principaux éléments de l'architecture Internet Data Center.

Éléments architecturaux de l'architecture Internet Data Center

Figure 1. Éléments architecturaux de l'architecture Internet Data Center

Les principaux éléments architecturaux comprennent les clients Internet, les périphériques du réseau de périmètre, la zone démilitarisée (DMZ), le pare-feu interne et un réseau interne qui incorpore les segments de réseau pour les serveurs d'infrastructure, les serveurs de base de données et de gestion et les serveurs d'entreprise. Un réseau SAN (Storage Area Network) est utilisé pour centraliser le stockage et pour implémenter une solution de sauvegarde et de restauration à grande vitesse qui n'interfère pas avec le réseau de production.

Clients Internet

Les clients Internet se composent des utilisateurs finaux, des périphériques intelligents ou d'applications pouvant être accédés via Internet. Les utilisateurs généralement des personnes assis devant leur ordinateur et accédant à des informations sur Internet à l'aide de leur navigateur local, mais il peut s'agir de périphériques intelligents tels que les ordinateurs de poche ou des assistants personnels (PDA), des téléphones sans fil prenant en charge la transmission de données et des téléphones intelligents.

Réseau de périmètre

Le réseau de périmètre sépare le réseau extérieur (ou réseau Internet public) du réseau interne d'une organisation. Les dispositifs d'un réseau de périmètre incluent les routeurs de limites, les serveurs de mise en mémoire cache et les pare-feu. Ces dispositifs assurent connectivité, sécurité réseau et disponibilité du réseau.

Les routeurs de limites sont utilisés pour connecter l'infrastructure d'une entreprise au réseau d'un fournisseur de services Internet (ISP) offrant l'accès à Internet. Les systèmes Web d'entreprises haut de gamme doivent s'équiper d'une redondance complète en implémentant au moins deux routeurs de limites connectés à différents ISP afin d'obtenir une tolérance de panne et l'agrégation du trafic.

Un serveur de mise en mémoire cache stocke des pages Web statiques et du contenu sur un périphérique de stockage proche de l'utilisateur sur le plan physique ou logique. Les requêtes courantes sont servies depuis cet emplacement afin d'améliorer les temps de réponse et réduire les exigences générales en matière de bande passante. Les serveurs de mise en mémoire cache fonctionnent de manière optimale avec les sites principalement constitués de contenu statique.

Un pare-feu est un mécanisme permettant de contrôler le flux de données entre deux parties d'un réseau dont les niveaux de confiance sont différents. Le pare-feu de périmètre doit inspecter le trafic du réseau entre le périmètre et la zone DMZ. Il ne doit autoriser que les ports TCP/IP requis à passer par le serveur Web frontal. Étant donné que le pare-feu peut devenir un point de panne et un goulot d'étranglement pour le trafic, l'architecture est implémentée selon une configuration de basculement. Certaines des fonctions de sécurité devant être implémentées à l'intérieur des pare-feu de périmètre sont :

  • le filtrage de trafic (par adresse IP, port TCP, étiquette d'hôte, URL complète ou type de fichier)

  • la traduction des adresses réseau (NAT, Network Address Translation)

  • des mécanismes et des procédures garantissant une protection contre les attaques du type refus de service

Zone démilitarisée

La zone démilitarisée (DMZ) se situe entre le réseau de périmètre et le réseau interne et elle est délimitée des deux côtés par des pare-feu. Ce réseau comprend des serveurs fournissant deux groupes basiques de services. Le premier groupe est le service de serveur Web frontal, constitué de serveurs IIS (Internet Information Server). Ce groupe assure les services Web de base et communique avec les clients Internet grâce aux protocoles de transport standard sur Internet tels que HTTP et HTTPS. Ces serveurs sont regroupés en clusters d'équilibrage de la charge réseau. Le second groupe de serveurs assure des services de réseau, notamment DNS (Domain Naming System). Tous les serveurs de la zone DMZ peuvent également communiquer avec les ressources internes, telles que les bases de données et d'autres serveurs de composants faisant partie du réseau interne.

Pare-feu interne

Le pare-feu interne offre une protection supplémentaire aux serveurs du réseau interne. Dans l'architecture Internet Data Center, le pare-feu est positionné immédiatement derrière la zone DMZ et devant tous les segments de réseau implémentés dans l'architecture. Ceci comprend le segment de réseau de données et de gestion, le segment de réseau d'infrastructure et le segment de réseau d'entreprise (Figure 1). Cette configuration permet d'empêcher l'accès à tous les segments du réseau si un pirate s'attaque à un serveur Web. Pour pénétrer le réseau, un pirate doit alors déchiffrer les règles du pare-feu et les filtres de paquets IP pour accéder aux composants vitaux de données et d'entreprise.

Réseau interne

Le réseau interne situé derrière le pare-feu interne est constitué de zones fonctionnelles distinctes elles-mêmes divisées en segments de réseau ou en réseaux VLAN. L'implémentation de réseaux locaux virtuels (VLAN) permet d'optimiser l'isolation des différents segments et d'accroître la sécurité et la capacité de gestion des flux de données entre les composants d'applications.

Les règles de trafic peuvent être configurées sur le pare-feu interne qui n'autorise que certains serveurs et ports TCP/IP de la zone DMZ à communiquer avec les serveurs de chaque réseau VLAN. Par exemple, les ports TCP/IP autorisés à passer de la zone DMZ au réseau d'infrastructure ne doivent pas obligatoirement être ouverts dans le réseau de données et de gestion. La technologie VLAN permet à une organisation de segmenter ou de grouper les serveurs internes, en fonction des besoins en matière de fonctionnalité ou de sécurité, et d'implémenter des règles de pare-feu afin de spécifier quel trafic provenant de la zone DMZ est autorisé à atteindre chaque segment du réseau VLAN. Le réseau interne de l'architecture Internet Data Center est constitué des réseaux VLAN suivants :

  • Réseau VLAN Infrastructure. Ce réseau local virtuel comprend des serveurs DNS/de service d'annuaire Active Directory™ qui ne doivent pas être directement exposés à Internet. De plus, ce réseau VLAN s'étend afin de contenir les serveurs intermédiaires requis par la solution de gestion de contenu et tous les serveurs de logique d'entreprise devant être intégrés à la solution d'applications Web.

  • Réseau VLAN Groupe de stockage. Ce réseau local virtuel comprend les clusters Microsoft SQL Server™, les serveurs de gestion et les serveurs de réseau privé virtuel (VPN) pour une gestion sécurisée du réseau. Les serveurs de bases de données sont également connectés à un réseau SAN (Storage Area Network), qui utilise son propre matériel de mise en réseau, son support de stockage et ses canaux Fiber Channel pour garantir l'accès aux données. Ce VLAN renferme également les systèmes de sauvegarde pour l'ensemble de l'architecture.

  • Réseau VLAN d'entreprise. Ce réseau local virtuel offre un point d'accès pour la connexion au réseau de l'entreprise. Il est possible de configurer le pare-feu interne de manière à définir quels serveurs et quels ports TCP/IP sont autorisés à passer à travers la zone DMZ pour communiquer avec les serveurs du réseau intranet de l'entreprise. Le réseau de l'entreprise peut être raccordé à l'architecture Internet Data Center via un VPN, une connexion de réseau privé ou une connexion locale.

Le diagramme suivant présente un aperçu de cette architecture et met en valeur les rôles assignés aux serveurs connectés à chaque réseau VLAN :

L'architecture Internet Data Center

Figure 2. L'architecture Internet Data Center

Pour une présentation plus détaillée de la configuration réseau utilisée comme architecture Internet Data Center, reportez-vous au diagramme Architecture consolidée également présent dans cette documentation. Ce diagramme peut également être téléchargé séparément ici.

Infrastructure de sécurité

La sécurité est un problème majeur pour tous les environnements, mais elle est vitale pour les réseaux e-commerce, car ils régissent des transactions financières, renferment des informations sensibles et sont donc devenus la cible privilégiée des actions malveillantes perpétrées sur Internet. Les violations de la sécurité vont des intrusions mineures aux infiltrations compromettantes, voire des actes sérieux, dangereux et pouvant s'avérer coûteux.

La sécurité est l'un des aspects les plus importants d'une solution e-business. Sans règles strictes de sécurité, les informations confidentielles des clients, telles que les numéros de carte de crédit et les adresses personnelles, sont compromises. Les effets d'une violation de sécurité peuvent entraîner une baisse de confiance des clients et une perte importante de bénéfices.

Ainsi, pour mettre en place un modèle complet de sécurité, les points importants sont :

  • L'évaluation. Déterminez le niveau de sécurité actuel et les besoins en matière de sécurité des informations en fonction d'un niveau de risque acceptable pour l'entreprise. Procédez à l'analyse de l'écart entre le niveau de sécurité actuel et celui requis.

  • La conception. Développez une conception de solution de Systèmes de gestion de la sécurité des informations avec des recommandations spécifiques pour la solution de sécurité et un plan détaillé pour implémenter la solution.

  • Le déploiement. Orientez la conception et développez une configuration standard de production. Définissez et documentez les stratégies, les normes et les procédures de fonctionnement requises pour déployer et gérer efficacement la solution.

Lors de la phase d'évaluation, il est important de classifier le niveau de sécurité de chaque serveur de l'environnement. Par exemple, les serveurs Web sont classifiés sous public, mais comme les serveurs Active Directory sont classifiés sous secret, ils sont placés derrière le pare-feu de la couche dorsale. Les données les plus précieuses et les plus sensibles du réseau sont classifiées sous top secret est hébergées sur les serveurs dorsaux de bases de données. Les informations, notamment l'historique du compte du client, les inventaires de produits et les détails des transactions financières, sont disponibles dans la base de données principale et doivent à tout prix être sécurisées contre tout acte malveillant. Pour résoudre ce problème, des services de pare-feu avec état sont utilisés afin de sécuriser les connexions provenant des serveurs de la zone DMZ et des serveurs d'applications vers les serveurs dorsaux de bases de données.

Infrastructure de gestion

Les composants architecturaux basiques d'un système de gestion sont les consoles de gestion, la gestion à distante par le biais des services Terminal Server, les cartes matérielles de gestion de serveurs et les systèmes de sauvegarde. Les consoles de gestion sont les portails qui permettent aux administrateurs d'accéder aux systèmes gérés et de les manipuler, alors que les solutions de gestion à distance permettent d'accéder à ces consoles à partir de toute connexion sécurisée. Les systèmes de sauvegarde garantissent que l'architecture dispose des éléments nécessaires pour être parfaitement protégée contre les défaillances ou les altérations de système.

Lorsque les systèmes atteignent un certain niveau et un certain taux de modification, la gestion et le fonctionnement d'un site deviennent essentiels à la continuité du succès de l'entreprise. La simplicité de l'administration et de la configuration, la surveillance continue de la santé du système et la détection des pannes sont indispensables pour atteindre les objectifs de haute disponibilité de l'infrastructure. Pour répondre à ces exigences, il est possible d'ajouter des serveurs de gestion et des agents de gestion supplémentaires à l'architecture de base.

Cette architecture étendue exploite un ensemble de serveurs de gestion qui répartissent et déploient le contenu, surveillent l'environnement et génère des alertes, sauvegardent et restaurent l'environnement et fournissent une interface utilisateur distante. Ces serveurs sont principalement situés sur le réseau VLAN Groupe de stockage, bien que les serveurs intermédiaires soient déployés localement dans le réseau VLAN Infrastructure. Cette architecture intègre les principaux composants des procédures de gestion de système MOF (Microsoft Operations Framework), notamment :

  • Gestion des incidents (ou pannes). Ceci comprend la détection, l'enregistrement, l'affectation et l'élimination des pannes. Vous pouvez détecter les pannes soit en vous basant sur les rapports des utilisateurs, soit en utilisant des outils proactifs de surveillance et de génération d'alertes.

  • Gestion des problèmes. Ceci comprend le traitement des problèmes survenant lorsqu'une défaillance ne peut pas être réparée conformément aux procédures opérationnelles actuelles.

  • Gestion de la configuration. Ceci comprend le contrôle de configuration, les droits de modification et la planification des modifications pour tous les composants matériels et logiciels du système.

  • Gestion de la sécurité. Ceci comprend la définition et le maintien des stratégies de sécurité, qui concernent le contrôle d'accès, l'enregistrement dans les journaux et la réaction aux exceptions telles que l'échec d'authentification. Le contrôle d'accès a lieu dans les pare-feu, les serveurs VPN, les serveurs Web et d'autres serveurs. Les capacités de sauvegarde et de restauration permettent d'éviter la perte accidentelle de données.

  • Gestion des performances. Ceci comprend la planification des capacités du réseau et des serveurs, leur disponibilité, leur temps de réponse, leur débit et leur usage. Des outils de collectes de données statistiques, des techniques de régulation du réseau et des contrôles de niveau de service sont requis pour assurer que les accords de niveaux de service sont respectés.

  • Gestion de la comptabilité. Ceci comprend la gestion des équipements, le contrôle des coûts et les mécanismes de facturation interne.

Introductions aux chapitres

Ce guide de conception de système comprend les chapitres suivants, chacun traitant d'un aspect de la conception de l'architecture Internet Data Center.

Chapitre 2 - Conception de l'infrastructure réseau

Ce chapitre décrit la conception générale utilisée dans l'architecture Internet Data Center. Il présente les éléments architecturaux, tels que les routeurs et les commutateurs ainsi que les composants et la conception de l'infrastructure du Web. Il traite également de la configuration du système d'exploitation Microsoft Windows® 2000 Server et du trafic entre les réseau locaux virtuels (VLAN).

Chapitre 3 - Conception de pare-feu

Ce chapitre décrit la conception générale des pare-feu utilisée dans l'architecture IDC. Il présente différents éléments, tels que les fonctions de sécurité, la mise en mémoire cache, l'équilibrage de la charge du réseau et les réseaux privés virtuels (VPN). Il décrit aussi les autres domaines pouvant être concernés par la conception des pare-feu.

Chapitre 4 - Infrastructure de sécurité

Ce chapitre décrit le code de procédure British Standard 7799 pour la sécurité des informations et la stratégie de défense en profondeur utilisée dans la conception de la sécurité. Après avoir traité des techniques de piratage, ce chapitre décrit la configuration de la sécurité dans Microsoft Internet Information Server (IIS) et la conception pour Active Directory, Domain Name Service (DNS) et Stratégie de groupe. Les dernière partie de ce chapitre présente les mécanismes d'authentification utilisés dans l'architecture Internet Data Center.

Chapitre 5 - Conception de bases de données SQL Server

Ce chapitre se concentre sur la sécurité dans SQL Server, y compris les considérations de compte de service, de registre et d'audit. Il traite également des clusters de basculement SQL Server, des fédérations de serveurs et de l'optimisation des performances dans SQL Server.

Chapitre 6 - Conception de la solution de gestion

Ce chapitre couvre les quatre principaux domaines de gestion : surveillance de serveur et alertes, gestion à distance, déploiement de contenu et sauvegarde et restauration. Il décrit la solution de surveillance et d'alertes de l'architecture Internet Data Center, y compris la conception de cette solution et de ses composants : Microsoft Operations Manager 2000, NetIQ Operations Manager, NetIQ AppManager et Xtremesoft AppMetrics. Ce chapitre traite ensuite de la conception de gestion à distance utilisée, notamment l'utilisation des services Terminal Server pour l'accès principal et les fonctions des cartes supplémentaires de gestion de serveur. La troisième partie de ce chapitre décrit le déploiement de contenu, la gestion des modifications et le rôle de Microsoft Application Center 2000 en l'extension de l'architecture IDC de base. Les sujets traités comprennent le placement des serveurs, leur accessibilité et leur sécurité, ainsi le processus de publication de la gestion de contenu sur le Web, l'infrastructure et les réseaux de données.

Ce chapitre offre également une présentation de la solution de sauvegarde utilisée dans l'architecture Internet Data Center.

Chapitre 7 - Conception de BizTalk Server

Ce chapitre examine les problèmes posés par l'intégration d'une solution Microsoft BizTalk™ Server dans l'architecture Internet Data Center. Ce chapitre fournit des directives pour une conception appropriée de l'infrastructure à la fois pour les solutions d'intégration de partenaires utilisant la fonction de messagerie de BizTalk Server et pour l'automatisation des processus commerciaux à l'aide des services d'orchestration de BizTalk Server. Les problèmes de conception, tels que l'emplacement des composants de BizTalk Server et des services connexes, par exemple Message Queuing, sont traités conjointement aux problèmes de configuration liés à la sécurité, à la disponibilité et à l'évolutivité. Les protocoles de communications tels que HTTP, SMTP, FTP et Message Queuing y sont également étudiés et des directives pour la configuration et la sécurisation de chaque protocole vous sont fournies.

Chapitre 8 - Conception de Commerce Server

Ce chapitre décrit la conception d'infrastructure recommandée pour l'intégration d'un site e-commerce Microsoft® Commerce Server 2000 dans l'infrastructure de Microsoft Internet Data Center. Ce chapitre traite des problèmes auxquels vous pourriez être confronté lors du déploiement des différents composants d'une solution Commerce Server, notamment l'intégration des services Commerce Server, des bases de données Commerce Server et des composants de pipeline. Ce document met en exergue les principaux choix de conception qui vous aideront à mettre en place des solutions de commerce électronique sécurisé pouvant être adaptées à vos besoins.

Chapitre 9 - Élaboration de vos procédures de test

Ce chapitre décrit les procédures à suivre lors des tests d'une implémentation de l'architecture de Microsoft Internet Data Center. Ce chapitre donne des informations sur la gestion du processus de test ainsi que des critères de publication et les outils de test à utiliser. Il décrit aussi les principaux documents de test et propose un modèle et des exemples de ces documents en annexe.

Portée de la documentation

Il s'agit d'une documentation bêta préliminaire qui sera étoffée et mise à jour dans de futures versions. Par conséquent, certains aspects de l'architecture Internet Data Center sont intentionnellement traités de manière plus ou moins précise.
Les éléments considérés comme ne faisant pas partie du sujet de cette documentation comprennent des informations ou des directives spécifiques dans les domaines suivants :

  • Conception et déploiement d'applications

  • Message Queuing

  • Solution de sauvegarde

  • Déploiement de pare-feu interne

  • Évolutivité générale et données de performance

Public concerné

Ce guide est avant tout destiné aux consultants, aux informaticiens et aux développeurs en charge des tâches de planification du développement d'applications ou d'infrastructure et de leur déploiement sur plusieurs projets. Ceci inclut les rôles communs répondant à ces descriptions :

  • Architectes et planificateurs devant gérer les efforts d'architecture pour leur organisation

  • Analystes d'entreprise et décideurs dont les objectifs et les exigences commerciaux requièrent un support informatique

  • Consultants, juniors et seniors, qui ont besoin d'outils de transfert d'informations pour leurs partenaires et leurs clients professionnels

Cependant, les autres lecteurs impliqués dans la planification, l'élaboration et l'implémentation d'un projet d'infrastructure trouveront dans ce guide des informations utiles et pertinentes. Le développement d'infrastructure implique de nombreux rôles et chaque personne engagée dans le projet a besoin d'informations de type et de niveau différents. Pour des informations sur les rôles impliqué dans un projet de développement de logiciel dans le Modèle d'équipe Microsoft Solutions Framework, reportez-vous à la page Microsoft Solutions Framework Site en anglais

Conventions de style

Ce guide utilise les conventions de style et la terminologie suivants.

Élément

Signification

caractères en gras

Caractères que vous tapez exactement comme indiqué, comprenant des commandes et des commutateurs. Les d'interface utilisateur sont aussi en caractères gras.

caractères en italique

Emplacement réservé aux variables pour lesquelles vous spécifiez une valeur. Par exemple, Nomdefichier.ext peut faire référence à tout nom de fichier valide pour la situation actuelle. La terminologie nouvelle apparaît en italique la première fois qu'elle est utilisée.

police Monospace

Exemples de codes.

%SystemRoot%

Le dossier dans lequel est installé Windows 2000.

Remarque

Signale un complément d'information.

Important

Signale un complément d'information essentiel à l'exécution d'une tâche.

<< 1 2 3 4 5 6 7 8 9 >>

Dernière mise à jour le vendredi 1 mars 2002

Pour en savoir plus