L'AWS IAM Management Console répertorie plus de 500 stratégies basées sur des autorisations attribuables que vous pouvez donner pour permettre à vos utilisateurs IAM d'accéder à différents services. Que font-ils tous et comment pouvez-vous configurer le vôtre?

Vous devez toujours affiner vos autorisations

Tout d’abord, c’est une très mauvaise idée d’utiliser vos identifiants root pour tout. AWS vous recommande de créer un utilisateur IAM administrateur avec un accès à la console (avec lequel vous pouvez vous connecter) pour gérer votre compte et d'utiliser uniquement vos informations d'identification racine pour la maintenance du compte.

Mais pour tout ce qui n'est pas votre propre ordinateur personnel, vous devez configurer des autorisations basées sur l'accès pour tout service distant qui doit se connecter à AWS. Même si vous êtes une équipe composée d'une seule personne, votre serveur ne doit pas avoir accès administrateur à l'ensemble de votre compte.

L'accès en lecture seule fonctionne bien pour les applications qui n'apportent aucune modification. Donner un accès en écriture est plus dangereux que vous ne le pensez. L'accès en écriture signifie le privilège de supprimer des fichiers et de mettre fin aux instances, ce que vous ne voudrez peut-être pas que ce compte fasse.

En général, chaque fois que vous devez lier l'AWS CLI à une machine distante, vous devez créer un nouvel utilisateur IAM et lui donner uniquement les autorisations dont il a besoin pour fonctionner. Il est également judicieux de reconfigurer votre CLI personnelle avec:

aws configurer

pour correspondre aux autorisations que vous prévoyez d'utiliser sur le serveur, afin de ne pas rencontrer de problèmes d'autorisations incompatibles lors des tests.

Quelles autorisations dois-je utiliser?

Vous pouvez parcourir cette liste d'autorisations à partir du Console de gestion IAM, sous l'onglet «Politiques»:

En règle générale, pour la plupart des services, il y aura une autorisation «lecture seule» et une autorisation «accès complet». Par exemple, S3 a "AmazonS3FullAccess" et "AmazonS3ReadOnlyAccess«. Ils sont tous gérés par Amazon, mais la plupart sont simplement ici en tant que modèles. Il est préférable de créer vos propres politiques.

Par exemple, chaque autorisation active un ensemble spécifique d'actions; vous pouvez les afficher plus en détail en cliquant dessus et en sélectionnant «JSON», qui affiche une liste complète de tout ce que l'autorisation autorise. Par exemple, le "AmazonDMSRedshiftS3Role”La politique donne les autorisations suivantes:

Votre service n'a probablement pas besoin d'accéder à tout, donc plutôt que d'essayer de trouver la stratégie spécifique qui fonctionne le mieux, vous devez créer votre propre stratégie pour restreindre l'accès autant que possible. Si vous ne souhaitez pas faire cela, vous devez – à tout le moins – limiter l'accès au service concerné plutôt que de donner un accès complet à tout.

Vous devez créer vos propres politiques

Si les règles par défaut ne disposent pas des autorisations spécifiques souhaitées, vous pouvez créer vos propres règles. Par exemple, si vous disposez d'un service qui doit importer des éléments sur S3, vous ne pouvez pas lui donner un accès en lecture seule, mais il ne doit pas non plus avoir un accès complet. Vous pouvez définir une nouvelle stratégie qui lui permettra uniquement de télécharger des objets dans un compartiment spécifique.

Cliquez sur «Créer une politique» dans le navigateur de politiques. Vous pouvez les modifier au format JSON, mais l'éditeur visuel est beaucoup plus simple. Sélectionnez un service; nous avons sélectionné S3 pour cet exemple. Chaque politique s'applique à un service spécifique; si vous devez attribuer plusieurs autorisations à une application, vous devez créer des stratégies distinctes pour chaque service.

Ensuite, vous sélectionnez les autorisations souhaitées, en fonction de différents niveaux d'accès (liste, lecture, étiquette, écriture). Celui que vous recherchez est "PutObject", qui permet de télécharger des objets. Vous pouvez voir ici comment donner un accès en écriture à une application comme celle-ci est une mauvaise idée; il n'a vraiment besoin que d'une seule autorisation, mais s'il avait un accès en écriture complet, il aurait toutes les autorisations de cette liste.

Comme vous pouvez le voir, il y a un lot plus d'autorisations individuelles que les politiques par défaut. Nous ne pouvons pas tous les expliquer, mais heureusement, AWS le rend facile à comprendre. Clique le ? icône à côté de l'autorisation que vous souhaitez connaître, et il fera apparaître une barre latérale avec une description rapide. Si cela ne suffit pas, vous pouvez cliquer sur "En savoir plus" pour accéder à la page de documentation relative à cette autorisation.

Lorsque vous avez sélectionné toutes les autorisations souhaitées, vous pouvez désormais restreindre l'accès à des ressources spécifiques ou choisir d'activer les autorisations pour n'importe quelle ressource. Dans cet exemple, notre application n'a peut-être besoin que d'importer des fichiers dans un bucket spécifique et n'a pas besoin d'accéder à d'autres buckets que vous possédez ou que vous pourriez créer à l'avenir.

Vous pouvez choisir des ressources en sélectionnant "Ajouter ARN" pour restreindre l'accès:

Vous devez entrer le nom de ressource Amazon (ARN) de l'objet auquel vous souhaitez donner accès. Heureusement, l'éditeur de règles facilite cette tâche et propose une boîte de dialogue personnalisée qui demande simplement le nom ou l'ID de la ressource; dans ce cas, vous pouvez saisir le nom du bucket:

Pour aller encore plus loin, vous pouvez activer la liste blanche afin que les requêtes doivent toujours provenir de votre serveur. Si vous activez l'accès pour un service distant et que l'adresse IP de votre serveur ne changera pas de sitôt, il est judicieux de l'activer.

Vous pouvez également exiger que l'authentification multifacteur soit activée pour que la stratégie s'applique, ce qui n'est pertinent que pour les comptes d'utilisateurs réels ayant accès à la console.

Si vous cliquez sur "Ajouter une condition", vous pouvez spécifier des conditions étendues que la demande doit remplir avant d'être approuvée, comme n'autoriser l'accès que le jeudi, si c'est ce que vous souhaitez.

Une fois que vous avez terminé, cliquez sur Suivant pour examiner la politique et donnez-lui un nom et une description. Cliquez sur «Créer une politique», et elle devrait être visible et assignable aux utilisateurs dans la liste des politiques.