개인 WordPress 블로그를 운영하면서 SSH를 계속 열어 둘 필요가 있는지 다시 검토했습니다. 접속 주체가 한 명이고 서버가 AWS EC2에 있으므로, 보안 그룹의 22번 포트를 제거하고 AWS Systems Manager Session Manager로 운영 접근을 전환했습니다. 이 글은 단순히 접속 명령을 바꾼 것이 아니라 IAM, 보안 그룹, 파일 권한, 운영 절차를 함께 정리한 기록입니다.
기존 SSH 방식에서 신경 써야 했던 것
- 22번 포트의 소스 IP 범위 관리
- 개인 키 파일 보관과 교체
- 접속용 로컬 네트워크가 바뀔 때 보안 그룹 수정
- 장기간 사용하지 않는 계정과 키 정리
SSH 자체가 안전하지 않다는 뜻은 아닙니다. 다만 이 환경에서는 이미 AWS 제어 영역과 IAM을 사용하고 있었고, 별도의 인바운드 포트 없이 접속할 수 있는 SSM이 운영 모델에 더 잘 맞았습니다.
SSM 전환 구성
- EC2 전용 IAM 역할과 인스턴스 프로파일 생성
AmazonSSMManagedInstanceCore정책만 연결- Amazon Linux 2023의 SSM Agent 상태 확인
- Managed node가 Online으로 표시되는지 확인
- 실제 Session Manager 접속 테스트
- 마지막에 보안 그룹의 SSH 인바운드 규칙 제거
aws ssm start-session
--region ap-northeast-2
--target i-xxxxxxxxxxxxxxxxx순서가 중요한 이유
SSM 등록이 확인되기 전에 SSH 규칙부터 제거하면 서버에 접근할 경로를 잃을 수 있습니다. 역할 연결, Agent, 네트워크 통신, 세션 시작을 모두 확인한 뒤 SSH를 닫아야 합니다. 전환 후에는 다른 네트워크에서 22번 포트가 실제로 차단되는지도 확인했습니다.
운영 명령도 SSM 기준으로 변경
WordPress 업데이트는 웹 서버 프로세스가 직접 수행하지 않도록 코어·테마·플러그인을 읽기 전용으로 유지합니다. 업데이트가 필요할 때는 SSM으로 접속해 전용 유지보수 스크립트를 실행합니다. 스크립트는 변경 전 파일과 데이터베이스 스냅샷을 만들고, 업데이트 후 WordPress 부트스트랩과 공개 URL을 점검합니다.
함께 적용한 서버 보안 정리
- 사용하지 않는 FTP 서버와 평문 FTP 설정 제거
- Apache 디렉터리 목록과 CGI 비활성화
- 업로드 디렉터리에서 PHP 실행 차단
- PHP 세션 쿠키의 Secure, HttpOnly, SameSite 적용
- SELinux Enforcing과 필요한 최소 boolean만 활성화
wp-config.php권한을 root와 Apache 그룹으로 제한
운영 시 남는 과제
Session Manager를 사용해도 IAM 계정과 권한 관리가 사라지는 것은 아닙니다. 누가 세션을 열 수 있는지 최소화하고, 필요하면 세션 기록을 CloudWatch Logs나 S3에 남겨야 합니다. 이 블로그에서는 비용과 개인 운영 범위를 고려해 세션 로그 중앙 저장은 별도 과제로 남겼습니다.
결론
SSM 전환의 가장 큰 장점은 단순히 SSH 키를 없앤 것이 아니라, 서버 접근을 IAM과 AWS 관리형 채널로 모으고 인바운드 포트를 하나 줄였다는 점입니다. 개인 블로그처럼 접속 주체가 명확한 환경에서는 운영 절차까지 함께 정리하면 관리 부담과 공격 표면을 동시에 줄일 수 있습니다.