Créer des politiques d’approbation pour vos nœuds

Les politiques d’approbation définissent les approbations dont les utilisateurs ont besoin pour accéder à un nœud. Étant donné que l’accès aux nœuds en flux tendu élimine le besoin d’autorisations de longue durée sur les nœuds par le biais de politiques IAM, vous devez créer des politiques d’approbation pour autoriser l’accès à vos nœuds. Si aucune politique d’approbation ne s’applique à un nœud, les utilisateurs ne peuvent pas demander l’accès au nœud.

Avec l’accès aux nœuds en flux tendu, il existe trois types de politiques. Ces types de politique sont l’approbation automatique, le refus d’accès et l’approbation manuelle.

Une politique de refus d'accès s'applique à tous les comptes d'une AWS Organizations organisation. Par exemple, vous pouvez refuser explicitement les approbations automatiques du Intern groupe aux nœuds marqués par la Production clé. Auto-approval et les politiques d'approbation manuelle ne s'appliquent qu'à Comptes AWS l' Régions AWS endroit où elles ont été créées. Chaque compte membre de votre organisation gère sa propre politique d’approbation. Les politiques d’approbation sont évaluées dans l’ordre suivant :

Bien que vous ne puissiez avoir qu’une seule politique de refus d’accès par organisation et une seule politique d’approbation automatique par compte et par région, vous aurez probablement plusieurs politiques d’approbation manuelle dans un compte. Lors de l’évaluation des politiques d’approbation manuelle, l’accès aux nœuds en flux tendu favorise toujours la politique la plus spécifique pour un nœud. Les stratégies d’approbation manuelle sont évaluées dans l’ordre suivant :

Par exemple, supposons que vous avez un nœud balisé avec la clé Demo. Dans le même compte, vous disposez d’une politique d’approbation manuelle qui cible tous les nœuds et nécessite une approbation d’un niveau. Vous avec également d’une politique d’approbation manuelle qui exige deux approbations à deux niveaux pour les nœuds balisés avec la clé Demo. Systems Manager applique la politique qui cible la balise Demo au nœud, car elle est plus spécifique que la politique qui cible tous les nœuds. Cela vous permet de créer une politique générale pour tous les nœuds de votre compte, afin que les utilisateurs puissent soumettre des demandes d’accès tout en vous permettant de créer des politiques plus détaillées selon les besoins.

En fonction de votre organisation, plusieurs balises peuvent être appliquées à vos nœuds. Dans ce scénario, si plusieurs politiques d’approbation manuelle s’appliquent à un nœud, les demandes d’accès échouent. Par exemple, supposons qu’un nœud est balisé avec les clés Production et Database. Dans le même compte, vous disposez d’une politique d’approbation manuelle qui s’applique aux nœuds balisés par la clé Production et d’une autre politique d’approbation manuelle qui s’applique aux nœuds balisés par la clé Database. Cela entraîne un conflit pour le nœud balisé avec les deux clés, et les demandes d’accès échouent. Systems Manager redirige l’utilisateur vers la demande qui a échoué. Il peut y consulter les détails des politiques et des balises en conflit afin de pouvoir effectuer les ajustements nécessaires s’il dispose des autorisations requises. Dans le cas contraire, il peut demander à un collègue de son organisation disposant des autorisations requises de modifier les politiques. Les conflits de politiques qui se traduisent par l'échec des demandes d'accès EventBridge génèrent des événements qui vous permettent de créer vos propres flux de travail de réponse en toute flexibilité. En outre, Systems Manager envoie des notifications par e-mail en cas de conflit de politique entraînant l’échec des demandes d’accès aux destinataires que vous spécifiez. Pour plus d’informations sur la configuration des notifications par e-mail pour les conflits de politique, consultez Configurer les notifications pour les demandes d’accès en flux tendu.

Dans une politique de refus d'accès, vous utilisez le langage de politique Cedar pour définir les nœuds auxquels les utilisateurs ne peuvent explicitement pas se connecter automatiquement dans votre organisation. Cette politique est créée et partagée à partir du compte d'administrateur délégué de votre organisation. La politique de refus d'accès remplace toutes les politiques d'approbation automatique. Vous ne pouvez avoir qu'une seule politique de refus d'accès par organisation.

Dans une politique d'approbation automatique, vous utilisez le langage de politique Cedar pour définir quels utilisateurs peuvent se connecter automatiquement aux nœuds spécifiés sans approbation manuelle. La durée d’accès pour une demande d’accès approuvée automatiquement est de 1 heure. Cette valeur ne peut pas être modifiée. Vous ne pouvez avoir qu'une seule politique d'approbation automatique par compte et par région.

Dans une politique d’approbation manuelle, vous spécifiez la durée d’accès, le nombre de niveaux d’approbation requis, le nombre d’approbateurs requis par niveau et les nœuds auxquels ils peuvent approuver les demandes d’accès en flux tendu. La durée d’accès pour une politique d’approbation manuelle doit être comprise entre 1 et 336 heures. Si vous spécifiez plusieurs niveaux d’approbation, les approbations pour la demande d’accès sont traitées un niveau à la fois. Cela signifie que toutes les approbations dont vous avez besoin pour un niveau doivent être fournies avant que le processus d’approbation passe aux niveaux suivants. Si vous spécifiez plusieurs balises dans une politique d’approbation manuelle, elles sont évaluées comme des instructions or et non comme des instructions and. Par exemple, si vous créez une politique d’approbation manuelle qui inclut les balises Application, Web et Test, la politique s’applique à tout nœud balisé avec l’une de ces clés. La politique ne s’applique pas uniquement aux nœuds balisés avec les trois clés.

Nous vous recommandons d’utiliser une combinaison de politiques manuelles avec votre politique d’approbation automatique pour vous aider à sécuriser les nœuds contenant des données plus critiques tout en permettant aux utilisateurs de se connecter aux nœuds moins critiques sans intervention. Par exemple, vous pouvez exiger des approbations manuelles pour les demandes d’accès aux nœuds de base de données et approuver automatiquement les sessions pour les nœuds de niveau présentation non persistants.

Les procédures suivantes décrivent comment créer des politiques d’approbation pour un accès aux nœuds en flux tendu.