Fourniture d`une solution de Réseau Privé Virtuel redondante et des
Transcription
Fourniture d`une solution de Réseau Privé Virtuel redondante et des
Fourniture d'une solution de Réseau Privé Virtuel redondante et des logiciels clients associés pour les accès distants sécurisés et prestations de maintenance 12/04/2013 Table des matières 1. Introduction...........................................................................................................................................3 2. Description de la procédure..................................................................................................................4 2.1. Objet..............................................................................................................................................4 2.2. Coordination..................................................................................................................................4 3. Contexte................................................................................................................................................5 3.1. Service RPV actuellement proposé par la DI................................................................................5 3.2. Fonctionnement technique du service RPV actuel........................................................................5 4. Besoins..................................................................................................................................................9 5. Spécifications techniques....................................................................................................................10 5.1. Fourniture d'une solution de Réseau Privé Virtuel redondante et des logiciels clients associés.10 5.2. Support et maintenance..............................................................................................................12 6. Prestations demandées........................................................................................................................14 7. Établissement de la proposition..........................................................................................................15 7.1. Conditions d’achat.......................................................................................................................15 7.2. Mémoire technique......................................................................................................................15 7.3. Grilles de réponse........................................................................................................................16 7.4. Critères de jugement des offres...................................................................................................16 7.5. Planning prévisionnel..................................................................................................................16 Université de Strasbourg 2 1. Introduction Le présent document est le cahier des clauses techniques particulières pour la fourniture d'une solution de Réseau Privé Virtuel (RPV) redondante et des logiciels clients associés pour les accès distants sécurisés sur le réseau Osiris. Le réseau Osiris est le réseau informatique de l'enseignement supérieur et de la recherche à Strasbourg. Au total, 15 établissements sont connectés, ce qui représente 20 sites, 120 bâtiments, plus de 60 000 machines connectées et plus de 50 000 utilisateurs. Le réseau Osiris est géré par la Direction Informatique (DI) de l'Université de Strasbourg, pour le compte de l'ensemble des établissements membres d'Osiris. Le réseau Osiris irrigue les campus universitaires situés sur le territoire de la Communauté Urbaine de Strasbourg (CUS). L'interconnexion des bâtiments se fait au travers de liaisons à haut débit en utilisant des fibres optiques privatives supportant des débits à 10 Gigabits et les protocoles IPv4 et IPv6. La DI propose également de très nombreux services aux utilisateurs de l'ensemble des établissements membres d'Osiris : hébergement de boîtes aux lettres, relais de messagerie, service de synchronisation de temps (NTP), service de nommage (DNS), service de transfert de fichiers (FTP), service de listes de diffusion, et depuis 2005, service d'accès à distance sécurisé (service RPV). Le service RPV est un service permettant à un poste client distant de se connecter, via un réseau public, à Osiris et ainsi d'obtenir une adresse IP dans ce réseau. La communication est sécurisée par la mise en place d'un tunnel chiffré entre le poste client et le serveur RPV. Concrètement, cette technologie permet aux utilisateurs d'accéder aux ressources privées de leur réseau quel que soit leur lieu de connexion : domicile, campus extérieur, depuis l'étranger, etc. Le service RPV proposé par la DI permet à chaque établissement, laboratoire ou service, de disposer d'un serveur RPV virtuel qui amène ses utilisateurs dans son propre sous-réseau. Le service RPV est devenu un service critique et doit se conformer à l'objectif de disponibilité du réseau de 99.9 %. Cet objectif de disponibilité a été défini par l'ensemble des établissements membres d'Osiris pour tous les réseaux et services gérés par la DI. La nouvelle solution RPV devra au minimum posséder les fonctionnalités du service RPV actuel et permettre à la DI d'évoluer vers de nouveaux usages. L'objectif de ce document est de spécifier les besoins techniques précis des futurs matériels et logiciels afin que ceux-ci répondent aux critères de haute disponibilité et de maintien des fonctionnalités existantes. Université de Strasbourg 3 2. Description de la procédure 2.1. Objet • Fourniture de deux (2) serveurs RPV et des logiciels clients associés pour les accès distants sécurisés sur Osiris ; • prestation de maintenance logicielle et matérielle des deux serveurs RPV ; • prestation de maintenance logicielle des logiciels clients RPV. 2.2. Coordination Des renseignements peuvent être obtenus auprès des personnes désignées ci-dessous : Coordination administrative du projet : Mme Fabienne Sanchez Direction informatique — Département administration 4 rue Blaise Pascal - CS 90032 - F-67081 Strasbourg Cedex 67070 Strasbourg Cedex Tél. : 03 68 85 69 98 Fax : 03 68 85 68 47 Email : [email protected] Coordinateur du projet : Mme Laurence Moindrot Direction informatique — Département infrastructures 4 rue Blaise Pascal - CS 90032 - F-67081 Strasbourg Cedex 67070 Strasbourg Cedex Tél. : 03 68 85 03 22 Fax : 03 68 85 03 12 Email : [email protected] Responsable technique : M Benjamin Collet Direction informatique — Département infrastructures 4 rue Blaise Pascal - CS 90032 - F-67081 Strasbourg Cedex 67070 Strasbourg Cedex Tél. : 03 68 85 57 49 Fax : 03 68 85 03 12 Email : [email protected] Université de Strasbourg 4 3. Contexte La DI propose un service d'accès à distance sécurisé (service RPV) aux utilisateurs de l'ensemble des établissements membres d'Osiris. Selon les besoins des laboratoires ou établissements, ce service est décliné sous trois formes différentes. 3.1. 3.1.1. Service RPV actuellement proposé par la DI L'accès « VPN standard » L'accès « VPN standard » permet aux utilisateurs nomades d'arriver dans un sous-réseau d'Osiris commun. Les utilisateurs peuvent dès lors accéder aux données à accès restreint, comme par exemple les partages de fichier en réseau. 3.1.2. L'accès « VPN-Lab » L'accès « VPN-Lab » permet aux utilisateurs nomades d'arriver dans un sous-réseau dédié à leur composante (laboratoire, service, voire établissement tout entier). Une plage d'adresses IP étant réservée à ses utilisateurs, l'administrateur système et réseau de la composante peut autoriser l'accès à des ressources internes. 3.1.3. L'accès « VPN-Lab+ » L'accès « VPN-Lab+ » permet aux utilisateurs nomades d'arriver directement dans le sous-réseau de leur composante. La différence par rapport à l'accès « VPN-Lab » est que le trafic des postes nomades est amené par la DI sur un port spécifique du commutateur d'entrée de bâtiment de la composante, permettant à l'administrateur système et réseau de la composante de connecter les domaines de diffusion Ethernet du réseau principal et du réseau nomade, et de mettre un pare-feu (bridgé par exemple) pour implémenter une politique de sécurité plus fine. Pour l'utilisateur nomade, le bénéfice est qu'il est protégé par cette politique de sécurité et qu'il peut de plus accéder aux fonctionnalités nécessitant le mécanisme de diffusion (« broadcast »). Pour l'administrateur système et réseau, la politique de sécurité est aussi simplifiée car le réseau des utilisateurs nomades est distingué sur une interface particulière. 3.2. 3.2.1. Fonctionnement technique du service RPV actuel Serveur RPV Le service RPV actuel est basé sur deux routeurs Cisco 3845 en actif-passif. 3.2.2. Clients RPV Étant donnée la diversité des utilisateurs et des systèmes d'exploitation de leur poste de travail, 3 Université de Strasbourg 5 logiciels clients (les clients libres VPNC et Shrew et le client RPV Cisco) ont été mis à disposition des utilisateurs Osiris. Les systèmes d'exploitation supportés sont Windows 98, Windows 2000, Windows XP, Windows 2003, Windows 7, Linux, MAC OS X, et les systèmes *BSD. Pour simplifier l'administration, la configuration des logiciels clients est téléchargeable (client VPNC) ou pré configurée (client RPV CISCO). Les logiciels clients sont financièrement pris en charge par la DI, et ne sont donc pas à la charge de l'utilisateur. 3.2.3. Authentification client/serveur Le mécanisme d'authentification client/serveur RPV actuel repose sur l'authentification étendue IKE : PSK+XAUTH. 3.2.4. Authentification et autorisation des utilisateurs L'authentification des utilisateurs repose sur le service d'authentification de la DI, basé sur un serveur RADIUS/LDAP. L'annuaire LDAP fournit toutes les données nécessaires à la configuration du poste client : adressage IP, serveur de nom, routage spécifique. Le serveur RADIUS authentifie l'utilisateur et renvoie les attributs nécessaires à l'autorisation. 3.2.5. Statistiques et supervision Les statistiques de connexion des utilisateurs sont collectées par le serveur RADIUS : date et heure de connexion et déconnexion, adresse IP utilisée, trafic émis et reçu, état de la déconnexion, etc. La supervision et la métrologie des serveurs RPV actuels sont faites via le protocole SNMP. 3.2.6. Compatibilité IPv6 Le service RPV actuel a également été rendu compatible IPv6. Le serveur RPV permet aux utilisateurs qui le souhaitent de monter un tunnel ISATAP dans le tunnel IPSEC de base et ainsi d'obtenir un adresse IPv6 dans le réseau Osiris. Les logiciels clients actuels ne supportant pas IPv6, nous avons développé des scripts que la DI fournit aux utilisateurs sur demande. 3.2.7. Fonctionnement réseau 3.2.7.1. Configuration réseau du serveur RPV actuel Les serveurs RPV actuels possèdent 2 interfaces Ethernet 10/100/1000 Mb/s. La première interface Gi0/0 est l'interface externe du serveur RPV. Les postes clients se connectent au service via cette interface. Université de Strasbourg 6 La seconde interface Gi0/1 est l'interface interne du serveur RPV. Cette interface est découpée en sous-interfaces logiques tagguées (protocole 802.1Q). Chaque sous-interface logique correspond à un VLAN et possède une adresse IP A.I dans un sous-réseau A. Une des sous-interfaces logiques est dédiée au réseau « VPN standard ». Les autres sous-interfaces possèdent une adresse IP soit dans un sous-réseau dédié à une composante, option « VPN-Lab », soit directement dans le sous-réseau d'une composante, option « VPN-Lab+ ». Il existe une sous-interface logique par composante. A.I Réseau A RPV Gi0/0 Gi0/1 3.2.7.2. Attribution des paramètres réseaux et mécanisme de routage sur le poste client Lorsqu'un utilisateur nomade se connecte au serveur RPV actif, il obtient une adresse IP A.N dans le réseau A défini dans son profil de connexion. Un tunnel chiffré est créé entre le poste client et le serveur RPV. Par défaut, tout le trafic réseau du poste client est envoyé vers le serveur RPV à travers le tunnel chiffré. tunnel chiffré A.I Réseau local Réseau A RPV A.N Gi0/0 Gi0/1 Réseau spécifique en option Seul le trafic à destination du réseau local du poste client ne passe pas par le tunnel chiffré. Il est également possible de créer un routage spécifique sur le poste client en utilisant l'option de « Split tunneling ». 3.2.7.3. Mécanisme de routage sur le serveur RPV Le serveur RPV reçoit tout le trafic réseau en provenance du poste client et l'aiguille en fonction de l'adresse IP source A.N : Université de Strasbourg 7 Si le trafic est à destination du réseau A, le trafic est directement transmis sur l'interface A.I en utilisant le mécanisme de routage traditionnel (routage direct). A.I Réseau A RPV A.N Gi0/0 Gi0/1 Sinon, le serveur RPV aiguille le trafic vers le routeur par défaut A.R du réseau A. Cet aiguillage est réalisé par le mécanisme de Policy Routing basé sur l'adresse IP source. A.I Réseau A RPV A.N Gi0/0 A.R Gi0/1 3.2.7.4. Mécanisme de Proxy ARP La dernière fonctionnalité indispensable au fonctionnement du service actuel est le mécanisme de Proxy ARP qui permet l'interconnexion de 2 réseaux physiques sans routage. Le Proxy ARP est activé sur chaque sous-interface interne du serveur RPV. Ceci permet au serveur RPV de répondre aux requêtes ARP à destination des postes clients et de transmettre le trafic à destination de leurs adresses IP. A.I Réseau A RPV A.N Gi0/0 Gi0/1 Des schémas explicatifs plus précis sont fournis en annexe. Université de Strasbourg 8 4. Besoins La nouvelle solution RPV prévue dans le cadre de cet appel d'offres devra être redondante. 2 serveurs RPV strictement identiques seront déployés sur 2 campus distincts : un serveur primaire et un serveur secondaire de secours en cas de panne ou de coupure planifiée. Si le serveur primaire subit une panne ou un arrêt volontaire, les connexions en cours ou à venir seront automatiquement basculées sur le serveur secondaire de façon transparente pour les utilisateurs. Chaque serveur disposera d'une double alimentation électrique interne. Les nouveaux serveurs RPV et les logiciels clients associés devront être évolutifs et suivre les évolutions des standards réseaux et l'évolution des systèmes d'exploitation des postes clients sans sur-coût. Les nouveaux serveurs RPV devront permettre à la DI de proposer les mêmes options d'accès distants sécurisés à ses utilisateurs (VPN standard, VPN-Lab, VPN-Lab+). Les différents logiciels clients RPV devront être distribuables et « packageables ». Le nombre de licences pour l'installation des clients RPV devra être illimité pour tous les systèmes d'exploitation requis. Université de Strasbourg 9 5. Spécifications techniques 5.1. Fourniture d'une solution de Réseau Privé Virtuel redondante et des logiciels clients associés 5.1.1. Fonctionnalités requises pour les serveurs RPV redondants Cette section décrit les fonctionnalités minimales demandées pour les serveurs RPV redondants faisant l'objet de cette consultation. 5.1.1.1. Fonctionnalités Les nouveaux serveurs RPV devront proposer les mêmes possibilités d'accès que le serveur RPV actuel (VPN standard, VPN-Lab, VPN-Lab+, voir chapitre 3). 5.1.1.2. Dimensionnement Les nouveaux serveurs devront posséder au moins 2 interfaces Gigabit Ethernet (1000BaseTX) chacun. Les nouveaux serveurs devront matériellement supporter au moins 1 000 tunnels SSL client/serveur simultanés chacun. 5.1.1.3. Support des protocoles Les nouveaux serveurs devront supporter les caractéristiques, fonctionnalités et protocoles suivants : Fonctionnalités RPV : ✔ support du protocole SSL ; ✔ support du « split tunneling » ; ✔ support de l'authentification RADIUS ; ✔ support de l'autorisation RADIUS : avec attributs (plage IP, masque réseau, serveur de nom, ACL) ; ✔ support de l'accounting RADIUS pour la génération de statistiques ; ✔ support des terminaux mobiles ; ✔ support des connexions clientless (utilisation ne nécessitant pas de logiciel installé sur le poste, via navigateur web). Université de Strasbourg 10 Fonctionnalités de haute disponibilité : Le support de la haute disponibilité est obligatoire. 2 serveurs RPV identiques seront déployés (un serveur primaire et un serveur secondaire) ; le serveur primaire sera le serveur actif ; le serveur secondaire deviendra actif en cas de panne du serveur primaire ; la détection d'une panne sur le serveur primaire et le passage du serveur secondaire en serveur actif devra être automatique ; le serveur secondaire devra connaître à tout moment les informations et états des sessions SSL ; si le serveur primaire subit une panne ou un arrêt volontaire, les sessions SSL en cours ou à venir seront automatiquement basculées sur le serveur secondaire de façon transparente pour les utilisateurs. Fonctionnalités générales de sécurité/filtrage : filtrage de paquets IPv4 et IPv6 : Il doit être possible de filtrer le trafic entrant et sortant sur toutes les interfaces et tous les VLANs ; support du NAC (Network Acces Control) en option. 5.1.1.4. Administration L'ensemble des fonctionnalités des serveurs RPV devra pouvoir être configuré à distance, soit par l'intermédiaire d'une interface en ligne de commande soit par une interface graphique (web, client lourd, etc.). La configuration des serveurs RPV devra pouvoir être exportable et importable sous forme d'un fichier texte. En outre, le support de SNMP v2 en lecture est obligatoire. 5.1.1.5. Contraintes physiques et alimentation électrique Chaque serveur devra pouvoir être installé (rackable) dans une armoire serveur standard (19 pouces). Chaque serveur devra posséder 2 alimentations électriques internes. 5.1.2. Fonctionnalités requises pour les logiciels clients associés aux serveurs RPV Cette section décrit les fonctionnalités minimales demandées pour les logiciels clients associés aux serveurs RPV faisant l'objet de cette consultation. La solution proposée devra inclure des logiciels clients RPV multi-plate-formes et multi-architectures (propriétaires et/ou libres) ; afin de faciliter l'administration et l'installation, les logiciels clients devront pouvoir être packagés pour offrir un client pré configuré et téléchargeable par les utilisateurs ; le poste client, lorsqu'il a établi un tunnel vers le serveur RPV devra recevoir au moins les attributs réseaux suivants du serveur : adresse IP, masque, adresse IP du serveur de nom, Université de Strasbourg 11 domaine IP, routage spécifique si besoin est ; le poste client, lorsqu'il a établi un tunnel vers le serveur et qu'il possède une adresse IP dans un réseau privé local (VPN-Lab+), devra pouvoir accéder aux réseaux Osiris et à Internet à partir de ce réseau local via le serveur RPV ; le poste client devra pouvoir se connecter depuis un système situé derrière un routeur faisant de la translation d'adresses ; les logiciels clients devront être évolutifs et suivre les évolutions des standards réseaux et l'évolution des systèmes d'exploitation des postes clients sans sur-coût ; la solution devra supporter la connexion de tablettes et de smartphones. 5.2. Support et maintenance Le soumissionnaire fera une proposition de maintenance globale sur 3 ans, payable annuellement, en intégrant l'année de garantie. Le soumissionnaire fera également une proposition de maintenance pour une 4ème et une 5ème années supplémentaires. Le soumissionnaire proposera obligatoirement 3 options pour la maintenance matérielle et logicielle des équipements : • option 1 : GTI (garantie de temps d'intervention) en J+1 ; • option 2 : GTI en J+2 ; • option 3 : GTI en J+5. La maintenance matérielle et logicielle sera applicable du lundi au vendredi de 8h à 18h. Les contrats de maintenance matériel et logiciel prendront effet à compter de la VSR. Le soumissionnaire proposera un service d'assistance permettant d'accéder à un centre de support technique capable d'assister la DI en cas de problème. Le soumissionnaire devra détailler le contenu de la prestation de la maintenance matérielle des serveurs RPV. Il précisera en particulier les conditions et la procédure de dépannage des serveurs RPV. À compter de la VSR, le soumissionnaire proposera une maintenance et une assistance logicielle pour les serveurs RPV et les logiciels clients associés. Dans ce cadre, le soumissionnaire s'engage à informer la DI de la disponibilité des mises à jour des logiciels (clients et serveurs), et à fournir ces mises à jour sans supplément de prix dans les 30 jours suivant l'annonce de la disponibilité des-dits logiciels. Université de Strasbourg 12 6. Prestations demandées Le présent marché sera composé : • • d’une partie forfaitaire dans laquelle le candidat fournira : • les matériels et logiciels nécessaires à la mise en œuvre de la solution en réponse au besoin spécifié dans la section Spécifications techniques. • les licences permettant la connexion d'au moins 500 clients simultanés en SSL (hors usage clientless), y compris tablettes et smartphones, • la maintenance pour l'ensemble de la solution sur une durée initiale de trois ans, payable annuellement, d’une partie à bon de commande dans laquelle il proposera : • des tranches d'achats de licences supplémentaires hors usage clientless, par tranches de 100 à 200 compris, • des tranches d'achats de licences pour les usages clientless, à partir de 500 connexions simultanées et par tranches de 100 à 200 compris, • la prolongation de la maintenance par tranche supplémentaire d'un an (dans la limite de 2 périodes annuelles supplémentaires). Le candidat s’engage à respecter les tarifs proposés pendant toute la durée du marché. Université de Strasbourg 13 7. Établissement de la proposition L’offre remise par le candidat sera composée de trois documents : − les conditions d’achat complétées et signées ; − un mémoire technique ; − les grilles de réponse complétées. 7.1. Conditions d’achat Le candidat joindra à son dossier les conditions d’achats applicables au présent marché fournies avec le présent CCTP, qu’il aura complétées et signées. 7.2. Mémoire technique Le candidat fournira un mémoire technique présentant sa solution et son adéquation avec les besoins exprimés dans le présent CCTP. Afin de faciliter l’analyse des offres, le candidat est invité à respecter la trame suivante dans ce document. 7.2.1. Présentation de la société Le candidat présentera sa société. Si le candidat est uniquement revendeur du produit, il présentera également la société éditrice de la solution. 7.2.2. Présentation générale du produit Le candidat présentera de manière globale le produit. Il évoquera l’historique des évolutions du produit. Il listera les références de déploiements aboutis du produit dans la version proposée, pour des projets similaires. 7.2.3. Réponse aux caractéristiques et fonctionnalités Le candidat indiquera de manière détaillée l’adéquation de sa solution avec les exigences décrites dans le présent CCTP. Il pourra intégrer des copies d’écrans de la solution en lien avec les fonctionnalités demandées. 7.2.4. Environnement technique de la solution Le candidat présentera les technologies employées par la solution. Il détaillera les pré-requis techniques nécessaires au déploiement de la solution. 7.2.5. Modèle de licences Le candidat expliquera le mode de calcul du coût de licence du produit. Les coûts seront recensés dans la grille de réponse fournie en annexe. Université de Strasbourg 14 7.2.6. Garantie et maintenance Conformément au besoin exprimé en « 5.2 Support et maintenance », le candidat détaillera les conditions de garanties de la solution ainsi que l’offre de support et maintenance. Le candidat indiquera le mode de tarification de cette prestation et effectuera une proposition financière. 7.3. Grilles de réponse Le candidat joindra à son dossier technique, au format numérique, les grilles de réponse de synthèse fournies en annexe dûment remplies. 7.4. Critères de jugement des offres Les critères retenus pour le jugement des offres sont pondérés de la manière suivante : • valeur technique de l’offre : 50 % ; • prix de la solution : 50 %, dont : 7.5. • partie forfaitaire : 80 %, • partie à bon de commande : 20 %. Planning prévisionnel Le planning prévisionnel de ce marché est comme suit : • Publication du marché : semaine 15 • Réception des offres : semaine 20 • Analyse des offres : semaine 20 et 21 • Sessions de négociation des offres : semaine 22 Université de Strasbourg 15