Lorsqu'une entité RAM (utilisateur ou rôle) demande l'accès à une ressource Alibaba Cloud, RAM évalue toutes les politiques applicables pour autoriser ou refuser la demande.
Principes fondamentaux
L'évaluation des politiques repose sur deux principes :
Refus par défaut : les entités RAM ne disposent d'aucune permission par défaut. Sauf si une politique autorise explicitement une demande, celle-ci est implicitement refusée.
Le refus explicite l'emporte sur l'autorisation : si une politique contient une instruction
Denyexplicite, la demande est refusée, indépendamment des instructionsAllowprésentes dans d'autres politiques.
Flux d'évaluation
RAM évalue les politiques selon un ordre défini. Si une étape refuse la demande, l'évaluation s'arrête. La demande n'est autorisée que si elle passe avec succès toutes les vérifications de politiques applicables.
L'évaluation comprend les étapes suivantes :
Étape 1 : Évaluer les politiques de contrôle Resource Directory (le cas échéant)
Si le compte est membre d'un répertoire de ressources, RAM évalue les politiques de contrôle applicables. Ces politiques servent de garde-fous en matière d'autorisations pour le compte.
Si la politique de contrôle n'autorise pas l'action demandée, la demande est refusée et l'évaluation s'arrête.
Si l'action est autorisée, l'évaluation passe à l'étape suivante.
S'il n'existe aucune politique de contrôle, cette étape est ignorée.
Les politiques de contrôle s'appliquent à toutes les entités RAM (utilisateurs et rôles) au sein d'un compte membre, mais ne s'appliquent ni au propriétaire de ce compte ni aux entités du compte de gestion du répertoire de ressources.
Étape 2 : Évaluer les politiques de session de rôle RAM (le cas échéant)
Si l'entité est un rôle RAM endossé avec une politique de session (par exemple via l'opération AssumeRole), RAM évalue cette politique.
Si la politique de session n'autorise pas l'action demandée, la demande est refusée et l'évaluation s'arrête.
Si l'action est autorisée, l'évaluation se poursuit.
Cette étape est ignorée pour les demandes des utilisateurs RAM et pour la fédération SSO, car les politiques de session ne s'appliquent pas.
Étape 3 : Évaluer les politiques basées sur l'identité et les politiques basées sur les ressources
RAM évalue les politiques basées sur l'identité (attachées à l'utilisateur ou au rôle RAM demandeur) et les politiques basées sur les ressources (attachées à la ressource cible).
-
Politique basée sur l'identité : RAM évalue toutes les politiques attachées à l'entité demanderesse. Si une politique refuse explicitement la demande, le résultat est un refus explicite. Si au moins une politique autorise la demande, le résultat est une autorisation. Dans le cas contraire, le résultat est un refus implicite.
RemarqueLors d'une authentification unique (SSO) initiée par le fournisseur d'identité (IdP), l'utilisateur n'a pas encore endossé d'identité ; aucune politique basée sur l'identité n'est donc évaluée. Seule la politique d'approbation du rôle RAM est vérifiée.
Politique basée sur les ressources : si la ressource cible dispose d'une politique basée sur les ressources (telle qu'une politique de compartiment OSS ou une politique d'approbation de rôle RAM), RAM l'évalue selon la même logique : le résultat est une autorisation, un refus explicite ou un refus implicite. En l'absence de politique basée sur les ressources, cette vérification est ignorée.
Étape 4 : Déterminer le résultat final
RAM combine les résultats de toutes les étapes précédentes pour prendre une décision finale.
Si un refus explicite a été produit à n'importe quelle étape, la décision finale est DENY.
S'il n'existe aucun refus explicite et qu'au moins une autorisation a été produite (par une politique basée sur l'identité ou sur les ressources), la décision finale est ALLOW.
Dans tous les autres cas (si aucune politique n'autorise explicitement la demande), la décision finale est un refus implicite.
Cas d'évaluation particuliers
Endossement d'un rôle RAM : l'endossement d'un rôle RAM constitue un cas particulier qui requiert une instruction
Allowà la fois dans la politique basée sur l'identité de l'entité et dans la politique d'approbation du rôle. Pour plus d'informations, consultez la rubrique Comment RAM évalue les politiques lors de l'endossement d'un rôle.Object Storage Service (OSS) : pour les requêtes OSS, les listes de contrôle d'accès (ACL) des compartiments ou des objets sont évaluées après les politiques RAM. Une ACL peut refuser une demande même si une politique RAM l'autorise. Consultez la rubrique Autorisation OSS.