한눈에 보기: 서버 접속을 막아도 로그 확인, 파일 전송, 서비스 점검은 계속해야 합니다. 따라서 현장에서는 운영자가 대신 처리하거나, 운영자 PC를 빌려 쓰거나, 통제실을 두는 방식으로 우회합니다. 하지만 이러한 방식은 일이 늦어지고, 권한의 분리와 통제가 어려우며, 업무 이력을 추적하기 어렵다는 문제가 있습니다.
서버 접속 차단 뒤에도 계속해야 하는 업무
서버 접속 차단은 개발자와 외주인력이 운영 서버에 직접 로그인하지 못하게 막는 운영 서버 접근 통제 조치입니다. 감사에서 개인 계정 관리를 지적받거나 직무분리 기준을 정비할 때, 계정을 회수하거나 방화벽으로 접속을 막는 방식으로 진행합니다. 물론 이렇게 하면 감사 지적은 피할 수 있습니다. 하지만 이것은 큰 혼란과 위험을 불러옵니다.
차단 다음 날 운영팀을 떠올려 보면 쉽습니다. 오전에는 배치 실패 로그를 보내 달라는 요청이 옵니다. 오후에는 분석용 파일을 내려 달라는 요청이 이어집니다. 저녁에는 배포한 서비스가 정상인지 봐 달라는 전화가 옵니다. 모두 어제까지 개발자가 직접 하던 일입니다. 운영자는 자기 업무를 하면서 이 요청들을 처리해야 합니다.
| 계속해야 하는 업무 | 하던 일의 예 | 막히면 생기는 일 |
|---|---|---|
| 로그 확인 | 장애 원인 분석, 배치 결과 확인 | 원인 찾기가 늦어집니다 |
| 파일 전송 | 분석용 로그·덤프 파일 내려받기 | 자세한 분석이 늦어집니다 |
| 서비스 점검 | 프로세스·포트 상태 확인, 배포 뒤 정상 동작 확인 | 장애 조치가 늦어집니다 |
일은 해야 하므로 조직은 우회할 방법을 찾습니다. 현장에서 흔히 보는 우회 방식은 아래 세 가지이며, 특정 조직의 사례가 아니라 여러 현장에서 되풀이되는 모습을 재구성한 것입니다.
방식 1. 운영자가 대신 처리한다
운영자 대행은 접속 권한이 있는 운영자가 개발자의 요청을 받아 대신 처리하는 방식입니다.
운영자는 요청이 올 때마다 하던 일을 멈추고 로그를 찾아 보내거나, 파일을 내려받아 전달하거나, 불러 주는 명령을 대신 입력합니다. 모든 일이 운영자를 거치기 때문에 운영자가 바쁘면 그만큼 늦어집니다. 장애가 나면 요청이 소수의 운영자에게 한꺼번에 몰려 지연은 더 길어집니다.
더 큰 문제는 책임과 기록입니다. 파일을 전달하고 명령을 입력한 사람이 운영자이므로, 문제가 생기면 책임도 운영자에게 돌아갑니다. 또 요청과 전달 내역이 메일, 메신저, 전화에 나뉘어 남기 때문에 감사 때 이를 한곳에 모아 확인하기 어렵습니다.
방식 2. 개발자가 운영자 PC와 계정을 빌려 쓴다
운영자 PC 사용은 개발자가 운영자 자리에 가서 운영자의 PC와 계정으로 직접 작업하는 방식입니다. 대행을 기다리기에는 일이 너무 급할 때 주로 생깁니다.
담당자가 직접 하니 속도는 빨라집니다. 하지만 서버에는 실제 작업자가 아니라 운영자 계정으로 기록이 남습니다. 또 운영자 계정에는 운영자의 권한이 그대로 있어서, 로그만 보려고 앉았더라도 운영자만 해야 할 작업까지 할 수 있습니다. 결국 운영자는 자기 계정으로 일어난 모든 작업을 책임져야 하고, 이런 계정 공유 자체가 감사에서 다시 지적받을 수 있습니다.
방식 3. 이머전시 룸·통제실을 운영한다
통제실(이머전시 룸)은 서버에 접속할 수 있는 전용 PC를 별도의 방에 두고, 그 방에서만 서버 작업을 하게 하는 방식입니다. 관리를 한 곳에서 하기 때문에 세 방식 가운데 가장 잘 통제되는 것처럼 보입니다.
하지만 PC 수가 정해져 있어서 요청이 몰리는 날에는 자리가 날 때까지 기다려야 합니다. 방 안에서는 운영자가 열어 준 세션으로 작업하기 때문에, 작업자는 그 세션의 권한 안에서 무엇이든 할 수 있습니다. 시스템에는 실제 작업자가 아니라 세션을 열어 준 운영자의 작업으로 기록되고, 출입 기록에는 누가 언제 방에 들어갔는지만 남습니다. 그래서 필요한 일만 하도록 통제하기도 어렵고, 감사 때 누가 무엇을 했는지 증명하기도 어렵습니다.
세 가지 우회 방식 비교
| 점검할 것 | 운영자 대행 | 운영자 PC 사용 | 통제실 |
|---|---|---|---|
| 담당자 본인의 행위가 남는가? | 요청 기록만 여러 채널에 남는다 | 운영자 계정으로 남는다 | 출입 기록과, 세션을 열어 준 운영자 계정으로 남는다 |
| 필요한 일만 할 수 있는가? | 운영자 판단에 달렸다 | 운영자 권한을 모두 쓸 수 있다 | 운영자가 열어 준 세션의 권한을 모두 쓸 수 있다 |
| 장애 때 바로 쓸 수 있는가? | 운영자를 기다린다 | 운영자 자리로 가야 한다 | 방에 빈자리가 있어야 한다 |
| 운영자 업무가 유지되는가? | 요청마다 끊긴다 | 자리를 내줘야 한다 | 방과 PC를 관리해야 한다 |
우회 방식의 비용과 위험
서버 접속 차단 뒤 쓰는 운영자 대행, 운영자 PC 사용, 이머전시 룸이나 통제실 같은 우회 방식을 C레벨에서 보면 시간과 비용은 늘어나는데 위험은 줄지 않는 구조입니다. 보안 면에서는 권한 통제가 미흡해 사고가 발생할 수 있고, 감사 때 작업 이력을 증명하지 못해 다시 지적을 받을 수도 있습니다. 특히 장애나 정보 유출이 의심될 때 누가 어떤 로그를 보고 어떤 파일을 가져갔는지 확인하지 못하면, 원인을 찾기도 책임을 가리기도 어렵습니다.
시간과 비용도 늘어납니다. 운영 인력은 다른 사람의 요청을 대신 처리하느라 본업 시간을 씁니다. 장애 시에는 각 담당자가 즉시 점검하지 못해서 원인 분석과 조치 시간도 길어집니다.
서버 접속 차단 전에 무엇을 정해야 하나요?
차단을 계획할 때에는 어떻게 막을지도 고민해야 하지만, 그와 동시에 필수 업무들을 어떻게 수행할지도 고민해야 합니다. 최소한 아래 다섯 가지는 미리 고민하여 정해 두는 것이 좋습니다.
- 요청 경로: 누가 누구에게, 어떻게 요청하는가
- 허용 범위: 누가 어느 서버에서 어떤 일까지 해도 되는가
- 기록 방식: 담당자의 행위와 승인 내역이 어디에 남는가
- 장애 때 절차: 급할 때도 같은 경로와 기록을 쓰는가
- 책임자: 누가 승인하고, 누가 기록을 확인하는가
Qplat(큐플랫)은 바로 이런 문제를 해결하는 솔루션입니다.
서버에 접속하지 않고 로그 확인, 파일 전송, 서비스 점검 같은 필수 작업을 담당자 본인 ID로 처리합니다. 로그 조회 같은 평소 업무는 허용된 범위 안에서 바로 처리하고, 파일 전송 같은 민감한 업무는 강제로 사전 결재를 거치게 할 수 있습니다. 필요하지 않은 기능은 끌 수 있어서, 파일 전송이나 다운로드 없이 로그 조회 전용으로 도입하거나 다운로드는 끄고 업로드만 쓰도록 구성할 수도 있습니다. 누가 언제 어느 서버에서 무엇을 했는지는 본인 ID로 남아, 감사가 묻는 질문에 기록으로 답할 수 있습니다.