web-dev-qa-db-fra.com

AWS API Gateway devrait empêcher l'utilisation de TLS v1

En vous référant à AWS Cloudfront Documentation , AWS API Gateway prend en charge TLS v1.0, v1.1, v1.2.

Mais je veux limiter les protocoles de chiffrement à TLS v1.1 et v1.2 pour mon API Gateway. Où est-ce que je configure ceci? Je ne vois aucune distribution cloudfront pour mon API. La page de ressources de la passerelle n'a pas d'option pour spécifier le protocole de sécurité.

Mon API est en production depuis 2 ans avec un domaine personnalisé . Avez-vous une idée de la façon dont je limite mon API aux protocoles TLS V1.1 et V1.2 uniquement dans API Gateway?

amazon-web-servicesaws-api-gatewayaws-security-group
8
suman j

Pour que l’API de la passerelle avec une distribution frontale de nuage supplémentaire fonctionne, nous devons:

  1. Depuis la console AWS, sous API Gateway, accédez à Nom de domaine personnalisé et supprimez l'entrée mappée. 
  2. Créez une nouvelle distribution cloudfront avec

Paramètres de Cloudfront

  • Nom de domaine d'origine en tant que point de terminaison de votre API Gate https://abcdfefg.execute-api.us-east-1.amazonaws.com
  • Stratégie de protocole de l'afficheur en tant que HTTPS uniquement
  • Protocoles SSL d'origine tels que TLSv1.2, TLSv1.1 (décochez TLSv1)
  • Ajoutez une entrée CNAME sous Nom de domaine alternatif pour faire référence au nom de domaine personnalisé.
  • et quelques autres valeurs par défaut Une fois les modifications ci-dessus terminées, l'accès au nom de domaine personnalisé sur https appliquera les paramètres de sécurité TLS définis dans la distribution Cloudfront.
5
suman j

Je viens de travailler intensément sur ce sujet et, grâce à de nombreux essais et erreurs, je peux documenter ce que je pense être la solution optimale actuelle à cet égard. La réponse de suman j était la meilleure solution en octobre 2017, mais elle a une limitation et AWS a également évolué depuis.

Alors, quelle est la limitation? 

Si vous utilisez Lambda avec la passerelle API et supprimez le nom de domaine personnalisé, la création manuelle d'une distribution CloudFront et l'association d'une fonction Lambda nécessitent un numéro de version Lambda spécifique. Autrement dit, il ne prend pas en charge les alias. Ceci est problématique avec CI/CD où les numéros de version peuvent changer continuellement. Cependant, les mappages de chemin de base des noms de domaine personnalisés de la passerelle API prennent en charge les alias. Il est donc préférable de continuer à les utiliser.

Alors, comment AWS a-t-il évolué? 

À compter de novembre 2017, API Gateway prend en charge la création de points de terminaison régionaux dans des noms de domaine personnalisés. Ces points de terminaison ne créent pas de distribution CloudFront, optimisant ainsi la stratégie de placer votre propre distribution CloudFront devant eux, empêchant ainsi l'utilisation de TLS v1.0.

Alors, comment puis-je tout organiser? 

