Contrôler les accès à l'aide de pare-feu

Un pare-feu permet un contrôle des accès indépendant des identités pour les applications App Engine. Le pare-feu App Engine vous permet de définir jusqu'à 1 000 règles individuelles autorisant ou limitant une plage d'adresses IP et de sous-réseaux.

Pour configurer un pare-feu, vous devez définir des règles spécifiant une valeur de priorité, la plage d'adresses IP à autoriser ou à refuser, ainsi qu'une description facultative.

Pour vous assurer que vous avez configuré l'application de manière sécurisée et défini les niveaux d'accès appropriés, consultez les pages Sécurité des applications et Contrôle des accès.

Structurer des règles de pare-feu

Un pare-feu App Engine consiste en une liste numérotée de règles pouvant autoriser ou refuser l'accès à l'application depuis l'adresse IP (ou la plage d'adresses IP) spécifiée. La règle s'applique à toutes les ressources de l'application App Engine.

Les règles de pare-feu sont classées selon leur importance, que vous définissez à l'aide d'une valeur numérique dans la priorité de chaque règle. Vous devez indiquer une valeur de priorité unique pour chaque règle, car cette valeur définit l'importance de la règle par rapport aux autres règles du pare-feu. Les valeurs définies pour la priorité d'une règle varient de la plus élevée (1) à la plus faible (2147483647).

Chaque pare-feu comprend une règle default, créée automatiquement avec la priorité 2147483647, et qui s'applique à toute la plage d'adresses IP de l'application. La règle default est toujours la dernière à être évaluée, et elle s'applique à toutes les requêtes transmises via toutes les adresses IP.

Le pare-feu évalue d'abord la règle ayant la priorité la plus élevée. Toutes les autres règles du pare-feu sont évaluées dans l'ordre jusqu'à ce que l'une d'elles corresponde à la plage d'adresses IP de la requête. Lorsqu'une règle correspondante est trouvée, la connexion est autorisée ou refusée. Toutes les règles restantes du pare-feu sont alors ignorées. Si aucune des règles définies manuellement dans le pare-feu ne correspond à la requête, la règle default est évaluée.

Par exemple, si vous créez une règle avec la priorité 1, celle-ci est toujours évaluée en premier. Si une requête entrante correspond à la règle de priorité 1, seule cette règle est évaluée. Toutes les autres règles du pare-feu sont ignorées, y compris la règle default.

L'exemple de pare-feu ci-dessous montre comment la priorité d'une règle peut modifier le comportement du pare-feu.

Avant de commencer

Afin de créer un pare-feu pour l'application, vous devez disposer de l'un des rôles IAM App Engine ci-dessous. Ils vous attribuent les droits nécessaires pour créer ou modifier des règles de pare-feu.

  • Administrateur App Engine
  • Éditeur
  • Propriétaire

Si vous souhaitez utiliser l'outil gcloud ou l'API Admin, vous devez d'abord installer et configurer les outils ci-dessous.

Empêcher l'accès au contenu mis en cache

Le pare-feu App Engine repose sur des mécanismes qui mettent en cache le contenu (tels que des serveurs proxy et des navigateurs Web). Lorsque du contenu est mis en cache, il est diffusé publiquement à partir de l'URL concernée jusqu'à son expiration. Il est possible d'y accéder même après la création d'autres règles de pare-feu.

Le délai d'expiration par défaut du contenu mis en cache est de 10 minutes. Pour en savoir plus sur la configuration du délai d'expiration, consultez la section Expiration du cache statique.

Pour empêcher la mise en cache du contenu, employez les en-têtes de réponse HTTP Cache-Control et Expires. Pour en savoir plus sur ces en-têtes HTTP, y compris sur le contrôle de la mise en cache, consultez la page Éviter la mise en cache.

Pour le contenu statique, vous pouvez configurer l'application d'environnement standard afin de définir les en-têtes de réponse HTTP. Pour en savoir plus sur la configuration des en-têtes de réponse HTTP dans le fichier de configuration de l'application, consultez les pages Mode de traitement des requêtes et la documentation de référence sur app.yaml.

Autoriser les requêtes provenant des services

