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.
Politiques de sécurité pour les API REST dans API Gateway
Une politique de sécurité est une combinaison prédéfinie d’une version minimale du protocole TLS et de suites de chiffrement offertes par API Gateway. Lorsque vos clients établissent une liaison TLS vers votre API ou nom de domaine personnalisé, la politique de sécurité applique la version TLS et la suite de chiffrement acceptées par API Gateway. Les politiques de sécurité protègent vos API et vos noms de domaine personnalisés contre les problèmes de sécurité réseau tels que la falsification et l’écoute clandestine entre un client et un serveur.
API Gateway prend en charge les politiques de sécurité existantes et les politiques de sécurité améliorées. TLS_1_0et TLS_1_2 sont des politiques de sécurité héritées du passé. Utilisez ces politiques de sécurité pour des raisons de rétrocompatibilité. Toute politique commençant par SecurityPolicy_ est une politique de sécurité renforcée. Utilisez-les pour les charges de travail régulées, la gouvernance avancée ou pour utiliser la cryptographie post-quantique. Lorsque vous utilisez une politique de sécurité améliorée, vous devez également définir le mode d’accès aux points de terminaison pour une meilleure gouvernance. Pour plus d’informations, consultez Mode d’accès au point de terminaison.
Comment API Gateway applique les politiques de sécurité
L'exemple suivant montre comment API Gateway applique les politiques de sécurité en utilisant la politique de SecurityPolicy_TLS13_1_3_2025_09 sécurité comme exemple.
La politique SecurityPolicy_TLS13_1_3_2025_09 de sécurité accepte le trafic TLS 1.3 et rejette le trafic TLS 1.2 et TLS 1.0. Pour le trafic TLS 1.3, la politique de sécurité accepte les suites de chiffrement suivantes :
TLS_AES_128_GCM_SHA256TLS_AES_256_GCM_SHA384TLS_CHACHA20_POLY1305_SHA256
API Gateway n'accepte aucune autre suite de chiffrement. Par exemple, la politique de sécurité rejetterait tout trafic TLS 1.3 utilisant la suite de AES128-SHA chiffrement. Pour plus d'informations sur les versions et chiffrements TLS pris en charge, consultez. Politiques de sécurité prises en charge
Pour contrôler le protocole TLS et les chiffrements que les clients ont utilisés pour accéder à votre API Gateway, vous pouvez utiliser les variables de $context.cipherSuite contexte $context.tlsVersion et de vos journaux d'accès. Pour plus d’informations, consultez Surveillance des API REST dans API Gateway.
Mode d’accès au point de terminaison
Le mode d’accès au point de terminaison est un paramètre supplémentaire que vous devez spécifier pour toute API REST ou tout nom de domaine personnalisé utilisant une politique de sécurité améliorée commençant par SecurityPolicy_. Vous le faites lorsque vous créez votre ressource ou si vous modifiez la politique de sécurité d'une politique héritée à une politique améliorée.
Lorsque le mode d'accès aux terminaux est défini surSTRICT, toutes les demandes adressées à votre API REST ou à votre nom de domaine personnalisé doivent passer les contrôles suivants :
-
La demande doit provenir du même type de point de terminaison API Gateway que votre ressource. Il peut s’agir d’un point de terminaison régional, d’un point de terminaison optimisé pour la périphérie ou d’un point de terminaison privé.
-
Si vous utilisez un point de terminaison régional ou privé, API Gateway utilise la correspondance d'hôtes SNI. Si vous utilisez un point de terminaison optimisé pour la périphérie, API Gateway est conforme à la protection frontale CloudFront de domaine de la plateforme. Pour plus d'informations, consultez la section Domain Fronting.
Si l'une de ces conditions n'est pas remplie, API Gateway rejette la demande. Nous vous recommandons d'utiliser le mode d'accès aux STRICT terminaux lorsque cela est possible.
Pour migrer une API ou un nom de domaine existant afin d'utiliser le mode d'accès strict aux terminaux, mettez d'abord à jour votre politique de sécurité pour adopter une politique de sécurité renforcée et maintenez le mode d'accès aux terminaux défini surBASIC. Après avoir validé vos journaux de trafic et d'accès, définissez le mode d'accès des terminaux surSTRICT. Lorsque vous migrez le mode d'accès au terminal de STRICT àBASIC, votre terminal sera indisponible pendant environ 15 minutes à mesure que les modifications se propagent.
Vous ne devez pas définir le mode d'accès aux terminaux STRICT pour certaines architectures d'applications, mais plutôt définir le mode d'accès aux terminaux surBASIC. Le tableau suivant présente certaines architectures d'applications et propose une recommandation pour que votre API REST ou votre nom de domaine personnalisé puisse utiliser le mode d'accès aux STRICT terminaux.
| Architecture | Migration suggérée |
|---|---|
Utilisation d'un point de terminaison VPC pour accéder à un nom de domaine personnalisé public. |
Cette architecture utilise un trafic de type inter-terminaux. Nous vous recommandons de migrer versNoms de domaine personnalisés pour les API privées dans API Gateway. |
|
Utiliser n'importe quelle méthode pour invoquer une API privée qui n'utilise pas de nom de domaine personnalisé ni de noms DNS privés. |
Cette architecture crée une incompatibilité entre l'en-tête de l'hôte et le SNI utilisé lors de la prise de contact TLS et ne passe pas les restrictions de front CloudFront de domaine. Nous vous recommandons de migrer votre VPC pour utiliser un DNS privé. |
Utiliser le partage de domaine pour distribuer du contenu sur plusieurs domaines ou sous-domaines. |
Cette architecture crée une incompatibilité entre l'en-tête de l'hôte et le SNI utilisé lors de la prise de contact TLS et ne passe pas les restrictions de front CloudFront de domaine. Nous vous recommandons d'utiliser cet anti-modèle |
Les considérations suivantes concernent l'utilisation du mode d'accès aux terminaux :
-
Si le mode d'accès au point de terminaison d'une API ou d'un nom de domaine l'est
STRICT, vous ne pouvez pas modifier le type de point de terminaison. Pour modifier le type de point de terminaison, modifiez d'abord le mode d'accès au point de terminaison surBASIC. -
Une fois que vous avez modifié le mode d'accès aux terminaux de
BASICàSTRICT, API Gateway applique un délai de 15 minutes pour appliquer le mode d'accès strict aux terminaux. -
Lorsque vous modifiez une politique de sécurité, passant d'une politique commençant par
SecurityPolicy_à une politique héritée, vous devez désactiver le mode d'accès aux terminaux sur"".
Considérations
Les considérations suivantes concernent les politiques de sécurité pour les API REST dans API Gateway :
-
Vous pouvez importer la politique de sécurité dans un fichier de définition OpenAPI. Pour plus d’informations, consultez Politique de sécurité de x-amazon-apigateway-.
-
Votre API peut être mappée à un nom de domaine personnalisé avec une politique de sécurité différente de celle de votre API. Lorsque vous invoquez ce nom de domaine personnalisé, API Gateway utilise la politique de sécurité du domaine personnalisé pour négocier la prise de contact TLS. La désactivation du point de terminaison de votre API par défaut peut avoir une incidence sur la manière dont les appelants peuvent invoquer votre API.
-
Si vous modifiez votre politique de sécurité, la mise à jour prend environ 15 minutes. Vous pouvez surveiller l'état
apiStatusde votre API. Au fur et à mesure que votre API sera mise à jour, elle le seraUPDATINGet quand elle sera terminéeAVAILABLE.apiStatusLorsque le statut de votre API estUPDATINGdéfini, vous pouvez toujours l'invoquer. -
API Gateway prend en charge les politiques de sécurité sur toutes les API. Toutefois, vous ne pouvez choisir une politique de sécurité que pour les API REST. API Gateway prend uniquement en charge la politique de
TLS_1_2sécurité pour HTTP ou WebSocket les API. -
Vous ne pouvez pas mettre à jour la politique de sécurité d'une API de
TLS_1_0àTLS_1_2. -
Certaines politiques de sécurité prennent en charge les suites de chiffrement ECDSA et RSA. Si vous utilisez ce type de politique avec un nom de domaine personnalisé, les suites de chiffrement correspondent au type de clé de certificat fourni par le client, RSA ou ECDSA. Si vous utilisez ce type de politique avec une API REST, les suites de chiffrement correspondent aux suites de chiffrement compatibles avec les types de certificats RSA.
