La Française des Jeux disposait sur son infrastructure DNS/DHCP

Sécurisation et résilience des services
DNS/DHCP
Gestion de l’adressage IP automatisée
Eric ARNOUX
Responsable Réseaux & Télécoms FDJ
[email protected]
Sommaire










La Française des Jeux
Situation initiale
Architecture DNS/DHCP Corporate
Constat technique
Projet & Etapes
Choix technique
Architecture Corporate Cible
Architecture DMZ Cible
Retour d’expérience
Perspectives
La Française des Jeux

Opérateur de jeux de hasard payant

Les chiffres clefs :



12 Milliard € CA en 2012
4 Milliard de transactions jeu / an
3ème loterie mondiale

SI complètement géré en interne avec 2 salles de Datacenter installées
sur le site de Vitrolles

Criticité et performance des opérations (activité 24h/24)
Situation initiale

La Française des Jeux disposait sur son infrastructure DNS/DHCP
interne d’une solution logicielle Vital QIP Entreprise server de chez
Alcatel Lucent installée sur des serveurs Sun Solaris :




De 3 serveurs physiques SUN Sparc et SUN ULTRA pour l’architecture interne (VitalQIP)
De 2 serveurs physiques SUN Solaris pour le DNS externe en BIND 8.2
1 serveur Maître sur le site principal FDJ
D’une synchronisation des zones réalisée via le mécanisme de maître/esclave de BIND
(serveurs esclaves sur les autres sites)
 La plateforme fournissait les services DHCP et NTP à l’environnement
de travail




Le service DHCP était assuré par 3 serveurs ; le service DNS était assuré par 5 serveurs
Le mécanisme de bail DHCP était sécurisé, pour les postes se connectant au réseau, par l’
association MAC/IP.
Une configuration spécifique sur les commutateurs N2/N3 permettait de relayer les
informations vers les serveurs DHCP correspondants (IP Helper)
Chacun des 2 serveurs Solaris (serveur de temps) était raccordé à un récepteur GPS, pour
fournir l’horloge, via une liaison série (RS232)
Architecture situation initiale
Constat Technique (en 2008)

