• Aucun résultat trouvé

MIR Intégration. Réponse à appel d offre Intégration Systèmes et Réseaux

N/A
N/A
Protected

Academic year: 2022

Partager "MIR Intégration. Réponse à appel d offre Intégration Systèmes et Réseaux"

Copied!
159
0
0

Texte intégral

(1)

Introduction (Jérôme TENEUR) 1

Groupe CFG

MIR Intégration

Réponse à appel d’offre

Intégration Systèmes et Réseaux

Dans le cadre de l’appel d’offre émit par la société Aristote pour le renouvellement complet de son système d’information, nous vous proposons au travers de ce rapport d’étude, une analyse complète visant à répondre à tous les besoins décris. Mais nous tâcherons également à faire valoir notre expertise en apportant une réelle plu value visant à accroitre toujours plus votre productivité et votre compétitivité.

Teneur Jérôme - Gayral Bastien - Promé Rudy - Desseaux Vincent - Hamon Arnaud - Delahaie Jérôme

(2)

Introduction (Jérôme TENEUR) 2

PERSONNES MORALES

Elèves Apprentis :

[Promotion ERE P43]

Jérôme TENEUR (Gérant de la filiale MediaNetwork) Delahaie Jérôme (Chef de Projet Intégration) Gayral Bastien

Promé Rudy Desseaux Vincent Hamon Arnaud

mir_g2@googlegroups.com

Ecole d’accueil :

CFA AFTI

Domaine de Corbeville RD 128 - BP46

91401 ORSAY Cedex

PERSONNES FICTIVES

Maison mère

Groupe CFG

Domaine de Corbeville RD 128 - BP46

91401 ORSAY Cedex

Filiale du groupe :

MediaNetwork Domaine de Corbeville RD 128 - BP46

91401 ORSAY Cedex

Client final :

Aristote

Domaine de Corbeville RD 128 - BP46

91401 ORSAY Cedex

NOTE DE CONFIDENTIALITE

Certaines données et informations de ce rapport d’étude, qu’elles soient explicites, sous-entendus ou masques, sont strictement confidentielles.

Dès lors, toute reproduction, sous quelque forme que ce soit, est formellement interdite ; sauf accord préalable de l’une des personnes morales précédemment citées.

(3)

Introduction (Jérôme TENEUR) 3

VERSIONS DU DOCUMENT

Version Modifications apportées Date

1.0 Première version du document 04/04/2011

1.1 Correction de syntaxe et d’orthographe 07/04/2011

1.2 Refonte de la mise en page 09/04/2011

(4)

Introduction (Jérôme TENEUR) 4

SOMMAIRE

Introduction (Jérôme TENEUR) ... 7

Chapitre I. Architecture réseau ... 8

Chapitre II.

II.1 Portrait de la solution réseau (Jérôme TENEUR) ... 9

II.2 Etudes des flux (Jérôme TENEUR) ... 10

II.3 Interconnexion des bâtiments (Jérôme TENEUR) ... 11

II.4 Infrastructure de câblage (Vincent DESSEAUX) ... 12

II.5 Architecture physique du LAN (Jérôme TENEUR) ... 13

II.6 Architecture Logique du LAN (Jérôme TENEUR) ... 17

II.6.1 Plan d’adressage ... 17

II.6.2 VLANs ... 18

II.6.3 Spanning Tree ... 19

II.6.4 Routage ... 19

II.6.5 Plan de nommage ... 19

II.7 Architecture WAN (Vincent DESSEAUX) ... 20

II.8 Intégration de la VOIP (Vincent DESSEAUX) ... 22

Energies Informatiques ... 23

Chapitre III.

III.1 Architecture Active Directory (Jérôme TENEUR) ... 24

III.2 Architecture DHCP (Vincent DESSEAUX) ... 27

III.3 Architecture DNS (Rudy PROME) ... 28

III.4 Architecture de Messagerie Collaborative (Rudy PROME) ... 29

III.5 Architecture de Messagerie Instantanée (Rudy PROME) ... 30

III.6 Messagerie unifiée (Vincent DESSEAUX) ... 31

III.7 Partages de fichiers (Bastien GAYRAL) ... 32

III.8 Gestion de contenu (Bastien GAYRAL) ... 33

III.9 Site Web de l’entreprise (Bastien GAYRAL) ... 34

III.10 Accès aux outils de bureautique Office (Arnaud HAMON) ... 35

III.11 Accès à des systèmes d’impression partagés pour tous les utilisateurs (Arnaud HAMON) ... 36

III.12 Reverse Proxy (Bastien GAYRAL) ... 37

III.13 Gestion des Machines Utilisateurs (Rudy PROME) ... 38

(5)

Introduction (Jérôme TENEUR) 5

Sécurité du système d’information ... 39

Chapitre IV.

IV.1 Choix des équipements Firewall (Jérôme TENEUR) ... 40

IV.2 Sécurisation de l'Accès Internet (Arnaud HAMON) ... 41

IV.3 Relai de messagerie SMTP (Jérôme TENEUR) ... 42

IV.4 Accès VPN (Bastien GAYRAL) ... 43

IV.5 Architecture à clés publiques (Jérôme DELAHAIE) ... 44

IV.6 Politique de mise à jour des correctifs de sécurité (Vincent DESSEAUX) ... 45

IV.7 Politique Antivirale (Rudy PROME) ... 46

IV.8 Sécurité des postes nomades (Vincent DESSEAUX) ... 47

IV.9 Sécurisation Physique du Système d’Informations (Rudy PROME) ... 48

IV.10 Prévention du vol de matériel (Jérôme DELAHAIE) ... 49

Administration et surveillance du système ... 50

Chapitre V.

V.1 Surveillance du système et gestion des alertes (Arnaud HAMON) ... 51

V.2 Gestion du parc informatique (Bastien GAYRAL) ... 52

V.3 Aide au déploiement de masse (Vincent DESSEAUX) ... 53

V.4 Administration et prise en main à distance (Vincent DESSEAUX) ... 54

Méthodologie de déploiement ... 55

Chapitre VI.

VI.1 Formation des utilisateurs (Arnaud HAMON) ... 56

VI.2 Planification du déploiement (Jérôme DELAHAIE) ... 57

Exploitation des infrastructures ... 58

Chapitre VII.

VII.1 Gestion des mises en production (Bastien GAYRAL) ... 59

VII.2 Service Level Agreement (Jérôme DELAHAIE) ... 60

Bilan financier ... 63

Chapitre VIII.

VIII.1 Intérêts de la Virtualisation (Rudy PROME) ... 64

VIII.2 Identification du Matériel et des Licences Nécessaires (Rudy PROME) ... 65

VIII.3 Matériel et Licences à Acheter (Rudy PROME) ... 67

VIII.4 Total Cost of Ownership (Rudy PROME, Jérôme TENEUR, Jérôme DELAHAIE) ... 69

VIII.4.1 Principe ... 69

VIII.4.2 E.C.U. ... 69

VIII.4.3 S.C.U. ... 69

VIII.4.4 O.C.U. ... 69

VIII.4.5 T.C.U. ... 69

VIII.4.6 A.C.U... 69

VIII.4.7 Conclusion ... 69

(6)

Introduction (Jérôme TENEUR) 6

Conclusion (Jérôme TENEUR) ... 70

Chapitre IX. Schéma d’architecture générale (Jérôme TENEUR) ... 70

Chapitre X. Annexes ... 71

Chapitre XI.

XI.1 Lexique ... 72

XI.2 Schéma de l’architecture réseau de chaque site (Jérôme TENEUR) Orsay ... 74

XI.3 Représentation physique de l’architecture réseau (Jérôme TENEUR)... 78

XI.4 Infrastructure de câblage (Vincent DESSEAUX) ... 80

XI.5 Architecture WAN (Vincent DESSEAUX)... 86

XI.6 Plan d’adressage (Jérôme TENEUR) ... 91

XI.7 Règles de nommage du matériel (Jérôme TENEUR) ... 92

XI.8 Topologie Spanning Tree (Jérôme TENEUR) ... 93

XI.9 Redondance de routeur MPLS : HSRP (Jérôme TENEUR) ... 94

XI.10 La qualité de service (Vincent DESSEAUX) ... 95

XI.11 Annuaire Active Directory (Jérôme TENEUR) ... 97

XI.12 Architecture DNS (Rudy PROME) ... 110

