Configurer les bonnes pratiques de sécurité

Cette page présente les bonnes pratiques de sécurité recommandées pour renforcer la sécurité et la protection des données autour de vos Cloud Workstations. Cette liste n'est pas une checklist complète garantissant la sécurité ni un remplacement de vos postures de sécurité existantes.

L'objectif est de vous fournir un guide des bonnes pratiques de sécurité rendues possibles par Cloud Workstations. Ajoutez ces recommandations à votre portefeuille de solutions de sécurité, le cas échéant, dans le cadre de vos efforts visant à créer une approche de sécurité en couches. Une approche de sécurité en couches est l'un des principes de sécurité fondamentaux pour exécuter des services sécurisés et conformes sur Google Cloud.

Contexte

Le service Cloud Workstations fournit des images de base prédéfinies à utiliser avec le service. Le service recrée et publie ces images chaque semaine pour garantir que le logiciel groupé inclut les derniers correctifs de sécurité. De plus, le service utilise une valeur par défaut de expiration de l'exécution dans votre configuration de la station de travail pour vous assurer que les stations de travail sont automatiquement mises à jour et que les images non corrigées ne restent pas actives.

Toutefois, Google Cloud ne détient pas tous les packages groupés dans ces images. Les gestionnaires de paquets peuvent prioriser les mises à jour différemment en fonction de l'impact d'un bug ou d'une faille CVE sur leur produit. Si un produit n'utilise qu'une partie d'une bibliothèque, il n'est peut-être pas affecté par les découvertes effectuées dans d'autres parties de la bibliothèque. Par conséquent, bien que des résultats CVE soient détectés lors des analyses de failles de nos images, Cloud Workstations peut toujours fournir un produit sécurisé.

Cloud Workstations peuvent le faire, car elles fournissent un système d'authentification et d'autorisation qui permet de s'assurer que seul le développeur désigné peut accéder à sa station de travail. Comme pour tout environnement de développement, les développeurs doivent appliquer les bonnes pratiques lorsqu'ils utilisent leur poste de travail. Pour une sécurité optimale, n'exécutez que du code fiable, ne travaillez que sur des entrées fiables et n'accédez qu'à des domaines fiables. De plus, nous vous déconseillons d'utiliser des stations de travail pour héberger des serveurs de production ou de partager une seule station de travail avec plusieurs développeurs.

Si vous souhaitez mieux contrôler la sécurité des images de la station de travail de votre organisation, vous pouvez également créer vos propres images de conteneur personnalisées.

Limiter l'accès au réseau public

Désactivez les adresses IP publiques sur vos postes de travail à l'aide de leur configuration et configurez des règles de pare-feu limitant l'accès aux destinations Internet publiques non requises pour le travail quotidien depuis Cloud Workstations. Si vous désactivez les adresses IP publiques, vous devez configurer l'accès privé à Google ou Cloud NAT sur votre réseau. Si vous utilisez l'accès privé à Google et que vous utilisez private.googleapis.com ou restricted.googleapis.com pour Artifact Registry (ou Container Registry), assurez-vous de configurer des enregistrements DNS pour les domaines *.pkg.dev et *.gcr.io.

Restreindre l'accès SSH direct

