Configurer des règles d'autorisation pour Secure Web Proxy

Aperçu

Ce produit ou cette fonctionnalité sont soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Cette page explique comment configurer des règles d'autorisation pour Secure Web Proxy.

Avant de commencer

• Consultez les pages Présentation du proxy Web sécurisé et Présentation des règles d'autorisation.

• Activez les API suivantes :

  • API de sécurité réseau
  • API de services réseau
  • API Certificate Manager

• Assurez-vous de disposer des rôles et autorisations appropriés.

• Vous devez avoir déployé une instance de Secure Web Proxy active et l'avoir associée à un GatewaySecurityPolicy. Pour en savoir plus, consultez Déployer une instance Secure Web Proxy.

• Pour configurer des règles d'autorisation de Secure Web Proxy, vous devez activer une règle d'inspection TLS.

Créer une règle d'autorisation

Cette section explique comment créer différents types de règles d'autorisation associées à une instance de Secure Web Proxy.

Pour créer une règle d'autorisation pour Secure Web Proxy, procédez comme suit :

• Configurez un fichier YAML qui définit la cible et les règles.
• Importez le fichier à l'aide de la commande gcloud network-security authz-policies import.

Règle d'autorisation basée sur l'identité mTLS

Secure Web Proxy permet d'appliquer des règles de sécurité basées sur des identités dérivées de certificats TLS mutuels (mTLS). L'application de règles basées sur ces identités est particulièrement utile dans les environnements "zéro confiance", où le trafic entre les clients et le proxy est sécurisé par mTLS. Pour en savoir plus, consultez Règle d'autorisation basée sur les principaux.

L'exemple suivant montre une règle d'autorisation pour une instance Secure Web Proxy nommée swp1. Cet exemple suppose que le trafic vers le proxy utilise le protocole HTTPS.

La stratégie avec le profil REQUEST_AUTHZ exige que tout le trafic vers example.com/mcp nécessite une authentification mTLS à partir d'un principal spécifique avant d'être autorisé à transiter. La règle refuse également tout le trafic sortant qui n'est pas destiné à example.com/mcp.

1. Créez le fichier YAML de règle d'autorisation.

   L'exemple suivant crée un fichier authz-policy.yaml. La règle autorise le trafic vers l'hôte et le chemin d'accès spécifiés uniquement si le client présente un certificat correspondant au compte principal SPIFFE ID défini.

   $ cat >authz-policy.yaml <<EOF
   name: test-authz-policy-mtls
   target:
     resources:
     - "projects/ PROJECT_ID /locations/ LOCATION /gateways/swp1"
   policyProfile: REQUEST_AUTHZ
   httpRules:
   - to:
     operations:
     - hosts:
         - exact: "example.com"
       paths:
         - exact: "/mcp"
     from:
       sources:
       - principals:
         - principalSelector: CLIENT_CERT_URI_SAN
           principal:
             exact: "spiffe:// PROJECT_ID .global.123.workload.id.goog/ns/ns1/sa/hellomcp"
   action: ALLOW
   EOF
   

   Remplacez les éléments suivants :

   • PROJECT_ID : ID de votre projet Google Cloud
   • LOCATION : région de votre instance Secure Web Proxy

2. Créez une règle d'autorisation et importez le fichier YAML à l'aide de la commande gcloud network-security authz-policies import.

   gcloud beta network-security authz-policies import my-authz-policy-allow
       --source=authz-policy.yaml
       --location= LOCATION 
   

   Remplacez LOCATION par la région de votre instance Secure Web Proxy.

Règle d'autorisation basée sur des comptes de service ou des tags

Vous pouvez appliquer une stratégie d'autorisation basée sur des comptes de service ou des tags associés à différentes ressources Google Cloud .

Cet exemple suppose que vous avez effectué les opérations suivantes :

• Vous avez créé un compte de service et l'avez associé à une ressource Google Cloud.

• Vous avez créé un tag et l'avez associé à une ressource Google Cloud en tant que paire clé/valeur. Lorsque vous créez un tag, définissez son indicateur --purpose sur GCE_FIREWALL. Les règles d'autorisation nécessitent l'objectif GCE_FIREWALL pour appliquer le tag.

Compte de service

1. Créez un fichier YAML de règle d'autorisation pour autoriser certaines requêtes.

   L'exemple suivant crée un fichier authz-policy.yaml pour l'instance Secure Web Proxy nommée swp1. La règle est configurée pour autoriser les requêtes d'une instance de machine virtuelle (VM) Compute Engine avec le compte de service [e-mail] à atteindre le chemin d'accès example1.com/url1.

   $ cat >authz-policy.yaml <<EOF
   name: my-authz-policy-allow
   target:
       resources:
       - "projects/PROJECT_ID/locations/ LOCATION /gateways/swp1"
   policyProfile: REQUEST_AUTHZ
   httpRules:
   - from:
       sources:
           - resources:
               - iamServiceAccount:
                   exact: "[e-mail]"
     to:
       operations:
       - hosts:
           - exact: "example1.com"
       paths:
       - prefix: "/url1"
   action: ALLOW
   EOF
   

   Remplacez les éléments suivants :

   • PROJECT_ID : ID de votre projet Google Cloud
   • LOCATION : région de votre instance Secure Web Proxy

