Concevoir et concevoir des périmètres de service

Ce document décrit les architectures de déploiement de VPC Service Controls recommandées. Ce document s'adresse 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 atténuer le risque de perte de données sensibles.

Étant donné que la protection 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 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 de concevoir des périmètres qui utilisent plusieurs liaisons, projets de réseau de périmètre ou périmètre de la DMZ, ainsi que des 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 offre également l'avantage de réduire les frais 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 responsables de la gestion du périmètre s'occupent principalement de l'accès nord-sud, c'est-à-dire l'accès depuis Internet aux ressources situées à l'intérieur du périmètre.

Lorsqu'une entreprise 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 surcharge peut être considérable. Nous vous recommandons d'appliquer à votre périmètre des contrôles de sécurité et des bonnes pratiques supplémentaires, par exemple en vous assurant que les ressources du réseau VPC ne disposent 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 respecté et que les bonnes pratiques IAM sont appliqué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 entreprise qui gère des données de santé peut vouloir un périmètre pour les données non obscurcies à haute confiance et un périmètre distinct pour les données anonymisées de niveau inférieur afin de faciliter le partage avec des entités externes tout en protégeant les données à niveau de confiance élevé.

Si votre entreprise souhaite se conformer à des normes telles que la norme PCI DSS, vous pouvez définir un périmètre distinct autour de vos données réglementées.

Lorsque le partage de 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é 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 d'un de ces locataires à un autre constitue une exfiltration, nous vous recommandons de mettre en place 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 permet de réduire la complexité opérationnelle et de minimiser les vecteurs d'exfiltration potentiels. Laisser les API non protégées augmente les vecteurs d'exfiltration possibles. Par conséquent, il doit y avoir des examens et des justifications si votre organisation choisit de protéger une API et non une autre.

Tous les nouveaux projets doivent passer par le 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 leur utilisation dans un projet distinct ou de déplacer l'ensemble 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 est sans ambiguïté. Par conséquent, ce type de dépendance peut ne pas fonctionner dans un périmètre. Nous vous recommandons de modifier la charge de travail pour isoler les besoins liés aux services non compatibles dans un projet distinct ou de déplacer la charge de travail hors 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 réduire au maximum la complexité du périmètre.

Étapes suivantes