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

Documents pareils