Concevoir et implémenter des périmètres de service

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 à grande échelle en production sur Google Cloud et qui souhaitent réduire le risque de 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 d'en tenir compte dès la conception de l'architecture. La conception de votre configuration VPC Service Controls doit rester aussi simple que possible. Nous vous recommandons d'éviter les conceptions de périmètre comportant plusieurs liaisons, projets de réseau de périmètre (ou périmètres DMZ) et 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 réduit également les frais généraux de gestion pour les équipes chargées de la création et de la maintenance du périmètre. Comme les services et les ressources réseau d'un périmètre peuvent communiquer librement avec les autorisations IAM et de contrôle du réseau nécessaires, les équipes responsables de la gestion du périmètre s'intéresseront principalement à l'accès nord-sud, c'est-à-dire l'accès depuis Internet aux ressources à l'intérieur du périmètre.

Lorsqu'une organisation utilise plusieurs petits périmètres, les équipes de gestion des périmètres doivent consacrer des ressources à la gestion du trafic est-ouest entre les périmètres d'une organisation, en plus du trafic nord-sud provenant de l'extérieur de l'organisation. Selon la taille de l'organisation et le nombre de périmètres, cette gestion peut représenter des frais généraux importants. Nous vous recommandons de superposer des contrôles de sécurité et des bonnes pratiques supplémentaires à votre périmètre, par exemple en veillant à ce que les ressources du réseau VPC n'aient 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, veillez à appliquer le principe du moindre privilège et à suivre les bonnes pratiques IAM.

Pour en savoir plus, consultez la page 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 disposer d'un périmètre pour les données non masquées à haut niveau de confiance et d'un périmètre distinct pour les données anonymisées de niveau inférieur. Cette approche permet de partager les données anonymisées avec des entités externes tout en maintenant la protection des données sensibles.

Si votre organisation souhaite respecter des normes telles que 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é.

De plus, si vous utilisez votre organisation Google Cloud pour héberger des locataires tiers indépendants, tels que des partenaires ou des clients, pensez à définir un périmètre pour chacun d'eux. Si le transfert de données entre ces locataires est considéré comme une exfiltration, nous vous recommandons de mettre en place un périmètre séparé pour chacun.

Conception de périmètres

Il est recommandé d'activer tous les services protégés au moment de la création d'un périmètre afin de réduire la complexité opérationnelle et de minimiser les vecteurs d'exfiltration de données. Le fait de laisser certaines API non protégées augmente les risques d'exfiltration. Si votre organisation décide de ne pas protéger certains services, elle doit réaliser un examen de sécurité et justifier cette décision.

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 correspondant à différentes charges de travail et composants de haut niveau, tels que des plans de contrôle, des lacs de données, des unités commerciales ou encore des étapes du cycle de vie. En plus d'organiser ces projets et composants dans des dossiers, nous vous recommandons d'évaluer lesquels doivent être inclus 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 n'utilise 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 Création de la liste d'autorisation. Toutefois, nous vous recommandons de minimiser la complexité du périmètre.

Étapes suivantes