서버 보안, 어디서부터 손대야 할까요: 공용 관리자 계정부터 나누는 이유

누가 했는지 말할 수 없는 시스템

서버 보안을 어디서부터 손대야 할지 몰라 막막하셨던 적 있으시죠. 백신이며 방화벽이며 이것저것 떠오르는데, 정작 첫 단추가 어디인지가 안 잡혀서 계속 미루게 돼요. 결론부터 말씀드리면 출발점은 계정과 권한이고, 이 글에서 그 정리 순서를 하나씩 짚어 드릴게요.

서버 점검을 시작할 때 자주 마주치는 장면이 있어요. 팀원 여럿이 같은 관리자 계정과 같은 비밀번호를 쓰고 있고, 그 비밀번호가 몇 년째 그대로인 경우예요. 편해서 그렇게 돼요. 계정을 따로 만들면 권한을 따로 챙겨야 하고, 사람이 바뀔 때마다 손이 가니까요. 급한 업무 앞에서 그 손이 계속 미뤄지다 보면 공용 계정 하나만 남아요.

근데 말이죠, 문제는 사고가 났을 때 드러나요. 설정이 잘못 바뀌었거나 데이터가 지워졌을 때, 기록에는 '관리자 계정이 접속해서 이 작업을 했다'까지만 남아요. 그 순간 조직은 누구를 탓하려는 게 아니라, 무슨 일이 있었는지를 재구성하지 못하게 돼요. 원인을 모르면 재발을 막는 조치도 세울 수 없고요.

그래서 계정 분리는 감시나 통제의 문제이기 전에, 사실 관계를 확인할 수 있는 상태를 만드는 문제예요. 사람 단위로 계정이 나뉘어 있어야 '언제 누가 무엇을 했다'는 문장이 비로소 성립해요.

최소 권한이라는 원칙

최소 권한은 각 계정에 업무에 꼭 필요한 만큼만 권한을 주고 그 이상은 주지 않는다는 원칙이에요. 말은 간단한데 현장에서는 자주 미뤄져요. 권한을 좁게 주면 '이것도 안 되네' 하는 요청이 계속 들어오고, 그때마다 대응하는 것보다 넉넉하게 열어 두는 편이 당장은 편하니까요.

여기서 목적을 오해하면 팀 설득이 어려워져요. 최소 권한은 동료를 잠재적 내부자로 의심하려는 장치가 아니에요. 사고가 났을 때 피해가 번지는 범위를 미리 줄여 두는 설계예요. 계정 하나가 탈취되거나, 실수로 잘못된 명령을 실행하거나, 악성 프로그램이 그 계정의 권한으로 동작하기 시작했을 때, 그 계정이 손댈 수 있는 범위가 곧 피해의 범위가 돼요.

관리자 권한이 꼭 필요한 작업이 실제로 있다는 점도 인정해야 해요. 요령은 그 권한을 상시로 들고 다니지 않는 거예요. 평소에는 일반 권한으로 일하고, 관리자 권한이 필요한 순간에만 별도 절차를 거쳐 승격해 쓰는 방식이 널리 쓰여요. 사용 시점이 기록으로 남는다는 이점도 함께 따라와요.

사람이 아니라 역할에 권한을 붙인다

계정마다 필요한 권한을 하나씩 직접 붙이기 시작하면, 사람이 늘어날수록 관리가 버거워져요. 비슷한 일을 하는 두 사람의 권한이 미묘하게 달라지고, 그 차이가 왜 생겼는지 아무도 설명하지 못하는 상태가 되거든요. 그래서 실무에서는 '운영 담당', '조회 전용', '백업 담당'처럼 역할을 먼저 정의해요. 권한 묶음을 역할에 붙인 뒤, 사람에게는 역할만 부여하는 방식이에요.

이 방식은 관리 지점이 확 줄어서 좋아요. 정책이 바뀌면 역할 하나만 고치면 되고, 사람이 바뀌면 역할만 옮겨 주면 돼요. 새로 합류한 분에게 무엇을 줘야 할지도 '어떤 역할인가' 질문 하나로 정리돼요. 처음 한 번만 역할표를 만들어 두면 그 뒤로는 계속 편해지는 구조예요.

함께 따라오는 개념이 직무 분리예요. 요청하는 사람과 승인하는 사람, 변경하는 사람과 그 기록을 점검하는 사람을 가능하면 나눠 두는 거예요. 인원이 적은 조직에서 완전한 분리는 현실적으로 어렵지만, 최소한 '혼자서 시작부터 끝까지 아무 흔적 없이 처리할 수 있는 작업'이 무엇인지는 알아 두시면 좋아요.

권한은 주기보다 거두기가 어렵다