XI.13 Architecture DHCP (Vincent DESSEAUX) ... 111

XI.14 Firewall (Jérôme TENEUR) ... 113

XI.15 Sécurisation des accès Internet (Arnaud HAMON)... 114

XI.16 Reverse Proxy (Bastien GAYRAL) ... 117

XI.17 Architecture de Messagerie Collaborative (Rudy PROME) ... 120

XI.18 Architecture de Messagerie Instantanée (Rudy PROME) ... 124

XI.19 Partage de fichiers (Bastien GAYRAL) ... 125

XI.20 Gestion de contenu (Bastien GAYRAL) ... 129

XI.21 Relai SMTP (Jérôme TENEUR) ... 132

XI.22 Virtualisation (Arnaud HAMON) ... 133

XI.23 Système d’impression (Arnaud HAMON) ... 134

XI.24 Accès outil de bureautique office Applications métiers (Arnaud HAMON) ... 135

XI.25 Accès VPN (Bastien GAYRAL) ... 137

XI.26 Politique de mise à jour (Vincent DESSEAUX)... 138

XI.27 Politique Antivirale (Rudy PROME) ... 141

XI.28 Politique de sauvegarde (Arnaud HAMON) ... 143

XI.29 Aide au déploiement de masse (Vincent DESSEAUX) ... 147

XI.30 Outil de monitoring système et réseau (Arnaud HAMON) ... 148

XI.31 Planification du déploiement (Jérôme DELAHAIE) ... 150

XI.32 Charte informatique (Jérôme TENEUR) ... 153

XI.33 Table des figures ... 157

XI.34 Bibliographie ... 157

(7)

Introduction (Jérôme TENEUR) 7

Introduction (Jérôme TENEUR) Chapitre I.

Dans le cadre de l’appel d’offre émit par la société Aristote, nous vous proposons au travers de ce document une analyse visant à répondre à chacun des besoins exprimer. Mais nous tâcherons également de faire valoir notre expertise et notre savoir-faire en vous proposant des solutions innovantes, technologiquement pérennes, et qui vous garantirons un cout d’exploitation le plus faible possible pour une rentabilité toujours plus importante.

