Python 3.9 est désormais disponible pour l'ensemble des utilisateurs.

Présentation de la sécurité des applications

ID de la région

Le REGION_ID est un code abrégé que Google attribue en fonction de la région que vous sélectionnez lors de la création de votre application. Le code ne correspond pas à un pays ou une province, même si certains ID de région peuvent ressembler aux codes de pays et de province couramment utilisés. L'ajout de REGION_ID.r dans les URL App Engine est facultatif pour les applications existantes. Il sera bientôt obligatoire pour toutes les applications nouvelles.

Pour assurer une transition en douceur, nous mettons lentement à jour App Engine afin d'utiliser les ID de région. Si nous n'avons pas encore mis à jour votre projet Google Cloud, vous ne verrez pas d'ID de région pour votre application. Étant donné que l'ID est facultatif pour les applications existantes, vous n'avez pas besoin de mettre à jour les URL ni d'effectuer d'autres modifications une fois l'ID de région disponible pour vos applications existantes.

En savoir plus sur les ID de région

La sécurité est une fonctionnalité essentielle de Google Cloud, mais vous devez tout de même prendre des mesures pour protéger votre application App Engine et identifier les failles.

Utilisez les fonctionnalités suivantes pour assurer la sécurité de votre application App Engine. Pour en savoir plus sur le modèle de sécurité Google et sur la procédure à suivre pour sécuriser vos projets Cloud, consultez la page Sécurité sur Google Cloud Platform.

Requêtes HTTPS

Accédez en toute sécurité à votre application App Engine à l'aide des requêtes HTTPS. Selon la configuration de votre application, vous disposez des options suivantes :

Domaines appspot.com
  • Utilisez le préfixe d'URL https pour envoyer une requête HTTPS au service default de votre projet Cloud. Exemple :
    https://PROJECT_ID.REGION_ID.r.appspot.com
  • Pour cibler des ressources spécifiques dans votre application App Engine, séparez chaque ressource à cibler à l'aide de la syntaxe -dot-. Exemple :
    https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

  • Pour convertir une URL HTTP en URL HTTPS, remplacez les points entre chaque ressource par -dot-. Exemple :
    http://SERVICE_ID.PROJECT_ID.REGION_ID.r.appspot.com
    https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com

Pour en savoir plus sur les URL HTTPS et le ciblage des ressources, consultez la page Mode de routage des requêtes.

Domaines personnalisés

Pour envoyer des requêtes HTTPS avec votre domaine personnalisé, vous pouvez vous servir des certificats SSL gérés provisionnés par App Engine. Pour en savoir plus, consultez la page Sécuriser des domaines personnalisés avec SSL.

Gestionnaires d'application

Pour forcer HTTPS au niveau de vos gestionnaires d'application, spécifiez l'élément secure: always pour chaque gestionnaire dans votre fichier app.yaml. Exemple :

handlers:
- url: /.*
  script: auto
  secure: always
  redirect_http_response_code: 301

L'utilisation de secure: always redirige tout le trafic HTTP vers une URL HTTPS ayant le même chemin d'accès. Consultez la documentation de référence sur la configuration du fichier app.yaml pour obtenir plus d'informations.

Contrôle des accès

Dans chaque projet Cloud, configurez le contrôle des accès pour déterminer qui peut accéder aux services du projet, y compris à App Engine. Vous pouvez attribuer des rôles différents à des comptes distincts pour vous assurer que chaque compte ne dispose que des autorisations nécessaires pour gérer votre application. Pour plus d'informations, consultez la section Configurer le contrôle des accès.

Pare-feu App Engine

Le pare-feu App Engine vous permet de contrôler l'accès à votre application App Engine via un ensemble de règles qui autorisent ou refusent les requêtes provenant des plages d'adresses IP spécifiées. Le trafic et la bande passante bloqués par le pare-feu ne vous sont pas facturés. Vous pouvez créer un pare-feu pour les raisons suivantes :

N'autoriser que le trafic provenant d'un réseau spécifique
Vous pouvez vous assurer que seule une plage d'adresses IP issue de réseaux spécifiques peut accéder à votre application. Par exemple, vous avez la possibilité de créer des règles n'autorisant que la plage d'adresses IP du réseau privé de votre entreprise pendant la phase de test de votre application. Vous pouvez ensuite créer et modifier les règles de pare-feu pour contrôler le champ d'accès tout au long du processus de publication. Seules certaines organisations, au sein de votre entreprise ou en externe, pourront ainsi accéder à l'application à mesure qu'elle est rendue publique.
N'autoriser que le trafic provenant d'un service spécifique
Assurez-vous que l'ensemble du trafic vers l'application App Engine est d'abord acheminé par le biais d'un serveur proxy via un service spécifique. Par exemple, si vous utilisez un pare-feu d'application Web (WAF, Web Application Firewall) tiers en guise de proxy pour les requêtes dirigées vers votre application, vous pouvez créer des règles de pare-feu pour refuser toutes les requêtes, à l'exception de celles transmises depuis votre WAF.
Bloquer les adresses IP abusives
Bien que Google Cloud dispose de nombreux mécanismes pour empêcher les attaques, vous pouvez vous servir du pare-feu App Engine pour bloquer le trafic acheminé vers l'application en provenance d'adresses IP utilisées à des fins malveillantes, ou pour protéger l'application contre les attaques par déni de service et d'autres formes similaires d'abus. Vous pouvez ajouter des adresses ou des sous-réseaux IP à une liste de blocage, de sorte à ce que les requêtes acheminées à partir de ces adresses et sous-réseaux soient refusées avant d'atteindre l'application App Engine.

