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'attache spécifiques pour les politiques et les autorisations.
À un niveau élevé, cela ressemble à ceci:
Un 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 compartiments de stockage, etc.
Migration des Projets
Il est possible de migrer un projet sans aucune organisation vers une organisation avec les autorisations 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 déplacer hors de l'organisation en premier. Pour plus d'informations, consultez ce lien.
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 balises de sécurité 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 dossier(s) ou des 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 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 de Gestion des identités et des accès.
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 précis sur les ressources de votre organisation. Pour plus d'informations, consultez la liste de toutes les contraintes de service de Politique d'Organisation.
Politiques d'Organisation par Défaut
Rôles IAM
Ceux-ci sont similaires aux politiques IAM dans AWS car chaque rôle contient un ensemble de permissions.
Cependant, contrairement à AWS, il n'y a pas de référentiel 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 problème car cela signifie que la seule façon de savoir quelles permissions un principal a est de demander à chaque ressource à qui il donne des autorisations, et un utilisateur pourrait ne pas avoir les autorisations pour obtenir des autorisations de toutes les ressources.
Il existe trois types de rôles dans IAM :
Rôles de base/primitifs, qui incluent les rôles Propriétaire, Éditeur et Consultant qui existaient avant l'introduction d'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 les 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 existe des milliers de permissions dans GCP. Pour vérifier si un rôle a une permission, vous pouvez rechercher la permission ici et voir quels rôles l'ont.
Vous pouvez également rechercher ici les rôles prédéfinis offerts par chaque produit. Notez que certains rôles ne peuvent pas être attribués aux utilisateurs et uniquement aux SA 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.
pageGCP - IAM, Principals & Org Policies EnumUtilisateurs
Dans la console GCP, il n'y a aucune gestion des utilisateurs ou des groupes, cela se fait dans Google Workspace. Cependant, vous pouvez synchroniser un fournisseur d'identité différent dans Google Workspace.
Vous pouvez accéder aux utilisateurs et groupes de Workspaces sur https://admin.google.com.
La MFA peut être imposée aux utilisateurs de Workspaces, cependant, un attaquant pourrait utiliser un jeton pour accéder à GCP via la CLI sans protection 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, il est fortement recommandé de créer plusieurs groupes. Si vous gérez l'un d'entre eux, vous pourriez compromettre tout ou une partie importante de l'organisation :
Groupe | Fonction |
| Administration de toute ressource appartenant à l'organisation. Attribuez ce rôle avec parcimonie ; les administrateurs d'organisation ont accès à toutes vos ressources Google Cloud. Envisagez plutôt d'utiliser des comptes individuels au lieu de créer un groupe, car cette fonction est très privilégiée. |
| Création de réseaux, de sous-réseaux, de règles de pare-feu et de dispositifs réseau tels que Cloud Router, Cloud VPN et équilibreurs de charge cloud. |
| Configuration des comptes de facturation et surveillance de leur utilisation. |
| Conception, codage et test d'applications. |
| Établissement et gestion des politiques de sécurité pour l'ensemble de l'organisation, y compris la gestion des accès et les politiques de contrainte d'organisation. Consultez le guide des fondamentaux de la sécurité Google Cloud pour plus d'informations sur la planification de votre infrastructure de sécurité Google Cloud. |
| Création ou gestion de pipelines de bout en bout qui prennent en charge l'intégration et la livraison continues, la surveillance et la provision de systèmes. |
| |
| |
| |
| Surveillance des dépenses sur les projets. Les membres typiques font partie de l'équipe financière. |
| Examen des informations sur les ressources dans l'organisation Google Cloud. |
| Examen de la sécurité cloud. |
| Examen des configurations réseau. |
| Consultation des journaux d'audit. |
| Administration du Centre de commandement de sécurité. |
| Gestion des 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 auxquels les ressources peuvent être attachées et avoir accès 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 IAM et de 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 https://www.googleapis.com/auth/compute.readonly. Cela vous empêcherait d'apporter des modifications à l'aide du jeton OAuth qui est 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'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 ressources des comptes de service personnalisés, qui ressembleront à ceci :
Étendues d'accès
Les étendues 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 autorisations du jeton OAuth. Cela signifie que si un jeton appartient à un propriétaire d'une ressource mais n'a pas dans l'étendue du jeton l'accès à 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 étendues d'accès et de s'appuyer entièrement sur IAM. Le portail de gestion web impose en fait cela, mais les étendues d'accès peuvent encore être appliquées aux instances en utilisant des comptes de service personnalisés de manière programmatique.
Vous pouvez voir quelles étendues 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 parmi 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 informations d'identification du navigateur gcloud, il est possible d'obtenir un jeton avec d'autres scopes, en faisant quelque chose comme :
Politiques IAM Terraform, Assignations et Adhésions
Tel que 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 façons d'accorder l'accès à un principal sur une ressource :
Adhésions : Vous définissez des principaux en tant que membres de rôles sans restrictions sur le rôle ou les principaux. Vous pouvez mettre un utilisateur en tant que membre d'un rôle, puis mettre un groupe en tant que membre du même rôle et également définir ces principaux (utilisateur et groupe) en tant que membres d'autres rôles.
Assignations : Plusieurs principaux peuvent être assignés à un rôle. Ces principaux peuvent toujours être assignés ou être membres d'autres rôles. Cependant, si un principal qui n'est pas assigné au rôle est défini en tant que membre d'un rôle assigné, la prochaine fois que l'assignation est appliquée, l'adhésion disparaîtra.
Politiques : Une politique est contraignante, 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 (pas même dans d'autres politiques, assignations ou adhésions). Par conséquent, lorsque qu'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 se voit accorder l'option de modifier la politique ou les autorisations d'escalade de privilèges (comme créer un nouveau principal et lui attribuer un nouveau rôle).
Références
Dernière mise à jour
