사용자 계정 생성 및 보조 그룹 바인딩

리눅스에서 다중 사용자 환경을 구축하고 권한을 분리할 때 사용되는 핵심 사용자 관리 명령어 실무입니다.

• useradd --create-home (또는 -m): 사용자를 새로 생성할 때 홈 디렉토리를 물리적으로 함께 자동 생성해 주는 핵심 옵션입니다. 이 옵션이 없으면 사용자는 로그인 시 홈 디렉토리가 없어 루트 디렉토리 /나 갈 곳 없는 가상 터미널 환경에 갇히게 됩니다.
  로컬 터미널

  $ sudo useradd --create-home alice
  

  복사
• usermod -aG: 사용자의 기본 그룹을 유지하면서 추가적인 보조 그룹(예: sudo 또는 developers 등)에 안전하게 바인딩할 때 사용합니다. -a (append) 옵션이 누락되면 기존의 모든 보조 그룹 연동 정보가 전량 증발하는 대참사가 납니다.
  로컬 터미널

  $ sudo usermod -aG sudo alice
  

  복사
• id: 사용자의 현재 보안 식별자 정보(uid, gid, 소속된 groups 목록)를 콘솔에 직관적으로 매핑하여 출력하는 검증 도구입니다.
  로컬 터미널

  $ id alice
  uid=1001(alice) gid=1001(alice) groups=1001(alice),27(sudo)
  

  복사

서버에서 특정 사용자가 갑자기 로그인이 안 된다는 제보가 들어왔을 때, 또는 새로 만든 계정이 docker 명령을 못 쓴다고 할 때 — 첫 번째로 확인해야 할 것이 이 세 파일입니다. Linux는 사용자 정보를 데이터베이스가 아닌 텍스트 파일로 관리하고, 각 파일이 다른 역할을 담당합니다. 이 파일들을 직접 읽을 줄 알면, id 명령 출력이 왜 그렇게 나오는지, 그룹 추가가 왜 바로 반영되지 않는지, 패스워드가 어디에 어떤 형태로 저장되는지를 모두 직접 확인할 수 있습니다.

Linux의 사용자 정보는 세 개의 텍스트 파일에 나뉘어 저장됩니다.

/etc/passwd — 사용자 계정 데이터베이스

모든 사용자(사람 + 시스템 계정)가 한 줄씩 기록됩니다.

username:x:UID:GID:comment:home_dir:shell

실제 예시를 보면 다음과 같습니다.

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
deploy:x:1001:1001:서비스 배포 계정:/home/deploy:/bin/bash

UID 범위별 역할

UID 숫자 범위에 따라 계정의 유형이 구분됩니다. 이 범위를 알면 낯선 시스템에서 /etc/passwd를 봤을 때 어떤 계정이 사람용이고 어떤 게 데몬용인지 바로 판별할 수 있습니다.

두 번째 필드가 x인 것에 주목하세요. 실제 패스워드 해시는 여기에 없습니다.

/etc/shadow — 패스워드 해시 분리 저장

과거에는 패스워드 해시가 /etc/passwd에 직접 들어 있었습니다. 이 파일은 누구나 읽을 수 있기 때문에 오프라인 크래킹 공격에 노출됐습니다. 현대 Linux는 해시를 /etc/shadow로 분리하고, root만 읽을 수 있도록 권한을 640 또는 000으로 제한합니다.

username:$hash:last_change:min:max:warn:inactive:expire:reserved

deploy:$6$rounds=656000$salt$longhashstring...:19800:0:99999:7:::

각 필드의 의미입니다.

• $6$... — SHA-512 해시 (알고리즘 번호 6)
• 19800 — 마지막 패스워드 변경일 (1970-01-01 기준 일수)
• 99999 — 패스워드 최대 유효 기간 (일)
• 7 — 만료 7일 전부터 경고

보안 원칙: /etc/shadow는 절대 직접 편집하지 마세요. passwd, chage, usermod 명령을 사용하면 형식 오류 없이 안전하게 수정할 수 있습니다.

/etc/group — 그룹 멤버십

그룹 정보는 /etc/group 파일에 저장됩니다. 각 줄이 하나의 그룹이며, 쉼표로 구분된 사용자 목록이 마지막 필드에 옵니다.

groupname:x:GID:member1,member2,...

docker:x:998:alice,deploy
sudo:x:27:alice

사용자는 하나의 **주 그룹(primary group)**과 여러 개의 **보조 그룹(supplementary group)**에 속할 수 있습니다. 파일에 접근할 때 커널은 이 목록 전체를 확인합니다.

