reduction des couts,voyage,low cost,cheap airfare,cheap flight,transport,energie,telecom,IT reduction,cout,anti,gaspi,cost killer,operatoire,hors production,e.procurement,grappiller,faire des economies,chasse,maitrise,budgetaire,budget,reduction,prix,tarifs,energie,optimisation,maintenance,TCO,Total cost of ownership,Return of investment,ROI,contrat cadre,achat,sauvage,cost cutting,saving,savy,expense,achats,affaires,bonne,promotions,promos
Costkiller centre de coûts
Costkiller services généraux
costkiller - Direction Financière
Grilles de Salaires
Charges Sociales Patronales
Audit
IMéthodes Analyse Coût
Trésorerie - Recouvrement
Délocalisation Mondialisation
costkiller - DRH
Ressources humaines
Licenciement - Plan social
Grille Salaire
Salaire métier
Salaire secteur
Salaire profession
Portage salarial
Conventions Collectives
Relation client - CRM
ERP
BPM
e-procurement
e-Sourcing
Externalisation
Production
GPAO
GMAO
Management
Supply Chain - Logistique
Gestion de Stock
Dématérialisation

IPsec : garde du corps officiel des réseaux privés virtuels IP

Les spécifications IPsec protège le protocole IP dans la perspective d'un convoyage de fonds sensibles. Ce standard valide le concept de réseaux privés virtuels à travers internet, bien qu'il souffre encore de défauts de jeunesse.

La version 6 du véhicule IP amenée à transporter "tout et n'importe quoi" dispose en standard d'une cuirasse désignée IPSec (IP Security) sensée garantir l'inviolabilité de chargements confidentiels. Seulement voilà, le peu d'entrain à migrer vers la nouvelle mouture IPv6 condamnait cet attribut à végéter dans l’antichambre de l'IETF. Pragmatique, le lobby Internet a en 1995 redonné une seconde chance à IPSec, en autorisant son portage sur la version contemporaine du protocole IP. Cette adaptation ne s'est cependant pas fait en un jour. Il a fallu attendre 1999 pour que la boîte à outils IPSec se dote d'un système d'échange de clés IKE (Internet Key Exchange) efficace, quoi que perfectible. L'alignement progressif des acteurs IP par nature sécessionnistes témoigne de cette maturité grandissante. Bien qu'il faille encore remarquer des poches de résistances propriétaires. Il est vrai que la flexibilité du modèle IPsec favorise les interprétations privées. Hormis un minimum d'exigences dans le tracé des tunnels virtuels; IPSec n'impose ni algorithmes de chiffrement, ni procédures d'authentification particulières. Pour blinder les tuyaux logiques d'un réseau privé virtuel (VPN: Virtual Private Network) IPsec s'en remet à la procédure ESP (Encapsulation Security Payload).

Une panoplie de gendarme pour les autoroutes de l'information

Comme son nom le laisse supposer ESP ne protège que le champ de données du paquet IP. Par ce biais seul le segment TCP/UDP du datagramme IP subit une opération de cryptographie, ce qui a l'avantage de ne pas entraver son aptitude au routage. Outre ce mode de "transport", la procédure ESP peut également brouiller l'intégralité du paquet. Ce "tunnel" intégral oblige cependant à créer une pseudo en-tête, en remplacement de celle d'origine. Quel que soit le mode d'encapsulation retenu, ESP autorise l'adjonction d'un champ de contrôle optionnel permettant de valider l'origine du paquet. Mais cette signature se rapporte au seul contenu. Pour garantir une identification complète y compris l'entête IP, IPsec s'en remet à la procédure AH (Authentification Header). Celle-ci ajoute au paquet IP une étiquette faisant office de signature numérique, afin de contrôler l'authenticité de ce dernier à l'autre extrémité. Pour engendrer ce "label d’origine contrôlé" IPSec emprunte concurremment les algorithmes de "hashing": MD-5 (Message Digest 5) ou Sha-1 (Secure hashing algorithm 1). Contrairement à ces deux fonctions de "hashing" obligatoires, IPsec n'impose aucun algorithme pour l'opération de chiffrement ESP. Avec bon sens, les solutions IPsec intègrent le codage DES (Data Encryption Standard), considéré comme le plus répandu. Seulement voilà, à force d'être défloré, cet algorithme a perdu tout crédit. Celui-ci s’efface au profit d'une version 3DES plus musclée. D'autres algorithmes (Blowfish, RC5…) doté d'un verrou plus difficile à briser, prétendent également au service IPsec. Cela dit, le délai de chiffrement induit par ces outils de cryptographie tempère leur utilisation intensive dans le contexte temps réel d'un VPN. Cet environnement ne sied guère aux algorithmes tel que RSA, néanmoins emprunté au sein d'IPSec pour chiffrer les clés adossées à des codages moins gourmands en ressources CPU. En effet, la caractéristique asymétrique de l’algorithme RSA prédispose ce dernier à un tel l'échange. Il faut comprendre par asymétrique l'usage de deux clés l'une pour chiffrer et l'autre pour déchiffrer, par opposition au cryptosystème symétrique doté d'une seule et même clé. Cette dichotomie autorise la diffusion d'une clé de chiffrage sans souci de confidentialité, d'où d'ailleurs l’appellation de clé publique. Par contre le géniteur de cette clé, se doit de garder jalousement en interne une contrepartie privée. Ces deux morceaux du sésame sont étroitement liés, puisque la clé publique correspond à un nombre entier, produit de deux nombres premiers composant la clé privée. Le niveau de protection tient donc à la difficulté à retrouver les facteurs premiers du nombre entier correspondant à la clé publique. Par exemple, pour une clé publique égale à 4, l’énigme se réduit aux combinaisons de produits suivants: 1x2 et 2x2. Mais pour une clé publique longue de plusieurs dizaines de chiffres, le nombre d'arrangements devient vite exponentiel. En pratique, un utilisateur souhaitant garantir la confidentialité de ses communications diffusera la clé publique à ses interlocuteurs pour que ces derniers puissent brouiller tous les messages à son attention. A la récéption de ces messages, celui-ci n’a plus qu’à retrouver la clé privée correspondant à la clé publique, à travers une table de corrélation pour en déchiffrement le contenu. Cette protection "asymétrique" s'avère fort utile pour protéger l'échange d'une clé privée associée à un algorithme tel que DES. Ainsi, seule la clé subira un chiffrement musclé alors que le message sera transmis à la volée après une cryptographie légère.

Le choix des armes

