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 REST APIs 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 un lien TLS avec votre API ou votre 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 votre nom de domaine APIs et celui de vos noms de domaine personnalisés contre les problèmes de sécurité du réseau tels que la falsification et l'écoute 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. Utilisez ces politiques de sécurité pour garantir la rétrocompatibilité. Toute politique qui commence par SecurityPolicy_ est une politique de sécurité renforcée. Utilisez ces politiques 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é renforcée, vous devez également définir le mode d'accès aux terminaux pour une gouvernance supplémentaire. Pour de plus amples informations, veuillez consulter Mode d'accès aux terminaux.
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 TLS et les chiffrements pris en charge, consultez. Politiques de sécurité prises en charge
Pour contrôler le protocole TLS et les chiffrements utilisés par les clients pour accéder à votre API Gateway, vous pouvez utiliser les variables de $context.cipherSuite contexte $context.tlsVersion et dans vos journaux d'accès. Pour de plus amples informations, veuillez consulter Surveillance des API REST dans API Gateway.
Mode d'accès aux terminaux
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 parSecurityPolicy_. Vous le faites lorsque vous créez votre ressource ou si vous modifiez la politique de sécurité d'une stratégie existante à une stratégie améliorée.
Lorsque le mode d'accès au point de terminaison est défini surSTRICT, toutes les demandes adressées à votre API REST ou à votre nom de domaine personnalisé doivent passer les vérifications suivantes :
-
La demande doit provenir du même type de point de terminaison API Gateway que votre ressource. Cela peut provenir d'un point de terminaison régional, d'un point de terminaison optimisé pour les périphériques 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 les périphériques, API Gateway est conforme à CloudFront la protection frontale du domaine. Pour plus d'informations, consultez 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é vers une politique de sécurité renforcée et conservez le mode d'accès aux terminaux défini surBASIC. Après avoir validé votre trafic et vos journaux d'accès, définissez le mode d'accès au point de terminaison surSTRICT. Lorsque vous migrez le mode d'accès au point de terminaison de STRICT versBASIC, votre point de terminaison sera indisponible pendant environ 15 minutes au fur et à mesure que les modifications se propagent.
Vous ne devez pas définir le mode d'accès au point de terminaison sur STRICT pour certaines architectures d'applications, mais plutôt surBASIC. Le tableau suivant présente certaines architectures d'applications et 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 public personnalisé. |
Cette architecture utilise un trafic de type cross-endpoint. Nous vous recommandons de migrer versNoms de domaine personnalisés pour le privé APIs dans API Gateway. |
|
Utiliser n'importe quelle méthode pour appeler une API privée qui n'utilise pas de nom de domaine personnalisé ni de noms DNS privés. |
Cette architecture crée une discordance entre l'en-tête de l'hôte et le SNI utilisé dans le handshake TLS et ne respecte pas les restrictions de fronting CloudFront du domaine. Nous vous recommandons de migrer votre VPC pour utiliser un DNS privé. |
Utilisation du partitionnement de domaine pour distribuer du contenu sur plusieurs domaines ou sous-domaines. |
Cette architecture crée une discordance entre l'en-tête de l'hôte et le SNI utilisé dans le handshake TLS et ne respecte pas les restrictions de fronting CloudFront du domaine. Nous vous recommandons d'utiliser cet anti-modèle |
Voici les points à prendre en compte lors de 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 est défini comme
STRICTtel, vous ne pouvez pas modifier le type de point de terminaison. Pour modifier le type de point de terminaison, changez d'abord le mode d'accès au point de terminaison surBASIC. -
Une fois que vous avez changé le mode d'accès aux terminaux de
BASICàSTRICT, API Gateway applique le mode d'accès strict aux points de terminaison dans un délai de 15 minutes. -
Lorsque vous modifiez une politique de sécurité d'une stratégie commençant
SecurityPolicy_par une stratégie existante, vous devez annuler le mode d'accès au point de terminaison sur"".
Considérations
Voici quelques considérations relatives aux politiques de sécurité pour REST APIs dans API Gateway :
-
Vous pouvez importer la politique de sécurité dans un fichier de définition OpenAPI. Pour de plus amples informations, veuillez consulter x-amazon-apigateway-endpoint-mode d'accès.
-
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é de l'API pour négocier le handshake 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 l'apiStatusestUPDATINGet lorsqu'elle sera terminée, elle le seraAVAILABLE. Lorsque le statut de votre API estUPDATINGdéfini, vous pouvez toujours l'invoquer. -
API Gateway prend en charge les politiques de sécurité pour tous APIs. Toutefois, vous pouvez uniquement choisir une politique de sécurité pour REST APIs. API Gateway prend uniquement en charge la politique de
TLS_1_2sécurité pour HTTP ou WebSocket APIs. -
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, soit RSA, soit 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.