배포 서버에 접속해서 Nginx를 재시작해야 하는데, 현재 계정으로는 권한이 없습니다. 이 상황에서 두 가지 선택지가 있습니다. root로 완전히 전환하거나, 이 명령 하나만 권한 상승해서 실행하거나. 전자가 su, 후자가 sudo입니다. 실무에서는 대부분 sudo가 더 안전한 선택입니다. 실행 내역이 로그에 남고, 권한 범위를 명령 단위로 제한할 수 있기 때문입니다. su는 여러 명령을 연속으로 실행해야 할 때나 root 환경이 필요한 경우에 씁니다.

su — 사용자 전환 (Switch User)

su는 다른 사용자로 완전히 전환합니다. 대상 계정의 패스워드가 필요합니다.

# root로 전환 (root 패스워드 필요)
su -

# 특정 사용자로 전환 (해당 사용자 패스워드 필요)
su - deploy

# 전환 없이 단일 명령만 실행
su - deploy -c "systemctl status myapp"

- (하이픈)는 중요합니다. 이것이 있으면 대상 사용자의 환경변수(PATH, HOME 등)까지 완전히 불러옵니다. 없으면 현재 환경을 유지한 채 사용자만 바뀌어 예상치 못한 동작이 생길 수 있습니다.

sudo — 특정 명령에 권한 위임 (Superuser Do)

sudo는 현재 사용자가 자신의 패스워드로 인증한 뒤 지정된 명령을 다른 사용자(보통 root) 권한으로 실행합니다. 모든 실행 내역이 /var/log/auth.log 또는 /var/log/secure에 기록됩니다.

# root 권한으로 단일 명령 실행
sudo apt update

# root 쉘로 진입
sudo -s

# 다른 사용자 권한으로 실행
sudo -u deploy ls /home/deploy

# 현재 계정에 부여된 sudo 권한 확인
sudo -l

/etc/sudoers 구조

visudo 명령으로만 편집하세요. 문법 검사를 자동으로 수행해 파일이 망가지는 것을 막아줍니다.

# 기본 문법
WHO WHERE=(AS_WHOM) WHAT

# alice는 어디서든 root로 모든 명령 실행 가능
alice ALL=(ALL) ALL

# deploy는 패스워드 없이 systemctl restart myapp만 실행 가능
deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp

두 방법의 차이를 한 표로 정리하면 어떤 상황에서 무엇을 써야 할지 명확해집니다.

비밀번호가 1234인 계정이 프로덕션 서버에 있다면, 브루트포스 공격에 몇 초도 안 걸립니다. 반대로 로그인 실패가 일정 횟수를 넘으면 자동으로 잠기는 정책이 있다면 공격 가능성이 크게 줄어듭니다. PAM은 이런 보안 정책을 시스템 전반에 일관되게 적용하는 Linux의 인증 프레임워크입니다. 패스워드 복잡도 요구사항, 로그인 실패 시 계정 잠금 — 이 두 가지가 기본 방어선이고, 여기서 다루는 설정이 그 구현입니다.

패스워드 관련 보안 정책은 PAM(Pluggable Authentication Modules)을 통해 시스템 전반에 일관되게 적용합니다. 설정 파일 위치는 배포판마다 다릅니다.

패스워드 품질 정책 (pwquality):

pwquality는 패스워드를 설정할 때 길이, 대소문자, 숫자, 특수문자 조건을 강제합니다. /etc/security/pwquality.conf에 정책을 정의하면 passwd 명령 실행 시 자동으로 적용됩니다.

# /etc/security/pwquality.conf 설정 예
sudo tee /etc/security/pwquality.conf << 'EOF'
minlen = 12          # 최소 12자
dcredit = -1         # 숫자 최소 1개 이상
ucredit = -1         # 대문자 최소 1개 이상
lcredit = -1         # 소문자 최소 1개 이상
ocredit = -1         # 특수문자 최소 1개 이상
maxrepeat = 3        # 같은 문자 3번 연속 금지
usercheck = 1        # 사용자명 포함 금지
EOF

# 설정 테스트 (패스워드 품질 점수 확인)
pwscore
# 입력: 12345        → 점수: 0 (너무 약함)
# 입력: P@ssw0rd123! → 점수: 100 (강함)

로그인 실패 잠금 정책 (pam_faillock):

pam_faillock은 지정한 횟수 이상 로그인에 실패하면 계정을 일시 잠금합니다. 브루트포스 공격의 기본 방어선입니다.

