Les stratégies IAM et les LCA nécessitent une gestion active pour être efficaces.
Avant de rendre un bucket ou un objet accessible aux autres utilisateurs, veillez à bien savoir avec qui vous souhaitez le partager et quels rôles vous souhaitez attribuer à chaque personne. Au fil du temps, les modifications apportées au processus de gestion de projet, aux modèles d'utilisation et à la propriété organisationnelle peuvent vous contraindre à modifier les paramètres IAM ou LCA associés aux buckets et aux projets, surtout si vous gérez Cloud Storage dans le cadre d'une grande organisation ou pour un grand groupe d'utilisateurs. Lorsque vous évaluez et planifiez vos paramètres de contrôle des accès, gardez à l'esprit les bonnes pratiques présentées ci-dessous :
Utilisez le principe du moindre privilège lorsque vous accordez l'accès à vos buckets et objets.
Le principe du moindre privilège est une mesure de sécurité appliquée au moment d'accorder l'accès à vos ressources. Lorsque vous accordez un accès selon ce principe, vous attribuez le niveau minimal d'autorisations requis pour qu'un utilisateur puisse accomplir la tâche qui lui est assignée. Par exemple, si vous souhaitez partager des fichiers avec un autre utilisateur, vous devez lui attribuer le rôle IAM storage.objectViewer ou l'autorisation LCA READER, et non le rôle IAM storage.admin ou l'autorisation LCA OWNER.
Évitez d'accorder des rôles IAM avec l'autorisation setIamPolicy ou d'accorder l'autorisation LCA OWNER aux utilisateurs que vous ne connaissez pas.
L'autorisation IAM setIamPolicy ou l'autorisation LCA OWNER permet à un utilisateur de modifier les autorisations et de prendre le contrôle des données. Vous ne devez utiliser les rôles avec ces autorisations que si vous souhaitez déléguer le contrôle administratif sur les objets et les buckets.
Soyez prudent lorsque vous accordez des autorisations aux utilisateurs anonymes.
Les types de comptes principaux allUsers et allAuthenticatedUsers ne doivent être utilisés que s'il est acceptable que tout internaute puisse lire et analyser vos données. Même si ces niveaux d'accès peuvent être utiles pour des applications et des scénarios particuliers, il est généralement déconseillé d'accorder certaines autorisations telles que les autorisations IAM setIamPolicy, update, create ou delete, ou les autorisations LCA OWNER.
Veillez à déléguer le contrôle administratif de vos buckets.
Vous devez vous assurer que vos ressources peuvent toujours être gérées par d'autres membres de l'équipe lorsqu'une personne dotée d'un accès administrateur quitte le groupe.
Pour empêcher les ressources d'être inaccessibles, vous pouvez effectuer l'une des opérations suivantes :
Accordez le rôle IAM Administrateur de l'espace de stockage de votre projet à un groupe plutôt qu'à une personne.
Accordez le rôle Administrateur de l'espace de stockage IAM de votre projet à au moins deux personnes.
Accordez l'autorisation LCA OWNER pour votre bucket à au moins deux personnes.
Tenez compte du comportement interopérable de Cloud Storage.
Lorsque vous utilisez l'API XML pour permettre un accès interopérable avec d'autres services de stockage, tels qu'Amazon S3, l'identifiant de signature détermine la syntaxe des LCA. Par exemple, si l'outil ou la bibliothèque que vous employez demande à Cloud Storage de récupérer les LCA, et si la requête inclut l'identifiant de signature d'un autre fournisseur de stockage, Cloud Storage renvoie un document XML utilisant la syntaxe de LCA de ce fournisseur. Si l'outil ou la bibliothèque que vous employez demande à Cloud Storage d'appliquer les LCA, et si la requête inclut l'identifiant de signature d'un autre fournisseur de stockage, Cloud Storage s'attend à recevoir un document XML utilisant la syntaxe de LCA de ce fournisseur.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/05 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/05 (UTC)."],[],[],null,["# Access control best practices\n\nThis page describes best practices for using\n[Identity and Access Management (IAM)](/storage/docs/access-control/iam)\nand [Access Control Lists (ACLs)](/storage/docs/access-control/lists) to manage access to your data.\n\nIAM policies and ACLs require active management to be effective.\nBefore you make a bucket or object accessible to other users, be sure you know\nwho you want to share the bucket or object with and what roles you want each of\nthose people to have. Over time, changes in project management, usage patterns,\nand organizational ownership may require you to modify IAM or ACL\nsettings on buckets and projects, especially if you manage\nCloud Storage in a large organization or for a large group of users. As\nyou evaluate and plan your access control settings, keep the following best\npractices in mind:\n\n- **Use the principle of least privilege when granting access to your buckets or\n objects.**\n\n The [*principle of least privilege*](https://en.wikipedia.org/wiki/Principle_of_least_privilege) is a security\n guideline for granting access to your resources. When you grant access based\n on the principle of least privilege, you grant the minimum permission\n that's necessary for a user to accomplish their assigned task. For example,\n if you want to share files with someone, you should grant them the\n `storage.objectViewer` IAM role or the `READER` ACLs\n permission, and not the `storage.admin` IAM role or the\n `OWNER` ACLs permission.\n- **Avoid granting IAM roles with `setIamPolicy` permission or\n granting the ACL `OWNER` permission to people you do not know.**\n\n Granting the `setIamPolicy` IAM permission or the\n `OWNER` ACLs permission allows a user to change permissions and take control\n of data. You should use roles with these permissions only when you want to\n delegate administrative control over objects and buckets.\n- **Be careful how you grant permissions for anonymous users.**\n\n The `allUsers` and `allAuthenticatedUsers` principal types should only be\n used when it is acceptable for anyone on the Internet to read and analyze\n your data. While these scopes are useful for some applications and\n scenarios, it is usually not a good idea to grant all users certain\n permissions, such as the IAM permissions `setIamPolicy`,\n `update`, `create`, or `delete`, or the ACLs `OWNER` permission.\n- **Be sure you delegate administrative control of your buckets.**\n\n You should be sure that your resources can still be managed by\n other team members should an individual with administrative access leave the\n group.\n\n To prevent resources from becoming inaccessible, you can do any of the\n following:\n - Grant the **Storage Admin** IAM role for your project to a\n group instead of an individual\n\n - Grant the **Storage Admin** IAM role for your project to\n at least two individuals\n\n - Grant the `OWNER` ACLs permission for your bucket to at least two\n individuals\n\n- **Be aware of Cloud Storage's interoperable behavior.**\n\n When using the XML API for interoperable access with other storage services,\n such as Amazon S3, the signature identifier determines the ACL syntax. For\n example, if the tool or library you are using makes a request to\n Cloud Storage to retrieve ACLs and the request uses another storage\n provider's signature identifier, then Cloud Storage returns an XML\n document that uses the corresponding storage provider's ACL syntax. If the\n tool or library you are using makes a request to Cloud Storage to\n apply ACLs and the request uses another storage provider's signature\n identifier, then Cloud Storage expects to receive an XML document\n that uses the corresponding storage provider's ACL syntax.\n\n For more information about using the XML API for interoperability with\n Amazon S3, see [Simple migration from Amazon S3 to Cloud Storage](/storage/docs/aws-simple-migration).\n\nWhat's next\n-----------\n\n- [Learn how to use IAM policies with Cloud Storage](/storage/docs/access-control/using-iam-permissions).\n- [Learn how to use ACLs with Cloud Storage](/storage/docs/access-control/create-manage-lists).\n- [Review the IAM reference table for Cloud Storage](/storage/docs/access-control/iam-reference)."]]
