De nombreuses organisations doivent répondre à des exigences de conformité pour limiter l'accès réseau à une liste d'API explicitement approuvée, en fonction d'exigences internes ou de l'adoption de Assured Workloads. Sur site, cette exigence est souvent traitée par les contrôles de proxy, mais, votre cloud privé virtuel (VPC) Google, vous pouvez y répondre en utilisant les règles d'administration Restreindre l'utilisation des services de ressources Cette stratégie permet à un administrateur de définir les ressources Google Cloud pouvant être créées dans leur hiérarchie de ressources. Toutefois, pour utiliser efficacement cette règle d'administration, vous devez aligner divers contrôles de mise en réseau dans votre environnement.
Ce document explique comment limiter l'accès aux API Google approuvées individuellement à l'aide du service de règles d'administration et d'autres contrôles réseau, ainsi que les problèmes liés à l'application de l'approche sur site basée sur un proxy aux services Google Cloud. Ce document est destiné aux administrateurs réseau ou aux équipes de sécurité qui souhaitent décider quelles sont les API Google Cloud qui peuvent être accessibles à partir de leurs points de terminaison du réseau VPC.
Défis liés aux proxys pour le contrôle des accès aux API Google
Dans un réseau sur site, votre entreprise peut exiger que le trafic sortant ne soit autorisé que vers des services et des domaines approuvés. Cette exigence peut être appliquée en filtrant le trafic de sortie via un proxy Web ou une passerelle d'accès sécurisé. Ce proxy intercepte tout le trafic sortant et n'autorise la sortie que vers les API explicitement approuvées.
Dans certaines entreprises, vous pouvez également être soumis à des exigences de conformité pour limiter l'accès de votre réseau VPC aux API Google Cloud approuvées. Ce contrôle de conformité est souvent observé dans les scénarios suivants :
- Une entreprise adopte Assured Workloads pour les charges de travail sensibles et les contrôles de conformité.
- Une entreprise impose des exigences de conformité internes concernant l'accès des points de terminaison du réseau sur Google Cloud aux API Google Cloud approuvées via un processus interne.
- Une entreprise souhaite migrer des charges de travail IaaS (Infrastructure as a Service) vers Google Cloud avec un minimum de refactorisation.
- Une entreprise n'a pas encore développé de contrôles pour le cloud et préfère étendre les contrôles existants à partir de l'environnement sur site.
Bien que votre entreprise puisse utiliser un proxy Web pour contrôler la sortie de son réseau sur site vers les services Web, nous ne recommandons pas cette approche pour contrôler l'accès de votre réseau VPC aux API Google Cloud. Cette approche introduit des problèmes d'évolutivité, crée un point de défaillance unique et ne résout pas les risques d'exfiltration de données à l'aide des API Google Cloud.
Nous vous recommandons d'utiliser la règle d'administration Limiter l'utilisation des services de ressources plutôt que les proxys pour autoriser de manière sélective l'accès à des API Google Cloud individuelles. Les défis liés à la création et à la gestion d'un proxy Web pour le contrôle d'accès à des API Google individuelles sont abordés dans les sections suivantes.
Plages d'adresses IP partagées utilisées par plusieurs API Google
Vous ne pouvez pas contrôler l'accès à une API Google individuelle par un proxy ou une règle de pare-feu qui filtre sur une seule adresse IP. Google utilise une plage dynamique d'adresses IP pour les domaines par défaut. Au sein de ces adresses IP, il n'existe pas de relation un à un entre une adresse IP dédiée et une API spécifique.
Domaines partagés utilisés par les API Google
Pour certaines API Google, vous ne pouvez pas contrôler l'accès au réseau en filtrant le trafic sur les domaines. La plupart des API Google sont accessibles sur des points de terminaison qui différencient des API spécifiques par chemin, et commencent par un URI commençant par www.googleapis.com. Certaines API Google utilisent également un point de terminaison avec un sous-domaine dédié. Par exemple, la documentation de référence de l'API Cloud Storage décrit les URI relatifs au point de terminaison storage.googleapis.com/storage/v1, mais vous pouvez également utiliser un URI commençant par www.googleapis.com/storage/v1 pour appelez les mêmes méthodes API.
Lorsque vous utilisez plusieurs API ne disposant que de points de terminaison sur le domaine www.googleapis.com, le proxy de sortie ne peut pas distinguer les API basées uniquement sur le domaine. Par exemple, certaines API Google Cloud telles que Deployment Manager et d'autres API Google, comme Tag Manager ou Google Play Jeux, ne sont accessibles que sur le domaine www.googleapis.com.
De plus, toutes les API Google Cloud utilisent le chiffrement TLS par défaut. Si vous souhaitez autoriser l'une de ces API, mais bloquer les autres, votre proxy devra déchiffrer la requête pour filtrer sur le chemin d'URI, ce qui augmente la complexité.
Goulots d'étranglement causés par les proxys
Si tout le trafic de votre réseau VPC vers les API Google doit passer par un proxy de sortie, celui-ci peut devenir un goulot d'étranglement. Si vous utilisez un proxy de sortie pour le trafic de votre réseau VPC vers les API Google, nous vous recommandons de créer le proxy pour la haute disponibilité afin d'éviter toute interruption de service. La maintenance et le scaling du proxy peuvent devenir complexes, car à mesure que votre organisation se développe, le proxy peut introduire un point de défaillance unique, une latence et un débit réduit. Cela peut avoir un impact particulier sur les opérations qui transfèrent d'importants volumes de données.
Risque d'exfiltration de service à service
Un proxy Web peut contrôler si une API Google est accessible depuis votre réseau VPC, mais ne résout pas les autres chemins d'exfiltration qui utilisent l'API Google. Par exemple, un employé de votre entreprise peut disposer de droits IAM légitimes pour lire des buckets Cloud Storage internes. Avec ce droit, il peut lire les données internes, puis les copier dans un bucket public. Le proxy de sortie ne peut pas limiter le trafic API vers API qui ne provient pas de votre VPC, ni contrôler la manière dont le trafic Internet atteint les points de terminaison publics des API Google Cloud.
Pour les données sensibles, un périmètre VPC Service Controls permet de limiter ce type d'exfiltration. L'application d'un périmètre VPC Service Controls permet de protéger les ressources du périmètre contre les stratégies IAM mal configurées, l'exfiltration et les identifiants compromis.
Configurer des contrôles réseau pour limiter les services non approuvés
Lorsque vous utilisez la règle d'administration "Restreindre l'utilisation des services de ressources" pour restreindre de manière efficace l'accès aux services, vous devez prendre en compte la manière dont votre réseau VPC limite le trafic de sortie et les chemins d'exfiltration. Les sections suivantes décrivent les bonnes pratiques de conception réseau pour utiliser efficacement les règles d'administration liées à la restriction de l'utilisation des services de ressources.
Configurez VPC Service Controls
Lorsque vous utilisez la règle d'administration de restriction d'utilisation des services de ressources, nous vous recommandons également de configurer VPC Service Controls. En appliquant la règle d'administration à un projet, vous limitez les services pouvant être utilisés dans ce projet, mais celle-ci n'empêche pas les services de ce projet de communiquer avec les services d'autres projets. En comparaison, VPC Service Controls vous permet de définir un périmètre empêchant la communication avec des services en dehors du périmètre.
Par exemple, si vous définissez une règle d'administration pour autoriser Compute Engine et interdire Cloud Storage dans votre projet, une VM de ce projet ne peut pas créer de bucket Cloud Storage dans le projet ni communiquer avec lui. Cependant, la VM peut envoyer des requêtes à un bucket Cloud Storage d'un autre projet. Par conséquent, l'exfiltration avec le service Cloud Storage est toujours possible. Pour bloquer la communication avec Cloud Storage ou d'autres services Google en dehors du périmètre, vous devez configurer un périmètre VPC Service Controls.
Utilisez ces contrôles ensemble pour autoriser de manière sélective les services approuvés dans votre environnement et bloquer une plage de chemins d'exfiltration vers des services non approuvés.
Supprimer des chemins d'accès à Internet
Si les ressources de votre réseau VPC peuvent communiquer directement avec Internet, il peut exister un chemin d'accès alternatif vers des API Google et d'autres services non approuvés que vous souhaitez bloquer. Par conséquent, nous vous recommandons de n'utiliser que des adresses IP internes sur vos VM et de ne pas autoriser les routes de sortie via une solution NAT ou un proxy. La règle d'administration de restriction d'utilisation des services de ressources n'atténuera pas les chemins d'exfiltration vers l'Internet public, de sorte que les services non approuvés seront toujours accessibles indirectement depuis un serveur situé en dehors de votre environnement.
Configurer un point de terminaison privé pour l'accès à l'API
Pour contrôler les points de terminaison des API de votre réseau, nous vous recommandons d'accéder aux API Google à l'aide de Private Service Connect. Lorsque vous configurez l'accès privé à Google pour autoriser des VM disposant uniquement d'une adresse IP interne à accéder aux API Google, cela inclut l'accès à toutes les API Google, y compris celles qui ne sont pas compatibles avec VPC Service Controls. ou la règle d'administration "Restreindre l'utilisation des services de ressources".
Vous pouvez limiter l'accès privé à Google aux seules API compatibles en configurant également Private Service Connect avec le groupe vpc-sc.
Par exemple, l'activation de l'accès privé à Google permet d'accéder à toutes les API Google, telles que Google Drive ou Google Maps Platform, via un chemin d'accès réseau privé. Un employé peut copier des données sur son Google Drive personnel à partir d'une instance Compute Engine à l'aide de l'API Google Drive. Vous pouvez éviter ce chemin d'exfiltration en configurant Private Service Connect avec le groupe vpc-sc pour fournir un accès au même ensemble de services compatibles avec l'adresse IP virtuelle (VIP) restreinte au point de terminaison restricted.googleapis.com. Par comparaison, un ensemble plus large d'API Google peut être accessible à l'aide de l'accès privé à Google en utilisant les domaines par défaut Google, un point de terminaison Private Service Connect configuré avec le groupe all-apis ou l'adresse IP virtuelle privée (private.googleapis.com).
Vous pouvez également configurer des routes vers restricted.googleapis.com. Vous préférerez peut-être utiliser l'adresse IP virtuelle restreinte si vous ne souhaitez pas créer de point de terminaison Private Service Connect pour chaque région et chaque réseau VPC dans votre environnement. Toutefois, nous vous recommandons d'utiliser l'approche Private Service Connect, car vous pouvez créer un point de terminaison interne à votre réseau VPC, par rapport à l'approche VIP limitée qui nécessite une route vers un point de terminaison annoncé publiquement.
Étape suivante
- Obtenez plus d'informations sur la règle d'administration Restreindre l'utilisation des services de ressources.
- Découvrez quelles API sont compatibles avec la règle d'administration "Restreindre l'utilisation des services de ressources".
- Découvrez quelles API sont compatibles avec VPC Service Controls.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.