서버 계정을 점검하다 보면 "sudo 권한을 누가 가지고 있는지 아무도 정확히 모른다"는 상황을 자주 만납니다. 프로젝트가 끝난 뒤에도 배포용 그룹은 그대로 남고, 퇴사자 계정은 지워지지 않으며, 편의를 위해 추가한 NOPASSWD 한 줄이 몇 년째 유지되기도 합니다. ISMS-P 심사에서도 이런 권한이 왜 필요한지, 누가 승인했는지 설명하지 못하면 지적으로 이어지기 쉽습니다.
이 글에서는 sudoers 파일과 /etc/sudoers.d 항목, 그룹 기반 권한 부여 현황을 명령어로 확인하는 방법을 정리합니다. 이어서 업무상 필요 없는 NOPASSWD와 ALL 권한을 찾아 줄이고, 변경 근거를 남기는 순서까지 따라 할 수 있도록 구성했습니다. 명령어는 Ubuntu·Debian과 RHEL 계열을 기준으로 하며, 배포판에 따라 그룹 이름과 로그 경로가 다를 수 있습니다.
점검 전에 정해 둘 기준
sudo 점검은 명령어를 치기 전에 기준을 정해야 결과를 해석할 수 있습니다. 가장 먼저 "이 서버에서 root 권한이 업무상 필요한 계정은 누구인가"를 목록으로 만듭니다. 인사 기록이나 계정 신청 기록과 대조하면 퇴사자, 전배자, 임시 계정이 함께 드러납니다.
기준이 없으면 "혹시 몰라서"라는 이유로 권한이 계속 늘어납니다. 최소권한 원칙은 작업에 필요한 명령만, 필요한 기간 동안, 필요한 사람에게 주는 것입니다. 이 문장을 점검표의 판단 기준으로 쓰면 이후 판단이 훨씬 빨라집니다.
sudoers 파일과 /etc/sudoers.d 확인하기
sudo 권한은 대부분 /etc/sudoers 본 파일이나 /etc/sudoers.d/ 디렉터리 아래 파일에 정의됩니다. 본 파일에 #includedir /etc/sudoers.d 줄이 있어야 디렉터리의 파일이 읽힙니다. 먼저 두 위치의 목록과 파일 상태부터 확인합니다.
sudo ls -l /etc/sudoers /etc/sudoers.d/
소유자는 root, 권한은 440이 기본입니다. 다르게 설정된 파일이 있다면 누가 언제 수정했는지부터 확인해야 합니다. 또한 파일 이름에 점(.)이 들어가거나 물결표(~)로 끝나는 파일은 sudo가 무시합니다. backup.old나 deploy~ 같은 파일은 적용되지 않지만 점검에서 빠지기 쉬우니, 목록에 함께 올려 두고 필요 없으면 삭제합니다.
그룹 기반 권한 부여 현황 확인하기
sudo 권한은 사용자 한 명에게 직접 주기보다 그룹 단위로 주는 경우가 많습니다. Ubuntu·Debian은 sudo 그룹, RHEL 계열은 wheel 그룹을 기본으로 사용합니다. 그룹에 들어 있는 계정이 누구인지 먼저 확인해야 실제 권한 보유자를 알 수 있습니다.
getent group sudo 또는 getent group wheel로 그룹 구성원을 봅니다. 특정 계정이 어떤 규칙을 받는지는 sudo -l -U 계정명으로 확인합니다. 이 명령은 root 권한이 필요하며, 출력에 나온 규칙이 그 계정에 실제 적용되는 규칙입니다.
그룹 외에도 sudoers 파일에 사용자 이름이나 별도 그룹(예: %deploy)이 직접 적혀 있는 경우가 많습니다. 그룹 목록만 보고 끝내면 빠지는 계정이 생기므로, 규칙 파일과 그룹 목록을 함께 대조해야 합니다.
NOPASSWD와 ALL 규칙 찾아내기
NOPASSWD는 sudo 실행 시 비밀번호 입력을 생략하는 설정입니다. 자동화 스크립트나 배포 계정에 편의상 넣는 경우가 많지만, 계정이 탈취되면 root 명령을 즉시 실행할 수 있게 됩니다. ALL은 대상 명령을 제한하지 않는다는 뜻이며, 두 가지가 함께 있으면 가장 위험한 조합입니다.
sudo grep -rnE "NOPASSWD|ALL" /etc/sudoers /etc/sudoers.d/
위 명령으로 후보를 뽑은 뒤 주석 줄(#으로 시작하는 줄)은 제외합니다. 결과는 주체(사용자 또는 그룹), 대상 호스트, 실행 가능 명령, 비밀번호 필요 여부의 네 가지를 한 줄씩 기록하면 판단이 쉬워집니다.
가상의 예시입니다. 한 개발 서버에서 2년 전 배포용으로 만든 deploy 그룹이 "%deploy ALL=(ALL) NOPASSWD: ALL" 규칙으로 남아 있었습니다. 그룹 구성원을 확인해 보니 프로젝트 종료 후 합류했던 외주 계정 세 개가 들어 있었고, 실제 배포는 스크립트 한 개로 충분했습니다. 규칙을 배포 스크립트 경로만 허용하도록 바꾸고 외주 계정을 그룹에서 뺀 뒤, 점검 기록에 사유를 남겼습니다.
자동화 계정의 NOPASSWD는 따로 본다
배치나 배포 자동화에 NOPASSWD가 필요한 경우는 실제로 있습니다. 다만 이때도 원칙은 명령을 특정 스크립트 한두 개로 제한하는 것입니다. ALL 대신 필요한 명령의 절대 경로만 적어 두면 나중에 권한 범위를 설명하기도 훨씬 수월합니다.
업무 필요성 판단 기준과 조치 방법
모든 규칙을 한꺼번에 지우면 장애가 생깁니다. 규칙마다 업무 근거가 있는지, 실제 사용 기록이 있는지를 함께 보고 조치 수준을 나눕니다. 아래 표는 현장에서 자주 쓰는 판단 기준입니다.
| 구분 | 확인된 상태 | 판단 | 조치 |
|---|---|---|---|
| 퇴사·전배 계정이 그룹에 남음 | 인사 기록과 계정 상태 불일치 | 업무상 불필요 | 그룹에서 제거하고 계정 잠금 |
| ALL + NOPASSWD, 업무 불명 | 소유자 확인 안 됨 | 축소 대상 | 명령 범위를 제한하고 소유자에게 확인 |
| 배포 자동화 계정의 NOPASSWD | 특정 스크립트만 실행 | 필요 가능 | 명령을 절대 경로로 한정 |
| 확인 기간 내 사용 기록 없음 | sudo 로그 검색 결과 0건 | 회수 검토 | 소유자 승인 후 규칙 제거 |
| 운영자의 일상 관리 업무 | 비밀번호 입력 후 실행 | 유지 | 명령 범위와 승인 근거를 기록 |
사용 여부는 로그로 확인합니다. Ubuntu·Debian은 보통 /var/log/auth.log, RHEL 계열은 /var/log/secure에 sudo 실행 기록이 남습니다. 배포판과 rsyslog 설정에 따라 다를 수 있으니 sudo grep sudo /var/log/auth.log처럼 경로를 먼저 확인하세요. 로그가 로테이션되어 기간이 짧다면 확인 가능한 기간을 보고서에 함께 적습니다.
바로 해 볼 순서 5단계
- 서버별 sudoers 본 파일과 sudoers.d 목록을 수집하고, 소유자(root)와 권한(440)을 확인합니다.
- getent group sudo, wheel로 그룹 구성원을 뽑고, 각 계정에 sudo -l -U로 실제 규칙을 확인합니다.
- NOPASSWD와 ALL 규칙을 grep으로 추출해 주체, 대상, 명령, 비밀번호 여부를 표로 정리합니다.
- 퇴사·전배·미사용 계정을 인사 기록과 계정 신청 기록에 대조하고, 소유자에게 업무 근거를 확인합니다.
- visudo로 수정한 뒤 visudo -c로 문법을 검사하고, 변경 전후 내용과 승인자를 증적으로 남긴 다음 같은 점검을 정기 일정에 넣습니다.
변경 적용과 증적 남기기
sudoers는 문법 오류가 나면 sudo 자체가 막힐 수 있습니다. 수정은 반드시 visudo로 하고, 저장 전에 문법 검사를 거칩니다. 변경 작업 중에는 root 세션이나 서버 콘솔을 하나 열어 둬서, 실수했을 때 되돌릴 경로를 남겨 둡니다.
변경 전 백업을 남기고, 변경 후에는 전후 차이를 기록합니다. 점검 기록에는 대상 계정, 변경 전 규칙, 변경 후 규칙, 승인자, 날짜를 포함합니다. ISMS-P의 계정·권한 관리 항목은 권한의 부여, 변경, 회수에 승인 근거가 있는지와 정기적으로 권한을 검토했는지를 보므로, 이 기록이 곧 심사 증적이 됩니다. 관련 인증기준의 항목 번호는 최신 KISA 인증기준 문서에서 직접 확인하시기 바랍니다.
자주 묻는 질문
NOPASSWD를 모두 없애면 자동화가 깨지지 않나요?
깨질 수 있습니다. 그래서 자동화 계정은 명령을 절대 경로의 스크립트로 한정하고, 변경 전에 해당 작업을 테스트 서버에서 한 번 실행해 봅니다. 일괄 제거보다 서비스 단위로 나눠 적용하면 문제가 생겼을 때 되돌릴 범위가 줄어듭니다.
sudo -l 결과가 비어 있으면 안전한 건가요?
해당 계정이 sudo 규칙을 받지 않는다는 뜻입니다. sudo -l 출력에는 그룹으로 받은 규칙도 포함되지만, 중앙 인증 서버처럼 서버 밖에서 관리되는 sudo 규칙은 이 서버의 파일에 나타나지 않습니다. 이런 구조를 쓰는 환경이라면 관리 도구의 정책도 함께 확인해야 합니다.
정기 점검은 얼마나 자주 해야 하나요?
주기는 조직의 정책과 ISMS-P 내부 관리계획에서 정하는 것이 맞습니다. 정한 주기에 맞춰 같은 명령 세트를 스크립트로 묶어 두면 기록을 일관되게 남기기 좋습니다. 점검 결과는 파일로 저장하되, 점검 스크립트는 권한이 제한된 경로에 두시기 바랍니다.
정리
- sudo 권한은 sudoers 본 파일, /etc/sudoers.d, 그룹 구성원을 함께 대조해야 실제 상태가 보입니다.
- NOPASSWD와 ALL은 업무 근거와 사용 로그를 확인한 뒤, 명령 경로를 한정하거나 회수합니다.
- visudo 검사와 변경 기록을 남기면 조치가 곧 ISMS-P 계정·권한 관리의 증적이 됩니다.
오늘 할 일: 운영 서버 한 대를 골라 getent group sudo 결과의 계정마다 sudo -l -U를 실행하고, 퇴사·미사용 의심 계정을 목록으로 만들어 보세요.
댓글