Comme le met en avant le cahier des charges, nous comptons exploiter au maximum les contraintes liées à la structure de la société Aristote. Par exemple, chaque site distant pourra fonctionner de manière autonome, et nous permettra de garantir la sécurité des données (au sens pérennité) grâce à des réplications inter-sites. Mais nous prévoyons également de gérer au plus près de vos besoins l’utilisation de la bande passante inter-site (c'est-à-dire les liaisons opérateur) en vous garantissant une disponibilité maximale vous offrant ainsi une expérience en environnement de production, la plus fluide possible.

A noter également que les aspects sécurités, que ce soit des données, du système d’information vis-à-vis de l’internet, ou encore la segmentation des flux en interne, sont des composantes largement pris en compte tout au long de notre rapport d’analyse. Ainsi nos experts sécurités font valoir toute leur expertise et leur expérience au travers de ce rapport, et ce afin de vous garantir une sécurité la plus proche de la perfection et la plus évolutive possible.

Nous allons donc dans un premier temps vous présenter l’architecture réseau de la solution.

Cela va du câblage des bâtiments, jusqu’aux liaisons inter-site, en passant par tous les besoins en matière de matériel, et la définition des protocoles mis en place, mais également en vous proposant les évolutions possible pour l’intégration de la VOIP.

Dans un second temps, nous vous présenterons les énergies informatiques, c'est-à-dire la mise en place des services actifs participant au fonctionnement de l’architecture système de l’infrastructure. Au travers de ces énergies informatiques, nous retrouverons les informations liées à la mise en place et au fonctionnement de l’annuaire d’entreprise, mais également de tous les services rendus aux utilisateurs tel que la messagerie ou la publication de documents…

Dans un troisième temps, comme stipulé plus haut, nous nous attarderons sur l’aspect sécurité de l’infrastructure, et sécurité des données. Cela se fera au travers de la présentation de l’implémentation de firewall, des VPN, ou encore de la politique antivirale. Tous ces éléments nous permettrons de définir une politique de sécurité du système d’information.

Ensuite, nous tâcherons de répondre à une problématique que vous avez introduite dans le cahier des charges, mais qui doit être sérieusement pris en considération : l'administration et de surveillance du système d’exploitation. C’est en effet au travers de la mise en place de ces moyens que vous serez en mesure de contrôler votre architecture et assurerez la continuité de service pour vos utilisateurs.

Enfin, dans une dernière partie, nous vous proposerons une méthodologie de déploiement et un bilan financier de la mise en place d’un tel système d’information. Ces deux éléments seront une estimation la plus réaliste possible basée sur notre expérience et nos partenariats avec des constructeurs

(8)

Architecture réseau 8

Architecture réseau Chapitre II.

Le premier point à considérer concerne la qualité de service. Le réseau d’entreprise devant faire transiter à la fois le téléphone, la vidéo et les données.

Il faut calculer le débit maximal de la classe la plus prioritaire, c’est-à-dire les paquets de flux téléphonique et l’ensemble des paquets des applications qui auront été mis dans cette classe, et s’assurer que le débit Ethernet est largement supérieur à ces valeurs. C’est là un aspect permettant de garantir la disponibilité et la pérennité de l’infrastructure.

Nous devrons également isoler des sous-réseaux à l’intérieur du réseau d’entreprise, l’utilisation de VLAN est particulièrement appréciée. Ces derniers permettent de mettre en œuvre des isolations entre sous-réseaux et de mettre en relation simplement des équipements qui doivent se parler.

Les schémas que vous rencontrerez ci-dessous mettent en avant des firewalls.

L’objectif des pare-feu est de stopper les flux menaçants pour l’entreprise et d’empêcher que certains flux ne sortent de l’entreprise. Les pare-feu jouent sur le port qui porte le numéro indiquant l’application transportée. Cette information pouvant être modifiée, nous nous appuierons sur des pare-feu introduisant des filtres applicatifs permettant de déterminer précisément les applications qui peuvent passer.

Pour compléter ce panorama nous traiterons de l’aspect opérateur, tant pour l’interconnexion des sites distants que pour l’accès à Internet des quatre sites.

(9)

Architecture réseau 9

II.1 Portrait de la solution réseau (Jérôme TENEUR) II.1.1 Rappel des besoins et contraintes

Dans le cadre de l’intégration du nouveau système d’information, une liste des contraintes a été dressée dans le cahier des charges.

Pour résumer, nous avons donc quatre sites distants (Orsay – Bayonne – Sophia Antipolis – Bruxelles) devant être interconnecter au moyen d’une solution opérateur. L’infrastructure devra être opérationnelle 24h/24 et 7 jours sur 7, et la tolérance de pannes est de quelques minutes. De telles contraintes impliquent la mise en place d’une forte redondance pour tous les équipements réseau et système.

Il est également demandé, la possibilité que des utilisateurs puissent travailler à distance (de chez eux, hôtel, … ) et ce, dans un environnement fortement sécurisé. La sécurité est un point très sensible et fortement mis en avant dans le cahier des charges. Nous nous attacherons donc à mettre en place des solutions en couvrant tous les aspects, et ce directement depuis l’architecture réseau.

Notons également qu’Aristote souhaite que l’infrastructure fasse l’objet d’une étude concernant l’hypothétique mise en place d’une solution de VoIP (une solution de voix sur IP vous est également proposée dans cette étude).

Enfin, les informations du CDC nous permettent d’établir un listing des utilisateurs en fonction de leur répartition géographique et de leur direction d’appartenance :

Orsay Bayonne Sophia Antipolis Bruxelles Total

Direction Générale 40 4 1 15 60

Direction Administrative et Financière 30 10 0 5 45

Direction Commerciale et Marketing 70 16 4 25 115

Direction Etudes 255 20 10 40 325

Direction Production 5 130 65 75 275

Total 400 180 80 160 820

II.1.2 Portrait de la solution réseau

Tout d’abord nous devons interconnecter les quatre sites distants ; pour cela plusieurs technologies opérateurs sont envisageables. Cette interconnexion devra supporter vos besoins en termes de bande passante, notamment pour le site d’Orsay, siège d’Aristote et cœur du système d’information.

Ensuite, la nécessité d’une infrastructure hautement sécurisé impliquera l’implémentation d’un système de chiffrement pour les communications inter-sites. Le paysage des solutions envisageable sera et leurs applications sera développé dans le chapitre sécurité VPN.

Toujours dans un principe de sécurité, et de par notre expérience, nous préconisons la mise en place d’un seul point d’entré Internet pour les quatre sites. Il s’agira en réalité d’une double entrée car deux liens opérateur nous raccorderont à Internet, pour garantir une continuité de service et un partage de charge. Cet accès sera ensuite « partagé » aux trois sites distants via les liaisons inter-sites.

Du point de vu réseau interne d’Aristote, nous distinguerons trois types de réseau : - Réseau serveurs internes

- Réseau DMZ - Réseaux utilisateurs

La distinction de ces réseaux représente un aspect de la sécurité, notamment grâce aux VLAN et aux règles d’accès qui s’appuieront sur cette segmentation.

Enfin, notons que la distinction des utilisateurs et leur direction d’appartenance se fera également d’un point de vu réseau, et ce toujours dans une optique de sécurité (avec une séparation des flux).

(10)

Architecture réseau 10

II.2 Etudes des flux (Jérôme TENEUR)

L’étude des flux réseaux répond à deux objectifs. Dans un premier temps cela nous permettra d’évaluer la charger réseau totale que devra supporter l’infrastructure. Dans un second temps cette étude sera un moyen d’identifier précisément les flux transitant par les firewalls et ainsi de lister les autorisations qui devront être misent en place.

Types de flux Protocoles utilisés Volumes Fréquence Communication

Communication en temps réelle

SIP pour la messagerie

instantanée Moyen Moyenne

Inter Site SIP pour la vidéoconférence

Elevés

Basse

SIP pour la voix Très élevée Inter Site

Orsay Internet

Messagerie

IMAP4/MAPI/SMTP pour les

mails Elevés Très élevée Inter Site

Orsay Internet ActiveSync pour la

synchronisation Smartphone/ PocketPC

Basse Basse

Internet Orsay HTTP/HTTPS pour l’OWA Moyen Moyenne

RPC sur HTTP pour Outlook

Anywhere Elevés Elevés

Réplication AD RPC Basse Quotidienne Inter Site

Résolution de noms DNS Faibles Très élevée Inter Site

Orsay Internet

Navigation Internet

HTTP

Elevés Elevée Inter Site

Orsay Internet HTTPS

FTP

Supervision SNMP/Netflow Moyenne Très élevée OrsayAutres sites

Administration SSH

Moyenne Moyenne

OrsayAutres sites

RDP Très élevée

VPN IPsec

Moyenne Basse Internet Orsay

SSL

Echange Fichier DFS Très élevés Quotidienne Inter Site

Application Métier HTTPS Elevés Très élevée Inter Site

Serveurs Publiés HTTP

Moyenne Moyenne Internet Orsay

HTTPS

Mise à Jour WSUS Basse Quotidienne Inter Site

Anti-virus Protocole Propriétaire Basse Quotidienne Inter Site Terminal Server

RDP

Elevés

Elevée Inter Site

TS Web/Gateway Moyenne Internet Orsay

OrsayAutres sites

(11)

Architecture réseau 11

II.3 Interconnexion des bâtiments (Jérôme TENEUR) II.3.1 Rappel du besoin

Comme stipulé dans le cahier des charges, les sites d’Orsay, de Bayonne et de Bruxelles sont composés de plusieurs bâtiments. Nous allons donc, ci-dessous, proposer plusieurs solutions visant à interconnecter ces bâtiments, en prenant soin d’offrir le meilleur compromis entre performances et coûts.

II.3.2 Solutions proposées

Aux vus des plans fournis dans le cahier des charges, et le fait que le point d’entrée opérateur se trouve toujours dans le bâtiment principal de chaque site, nous pouvons en tirer 2 scénarios possibles. En effet, ces trois sites, étant composés de 3 bâtiments chacun, nous pouvons :

- Relier les deux bâtiments secondaires directement au site principal via une double fibre optique

- Créer une boucle réseau entre les 3 bâtiments

Avantage(s) Inconvénient(s) Avantage(s) Inconvénient(s)

- agrégat des liens - couteux en fibre

- si rupture d’une tranché : perte d’un bâtiment

- deux routes de sortie pour les bâtiments secondaires

- boucle gérée par STP

- une tranché supplémentaire

II.3.3 Préconisations

Ces deux scénarios offrent une redondance des liens et donc garantissent une continuité de service en cas de rupture de l’un d’entre eux. Cependant, nous préconisons une architecture maillée telle que dans le second scénario. En effet, les coûts étant similaires, nous distinguerons la meilleure garantie de continuité de service dans le second.

(12)

Architecture réseau 12

II.4 Infrastructure de câblage (Vincent DESSEAUX)

II.4.1 Rappel des besoins

L’infrastructure de câblage mise en place devra pouvoir être en mesure de supporter des débits de 1 Gbit/s. Il est également demandé de prendre en compte les perspectives de croissance prévue de 20% de ses effectifs en 5 ans tout en garantissant une solution pérenne, évolutive et répondant aux demandes de performance et de disponibilité des utilisateurs.

II.4.2 Câblage inter-bâtiments

Afin de relier les bâtiments entre eux, nous avons choisi de mettre en place des liaisons en fibre optique multi mode 62.5/125 µm de classe OM2 avec connecteurs SC. Cette fibre est idéale pour les liaisons de courtes distances et permet ainsi d’atteindre des débits de 10 Gb/s sur une distance de 300m. Afin de garantir une tolérance aux pannes, l’architecture réseau proposée repose sur des cœurs de distribution redondés. Il est donc nécessaire de disposer de 4 brins par liaison inter-bâtiments (deux pour la réception et deux pour la transmission).

II.4.3 Câblage inter-étages

Un coffret de brassage sera installé à chaque étage des bâtiments, à l’emplacement du passage de câbles excepté le rez- de-chaussée qui lui sera équipé d’un local technique. Afin d’assurer la liaison entre les équipements réseaux de chaque étage, tout en garantissant qu’aucun bruit électromagnétique ne viendra les perturber, nous vous préconisons également l’utilisation de liaisons fibres optiques multi mode 62.5/125 µm de classe OM2 avec connecteurs SC.

II.4.4 Câblage des étages

Le câblage des différents étages sera élaboré selon les effectifs ainsi que sa croissance de 20 % prévu sur 5 ans. De plus, nous préconisons l’ajout de 6 prises supplémentaires par étage, qui seront installées pour l’interconnexion de bornes WIFI ou de photocopieurs. Les étages seront donc équipés de prises RJ45 avec des câbles réseau FTP à 4 paires torsadées de catégorie 6 permettant un débit de 1 Gb/s.

II.4.5 Proposition d’architecture

Le premier cas d’architecture met en avant une tranchée commune pour relier les bâtiments. Cette solution à comme avantage d’être la moins coûteuse, mais cela implique que si pour quelconque raison, la liaison physique vient un jour à se détériorer, un ou plusieurs bâtiments seront impactés.

Le second cas d’architecture, que nous vous préconisons, met en avant plusieurs tranchées ainsi qu’une topologie en anneau, ce qui permet de prévoir systématiquement deux points de pénétration pour le passage des câbles. Cette solution est certes plus coûteuse, mais permet de contrecarrer le risque d’isolation d’un bâtiment annexe.

Architecture de câblage préconisé pour le site d’Orsay

Figure 1 - Schéma de l’infrastructure de câblage proposé pour le site d’Orsay Note : De plus amples informations en annexe

(13)

Architecture réseau 13

II.5 Architecture physique du LAN (Jérôme TENEUR)

Le rappel des besoins et contraintes ayant été traité dans la partie « Portrait de la solution réseau », nous ne reviendrons pas dessus ici.

II.5.1 Architecture générale retenue

La solution que nous avons retenue est une architecture dite en triangle sur trois niveaux. Cette architecture présente le meilleur compromis entre la redondance et la facilité d’administration.

Les différents niveaux du réseau sont nommés comme suit :

1. Accès : Les équipements d’extrémité se trouvant dans les différents étages et permettant de donner l’accès au réseau aux utilisateurs sont appelés les équipements d’accès ou Edge.

(Le site de Sophia sera dépourvu d’équipement de cœur de réseau.)

2. Distribution : Les équipements réalisant le lien entre les équipements d’accès et les cœurs de réseau sont appelés les équipements de distribution. Ils sont situés dans le local technique du rez-de-chaussée de chaque bâtiment.

Cet équipement est nécessaire sinon nous aurions autant de fibre optique entre les bâtiments qu’il y a de switch d’étage, ce qui n’est pas envisageable.

3. Les équipements réalisant le cœur du réseau en interconnectant tous les équipements de distribution sont appelés équipements de cœur ou de Backbone. Ils seront installés dans le bâtiment qui recevra la liaison avec l’opérateur. Les commutateurs hébergeant les serveurs seront connectés directement sur les cœurs. Les cœurs s’occuperont du routage, du lien avec le réseau MPLS de l’opérateur et du lien avec le pare-feu Internet.

Figure 2 - Modèle infrastructure réseau

Note : Les schémas des réseaux physiques sont disponibles en annexes ainsi que la liste des équipements actifs.

(14)

Architecture réseau 14

II.5.2 Exemple avec l’architecture d’Orsay

Nous avons donc ici une architecture pyramidale composée de matériel Cisco, dans un ensemble garantissant un routage et une commutation hiérarchique.

On remarquera que tous les liens sont redondés, créant ainsi des boucles réseaux. La haut disponibilité et la gestion des boucles réseaux sera expliqué dans la partie suivante.

note : Un schéma des réseaux physiques de chaque site, dans un plus grand format, est disponible en annexe

(15)

Architecture réseau 15

II.5.3 Choix des équipements réseaux

II.5.3.1 Cœur de réseau

Pour le site d’Orsay, nous préconisons de mettre en place deux châssis Cisco 6506 pour le Backbone. Cet équipement convient à l’architecture mis en place. En effet, le Backbone d’Orsay sera grandement sollicité étant donné qu’il fera le lien entre les accès à l’Internet, le réseau MPLS, les serveurs hébergés pour tous les sites, la DMZ, et tous les utilisateurs.

Le choix de l’équipement de cœur c’est fait d’abord en fonction des besoins et contraintes décrites dans le CDC. Nous avons naturellement orienté notre choix vers des produits Cisco pour la qualité de ses produits et pour l’expérience Cisco.

Nous préconisons ensuite un produit de la gamme de catalyst 6500 car ce dernier couvre l’ensemble des attentes exprimées pour un dimensionnement cohérant. Enfin, le modèle catalyst 6506 a été sélectionné sur la base de notre expérience et d’une étude réalisé par Cisco sur la gamme des 6500.

Pour plus d’informations, retrouvez le comparatif des Catalyst 6500 à l’adresse suivante : www.cisco.com/Web/FR/documents/pdfs/datasheet/switching/CATALYST_6500.pdf

Ces commutateurs possèdent 6 slots qui peuvent accueillir des modules de différents types. Ils seront équipés des cartes suivantes :

Slot 1: un module 24 ports SFP pour la connexion des commutateurs d’extrémité hébergeant les commutateurs de distribution et la connexion avec le pare-feu et le routeur MPLS.

Slot 2 : Un module Cisco 4402 pour la gestion du réseau sans fil.

Slot 3 : Une carte de supervision sup720-3C avec 3 ports gigabit (2 SFP et un 10/100/1000) pour le lien d’agrégat avec l’autre cœur ainsi que 2 ports X2 10GbE qui ne seront pas utilisés pour le moment.

Pour les cœurs de réseau des autres sites, comme pour les équipements de distribution, nous avons choisi de mettre en place des Cisco 3750 avec 12 ports SFP (1Gbits/s).

II.5.3.2 Cœur de distribution

Le cœur de distribution devant gérer une charge également très importante, nous préconisons les catalyst 3750. Ces derniers disposent de deux ports « stackwise » en face arrière pour les connecter les uns aux autres en formant un seul et unique équipement (une seule configuration, un nom unique, une adresse IP unique …). Un des équipements du stack est élu master du stack. Il gère l’ensemble du stack (on peut le comparer à une carte de supervision d’un châssis mais pour le stack). En cas de défaillance de ce Switch master, un autre Switch du stack est élu master. Dans les ports SFP, il faut rajouter un connecteur appelé SFP (Small Form-Factor Pluggable). Sur le réseau d’Aristote, ce sera des SFP SX. Ceci permettra de réaliser la connexion uplink entre un stack et les deux Switch de distribution et ceci permettra de faire le lien entre les Switch de distribution avec les cœurs.

II.5.3.3 Accès réseau

Pour les commutateurs d’accès de tous les sites, nous avons choisi de mettre en place des Cisco 2960 avec 24/48 ports cuivre POE avec 2/4 ports SFP (1Gbits/s).

(16)

Architecture réseau 16

II.5.4 Haute disponibilité et continuité de service

Au travers de l’infrastructure, nous garantissons la haute disponibilité et une continuité de service en cas de rupture d’un lien ou de perte d’un équipement réseau. Pour cela nous mettons en place de la redondance à deux niveaux : physique et logique.

La redondance physique est assurée de plusieurs manières : - Cœur de réseau

o Double alimentation (type hot-swappable : retirable à chaud) o Le Backbone est constitué de deux équipements.

o Un lien d’agrégation (2fibres optiques) 802.3ad entre ces deux équipements.

o Pour le site d’Orsay, les cœurs sont connectés chacun à un pare-feu afin de maintenir l’accès au WAN en cas de défaillance d’un cœur, d’un routeur WAN ou d’un pare-feu.

- Cœur de distribution

o Constituer de deux équipements

o Présence d’un double lien d’agrégat entre les deux équipements o Ces équipements sont directement liés au deux backbones - Accès réseau

o Les équipements d’accès sont regroupés en stack grâce à la technologie stackwise.

o Les piles d’accès sont connectées par leur premier équipement au premier Switch de distribution et par leur dernier équipement au deuxième Switch de distribution.

La redondance logique se fera au travers de deux protocoles :

- Spanning-Tree : Tous les équipements ont la fonctionnalité Spanning-tree activée pour gérer la redondance de lien afin de permettre la redondance physique sans avoir de boucle de niveau 2.

- HSRP : Les deux cœurs ont la fonctionnalité HSRP d’implémentée afin de gérer la redondance de passerelle par défaut pour chacun des VLANs.

II.5.5 Réseau Sans Fil

Concernant le réseau sans fil, nous mettrons en place sur chaque site un contrôleur WIFI Cisco 4402. Le site d’Orsay sera pourvu de deux contrôleurs WIFI qui seront mis en place dans les slots des Châssis Cisco 6500. Afin de sécuriser les flux WIFI, il y aura un réseau privé avec authentification forte de type EAP-PEAP avec un chiffrement AES. Les collaborateurs pourront s’authentifier à l’aide de leur compte du domaine et ils auront accès à tout le réseau d’Aristote. Les invités auront uniquement accès à Internet et pourront s’authentifier à l’aide d’un portail captif. Il n’y aura aucun chiffrement sur ce réseau.

Une étude d’emplacement des bornes WIFI sera planifiée afin d’optimiser la couverture WIFI au niveau des bâtiments mais nous prévoyons pour chaque bâtiment 3 bornes Wifi Cisco Aironet 1142.

(17)

Architecture réseau 17

II.6 Architecture Logique du LAN (Jérôme TENEUR) II.6.1 Plan d’adressage

Le plan d’adressage que nous allons mettre en place s’organisera autour de trois réseaux IP : - 10.0.0.0/8 pour la DMZ

- 172.16.0.0/11 pour les serveurs et utilisateurs - 192.168.0.0/24 pour les interconnexions des routeurs

Ensuite nous devons distinguer différents éléments, afin d’avoir un adressage cohérent et faciliter la caractérisation d’un utilisateur en fonction de son adresse IP. Nous prendrons en compte :

- Le site géographique - La direction d’appartenance

Le plan d’adressage devra prendre en considération l’augmentation prévisionnelle du nombre d’employé, à savoir 20%

d’utilisateurs supplémentaire dans les 5 prochaines années. De plus, le nombre de périphériques utilisateurs s’appuyant sur IP étant en constante augmentation ces dernières années, il nous parait judicieux de prévoir plusieurs IP par utilisateurs (par exemple pour des Smartphone en WiFi). Ainsi en plaçant le masque réseau à 20, nous avons 4094 IP disponibles pour 16 sous-réseaux, ce qui est largement suffisant pour l’infrastructure à mettre en place.

Ainsi nous aurons un plan d’adressage comme ci-dessous :

Figure 3 - Plan d'adressage

(18)

Architecture réseau 18

II.6.2 VLANs

Les VLANs permettent de segmenter les réseaux comportant un nombre de stations important de façon à : - Diminuer les domaines de broadcast

- Identifier les flux pour gérer des droits d’accès

Afin de rendre plus souple la diffusion des Vlans dans chaque équipement, nous allons mettre en place le protocole VTP.

Ce protocole permet une diffusion dynamique des Vlans. Sur les cœurs de chaque site, nous mettrons le VTP en mode serveur et sur les équipements de distribution et d’accès, nous mettrons le VTP en mode client. Cependant, il faudra inscrire manuellement les Vlans sur les cœurs.

Concernant la configuration des Vlans sur les ports d’accès clients des commutateurs, nous allons mettre en place des VLANs statiques. En effet, même si la gestion statique des Vlans sur les switchs d’accès est compliquée à maintenir sur un grand réseau, nous garantissons ainsi un niveau de sécurité supplémentaire en rendant encore plus compliqué une tentative d’usurpation d’identité.

Néanmoins, les ports interconnectant les commutateurs seront fixés en mode Trunk Cisco et les ports interconnectant le pare-feu et le routeur MPLS seront fixés en port Access Cisco.

Nous aurons donc finalement des VLAN organisé ainsi :

Type de flux VLAN ID

Orsay Bayonne Sophia Antipolis

Bruxelles

Direction Informatique 2 2 2 2

Direction Générale 3 103 203 303

Direction Administrative et Financière 4 104 204 304

Direction Commerciale et Marketing 5 105 205 305

Direction Etude 6 106 206 306

Direction Production 7 107 207 307

Réseau VPN 8 108 208 308

Téléphonie 9 9 9 9

Serveurs Internes 10 110 210 310

Réseau DMZ 11 111 211 311

(19)

Architecture réseau 19

II.6.3 Spanning Tree

Le protocole Rapid Spanning Tree (RSTP) sera mis en place sur chaque site, ceci dans le but d’avoir de la redondance physique des liens sans à avoir de boucle de niveau 2. En effet, sur un réseau Ethernet, le fait d’avoir des boucles provoque des tempêtes de Broadcast. Le mode RSTP sera positionné car il permet une convergence plus rapide que le protocole standard STP. Sur chaque site, nous positionnerons le cœur master en Root RSTP avec une priorité de 4096 et le cœur secondaire avec une priorité de 8192. Les autres équipements auront leurs priorités par défaut. Nous mettrons en place de la sécurité pour ce protocole afin d’éviter qu’une personne provoque des dénis de service ou qu’une personne mette en place un équipement avec une priorité plus basse que le Root.

Note : Les topologies STP de chaque site sont disponibles en annexe.

II.6.4 Routage

Le routage sera assuré par chaque cœur de chaque site. D’un point de vue local, les cœurs assureront le routage inter- vlan. Des ACL seront mises en place afin d’éviter que certains Vlan communique avec d’autre Vlan. Cette spécification sera détaillée dans la partie sécurité. Sur tous les sites, nous mettrons en place le protocole HSRP qui permet de bénéficier d’un routeur virtuel « partagé » entre les 2 routeurs MPLS, ce qui permet de réaliser une redondance de passerelle par défaut.

Le routeur actif (d’un point de vue HSRP) est celui qui possède la plus grande priorité HSRP. Le routeur maitre HSRP sera calqué avec le Root du protocole Spanning Tree.

Note : Le principe du protocole HSRP est disponible en annexe.

Concernant le routage inter-site, nous avons décidé de mettre en place le routage OSPF pour sa performance. Il nous permettra d’établir des routes primaires pour la liaison VPN MPLS et des routes secondaires pour la liaison VPN IPSEC en jouant au niveau des coûts des liens d’interconnexion avec ces différents réseaux. La liaison avec la métrique la plus faible sera la route primaire. Nous fixerons la liaison VPN avec un coût de 1000. Le pare-feu central d’Orsay distribuera sa route par défaut au travers d’OSPF.

II.6.5 Plan de nommage

Afin de faciliter l’administration des équipements réseau et système, une politique de nommage doit être préalablement définie. Le but étant de caractériser un élément en fonction de son rôle ou de sa position géographique. Ainsi, nous préconisons un nommage sur plusieurs champs :

- Site géographique sur 3 caractères (ORS – BAY – SOP – BRU) - Le bâtiment ou la fonction concernée

- Le type d’équipement - Le service rendu

Note : le nommage est un choix de politique interne à l’entreprise, cependant un exemple vous est proposé en annexe.

(20)

Architecture réseau 20

II.7 A rchitecture WAN (Vincent DESSEAUX)

II.7.1 Rappel des besoins

Il nous est demandé de retenir une solution de services opérateurs parmi les offres de l’opérateur Orange. De plus, il nous est également demandé d’implémenter de la qualité de service pour les flux inter-sites des applications métiers.

L’hypothèse admise est de prévoir une ressource disponible de 256Kbps tout en offrant une Qualité de service équivalente à celle proposée par les circuits de données.

II.7.2 Préconisations

Afin de vous conseiller au mieux sur le choix de l’offre opérateur, il convient de prendre en considération votre infrastructure globale, les flux générés par les infrastructures techniques, le nombre de personne par site, ainsi que les besoins en termes de disponibilité demandés, le tout en apportant une notion de sécurité et de confidentialité.

Parmi l’éventail de solutions proposées par Orange, il parait indispensable de retenir plusieurs solutions, une pour l’accès au réseau Internet, une seconde pour l’accès inter-sites et enfin une dernière pour l’accès des nomades. Les solutions WAN que nous vous préconisons sont les suivantes :

Réseau Internet :

l’offre Business Internet est la solution la mieux adaptée à vos besoins actuels et futurs en proposant des débits symétriques compris entre 500 Kbits/s et 80 Mbits/s. L’offre comprend une garantie de la bande passante allouée ainsi qu’une Garantie de Temps de Rétablissement (GTR) de moins de 4h ouvrable avec un taux d’interruption maximum de 17h par an.

Accès nomade :

la solution Business Everywhere Pro, permettant l’utilisation du réseau 3G+ est actuellement la meilleure solution pour répondre aux besoins exprimés et réduire les coûts d’abonnement

Accès inter sites :

l’offre Equant IP VPN, est la solution WAN répondant à l’ensemble de vos contraintes.

S’architecturant sur un réseau privé MPLS, les débits proposés sont symétriques, compris entre 64 Kbits/s à 1 Gbits/s et garantis. Ayant pour champ d’action l’international, cette solution peut être mise en place sur le site de Bruxelles. De plus, une option de qualité de service, que nous utiliserons pour vos applications métiers, mais aussi pour votre future architecture VOIP, est proposée.

II.7.3 Garantie de service

Toujours dans un souci de haute disponibilité, Orange propose deux options de Garantie de Temps de Rétablissement (GTR) afin de s’engager à régler les problèmes en moins de 4h sur les lignes:

Option GTR S1 : rétablissement du service en moins de 4 heures, 7 jours sur 7 et 24 heures sur 24, dès que le client signale l’incident.

Option GTR S2 : rétablissement du service en moins de 4 heures pour tout incident signalé du lundi au samedi, de 8h à 18h à l’exception des jours fériés.

En plus de cet engagement de réactivité (GTR), OBS prend en charge l’installation, l’administration, la supervision et la maintenance de tous équipements et liaisons WAN grâce à une équipe d’expert dédiée. Les résultats de cette prestation sont disponibles via l’espace client et présente :

Une cartographie prédéfinie permettant de suivre en temps réel l’évolution de l’état des éléments

Des statistiques en temps réel vous permettant de disposer de données de volumétrie et de charge sur les accès et matériels de votre réseau. Une gestion des liens logiques pour chacune des routes de votre réseau que vous choisirez. Cette prestation regroupe trois engagements mensuels de performance de bout en bout : délai de transit, taux de perte de paquets et la gigue.

(21)

Architecture réseau 21 Afin d’intensifier l’accompagnement dans le déploiement et la vie de votre solution dans la durée, une équipe commerciale et technique est disponible au travers d’un service client qui fournit :

Un guichet unique SAV 24h/24 et 7j/7 en Centre Support Client

Un responsable service client : il sera l’interlocuteur privilégié pour la gestion opérationnelle de votre réseau Un tableau de bord mensuel analysé par le responsable du service client

Un bilan annuel accompagné d’une restitution pour faire un point exhaustif sur votre solution

Un espace client dédié pour le suivi en temps réel du fonctionnement de votre réseau : suivi des commandes et des incidents, inventaire de parc

Un engagement contractuel de disponibilité globale mensuelle pour l’ensemble de vos sites

II.7.4 La qualité de service

La qualité de service (QoS) est la capacité à véhiculer dans de bonnes conditions un type de trafic donné, en termes de disponibilité, débit, délais de transmission, gigue, taux de perte de paquets etc.

Pour répondre aux attentes exprimées en matière de disponibilité et de sécurité, nous sommes dans l’obligation d’implémenter la qualité de service sur l’architecture WAN proposée.

En premier lieu, il convient de rappeler que l’offre Equant IP VPN précédemment préconisée est une solution proposant en option un système de priorisation des flux s’appuyant sur DiffServ. Cette offre propose pour ce point précis 5 classes de service (CoS) pour assurer le transport priorisé des flux selon leur nature. Ainsi, la voix et la visioconférence bénéficient chacune d'une CoS, et les données bénéficient de 3 CoS pour les données très prioritaires, prioritaires ou sans exigence particulière, il sera donc possible de part cette fonctionnalité de prioriser le flux des applications métiers, mais aussi la voix.

II.7.5 Présentation de l’architecture

Figure 4 - Schéma de l’architecture WAN proposée

Note : De plus amples informations en annexe

(22)

Architecture réseau 22

II.8 Intégration de la VOIP (Vincent DESSEAUX) II.8.1 Rappel des besoins

Il nous est demandé qu’une étude de faisabilité soit amenée quant à l’intégration de la VOIP dans l’architecture proposée, notamment en spécifiant les impacts de l’intégration dans votre système, notamment sur les modifications à apporter par rapport à l’infrastructure réseaux.

II.8.2 Préconisations

La VoIP permet la convergence des flux de données, voix ou encore vidéo sur un même support de transmission et permet ainsi de contribuer à la réduction de coûts pour l’entreprise. Néanmoins, afin de mettre en œuvre de la VoIP au sein d’un réseau, il est nécessaire de s’assurer que le réseau remplisse tous les prérequis nécessaires au bon fonctionnement de la VoIP. La qualité de la téléphonie s'évalue selon trois critères:

les délais de transit au travers du réseau (inférieur à 150 ms) les variations des délais (la gigue) (inférieur à 10 ms)

le taux de perte de paquets (inférieur à 5%)

Il est donc nécessaire d’implémenter au sein du réseau LAN une qualité de service, qui consiste à prioriser le trafic voix parmi tous les types de flux circulant sur le réseau afin de disposer d’une qualité de téléphonie optimale. Tous les équipements réseau précédemment proposés sont capables de traiter cette qualité de service, cependant afin de celle-ci se révèle bénéfique il faudra s’assurer que la charge des équipements réseaux ne dépasse pas 60 % de leur charge maximale.

La qualité de service basée DiffServ spécifique aux flux voix sera implémentée sur le réseau de l’entreprise avec un profil TollQuality. Les liens WAN ne sont pas en reste puisqu’il est également nécessaire d’implémenter cette qualité de service, celle-ci est définie par l’opérateur dans l’offre souscrite.

Un VLAN dédié à l’utilisation de la VOIP sera également déployé, son but est d’isoler le trafic voix pour un souci de confidentialité, mais aussi d’homogénéité.

De plus, le POE (Power Over Ethernet) est proposé sur l’ensemble des équipements réseau, ce qui vous permettra d’opter pour l’utilisation de téléphone IP prenant en charge cette technologie et vous affranchir ainsi de l’utilisation de prise électrique pour celui-ci.

Afin de s’assurer de l’intégration de la VoIP sur le réseau, un audit sera nécessaire afin d’évaluer et de valider votre infrastructure réseau.

(23)

Energies Informatiques 23

Energies Informatiques Chapitre III.

L'énergie informatique représente l'ensemble des ressources et services mis à disposition des utilisateurs.

Nous verrons dans un premier temps l’annuaire de gestion des utilisateurs qui permettent la base nécessaire aux restes des fonctionnalités.

L'utilisateur disposant d'un poste sous Windows ou Linux doit pouvoir accéder aux ressources et services suivants :

- Un partage de fichiers distribués, permettant à chaque utilisateur d'un site de trouver les documents désirés sans utilisation des liens WAN.

- Un accès aux outils bureautiques Office.

- Une gestion des contenus en complément au partage de fichiers.

- Un accès au portail d'entreprise.

- Un accès à des services d'impressions partagés.

- Une messagerie collaborative, complété d'un système de messagerie instantanée et de vidéoconférence.

- Un accès à Internet pour la navigation.

Enfin ces accès doivent être disponibles pour des postes fixes en interne, ainsi que pour des ordinateurs portables sédentaires mais aussi nomades.

(24)

Energies Informatiques 24

III.1 Architecture Active Directory (Jérôme TENEUR) III.1.1 Rappel du contexte et des besoins

Il nous est important de savoir où et comment Aristote est géographiquement implantée, pour répondre aux questions concernant l’implantation de la structure Active Directory. En effet, nous nous baserons sur cette répartition pour optimiser la gestion du service d’annuaire au travers des liaisons inter-sites. Nous avons donc quatre sites distants :

Orsay Bayonne Sophia Antipolis Bruxelles

A noter que le nombre d’utilisateur est un facteur très important pour le dimensionnement. Ainsi le cœur du système d’information se trouvant à Orsay, nous y trouverons une architecture en mesure de gérer une charge très importante, et de garantir une forte tolérance de pannes.

Active directory permettra de gérer l’ensemble des utilisateurs, postes informatiques, et équipements de l’architecture.

Aussi nous nous appuierons sur Windows Serveur 2008 R2 et sa nouvelle version d’Active Directory (et donc nous nous baserons sur le niveau fonctionnel 2008 R2).

III.1.2 Organisation de l’annuaire

Nous proposons une architecture qui ne se basera que sur un seul domaine dans une unique forêt. La gestion des sites distants se fera en deux points :

- Au travers d’OU nommées pour chaque site permettant d’y classer les utilisateurs et stations - Au travers des sites et services Active Directory.

Grâce à une organisation de ce type nous garantissons:

- Une optimisation des réplications inter-sites

- Une meilleure gestion des flux grâce à l’association des sites à un sous-réseau IP - Une meilleure gestion du mode dégradé si l’un des DC était inaccessible - Une plus grande flexibilité pour la délégation des droits administratifs

III.1.2.1 Organisation des serveurs physiques

Nous devons ensuite prendre en considération le nombre d’utilisateurs, ainsi que leur répartition géographique :

Orsay Bayonne Sophia Antipolis Bruxelles

2 Serveurs haute disponibilité 1 serveur autonome en DMZ

1 serveur 1 serveur autonome 1 serveur

Grâce aux nouvelles fonctionnalités offertes par Windows server 2008 R2, nous allons pouvoir envisager de mettre en place un RODC (Read Only Domain Controler) c’est-à-dire un système autonome en lecture seule, dans la DMZ d’Orsay (pour la sécurité) et à Sophia Antipolis (pour des facilités d’administration). Ces serveurs n’autorisent pas l’ajout de nouveaux utilisateurs et les modifications d’OU ou de schéma.

Note : Une description de la mise en place des RODC est disponible en annexe

(25)

Energies Informatiques 25 III.1.2.2 Organisation fonctionnelle

Tout d’abord nous devons définir le catalogue global, nécessaire pour la recherche d’objets au sein d’une forêt. Nous le placerons sur chaque site pour une meilleure gestion des services liés à Exchange 2010.

Ensuite, nous devons répartir les rôles FSMO de la forêt et du domaine. Ces derniers vous sont présentés dans le tableau ci-après.

Enfin, les services de domaine Active Directory emploient une méthode de réplication différée multimaître. Un contrôleur de domaine communique les modifications apportées à l’annuaire à un deuxième contrôleur de domaine qui les communique ensuite à un troisième, et ainsi de suite, jusqu’à ce que tous les contrôleurs de domaine aient reçu les modifications.

Note : La gestion des sites et service au travers de l’annuaire (comme le suggère le schéma ci-dessus) et la présentation des rôles FSMO est détaillé en annexe

III.1.3 Organisation des ressources dans l’annuaire

III.1.3.1 OU et Groupes d'utilisateurs

Afin de rendre l’administration et l’utilisateur de l’annuaire la plus intuitive possible, nous utiliserons deux paramètres : - Le site géographique

- La direction d’appartenance

Ainsi visuellement les utilisateurs seront classés par OU représentant les sites géographiques, mais ils pourront être définis par un groupe AD représentant leur direction d’appartenance.

Note : La représentation des OU et groupe utilisateurs est disponible en annexe

III.1.3.2 Stratégie de groupe (GPO)

Les stratégies de groupe nous permettrons de répondre à un grand nombre de prérogatives de sécurités, mais faciliterons également la gestion du parc en y appliquant des règles prédéfinies tels que :

- Installation automatique d’application en fonction des directions - Configuration de l’environnement utilisateur

- Configuration du proxy - Déploiement des imprimantes - Mappage des lecteurs réseaux - Etc…

Note : La liste des GPO et leurs OU sont détaillées en annexe ainsi qu’un schéma de l’organisation fonctionnel des OU

FSMO DC désigné

Maître d'attribution des noms de domaine ORS-SRV-AD1

Contrôleur de schéma ORS-SRV-AD1

Maître RID ORS-SRV-AD2

Maître d'infrastructure ORS-SRV-AD2

Emulateur CPD ORS-SRV-AD2

Figure 5 - Rôles FSMO

Figure 6 - Schéma organisationnel du domaine vsn-aristote.lan

(26)

Energies Informatiques 26

III.1.4 Gestion avancée de l’annuaire Active Directory

III.1.4.1 Processus d’administration

- La direction informatique disposera en cas d’urgence des accès utilisateurs compris dans ces groupes

- Les équipes informatiques d’administration seront situées sur chaque site avec une compétence limitée au site et auront le moins de privilèges possible

- Les équipes informatiques de chaque site distant ne pourront ajouter/supprimer/modifier des objets stratégies de groupes, mais ont la possibilité d’une part d’attribuer des stratégies de groupes existantes sur une unité d’organisation pouvant être administrée par eux, et d’autre part d’effectuer l’analyse des jeux de stratégies résultants

- Les équipes informatiques pourront utiliser les services de bureau à distance pour se connecter sur les contrôleurs de domaines et les serveurs membres de leur site respectif

- Les équipes informatiques pourront effectuer n’importe quelle opération sur les ressources partagées

III.1.4.2 Sauvegarde

Bien que nous prévoyons la mise en place un cluster de contrôleurs de domaine sur le siège d’Aristote, il est fortement recommandé de planifier régulièrement des sauvegardes de ces contrôleurs de domaine complets avec tous leurs services liés à Active Directory qu’il s’agisse :

- De l’annuaire d’Active Directory

- Des rôles clés de l’Active Directory (notamment le rôle PDC)

- Des GPO

- Du rôle DHCP - Du rôle DNS

Ainsi nous proposons la mise en place d’une sauvegarde incrémentielle, située à Bayonne. Le but recherché ici étant de décentraliser de cœur du système de sauvegarde

Figure 7 - Schéma de la mise en place du serveur de sauvegardes

III.1.5 Conclusion

La majorité des services s’appuie sur Active Directory, la communication unifiée, le travail collaboratif, des services de sécurité... C’est donc une référence pour gérer efficacement les utilisateurs, les ordinateurs, les groupes, les imprimantes, les applications et d’autres objets de l’annuaire, à partir d’un emplacement centralisé.

Notre choix s’est tourné vers une restructuration de votre architecture existante vers un domaine unique. Cette solution vous permettra d’atteindre une architecture évolutive, simple d’administration et d’exploitation mais également sécurisée et s’intégrant parfaitement avec l’ensemble de votre structure.

Enfin, dans le cadre de l’augmentation de ses activités, Aristote prévoit une hausse de ses effectifs de l’ordre de 20% dans les 5 ans. Dans ce cadre, l’infrastructure que nous vous avons proposée permettra de gérer une charge allant jusqu’à 1000 utilisateurs.

(27)

Energies Informatiques 27

III.2 A rchitecture DHCP ( Vincent DESSEAUX)

III.2.1 Rappel des besoins

Il nous est demandé de mettre en place une solution permettant aux stations du site d’obtenir, via un serveur DHCP, leur configuration IP.

III.2.2 Présentation de la solution

DHCP est un service intégré au serveur Windows Server 2008 R2 en tant que rôle. Ce rôle ne nécessite aucun coût supplémentaire à la licence Windows Server et est peu gourmand en ressources. Cette fonction pourra donc être intégrée sur les contrôleurs de domaine.

III.2.3 Proposition d’architecture

DHCP est un service dit sensible car s’il n’est plus disponible sur le réseau, les stations ne pourrons plus acquérir de baux IP, et donc par conséquent n’auront plus accès aux ressources du réseau. Il est donc primordial que cette solution prenne en charge la haute disponibilité afin de pouvoir assurer la distribution des configurations IP de façon redondée.

Sachant que l’architecture réseau que nous vous proposons comprend l’utilisation de VLAN, et que cette fonctionnalité a pour but de segmenter un domaine de diffusion, il nous faudra impérativement mettre en place sur chaque site le service de relai DHCP qui est de nos jours, pris en charge par les routeurs. Le service DHCP sera déployé sur les serveurs d’infrastructures comprenant Active Directory et DNS.

Le scénario que nous vous proposons est de mettre en place comprendra un serveur DHCP par site, complété par un serveur DHCP supplémentaire sur le site d’Orsay. Le service relai DHCP sera mis en place sur les routeurs afin de pouvoir desservir l’ensemble des VLAN d’un site, mais aussi pour que les serveurs DHCP d’un site adjacent puissent prendre le relai en cas de défaillance du serveur DHCP du site local.

Solution Préconisée

Figure 8 - Schéma de l’architecture DHCP proposée

Note : De plus amples informations en annexe

(28)

Energies Informatiques 28

III.3 Architecture DNS (Rudy PROME) III.3.1 Rappel des besoins

Il est indispensable de pouvoir localiser facilement les différentes ressources de votre système d’information. Il s’agit du rôle primaire des serveurs DNS. De plus, ils permettent aux utilisateurs d’ouvrir une session sur le réseau.

III.3.2 Infrastructure proposée

Dans la solution que nous vous proposons, nous prévoyons l’utilisation du rôle DNS présent dans le système d’exploitation Windows Server 2008 R2, qui sera pour rappel, le système d’exploitation présent sur vos contrôleurs de domaine.

Pour faciliter l’administration et d’accroître la sécurité lors des mises à jour entre serveurs DNS primaire et secondaires, ils seront directement intégrés à chaque Active Directory qui leur est propre. Compte tenu de votre nombre d’utilisateurs, nous vous proposons une forêt composée d’un seul et unique domaine dans l’intérêt d’éviter des complications d’administration.

Nous préconisons l’utilisation de deux suffixes au nom de domaine, pour distinguer le réseau interne de ce qui est visible depuis l’extérieur. Ainsi, vous aurez le nom « vsn-aristote.eu » pour l’extérieur et « vsn-aristote.lan » pour l’interne.

Enfin, la haute disponibilité DNS sera bien sûr assurée par le cluster de contrôleurs de domaine sur le site d’Orsay et les serveurs DNS secondaires des sites distants du siège d’Aristote.

III.3.3 Schéma de l’infrastructure proposée

Pour éclaircir notre point de vue sur l’infrastructure proposée, voici un schéma synthétisant tous les points abordés :

Figure 9 – Schéma de l’architecture DNS

III.3.4 Conclusion

L’architecture DNS proposée se présente comme étant à la fois la plus adapté à votre parc informatique et la moins coûteuse possible car le rôle DNS utilisé est natif à Windows Server 2008 R2 qui équipe tous vos contrôleurs de domaine.

Vous trouverez une documentation plus complète en annexe.

(29)

Energies Informatiques 29

III.4 Architecture de Messagerie Collaborative (Rudy PROME) III.4.1 Rappel des besoins

La messagerie collaborative consistera à mettre à disposition des employés un système intégrant un agenda avec la gestion des tâches, des demandes de réunion, la possibilité d’enregistrer des contacts personnels, ainsi qu’une boîte de messagerie. Le tout sera possible de l’intérieur comme de l’extérieur et disposera de toute la sécurité nécessaire.

III.4.2 Infrastructure proposée

L’architecture de notre client étant en grande partie basée dans un environnement Microsoft, l’infrastructure Exchange 2010 que nous proposons s’intègrera sans difficultés dans celle-ci.

Elle dispose de toutes les fonctionnalités attendues par notre client. Son administration se veut simple et centralisée, la console d’administration (EMC : Exchange Management Console) est accessible depuis n’importe quel serveur Exchange (par exemple, la migration de boîtes mails et la création de nouveaux comptes sont extrêmement simples).Nous assurons la haute disponibilité des serveurs d’accès clients et de transport sur le site d’Orsay par l’intermédiaire d’un cluster. Nous assurons également la haute disponibilité et restauration des MailBox grâce à la fonction DAG (Data Availability Group) propre au produit Exchange 2010.

Nous préconisons le déploiement du client Microsoft Outlook 2010 sur les postes utilisateurs. Outlook et Exchange communiquent par le protocole natif d’Exchange : MAPI. Tout échange est donc chiffré. Enfin, pour les nomades, Outlook Web Access offrira un accès à toutes les fonctionnalités d’Outlook 2010 dans une interface similaire à partir de n’importe quel navigateur Internet depuis un ordinateur de l’entreprise ou public, Smartphones compris.

III.4.3 Schéma de l’infrastructure proposée

Voici tous les serveurs Exchange nécessaires ainsi que leurs rôles. L’explication en détails des différents rôles est disponible en annexe. La messagerie unifiée est traitée plus en détails dans la suite du rapport mais nous l’avons intégrée au schéma de façon simplifiée afin d’avoir une vision de l’emplacement des serveurs nécessaires.

Figure 10 - Schéma de l'architecture de messagerie collaborative

III.4.4 Conclusion

Puisque chaque site disposera de ses propres serveurs, vous possèderez l’architecture à la fois la plus performante et la plus sûre. En effet, le temps d’accès aux données par le client sera non seulement très rapide mais sera également assuré en cas de rupture d’un lien WAN ou d’incident sur un des serveurs Exchange. Aucun serveur ne sera virtualisé.

Vous trouverez une documentation plus complète en annexe.

(30)

Energies Informatiques 30

III.5 Architecture de Messagerie Instantanée (Rudy PROME) III.5.1 Rappel des besoins

Liée à la messagerie collaborative, la messagerie instantanée permettra aux utilisateurs d’établir des communications en temps réel entre eux. Elle pourra être textuelle, vocale ou même visuelle. L’organisation de vidéo conférence à plusieurs sera également disponible comme le demande notre client.

III.5.2 Infrastructure proposée

La parfaite corrélation entre Exchange 2010 et Lync Server 2010 n’est plus à démontrer. Bien qu’il s’agisse d’un produit relativement récent, celui-ci a auparavant fait ses preuves en répondant au nom d’Office Communication Server.

Côté serveur, son administration est centralisée et sa console de gestion est accessible depuis un navigateur Internet. Lync dispose de nombreux rôles comme c’est le cas d’Exchange mais tous ne sont pas indispensables. Afin de ne pas arriver à de coûts excessifs et comme nous ne considérons pas ces fonctionnalités comme cruciales par rapport à l’activité d’Aristote, nous ne déploierons seulement ceux que nous jugeons nécessaires. Nous allons également centraliser les rôles retenus sur un serveur par site.

Les postes des collaborateurs d’Aristote seront équipés du client lourd Lync 2010 permettant la communication instantanée sous toutes les formes demandées (texte, voix, vidéo). L’état de présence des utilisateurs sera même synchronisé sur les clients Outlook 2010. Lync 2010 Mobile est disponible pour les Smartphones afin de disposer des mêmes fonctionnalités. Par ailleurs, les nomades auront aussi accès à la messagerie instantanée par le biais de Lync Web Access depuis un navigateur Web.

III.5.3 Schéma de l’infrastructure proposée

L’architecture de Lync est assez ressemblante à celle d’Exchange par son système de rôle et son serveur Edge dans la DMZ.

Cependant, nous avons dispensé l’infrastructure de certains rôles que nous n’avons pas jugés indispensable pour notre client. Nous préconisons la mise en place d’un serveur Lync comprenant sa propre base SQL par site afin que chacun d’eux soient optimisés pour accueillir plusieurs flux voix/audio avec une qualité optimale simultanément.

Figure 11 - Schéma de l'architecture de messagerie instantanée

III.5.4 Conclusion

Ce produit répond donc aux besoins du client. Couplé à Exchange 2010, les utilisateurs auront tout le panel de fonctionnalités nécessaires pour travailler dans les meilleures conditions en optimisant les coûts de déploiement et d’administration de l’infrastructure. Aucun serveur ne sera virtualisé. Lync comprend des fonctionnalités le rendant prêt à accueillir de la voix sur IP.

Vous trouverez une documentation plus complète en annexe.

(31)

Energies Informatiques 31

III.6 Messagerie unifiée (Vincent DESSEAUX)

III.6.1 Rappel des besoins

Aristote souhaite à terme intégrer la téléphonie au sein de son système de messagerie afin de diminuer les coûts de gestion liés à la messagerie et à la téléphonie, deux services dont le fonctionnement est devenu indispensable. Ce service permettra aux utilisateurs de recevoir des fax et messages vocaux dans leur BAL.

III.6.2 Présentation de la solution

Exchange 2010 permet de mettre en place cette notion de messagerie unifiée. Un serveur intermédiaire entre l'infrastructure téléphonique de l'entreprise et l'organisation Exchange permet aux utilisateurs d’accéder aux messages vocaux, aux courriers électroniques et aux informations de calendrier situés dans leur boîte aux lettres Exchange 2010 à partir d’un client de messagerie (Microsoft Outlook ou Outlook Web Access) ou d’un périphérique mobile sur lequel ActiveSync Exchange est activé (Smartphone Windows Mobile, assistant numérique personnel (PDA) ou téléphone). La messagerie unifiée d'Exchange Server 2010 permet :

- De gérer vos systèmes de messagerie vocale et électronique à partir d'une seule plateforme

- D’offrir aux utilisateurs la possibilité de créer des messages d'accueil personnalisés et des options de transfert d'appel individuel

- De gérer la messagerie unifiée à l'aide d'un menu personnalisable de routage d'appel

- D’activer l'indicateur de message en attente sur votre téléphone pour annoncer l'arrivée d'un nouveau message vocal

III.6.3 Proposition d’architecture

Pour mettre en œuvre cette infrastructure, il convient de disposer d’une passerelle multimédia pour l'interconnexion de votre réseau téléphonique existant avec la messagerie unifiée. Celle-ci fera office d’intermédiaire et redirigera les messages vocaux et fax, vers le serveur ayant le rôle de messagerie unifiée, qui se chargera ensuite de le transmettre, via l’envoi d’un courriel, à l’utilisateur concerné.

Figure 12 - Schéma explicatif de la solution préconisée

Sachant que la VOIP sera à terme intégrée sur l’ensemble de vos sites, nous vous préconisons de disposer de ce rôle sur chacun d’eux.

Références

Documents relatifs

Que vous cherchiez à rendre vos machines virtuelles plus mobiles, à augmenter leur disponibilité, à gérer des environnements mutualisés, à monter en charge ou à gagner

Cet article décrit les étapes à pour changer le nom d’un contrôleur de domaine sous Windows Server 2008 R2.. Les entreprises peuvent être amenées à changer de nom du

Les services de rôle disponibles sont : – Serveur NPS : permet la mise en place des stratégies d'accès réseau pour les demandes de connexion.. – Autorité HRA : émission

2.2 Fonctionnalités de l’Active Directory sous Windows Server 2008 R2.. 19 2.2.1 Installation d’un annuaire

2.2 Fonctionnalités de l’Active Directory sous Windows Server 2008 R2. 19 2.2.1 Installation d’un annuaire

Public visé : Informaticiens, ingénieurs systèmes, administrateurs Objectifs : Décrire les composants clés pour concevoir des infrastructures réseaux, Décrire

Vous allez donc utiliser la virtualisation pour mettre en place un serveur de base de données SQL, mais dans certains cas il peut être nécessaire que chaque

➔ Le nombre de véhicules maximum pour une voie donnée Créer / Modifier / Supprimer des lieux d’habitations (H).. ➔ Un lieu d’habitation est défini par une zone (plusieurs