Ce document décrit les architectures de déploiement recommandées pour VPC Service Controls. Ce document est destiné aux administrateurs réseau, aux architectes de sécurité et aux professionnels des opérations cloud qui exécutent et exploitent des déploiements en production sur Google Cloud et qui souhaitent réduire le risque liés à la perte de données sensibles.
Comme la protection de VPC Service Controls affecte les fonctionnalités des services cloud, nous vous recommandons de planifier l'activation de VPC Service Controls à l'avance et de prendre en compte VPC Service Controls lors de la conception de l'architecture. Il est important que la conception de VPC Service Controls soit aussi simple que possible. Nous vous recommandons d'éviter les conceptions de périmètre qui utilisent plusieurs liaisons, projets de réseau de périmètre ou un périmètre DMZ, ainsi que les niveaux d'accès complexes.
Utiliser un périmètre unifié commun
Un périmètre étendu unique, appelé périmètre unifié commun, offre la protection la plus efficace contre l'exfiltration de données par rapport à l'utilisation de plusieurs périmètres segmentés.
Un périmètre unifié commun présente également l'avantage de réduire les coûts de gestion pour les équipes chargées de la création et de la maintenance du périmètre. Étant donné que les services et les ressources réseau d'un périmètre peuvent communiquer librement avec les autorisations IAM et de contrôle réseau nécessaires, les équipes chargées de la gestion du périmètre s'intéressent principalement à l'accès nord-sud, c'est-à-dire à l'accès depuis Internet aux ressources situées dans le périmètre.
Lorsqu'une organisation utilise plusieurs périmètres plus petits, les équipes de gestion des périmètres doivent consacrer des ressources à la gestion du trafic est-ouest entre les périmètres de l'organisation, en plus du trafic nord-sud provenant de l'extérieur de l'organisation. En fonction de la taille de l'organisation et du nombre de périmètres, ces coûts peuvent être considérables. Nous vous recommandons d'ajouter des contrôles de sécurité et des bonnes pratiques supplémentaires à votre périmètre, par exemple en vous assurant que les ressources du réseau VPC n'ont pas de sortie Internet directe.
Les périmètres de service ne sont pas destinés à remplacer ni à réduire le besoin de contrôles IAM. Lorsque vous définissez des contrôles d'accès, nous vous recommandons de vous assurer que le principe du moindre privilège est appliqué et que les bonnes pratiques IAM sont respectées.
Pour en savoir plus, consultez la section Créer un périmètre de service.
Utiliser plusieurs périmètres dans une organisation
Certains cas d'utilisation peuvent nécessiter plusieurs périmètres pour une organisation. Par exemple, une organisation qui gère des données de santé peut souhaiter un périmètre pour les données non obscurcies de haute confiance et un périmètre distinct pour les données de niveau inférieur anonymisées afin de faciliter le partage avec des entités externes tout en protégeant les données de haute confiance.
Si votre organisation souhaite se conformer à des normes telles que la norme PCI DSS, vous pouvez créer un périmètre distinct autour de vos données réglementées.
Lorsque le partage des données est un cas d'utilisation principal pour votre organisation, envisagez d'utiliser plusieurs périmètres. Si vous produisez et partagez des données de niveau inférieur telles que des données de santé de patients anonymisées, vous pouvez utiliser un périmètre distinct pour faciliter le partage avec des entités externes. Pour en savoir plus, consultez les modèles de référence pour l'échange de données sécurisé.
En outre, si vous utilisez votre organisation Google Cloud pour héberger des locataires tiers indépendants, tels que des partenaires ou des clients, envisagez de définir un périmètre pour chaque locataire. Si vous considérez que le transfert de données de l'un de ces locataires vers un autre est d'exfiltration, nous vous recommandons de mettre en œuvre un périmètre distinct.
Conception de périmètres
Nous vous recommandons d'activer tous les services protégés lorsque vous créez un périmètre, ce qui contribue à réduire la complexité opérationnelle et à minimiser les vecteurs d'exfiltration potentiels. Étant donné que laisser les API non protégées augmente les vecteurs d'exfiltration possibles, des examens et des justifications doivent être effectués si votre organisation choisit de protéger une API et non une autre.
Tous les nouveaux projets doivent être soumis au processus d'examen et de qualification, décrit dans les sections suivantes. Incluez dans le périmètre tous les projets qui remplissent les conditions de qualification.
Assurez-vous qu'il n'existe aucun chemin d'accès à l'adresse IP virtuelle privée depuis les VPC du périmètre. Si vous autorisez une route du réseau sur private.googleapis.com, vous annulez la protection de VPC Service Controls contre l'exfiltration de données internes. Si vous devez autoriser l'accès à un service non compatible, essayez d'isoler l'utilisation de services non compatibles dans un projet distinct ou de transférer l'intégralité de la charge de travail en dehors du périmètre.
Examiner et faire certifier des projets
Une entreprise type dispose de nombreux projets qui représentent des charges de travail et des constructions de haut niveau, telles que des plans de contrôle, des lacs de données, des unités commerciales et des étapes du cycle de vie. En plus d'organiser ces projets et ces composants dans des dossiers, nous vous recommandons de déterminer s'ils doivent se trouver ou non dans un périmètre VPC Service Controls. Pour passer la certification, posez-vous les questions suivantes :
Y a-t-il un composant qui présente une dépendance forte envers un service non compatible avec VPC Service Controls ?
L'application de VPC Service Controls n'étant pas ambigu, ce type de dépendance peut ne pas fonctionner dans un périmètre. Nous vous recommandons de modifier la charge de travail de façon à isoler l'exigence concernant les services non compatibles dans un projet distinct ou de transférer la charge de travail en dehors du périmètre.
Existe-t-il un composant qui ne comporte aucune donnée sensible et qui ne consomme pas de données sensibles provenant d'autres projets ?
Si vous avez répondu oui à l'une des questions précédentes, nous vous recommandons de ne pas placer le projet dans un périmètre. Vous pouvez contourner ce problème, comme indiqué dans la section Conception de la liste d'autorisation. Toutefois, nous vous recommandons de minimiser la complexité du périmètre.
Étape suivante
- Découvrez comment créer un périmètre de service.
- Découvrez comment tester l'impact d'un périmètre à l'aide du mode simulation.
- Découvrez les règles d'entrée et de sortie qui permettent la communication entre les périmètres de service.