La pire erreur de sécurité que vous puissiez faire est peut-être de laisser des clés d'accès secrètes hautement confidentielles sur un serveur Web. Alors, quand vient le temps d'installer et d'authentifier l'AWS CLI sur une instance EC2 distante, comment la configurer?
Vous devriez utiliser des utilisateurs IAM
La réponse est définitivement pas à l'aide de vos clés d'accès root: ce sont les jetons les plus importants de votre compte et ils peuvent contourner tout périphérique d'authentification multifacteur que vous avez configuré. (Vous pouvez en fait configurer Accès API protégé par MFA mais pas pour le compte root.)
AWS fournit un service pour résoudre ce problème. La console «Identity and Access Management» (IAM) vous permet de créer des utilisateurs enfants séparés de votre compte racine. Il peut s'agir d'utilisateurs de services avec accès API ou de comptes utilisateur complets (avec accès à AWS Management Console) que vous pouvez utiliser pour les comptes d'employés.
Chaque utilisateur IAM a géré l'accès aux ressources AWS dans votre compte. L'accès est contrôlé par des stratégies, qui donnent un ensemble d'autorisations qui contrôlent ce que chaque utilisateur peut faire. Ces politiques approfondies peuvent contrôler à peu près toutes les actions que vous pouvez effectuer dans AWS Management Console.
Vous pouvez également définir manuellement une limite d'autorisations, qui agit comme une autorisation maximale qu'un utilisateur ne peut pas dépasser, en remplaçant toute stratégie qui pourrait lui accorder davantage. Il s'agit d'une fonctionnalité avancée utilisée pour déléguer la gestion des autorisations aux employés IAM et leur permet de créer des rôles de service supplémentaires sans élévation de privilèges.
Comment configurer les utilisateurs IAM
Du Console de gestion IAM, cliquez sur l'onglet "Utilisateurs" et sélectionnez "Ajouter un utilisateur".
Donnez-lui un nom, puis sélectionnez la manière dont vous souhaitez que cet utilisateur accède à AWS. L'accès par programme vous donne un ID de clé d'accès et une clé d'accès secrète, utilisés pour l'authentification avec l'API et la CLI AWS.
L'accès à la console de gestion permet à l'utilisateur d'accéder à la console Web, ce que vous activez si vous donnez l'accès aux employés. Si vous configurez cela, AWS donne par défaut un mot de passe généré automatiquement et oblige l'employé à le modifier lorsqu'il se connecte.
Vous pouvez donner les deux types d'accès si vous le souhaitez.
Ensuite, vous configurez les autorisations. AWS fournit de nombreuses stratégies prédéfinies, que vous pouvez attacher directement à l'utilisateur. Vous pouvez également créer un groupe et ajouter l'utilisateur à ce groupe, ce qui vous permet de gérer plus facilement plusieurs utilisateurs.
Vraiment, nous ne recommandons pas d'utiliser la plupart de ces règles prédéfinies. Vous ne voulez vraiment pas donner un "accès complet" à un service individuel, et l'autre alternative est généralement "lecture seule", qui n'est probablement pas un accès suffisant en soi. Certaines des autorisations les plus précises conviennent, mais vous devez vraiment créer les vôtres.
Vous comprendrez rapidement pourquoi le "Full Access" est une mauvaise idée. Supposons que vous configuriez un serveur qui doit accéder à S3 et télécharger des objets. Vous voudrez peut-être lui donner un accès "Écriture", mais cela permet également à cet utilisateur de supprimer des compartiments entiers, ce qui n'est pas du tout idéal. Une meilleure solution consiste à donner la permission «PutObject», qui permet de faire des requêtes PUT.
Ces autorisations sont assez intensives et varient d'un service à l'autre, mais vous pouvez toujours cliquer sur le point d'interrogation à côté du nom de l'autorisation pour afficher une définition rapide. Sinon, vous pouvez lire notre guide sur les autorisations IAM pour en savoir plus.
Vous pouvez (et devriez probablement) restreindre l'accès à certaines ressources par leur Amazon Resource Name (ARN), qui désactive l'accès à l'échelle du compte. Il existe également certaines conditions que vous pouvez associer aux autorisations, telles que la date et l'heure, qu'AWS vérifie avant de permettre à une action de se produire.
Une fois que vous avez terminé d'attacher les autorisations, vous pouvez créer l'utilisateur (éventuellement en ajoutant d'abord des balises). Vous êtes amené à un écran où vous pouvez télécharger ou copier les clés d'accès, et si vous ajoutez l'accès à la console de gestion, un lien de connexion apparaîtra que vous pourrez envoyer à l'employé qui détient le compte.
Remplacez votre compte racine par un utilisateur IAM
AWS le recommande vivement pour les comptes d'entreprise. Au lieu d'utiliser votre compte root pour des choses telles que votre CLI personnelle, vous devez créer un utilisateur IAM «Administrateur» avec accès à la console de gestion et utiliser le jeton d'accès pour authentifier votre terminal personnel.
Cela ne signifie pas que vous devez traiter les informations d'identification de cet utilisateur IAM comme étant moins sécurisées que votre compte racine. Cela vous gâcherait toujours la journée si votre compte administrateur était compromis, vous devez donc continuer à utiliser les comptes de service pour les applications distantes, et vous devriez activez toujours définitivement l'authentification multifacteur pour votre compte administrateur IAM. Cependant, l'utilisation d'un utilisateur IAM au lieu du compte racine est plus sécurisée, car il existe certaines actions à l'échelle du compte que seul le compte racine réel peut effectuer.
Avec cette configuration, la seule chose pour laquelle vous utilisez votre compte root est les éléments super-sécurisés qui sont directement liés à votre compte root, comme la maintenance du compte et la facturation. Pour tout le reste, les autorisations d'administrateur suffisent et vous permettent de supprimer vos clés d'accès root afin que vous ne puissiez accéder au compte root qu'en vous connectant manuellement (et en passant MFA).