• O AWS Systems Manager CloudWatch Dashboard não estará mais disponível a partir de 30 de abril de 2026. Os clientes podem continuar usando o console do Amazon CloudWatch para visualizar, criar e gerenciar os painéis do Amazon CloudWatch exatamente como fazem hoje. Para obter mais informações, consulte a [documentação do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html).
# Configurar o acesso just-in-time com o Systems Manager
A configuração do acesso a nós just-in-time com o Systems Manager envolve várias etapas. Primeiro, você escolhe os *destinos* em que deseja configurar o acesso a nós just-in-time. Os destinos consistem em unidades organizacionais (UOs) do AWS Organizations e Regiões da AWS. Por padrão, os mesmos destinos que você escolheu ao configurar o console unificado do Systems Manager são selecionados para acesso a nós just-in-time. Você pode optar por configurar o acesso a nós just-in-time para todos os mesmos destinos ou para um subconjunto dos destinos que você especificou ao configurar o console unificado do Systems Manager. Não há suporte para a adição de novos destinos que não foram selecionados quando você configurou o console unificado do Systems Manager.
Em seguida, você criará *políticas de aprovação* para determinar quando as conexões com os nós exigem aprovação manual e quando são aprovadas automaticamente. As políticas de aprovação são gerenciadas por cada conta em sua organização. Você também pode compartilhar uma política da conta do administrador delegado para negar explicitamente a aprovação automática de conexões com nós específicos.
**nota**
A configuração do acesso a nós just-in-time não afeta as preferências ou políticas existentes do IAM que você configurou para o Session Manager. Você deve remover a permissão para a ação de API do `StartSession` de suas políticas do IAM para garantir que somente o acesso a nós just-in-time seja usado quando os usuários tentarem se conectar aos nós. Depois de configurar o acesso a nós just-in-time, recomendamos testar suas políticas de aprovação com um subconjunto de usuários e nós para verificar se suas políticas estão funcionando conforme desejado, antes de remover as permissões para o Session Manager.
**Compatibilidade com autenticação**
Observe os seguintes detalhes sobre o suporte à autenticação usado para acesso a nós just-in-time:
+ O acesso a nós just-in-time não é compatível com o tipo de autenticação de login único ao se conectar a instâncias Windows Server com o Remote Desktop.
+ Há suporte somente a credenciais de segurança temporárias `AssumeRole` do AWS Security Token Service (AWS STS). Para obter mais informações, consulte os seguintes tópicos no *Guia do usuário do IAM*:
+
+ [Credenciais de segurança temporárias no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [Comparar credenciais do AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_sts-comparison.html)
+ [Solicitar credenciais de segurança temporárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html)
As políticas do IAM a seguir descrevem as permissões necessárias para administrar e permitir que os usuários criem solicitações de acesso a nós just-in-time com o Systems Manager. Depois de verificar se você tem as permissões necessárias para usar o acesso a nós just-in-time com o Systems Manager, você pode continuar o processo de configuração. Substitua cada *espaço reservado para recurso de exemplo* por suas próprias informações.
## Política do IAM para habilitar o acesso a nós just-in-time
------
#### [ 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": "*"
}
]
}
```
------
## Política do IAM para configurar o acesso a nós just-in-time
------
#### [ 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": "*"
}
]
}
```
------
## Política do IAM para aprovadores de solicitações de acesso
------
#### [ 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": "*"
}
]
}
```
------
## Política do IAM para usuários de acesso a nós just-in-time
------
#### [ 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": "*"
}
]
}
```
------
**nota**
Para restringir o acesso às operações de API que criam, atualizam ou excluem políticas de aprovação, use a chave de condição `ssm:DocumentType` para os tipos de documento `AutoApprovalPolicy` e `ManualApprovalPolicy `. As operações de API `StartAccessRequest` e `GetAccessToken` não são compatíveis com as seguintes chaves de contexto globais:
`aws:SourceVpc`
`aws:SourceVpce`
`aws:VpcSourceIp`
`aws:UserAgent`
`aws:MultiFactorAuthPresent`
Para obter mais informações sobre chaves de contexto de condição para o Systems Manager, consulte [Condition keys for AWS Systems Manager](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanager.html#awssystemsmanager-policy-keys) na *Referência de autorização do serviço*.
O procedimento a seguir descreve como concluir a primeira etapa de configuração para o acesso a nós just-in-time.
**Para configurar o acesso a nós just-in-time**
1. Faça login na conta de administrador delegado do Systems Manager da sua organização.
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Acesso ao nó Just-in-time** no painel de navegação.
1. Escolha **Habilitar nova experiência**.
1. Escolha as regiões em que você deseja habilitar o acesso a nós just-in-time. Por padrão, as mesmas regiões que você escolheu ao configurar o console unificado do Systems Manager são selecionadas para acesso a nós just-in-time. Não há suporte para a escolha de novas regiões que não foram selecionadas quando você configurou o console unificado do Systems Manager.
1. Selecione **Habilitar acesso a nós just-in-time**.
Não há cobrança para usar o acesso a nós just-in-time por 30 dias após a habilitação do recurso. Após o período de teste de 30 dias, há uma cobrança pelo uso do acesso a nós just-in-time. Para saber mais, consulte [Preços do AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
# Criar políticas de aprovação para os nós
As políticas de aprovação definem quais aprovações os usuários precisam ter para acessar um nó. Como o acesso a nós just-in-time elimina a necessidade de permissões prolongadas para os nós por meio de políticas do IAM, você deve criar políticas de aprovação para permitir o acesso aos nós. Se não houver políticas de aprovação que se apliquem a um nó, os usuários não poderão solicitar acesso ao nó.
No acesso a nós just-in-time, há três tipos de políticas. Os tipos de política são: *aprovação automática*, *negação de acesso* e *aprovação manual*.
**Tipos de política de acesso a nós just-in-time**
+ Uma política de aprovação automática define a quais nós os usuários podem se conectar automaticamente.
+ As políticas de aprovação manual definem o número e os níveis de aprovações manuais que devem ser fornecidas para acessar os nós que você especificar.
+ Uma política de negação de acesso impede explicitamente a aprovação automática de solicitações de acesso aos nós que você especificar.
Uma política de negação de acesso se aplica a todas as contas em uma organização do AWS Organizations. Por exemplo, você pode negar explicitamente as aprovações automáticas para o grupo `Intern` aos nós marcados com a chave `Production`. As políticas de aprovação automática e manual se aplicam somente às Contas da AWS e às Regiões da AWS onde foram criadas. Cada conta de membro em sua organização gerencia suas próprias políticas de aprovação. As políticas de aprovação são avaliadas na seguinte ordem:
1. Negar acesso
1. Aprovação automática
1. Manual
Embora você só possa ter uma política de negação de acesso por organização e uma política de aprovação automática por conta e região, você provavelmente terá várias políticas de aprovação manual em uma conta. Ao avaliar as políticas de aprovação manual, o acesso a nós just-in-time sempre favorece a política mais específica de um nó. As políticas de aprovação manual são avaliadas na seguinte ordem:
1. Tags específicas para destino
1. Todos os nós para destino
Por exemplo, você tem um nó marcado com a chave `Demo`. Na mesma conta, você tem uma política de aprovação manual que visa todos os nós e exige uma aprovação de um nível. Você também tem uma política de aprovação manual que exige duas aprovações de dois níveis para nós marcados com a chave `Demo`. O Systems Manager aplica a política que direciona a tag `Demo` ao nó, pois ela é mais específica do que a política que visa todos os nós. Isso permite que você crie uma política geral para todos os nós na sua conta, garantindo que os usuários possam enviar solicitações de acesso e, ao mesmo tempo, permitindo que você crie políticas mais granulares conforme necessário.
Dependendo da sua organização, pode haver várias tags aplicadas aos nós. Nesse cenário, se várias políticas de aprovação manual se aplicarem a um nó, as solicitações de acesso falharão. Por exemplo, um nó é marcado com as chaves `Production` e `Database`. Na mesma conta, você tem uma política de aprovação manual que se aplica aos nós marcados com a chave `Production` e outra política de aprovação manual que se aplica aos nós marcados com a chave `Database`. Isso resulta em um conflito para o nó marcado com ambas as chaves, e as solicitações de acesso falham. O Systems Manager redireciona o usuário para a solicitação que falhou. Lá, é possível ver os detalhes sobre as políticas e tags conflitantes para que o usuário possa fazer os ajustes necessários caso tenha as permissões necessárias. Do contrário, o usuário pode notificar um colega em sua organização com as permissões necessárias para modificar as políticas. Conflitos de políticas que resultam em falhas nas solicitações de acesso emitem eventos do EventBridge, permitindo flexibilidade na criação de seus próprios fluxos de trabalho de resposta. Além disso, o Systems Manager envia notificações por e-mail sobre conflitos de políticas que resultam em solicitações de acesso com falha para os destinatários que você especificar. Para obter mais informações sobre como configurar notificações por e-mail de conflitos de políticas, consulte [Configurar notificações para solicitações de acesso just-in-time](systems-manager-just-in-time-node-access-notifications.md).
Em uma política de *negação de acesso*, você usa a linguagem de política Cedar para definir a quais nós os usuários explicitamente não podem se conectar automaticamente em sua organização. Essa política é criada e compartilhada da conta do administrador delegado da sua organização. A política de negação de acesso substitui todas as políticas de aprovação automática. Você só pode ter uma política de negação de acesso por organização.
Em uma política de *aprovação automática*, você usa a linguagem de política Cedar para definir quais usuários podem se conectar automaticamente aos nós especificados sem aprovação manual. A duração do acesso para uma solicitação de acesso aprovada automaticamente é de uma hora. Esse valor não pode ser alterado. Você só pode ter uma política de aprovação automática por conta e região.
Em uma política de aprovação *manual*, você especifica a duração do acesso, quantos níveis de aprovações são necessários, o número de aprovadores necessários por nível e os nós para os quais eles podem aprovar solicitações de acesso just-in-time. A duração do acesso para uma política de aprovação manual deve estar entre 1 e 336 horas. Se você especificar vários níveis de aprovações, as aprovações para a solicitação de acesso processarão um nível por vez. Isso significa que todas as aprovações necessárias para um nível deverão ser fornecidas antes que o processo de aprovação passe para os níveis subsequentes. Se você especificar várias tags em uma política de aprovação manual, elas serão avaliadas como instruções `or`, não instruções `and`. Por exemplo, se você criar uma política de aprovação manual que inclua as tags `Application`, `Web` e `Test`, a política se aplicará a qualquer nó que esteja marcado com uma dessas chaves. A política não se aplica somente aos nós marcados com as três chaves.
Recomendamos usar uma combinação de políticas manuais com sua política de aprovação automática para ajudar você a proteger nós com dados mais críticos e, ao mesmo tempo, permitir que os usuários se conectem a nós menos críticos sem intervenção. Por exemplo, você pode exigir aprovações manuais para solicitações de acesso aos nós do banco de dados e aprovar automaticamente sessões para nós não persistentes da camada de apresentação.
Os procedimentos a seguir descrevem como criar políticas de aprovação para o acesso a nós just-in-time.
**Topics**
+ [Criar políticas de aprovação manual para acesso a nós just-in-time](systems-manager-just-in-time-node-access-create-manual-policies.md)
+ [Estrutura de instruções e operadores integrados para políticas de aprovação automática e negação de acesso](auto-approval-deny-access-policy-statement-structure.md)
+ [Criar uma política de aprovação automática para acesso a nós just-in-time](systems-manager-just-in-time-node-access-create-auto-approval-policies.md)
+ [Criar uma política de negação de acesso para acesso a nós just-in-time](systems-manager-just-in-time-node-access-create-deny-access-policies.md)
+ [Criar políticas de aprovação para acesso a nós just-in-time com o Amazon Q](systems-manager-just-in-time-node-access-create-approval-policies-q-ide-cli.md)
# Criar políticas de aprovação manual para acesso a nós just-in-time
O procedimento a seguir descreve como criar políticas de aprovação manual. O Systems Manager permite que você crie até 50 políticas de aprovação manual por Conta da AWS e Região da AWS.
**Para criar uma política de aprovação manual**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Gerenciar acesso a nós** no painel de navegação.
1. Na seção **Detalhes da política** da etapa **Criar política de aprovação manual**, insira um nome e uma descrição para a política de aprovação.
1. Insira um valor para a **Duração do acesso**. Este é o tempo máximo que um usuário pode iniciar sessões em um nó após a aprovação de uma solicitação de acesso. O valor deve ser entre 1 e 336 horas.
1. Na seção **Destinos do nó**, insira os pares de chave/valor da tag associados aos nós aos quais você deseja que a política se aplique. Se nenhuma das tags especificadas na política estiver associada a um nó, a política não será aplicada ao nó.
1. Na seção **Aprovadores de solicitações de acesso**, insira os usuários ou grupos que você deseja que possam aprovar solicitações de acesso aos destinos de nós na política. Os aprovadores de solicitações de acesso podem ser usuários e grupos do Centro de Identidade do IAM ou perfis do IAM. Você pode especificar até cinco aprovadores por nível e até cinco níveis de aprovadores.
1. Selecione **Criar política de aprovação manual**.
# Estrutura de instruções e operadores integrados para políticas de aprovação automática e negação de acesso
A tabela a seguir mostra a estrutura das políticas de aprovação automática e negação de acesso.
| Componente | Sintaxe |
| --- | --- |
| efeito; | `permit \| forbid` |
| scope | `(principal, action, resource)` |
| Cláusula de condição | when {
principal or resource has attribute name
}; |
## Componentes da política
Uma política de aprovação automática ou negação de acesso contém os seguintes componentes:
+ **Efeito**: permite (`permit`) ou nega (`forbid`) o acesso.
+ **Escopo**: a entidade principal, as ações e os recursos aos quais o efeito se aplica. Você pode deixar o escopo no Cedar indefinido ao não identificar entidades principais, ações ou recursos específicos. Nesse caso, a política se aplica a todos os principais, ações e recursos possíveis. Para acesso a nós just-in-time, o `action` é sempre `AWS::SSM::Action::"getTokenForInstanceAccess"`.
+ **Cláusula de condição**: o contexto no qual o efeito se aplica.
## Comentários
Você pode incluir comentários nas políticas do . Os comentários são definidos como uma linha que começa com `//` e termina com um caractere de nova linha.
O exemplo a seguir mostra comentários em uma política.
```
// 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"
};
```
## Cláusulas múltiplas
Você pode usar mais de uma cláusula de condição em uma declaração de política usando o operador `&&`.
```
// 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"
};
```
## Caracteres reservados
O exemplo a seguir mostra como escrever uma política se uma propriedade de contexto usar `:` (ponto e vírgula), que é um caractere reservado na linguagem da política.
```
permit (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has employeeNumber && principal.employeeNumber like "E-1*" && resource.hasTag("Purpose") && resource.getTag("Purpose") == "Testing"
}
```
Para obter exemplos adicionais, consulte [Exemplo de instruções de políticas](#policy-statement-examples).
## Esquema de acesso a nós just-in-time
Confira abaixo o esquema Cedar para acesso a nós just-in-time.
```
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
}
};
}
```
## Operadores integrados
Ao criar o contexto de uma política de aprovação automática ou negação de acesso usando várias condições, você pode usar o operador `&&` para adicionar outras condições. Há também muitos outros operadores integrados que você pode usar para adicionar mais poder expressivo às condições da sua política. A tabela a seguir contém todos os operadores integrados para referência.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/auto-approval-deny-access-policy-statement-structure.html)
## Exemplo de instruções de políticas
Confira abaixo exemplos de instruções de política.
```
// 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"
};
```
# Criar uma política de aprovação automática para acesso a nós just-in-time
As políticas de aprovação automática usam a linguagem de política Cedar para definir quais usuários podem se conectar automaticamente aos nós especificados sem aprovação manual. Uma política de aprovação automática contém várias declarações `permit` especificando a `principal` e o `resource`. Cada instrução inclui uma cláusula `when` que define as condições para a aprovação automática.
Confira abaixo um exemplo de política de aprovação automática.
```
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"
};
```
O procedimento a seguir descreve como criar uma política de aprovação automática para acesso a nós just-in-time. A duração do acesso para uma solicitação de acesso aprovada automaticamente é de uma hora. Esse valor não pode ser alterado. Você só pode ter uma política de aprovação automática por Conta da AWS e Região da AWS. Para obter informações sobre como criar instruções de política, consulte [Estrutura de instruções e operadores integrados para políticas de aprovação automática e negação de acesso](auto-approval-deny-access-policy-statement-structure.md).
**Para criar uma política de aprovação automática**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Gerenciar acesso a nós** no painel de navegação.
1. Na guia **Políticas de aprovação**, selecione **Criar uma política de aprovação automática**.
1. Insira sua instrução de política para a política de aprovação automática na seção **Instrução de política**. Você pode usar as **Instruções de exemplo** fornecidas para ajudar a criar sua política.
1. Selecione **Criar política de aprovação automática**.
# Criar uma política de negação de acesso para acesso a nós just-in-time
As políticas de negação de acesso usam a linguagem de política Cedar para definir a quais nós os usuários não podem se conectar automaticamente sem aprovação manual. Uma política de negação de acesso contém várias instruções `forbid` especificando a `principal` e o `resource`. Cada instrução inclui uma cláusula `when` que define as condições para negar explicitamente a aprovação automática.
Confira abaixo um exemplo de política de negação de acesso.
```
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"
};
```
O procedimento a seguir descreve como criar uma política de negação de acesso para acesso a nós just-in-time. Para obter informações sobre como criar instruções de política, consulte [Estrutura de instruções e operadores integrados para políticas de aprovação automática e negação de acesso](auto-approval-deny-access-policy-statement-structure.md).
**nota**
Observe as seguintes informações:
Você poderá criar políticas de negação de acesso enquanto estiver conectado à conta de gerenciamento da AWS ou à conta de administrador delegado. Sua organização do AWS Organizations pode ter apenas uma política de negação de acesso.
O acesso ao nó just-in-time faz uso do AWS Resource Access Manager (AWS RAM) para compartilhar sua política de negação de acesso com as contas de membros na sua organização. Se você quiser compartilhar sua política de negação de acesso com as contas de membros da sua organização, o compartilhamento de recursos deve ser habilitado na conta gerencial da sua organização. Para obter mais informações, consulte [Habilitar o compartilhamento de recursos no AWS Organizations](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs) no *Guia do usuário do AWS RAM*.
**Para criar uma política de negação de acesso**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Gerenciar acesso a nós** no painel de navegação.
1. Na guia **Políticas de aprovação**, selecione **Criar uma política de negação de acesso**.
1. Insira sua instrução de política para a política de negação de acesso na seção **Instrução de política**. Você pode usar as **Instruções de exemplo** fornecidas para ajudar a criar sua política.
1. Selecione **Criar política de negação de acesso**.
# Criar políticas de aprovação para acesso a nós just-in-time com o Amazon Q
O uso do Amazon Q Developer para a linha de comando fornece orientação e suporte em vários aspectos do desenvolvimento de software. Para acesso a nós just-in-time, o Amazon Q ajuda você a criar políticas de aprovação gerando e atualizando o código das políticas, analisando declarações de políticas e muito mais. As informações a seguir descrevem como criar políticas de aprovação usando o Amazon Q para a linha de comando.
## Identifique seu caso de uso
A primeira etapa na criação de políticas de aprovação é definir claramente o caso de uso. Por exemplo, na sua organização, talvez você queira aprovar automaticamente as solicitações de acesso a nós com uma tag `Environment:Testing`. Talvez você também queira negar explicitamente as aprovações automáticas aos nós com uma tag `Environment:Production` se o ID do funcionário começar com `TEMP`. Para nós com uma tag `Tier:Database`, talvez você queira exigir dois níveis de aprovações manuais.
Em qualquer cenário específico, você pode preferir uma política ou condição em vez de outra. Portanto, recomendamos que você defina claramente os comportamentos da política que deseja para determinar quais instruções melhor se adaptam ao seu caso de uso e preferências.
## Configuração do ambiente de desenvolvimento
Instale o Amazon Q para a linha de comando em que você deseja desenvolver suas políticas de aprovação. Para obter informações sobre a instalação do Amazon Q para a linha de comando, consulte [Installing Amazon Q for command line](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-installing.html) no *Guia do usuário do Amazon Q Developer*.
Também recomendamos instalar o servidor MCP da documentação da AWS. Esse servidor MCP conecta o Amazon Q da linha de comando aos recursos de documentação mais atuais. Para obter informações sobre o uso do MCP com o Amazon Q para a linha de comando, consulte [Using MCP with Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-mcp.html) no *Guia do usuário do Amazon Q Developer*.
Para obter mais informações sobre o servidor MCP da documentação da AWS, consulte [AWS Documentation MCP Server](https://awslabs.github.io/mcp/servers/aws-documentation-mcp-server/).
Instale e configure a AWS CLI, caso ainda não tenha feito isso. Para obter informações, consulte [Instalar ou atualizar a versão mais recente da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
## Desenvolver o conteúdo da política de aprovação
Com o caso de uso identificado e o ambiente configurado, você está pronto para desenvolver o conteúdo das políticas. Seu caso de uso e suas preferências ditarão em grande parte os tipos de políticas e declarações de aprovação que você usa.
Caso não tenha certeza de como usar uma política específica ou precise de mais informações sobre o esquema de uma política, consulte [Criar políticas de aprovação para os nós](systems-manager-just-in-time-node-access-approval-policies.md) e os tópicos subsequentes. Esses tópicos explicam em detalhes como as políticas são avaliadas e fornecem exemplos práticos de instruções.
O procedimento a seguir descreve como criar políticas de aprovação com o Amazon Q da linha de comando.
**nota**
O Amazon Q Developer usa IA generativa. Talvez seja necessário verificar as respostas. Consulte a [Política de uso responsável de IA da AWS](https://aws.amazon.com/ai/responsible-ai/policy/).
**Para criar políticas de aprovação usando o Amazon Q da linha de comando**
1. Abra seu terminal e inicie uma sessão com o Amazon Q.
```
$ q chat
```
1. Insira um prompt e descreva o tipo de instrução de política que você deseja criar. Por exemplo, usando o cenário anterior para uma política de aprovação, você pode inserir o seguinte prompt:
```
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. A inserção desse prompt de exemplo resultou na seguinte saída:
```
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. Cole a instrução de política em um novo arquivo Cedar para validar a sintaxe. Você também pode validar a instrução usando o [playground Cedar](https://www.cedarpolicy.com/en/playground).
1. Depois de validar a instrução, salve o arquivo Cedar.
1. No seu terminal, execute o comando da AWS CLI a seguir para criar um documento do SSM usando o conteúdo da sua política. Antes de usar políticas de aprovação em um ambiente de produção, teste suas políticas de aprovação com um subconjunto de identidades e nós em uma Conta da AWS e Região da AWS.
**nota**
Para uma política de aprovação automática, o nome do documento deve ser `SSM-JustInTimeAccessAutoApprovalPolicy`. Só pode haver uma política de aprovação automática por Conta da AWS e Região da AWS. Para uma política de negação de acesso, o nome do documento deve ser `SSM-JustInTimeAccessDenyAccessOrgPolicy`. Só pode haver uma política de negação de acesso por organização do AWS Organizations, e a política deve ser criada na conta de administrador delegado do Systems Manager. As restrições de nomenclatura das políticas de aprovação manual são as mesmas de outros documentos do SSM. Para obter mais informações, consulte [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"
```
------
# Atualizar as preferências da sessão de acesso a nós just-in-time
Com o acesso a nós just-in-time, você pode especificar as preferências gerais de sessão e registro em log em cada Conta da AWS e Região da AWS em sua organização. Como alternativa, você pode usar o CloudFormation StackSets para criar um documento de preferências de sessão em várias contas e regiões para ajudar você a ter preferências de sessão consistentes. Para obter informações sobre o esquema para documentos de preferências de sessão, consulte [Esquema do documento de sessão](session-manager-schema.md).
Para fins de registro em log, recomendamos usar a opção de streaming com o Amazon CloudWatch Logs. Esse recurso permite que você envie uma transmissão contínua de logs de dados de sessão ao Amazon CloudWatch Logs. Detalhes essenciais, como os comandos que um usuário executou em uma sessão, o ID do usuário que executou os comandos e carimbos de data/hora para quando os dados da sessão são transmitidos para o CloudWatch Logs, são incluídos ao transmitir dados da sessão. Ao transmitir dados de sessão, os logs são formatados em JSON para ajudar você a integrar com suas soluções de log existentes.
O Systems Manager não encerra automaticamente as sessões de acesso a nós just-in-time. Como prática recomendada, especifique os valores para as configurações de *duração máxima da sessão* e *tempo limite de sessão ociosa*. O uso dessas configurações ajuda a evitar que um usuário permaneça conectado a um nó por mais tempo do que a janela de tempo aprovada em uma solicitação de acesso. O procedimento a seguir descreve como atualizar as preferências de sessão para acesso a nós just-in-time.
**Importante**
É necessário marcar com tags as chaves do AWS KMS usadas para criptografia e gravação RDP no acesso a nós just-in-time no Session Manager com a chave de tag `SystemsManagerJustInTimeNodeAccessManaged` e o valor de tag `true`.
Para obter mais informações sobre tags de chaves do KMS, consulte [Tags no AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/tagging-keys.html) no *Guia do desenvolvedor do AWS Key Management Service*.
**Para atualizar as preferências da sessão**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Configurações** no painel de navegação.
1. Selecione a guia **Acesso a nós just-in-time**.
1. Na seção **Preferências da sessão**, selecione **Editar**.
1. Atualize suas preferências gerais e de registro em log conforme necessário e selecione **Salvar**.
# Configurar notificações para solicitações de acesso just-in-time
Você pode configurar o Systems Manager para enviar notificações quando um usuário criar uma solicitação de acesso a nós just-in-time para os endereços de e-mail ou cliente de chat dos aprovadores e do solicitante. A notificação contém o motivo da solicitação de acesso fornecido pelo solicitante, a Conta da AWS, a Região da AWS, o status da solicitação e o ID do nó de destino. Atualmente, o Systems Manager oferece suporte aos clientes do Slack e do Microsoft Teams por meio da integração com o Amazon Q Developer em aplicações de chat. Ao usar notificações por meio de clientes de chat, os aprovadores de solicitações de acesso podem interagir diretamente com as solicitações de acesso. Isso elimina a necessidade de fazer login no console para executar ações em relação às solicitações de acesso.
**Antes de começar**
Antes de configurar um cliente de chat para notificações de acesso a nós just-in-time, observe o seguinte requisito:
+ Caso esteja usando perfis do IAM para gerenciar identidades de usuários em sua conta, você deverá associar manualmente os endereços de e-mail dos aprovadores ou solicitantes aos quais deseja enviar notificações ao perfil associado. Caso contrário, os destinatários pretendidos não poderão ser notificados por e-mail.
Os procedimentos a seguir descrevem como configurar notificações para solicitações de acesso a nós just-in-time.
**Para configurar um cliente de chat para notificações de acesso a nós just-in-time**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Configurações** no painel de navegação.
1. Selecione a guia **Acesso a nós just-in-time**.
1. Na seção **Chat**, selecione **Configurar novo cliente**.
1. No menu suspenso **Selecionar tipo de cliente**, escolha o tipo de cliente de chat que você deseja configurar e selecione **Próximo**.
1. Você será solicitado a permitir que o Amazon Q Developer em aplicações de chat acesse seu cliente de chat. Selecione **Permitir**.
1. Na seção **Configurar canal**, insira as informações do canal do cliente de chat e selecione os tipos de notificações que você deseja receber.
1. Se você estiver configurando as notificações do Slack, convide "@Amazon Q" para cada canal do Slack em que as notificações estão sendo configuradas.
1. Selecione **Configurar canal**.
**nota**
Para permitir a aprovação/rejeição de solicitações de acesso diretamente de um canal do Slack, certifique-se de que o perfil do IAM configurado com o canal do Slack tenha permissões `ssm:SendAutomationSignal` e tenha uma política de confiança que inclua o chatbot:
```
{
"Effect": "Allow",
"Principal": {
"Service": "chatbot.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
```
**Para configurar notificações por e-mail para notificações de acesso a nós just-in-time**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Configurações** no painel de navegação.
1. Selecione a guia **Acesso a nós just-in-time**.
1. Na seção **E-mail**, selecione **Editar**.
1. Selecione **Adicionar e-mails**, escolha o **perfil do IAM** ao qual você deseja associar manualmente os endereços de e-mail.
1. No campo **Endereço de e-mail**, insira um endereço de e-mail. Sempre que uma solicitação de acesso é criada e exige aprovação do perfil do IAM que você especificou, os endereços de e-mail que você associou ao perfil são notificados.
1. Selecione **Adicionar endereço de e-mail**.
# Gravar conexões RDP
O acesso a nós just-in-time inclui a capacidade de gravar conexões RDP realizadas com seus nós do Windows Server. A gravação de conexões RDP requer um bucket do S3 e uma chave do AWS Key Management Service (AWS KMS) gerenciada pelo cliente. A AWS KMS key é usada para criptografar temporariamente os dados de gravação enquanto são gerados e armazenados nos recursos do Systems Manager. A chave gerenciada pelo cliente deve ser uma chave simétrica com o uso da chave de criptografia e descriptografia. Você pode usar uma chave multirregional para sua organização, ou você deve criar uma chave gerenciada pelo cliente em cada região onde você habilitou o acesso a nós just-in-time.
Se você habilitou a criptografia do KMS no bucket do S3 no qual armazena gravações, será necessário fornecer acesso à chave gerenciada pelo cliente utilizada para a criptografia de buckets à entidade principal de serviço `ssm-guiconnect`. Essa chave gerenciada pelo cliente pode ser diferente da especificada nas configurações de gravação, que precisa incluir a permissão `kms:CreateGrant` que é necessária para o estabelecimento de conexões.
## Configurar a criptografia de buckets do S3 para gravações de RDP
Suas gravações de conexão são armazenadas no bucket do S3 especificado ao habilitar a gravação de RDP.
Se você utilizar uma chave do KMS como mecanismo de criptografia padrão para o bucket do S3 (SSE-KMS), deverá permitir que a entidade principal de serviço `ssm-guiconnect` acesse a ação `kms:GenerateDataKey` nessa chave. Recomendamos o uso de uma chave gerenciada pelo cliente ao usar a criptografia SSE-KMS com um bucket do S3. Isso porque é possível atualizar a política de chave associada de uma chave gerenciada pelo cliente. Não é possível atualizar as políticas de chave para Chaves gerenciadas pela AWS.
**Importante**
É necessário marcar com tags as chaves do AWS KMS usadas para criptografia e gravação RDP no acesso a nós just-in-time no Session Manager com a chave de tag `SystemsManagerJustInTimeNodeAccessManaged` e o valor de tag `true`.
Para obter mais informações sobre tags de chaves do KMS, consulte [Tags no AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/tagging-keys.html) no *Guia do desenvolvedor do AWS Key Management Service*.
Use a política de chave gerenciada pelo cliente a seguir para permitir que o serviço `ssm-guiconnect` acesse a chave do KMS para armazenamento no S3. Para obter informações sobre como modificar uma chave gerenciada pelo cliente, consulte [Alterar uma política de chave](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html) no *Guia do desenvolvedor do AWS Key Management Service*.
Substitua cada *espaço reservado para recurso de exemplo* por suas próprias informações:
+ *account-id* representa o ID da Conta da AWS que inicia a conexão.
+ *region* representa a Região da AWS em que o bucket do S3 está localizado. (Você poderá usar `*` se o bucket for receber gravações de várias regiões. Exemplo: `s3.*.amazonaws.com`).
**nota**
Você poderá usar `aws:SourceOrgID` na política em vez de `aws:SourceAccount` se a conta pertencer a uma organização no 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"
}
}
}
```
## Configurar permissões do IAM para gravar conexões RDP
Além das permissões do IAM necessárias para o acesso a nós just-in-time, o usuário ou perfil que você utilizar deverá ter as permissões a seguir com base na tarefa que você precisará realizar.
**Permissões para configurar a gravação de conexão**
Para configurar o registro de conexões RDP, as seguintes permissões são necessárias:
+ `ssm-guiconnect:UpdateConnectionRecordingPreferences`
+ `ssm-guiconnect:GetConnectionRecordingPreferences`
+ `ssm-guiconnect:DeleteConnectionRecordingPreferences`
+ `kms:CreateGrant`
**Permissões para iniciar conexões**
Para fazer conexões RDP com o acesso a nós just-in-time, as seguintes permissões são necessárias:
+ `ssm-guiconnect:CancelConnection`
+ `ssm-guiconnect:GetConnection`
+ `ssm-guiconnect:StartConnection`
+ `kms:CreateGrant`
**Antes de começar**
Para armazenar as gravações de conexão, primeiro você deve criar um bucket do S3 e adicionar política de bucket a seguir. Substitua cada *espaço reservado para recurso de exemplo* por suas próprias informações.
(Para obter mais informações sobre como adicionar uma política de bucket, consulte [Adicionar uma política de bucket usando o console do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html) no *Guia do usuário do Amazon Simple Storage Service*.)
------
#### [ 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"
}
}
}
]
}
```
------
## Habilitar e configurar a gravação de conexões RDP
O procedimento a seguir descreve como habilitar e configurar o registro de conexões RDP.
**Para habilitar e configurar a gravação de conexões RDP**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Configurações** no painel de navegação.
1. Selecione a guia **Acesso a nós just-in-time**.
1. Na seção **Gravação RDP**, selecione **Habilitar gravação RDP**.
1. Escolha o bucket do S3 no qual você deseja fazer upload das gravações da sessão.
1. Escolha a chave gerenciada pelo cliente que você deseja usar para criptografar temporariamente os dados de gravação enquanto eles são gerados e armazenados nos recursos do Systems Manager. (Pode ser uma chave gerenciada pelo cliente diferente da que você utiliza para criptografar o bucket.)
1. Selecione **Salvar**.
## Valores de status de gravação de conexões RDP
Os valores de status válidos para gravações de conexões RDP incluem o seguinte:
+ `Recording`: a conexão está em processo de ser gravada
+ `Processing`: o vídeo está sendo processado após o encerramento da conexão.
+ `Finished`: estado de terminal com êxito: o vídeo de gravação da conexão foi processado com êxito e carregado no bucket especificado.
+ `Failed`: estado de terminal com falha. A conexão não foi gravada com êxito.
+ `ProcessingError`: uma ou mais falhas/erros intermediários ocorreram durante o processamento do vídeo. Possíveis causas incluem falhas na dependência de serviços ou permissões ausentes em decorrência de uma configuração incorreta no bucket do S3 especificado para o armazenamento de gravações. O serviço continua a fazer tentativasd de processamento quando a gravação se encontra nesse estado.
**nota**
`ProcessingError` pode ocorrer porque a entidade principal de serviço `ssm-guiconnect` não tem permissão para fazer upload de objetos no bucket do S3 depois que a conexão é estabelecida. Outra causa possível é a ausência de permissões do KMS na chave do KMS utilizada para a criptografia do bucket do S3.
# Modificar destinos
Ao configurar o acesso a nós just-in-time, você escolhe os *destinos* em que deseja configurar o acesso a nós just-in-time. Os destinos consistem em unidades organizacionais (UOs) do AWS Organizations e Regiões da AWS. Por padrão, os mesmos destinos que você escolheu ao configurar o console unificado do Systems Manager são selecionados para acesso a nós just-in-time. Você pode optar por configurar o acesso a nós just-in-time para todos os mesmos destinos ou para um subconjunto dos destinos que você especificou ao configurar o console unificado do Systems Manager. Não há suporte para a adição de novos destinos que não foram selecionados quando você configurou o console unificado do Systems Manager. Você pode alterar os destinos selecionados após configurar o acesso a nós just-in-time.
O procedimento a seguir descreve como modificar os destinos para acesso a nós just-in-time.
**Para modificar destinos**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Configurações** no painel de navegação.
1. Selecione a guia **Acesso a nós just-in-time**.
1. Na seção **Destinos**, selecione **Editar**.
1. Selecione as **Unidades organizacionais** e as **Regiões** em que você deseja usar o acesso a nós just-in-time.
1. Selecione **Salvar**.
# Alterar provedores de identidade
Por padrão, o acesso a nós just-in-time usa o IAM como provedor de identidade. Depois de habilitar o acesso a nós just-in-time, os clientes que usam o console unificado com uma organização podem modificar essa configuração para usar o Centro de Identidade do IAM. O acesso a nós just-in-time não é compatível com o Centro de Identidade do IAM como provedor de identidade quando configurado para uma única conta e região.
O procedimento a seguir descreve como modificar o provedor de identidade para acesso a nós just-in-time.
**Para modificar provedores de identidade**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Configurações** no painel de navegação.
1. Selecione a guia **Acesso a nós just-in-time**.
1. Na seção **Identidade do usuário**, selecione **Editar**.
1. Escolha **Habilitar o Centro de Identidade do AWS IAM**.
1. Selecione **Salvar**.