AWS - Basic Information
Hiérarchie de l'organisation
Comptes
Dans AWS, il y a un compte racine, qui est le conteneur parent pour tous les comptes de votre organisation. Cependant, vous n'avez pas besoin d'utiliser ce compte pour déployer des ressources, vous pouvez créer d'autres comptes pour séparer différents AWS infrastructures entre eux.
Cela est très intéressant d'un point de vue sécurité, car un compte ne pourra pas accéder aux ressources d'un autre compte (sauf si des ponts sont spécifiquement créés), de cette manière, vous pouvez créer des frontières entre les déploiements.
Par conséquent, il existe deux types de comptes dans une organisation (nous parlons de comptes AWS et non de comptes utilisateur) : un seul compte désigné comme compte de gestion, et un ou plusieurs comptes membres.
Le compte de gestion (le compte racine) est le compte que vous utilisez pour créer l'organisation. À partir du compte de gestion de l'organisation, vous pouvez faire ce qui suit :
Créer des comptes dans l'organisation
Inviter d'autres comptes existants à rejoindre l'organisation
Supprimer des comptes de l'organisation
Gérer les invitations
Appliquer des politiques aux entités (racines, UO ou comptes) au sein de l'organisation
Activer l'intégration avec les services AWS pris en charge pour fournir des fonctionnalités de service dans tous les comptes de l'organisation.
Il est possible de se connecter en tant qu'utilisateur racine en utilisant l'e-mail et le mot de passe utilisés pour créer ce compte racine/organisation.
Le compte de gestion a les responsabilités d'un compte payeur et est responsable du paiement de toutes les charges accumulées par les comptes membres. Vous ne pouvez pas changer le compte de gestion d'une organisation.
Les comptes membres constituent tous les autres comptes d'une organisation. Un compte ne peut être membre que d'une seule organisation à la fois. Vous pouvez attacher une politique à un compte pour appliquer des contrôles à ce seul compte.
Les comptes membres doivent utiliser une adresse e-mail valide et peuvent avoir un nom, en général ils ne pourront pas gérer la facturation (mais ils pourraient y avoir accès).
Unités d'organisation
Les comptes peuvent être regroupés dans des Unités d'organisation (OU). De cette manière, vous pouvez créer des politiques pour l'Unité d'organisation qui seront appliquées à tous les comptes enfants. Notez qu'une OU peut avoir d'autres OUs comme enfants.
Politique de contrôle de service (SCP)
Une politique de contrôle de service (SCP) est une politique qui spécifie les services et actions que les utilisateurs et rôles peuvent utiliser dans les comptes affectés par le SCP. Les SCP sont similaires aux politiques de permissions IAM sauf qu'ils ne accordent aucune permission. Au lieu de cela, les SCP spécifient les permissions maximales pour une organisation, une unité organisationnelle (OU) ou un compte. Lorsque vous attachez un SCP à la racine de votre organisation ou à une OU, le SCP limite les permissions pour les entités dans les comptes membres.
C'est la SEULE façon de même empêcher l'utilisateur root de faire quelque chose. Par exemple, cela pourrait être utilisé pour empêcher les utilisateurs de désactiver CloudTrail ou de supprimer des sauvegardes. La seule façon de contourner cela est de compromettre également le compte principal qui configure les SCP (le compte principal ne peut pas être bloqué).
Notez que les SCPs ne restreignent que les principaux dans le compte, donc les autres comptes ne sont pas affectés. Cela signifie qu'un SCP refusant s3:GetObject
n'empêchera pas les gens d'accéder à un compartiment S3 public dans votre compte.
Exemples de SCP :
Refuser l'accès complet au compte root
Autoriser uniquement des régions spécifiques
Autoriser uniquement des services autorisés
Refuser la désactivation de GuardDuty, CloudTrail et l'accès public à S3
Refuser la suppression ou la modification des rôles de sécurité/intervention en cas d'incident
Refuser la suppression des sauvegardes
Refuser la création d'utilisateurs IAM et de clés d'accès
Trouvez des exemples JSON sur https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html
ARN
Amazon Resource Name est le nom unique que chaque ressource à l'intérieur d'AWS possède, il est composé comme suit :
Notez qu'il y a 4 partitions dans AWS mais seulement 3 façons de les appeler :
AWS Standard :
aws
AWS Chine :
aws-cn
AWS Internet public US (GovCloud) :
aws-us-gov
AWS Secret (US Classified) :
aws
IAM - Identity and Access Management
IAM est le service qui vous permet de gérer l'Authentification, l'Autorisation et le Contrôle d'Accès à l'intérieur de votre compte AWS.
Authentification - Processus de définition d'une identité et de vérification de cette identité. Ce processus peut être subdivisé en : Identification et vérification.
Autorisation - Détermine ce à quoi une identité peut accéder dans un système une fois qu'elle y est authentifiée.
Contrôle d'Accès - La méthode et le processus par lesquels l'accès est accordé à une ressource sécurisée.
IAM peut être défini par sa capacité à gérer, contrôler et gouverner les mécanismes d'authentification, d'autorisation et de contrôle d'accès des identités à vos ressources dans votre compte AWS.
Lorsque vous créez un compte Amazon Web Services (AWS) pour la première fois, vous commencez avec une identité de connexion unique qui a un accès complet à tous les services et ressources AWS dans le compte. Il s'agit de l'utilisateur racine du compte AWS et on y accède en se connectant avec l'adresse e-mail et le mot de passe que vous avez utilisés pour créer le compte.
Notez qu'un nouveau utilisateur administrateur aura moins de permissions que l utilisateur racine.
D'un point de vue sécurité, il est recommandé de créer d'autres utilisateurs et d'éviter d'utiliser celui-ci.
Un utilisateur IAM est une entité que vous créez dans AWS pour représenter la personne ou l'application qui l'utilise pour interagir avec AWS. Un utilisateur dans AWS se compose d'un nom et de justificatifs d'identité (mot de passe et jusqu'à deux clés d'accès).
Lorsque vous créez un utilisateur IAM, vous lui accordez des permissions en le plaçant dans un groupe d'utilisateurs ayant des politiques de permission appropriées attachées (recommandé), ou en attachant directement des politiques à l'utilisateur.
Les utilisateurs peuvent avoir l'authentification multifacteur (MFA) activée pour se connecter via la console. Les jetons API des utilisateurs MFA activés ne sont pas protégés par MFA. Si vous souhaitez restreindre l'accès aux clés API d'un utilisateur en utilisant MFA, vous devez indiquer dans la politique que pour effectuer certaines actions, MFA doit être présent (exemple ici).
CLI
ID de clé d'accès : 20 caractères alphanumériques majuscules aléatoires comme AKHDNAPO86BSHKDIRYT
ID de clé d'accès secrète : 40 caractères aléatoires en majuscules et minuscules : S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Il n'est pas possible de récupérer les ID de clé d'accès secrète perdus).
Chaque fois que vous devez changer la clé d'accès, voici le processus à suivre : Créer une nouvelle clé d'accès -> Appliquer la nouvelle clé au système/application -> marquer l'originale comme inactive -> Tester et vérifier que la nouvelle clé d'accès fonctionne -> Supprimer l'ancienne clé d'accès
MFA - Authentification Multifacteur
Elle est utilisée pour créer un facteur supplémentaire pour l'authentification en plus de vos méthodes existantes, telles que le mot de passe, créant ainsi un niveau d'authentification multifacteur. Vous pouvez utiliser une application virtuelle gratuite ou un appareil physique. Vous pouvez utiliser des applications comme Google Authenticator gratuitement pour activer un MFA dans AWS.
Les politiques avec des conditions MFA peuvent être attachées aux éléments suivants :
Un utilisateur ou groupe IAM
Une ressource telle qu'un compartiment Amazon S3, une file d'attente Amazon SQS ou un sujet Amazon SNS
La politique de confiance d'un rôle IAM qui peut être assumé par un utilisateur
Si vous souhaitez accéder via CLI à une ressource qui vérifie la MFA, vous devez appeler GetSessionToken
. Cela vous donnera un jeton avec des informations sur la MFA.
Notez que les informations d'identification AssumeRole
ne contiennent pas cette information.
Comme indiqué ici, il existe de nombreux cas où MFA ne peut pas être utilisé.
Un groupe d'utilisateurs IAM est une manière d'attacher des stratégies à plusieurs utilisateurs en une seule fois, ce qui peut faciliter la gestion des autorisations pour ces utilisateurs. Les rôles et les groupes ne peuvent pas faire partie d'un groupe.
Vous pouvez attacher une stratégie basée sur l'identité à un groupe d'utilisateurs afin que tous les utilisateurs du groupe d'utilisateurs reçoivent les autorisations de la stratégie. Vous ne pouvez pas identifier un groupe d'utilisateurs en tant que Principal
dans une stratégie (comme une stratégie basée sur les ressources) car les groupes sont liés aux autorisations, pas à l'authentification, et les principaux sont des entités IAM authentifiées.
Voici quelques caractéristiques importantes des groupes d'utilisateurs :
Un groupe d'utilisateurs peut contenir de nombreux utilisateurs, et un utilisateur peut appartenir à plusieurs groupes.
Les groupes d'utilisateurs ne peuvent pas être imbriqués ; ils peuvent contenir uniquement des utilisateurs, pas d'autres groupes d'utilisateurs.
Il n'existe pas de groupe d'utilisateurs par défaut qui inclut automatiquement tous les utilisateurs du compte AWS. Si vous souhaitez avoir un groupe d'utilisateurs de ce type, vous devez le créer et attribuer chaque nouvel utilisateur à ce groupe.
Le nombre et la taille des ressources IAM dans un compte AWS, tels que le nombre de groupes et le nombre de groupes dont un utilisateur peut être membre, sont limités. Pour plus d'informations, consultez les quotas IAM et AWS STS.
Un rôle IAM est très similaire à un utilisateur, en ce sens qu'il s'agit d'une identité avec des stratégies d'autorisation qui déterminent ce qu'il peut et ne peut pas faire dans AWS. Cependant, un rôle n'a pas de (mot de passe ou clés d'accès) associés. Au lieu d'être associé de manière unique à une personne, un rôle est destiné à être assumé par quiconque en a besoin (et a suffisamment d'autorisations). Un utilisateur IAM peut assumer un rôle pour prendre temporairement des autorisations différentes pour une tâche spécifique. Un rôle peut être assigné à un utilisateur fédéré qui se connecte en utilisant un fournisseur d'identité externe au lieu d'IAM.
Un rôle IAM se compose de deux types de stratégies : Une stratégie de confiance, qui ne peut pas être vide, définissant qui peut assumer le rôle, et une stratégie d'autorisations, qui ne peut pas être vide, définissant ce à quoi il peut accéder.
Service de jetons de sécurité AWS (STS)
Le service de jetons de sécurité AWS (STS) est un service web qui facilite l'émission de jetons d'accès temporaires à privilèges limités. Il est spécifiquement conçu pour :
Les jetons d'accès temporaires sont principalement utilisés avec les rôles IAM, mais il existe également d'autres utilisations. Vous pouvez demander des jetons d'accès temporaires qui ont un ensemble de permissions plus restreint que votre utilisateur IAM standard. Cela vous empêche d'effectuer accidentellement des tâches non autorisées par les autorisations plus restreintes. Un avantage des jetons d'accès temporaires est qu'ils expirent automatiquement après une période définie. Vous avez le contrôle sur la durée pendant laquelle les jetons sont valides.
Stratégies
Autorisations de stratégie
Sont utilisées pour attribuer des autorisations. Il existe 2 types :
Stratégies gérées par AWS (préconfigurées par AWS)
Stratégies gérées par le client : Configurées par vous. Vous pouvez créer des stratégies basées sur les stratégies gérées par AWS (en modifiant l'une d'entre elles et en créant la vôtre), en utilisant le générateur de stratégies (une vue GUI qui vous aide à accorder et refuser des autorisations) ou en écrivant la vôtre.
Par défaut, l'accès est refusé, l'accès sera accordé si un rôle explicite a été spécifié. Si un seul "Refus" existe, il remplacera l'"Autorisation", sauf pour les demandes utilisant les informations d'identification de sécurité racine du compte AWS (qui sont autorisées par défaut).
Les champs globaux pouvant être utilisés pour des conditions dans n'importe quel service sont documentés ici. Les champs spécifiques pouvant être utilisés pour des conditions par service sont documentés ici.
Politiques en ligne
Ce type de politiques est directement attribué à un utilisateur, un groupe ou un rôle. Ensuite, elles n'apparaissent pas dans la liste des politiques comme les autres peuvent les utiliser. Les politiques en ligne sont utiles si vous souhaitez maintenir une relation stricte de un à un entre une politique et l'identité à laquelle elle est appliquée. Par exemple, vous voulez vous assurer que les autorisations dans une politique ne sont pas attribuées par inadvertance à une identité autre que celle pour laquelle elles sont destinées. Lorsque vous utilisez une politique en ligne, les autorisations dans la politique ne peuvent pas être attachées par inadvertance à la mauvaise identité. De plus, lorsque vous utilisez la console de gestion AWS pour supprimer cette identité, les politiques intégrées à l'identité sont également supprimées. C'est parce qu'elles font partie de l'entité principale.
Politiques de compartiment de ressources
Ce sont des politiques qui peuvent être définies dans des ressources. Toutes les ressources d'AWS ne les prennent pas en charge.
Si un principal n'a pas de refus explicite sur eux, et qu'une politique de ressource leur accorde l'accès, alors ils sont autorisés.
Limites IAM
Les limites IAM peuvent être utilisées pour limiter les autorisations auxquelles un utilisateur ou un rôle devrait avoir accès. De cette manière, même si un ensemble différent d'autorisations est accordé à l'utilisateur par une politique différente, l'opération échouera s'il essaie de les utiliser.
Une limite est simplement une politique attachée à un utilisateur qui indique le niveau maximum d'autorisations que l'utilisateur ou le rôle peut avoir. Ainsi, même si l'utilisateur a un accès administrateur, si la limite indique qu'il ne peut lire que des compartiments S3, c'est le maximum qu'il peut faire.
Cela, les SCPs et le suivi du principe du moindre privilège sont les moyens de contrôler que les utilisateurs n'ont pas plus d'autorisations que celles dont ils ont besoin.
Politiques de session
Une politique de session est une politique définie lorsqu'un rôle est assumé d'une manière ou d'une autre. Cela sera comme une limite IAM pour cette session : Cela signifie que la politique de session ne confère pas d'autorisations mais les restreint à celles indiquées dans la politique (les autorisations maximales étant celles que le rôle possède).
Cela est utile pour des mesures de sécurité : Lorsqu'un administrateur va assumer un rôle très privilégié, il pourrait restreindre les autorisations uniquement à celles indiquées dans la politique de session au cas où la session serait compromise.
Notez que par défaut AWS peut ajouter des stratégies de session aux sessions qui vont être générées en raison de tiers raisons. Par exemple, dans les rôles supposés Cognito non authentifiés par défaut (en utilisant l'authentification améliorée), AWS générera des informations de session avec une politique de session qui limite les services auxquels la session peut accéder à la liste suivante.
Par conséquent, si à un moment donné vous rencontrez l'erreur "... car aucune politique de session ne permet le ...", et que le rôle a accès pour effectuer l'action, c'est parce qu'il y a une politique de session qui l'empêche.
Fédération d'identité
La fédération d'identité permet aux utilisateurs des fournisseurs d'identité externes à AWS d'accéder de manière sécurisée aux ressources AWS sans avoir à fournir les informations d'identification utilisateur AWS à partir d'un compte IAM utilisateur valide. Un exemple de fournisseur d'identité peut être votre propre Active Directory Microsoft (via SAML) ou des services OpenID (comme Google). L'accès fédéré permettra ensuite aux utilisateurs de l'utiliser pour accéder à AWS.
Pour configurer cette confiance, un fournisseur d'identité IAM est généré (SAML ou OAuth) qui fait confiance à l'autre plateforme. Ensuite, au moins un rôle IAM est attribué (de confiance) au fournisseur d'identité. Si un utilisateur de la plateforme de confiance accède à AWS, il accèdera en tant que le rôle mentionné.
Cependant, vous voudrez généralement attribuer un rôle différent en fonction du groupe de l'utilisateur dans la plateforme tierce. Ensuite, plusieurs rôles IAM peuvent faire confiance au fournisseur d'identité tiers et la plateforme tierce permettra aux utilisateurs d'assumer tel ou tel rôle.
Centre d'identité IAM
Le Centre d'identité IAM AWS (successeur de la connexion unique AWS) étend les capacités de la gestion des identités et des accès AWS (IAM) pour fournir un endroit centralisé qui regroupe l'administration des utilisateurs et de leur accès aux comptes AWS et aux applications cloud.
Le domaine de connexion sera quelque chose comme <user_input>.awsapps.com
.
Pour connecter les utilisateurs, il existe 3 sources d'identité qui peuvent être utilisées :
Répertoire du Centre d'identité : Utilisateurs AWS réguliers
Active Directory : Prend en charge différents connecteurs
Fournisseur d'identité externe : Tous les utilisateurs et groupes proviennent d'un fournisseur d'identité externe (IdP)
Dans le cas le plus simple du répertoire du Centre d'identité, le Centre d'identité aura une liste d'utilisateurs et de groupes et pourra leur attribuer des politiques pour n'importe quel compte de l'organisation.
Pour donner accès à un utilisateur/groupe du Centre d'identité à un compte, un fournisseur d'identité SAML faisant confiance au Centre d'identité sera créé, et un rôle faisant confiance au fournisseur d'identité avec les politiques indiquées sera créé dans le compte de destination.
AwsSSOInlinePolicy
Il est possible de donner des autorisations via des politiques intégrées aux rôles créés via le Centre d'identité IAM. Les rôles créés dans les comptes auxquels des politiques intégrées sont attribuées dans le Centre d'identité AWS auront ces autorisations dans une politique intégrée appelée AwsSSOInlinePolicy
.
Par conséquent, même si vous voyez 2 rôles avec une politique intégrée appelée AwsSSOInlinePolicy
, cela ne signifie pas qu'ils ont les mêmes autorisations.
Confiances et rôles intercomptes
Un utilisateur (de confiance) peut créer un rôle intercomptes avec certaines politiques, puis autoriser un autre utilisateur (de confiance) à accéder à son compte mais seulement avec l'accès indiqué dans les nouvelles politiques de rôle. Pour créer cela, créez simplement un nouveau rôle et sélectionnez Rôle intercomptes. Les rôles pour l'accès intercomptes offrent deux options. Fournir un accès entre les comptes AWS que vous possédez et fournir un accès entre un compte que vous possédez et un compte AWS tiers. Il est recommandé de spécifier l'utilisateur de confiance et de ne pas mettre quelque chose de générique car sinon, d'autres utilisateurs authentifiés comme les utilisateurs fédérés pourront également abuser de cette confiance.
AWS Simple AD
Non pris en charge :
Relations de confiance
Centre d'administration AD
Prise en charge complète de l'API PS
Corbeille AD
Comptes de service gérés par groupe
Extensions de schéma
Pas d'accès direct au système d'exploitation ou aux instances
Fédération Web ou Authentification OpenID
L'application utilise AssumeRoleWithWebIdentity pour créer des informations d'identification temporaires. Cependant, cela ne donne pas accès à la console AWS, seulement aux ressources dans AWS.
Autres options IAM
Vous pouvez définir une politique de mot de passe avec des options comme la longueur minimale et les exigences de mot de passe.
Vous pouvez télécharger un "Rapport d'informations d'identification" avec des informations sur les informations d'identification actuelles (comme l'heure de création de l'utilisateur, si le mot de passe est activé...). Vous pouvez générer un rapport d'informations d'identification aussi souvent que toutes les quatre heures.
La gestion des identités et des accès AWS (IAM) offre un contrôle d'accès fin sur l'ensemble d'AWS. Avec IAM, vous pouvez spécifier qui peut accéder à quels services et ressources, et dans quelles conditions. Avec les politiques IAM, vous gérez les autorisations de votre personnel et de vos systèmes pour garantir des autorisations minimales.
Préfixes d'ID IAM
Dans cette page vous pouvez trouver les préfixes d'ID IAM des clés en fonction de leur nature :
ABIA | |
ACCA | Information d'identification spécifique au contexte |
AGPA | Groupe d'utilisateurs |
AIDA | Utilisateur IAM |
AIPA | Profil d'instance Amazon EC2 |
AKIA | Clé d'accès |
ANPA | Politique gérée |
ANVA | Version dans une politique gérée |
APKA | Clé publique |
AROA | Rôle |
ASCA | Certificat |
ASIA | Identifiants de clé d'accès temporaires (AWS STS) utilisent ce préfixe, mais sont uniques uniquement en combinaison avec la clé d'accès secrète et le jeton de session. |
Autorisations recommandées pour auditer les comptes
Les privilèges suivants accordent divers accès en lecture des métadonnées :
arn:aws:iam::aws:policy/SecurityAudit
arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
codebuild:ListProjects
config:Describe*
cloudformation:ListStacks
logs:DescribeMetricFilters
directconnect:DescribeConnections
dynamodb:ListTables
Divers
Authentification CLI
Pour qu'un utilisateur régulier s'authentifie à AWS via CLI, vous devez avoir des informations d'identification locales. Par défaut, vous pouvez les configurer manuellement dans ~/.aws/credentials
ou en exécutant aws configure
.
Dans ce fichier, vous pouvez avoir plus d'un profil, si aucun profil n'est spécifié en utilisant le cli aws, celui appelé [default]
dans ce fichier sera utilisé.
Exemple de fichier d'informations d'identification avec plus d'un profil:
Si vous devez accéder à différents comptes AWS et que votre profil a reçu l'autorisation de supposer un rôle à l'intérieur de ces comptes, vous n'avez pas besoin d'appeler manuellement STS à chaque fois (aws sts assume-role --role-arn <role-arn> --role-session-name sessname
) et de configurer les informations d'identification.
Vous pouvez utiliser le fichier ~/.aws/config
pour indiquer les rôles à assumer, puis utiliser le paramètre --profile
comme d'habitude (l'assume-role
sera effectué de manière transparente pour l'utilisateur).
Un exemple de fichier de configuration :
Avec ce fichier de configuration, vous pouvez ensuite utiliser aws cli comme suit :
Si vous recherchez quelque chose de similaire mais pour le navigateur, vous pouvez consulter l'extension AWS Extend Switch Roles.
Références
Dernière mise à jour