클라우드로 옮긴 서버에서 업무 화면이 정상적으로 열린다고 해서 전환 작업이 끝난 것은 아닙니다. 이관을 위해 발급한 계정, 임시로 연 접속 경로, 중간에 저장한 데이터가 남아 있다면 서비스가 정상이어도 보안 위험은 이어질 수 있습니다. 전환 기간에는 기존 환경과 새 환경을 함께 관리해야 합니다. 전환 중 누락되는 데이터와 config가 있을 수 있어, 이에따른 리스크가 존재합니다. 따라서 새 서버의 보안 설정뿐 아니라 이동 과정에서 무엇을 추가했고, 언제 회수할 것인지까지 확인해야 합니다.
임시 권한과 공개 접속 경로가 운영 설정에 잔존
이관 도구나 외부 작업자에게 넓은 권한을 주면 작업은 편해질 수 있지만, 외주업체에 부여한 권한을 회수하지 않는다면 작업 종료 후에도 구축 시 부여된 권한이 유지될 수 있습니다. 계정별로 대상 자원·허용 작업·사용 기간·회수 담당자를 기록하고, 이관용 권한과 운영용 권한을 구분해야 합니다.
AWS는 임시 자격 증명과 최소 권한 적용, 사용하지 않는 권한·자격 증명의 정기적인 확인 및 정리를 권고합니다. 다만 임시 자격 증명이 만료되어도 이를 다시 발급받을 수 있는 역할과 신뢰 설정이 남을 수 있으므로, IAM설정과 발급 가능 조건까지 검토해야 합니다. AWS IAM 보안 모범 사례에서 관련 원칙을 확인할 수 있습니다.
접속 오류를 해결하려고 관리 포트나 저장소를 인터넷 전체에 개방하는 것도 주의해야 합니다. 이는 구축 완료된 서비스에 백도어를 만들 수 있고, 업무용 웹 화면의 공개와 데이터베이스·관리 경로의 공개는 목적이 다르므로, 외부 업체에 필요한 출발지와 서비스만 허용했는지 따로 확인합니다.
예를 들어 Amazon S3의 퍼블릭 액세스 차단은 공개 접근을 제한하는 기능입니다. 이를 켰다고 모든 인증된 접근까지 차단되는 것은 아니므로 IAM 권한과 저장소 정책도 함께 살펴야 합니다. 공개 서비스라면 기능을 일괄 적용하기 전에 정상 제공 경로를 검증합니다. S3 공식 문서도 적용 전 애플리케이션 동작 확인을 안내합니다.
데이터 이동은 끝나도 복제본과 비밀정보는 남습니다
데이터베이스 덤프, 스냅샷, 임시 저장소, 작업자 PC에 보관한 파일은 원본과 별도로 관리해야 할 복제본입니다. 운영 데이터만 보호하고 Config설정과 파일을 놓치면 Gray영역에 정보가 남을 수 있습니다.
전송·저장 시 암호화 여부와 함께 누가 파일을 읽고 복호화할 수 있는지 확인합니다.
설정 파일에 포함된 비밀번호와 API 키도 점검 대상입니다. 불필요하게 생성된 credential은 제거하고, 노출이 의심되면 해당 자격 증명의 교체와 사용 이력 확인을 진행합니다.
다음은 가정 사례입니다. 고객 DB를 임시 저장소에 올린 뒤 새 DB에 정상 반영했어도, 임시 파일의 보존 목적과 삭제 담당자가 정해지지 않아 temp 데이터가 잔존한다면 다면 해당 작업을 종료하면 안됩니다.
복구에 필요한 사본은 접근을 제한해 보관하고, 불필요한 사본은 보존 의무와 내부 기준을 확인한 뒤 정리해야 합니다.
로그 누락과 복구 미검증은 전환 후 대응을 어렵게 만듭니다
기존 서버의 로그 수집 설정이 새 환경에 그대로 이어진다고 가정하면 안 됩니다. 계정·권한 변경 기록, 애플리케이션 기록, 필요한 데이터 접근 기록을 구분하고 실제 이벤트가 수집되는지 확인해야 합니다.
AWS CloudTrail의 이벤트 기록은 리전별 최근 90일의 관리 이벤트를 제공하며 데이터 이벤트는 표시하지 않습니다. 따라서 이 화면만 보고 파일 접근을 포함한 모든 행위가 기록된다고 판단하면 안 됩니다. CloudTrail 이벤트 기록의 범위와 제한을 기준으로 필요한 수집 설정과 보관 방식을 별도로 결정합니다.
원복도 접속 주소만 예전 환경으로 되돌리는 문제로 생각하기 쉽습니다. 새 환경에서 주문이나 게시물이 추가되었다면 기존 DB에는 그 내용이 없을 수 있습니다. 어느 시점의 데이터를 기준으로 돌아갈지, 변경분을 어떻게 반영할지, 누가 원복을 결정할지 정해야 합니다.
AWS 전환 단계 가이드는 사전 테스트, 모니터링·알림 준비 확인, 변경된 데이터의 처리를 포함한 원복 계획을 권고합니다. 다음 점검표는 이를 전환 작업에 적용하기 위한 실무용 정리입니다.
| 점검 대상 | 완료를 판단할 근거 |
|---|---|
| 권한·접속 | 운영 권한으로 정상 동작하며 불필요한 이관 계정·접속 예외가 정리됨 |
| 데이터 사본 | 사본별 보관 목적·담당자·정리 조건이 기록됨 |
| 로그·알림 | 필요한 테스트 이벤트가 수집되고 지정 담당자가 알림을 수신함 |
| 복구·원복 | 복원 테스트 결과와 변경 데이터 처리 절차, 판단 담당자가 확인됨 |
자주 묻는 질문
전환 업체가 작업했다면 회사는 무엇을 확인해야 합니까?
업체가 수행한 작업 범위와 회사가 인수할 운영 항목을 구분합니다. 특히 이관 계정 회수, 데이터 사본의 보관·삭제 내역, 로그 확인 방법과 비상 연락 담당자를 인수 자료에 포함하는 것이 좋습니다.
기존 환경은 전환 직후 바로 삭제해도 됩니까?
복구 계획과 데이터 검증이 끝나기 전에 삭제하면 원복 수단을 잃을 수 있습니다. 보존 기간과 종료 조건을 먼저 정하고, 유지하는 동안에도 접근 제한·보안 업데이트·모니터링 담당자를 지정해야 합니다.
점검표에서 미완료 항목이 나오면 어떻게 합니까?
데이터 노출 가능성이나 필수 기록 누락처럼 영향이 큰 항목은 서비스 전환 전에 해소할 대상으로 다룹니다. 당장 해결하기 어렵다면 위험의 영향, 임시 통제, 담당자와 완료 기한을 기록하고 전환 여부를 결정할 책임자가 검토해야 합니다.
결론
클라우드 전환의 완료 기준에는 서비스 동작과 보안 인수가 함께 들어가야 합니다. 작업 중 추가한 권한·접속 경로·데이터 사본을 목록화하고, 로그 수신과 복구 결과를 근거로 남기십시오. 새 환경을 여는 절차와 임시 설정을 회수하는 절차를 함께 계획하는 것이 전환 과정의 보안 공백을 줄이는 출발점입니다.