Définir les droits d'accès à S3



Comme vous l'avez vu, sur le papier S3 est très simple :

  • On peut stocker des fichiers dans des buckets.
  • On peut lire et télécharger ces fichiers sur Internet.

Ca devient compliqué en revanche quand on commence à s'intéresser de près aux problématiques des droits d'accès. Qui a le droit d'ajouter des fichiers dans ce bucket ? Dans ce dossier de ce bucket ? Qui a le droit des récupérer les fichiers ?

Autant de questions importantes qui ne devraient pas être passées sous silence. Ceux qui ont laissé des buckets ouverts alors qu'ils y stockaient des données personnelles s'en sont mordus les doigts. Ca arrive plus souvent qu'on ne le pense.

Le sujet étant vaste, je vous proposerai ici juste une introduction aux droits d'accès avec S3. Je vous encourage fortement à vous renseigner plus sur les droits d'accès si vous vous mettez à stocker des informations importantes à caractère personnel. Vous seriez tenus pour responsables en cas de mauvaise configuration, notamment depuis la règlementation européenne sur les données (voir RGPD).



User policy vs resource-based policy

Les droits d'accès à un bucket et ses fichiers sont déterminés par un processus assez complexe de policies (règles). Je vais tenter de vous le simplifier. 😜

Il y a 2 types de règles :

  • User policy : définit ce qu'un utilisateur a le droit de faire.
  • Resource-based policy : définit ce qu'on a le droit de faire sur un bucket ou un fichier.

... ça revient au même, non ?

Oui, mais la user policy est centrée sur l'utilisateur, tandis que la resource-based policy est centrée sur la ressource (le bucket ou le fichier).

Avec un exemple, ça sera sûrement plus clair :

  • User policy : "Jennifer a le droit de lire et modifier tous les fichiers dans le bucket A, ainsi que d'ajouter des fichiers PNG dans le bucket B".
  • Resource-based policy : "Dans le bucket A, Jennifer a le droit de lire et modifier tous les fichiers, tandis que Patrick a le droit uniquement d'ajouter des fichiers.".

A vous d'utiliser ce qui vous paraît le plus adapté à votre cas. Dans la suite de ce chapitre, je vous propose que l'on s'intéresse aux resource-based policies.

Les utilisateurs dans AWS sont créés via le service IAM (allez y faire un tour pour voir !). L'utilisateur principal dont vous vous servez actuellement est appelé "root". Il est recommandé de créer des utilisateurs IAM, plutôt que de passer par le compte root.



Structure d'une resource-based policy

Voici une policy très simple. Elles sont écrites au format JSON :



Décortiquons-la !

  • Version : c'est le numéro de version de la policy. Ne mettez pas la date du jour, copiez la même date que moi (ça revient en gros à dire "j'utilise la version 3 du système de policy").
  • Statement : ce sont les règles de la policy. Ici, il y en a une seule. Voyons ce que ça dit à l'intérieur :
    • Effect : Allow (autoriser) ou Deny (refuser). Par défaut, tout est refusé par sécurité. Il faut donc explicitement autoriser des choses.
    • Principal : le nom de l'utilisateur à qui on donne le droit. Ici, l'étoile * signifie "tout le monde, y compris le grand public sur internet sans compte AWS".
    • Action : c'est l'action qu'on veut autoriser (il peut y en avoir plusieurs). Ici, s3:GetObject permet de télécharger un objet (un fichier). La liste des actions peut être retrouvée dans la doc. Oui, il y en a beaucoup ! Parmi les plus importantes, citons :
      • s3:DeleteObject : autorise la suppression des fichiers
      • s3:GetObject : autorise la lecture des fichiers et leur téléchargement
      • s3:PutObject : autorise l'ajout de fichiers
      • s3:ListBucket : autorise la récupération du nom de tous les fichiers dans le bucket
      • s3:ListAllMyBuckets : autorise l'affichage de la liste de tous les buckets.
    • Resource : le nom de la ressource qui est autorisée. Il y a un format un peu spécial. Ici, arn:aws:s3:::examplebucket/* indique qu'on effectue l'autorisation sur tous les fichiers ( * ) du bucket nommé examplebucket .

Ecrire une policy S3 demande un peu d'entraînement. Là, vous avez vu une policy très simple. 😉

J'ai réfléchi à la question dans tous les sens, et je pense que le meilleur moyen de comprendre est encore de prendre des exemples. Voyons donc quelques exemples ensemble.



Exemples de policies

Apprenons à lire quelques policies !

Exemple 1


Cette policy autorise l'utilisateur Dave (créé sur AWS IAM) à lire un objet, connaître la localisation d'un bucket et à lister le contenu du bucket. Si vous vous demandez comment je connais la signification des actions, c'est parce que j'ai lu la doc, moi 😛). Les ressources qui sont affectées sont examplebucket et tous ses fichiers à l'intérieur.

Vous remarquerez qu'on peut donner des noms (Id, Sid) à la policy et à ses règles.


Exemple 2


Cette policy autorise tout le monde à lire les objets dans le dossier "public" de "my-brand-new-bucket". Cela veut dire que n'importe quel internaute pourra télécharger les fichiers du dossier "public" de ce bucket, s'il connaît son URL. Si vous hébergez les images de votre site sur S3, vous aurez sûrement besoin de donner ce genre de droit.

Cette policy donne aussi d'autres autorisations (vous pouvez voir qu'il y a 2 statements). Elle dit que Dave peut ajouter et supprimer des fichiers partout dans ce bucket.

En résumé : tout le monde peut lire les fichiers dans "public", mais seul Dave peut en ajouter ou en supprimer.



Activer une policy

Tout ça c'est bien beau, mais comment mettre en place les policies ?

Si vous voulez ajouter une policy au format JSON pour un bucket, comme on vient de le voir, il faut aller dans le bucket, onglet "Autorisations" / "Stratégies de compartiment" :



La policy ci-dessus autorise la lecture de fichiers par tout le monde dans le bucket. Elle rend donc le bucket public.

Une fois la policy enregistrée, elle est immédiatement activée (s'il n'y a pas d'erreurs). S3 m'avertit que du coup le bucket est public et qu'il faut être prudent de ne pas y partager de données confidentielles.

Il existe un générateur de policies en ligne, pour vous aider à les écrire.

Nous venons de voir une courte introduction aux règles d'accès dans S3. Cela devrait, je l'espère, vous aider à naviguer un peu au début (je vous avoue que j'étais complètement perdu moi quand j'ai démarré !). N'hésitez pas à lire la documentation pour vous renseigner plus en détails !

Dans le prochain chapitre, je vous propose de passer à la pratique et de créer un uploader de fichiers dans S3 en PHP !





Unité suivante : TP : le Cloud Uploader

Continue        
Retour