DNS Interne (VitalQIP)
 Modèle de licence (dépend du # d'adresses) – ne permettait pas la prise en compte de l’ensemble




du parc d’adresses
Solution logicielle sur serveurs + base de données (Sybase) multiples couches à gérer (systèmes,
serveurs, base de données)
Mise à jour QIP complexe et risquée
Pérennité solution QIP ? hors cœur de métier Alcatel Lucent
Mise en œuvre de la résilience des services complexe





Sûreté de fonctionnement, sauvegarde, traçabilité modifications au niveau : système Solaris,
applicatif QIP, Base de données Sybase…
2 gestions : 1 fichier Excel du plan d’adressage, l’application QIP DNS/DHCP : décorélation
progressive
Aucun outil central et complet d’exploitation et d’administration : gestion de fichiers de
configuration et nécessité de scripter
Difficulté de déléguer les accès

DNS Externe
 Risque de sécurité lié à l’exposition sur l’internet
Points communs
 Abandon Solaris (cf. strategie société)
 Coûts Exploitation/Maintenance SUN, Exploitation complexe





Environnement géré par les équipes systèmes et sécurités
Redondance complexe (cluster Solaris)
Gestion manuelle des configurations : scripts, fichiers texte - risque d'erreurs
Gestion et application des patches Bind / dépendance système
Besoin NTP
Projet & étapes
Décision en 2008 de faire évoluer l’infrastructure



Objectifs







Etude de marché

Réalisation d’une shortlist constructeurs:
• Efficient IP
• Infoblox
• …
Conception de la solution avec prise en compte des contraintes réseaux, système et
sécurité






Une solution centralisée
Un mode Appliance
DNS / DHCP / NTP, gestion du plan d’adressage
Outil de gestion centralisée
Exploitation simplifiée
Délégation des environnements (Bureautique, système, réseau)
Ratio : Coût / (Performance, Sécurité)
Haute disponibilité
Administration centralisée et granulaire
Logs et Troubleshoot rapide
Mise à niveau simplifiée
Localisation des équipements sur site (autonomie des sites)
Réalisation d’un POC (Proof of concept)



Evaluation des fonctionnalités disponibles
Simplicité de la migration des données (quelques outils)
Simplicité de mise en œuvre
Choix technique : Pourquoi
INFOBLOX ?


Principes d’architectures :






1 Cluster par site
Gestion centralisée
Etanchéité environnement interne / externe (2 Grid ≠)
Standardisation du déploiement en mode cluster « Haute disponibilité »
Disponibilité locale des services au niveau des sites
• Chaque poste de travail dispose du DNS primaire de son site de rattachement
• Réduction des requêtes sur le WAN
Double alimentation sur les sites critiques
Points différentiateurs












Véritable Appliance dédiée
OS durci (système d’exploitation NIOS) et absence d'accès root (versus autres solutions testées)
Granularité - délégation d'administration pour les équipes techniques en charge
Traçabilité des actions
Haute disponibilité au niveau réseau
Simplification de la mise en œuvre - transparente pour l'ensemble des services portés par
l'Appliance (DNS, DHCP, NTP en stratum1) - intégrée
Points additionnels : support SNMP complet et détaillé, API documentée et supportée Sauvegarde et restauration "one-click" (Depuis la version v5)
Processus de mise à jour simple, unifié ("one button")
Vérification de la cohérence et de la consistance des données : interface graphique, API

Mécanisme de vérification  unicité des adresses IP, des noms DNS…
Organisation du support : 24/7/365
Maturité / Pérennité / Taille de la société
Architecture interne actuelle
IB 1552
IB 550
Architecture externe actuelle
Hébergeur serveurs secondaires
IB 1552
Retour d’expérience

Les aspects techniques

Migration DNS/DHCP/NTP/IPAM (charge : 60 j.h, délai : 4 mois fin de VSR)
 Cinq étapes : Etude existant, Etude migration, Etude/réalisation interne, Etude/réalisation Externe,







Formation-transfert de compétences.
Etudes incluant : dossier d’architecture et de spécifications, maquettages, tests fonctionnels, de
performance et sécurité (dont tests de résilience)
Réalisations en HNO et en minimisant la coupure de service
Forte stabilité de la plateforme (faible nombre d’incident)
 Aucun incident de saturation à ce jour (sauf une fois!)
 Un bagot HA lié à une perte de lien inter-membres
Simplicité des opérations de gestion et d’administration
 Création de sous-réseau
 Réservation adresse IP
 Dashboard complet permettant une vision globale de la plateforme
Réduction des risques d'erreurs
 Arrêt du process « Excel »
Délégation granulaire
 Chaque utilisateur dispose d’un compte propre permettant de tracer ses actions et d’assurer un suivi
Mises à jour sur vulnérabilités simples, avec sécurité du retour arrière
Retour d’expérience (suite)



Intervention simplifiée à l’aide des clusters sur chacun des sites
Performances au RDV :
 Grid interne : gestion de plusieurs milliers de Lans, de postes utilisateurs et de serveurs en


DNS/DHCP/NTP/IPAM
Grid externe : gestion de 1500 zones dns sur l’internet
Actes techniques d’administration, supervision et sauvegarde quotidiens réalisés avec succès
La relation Infoblox

Un support de qualité et disponible

Un accompagnement en formation et transferts de compétences efficace

Des aspects économiques corrects!

Une présence permanente via les clubs utilisateurs, newsletters d’informations,
events, formations gratuites…
Evolutions prévues en 2013
Augmentation des capacités des grid interne et externe - nouvelles plateformes
TRINZIC DDI (DNS, DHCP, IPAM)
Passage en NIOS version 6
Evolution de l’architecture du grid interne par ajout d’un membre sur le site de
PRA (Marseille)
Intégration du module de reporting pour améliorer l’ exploitation
Extension du service DNS dans les Zones DMZ sécurisées (jeux) par ajout d’un
cluster
Possibilité d’activer le DNSSEC a terme ?
IPV6 ?
Questions ?
Merci de votre attention