Par défaut, les ressources Object Storage Service (OSS), telles que les buckets et les objets, sont privées. Vous en contrôlez l'accès à l'aide de listes de contrôle d'accès (ACL), de politiques d'autorisation et de fonctionnalités de protection de la sécurité. Cette rubrique explique comment OSS évalue une demande d'accès et comment choisir le mécanisme de contrôle des autorisations approprié.
Sélection rapide
Choisissez un mécanisme de contrôle des autorisations en fonction de votre scénario :
|
Scénario |
Solution recommandée |
|
Garder les données privées et bloquer les accès non autorisés |
Définissez l'ACL du bucket sur |
|
Autoriser plusieurs utilisateurs à accéder à un bucket spécifique |
Utilisez une Bucket Policy. |
|
Gérer de manière centralisée toutes les ressources auxquelles un utilisateur peut accéder |
Attachez une RAM policy à l'utilisateur. |
|
Partager des ressources avec d'autres comptes Alibaba Cloud |
Utilisez une Bucket Policy ou Utilisez un rôle RAM pour un accès intercomptes à OSS. |
|
Accorder différents niveaux d'accès au même bucket à plusieurs applications ou équipes |
Utilisez un Access Point pour fournir un endpoint et une politique indépendants à chaque application ou équipe. |
|
Définir de manière centralisée des limites d'autorisations dans des scénarios multi-comptes, par exemple en appliquant Block Public Access |
Utilisez une Control Policy. |
|
Publier des ressources statiques accessibles en lecture par tous |
Définissez l'ACL du bucket sur |
|
Empêcher l'exposition des données due à une mauvaise configuration |
Activez Block Public Access. Les autorisations publiques configurées via une ACL ou une bucket policy ne prennent plus effet. |
|
Accéder à OSS depuis du code JavaScript côté navigateur |
Configurez des règles CORS pour le bucket. Le protocole CORS contrôle uniquement l'accès cross-origin du navigateur et n'accorde ni ne refuse les autorisations d'accès. |
Comment OSS évalue les autorisations
OSS évalue chaque demande en fonction des mécanismes de contrôle des autorisations qui s'y appliquent : les ACL, les bucket policies, les RAM policies, les control policies de Resource Directory et les access point policies (AP policies). Chaque mécanisme est décrit dans la section Méthodes de contrôle des autorisations.
OSS utilise un processus d'autorisation différent pour chaque type de demande :
Demandes signées — Après validation de la signature, OSS évalue la control policy de Resource Directory (le cas échéant), la RAM policy, la bucket policy et l'ACL.
Demandes anonymes — OSS évalue si la control policy de Resource Directory (le cas échéant), la bucket policy et l'ACL autorisent l'accès public.
Chaque évaluation renvoie l'un des résultats suivants :
Allow — Une politique accorde explicitement l'accès.
Explicit Deny — Une politique refuse explicitement l'accès. Un Explicit Deny a la priorité la plus élevée.
Implicit Deny — Aucune politique n'accorde l'accès, la demande est donc refusée.
Lorsque vous configurez plusieurs mécanismes, les règles suivantes s'appliquent :
Plusieurs types de politiques — Vous pouvez utiliser conjointement une bucket policy, une RAM policy et une control policy. OSS évalue toutes les politiques applicables et n'autorise la demande que si chacune d'entre elles l'autorise. Une control policy définit une limite d'autorisation plutôt que d'accorder directement l'accès.
Priorité de l'ACL d'objet — L'ACL d'un objet a une priorité supérieure à celle du bucket. Si vous ne spécifiez pas d'ACL d'objet, celui-ci hérite de l'ACL du bucket.
Demandes via Access Point — Lorsqu'un utilisateur accède à un bucket via un access point, le résultat fusionné de l'évaluation de la RAM policy et de la bucket policy doit être Allow, et l'AP policy doit également être Allow.
Block Public Access — Lorsque Block Public Access est activé, les autorisations publiques configurées via une ACL ou une bucket policy ne prennent plus effet.
Pour connaître le processus d'autorisation complet, consultez la rubrique Détails de l'autorisation OSS.
Méthodes de contrôle des autorisations
ACL
Une ACL détermine si une ressource OSS est publique ou privée grâce à des niveaux d'autorisation prédéfinis.
L'ACL du bucket contrôle les autorisations d'accès par défaut d'un bucket, tandis que l'ACL d'objet contrôle les autorisations d'un objet unique et a une priorité supérieure. Si vous ne spécifiez pas d'ACL d'objet, celui-ci hérite de l'ACL du bucket. Le tableau suivant décrit les niveaux d'autorisation pris en charge.
|
Niveau d'autorisation |
S'applique à |
Effet |
|
|
ACL du bucket et ACL d'objet |
Les données sont privées. Seul le propriétaire de la ressource ou les utilisateurs autorisés peuvent y accéder. |
|
|
ACL du bucket et ACL d'objet |
Tout le monde peut lire les données. Seul le propriétaire de la ressource ou les utilisateurs autorisés peuvent écrire des données. |
|
|
ACL du bucket et ACL d'objet |
Tout le monde peut lire et écrire les données. |
|
|
ACL d'objet |
L'objet hérite de l'ACL du bucket. |
Une ACL prend uniquement en charge des niveaux d'autorisation prédéfinis et ne permet pas de spécifier des principaux autorisés ou des conditions. Pour un contrôle plus fin, utilisez une bucket policy ou une RAM policy.
Bucket policy
Une Bucket Policy est une politique d'autorisation configurée sur un bucket. Elle définit qui peut accéder aux ressources de ce bucket. Une bucket policy peut autoriser des utilisateurs RAM, d'autres comptes Alibaba Cloud et des utilisateurs anonymes, et peut imposer des conditions telles que des restrictions basées sur l'adresse IP, le VPC et l'heure.
Une seule bucket policy peut autoriser plusieurs utilisateurs à accéder au même bucket. Vous n'avez pas besoin de configurer une politique distincte pour chaque utilisateur.
Tutoriels : Contrôle d'accès double avec VPC et bucket policies | Partage de données entre départements basé sur une bucket policy
RAM policy
Une RAM policy est une politique d'autorisation attachée à une identité utilisateur. Elle définit les ressources OSS auxquelles cet utilisateur peut accéder et convient à la gestion centralisée des autorisations d'un utilisateur ou d'une application sur plusieurs buckets.
OSS fournit des politiques système telles que AliyunOSSFullAccess et AliyunOSSReadOnlyAccess que vous pouvez utiliser directement, et prend également en charge les politiques personnalisées. Les rôles RAM permettent l'accès intercomptes et l'autorisation temporaire STS.
Tutoriels : Utilisez un rôle RAM pour un accès intercomptes à OSS | Contrôlez l'accès à OSS avec des RAM policies
Control policy
Une control policy est une politique de contrôle d'accès basée sur la hiérarchie des ressources dans Resource Directory, telle que les dossiers ou les membres, et sert principalement à définir des limites d'autorisation. Dans les scénarios de gestion multi-comptes, une custom control policy peut appliquer de manière centralisée des restrictions sur les politiques de sécurité des buckets des comptes membres, par exemple en exigeant l'activation de Block Public Access. Pour plus de détails, consultez la rubrique Control Policy.
Access Point
Un Access Point fournit un endpoint d'accès indépendant pour un bucket. Lorsque plusieurs applications ou équipes doivent accéder au même bucket avec des autorisations différentes, créez un access point distinct pour chaque partie et utilisez une access point policy (AP policy) pour gérer les autorisations de cette partie. Cette approche évite de maintenir des règles complexes dans une seule bucket policy.
Chaque access point dispose d'un endpoint indépendant, d'une AP policy et d'une configuration de restriction réseau. Une demande arrivant via un access point est évaluée selon l'AP policy, en plus de la RAM policy et de la bucket policy. Pour connaître les règles d'évaluation, consultez la section Comment OSS évalue les autorisations.
Accès temporaire
Deux méthodes permettent d'accéder temporairement aux ressources OSS :
Autorisation temporaire STS — Un rôle RAM permet l'accès intercomptes et l'autorisation temporaire STS.
URL signée — Une URL signée offre une sécurité supérieure à la protection contre le hotlinking, car le champ Referer dans un en-tête de requête HTTP peut être falsifié.
Comparaison des méthodes de contrôle des autorisations
Le tableau suivant compare les méthodes de contrôle des autorisations fournies par OSS :
|
Méthode |
Emplacement de configuration |
Perspective de gestion |
Granularité et conditions |
Exigences de configuration |
|
ACL |
Sur un bucket ou sur un objet unique |
Centrée sur la ressource : caractère public ou privé d'une ressource |
Niveaux d'autorisation prédéfinis uniquement. Impossible de spécifier des principaux autorisés ou des conditions. |
Seul le propriétaire du bucket peut définir ou modifier l'ACL du bucket. |
|
Bucket policy |
Sur un bucket |
Centrée sur la ressource : qui peut accéder aux ressources du bucket |
Principaux autorisés, actions, ressources et conditions telles que les restrictions basées sur l'adresse IP, le VPC et l'heure |
Plus simple à configurer qu'une RAM policy et configurable graphiquement dans la console. Les propriétaires de bucket peuvent accorder directement des autorisations d'accès sans disposer d'autorisations d'opération RAM. |
|
RAM policy |
Sur une identité RAM |
Centrée sur l'identité : quelles ressources OSS une identité peut accéder |
Actions et ressources pour l'identité, avec conditions facultatives. Les politiques système et les politiques personnalisées sont prises en charge. Ne nécessite pas l'élément |
Nécessite des autorisations d'opération RAM. |
|
Control policy |
À chaque niveau de la hiérarchie des ressources dans un resource directory, tel qu'un dossier ou un membre |
Centrée sur la gouvernance de l'organisation : restreint de manière centralisée les limites d'autorisation dans l'ensemble du resource directory |
Limites d'autorisation pour les comptes membres, avec conditions facultatives. Ne nécessite pas l'élément |
Gérée dans Resource Directory. |
|
AP policy |
Sur un access point |
Centrée sur l'endpoint : autorisations séparées pour chaque application ou équipe accédant au même bucket |
Actions, ressources, principaux et conditions pour les demandes arrivant via l'access point. Les restrictions réseau sont configurées séparément. |
Gérée sur l'access point. |
Suivez les recommandations suivantes pour choisir entre les méthodes :
Autoriser plusieurs utilisateurs à accéder à la même ressource — Une bucket policy est plus efficace. Une seule politique spécifie la liste des utilisateurs autorisés.
Gérer toutes les autorisations de ressources d'un seul utilisateur — Une RAM policy est plus intuitive.
Accorder un accès anonyme — Parmi les types de politiques, seule une bucket policy prend en charge l'accès anonyme. Une ACL permet également l'accès anonyme aux niveaux
public-readetpublic-read-write.Restreindre les autorisations sur plusieurs comptes — Une control policy restreint de manière centralisée les limites d'autorisation. Elle contraint ce que les comptes membres sont autorisés à faire plutôt que d'accorder directement l'accès.
Séparer l'accès pour plusieurs applications ou équipes — Une AP policy maintient les autorisations de chaque partie indépendantes et évite des règles complexes dans une seule bucket policy.
Protection de la sécurité
Block Public Access
Après avoir activé Block Public Access, les autorisations publiques configurées via une ACL ou une bucket policy ne prennent plus effet. Les autorisations d'accès public existantes sont ignorées et il est impossible de créer de nouvelles autorisations d'accès public. Cela permet d'éviter l'exposition des données due à une mauvaise configuration.
Vous pouvez configurer Block Public Access au niveau du compte, ce qui s'applique à tous les buckets, ainsi qu'aux niveaux du bucket, de l'access point et de l'object FC access point. La priorité diminue dans cet ordre, de sorte que le paramètre au niveau du compte a la priorité la plus élevée.
Si vous stockez des données sensibles et n'avez pas besoin d'accès anonyme, activez Block Public Access au niveau du compte.
Block Public Access et l'accès public s'excluent mutuellement. Si Block Public Access est activé pour le compte, le bucket ou l'access point, une ACL public-read ou une bucket policy publique ne prend pas effet. Vérifiez les paramètres de Block Public Access avant de publier des ressources publiquement.
Protection contre le hotlinking
La protection contre le hotlinking valide la source des requêtes HTTP, telles que les en-têtes Referer et User-Agent, pour empêcher les sites Web non autorisés de référencer vos ressources OSS. Vous pouvez configurer la protection contre le hotlinking à l'aide de listes d'autorisation, de listes de blocage ou d'expressions régulières. Une liste d'autorisation n'autorise que les noms de domaine spécifiés, tandis qu'une liste de blocage refuse les noms de domaine spécifiés. Utilisez la protection contre le hotlinking pour empêcher l'utilisation non autorisée de ressources telles que les images et les vidéos.
Le champ Referer peut être falsifié. Pour une sécurité accrue, utilisez une URL signée, qui est une méthode d'accès temporaire.
Partage de ressources cross-origin (CORS)
Par défaut, un navigateur empêche le code JavaScript d'une page Web d'accéder aux ressources d'un nom de domaine différent. Après avoir configuré des règles CORS, OSS renvoie des en-têtes cross-origin dans la réponse afin que le navigateur autorise la demande. Le protocole CORS s'applique à des scénarios tels que les téléchargements directs de fichiers depuis le frontend et la récupération de ressources.
Le protocole CORS résout uniquement la restriction same-origin des navigateurs. Il n'accorde ni ne refuse les autorisations d'accès ; configurez donc le protocole CORS en complément d'un mécanisme de contrôle des autorisations, et non à sa place.
Références
Les rubriques suivantes fournissent plus d'informations sur les autorisations et le contrôle d'accès dans OSS :