Apr\u00e8s des ann\u00e9es d’\u00e9volution de la puissance des serveurs, mais aussi de la complexit\u00e9 des architecture d\u00e9ploy\u00e9es, la r\u00e9ponse des architectures r\u00e9seau aux besoins de s\u00e9curit\u00e9 et d’interconnexion n’a pas \u00e9norm\u00e9ment \u00e9volu\u00e9. Sagesse ou manque de communication entre discipline?<\/p>\n
Essayons de voyager d’une architecture r\u00e9seau \u00e0 une infrastructure orient\u00e9e services.
\n<\/p>\n
Nombre d’entreprises (et quelques particuliers) s\u00e9curisent leurs serveurs par une architecture diff\u00e9renciant fortement \u00ab\u00a0l’int\u00e9rieur\u00a0\u00bb de \u00ab\u00a0l’ext\u00e9rieur\u00a0\u00bb.
\nClassiquement, cela abouti \u00e0 un mod\u00e8le<\/p>\n
Internet < -> DMZ < -> LAN<\/pre>\nO\u00f9 l’on va positionner un firewall entre chaque couche (on peut aller un peu plus loin en s\u00e9parant encore le LAN en zones plus ou moins \u00ab\u00a0int\u00e9rieures\u00a0\u00bb comme par exemple une zone LAN production et une zone LAN entreprise s\u00e9par\u00e9es par un firewall.<\/p>\n
Ce mod\u00e8le part d’une hypoth\u00e8se commun\u00e9ment admise: l’ext\u00e9rieur est dangereux et l’int\u00e9rieur est une zone de confiance (Microsoft avec Internet Explorer a m\u00eame \u00e9tendu cette notion au niveau applicatif avec des zones de plus ou moins de confiance, et l’a d’ailleurs pay\u00e9 assez cher par plusieurs failles de s\u00e9curit\u00e9 li\u00e9es \u00e0 des attaques semblant venir de ce qu’IE pensait \u00eatre une zone de confiance).<\/p>\n
Pourquoi changer?<\/h3>\n
Cette hypoth\u00e8se, assez ancienne, repose sur l’id\u00e9e que l’attaque est organis\u00e9e, voire manuelle. Avec la prolif\u00e9ration des virus et des bot-nets associ\u00e9s, cela tend \u00e0 \u00eatre plus discutable maintenant.
\nDe plus, cette hypoth\u00e8se est simplificatrice, elle ne r\u00e9pond que par r\u00e9duction, voire effet de bord, \u00e0 l’exigence de base de la s\u00e9curit\u00e9 : Ce qui n’est pas autoris\u00e9 est interdit<\/em>.<\/p>\nD’autre part, il est actuellement possible de d\u00e9ployer un firewall de base sur un serveur sans prendre un risque de charge d\u00e9raisonnable, et m\u00eame de crypter les communications (\u00e0 la SSL).<\/p>\n
Ainsi, chaque serveur se prot\u00e8ge des acc\u00e8s non autoris\u00e9s, le filtrage pouvant \u00eatre bien plus fin qu’avec un firewall qui raisonne g\u00e9n\u00e9ralement par zones. Rien n’emp\u00eache d’ailleurs d’ajouter un firewall, par exemple simplement en entr\u00e9e de r\u00e9seau, pour assurer un premier tri, une r\u00e9duction de trafic et un protection contre des erreurs de configuration (2 pr\u00e9cautions valant mieux qu’une).<\/p>\n
Par exemple, un serveur de base de donn\u00e9es fermera tout sauf<\/p>\n
\n
- ssh pour l’administration, et uniquement les flux entrants provenant des consoles d’administration.<\/li>\n
- sql (un port pour mysql, un peu plus pour Oracle), et uniquement les flux entrants provenant des serveurs applicatifs dont on h\u00e9berge une base de donn\u00e9es.<\/li>\n
- les flux sortants sont g\u00e9r\u00e9s et s\u00e9curis\u00e9s par le firewall, uniquement en r\u00e9ponse aux flux autoris\u00e9s ci-dessus.<\/li>\n
- on pourra \u00e9ventuellement ajouter un flux sortant d’authentification si elle est centralis\u00e9e, uniquement vers l’annuaire.<\/li>\n
- les communications DNS pourront \u00eatre autoris\u00e9es en entr\u00e9e\/sortie, mais uniquement avec les serveurs DNS.<\/li>\n<\/ul>\n
soit 2 ports TCP entrants et filtr\u00e9s, et au plus un port TCP et un port UDP sortants filtr\u00e9s.<\/p>\n
Vers une architecture orient\u00e9e service<\/h3>\n
Prenons cette exigence au pied de la lettre, est voyons si l’on peut la r\u00e9-exprimer en termes adaptables \u00e0 une architecture r\u00e9seau\/syst\u00e8me orient\u00e9e services<\/strong>, avec<\/p>\n
\n
- des clients,<\/li>\n
- des services consommateurs<\/li>\n
- et des services fournisseurs<\/li>\n<\/ul>\n
(un service pouvant \u00eatre les deux).<\/p>\n
Je s\u00e9pare la notion de client et de service consommateur par le fait qu’un client n’est pas pr\u00e9-identifi\u00e9.
\nCela diff\u00e9rencie donc deux types de services fournisseurs<\/p>\n