GCP - Basic Information
Hiérarchie des ressources
Google Cloud utilise une hiérarchie des ressources qui est conceptuellement similaire à celle d'un système de fichiers traditionnel. Cela fournit un flux de travail logique parent/enfant avec des points d'attachement spécifiques pour les politiques et les autorisations.
À un niveau élevé, cela ressemble à ceci :
Une machine virtuelle (appelée une instance de calcul) est une ressource. Une ressource réside dans un projet, probablement aux côtés d'autres instances de calcul, de buckets de stockage, etc.
Migration de projets
Il est possible de migrer un projet sans organisation vers une organisation avec les autorisations roles/resourcemanager.projectCreator et roles/resourcemanager.projectMover. Si le projet se trouve dans une autre organisation, il est nécessaire de contacter le support GCP pour les déplacer hors 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 façon 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'ensemble de l'organisation, le(s) dossier(s) ou le(s) projet(s). Les descendants du nœud de hiérarchie de ressources ciblé héritent de la politique d'organisation.
Pour définir une politique d'organisation, vous choisissez un 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 vos 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 ressources nouvellement 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
Ce sont comme des politiques IAM dans AWS car chaque rôle contient un ensemble d'autorisations.
Cependant, contrairement à AWS, il n'y a pas de dépôt centralisé de rôles. Au lieu de cela, les ressources donnent X rôles d'accès à Y principaux, et le seul moyen 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 le seul moyen de savoir quelles autorisations un principal a est de demander à chaque ressource à qui elle accorde des autorisations, et un utilisateur pourrait ne pas avoir les autorisations nécessaires pour obtenir des autorisations de toutes les ressources.
Il existe trois types de rôles dans IAM :
Rôles de base/primitive, qui incluent les rôles Propriétaire, Éditeur et Visionneuse qui existaient avant l'introduction de l'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 existe de nombreux rôles prédéfinis, vous pouvez voir tous les rôles avec les privilèges qu'ils ont ici.
Rôles personnalisés, qui fournissent un accès granulaire selon une liste d'autorisations spécifiée par l'utilisateur.
Il existe des milliers d'autorisations dans GCP. Pour vérifier si un rôle a une autorisation, vous pouvez chercher l'autorisation ici et voir quels rôles l'ont.
Vous pouvez également chercher ici des rôles prédéfinis offerts par chaque produit. Notez que certains rôles ne peuvent pas être attachés à des utilisateurs et uniquement à des SAs en raison de certaines autorisations qu'ils contiennent. De plus, notez que les autorisations ne prendront effet que si elles sont attachées au service pertinent.
Ou vérifiez si un rôle personnalisé peut utiliser une autorisation spécifique ici.
GCP - IAM, Principals & Org Policies EnumUtilisateurs
Dans la console GCP, il n'y a pas de gestion des utilisateurs ou des groupes, cela se fait dans Google Workspace. Bien que vous puissiez synchroniser un autre fournisseur d'identité dans Google Workspace.
Vous pouvez accéder aux utilisateurs et groupes de Workspaces à https://admin.google.com.
MFA peut être imposé 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 à être créés. Si vous gérez l'un d'eux, vous pourriez avoir compromis tout 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, étant donné 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 des équilibreurs de charge cloud. |
| Configurer des comptes de facturation et surveiller leur utilisation. |
| Concevoir, coder et tester des applications. |
| Établir et gérer des politiques de sécurité pour l'ensemble de l'organisation, y compris la gestion des accès et les politiques de contraintes d'organisation. Consultez 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 soutiennent l'intégration et la livraison continues, la surveillance et le provisionnement des 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é cloud. |
| Examiner les configurations réseau. |
| Voir les journaux d'audit. |
| Administrer le Security Command Center. |
| Gérer les secrets dans le 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 des 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 des conflits lors de l'utilisation à la fois de l'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 restriction de portée de https://www.googleapis.com/auth/compute.readonly. Cela vous empêcherait d'apporter des modifications en utilisant le jeton OAuth qui est automatiquement attribué à votre instance.
C'est similaire aux rôles IAM d'AWS. Mais contrairement à AWS, tout compte de service peut être attaché à n'importe quel service (il n'est pas nécessaire 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 des comptes de service personnalisés aux ressources, qui ressembleront à ceci :
Clés & Jetons
Il existe 2 principales façons d'accéder à GCP en tant que compte de service :
Via des jetons OAuth : Ce sont des jetons que vous obtiendrez à partir d'endroits comme les points de terminaison de métadonnées ou en volant des requêtes http et ils sont limités par les portées d'accès.
Clés : Ce sont des paires de clés publiques et privées qui vous permettront de signer des requêtes en tant que compte de service et même de générer des jetons OAuth pour effectuer des actions en tant que compte de service. Ces clés sont dangereuses car elles sont plus compliquées à limiter et à contrôler, c'est pourquoi GCP recommande de ne pas les générer.
Notez que chaque fois qu'un SA est créé, GCP génère une clé pour le compte de service à laquelle l'utilisateur n'a pas accès (et qui ne sera pas listée dans l'application web). Selon ce fil, cette clé est utilisée en interne par GCP pour donner accès aux points de terminaison de métadonnées afin de générer les jetons OAuth accessibles.
Portées d'accès
Les portées d'accès sont attachées aux jetons OAuth générés pour accéder aux points de terminaison de l'API GCP. Elles 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 dans le jeton pour accéder à cette ressource, le jeton ne peut pas être utilisé pour (ab)user de ces privilèges.
Google recommande en fait de ne pas utiliser les portées d'accès et de s'appuyer totalement sur IAM. Le portail de gestion web impose en fait cela, mais les portées d'accès peuvent toujours être appliquées aux instances en utilisant des comptes de service personnalisés de manière programmatique.
Vous pouvez voir quelles portées sont assignées 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 l'utilisez pour contacter les points de terminaison.
Le scope le plus important de ceux-ci est cloud-platform, ce qui signifie essentiellement 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 :
Politiques IAM Terraform, Liens et Adhésions
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 :
Adhésions : Vous définissez des 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.
Liens : 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 lien est appliqué, l'adhésion disparaîtra.
Politiques : Une politique est autoritaire, elle indique des rôles et des 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 (pas même dans d'autres politiques, liens ou adhésions). 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 des permissions d'escalade de privilèges (comme créer un nouveau principal et le lier à un nouveau rôle).
Références
Last updated
