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 eric.arnoux@lfdj.com
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 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é) 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é 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 mise en œuvre Simplicité de la migration des données (quelques outils)
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