Les étapes que j’avais l'habitude de faire (via la console) sont les suivantes. Notez que vous devrez peut-être modifier certains paramètres pour prendre en charge votre application particulière. Aux fins de cette documentation, supposons que votre API s'appelle api.example.com.

  1. Dans API Gateway, modifiez votre nom de domaine personnalisé, ajoutez une configuration régionale, sélectionnez votre certificat et cliquez sur Enregistrer. Remarque: pour les API régionales, vous devez utiliser un certificat ACM de la même région que l'API. Plus d'infos ici: https://docs.aws.Amazon.com/apigateway/latest/developerguide/apigateway-regional-api-custom-domain-main-home.html

  2. Copiez le nom de domaine cible du noeud final régional nouvellement créé. (Par exemple, d-abcdefg123.execute-api.us-east-1.amazonaws.com)

  3. Dans Route 53 ou votre fournisseur DNS, modifiez le mappage de votre API du nom de domaine cible Edge Optimized CloudFront vers le nom de domaine cible créé pour le point de terminaison régional (c'est-à-dire d-abcdefg123.execute-api.us-east-1.amazonaws.com ).

  4. Une fois le changement DNS propagé, modifiez le nom du domaine personnalisé et supprimez le point de terminaison Edge optimisé en cliquant sur l'icône x. Cela devrait ensuite vous permettre de créer une nouvelle distribution CloudFront avec le même CNAME de votre API sans qu'AWS ne vous bloque.

  5. Dans API Gateway, créez un nouveau nom de domaine personnalisé avec le nom de domaine = regional-api.example.com, Endpoint Configuration = Regional et sélectionnez le certificat ACM. Cliquez sur Enregistrer, puis sur Modifier et ajoutez le mappage de chemin de base conformément à votre API actuelle, puis cliquez sur Enregistrer. Copiez le nom de domaine cible du noeud final régional nouvellement créé. (Par exemple, d-xyzabcd456.execute-api.us-east-1.amazonaws.com)

  6. Dans Route 53 ou votre fournisseur DNS, créez un nouvel enregistrement CNAME mappant regional-api.example.com au nouveau nom de domaine cible du point de terminaison régional. (Par exemple, d-xyzabcd456.execute-api.us-east-1.amazonaws.com)

  7. Dans CloudFront, créez une nouvelle distribution avec les paramètres suivants:

PARAMETRES D'ORIGINE:

  Origin Domain Name = regional-api.example.com
   

  After entering the above the following hidden fields should then be displayed:   

  Origin SSL Protocols = TLSv1.2 & TLSv1.1

  Origin Protocol Policy = HTTPS Only

PARAMÈTRES DE COMPORTEMENT DU CACHE PAR DÉFAUT: (Ces valeurs sont ce dont j'avais besoin pour l'application qui appelle l'API pour fonctionner correctement) 

  Viewer Protocol Policy = Redirect HTTP to HTTPS
    

  Allowed HTTP Methods = GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE

  Cached HTTP Methods = OPTIONS

  Cache Based on Selected Request Headers = Whitelist
    

  Whitelist Headers = Authorization   


  Object Caching = Customize  

  Minimum TTL = 0

  Maximum TTL = 0

  Default TTL = 0 

  Forward Cookies = All
      

  Query String Forwarding and Caching = Forward all, cache based on all
    

  Smooth Streaming = No

  Restrict Viewer Access (Use Signed URLs or Signed Cookies) = No
    

  Compress Objects Automatically = No 
   

  Lambda Function Associations = None



RÉGLAGES DE DISTRIBUTION:

  Price Class = Use All Edge Locations
   

  AWS WAF Web ACL = None
     

  Alternate Domain Names (CNAMEs) = test-api.example.com
     

  SSL Certificate = Custom SSL Certificate (example.com)
   

  Custom SSL Client Support = Only Clients that Support Server Name Indication (SNI)
    

  Security Policy = TLSv1.1_2016 (recommended)


Versions HTTP prises en charge = HTTP/2, HTTP/1.1, HTTP/1.0

  1. En attendant la fin de la création de la distribution CloudFront (en moyenne 40 minutes), dans Route 53 ou votre fournisseur DNS, créez un nouveau mappage d’enregistrements CNAME test-api.example.com avec le nom de domaine CloudFront créé (par exemple, d123abcdefg.cloudfront.net).

  2. Une fois la création terminée, testez votre application avec test-api.example.com.

  3. Si les tests sont satisfaisants, mettez à jour les noms de domaine alternatifs (CNAME) de votre nouveau CloudFront afin qu'ils soient = api.example.com. (remarque - cela ne le fera pas vivre, le changement de DNS ci-dessous est nécessaire pour cela)

  4. Une fois la mise à jour de la distribution terminée (en moyenne 40 minutes), puis dans Route 53 ou votre fournisseur DNS, mettez à jour le mappage d'enregistrement CNAME d'api.example.com avec le nom de domaine CloudFront créé (par exemple, d123abcdefg.cloudfront.net)

  5. Si tout fonctionne correctement, vous pouvez maintenant supprimer l'enregistrement test-api.example.com de Route 53/DNS CNA et supprimer le nom de domaine personnalisé de la passerelle API api.example.com.

  6. Pour les points bonus, si vous utilisez Route 53, il est recommandé d’utiliser des alias d’enregistrement A et AAAA au lieu de CNAME pour les étapes de la Route 53 ci-dessus (ce que j’ai fait). Cela réduit légèrement les coûts, masque quelque peu la distribution CloudFront sous-jacente et active également la prise en charge IPv6.

J'espère que ça aide! :-)

2
Alistair

Vous pouvez créer une distribution de passerelle API dans votre liste de distribution CloudFront. Si votre passerelle API Origin est dotée du protocole HTTPS, vous pouvez spécifier le type de protocoles TLS à utiliser entre Cloudfront et la passerelle API. Entre spectateur/client et cloudfront, vous pouvez spécifier les protocoles et les suites TLS dans la section Général> Politique de sécurité de la configuration CloudFront. Cette configuration n'est visible que si vous utilisez un protocole SSL personnalisé avec SNI. Vous pouvez choisir entre:

  1. TLSv1
  2. TLSv1_2016
  3. TLSv1.1_2016
  4. TLSv1.2_2018
0
Faizal Sidek