Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Écouteurs TLS pour votre Network Load Balancer
Pour utiliser un écouteur TLS, vous devez déployer au moins un certificat de serveur sur votre équilibreur de charge. L'équilibreur de charge utilise un certificat de serveur pour mettre fin à la connexion frontale, puis déchiffrer les demandes des clients avant de les envoyer aux cibles. Veuillez noter que si vous devez transmettre du trafic chiffré aux cibles sans que l'équilibreur de charge le déchiffre, créez un écouteur TCP sur le port 443 au lieu de créer un écouteur TLS. L'équilibreur de charge transmet la demande à la cible telle quelle, sans la déchiffrer.
Elastic Load Balancing utilise une configuration de négociation TLS (ou stratégie de sécurité) pour négocier des connexions TLS entre un client et l'équilibreur de charge. Une stratégie de sécurité est une combinaison de protocoles et de chiffrements. Le protocole établit une connexion sécurisée entre un client et un serveur, et s'assure que toutes les données transmises entre le client et votre équilibreur de charge sont privées. Un chiffrement est un algorithme de chiffrement qui utilise des clés de chiffrement pour créer un message codé. Les protocoles utilisent plusieurs chiffrements pour chiffrer les données sur Internet. Pendant le processus de négociation de connexion , le client et l'équilibreur de charge présentent une liste de chiffrements et de protocoles pris en charge par chacun d'entre eux dans l'ordre de préférence. Le premier chiffrement sur la liste du serveur qui correspond à l'un des chiffrements du client est sélectionné pour la connexion sécurisée.
Les Network Load Balancers ne prennent pas en charge la renégociation TLS ni l'authentification TLS mutuelle (mTLS). Pour la prise en charge de mTLS, créez un écouteur TCP au lieu d'un écouteur TLS. L'équilibreur de charge transmet la demande en l'état pour que vous puissiez implémenter mTLS sur la cible.
Pour créer un écouteur TLS, consultez Ajouter un écouteur. Pour les démonstrations associées, veuillez consulter Prise en charge de TLS sur Network Load Balancer
Certificats de serveur
L'équilibreur de charge exige des certificats X.509 (certificats de serveur). Les certificats constituent une forme numérique d'identification émise par une autorité de certification (AC). Un certificat contient les informations d'identification, une période de validité, une clé publique, un numéro de série et la signature numérique de l'émetteur.
Lorsque vous créez un certificat à utiliser avec votre équilibreur de charge, vous devez spécifier un nom de domaine. Le nom de domaine figurant sur le certificat doit correspondre à l'enregistrement du nom de domaine personnalisé, afin que nous puissions vérifier la connexion TLS. S'ils ne correspondent pas, le trafic n'est pas chiffré.
Vous devez spécifier un nom de domaine complet (FQDN) pour votre certificat, tel que www.example.com
ou un nom de domaine apex tel que example.com
. Vous pouvez également utiliser un astérisque (*) comme caractère générique pour protéger plusieurs noms de sites dans le même domaine. Lorsque vous demandez un certificat générique, l'astérisque (*) doit se trouver tout à gauche du nom de domaine et ne peut protéger qu'un seul niveau de sous-domaine. Par exemple, *.example.com
protège corp.example.com
et images.example.com
, mais ne peut pas protéger test.login.example.com
. Notez également que *.example.com
ne protège que les sous-domaines de example.com
, il ne protège pas le domaine strict ou apex (example.com
). Le nom générique apparaît dans le champ Objet et dans l'extension Autre nom de l'objet du certificat. Pour plus d'informations sur les certificats publics, consultez Demande de certificat public du Guide de l'utilisateur AWS Certificate Manager.
Nous vous recommandons de créer des certificats pour vos équilibreurs de charge à l'aide d'AWS Certificate Manager (ACM)
Sinon, vous pouvez utiliser les outils TLS pour créer une demande de signature de certificat (CSR), puis faire signer le CSR par une CA afin de générer un certificat que vous importerez dans ACM ou que vous chargerez dans AWS Identity and Access Management (IAM). Pour plus d'informations, veuillez consulter Importation de certificats dans le Guide de l'utilisateur AWS Certificate Manager ou Gestion des certificats de serveur dans le Guide de l'utilisateur IAM.
Table des matières
Algorithmes clés supportés
RSA 1024 bits
RSA 2048 bits
RSA 3072 bits
ECDSA 256 bits
ECDSA 384 bits
ECDSA 512 bits
Certificat par défaut
Lorsque vous créez un écouteur TLS, vous devez spécifier précisément un certificat par défaut. Ce certificat est connu comme le certificat par défaut. Vous pouvez remplacer le certificat par défaut après avoir créé l'écouteur TLS. Pour plus d’informations, consultez Remplacer le certificat par défaut.
Si vous spécifiez des certificats supplémentaires dans une liste de certificats, le certificat par défaut est uniquement utilisé si un client se connecte sans utiliser le protocole SNI (Server Name Indication) pour spécifier un nom d'hôte ou si la liste de certificats ne contient aucun certificat correspondant.
Si vous ne spécifiez aucun certificat supplémentaire, mais que vous que devez héberger plusieurs applications sécurisées via un seul équilibreur de charge, vous pouvez utiliser un certificat générique ou ajouter un Subject Alternative Name (SAN) pour chaque domaine supplémentaire à votre certificat.
Liste de certificats
Après avoir créé un écouteur TLS, il comprend un certificat par défaut et une liste de certificats vide. Vous pouvez éventuellement ajouter des certificats à la liste de certificats pour l'écouteur. Grâce à une liste de certificats, l’équilibreur de charge peut ainsi prendre en charge plusieurs domaines sur le même port et fournir un certificat différent pour chaque domaine. Pour plus d’informations, consultez Ajouter des certificats à la liste des certificats.
L’équilibreur de charge prend également en charge un algorithme de sélection de certificat intelligent avec prise en charge de SNI. Si le nom d'hôte fourni par un client correspond à un seul certificat de la liste de certificats, l'équilibreur de charge sélectionne ce certificat. Si un nom d'hôte fourni par un client correspond à plusieurs certificats de la liste de certificats, l'équilibreur de charge sélectionne celui qui est le mieux adapté par rapport aux capacités du client. La sélection des certificats dépend des critères suivants, dans l'ordre indiqué :
-
Algorithme de hachage (préférer SHA plutôt que MD5)
-
Longueur de clé (préférer la plus longue)
-
Période de validité
Les entrées de journaux d'accès de l'équilibreur de charge indiquent le nom d'hôte spécifié par le client et le certificat présenté à ce dernier. Pour plus d’informations, consultez Entrées des journaux d'accès.
Renouvellement des certificats
Chaque certificat est associé à une durée de validité. Vous devez veiller à renouveler ou remplacer chaque certificat pour votre équilibreur de charge avant la fin de la période de validité. Cela inclut le certificat par défaut les certificats dans une liste de certificats. Le renouvellement ou le remplacement d'un certificat n'affecte pas les demandes en cours reçues par le nœud d'équilibreur de charge et qui sont en attente d'acheminement vers une cible saine. Après le renouvellement d'un certificat, les nouvelles demandes utilisent le certificat renouvelé. Après le remplacement d'un certificat, les nouvelles demandes utilisent le nouveau certificat.
La gestion des renouvellements et des remplacements s'effectue comme suit :
-
Les certificats fournis par AWS Certificate Manager et déployés sur votre équilibreur de charge peuvent être renouvelés automatiquement. ACM essaie de renouveler les certificats avant leur expiration. Pour plus d'informations, consultez Renouvellement géré dans le Guide de l'utilisateur AWS Certificate Manager.
-
Si vous avez importé un certificat dans ACM, vous devez surveiller sa date d'expiration et le renouveler avant qu'il n'arrive à expiration. Pour plus d'informations, consultez la section Importation de certificats dans le AWS Certificate ManagerGuide de l'utilisateur.
-
Si vous avez importé un certificat dans IAM, vous devez en créer un nouveau, l'importer dans ACM ou IAM, l'ajouter dans votre équilibreur de charge et supprimer de votre équilibreur de charge le certificat arrivé à expiration.
Stratégies de sécurité
Lorsque vous créez un écouteur TLS, vous devez sélectionner une stratégie de sécurité. Vous pouvez mettre à jour la stratégie de sécurité si nécessaire. Pour plus d’informations, consultez Mettre à jour la stratégie de sécurité.
Considérations :
-
Il s'agit
ELBSecurityPolicy-TLS13-1-2-2021-06
de la politique de sécurité par défaut pour les écouteurs TLS créés à l'aide du. AWS Management Console-
Nous recommandons la politique
ELBSecurityPolicy-TLS13-1-2-2021-06
de sécurité, qui inclut le protocole TLS 1.3 et qui est rétrocompatible avec le protocole TLS 1.2.
-
-
Il s'agit
ELBSecurityPolicy-2016-08
de la politique de sécurité par défaut pour les écouteurs TLS créés à l'aide du. AWS CLI -
Vous pouvez choisir la politique de sécurité qui est utilisée pour les connexions frontales, mais pas pour les connexions dorsales.
-
Pour les connexions backend, si votre écouteur TLS utilise une stratégie de sécurité TLS 1.3, c'est la stratégie de sécurité
ELBSecurityPolicy-TLS13-1-0-2021-06
qui est utilisée. Dans le cas contraire, la stratégie de sécuritéELBSecurityPolicy-2016-08
est utilisée pour les connexions backend.
-
-
Pour respecter les normes de conformité et de sécurité qui nécessitent la désactivation de certaines versions du protocole TLS, ou pour prendre en charge les anciens clients nécessitant des chiffrements obsolètes, vous pouvez utiliser l'une des politiques de sécurité.
ELBSecurityPolicy-TLS-
Vous pouvez activer les journaux d'accès pour obtenir des informations sur les requêtes TLS envoyées à votre Network Load Balancer, analyser les modèles de trafic TLS, gérer les mises à niveau des politiques de sécurité et résoudre les problèmes. Activez la journalisation des accès pour votre équilibreur de charge et examinez les entrées du journal d'accès correspondantes. Pour plus d'informations, veuillez consulter Accès aux journaux (langue française non garantie) et Exemples de requêtes du Network Load Balancer. -
Vous pouvez restreindre les politiques de sécurité accessibles aux utilisateurs de votre pays Comptes AWS et en AWS Organizations utilisant les clés de condition Elastic Load Balancing dans vos politiques IAM et de contrôle des services (SCP), respectivement. Pour plus d'informations, voir Politiques de contrôle des services (SCP) dans le guide de l'AWS Organizationsutilisateur
Stratégies de sécurité TLS 1.3
Note
Les politiques de sécurité TLS 1.3 pour les équilibreurs de charge réseau ne sont prises en charge que dans la nouvelle expérience EC2. Lorsque vous utilisez l'ancienne expérience EC2, les politiques de sécurité TLS 1.3 ne peuvent pas être sélectionnées.
Elastic Load Balancing fournit les politiques de sécurité TLS 1.3 suivantes pour les Network Load Balancers :
-
ELBSecurityPolicy-TLS13-1-2-2021-06
(Recommandé) -
ELBSecurityPolicy-TLS13-1-2-Res-2021-06
-
ELBSecurityPolicy-TLS13-1-2-Ext1-2021-06
-
ELBSecurityPolicy-TLS13-1-2-Ext2-2021-06
-
ELBSecurityPolicy-TLS13-1-1-2021-06
-
ELBSecurityPolicy-TLS13-1-0-2021-06
-
ELBSecurityPolicy-TLS13-1-3-2021-06
Politiques de sécurité FIPS
La norme fédérale de traitement de l'information (FIPS) est une norme gouvernementale américaine et canadienne qui spécifie les exigences de sécurité pour les modules cryptographiques qui protègent les informations sensibles. Pour en savoir plus, consultez la norme fédérale de traitement de l'information (FIPS) 140
Toutes les politiques FIPS tirent parti du module cryptographique AWS-LC validé FIPS. Pour en savoir plus, consultez la page du module cryptographique AWS-LC sur le site du programme de validation du module
Elastic Load Balancing fournit les politiques de sécurité FIPS suivantes pour Network Load Balancer :
-
ELBSecurityPolicy-TLS13-1-3-FIPS-2023-04
-
ELBSecurityPolicy-TLS13-1-2-Res-FIPS-2023-04
-
ELBSecurityPolicy-TLS13-1-2-FIPS-2023-04
(Recommandé) -
ELBSecurityPolicy-TLS13-1-2-Ext0-FIPS-2023-04
-
ELBSecurityPolicy-TLS13-1-2-Ext1-FIPS-2023-04
-
ELBSecurityPolicy-TLS13-1-2-Ext2-FIPS-2023-04
-
ELBSecurityPolicy-TLS13-1-1-FIPS-2023-04
-
ELBSecurityPolicy-TLS13-1-0-FIPS-2023-04
Politiques FS prises en charge
Elastic Load Balancing fournit les politiques de sécurité compatibles FS (Forward Secrecy) suivantes pour les Network Load Balancers :
-
ELBSecurityPolicy-FS-1-2-Res-2020-10
-
ELBSecurityPolicy-FS-1-2-Res-2019-08
-
ELBSecurityPolicy-FS-1-2-2019-08
-
ELBSecurityPolicy-FS-1-1-2019-08
-
ELBSecurityPolicy-FS-2018-06
Politiques de sécurité TLS 1.0 - 1.2
Elastic Load Balancing fournit les politiques de sécurité TLS 1.0 à 1.2 suivantes pour les Network Load Balancers :
-
ELBSecurityPolicy-TLS-1-2-Ext-2018-06
-
ELBSecurityPolicy-TLS-1-2-2017-01
-
ELBSecurityPolicy-TLS-1-1-2017-01
-
ELBSecurityPolicy-2016-08
-
ELBSecurityPolicy-TLS-1-0-2015-04
-
ELBSecurityPolicy-2015-05
(identique àELBSecurityPolicy-2016-08
)
Protocoles et chiffrements TLS
Stratégies ALPN
Application-Layer Protocol Negotiation (ALPN) est une extension TLS qui est envoyée sur les messages de liaison Hello TLS initiaux. ALPN permet à la couche d'application de négocier les protocoles à utiliser sur une connexion sécurisée, telle que HTTP/1 et HTTP/2.
Lorsque le client lance une connexion ALPN, l'équilibreur de charge compare la liste des préférences ALPN client à sa stratégie ALPN. Si le client prend en charge un protocole de la stratégie ALPN, l'équilibreur de charge établit la connexion en fonction de la liste des préférences de la stratégie ALPN. Sinon, l'équilibreur de charge n'utilise pas ALPN.
Stratégies ALPN prises en charge
Les stratégies ALPN prises en charge sont les suivantes :
HTTP1Only
-
Négocier uniquement HTTP/1.*. La liste des préférences ALPN est http/1.1, http/1.0.
HTTP2Only
-
Négocier uniquement HTTP/2. La liste des préférences ALPN est h2.
HTTP2Optional
-
Privilégiez HTTP/1.* par rapport à HTTP/2 (ce qui peut être utile pour les tests HTTP/2). La liste des préférences ALPN est http/1.1, http/1.0, h2.
HTTP2Preferred
-
Privilégiez HTTP/2 par rapport à HTTP/1.*. La liste des préférences ALPN est h2, http/1.1, http/1.0.
None
-
Ne négociez pas ALPN. Il s’agit de l’option par défaut.
Activer les connexions ALPN
Vous pouvez activer les connexions ALPN lorsque vous créez ou modifiez un écouteur TLS. Pour plus d’informations, consultez Ajouter un écouteur et Mettre à jour la stratégie ALPN.