• Le AWS Systems Manager CloudWatch tableau de bord ne sera plus disponible après le 30 avril 2026. Les clients peuvent continuer à utiliser CloudWatch la console Amazon pour consulter, créer et gérer leurs CloudWatch tableaux de bord Amazon, comme ils le font aujourd'hui. Pour plus d'informations, consultez la [documentation Amazon CloudWatch Dashboard](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html).
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.
# Just-in-time accès aux nœuds à l'aide de Systems Manager
Systems Manager vous aide à améliorer la sécurité de vos nœuds en facilitant *just-in-time*l'accès. Just-in-timel'accès aux nœuds permet aux utilisateurs de demander un accès temporaire limité dans le temps aux nœuds, que vous ne pouvez approuver que lorsque l'accès est réellement nécessaire. Il n'est donc plus nécessaire de fournir un accès permanent aux nœuds gérés par des politiques IAM. En outre, Systems Manager fournit un enregistrement de session pour les sessions RDP aux Windows Server nœuds afin de vous aider à répondre aux exigences de conformité, à effectuer une analyse des causes premières, etc. Pour utiliser l'accès aux just-in-time nœuds, vous devez configurer la console unifiée Systems Manager.
Avec l'accès aux just-in-time nœuds, vous créez des politiques IAM granulaires pour garantir que seuls les utilisateurs autorisés peuvent soumettre des demandes d'accès à vos nœuds. Vous créez ensuite des *politiques d’approbation* qui définissent les approbations requises pour vous connecter à vos nœuds. Pour l'accès aux just-in-time nœuds, il existe des politiques *d'approbation automatique* et des politiques *d'approbation manuelle*. Une politique d’approbation automatique définit les nœuds auxquels les utilisateurs peuvent se connecter automatiquement. Les politiques d’approbation manuelle définissent le nombre et les niveaux d’approbations manuelles qui doivent être fournis pour accéder aux nœuds que vous spécifiez. Vous pouvez également créer une politique de *refus d’accès*. Une politique de refus d’accès empêche explicitement l’approbation automatique des demandes d’accès aux nœuds que vous spécifiez. Une politique de refus d'accès s'applique à tous les comptes d'une AWS Organizations organisation. Les politiques d'approbation automatique et d'approbation manuelle s'appliquent uniquement au Régions AWS lieu Comptes AWS et à l'endroit où elles ont été créées.
Lorsqu’un utilisateur tente de se connecter à un nœud, il est invité à saisir le motif de son accès au nœud. Vos politiques d’approbation sont ensuite évaluées. Selon vos politiques, les utilisateurs se connectent automatiquement au nœud cible, ou Systems Manager crée automatiquement une demande d’approbation manuelle au nom du demandeur. Les approbateurs spécifiés dans la politique d’approbation manuelle qui s’applique au nœud sont ensuite informés de la demande d’accès et peuvent approuver ou refuser la demande. Les approbateurs et demandeurs peuvent être avertis par e-mail ou via Amazon Q Developer dans le cadre de l’intégration des applications de chat à Slack ou Microsoft Teams. Systems Manager n’accorde l’accès aux nœuds demandés que lorsque les approbateurs spécifiés fournissent toutes les approbations requises. Une fois que toutes les approbations requises ont été reçues, l’utilisateur peut démarrer autant de sessions sur le nœud que nécessaire pendant la durée de la fenêtre d’accès spécifiée dans la politique d’approbation. Systems Manager ne met pas automatiquement fin aux sessions d'accès aux just-in-time nœuds. Il est recommandé de spécifier des valeurs pour la *durée maximale de session* et les préférences de *délai d’inactivité des sessions*. Ces préférences empêchent les utilisateurs de rester connectés aux nœuds au-delà de leur fenêtre d’accès approuvée.
Nous vous recommandons d’utiliser une combinaison de politiques d’approbation pour vous aider à sécuriser les nœuds contenant des données plus critiques tout en permettant aux utilisateurs de se connecter à des 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.
Systems Manager prend en charge l'accès aux just-in-time nœuds pour les utilisateurs fédérés avec IAM Identity Center ou IAM. Lorsqu’un utilisateur fédéré soumet une demande d’accès, il indique le nœud cible et la raison pour laquelle il doit se connecter au nœud. Systems Manager compare l’identité de l’utilisateur aux paramètres définis dans les politiques d’approbation de votre organisation. Lorsque les conditions de la politique d’approbation automatique sont remplies ou que les approbateurs fournissent manuellement des approbateurs, le demandeur peut se connecter au nœud cible. Lorsqu’un utilisateur tente de se connecter à un nœud approuvé, Systems Manager crée et utilise un jeton temporaire pour établir la session.
Étant donné que le service Systems Manager gère l’authentification des demandes d’accès et l’établissement des sessions, vous n’avez pas besoin d’utiliser les politiques IAM pour gérer l’accès à vos nœuds. En utilisant l'accès aux just-in-time nœuds, Systems Manager aide votre entreprise à se rapprocher de l'absence de privilèges permanents, car il vous suffit d'autoriser les utilisateurs à créer des demandes d'accès au lieu de les autoriser à démarrer des sessions avec des autorisations permanentes sur vos nœuds. Pour vous aider à répondre aux exigences de conformité, Systems Manager conserve toutes les demandes d’accès pendant un an. Systems Manager émet également des EventBridge événements pour l'accès aux just-in-time nœuds en cas d'échec des demandes d'accès et des mises à jour du statut des demandes d'accès pour des approbations manuelles. Pour plus d'informations, voir,[Surveillance des événements de Systems Manager avec Amazon EventBridge](monitoring-eventbridge-events.md).
**Topics**
+ [Configuration de just-in-time l'accès avec Systems Manager](systems-manager-just-in-time-node-access-setting-up.md)
+ [Démarrer une session d'accès aux just-in-time nœuds](systems-manager-just-in-time-node-access-start-session.md)
+ [Gestion des demandes just-in-time d'accès](systems-manager-just-in-time-node-access-manage-requests.md)
+ [Passage à l'accès aux just-in-time nœuds depuis Session Manager](systems-manager-just-in-time-node-access-moving-from-session-manager.md)
+ [Désactivation de just-in-time l'accès avec Systems Manager](systems-manager-just-in-time-node-access-disable.md)
+ [Just-in-time questions fréquemment posées sur l'accès aux nœuds](just-in-time-node-access-faq.md)
# Configuration de just-in-time l'accès avec Systems Manager
La configuration de l'accès aux just-in-time nœuds avec Systems Manager impliquait plusieurs étapes. Vous devez d'abord choisir les *cibles* pour lesquelles vous souhaitez configurer l'accès aux just-in-time nœuds. Les cibles comprennent les unités AWS Organizations organisationnelles (OUs) et Régions AWS. Par défaut, les mêmes cibles que celles que vous avez choisies lors de la configuration de la console unifiée Systems Manager sont sélectionnées pour l'accès aux just-in-time nœuds. Vous pouvez choisir de configurer l'accès aux just-in-time nœuds pour toutes les mêmes cibles ou pour un sous-ensemble des cibles que vous avez spécifiées lors de la configuration de la console unifiée Systems Manager. L'ajout de nouvelles cibles qui n'ont pas été sélectionnées lors de la configuration de la console unifiée Systems Manager n'est pas pris en charge.
Vous allez ensuite créer des *politiques d’approbation* pour déterminer quand les connexions aux nœuds nécessitent une approbation manuelle et sont automatiquement approuvées. Les politiques d’approbation sont gérées par chaque compte de votre organisation. Vous pouvez également partager une politique depuis le compte d’administrateur délégué pour refuser explicitement l’approbation automatique des connexions à des nœuds spécifiques.
**Note**
La configuration de l'accès aux just-in-time nœuds n'affecte pas les politiques ou préférences IAM existantes pour Session Manager lesquelles vous avez configuré. Vous devez supprimer l'autorisation d'effectuer l'action d'`StartSession`API dans vos politiques IAM afin de garantir que seul l'accès aux just-in-time nœuds est utilisé lorsque les utilisateurs tentent de se connecter à vos nœuds. Après avoir configuré l'accès aux just-in-time nœuds, nous vous recommandons de tester vos politiques d'approbation auprès d'un sous-ensemble d'utilisateurs et de nœuds afin de vérifier que vos politiques fonctionnent comme vous le souhaitez avant de supprimer les autorisations deSession Manager.
**Prise en charge de l'authentification**
Notez les informations suivantes concernant la prise en charge de l'authentification utilisée pour l'accès aux just-in-time nœuds :
+ Just-in-time l'accès aux nœuds ne prend pas en charge le type d'authentification unique lors de la connexion à des Windows Server instances avec Remote Desktop.
+ Seules AWS Security Token Service (AWS STS) les informations d'identification de sécurité `AssumeRole` temporaires sont prises en charge. Pour plus d’informations, consultez les rubriques suivantes dans le *Guide de l’utilisateur IAM* :
+
+ [Informations d'identification de sécurité temporaires dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [Comparaison des AWS STS informations d'identification](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_sts-comparison.html)
+ [Demande d'informations d'identification de sécurité temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html)
Les politiques IAM suivantes décrivent les autorisations nécessaires pour administrer et permettre aux utilisateurs de créer des demandes d'accès aux just-in-time nœuds avec Systems Manager. Après avoir vérifié que vous disposez des autorisations requises pour utiliser l'accès aux just-in-time nœuds avec Systems Manager, vous pouvez poursuivre le processus de configuration. Remplacez chaque *example resource placeholder* par vos propres informations.
## Politique IAM pour permettre l' just-in-timeaccès aux nœuds
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "QuickSetupConfigurationManagers",
"Effect": "Allow",
"Action": [
"ssm-quicksetup:CreateConfigurationManager",
"ssm-quicksetup:DeleteConfigurationManager",
"ssm-quicksetup:GetConfiguration",
"ssm-quicksetup:GetConfigurationManager",
"ssm-quicksetup:GetServiceSettings",
"ssm-quicksetup:ListConfigurationManagers",
"ssm-quicksetup:ListConfigurations",
"ssm-quicksetup:ListQuickSetupTypes",
"ssm-quicksetup:ListTagsForResource",
"ssm-quicksetup:TagResource",
"ssm-quicksetup:UntagResource",
"ssm-quicksetup:UpdateConfigurationDefinition",
"ssm-quicksetup:UpdateConfigurationManager",
"ssm-quicksetup:UpdateServiceSettings"
],
"Resource": "*"
},
{
"Sid": "QuickSetupDeployments",
"Effect": "Allow",
"Action": [
"cloudformation:DescribeStackSetOperation",
"cloudformation:ListStacks",
"cloudformation:DescribeStacks",
"cloudformation:DescribeStackResources",
"cloudformation:ListStackSetOperations",
"cloudformation:ListStackInstances",
"cloudformation:DescribeStackSet",
"cloudformation:ListStackSets",
"cloudformation:DescribeStackInstance",
"cloudformation:DescribeOrganizationsAccess",
"cloudformation:ActivateOrganizationsAccess",
"cloudformation:GetTemplate",
"cloudformation:ListStackSetOperationResults",
"cloudformation:DescribeStackEvents",
"cloudformation:UntagResource",
"ssm:DescribeAutomationExecutions",
"ssm:GetAutomationExecution",
"ssm:ListAssociations",
"ssm:DescribeAssociation",
"ssm:GetDocument",
"ssm:ListDocuments",
"ssm:DescribeDocument",
"ssm:GetOpsSummary",
"organizations:DeregisterDelegatedAdministrator",
"organizations:DescribeAccount",
"organizations:DescribeOrganization",
"organizations:ListDelegatedAdministrators",
"organizations:ListRoots",
"organizations:ListParents",
"organizations:ListOrganizationalUnitsForParent",
"organizations:DescribeOrganizationalUnit",
"organizations:ListAWSServiceAccessForOrganization",
"iam:ListRoles",
"iam:ListRolePolicies",
"iam:GetRole",
"iam:CreatePolicy",
"cloudformation:TagResource"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudformation:RollbackStack",
"cloudformation:CreateStack",
"cloudformation:UpdateStack",
"cloudformation:DeleteStack"
],
"Resource": [
"arn:aws:cloudformation:*:*:stack/StackSet-AWS-QuickSetup-JITNA*",
"arn:aws:cloudformation:*:*:stack/AWS-QuickSetup-*",
"arn:aws:cloudformation:*:*:type/resource/*",
"arn:aws:cloudformation:*:*:stack/StackSet-SSMQuickSetup"
]
},
{
"Sid": "StackSetOperations",
"Effect": "Allow",
"Action": [
"cloudformation:CreateStackSet",
"cloudformation:UpdateStackSet",
"cloudformation:DeleteStackSet",
"cloudformation:DeleteStackInstances",
"cloudformation:CreateStackInstances",
"cloudformation:StopStackSetOperation"
],
"Resource": [
"arn:aws:cloudformation:*:*:stackset/AWS-QuickSetup-JITNA*",
"arn:aws:cloudformation:*:*:type/resource/*",
"arn:aws:cloudformation:*:*:stackset-target/AWS-QuickSetup-JITNA*:*"
]
},
{
"Sid": "IamRolesMgmt",
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:DeleteRole",
"iam:GetRole",
"iam:AttachRolePolicy",
"iam:PutRolePolicy",
"iam:DetachRolePolicy",
"iam:GetRolePolicy",
"iam:ListRolePolicies"
],
"Resource": [
"arn:aws:iam::*:role/AWS-QuickSetup-JITNA*",
"arn:aws:iam::*:role/service-role/AWS-QuickSetup-JITNA*"
]
},
{
"Sid": "IamPassRole",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/AWS-QuickSetup-JITNA*",
"arn:aws:iam::*:role/service-role/AWS-QuickSetup-JITNA*"
],
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"ssm.amazonaws.com",
"ssm-quicksetup.amazonaws.com",
"cloudformation.amazonaws.com"
]
}
}
},
{
"Sid": "SSMAutomationExecution",
"Effect": "Allow",
"Action": "ssm:StartAutomationExecution",
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/AWS-EnableExplorer",
"arn:aws:ssm:us-east-1:111122223333:automation-execution/*"
]
},
{
"Sid": "SSMAssociationPermissions",
"Effect": "Allow",
"Action": [
"ssm:DeleteAssociation",
"ssm:CreateAssociation",
"ssm:StartAssociationsOnce"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:association/*"
},
{
"Sid": "SSMResourceDataSync",
"Effect": "Allow",
"Action": [
"ssm:CreateResourceDataSync",
"ssm:UpdateResourceDataSync"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:resource-data-sync/AWS-QuickSetup-*"
},
{
"Sid": "ListResourceDataSync",
"Effect": "Allow",
"Action": [
"ssm:ListResourceDataSync"
],
"Resource": "*"
},
{
"Sid": "CreateServiceLinkedRoles",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Condition": {
"StringEquals": {
"iam:AWSServiceName": [
"accountdiscovery.ssm.amazonaws.com",
"ssm.amazonaws.com",
"ssm-quicksetup.amazonaws.com",
"stacksets.cloudformation.amazonaws.com"
]
}
},
"Resource": "*"
},
{
"Sid": "CreateStackSetsServiceLinkedRole",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/stacksets.cloudformation.amazonaws.com/AWSServiceRoleForCloudFormationStackSetsOrgAdmin"
},
{
"Sid": "AllowSsmJitnaPoliciesCrudOperations",
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:UpdateDocument",
"ssm:UpdateDocumentDefaultVersion",
"ssm:GetDocument",
"ssm:DescribeDocument",
"ssm:DeleteDocument"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-JustInTimeAccessDenyAccessOrgPolicy"
],
"Condition": {
"StringEquals": {
"ssm:DocumentType": [
"AutoApprovalPolicy"
]
}
}
},
{
"Sid": "AllowAccessRequestOpsItemOperations",
"Effect": "Allow",
"Action": [
"ssm:GetOpsItem",
"ssm:DescribeOpsItems",
"ssm:GetOpsSummary",
"ssm:DeleteOpsItem",
"ssm:ListOpsItemEvents"
],
"Resource": "*"
},
{
"Sid": "IdentityCenterPermissions",
"Effect": "Allow",
"Action": [
"sso:DescribeRegisteredRegions",
"sso:ListDirectoryAssociations",
"identitystore:GetUserId",
"identitystore:DescribeUser",
"identitystore:DescribeGroup",
"identitystore:ListGroupMembershipsForMember"
],
"Resource": "*"
}
]
}
```
------
## Politique IAM pour configurer l'accès aux just-in-time nœuds
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSsmJitnaPoliciesCrudOperations",
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:UpdateDocument",
"ssm:UpdateDocumentDefaultVersion",
"ssm:GetDocument",
"ssm:DescribeDocument",
"ssm:DeleteDocument"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/*"
],
"Condition": {
"StringEquals": {
"ssm:DocumentType": [
"ManualApprovalPolicy",
"AutoApprovalPolicy"
]
}
}
},
{
"Sid": "AllowSsmJitnaPoliciesListOperations",
"Effect": "Allow",
"Action": [
"ssm:ListDocuments",
"ssm:ListDocumentVersions"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/SSM-JustInTimeAccessTokenRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"justintimeaccess.ssm.amazonaws.com"
]
}
}
},
{
"Sid": "AllowAccessRequestOpsItemOperations",
"Effect": "Allow",
"Action": [
"ssm:GetOpsItem",
"ssm:DescribeOpsItems",
"ssm:GetOpsSummary",
"ssm:DeleteOpsItem",
"ssm:ListOpsItemEvents"
],
"Resource": "*"
},
{
"Sid": "AllowSessionManagerPreferencesOperation",
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:GetDocument",
"ssm:DescribeDocument",
"ssm:UpdateDocument",
"ssm:DeleteDocument"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell",
"Condition": {
"StringEquals": {
"ssm:DocumentType": "Session"
}
}
},
{
"Sid": "AllowSessionManagerOperations",
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus",
"ssm:TerminateSession"
],
"Resource": "*"
},
{
"Sid": "AllowRDPConnectionRecordingOperations",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:UpdateConnectionRecordingPreferences",
"ssm-guiconnect:GetConnectionRecordingPreferences",
"ssm-guiconnect:DeleteConnectionRecordingPreferences"
],
"Resource": "*"
},
{
"Sid": "AllowRDPConnectionRecordingKmsOperation",
"Effect": "Allow",
"Action": [
"kms:CreateGrant"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/SystemsManagerJustInTimeNodeAccessManaged": "true"
},
"StringLike": {
"kms:ViaService": "ssm-guiconnect.*.amazonaws.com"
},
"Bool": {
"aws:ViaAWSService": "true"
}
}
},
{
"Sid": "AllowFleetManagerOperations",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:GetConnection",
"ssm-guiconnect:ListConnections"
],
"Resource": "*"
},
{
"Sid": "SNSTopicManagement",
"Effect": "Allow",
"Action": [
"sns:CreateTopic",
"sns:SetTopicAttributes"
],
"Resource": [
"arn:aws:sns:us-east-1:111122223333:SSM-JITNA*"
]
},
{
"Sid": "SNSListTopics",
"Effect": "Allow",
"Action": [
"sns:ListTopics"
],
"Resource": "*"
},
{
"Sid": "EventBridgeRuleManagement",
"Effect": "Allow",
"Action": [
"events:PutRule",
"events:PutTargets"
],
"Resource": [
"arn:aws:events:us-east-1::rule/SSM-JITNA*"
]
},
{
"Sid": "ChatbotSlackManagement",
"Effect": "Allow",
"Action": [
"chatbot:CreateSlackChannelConfiguration",
"chatbot:UpdateSlackChannelConfiguration",
"chatbot:DescribeSlackChannelConfigurations",
"chatbot:DescribeSlackWorkspaces",
"chatbot:DeleteSlackChannelConfiguration",
"chatbot:RedeemSlackOauthCode",
"chatbot:DeleteSlackWorkspaceAuthorization",
"chatbot:GetSlackOauthParameters"
],
"Resource": "*"
},
{
"Sid": "ChatbotTeamsManagement",
"Effect": "Allow",
"Action": [
"chatbot:ListMicrosoftTeamsChannelConfigurations",
"chatbot:CreateMicrosoftTeamsChannelConfiguration",
"chatbot:UpdateMicrosoftTeamsChannelConfiguration",
"chatbot:ListMicrosoftTeamsConfiguredTeams",
"chatbot:DeleteMicrosoftTeamsChannelConfiguration",
"chatbot:RedeemMicrosoftTeamsOauthCode",
"chatbot:DeleteMicrosoftTeamsConfiguredTeam",
"chatbot:GetMicrosoftTeamsOauthParameters",
"chatbot:TagResource"
],
"Resource": "*"
},
{
"Sid": "SSMEmailSettings",
"Effect": "Allow",
"Action": [
"ssm:UpdateServiceSetting",
"ssm:GetServiceSetting"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/access-request/email-role-mapping",
"arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/access-request/enabled-email-notifications"
]
},
{
"Sid": "AllowViewingJitnaCloudWatchMetrics",
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricData",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"cloudwatch:namespace": "AWS/SSM/JustInTimeAccess"
}
}
},
{
"Sid": "QuickSetupConfigurationManagers",
"Effect": "Allow",
"Action": [
"ssm-quicksetup:ListConfigurationManagers",
"ssm-quicksetup:ListConfigurations",
"ssm-quicksetup:ListQuickSetupTypes",
"ssm-quicksetup:GetConfiguration",
"ssm-quicksetup:GetConfigurationManager"
],
"Resource": "*"
},
{
"Sid": "QuickSetupDeployments",
"Effect": "Allow",
"Action": [
"cloudformation:ListStacks",
"cloudformation:DescribeStacks",
"organizations:DescribeOrganization",
"organizations:ListDelegatedAdministrators"
],
"Resource": "*"
},
{
"Sid": "ManualPolicy",
"Effect": "Allow",
"Action": [
"sso:DescribeRegisteredRegions",
"ssm:GetServiceSetting",
"iam:ListRoles"
],
"Resource": "*"
},
{
"Sid": "SessionPreference",
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets"
],
"Resource": "*"
},
{
"Sid": "AllowIamListForKMS",
"Effect": "Allow",
"Action": [
"iam:ListUsers"
],
"Resource": "arn:aws:iam::111122223333:user/*"
},
{
"Sid": "KMSPermission",
"Effect": "Allow",
"Action": [
"kms:TagResource",
"kms:ListAliases",
"kms:CreateAlias"
],
"Resource": "*"
},
{
"Sid": "KMSCreateKey",
"Effect": "Allow",
"Action": [
"kms:CreateKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/SystemsManagerJustInTimeNodeAccessManaged": "true"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"SystemsManagerJustInTimeNodeAccessManaged"
]
}
}
},
{
"Sid": "AllowIamRoleForChatbotAction",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/role name",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"chatbot.amazonaws.com"
]
}
}
},
{
"Sid": "AllowIamServiceRoleForChat",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/management.chatbot.amazonaws.com/AWSServiceRoleForAWSChatbot"
},
{
"Sid": "CloudWatchLogs",
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups"
],
"Resource": "arn:aws:logs:*:111122223333:log-group::log-stream:"
},
{
"Sid": "IdentityStorePermissions",
"Effect": "Allow",
"Action": [
"sso:ListDirectoryAssociations",
"identitystore:GetUserId",
"sso-directory:SearchUsers",
"sso-directory:SearchGroups",
"identitystore:DescribeGroup",
"identitystore:DescribeUser"
],
"Resource": "*"
}
]
}
```
------
## Politique IAM pour les approbateurs de demandes d’accès
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAccessRequestDescriptions",
"Effect": "Allow",
"Action": [
"ssm:DescribeOpsItems",
"ssm:GetOpsSummary",
"ssm:ListOpsItemEvents"
],
"Resource": "*"
},
{
"Sid": "AllowGetSpecificAccessRequest",
"Effect": "Allow",
"Action": [
"ssm:GetOpsItem"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:opsitem/*"
},
{
"Sid": "AllowApprovalRejectionSignal",
"Effect": "Allow",
"Action": [
"ssm:SendAutomationSignal"
],
"Resource": "arn:aws:ssm:*:*:automation-execution/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/SystemsManagerJustInTimeNodeAccessManaged": "true"
}
}
},
{
"Sid": "QuickSetupConfigurationManagers",
"Effect": "Allow",
"Action": [
"ssm-quicksetup:ListConfigurationManagers",
"ssm-quicksetup:ListConfigurations",
"ssm-quicksetup:GetConfigurationManager",
"ssm-quicksetup:ListQuickSetupTypes",
"ssm-quicksetup:GetConfiguration"
],
"Resource": "*"
},
{
"Sid": "QuickSetupDeployments",
"Effect": "Allow",
"Action": [
"cloudformation:ListStacks",
"cloudformation:DescribeStacks",
"organizations:DescribeOrganization",
"organizations:ListDelegatedAdministrators"
],
"Resource": "*"
},
{
"Sid": "AllowSsmJitnaPoliciesCrudOperations",
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:DescribeDocument"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/*"
],
"Condition": {
"StringEquals": {
"ssm:DocumentType": [
"ManualApprovalPolicy",
"AutoApprovalPolicy"
]
}
}
},
{
"Sid": "AllowSsmJitnaPoliciesListOperations",
"Effect": "Allow",
"Action": [
"ssm:ListDocuments",
"ssm:ListDocumentVersions"
],
"Resource": "*"
},
{
"Sid": "IDCPermissions",
"Effect": "Allow",
"Action": [
"sso:DescribeRegisteredRegions",
"sso:ListDirectoryAssociations",
"identitystore:GetUserId",
"identitystore:DescribeUser",
"identitystore:DescribeGroup",
"identitystore:ListGroupMembershipsForMember"
],
"Resource": "*"
}
]
}
```
------
## Politique IAM pour les utilisateurs d'accès aux just-in-time nœuds
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowJITNAOperations",
"Effect": "Allow",
"Action": [
"ssm:StartAccessRequest",
"ssm:GetAccessToken"
],
"Resource": "*"
},
{
"Sid": "AllowOpsItemCreationAndRetrieval",
"Effect": "Allow",
"Action": [
"ssm:CreateOpsItem",
"ssm:GetOpsItem"
],
"Resource": "arn:aws:ssm:*:*:opsitem/*"
},
{
"Sid": "AllowListAccessRequests",
"Effect": "Allow",
"Action": [
"ssm:DescribeOpsItems",
"ssm:GetOpsSummary",
"ssm:ListOpsItemEvents",
"ssm:DescribeSessions"
],
"Resource": "*"
},
{
"Sid": "RequestManualApprovals",
"Action": "ssm:StartAutomationExecution",
"Effect": "Allow",
"Resource": "arn:aws:ssm:*:*:document/*",
"Condition": {
"StringEquals": {
"ssm:DocumentType": "ManualApprovalPolicy"
}
}
},
{
"Sid": "StartManualApprovalsAutomationExecution",
"Effect": "Allow",
"Action": "ssm:StartAutomationExecution",
"Resource": "arn:aws:ssm:*:*:automation-execution/*"
},
{
"Sid": "CancelAccessRequestManualApproval",
"Effect": "Allow",
"Action": "ssm:StopAutomationExecution",
"Resource": "arn:aws:ssm:*:*:automation-execution/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/SystemsManagerJustInTimeNodeAccessManaged": "true"
}
}
},
{
"Sid": "DescribeEC2Instances",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:GetPasswordData"
],
"Resource": "*"
},
{
"Sid": "AllowListSSMManagedNodesAndTags",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceInformation",
"ssm:ListTagsForResource"
],
"Resource": "*"
},
{
"Sid": "QuickSetupConfigurationManagers",
"Effect": "Allow",
"Action": [
"ssm-quicksetup:ListConfigurationManagers",
"ssm-quicksetup:GetConfigurationManager",
"ssm-quicksetup:ListConfigurations",
"ssm-quicksetup:ListQuickSetupTypes",
"ssm-quicksetup:GetConfiguration"
],
"Resource": "*"
},
{
"Sid": "AllowSessionManagerOperations",
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus"
],
"Resource": "*"
},
{
"Sid": "AllowRDPOperations",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:ListConnections",
"ssm:GetConnectionStatus"
],
"Resource": "*"
},
{
"Sid": "QuickSetupDeployments",
"Effect": "Allow",
"Action": [
"cloudformation:ListStacks",
"cloudformation:DescribeStacks",
"organizations:DescribeOrganization",
"organizations:ListDelegatedAdministrators"
],
"Resource": "*"
},
{
"Sid": "AllowSsmJitnaPoliciesReadOnly",
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:DescribeDocument"
],
"Resource": [
"arn:aws:ssm:*:111122223333:document/*"
],
"Condition": {
"StringEquals": {
"ssm:DocumentType": [
"ManualApprovalPolicy",
"AutoApprovalPolicy"
]
}
}
},
{
"Sid": "AllowSsmJitnaPoliciesListOperations",
"Effect": "Allow",
"Action": [
"ssm:ListDocuments",
"ssm:ListDocumentVersions"
],
"Resource": "*"
},
{
"Sid": "ExploreNodes",
"Effect": "Allow",
"Action": [
"ssm:ListNodesSummary",
"ssm:ListNodes",
"ssm:DescribeInstanceProperties"
],
"Resource": "*"
},
{
"Sid": "IdentityStorePermissions",
"Effect": "Allow",
"Action": [
"sso:DescribeRegisteredRegions",
"sso:ListDirectoryAssociations",
"identitystore:GetUserId",
"identitystore:DescribeUser",
"identitystore:DescribeGroup"
],
"Resource": "*"
}
]
}
```
------
**Note**
Pour restreindre l’accès aux opérations d’API qui créent, mettent à jour ou suppriment des politiques d’approbation, utilisez la clé de condition `ssm:DocumentType` pour les types de document `AutoApprovalPolicy` et `ManualApprovalPolicy `. Les opérations d’API `StartAccessRequest` et `GetAccessToken` ne prennent pas en charge les clés de contexte globales suivantes :
`aws:SourceVpc`
`aws:SourceVpce`
`aws:VpcSourceIp`
`aws:UserAgent`
`aws:MultiFactorAuthPresent`
Pour plus d’informations sur les clés de contexte de condition pour Systems Manager, consultez la section [Clés de condition pour AWS Systems Manager](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanager.html#awssystemsmanager-policy-keys) dans la *Référence de l’autorisation de service*.
La procédure suivante décrit comment effectuer la première étape de configuration pour l'accès aux just-in-time nœuds.
**Pour configurer l'accès aux just-in-time nœuds**
1. Connectez-vous au compte d’administrateur délégué de Systems Manager pour votre organisation.
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Sélectionnez **l'accès aux Just-in-time nœuds** dans le volet de navigation.
1. Sélectionnez **Activer la console unifiée**.
1. Choisissez les régions dans lesquelles vous souhaitez activer l'accès aux just-in-time nœuds. Par défaut, les mêmes régions que celles que vous avez choisies lors de la configuration de la console unifiée Systems Manager sont sélectionnées pour l'accès aux just-in-time nœuds. Le choix de nouvelles régions qui n’étaient pas sélectionnées lors de la configuration de la console unifiée Systems Manager n’est pas pris en charge.
1. Sélectionnez **Activer l'accès aux just-in-time nœuds**.
L'utilisation de l'accès aux just-in-time nœuds pendant 30 jours après l'activation de la fonctionnalité est gratuite. Après la période d'essai de 30 jours, l'utilisation de l'accès aux just-in-time nœuds est payante. Pour plus d’informations, consultez [Tarification d’AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
# 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 just-in-time nœuds é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.
Dans le just-in-time domaine de l'accès aux nœuds, il existe trois types de politiques. Ces types de politique sont l’*approbation automatique*, le *refus d’accès* et l’*approbation manuelle*.
**Just-in-time types de politiques d'accès aux nœuds**
+ Une politique d’approbation automatique définit les nœuds auxquels les utilisateurs peuvent se connecter automatiquement.
+ Les politiques d’approbation manuelle définissent le nombre et les niveaux d’approbations manuelles qui doivent être fournis pour accéder aux nœuds que vous spécifiez.
+ Une politique de refus d’accès empêche explicitement l’approbation automatique des demandes d’accès aux nœuds que vous spécifiez.
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 groupe `Intern` aux nœuds marqués par la clé `Production`. Les politiques d'approbation automatique et d'approbation manuelle s'appliquent uniquement au Régions AWS lieu Comptes AWS et à l'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 :
1. Refuser l’accès
1. Approbation automatique
1. Manuelle
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 au just-in-time nœud privilégie toujours la politique la plus spécifique à un nœud. Les stratégies d’approbation manuelle sont évaluées dans l’ordre suivant :
1. Balise cible spécifique
1. Tous les nœuds à cibler
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 [Configuration des notifications pour les demandes just-in-time d'accès](systems-manager-just-in-time-node-access-notifications.md).
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 just-in-time d'accès. 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 l'accès aux just-in-time nœuds.
**Topics**
+ [Créez des politiques d'approbation manuelle pour l'accès aux just-in-time nœuds](systems-manager-just-in-time-node-access-create-manual-policies.md)
+ [Structure de déclaration et opérateurs intégrés pour les politiques d’approbation automatique et de refus d’accès](auto-approval-deny-access-policy-statement-structure.md)
+ [Création d'une politique d'approbation automatique pour l' just-in-timeaccès aux nœuds](systems-manager-just-in-time-node-access-create-auto-approval-policies.md)
+ [Création d'une politique de refus d'accès pour just-in-time l'accès aux nœuds](systems-manager-just-in-time-node-access-create-deny-access-policies.md)
+ [Créez des politiques d'approbation pour l'accès aux just-in-time nœuds avec Amazon Q](systems-manager-just-in-time-node-access-create-approval-policies-q-ide-cli.md)
# Créez des politiques d'approbation manuelle pour l'accès aux just-in-time nœuds
La procédure suivante indique comment créer des politiques d’approbation manuelles. Systems Manager vous permet de créer jusqu'à 50 politiques d'approbation manuelle par Compte AWS utilisateur Région AWS.
**Créer une politique d’approbation manuelle**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Sélectionnez **Gérer l’accès aux nœuds** dans le volet de navigation.
1. Dans la section **Détails de la politique** de l’étape **Créer une politique d’approbation manuelle**, entrez le nom et la description de la politique d’approbation.
1. Entrez une valeur pour **Durée de l’accès**. Il s’agit de la durée maximale pendant laquelle un utilisateur peut démarrer des sessions sur un nœud après l’approbation d’une demande d’accès. La valeur doit être comprise entre 1 et 336 heures.
1. Dans la section **Nœuds cibles**, entrez les paires clé-valeur de balise associées aux nœuds auxquels vous souhaitez que la politique s’applique. Si aucune des balises spécifiées dans la politique n’est associée à un nœud, la stratégie n’est pas appliquée au nœud.
1. Dans la section **Approbateurs de demandes d’accès**, entrez les utilisateurs ou les groupes que vous souhaitez autoriser à approuver les demandes d’accès aux nœuds cibles de la politique. Les approbateurs de demandes d’accès peuvent être des utilisateurs et groupes IAM Identity Center ou des rôles IAM. Vous pouvez spécifier jusqu’à 5 approbateurs par niveau et jusqu’à 5 niveaux d’approbateurs.
1. Sélectionnez **Créer une politique d’approbation manuelle**.
# Structure de déclaration et opérateurs intégrés pour les politiques d’approbation automatique et de refus d’accès
Le tableau suivant montre la structure des politiques d’approbation automatique et de refus d’accès.
| Composant | Syntaxe |
| --- | --- |
| effet | `permit \| forbid` |
| scope | `(principal, action, resource)` |
| clause de condition | when {
principal or resource has attribute name
}; |
## Composants de politique
Une politique d’approbation automatique ou de refus d’accès contient les composants suivants :
+ **Effet** : `permit` (autoriser) ou `forbid` (refuser) l’accès.
+ **Portée** : les principaux, actions et ressources auxquels s’applique l’effet. Vous pouvez laisser le champ de portée indéfini dans Cedar en n’identifiant pas de principaux, d’actions ou de ressources spécifiques. Dans ce cas, la politique s’applique à tous les principaux, actions et ressources possibles. Pour l'accès aux just-in-time nœuds, `action` c'est toujours le cas`AWS::SSM::Action::"getTokenForInstanceAccess"`.
+ **Clause de condition** : le contexte dans lequel l’effet s’applique.
## Commentaires
Vous pouvez inclure des commentaires dans vos politiques. Les commentaires sont définis comme une ligne commençant par `//` et se terminant par un caractère de nouvelle ligne.
L’exemple suivant illustre les commentaires dans une politique.
```
// Allows users in the Engineering group from the Platform org to automatically connect to nodes tagged with Engineering and Production keys.
permit (
principal in AWS::IdentityStore::Group::"d4q81745-r081-7079-d789-14da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has organization && resource.hasTag("Engineering") && resource.hasTag("Production") && principal.organization == "Platform"
};
```
## Clauses multiples
Vous pouvez utiliser plusieurs clauses de condition dans une déclaration de politique à l’aide de l’opérateur `&&`.
```
// Allow access if node has tag where the tag key is Environment
// & tag value is Development
permit(principal, action == AWS::SSM::getTokenForInstanceAccess, resource)
when {
resource.hasTag("Environment") &&
resource.getTag("Environment") == "Development"
};
```
## Caractères réservés
L’exemple suivant montre comment écrire une politique si une propriété de contexte utilise un `:` (point-virgule), qui est un caractère réservé dans le langage de politique.
```
permit (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has employeeNumber && principal.employeeNumber like "E-1*" && resource.hasTag("Purpose") && resource.getTag("Purpose") == "Testing"
}
```
Pour accéder à des exemples supplémentaires, consultez [Exemples de déclarations de politique](#policy-statement-examples).
## Just-in-time schéma d'accès aux nœuds
Voici le schéma Cedar pour l'accès aux just-in-time nœuds.
```
namespace AWS::EC2 {
entity Instance tags String;
}
namespace AWS::IdentityStore {
entity Group;
entity User in [Group] {
employeeNumber?: String,
costCenter?: String,
organization?: String,
division?: String,
};
}
namespace AWS::IAM {
entity Role;
type AuthorizationContext = {
principalTags: PrincipalTags,
};
entity PrincipalTags tags String;
}
namespace AWS::SSM {
entity ManagedInstance tags String;
action "getTokenForInstanceAccess" appliesTo {
principal: [AWS::IdentityStore::User],
resource: [AWS::EC2::Instance, AWS::SSM::ManagedInstance],
context: {
"iam": AWS::IAM::AuthorizationContext
}
};
}
```
## Opérateurs intégrés
Lorsque vous créez le contexte d’une politique d’approbation automatique ou de refus d’accès utilisant différentes conditions, vous pouvez utiliser l’opérateur `&&` pour ajouter des conditions supplémentaires. Il existe également de nombreux autres opérateurs intégrés que vous pouvez utiliser pour ajouter un pouvoir d’expression supplémentaire à vos conditions de politique. Le tableau suivant contient tous les opérateurs intégrés à titre de référence.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/auto-approval-deny-access-policy-statement-structure.html)
## Exemples de déclarations de politique
Voici des exemples de déclaration de politique.
```
// Users assuming IAM roles with a principal tag of "Elevated" can automatically access nodes tagged with the "Environment" key when the value equals "prod"
permit(principal, action == AWS::SSM::getTokenForInstanceAccess, resource)
when {
// Verify IAM role principal tag
context.iam.principalTags.getTag("AccessLevel") == "Elevated" &&
// Verify the node has a tag with "Environment" tag key and a tag value of "prod"
resource.hasTag("Environment") &&
resource.getTag("Environment") == "prod"
};
```
```
// Identity Center users in the "Contractor" division can automatically access nodes tagged with the "Environment" key when the value equals "dev"
permit(principal, action == AWS::SSM::getTokenForInstanceAccess, resource)
when {
// Verify that the user is part of the "Contractor" division
principal.division == "Contractor" &&
// Verify the node has a tag with "Environment" tag key and a tag value of "dev"
resource.hasTag("Environment") &&
resource.getTag("Environment") == "dev"
};
```
```
// Identity Center users in a specified group can automatically access nodes tagged with the "Environment" key when the value equals "Production"
permit(principal in AWS::IdentityStore::Group::"d4q81745-r081-7079-d789-14da1EXAMPLE",
action == AWS::SSM::getTokenForInstanceAccess,
resource)
when {
resource.hasTag("Environment") &&
resource.getTag("Environment") == "Production"
};
```
# Création d'une politique d'approbation automatique pour l' just-in-timeaccès aux nœuds
Les politiques d’approbation automatique utilisent le langage de politique Cedar pour définir quels utilisateurs peuvent se connecter automatiquement aux nœuds spécifiés sans approbation manuelle. Une politique d’approbation automatique contient plusieurs déclarations `permit` spécifiant le `principal` et la `resource`. Chaque déclaration inclut une clause `when` définissant les conditions d’approbation automatique.
Voici un exemple de politique d’approbation automatique.
```
permit (
principal in AWS::IdentityStore::Group::"e8c17310-e011-7089-d989-10da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has costCenter && resource.hasTag("CostCenter") && principal.costCenter == resource.getTag("CostCenter")
};
permit (
principal in AWS::IdentityStore::Group::"d4q81745-r081-7079-d789-14da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has organization && resource.hasTag("Engineering") && resource.hasTag("Production") && principal.organization == "Platform"
};
permit (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has employeeNumber && principal.employeeNumber like "E-1*" && resource.hasTag("Purpose") && resource.getTag("Purpose") == "Testing"
};
```
La procédure suivante explique comment créer une politique d'approbation automatique pour l' just-in-timeaccès aux nœuds. 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 AWS et Région AWS. Pour plus d’informations sur l’élaboration de déclarations de politique, consultez [Structure de déclaration et opérateurs intégrés pour les politiques d’approbation automatique et de refus d’accès](auto-approval-deny-access-policy-statement-structure.md).
**Créer une politique d’approbation automatique**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Sélectionnez **Gérer l’accès aux nœuds** dans le volet de navigation.
1. Dans l’onglet **Politiques d’approbation**, sélectionnez **Créer une politique d’approbation automatique**.
1. Saisissez votre déclaration de politique pour la politique d’approbation automatique dans la section **Déclaration de politique**. Vous pouvez utiliser les **exemples de déclarations** fournis pour vous aider à créer votre politique.
1. Sélectionnez **Créer une politique d’approbation automatique**.
# Création d'une politique de refus d'accès pour just-in-time l'accès aux nœuds
Les politiques de refus d’accès utilisent le langage de politique Cedar pour définir les nœuds auxquels les utilisateurs ne peuvent pas se connecter automatiquement sans approbation manuelle. Une politique de refus d’accès contient plusieurs instructions `forbid` spécifiant le `principal` et la `resource`. Chaque déclaration inclut une clause `when` définissant les conditions du refus explicite de l’approbation automatique.
Voici un exemple de stratégie de refus d’accès :
```
forbid (
principal in AWS::IdentityStore::Group::"e8c17310-e011-7089-d989-10da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
resource.hasTag("Environment") && resource.getTag("Environment") == "Production"
};
forbid (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has division && principal.division != "Finance" && resource.hasTag("DataClassification") && resource.getTag("DataClassification") == "Financial"
};
forbid (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has employeeNumber && principal.employeeNumber like "TEMP-*" && resource.hasTag("Criticality") && resource.getTag("Criticality") == "High"
};
```
La procédure suivante décrit comment créer une politique de refus d'accès pour l'accès aux just-in-time nœuds. Pour plus d’informations sur l’élaboration d’une stratégie de cycle de vie, consultez [Structure de déclaration et opérateurs intégrés pour les politiques d’approbation automatique et de refus d’accès](auto-approval-deny-access-policy-statement-structure.md).
**Note**
Notez les informations suivantes.
Vous pouvez créer des politiques de refus d’accès lorsque vous êtes connecté au compte de gestion AWS ou au compte administrateur délégué. Votre organisation AWS Organizations ne peut avoir qu’une seule politique de refus d’accès.
Just-in-time node access uses AWS Resource Access Manager (AWS RAM) pour partager votre politique de refus d'accès avec les comptes membres de votre organisation. Si vous souhaitez partager votre politique de refus d’accès avec les comptes membres de votre organisation, le partage des ressources doit être activé depuis le compte de gestion de votre organisation. Pour de plus amples informations, veuillez consulter [Activer le partage de ressources dans AWS Organizations](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs) dans le *Guide de l’utilisateur AWS RAM *.
**Créer une politique de refus d’accès**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Sélectionnez **Gérer l’accès aux nœuds** dans le volet de navigation.
1. Dans l’onglet **Politiques d’approbation**, sélectionnez **Créer une politique de refus d’accès**.
1. Entrez votre déclaration de politique pour la politique de refus d’accès dans la section **Déclaration de politique**. Vous pouvez utiliser les **exemples de déclarations** fournis pour vous aider à créer votre politique.
1. Sélectionnez **Créer une politique de refus d’accès**.
# Créez des politiques d'approbation pour l'accès aux just-in-time nœuds avec Amazon Q
L’utilisation d’Amazon Q Developer pour la ligne de commande fournit des conseils et une assistance sur les différents aspects du développement logiciel. Pour l'accès aux just-in-time nœuds, Amazon Q vous aide à créer des politiques d'approbation en générant et en mettant à jour le code des politiques, en analysant les déclarations de politique, etc. Les informations suivantes décrivent comment créer des politiques d’approbation à l’aide d’Amazon Q pour la ligne de commande.
## Identifier votre cas d'utilisation
La première étape de la création de politiques d’approbation consiste à définir clairement votre cas d’utilisation. Par exemple, dans votre organisation, vous souhaiterez peut-être approuver automatiquement les demandes d’accès aux nœuds dotés d’une balise `Environment:Testing`. Vous pouvez également refuser explicitement les approbations automatiques aux nœuds dotés d’une balise `Environment:Production` si l’ID d’un employé commence par `TEMP`. Pour les nœuds dotés d’une balise `Tier:Database`, vous pouvez avoir besoin de deux niveaux d’approbations manuelles.
Dans un scénario donné, vous pourriez préférer une politique ou une condition à une autre. Nous vous recommandons donc de définir clairement les comportements de politique à adopter afin de déterminer les déclarations les mieux adaptées à votre cas d’utilisation et à vos préférences.
## Configurer votre environnement de développement.
Installez Amazon Q pour la ligne de commande où vous souhaitez développer vos politiques d’approbation. Pour plus d’informations sur l’installation d’Amazon Q pour ligne de commande, consultez la section [Installer Amazon Q pour la ligne de commande](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-installing.html) dans le *Guide de l’utilisateur Amazon Q Developer*.
Nous vous recommandons également d'installer le serveur MCP pour la AWS documentation. Ce serveur MCP connecte Amazon Q pour ligne de commande aux ressources de documentation les plus récentes. Pour plus d’informations sur l’utilisation de MCP avec Amazon Q pour ligne de commande, consultez la section [Utiliser MCP avec Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-mcp.html) dans le *Guide de l’utilisateur Amazon Q*.
Pour plus d'informations sur le serveur de AWS documentation MCP, consultez la section Serveur de [AWS documentation MCP.](https://awslabs.github.io/mcp/servers/aws-documentation-mcp-server/)
Installez et configurez le AWS CLI, si ce n'est pas déjà fait. Pour plus d'informations, voir [Installation ou mise à jour de la dernière version du AWS CLI.](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
## Élaborer le contenu de la politique d’approbation
Une fois votre cas d’utilisation identifié et votre environnement configuré, vous pouvez développer le contenu de vos politiques. Votre cas d’utilisation et vos préférences dicteront en grande partie les types de politiques d’approbation et de déclarations à utiliser.
Si vous ne savez pas comment utiliser une politique particulière ou si vous avez besoin de plus d’informations sur le schéma d’une stratégie, consultez [Créer des politiques d’approbation pour vos nœuds](systems-manager-just-in-time-node-access-approval-policies.md) et les rubriques suivantes. Ces rubriques expliquent en détail comment les politiques sont évaluées, et fournissent des exemples pratiques de déclarations.
La procédure suivante décrit comment créer des politiques d’approbation avec Amazon Q pour ligne de commande.
**Note**
Amazon Q Developer utilise l’IA générative. Vous devrez peut-être vérifier les réponses. Consultez la [politique AWS en matière d’IA responsable](https://aws.amazon.com/ai/responsible-ai/policy/).
**Pour créer une politique d’approbation à l’aide d’Amazon Q pour ligne de commande**
1. Ouvrez votre terminal et démarrez une session avec Amazon Q.
```
$ q chat
```
1. Saisissez une invite et décrivez le type de déclaration de politique que vous souhaitez créer. Par exemple, en utilisant le scénario précédent pour une politique d’approbation, vous pourriez saisir l’invite suivante :
```
Create a Cedar policy statement that allows a principal to use the “getTokenForInstanceAccess" action for a resource
that has a tag key “Environment” and tag value of “Testing”. Use the following example statement for reference to verify the syntax.
permit (
principal in AWS::IdentityStore::Group::"e8c17310-e011-7089-d989-10da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has organization && resource.hasTag("Engineering") && resource.hasTag("Production") && principal.organization == "Platform"
};
The Cedar policy statement you create must be valid. Validate the Cedar statement using the AWS documentation provided for just-in-time node access policy statement structure and make sure you abide by the schema.
```
1. La saisie de cet exemple d’invite produit le résultat suivant :
```
Based on the AWS documentation for Cedar policy statements and the examples provided, I'll create a valid Cedar policy
statement that allows a principal to use the "getTokenForInstanceAccess" action for resources with the tag key "Environment" and tag value "Testing".
Here's the Cedar policy statement:
permit (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
resource.hasTag("Environment") &&
resource.getTag("Environment") == "Testing"
};
This policy statement:
1. Uses the permit effect to allow access
2. Applies to any principal (since no specific principal is defined)
3. Specifically targets the "getTokenForInstanceAccess" action
4. Applies to resources that have a tag with key "Environment" and value "Testing"
5. Uses the proper syntax for the condition clause with the hasTag() and getTag() operators
The statement follows the Cedar policy language structure as documented in the AWS Systems Manager documentation for just-in-time node access policies.
```
1. Collez la déclaration de politique dans un nouveau fichier Cedar pour valider sa syntaxe. Vous pouvez également valider la déclaration en utilisant le [terrain de jeu Cedar](https://www.cedarpolicy.com/en/playground).
1. Après avoir validé la déclaration, enregistrez le fichier Cedar.
1. Depuis votre terminal, exécutez la AWS CLI commande suivante pour créer un document SSM en utilisant le contenu de votre politique. Avant d'utiliser des politiques d'approbation dans un environnement de production, testez vos politiques d'approbation avec un sous-ensemble d'identités et de nœuds dans un Compte AWS et Région AWS.
**Note**
Pour une politique d’approbation automatique, le nom du document doit être `SSM-JustInTimeAccessAutoApprovalPolicy`. Il ne peut y avoir qu'une seule politique d'approbation automatique par Compte AWS et Région AWS. Pour une politique de refus d’accès, le nom du document doit être `SSM-JustInTimeAccessDenyAccessOrgPolicy`. Il ne peut y avoir qu'une seule politique de refus d'accès par AWS Organizations organisation, et la politique doit être créée dans le compte d'administrateur délégué de Systems Manager. Les contraintes de dénomination pour les politiques d’approbation manuelle sont les mêmes que celles des autres documents SSM. Pour de plus amples informations, veuillez consulter [CreateDocument](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateDocument.html#systemsmanager-CreateDocument-request-Name).
------
#### [ Linux & macOS ]
```
aws ssm create-document \
--content file://path/to/file/policyContent.cedar \
--name "SSM-JustInTimeAccessAutoApprovalPolicy" \
--document-type "AutoApproval"
```
------
#### [ Windows ]
```
aws ssm create-document ^
--content file://C:\path\to\file\policyContent.cedar ^
--name "SSM-JustInTimeAccessAutoApprovalPolicy" ^
--document-type "AutoApproval"
```
------
#### [ PowerShell ]
```
$cedar = Get-Content -Path "C:\path\to\file\policyContent.cedar" | Out-String
New-SSMDocument `
-Content $cedar `
-Name "SSM-JustInTimeAccessAutoApprovalPolicy" `
-DocumentType "AutoApproval"
```
------
# Mettre à jour les préférences de session d'accès aux just-in-time nœuds
Avec l'accès aux just-in-time nœuds, vous pouvez définir les préférences générales de session et de journalisation dans chaque nœud Compte AWS et Région AWS dans votre organisation. Vous pouvez également CloudFormation StackSets créer un document de préférences de session dans plusieurs comptes et régions pour vous aider à avoir des préférences de session cohérentes. Pour plus d’informations sur le schéma des documents de préférences de session, consultez [Schéma de document de session](session-manager-schema.md).
À des fins de journalisation, nous vous recommandons d'utiliser l'option de streaming avec Amazon CloudWatch Logs. Cette fonctionnalité vous permet d'envoyer un flux continu de journaux de données de session à CloudWatch Logs. Les détails essentiels, tels que les commandes qu'un utilisateur a exécutées dans une session, l'ID de l'utilisateur qui a exécuté les commandes et les horodatages indiquant le moment où les données de session sont diffusées vers CloudWatch Logs, sont inclus lors de la diffusion en continu des données de session. Lors du streaming de données de session, les journaux sont au format JSON afin de faciliter l'intégration à vos solutions de journalisation existantes.
Systems Manager ne met pas automatiquement fin aux sessions d'accès aux just-in-time nœuds. Il est recommandé de spécifier des valeurs pour la *durée maximale de session* et les paramètres de *délai d’inactivité des sessions*. L’utilisation de ces paramètres vous permet d’empêcher un utilisateur de rester connecté à un nœud plus longtemps que le délai approuvé dans une demande d’accès. La procédure suivante décrit comment mettre à jour les préférences de session pour l'accès aux just-in-time nœuds.
**Important**
Vous devez étiqueter les AWS KMS clés utilisées pour le Session Manager chiffrement et l'enregistrement RDP lors de l'accès aux just-in-time nœuds avec la clé de balise `SystemsManagerJustInTimeNodeAccessManaged` et la valeur de la `true` balise.
Pour plus d’informations sur le balisage des clés KMS, veuillez consulter la rubrique [Tags dans AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/tagging-keys.html) dans le *Guide du développeur AWS Key Management Service *.
**Mettre à jour les préférences de session**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Sélectionnez **Paramètres** dans le volet de navigation.
1. Sélectionnez l'onglet **Accès au Just-in-time nœud**.
1. Dans la section **Préférences de session**, sélectionnez **Modifier**.
1. Mettez à jour vos préférences générales et de journalisation selon vos besoins, puis sélectionnez **Enregistrer**.
# Configuration des notifications pour les demandes just-in-time d'accès
Vous pouvez configurer Systems Manager pour envoyer des notifications lorsqu'un utilisateur crée une demande d'accès aux just-in-time nœuds aux adresses e-mail, ou au client de chat, pour les approbateurs et le demandeur. La notification contient le motif de la demande d'accès fournie par le demandeur Compte AWS Région AWS, le statut de la demande et l'ID du nœud cible. Actuellement, Systems Manager prend en charge les clients Slack et Microsoft Teams grâce à l’intégration avec Amazon Q Developer dans les applications de chat. Lorsque vous utilisez des notifications via des clients de chat, les approbateurs de demandes d’accès peuvent interagir directement avec les demandes d’accès. Il n’est donc plus nécessaire de se connecter à la console pour répondre aux demandes d’accès.
**Avant de commencer**
Avant de configurer un client de chat pour les notifications d'accès aux just-in-time nœuds, tenez compte des exigences suivantes :
+ Si vous utilisez des rôles IAM pour gérer les identités des utilisateurs dans votre compte, vous devez associer manuellement les adresses e-mail des approbateurs ou demandeurs auxquels vous souhaitez envoyer des notifications au rôle associé. Dans le cas contraire, les destinataires prévus ne pourront pas être informés par e-mail.
Les procédures suivantes décrivent comment configurer les notifications pour les demandes d'accès aux just-in-time nœuds.
**Pour configurer un client de chat pour les notifications d'accès aux just-in-time nœuds**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Sélectionnez **Paramètres** dans le volet de navigation.
1. Sélectionnez l'onglet **Accès au Just-in-time nœud**.
1. Dans la section **Chat**, sélectionnez **Configurer un nouveau client**.
1. Dans le menu déroulant **Sélectionner le type de client**, choisissez le type de client de chat que vous souhaitez configurer, puis sélectionnez **Suivant**.
1. Vous êtes invité à autoriser Amazon Q Developer dans les applications de chat à accéder à votre client de chat. Sélectionnez **Autoriser**.
1. Dans la section **Configurer le canal**, saisissez les informations de votre canal client de chat et sélectionnez les types de notifications que vous souhaitez recevoir.
1. Si vous configurez les notifications Slack, invitez « @Amazon Q » à accéder à chaque canal Slack dans lequel les notifications sont configurées.
1. Sélectionnez **Configurer le canal**.
**Note**
Pour autoriser les demandes d' approving/rejecting accès directement depuis un canal Slack, assurez-vous que le rôle IAM configuré avec le canal Slack dispose d'`ssm:SendAutomationSignal`autorisations et d'une politique de confiance incluant le chatbot :
```
{
"Effect": "Allow",
"Principal": {
"Service": "chatbot.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
```
**Pour configurer les notifications par e-mail pour les notifications d'accès aux just-in-time nœuds**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Sélectionnez **Paramètres** dans le volet de navigation.
1. Sélectionnez l'onglet **Accès au Just-in-time nœud**.
1. Dans la section **E-mail**, sélectionnez **Modifier**.
1. Sélectionnez **Ajouter des e-mails**, puis choisissez le **rôle IAM** auquel vous souhaitez associer manuellement les adresses e-mail.
1. Dans le champ **Adresse e-mail**, saisissez une adresse e-mail. Chaque fois qu’une demande d’accès créée nécessite l’approbation du rôle IAM que vous avez spécifié, les adresses e-mail que vous associez au rôle sont notifiées.
1. Sélectionnez **Ajouter une adresse e-mail**.
# Enregistrement des connexions RDP
Just-in-time l'accès aux nœuds inclut la possibilité d'enregistrer les connexions RDP établies avec vos Windows Server nœuds. L’enregistrement des connexions RDP nécessite un compartiment S3 et une clé gérée par le client AWS Key Management Service (AWS KMS). Le AWS KMS key est utilisé pour chiffrer temporairement les données d'enregistrement pendant qu'elles sont générées et stockées sur les ressources de Systems Manager. La clé gérée par le client doit être une clé symétrique utilisant les fonctions de clé de chiffrement et de déchiffrement. Vous pouvez soit utiliser une clé multirégionale pour votre organisation, soit créer une clé gérée par le client dans chaque région où vous avez activé l'accès aux just-in-time nœuds.
Si vous avez activé le chiffrement KMS sur le compartiment S3 dans lequel vous stockez les enregistrements, vous devez fournir au principal de service `ssm-guiconnect` l’accès à la clé gérée par le client utilisée pour le chiffrement du compartiment. Cette clé gérée par le client peut être différente de celle que vous spécifiez dans les paramètres d’enregistrement, qui doivent inclure les éléments pour lesquels l’autorisation `kms:CreateGrant` est requise pour établir des connexions.
## Configuration du chiffrement de compartiment S3 pour les enregistrements RDP
Vos enregistrements de connexion sont stockés dans le compartiment S3 que vous spécifiez lorsque vous activez l’enregistrement RDP.
Si vous utilisez une clé KMS comme mécanisme de chiffrement par défaut pour le compartiment S3 (SSE-KMS), vous devez autoriser le principal de service `ssm-guiconnect` à accéder à l’action `kms:GenerateDataKey` sur la clé. Nous recommandons d’utiliser une clé gérée par le client lors de l’utilisation du chiffrement SSE-KMS avec un compartiment S3. En effet, vous pouvez mettre à jour la stratégie de clé associée à une clé gérée par le client. Vous ne pouvez pas mettre à jour les principales politiques pour Clés gérées par AWS.
**Important**
Vous devez étiqueter les AWS KMS clés utilisées pour le Session Manager chiffrement et l'enregistrement RDP lors de l'accès aux just-in-time nœuds avec la clé de balise `SystemsManagerJustInTimeNodeAccessManaged` et la valeur de la `true` balise.
Pour plus d’informations sur le balisage des clés KMS, veuillez consulter la rubrique [Tags dans AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/tagging-keys.html) dans le *Guide du développeur AWS Key Management Service *.
Utilisez la stratégie de clé gérée par le client suivante pour autoriser le service `ssm-guiconnect` à accéder à la clé KMS pour le stockage S3. Pour plus d’informations sur la mise à jour d’une clé gérée par le client, consultez [Modifier une politique de clés](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html) dans le *Guide du développeur AWS Key Management Service *.
Remplacez chacune *example resource placeholder* par vos propres informations :
+ *account-id*représente l'ID de celui Compte AWS qui initie la connexion.
+ *region*représente l' Région AWS emplacement du compartiment S3. (Vous pouvez utiliser `*` si le compartiment doit recevoir des enregistrements provenant de plusieurs régions. Exemple :`s3.*.amazonaws.com`.)
**Note**
Vous pouvez utiliser `aws:SourceOrgID` dans la stratégie plutôt que `aws:SourceAccount` si le compte appartient à une organisation dans AWS Organizations.
```
{
"Sid": "Allow the GUI Connect service principal to access S3",
"Effect": "Allow",
"Principal": {
"Service": "ssm-guiconnect.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "account-id"
},
"StringLike": {
"kms:ViaService": "s3.region.amazonaws.com"
}
}
}
```
## Configuration des autorisations IAM pour l’enregistrement des connexions RDP
Outre les autorisations IAM requises pour l'accès aux just-in-time nœuds, l'utilisateur ou le rôle que vous utilisez doit disposer des autorisations suivantes en fonction de la tâche que vous devez effectuer.
**Autorisations pour configurer l’enregistrement des connexions**
Pour configurer l’enregistrement de connexion RDP, les autorisations suivantes sont requises :
+ `ssm-guiconnect:UpdateConnectionRecordingPreferences`
+ `ssm-guiconnect:GetConnectionRecordingPreferences`
+ `ssm-guiconnect:DeleteConnectionRecordingPreferences`
+ `kms:CreateGrant`
**Autorisations pour l’établissement de connexions**
Pour établir des connexions RDP avec accès aux just-in-time nœuds, les autorisations suivantes sont requises :
+ `ssm-guiconnect:CancelConnection`
+ `ssm-guiconnect:GetConnection`
+ `ssm-guiconnect:StartConnection`
+ `kms:CreateGrant`
**Avant de commencer**
Pour stocker vos enregistrements de connexion, vous devez d’abord créer un compartiment S3 et ajouter la stratégie de compartiment suivante. Remplacez chaque *example resource placeholder* par vos propres informations.
(Pour plus d’informations sur l’ajout d’une stratégie de compartiment, consultez [Ajout d’une stratégie de compartiment à l’aide de la console Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html) dans le *Guide de l’utilisateur Amazon S3*.)
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ConnectionRecording",
"Effect": "Allow",
"Principal": {
"Service": [
"ssm-guiconnect.amazonaws.com"
]
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition":{
"StringEquals":{
"aws:SourceAccount":"111122223333"
}
}
}
]
}
```
------
## Activer et configurer l’enregistrement des connexions RDP
La procédure suivante décrit comment activer et configurer l’enregistrement de connexion RDP.
**Activer et configurer l’enregistrement des connexions RDP**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Sélectionnez **Paramètres** dans le volet de navigation.
1. Sélectionnez l'onglet **Accès au Just-in-time nœud**.
1. Dans la section **Enregistrement RDP**, sélectionnez **Activer l’enregistrement RDP**.
1. Choisissez le compartiment S3 dans lequel vous souhaitez charger les enregistrements de session.
1. Choisissez la clé gérée par le client que vous souhaitez utiliser pour chiffrer temporairement les données d’enregistrement pendant qu’elles sont générées et stockées sur les ressources de Systems Manager. (Il peut s’agir d’une clé gérée par le client différente de celle que vous utilisez pour chiffrer le compartiment.)
1. Cliquez sur **Enregistrer**.
## Valeurs de statut d’enregistrement de connexion RDP
Les valeurs de statut valides pour les enregistrements de connexion RDP sont les suivantes :
+ `Recording` : la connexion est en cours d’enregistrement
+ `Processing` : la vidéo est en cours de traitement une fois la connexion interrompue.
+ `Finished` : état du terminal réussi, la vidéo d’enregistrement de connexion a été traitée avec succès et chargée dans le compartiment spécifié.
+ `Failed` : échec de l’état du terminal. La connexion n’a pas été enregistrée correctement.
+ `ProcessingError`- Un ou plusieurs intermédiaires failures/errors se sont produits pendant le traitement vidéo. Les causes potentielles incluent des défaillances de dépendance au service ou des autorisations manquantes en raison d’une mauvaise configuration du compartiment S3 spécifié pour le stockage des enregistrements. Le service continue de tenter le traitement lorsque l’enregistrement est dans cet état.
**Note**
`ProcessingError` peut survenir si le principal de service `ssm-guiconnect` n’est pas autorisé à charger des objets dans le compartiment S3 une fois la connexion établie. Une autre cause potentielle est l’absence d’autorisations KMS sur la clé KMS utilisée pour le chiffrement du compartiment S3.
# Modification des cibles
Lorsque vous configurez l'accès aux just-in-time nœuds, vous choisissez les *cibles* sur lesquelles vous souhaitez configurer l'accès aux just-in-time nœuds. Les cibles comprennent les unités AWS Organizations organisationnelles (OUs) et Régions AWS. Par défaut, les mêmes cibles que celles que vous avez choisies lors de la configuration de la console unifiée Systems Manager sont sélectionnées pour l'accès aux just-in-time nœuds. Vous pouvez choisir de configurer l'accès aux just-in-time nœuds pour toutes les mêmes cibles ou pour un sous-ensemble des cibles que vous avez spécifiées lors de la configuration de la console unifiée Systems Manager. L'ajout de nouvelles cibles qui n'ont pas été sélectionnées lors de la configuration de la console unifiée Systems Manager n'est pas pris en charge. Vous pouvez modifier les cibles que vous avez sélectionnées après avoir configuré l'accès aux just-in-time nœuds.
La procédure suivante décrit comment modifier les cibles pour l'accès aux just-in-time nœuds.
**Modifier les cibles**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Sélectionnez **Paramètres** dans le volet de navigation.
1. Sélectionnez l'onglet **Accès au Just-in-time nœud**.
1. Dans la section **Cibles**, sélectionnez **Modifier**.
1. Sélectionnez les **unités organisationnelles** et **les régions dans** lesquelles vous souhaitez utiliser l'accès aux just-in-time nœuds.
1. Cliquez sur **Enregistrer**.
# Changer de fournisseurs d’identité
Par défaut, l'accès aux just-in-time nœuds utilise IAM comme fournisseur d'identité. Après avoir activé l'accès aux just-in-time nœuds, les clients utilisant la console unifiée avec une organisation peuvent modifier ce paramètre pour utiliser IAM Identity Center. Just-in-timel'accès aux nœuds ne prend pas en charge IAM Identity Center en tant que fournisseur d'identité lorsqu'il est configuré pour un seul compte et une seule région.
La procédure suivante décrit comment modifier le fournisseur d'identité pour l'accès aux just-in-time nœuds.
**Modifier les fournisseurs d’identité**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Sélectionnez **Paramètres** dans le volet de navigation.
1. Sélectionnez l'onglet **Accès au Just-in-time nœud**.
1. Dans la section **Identité utilisateur**, sélectionnez **Modifier**.
1. Choisissez **AWS IAM Identity Center**.
1. Sélectionnez **Save**.
# Démarrer une session d'accès aux just-in-time nœuds
Après avoir activé et configuré l'accès aux just-in-time nœuds, et configuré les préférences de session et de notification, les utilisateurs sont prêts à démarrer des sessions d'accès aux just-in-time nœuds. Vous pouvez démarrer des sessions en utilisant l'accès aux just-in-time nœuds depuis la console Systems Manager ou depuis le AWS Command Line Interface Session Manager plugin. Just-in-timeles sessions d'accès aux nœuds peuvent être démarrées sur les nœuds du même compte et de la même région. Les procédures suivantes décrivent comment démarrer des sessions avec un accès aux just-in-time nœuds.
**Note**
Si vos utilisateurs se connectaient auparavant Session Manager à des nœuds, vous devez supprimer les Session Manager autorisations, par exemple`ssm:StartSession`, de leurs politiques IAM pour démarrer des sessions en utilisant l'accès aux just-in-time nœuds. Sinon, lors de la connexion aux nœuds, ils continueront à utiliser Session Manager.
**Pour démarrer une session avec accès aux just-in-time nœuds à l'aide de la console**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Explorer les nœuds**.
1. Sélectionnez le nœud auquel vous souhaitez vous connecter.
1. Dans le menu déroulant **Actions**, sélectionnez **Connexion**.
Si les politiques d’approbation de votre organisation ne vous permettent pas de vous connecter automatiquement au nœud, vous êtes invité à soumettre une demande d’accès. Une fois que vous aurez rempli les informations demandées et soumis la demande d’accès, vous pourrez démarrer des sessions sur le nœud une fois que toutes les approbations requises auront été reçues.
**Pour démarrer une session avec accès aux just-in-time nœuds à l'aide du AWS CLI**
1. Exécutez la commande suivante pour démarrer le flux de travail des demandes d'accès, en veillant à les *placeholder values* remplacer par vos propres informations.
```
aws ssm start-access-request \
--targets Key=InstanceIds,Values=i-02573cafcfEXAMPLE
--reason "Troubleshooting networking performance issue"
```
Selon les politiques d’approbation de votre organisation, vous serez automatiquement connecté au nœud, ou le processus d’approbation manuelle sera lancé. Pour les demandes qui nécessitent des approbations manuelles, notez l’ID de la demande d’accès renvoyé dans la réponse.
1. Attendez que toutes les approbations requises soient fournies.
1. Une fois que toutes les approbations requises ont été fournies, exécutez la commande suivante pour obtenir un jeton d’accès contenant des informations d’identification temporaires. Remplacez les *placeholder values* par vos propres informations.
```
aws ssm get-access-token \
--access-request-id oi-12345abcdef
```
Notez le jeton d’accès de la réponse.
1. Exécutez la commande suivante pour utiliser les informations d'identification temporaires contenues dans le AWS CLI, en veillant à les *placeholder values* remplacer par vos propres informations.
```
export AWS_SESSION_TOKEN=AQoDYXdzEJr...
```
1. Exécutez la commande suivante pour démarrer une session sur le nœud, en veillant à les *placeholder values* remplacer par vos propres informations.
```
aws ssm start-session \
--target i-02573cafcfEXAMPLE
```
# Gestion des demandes just-in-time d'accès
Pour une visibilité accrue au sein de votre organisation, Systems Manager réplique les demandes d’accès vers le compte d’administrateur délégué de votre organisation. Pour vous aider à répondre aux exigences de conformité, Systems Manager conserve toutes les demandes d’accès pendant un an. Les rubriques suivantes décrivent comment gérer les demandes d'accès aux just-in-time nœuds. Ces informations sont destinées aux approbateurs de demandes d’accès. Avant de commencer, nous vous recommandons de revoir vos politiques IAM et de vous assurer que vous disposez des autorisations requises pour administrer l'accès aux just-in-time nœuds. Pour plus d'informations, voir,[Configuration de just-in-time l'accès avec Systems Manager](systems-manager-just-in-time-node-access-setting-up.md).
**Topics**
+ [Approuver et refuser les demandes d'accès aux just-in-time nœuds](systems-manager-just-in-time-node-access-approve-deny-requests.md)
# Approuver et refuser les demandes d'accès aux just-in-time nœuds
Les approbateurs de demandes d'accès peuvent approuver ou refuser les demandes d'accès aux just-in-time nœuds depuis la console unifiée Systems Manager ou à l'aide de votre outil de ligne de commande préféré. Ces informations sont destinées aux approbateurs de demandes d’accès. Si vous ne disposez pas des autorisations requises pour approuver ou rejeter les demandes d’accès, contactez votre administrateur. Les procédures suivantes décrivent comment approuver ou refuser les demandes d'accès aux just-in-time nœuds.
**Pour approuver ou refuser les demandes d'accès aux just-in-time nœuds à l'aide de la console**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Sélectionnez **Gérer l’accès aux nœuds** dans le volet de navigation.
1. Sélectionnez l’onglet **Demandes d’accès**.
1. Sélectionnez l’option **Demandes pour moi**.
1. Cochez la demande d’accès que vous souhaitez approuver ou rejeter.
1. Sélectionnez **Approuver** ou **Rejeter**.
Après avoir approuvé une demande d’accès, vous pouvez révoquer votre approbation à tout moment en sélectionnant **Révoquer**.
**Pour approuver ou refuser les demandes d'accès aux just-in-time nœuds à l'aide de la ligne de commande**
1. Notez l’ID de demande d’accès à partir de la notification. Par exemple, *oi-12345abcdef*.
1. Exécutez la commande suivante pour renvoyer des informations sur le flux de travail d'approbation des demandes d'accès, en veillant à les *placeholder values* remplacer par vos propres informations.
```
aws ssm get-ops-item \
--ops-item-id oi-12345abcdef
```
Notez la valeur `automationExecutionId` dans le champ `/aws/accessrequest` pour `OperationalData`. Par exemple, *9231944f-61c6-40be-8bce-8ee2bEXAMPLE*.
1. Exécutez la commande suivante pour approuver ou rejeter la demande d’accès. Utilisez le type de signal `Approve` pour approuver la demande et `Deny` pour la refuser. Veillez à remplacer les *placeholder values* par vos propres informations.
```
aws ssm send-automation-signal \
--automation-execution-id 9231944f-61c6-40be-8bce-8ee2bEXAMPLE \
--signal-type "Approve"
```
# Passage à l'accès aux just-in-time nœuds depuis Session Manager
Lorsque vous activez l'accès aux just-in-time nœuds, Systems Manager n'apporte aucune modification à vos ressources existantes pourSession Manager. Cela garantit que votre environnement existant n’est pas perturbé et que les utilisateurs peuvent continuer à démarrer des sessions pendant que vous créez et validez des politiques d’approbation. Une fois que vous êtes prêt à tester vos politiques d'approbation, vous devez modifier vos politiques IAM existantes pour terminer la transition vers l'accès aux just-in-time nœuds. Cela inclut l'ajout des autorisations requises pour l'accès des just-in-time nœuds aux identités et la suppression des autorisations pour le fonctionnement de l'`StartSession`API pourSession Manager. Nous vous recommandons de tester les politiques d'approbation avec un sous-ensemble d'identités et de nœuds dans un Compte AWS et Région AWS.
Pour plus d'informations sur les autorisations requises pour accéder aux just-in-time nœuds, consultez[Configuration de just-in-time l'accès avec Systems Manager](systems-manager-just-in-time-node-access-setting-up.md).
Pour plus d’informations sur la modification des autorisations IAM d’une identité, consultez la rubrique [Ajout et suppression d’autorisations basées sur l’identité IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) dans le *Guide de l’utilisateur IAM*.
La section suivante décrit une méthode détaillée permettant de passer à l'accès aux just-in-time nœuds à partir deSession Manager.
Le passage du gestionnaire de session à l'accès aux just-in-time nœuds nécessite une planification et des tests minutieux afin de garantir une transition fluide sans perturber vos opérations. Les sections suivantes décrivent la façon dont vous pouvez procéder.
## Conditions préalables
Avant de commencer, assurez-vous que vous avez terminé les tâches suivantes :
+ Configurez la console unifiée Systems Manager.
+ Vérifié que vous avez l’autorisation de modifier les politiques IAM de votre compte.
+ Identifié toutes les politiques et tous les rôles IAM qui accordent actuellement des autorisations Session Manager.
+ Documenté votre configuration Session Manager actuelle, y compris les préférences de session et les paramètres de journalisation.
## Évaluation
Évaluez votre environnement actuel et définissez les comportements d’approbation souhaités en effectuant les tâches suivantes :
1. **Faites l’inventaire de vos nœuds** : identifiez tous les nœuds auxquels les utilisateurs accèdent actuellement via Session Manager.
1. **Identifiez les modèles d’accès des utilisateurs** : documentez quels utilisateurs ou rôles ont besoin d’accéder à quels nœuds et dans quelles circonstances.
1. **Mappez les flux de travail d’approbation** : déterminez qui doit approuver les demandes d’accès pour les différents types de nœuds.
1. **Passez en revue la stratégie de balisage** : assurez-vous que vos nœuds sont correctement balisés pour prendre en charge vos politiques d’approbation planifiées.
1. **Auditez les politiques IAM existantes** : identifiez toutes les politiques qui incluent des autorisations Session Manager.
## Planification
### Stratégie en phases
Lorsque vous passez de Session Manager l'accès aux just-in-time nœuds, nous vous recommandons d'utiliser une approche progressive telle que la suivante :
1. **Phase 1 : Installation et configuration** - Activez l'accès aux just-in-time nœuds sans modifier les Session Manager autorisations existantes.
1. **Phase 2 : élaboration de politiques** - Créez et testez des politiques d’approbation pour vos nœuds.
1. **Phase 3 : migration pilote** - Modifiez un petit groupe de nœuds et d'utilisateurs ou de rôles non critiques pour passer de l'accès Session Manager aux just-in-time nœuds.
1. **Phase 4 : migration complète** - Migrez progressivement tous les nœuds et utilisateurs ou rôles restants.
### Considérations chronologiques
Tenez compte des facteurs suivants lors de la création de votre chronologie pour passer de l'accès aux just-in-time nœuds Session Manager à l'accès aux nœuds :
+ Prévoyez du temps pour la formation des utilisateurs et l’adaptation au nouveau flux de travail d’approbation.
+ Planifiez les migrations pendant les périodes de faible activité opérationnelle.
+ Prévoyez du temps pour les éventuelles opérations de dépannage et d’ajustement.
+ Prévoyez une période d’exploitation parallèle pendant laquelle les deux systèmes seront disponibles.
## Étapes d’implémentation
### Phase 1 : installation et configuration
1. Activez l'accès aux just-in-time nœuds dans la console Systems Manager. Pour obtenir des instructions complètes, consultez [Configuration de just-in-time l'accès avec Systems Manager](systems-manager-just-in-time-node-access-setting-up.md).
1. Configurez les préférences de session pour l'accès aux just-in-time nœuds en fonction de vos Session Manager paramètres actuels. Pour de plus amples informations, veuillez consulter [Mettre à jour les préférences de session d'accès aux just-in-time nœuds](systems-manager-just-in-time-node-access-session-preferences.md).
1. Configurez les préférences de notification relatives aux demandes d’accès. Pour de plus amples informations, veuillez consulter [Configuration des notifications pour les demandes just-in-time d'accès](systems-manager-just-in-time-node-access-notifications.md).
1. Si vous utilisez des connexions RDP aux nœuds Windows Server, configurez l’enregistrement RDP. Pour de plus amples informations, veuillez consulter [Enregistrement des connexions RDP](systems-manager-just-in-time-node-access-rdp-recording.md).
### Phase 2 : élaboration de politiques
1. Créez des politiques IAM pour les administrateurs et les utilisateurs d'accès aux just-in-time nœuds.
1. Développez des politiques d’approbation en fonction de vos exigences de sécurité et de votre cas d’utilisation.
1. Testez vos politiques dans un environnement hors production afin de vous assurer qu’elles fonctionnent comme prévu.
### Phase 3 : migration pilote
1. Sélectionnez un petit groupe d’utilisateurs et de nœuds non critiques pour le projet pilote.
1. Créez de nouvelles politiques IAM pour les utilisateurs pilotes qui incluent des autorisations d'accès aux just-in-time nœuds.
1. Supprimez les autorisations Session Manager (`ssm:StartSession`) des politiques IAM des utilisateurs pilotes.
1. Formez les utilisateurs pilotes au nouveau flux de travail de demande d’accès.
1. Surveillez le pilote pour détecter les problèmes, et recueillez les commentaires.
1. Ajustez les politiques et procédures en fonction des résultats du projet pilote.
**Exemple de modification de politique IAM pour les utilisateurs pilotes**
Politique initiale avec autorisations Session Manager :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:ResumeSession",
"ssm:TerminateSession"
],
"Resource": "*"
}
]
}
```
------
Politique modifiée pour l'accès aux just-in-time nœuds :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartAccessRequest",
"ssm:GetAccessToken",
"ssm:ResumeSession",
"ssm:TerminateSession"
],
"Resource": "*"
}
]
}
```
------
### Phase 4 : migration complète
Élaborez un calendrier pour la migration par lots des utilisateurs et nœuds restants.
## Méthodologie de test
Tout au long du processus de migration, effectuez les tests suivants :
+ **Validation des politiques** : vérifiez que les politiques d’approbation s’appliquent correctement aux nœuds et utilisateurs prévus.
+ **Flux de travail des demandes d’accès** : testez l’ensemble du flux de travail, de la demande d’accès à l’établissement de la session, à la fois pour les scénarios d’approbation automatique et d’approbation manuelle.
+ **Notifications** : vérifiez que les approbateurs reçoivent les notifications via les canaux configurés (e-mail, Slack, Microsoft Teams).
+ **Journalisation et surveillance** : vérifiez que les journaux de session et les demandes d’accès sont correctement capturés et stockés.
## Bonnes pratiques pour une migration réussie
+ **Communiquez tôt et souvent** : informez les utilisateurs du calendrier de migration et des avantages de l'accès aux just-in-time nœuds.
+ **Commencez par les systèmes non critiques** : commencez la migration par les environnements de développement ou de test avant de passer à la production.
+ **Documentez tout** : conservez des enregistrements détaillés de vos politiques d’approbation, des modifications des politiques IAM et des paramètres de configuration.
+ **Surveillez et ajustez** : surveillez en permanence les demandes d’accès et les flux de travail d’approbation, en ajustant les politiques selon les besoins.
+ **Établissez une gouvernance** : créez un processus permettant de revoir et de mettre à jour régulièrement les politiques d’approbation en fonction de l’évolution de votre environnement.
# Désactivation de just-in-time l'accès avec Systems Manager
La procédure suivante décrit comment désactiver l'accès aux just-in-time nœuds. Après avoir désactivé l'accès aux just-in-time nœuds, les utilisateurs de votre organisation peuvent ne pas être en mesure de se connecter à vos nœuds, sauf si vous avez déjà implémenté d'autres méthodes de connexion.
**Pour désactiver l'accès aux just-in-time nœuds**
1. Connectez-vous au compte d’administrateur délégué de Systems Manager pour votre organisation.
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Sélectionnez **Paramètres** dans le volet de navigation.
1. Dans l'onglet **Accès au Just-in-time nœud**, sélectionnez **Désactiver**.
# Just-in-time questions fréquemment posées sur l'accès aux nœuds
## Comment passer de l'accès Session Manager aux just-in-time nœuds ?
Après avoir configuré la console unifiée et activé l'accès aux just-in-time nœuds, vous devez modifier vos politiques IAM existantes pour terminer le passage à l'accès aux just-in-time nœuds. Cela inclut l'ajout des autorisations requises pour l'accès aux just-in-time nœuds et la suppression des autorisations pour le fonctionnement de l'`StartSession`API pourSession Manager. Pour plus d'informations sur les politiques IAM relatives à l'accès aux just-in-time nœuds, consultez[Configuration de just-in-time l'accès avec Systems Manager](systems-manager-just-in-time-node-access-setting-up.md).
## Dois-je configurer la console unifiée pour utiliser l'accès aux just-in-time nœuds ?
Oui, la configuration de la console unifiée est une condition préalable à l'accès aux just-in-time nœuds. Cependant, une fois que vous avez configuré la console unifiée et activé l'accès aux just-in-time nœuds, il existe plusieurs méthodes pour vous connecter à vos nœuds. Par exemple, vous pouvez démarrer des sessions d'accès aux just-in-time nœuds depuis la console Amazon EC2 et le. AWS CLI Pour plus d’informations sur la configuration de la console unifiée, consultez [Configuration de la console unifiée Systems Manager pour une organisation](systems-manager-setting-up-organizations.md).
## Y a-t-il un coût associé à l'accès aux just-in-time nœuds ?
Systems Manager propose un essai gratuit de 30 jours pour accéder aux just-in-time nœuds. Après la période d'essai, l'accès aux just-in-time nœuds entraîne des coûts. Pour plus d’informations, consultez [Tarification d’AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
## Quelle est la priorité des politiques d'approbation d'accès aux just-in-time nœuds ?
Les politiques d’approbation sont évaluées dans l’ordre suivant :
1. Refuser l’accès
1. Approbation automatique
1. Manuelle
## Comment les politiques d’approbation manuelle sont-elles évaluées ?
Just-in-time l'accès aux nœuds privilégie toujours la politique plus spécifique à un nœud. Les stratégies d’approbation manuelle sont évaluées dans l’ordre suivant :
1. Balise cible spécifique
1. Tous les nœuds à cibler
## Que se passe-t-il si aucune politique d’approbation ne s’applique à un nœud ?
Pour se connecter à un just-in-time nœud en utilisant l'accès au nœud, une politique d'approbation doit s'appliquer au nœud. Si aucune politique d’approbation ne s’applique à un nœud, les utilisateurs ne peuvent pas demander l’accès au nœud.
## Plusieurs politiques d’approbation peuvent-elles cibler une balise ?
Une balise ne peut être ciblée qu’une seule fois dans vos politiques d’approbation.
## Que se passe-t-il si plusieurs politiques d’approbation manuelle s’appliquent à un nœud en raison d’un chevauchement de balises ?
Lorsque plusieurs politiques d’approbation manuelle s’appliquent à un nœud, cela entraîne un conflit et les utilisateurs ne peuvent pas demander l’accès au nœud. Gardez cela à l’esprit lorsque vous créez vos politiques d’approbation manuelle, car certaines instances peuvent comporter plusieurs balises selon le cas.
## Puis-je utiliser l'accès aux just-in-time nœuds pour demander l'accès et démarrer des sessions sur les nœuds de différents comptes et régions ?
Just-in-time l'accès aux nœuds prend en charge les demandes d'accès et le démarrage de sessions sur les nœuds du même compte et de la même région que le demandeur.
## Puis-je utiliser l'accès aux just-in-time nœuds pour demander l'accès et démarrer des sessions sur les nœuds enregistrés avec une activation hybride ?
Oui, l'accès aux just-in-time nœuds prend en charge les demandes d'accès et le démarrage de sessions sur les nœuds enregistrés avec une activation hybride. Le nœud doit être enregistré dans le même compte et la même région que le demandeur.