리눅스 사용자와 그룹 관리 방식 및 서버 보안과의 관계

리눅스 서버를 운영하는 과정에서 사용자와 그룹 관리는 가장 기초적이면서도 동시에 가장 중요한 보안 영역에 속한다. 다중 사용자 운영체제로 설계된 리눅스는 처음부터 여러 사용자가 하나의 시스템 자원을 공유하되, 서로의 파일과 프로세스에 함부로 접근하지 못하도록 하는 권한 분리 구조를 근간으로 삼고 있다. 이 글에서는 리눅스의 사용자 및 그룹 관리 체계가 실제로 어떻게 동작하는지, 그리고 이러한 관리 방식이 서버 보안과 구체적으로 어떤 연관성을 가지는지를 체계적으로 살펴본다.

 

 

 

 

 

 

 

 

리눅스 사용자 관리의 기본 구조

 

리눅스 시스템에서 사용자 정보는 기본적으로 /etc/passwd 파일에 저장된다. 이 파일의 각 행은 콜론으로 구분된 여러 필드로 구성되며, 사용자 이름, 패스워드 표시 필드, 사용자 식별번호인 UID, 소속 그룹 식별번호인 GID, 사용자 설명, 홈 디렉터리 경로, 로그인 시 사용할 셸 정보가 순서대로 기록된다. 과거에는 이 파일에 암호화된 패스워드 값이 직접 저장되었으나, 현재 대부분의 배포판에서는 보안을 강화하기 위해 실제 패스워드 해시값을 /etc/shadow 파일로 분리하여 관리한다.

 

이렇게 분리하는 이유는 /etc/passwd 파일은 시스템의 여러 프로그램이 사용자 정보를 조회할 수 있도록 일반적으로 읽기 권한이 넓게 열려 있는 반면, /etc/shadow 파일은 오직 관리자 권한을 가진 프로세스만 읽을 수 있도록 제한되어 있기 때문이다. 만약 패스워드 해시값이 /etc/passwd에 그대로 남아 있었다면, 일반 사용자 권한만으로도 해시값을 확보하여 오프라인 무차별 대입 공격을 시도할 수 있는 여지가 커진다. 이러한 구조적 분리는 리눅스 보안 설계에서 최소 권한 원칙이 어떻게 실제 파일 시스템 수준에서 구현되는지를 보여주는 대표적인 사례라 할 수 있다.

 

 

 

▍ UID와 GID, 그리고 권한 판별의 원리

 

리눅스 커널은 사용자를 이름이 아니라 숫자로 된 UID를 통해 식별한다. 마찬가지로 그룹 역시 GID라는 숫자값으로 식별된다. 사람이 읽기 쉬운 사용자명이나 그룹명은 어디까지나 사람을 위한 표현 방식일 뿐이며, 실제 파일 시스템이나 프로세스 권한 검사는 전적으로 이 숫자값을 기준으로 이루어진다. 이 때문에 동일한 UID를 가진 서로 다른 계정명이 존재한다면 커널 입장에서는 사실상 같은 사용자로 취급될 수 있다는 점을 관리자는 반드시 인지하고 있어야 한다.

 

일반적으로 UID 0번은 시스템 전체에 대한 무제한적 접근 권한을 가진 루트 계정에 할당되어 있다. 시스템 서비스 운용을 위한 계정들은 통상 낮은 번호대의 UID를 부여받고, 일반 사용자 계정은 배포판에 따라 정해진 기준값 이상의 UID를 할당받는 것이 관례다. 이러한 구분은 강제되는 규칙이라기보다는 관습적인 설계이지만, 여러 배포판과 관리 도구들이 이 관례를 전제로 동작하기 때문에 임의로 UID 범위를 어기는 계정 생성은 예기치 못한 권한 문제를 일으킬 수 있다.

 

 

 

 

 

 

▍ 그룹 관리와 보조 그룹의 역할

 

리눅스에서 각 사용자는 하나의 기본 그룹과 여러 개의 보조 그룹에 동시에 소속될 수 있다. 기본 그룹 정보는 /etc/passwd 파일의 GID 필드에 기록되며, 사용자가 새로운 파일을 생성할 때 해당 파일의 소유 그룹으로 자동 지정된다. 보조 그룹 소속 정보는 /etc/group 파일에서 관리되며, 사용자가 특정 자원에 대한 그룹 단위 접근 권한을 추가로 얻고자 할 때 활용된다.

 

