• 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.
# 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**.