Découvrez les concepts de base de AWS IAM. Juste assez pour te faire démarrer, pas trop pour t’écraser avec le détail. Cet article est destiné aux débutants, mais peut également être un rafraîchissement utile pour les utilisateurs plus expérimentés.
AWS IAM est ce que je considère comme un service de base pour tout opérateur de cloud. C’est l’un des premiers, si ce n’est le premier service AWS, vous devriez apprendre juste là à côté des grands garçons comme Amazon S3 ou DynamoDB.
Dans ce billet de blog, je vais vous expliquer les fondamentaux de AWS IAM. Je vais couvrir assez de détails pour que vous puissiez frapper le terrain en cours de votre voyage dans AWS. Mais je ne vais pas vous écraser avec les détails de grain plus fin.
Nous commencerons par examiner les idées de base de l’IMA: Ressources, mesures et politiques .
De là, je vais décrire le processus d’autorisation de l’AM par un exemple. Nous parlerons brièvement des différentes méthodes d’interaction avec AWS qui sont facilitées par IAM (à travers la console, le CLI ou programmatiquement).
Ensuite, nous plongerons un peu plus profondément dans Ressources, Actions et Politiques en examinant un document de politique. Enfin, je vais vous expliquer quelques autres concepts importants, y compris Groupes, rôles, et Relations de confiance.
Alors, commençons…
Vous préférez un format vidéo? Regardez ma vidéo YouTube sur ce sujet ici. .
Un Primer Rapide
Avant de sauter dans les détails je veux prendre quelques instants pour couvrir certains des concepts de base pour décrire ce qui est à venir.
Tout d’abord, démystifier IAM. C’est vrai. Identité et Access Management et est le service qui réglemente l’accès aux ressources du SVA. Puisque l’accès aux ressources est l’une des choses les plus fondamentales que vous pouvez faire sur AWS, son compréhensible pourquoi ce sujet est si important.
Comment IAM fait ça ? Il s’avère qu’il y a 3 idées de base en jeu.
Core Idea 1 – Ressources
Ressources sont les entités que vous créez dans AWS. Cela peut inclure une chose comme un seau S3, un objet S3 ou une table DynamoDB. Toutes les ressources en AWS sont représentées par quelque chose appelé ARN ou A mazon R esource N Moi. Vous avez probablement vu un de ces identifiants avant, ils ressemblent un peu à ceci: arn:aws:s3:::test-website-awssimplified .
Tout au long de notre temps, nous nous référons constamment aux ARN. Ils sont la façon dont nous, en tant qu’utilisateurs, identifions les choses que nous créons dans AWS.
Core Idea 2 – Actions
Mesures à prendre sont les opérations que les utilisateurs tentent de réaliser sur les ressources. Par exemple, si j’ai créé une fonction lambda, je souhaiterais peut-être mettre à jour sa configuration. Pour cela, je dois utiliser une API appelée lambda:UpdateFunctionConfiguration . Pour effectuer cette action, j’ai besoin de permissions pour appeler cette API. Mais comment obtenir des permissions ?
La réponse se trouve dans la Politique …
Idée de base 3 – Document de politique / de politique
Le cœur de AWS IAM est le Politique . Les politiques de l’IAM renvoient des documents JSON spécifiques qui définissent les autorisations des utilisateurs pour accéder à une ressource. En d’autres termes, autorisation d’effectuer une Action est déterminé par si l’utilisateur a ou non le bon Document de politique générale avec les permissions associées.
Vous pouvez être un peu confus à propos de ces concepts, mais ne vous inquiétez pas, nous allons clarifier sous peu. Pour l’instant, rappelez-vous que l’IMA implique de garder l’accès à Ressources en contrôlant qui peut effectuer actions basé sur l’utilisateur politiques document .
Exemple – Gestion de l’accès à la création d’une fonction Lambda
Voyons de plus près ces concepts en regardant un exemple.
Supposons un instant que nous avons Utilisateur (dis-moi, Daniel) qui essaie de créer une fonction Lambda dans la console AWS. Comment AWS détermine si j’ai la permission de faire ça ?
La réponse se trouve dans la Politique qui est actuellement associé à cet utilisateur. Dans IAM, si un utilisateur n’a pas la permission explicite d’accéder à une ressource, ils ne pourront pas . Cela signifie que AWS IAM adopte une approche proactive – il nie tout par défaut à moins que vous spécifiez que quelque chose devrait avoir la permission.
Barre latérale – il y a aussi la possibilité de refuser explicitement l’accès à une ressource. Explicit Denial implique d’écrire une entrée dans votre document de politique qui appelle spécifiquement une API ou un groupe d’API auquel cet utilisateur ne devrait PAS avoir accès. Explicit Denies prend toujours la priorité sur Allows, donc s’il y a toujours un conflit, Deny gagnera.
Retour à notre point principal – AWS détermine si nous avons la permission d’effectuer une action sur une ressource si nous avons le document politique fourni associé à cet utilisateur.
Si un utilisateur ne avoir accès (implicit ou explicite), l’utilisateur sera accueilli avec le redouté Access Denied erreur. Si vous n’avez pas vu cette erreur dans vos voyages en nuage, préparez-vous, parce que je vous garantis.
Donc pour que cet utilisateur accède à cette lambda:CreateFunction est basé sur le document de politique de l’utilisateur. A quoi ressemble un document de politique ? Voyons un maintenant.
Examen d’un document de politique IAM
L’image ci-dessus est une Document de politique générale qui permettra à notre utilisateur de créer une fonction Lambda, mais pas beaucoup d’autre.
On inspecte certains éléments.
Version – C’est une valeur mystérieuse arbitraire et change rarement. Littéralement – sa valeur est toujours 2012-10-17. Pour tous les usages intensifs, cela n’a pas d’importance.
État – La déclaration contient la viande du document de politique. Comme on peut le voir dans l’image, il peut y avoir plusieurs déclarations dans un seul document de politique qui définit l’accès à différentes ressources.
SID – Stands for S tatement ID . Juste un identifiant unique pour votre déclaration.
Effect – Deux valeurs possibles, Indemnité ou Deny . Permettre d’être utilisé pour accorder l’accès, refuser d’être utilisé pour restreindre explicitement l’accès.
Action – L’opération AWS que vous essayez d’effectuer, habituellement 1:1 au nom de l’API. Les actions sont l’espace nom par le service. Par exemple, l’action de S3 pour créer un seau est – vous l’avez deviné – s3:createBucket.
Ressources – La ressource est l’élément auquel nous gardons accès. Nous pouvons spécifier un ARN spécifique d’une ressource pour définir les contrôles d’accès granulaires. Si nous voulons être plus libéraux, nous pouvons utiliser des wildcards représentés par des astérisques ( * ).
Principal – Une valeur optionnelle. Les directeurs nous aident à créer des politiques qui s’appliquent à certains utilisateurs, le cas échéant.
Espérons que cet exemple de base est clair pour vous et vous aide à comprendre quelques-unes des bases de la surveillance de l’accès aux AWS à travers IAM. Je veux rapidement prendre une pause et décrire certaines des autres méthodes pour vous identifier à AWS afin qu’il puisse déterminer qui vous êtes (aka authentification. Puisque nos politiques IAM sont principalement basées sur le concept d’un utilisateur, il est important de comprendre certains des vecteurs d’accès.
Accès aux AWS en utilisant votre utilisateur IAM
Afin d’interagir avec AWS, nous avons trois options :
- Par l’interface utilisateur Console – La façon dont vous avez utilisé AWS pour la première fois, en vous promenant sur la console de gestion AWS. Lorsque vous vous connectez à la console, vous pouvez soit le faire comme Root User (aka, signature dans l’utilisation de votre compte original créant e-mail), ou comme une normale Utilisateur via le portail d’accès au compte. Tous les comptes ont une URL unique pour utiliser vos identifiants d’utilisateur pour se connecter à la console. Les utilisateurs ont des documents de politique stockés contre eux, de sorte que vos autorisations sur AWS seront limitées à ce qui se trouve dans le document.
- Par le biais de l’AWS CLI – Probablement le deuxième moyen le plus populaire pour accéder à AWS. En utilisant l’AWS CLI, nous devons fournir notre
aws-access-keyetaws-secret-access-keycomme étape de configuration. Ce sont des chaînes alphanumériques qui sont uniques à chaque utilisateur et servent de leurs identifiants lors de l’accès programmatique AWS. Grâce au CLI, nous pouvons lancer des commandes pour appeler les API AWS. Encore une fois, notre accès est limité à ce qui est contenu dans le document politique de l’Utilisateur. - Programmatically Utiliser un SDK – Le dernier moyen est d’appeler les API AWS. Il existe de nombreux SDK fournis par AWS dans différentes langues de programmation populaires. En essayant d’accéder à une API programmatiquement et avec un SDK, nous avons besoin de créer un client, et habituellement l’instantaner avec notre
aws-access-keyetaws-secret-access-key.
Autre exemple – Gestion de l’accès à une table DynamoDB
Examinons un autre exemple plus intéressant qui utilise un couple d’autres caractéristiques de l’IAM. Ce document de politique sera permettre de lire seulement l’accès aux colonnes spécifiques d’une Dynamo Tableau DB .
Ce document de politique est semblable à l’exemple que nous avons examiné précédemment, mais a quelques caractéristiques intéressantes. Tout d’abord, notez que Action section, nous avons plusieurs actions énumérées ici. En outre, nous utilisons une wildcard pour le dynamodb: BatchGet* action.
Il est important de noter ici que les wildcards peuvent être utilisés dans de nombreuses parties du document politique, allant du principal, des ressources, à même une partie des actions elles-mêmes. Cette notation indique que toute action commençant par Batterie Allez ! sera autorisé selon ce document de politique. Par exemple, Batterie Allez-y. Ce serait une action autorisée ici.
Également avisé sous le Ressources section nous profitons davantage des wildcards dans cette déclaration: arn:aws:dynamodb:*:*:table/MyTable . Les deux * correspondent ici à la région et le numéro de compte. The table/MyTable la section dit que ces actions ne s’appliquent qu’à ce tableau particulier (ou à tout motif qui l’est). Les * sont ici utilisés pour remplacer région (c.-à-d. nous-est-1) et numéro de compte (c.-à-d. 755018473).
Cela signifie que les actions de la présente politique s’appliquent à un nom de table appelé MyTable qui peut exister dans n’importe quelle région et sous n’importe quel compte. Il s’agit d’une politique utile si vous disposez d’un environnement polyvalent et que vous cherchez à créer une politique permet à READ d’accéder à l’un de ces tableaux.
Enfin, le Conditions section de la politique permettent quelques fonctionnalités intéressantes. Conditions nous permettre de préciser le contexte dans lequel cette politique prend effet.
In the policy above, the parts under ForAllValues:StringEquals et les attributs énumérés ci-après indiquent à IAM que nous voulons limiter nos autorisations à un ensemble spécifique de noms de colonnes dans notre table. Il y a tout un tas d’autres clés de condition que nous pouvons utiliser autre que dynamodb:Attribute . Celui-ci en particulier est unique à dynamo et nous permet de restreindre l’accès au niveau de colonne.
La dernière partie, StringEqualsIfNotExists et correspondant dynamodb:Select la déclaration est une autre exigence pour permettre le contrôle d’accès au niveau de la colonne pour dynamo.
Ne vous inquiétez pas si vous ne comprenez pas trop sur Conditions . Vous pouvez vous rendre très loin dans votre parcours AWS avec une connaissance zéro ou limitée sur eux. Pour l’instant, sachez qu’ils existent et généralement ce qu’ils font. Si vous voulez en savoir plus sur eux, vous pouvez lire sur les docs IAM Condition ici. .
Autres concepts importants – Groupes, rôles et relations de confiance
Jusqu’à présent, je vous ai expliqué assez à propos de AWS IAM pour vous obtenir assez loin, mais il ya quelques autres concepts que vous pouvez rencontrer et devrait connaître. Allons les explorer maintenant.
Groupes
Les groupes IAM sont simplement une collection d’utilisateurs AWS. Ils sont un outil organisationnel important pour vous aider à attribuer des autorisations similaires à une collection d’utilisateurs à la fois. Vous pouvez visualiser ce concept dans l’image ci-dessous:
En utilisant des groupes, vous pouvez associer les utilisateurs ajoutés au groupe avec une politique IAM par défaut. Cela est vraiment utile si vous avez des collections d’utilisateurs qui nécessitent des niveaux de permission communs. Par exemple, je peux créer un groupe de « développeur interne » qui a des politiques très libérales sur le compte. Par contre, je peux avoir un groupe «Contracteur» qui a quelques autorisations étroites seulement applicables au projet sur lequel ils travaillent.
Vous pouvez utiliser des groupes dans un ensemble de façons d’organiser les utilisateurs et de contrôler l’accès aux ressources en une seule fois. Pour plus d’informations sur les groupes, consultez la documentation ici. .
Rôles
Les rôles sont similaires aux utilisateurs dans le sens où nous pouvons y joindre les politiques IAM. Cependant, contrairement aux Utilisateurs, les Rôles sont destinés à accorder un accès à court terme aux ressources. En d’autres termes, si je veux accorder un accès à court terme à un utilisateur pour fournir une fonction d’emploi, dire en tant qu’administrateur, je peux leur accorder la possibilité de assume un rôle spécifique. Ce faisant, l’utilisateur aura toutes les autorisations définies dans le document de politique de la règle présumée. Les rôles peuvent être utilisés par de nombreux utilisateurs et à la fois si nécessaire.
Les rôles peuvent être assumés par les utilisateurs et les autres services AWS. Par exemple, lors de la création d’une fonction Lambda, nous devons spécifier une fonction Rôle que la fonction Lambda utilisera. Si notre fonction doit accéder à DynamoDB par exemple, je devrai ajouter dynamodb spécifique Mesures à prendre au document de politique du rôle.
J’aime penser à Rôles comme porter de nombreux chapeaux différents. Nous pouvons assumer différents rôles à différents moments en fonction de notre fonction de travail ou quelque chose de court terme que nous pouvons essayer de faire. Fait intéressant, nous pouvons également créer des rôles qui permettent d’accéder à nos ressources des utilisateurs dans un différent Le compte AWS, qui est notre prochain sujet de discussion.
Relations de confiance
Relations de confiance ne sont pas tellement un concept de base de IAM, mais ils sont une source de problèmes que beaucoup de développeurs courent dans ce qui est pourquoi je pense qu’ils méritent discuter.
Relations de confiance nous permettre de créer Rôles qui permettent aux utilisateurs d’un compte DIFFERENT AWS d’y accéder temporairement. Par exemple, considérez un exemple comme nous avons ci-dessous où nous avons un compte avec une table DynamoDB, et un utilisateur d’un compte différent voulant y accéder.
La façon de donner accès à un utilisateur dans un compte différent n’est pas immédiatement claire. Pour cela, nous devons utiliser Relations de confiance et Rôles . Premièrement, nous devons aller à la console IAM et créer une relation de confiance entre ces deux comptes. Ce processus est bidirectionnel – le compte 1 a besoin d’une entrée disant « Compte de confiance 2 » et le compte 2 a besoin d’une entrée disant « Compte de confiance 1 ».
De plus, le compte 1 (qui détient la ressource qui tente d’être accessible) doit créer un Rôle qui a l’accès nécessaire. De là, nous devons accorder à l’utilisateur spécifique de Compte 2 la capacité à assume ce rôle. Un diagramme plus complet de ce processus peut être visualisé ci-dessous:
En tout, vous ne devriez généralement pas fournir un accès direct à vos ressources AWS par des tiers – cela devrait généralement être fait en exposant une API. Cependant, il y a certaines circonstances où l’accès partagé est logique, et les relations de confiance sont les moyens par lesquels l’AWS rend cela possible.
Pro Tips (comme appris par ma frustration)
Avant de résumer, je veux prendre quelques instants pour partager quelques conseils pro que j’ai recueillis au fil du temps. Ces astuces sont le résultat d’années d’expérience en utilisant AWS, et d’heures de frustration me tirant la tête contre le clavier essayant de comprendre « pourquoi mon X n’arrive-t-il pas mon Y ? ».
Conseil 1 – Protégez votre compte racine
Votre Root compte est le compte «propriétaire» de AWS. Il est généralement accédé en se dirigeant vers la page de connexion AWS et en vous connectant avec l’e-mail que vous avez utilisé pour enregistrer le compte à l’origine.
Le compte racine est spécial, comme le nœud de niveau supérieur dans une hiérarchie organisationnelle. En l’utilisant, vous avez des capacités spéciales comme la possibilité de révoquer ANY autre compte utilisateur, ou d’accéder aux informations de facturation de compte.
Si un mauvais acteur accède à votre compte racine – vous n’avez aucun recours en plus d’appeler ou d’envoyer un courriel à AWS lui-même pour vous aider. Si cela se produit, vous pourriez avoir des ennuis et peut avoir quelques factures surprise de AWS à traiter.
Prenez mes conseils et créez un compte utilisateur pour vos activités quotidiennes. Accordez-le Accès administratif et soyez en chemin. Ne fais pas Utilisez votre compte root pour un accès de jour en jour, vous me remercierez plus tard.
Astuce 2 – Explicit Deny gagne sur Explicit Allow
Comme nous l’avons mentionné précédemment, AWS IAM dispose de deux modes de contrôle d’accès: Permettre ou refuser . Si pour une raison quelconque vous êtes coincé dans un scénario où vous avez des politiques plafonnées contre vous qui ont les deux effets pour la même ressource, le Deny gagnera toujours. Cela peut se produire surtout lorsque vous assumez un rôle que vous ne connaissez pas, alors soyez conscient.
Ce seul problème m’a causé de nombreuses heures de maux de tête et de traumatisme. J’espère que ça pourra vous sauver un peu de temps.
Conseil 3 – Utiliser le modèle de privilège le moins élevé
Le modèle le moins privilégié est une sécurité commune suggère de n’accordez que le niveau d’accès requis pour exécuter la fonction nécessaire, et plus . En d’autres termes, ne soyez pas trop libéral avec vos politiques IAM et donnez accès à des actions telles que dynamodb:* par exemple (ceci donne accès à toutes les actions DynamoDB).
Faire si sur-expose votre application pour attaquer les vecteurs et les trous de sécurité si un mauvais acteur par hasard obtient accès à l’un de vos rôles ou utilisateurs IAM. Protégez-vous à l’avance et n’accordez accès qu’à ce qui est nécessaire.
Astuce 4 – Utiliser le simulateur de politique AWS pour le débogage IAM
Le simulateur de politique AWS est un outil utile construit par AWS qui vous aide à simuler des actions sur votre politique IAM. Il est particulièrement utile si vous êtes coincé dans un scénario où vous pensez votre politique should avoir accès à une certaine ressource, mais ne le fait pas.
En utilisant l’outil, vous pouvez sélectionner IAM Les utilisateurs que vous avez créés dans votre compte et les autorisations d’accès de test comme le montre le diagramme ci-dessous pour exécuter des simulations.
Policy Simulator can be accessed via https://policysim.aws.amazon.com. Assurez-vous de vous connecter à votre compte AWS pour le laisser accéder à IAM Profils d’utilisateur qui sont actuellement présents sur votre compte afin que vous puissiez exécuter des simulations.
Résumé
Dans cet article, je vous ai présenté les concepts de base IAM de base pour commencer à apprendre AWS. En résumé de la plupart des choses que nous avons apprises, rappelez-vous ce qui suit :
Si vous avez apprécié cet article consultez les autres que j’ai sur ce site, et si vous avez des questions ou des commentaires, assurez-vous de les laisser ci-dessous.