실무에서 그룹을 어떻게 설계하느냐는 서버 보안 수준에 직접적인 영향을 미친다. 예를 들어 여러 사용자가 협업 목적으로 동일한 디렉터리에 접근해야 하는 경우, 개별 사용자마다 파일 소유권을 넘기는 방식보다는 전용 그룹을 만들고 해당 그룹에 필요한 사용자만 소속시킨 뒤 디렉터리 권한을 그룹 단위로 제어하는 방식이 훨씬 안전하고 관리하기 쉽다. 이런 방식은 개별 계정의 증가나 퇴사, 직무 변경 등의 상황에서도 그룹 소속 관계만 조정하면 되므로 권한 관리의 일관성을 유지하는 데 유리하다.

 

 

 

파일 권한 체계와 특수 권한 비트

 

리눅스의 파일 접근 제어는 소유자, 소유 그룹, 그 외 사용자라는 세 가지 범주에 대해 각각 읽기, 쓰기, 실행 권한을 부여하는 방식으로 이루어진다. 이는 흔히 숫자 표기법으로 나타내며, 예를 들어 644라는 권한은 소유자에게는 읽기와 쓰기, 그룹과 기타 사용자에게는 읽기 권한만 부여함을 의미한다. 이러한 기본 권한 체계 외에도 리눅스는 특수한 목적을 위한 세 가지 추가 권한 비트를 제공한다.

 

Set-UID는 실행 파일에 부여할 경우 그 파일을 실행하는 사용자가 누구든 파일 소유자의 권한으로 프로그램이 동작하도록 만드는 속성이다. 대표적으로 패스워드 변경 명령어가 이 속성을 사용하는데, 일반 사용자가 실행하더라도 내부적으로는 shadow 파일을 수정할 수 있는 권한으로 동작해야 하기 때문이다. Set-GID는 유사한 원리를 그룹 권한에 적용하며, 디렉터리에 설정될 경우에는 그 안에 새로 생성되는 파일이 자동으로 해당 디렉터리의 그룹 소유권을 상속받도록 한다. 스티키 비트는 주로 여러 사용자가 공동으로 쓰기 권한을 가지는 디렉터리에 적용되며, 디렉터리 안의 파일을 다른 사용자가 삭제하거나 이름을 바꾸지 못하도록 제한하여 본인이 생성한 파일만 삭제할 수 있게 만든다.

 

이러한 특수 권한 비트는 편리한 기능을 제공하지만 동시에 대표적인 권한 상승 공격의 표적이 되기도 한다. 특히 Set-UID가 설정된 실행 파일 가운데 루트 소유의 프로그램에 취약점이 존재할 경우, 공격자는 이를 악용하여 일반 사용자 권한에서 관리자 권한으로 상승할 수 있는 경로를 얻게 된다. 이 때문에 다수의 보안 점검 항목에서는 시스템 전반에 걸쳐 불필요한 Set-UID, Set-GID 파일을 주기적으로 탐색하고 제거하도록 권고하고 있다.

 

아래 표는 세 가지 특수 권한 비트의 적용 대상과 효과를 간단히 정리한 것이다.

 

 

 

 

이처럼 특수 권한은 시스템 운영에 필요한 기능을 제공하는 동시에 관리가 소홀할 경우 심각한 보안 허점으로 이어질 수 있다는 양면성을 지닌다.

 

 

 

 

 

 

루트 권한 관리와 최소 권한 원칙

 

서버 보안에서 가장 근본적인 원칙 가운데 하나는 최소 권한 원칙이다. 즉 각 사용자와 프로세스는 자신의 업무 수행에 필요한 최소한의 권한만을 가져야 한다는 것이다. 리눅스 환경에서 이 원칙을 실현하는 대표적인 방법이 바로 루트 계정의 직접 로그인을 제한하고, 대신 일반 계정으로 로그인한 뒤 필요할 때만 관리자 권한을 일시적으로 획득하도록 하는 방식이다.

 

