리눅스 서버를 운영하다 보면 root 계정을 직접 쓰기보다 sudo 로 필요한 작업만 수행하는 방식이 기본이 된다. 문제는 sudo 를 편하게만 쓰다 보면 권한이 너무 넓어지거나, 누가 어떤 명령을 실행했는지 추적이 어려워지는 경우가 많다는 점이다.

이번 글에서는 리눅스에서 sudo 권한을 조금 더 안전하게 운영하는 실무 기준을 정리해본다. 개인 서버부터 팀 서버까지 공통으로 적용하기 좋다.

왜 sudo 관리가 중요한가

sudo 는 단순히 “관리자 권한 실행 명령”이 아니다. 실제로는 다음 세 가지를 동시에 다루는 보안 도구에 가깝다.

  • 누가 관리자 작업을 할 수 있는가
  • 어떤 범위까지 허용할 것인가
  • 실행 이력을 어떻게 남길 것인가

즉, sudo 설정이 느슨하면 root 비밀번호를 여러 사람이 공유하는 것과 비슷한 문제가 생길 수 있다.

1. root 직접 사용보다 sudo 기반 운영이 좋은 이유

대부분의 환경에서는 root 계정으로 상시 로그인하는 것보다 일반 계정 + sudo 조합이 안전하다.

장점은 분명하다.

  • 사용자별 작업 이력을 구분하기 쉽다
  • 필요할 때만 권한 상승이 이뤄진다
  • 특정 사용자에게 필요한 범위만 위임할 수 있다
  • SSH 설정과 결합하면 root 직접 로그인 차단이 가능하다

예를 들어 SSH 보안 정책에서 다음과 같이 root 직접 로그인을 막고, 관리자 계정만 공개키 인증으로 접속시키는 구성이 흔하다.

PermitRootLogin no 
PasswordAuthentication no 
PubkeyAuthentication yes

2. sudo 권한은 사용자 단위보다 그룹 단위가 관리하기 쉽다

운영자가 여러 명인 환경에서는 개별 사용자마다 권한을 늘려가는 방식보다 그룹 단위 관리가 훨씬 깔끔하다.

우분투 계열에서는 보통 sudo 그룹, RHEL 계열에서는 wheel 그룹을 사용한다.

# Debian/Ubuntu 계열 예시
sudo usermod -aG 
sudo deploy 
# RHEL/CentOS/Rocky 계열 예시
sudo usermod -aG wheel deploy

이 방식의 장점은 사람이 바뀌거나 계정이 추가될 때 정책을 다시 짤 필요가 적다는 점이다. 

권한은 그룹에 묶고, 사용자는 그 그룹에 넣거나 빼는 식으로 관리하면 된다.

3. /etc/sudoers 를 직접 편집하지 말고 visudo 를 사용하자

sudoers 파일 문법이 깨지면 관리자 권한 자체가 막힐 수 있다. 

그래서 직접 편집기만 열어 수정하기보다 visudo 를 사용하는 편이 안전하다.

sudo visudo

"visudo"는 저장 전에 문법 검사를 해주기 때문에 실수를 줄여준다.

실무에서는 메인 파일 하나에 모든 설정을 몰아넣기보다 /etc/sudoers.d/ 아래에 역할별 파일을 나눠 두는 편이 관리가 쉽다.

예를 들면:

sudo visudo -f /etc/sudoers.d/deploy

그리고 파일 안에는 필요한 최소 권한만 넣는다.

deploy ALL=(ALL) /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx

이렇게 하면 deploy 사용자는 nginx 재시작과 상태 확인만 할 수 있고, 모든 관리자 명령을 마음대로 실행할 수는 없다.

4. NOPASSWD 는 정말 필요한 명령에만 제한적으로

자동화 때문에 NOPASSWD 를 쓰는 경우가 있다. 

문제는 이 옵션을 너무 넓게 열어두면 사실상 무제한 관리자 권한과 비슷해질 수 있다는 점이다.

위험한 예시는 이런 식이다.

deploy ALL=(ALL) NOPASSWD: ALL

이 설정은 편하지만 보안 관점에서는 추천하기 어렵다.

대신 자동화가 필요한 명령만 좁혀서 허용하는 편이 낫다.

deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart myapp, /usr/bin/systemctl status myapp

핵심은 계정 전체가 아니라 명령 단위로 위임하는 것이다.

5. sudo 로그를 반드시 확인할 수 있어야 한다

권한 통제만큼 중요한 게 추적성이다. 누가 언제 어떤 명령을 실행했는지 확인할 수 있어야 사고 대응이 쉬워진다.

배포판에 따라 다음 경로에서 흔히 확인한다.

# Debian/Ubuntu
sudo tail -n 100 /var/log/auth.log
# RHEL 계열 
sudo tail -n 100 /var/log/secure

systemd 기반 환경에서는 journal 조회도 유용하다.

sudo journalctl _COMM=sudo -n 100

정기적으로 봐야 할 포인트는 다음과 같다.

  • 반복적인 인증 실패가 있는가
  • 평소 쓰지 않던 계정이 sudo 를 실행했는가
  • 야간 시간대 등 비정상 패턴이 있는가
  • 자동화 계정이 예상 밖 명령을 실행했는가

6. 팀 운영이라면 공용 계정보다 개인 계정을 쓰는 편이 낫다

작은 팀에서는 admin 같은 공용 계정을 함께 쓰는 경우가 있다. 

하지만 이런 방식은 누가 작업했는지 구분이 어려워진다.

가능하면 다음 원칙을 지키는 편이 좋다.

  • 관리자마다 개인 계정을 따로 발급
  • SSH 공개키도 개인별로 관리
  • 퇴사/권한 회수 시 계정 단위로 즉시 차단
  • sudo 권한은 그룹 또는 역할 파일로 통제

이렇게 해야 감사 추적과 권한 회수가 쉬워진다.

7. 최소 권한 원칙으로 다시 점검해보기

현재 서버에서 sudo 설정이 이미 돌아가고 있다면, 아래 질문으로 한 번 점검해볼 수 있다.

  1. root 직접 SSH 로그인은 막혀 있는가
  2. 관리자 권한이 필요한 사용자만 sudo 그룹에 들어가 있는가
  3. /etc/sudoers.d/ 로 역할을 분리했는가
  4. NOPASSWD: ALL 같은 과도한 설정이 없는가
  5. sudo 실행 로그를 정기적으로 확인하고 있는가

이 다섯 가지만 정리해도 운영 리스크를 꽤 줄일 수 있다.

마무리

리눅스 보안은 방화벽이나 SSH 설정만으로 끝나지 않는다. 

실무에서는 누가 관리자 권한을 어떻게 쓰는지가 더 중요한 순간이 많다.

sudoers 를 대충 열어두면 평소에는 편해 보여도, 문제 발생 시 원인 파악과 복구가 훨씬 어려워진다. 

반대로 그룹 기반 권한 관리, 최소 권한 위임, 로그 점검 습관만 잡아도 작은 서버부터 운영 품질이 꽤 안정된다.

서버를 한 번 점검할 계획이라면, 오늘은 방화벽보다 먼저 sudo 설정부터 확인해보는 걸 추천한다.