Protection contre l'accès public

Accéder aux exemples

Cette page présente le paramètre du bucket de protection contre l'accès public et la contrainte de règle d'administration associée de protection contre l'accès public. L'utilisation du paramètre ou de la contrainte restreint les entités, telles que les utilisateurs anonymes sur Internet, qui peuvent se voir accorder l'accès à vos données. Pour obtenir une présentation des options de contrôle des accès, consultez la page Présentation du contrôle des accès.

Présentation

La protection contre l'accès public empêche les buckets et les objets Cloud Storage d'être accidentellement exposés au public. Lorsque vous appliquez la protection contre l'accès public, personne ne peut rendre publiques les données des buckets applicables via des stratégies IAM ou des LCA. Il existe deux façons d'appliquer la protection contre l'accès public :

Devez-vous utiliser la protection contre l'accès public ?

Si vous savez que vos données ne doivent jamais être exposées sur l'Internet public, utilisez la protection contre l'accès public. Afin de renforcer la sécurité de vos ressources, appliquez la protection contre l'accès public au plus haut niveau possible de votre organisation.

N'utilisez pas la protection contre l'accès public si vous devez rendre le bucket public pour des cas d'utilisation tels que l'hébergement de sites Web statiques. Pour définir des exceptions pour ces buckets dans des organisations qui appliquent normalement la protection contre l'accès public, désactivez la protection contre l'accès public sur le projet spécifique qui contient le bucket.

Comportement lorsque la fonctionnalité est activée

Les ressources soumises à la protection contre l'accès public présentent le comportement suivant :

  • Les requêtes adressées aux buckets et aux objets autorisés à l'aide de allUsers et de allAuthenticatedUsers échouent avec un code d'état HTTP 401 ou 403.

  • Les stratégies IAM existantes et les LCA qui accordent l'accès à allUsers et à allAuthenticatedUsers restent en place, mais sont remplacées par la protection contre l'accès public.

  • Les requêtes de création de buckets ou d'objets avec allUsers et allAuthenticatedUsers dans leurs stratégies IAM ou leurs LCA échouent, à l'exception suivante :

    • Si une LCA d'objet par défaut contient allUsers pour un bucket, les requêtes de création d'objets dans ce bucket aboutissent. Les LCA de ces objets contiennent allUsers, mais allUsers est remplacé par une protection contre l'accès public.
  • Les requêtes d'ajout de allUsers et de allAuthenticatedUsers à une stratégie IAM ou à une LCA échouent avec 412 Precondition Failed.

Héritage

Même si la protection contre l'accès public n'est pas explicitement appliquée dans les paramètres d'un bucket, celui-ci peut tout de même hériter de la protection contre l'accès public. Celle-ci survient si la contrainte de règle d'administration storage.publicAccessPrevention est défini sur le projet, le dossier ou l'organisation dans lequel se trouve le bucket. Pour cette raison, l'état du bucket ne peut être défini que sur enforced ou unspecified.

Si l'état du bucket est unspecified, le bucket hérite de son état à partir du projet parent. De même, le projet hérite par défaut de son état de protection contre l'accès public à partir du dossier ou de l'organisation dans lequel il existe. Toutefois, vous pouvez définir explicitement l'activation ou la désactivation de storage.publicAccessPrevention pour le projet, ce qui remplace toute valeur qui serait héritée. Par exemple, si vous désactivez storage.publicAccessPrevention pour un projet, cela garantit que les buckets du projet ayant un paramètre unspecified n'utilisent pas la protection contre l'accès public, quel que soit l'état de protection contre l'accès public au niveau du dossier ou de l'organisation.

Comportement si la fonctionnalité est désactivée

Lorsque la protection contre l'accès public ne s'applique plus à une ressource, voici ce qui se produit :

  • Les stratégies IAM existantes et les LCA qui accordent l'accès à allUsers et à allAuthenticatedUsers prennent effet et rendent les données accessibles au public.

  • Les requêtes de création de stratégies IAM ou de LCA qui autorisent l'accès à allUsers et à allAuthenticatedUsers aboutissent.

  • Un objet créé sous la protection contre l'accès public sans LCA publique peut devenir accessible au public s'il a été créé dans un bucket accessible au public.

Vous pouvez désactiver à tout moment la protection contre l'accès public pour un projet, un dossier ou une organisation. La protection contre l'accès public est toujours appliquée aux buckets avec le paramètre enforced, même si vous la désactivez pour un projet, un dossier ou une organisation contenant le bucket.

Autorisations IAM pour la protection contre l'accès public

Pour gérer la règle d'administration sur la protection contre l'accès public au niveau du projet, du dossier ou de l'organisation, vous devez disposer de l'autorisation IAM orgpolicy.*. Cette autorisation est disponible dans le rôle IAM roles/orgpolicy.policyAdmin.

Pour gérer le paramètre de la protection contre l'accès public sur un bucket, vous devez disposer des autorisations IAM storage.buckets.update et storage.buckets.setIamPolicy. Ces autorisations sont disponibles dans le rôle roles/storage.admin.

Si la protection contre l'accès public est appliquée au projet parent du bucket à l'aide d'une règle d'administration, les administrateurs de l'espace de stockage ne peuvent pas exempter le bucket de la protection contre l'accès public.

Remarques

  • Lorsque vous appliquez la protection contre l'accès public sur les ressources existantes, toutes les autorisations existantes et les nouveaux ajouts de allUsers et de allAuthenticatedUsers sont bloqués. Cela peut affecter vos buckets comme suit :

    • Si une application dépend de allUsers et de allAuthenticatedUsers pour accéder à vos données ou créer des ressources publiques, l'activation de la protection contre l'accès public peut l'endommager.

    • Cloud Audit Logs ne permet pas de suivre les accès aux objets publics. Si les journaux d'accès aux données sont activés lorsque vous appliquez la protection contre l'accès public, vous pouvez constater une augmentation de la génération des journaux, qui est comptabilisée dans votre quota d'ingestion de journaux et peut entraîner des frais pour Cloud Audit Logs. Cette augmentation peut se produire, car un accès précédemment public et non consigné pourrait être associé à des autorisations spécifiques, qui sont consignées.

  • Les URL signées, qui donnent un accès limité dans le temps à toute personne qui les utilise, ne sont pas affectées par la protection contre l'accès public.

  • Les projets non associés à une organisation ne peuvent pas utiliser de règles d'administration. Les buckets au sein de ce projet doivent utiliser le paramètre au niveau du bucket.

  • La protection contre l'accès public présente une cohérence forte pour la lecture après la mise à jour, mais l'application des règles peut prendre jusqu'à 10 minutes.

  • Une fois l'application commencée, vos objets peuvent toujours être accessibles publiquement via un cache Internet pendant un certain temps, selon le paramètre Cache-Control des objets. Par exemple, si la valeur Cache-Control:max-age d'un objet est définie sur la valeur par défaut de 3 600 secondes, l'objet peut rester dans un cache Internet pendant cette durée.

Étape suivante