Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Sécurité et autorisations
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Chacun de vos utilisateurs doit disposer des AWS informations d'identification appropriées pour accéder aux AWS ressources de votre compte. La méthode recommandée pour fournir des informations d'identification aux utilisateurs est d'utiliser [Gestion des identités et des accès AWS](https://docs.aws.amazon.com/iam/)(IAM). OpsWorks Stacks s'intègre à IAM pour vous permettre de contrôler les éléments suivants :
+ Comment les utilisateurs individuels peuvent interagir avec OpsWorks Stacks.
Par exemple, vous pouvez autoriser certains utilisateurs à déployer des applications sur n'importe quelle pile, mais pas à modifier la pile elle-même, tout en accordant à d'autres utilisateurs un accès complet, mais uniquement à certaines piles, etc.
+ Comment OpsWorks Stacks peut agir en votre nom pour accéder aux ressources du stack telles que les EC2 instances Amazon et les buckets Amazon S3.
OpsWorks Stacks fournit un rôle de service qui accorde des autorisations pour ces tâches.
+ Comment les applications exécutées sur des EC2 instances Amazon contrôlées par OpsWorks Stacks peuvent accéder à d'autres AWS ressources, telles que les données stockées dans des compartiments Amazon S3.
Vous pouvez attribuer un profil d'instance aux instances d'une couche afin d'autoriser les applications exécutées sur ces instances à accéder à d'autres AWS ressources.
+ Comment gérer les clés SSH basées sur l'utilisateur et utiliser SSH ou RDP pour se connecter aux instances.
Pour chaque pile, les utilisateurs administratifs peuvent attribuer à chaque utilisateur une clé SSH personnelle ou autoriser les utilisateurs à spécifier leurs propres clés. Vous pouvez également autoriser un accès SSH ou RDP et des privilèges sudo ou administrateur sur les instances de la pile pour chaque utilisateur.
Les autres aspects de la sécurité sont les suivants :
+ Comment gérer la mise à jour du système d'exploitation de vos instances avec les derniers correctifs de sécurité.
Pour de plus amples informations, veuillez consulter [Gestion des mises à jour de sécurité](workingsecurity-updates.md).
+ Comment configurer les [groupes EC2 de sécurité Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) pour contrôler le trafic réseau à destination et en provenance de vos instances.
Comment spécifier des groupes de sécurité personnalisés au lieu des groupes de sécurité par défaut de OpsWorks Stacks. Pour de plus amples informations, veuillez consulter [Utilisation des groupes de sécurité](workingsecurity-groups.md).
**Topics**
+ [Gestion des OpsWorks autorisations utilisateur de Stacks](opsworks-security-users.md)
+ [Permettre à OpsWorks Stacks d'agir en votre nom](opsworks-security-servicerole.md)
+ [Prévention interservices confuse des adjoints dans Stacks OpsWorks](cross-service-confused-deputy-prevention-stacks.md)
+ [Spécification des autorisations pour les applications exécutées sur EC2 des instances](opsworks-security-appsrole.md)
+ [Gestion de l'accès SSH](security-ssh-access.md)
+ [Gestion des mises à jour de sécurité Linux](workingsecurity-updates.md)
+ [Utilisation des groupes de sécurité](workingsecurity-groups.md)
# Gestion des OpsWorks autorisations utilisateur de Stacks
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Il est recommandé de limiter les utilisateurs de OpsWorks Stacks à un ensemble spécifique d'actions ou à un ensemble de ressources de stack. Vous pouvez contrôler les autorisations OpsWorks des utilisateurs de Stacks de deux manières : en utilisant la page **Permissions** de OpsWorks Stacks et en appliquant une politique IAM appropriée.
*La page OpsWorks **Permissions**, ou les actions d'API ou de CLI équivalentes, vous permet de contrôler les autorisations des utilisateurs dans un environnement multi-utilisateurs au cas par cas en attribuant à chaque utilisateur l'un des différents niveaux d'autorisation.* Chaque niveau accorde les autorisations pour un ensemble standard d'actions pour une ressource de pile particulière. Sur la page **Autorisations**, vous pouvez contrôler les éléments suivants :
+ Les personnes autorisées à accéder à chaque pile.
+ Les actions que chaque utilisateur est autorisé à effectuer sur chaque pile.
Par exemple, vous pouvez autoriser certains utilisateurs à afficher uniquement la pile, alors que d'autres peuvent déployer des applications, ajouter des instances, et ainsi de suite.
+ Les personnes autorisées à gérer chaque pile.
Vous pouvez déléguer la gestion de chaque pile à un ou plusieurs utilisateurs spécifiés.
+ Qui dispose d'un accès SSH et de privilèges sudo (Linux) ou d'un accès RDP et de privilèges d'administrateur (Windows) au niveau utilisateur sur les instances Amazon de chaque pile. EC2
Vous pouvez accorder ou supprimer ces autorisations séparément pour chaque utilisateur à tout moment.
**Important**
Le refus SSH/RDP d'accès n'empêche pas nécessairement un utilisateur de se connecter aux instances. Si vous spécifiez une paire de EC2 clés Amazon pour une instance, tout utilisateur possédant la clé privée correspondante peut se connecter ou utiliser la clé pour récupérer le mot de passe administrateur Windows. Pour de plus amples informations, veuillez consulter [Gestion de l'accès SSH](security-ssh-access.md).
Vous pouvez utiliser la [console, la CLI ou l'API IAM](https://console.aws.amazon.com/iam) pour ajouter à vos utilisateurs des politiques qui accordent des autorisations explicites pour les différentes ressources et actions de OpsWorks Stacks.
+ L'utilisation d'une politique IAM pour spécifier les autorisations est plus flexible que l'utilisation des niveaux d'autorisation.
+ Vous pouvez configurer des [identités IAM (utilisateurs, groupes d'utilisateurs et rôles),](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) qui accordent des autorisations aux identités IAM, telles que les utilisateurs et les groupes d'utilisateurs, ou définir des [rôles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) pouvant être associés à des utilisateurs fédérés.
+ Une politique IAM est le seul moyen d'accorder des autorisations pour certaines actions clés de OpsWorks Stacks.
Par exemple, vous devez utiliser IAM pour accorder des autorisations pour `opsworks:CreateStack` et`opsworks:CloneStack`, qui sont utilisées pour créer et cloner des piles, respectivement.
Bien qu'il ne soit pas explicitement possible d'importer des utilisateurs fédérés dans la console, un utilisateur fédéré peut implicitement créer un profil utilisateur en choisissant **Mes paramètres** en haut à droite de la console OpsWorks Stacks, puis en choisissant **Utilisateurs**, également en haut à droite. Sur la page **Utilisateurs**, les utilisateurs fédérés, dont les comptes sont créés à l'aide de l'API ou de la CLI, ou implicitement via la console, peuvent gérer leurs comptes de la même manière que les utilisateurs non fédérés.
Les deux approches ne s'excluent pas mutuellement et il est parfois utile de les combiner ; OpsWorks Stacks évalue alors les deux ensembles d'autorisations. Par exemple, supposons que vous vouliez permettre aux utilisateurs d'ajouter ou de supprimer des instances, mais pas d'ajouter ou de supprimer des couches. Aucun des niveaux d'autorisation de OpsWorks Stacks n'accorde cet ensemble spécifique d'autorisations. Cependant, vous pouvez utiliser la page **Autorisations** pour accorder aux utilisateurs un niveau d'autorisation de **gestion**, qui leur permet d'effectuer la plupart des opérations de stack, puis d'appliquer une politique IAM qui refuse les autorisations d'ajouter ou de supprimer des couches. Pour plus d'informations, consultez la section [Contrôle de l'accès aux AWS ressources à l'aide de politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html).
Le modèle suivant est un modèle classique de gestion des autorisations utilisateur. Dans chaque cas, le lecteur (vous-même) est censé être un utilisateur administrateur.
1. Utilisez la [console IAM](https://console.aws.amazon.com/iam) pour appliquer des AWSOpsWorks\$1FullAccess politiques à un ou plusieurs utilisateurs administratifs.
1. Créez un utilisateur pour chaque utilisateur non administratif avec une politique qui n'accorde aucune autorisation OpsWorks Stacks.
Si un utilisateur a uniquement besoin d'accéder à OpsWorks Stacks, il se peut que vous n'ayez pas du tout besoin d'appliquer de politique. Vous pouvez plutôt gérer leurs autorisations sur la page OpsWorks Stacks **Permissions**.
1. Utilisez la page **Utilisateurs** de OpsWorks Stacks pour importer les utilisateurs non administratifs dans OpsWorks Stacks.
1. Pour chaque pile, utilisez la page **Autorisations** de la pile pour attribuer un niveau d'autorisation à chaque utilisateur.
1. Le cas échéant, personnalisez les niveaux d'autorisation des utilisateurs en appliquant une politique IAM correctement configurée.
Pour plus de recommandations sur la gestion des utilisateurs, consultez[Bonnes pratiques : Gestion des autorisations](best-practices-permissions.md).
Pour plus d'informations sur les meilleures pratiques en matière d'IAM, consultez la section Bonnes [pratiques de sécurité en matière d'IAM dans](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) le guide de l'utilisateur d'*IAM*.
**Topics**
+ [Gestion des OpsWorks utilisateurs de Stacks](opsworks-security-users-manage.md)
+ [Octroi d'autorisations par OpsWorks pile aux utilisateurs de Stacks](opsworks-security-users-console.md)
+ [Gestion des autorisations de OpsWorks Stacks en joignant une politique IAM](opsworks-security-users-policy.md)
+ [Exemples de stratégies](opsworks-security-users-examples.md)
+ [OpsWorks Stabilise les niveaux d'autorisation](opsworks-security-users-standard.md)
# Gestion des OpsWorks utilisateurs de Stacks
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Avant de pouvoir importer des utilisateurs dans OpsWorks Stacks et de leur accorder des autorisations, vous devez d'abord avoir créé un utilisateur pour chaque individu. Pour créer des utilisateurs IAM, commencez par vous connecter en AWS tant qu'utilisateur disposant des autorisations définies dans la politique IAMFull d'accès. Vous utilisez ensuite la console IAM pour [créer des utilisateurs IAM](opsworks-security-users-create-user.md) pour tous ceux qui ont besoin d'accéder OpsWorks à Stacks. Vous pouvez ensuite importer ces utilisateurs dans OpsWorks Stacks et leur accorder des autorisations comme suit :
**Utilisateurs réguliers OpsWorks de Stacks**
Les utilisateurs réguliers ne requièrent pas une stratégie attachée. S'ils en ont une, elle n'inclut généralement aucune autorisation OpsWorks Stacks. Utilisez plutôt la page OpsWorks Stacks **Permissions** pour attribuer l'un des niveaux d'autorisation suivants aux utilisateurs réguliers sur une stack-by-stack base régulière.
+ Les autorisations **Afficher** permettent aux utilisateurs d'afficher la pile, mais pas d'effectuer des opérations.
+ Les autorisations **Déployer** incluent les autorisations **Afficher** et permettent aussi aux utilisateurs de déployer et de mettre à jour des applications.
+ Les autorisations de **gestion** incluent les autorisations de **déploiement** et permettent également aux utilisateurs d'effectuer des opérations de gestion de pile, telles que l'ajout de couches ou d'instances, d'utiliser la page **Autorisations** pour définir les autorisations des utilisateurs et d'activer leurs propres privilèges SSH/RDP et ceux de sudo/administrateur.
+ Les autorisations **Refuser** refusent l'accès à la pile.
Si ces niveaux d'autorisation ne correspondent pas exactement à ce que vous souhaitez pour un utilisateur en particulier, vous pouvez personnaliser les autorisations de l'utilisateur en appliquant une politique IAM. Par exemple, vous pouvez utiliser la page **Permissions** des OpsWorks piles pour attribuer le niveau de **gestion** des autorisations à un utilisateur, qui lui accorde les autorisations nécessaires pour effectuer toutes les opérations de gestion des piles, mais pas pour créer ou cloner des piles. Vous pouvez ensuite appliquer une politique qui restreint ces autorisations en leur refusant l'autorisation d'ajouter ou de supprimer des couches ou en augmentant ces autorisations en leur permettant de créer ou de cloner des piles. Pour de plus amples informations, veuillez consulter [Gestion des autorisations de OpsWorks Stacks en joignant une politique IAMJoindre une politique IAM](opsworks-security-users-policy.md).
**OpsWorks Utilisateurs administratifs de Stacks**
Les utilisateurs administratifs sont le propriétaire du compte ou un utilisateur IAM disposant des autorisations définies par la [AWSOpsWorks\$1FullAccess politique](opsworks-security-users-examples.md#opsworks-security-users-examples-admin). En plus des autorisations accordées aux utilisateurs **Gérer**, cette stratégie inclut les autorisations relatives aux actions qui ne peuvent pas être attribuées via la page **Autorisations**, telles que celles-ci :
+ Importation d'utilisateurs dans OpsWorks Stacks
+ Création et clonage de piles
Pour obtenir la stratégie complète, consultez [Exemples de stratégies](opsworks-security-users-examples.md). Pour une liste détaillée des autorisations qui ne peuvent être accordées aux utilisateurs qu'en appliquant une politique IAM, consultez[OpsWorks Stabilise les niveaux d'autorisationNiveaux d'autorisation](opsworks-security-users-standard.md).
**Topics**
+ [Utilisateurs et régions](#UsersandRegions)
+ [Création d'un utilisateur administratif de OpsWorks Stacks](opsworks-security-users-manage-admin.md)
+ [Création d'utilisateurs IAM pour Stacks OpsWorks](opsworks-security-users-create-user.md)
+ [Importation d'utilisateurs dans OpsWorks Stacks](opsworks-security-users-manage-import.md)
+ [Modification des OpsWorks paramètres utilisateur de Stacks](opsworks-security-users-manage-edit.md)
## Utilisateurs et régions
OpsWorks Les utilisateurs de Stacks sont disponibles dans le point de terminaison régional dans lequel ils ont été créés. Vous pouvez créer des utilisateurs dans l'une des régions suivantes.
+ Région US East (Ohio)
+ Région USA Est (Virginie du Nord)
+ Région USA Ouest (Oregon)
+ Région US West (N. California)
+ Région du Canada (Centre) (API uniquement ; non disponible dans le AWS Management Console
+ Région Asie-Pacifique (Mumbai)
+ Région Asia Pacific (Singapore)
+ Région Asie-Pacifique (Sydney)
+ Région Asia Pacific (Tokyo)
+ Région Asia Pacific (Seoul)
+ Région Europe (Frankfurt)
+ Région Europe (Irlande)
+ Région Europe (Londres)
+ Région Europe (Paris)
+ Région Amérique du Sud (São Paulo)
Lorsque vous importez des utilisateurs dans OpsWorks Stacks, vous les importez vers l'un des points de terminaison régionaux ; si vous souhaitez qu'un utilisateur soit disponible dans plusieurs régions, vous devez l'importer dans cette région. Vous pouvez également importer des utilisateurs OpsWorks Stacks d'une région à l'autre ; si vous importez un utilisateur dans une région qui possède déjà un utilisateur portant le même nom, l'utilisateur importé remplace l'utilisateur existant. Pour plus d'informations sur l'importation d'utilisateurs, consultez [Importation d'utilisateurs](opsworks-security-users-manage-import.md).
# Création d'un utilisateur administratif de OpsWorks Stacks
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Vous pouvez créer un utilisateur administratif de OpsWorks Stacks en ajoutant la `AWSOpsWorks_FullAccess` politique à un utilisateur, qui accorde à cet utilisateur des autorisations d'accès complet à OpsWorks Stacks. Pour plus d'informations sur la création d'un utilisateur administratif, voir [Création d'un utilisateur administratif](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-set-up.html#create-an-admin).
**Note**
La AWSOpsWorks\$1FullAccess politique permet aux utilisateurs de créer et de gérer des OpsWorks piles Stacks, mais les utilisateurs ne peuvent pas créer de rôle de service IAM pour la pile ; ils doivent utiliser un rôle existant. Le premier utilisateur à créer une pile doit disposer d'autorisations IAM supplémentaires, comme décrit dans[Autorisations administratives](opsworks-security-users-examples.md#opsworks-security-users-examples-admin). Lorsque cet utilisateur crée la première pile, OpsWorks Stacks crée un rôle de service IAM avec les autorisations requises. Par la suite, n'importe quel utilisateur avec les autorisations `opsworks:CreateStack` peut utiliser ce rôle pour créer des piles supplémentaires. Pour de plus amples informations, veuillez consulter [Permettre à OpsWorks Stacks d'agir en votre nom](opsworks-security-servicerole.md).
Lorsque vous créez un utilisateur, vous pouvez ajouter des politiques supplémentaires gérées par le client pour affiner les autorisations de l'utilisateur, selon les besoins. Par exemple, il se peut que vous souhaitiez qu'un utilisateur administratif soit capable de créer ou de supprimer des piles, mais pas d'importer de nouveaux utilisateurs. Pour de plus amples informations, veuillez consulter [Gestion des autorisations de OpsWorks Stacks en joignant une politique IAMJoindre une politique IAM](opsworks-security-users-policy.md).
Si vous avez plusieurs utilisateurs administratifs, au lieu de définir des autorisations séparément pour chaque utilisateur, vous pouvez ajouter la AWSOpsWorks\$1FullAccess politique à un groupe IAM et ajouter les utilisateurs à ce groupe.
Pour plus d'informations sur la création d'un groupe, consultez la section [Création de groupes d'utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_create.html). Lorsque vous créez le groupe, ajoutez la **AWSOpsWorks\$1FullAccess**politique. Vous pouvez également ajouter la **AdministratorAccess**politique, qui inclut les **AWSOpsWorks\$1FullAccess**autorisations.
Pour plus d'informations sur l'ajout d'autorisations à un groupe existant, voir [Attacher une politique à un groupe d'utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_attach-policy.html).
# Création d'utilisateurs IAM pour Stacks OpsWorks
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Avant de pouvoir importer des utilisateurs IAM dans OpsWorks Stacks, vous devez les créer. Vous pouvez le faire à l'aide de la [console IAM](https://console.aws.amazon.com/iam/), de la ligne de commande ou de l'API. Pour obtenir des instructions complètes, consultez [la section Création d'un utilisateur IAM dans votre AWS compte](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html).
Notez que, contrairement aux [utilisateurs administratifs](opsworks-security-users-manage-admin.md), vous n'avez pas besoin d'attacher une stratégie pour définir des autorisations. Vous pouvez définir les autorisations après l'[importation de ces utilisateurs dans OpsWorks Stacks](opsworks-security-users-manage-import.md), comme indiqué dans [Gestion des autorisations utilisateur](opsworks-security-users.md).
Pour plus d'informations sur la création d'utilisateurs et de groupes IAM, consultez [Getting started with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started.html).
# Importation d'utilisateurs dans OpsWorks Stacks
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Les utilisateurs administratifs peuvent importer des utilisateurs dans OpsWorks Stacks ; ils peuvent également importer des utilisateurs OpsWorks Stacks d'un point de terminaison régional à un autre. Lorsque vous importez des utilisateurs dans OpsWorks Stacks, vous les importez vers l'un des points de terminaison régionaux de OpsWorks Stacks. Si vous souhaitez qu'un utilisateur soit disponible dans plusieurs régions, vous devez l'importer dans cette région.
Bien qu'il ne soit pas explicitement possible d'importer des utilisateurs fédérés dans la console, un utilisateur fédéré peut implicitement créer un profil utilisateur en choisissant **Mes paramètres** en haut à droite de la console OpsWorks Stacks, puis en choisissant **Utilisateurs**, également en haut à droite. Sur la page **Utilisateurs**, les utilisateurs fédérés, dont les comptes sont créés à l'aide de l'API ou de la CLI, ou implicitement via la console, peuvent gérer leurs comptes de la même manière que les utilisateurs non fédérés.
**Pour importer des utilisateurs dans OpsWorks Stacks**
1. Connectez-vous à OpsWorks Stacks en tant qu'utilisateur administratif ou en tant que propriétaire du compte.
1. Choisissez **Utilisateurs** dans le coin supérieur droit pour ouvrir la page **Utilisateurs**.
![\[Page Utilisateurs affichant les utilisateurs us-east-1\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/permissions_users_page.png)
1. Choisissez **Importer les utilisateurs IAM vers < *region name* >** pour afficher les utilisateurs disponibles, mais qui n'ont pas encore été importés.
![\[Importer des commandes sur la page Utilisateurs\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/permissions_import.png)
1. Cochez la case **Sélectionner tout** ou sélectionnez un ou plusieurs utilisateurs individuels. Lorsque vous avez terminé, choisissez **Importer vers OpsWorks**.
**Note**
Après avoir importé un utilisateur dans OpsWorks Stacks, si vous utilisez la console ou l'API IAM pour le supprimer de votre compte, l'utilisateur ne perd pas automatiquement l'accès SSH que vous lui avez accordé via Stacks. OpsWorks Vous devez également supprimer l'utilisateur de OpsWorks Stacks en ouvrant la page **Utilisateurs** et en choisissant **Supprimer** dans la colonne **Actions** de l'utilisateur.
**Pour importer des utilisateurs OpsWorks Stacks d'une région à une autre**
OpsWorks Les utilisateurs de Stacks sont disponibles dans le point de terminaison régional dans lequel ils ont été créés. Vous pouvez créer des utilisateurs dans les régions indiquées dans[Utilisateurs et régions](opsworks-security-users-manage.md#UsersandRegions).
Vous pouvez importer des utilisateurs OpsWorks Stacks d'une région vers la région dans laquelle votre liste d'**utilisateurs** est actuellement filtrée. Si vous importez un utilisateur dans une région qui possède déjà un utilisateur portant le même nom, l'utilisateur importé remplace l'utilisateur existant.
1. Connectez-vous à OpsWorks Stacks en tant qu'utilisateur administratif ou en tant que propriétaire du compte.
1. Choisissez **Utilisateurs** dans le coin supérieur droit pour ouvrir la page **Utilisateurs**. Si vous avez des utilisateurs OpsWorks Stacks dans plusieurs régions, utilisez le contrôle **Filtrer pour filtrer** en fonction de la région dans laquelle vous souhaitez importer des utilisateurs.
![\[Page Utilisateurs affichant les utilisateurs us-east-1\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/permissions_users_page.png)
1. Choisissez **Importer les utilisateurs de OpsWorks Stacks d'une autre région vers < *current region* >**.
![\[Page Utilisateurs affichant les utilisateurs us-west-2\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/permissions_import_otherregion.png)
1. Sélectionnez la région à partir de laquelle vous souhaitez importer des utilisateurs de OpsWorks Stacks.
1. Sélectionnez un ou plusieurs utilisateurs à importer, ou sélectionnez tous les utilisateurs, puis choisissez **Importer vers cette région**. Attendez que OpsWorks Stacks affiche les utilisateurs importés dans la liste des **utilisateurs**.
## Unix IDs et utilisateurs créés en dehors OpsWorks de Stacks
OpsWorks attribue aux utilisateurs des instances OpsWorks Stacks des valeurs d'identifiant Unix (UID) comprises entre 2000 et 4000. Dans la OpsWorks mesure où les réserves se situent entre 2000 et 4000 UIDs, les utilisateurs que vous créez en dehors OpsWorks (en utilisant des recettes de livres de recettes ou en important des utilisateurs OpsWorks depuis IAM, par exemple) peuvent être remplacés UIDs par OpsWorks Stacks pour un autre utilisateur. Cela peut avoir pour conséquence que les utilisateurs que vous avez créés en dehors de OpsWorks Stacks n'apparaissent pas dans les résultats de recherche dans les sacs de données ou soient exclus du fonctionnement intégré `sync_remote_users` de OpsWorks Stacks.
Les processus externes peuvent également créer des utilisateurs UIDs que OpsWorks Stacks peut remplacer. Certains packages de systèmes d'exploitation, par exemple, peuvent créer un utilisateur dans le cadre des processus post-installation. Lorsque vous ou un processus logiciel créez un utilisateur sur un système d'exploitation basé sur Linux sans spécifier explicitement d'UID (qui est la valeur par défaut), l'UID attribué par Stacks est \$11. OpsWorks **
Il est recommandé de créer des utilisateurs OpsWorks Stacks et de gérer leur accès dans la console OpsWorks Stacks ou à l'aide d'un AWS SDK. AWS CLI Si vous créez des utilisateurs sur des instances OpsWorks Stacks en dehors de OpsWorks, utilisez des *UnixID* valeurs supérieures à 4 000.
# Modification des OpsWorks paramètres utilisateur de Stacks
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Une fois que vous avez importé les utilisateurs, vous pouvez modifier leurs paramètres, comme suit :
**Pour modifier les paramètres utilisateur**
1. Sur la page **Utilisateurs**, choisissez **Modifier** dans la colonne **Actions** de l'utilisateur.
1. Vous pouvez spécifier les paramètres suivants.
**Gestion automatique**
Sélectionnez **Oui** pour autoriser l'utilisateur à utiliser la MySettings page pour spécifier sa clé SSH personnelle.
Vous pouvez également activer l'autogestion en ajoutant une politique IAM à l'identité IAM qui accorde des autorisations pour les [DescribeMyUserProfile](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeMyUserProfile.html)actions et. [UpdateMyUserProfile](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateMyUserProfile.html)
**Clé SSH publique**
(Facultatif) Entrez une clé publique SSH pour l'utilisateur. Cette clé s'affiche sur la page **Mes paramètres** de l'utilisateur. Si vous activez la gestion automatique, l'utilisateur peut modifier **Mes paramètres** et spécifier sa propre clé. Pour de plus amples informations, veuillez consulter [Enregistrement de la clé SSH publique d'un utilisateur](security-settingsshkey.md).
OpsWorks Stacks installe cette clé sur toutes les instances Linux ; les utilisateurs peuvent utiliser la clé privée associée pour se connecter. Pour de plus amples informations, veuillez consulter [Connexion avec SSH](workinginstances-ssh.md). Vous ne pouvez pas utiliser cette clé avec les piles Windows.
**Autorisations**
(Facultatif) Définissez les niveaux d'autorisation utilisateur pour chaque pile dans un seul emplacement au lieu de les définir séparément à l'aide de la page **Autorisations** de la pile. Pour plus d'informations sur les niveaux d'autorisation, consultez [Attribution des autorisations par pile](opsworks-security-users-console.md).
![\[User details page showing name, ARN, SSH settings, and permission levels for various stacks.\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/permissions_edit_user.png)
# Octroi d'autorisations par OpsWorks pile aux utilisateurs de Stacks
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Le moyen le plus simple de gérer les autorisations OpsWorks des utilisateurs de Stacks consiste à utiliser la page d'**autorisations** d'une pile. Chaque pile a sa propre page, qui attribue les autorisations pour cette pile.
Vous devez être connecté tant qu'utilisateur administratif ou qu'utilisateur **Gérer** pour modifier les paramètres d'autorisation. La liste affiche uniquement les utilisateurs qui ont été importés dans OpsWorks Stacks. Pour plus d'informations sur la façon de créer et d'importer des utilisateurs, consultez [Gestion des utilisateurs](opsworks-security-users-manage.md).
Le niveau d'autorisation par défaut est IAM Policies Only, qui accorde aux utilisateurs uniquement les autorisations figurant dans leur politique IAM.
+ Lorsque vous importez un utilisateur depuis IAM ou depuis une autre région, l'utilisateur est ajouté à la liste de toutes les piles existantes avec un niveau d'autorisation **IAM Policies Only**.
+ Par défaut, un utilisateur que vous venez d'importer depuis une autre région n'a pas accès aux piles de la région de destination. Si vous importez des utilisateurs d'une autre région, pour leur permettre de gérer les piles dans la région de destination, des autorisations doivent leur être attribuées après avoir importé les utilisateurs.
+ Lorsque vous créez une pile, tous les utilisateurs actuels sont ajoutés à la liste avec les niveaux d'autorisation **Stratégies IAM uniquement**.
**Topics**
+ [Définition des autorisations d'un utilisateur](#opsworks-security-users-console-set)
+ [Affichage des autorisations](#opsworks-security-users-console-viewing)
+ [Utilisation des clés de condition IAM pour vérifier les informations d'identification temporaires](#w2ab1c14c67c15c37c21)
## Définition des autorisations d'un utilisateur
**Pour définir les autorisations d'un utilisateur**
1. Dans le panneau de navigation, sélectionnez **Autorisations**.
1. Sur la page **Autorisations**, choisissez **Modifier**.
1. Modifiez les paramètres **Niveau d'autorisation** et **Accès à l'instance** :
+ Utilisez les paramètres **Niveau d'autorisation** pour attribuer l'un des niveaux d'autorisation standard à chaque utilisateur, lesquels déterminent si l'utilisateur peut accéder à cette pile et les actions qu'il peut effectuer. Si un utilisateur dispose d'une politique IAM, OpsWorks Stacks évalue les deux ensembles d'autorisations. Pour obtenir un exemple, consultez [Exemples de stratégies](opsworks-security-users-examples.md).
+ Le paramètre **Accès à l'instance** **SSH/RDP** spécifie si l'utilisateur dispose de l'accès SSH (Linux) ou RDP (Windows) aux instances de la pile.
Si vous autorisez l'accès **SSH/RDP**, vous pouvez, le cas échéant, sélectionner **sudo/admin**, qui accorde à l'utilisateur les privilèges sudo (Linux) ou admin (Windows) sur les instances de la pile.
![\[Gestion des utilisateurs à l'aide de la page Autorisations.\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/permissions-edit.png)
Vous pouvez attribuer à chaque utilisateur l'un des niveaux d'autorisation suivants. Pour obtenir la liste des actions autorisées par chaque niveau, consultez [OpsWorks Stabilise les niveaux d'autorisationNiveaux d'autorisation](opsworks-security-users-standard.md).
**Refuser**
L'utilisateur ne peut effectuer aucune action OpsWorks Stacks sur la pile, même s'il dispose d'une politique IAM qui accorde à OpsWorks Stacks des autorisations d'accès complètes. Vous pouvez l'utiliser pour interdire, par exemple, à certains utilisateurs l'accès aux piles des produits non distribués.
**Stratégies IAM uniquement**
Niveau par défaut, assigné à tous les utilisateurs nouvellement importés et à tous les utilisateurs des piles nouvellement créées. Les autorisations de l'utilisateur sont déterminées par sa politique IAM. Si un utilisateur n'a aucune politique IAM ou si sa politique ne comporte aucune autorisation OpsWorks Stacks explicite, il ne peut pas accéder à la pile. Ce niveau est généralement attribué aux utilisateurs administratifs car leurs politiques IAM accordent déjà des autorisations d'accès complètes.
**Afficher**
L'utilisateur peut afficher une pile, mais ne peut pas effectuer d'opérations. Par exemple, il se peut que les gestionnaires souhaitent surveiller les piles d'un compte, mais qu'ils n'aient pas besoin de déployer des applications ou de modifier la pile de quelque façon que ce soit.
**Déploiement**
Inclut les autorisations **Show** et permet également à l'utilisateur de déployer des applications. Par exemple, un développeur d'application peut avoir besoin de déployer des mises à jour sur les instances de la pile, mais pas d'ajouter des couches ou des instances à la pile.
**Gérer**
Inclut les autorisations **Deploy** et permet également à l'utilisateur d'effectuer diverses opérations de gestion de la pile, y compris les actions suivantes :
+ Ajout ou suppression de couches et d'instances.
+ Utilisation de la pile **Permissions** pour attribuer les niveaux d'autorisation aux utilisateurs.
+ Enregistrement ou annulation de l'enregistrement des ressources.
Par exemple, chaque pile peut avoir un gestionnaire dédié, chargé de s'assurer que la pile possède un nombre et un type appropriés d'instances, de gérer les mises à jour des packages et du système d'exploitation, et ainsi de suite.
Le niveau Manage ne permet pas aux utilisateurs de créer des piles ou d'en cloner. Ces autorisations doivent être accordées par une politique IAM. Pour obtenir un exemple, consultez [Gestion des autorisations](opsworks-security-users-examples.md#opsworks-security-users-examples-manage).
Si l'utilisateur dispose également d'une politique IAM, OpsWorks Stacks évalue les deux ensembles d'autorisations. Cela vous permet d'attribuer un niveau d'autorisation à un utilisateur, puis d'appliquer une politique pour restreindre ou augmenter les actions autorisées au niveau. Par exemple, vous pouvez appliquer une politique qui autorise un utilisateur de **gestion** à créer ou à cloner des piles, ou qui refuse à cet utilisateur la possibilité d'enregistrer ou de désenregistrer des ressources. Pour obtenir des exemples de ces stratégies, consultez [Exemples de stratégies](opsworks-security-users-examples.md).
**Note**
Si la stratégie de l'utilisateur autorise des actions supplémentaires, le résultat peut apparaître pour remplacer les paramètres de la page **Permissions**. Par exemple, si un utilisateur dispose d'une politique qui autorise l'[CreateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateLayer.html)action mais que vous utilisez la page **Autorisations** pour spécifier les autorisations de **déploiement**, l'utilisateur est toujours autorisé à créer des couches. L'exception à cette règle est l'option **Deny**, qui refuse l'accès à la pile même aux utilisateurs soumis à des AWSOpsWorks\$1FullAccess politiques. Pour plus d'informations, consultez la section [Contrôle de l'accès aux AWS ressources à l'aide de politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html).
## Affichage des autorisations
Si l'option [self-management](opsworks-security-users-manage-edit.md) est activée, les utilisateurs peuvent afficher un résumé de leurs niveaux d'autorisations pour chaque pile en choisissant **My Settings**, dans l'angle supérieur droit. Les utilisateurs peuvent également accéder à **Mes paramètres** si leur politique accorde des autorisations pour les [UpdateMyUserProfile](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateMyUserProfile.html)actions [DescribeMyUserProfile](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeMyUserProfile.html)et.
## Utilisation des clés de condition IAM pour vérifier les informations d'identification temporaires
OpsWorks Stacks possède une couche d'autorisation intégrée qui prend en charge les cas d'autorisation supplémentaires (tels que la gestion simplifiée de l'accès en lecture seule ou en lecture-écriture aux piles pour les utilisateurs individuels). Cette couche d'autorisation s'appuie sur l'utilisation d'informations d'identification temporaires. Pour cette raison, vous ne pouvez pas utiliser de `aws:TokenIssueTime` condition pour vérifier que les utilisateurs utilisent des informations d'identification à long terme ou pour bloquer les actions des utilisateurs qui utilisent des informations d'identification temporaires, comme décrit dans la [référence aux éléments de politique IAM JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Conditions_Null) dans la documentation IAM.
# Gestion des autorisations de OpsWorks Stacks en joignant une politique IAM
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Vous pouvez spécifier les autorisations OpsWorks Stacks d'un utilisateur en joignant une politique IAM. Une stratégie attachée est requise pour certaines autorisations :
+ Autorisations utilisateur administratif, comme l'importation d'utilisateurs.
+ Autorisations pour certaines actions, telles que la création ou le clonage d'une pile.
Pour obtenir la liste complète des actions qui nécessitent une stratégie attachée, consultez [OpsWorks Stabilise les niveaux d'autorisationNiveaux d'autorisation](opsworks-security-users-standard.md).
Vous pouvez également utiliser une politique pour personnaliser les niveaux d'autorisation accordés via la page **Autorisations**. Cette section fournit un bref résumé de la manière d'appliquer une politique IAM à un utilisateur pour spécifier les autorisations OpsWorks Stacks. Pour plus d'informations, consultez la section [Gestion des accès aux AWS ressources](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html).
Une politique IAM est un objet JSON qui contient une ou plusieurs *instructions*. Chaque élément de la déclaration possède une liste d'autorisations, composées chacune de trois éléments de base :
**Action**
Les actions que l'autorisation affecte. Vous spécifiez les actions OpsWorks Stacks sous la forme`opsworks:action`. Une `Action` peut être définie sur une action spécifique comme `opsworks:CreateStack`, qui indique si l'utilisateur est autorisé à appeler [https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateStack.html](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateStack.html). Vous pouvez également utiliser des caractères génériques pour spécifier des groupes d'actions. Par exemple, `opsworks:Create*` spécifie toutes les actions de création. Pour une liste complète des actions OpsWorks Stacks, consultez la référence de l'[API OpsWorks Stacks](https://docs.aws.amazon.com/opsworks/latest/APIReference/Welcome.html).
**Effet**
Indique si les actions spécifiées sont autorisées ou refusées.
**Ressource**
Les AWS ressources concernées par l'autorisation. OpsWorks Stacks possède un seul type de ressource, la pile. Pour spécifier les autorisations d'une ressource de pile particulière, définissez `Resource` sur l'ARN de la pile, qui a le format suivant : `arn:aws:opsworks:region:account_id:stack/stack_id/`.
Vous pouvez également utiliser des caractères génériques. Par exemple, la définition de `Resource` sur `*` attribue les autorisations pour chaque ressource.
Par exemple, la stratégie suivante refuse à l'utilisateur la possibilité d'arrêter les instances sur la pile dont l'ID est `2860-2f18b4cb-4de5-4429-a149-ff7da9f0d8ee`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": "opsworks:StopInstance",
"Effect": "Deny",
"Resource": "arn:aws:opsworks:*:*:stack/2f18b4cb-4de5-4429-a149-ff7da9f0d8ee/"
}
]
}
```
------
Pour plus d'informations sur l'ajout d'autorisations à un utilisateur IAM, consultez[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console).
Pour plus d'informations sur la façon de créer ou de modifier des politiques IAM, consultez la section [Politiques et autorisations dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html). Pour des exemples de politiques de OpsWorks Stacks, voir[Exemples de stratégies](opsworks-security-users-examples.md).
# Exemples de stratégies
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Cette section décrit des exemples de politiques IAM qui peuvent être appliquées aux utilisateurs de OpsWorks Stacks.
+ [Autorisations administratives](#opsworks-security-users-examples-admin)décrit les politiques utilisées pour accorder des autorisations aux utilisateurs administratifs.
+ [Gestion des autorisations](#opsworks-security-users-examples-manage)et [Autorisations Deploy](#opsworks-security-users-examples-deploy) montrez des exemples de politiques qui peuvent être appliquées à un utilisateur pour augmenter ou restreindre les niveaux d'autorisation de gestion et de déploiement.
OpsWorks Stacks détermine les autorisations de l'utilisateur en évaluant les autorisations accordées par les politiques IAM ainsi que les autorisations accordées par la page **Permissions**. Pour plus d'informations, consultez la section [Contrôle de l'accès aux AWS ressources à l'aide de politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html). Pour plus d'informations sur les autorisations de la page **Autorisations**, consultez [OpsWorks Stabilise les niveaux d'autorisationNiveaux d'autorisation](opsworks-security-users-standard.md).
## Autorisations administratives
Utilisez la console IAM [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/), pour accéder à la AWSOpsWorks\$1FullAccess politique, attachez cette politique à un utilisateur pour lui accorder l'autorisation d'effectuer toutes les actions OpsWorks Stacks. Les autorisations IAM sont requises, entre autres, pour permettre à un utilisateur administratif d'importer des utilisateurs.
Vous devez créer un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) qui permet à OpsWorks Stacks d'agir en votre nom pour accéder à d'autres AWS ressources, telles que les instances Amazon EC2 . Vous gérez généralement cette tâche en demandant à un utilisateur administratif de créer la première pile et en laissant OpsWorks Stacks créer le rôle pour vous. Vous pouvez ensuite utiliser ce rôle pour toutes les piles suivantes. Pour de plus amples informations, veuillez consulter [Permettre à OpsWorks Stacks d'agir en votre nom](opsworks-security-servicerole.md).
L'utilisateur administratif qui crée la première pile doit disposer d'autorisations pour certaines actions IAM qui ne sont pas incluses dans la AWSOpsWorks\$1FullAccess politique. Ajoutez les autorisations suivantes à la `Actions` section de la politique. Pour une syntaxe JSON correcte, veillez à ajouter des virgules entre les actions et à supprimer la virgule de fin à la fin de la liste des actions.
```
"iam:PutRolePolicy",
"iam:AddRoleToInstanceProfile",
"iam:CreateInstanceProfile",
"iam:CreateRole"
```
## Gestion des autorisations
Le niveau d'autorisation **Gérer** permet à un utilisateur d'effectuer diverses actions de gestion de pile, y compris l'ajout ou la suppression de couches. Cette rubrique décrit plusieurs politiques que vous pouvez utiliser pour **gérer les** utilisateurs afin d'augmenter ou de restreindre les autorisations standard.
Refuser à un utilisateur **Gérer** la possibilité d'ajouter ou de supprimer des couches
Vous pouvez restreindre le niveau des autorisations de **gestion** pour permettre à un utilisateur d'effectuer toutes les actions de **gestion**, à l'exception de l'ajout ou de la suppression de couches, en utilisant la politique IAM suivante. Remplacez *region**account\$1id*, et *stack\$1id* par des valeurs adaptées à votre configuration.
Permettre à un utilisateur **Gérer** de créer ou de cloner des piles
Le niveau **Gérer** les autorisations ne permet pas aux utilisateurs de créer ou de cloner des piles. Vous pouvez modifier les autorisations de **gestion** pour permettre à un utilisateur de créer ou de cloner des piles en appliquant la politique IAM suivante. Remplacez *region* et *account\$1id* par des valeurs adaptées à votre configuration.
Refuser à un utilisateur Manage la possibilité d'enregistrer des ressources ou d'annuler leur enregistrement
Le niveau de **gestion** des autorisations permet à l'utilisateur d'[enregistrer et de désenregistrer les ressources d'adresses IP Amazon EBS et Elastic](resources-reg.md) auprès de la pile. Vous pouvez restreindre les autorisations de **gestion** pour permettre à l'utilisateur d'effectuer toutes les actions de **gestion**, à l'exception de l'enregistrement des ressources, en appliquant la politique suivante.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"opsworks:RegisterVolume",
"opsworks:RegisterElasticIp"
],
"Resource": "*"
}
]
}
```
Autoriser un utilisateur **Gérer** à importer des utilisateurs
Le niveau de **gestion** des autorisations ne permet pas aux utilisateurs d'importer des utilisateurs dans OpsWorks Stacks. Vous pouvez augmenter les autorisations de **gestion** pour permettre à un utilisateur d'importer et de supprimer des utilisateurs en appliquant la politique IAM suivante. Remplacez *region* et *account\$1id* par des valeurs adaptées à votre configuration.
## Autorisations Deploy
Le niveau d'autorisation **Déployer** ne permet pas aux utilisateurs de créer ou de supprimer des applications. Vous pouvez augmenter les autorisations de **déploiement** pour permettre à un utilisateur de créer et de supprimer des applications en appliquant la politique IAM suivante. Remplacez *region**account\$1id*, et *stack\$1id* par des valeurs adaptées à votre configuration.
# OpsWorks Stabilise les niveaux d'autorisation
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Cette section répertorie les actions autorisées par les niveaux d'autorisation **Afficher**, **déployer** et **gérer** sur la page OpsWorks Stacks **Permissions**. Il inclut également une liste d'actions auxquelles vous pouvez accorder des autorisations uniquement en appliquant une politique IAM à l'utilisateur.
**Afficher**
Le niveau **Show** autorise les commandes `DescribeXYZ`, avec les exceptions suivantes :
```
DescribePermissions
DescribeUserProfiles
DescribeMyUserProfile
DescribeStackProvisioningParameters
```
Si un utilisateur administrateur a activé la gestion automatique pour l'utilisateur, les utilisateurs **Show** peuvent également utiliser `DescribeMyUserProfile` et `UpdateMyUserProfile`. Pour plus d'informations sur la gestion automatique, consultez [Modification des paramètres utilisateur](opsworks-security-users-manage-edit.md).
**Déploiement**
Les actions suivantes sont autorisées par le niveau **Deploy**, en plus des actions autorisées par le niveau **Show**.
```
CreateDeployment
UpdateApp
```
**Gérer**
Les actions suivantes sont autorisées par le niveau **Manage**, en plus des actions autorisées par les niveaux **Deploy** et **Show**.
```
AssignInstance
AssignVolume
AssociateElasticIp
AttachElasticLoadBalancer
CreateApp
CreateInstance
CreateLayer
DeleteApp
DeleteInstance
DeleteLayer
DeleteStack
DeregisterElasticIp
DeregisterInstance
DeregisterRdsDbInstance
DeregisterVolume
DescribePermissions
DetachElasticLoadBalancer
DisassociateElasticIp
GrantAccess
GetHostnameSuggestion
RebootInstance
RegisterElasticIp
RegisterInstance
RegisterRdsDbInstance
RegisterVolume
SetLoadBasedAutoScaling
SetPermission
SetTimeBasedAutoScaling
StartInstance
StartStack
StopInstance
StopStack
UnassignVolume
UpdateElasticIp
UpdateInstance
UpdateLayer
UpdateRdsDbInstance
UpdateStack
UpdateVolume
```
**Autorisations nécessitant une politique IAM**
Vous devez accorder des autorisations pour les actions suivantes en appliquant une politique IAM appropriée à l'utilisateur. Pour obtenir quelques exemples, consultez [Exemples de stratégies](opsworks-security-users-examples.md).
```
CloneStack
CreateStack
CreateUserProfile
DeleteUserProfile
DescribeUserProfiles
UpdateUserProfile
```
# Permettre à OpsWorks Stacks d'agir en votre nom
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
OpsWorks Stacks doit interagir avec divers services AWS en votre nom. Par exemple, OpsWorks Stacks interagit avec Amazon EC2 pour créer des instances et avec Amazon CloudWatch pour obtenir des statistiques de surveillance. Lorsque vous créez une pile, vous spécifiez un rôle IAM, généralement appelé rôle de service, qui accorde à OpsWorks Stacks les autorisations appropriées.
![\[Liste des rôles IAM sur la page Ajouter une pile.\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/add-stack-iamrole.png)
Lorsque vous spécifiez le rôle de service d'une nouvelle pile, vous pouvez effectuer l'une des actions suivantes :
+ Spécifier un rôle de service standard que vous avez créé plus tôt.
Vous pouvez généralement créer un rôle de service standard lorsque vous créez votre première pile, puis utiliser ce rôle pour toutes les piles suivantes.
+ Spécifiez un rôle de service personnalisé que vous avez créé à l'aide de la console ou de l'API IAM.
Cette approche est utile si vous souhaitez accorder à OpsWorks Stacks des autorisations plus limitées que le rôle de service standard.
**Note**
Pour créer votre première pile, vous devez disposer des autorisations définies dans le modèle de **AdministratorAccess**politique IAM. Ces autorisations permettent à OpsWorks Stacks de créer un rôle de service IAM et vous permettent d'importer des utilisateurs, [comme indiqué plus tôt](opsworks-security-users-manage-import.md). Pour toutes les piles suivantes, les utilisateurs peuvent sélectionner le rôle de service créé pour la première pile ; ils n'ont pas besoin d'autorisations d'administration complètes pour créer une pile.
Le rôle de service standard octroie les autorisations suivantes :
+ Effectuez toutes les EC2 actions Amazon (`ec2:*`).
+ Obtenez CloudWatch des statistiques (`cloudwatch:GetMetricStatistics`).
+ Utilisez Elastic Load Balancing pour distribuer le trafic vers les serveurs (`elasticloadbalancing:*`).
+ Utilisez une instance Amazon RDS comme serveur de base de données (`rds:*`).
+ Utilisez les rôles IAM (`iam:PassRole`) pour garantir une communication sécurisée entre OpsWorks Stacks et vos instances Amazon EC2 .
Si vous créez un rôle de service personnalisé, vous devez vous assurer qu'il accorde toutes les autorisations dont OpsWorks Stacks a besoin pour gérer votre stack. L'exemple JSON suivant est la déclaration de stratégie pour le rôle de service standard ; un rôle de service personnalisé doit au moins inclure les autorisations suivantes dans sa déclaration de stratégie.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:*",
"iam:PassRole",
"cloudwatch:GetMetricStatistics",
"cloudwatch:DescribeAlarms",
"ecs:*",
"elasticloadbalancing:*",
"rds:*"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"iam:PassedToService": "ec2.amazonaws.com"
}
}
}
]
}
```
------
Un rôle de service a également une relation d'approbation. Les rôles de service créés par OpsWorks Stacks ont la relation de confiance suivante.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "StsAssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "opsworks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Le rôle de service doit avoir cette relation de confiance pour que OpsWorks Stacks agisse en votre nom. Si vous utilisez le rôle de service par défaut, ne modifiez pas la relation d'approbation. Si vous créez un rôle de service personnalisé, spécifiez la relation de confiance en effectuant l'une des opérations suivantes :
+ Si vous utilisez l'assistant de **création de rôle** dans la [console IAM](https://console.aws.amazon.com/iam/home#roles), dans **Choisir un cas d'utilisation**, choisissez **Opsworks**. Ce rôle possède la relation de confiance appropriée, mais aucune politique n'y est implicitement attachée. Pour autoriser OpsWorks Stacks à agir en votre nom, créez une politique gérée par le client contenant les éléments suivants et associez-la au nouveau rôle.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:DescribeAlarms",
"cloudwatch:GetMetricStatistics",
"ec2:*",
"ecs:*",
"elasticloadbalancing:*",
"iam:GetRolePolicy",
"iam:ListInstanceProfiles",
"iam:ListRoles",
"iam:ListUsers",
"rds:*"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "ec2.amazonaws.com"
}
}
}
]
}
```
------
+ Si vous utilisez un CloudFormation modèle, vous pouvez ajouter quelque chose comme ce qui suit à la section **Ressources** de votre modèle.
```
"Resources": {
"OpsWorksServiceRole": {
"Type": "AWS::IAM::Role",
"Properties": {
"AssumeRolePolicyDocument": {
"Statement": [ {
"Effect": "Allow",
"Principal": {
"Service": [ "opsworks.amazonaws.com" ]
},
"Action": [ "sts:AssumeRole" ]
} ]
},
"Path": "/",
"Policies": [ {
"PolicyName": "opsworks-service",
"PolicyDocument": {
...
} ]
}
},
}
}
```
# Prévention interservices confuse des adjoints dans Stacks OpsWorks
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Le problème de député confus est un problème de sécurité dans lequel une entité qui n’est pas autorisée à effectuer une action peut contraindre une entité plus privilégiée à le faire. En AWS, l'usurpation d'identité interservices peut entraîner la confusion des adjoints. L’usurpation d’identité entre services peut se produire lorsqu’un service (le *service appelant*) appelle un autre service (le *service appelé*). Le service appelant peut être manipulé et ses autorisations utilisées pour agir sur les ressources d’un autre client auxquelles on ne serait pas autorisé à accéder autrement. Pour éviter cela, AWS fournit des outils qui vous aident à protéger vos données pour tous les services avec des principaux de service qui ont eu accès aux ressources de votre compte.
Nous recommandons d'utiliser les clés de contexte de condition [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)globale [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)et les clés de contexte dans les politiques d'accès aux piles afin de limiter les autorisations que AWS OpsWorks Stacks accorde à un autre service aux piles. Si la valeur `aws:SourceArn` ne contient pas l'ID du compte, tel qu'un ARN de compartiment Amazon S3, vous devez utiliser les deux clés de contexte de condition globale pour limiter les autorisations. Si vous utilisez les deux clés de contexte de condition globale et que la valeur `aws:SourceArn` contient l'ID de compte, la valeur `aws:SourceAccount` et le compte dans la valeur `aws:SourceArn` doivent utiliser le même ID de compte lorsqu'ils sont utilisés dans la même instruction de politique. À utiliser `aws:SourceArn` si vous souhaitez qu'une seule pile soit associée à l'accès multiservice. À utiliser `aws:SourceAccount` si vous souhaitez autoriser toute pile de ce compte à être associée à l'utilisation interservices.
La valeur de `aws:SourceArn` doit être l'ARN d'une OpsWorks pile.
Le moyen le plus efficace de se protéger contre le problème de confusion des adjoints consiste à utiliser la clé de contexte de condition `aws:SourceArn` globale avec l'ARN complet de la pile OpsWorks Stacks. Si vous ne connaissez pas l'ARN complet ou si vous spécifiez plusieurs piles ARNs, utilisez la clé de condition de contexte `aws:SourceArn` globale avec des caractères génériques (`*`) pour les parties inconnues de l'ARN. Par exemple, `arn:aws:servicename:*:123456789012:*`.
La section suivante explique comment utiliser les clés contextuelles `aws:SourceArn` et les clés de contexte de condition `aws:SourceAccount` globale dans OpsWorks Stacks pour éviter le problème de confusion des adjoints.
## Empêchez les exploits secondaires confus dans OpsWorks Stacks
Cette section décrit comment vous pouvez empêcher les exploits secondaires confus dans OpsWorks Stacks et inclut des exemples de politiques d'autorisation que vous pouvez associer au rôle IAM que vous utilisez pour accéder OpsWorks à Stacks. Pour des raisons de sécurité, nous vous recommandons d'ajouter les clés de `aws:SourceAccount` condition `aws:SourceArn` et aux relations de confiance que votre rôle IAM entretient avec d'autres services. Les relations de confiance permettent à OpsWorks Stacks d'assumer un rôle pour effectuer des actions dans d'autres services nécessaires à la création ou à la gestion de vos OpsWorks stacks Stacks.
**Pour modifier les relations de confiance afin d'ajouter `aws:SourceArn` et de `aws:SourceAccount` conditionner des clés**
1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Dans le volet de navigation de gauche, choisissez **Rôles**.
1. Dans la zone **de** recherche, recherchez le rôle que vous utilisez pour accéder à OpsWorks Stacks. Le rôle AWS géré est`aws-opsworks-service-role`.
1. Sur la page **Résumé** du rôle, choisissez l'onglet **Relations de confiance**.
1. Dans l'onglet **Relations de confiance**, choisissez **Modifier la politique de confiance**.
1. Sur la page **Modifier la politique de confiance**, ajoutez au moins l'une des clés de `aws:SourceAccount` condition `aws:SourceArn` ou à la politique. `aws:SourceArn`À utiliser pour restreindre la relation de confiance entre les services croisés (tels qu'Amazon EC2) et OpsWorks Stacks à des piles OpsWorks Stacks spécifiques, ce qui est plus restrictif. Ajoutez `aws:SourceAccount` pour limiter la relation de confiance entre cross services et OpsWorks Stacks aux piles d'un compte spécifique, ce qui est moins restrictif. Voici un exemple. Notez que si vous utilisez les deux clés de condition, le compte IDs doit être le même.
1. Lorsque vous avez terminé d'ajouter des clés de condition, choisissez **Mettre à jour la politique**.
Vous trouverez ci-dessous d'autres exemples de rôles qui limitent l'accès aux piles en utilisant `aws:SourceArn` et`aws:SourceAccount`.
**Topics**
+ [Exemple : accès aux piles dans une région spécifique](#confused-deputy-opsworks-stacks-example1)
+ [Exemple : ajout de plusieurs ARN de pile à `aws:SourceArn`](#confused-deputy-opsworks-stacks-example2)
### Exemple : accès aux piles dans une région spécifique
La déclaration de relation de confiance suivante permet d'accéder à toutes les OpsWorks piles Stacks de la région USA Est (Ohio) (). `us-east-2` Notez que la région est spécifiée dans la valeur ARN de`aws:SourceArn`, mais que la valeur de l'ID de pile est un caractère générique (\$1).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "opsworks.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:opsworks:us-east-2:123456789012:stack/*"
}
}
}
]
}
```
------
### Exemple : ajout de plusieurs ARN de pile à `aws:SourceArn`
L'exemple suivant limite l'accès à un tableau de deux OpsWorks piles Stacks dans l'ID de compte 123456789012.
# Spécification des autorisations pour les applications exécutées sur EC2 des instances
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Si les applications exécutées sur les EC2 instances Amazon de votre stack doivent accéder à d'autres ressources AWS, telles que les compartiments Amazon S3, elles doivent disposer des autorisations appropriées. Pour attribuer ces autorisations, vous utilisez un profil d'instance. Vous pouvez spécifier un profil d'instance pour chaque instance lorsque vous [créez une pile OpsWorks Stacks](workingstacks-creating.md).
![\[Option Advanced de la page Add Stack.\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/add-stack-instanceproflie.png)
Vous pouvez également spécifier un profil pour les instances d'une couche en [modifiant la configuration de la couche](workinglayers-basics-edit.md).
Le profil d'instance spécifie un rôle IAM. Les applications qui s'exécutent sur l'instance peuvent assumer ce rôle pour accéder aux ressources AWS, sous réserve des autorisations accordées par la stratégie du rôle. Pour plus d'informations sur la façon dont une application assume un rôle, consultez [Assumer un rôle à l'aide d'un appel d'API](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-assume-role.html).
Vous pouvez créer un profil d'instance de différentes façons :
+ Utilisez la console ou l'API IAM pour créer un profil.
Pour plus d'informations, consultez [Rôles (délégation et fédération)](https://docs.aws.amazon.com/IAM/latest/UserGuide/WorkingWithRoles.html).
+ Utilisez un CloudFormation modèle pour créer un profil.
Pour des exemples d'inclusion de ressources IAM dans un modèle, consultez [Identity and Access Management (IAM) Template Snippets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-iam.html).
Un profil d'instance doit avoir une relation d'approbation et une stratégie attachée qui accorde les autorisations d'accès aux ressources AWS.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Le profil d'instance doit avoir cette relation de confiance pour que OpsWorks Stacks puisse agir en votre nom. Si vous utilisez le rôle de service par défaut, ne modifiez pas la relation d'approbation. Si vous créez un rôle de service personnalisé, spécifiez la relation d'approbation comme suit :
+ Si vous utilisez l'assistant de **création de rôle** dans la [console IAM](https://console.aws.amazon.com/iam/home#roles), spécifiez le type de EC2 rôle **Amazon** sous **AWS Service Roles** sur la deuxième page de l'assistant.
+ Si vous utilisez un CloudFormation modèle, vous pouvez ajouter quelque chose comme ce qui suit à la section **Ressources** de votre modèle.
```
"Resources": {
"OpsWorksEC2Role": {
"Type": "AWS::IAM::Role",
"Properties": {
"AssumeRolePolicyDocument": {
"Statement": [ {
"Effect": "Allow",
"Principal": {
"Service": [ "ec2.amazonaws.com" ]
},
"Action": [ "sts:AssumeRole" ]
} ]
},
"Path": "/"
}
},
"RootInstanceProfile": {
"Type": "AWS::IAM::InstanceProfile",
"Properties": {
"Path": "/",
"Roles": [ {
"Ref": "OpsWorksEC2Role"
}
]
}
}
}
```
Lorsque vous créez votre profil d'instance, vous pouvez associer une politique appropriée au rôle du profil à ce moment-là. Après avoir créé la pile, vous devez utiliser la [console ou l'API IAM](https://console.aws.amazon.com/iam/) pour associer une politique appropriée au rôle du profil. Par exemple, la politique suivante accorde un accès complet à tous les objets du compartiment Amazon S3 nommé amzn-s3-demo-bucket. Remplacez *region* et amzn-s3-demo-bucket par des valeurs adaptées à votre configuration.
Pour obtenir un exemple de la façon de créer et d'utiliser un profil d'instance, consultez [Utilisation d'un compartiment Amazon S3](https://docs.aws.amazon.com/opsworks/latest/userguide/gettingstarted.walkthrough.photoapp.html).
Si votre application utilise un profil d'instance pour appeler l'API OpsWorks Stacks depuis une EC2 instance, la politique doit autoriser l'`iam:PassRole`action en plus des actions appropriées pour OpsWorks Stacks et les autres services AWS. L'autorisation `iam:PassRole` permet à OpsWorks Stacks d'assumer le rôle de service en votre nom. Pour plus d'informations sur l'API OpsWorks Stacks, consultez le manuel de [référence des OpsWorks API AWS](https://docs.aws.amazon.com/opsworks/latest/APIReference/Welcome.html).
Voici un exemple de politique IAM qui vous permet d'appeler n'importe quelle action OpsWorks Stacks depuis une EC2 instance, ainsi que toute action Amazon EC2 ou Amazon S3.
**Note**
Si vous ne l'autorisez pas`iam:PassRole`, toute tentative d'appel d'une action OpsWorks Stacks échoue avec une erreur comme celle-ci :
```
User: arn:aws:sts::123456789012:federated-user/Bob is not authorized
to perform: iam:PassRole on resource:
arn:aws:sts::123456789012:role/OpsWorksStackIamRole
```
Pour plus d'informations sur l'utilisation des rôles sur une EC2 instance pour obtenir des autorisations, consultez la section [Accorder aux applications exécutées sur EC2 des instances Amazon l'accès aux ressources AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/role-usecase-ec2app.html) dans le *guide de Gestion des identités et des accès AWS l'utilisateur*.
# Gestion de l'accès SSH
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
OpsWorks Stacks prend en charge les clés SSH pour les piles Linux et Windows.
+ Pour les instances Linux, vous pouvez utiliser SSH pour vous connecter à une instance : par exemple, pour exécuter les commandes [de l'interface de ligne de commande de l'agent](agent.md).
Pour de plus amples informations, veuillez consulter [Connexion avec SSH](workinginstances-ssh.md).
+ Pour les instances Windows, vous pouvez utiliser une clé SSH pour obtenir le mot de passe Administrateur de l'instance, que vous pouvez ensuite utiliser pour vous connecter avec le protocole RDP.
Pour de plus amples informations, veuillez consulter [Connexion avec RDP](workinginstances-rdp.md).
L'authentification est basée sur une paire de clés SSH, qui se compose d'une clé publique et d'une clé privée :
+ Vous installez la clé publique sur l'instance.
L'emplacement dépend du système d'exploitation en question, mais OpsWorks Stacks s'occupe des détails pour vous.
+ Vous stockez la clé privée localement et la fournissez à un client SSH, tel que `ssh.exe`, pour accéder à l'instance.
Le client SSH utilise la clé privée pour se connecter à l'instance.
Pour fournir un accès SSH aux utilisateurs d'une pile, vous avez besoin d'un moyen de créer les paires de clés SSH, d'installer les clés publiques sur les instances de la pile et de gérer en toute sécurité les clés privées.
Amazon EC2 propose un moyen simple d'installer une clé SSH publique sur une instance. Vous pouvez utiliser la EC2 console ou l'API Amazon pour créer une ou plusieurs paires de clés pour chaque région AWS que vous prévoyez d'utiliser. Amazon EC2 stocke les clés publiques sur AWS et vous stockez les clés privées localement. Lorsque vous lancez une instance, vous spécifiez l'une des paires de clés de la région et Amazon l'installe EC2 automatiquement sur l'instance. Vous utilisez ensuite la clé privée correspondante pour vous connecter à l'instance. Pour plus d'informations, consultez [Amazon EC2 Key Pairs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html).
Avec OpsWorks Stacks, vous pouvez spécifier l'une des paires de EC2 clés Amazon de la région lorsque vous créez une pile, et éventuellement la remplacer par une paire de clés différente lorsque vous créez chaque instance. Lorsque OpsWorks Stacks lance l' EC2 instance Amazon correspondante, il spécifie la paire de clés et Amazon EC2 installe la clé publique sur l'instance. Vous pouvez ensuite utiliser la clé privée pour vous connecter ou récupérer un mot de passe administrateur, comme vous le feriez avec une EC2 instance Amazon standard. Pour de plus amples informations, veuillez consulter [Installation d'une EC2 clé Amazon](security-settingec2key.md).
L'utilisation d'une paire de EC2 clés Amazon est pratique, mais présente deux limites importantes :
+ Une paire de EC2 clés Amazon est liée à une région AWS spécifique.
Si vous travaillez dans plusieurs régions, vous devez gérer plusieurs paires de clés.
+ Vous ne pouvez installer qu'une seule paire de EC2 clés Amazon sur une instance.
Si vous voulez autoriser plusieurs utilisateurs à se connecter, ils doivent tous avoir une copie de la clé privée, ce qui n'est pas une méthode de sécurité recommandée.
Pour les piles Linux, OpsWorks Stacks fournit un moyen plus simple et plus flexible de gérer les paires de clés SSH.
+ Chaque utilisateur enregistre une paire de clés personnelle.
Ils stockent la clé privée localement et enregistrent la clé publique auprès de OpsWorks Stacks, comme décrit dans[Enregistrement de la clé SSH publique d'un utilisateur](security-settingsshkey.md).
+ Lorsque vous définissez les autorisations utilisateur pour une pile, vous spécifiez les utilisateurs qui doivent bénéficier d'un accès SSH aux instances de la pile.
OpsWorks Stacks crée automatiquement un utilisateur système sur les instances de la pile pour chaque utilisateur autorisé et installe sa clé publique. L'utilisateur peut ensuite utiliser la clé privée correspondante pour se connecter, comme décrit dans [Connexion avec SSH](workinginstances-ssh.md).
L'utilisation de clés SSH personnelles présente les avantages suivants.
+ Il n'est pas nécessaire de configurer manuellement les clés sur les instances ; OpsWorks Stacks installe automatiquement les clés publiques appropriées sur chaque instance.
+ OpsWorks Stacks installe uniquement les clés publiques personnelles des utilisateurs autorisés.
Les utilisateurs non autorisés ne peuvent pas utiliser leur clé privée personnelle pour accéder aux instances. Avec les paires de EC2 clés Amazon, tout utilisateur possédant la clé privée correspondante peut se connecter, avec ou sans accès SSH autorisé.
+ Si un utilisateur n'a plus besoin de l'accès SSH, vous pouvez utiliser la page [**Autorisations**](opsworks-security-users-manage-edit.md) pour révoquer les autorisations SSH/RDP de l'utilisateur.
OpsWorks Stacks désinstalle immédiatement la clé publique des instances de la pile.
+ Vous pouvez utiliser la même clé pour n'importe quelle région AWS.
Les utilisateurs ne doivent gérer qu'une seule clé privée.
+ Il n'y a pas besoin de partager les clés privées.
Chaque utilisateur a sa propre clé privée.
+ Il est facile d'effectuer une rotation des clés.
Vous ou l'utilisateur mettez à jour la clé publique dans **Mes paramètres** et OpsWorks Stacks met automatiquement à jour les instances.
# Installation d'une EC2 clé Amazon
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Lorsque vous créez une pile, vous pouvez spécifier une clé Amazon EC2 SSH installée par défaut sur chaque instance de la pile.
![\[Liste des clés SSH par défaut sur la page Ajouter une pile\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/ec2_keys.png)
La liste des **clés SSH par défaut** indique Amazon EC2keys de votre compte AWS. Vous pouvez effectuer l’une des actions suivantes :
+ Sélectionnez la clé appropriée dans la liste.
+ Sélectionnez **Ne pas utiliser de clé SSH par défaut** pour ne spécifier aucun clé.
Si vous avez sélectionné **Ne pas utiliser de clé SSH par défaut** ou que vous ne voulez pas remplacer la clé par défaut d'une pile, vous pouvez spécifier une clé lorsque vous créez une instance.
![\[Spécification d'une clé SSH\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/instance_keys.png)
Lorsque vous démarrez l'instance, OpsWorks Stacks installe la clé publique dans le `authorized_keys` fichier.
# Enregistrement de la clé SSH publique d'un utilisateur
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Il existe deux façons d'enregistrer la clé publique SSH d'un utilisateur :
+ Un utilisateur administratif peut attribuer une clé publique SSH à un ou plusieurs utilisateurs et leur offrir la clé privée correspondante.
+ Un utilisateur administratif peut activer la gestion automatique pour un ou plusieurs utilisateurs.
Ces utilisateurs peuvent alors spécifier leur propre clé publique SSH.
Pour plus d'informations sur la façon dont les utilisateurs administratifs peuvent activer la gestion automatique ou attribuer des clés publiques aux utilisateurs, consultez [Modification des paramètres utilisateur](opsworks-security-users-manage-edit.md).
La connexion à des instances basées sur Linux à l'aide de SSH dans un terminal PuTTY requiert des étapes supplémentaires. Pour plus d'informations, consultez la page [Connexion à votre instance Linux à partir de Windows à l'aide de PuTTY](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html) et [Dépannage de la connexion à votre instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html) dans la documentation AWS.
Ce qui suit décrit comment un utilisateur dont l'autogestion est activée peut spécifier sa clé publique.
**Pour spécifier votre clé publique SSH**
1. Créez une paire de clés SSH.
L'approche la plus simple consiste à générer la paire de clés localement. Pour plus d'informations, consultez [Comment générer votre propre clé et l'importer sur Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/generating-a-keypair.html#how-to-generate-your-own-key-and-import-it-to-aws).
**Note**
Si vous utilisez Pu TTYgen pour générer votre paire de clés, copiez la clé publique depuis la clé publique **pour la coller dans le champ de fichier openSSH authorized\$1keys**. Cliquez sur **Enregistrer la clé publique** pour enregistrer la clé publique dans un format non pris en charge par MindTerm.
1. Connectez-vous à la console OpsWorks Stacks en tant qu'utilisateur IAM avec l'autogestion activée.
**Important**
**Si vous vous connectez en tant que propriétaire du compte ou en tant qu'utilisateur IAM pour lequel l'autogestion n'est pas activée, OpsWorks Stacks n'affiche pas Mes paramètres.** Si vous êtes un utilisateur administratif ou le propriétaire du compte, vous pouvez spécifier à la place les clés SSH en accédant à la page **Users** et [en modifiant les paramètres de l'utilisateur](opsworks-security-users-manage-edit.md).
1. Sélectionnez **Mes paramètres**, qui affiche les paramètres de l'utilisateur connecté.
![\[Lien Mes paramètres dans le OpsWorks tableau de bord.\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/permissions-mysettings-link.png)
1. Sur la page **Mes paramètres**, cliquez sur **Modifier**.
![\[Bouton Modifier de la page Mes paramètres.\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/mysettings-editbutton.png)
1. Dans la zone **Clé publique SSH**, saisissez votre clé publique SSH, puis cliquez sur **Enregistrer**.
![\[Zone Clé publique SSH de la page Mes paramètres.\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/mysettings-setsshkey.png)
**Important**
Pour utiliser le client MindTerm SSH intégré pour se connecter aux EC2 instances Amazon, un utilisateur doit être connecté en tant qu'utilisateur IAM et disposer d'une clé SSH publique enregistrée auprès de Stacks. OpsWorks Pour de plus amples informations, veuillez consulter [Utilisation du client MindTerm SSH intégré](workinginstances-ssh-mindterm.md).
# Gestion des mises à jour de sécurité Linux
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
## Mises à jour de sécurité
Les fournisseurs de systèmes d'exploitation Linux fournissent des mises à jour régulières, dont la plupart sont des correctifs de sécurité du système d'exploitation, mais elles peuvent aussi inclure les mises à jour des packages installés. Vous devez vous assurer que les systèmes d'exploitation de vos instances sont à jour avec les derniers correctifs de sécurité.
Par défaut, OpsWorks Stacks installe automatiquement les dernières mises à jour lors de l'installation, une fois le démarrage d'une instance terminé. OpsWorks Stacks n'installe pas automatiquement les mises à jour une fois qu'une instance est en ligne, afin d'éviter des interruptions telles que le redémarrage des serveurs d'applications. Au lieu de cela, comme vous gérez les mises à jour de vos instances en ligne vous-même, vous pouvez réduire les perturbations.
Nous vous recommandons d'utiliser l'une des actions suivantes pour mettre à jour vos instances en ligne.
+ Créez et démarrez de nouvelles instances pour remplacer vos instances en ligne actuelles. Puis, supprimez les instances en cours.
Les nouvelles instances bénéficient de l'ensemble des correctifs de sécurité les plus récents pendant l'installation.
+ Sur les instances Linux des piles Chef 11.10 ou plus anciennes, exécutez la [commande de pile Mettre à jour les dépendances](workingstacks-commands.md), qui installe le jeu actuel de correctifs de sécurité et autres mises à jour sur les instances spécifiées.
Pour ces deux approches, OpsWorks Stacks effectue la mise à jour en l'exécutant `yum update` pour Amazon Linux et Red Hat Enterprise Linux (RHEL) ou `apt-get update` pour Ubuntu. Comme chaque distribution gère les mises à jour un peu différemment, vous devez examiner les informations contenues dans les liens associés pour comprendre exactement comment une mise à jour affecte vos instances :
+ **Amazon Linux** — Les mises à jour d'Amazon Linux installent des correctifs de sécurité et peuvent également installer des mises à jour de fonctionnalités, notamment des mises à jour de packages.
Pour plus d'informations, consultez [AMI Amazon Linux FAQs](https://aws.amazon.com/amazon-linux-ami/faqs/#lock).
+ **Ubuntu** — Les mises à jour d'Ubuntu se limitent en grande partie à l'installation de correctifs de sécurité, mais peuvent également installer des mises à jour de packages pour un nombre limité de correctifs critiques.
Pour plus d'informations, consultez [LTS - Ubuntu Wiki](https://wiki.ubuntu.com/LTS).
+ **CentOS — Les** mises à jour de CentOS conservent généralement la compatibilité binaire avec les versions antérieures.
+ **RHEL** — Les mises à jour de RHEL maintiennent généralement la compatibilité binaire avec les versions antérieures.
Pour plus d'informations, consultez [Cycle de vie Red Hat Enterprise Linux](https://access.redhat.com/support/policy/updates/errata/).
Si vous souhaitez mieux contrôler les mises à jour, par exemple en spécifiant des versions de package spécifiques, vous pouvez désactiver les mises à jour automatiques en utilisant les [UpdateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateLayer.html)actions [CreateInstance](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateInstance.html), [UpdateInstance](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateInstance.html), ou [CreateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateLayer.html), ou les méthodes du [SDK](https://aws.amazon.com/tools/) AWS ou les commandes de la [CLI](https://aws.amazon.com/documentation/cli/) AWS équivalentes, pour définir le paramètre sur. `InstallUpdatesOnBoot` `false` L'exemple suivant montre comment utiliser l'interface de ligne de commande AWS pour désactiver `InstallUpdatesOnBoot` comme paramètre par défaut d'une couche existante.
```
aws opsworks update-layer --layer-id layer ID --no-install-updates-on-boot
```
Vous devez ensuite gérer vous-même les mises à jour. Par exemple, vous pourriez faire appel à l'une de ces stratégies :
+ Mettre en œuvre une recette personnalisée qui [exécute la commande shell appropriée](cookbooks-101-basics-commands.md#cookbooks-101-basics-commands-script) pour installer vos mises à jour préférées.
Comme les mises à jour système ne correspondent pas naturellement à un [événement du cycle de vie](workingcookbook-events.md), incluez la recette dans vos livres de recettes personnalisés, mais [exécutez-la manuellement](workingcookbook-manual.md). Pour les mises à jour de package, vous pouvez aussi utiliser les ressources [yum\$1package](https://docs.chef.io/chef/resources.html#yum-package) (Amazon Linux) ou [apt\$1package](https://docs.chef.io/chef/resources.html#apt-package) (Ubuntu) au lieu d'une commande shell.
+ [Connectez-vous à chaque instance avec SSH](workinginstances-ssh.md) et exécutez les commandes appropriées manuellement.
# Utilisation des groupes de sécurité
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
## Groupes de sécurité
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Chaque EC2 instance Amazon possède un ou plusieurs groupes de sécurité associés qui régissent le trafic réseau de l'instance, un peu comme un pare-feu. Un groupe de sécurité a une ou plusieurs *règles*, chacune spécifiant une catégorie spécifique de trafic autorisé. Une règle spécifie les éléments suivants :
+ Le type de trafic autorisé, par exemple SSH ou HTTP
+ Le protocole du trafic, tel que TCP ou UDP
+ La plage d'adresses IP dont le trafic peut provenir
+ La plage de ports autorisée pour le trafic
Les groupes de sécurité ont deux types de règles :
+ Les règles de trafic entrant qui gèrent le trafic réseau entrant.
Par exemple, les instances de serveur d'applications ont généralement une règle entrante qui autorise le trafic HTTP entrant à partir de n'importe quelle adresse IP sur le port 80 et une autre règle de trafic entrant qui autorise le trafic SSH entrant vers le port 22 et provenant d'une plage d'adresses IP spécifiée.
+ Les règles de trafic sortant gèrent le trafic réseau sortant.
Une pratique courante consiste à utiliser le paramètre par défaut, qui autorise tout le trafic sortant.
Pour plus d'informations sur les groupes de sécurité, consultez [Amazon EC2 Security Groups](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html).
La première fois que vous créez une pile dans une région, OpsWorks Stacks crée un groupe de sécurité intégré pour chaque couche avec un ensemble de règles approprié. Tous les groupes ont des règles de trafic sortant par défaut qui autorisent tout le trafic sortant. En général, les règles de trafic entrant autorisent les éléments suivants :
+ Trafic TCP, UDP et ICMP entrant provenant des couches Stacks appropriées OpsWorks
+ Trafic TCP entrant sur le port 22 (connexion SSH)
**Avertissement**
La configuration du groupe de sécurité par défaut ouvre SSH (port 22) vers n'importe quel emplacement réseau (0.0.0.0/0.). Cela permet à toutes les adresses IP d'accéder à votre instance à l'aide de SSH. Pour les environnements de production, vous devez utiliser une configuration qui autorise uniquement l'accès SSH à partir d'une adresse IP spécifique ou d'une plage d'adresses. Mettez à jour les groupes de sécurité par défaut immédiatement après leur création ou utilisez des groupes de sécurité personnalisés à la place.
+ Pour les couches de serveur web, tout le trafic entrant TCP et UDP vers les ports 80 (HTTP) et 443 (HTTPS)
**Note**
Le groupe de sécurité intégré `AWS-OpsWorks-RDP-Server` est attribué à toutes les instances Windows pour autoriser un accès RDP. Toutefois, par défaut, il n'a pas de règles. Si vous exécutez une pile Windows et que vous souhaitez utiliser RDP pour accéder aux instances, vous devez ajouter une règle entrante qui autorise l'accès RDP. Pour de plus amples informations, veuillez consulter [Connexion avec RDP](workinginstances-rdp.md).
Pour consulter les détails de chaque groupe, accédez à la [ EC2console Amazon](https://console.aws.amazon.com/ec2/), sélectionnez **Security Groups** dans le volet de navigation, puis sélectionnez le groupe de sécurité de la couche appropriée. Par exemple, **AWS- OpsWorks -Default-Server** est le groupe de sécurité intégré par défaut pour toutes les piles, et **AWS OpsWorks WebApp -** est le groupe de sécurité intégré par défaut pour la pile d'échantillons Chef 12.
**Note**
Si vous supprimez accidentellement un groupe de sécurité OpsWorks Stacks, il est préférable de le recréer en demandant à OpsWorks Stacks d'effectuer la tâche à votre place. Créez simplement une nouvelle pile dans la même région AWS (et un VPC, le cas échéant OpsWorks ). Stacks recréera automatiquement tous les groupes de sécurité intégrés, y compris celui que vous avez supprimé. Vous pouvez ensuite supprimer la pile si vous n'en avez plus l'utilisation ; les groupes de sécurité demeureront. Si vous souhaitez recréer le groupe de sécurité manuellement, il doit être une copie exacte de l'original, y compris les majuscules du nom du groupe.
En outre, OpsWorks Stacks tentera de recréer tous les groupes de sécurité intégrés si l'une des situations suivantes se produit :
Vous pouvez apporter des modifications à la page des paramètres de la pile dans la console OpsWorks Stacks.
Vous démarrez l'un des instances de la pile.
Vous créez une pile.
Vous pouvez utiliser l'une des approches suivantes pour spécifier les groupes de sécurité. Vous utilisez le paramètre **Utiliser les groupes de OpsWorks sécurité** pour définir vos préférences lorsque vous créez une pile.
+ **Oui** (paramètre par défaut) — OpsWorks Stacks associe automatiquement le groupe de sécurité intégré approprié à chaque couche.
Vous pouvez ajuster le groupe de sécurité intégré d'une couche en ajoutant un groupe de sécurité personnalisé avec vos paramètres préférés. Toutefois, lorsqu'Amazon EC2 évalue plusieurs groupes de sécurité, il utilise les règles les moins restrictives. Vous ne pouvez donc pas utiliser cette approche pour définir des règles plus restrictives que le groupe intégré.
+ **Non**, OpsWorks Stacks n'associe pas les groupes de sécurité intégrés aux couches.
Vous devez créer des groupes de sécurité appropriés et en associer au moins un à chaque couche que vous créez. Cette approche permet de spécifier des règles plus contraignantes que celles des groupes intégrés. Notez qu'il reste possible d'associer manuellement un groupe de sécurité intégré à une couche. Les groupes de sécurité personnalisés ne sont nécessaires que pour les couches requérant des paramètres personnalisés.
**Important**
Si vous utilisez les groupes de sécurité intégrés, vous ne pouvez pas créer de règles plus contraignantes en modifiant manuellement les paramètres du groupe. Chaque fois que vous créez une pile, OpsWorks Stacks remplace les configurations des groupes de sécurité intégrés, de sorte que toutes les modifications que vous apportez seront perdues lors de la prochaine création d'une pile. Si une couche nécessite des paramètres de groupe de sécurité plus restrictifs que le groupe de sécurité intégré, définissez **Utiliser les groupes de OpsWorks sécurité** sur **Non**, créez des groupes de sécurité personnalisés avec vos paramètres préférés et attribuez-les aux couches lors de leur création.