Last updated
Apprenez et pratiquez le Hacking AWS :HackTricks Training AWS Red Team Expert (ARTE) Apprenez et pratiquez le Hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
Modèle de ressources IBM Cloud (des docs):
Méthode recommandée pour diviser les projets :
Les utilisateurs ont un email qui leur est attribué. Ils peuvent accéder à la console IBM et également générer des clés API pour utiliser leurs permissions de manière programmatique. Les permissions peuvent être accordées directement à l'utilisateur avec une politique d'accès ou via un groupe d'accès.
Ceux-ci sont comme les Rôles d'AWS ou les comptes de service de GCP. Il est possible de les attribuer à des instances VM et d'accéder à leurs identifiants via les métadonnées, ou même permettre aux fournisseurs d'identité de les utiliser afin d'authentifier des utilisateurs provenant de plateformes externes. Les permissions peuvent être accordées directement au profil de confiance avec une politique d'accès ou via un groupe d'accès.
C'est une autre option pour permettre aux applications de interagir avec IBM cloud et d'effectuer des actions. Dans ce cas, au lieu de l'attribuer à une VM ou à un fournisseur d'identité, une clé API peut être utilisée pour interagir avec IBM de manière programmatique. Les permissions peuvent être accordées directement à l'identifiant de service avec une politique d'accès ou via un groupe d'accès.
Des Fournisseurs d'identité externes peuvent être configurés pour accéder aux ressources IBM cloud depuis des plateformes externes en accédant à des Profils de confiance.
Dans le même groupe d'accès, plusieurs utilisateurs, profils de confiance et identifiants de service peuvent être présents. Chaque principal dans le groupe d'accès héritera des permissions du groupe d'accès. Les permissions peuvent être accordées directement au profil de confiance avec une politique d'accès. Un groupe d'accès ne peut pas être membre d'un autre groupe d'accès.
Un rôle est un ensemble de permissions granulaires. Un rôle est dédié à un service, ce qui signifie qu'il ne contiendra que des permissions de ce service. Chaque service de l'IAM aura déjà quelques rôles possibles parmi lesquels choisir pour accorder un accès à un principal à ce service : Visionneuse, Opérateur, Éditeur, Administrateur (bien qu'il puisse y en avoir d'autres).
Les permissions de rôle sont données via des politiques d'accès aux principaux, donc si vous devez donner par exemple une combinaison de permissions d'un service de Visionneuse et Administrateur, au lieu de donner ces 2 (et de sur-privilégier un principal), vous pouvez créer un nouveau rôle pour le service et donner à ce nouveau rôle les permissions granulaires dont vous avez besoin.
Les politiques d'accès permettent de joindre 1 ou plusieurs rôles d'1 service à 1 principal. Lors de la création de la politique, vous devez choisir :
Le service où les permissions seront accordées
Ressources affectées
Accès Service & Plateforme qui sera accordé
Cela indique les permissions qui seront données au principal pour effectuer des actions. Si un rôle personnalisé est créé dans le service, vous pourrez également le choisir ici.
Conditions (le cas échéant) pour accorder les permissions
Pour accorder l'accès à plusieurs services à un utilisateur, vous pouvez générer plusieurs politiques d'accès
Apprenez et pratiquez le Hacking AWS :HackTricks Training AWS Red Team Expert (ARTE) Apprenez et pratiquez le Hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
