Vers une infrastructure orientée services
Après des années d’évolution de la puissance des serveurs, mais aussi de la complexité des architecture déployées, la réponse des architectures réseau aux besoins de sécurité et d’interconnexion n’a pas énormément évolué. Sagesse ou manque de communication entre discipline?
Essayons de voyager d’une architecture réseau à une infrastructure orientée services.
Nombre d’entreprises (et quelques particuliers) sécurisent leurs serveurs par une architecture différenciant fortement « l’intérieur » de « l’extérieur ».
Classiquement, cela abouti à un modèle
Internet < -> DMZ < -> LAN
Où l’on va positionner un firewall entre chaque couche (on peut aller un peu plus loin en séparant encore le LAN en zones plus ou moins « intérieures » comme par exemple une zone LAN production et une zone LAN entreprise séparées par un firewall.
Ce modèle part d’une hypothèse communément admise: l’extérieur est dangereux et l’intérieur est une zone de confiance (Microsoft avec Internet Explorer a même étendu cette notion au niveau applicatif avec des zones de plus ou moins de confiance, et l’a d’ailleurs payé assez cher par plusieurs failles de sécurité liées à des attaques semblant venir de ce qu’IE pensait être une zone de confiance).
Pourquoi changer?
Cette hypothèse, assez ancienne, repose sur l’idée que l’attaque est organisée, voire manuelle. Avec la prolifération des virus et des bot-nets associés, cela tend à être plus discutable maintenant.
De plus, cette hypothèse est simplificatrice, elle ne répond que par réduction, voire effet de bord, à l’exigence de base de la sécurité : Ce qui n’est pas autorisé est interdit.
D’autre part, il est actuellement possible de déployer un firewall de base sur un serveur sans prendre un risque de charge déraisonnable, et même de crypter les communications (à la SSL).
Ainsi, chaque serveur se protège des accès non autorisés, le filtrage pouvant être bien plus fin qu’avec un firewall qui raisonne généralement par zones. Rien n’empêche d’ailleurs d’ajouter un firewall, par exemple simplement en entrée de réseau, pour assurer un premier tri, une réduction de trafic et un protection contre des erreurs de configuration (2 précautions valant mieux qu’une).
Par exemple, un serveur de base de données fermera tout sauf
- ssh pour l’administration, et uniquement les flux entrants provenant des consoles d’administration.
- sql (un port pour mysql, un peu plus pour Oracle), et uniquement les flux entrants provenant des serveurs applicatifs dont on héberge une base de données.
- les flux sortants sont gérés et sécurisés par le firewall, uniquement en réponse aux flux autorisés ci-dessus.
- on pourra éventuellement ajouter un flux sortant d’authentification si elle est centralisée, uniquement vers l’annuaire.
- les communications DNS pourront être autorisées en entrée/sortie, mais uniquement avec les serveurs DNS.
soit 2 ports TCP entrants et filtrés, et au plus un port TCP et un port UDP sortants filtrés.
Vers une architecture orientée service
Prenons cette exigence au pied de la lettre, est voyons si l’on peut la ré-exprimer en termes adaptables à une architecture réseau/système orientée services, avec
- des clients,
- des services consommateurs
- et des services fournisseurs
(un service pouvant être les deux).
Je sépare la notion de client et de service consommateur par le fait qu’un client n’est pas pré-identifié.
Cela différencie donc deux types de services fournisseurs
- les services fournisseurs à des clients
- les services fournisseurs à des services
Concentrons-nous sur la relation entre nos deux types de services. On admet communément que les communications entre les serveurs hébergeant ces services sont autorisées, c’est cette simplification que nous essayons ici d’éviter.
Appliquons pour résoudre ce dilemme une déclinaison du pattern d’inversion de contrôle (IoC) en affirmant que c’est le service consommé que l’on va « brancher » sur le service consommateur, notre container étant le réseau, notre branchement sera (par exemple) un tunnel ssh.
On pourra selon l’environnement ajouter un système automatique de reprise en cas de coupure des liens entre serveurs.
par exemple un serveur de base de données fermera tout sauf
- ssh pour l’administration, et uniquement les flux entrants provenant des consoles d’administration et du serveur d’annuaire.
mais il établira
- un tunnel ssh vers chaque serveur applicatif dont on héberge une base de données.
- les communications DNS pourront être autorisées en entrée/sortie, mais uniquement avec les serveurs DNS.
soit 1 port TCP entrant et filtré et au plus un port TCP et un port UDP sortants filtrés.
Quels avantages par rapport à la solution précédente ?
- les communications sont cryptées et ouvrent donc notre infrastructure à un déploiement multi-site.
- les serveurs, au-delà de la vérification des IPs, sont authentifiés réciproquement de façon forte. Le spoofing, même interne, est rendu quasiment impossible.
- chaque service a un contrat à remplir vis-à-vis de ses clients, en cas de migration/consolidation par exemple, on peut « basculer » d’un ancien à un nouveau serveur par une simple micro-coupure.
Pour les fournisseurs de services à des clients, on pourra conserver le modèle précédent, en particulier dans le cas de clients « externes ».
Perspectives
Mettre en place ce type d’architecture depuis des clients.
- Elle nécessitera cependant une extension du système de provisionning pour déclarer/répudier les clients auprès des services fournisseurs (les serveurs frontaux par exemple). Mais ce sera pour un autre article…
Evoluer vers une infrastructure multi-sites car on peut maintenant s’affranchir de la continuité de réseau
- Tirant partie des interconnexions opérateurs, bien plus performantes et résiliantes que la plupart de celles rencontrées en entreprise ou dans les DRP/PCA/PRA (reprise-continuité d’activités).
- Mettant en concurrence opérationnelle les fournisseurs et répondant en partie au paradoxe centralisation ou réduction des coûts par proximité.
- Réduisant les risques court terme liés aux revirements d’alliances et de tarifs.
- Initiant les équipes infrastructures à de nouveaux modèles de scalabilité, économiques et en phase avec la réactivité et la proximité des services récents.