# RHEL 8+ / Rocky / AlmaLinux — /etc/security/faillock.conf
sudo tee /etc/security/faillock.conf << 'EOF'
deny = 5            # 5회 실패 시 잠금
fail_interval = 120 # 2분 안에 실패 횟수 집계
unlock_time = 300   # 5분 후 자동 잠금 해제 (0이면 영구 잠금)
silent              # 잠금 여부 숨기기 (보안 강화)
audit               # 잠금 이벤트를 audit 로그에 기록
EOF

# Ubuntu 22.04+ — /etc/pam.d/common-auth 확인
grep pam_faillock /etc/pam.d/common-auth

# 현재 잠긴 계정 확인
sudo faillock --user alice

# 계정 수동 잠금 해제 (관리자)
sudo faillock --user alice --reset

배포판별 PAM 설정 파일 위치:

Ubuntu와 RHEL 계열은 설정 파일 경로가 달라 혼동하기 쉽습니다. 서버 배포판을 확인한 뒤 해당 경로를 수정하세요.

운영 주의: PAM 설정을 잘못 적용하면 모든 사용자가 로그인 불가 상태가 됩니다. 변경 전 반드시 root 세션을 별도 유지하고, pam_config --service=sshd --query 또는 pamtester sshd <user> authenticate로 검증하세요.

CI/CD 파이프라인에서 배포 스크립트가 sudo systemctl restart myapp을 실행해야 한다면, 해당 계정에 sudo 전체 권한을 주는 건 과합니다. root 권한으로 모든 명령을 실행할 수 있게 되기 때문입니다. sudoers의 Cmnd_Alias를 쓰면 "이 계정은 이 명령만, 패스워드 없이"를 정밀하게 설정할 수 있습니다. 실무에서 서비스 계정의 sudo 권한을 설계할 때 가장 많이 쓰는 패턴입니다.

sudoers 파일은 최소 권한 원칙(Least Privilege)을 적용해 꼭 필요한 명령만 허용해야 합니다.

Cmnd_Alias로 명령 그룹화:

Cmnd_Alias는 관련 명령을 하나의 이름으로 묶어 sudoers 파일을 읽기 쉽게 유지하고, 추후 명령 추가·제거를 한 곳에서 관리할 수 있게 합니다.

# /etc/sudoers.d/deploy (visudo -f /etc/sudoers.d/deploy로 편집)

# 명령 그룹 정의
Cmnd_Alias DEPLOY_CMDS = /bin/systemctl restart myapp, \
                          /bin/systemctl start myapp, \
                          /bin/systemctl stop myapp, \
                          /usr/bin/rsync

Cmnd_Alias LOG_CMDS = /usr/bin/journalctl, \
                      /bin/tail

# 배포 계정에 명령 그룹 허용 (패스워드 없이)
deploy ALL=(root) NOPASSWD: DEPLOY_CMDS

# 개발자는 로그만 볼 수 있음
%developers ALL=(root) NOPASSWD: LOG_CMDS

# 특정 IP에서만 NOPASSWD 허용 (내부 CI/CD 서버 IP)
cicd 10.0.1.0/24=(root) NOPASSWD: DEPLOY_CMDS

NOPASSWD 사용 시 감사 보강:

NOPASSWD를 허용하면 패스워드 확인이 없어 편리하지만 그만큼 감사 로그가 중요해집니다. auditd를 함께 구성하면 sudoers 파일 자체의 변경 이력도 추적할 수 있습니다.

# sudo 실행 내역은 /var/log/auth.log 또는 /var/log/secure에 자동 기록
grep "sudo" /var/log/auth.log | grep "COMMAND"
# sudo: deploy : ... COMMAND=/bin/systemctl restart myapp

# auditd로 더 세밀한 감사 (설치 필요)
sudo apt install auditd
# /etc/audit/rules.d/sudo.rules
# -w /etc/sudoers -p wa -k sudoers_change
# -w /etc/sudoers.d/ -p wa -k sudoers_change
sudo augenrules --load

# sudo 실행 내역 감사 로그 확인
sudo ausearch -k sudoers_change

sudoers 파일 안전 편집 규칙:

/etc/sudoers를 직접 편집하다가 문법 오류가 생기면 sudo 자체가 잠겨 root 접근이 불가능해질 수 있습니다. visudo는 저장 전에 문법을 검사해 이를 방지합니다.

# 반드시 visudo 사용 (문법 검증 포함)
sudo visudo

# 특정 파일 편집
sudo visudo -f /etc/sudoers.d/deploy

# 문법 오류 있으면 저장 거부 → 파일 손상 방지
# 절대 직접 편집하지 말 것: sudo vi /etc/sudoers  ← 위험!

# 현재 자신의 sudo 권한 확인
sudo -l