Object Storage Service:Processus d'autorisation

Lorsque OSS reçoit une requête non anonyme, il l'évalue en fonction du résultat de l'authentification, des politiques de session basées sur les rôles, des politiques basées sur l'identité (politiques RAM), des politiques de bucket, des listes de contrôle d'accès (ACL) des objets et des ACL des buckets afin de décider d'autoriser ou de refuser la requête.

Le diagramme illustre trois résultats possibles :

• Autoriser : la politique applicable autorise la requête.

• Refus explicite : la politique applicable rejette explicitement la requête.

• Refus implicite : aucune politique applicable n'existe, ou aucune politique ne produit un résultat d'autorisation ou de refus explicite.

OSS évalue une requête non anonyme selon l'ordre suivant :

1. OSS vérifie l'identité de la requête.

   OSS compare la signature contenue dans la requête avec celle calculée par le serveur OSS.

   • Les signatures ne correspondent pas : OSS refuse la requête.

   • Les signatures correspondent : OSS vérifie si la requête est soumise à des politiques de session basées sur les rôles.

2. OSS vérifie l'application des politiques de session basées sur les rôles.

   Oui : OSS évalue la requête à l'aune des politiques de session.

   • Refus explicite ou refus implicite : OSS refuse la requête.

   • Autoriser : OSS poursuit la vérification des politiques RAM et des politiques de bucket.

   Non : OSS ignore l'évaluation des politiques de session et passe aux politiques RAM et aux politiques de bucket.

3. OSS évalue les politiques RAM et les politiques de bucket.

   Les politiques RAM sont des politiques de contrôle d'accès basées sur l'identité qui déterminent quelles identités peuvent accéder à vos ressources OSS. OSS détermine le résultat en fonction de l'expéditeur de la requête :

   • Paire AccessKey d'un compte Alibaba Cloud : OSS refuse implicitement la requête.

   • Paire AccessKey d'un utilisateur RAM ou informations d'identification Security Token Service (STS) utilisées pour accéder à un bucket qui n'appartient pas au compte Alibaba Cloud ou au propriétaire de l'utilisateur RAM : OSS refuse implicitement la requête.

   • Dans les autres cas, OSS appelle RAM pour authentifier la requête. OSS prend en charge l'authentification par compte et par groupe de ressources du bucket, et détermine s'il faut autoriser, refuser explicitement ou refuser implicitement la requête en fonction du résultat.

   Les politiques de bucket sont des politiques d'autorisation basées sur les ressources. Le propriétaire du bucket peut utiliser ces politiques pour accorder aux utilisateurs RAM ou à d'autres comptes Alibaba Cloud l'autorisation d'effectuer des opérations sur le bucket ou sur des ressources spécifiques qu'il contient.

   • Aucune politique de bucket configurée : OSS refuse implicitement la requête.

   • Une politique de bucket existe : OSS vérifie si la requête correspond à la politique et renvoie une autorisation, un refus explicite ou un refus implicite.

4. OSS vérifie la présence d'un refus explicite dans le résultat combiné.

   Si une politique produit un refus explicite, OSS refuse la requête. Sinon, OSS vérifie si une politique produit une autorisation.

   1. OSS vérifie les politiques RAM et les politiques de bucket pour détecter une autorisation.

      Si une politique produit une autorisation, OSS autorise la requête. Sinon, OSS vérifie la source de la requête.

   2. OSS vérifie la source de la requête.

      Les requêtes Management API sont refusées. Les requêtes Data API passent à l'évaluation des ACL.

      Les opérations Management API incluent les opérations de service telles que GetService (ListBuckets), les opérations de bucket telles que PutBucket et GetBucketLifecycle, ainsi que les opérations LiveChannel telles que PutLiveChannel et DeleteLiveChannel.

      Les opérations Data API incluent les opérations sur les objets telles que PutObject et GetObject.

5. OSS évalue l'ACL de l'objet et l'ACL du bucket.

   Lors de la vérification de l'ACL de l'objet, OSS détermine si le demandeur est le propriétaire du bucket et si la requête est une opération de lecture ou d'écriture. Pour plus d'informations, consultez PutBucketAcl.

   • Autoriser : OSS autorise la requête.

   • Refuser : OSS refuse la requête.

   Si l'ACL de l'objet est définie pour hériter du bucket, OSS se rabat sur l'ACL du bucket.

   Lors de la vérification de l'ACL du bucket, OSS détermine si le demandeur est le propriétaire du bucket. Pour plus d'informations, consultez PutBucketAcl.

   • Autoriser : OSS autorise la requête.

   • Refuser : OSS refuse la requête.

Pour les requêtes anonymes, OSS ignore entièrement l'authentification, les politiques de session basées sur les rôles et les politiques RAM. La décision repose uniquement sur les politiques de bucket, les ACL des objets et les ACL des buckets.

OSS évalue une requête anonyme selon l'ordre suivant :

1. OSS évalue les politiques de bucket.

   • Refuser : OSS refuse la requête.

   • Autoriser : OSS autorise la requête.

   • Ignorer (aucune politique correspondante) : OSS passe à l'évaluation des ACL.

2. OSS évalue l'ACL de l'objet et l'ACL du bucket.

   • L'ACL de l'objet est privée : OSS refuse la requête.

   • L'ACL de l'objet est public-read ou public-read-write : OSS autorise la requête.

   • L'ACL de l'objet est définie pour hériter du bucket : OSS vérifie l'ACL du bucket.

     • L'ACL du bucket est public-read ou public-read-write : OSS autorise la requête.

     • L'ACL du bucket est privée : OSS refuse la requête.