이를 위해 흔히 사용되는 도구가 sudo이다. sudo는 지정된 사용자나 그룹에 한해 특정 명령을 관리자 권한으로 실행할 수 있도록 세밀하게 통제할 수 있으며, 각 명령의 실행 기록을 로그로 남긴다는 장점이 있다. 이는 단순히 su 명령으로 루트 계정에 완전히 전환하는 방식과 비교했을 때, 누가 언제 어떤 관리 작업을 수행했는지 추적할 수 있다는 점에서 감사 측면의 이점이 크다. 다수의 서버 보안 가이드에서는 루트 계정의 원격 SSH 직접 로그인을 비활성화하고, 관리 작업이 필요한 사용자에게는 개별 계정과 sudo 권한을 부여하는 방식을 권장하고 있다.

 

또한 계정 자체의 위험 노출을 줄이기 위해 사용하지 않는 계정, 특히 시스템 설치 시 기본으로 생성되었으나 실제로는 사용되지 않는 서비스 계정의 로그인 셸을 nologin이나 false로 설정하여 대화형 로그인을 원천 차단하는 것도 일반적인 보안 관행이다. 이렇게 하면 해당 계정의 패스워드가 유출되더라도 공격자가 셸을 통해 직접 시스템에 접근하는 경로를 차단할 수 있다.

 

 

 

패스워드 정책과 계정 잠금 메커니즘

 

사용자 계정 관리에서 패스워드 정책은 서버 보안의 첫 관문 역할을 한다. 리눅스는 PAM이라는 인증 모듈 프레임워크를 통해 패스워드의 최소 길이, 복잡도, 만료 주기, 재사용 제한 등을 유연하게 설정할 수 있도록 지원한다. 아울러 로그인 실패 횟수가 일정 기준을 넘으면 해당 계정을 일시적으로 잠그는 기능도 PAM 모듈을 통해 구현할 수 있는데, 이는 무차별 대입 공격에 대한 효과적인 방어 수단이 된다.

 

패스워드 만료 정책과 관련해서는 /etc/login.defs 파일이나 chage 명령을 통해 계정별로 패스워드 유효 기간, 만료 전 경고 일수, 만료 후 계정 비활성화까지의 유예 기간 등을 세밀하게 조정할 수 있다. 다만 지나치게 짧은 주기로 패스워드 변경을 강제하는 정책은 오히려 사용자가 예측 가능한 패턴으로 패스워드를 변경하게 만들어 보안성을 떨어뜨릴 수 있다는 지적도 있으므로, 조직의 상황에 맞는 균형 잡힌 정책 수립이 필요하다.

 

 

 

▍ 사용자 관리와 접근 통제의 연계

 

사용자와 그룹 관리는 그 자체로 끝나는 것이 아니라 시스템 전반의 접근 통제 체계와 유기적으로 연결된다. 예를 들어 방화벽 규칙이나 애플리케이션 수준의 접근 제어가 아무리 정교하게 구성되어 있다 하더라도, 서버 내부의 계정 관리가 허술하다면 공격자가 일단 하나의 계정을 탈취한 이후 손쉽게 권한을 확장하거나 다른 시스템 자원에 접근할 수 있는 경로가 열리게 된다.

 

이러한 맥락에서 최근에는 전통적인 UID·GID 기반 권한 체계의 한계를 보완하기 위한 다양한 접근 통제 기술이 함께 사용되는 경우가 많다. SELinux나 AppArmor와 같은 강제적 접근 통제 프레임워크는 단순히 사용자 신원에 기반한 권한 부여를 넘어, 프로세스가 수행할 수 있는 구체적인 행위 자체를 정책으로 제한한다. 또한 리눅스 커널의 capabilities 기능은 전통적으로 루트 권한에 통합되어 있던 다양한 관리 기능을 세분화된 단위로 나누어, 특정 프로세스에 필요한 최소한의 권한만을 선별적으로 부여할 수 있도록 지원한다. 예를 들어 커널 모듈을 적재하거나 제거하는 권한만을 별도로 부여하고 그 외의 관리자 권한은 제한하는 방식이 가능한데, 이는 전체 시스템을 장악할 수 있는 단일 권한 대신 필요한 기능만 세밀하게 나누어 위험을 분산시키는 접근이라 할 수 있다.

 

 

 

 

 

 

