GCP - Basic Information
Hiérarchie des ressources
Google Cloud utilise une Hiérarchie des ressources qui est similaire, conceptuellement, à celle d'un système de fichiers traditionnel. Cela fournit un flux de travail parent/enfant logique avec des points d'attachement spécifiques pour les politiques et les permissions.
À un niveau élevé, cela ressemble à ceci :
Une machine virtuelle (appelée Compute Instance) est une ressource. Une ressource réside dans un projet, probablement aux côtés d'autres Compute Instances, des buckets de stockage, etc.
Migration de Projets
Il est possible de migrer un projet sans aucune organisation vers une organisation avec les permissions roles/resourcemanager.projectCreator et roles/resourcemanager.projectMover. Si le projet est à l'intérieur d'une autre organisation, il est nécessaire de contacter le support GCP pour les sortir de l'organisation d'abord. Pour plus d'informations, consultez ceci.
Politiques d'Organisation
Permettent de centraliser le contrôle sur les ressources cloud de votre organisation :
Centraliser le contrôle pour configurer des restrictions sur la manière dont les ressources de votre organisation peuvent être utilisées.
Définir et établir des garde-fous pour que vos équipes de développement restent dans les limites de conformité.
Aider les propriétaires de projets et leurs équipes à avancer rapidement sans craindre de violer la conformité.
Ces politiques peuvent être créées pour affecter l'organisation complète, des dossiers ou des projets. Les descendants du nœud de la hiérarchie des ressources ciblées héritent de la politique d'organisation.
Pour définir une politique d'organisation, vous choisissez une contrainte, qui est un type particulier de restriction contre un service Google Cloud ou un groupe de services Google Cloud. Vous configurez cette contrainte avec les restrictions souhaitées.
Cas d'utilisation courants
Limiter le partage de ressources en fonction du domaine.
Limiter l'utilisation des comptes de service Identity and Access Management.
Restreindre l'emplacement physique des nouvelles ressources créées.
Désactiver la création de comptes de service.
Il existe de nombreuses autres contraintes qui vous donnent un contrôle granulaire sur les ressources de votre organisation. Pour plus d'informations, consultez la liste de toutes les contraintes du service de politique d'organisation.
Politiques d'Organisation par Défaut
Rôles IAM
Ceux-ci sont comme les politiques IAM dans AWS car chaque rôle contient un ensemble de permissions.
Cependant, contrairement à AWS, il n'y a pas de dépôt centralisé de rôles. Au lieu de cela, les ressources donnent des rôles d'accès X à des principaux Y, et la seule façon de savoir qui a accès à une ressource est d'utiliser la méthode get-iam-policy sur cette ressource.
Cela pourrait poser un problème car cela signifie que la seule façon de savoir quelles permissions un principal a est de demander à chaque ressource à qui elle donne des permissions, et un utilisateur pourrait ne pas avoir les permissions pour obtenir des permissions de toutes les ressources.
Il y a trois types de rôles dans IAM :
Rôles de base/primaires, qui incluent les rôles Propriétaire, Éditeur et Lecteur qui existaient avant l'introduction de IAM.
Rôles prédéfinis, qui fournissent un accès granulaire pour un service spécifique et sont gérés par Google Cloud. Il y a beaucoup de rôles prédéfinis, vous pouvez voir tous avec les privilèges qu'ils ont ici.
Rôles personnalisés, qui fournissent un accès granulaire selon une liste de permissions spécifiée par l'utilisateur.
Il y a des milliers de permissions dans GCP. Pour vérifier si un rôle a une permission, vous pouvez chercher la permission ici et voir quels rôles l'ont.
Vous pouvez également chercher ici les rôles prédéfinis offerts par chaque produit. Notez que certains rôles ne peuvent pas être attachés aux utilisateurs et seulement aux SAs en raison de certaines permissions qu'ils contiennent. De plus, notez que les permissions ne prendront effet que si elles sont attachées au service pertinent.
Ou vérifier si un rôle personnalisé peut utiliser une permission spécifique ici.
GCP - IAM, Principals & Org Policies EnumUtilisateurs
Dans la console GCP il n'y a aucune gestion des Utilisateurs ou Groupes, cela se fait dans Google Workspace. Bien que vous puissiez synchroniser un fournisseur d'identité différent dans Google Workspace.
Vous pouvez accéder aux utilisateurs et groupes de Workspaces à l'adresse https://admin.google.com.
MFA peut être imposée aux utilisateurs de Workspaces, cependant, un attaquant pourrait utiliser un jeton pour accéder à GCP via cli qui ne sera pas protégé par MFA (il sera protégé par MFA uniquement lorsque l'utilisateur se connecte pour le générer : gcloud auth login).
Groupes
Lorsqu'une organisation est créée, plusieurs groupes sont fortement suggérés d'être créés. Si vous gérez l'un d'eux, vous pourriez avoir compromis toute ou une partie importante de l'organisation :
Groupe | Fonction |
| Administrer toute ressource appartenant à l'organisation. Attribuez ce rôle avec parcimonie ; les administrateurs d'organisation ont accès à toutes vos ressources Google Cloud. Alternativement, parce que cette fonction est hautement privilégiée, envisagez d'utiliser des comptes individuels au lieu de créer un groupe. |
| Créer des réseaux, des sous-réseaux, des règles de pare-feu et des dispositifs réseau tels que Cloud Router, Cloud VPN et les équilibreurs de charge cloud. |
| Configurer des comptes de facturation et surveiller leur utilisation. |
| Concevoir, coder et tester des applications. |
| Établir et gérer les politiques de sécurité pour l'ensemble de l'organisation, y compris la gestion des accès et les politiques de contraintes d'organisation. Voir le guide des fondations de sécurité Google Cloud pour plus d'informations sur la planification de votre infrastructure de sécurité Google Cloud. |
| Créer ou gérer des pipelines de bout en bout qui prennent en charge l'intégration et la livraison continues, la surveillance et la provision de systèmes. |
| |
| |
| |
| Surveiller les dépenses sur les projets. Les membres typiques font partie de l'équipe financière. |
| Examiner les informations sur les ressources à travers l'organisation Google Cloud. |
| Examiner la sécurité du cloud. |
| Examiner les configurations réseau. |
| Voir les journaux d'audit. |
| Administrer le Security Command Center. |
| Gérer les secrets dans Secret Manager. |
Politique de Mot de Passe par Défaut
Imposer des mots de passe forts
Entre 8 et 100 caractères
Pas de réutilisation
Pas d'expiration
Si les personnes accèdent à Workspace via un fournisseur tiers, ces exigences ne s'appliquent pas.
Comptes de service
Ce sont les principaux que les ressources peuvent avoir attachés et accéder pour interagir facilement avec GCP. Par exemple, il est possible d'accéder au jeton d'authentification d'un compte de service attaché à une VM dans les métadonnées.
Il est possible de rencontrer certains conflits lors de l'utilisation à la fois des IAM et des portées d'accès. Par exemple, votre compte de service peut avoir le rôle IAM de compute.instanceAdmin mais l'instance que vous avez compromise a été limitée par la portée de https://www.googleapis.com/auth/compute.readonly. Cela vous empêcherait d'apporter des modifications en utilisant le jeton OAuth automatiquement attribué à votre instance.
C'est similaire aux rôles IAM d'AWS. Mais contrairement à AWS, n'importe quel compte de service peut être attaché à n'importe quel service (il n'a pas besoin de l'autoriser via une politique).
Plusieurs des comptes de service que vous trouverez sont en fait générés automatiquement par GCP lorsque vous commencez à utiliser un service, comme :
Cependant, il est également possible de créer et d'attacher aux ressources des comptes de service personnalisés, qui ressembleront à ceci :
Access scopes
Les access scopes sont attachés aux jetons OAuth générés pour accéder aux points de terminaison de l'API GCP. Ils restreignent les permissions du jeton OAuth. Cela signifie que si un jeton appartient à un propriétaire d'une ressource mais n'a pas la portée du jeton pour accéder à cette ressource, le jeton ne peut pas être utilisé pour (ab)user de ces privilèges.
Google recommande en fait que les access scopes ne soient pas utilisés et de se fier totalement à IAM. Le portail de gestion web applique en fait cela, mais les access scopes peuvent toujours être appliqués aux instances en utilisant des comptes de service personnalisés de manière programmatique.
Vous pouvez voir quels scopes sont assignés en interrogeant :
Les scopes précédents sont ceux générés par défaut en utilisant gcloud pour accéder aux données. Cela est dû au fait que lorsque vous utilisez gcloud, vous créez d'abord un jeton OAuth, puis vous l'utilisez pour contacter les points de terminaison.
Le scope le plus important parmi ceux-ci est potentiellement cloud-platform, ce qui signifie qu'il est possible d'accéder à n'importe quel service dans GCP.
Vous pouvez trouver une liste de tous les scopes possibles ici.
Si vous avez des identifiants de navigateur gcloud, il est possible d'obtenir un jeton avec d'autres scopes, en faisant quelque chose comme :
Terraform IAM Policies, Bindings and Memberships
Comme défini par terraform dans https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam en utilisant terraform avec GCP, il existe différentes manières d'accorder à un principal l'accès à une ressource :
Memberships : Vous définissez les principaux comme membres de rôles sans restrictions sur le rôle ou les principaux. Vous pouvez mettre un utilisateur comme membre d'un rôle puis mettre un groupe comme membre du même rôle et également définir ces principaux (utilisateur et groupe) comme membres d'autres rôles.
Bindings : Plusieurs principaux peuvent être liés à un rôle. Ces principaux peuvent toujours être liés ou être membres d'autres rôles. Cependant, si un principal qui n'est pas lié au rôle est défini comme membre d'un rôle lié, la prochaine fois que le binding est appliqué, l'appartenance disparaîtra.
Policies : Une politique est autoritaire, elle indique les rôles et les principaux et ensuite, ces principaux ne peuvent pas avoir plus de rôles et ces rôles ne peuvent pas avoir plus de principaux à moins que cette politique ne soit modifiée (même pas dans d'autres politiques, bindings ou memberships). Par conséquent, lorsqu'un rôle ou un principal est spécifié dans une politique, tous ses privilèges sont limités par cette politique. Évidemment, cela peut être contourné si le principal a la possibilité de modifier la politique ou les permissions d'escalade de privilèges (comme créer un nouveau principal et lui attribuer un nouveau rôle).
Références
Last updated
