모두
모두콘텐츠
얼마 전 서버 이전을 도와주다가 운영 계정 하나로 개발, 배포, 백업까지 처리하는 곳을 봤습니다. 서버 사양은 넉넉했지만 그 계정이 탈취되면 서비스와 백업을 함께 잃을 수 있는 구조였습니다. 클라우드 보안은 비싼 장비를 추가하기 전에 누가 무엇을 바꿀 수 있는지, 사고가 나면 어디서 복구할지를 확인하는 일부터 시작합니다.
관리자 계정의 권한부터 나누기
클라우드에서는 서버 한 대의 비밀번호보다 관리 콘솔 계정이 더 큰 권한을 갖는 경우가 많습니다. 콘솔에서 서버를 삭제하고 방화벽을 열고 백업 저장소까지 지울 수 있기 때문입니다. 운영자 전원이 같은 관리자 계정을 쓰면 사고 뒤에 누가 어떤 설정을 바꿨는지도 추적하기 어렵습니다.
사람마다 계정을 만들고 다중 인증을 켜는 것이 첫 순서입니다. 평소에는 필요한 작업만 허용하고, 전체 관리자 권한은 긴급 작업용으로 제한합니다. 퇴사자 계정과 오래된 접근 키도 함께 확인해야 합니다. 제가 점검할 때는 최근에 사용하지 않은 키부터 찾습니다. 쓰는 곳을 확인한 뒤 폐기하면 서비스 장애를 피하면서 권한을 줄일 수 있습니다.
- 사람이 쓰는 계정과 프로그램이 쓰는 계정을 분리합니다.
- 배포 프로그램에는 배포에 필요한 자원만 수정할 권한을 줍니다.
- 관리자 계정의 로그인과 권한 변경에는 알림을 걸어 둡니다.
권한을 줄일 때는 서버 이름만 보고 범위를 정하지 않는 편이 안전합니다. 예를 들어 이미지 업로드 프로그램에는 파일 저장 권한이 필요하지만, 서버 생성이나 백업 삭제 권한까지 줄 이유는 없습니다. 반대로 권한을 한꺼번에 제거하면 야간 배포가 멈출 수 있으니 실제 사용 기록을 보고 단계적으로 바꿉니다.
외부에 열린 통로를 확인하기
다음은 네트워크입니다. 웹 서비스라면 이용자가 접속할 통로는 열려 있어야 합니다. 하지만 데이터베이스나 서버 관리 포트까지 인터넷 전체에 열어 둘 필요는 대개 없습니다. 특히 테스트용 서버를 만들 때 임시로 연 규칙이 운영 환경에 남는 일이 잦습니다.
웹 서버, 애플리케이션, 데이터베이스를 나눠 생각하면 점검이 쉬워집니다. 웹 서버는 필요한 서비스 포트만 외부에 열고, 데이터베이스는 애플리케이션 서버에서 오는 연결만 받게 합니다. 관리 접속은 허용할 위치를 좁히고 사용하지 않을 때 닫습니다. 서버가 한 대뿐인 저가 요금제에서도 이 원칙은 같습니다. 장비를 더 사기 전에 방화벽 규칙 몇 개를 바로잡는 편이 효과적일 때가 많습니다.
다만 방화벽만 믿으면 빈틈이 생깁니다. 운영체제와 설치한 프로그램의 보안 업데이트를 적용할 시간을 정하고, 자동 갱신을 쓰는 항목도 재시작 여부를 확인해야 합니다. 업데이트 직후 문제가 생길 수 있으므로 적용 전 복구 지점을 확보하고, 서비스가 실제로 응답하는지 점검합니다.
백업은 삭제 사고까지 가정하기
클라우드 서버에 자동 스냅샷이 있다고 해서 복구 준비가 끝난 것은 아닙니다. 같은 계정으로 서버와 스냅샷을 모두 삭제할 수 있다면 계정 탈취나 작업 실수에 함께 영향을 받습니다. 스냅샷은 서버 상태를 되돌리는 데 편하지만, 데이터베이스가 기록 중이던 시점의 일관성도 확인해야 합니다.
예를 들어 하루 한 번 백업하면 장애 시 최대 하루치 변경분을 잃을 수 있습니다. 주문이나 예약처럼 손실 허용 시간이 짧은 서비스라면 더 자주 백업하거나 별도 복제 방식을 검토해야 합니다. 반대로 한 달에 몇 번만 수정하는 소개 사이트에 고가의 실시간 복제를 붙이는 건 과한 지출일 수 있습니다. 필요한 백업 주기는 방문자 수보다 데이터 변경량과 허용 가능한 손실 시간으로 결정합니다.
- 서버와 분리된 위치에 백업 사본을 보관합니다.
- 백업 삭제 권한을 일상 운영 권한과 분리합니다.
- 복구 파일의 보관 기간과 저장 비용을 함께 계산합니다.
- 정기적으로 새 서버에 복원해 로그인, 화면, 데이터까지 확인합니다.
복구 시험은 파일이 열리는지 확인하는 데서 끝나지 않습니다. 데이터베이스를 되살린 뒤 서비스 설정과 인증서가 맞는지, 도메인 전환 후에도 접속이 되는지 봐야 합니다. 저는 복구 절차에 걸린 시간을 기록해 둡니다. 실제 장애 때 필요한 서버 사양과 담당 인원을 가늠하는 데 그 기록이 더 유용합니다.
로그와 알림은 적게 시작해도 된다
소규모 사이트에 비싼 보안 관제 상품이 항상 필요한 것은 아닙니다. 우선 관리 계정 로그인, 권한 변경, 방화벽 변경, 서버 삭제, 백업 실패를 기록하고 알림을 받는 구성이면 주요 사고를 빨리 발견하는 데 도움이 됩니다. 서버 안의 로그만 남기면 서버가 지워졌을 때 조사 자료도 사라질 수 있으므로 로그 보관 위치도 분리합니다.
알림은 개수보다 대응 가능성이 중요합니다. 매일 수십 통씩 오는 알림은 결국 무시하게 됩니다. 야간에도 즉시 확인할 항목과 다음 근무 시간에 점검할 항목을 나누고, 각 알림에 첫 확인 순서를 적어 둡니다. 접속 장애라면 서버 상태, 최근 설정 변경, 네트워크 규칙, 데이터베이스 연결, 백업 상태 순으로 보면 원인을 좁히기 쉽습니다.
클라우드 보안에 예산을 쓰기 전에는 계정 권한, 외부 접속 규칙, 복구 시험 기록을 먼저 펼쳐 봅니다. 이 세 가지가 불분명한 상태에서 서버 사양이나 보안 상품만 올려도 운영 위험은 그대로 남습니다. 작은 사이트일수록 복잡한 구성보다 담당자가 실제로 점검하고 복구할 수 있는 구성이 오래 버팁니다.
