Last updated
Apprenez et pratiquez le Hacking AWS :Formation HackTricks AWS Red Team Expert (ARTE) Apprenez et pratiquez le Hacking GCP : Formation HackTricks GCP Red Team Expert (GRTE)
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'attache 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.
Il est possible de migrer un projet sans organisation vers une organisation avec les permissions 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'infos, consultez ceci.
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.
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.
Ce sont comme des 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 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 permissions un principal a est de demander à chaque ressource à qui elle accorde des permissions, et un utilisateur pourrait ne pas avoir les permissions nécessaires pour obtenir les permissions 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 ceux-ci 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 existe 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 à des utilisateurs et uniquement à des 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érifiez si un rôle personnalisé peut utiliser une permission spécifique ici.
GCP - IAM, Principals & Org Policies EnumDans la console GCP, il n'y a pas de gestion des Utilisateurs ou 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 forcée pour les 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).
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, comme 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, sous-réseaux, règles de pare-feu et dispositifs réseau tels que Cloud Router, Cloud VPN et équilibreurs de charge cloud. |
| Configurer des comptes de facturation et surveiller leur utilisation. |
| Concevoir, coder et tester des applications. |
| |
| Créer ou gérer des pipelines de bout en bout qui soutiennent 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é cloud. |
| Examiner les configurations réseau. |
| Voir les journaux d'audit. |
| Administrer le Security Command Center. |
| Gérer les secrets dans Secret Manager. |
Appliquer 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.
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 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 :
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.
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 se fier totalement à 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 portées précédentes sont celles générées 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.
La portée la plus importante de celles-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 toutes les portées possibles ici.
Si vous avez des identifiants de navigateur gcloud, il est possible d'obtenir un jeton avec d'autres portées, en faisant quelque chose comme :
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 la 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).
Établir et gérer des politiques de sécurité pour l'ensemble de l'organisation, y compris la gestion des accès et les . Consultez le pour plus d'informations sur la planification de votre infrastructure de sécurité Google Cloud.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