권한 관리에서 가장 흔한 실패는 부여가 아니라 회수 쪽에서 생겨요. 부서를 옮긴 사람이 이전 업무 권한을 그대로 들고 가고, 잠시 필요하다며 열어준 권한이 그대로 남고, 프로젝트가 끝난 뒤에도 임시 계정이 살아 있어요. 아시죠 그 느낌? 한 건씩 보면 사소한데, 몇 년이 쌓이면 조직 전체의 권한 지도가 실제 업무와 전혀 맞지 않게 돼요.

여기서 많이들 자책하시는데, 게으름 때문이 아니에요. 회수에는 먼저 요청하는 사람이 없다는 구조적인 이유가 있어요. 권한을 달라는 요청은 업무가 막힌 사람이 먼저 하지만, 이제 필요 없으니 거둬 달라는 요청은 아무도 먼저 하지 않거든요. 그래서 회수는 선의가 아니라 절차로 만들어 두어야 합니다.

실무에서 쓰는 방법은 두 갈래예요. 하나는 사건 기준이에요. 입사·부서 이동·퇴사·프로젝트 종료 같은 시점에 권한 조정을 반드시 거치도록 연결해 두는 거예요. 다른 하나는 주기 기준이에요. 정해진 간격마다 계정과 권한 목록을 뽑아 현업 책임자에게 '지금도 필요한가'를 확인받는 방식이에요. 이 검토는 정확도보다 꾸준함이 훨씬 중요해요.

클라우드에서는 권한이 더 빠르게 불어난다

지금까지는 사내 서버를 염두에 둔 이야기였는데요, 클라우드로 옮겨 가면 같은 원칙이 더 무겁게 적용돼요. 클라우드 관리 콘솔의 계정 하나는 서버 접속 권한을 넘어 서버를 만들고 지우는 권한, 저장소와 결제 정보에 닿는 권한까지 품을 수 있어요. 관리 화면의 로그인 정보 하나가 곧 인프라 전체의 열쇠가 되는 구조예요.

권한이 불어나는 속도도 달라요. 사내 서버에서는 권한을 열어 주는 데 담당자의 손이 한 번은 필요하지만, 클라우드에서는 화면에서 몇 번만 눌러도 넓은 권한 묶음이 붙어요. 심지어 서비스가 늘어날 때마다 프로그램이 쓰는 접근 키도 함께 늘어나요. 당장 편하다는 이유로 전체 관리자에 가까운 권한을 주고 잊어버리는 패턴은 현장 점검에서 자주 보여요.

다행히 대응 방법은 새로울 게 없어요. 사람 단위 계정 분리, 역할 기반 권한 부여, 쓰지 않는 계정과 접근 키의 주기적 회수까지 앞에서 정리한 원칙이 그대로 통해요. 클라우드 서비스 대부분이 권한 사용 내역을 돌아볼 수 있는 기능을 기본으로 주니, 어디까지가 이용자의 책임 영역인지를 책임 공유 모델과 함께 묶어 정리해 두시면 관리 지점이 훨씬 또렷해져요.

로그가 증거가 되는 조건

계정과 권한 이야기의 마지막은 기록으로 이어져요. 접속 기록, 명령 실행 기록, 권한 변경 기록은 사고가 났을 때 무슨 일이 있었는지 되짚는 유일한 근거예요. 평소에는 이상한 흐름을 발견하는 재료가 되고요. 그런데 이 기록이 의미를 가지려면 앞의 조건들이 먼저 갖춰져 있어야 해요.

계정이 사람 단위로 분리되어 있지 않으면 기록은 '누군가'까지만 말해 줘요. 권한이 필요 이상으로 넓으면 기록에 남은 행위가 규정 위반인지 정상 업무인지 판단할 기준이 없고요. 기록을 지울 수 있는 권한이 기록을 남기는 사람과 같은 손에 있다면, 그 기록은 증거로서의 무게를 잃습니다.

계정 분리와 최소 권한과 기록 보존은 따로 떨어진 세 조치가 아니라 하나의 묶음으로 보시는 게 좋아요. 서버 보안을 어디서부터 시작하냐는 질문에 계정과 권한이 먼저 나오는 이유도 여기에 있어요. 계정·권한 관리 기준을 더 살펴보고 싶다면 한국인터넷진흥원(KISA)이 공개하는 보안 가이드에서 확인할 수 있어요.

이제 이렇게 하시면 돼요. 먼저 공용으로 쓰는 계정이 있는지 목록을 뽑아 사람 단위로 나눠 보세요. 그다음 역할을 서너 개만 정의해서 권한을 묶고, 인사 변동 시점에 권한 조정을 붙여 두시면 돼요. 여기까지만 해도 로그가 증거로서 힘을 갖게 되고, 다음에 올리는 조치들이 제 역할을 하기 시작해요. 한 번에 완벽하게 만들 필요는 없어요. 오늘 계정 목록 하나 뽑아 보는 것만으로도 출발선은 충분히 넘은 거예요. 이제 여러분 차례예요.