Toutefois, le biais du cryptosystème asymétrique n'est pas infaillible puisqu'il ne garantit en rien l'origine du message. Pour répondre à cette exigence, il existe un subterfuge qui consiste à comprimer le message, à l'aide d'un algorithme de "hashing", afin d’engendrer une empreinte caractéristique de petite taille. Ce condensé est alors brouillé à l’aide d'une clé privée afin de créer une «signature numérique». Ce paraphe subit un second chiffrement avec la clé publique du destinataire au même titre que le contenu du message. Une fois ces deux éléments déchiffrés par le biais de sa clé privée, le destinataire décode la signature numérique grâce à la clé publique de l’expéditeur. Il comprime et brouille à son tour le contenu du message, avec le même algorithme de codage aléatoire que l’expéditeur, puis compare le résultat obtenu avec l'abrégé reçu. Pour éviter ce contrôle laborieux, une autre solution d'identification emprunte des certificats numériques délivrés par un tiers de confiance. Ce notaire atteste ainsi de la paternité des clés échangées lors de chaque session. Malgré l'aversion de l'IETF pour les recommandations ITU-T, celui-ci à retenu les spécifications X.509 afin d'inhiber toutes dérives propriétaires. IPsec use également d'un biais d'authentification plus trivial basé sur un "mot de passe" commun désigné secret pré-partagé. Il faut comprendre par pré-partagé l'initialisation préalable de ce mot de passe sur l'ensemble des équipements du réseau privé virtuel, avant même d'entamer la phase d'authentification. Evidemment, cette identification mutuelle présuppose une distribution du dit mot de passe à l'ensemble des parties, à travers un média différent du VPN comme l'email, le téléphone, voire le courrier postal. Cette alternative rudimentaire ne sied qu'aux petits réseaux privés virtuels. Mais elle pallie la complexité des infrastructures à clé publique et les variations propriétaires constatées sur le standard X.509. En définitive, toutes ces options de sécurité confèrent au cadre normatif IPSec un champ de protection à géométrie variable. Une telle liberté de manœuvre contraint chaque unité à s'accorder, avec l'autre extrémité, sur le choix des armes sécuritaires. Cette mise au diapason appelée SA (Security Association) consiste pour les deux parties à s'accorder sur le niveau de sécurité ESP ou AH, le mode d'encapsulation "transport" ou "tunnel", les algorithmes de chiffrement et de hashing, les clés d'exploitation de ces derniers ainsi que leur date de péremption. Evidemment, le caractère temporaire des sessions implique une mise à jour régulière et sécurisée de tous ces paramètres. Une tâche fort difficile à satisfaire manuellement lorsque le VPN s'avère de taille conséquente. Pour automatiser au mieux cete configuration, l'IETF a donc défini un protocole désigné IKE (Internet Key Exhchange). Celui-ci reprend partiellement les fonctions des protocoles Oakley et SKEME (Secure Key Exchange MEchanism) afin d'engendrer automatiquement les clés et gérer dynamiquement leur renouvellement. Au premier, il emprunte l'algorithme Diffie-Hellman afin de sécuriser l'échange de clés. Celui-ci offre la possibilité à deux interlocuteurs de créer une clé commune appelée "secret partagé", sans avoir recours à une transaction chiffrée. Un simple échange de clé publique suffit. Pour renforcer la confidentialité, le protocole IKE reprend le mécanisme de rafraîchissement de clé du protocole SKEME, rendant ainsi les attaques éventuelles plus compliquées. IKE coiffe cet échange de clés, par un tiers protocole désigné ISAKMP (Internet Security Association and Key Management Protocol). Celui-ci se préoccupe de l'établissement des Associations de Sécurités (SA: Security Association) relatives aux sessions de communication de données, mais aussi aux SA liées à l'échange des paramètres IKE. Autrement dit, ISAKMP commence d'abord par protéger le canal de transmission, avant de sécuriser le transfert de données. La première phase consiste à établir une Association de Sécurité entre les deux extrémités, en commençant par négocier le choix de l'algorithme de chiffrement (DES, 3DES…), la fonction de hashing (MD5, SHA-1), la méthode d'authentification (Clé pré-partagé, signature ou certificat numérique), ainsi que les paramètres de codage propres à Diffie-Hellman. Puis, les deux parties entament le calcul du "secret partagé" et des clés de sessions destinées à protéger les échanges IKE suivants. Vient ensuite l'opération d'identification mutuelle selon le mode d’authentification retenu précédemment. Il faut remarquer que ce contrôle s'effectue postérieurement au calcul des clés. En outre, IKE permet de faire l'impasse sur cette authentification, afin de réduire overhead de service. Cette "mode agressif" se contente en effet de l'échange de 3 messages contre 6 pour en "mode principal". Une fois le circuit sécurisé, IKE passe alors la seconde phase en établissement des Associations de Sécurités de type IPsec, afin de protéger l'échange des données proprement dit. Cette phase recouvre grossièrement les mêmes opérations d'échange de paramètres, de clés et d’authentification que l'étape de protection du canal de transmission. Pour organiser ce contrôle de manière judicieuse IKE s'en remet à des mesures de sécurité SP(Securitiy Policies) associées à chaque SA. Outre la définition d'un profil de tunnel adéquate, ces règles de sécurité permettent d'affiner le contrôle au niveau de chaque datagramme et le cas échéant de rejeter les contrevenants. Malheureusement faute d'outil, la programmation centralisé de ces règles s'effectue encore manuellement. Outre cette entrave, le standard IPsec souffre d'un manque d’interopérabilité persistant. Rares sont les produits à supporter rigoureusement toutes les spécifications IPSec. La liberté laissée quant au support des algorithmes de chiffrement ne facilite en rien cette interaction entre produits d'origines disparates. Même motif et même punition pour le protocole IKE qui souffre d'une prolifération de techniques d’authentification intégrées selon le bon vouloir de chaque vendeur. Même le standard de définition et de révocation de certificats numériques X.509 souffre d'incompatibilité. Enfin, sur le terrain, IPSec se cantonne encore à la construction de VPN entre réseaux locaux, bien qu'une version client/serveur désignée IPSRA (IPsec Remote Access) soit déjà formalisée par l'IETF. En attendant l'émergence de ce protocole, les VDPN (Virtual Dial-up Private Network) demeure la châsse gardée des procédures PPTP (Point to Point Tunneling Protocol) ou L2TP(Layer 2 Tunneling Protocol).

Source : costkiller.net

 

Dictionnaire & Définitions   3 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Costkiller.net - portail réduction des coûts 2012 - 2013 - Coskiller.net - all rights reserved

Costkiller.net   B2B cost saving and costs cutting portal costkiller copyright