“운영 서버에 개발자 계정이 왜 남아 있죠?”
“서비스에 장애가 나면 로그를 바로 확인해야 해서요.”
“로그만 보고 나갈 거라는 걸 확신할 수 있나요?”
“……”
“운영 서버에서 개발자 계정 전부 삭제하세요.”

IT 보안 감사 현장에서 매우 자주 반복되는 대화입니다.

“우리 회사에는 든든한 서버 접근제어(PAM) 솔루션이 도입되어 있고, 접속 기록도 잘 남고 있는데 왜 자꾸 운영 서버에서 개발자 계정을 빼라고 할까?” 하고 억울함을 토로하는 담당자분들이 많습니다.

하지만 감사관의 눈으로 보면 이유는 아주 명확합니다. 감사가 묻는 것은 ‘접속 권한의 유무’가 아니라 ‘위험 행위의 차단 증명’이기 때문입니다.

접근 제어가 완벽한 통제를 의미하지는 않습니다

서버 접근제어 솔루션은 ‘누가 어느 서버에 들어갈 수 있는가’를 인증하고 통제하며, ‘누가, 언제, 어느 서버에 들어가서 무엇을 했는가’를 기록하는 데 최적화되어 있습니다. 물론 특정 명령어 실행을 막는 ‘금지 명령어’ 기능도 제공합니다.

하지만 현업 실무에서는 다음과 같은 한계에 직면하게 됩니다.

• 개발자의 우회 역량: 개발자는 터미널 명령어뿐만 아니라 쉘 스크립트, 프로그램 코드를 직접 다루는 전문가입니다. 마음만 먹으면 얼마든지 금지 명령어 규칙을 우회해 다른 방식으로 작업을 수행할 수 있습니다.
• 업무 가용성과 통제의 딜레마: 우회를 막겠다고 금지 명령어의 범위를 너무 넓히면, 장애 대응에 필요한 정상적인 업무까지 막혀버립니다. 결국 실무에서는 최소한의 명령어만 등록해 둔 채 운용할 수밖에 없습니다.
• OS 환경의 한계: 텍스트 기반의 유닉스·리눅스 터미널과 달리, GUI 기반의 Windows 서버(RDP)에서는 이러한 명령어 단위 통제 자체가 사실상 어렵습니다.

이러한 한계들 때문에 감사관은 명령어를 칠 수 있는 한 위험이 100% 통제된 것이 아니라고 봅니다. 완벽하게 통제할 수 없다면 접속 자체를 막는 것이 가장 확실하기 때문에, 개발자 계정을 빼라고 권고하는 것입니다.

그렇다면 개발자의 운영 서버 접속 권한을 완전히 뺏고도, 장애 대응과 일상 운영 업무를 차질 없이 돌릴 수 있는 방법은 없을까요?

‘접속’을 막으면서 ‘업무’는 가능하게 하는 법: Qplat

Qplat(큐플랫)은 위험한 쉘 접속이나 명령어 입력 환경 자체를 제거하고, 개발자가 필요한 ‘결과’만 안전하게 얻어갈 수 있는 전용 업무 환경을 제공합니다.

Qplat이 현장의 통제와 업무를 동시에 해결하는 방식

1. 내장 뷰어를 통한 안전한 로그 조회
   개발자가 서버에 SSH로 직접 로그인하지 않아도, Qplat 내장 뷰어를 통해 필요한 로그만 실시간으로 안전하게 확인할 수 있습니다.

2. 사전 승인 기반의 파일 전송
   덤프 파일이나 로그 파일의 다운로드가 꼭 필요한 경우, 사전 결재 및 승인 절차를 강제하여 무단 다운로드를 근본적으로 차단합니다. 서버에 파일을 업로드 할 때도 결재를 걸어, 승인된 파일만 반영되게 할 수 있습니다.

3. 사전 정의 기반의 정형화된 작업(Job) 실행
   서비스 점검 등 명령어 실행이 불가피한 경우에도 자유 입력을 허용하지 않습니다. 관리자가 미리 파라미터까지 정의해 등록해 둔 ‘작업(Job) 트리’에서 선택하여 실행하고, 결과는 실시간 스트리밍으로 확인합니다.

모든 기능은 필요한 것만 골라서 도입할 수 있고, 도입한 뒤에도 기능별로 켜고 끌 수 있습니다. 그래서 로그 조회만 여는 것으로 시작해도 됩니다.

자주 묻는 질문 (FAQ)

Qplat을 도입하면 기존 서버 접근제어 솔루션은 버려야 하나요?

아닙니다. Qplat은 엔지니어나 전임 운영자들에게 필요한 통제된 쉘(CLI) 접속 환경까지 완전히 대체하지는 않습니다. 기존 서버 접근제어로 전체 인프라 관문(Bastion)을 지키면서, 보안 위험이 가장 큰 ‘개발자의 운영 서버 직접 접속’만 Qplat으로 이관하여 감사 지적 사항을 깔끔하게 해소하는 것이 가장 이상적인 조합입니다.

함께 읽어 볼 글

• 서버 접속 차단 뒤 흔한 우회 방식 3가지와 그 위험
• SSH 등 원격 접속 없이 서버 로그를 조회하는 방법