

• AWS Systems Manager CloudWatch 대시보드는 2026년 4월 30일 이후에는 더 이상 사용할 수 없습니다. 고객은 Amazon CloudWatch 콘솔을 계속 사용하여 현재와 마찬가지로 Amazon CloudWatch 대시보드를 보고, 생성하고, 관리할 수 있습니다. 자세한 내용은 [Amazon CloudWatch 대시보드 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)를 참조하세요.

# Session Manager에서 JIT(Just-in-Time) 노드 액세스로 이동
<a name="systems-manager-just-in-time-node-access-moving-from-session-manager"></a>

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) 노드 액세스로 이동하려면 작업을 중단하지 않고 원활하게 전환할 수 있도록 신중한 계획과 테스트가 필요합니다. 다음 섹션에서는 이 프로세스를 완료하는 방법을 설명합니다.

## 사전 조건
<a name="migration-prerequisites"></a>

시작하기 전에 다음 작업을 완료해야 합니다.
+ Systems Manager 통합 콘솔을 설정합니다.
+ 계정에서 IAM 정책을 수정할 권한이 있는지 확인했습니다.
+ 현재 Session Manager 권한을 부여하는 모든 IAM 정책 및 역할을 식별했습니다.
+ 세션 기본 설정 및 로깅 설정을 포함하여 현재 Session Manager 구성을 문서화했습니다.

## 평가
<a name="environment-assessment"></a>

다음 작업을 완료하여 현재 환경을 평가하고 원하는 승인 동작의 개요를 작성합니다.

1. **노드 인벤토리 작성** - 사용자가 Session Manager을 통해 현재 액세스하는 모든 노드를 식별합니다.

1. **사용자 액세스 패턴 식별** - 어떤 사용자 또는 역할이 어떤 상황에서 어떤 노드에 액세스해야 하는지 문서화합니다.

1. **맵 승인 워크플로** - 다양한 유형의 노드에 대해 누가 액세스 요청을 승인해야 하는지 결정합니다.

1. **태그 지정 전략 검토** - 계획된 승인 정책을 지원하도록 노드에 적절한 태그가 지정되어야 합니다.

1. **기존 IAM 정책 감사** - Session Manager 권한이 포함된 모든 정책을 식별합니다.

## 계획
<a name="migration-planning"></a>

### 단계별 전략
<a name="migration-planning-strategy"></a>

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단계: 전체 마이그레이션** - 나머지 모든 노드와 사용자 또는 역할을 점진적으로 마이그레이션합니다.

### 타임라인 고려 사항
<a name="migration-planning-timeline"></a>

Session Manager에서 JIT(Just-in-Time) 노드 액세스로 이동할 타임라인을 생성할 때 다음 요소를 고려합니다.
+ 사용자 교육 및 새로운 승인 워크플로에 적응할 시간을 확보하세요.
+ 운영 활동이 적은 기간 동안 마이그레이션을 예약하세요.
+ 문제 해결 및 조정을 위한 여유 시간을 포함하세요.
+ 두 시스템을 모두 사용할 수 있는 병렬 운영 기간을 계획하세요.

## 구현 단계
<a name="migration-implementation"></a>

### 1단계: 설정 및 구성
<a name="migration-implementation-phase1"></a>

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단계: 정책 개발
<a name="migration-implementation-phase2"></a>

1. JIT(Just-in-Time) 노드 액세스 관리자 및 사용자에 대한 IAM 정책을 생성합니다.

1. 보안 요구 사항 및 사용 사례에 따라 승인 정책을 개발합니다.

1. 비프로덕션 환경에서 정책을 테스트하고 예상한 대로 작동하는지 확인합니다.

### 3단계: 파일럿 마이그레이션
<a name="migration-implementation-phase3"></a>

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단계: 전체 마이그레이션
<a name="migration-implementation-phase4"></a>

나머지 사용자와 노드를 일괄적으로 마이그레이션할 일정을 수립합니다.

## 테스트 방법론
<a name="migration-testing"></a>

마이그레이션 프로세스 전반에 걸쳐 다음 테스트를 실시합니다.
+ **정책 검증** - 승인 정책이 원하는 노드 및 사용자를 대상으로 올바르게 적용되는지 확인합니다.
+ **액세스 요청 워크플로** - 자동 승인 및 수동 승인 시나리오 모두에 대해 액세스 요청부터 세션 설정까지의 전체 워크플로를 테스트합니다.
+ **알림** - 승인자가 구성된 채널(이메일, Slack, Microsoft Teams)을 통해 알림을 받는지 확인합니다.
+ **로깅 및 모니터링** - 세션 로그 및 액세스 요청이 올바르게 캡처 및 저장되었는지 확인합니다.

## 성공적인 마이그레이션 모범 사례
<a name="migration-best-practices"></a>
+ **처음부터 자주 커뮤니케이션** - 마이그레이션 타임라인과 JIT(Just-in-Time) 노드 액세스의 이점에 대해 사용자에게 알립니다.
+ **중요하지 않은 시스템으로 시작** - 프로덕션으로 이동하기 전에 개발 또는 테스트 환경으로 마이그레이션을 시작합니다.
+ **모든 사항 문서화** - 승인 정책, IAM 정책 변경 사항 및 구성 설정과 관련된 세부 기록을 유지 관리합니다.
+ **모니터링 및 조정** - 액세스 요청 및 승인 워크플로를 지속적으로 모니터링하고 필요에 따라 정책을 조정합니다.
+ **거버넌스 설정** - 환경 변경 시 승인 정책을 정기적으로 검토 및 업데이트하는 프로세스를 생성합니다.