▍ 계정 관리 소홀이 초래하는 대표적인 위험

 

실제 서버 침해 사고 사례를 살펴보면 사용자 및 그룹 관리 소홀에서 비롯된 문제가 상당한 비중을 차지한다. 대표적으로 퇴사자 계정이나 프로젝트 종료 후 사용하지 않는 계정을 즉시 삭제하거나 비활성화하지 않고 방치하는 경우, 이러한 유휴 계정은 공격자에게 발견되지 않은 침입 경로로 악용될 가능성이 높아진다. 또한 여러 사용자가 하나의 공용 계정을 공유하는 관행 역시 문제가 생겼을 때 책임 소재를 규명하기 어렵게 만들고, 패스워드 유출 위험도 함께 커진다는 점에서 지양해야 할 방식으로 꼽힌다.

 

파일 및 디렉터리 권한 설정의 오류도 흔히 발생하는 문제다. 웹 서버가 실행되는 계정에 필요 이상의 쓰기 권한을 부여하거나, 설정 파일에 누구나 읽을 수 있는 권한이 부여되어 데이터베이스 접속 정보와 같은 민감한 값이 노출되는 사례는 실무에서 드물지 않게 발견된다. 이런 유형의 문제는 대개 초기 설정 당시의 편의성을 우선시한 결과로 발생하며, 시간이 지나면서 점검이 이루어지지 않은 채 방치되는 경향이 있다.

 

다음 표는 사용자 및 그룹 관리 측면에서 흔히 발생하는 취약 사례와 그에 대응하는 일반적인 관리 방향을 정리한 것이다.

 

 

 

 

 

 

▍ 로그 관리와 사용자 활동 추적

 

사용자 관리 체계가 아무리 견고하게 설계되어 있다 하더라도, 실제로 어떤 사용자가 어떤 작업을 수행했는지 추적할 수 있는 로그 체계가 뒷받침되지 않는다면 사고 발생 시 원인 규명이 어려워진다. 리눅스 시스템은 로그인 및 로그아웃 기록, 명령 실행 이력, 시스템 이벤트 등을 다양한 로그 파일과 데몬을 통해 기록한다. 개인 사용자 단위에서는 셸 히스토리 파일이 실행된 명령의 이력을 남기며, 시스템 전반의 인증 관련 로그는 별도의 로그 파일을 통해 관리자만 접근할 수 있는 형태로 보관되는 것이 일반적이다.

 

다중 사용자 환경에서 로그 관리의 중요성은 단순한 기록 보관을 넘어선다. 계정별 활동 이력이 명확하게 남아 있어야 이상 징후를 조기에 발견할 수 있으며, 침해 사고가 발생했을 때 피해 범위를 정확히 파악하고 후속 대응을 신속하게 진행할 수 있다. 이런 이유로 다수의 보안 인증 체계나 규제 지침에서는 계정별 활동 로그의 수집과 일정 기간 보관을 요구사항으로 명시하고 있다.

 

 

 

결론

 

리눅스의 사용자와 그룹 관리 방식은 단순히 계정을 생성하고 삭제하는 행정적인 작업이 아니라, 서버 전체의 보안 수준을 결정짓는 근간이 되는 체계다. UID와 GID를 통한 신원 식별, 파일 권한 체계와 특수 권한 비트의 정교한 활용, 최소 권한 원칙에 입각한 루트 권한 관리, 그리고 이를 뒷받침하는 패스워드 정책과 로그 관리에 이르기까지, 이 모든 요소들은 서로 밀접하게 연결되어 하나의 방어 체계를 이룬다.

 

특히 서버 운영 환경이 복잡해지고 다수의 사용자와 서비스 계정이 공존하는 오늘날에는, 초기 설계 단계에서부터 사용자와 그룹 구조를 명확히 계획하고 정기적으로 점검하는 습관이 무엇보다 중요하다. 사소해 보이는 계정 하나, 권한 설정 하나가 전체 시스템의 보안을 좌우할 수 있다는 점을 염두에 두고, 지속적인 관리와 검토를 이어가는 것이 안전한 리눅스 서버 운영의 핵심이라 할 수 있다.