Lorsque vous créez des règles, tenez compte des points suivants :

  • Par défaut, une requête ne correspondant à aucune règle est autorisée à accéder à l'application. Si vous souhaitez bloquer toutes les requêtes qui ne correspondent pas à une règle spécifique, vous devez définir la règle default sur deny.
  • Le pare-feu autorise les files d'attente de tâches et le trafic Cron, même si la règle default est définie sur deny.
  • Pour contrôler l'accès de requêtes provenant d'autres applications ou services App Engine, vous devrez peut-être créer des règles permettant de prendre en compte les adresses IP utilisées pour la communication entre les services. Si l'application communique avec d'autres applications ou services dans App Engine, vous devez déterminer comment les requêtes provenant des adresses IP ci-dessous doivent être gérées.

    • Requêtes du service de récupération d'URL : 0.1.0.40
      • Requêtes reçues dans l'environnement standard : 0.1.0.40
      • Requêtes reçues dans l'environnement flexible : 0.1.0.40 et 10.0.0.1
    • Requêtes du service Blobstore ou de Cloud Storage : 0.1.0.30
    • Requêtes reçues uniquement dans l'environnement standard :
      • Requêtes de déploiement d'applications : 10.1.0.41

    Exemple

    L'application dispose d'un service de backend s'exécutant dans l'environnement standard (backend_std) et utilisant le service de récupération d'URL pour communiquer avec l'environnement flexible (backend_flex).

    Pour autoriser les requêtes, vous devez créer deux règles de pare-feu :

    • 0.1.0.40 qui autorise backend_flex à recevoir les requêtes de récupération d'URL de backend_std ;
    • 10.0.0.1 qui autorise la communication entre les services pour les requêtes de récupération d'URL dans backend_flex.

Créer des règles de pare-feu

Utilisez l'une des méthodes suivantes pour créer une règle de pare-feu. Répétez ces étapes pour chaque règle supplémentaire.

Console

Utilisez la page "Règles de pare-feu" de la console GCP pour créer une règle de pare-feu.

  1. Accédez à la page "Créer une règle de pare-feu" dans la console GCP :

    Accéder à la page "Créer une règle de pare-feu"

  2. Saisissez les détails de la règle. Pour ce faire, procédez comme suit :

    1. Dans Priorité, indiquez un nombre entier pour spécifier l'importance relative de la règle et définir l'ordre selon lequel elle doit être évaluée.

      Les valeurs valides sont comprises entre 1 et 2147483646. La priorité 1 correspond à la première règle évaluée. La priorité 2147483647 correspond à la dernière règle évaluée. Elle est réservée à la règle "default" (par défaut).

    2. Dans Action en cas de correspondance, indiquez si vous souhaitez autoriser ou refuser l'accès des requêtes correspondant à la règle. Les règles définies sur allow transfèrent la requête vers l'application. Celles définies sur deny répondent aux requêtes en renvoyant l'erreur 403 Forbidden.
    3. Dans Plage d'adresses IP, définissez la plage d'adresses IP qui s'applique à la règle. Celle-ci doit respecter le format CIDR, et peut inclure des masques de sous-réseau. Elle est par ailleurs compatible avec les protocoles IPv4 et IPv6.
    4. Facultatif : Dans Description, ajoutez une description de la règle comportant 100 caractères au maximum.
  3. Cliquez sur Enregistrer pour créer la règle.
  4. Testez la règle pour vous assurer que la priorité et l'action engendrent le comportement attendu. Pour ce faire, procédez comme suit :
    1. Cliquez sur Tester une adresse IP.
    2. Saisissez l'adresse IP que vous souhaitez valider, puis cliquez sur Tester pour vérifier que la règle correspondante est correctement évaluée.
gcloud

Exécutez les commandes gcloud app firewall-rules suivantes pour créer une règle de pare-feu :

  1. Exécutez la commande suivante pour créer une règle :

    gcloud app firewall-rules create PRIORITY --action ALLOW_OR_DENY --source-range IP_RANGE --description DESCRIPTION
    où :
    • PRIORITY est un nombre entier compris entre 1 et 2147483646 qui définit l'importance de la règle et l'ordre dans lequel elle sera évaluée. La priorité 1 correspond à la première règle évaluée. La priorité 2147483647 correspond à la dernière règle évaluée. Elle est réservée à la règle "default" (par défaut).
    • ALLOW_OR_DENY indique s'il faut autoriser ou refuser l'accès des requêtes correspondant à la règle. Les valeurs valides sont allow ou deny. Les règles définies sur allow transfèrent la requête vers l'application. Celles définies sur deny répondent aux requêtes en renvoyant l'erreur 403 Forbidden.
    • IP_RANGE définit la plage d'adresses IP appliquée à la règle. Elle doit respecter le format CIDR, et peut inclure des masques de sous-réseau. Elle est par ailleurs compatible avec les protocoles IPv4 et IPv6.
    • DESCRIPTION est une description facultative de la règle comportant 100 caractères au maximum.
  2. Exécutez la commande suivante pour tester la règle, et pour vérifier que la priorité et l'action engendrent le comportement attendu :
    gcloud app firewall-rules test-ip IP_ADDRESS
    IP_ADDRESS est l'adresse IP que vous souhaitez tester sur le pare-feu.
  3. Exécutez la commande suivante pour afficher la liste des règles existantes :
    gcloud app firewall-rules list
  4. Exécutez la commande suivante pour supprimer une règle existante :
    gcloud app firewall-rules delete PRIORITY
    PRIORITY correspond à la valeur de priorité de la règle à supprimer.
Exemples :
Utilisez les exemples ci-dessous pour créer le pare-feu :
  • Ajoutez une règle qui autorise un masque de sous-réseau et une adresse IPv6, puis testez-la pour vérifier qu'elle est évaluée avant les autres règles :

    gcloud app firewall-rules create 123 --source-range fe80::3636:3bff:fecc:8778/128 --action allow
    gcloud app firewall-rules test-ip fe80::3636:3bff:fecc:8778
  • Ajoutez une règle pour refuser un masque de sous-réseau et une adresse IPv4, puis testez cette règle pour vérifier qu'elle est correctement évaluée :

    gcloud app firewall-rules create 123456 --source-range "74.125.0.0/16" --action deny
    gcloud app firewall-rules test-ip 74.125.0.8
  • Mettez à jour, puis testez la règle par défaut pour vérifier qu'elle bloque toutes les adresses IP qui ne correspondent à aucune autre règle :

    gcloud app firewall-rules update default --action deny
    gcloud app firewall-rules test-ip 123.456.7.89
API

Pour créer par programmation des règles de pare-feu pour l'application App Engine, vous pouvez exécuter les méthodes apps.firewall.ingressRules dans l'API Admin.

Pour tester une règle de pare-feu, et vérifier que la priorité et l'action engendrent le comportement attendu, vous pouvez exécuter la méthode apps.firewall.ingressRules.list, puis indiquer l'adresse IP à tester dans le paramètre matchingAddress.

Exemple de pare-feu

Dans cet exemple, une entreprise a configuré un pare-feu pour permettre à son équipe d'ingénierie et au réseau d'entreprise interne d'accéder à son application en cours de développement. Elle a créé des règles de pare-feu avec de grands écarts entre chaque priorité afin de pouvoir ajouter des règles par la suite.

Priorité Action Plage d'adresses IP Description
1 000 Refuser 192.0.2.1 Empêche un pirate d'accéder à l'application dans le cadre d'une attaque par déni de service (DoS, Denial of Service).
2 000 Autoriser 198.51.100.2 Autorise un ingénieur du bureau satellite à accéder à l'application.
3 000 Refuser 198.51.100.0/24 Empêche l'accès à l'application depuis les bâtiments qui n'abritent pas de services d'ingénierie.
5 000 Autoriser 203.0.113.0/24 Autorise le réseau du bâtiment principal à accéder à l'application.
2147483647 Refuser * Réalise l'action par défaut.

Une fois le pare-feu créé, supposez que les requêtes ci-dessous soient adressées à l'exemple d'application. Notez alors la réponse de l'application :

  • La requête provenant de l'adresse 198.51.100.2 correspond à la règle de priorité 2 000. Elle est autorisée.
  • La requête provenant de l'adresse 198.51.100.100 correspond à la règle de priorité 3 000 est refusée.
  • La requête provenant de l'adresse 203.0.113.54 correspond à la règle de priorité 5 000. Elle est autorisée.
  • La requête provenant de l'adresse 45.123.35.242 correspond à la règle par défaut. Elle est refusée.

Résoudre les problèmes liés aux règles en conflit

Supposons par exemple que vous échangiez deux des priorités définies dans le pare-feu de l'entreprise. Si vous échangez les règles correspondant aux priorités 2 000 et 3 000, vous pouvez observer un comportement inattendu.

Priorité Action Plage d'adresses IP Description
1 000 Refuser 192.0.2.1 Empêche un pirate d'accéder à l'application dans le cadre d'une attaque par déni de service (DoS, Denial of Service).
2 000 Refuser 198.51.100.0/24 Empêche l'accès à l'application depuis les bâtiments qui n'abritent pas de services d'ingénierie.
3 000 Autoriser 198.51.100.2 Autorise un ingénieur du bureau satellite à accéder à l'application.
5 000 Autoriser 203.0.113.0/24 Autorise le réseau du bâtiment principal à accéder à l'application.
2147483647 Refuser * Réalise l'action par défaut.

L'ingénieur du bureau satellite ne pourra pas accéder à l'application de l'entreprise, car la nouvelle priorité de la règle signifie qu'elle ne sera jamais évaluée. L'adresse IP 198.51.100.2 de l'ingénieur est mise en correspondance avec la règle qui refuse l'accès à tous les utilisateurs non-ingénieurs situés dans la plage d'adresses IP 198.51.100.0/24, avant la règle qui l'autorise à accéder à l'application.

Pour résoudre ce problème, vous devez définir la priorité de la règle qui autorise l'accès de l'adresse 198.51.100.2 de sorte qu'elle soit supérieure à la règle qui refuse l'accès de la plage d'adresses IP 198.51.100.0/24.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Environnement standard App Engine pour Python