Pour en savoir plus sur la création des règles et la configuration d'un pare-feu, consultez la page Contrôler l'accès aux applications à l'aide d'un pare-feu.

Contrôles d'entrée

Par défaut, votre application App Engine reçoit toutes les requêtes HTTP envoyées à son URL appspot ou au domaine personnalisé que vous avez configuré pour elle.

Vous pouvez utiliser des contrôles d'entrée réseau pour limiter le trafic de sorte que votre application ne reçoive que les requêtes HTTP provenant de sources spécifiques :

  • Toutes (par défaut) : votre application reçoit l'ensemble du trafic, y compris les requêtes directes envoyées depuis Internet.

  • Interne et Cloud Load Balancing : votre application ne reçoit que les requêtes acheminées via Cloud Load Balancing ou envoyées depuis des réseaux VPC dans le même projet. Toutes les autres requêtes sont refusées avec une erreur 403.

  • Interne uniquement : votre application ne reçoit que les requêtes envoyées depuis des réseaux VPC dans le même projet. Toutes les autres requêtes sont refusées avec une erreur 403.

Afficher les paramètres d'entrée

Console

  1. Accédez à la page "Services App Engine".

    Accéder à la page Services

  2. Recherchez la colonne Ingress. Pour chaque service, la valeur de cette colonne affiche le paramètre d'entrée Tout (par défaut), Interne + Équilibrage de charge ou Interne.

gcloud

Pour afficher le paramètre d'entrée d'un service à l'aide de l'outil gcloud :

gcloud app services describe SERVICE

Remplacez SERVICE par le nom du service.

Par exemple, pour afficher les paramètres d'entrée et d'autres informations pour le service par défaut, exécutez la commande suivante :

gcloud app services describe default

Modifier les paramètres d'entrée

Console

  1. Accédez à la page "Services App Engine".

    Accéder à la page Services

  2. Sélectionnez le service que vous souhaitez modifier.

  3. Cliquez sur Modifier le paramètre d'entrée.

  4. Sélectionnez le paramètre d'entrée souhaité dans le menu, puis cliquez sur Enregistrer.

gcloud

Pour mettre à jour le paramètre d'entrée d'un service à l'aide de l'outil gcloud :

gcloud app services update SERVICE --ingress=INGRESS

Remplacez :

  • SERVICE : le nom de votre service.
  • INGRESS : le contrôle d'entrée que vous souhaitez appliquer. Spécifiez l'un des contrôles suivants : all, internal-only ou internal-and-cloud-load-balancing.

Exemple :

  • Pour mettre à jour le service par défaut d'une application App Engine afin de n'accepter que le trafic provenant de Cloud Load Balancing et des réseaux VPC appartenant au même projet :

    gcloud app services update default --ingress=internal-and-cloud-load-balancing
  • Pour mettre à jour un service nommé "internal-requests" afin de n'accepter que le trafic provenant des réseaux VPC appartenant au même projet :

    gcloud app services update internal-requests --ingress=internal-only

Paramètres de sortie

Si vous utilisez l'accès au VPC sans serveur, vous pouvez spécifier le paramètre de sortie de votre service App Engine.

Par défaut, seules les requêtes adressées aux adresses IP internes et aux noms DNS internes sont acheminées via un connecteur d'accès au VPC sans serveur. Vous pouvez spécifier le paramètre de sortie de votre service dans votre fichier app.yaml.

Pour configurer le comportement de sortie de votre service App Engine, procédez comme suit :

  1. Ajoutez l'attribut egress_setting au champ vpc_access_connector du fichier app.yaml de votre service :

    vpc_access_connector:
      name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
      egress_setting: EGRESS_SETTING
    

    Remplacez :

    • PROJECT_ID par votre ID de projet Cloud.
    • REGION par la région dans laquelle se trouve le connecteur.
    • CONNECTOR_NAME par le nom de votre connecteur.
    • EGRESS_SETTING par l'un des éléments suivants :
      • private-ranges-only (valeur par défaut). Seules les requêtes adressées aux plages d'adresses IP RFC 1918 et RFC 6598 ou aux noms DNS internes sont acheminées vers votre réseau VPC. Toutes les autres requêtes sont acheminées directement vers Internet.
      • all-traffic Toutes les requêtes sortantes provenant de votre service sont acheminées vers votre réseau VPC. Les requêtes sont ensuite soumises aux règles de pare-feu, de DNS et de routage de votre réseau VPC. Notez que le routage de toutes les requêtes sortantes vers votre réseau VPC augmente la quantité de trafic de sortie gérée par le connecteur d'accès au VPC sans serveur et peut entraîner des frais.
  2. Déployez le service :

    gcloud app deploy
    

Security Scanner

Le Web Security Scanner de Google Cloud détecte les failles en explorant votre application App Engine, en suivant tous les liens associés à vos URL de démarrage, et en tentant de tester un maximum d'entrées utilisateur et de gestionnaires d'événements.

Pour pouvoir utiliser Security Scanner, vous devez être le propriétaire du projet Cloud. Pour en savoir plus sur l'attribution de rôles, consultez la page Configurer le contrôle des accès.

Vous pouvez exécuter des analyses de sécurité à partir de Google Cloud Console pour identifier les failles de sécurité dans votre application App Engine. Pour en savoir plus sur l'exécution de Security Scanner, consultez le guide de démarrage rapide de Security Scanner.