• AWS Systems Manager CloudWatch 대시보드는 2026년 4월 30일 이후에는 더 이상 사용할 수 없습니다. 고객은 Amazon CloudWatch 콘솔을 계속 사용하여 현재와 마찬가지로 Amazon CloudWatch 대시보드를 보고, 생성하고, 관리할 수 있습니다. 자세한 내용은 [Amazon CloudWatch 대시보드 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)를 참조하세요.
# Systems Manager를 사용하는 JIT(Just-in-Time) 노드 액세스
Systems Manager는 **JIT(Just-in-Time) 액세스를 지원하여 노드의 보안 개선에 도움이 됩니다. JIT(Just-in-Time) 노드 액세스를 통해 사용자는 액세스가 실제로 필요한 경우에만 승인할 수 있는 노드에 대한 임시 시간 제한 액세스를 요청할 수 있습니다. 이렇게 하면 IAM 정책에서 관리하는 노드에 장기간 액세스할 필요가 없습니다. 추가로 Systems Manager는 RDP 세션을 Windows Server 노드에 기록하므로 규정 준수 요구 사항을 충족하고 근본 원인 분석을 수행하는 등에 도움이 됩니다. JIT(Just-in-Time) 노드 액세스를 사용하려면 통합 Systems Manager 콘솔을 설정해야 합니다.
JIT(Just-in-Time) 노드 액세스를 사용하면 허용하는 사용자만 노드에 액세스 요청을 제출할 수 있도록 세분화된 IAM 정책을 생성할 수 있습니다. 그런 다음 노드 연결에 필요한 승인을 정의하는 *승인 정책*을 생성합니다. JIT(Just-in-Time) 노드 액세스의 경우 *자동 승인* 정책과 *수동 승인* 정책이 있습니다. 자동 승인 정책은 사용자가 자동으로 연결할 수 있는 노드를 정의합니다. 수동 승인 정책은 지정한 노드에 액세스하기 위해 제공되어야 하는 수동 승인의 수와 수준을 정의합니다. *액세스 거부 정책*을 생성할 수도 있습니다. 액세스 거부 정책은 지정한 노드에 대한 액세스 요청의 자동 승인을 명시적으로 금지합니다. 액세스 거부 정책은 AWS Organizations 조직의 모든 계정에 적용됩니다. 자동 승인 및 수동 승인 정책은 생성된 AWS 계정 및 AWS 리전에만 적용됩니다.
사용자가 노드 연결을 시도하면 노드에 액세스하려는 이유를 입력하라는 메시지가 표시됩니다. 이후 승인 정책이 평가됩니다. 정책에 따라 사용자는 대상 노드에 자동으로 연결되거나 Systems Manager가 요청자를 대신하여 수동 승인 요청을 자동으로 생성합니다. 그러면 노드에 적용되는 수동 승인 정책에 지정된 승인자에게 액세스 요청 알림이 전송되고, 승인자는 요청을 승인 또는 거부할 수 있습니다. 승인자 및 요청자는 이메일로 또는 채팅 애플리케이션의 Amazon Q Developer와 Slack 또는 Microsoft Teams와의 통합을 통해 알림을 받을 수 있습니다. Systems Manager는 지정된 승인자가 필요한 모든 승인을 제공하는 경우에만 요청된 노드에 대한 액세스를 부여합니다. 필요한 모든 승인을 받으면 사용자는 승인 정책에 지정된 액세스 기간 동안 필요한 만큼 노드에 대한 세션을 시작할 수 있습니다. Systems Manager는 JIT(Just-in-Time) 노드 액세스 세션을 자동으로 종료하지 않습니다. 가장 좋은 방법은 *최대 세션 기간* 및 *유휴 세션 제한 시간* 기본 설정 값을 지정하는 것입니다. 이러한 기본 설정을 사용하면 사용자가 승인된 액세스 기간 이후 노드 연결을 유지할 수 없습니다.
사용자가 개입 없이 덜 중요한 노드에 연결할 수 있도록 허용하면서 더욱 중요한 데이터가 포함된 노드를 보호할 수 있도록 승인 정책을 조합하여 사용하는 것이 좋습니다. 예를 들어 데이터베이스 노드에 대한 액세스 요청에 수동 승인을 요구하고 비영구 프레젠테이션 계층 노드에 대한 세션을 자동 승인할 수 있습니다.
Systems Manager는 IAM Identity Center 또는 IAM과 페더레이션 사용자에 대한 JIT(Just-in-Time) 노드 액세스를 지원합니다. 페더레이션 사용자가 액세스 요청을 제출하면 대상 노드와 노드에 연결해야 하는 이유를 지정합니다. Systems Manager는 사용자의 자격 증명을 조직의 승인 정책에 정의된 파라미터와 비교합니다. 자동 승인 정책 조건이 충족되거나 승인자가 수동으로 승인을 제공하면 요청자는 대상 노드에 연결할 수 있습니다. 사용자가 승인된 노드에 연결을 시도하면 Systems Manager는 임시 토큰을 생성 및 사용하여 세션을 설정합니다.
Systems Manager 서비스는 액세스 요청 인증과 세션 설정을 처리하므로 IAM 정책을 사용하여 노드에 대한 액세스를 관리할 필요가 없습니다. Systems Manager는 JIT(Just-in-Time) 노드 액세스 사용을 통해 조직에 지속되는 권한이 없도록 하는 데 도움이 됩니다. 사용자가 노드에 대한 영구 권한으로 세션을 시작하도록 허용하는 대신 액세스 요청 생성을 허용하기만 하면 되기 때문입니다. 규정 준수 요구 사항 충족에 도움이 되도록 Systems Manager는 모든 액세스 요청을 1년 동안 유지합니다. 또한 Systems Manager는 JIT(Just-in-Time) 액세스에 대해 실패한 액세스 요청과 수동 승인을 위한 액세스 요청 상태 업데이트와 관련된 EventBridge 이벤트를 내보냅니다. 자세한 내용은 [Amazon EventBridge로 Systems Manager 이벤트 모니터링](monitoring-eventbridge-events.md) 단원을 참조하십시오.
**Topics**
+ [Systems Manager로 JIT(Just-in-Time) 액세스 설정](systems-manager-just-in-time-node-access-setting-up.md)
+ [JIT(Just-in-Time) 노드 액세스 세션 시작](systems-manager-just-in-time-node-access-start-session.md)
+ [JIT(Just-in-Time) 액세스 요청 관리](systems-manager-just-in-time-node-access-manage-requests.md)
+ [Session Manager에서 JIT(Just-in-Time) 노드 액세스로 이동](systems-manager-just-in-time-node-access-moving-from-session-manager.md)
+ [Systems Manager로 JIT(Just-in-Time) 액세스 비활성화](systems-manager-just-in-time-node-access-disable.md)
+ [JIT(Just-in-Time) 노드 액세스 자주 묻는 질문](just-in-time-node-access-faq.md)
# Systems Manager로 JIT(Just-in-Time) 액세스 설정
몇 단계에 걸쳐 Systems Manager로 JIT(Just-in-Time) 노드 액세스를 설정합니다. 먼저 JIT(Just-in-Time) 노드 액세스를 설정하려는 *대상*을 선택합니다. 대상은 AWS Organizations 조직 단위(OU)와 AWS 리전으로 구성됩니다. 기본적으로 통합 Systems Manager 콘솔을 설정할 때 선택한 것과 동일한 대상이 JIT(Just-in-Time) 노드 액세스 대상으로 선택됩니다. 통합 Systems Manager 콘솔을 설정할 때 모든 동일한 대상에 또는 지정한 대상의 하위 집합에 JIT(Just-in-Time) 노드 액세스를 설정할 수 있습니다. 통합 Systems Manager 콘솔 설정 시 선택되지 않은 새 대상을 추가하는 것은 지원되지 않습니다.
다음으로 *승인 정책*을 생성하여 노드 연결에 수동 승인이 필요한 경우와 자동으로 승인되는 경우를 결정합니다. 승인 정책은 조직의 각 계정에서 관리합니다. 또한 위임된 관리자 계정의 정책을 공유하여 특정 노드에 대한 연결 자동 승인을 명시적으로 거부할 수 있습니다.
**참고**
JIT(Just-in-Time) 노드 액세스를 설정해도 Session Manager에 대해 구성한 기존 IAM 정책 또는 기본 설정에 영향을 미치지 않습니다. 사용자가 노드 연결을 시도할 때 JIT(Just-in-Time) 노드 액세스만 사용하도록 IAM 정책에서 `StartSession` API 작업에 대한 권한을 제거해야 합니다. JIT(Just-in-Time) 노드 액세스를 설정한 후에는 Session Manager에 대한 권한을 제거하기 전에 사용자 및 노드의 하위 집합으로 승인 정책을 테스트하여 정책이 원하는 대로 작동하는지 확인하는 것이 좋습니다.
**인증 지원**
Just-in-Time 노드 액세스에 사용되는 인증 지원에 대한 다음 세부 정보를 참고하세요.
+ Just-in-Time 노드 액세스는 원격 데스크톱을 사용하여 Windows Server 인스턴스에 연결할 때 Single Sign-On 인증 유형을 지원하지 않습니다.
+ AWS Security Token Service(AWS STS) `AssumeRole` 임시 보안 자격 증명만 지원됩니다. 자세한 설명은 *IAM 사용자 가이드*에서 다음 주제를 참조하세요:
+
+ [IAM의 임시 보안 자격 증명](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [AWS STS 자격 증명 비교](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_sts-comparison.html)
+ [임시 보안 자격 증명 요청](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html)
다음 IAM 정책은 사용자가 Systems Manager로 노드에 JIT(Just-in-Time) 노드 액세스 요청을 생성하도록 관리 및 허용하는 데 필요한 권한을 간략하게 설명합니다. Systems Manager에서 JIT(Just-in-Time) 노드 액세스를 사용하는 데 필요한 권한이 있는지 확인한 후 설정 프로세스를 계속할 수 있습니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
## JIT(Just-in-Time) 노드 액세스 활성화를 위한 IAM 정책
------
#### [ 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": "*"
}
]
}
```
------
## JIT(Just-in-Time) 노드 액세스 구성을 위한 IAM 정책
------
#### [ 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": "*"
}
]
}
```
------
## 액세스 요청 승인자를 위한 IAM 정책
------
#### [ 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": "*"
}
]
}
```
------
## JIT(Just-in-Time) 노드 액세스 사용자를 위한 IAM 정책
------
#### [ 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": "*"
}
]
}
```
------
**참고**
승인 정책을 생성, 업데이트 또는 삭제하는 API 작업에 대한 액세스를 제한하려면 `AutoApprovalPolicy` 및 `ManualApprovalPolicy ` 문서 유형에 `ssm:DocumentType` 조건 키를 사용합니다. `StartAccessRequest` 및 `GetAccessToken` API 작업은 다음과 같은 전역 컨텍스트 키를 지원하지 않습니다.
`aws:SourceVpc`
`aws:SourceVpce`
`aws:VpcSourceIp`
`aws:UserAgent`
`aws:MultiFactorAuthPresent`
Systems Manager의 조건 컨텍스트 키에 대한 자세한 내용은 *서비스 승인 참조*의 [AWS Systems Manager의 조건 키](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanager.html#awssystemsmanager-policy-keys)를 참조하세요.
다음 절차에서는 JIT(Just-in-Time) 노드 액세스를 위한 첫 번째 설정 단계를 완료하는 방법을 설명합니다.
**JIT(Just-in-Time) 노드 액세스 설정**
1. 조직의 Systems Manager 위임된 관리자 계정에 로그인합니다.
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **JIT(Just-in-Time) 노드 액세스**를 선택합니다.
1. **새 환경 활성화**를 선택합니다.
1. JIT(Just-in-Time) 노드 액세스를 활성화할 리전을 선택합니다. 기본적으로 통합 Systems Manager 콘솔을 설정할 때 선택한 것과 동일한 리전이 JIT(Just-in-Time) 노드 액세스에 대해 선택됩니다. 통합 Systems Manager 콘솔 설정 시 선택되지 않은 새 리전을 선택하는 것은 지원되지 않습니다.
1. **JIT(Just-in-Time) 노드 액세스 활성화**를 선택합니다.
기능을 활성화한 후 30일 동안 JIT(Just-in-Time) 노드 액세스 사용에는 요금이 부과되지 않습니다. 30일의 평가판 기간이 지나면 JIT(Just-in-Time) 노드 액세스 사용 요금이 부과됩니다. 자세한 내용은 [AWS Systems Manager요금](https://aws.amazon.com/systems-manager/pricing/)을 참조하세요.
# 노드에 대한 승인 정책 생성
승인 정책은 사용자가 노드에 액세스하는 데 필요한 승인을 정의합니다. JIT(Just-in-Time) 노드 액세스로 인해 IAM 정책을 통해 노드에 대한 장기 지속 권한을 설정할 필요가 없으므로 노드에 대한 액세스를 허용하는 승인 정책을 생성해야 합니다. 노드에 적용되는 승인 정책이 없는 경우 사용자는 노드에 대한 액세스를 요청할 수 없습니다.
JIT(Just-in-Time) 노드 액세스에는 세 가지 유형의 정책이 있습니다. 정책 유형은 *자동 승인*, *액세스 거부*, *수동 승인*입니다.
**JIT(Just-in-Time) 노드 액세스 정책 유형**
+ 자동 승인 정책은 사용자가 자동으로 연결할 수 있는 노드를 정의합니다.
+ 수동 승인 정책은 지정한 노드에 액세스하기 위해 제공되어야 하는 수동 승인의 수와 수준을 정의합니다.
+ 액세스 거부 정책은 지정한 노드에 대한 액세스 요청의 자동 승인을 명시적으로 금지합니다.
액세스 거부 정책은 AWS Organizations 조직의 모든 계정에 적용됩니다. 예를 들어 `Production` 키로 태그가 지정된 노드에 대한 `Intern` 그룹의 자동 승인을 명시적으로 거부할 수 있습니다. 자동 승인 및 수동 승인 정책은 생성된 AWS 계정 및 AWS 리전에만 적용됩니다. 조직의 각 멤버 계정은 자체 승인 정책을 관리합니다. 승인 정책은 다음 순서로 평가됩니다.
1. 액세스 거부
1. 자동 승인
1. 수동
조직당 1개의 액세스 거부 정책과 계정 및 리전당 1개의 자동 승인 정책이 있을 수 있지만 계정에 여러 개의 수동 승인 정책이 있을 수 있습니다. 수동 승인 정책을 평가할 때 JIT(Just-in-Time) 노드 액세스는 항상 노드에 대한 더 구체적인 정책을 우선합니다. 수동 승인 정책은 다음 순서로 평가됩니다.
1. 태그별 대상
1. 모든 노드 대상
예를 들어 `Demo` 키로 태그가 지정된 노드가 있습니다. 동일한 계정에는 모든 노드를 대상으로 하고 한 수준에서 하나의 승인이 필요한 수동 승인 정책이 있습니다. `Demo` 키로 태그가 지정된 노드에 대해 두 수준에서 두 번의 승인이 필요한 수동 승인 정책도 있습니다. 모든 노드를 대상으로 하는 정책보다 더 구체적이므로 Systems Manager는 `Demo` 태그를 대상으로 하는 정책을 노드에 적용합니다. 이렇게 하면 사용자가 액세스 요청을 제출할 수 있도록 계정의 모든 노드에 대한 일반 정책을 생성하는 동시에 필요에 따라 더 세분화된 정책을 생성할 수 있습니다.
조직에 따라 노드에 여러 개의 태그가 적용될 수 있습니다. 이 시나리오에서는 노드에 여러 개의 수동 승인 정책이 적용되는 경우 액세스 요청이 실패합니다. 예를 들어 노드에는 `Production` 및 `Database` 키로 태그가 지정됩니다. 동일한 계정에서 `Production` 키로 태그가 지정된 노드에 적용되는 수동 승인 정책과 `Database` 키로 태그가 지정된 노드에 적용되는 또 다른 수동 승인 정책이 있습니다. 이에 따라 두 키로 태그가 지정된 노드가 충돌하고 액세스 요청은 실패합니다. Systems Manager는 사용자를 실패한 요청으로 리디렉션합니다. 여기에서 충돌하는 정책 및 태그에 관한 세부 정보를 볼 수 있으므로 필요한 권한이 있다면 필요에 따라 조정할 수 있습니다. 아니면 정책 수정에 필요한 권한을 조직의 동료에게 알릴 수 있습니다. 정책 충돌로 인해 액세스 요청이 실패하면 EventBridge 이벤트가 발생하므로 자체 응답 워크플로를 유연하게 구축할 수 있습니다. 또한 Systems Manager는 정책 충돌로 인해 액세스 요청이 실패할 경우 지정한 수신자에게 이메일 알림을 보냅니다. 정책 충돌 이메일 알림 구성에 대한 자세한 내용은 [JIT(Just-in-Time) 액세스 요청 알림 구성](systems-manager-just-in-time-node-access-notifications.md) 섹션을 참조하세요.
*액세스 거부* 정책에서 Cedar 정책 언어를 사용하여 조직의 사용자가 명시적으로 자동 연결할 수 없는 노드를 정의합니다. 이 정책은 조직의 위임된 관리자 계정에서 생성 및 공유됩니다. 액세스 거부 정책은 모든 자동 승인 정책보다 우선합니다. 조직당 액세스 거부 정책은 단 하나만 있을 수 있습니다.
*자동 승인* 정책에서 Cedar 정책 언어를 사용하여 어떤 사용자가 수동 승인 없이 지정된 노드에 자동으로 연결할 수 있는지 정의합니다. 자동 승인된 액세스 요청의 액세스 기간은 1시간입니다. 이 값은 변경할 수 없습니다. 계정 및 리전당 1개의 자동 승인 정책만 있을 수 있습니다.
*수동* 승인 정책에서 액세스 기간, 필요한 승인 수준, 수준당 필요한 승인자 수, JIT(Just-in-Time) 액세스 요청을 승인할 수 있는 노드를 지정합니다. 수동 승인 정책의 액세스 기간은 1\$1336시간이어야 합니다. 여러 수준의 승인을 지정하는 경우 한 번에 하나의 수준씩 액세스 요청 승인이 처리됩니다. 즉, 한 수준에서 필요한 모든 승인이 제공되어야 후속 수준으로 이동합니다. 수동 승인 정책에서 여러 태그를 지정하는 경우 해당 태그는 `and` 문이 아닌 `or` 문으로 평가됩니다. 예를 들어 태그 `Application`, `Web` 및 `Test`가 포함된 수동 승인 정책을 생성하면 해당 키 중 하나로 태그가 지정된 모든 노드에 정책이 적용됩니다. 이 정책은 3개의 키 모두로 태그가 지정된 노드에만 적용되지 않습니다.
사용자가 개입 없이 덜 중요한 노드에 연결할 수 있도록 허용하면서 더욱 중요한 데이터가 포함된 노드를 보호할 수 있도록 수동 승인과 자동 승인 정책을 조합하여 사용하는 것이 좋습니다. 예를 들어 데이터베이스 노드에 대한 액세스 요청에 수동 승인을 요구하고 비영구 프레젠테이션 계층 노드에 대한 세션을 자동 승인할 수 있습니다.
다음 절차에서는 JIT(Just-in-Time) 노드 액세스에 대한 승인 정책을 생성하는 방법을 설명합니다.
**Topics**
+ [JIT(Just-in-Time) 노드 액세스에 대한 수동 승인 정책 생성](systems-manager-just-in-time-node-access-create-manual-policies.md)
+ [자동 승인 및 액세스 거부 정책에 대한 문 구조 및 기본 제공 연산자](auto-approval-deny-access-policy-statement-structure.md)
+ [JIT(Just-in-Time) 노드 액세스에 대한 자동 승인 정책 생성](systems-manager-just-in-time-node-access-create-auto-approval-policies.md)
+ [JIT(Just-in-Time) 노드 액세스에 대한 액세스 거부 정책 생성](systems-manager-just-in-time-node-access-create-deny-access-policies.md)
+ [Amazon Q로 JIT(Just-in-Time) 노드 액세스에 대한 승인 정책 생성](systems-manager-just-in-time-node-access-create-approval-policies-q-ide-cli.md)
# JIT(Just-in-Time) 노드 액세스에 대한 수동 승인 정책 생성
다음 절차에서는 수동 승인 정책을 생성하는 방법을 설명합니다. Systems Manager를 사용하여 AWS 계정 및 AWS 리전당 최대 50개의 수동 승인 정책을 생성할 수 있습니다.
**수동 승인 정책 생성**
1. AWS Systems Manager 콘솔([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/))을 엽니다.
1. 탐색 창에서 **노드 액세스 관리**를 선택합니다.
1. **수동 승인 정책 생성** 단계의 **정책 세부 정보** 섹션에 승인 정책의 이름과 설명을 입력합니다.
1. **액세스 기간**에 값을 입력합니다. 이 값은 액세스 요청이 승인된 후 사용자가 노드에 대한 세션을 시작할 수 있는 최대 시간입니다. 1\$1336시간이어야 합니다.
1. **노드 대상** 섹션에서 정책을 적용할 노드와 연결된 태그 키-값 쌍을 입력합니다. 정책에 지정된 태그 중에 노드와 연결된 태그가 전혀 없으면 정책이 노드에 적용되지 않습니다.
1. **액세스 요청 승인자** 섹션에서 정책의 노드 대상에 대한 액세스 요청을 승인할 수 있는 사용자 또는 그룹을 입력합니다. 액세스 요청 승인자는 IAM Identity Center 사용자 및 그룹 또는 IAM 역할일 수 있습니다. 수준당 최대 5명의 승인자, 그리고 최대 5개의 승인자 수준을 지정할 수 있습니다.
1. **수동 승인 정책 생성**을 선택합니다.
# 자동 승인 및 액세스 거부 정책에 대한 문 구조 및 기본 제공 연산자
다음 표에는 자동 승인 및 액세스 거부 정책의 구조가 나와 있습니다.
| 구성 요소 | 구문 |
| --- | --- |
| effect | `permit \| forbid` |
| 범위 | `(principal, action, resource)` |
| 조건 절 | when {
principal or resource has attribute name
}; |
## 정책 구성 요소
자동 승인 또는 액세스 거부 정책에는 다음 구성 요소가 포함됩니다.
+ **효과** - 액세스를 `permit`(허용) 또는 `forbid`(거부)합니다.
+ **범위** – 효과가 적용되는 위탁자, 작업 및 리소스입니다. 특정 위탁자, 작업 또는 리소스를 식별하지 않음으로써 Cedar의 범위를 정의하지 않은 상태로 둘 수 있습니다. 이 경우 가능한 모든 주체, 작업 및 리소스에 정책이 적용됩니다. JIT(Just-in-Time) 노드 액세스에서 `action`은 항상 `AWS::SSM::Action::"getTokenForInstanceAccess"`입니다.
+ **조건 절** - 효과가 적용되는 컨텍스트입니다.
## 설명
정책에 주석을 포함할 수 있습니다. 주석은 `//`로 시작하고 줄바꿈 문자로 끝나는 줄로 정의됩니다.
다음 예는 정책의 주석을 보여줍니다.
```
// 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"
};
```
## 여러 절
`&&` 연산자를 사용하여 정책 문에 조건 절을 두 개 이상 사용할 수 있습니다.
```
// 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"
};
```
## 예약 문자
다음 예제는 컨텍스트 속성이 정책 언어의 예약 문자인 `:`(세미콜론)을 사용하는 경우 정책을 작성하는 방법을 보여줍니다.
```
permit (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has employeeNumber && principal.employeeNumber like "E-1*" && resource.hasTag("Purpose") && resource.getTag("Purpose") == "Testing"
}
```
추가 예제는 다음([정책 문 예제](#policy-statement-examples))을 참조하십시오.
## JIT(Just-in-Time) 노드 액세스 스키마
다음은 JIT(Just-in-Time) 노드 액세스에 대한 Cedar 스키마입니다.
```
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
}
};
}
```
## 내장 연산자
다양한 조건을 사용하여 자동 승인 또는 액세스 거부 정책의 컨텍스트를 생성할 때는 `&&` 연산자를 사용하여 추가 조건을 추가할 수 있습니다. 정책 조건에 추가적인 표현력을 추가하는 데 사용할 수 있는 다른 내장 연산자도 많이 있습니다. 다음 표에는 참조용으로 제공되는 모든 내장 연산자가 나와 있습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/auto-approval-deny-access-policy-statement-structure.html)
## 정책 문 예제
다음은 정책 문의 예제입니다.
```
// 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"
};
```
# JIT(Just-in-Time) 노드 액세스에 대한 자동 승인 정책 생성
자동 승인 정책은 Cedar 정책 언어를 사용하여 어떤 사용자가 수동 승인 없이 지정된 노드에 자동으로 연결할 수 있는지 정의합니다. 자동 승인 정책에는 `principal` 및 `resource`를 지정하는 여러 `permit` 문이 포함되어 있습니다. 각 문에는 자동 승인에 대한 조건을 정의하는 `when` 절이 포함됩니다.
다음은 자동 승인 정책의 예제입니다.
```
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"
};
```
다음 절차에서는 JIT(Just-in-Time) 노드 액세스에 대한 자동 승인 정책을 생성하는 방법을 설명합니다. 자동 승인된 액세스 요청의 액세스 기간은 1시간입니다. 이 값은 변경할 수 없습니다. AWS 계정 및 AWS 리전당 1개의 자동 승인 정책만 있을 수 있습니다. 정책 문을 구성하는 방법에 대한 자세한 내용은 [자동 승인 및 액세스 거부 정책에 대한 문 구조 및 기본 제공 연산자](auto-approval-deny-access-policy-statement-structure.md) 섹션을 참조하세요.
**자동 승인 정책 생성**
1. AWS Systems Manager 콘솔([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/))을 엽니다.
1. 탐색 창에서 **노드 액세스 관리**를 선택합니다.
1. **승인 정책** 탭에서 **자동 승인 정책 생성**을 선택합니다.
1. **정책 문** 섹션에 자동 승인 정책에 대한 정책 문을 입력합니다. 제공된 **샘플 문**을 사용하여 정책을 생성할 수 있습니다.
1. **자동 승인 정책 생성**을 선택합니다.
# JIT(Just-in-Time) 노드 액세스에 대한 액세스 거부 정책 생성
액세스 거부 정책은 Cedar 정책 언어를 사용하여 사용자가 수동 승인 없이 자동으로 연결할 수 없는 노드를 정의합니다. 액세스 거부 정책에는 `principal` 및 `resource`를 지정하는 여러 `forbid` 문이 포함되어 있습니다. 각 문에는 자동 승인을 명시적으로 거부하는 조건을 정의하는 `when` 절이 포함됩니다.
다음은 액세스 거부 정책의 예제입니다.
```
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"
};
```
다음 절차에서는 JIT(Just-in-Time) 노드 액세스에 대한 액세스 거부 정책을 생성하는 방법을 설명합니다. 정책 문을 구성하는 방법에 대한 자세한 내용은 [자동 승인 및 액세스 거부 정책에 대한 문 구조 및 기본 제공 연산자](auto-approval-deny-access-policy-statement-structure.md) 섹션을 참조하세요.
**참고**
다음 정보를 참고하세요.
AWS 관리 계정 또는 위임된 관리자 계정으로 로그인한 상태에서 액세스 거부 정책을 생성할 수 있습니다. AWS Organizations 조직에는 단 하나의 액세스 거부 정책만 있을 수 있습니다.
JIT(Just-in-Time) 노드 액세스는 AWS Resource Access Manager (AWS RAM)를 사용하여 액세스 거부 정책을 조직의 멤버 계정과 공유합니다. 액세스 거부 정책을 조직의 멤버 계정과 공유하려면 조직의 관리 계정에서 리소스 공유를 활성화해야 합니다. 자세한 내용은 *AWS RAM 사용 설명서*의 [AWS Organizations 내 리소스 공유 활성화](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs)를 참조하세요.
**액세스 거부 정책 생성**
1. AWS Systems Manager 콘솔([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/))을 엽니다.
1. 탐색 창에서 **노드 액세스 관리**를 선택합니다.
1. **승인 정책** 탭에서 **액세스 거부 정책 생성**을 선택합니다.
1. **정책 문** 섹션에 액세스 거부 정책에 대한 정책 문을 입력합니다. 제공된 **샘플 문**을 사용하여 정책을 생성할 수 있습니다.
1. **액세스 거부 정책 생성**을 선택합니다.
# Amazon Q로 JIT(Just-in-Time) 노드 액세스에 대한 승인 정책 생성
명령줄용 Amazon Q Developer를 사용하면 소프트웨어 개발의 다양한 측면에서 지침과 지원이 제공됩니다. JIT(Just-in-Time) 노드 액세스에 대해 Amazon Q를 사용하면 정책 코드를 생성 및 업데이트하고, 정책 설명을 분석하는 등 승인 정책을 생성할 수 있습니다. 다음 정보는 명령줄용 Amazon Q를 사용하여 승인 정책을 생성하는 방법을 설명합니다.
## 사용 사례 식별
승인 정책 생성의 첫 번째 단계는 사용 사례를 명확하게 정의하는 것입니다. 예를 들어 조직에서 `Environment:Testing` 태그가 있는 노드에 대한 액세스 요청을 자동으로 승인할 수 있습니다. 직원 ID가 `TEMP`로 시작하는 경우 `Environment:Production` 태그가 있는 노드에 대한 자동 승인을 명시적으로 거부할 수도 있습니다. `Tier:Database` 태그가 있는 노드의 경우 두 가지 수준의 수동 승인이 필요할 수 있습니다.
주어진 시나리오에서 한 가지 정책이나 조건이 다른 것보다 우선할 수 있습니다. 따라서 사용 사례 및 선호도에 가장 적합한 문을 결정하려는 정책 동작을 명확하게 정의하는 것이 좋습니다.
## 개발 환경 설정
승인 정책을 개발하려는 명령줄용 Amazon Q를 설치합니다. 명령줄용 Amazon Q 설치에 대한 자세한 내용은 *Amazon Q Developer 사용 설명서*의 [명령줄용 Amazon Q 설치](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-installing.html)를 참조하세요.
또한 AWS 설명서를 위해 MCP 서버를 설치하는 것이 좋습니다. 이 MCP 서버는 명령줄용 Amazon Q를 최신 설명서 리소스에 연결합니다. 명령줄용 Amazon Q에서 MCP를 사용하는 방법에 대한 자세한 내용은 *Amazon Q Developer 사용 설명서*의 [Amazon Q Developer에서 MCP 사용](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-mcp.html)을 참조하세요.
AWS 설명서 MCP 서버에 대한 자세한 내용은 [AWS 설명서 MCP 서버](https://awslabs.github.io/mcp/servers/aws-documentation-mcp-server/)를 참조하세요.
아직 하지 않은 경우 AWS CLI을 설치하고 구성합니다. 자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
## 승인 정책 콘텐츠 개발
사용 사례가 식별되고 환경이 설정되면 정책 콘텐츠를 개발할 준비가 된 것입니다. 사용 사례 및 기본 설정에 따라 사용하는 승인 정책 및 문의 유형이 주로 결정됩니다.
특정 정책을 사용하는 방법을 잘 모르거나 정책의 스키마에 대해 자세히 알아보려면 [노드에 대한 승인 정책 생성](systems-manager-just-in-time-node-access-approval-policies.md) 및 후속 주제를 참조하세요. 이 주제에서는 정책 평가 방법을 자세히 설명하고 실제 예제 문을 제공합니다.
다음 절차에서는 명령줄용 Amazon Q를 사용하여 승인 정책을 생성하는 방법을 설명합니다.
**참고**
Amazon Q Developer는 생성형 AI를 사용합니다. 응답을 확인해야 할 수 있습니다. [AWS 책임 있는 AI 정책](https://aws.amazon.com/ai/responsible-ai/policy/)을 참조하세요.
**명령줄용 Amazon Q를 사용하여 승인 정책 생성**
1. 터미널을 열고 Amazon Q로 세션을 시작합니다.
```
$ q chat
```
1. 프롬프트를 입력하고 생성하려는 정책 문의 유형을 설명합니다. 예를 들어 앞서 승인 정책 시나리오를 사용하여 다음 프롬프트를 입력할 수 있습니다.
```
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. 이 예제 프롬프트를 입력하고 다음과 같은 출력이 발생했습니다.
```
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. 정책 문을 새 Cedar 파일에 붙여 넣어 구문을 검증합니다. [Cedar playground](https://www.cedarpolicy.com/en/playground)를 사용하여 문을 검증할 수도 있습니다.
1. 문을 검증한 후 Cedar 파일을 저장합니다.
1. 터미널에서 AWS CLI 명령을 실행하고 정책 콘텐츠를 사용하여 SSM 문서를 생성합니다. 프로덕션 환경에서 승인 정책을 사용하기 전에 AWS 계정 및 AWS 리전의 자격 증명 및 노드 하위 집합을 사용하여 승인 정책을 테스트합니다.
**참고**
자동 승인 정책의 경우 문서 이름은 `SSM-JustInTimeAccessAutoApprovalPolicy`여야 합니다. AWS 계정 및 AWS 리전당 1개의 자동 승인 정책만 있을 수 있습니다. 액세스 거부 정책의 경우 문서 이름은 `SSM-JustInTimeAccessDenyAccessOrgPolicy`여야 합니다. AWS Organizations 조직당 1개의 거부 액세스 정책만 있을 수 있으며, 정책은 Systems Manager의 위임된 관리자 계정에서 생성되어야 합니다. 수동 승인 정책의 명명 제약 조건은 다른 SSM 문서와 동일합니다. 자세한 내용은 [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"
```
------
# JIT(Just-in-Time) 노드 액세스 세션 기본 설정 업데이트
JIT(Just-in-Time) 노드 액세스를 사용하면 조직의 AWS 계정 및 AWS 리전 각각에서 일반 세션 및 로깅 기본 설정을 지정할 수 있습니다. 또는 CloudFormation StackSets를 사용하여 여러 계정 및 리전에서 세션 기본 설정 문서를 생성하면 일관적인 세션 기본 설정 유지에 도움이 됩니다. 세션 기본 설정 문서의 스키마에 대한 자세한 내용은 [Session 문서 스키마](session-manager-schema.md) 섹션을 참조하세요.
로깅을 위해 Amazon CloudWatch Logs에서 스트리밍 옵션을 사용하는 것이 좋습니다. 이 기능을 통해 세션 데이터 로그의 연속 스트림을 CloudWatch Logs로 보낼 수 있습니다. 사용자가 세션에서 실행한 명령, 명령을 실행한 사용자의 ID, 세션 데이터가 CloudWatch Logs로 스트리밍되는 시간에 대한 타임스탬프와 같은 필수 세부 정보는 세션 데이터를 스트리밍할 때 포함됩니다. 세션 데이터를 스트리밍할 때 로그는 JSON 형식이므로 기존 로깅 솔루션과 통합할 수 있습니다.
Systems Manager는 JIT(Just-in-Time) 노드 액세스 세션을 자동으로 종료하지 않습니다. 가장 좋은 방법은 *최대 세션 기간* 및 *유휴 세션 제한 시간* 설정 값을 지정하는 것입니다. 이러한 설정을 사용하면 사용자가 액세스 요청에서 승인된 기간보다 오래 노드에 연결된 상태를 유지할 수 없습니다. 다음 절차에서는 JIT(Just-in-Time) 노드 액세스의 세션 기본 설정을 업데이트하는 방법을 설명합니다.
**중요**
Just-in-Time 노드 액세스에서 Session Manager 암호화 및 RDP 기록에 사용되는 AWS KMS 키에 태그 키 `SystemsManagerJustInTimeNodeAccessManaged` 및 태그 값 `true`를 사용하여 태그를 지정해야 합니다.
KMS 키 태그 지정에 대한 자세한 내용은 *AWS Key Management Service 개발자 안내서*의 [Tags in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/tagging-keys.html)를 참조하세요.
**세션 기본 설정 업데이트**
1. AWS Systems Manager 콘솔([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/))을 엽니다.
1. 탐색 창에서 **설정**을 선택합니다.
1. **JIT(Just-in-Time) 노드 액세스** 탭을 선택합니다.
1. **세션 기본 설정** 섹션에서 **편집**을 선택합니다.
1. 필요에 따라 일반 및 로깅 기본 설정을 업데이트하고 **저장**을 선택합니다.
# JIT(Just-in-Time) 액세스 요청 알림 구성
사용자가 승인자 및 요청자에 대해 이메일 주소 또는 채팅 클라이언트에 대한 JIT(Just-in-Time) 노드 액세스 요청을 생성할 때 알림을 보내도록 Systems Manager를 구성할 수 있습니다. 알림에는 요청자가 제공한 액세스 요청 이유, AWS 계정, AWS 리전, 요청 상태 및 대상 노드의 ID가 포함됩니다. 현재 Systems Manager는 채팅 애플리케이션에서 Amazon Q Developer와의 통합을 통해 Slack 및 Microsoft Teams 클라이언트를 지원합니다. 채팅 클라이언트를 통한 알림을 사용하는 경우 액세스 요청 승인자는 액세스 요청과 직접 상호 작용할 수 있습니다. 이렇게 하면 콘솔에 로그인하여 액세스 요청에 대한 조치를 취할 필요가 없습니다.
**시작하기 전 준비 사항**
Just-in-Time 노드 액세스 알림을 위해 채팅 클라이언트를 구성하기 전에 다음 요구 사항에 유의하세요.
+ IAM 역할을 사용하여 계정의 사용자 자격 증명을 관리하는 경우 알림을 보낼 승인자 또는 요청자의 이메일 주소와 연결된 역할을 수동으로 연결해야 합니다. 연결하지 않으면 원하는 수신자에게 이메일로 알림을 보낼 수 없습니다.
다음 절차에서는 JIT(Just-in-Time) 노드 액세스 요청에 대한 알림을 구성하는 방법을 설명합니다.
**채팅 클라이언트에서 JIT(Just-in-Time) 노드 액세스 알림 구성**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **설정**을 선택합니다.
1. **JIT(Just-in-Time) 노드 액세스** 탭을 선택합니다.
1. **채팅** 섹션에서 **새 클라이언트 구성**을 선택합니다.
1. **클라이언트 유형 선택** 드롭다운에서 구성할 채팅 클라이언트 유형을 선택하고 **다음**을 선택합니다.
1. 채팅 애플리케이션에서 Amazon Q Developer의 채팅 클라이언트 액세스 허용을 요청하는 메시지가 표시됩니다. **허용**을 선택합니다.
1. **채널 구성** 섹션에서 채팅 클라이언트 채널에 대한 정보를 입력하고 수신하려는 알림 유형을 선택합니다.
1. Slack 알림을 구성하는 경우 알림이 구성되는 모든 Slack 채널에 '@Amazon Q'를 초대합니다.
1. **채널 구성**을 선택합니다.
**참고**
Slack 채널에서 직접 액세스 요청을 승인 또는 거부하려면 Slack 채널로 구성된 IAM 역할에 `ssm:SendAutomationSignal` 권한이 있고 챗봇을 포함하는 신뢰 정책이 있는지 확인합니다.
```
{
"Effect": "Allow",
"Principal": {
"Service": "chatbot.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
```
**이메일 알림에서 JIT(Just-in-Time) 노드 액세스 알림 구성**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **설정**을 선택합니다.
1. **JIT(Just-in-Time) 노드 액세스** 탭을 선택합니다.
1. **이메일** 섹션에서 **편집**을 선택합니다.
1. **이메일 추가**를 선택하고 이메일 주소와 수동으로 연결할 **IAM 역할**을 선택합니다.
1. **이메일 주소** 필드에 이메일 주소를 입력합니다. 지정한 IAM 역할로부터의 승인이 필요한 액세스 요청이 생성될 때마다 해당 역할과 연결된 이메일 주소로 알림이 전송됩니다.
1. **이메일 주소 추가**를 선택합니다.
# RDP 연결 기록
JIT(Just-in-Time) 노드 액세스에는 Windows Server 노드에 대한 RDP 연결을 기록하는 기능이 포함됩니다. RDP 연결을 기록하려면 S3 버킷과 AWS Key Management Service (AWS KMS) 고객 관리형 키가 필요합니다. AWS KMS key는 Systems Manager 리소스에서 생성 및 저장되는 동안 기록 데이터를 일시적으로 암호화하는 데 사용됩니다. 고객 관리형 키는 키 사용이 암호화 및 복호화인 대칭 키여야 합니다. 조직에서 다중 리전 키를 사용하거나 JIT(Just-in-Time) 노드 액세스를 활성화한 각 리전에서 고객 관리형 키를 생성해야 합니다.
기록을 저장하는 S3 버킷에서 KMS 암호화를 활성화한 경우 `ssm-guiconnect` 서비스 위탁자에게 버킷 암호화에 사용되는 고객 관리형 키에 대한 액세스를 제공해야 합니다. 이 고객 관리형 키는 기록 설정에서 지정한 것과 다를 수 있으며, 여기에는 연결을 설정하는 데 필요한 `kms:CreateGrant` 권한이 포함되어야 합니다.
## RDP 기록에 대한 S3 버킷 암호화 구성
연결 기록은 RDP 기록을 활성화할 때 지정한 S3 버킷에 저장됩니다.
KMS 키를 S3 버킷(SSE-KMS)의 기본 암호화 메커니즘으로 사용하는 경우 `ssm-guiconnect` 서비스 위탁자가 키에 대한 `kms:GenerateDataKey` 작업에 액세스할 수 있도록 허용해야 합니다. S3 버킷에서 SSE-KMS 암호화를 사용할 때는 고객 관리형 키를 사용하는 것이 좋습니다. 고객 관리형 키에 연결된 키 정책을 업데이트할 수 있기 때문입니다. AWS 관리형 키에 대한 키 정책은 업데이트할 수 없습니다.
**중요**
Just-in-Time 노드 액세스에서 Session Manager 암호화 및 RDP 기록에 사용되는 AWS KMS 키에 태그 키 `SystemsManagerJustInTimeNodeAccessManaged` 및 태그 값 `true`를 사용하여 태그를 지정해야 합니다.
KMS 키 태그 지정에 대한 자세한 내용은 *AWS Key Management Service 개발자 안내서*의 [Tags in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/tagging-keys.html)를 참조하세요.
다음과 같은 고객 관리형 키 정책을 사용하여 S3 스토리지용 KMS 키에 대한 `ssm-guiconnect` 서비스 액세스를 허용합니다. 고객 관리형 키의 업데이트에 대한 자세한 내용은 *AWS Key Management Service 개발자 안내서*의 [Change a key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)를 참조하세요.
각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
+ *account-id*는 연결을 시작하는 AWS 계정의 ID를 나타냅니다.
+ *region*은 S3 버킷이 있는 AWS 리전을 나타냅니다. (버킷이 여러 리전에서 기록을 수신하는 경우 `*`를 사용할 수 있습니다. 예: `s3.*.amazonaws.com`.)
**참고**
계정이 AWS Organizations의 조직에 속하는 경우 `aws:SourceAccount` 대신 정책에서 `aws:SourceOrgID`를 사용할 수 있습니다.
```
{
"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"
}
}
}
```
## RDP 연결 기록을 위한 IAM 권한 구성
JIT(Just-in-Time) 노드 액세스에 필요한 IAM 권한 외에도 사용하는 사용자 또는 역할에 수행해야 하는 작업에 따라 다음 권한이 허용되어야 합니다.
**연결 기록 구성을 위한 권한**
RDP 연결 기록을 구성하려면 다음 권한이 필요합니다.
+ `ssm-guiconnect:UpdateConnectionRecordingPreferences`
+ `ssm-guiconnect:GetConnectionRecordingPreferences`
+ `ssm-guiconnect:DeleteConnectionRecordingPreferences`
+ `kms:CreateGrant`
**연결을 시작하기 위한 권한**
JIT(Just-in-Time) 노드 액세스 권한이 있는 RDP 연결을 만들려면 다음 권한이 필요합니다.
+ `ssm-guiconnect:CancelConnection`
+ `ssm-guiconnect:GetConnection`
+ `ssm-guiconnect:StartConnection`
+ `kms:CreateGrant`
**시작하기 전 준비 사항**
연결 기록을 저장하려면 먼저 S3 버킷을 생성하고 다음 버킷 정책을 추가해야 합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
(버킷 정책 추가에 대한 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [Amazon S3 콘솔을 사용하여 버킷 정책 추가](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html)를 참조하세요.)
------
#### [ 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"
}
}
}
]
}
```
------
## RDP 연결 기록 활성화 및 구성
다음 절차에서는 RDP 연결 기록을 활성화하고 구성하는 방법을 설명합니다.
**RDP 연결 기록을 활성화 및 구성하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **설정**을 선택합니다.
1. **JIT(Just-in-Time) 노드 액세스** 탭을 선택합니다.
1. **RDP 기록** 섹션에서 **RDP 기록 활성화**를 선택합니다.
1. 세션 기록을 업로드할 S3 버킷을 선택합니다.
1. Systems Manager 리소스에서 생성 및 저장되는 동안 기록 데이터를 일시적으로 암호화하는 데 사용할 고객 관리형 키를 선택합니다. (이는 버킷을 암호화하는 데 사용하는 것과 다른 고객 관리형 키일 수 있습니다.)
1. **저장**을 선택합니다.
## RDP 연결 기록 상태 값
RPD 연결 기록에 유효한 상태 값은 다음과 같습니다.
+ `Recording` - 연결이 기록되는 중입니다.
+ `Processing` - 연결이 종료된 후 비디오가 처리되고 있습니다.
+ `Finished` - 성공적인 터미널 상태: 연결 기록 비디오가 성공적으로 처리되어 지정된 버킷에 업로드되었습니다.
+ `Failed` - 실패한 터미널 상태입니다. 연결이 성공적으로 기록되지 않았습니다.
+ `ProcessingError` - 비디오 처리 중에 하나 이상의 중간 장애/오류가 발생했습니다. 잠재적 원인에는 기록 저장을 위해 지정된 S3 버킷에 대한 잘못된 구성으로 인한 서비스 종속성 실패 또는 권한 누락이 포함됩니다. 기록이 이 상태일 때 서비스는 계속 처리를 시도합니다.
**참고**
`ProcessingError`는 연결이 설정된 후 S3 버킷에 객체를 업로드할 권한이 `ssm-guiconnect` 서비스 위탁자에게 없기 때문일 수 있습니다. 또 다른 잠재적 원인은 S3 버킷 암호화에 사용되는 KMS 키에 대한 KMS 권한이 누락되는 것입니다.
# 대상 수정
JIT(Just-in-Time) 노드 액세스를 설정할 때 JIT(Just-in-Time) 노드 액세스를 설정할 *대상*을 선택합니다. 대상은 AWS Organizations 조직 단위(OU)와 AWS 리전으로 구성됩니다. 기본적으로 통합 Systems Manager 콘솔을 설정할 때 선택한 것과 동일한 대상이 JIT(Just-in-Time) 노드 액세스 대상으로 선택됩니다. 통합 Systems Manager 콘솔을 설정할 때 모든 동일한 대상에 또는 지정한 대상의 하위 집합에 JIT(Just-in-Time) 노드 액세스를 설정할 수 있습니다. 통합 Systems Manager 콘솔 설정 시 선택되지 않은 새 대상을 추가하는 것은 지원되지 않습니다. JIT(Just-in-Time) 노드 액세스를 설정한 후 선택한 대상을 변경할 수 있습니다.
다음 절차에서는 JIT(Just-in-Time) 노드 액세스 대상을 수정하는 방법을 설명합니다.
**대상 수정**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **설정**을 선택합니다.
1. **JIT(Just-in-Time) 노드 액세스** 탭을 선택합니다.
1. **대상** 섹션에서 **편집**을 선택합니다.
1. JIT(Just-in-Time) 노드 액세스를 사용하려는 **조직 단위** 및 **리전**을 선택합니다.
1. **저장**을 선택합니다.
# 자격 증명 공급자 변경
기본적으로 JIT(Just-in-Time) 노드 액세스는 자격 증명 공급자에 IAM을 사용합니다. JIT(Just-in-Time) 노드 액세스를 활성화한 후 조직에서 통합 콘솔을 사용하는 고객은 IAM Identity Center를 사용하도록 이 설정을 수정할 수 있습니다. JIT(Just-in-Time) 노드 액세스는 단일 계정 및 리전에 대해 설정할 때 IAM Identity Center를 자격 증명 공급자로 지원하지 않습니다.
다음 절차에서는 JIT(Just-in-Time) 노드 액세스에 대한 자격 증명 공급자를 수정하는 방법을 설명합니다.
**자격 증명 공급자 수정**
1. AWS Systems Manager 콘솔([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/))을 엽니다.
1. 탐색 창에서 **설정**을 선택합니다.
1. **JIT(Just-in-Time) 노드 액세스** 탭을 선택합니다.
1. **사용자 자격 증명** 섹션에서 **편집**을 선택합니다.
1. **AWS IAM Identity Center**를 선택합니다.
1. **저장**을 선택합니다.
# JIT(Just-in-Time) 노드 액세스 세션 시작
JIT(Just-in-Time) 노드 액세스를 활성화 및 설정하고 세션 및 알림 기본 설정을 구성하면 사용자는 JIT(Just-in-Time) 노드 액세스 세션을 시작할 준비가 됩니다. Systems Manager 콘솔에서 또는 Session Manager 플러그인을 사용하여 AWS Command Line Interface에서 JIT(Just-in-Time) 노드 액세스를 사용하는 세션을 시작할 수 있습니다. 동일한 계정 및 리전의 노드에서 JIT(Just-in-Time) 노드 액세스 세션을 시작할 수 있습니다. 다음 절차에서는 JIT(Just-in-Time) 노드 액세스로 세션을 시작하는 방법을 설명합니다.
**참고**
사용자가 이전에 Session Manager를 사용하여 노드에 연결한 경우 IAM 정책에서 Session Manager 권한(예: `ssm:StartSession`)을 제거하여 JIT(Just-in-Time) 노드 액세스를 사용하는 세션을 시작해야 합니다. 그렇지 않은 경우 노드에 연결할 때 Session Manager를 계속 사용합니다.
**콘솔을 사용하여 JIT(Just-in-Time) 노드 액세스로 세션 시작**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **노드 탐색**을 선택합니다.
1. 연결하려는 노드를 선택합니다.
1. **작업** 드롭다운에서 **연결**을 선택합니다.
조직의 승인 정책에서 자동 노드 연결을 허용하지 않는 경우 액세스 요청을 제출하라는 메시지가 표시됩니다. 요청된 정보를 작성하고 액세스 요청을 제출하면 필요한 승인을 모두 받는 대로 노드에 대한 세션을 시작할 수 있습니다.
**AWS CLI를 사용하여 JIT(Just-in-Time) 노드 액세스로 세션 시작**
1. 다음 명령을 실행하면서 *자리표시자 값*을 자신의 정보로 바꿔 액세스 요청 워크플로를 시작합니다.
```
aws ssm start-access-request \
--targets Key=InstanceIds,Values=i-02573cafcfEXAMPLE
--reason "Troubleshooting networking performance issue"
```
조직의 승인 정책에 따라 노드에 자동으로 연결되거나 수동 승인 프로세스가 시작됩니다. 수동 승인이 필요한 요청의 경우 응답에 반환된 액세스 요청의 ID를 기록해 둡니다.
1. 필요한 모든 승인이 제공될 때까지 대기합니다.
1. 필요한 승인이 모두 제공된 후에는 다음 명령을 실행하여 임시 자격 증명이 포함된 액세스 토큰을 가져옵니다. *자리 표시자*를 자신의 정보로 바꿉니다.
```
aws ssm get-access-token \
--access-request-id oi-12345abcdef
```
응답에 반환된 액세스 토큰을 기록해 둡니다.
1. 다음 명령을 실행하면서 *자리표시자 값*을 자신의 정보로 바꿔 AWS CLI에서 임시 자격 증명을 사용합니다.
```
export AWS_SESSION_TOKEN=AQoDYXdzEJr...
```
1. 다음 명령을 실행하면서 *자리표시자 값*을 자신의 정보로 바꿔 노드에 대한 세션을 시작합니다.
```
aws ssm start-session \
--target i-02573cafcfEXAMPLE
```
# JIT(Just-in-Time) 액세스 요청 관리
조직 전반에서의 가시성을 높이기 위해 Systems Manager는 조직의 위임된 관리자 계정으로 액세스 요청을 복제합니다. 규정 준수 요구 사항 충족에 도움이 되도록 Systems Manager는 모든 액세스 요청을 1년 동안 유지합니다. 다음 주제에서는 JIT(Just-in-Time) 노드 액세스 요청을 관리하는 방법을 설명합니다. 이 정보는 액세스 요청 승인자를 대상으로 합니다. 시작하기 전에 IAM 정책을 검토하고 JIT(Just-in-Time) 노드 액세스를 관리하는 데 필요한 권한이 있는지 확인하는 것이 좋습니다. 자세한 내용은 [Systems Manager로 JIT(Just-in-Time) 액세스 설정](systems-manager-just-in-time-node-access-setting-up.md) 단원을 참조하십시오.
**Topics**
+ [JIT(Just-in-Time) 노드 액세스 요청 승인 및 거부](systems-manager-just-in-time-node-access-approve-deny-requests.md)
# JIT(Just-in-Time) 노드 액세스 요청 승인 및 거부
액세스 요청 승인자는 통합 Systems Manager 콘솔에서 또는 선호하는 명령줄 도구를 사용하여 JIT(Just-in-Time) 노드 액세스 요청을 승인 또는 거부할 수 있습니다. 이 정보는 액세스 요청 승인자를 대상으로 합니다. 액세스 요청을 승인 또는 거부하는 데 필요한 권한이 없는 경우 관리자에게 문의합니다. 다음 절차에서는 JIT(Just-in-Time) 노드 액세스 요청을 승인 또는 거부하는 방법을 설명합니다.
**콘솔을 사용하여 JIT(Just-in-Time) 노드 액세스 요청 승인 또는 거부**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **노드 액세스 관리**를 선택합니다.
1. **액세스 요청** 탭을 선택합니다.
1. **나에 대한 요청** 토글을 선택합니다.
1. 승인 또는 거부하려는 액세스 요청 옆의 확인란을 선택합니다.
1. **승인** 또는 **거부**를 선택합니다.
액세스 요청을 승인한 후 **취소**를 선택하여 언제든 승인을 취소할 수 있습니다.
**명령줄을 사용하여 JIT(Just-in-Time) 노드 액세스 요청 승인 또는 거부**
1. 알림의 액세스 요청 ID를 기록해 둡니다. 예: *oi-12345abcdef*.
1. 다음 명령을 실행하면서 *자리표시자 값*을 자신의 정보로 바꾸면 액세스 요청 승인 워크플로에 대한 세부 정보가 반환됩니다.
```
aws ssm get-ops-item \
--ops-item-id oi-12345abcdef
```
`OperationalData`의 `/aws/accessrequest` 필드에 `automationExecutionId` 값을 기록해 둡니다. 예: *9231944f-61c6-40be-8bce-8ee2bEXAMPLE*.
1. 다음 명령을 실행하여 액세스 요청을 승인 또는 거부합니다. `Approve` 신호 유형을 사용하여 요청을 승인하고 `Deny`를 사용하여 요청을 거부합니다. *자리표시자 값*을 자신의 정보로 바꿔야 합니다.
```
aws ssm send-automation-signal \
--automation-execution-id 9231944f-61c6-40be-8bce-8ee2bEXAMPLE \
--signal-type "Approve"
```
# Session Manager에서 JIT(Just-in-Time) 노드 액세스로 이동
JIT(Just-in-Time) 노드 액세스를 활성화하면 Systems Manager는 Session Manager에 대한 기존 리소스를 변경하지 않습니다. 이를 통해 기존 환경이 중단되지 않고 사용자는 승인 정책을 생성 및 검증하는 동안 계속해서 세션을 시작할 수 있습니다. 승인 정책을 테스트할 준비가 되면 기존 IAM 정책을 수정하여 JIT(Just-in-Time) 노드 액세스로의 전환을 완료해야 합니다. 여기에는 자격 증명에 JIT(Just-in-Time) 노드 액세스에 필요한 권한을 추가하고, Session Manager에 대한 `StartSession` API 작업의 권한을 제거하는 것이 포함됩니다. AWS 계정 및 AWS 리전의 자격 증명 및 노드 하위 집합을 사용하여 승인 정책을 테스트하는 것이 좋습니다.
JIT(Just-in-Time) 노드 액세스에 필요한 권한에 대한 자세한 내용은 [Systems Manager로 JIT(Just-in-Time) 액세스 설정](systems-manager-just-in-time-node-access-setting-up.md) 섹션을 참조하세요.
자격 증명의 IAM 권한 수정에 대한 자세한 내용은 *IAM 사용 설명서*의 [IAM 자격 증명 권한 추가 및 제거](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)를 참조하세요.
다음은 Session Manager에서 JIT(Just-in-Time) 노드 액세스로 이동하는 방법을 자세히 설명합니다.
Session Manager에서 JIT(Just-in-Time) 노드 액세스로 이동하려면 작업을 중단하지 않고 원활하게 전환할 수 있도록 신중한 계획과 테스트가 필요합니다. 다음 섹션에서는 이 프로세스를 완료하는 방법을 설명합니다.
## 사전 조건
시작하기 전에 다음 작업을 완료해야 합니다.
+ Systems Manager 통합 콘솔을 설정합니다.
+ 계정에서 IAM 정책을 수정할 권한이 있는지 확인했습니다.
+ 현재 Session Manager 권한을 부여하는 모든 IAM 정책 및 역할을 식별했습니다.
+ 세션 기본 설정 및 로깅 설정을 포함하여 현재 Session Manager 구성을 문서화했습니다.
## 평가
다음 작업을 완료하여 현재 환경을 평가하고 원하는 승인 동작의 개요를 작성합니다.
1. **노드 인벤토리 작성** - 사용자가 Session Manager을 통해 현재 액세스하는 모든 노드를 식별합니다.
1. **사용자 액세스 패턴 식별** - 어떤 사용자 또는 역할이 어떤 상황에서 어떤 노드에 액세스해야 하는지 문서화합니다.
1. **맵 승인 워크플로** - 다양한 유형의 노드에 대해 누가 액세스 요청을 승인해야 하는지 결정합니다.
1. **태그 지정 전략 검토** - 계획된 승인 정책을 지원하도록 노드에 적절한 태그가 지정되어야 합니다.
1. **기존 IAM 정책 감사** - Session Manager 권한이 포함된 모든 정책을 식별합니다.
## 계획
### 단계별 전략
Session Manager에서 JIT(Just-in-Time) 노드 액세스로 이동할 때 다음과 같은 단계별 접근 방식을 사용하는 것이 좋습니다.
1. **1단계: 설정 및 구성** - 기존 Session Manager 권한을 수정하지 않고 JIT(Just-in-Time) 노드 액세스를 활성화합니다.
1. **2단계: 정책 개발** - 노드에 대한 승인 정책을 생성 및 테스트합니다.
1. **3단계: 파일럿 마이그레이션** - 중요하지 않은 노드와 사용자 또는 역할로 이루어진 소규모 그룹을 Session Manager에서 JIT(Just-in-Time) 노드 액세스로 수정합니다.
1. **4단계: 전체 마이그레이션** - 나머지 모든 노드와 사용자 또는 역할을 점진적으로 마이그레이션합니다.
### 타임라인 고려 사항
Session Manager에서 JIT(Just-in-Time) 노드 액세스로 이동할 타임라인을 생성할 때 다음 요소를 고려합니다.
+ 사용자 교육 및 새로운 승인 워크플로에 적응할 시간을 확보하세요.
+ 운영 활동이 적은 기간 동안 마이그레이션을 예약하세요.
+ 문제 해결 및 조정을 위한 여유 시간을 포함하세요.
+ 두 시스템을 모두 사용할 수 있는 병렬 운영 기간을 계획하세요.
## 구현 단계
### 1단계: 설정 및 구성
1. Systems Manager 콘솔에서 JIT(Just-in-Time) 노드 액세스를 활성화합니다. 자세한 단계는 [Systems Manager로 JIT(Just-in-Time) 액세스 설정](systems-manager-just-in-time-node-access-setting-up.md) 섹션을 참조하세요.
1. 현재 Session Manager 설정과 일치하도록 JIT(Just-in-Time) 노드 액세스에 대한 세션 기본 설정을 구성합니다. 자세한 내용은 [JIT(Just-in-Time) 노드 액세스 세션 기본 설정 업데이트](systems-manager-just-in-time-node-access-session-preferences.md) 섹션을 참조하세요.
1. 액세스 요청에 대한 알림 기본 설정을 지정합니다. 자세한 내용은 [JIT(Just-in-Time) 액세스 요청 알림 구성](systems-manager-just-in-time-node-access-notifications.md) 섹션을 참조하세요.
1. Windows Server 노드에 RDP 연결을 사용하는 경우 RDP 기록을 구성합니다. 자세한 내용은 [RDP 연결 기록](systems-manager-just-in-time-node-access-rdp-recording.md) 섹션을 참조하세요.
### 2단계: 정책 개발
1. JIT(Just-in-Time) 노드 액세스 관리자 및 사용자에 대한 IAM 정책을 생성합니다.
1. 보안 요구 사항 및 사용 사례에 따라 승인 정책을 개발합니다.
1. 비프로덕션 환경에서 정책을 테스트하고 예상한 대로 작동하는지 확인합니다.
### 3단계: 파일럿 마이그레이션
1. 파일럿 용도로 소규모 사용자 그룹과 중요하지 않은 노드를 선택합니다.
1. JIT(Just-in-Time) 노드 액세스 권한이 포함된 파일럿 사용자에 대한 새 IAM 정책을 생성합니다.
1. 파일럿 사용자의 IAM 정책에서 Session Manager 권한(`ssm:StartSession`)을 제거합니다.
1. 파일럿 사용자를 대상으로 새로운 액세스 요청 워크플로를 교육합니다.
1. 파일럿에 문제가 있는지 모니터링하고 피드백을 수집합니다.
1. 파일럿 결과에 따라 정책 및 절차를 조정합니다.
**파일럿 사용자를 위한 IAM 정책 수정 예제**
Session Manager 권한이 있는 기존 정책:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:ResumeSession",
"ssm:TerminateSession"
],
"Resource": "*"
}
]
}
```
------
JIT(Just-in-Time) 노드 액세스에 대해 수정된 정책:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartAccessRequest",
"ssm:GetAccessToken",
"ssm:ResumeSession",
"ssm:TerminateSession"
],
"Resource": "*"
}
]
}
```
------
### 4단계: 전체 마이그레이션
나머지 사용자와 노드를 일괄적으로 마이그레이션할 일정을 수립합니다.
## 테스트 방법론
마이그레이션 프로세스 전반에 걸쳐 다음 테스트를 실시합니다.
+ **정책 검증** - 승인 정책이 원하는 노드 및 사용자를 대상으로 올바르게 적용되는지 확인합니다.
+ **액세스 요청 워크플로** - 자동 승인 및 수동 승인 시나리오 모두에 대해 액세스 요청부터 세션 설정까지의 전체 워크플로를 테스트합니다.
+ **알림** - 승인자가 구성된 채널(이메일, Slack, Microsoft Teams)을 통해 알림을 받는지 확인합니다.
+ **로깅 및 모니터링** - 세션 로그 및 액세스 요청이 올바르게 캡처 및 저장되었는지 확인합니다.
## 성공적인 마이그레이션 모범 사례
+ **처음부터 자주 커뮤니케이션** - 마이그레이션 타임라인과 JIT(Just-in-Time) 노드 액세스의 이점에 대해 사용자에게 알립니다.
+ **중요하지 않은 시스템으로 시작** - 프로덕션으로 이동하기 전에 개발 또는 테스트 환경으로 마이그레이션을 시작합니다.
+ **모든 사항 문서화** - 승인 정책, IAM 정책 변경 사항 및 구성 설정과 관련된 세부 기록을 유지 관리합니다.
+ **모니터링 및 조정** - 액세스 요청 및 승인 워크플로를 지속적으로 모니터링하고 필요에 따라 정책을 조정합니다.
+ **거버넌스 설정** - 환경 변경 시 승인 정책을 정기적으로 검토 및 업데이트하는 프로세스를 생성합니다.
# Systems Manager로 JIT(Just-in-Time) 액세스 비활성화
다음 절차에서는 JIT(Just-in-Time) 노드 액세스를 비활성화하는 방법을 설명합니다. JIT(Just-in-Time) 노드 액세스를 비활성화한 후 다른 연결 방법을 이미 구현하지 않는 한 조직의 사용자가 노드에 연결하지 못할 수 있습니다.
**JIT(Just-in-Time) 노드 액세스 비활성화**
1. 조직의 Systems Manager 위임된 관리자 계정에 로그인합니다.
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **설정**을 선택합니다.
1. **JIT(Just-in-Time) 노드 액세스** 탭에서 **비활성화**를 선택합니다.
# JIT(Just-in-Time) 노드 액세스 자주 묻는 질문
## Session Manager에서 JIT(Just-in-Time) 노드 액세스로 이동하려면 어떻게 해야 하나요?
통합 콘솔을 설정하고 JIT(Just-in-Time) 노드 액세스를 활성화한 후에는 기존 IAM 정책을 수정하여 JIT(Just-in-Time) 노드 액세스로의 이동을 완료해야 합니다. 여기에는 JIT(Just-in-Time) 노드 액세스에 필요한 권한을 추가하고, Session Manager에 대한 `StartSession` API 작업의 권한을 제거하는 것이 포함됩니다. JIT(Just-in-Time)에 대한 IAM 정책에 대한 자세한 내용은 [Systems Manager로 JIT(Just-in-Time) 액세스 설정](systems-manager-just-in-time-node-access-setting-up.md) 섹션을 참조하세요.
## JIT(Just-in-Time) 노드 액세스를 사용하려면 통합 콘솔을 설정해야 하나요?
예, 통합 콘솔 설정을 JIT(Just-in-Time) 노드 액세스의 사전 조건입니다. 하지만 통합 콘솔을 설정하고 JIT(Just-in-Time) 노드 액세스를 활성화한 후에는 몇 가지 방법으로 노드에 연결할 수 있습니다. 예를 들어 Amazon EC2 콘솔 및 AWS CLI에서 JIT(Just-in-Time) 노드 액세스 세션을 시작할 수 있습니다. 통합 콘솔 설정에 대한 자세한 내용은 [조직을 위한 Systems Manager 통합 콘솔 설정](systems-manager-setting-up-organizations.md) 섹션을 참조하세요.
## JIT(Just-in-Time) 노드 액세스와 관련된 비용이 있나요?
Systems Manager는 JIT(Just-in-Time) 노드 액세스에 30일 무료 평가판을 제공합니다. 평가판 종료 후에는 JIT(Just-in-Time) 노드 액세스에 비용이 발생합니다. 자세한 내용은 [AWS Systems Manager요금](https://aws.amazon.com/systems-manager/pricing/)을 참조하세요.
## JIT(Just-in-Time) 노드 액세스 승인 정책의 우선순위는 무엇인가요?
승인 정책은 다음 순서로 평가됩니다.
1. 액세스 거부
1. 자동 승인
1. 수동
## 수동 승인 정책은 어떻게 평가되나요?
JIT(Just-in-Time) 노드 액세스는 항상 노드에 대한 더 구체적인 정책을 우선합니다. 수동 승인 정책은 다음 순서로 평가됩니다.
1. 태그별 대상
1. 모든 노드 대상
## 노드에 적용되는 승인 정책이 없는 경우 어떻게 되나요?
JIT(Just-in-Time) 노드 액세스를 사용하여 노드에 연결하려면 노드에 승인 정책을 적용해야 합니다. 노드에 적용되는 승인 정책이 없는 경우 사용자는 노드에 대한 액세스를 요청할 수 없습니다.
## 여러 승인 정책에서 태그를 대상으로 지정할 수 있나요?
태그는 승인 정책에서 한 번만 대상으로 지정될 수 있습니다.
## 태그 중첩으로 인해 노드에 여러 수동 승인 정책이 적용되는 경우 어떻게 되나요?
노드에 여러 개의 수동 승인 정책이 적용되면 충돌이 발생하여 사용자가 노드 액세스를 요청할 수 없습니다. 일부 인스턴스에는 여러 개의 태그가 있을 수 있으므로 수동 승인 정책을 생성할 때 이 점에 유의해야 합니다.
## JIT(Just-in-Time) 노드 액세스를 사용하여 계정 및 리전의 노드에서 액세스를 요청하고 세션을 시작할 수 있나요?
JIT(Just-in-Time) 노드 액세스는 요청자와 동일한 계정 및 리전의 노드에 대한 액세스 요청 및 세션 시작을 지원합니다.
## JIT(Just-in-Time) 노드 액세스를 사용하여 하이브리드 활성화에 등록된 노드에서 액세스를 요청하고 세션을 시작할 수 있나요?
예, JIT(Just-in-Time) 노드 액세스는 하이브리드 활성화로 등록된 노드에 대한 액세스 요청 및 세션 시작을 지원합니다. 노드는 요청자와 동일한 계정 및 리전에 등록되어야 합니다.