IBM - Informations de base

Reading time: 4 minutes

tip

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) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Hiérarchie

Modèle de ressources IBM Cloud (des docs):

Méthode recommandée pour diviser les projets :

IAM

Utilisateurs

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.

Profils de confiance

Ce 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 pour 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.

Identifiants de service

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.

Fournisseurs d'identité

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.

Groupes d'accès

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.

Rôles

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.

Politiques d'accès

Les politiques d'accès permettent de joindre 1 ou plusieurs rôles d'un 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 au service et à la 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

note

Pour accorder l'accès à plusieurs services à un utilisateur, vous pouvez générer plusieurs politiques d'accès

Références

tip

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) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks