계정과 권한을 나누는 일이 왜 서버 보안의 출발점인가
공용 관리자 계정이 만드는 문제부터 최소 권한 원칙, 권한 회수와 책임 추적성까지 순서대로 정리합니다.
누가 했는지 말할 수 없는 시스템
서버 점검을 시작할 때 자주 마주치는 장면이 있습니다. 팀원 여럿이 같은 관리자 계정과 같은 비밀번호를 공유하고 있고, 그 비밀번호가 몇 년째 그대로인 경우입니다. 편해서 그렇게 됩니다. 계정을 따로 만들면 권한을 따로 챙겨야 하고, 사람이 바뀔 때마다 손이 갑니다. 급한 업무 앞에서 그 손이 계속 미뤄지다 보면 공용 계정 하나가 남습니다.
문제는 사고가 났을 때 드러납니다. 설정이 잘못 바뀌었거나 데이터가 지워졌을 때, 기록에는 '관리자 계정이 접속해서 이 작업을 했다'까지만 남습니다. 그 순간 조직은 누구를 탓하려는 것이 아니라 무슨 일이 있었는지를 재구성하지 못하게 됩니다. 원인을 모르면 재발을 막는 조치도 세울 수 없습니다.
그래서 계정 분리는 감시나 통제의 문제이기 이전에 사실 관계를 확인할 수 있는 상태를 만드는 문제입니다. 사람 단위로 계정이 나뉘어 있어야 '언제 누가 무엇을 했다'는 문장이 성립합니다.
최소 권한이라는 원칙
최소 권한은 각 계정에 업무 수행에 꼭 필요한 만큼의 권한만 주고, 그 이상은 주지 않는다는 원칙입니다. 말은 간단하지만 현장에서는 자주 미뤄집니다. 권한을 좁게 주면 '이것도 안 되네' 하는 요청이 계속 들어오고, 그때마다 대응하는 것보다 넉넉하게 열어 두는 편이 당장은 편하기 때문입니다.
이 원칙의 목적을 오해하면 설득이 어려워집니다. 최소 권한은 동료를 잠재적 내부자로 의심하기 위한 장치가 아닙니다. 사고가 났을 때 피해가 번지는 범위를 미리 줄여 두는 설계입니다. 계정 하나가 탈취되거나, 실수로 잘못된 명령을 실행하거나, 악성 프로그램이 그 계정의 권한으로 동작하기 시작했을 때 — 그 계정이 손댈 수 있는 범위가 곧 피해의 범위가 됩니다.
관리자 권한이 필요한 작업이 실제로 있다는 것도 인정해야 합니다. 요령은 그 권한을 상시로 들고 다니지 않는 것입니다. 평소에는 일반 권한으로 일하고, 관리자 권한이 필요한 순간에만 별도의 절차를 거쳐 승격해 사용하는 방식이 널리 쓰입니다. 사용 시점이 기록으로 남는다는 부수 효과도 있습니다.
사람이 아니라 역할에 권한을 붙인다
계정마다 필요한 권한을 하나씩 직접 붙이기 시작하면, 사람이 늘어날수록 관리가 감당하기 어려워집니다. 비슷한 일을 하는 두 사람의 권한이 미묘하게 달라지고, 그 차이가 왜 생겼는지 아무도 설명하지 못하는 상태가 됩니다. 그래서 실무에서는 '운영 담당', '조회 전용', '백업 담당'처럼 역할을 먼저 정의하고 권한 묶음을 역할에 붙인 뒤, 사람에게는 역할을 부여하는 방식을 씁니다.
이 방식의 장점은 관리 지점이 줄어든다는 데 있습니다. 정책이 바뀌면 역할 하나만 고치면 되고, 사람이 바뀌면 역할만 옮겨 주면 됩니다. 새로 합류한 사람에게 무엇을 줘야 하는지도 '어떤 역할인가'라는 질문 하나로 정리됩니다.
함께 따라오는 개념이 직무 분리입니다. 요청하는 사람과 승인하는 사람, 변경하는 사람과 그 기록을 점검하는 사람을 가능하면 나누어 두는 것입니다. 인원이 적은 조직에서 완전한 분리는 현실적으로 어렵지만, 최소한 '혼자서 시작부터 끝까지 아무 흔적 없이 처리할 수 있는 작업'이 무엇인지는 파악해 둘 필요가 있습니다.
권한은 주기보다 거두기가 어렵다
권한 관리에서 가장 흔한 실패는 부여 과정이 아니라 회수 과정에서 생깁니다. 부서를 옮긴 사람이 이전 업무의 권한을 그대로 들고 가고, 잠시 필요하다며 열어준 권한이 그대로 남고, 프로젝트가 끝난 뒤에도 임시 계정이 살아 있습니다. 한 건씩 보면 사소하지만 몇 년이 쌓이면 조직 전체의 권한 지도가 실제 업무와 전혀 맞지 않는 상태가 됩니다.
권한이 조용히 불어나는 이 현상은 특정 조직의 게으름 때문이 아니라, 회수에는 요청하는 사람이 없다는 구조적 이유 때문에 생깁니다. 권한을 달라는 요청은 업무가 막힌 사람이 먼저 하지만, 이제 필요 없으니 회수해 달라는 요청은 아무도 먼저 하지 않습니다. 그래서 회수는 사람의 선의가 아니라 절차로 만들어 두어야 합니다.
실무에서 쓰이는 방법은 두 가지 축입니다. 하나는 사건 기준으로, 입사·부서 이동·퇴사·프로젝트 종료 같은 시점에 권한 조정을 반드시 거치도록 연결해 두는 것입니다. 다른 하나는 주기 기준으로, 정해진 간격마다 계정과 권한 목록을 뽑아 현업 책임자에게 '지금도 필요한가'를 확인받는 것입니다. 이 검토는 정확도보다 꾸준함이 중요합니다.
로그가 증거가 되는 조건
계정과 권한 이야기의 마지막은 기록으로 이어집니다. 접속 기록, 명령 실행 기록, 권한 변경 기록은 사고가 났을 때 무슨 일이 있었는지 되짚는 유일한 근거이고, 평소에는 이상한 흐름을 발견하는 재료입니다. 그런데 이 기록이 의미를 가지려면 앞의 조건들이 먼저 갖춰져 있어야 합니다.
계정이 사람 단위로 분리되어 있지 않으면 기록은 '누군가'까지만 말해 줍니다. 권한이 필요 이상으로 넓으면 기록에 남은 행위가 규정 위반인지 정상 업무인지 판단할 기준이 없습니다. 기록을 지울 수 있는 권한이 기록을 남기는 사람과 같은 손에 있다면, 그 기록은 증거로서의 무게를 잃습니다.
그래서 계정 분리, 최소 권한, 기록 보존은 따로 떨어진 세 가지 조치가 아니라 하나의 묶음으로 이해하는 것이 좋습니다. 서버 보안을 어디서부터 시작해야 하느냐는 질문에 계정과 권한이 먼저 나오는 이유도 여기에 있습니다. 이 바닥이 정리되어 있어야 그 위에 올리는 다른 조치들이 제 역할을 합니다.
초보자가 자주 하는 실수
- 여러 명이 공용 관리자 계정을 함께 쓰기 — 사고가 나도 누가 무엇을 했는지 재구성할 수 없어 재발 방지책을 세우지 못합니다.
- 평소 업무를 관리자 권한으로 처리하기 — 계정이 탈취되거나 실수가 발생했을 때 피해 범위가 그대로 최대치가 됩니다.
- 권한을 주기만 하고 회수 절차를 만들지 않기 — 이동·퇴사·프로젝트 종료 때 남은 권한이 쌓여 실제 업무와 무관한 권한 지도가 됩니다.
읽고 나서 체크리스트
- 공용 계정이 왜 책임 추적을 어렵게 만드는지 설명할 수 있다
- 최소 권한 원칙의 목적이 피해 범위 축소라는 점을 안다
- 역할 기반으로 권한을 묶는 방식의 장점을 말할 수 있다
- 권한 회수를 사건 기준과 주기 기준으로 설계한다는 개념을 안다
- 로그가 증거로 기능하려면 어떤 선행 조건이 필요한지 안다
자주 묻는 질문
인원이 적은 팀에서도 계정을 다 나눠야 하나요?
인원이 적을수록 오히려 나누기 쉽습니다. 계정 수가 적어 관리 부담이 크지 않고, 한 사람이 여러 역할을 겸하는 상황에서 무엇을 겸하고 있는지 드러나기 때문입니다. 완전한 직무 분리가 어렵다면 최소한 기록만이라도 남기는 것이 다음 단계입니다.
권한 검토를 얼마나 자주 해야 하나요?
적정 주기는 조직의 규모와 변화 속도, 그리고 적용받는 규정에 따라 달라집니다. 일반적인 숫자를 그대로 따르기보다, 인사 변동이 반영되는 주기에 맞춰 정하고 실제로 지켜지는지 확인하는 편이 낫습니다. 규정상 요구되는 주기가 있다면 해당 기준을 공식 문서에서 확인해야 합니다.
사람이 아닌 시스템 계정은 어떻게 다루나요?
프로그램이나 배치 작업이 쓰는 계정도 같은 원칙을 적용합니다. 용도별로 분리하고, 필요한 권한만 부여하고, 사용처와 담당자를 기록해 둡니다. 사람이 로그인에 쓰지 않도록 분리하는 것도 함께 검토할 사항입니다.
이 글은 입문자 기준으로 이해하기 쉽게 정리한 일반 정보이며, 내용은 운영 과정에서 순차적으로 점검·보완될 수 있습니다. 구체적인 절차나 수치는 해당 기관의 공식 안내를 기준으로 확인해주세요.