2. Créez une règle d'autorisation et importez le fichier YAML à l'aide de la commande gcloud network-security authz-policies import.

   L'exemple de commande suivant montre comment importer le fichier de règles créé précédemment et créer une règle d'autorisation :

   gcloud network-security authz-policies import my-authz-policy-allow
   
       --source=authz-policy.yaml
       --location= LOCATION 
   

   Remplacez LOCATION par la région de votre instance Secure Web Proxy.

Tag

1. Créez un fichier YAML de règle d'autorisation pour autoriser certaines requêtes.

   L'exemple suivant crée un fichier authz-policy-tag.yaml pour l'instance Secure Web Proxy nommée swp1. Cette règle n'autorise que les requêtes provenant d'une ressource Google Clouddont la valeur de tag est TAG_VALUE_PERMANENT_ID à accéder au chemin de l'URL example1.com/url1.

   $ cat >authz-policy-tag.yaml <<EOF
   name: my-authz-policy-tag-allow
   target:
       resources:
       - "projects/PROJECT_ID/locations/ LOCATION /gateways/ GATEWAY_NAME "
   policyProfile: REQUEST_AUTHZ
   httpRules:
   - from:
       sources:
       - resources:
           - tagValueIdSet:
               ids: ["TAG_VALUE_PERMANENT_ID"]
     to:
       operations:
       - hosts:
           - exact: "example1.com"
           paths:
           - exact: "/url1"
   action: ALLOW
   EOF
   

   Remplacez les éléments suivants :

   • PROJECT_ID : ID de votre projet Google Cloud
   • LOCATION : région de votre instance Secure Web Proxy
   • GATEWAY_NAME : nom de votre passerelle Secure Web Proxy
   • TAG_VALUE_PERMANENT_ID : ID permanent d'une valeur de tag, par exemple tagValues/123456789012

2. Créez une règle d'autorisation et importez le fichier YAML à l'aide de la commande gcloud network-security authz-policies import.

   L'exemple de commande suivant importe le fichier de règles créé précédemment et crée une règle d'autorisation dans la région Google Cloud spécifiée :

   gcloud network-security authz-policies import my-authz-policy-tag-allow
       --source=authz-policy-tag.yaml
       --location= LOCATION 
   

   Remplacez LOCATION par la région de votre instance Secure Web Proxy.

Règle d'autorisation permettant de déléguer les décisions d'autorisation

Pour les décisions d'autorisation complexes qui ne peuvent pas être exprimées à l'aide des règles ALLOW ou DENY standards, vous pouvez créer une règle d'autorisation avec une action CUSTOM. Vous pouvez ensuite déléguer vos décisions d'autorisation aux extensions d'autorisation (extensions de service).

Important : Secure Web Proxy n'accepte que les extensions d'autorisation qui utilisent un nom de domaine complet.

Lorsque vous configurez une règle avec une action CUSTOM, Secure Web Proxy décharge les métadonnées ou la charge utile de la requête sur Service Extensions. En fonction de la réponse de Service Extensions, le proxy autorise ou refuse le trafic.

Secure Web Proxy est compatible avec les types de délégations suivants :

• Déléguer les décisions d'autorisation des requêtes aux extensions de service : vous pouvez utiliser une règle d'autorisation configurée avec une action CUSTOM et un profil REQUEST_AUTHZ pour déléguer les décisions en fonction des métadonnées et des en-têtes des requêtes. Dans ce mode, la décision d'accès est déléguée à une extension d'autorisation. Vous pouvez utiliser ce mode pour vérifier les identités et les autorisations.

• Déléguer les décisions d'autorisation de contenu aux extensions de service : vous pouvez utiliser une règle d'autorisation avec une action CUSTOM et un profil CONTENT_AUTHZ pour déléguer les décisions à une extension d'autorisation en fonction de la charge utile de données réelle de la requête. Ce mode vous permet d'activer l'inspection approfondie du contenu et l'application de la sécurité. Il vous permet de rechercher des informations sensibles ou des schémas malveillants en s'intégrant à des services tels que Model Armor.

Limites

Lorsque vous implémentez des règles d'autorisation pour Secure Web Proxy, les limites suivantes s'appliquent :

• Contraintes de cible et de connectivité : les extensions d'autorisation pour Secure Web Proxy ne sont pas compatibles avec Identity-Aware Proxy (IAP) en tant que cible directe.

• Conflit et compatibilité des règles : si vous disposez d'une stratégie de sécurité de passerelle avec des règles de sécurité existantes, vous n'avez pas besoin de les supprimer. Secure Web Proxy ignore ces règles lorsque vous appliquez une règle d'autorisation à votre instance.

• Exigences concernant le protocole et l'inspection : pour configurer des règles d'autorisation de Secure Web Proxy, vous devez activer l'inspection TLS.

Étapes suivantes

• Utiliser l'authentification mTLS de l'interface avec le proxy Web sécurisé