Ignorer les liens de navigation | |
Quitter l'aperu | |
![]() |
Sécurisation du réseau dans Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library (Français) |
1. Utilisation de la protection des liens dans des environnements virtualisés
3. Serveurs Web et protocole SSL (Secure Sockets Layer)
4. IP Filter dans Oracle Solaris (présentation)
6. Architecture IPsec (présentation)
Associations de sécurité IPsec
Mécanismes de protection IPsec
ESP (Encapsulating Security Payload, association de sécurité)
Considérations de sécurité lors de l'utilisation de AH et ESP
Authentification et chiffrement dans IPsec
Algorithmes d'authentification dans IPsec
Algorithmes de chiffrement dans IPsec
Stratégies de protection IPsec
Modes Transport et Tunnel dans IPsec
Réseaux privés virtuels et IPsec
Passage de la translation d'adresses et IPsec
IPsec et les zones Oracle Solaris
7. Configuration d'IPsec (tâches)
8. Architecture IPsec (référence)
9. Protocole IKE (présentation)
Pour protéger les paquets IP, IPsec les chiffre et/ou les authentifie. IPsec s'exécute dans le module IP. Par conséquent, une application Internet peut tirer profit d'IPsec sans pour autant avoir à modifier sa configuration. Une utilisation à bon escient d'IPsec en fait un outil efficace de sécurisation du trafic réseau.
La protection IPsec implique les composants principaux suivants :
Protocoles de sécurité : les mécanismes de protection de datagramme IP. L'en-tête d'authentification (AH) inclut un hachage du paquet IP et garantit l'intégrité. Bien que le contenu du datagramme ne soit pas chiffré, le destinataire est sûr que le contenu du paquet n'a subi aucune modification et que l'expéditeur a envoyé les paquets. protocole ESP chiffre les données IP et obscurcit, par conséquent, le contenu des paquets lors de leur transmission. ESP garantit également l'intégrité des données par le biais d'une option d'algorithme d'authentification.
Associations de sécurité (SA) : paramètres cryptographiques et protocole de sécurité IP appliqués à un flux de trafic réseau donné. Chaque SA dispose d'une référence unique appelée SPI (security parameter index, index de paramètres de sécurité).
Base de données des associations de sécurité (SADB) : base de données qui associe un protocole de sécurité à une adresse IP de destination et un numéro d'indexation. Ce numéro d'indexation est appelé index du paramètre de sécurité. Ces trois éléments (protocole de sécurité, adresse de destination et SPI) identifient un seul paquet IPsec légitime. La base de données garantit que le paquet protégé est reconnu par le récepteur à son arrivée. Elle permet également au récepteur de déchiffrer la communication, de vérifier que les paquets n'ont pas été altérés, de rassembler les paquets et de livrer les paquets à leur destination finale.
Gestion des clés : génération et distribution des clés des algorithmes cryptographiques et de SPI.
Mécanismes de sécurité : algorithmes de chiffrement et d'authentification qui protègent les données des datagrammes IP.
SPD (Security Policy Database, base de données de stratégie de sécurité) : base de données indiquant le niveau de protection à appliquer à un paquet. La base de données SPD filtre le trafic IP et identifie le mode de traitement des paquets. Un paquet peut être rejeté, passé au clair ou protégé à l'aide d'IPsec. En ce qui concerne les paquets sortants, les bases de données SPD et SADB déterminent le niveau de protection à appliquer. Pour les paquets entrants, la base de données SPD permet de déterminer l'acceptabilité du niveau de protection. Si le paquet est protégé par IPsec, une consultation de la base de données SPD est effectuée après déchiffrement et vérification du paquet.
IPsec applique les mécanismes de sécurité aux datagrammes IP circulant en direction de l'adresse IP de destination. A l'aide des informations contenues dans la base de données SADB, le destinataire vérifie que les paquets entrants sont légitimes et les déchiffre. Les applications peuvent appeler IPsec pour appliquer les mécanismes aux datagrammes IP au niveau de chaque socket.
Lorsque la stratégie IPsec est appliquée à un port sur lequel un socket est déjà connecté, le trafic qui utilise ce socket ne bénéficie pas de la protection IPsec. Bien sûr, les sockets ouverts sur un port après l'application de la stratégie IPsec en bénéficient aussi.
Le groupe IETF (Internet Engineering Task Force) a publié un certain nombre de documents RFC (Request for Comments, demande de commentaires) décrivant l'architecture de sécurité de la couche IP. Tous les RFC constituent la propriété intellectuelle de l'Internet Society. Pour plus d'informations sur les RFC, reportez-vous au site Web http://www.ietf.org/. Les références de sécurité IP les plus générales sont couvertes par les RFC suivants :
RFC 2411, "IP Security Document Roadmap", novembre 1998
RFC 2401, "Security Architecture for the Internet Protocol", novembre 1998
RFC 2402, "IP Authentication Header", novembre 1998
RFC 2406, "IP Encapsulating Security Payload (ESP)", novembre 1998
RFC 2408, "Internet Security Association and Key Management Protocol (ISAKMP)", novembre 1998
RFC 2407, "The Internet IP Security Domain of Interpretation for ISAKMP", novembre 1998
RFC 2409, "The Internet Key Exchange (IKE)", novembre 1998
RFC 3554, “On the Use of Stream Control Transmission Protocol (SCTP) with IPsec,” juillet 2003
Les documents RFC IPsec définissent un certain nombre de termes qui s'avèrent utiles lors de l'implémentation d'IPsec sur des systèmes. Les tableaux suivants répertorient les termes IPsec, leur acronyme et leur définition. Le Tableau 9-1 dresse la liste des termes de négociation de clé.
Tableau 6-1 Termes IPsec, acronymes et usages
|