SSH 접근을 복구하고 나니 개인키 하나와 관리자 계정에 의존하고, 22번 port도 넓게 열려 있다는 문제가 보였다. 같은 일이 생겼을 때 복구 선택지가 하나뿐인 상태부터 바꾸기로 했다.
메인 키와 비상 키를 분리했다
authorized_keys에는 새로 복구한 키와 분실한 기존 키가 함께 있었다. 새 키를 메인으로 정하고 사용할 수
없는 공개키를 제거했다. 별도의 일반 SSH 비상 키도 당시 서버가 지원하는 ed25519로 만들었다.
ssh-keygen -t ed25519 -f ~/.ssh/<emergency-key> -C "oci-emergency-access"
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys서버에는 두 공개키만 남겼다. 비상 키는 복구 경로를 늘리지만 유효한 credential도 하나 늘린다. 평소에는 사용하지 않고 메인 키와 다른 보호 경계에 보관했다.
저장한 키로 실제 접속을 확인했다
메인 키는 암호화한 별도 보관소, 비상 키는 일상 파일과 분리한 관리형 secret 저장소에 뒀다. 실제 서비스와 위치는 공개하지 않았고 Git이나 일반 문서에도 개인키 원문을 넣지 않았다.
비상 키를 저장소에서 임시 파일로 복원해 permission을 제한하고 실제 SSH 접속을 확인한 뒤 삭제했다. 당시 저장한 값과 서버 공개키가 맞는지는 증명했지만, 이후 저장소 권한과 account recovery, key 폐기까지 자동으로 보장하는 test는 아니다.
복구에 사용한 Console Connection도 일반 SSH 확인 뒤 삭제했다. 상시 연결은 줄었지만 필요할 때 다시 만들 OCI account와 IAM이 마지막 복구 경계라는 사실은 남았다.
관리자 계정과 작업 계정을 나눴다
관리자 계정 하나로 IAM과 instance, network를 모두 관리하던 구조를 다음처럼 바꿨다.
| 계정 | 사용 범위 |
|---|---|
| 관리자 | IAM, 결제, 정책 변경과 비상 복구 |
| 작업용 | Instance와 volume, virtual network의 일상 관리 |
작업 group에는 manage instance-family, manage volume-family, manage virtual-network-family,
inspect compartments policy를 부여했다. 관리자 계정을 일상 작업에서 제외하는 첫 단계였지만 엄격한 최소
권한이라고 부르기에는 여전히 넓다.
처음에는 새 계정에서 instance가 보이지 않았지만 browser session을 완전히 끝내고 로그인하자 group과 policy가 반영됐다. 필요한 작업을 수행할 수 있는지 확인했고 관리자 계정의 MFA와 account recovery도 점검했다. 구체적인 인증 수단과 계정 정보는 기록하지 않았다. 이 방향은 Oracle의 IAM 운영 권장 사항과 같다.
SSH ingress를 현재 IP로 제한했다
OCI Security List의 SSH source는 모든 IPv4였다.
Before: TCP 22 <- 0.0.0.0/0
After: TCP 22 <- <current-client-ip>/32당시 접속 중인 공인 IP 하나로 줄였다. Network가 바뀌면 OCI Console에서 CIDR를 갱신해야 하는 편의성 비용을 받아들였다. HTTP와 HTTPS는 공개하고 MySQL과 백엔드 내부 port는 추가하지 않았다. 자세한 CIDR 동작은 Security List 문서를 기준으로 확인했다.
Cloud 규칙과 서버 상태를 따로 봤다
Security List가 좁아도 SSH daemon과 host firewall, listening process는 별도 경계다.
sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin|pubkeyauthentication'
sudo ss -tulpn당시 SSH는 password authentication을 사용하지 않고 public key authentication을 사용했다. Root 정책은 새로
바꾸지 않고 effective configuration만 확인했다. ss로 실제 address와 port를 확인했지만 firewall persistence와
reboot 뒤 상태까지는 아직 검증하지 않았다. Oracle의
Compute 보안 문서처럼 VCN
규칙과 host firewall은 함께 봐야 한다.
애플리케이션 배포 전 backup을 만들었다
접근과 network를 정리한 상태에서 수동 incremental Boot Volume Backup을 만들고 Available까지 확인했다.
Ubuntu 부팅과 SSH 메인·비상 접근 확인
분실한 공개키 제거
IAM 작업 계정 분리
임시 Console Connection 삭제
Security List 축소Boot Volume Backup 문서의 point-in-time 기준점이다. 실시간 backup이나 다른 region까지 포함한 disaster recovery가 아니며 실제 restore를 끝까지 시험하지도 않았다.
줄인 위험만큼 관리 대상도 늘었다
| 이전 | 변경 | 남은 비용 |
|---|---|---|
| SSH 키 하나 | 메인·비상 키 | 보호할 credential 증가 |
| 분실 공개키 유지 | 제거 | Key rotation 필요 |
| 관리자 일상 사용 | 작업 계정 분리 | 작업 policy도 넓음 |
| SSH 전체 공개 | /32 제한 | IP 변경 때 수동 갱신 |
| 복구 기준점 없음 | Boot Volume Backup | 단일 시점이며 restore 미검증 |
비상 키는 복구 가능성을 높이지만 노출될 credential도 늘린다. Console Connection을 지워도 Cloud Console과 IAM의 강한 권한은 남는다. 완벽하게 안전해진 것이 아니라 당시 확인한 위험을 줄이고 돌아갈 경로를 하나 더 만든 작업이었다.
현재 port와 process가 정상이라는 사실도 다음 부팅을 보장하지 않는다. Security List와 host firewall, 서비스가 재부팅 뒤에도 같은 상태로 시작하는지는 별도로 검증해야 했다.