Assurez-vous de limiter l'accès SSH direct aux VM du projet hébergeant vos Cloud Workstations afin que l'accès ne soit possible que via la passerelle de Cloud Workstations, où les stratégies Identity and Access Management (IAM) (Gestion de l'identité et des accès) sont appliquées et que les journaux de flux VPC peuvent être activés.

Pour désactiver l'accès SSH direct à la VM, exécutez la commande Google Cloud CLI suivante:

    gcloud workstations configs update CONFIG \
        --cluster=CLUSTER \
        --region=REGION \
        --project=PROJECT \
        --disable-ssh-to-vm

Limiter l'accès aux ressources sensibles

Configurez un périmètre de service VPC Service Controls pour limiter l'accès aux ressources sensibles à partir de vos stations de travail, ce qui empêche l'exfiltration du code source et des données.

Suivre le principe du moindre privilège

Respectez le principe du moindre privilège pour les autorisations et l'allocation des ressources.

Autorisations IAM

Utilisez la configuration par défaut d'Identity and Access Management, qui limite l'accès à la station de travail à un seul développeur. Cela permet de s'assurer que chaque développeur utilise une instance de station de travail unique avec une VM sous-jacente distincte, ce qui augmente l'isolation de l'environnement. Les éditeurs de code et les applications Cloud Workstations s'exécutent dans un conteneur en mode privilégié et avec un accès racine, ce qui offre une plus grande flexibilité aux développeurs. Cela fournit une station de travail unique par développeur et permet de s'assurer que, même si un utilisateur s'échappe de ce conteneur, il restera dans sa VM et ne pourra pas accéder à d'autres ressources externes.

Configurez des autorisations IAM limitant l'accès des utilisateurs non administrateurs pour modifier les configurations de la station de travail et les images de conteneur dans Artifact Registry.

De plus, Google vous recommande de configurer des autorisations IAM limitant l'accès des utilisateurs non administrateurs à l'une des ressources Compute Engine sous-jacentes du projet hébergeant vos Cloud Workstations.

Pour en savoir plus, consultez la section Utiliser IAM en toute sécurité.

Autorisations Cloud KMS

Pour mieux respecter le principe du moindre privilège, nous vous recommandons de conserver les ressources Cloud KMS et les ressources Cloud Workstations dans des projets Google Cloud distincts. Créez votre projet de clé Cloud KMS sans owner au niveau du projet, et désignez un administrateur de l'organisation attribué au niveau de l'organisation. Contrairement à un owner, un administrateur de l'organisation ne peut pas gérer ni utiliser de clés directement. Il peut simplement définir des stratégies IAM, qui limitent les utilisateurs autorisés à gérer et à utiliser les clés.

On parle également de séparation des tâches,qui consiste à s'assurer qu'une personne ne dispose pas de toutes les autorisations nécessaires pour effectuer une action malveillante. Pour en savoir plus, consultez la section Séparation des tâches.

Appliquer les mises à jour et correctifs automatiques des images

Assurez-vous que vos postes de travail utilisent la dernière version des images de base des postes de travail Cloud, qui contient les derniers correctifs et correctifs de sécurité. La valeur Expiration de l'exécution de la configuration de votre station de travail permet de s'assurer que les stations de travail créées avec cette configuration sont automatiquement mises à jour lors de la session suivante, afin de correspondre à la dernière version de l'image du conteneur définie dans la configuration de la station de travail.

  • Si votre organisation utilise l'une des images de base de Cloud Workstations, la station de travail détecte automatiquement toute mise à jour de sa configuration la prochaine fois qu'elle sera arrêtée et redémarrée. Définir runningTimeout ou utiliser la valeur par défaut permet de s'assurer que ces stations de travail sont arrêtées.
  • Si votre organisation utilise une image personnalisée, veillez à la recompiler régulièrement. Nous vous recommandons de créer un pipeline d'images sécurisé, comme décrit dans la section suivante.

Créer un pipeline d'images sécurisé pour les images personnalisées

Vous êtes responsable de la gestion et de la mise à jour des packages et des dépendances personnalisés ajoutés aux images personnalisées.

Si vous créez des images personnalisées, nous vous recommandons ce qui suit:

Configurer les journaux de flux VPC

Lorsque vous créez un cluster de stations de travail, Cloud Workstations l'associe à un sous-réseau particulier et toutes les stations de travail sont placées dans ce sous-réseau. Pour activer les journaux de flux VPC, assurez-vous d'activer la journalisation pour ce sous-réseau. Pour en savoir plus, consultez la section Activer les journaux de flux VPC pour un sous-réseau existant.