Step 25. 사용자 관리 실험 — 인증과 인가의 경계를 넘어 보라

Level 0 — 컴퓨터 조작과 구조의 이해 | 난이도 ★★☆☆☆ | 예상 소요 시간 3시간

전제: Step 23~24(권한, sudo)를 끝냈어야 합니다. 우분투 가상머신(또는 WSL)이 필요합니다. 실험용 계정을 만들고 지우는 실습이 포함됩니다.

준비물: 우분투 터미널, sudo 권한이 있는 계정.
주의: 오늘은 실험용 계정 두 개(attacker, defender)를 만들고, 실험이 끝나면 반드시 삭제합니다. 계정은 "열린 문"이 하나 더 생기는 것이라 방치 자체가 보안 구멍입니다.
안내: 사용자 명단(/etc/passwd)과 /etc/skel 조회는 실측했고, 계정 생성·전환·삭제 명령의 출력은 "출력 예시"로 표기했습니다. 모든 실험은 내 우분투 안에서 일어나는 합법 실험입니다.

지금까지 우리는 계정 하나로만 살았습니다. 그런데 리눅스는 태생이 "여러 사람이 함께 쓰는 컴퓨터"입니다. 한 대의 서버에 수십 명이 각자 계정으로 로그인하고, 각자의 홈 폴더에서 일하고, 남의 파일은 못 보게 막혀 있습니다. Step 23의 권한 문자열이 진짜 힘을 발휘하는 무대가 바로 이 다중 사용자 환경입니다.

오늘은 직접 실험실을 만듭니다. attacker(공격자)와 defender(방어자)라는 두 개의 가짜 계정을 만들고, 방어자의 비밀 파일을 공격자가 훔쳐 볼 수 있는지 시험합니다. 이 실험 하나로 "권한이 곧 보안의 경계"라는 문장이 머리가 아니라 손으로 이해됩니다.

1. 학습 목표

이 챕터를 끝내면 다음을 할 수 있습니다:

인증(authentication)과 인가(authorization)의 차이를 예를 들어 설명한다
adduser로 계정을 만들고 /etc/passwd에서 그 흔적을 확인한다
su - 계정으로 다른 사용자로 전환하고, 하이픈(-)의 의미를 설명한다
600/644 권한 실험으로 "권한이 방어벽"임을 양방향으로 확인한다
deluser --remove-home으로 실험 계정을 완전히 정리한다

2. 배경 지식 — 오늘의 도구와 개념

오늘의 도구 한눈에 보기

구분	내용
언어·환경	우분투 터미널(배시 셸), sudo 필요
오늘의 명령어	`sudo adduser`(계정 만들기), `su - 계정`(사용자 전환), `id`(내 번호·그룹 보기), `sudo deluser --remove-home`(계정 삭제)
필요한 개념	인증과 인가, UID, 홈 디렉토리, /etc/passwd와 /etc/skel

2-1. 인증과 인가 — 보안의 두 기둥

인증(Authentication): "너 누구야?" — 신원을 확인하는 절차입니다. 로그인할 때 아이디와 비밀번호를 치는 것이 대표적이고, 지문·OTP 앱·인증서도 인증 수단입니다.
인가(Authorization): "뭘 해도 돼?" — 인증이 끝난 사용자에게 어떤 행위를 허용할지 결정하는 절차입니다. Step 23의 권한 문자열, Step 24의 sudoers 명단이 인가의 구현입니다.

비유하면 회사 건물 출입과 같습니다. 인증은 로비에서 사원증을 찍는 것, 인가는 사원증에 찍힌 등급으로 열리는 층이 다른 것입니다. 사원증이 진짜라도(인증 통과) 옥상 기계실 문은 안 열릴 수 있습니다(인가 부족).

왜 이 구분이 중요할까요? 보안 사고의 절반은 이 둘의 구분 실패에서 옵니다. "로그인만 하면 모든 기능을 쓸 수 있게" 만든 시스템은 일반 계정 하나가 털리는 순간 전체가 털립니다. 반면 인가가 촘촘한 시스템은 계정 하나가 털려도 피해가 그 계정의 권한 범위에 갇힙니다.

2-2. 계정의 실체 — UID

리눅스 내부에서 사용자는 이름이 아니라 번호로 관리됩니다. 이 번호를 UID(User ID)라고 합니다. lee라는 이름은 사람을 위한 표시일 뿐, 커널은 "UID 1000번"으로 여러분을 압니다. 중요한 번호들:

0번: root. Step 24에서 배운 최고 관리자입니다
1~999번: 시스템용 계정(www-data 같은 서비스 전용)
1000번~: 우분투에서 사람이 쓰는 일반 계정. 첫 설치 계정이 1000번입니다

사용자 명단은 /etc/passwd에, 비밀번호 해시는 /etc/shadow에 나뉘어 저장됩니다 — Step 24에서 root만 shadow를 읽을 수 있음을 확인했지요.

2-3. 홈 디렉토리 — 각자의 방

계정이 만들어지면 /home/계정이름이라는 전용 폴더가 생깁니다. 여기가 그 사용자의 "방"이고, 방의 소유자는 그 계정입니다. 남의 방에 함부로 들어갈 수 없게 하는 것이 권한이고, 오늘 실험은 정확히 그 경계를 넘어 볼 수 있는가를 시험합니다.

새 계정의 방에는 기본 가구가 있습니다. /etc/skel이라는 보물함에 들어 있는 파일들이 계정 생성 시 홈 폴더로 복사됩니다 — 3-4절에서 직접 들여다봅니다.

3. 따라 하기

3-1. 지금 이 시스템의 사용자 명단 읽기

실험 계정을 만들기 전에, 현재 명단이 어떻게 생겼는지 조회부터 합니다. /etc/passwd는 모두 읽기 가능한 파일이라 sudo도 필요 없습니다:

head -3 /etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin

(2026-09-09 우분투 24.04 실측.)

출력 읽는 법: 한 줄이 한 계정이고 콜론(:)으로 필드가 나뉩니다 — 계정명 : x(비밀번호는 shadow에 있다는 표시) : UID : 그룹 번호 : 설명 : 홈 폴더 : 기본 셸. 첫 줄이 UID 0번 root입니다. daemon(1번), bin(2번)은 2-2절의 시스템 계정 — 로그인용이 아니라 셸이 /usr/sbin/nologin입니다.

전체가 몇 명인지, 끝부분에는 누가 있는지 봅시다:

wc -l /etc/passwd
tail -5 /etc/passwd

29 /etc/passwd
uuidd:x:103:103::/run/uuidd:/usr/sbin/nologin
landscape:x:104:105::/var/lib/landscape:/usr/sbin/nologin
polkitd:x:990:990:User for polkitd:/:/usr/sbin/nologin
dnsmasq:x:999:65534:dnsmasq:/var/lib/misc:/usr/sbin/nologin
tcpdump:x:105:110::/nonexistent:/usr/sbin/nologin

(2026-09-09 실측. 이 환경은 실험용 최소 구성이라 사람 계정이 없고 시스템 계정만 있습니다. 여러분의 우분투에서는 맨 아래에 여러분 계정(UID 1000)이 보일 겁니다.)

읽는 법: 29줄, 즉 29개의 계정이 있고 대부분이 시스템 계정입니다. 실제 서버도 이와 같습니다 — 사람 계정보다 서비스 전용 계정이 훨씬 많은 것이 정상 풍경입니다. 각 서비스에 전용 계정을 두는 것 자체가 최소 권한 원칙의 실천입니다: 웹서버가 뚫려도 www-data 권한에 갇히도록요.

실제로 그런 계정이 있는지 확인해 봅시다:

id www-data

uid=33(www-data) gid=33(www-data) groups=33(www-data)

(2026-09-09 실측.)

읽는 법: id는 계정의 UID·GID·소속 그룹을 보여 줍니다. 웹서버 전용 계정 www-data는 UID 33번 — 1000번대인 사람 계정과 구역이 다릅니다.

3-2. 실험용 계정 두 개 만들기

이제 실험실을 지을 시간입니다:

sudo adduser attacker

Adding user `attacker' ...
Adding new group `attacker' (1002) ...
Adding new user `attacker' (1001) with group `attacker' ...
Creating home directory `/home/attacker' ...
Copying files from `/etc/skel' ...
New password:

(출력 예시 — 계정 생성은 시스템을 바꾸는 명령이라 본 챕터에서는 실측하지 않았습니다. UID 번호는 환경마다 다릅니다.)

읽는 법: 시스템이 계정을 만들며 하는 일이 순서대로 보입니다. UID 1001 배정, 전용 그룹 생성, 홈 폴더 /home/attacker 생성, /etc/skel에서 기본 설정 파일 복사. 비밀번호를 물으면 실험용 간단한 것(예: test1234!)을 입력합니다. 재입력 후 Full Name 등은 전부 Enter로 건너뛰고, 마지막에 Y로 확정합니다.

왜: adduser는 "사람이 쓸 계정"을 만드는 우분투의 표준 명령입니다. 홈 폴더 생성, 그룹 생성, 비밀번호 설정까지 한 번에 해 줍니다.

같은 방법으로 defender도 만들고, 등록됐는지 확인합니다:

sudo adduser defender
tail -2 /etc/passwd

attacker:x:1001:1002::/home/attacker:/bin/bash
defender:x:1002:1003::/home/defender:/bin/bash

(출력 예시.)

읽는 법: 두 계정이 명단에 등록됐습니다. 3-1절의 시스템 계정들과 다른 점에 주목하세요 — 기본 셸이 /bin/bash, 즉 로그인 가능한 사람용 계정입니다.

3-3. 방어자가 비밀 파일 만들기

su - defender

(출력 예시) 비밀번호를 묻습니다. 방금 정한 defender의 비밀번호를 입력하면 프롬프트가 defender@ubuntu:~$로 바뀝니다.

읽는 법: su는 "switch user(사용자 전환)"입니다. -(하이픈)는 "그 사용자로 로그인한 것처럼 환경 전체를 바꿔라"는 뜻으로, 홈 폴더도 defender의 것으로 이동합니다. 이 -를 빼면 계정만 바뀌고 환경은 그대로라 혼란이 오니, 습관적으로 su -를 쓰세요.

방어자 신분으로 비밀 파일을 만들고 잠급니다:

whoami
echo "방어자의 최고 비밀: 금고 번호는 0426" > secret.txt
chmod 600 secret.txt
ls -l secret.txt

defender
-rw------- 1 defender defender 40  9월 9일 11:30 secret.txt

(출력 예시.)

읽는 법: 이 파일은 소유자 defender만 읽고 쓸 수 있습니다 — Step 23의 600입니다.

3-4. 공격자로 침입 시도 — 오늘 실험의 정점

exit
su - attacker

(exit하면 원래 내 계정으로 돌아오고, 다시 attacker로 전환합니다.)

예측해 보기: attacker가 /home/defender/secret.txt를 읽으려 하면 어떻게 될까요? ① 읽힌다 ② 거부된다. 예측하고 확인하세요.

whoami
cat /home/defender/secret.txt

attacker
cat: /home/defender/secret.txt: Permission denied

(출력 예시.)

읽는 법: 거부됐습니다. attacker는 소유자도 아니고 그룹 멤버도 아니므로 "기타(others)"이고, 600에서 기타의 권한은 ---입니다.

왜: 같은 컴퓨터, 같은 디스크 위의 파일인데, 권한 문자열 10글자가 읽기를 막았습니다. 공격자 입장에서 이 벽을 넘으려면? 더 높은 권한(root)을 얻거나, 방어자 계정 자체를 탈취하거나(인증 공격), 방어자가 권한을 실수로 풀어 주기를 기다려야 합니다. 이 세 가지가 실제 침해 사고의 주요 루트입니다.

참고로 새 계정의 방에 어떤 "기본 가구"가 복사됐는지 엿봅시다:

ls -a /etc/skel

.
..
.bash_logout
.bashrc
.profile

(2026-09-09 실측.)

읽는 법: /etc/skel에는 새 계정의 홈에 기본 복사되는 파일들 — 셸 설정(.bashrc 등) — 이 들어 있습니다. 회사 시스템 관리자가 모든 직원 계정에 공통 설정을 심을 때 이곳을 고칩니다.

3-5. 권한을 풀면 열린다

방어자가 실수로 권한을 풀어 주는 상황을 재현합니다:

exit
su - defender
chmod 644 secret.txt
exit
su - attacker
cat /home/defender/secret.txt

방어자의 최고 비밀: 금고 번호는 0426

(출력 예시.)

읽는 법: defender가 644로 바꾸자(기타에게 읽기 허용) attacker가 읽을 수 있게 됐습니다. 파일 내용은 하나도 안 바뀌었는데, 문자열 몇 글자가 "비밀"과 "공개"를 갈랐습니다. 권한 설정 실수가 곧 보안 사고임을 양방향으로 확인했습니다 — 600에서는 막혔고, 644에서는 뚫렸습니다.

3-6. 뒷정리 — 실험실 철수

⚠️ deluser는 계정을 시스템에서 삭제하는 명령이고, --remove-home은 그 계정의 홈 폴더까지 통째로 지웁니다. 되돌릴 수 없습니다. 지금은 오늘 만든 실험 계정 둘만 지웁니다 — 계정 이름을 두 번 확인하고 실행하세요.

exit
sudo deluser --remove-home attacker
sudo deluser --remove-home defender
ls /home

Removing user `attacker' ...
...
lee

(출력 예시.)

읽는 법: 두 실험 계정과 그 홈 폴더가 삭제되고, /home에는 원래 계정만 남았습니다.

왜: 실험이 끝나면 실험 환경을 정리하는 것도 실력입니다. 회사에서 퇴사자가 나오면 IT 부서가 가장 먼저 그 사람의 계정을 잠그는 것과 같은 이치입니다 — 계정이 살아 있는 한, 비밀번호를 아는 누군가는 여전히 문을 열 수 있습니다. "퇴사했는데 비활성화되지 않은 계정"으로 시작된 사고는 통계에 반복해서 등장합니다. 오늘의 뒷정리는 귀찮은 설거지가 아니라 기업 보안 운영의 축소판입니다.

4. 미션과 연습문제

미션 — 권한 경계 보고서 작성하기

/etc/passwd에서 자신의 계정 줄을 찾아 UID와 홈 폴더를 확인하고, id 명령의 출력과 비교하세요
ls -a /etc/skel로 새 계정에 기본 복사되는 파일들을 확인하세요 (.bashrc가 보이면 정상)
오늘 실험의 네 장면 — ① defender가 600으로 잠금 ② attacker의 읽기 거부 ③ 644로 권한 풀림 ④ attacker의 읽기 성공 — 을 "인가의 관점"으로 한 문단씩 설명해 authz-report.txt에 정리하세요
실험 계정을 삭제한 뒤, grep -c attacker /etc/passwd가 0인지 확인해 정리가 완벽함을 검증하세요 (0이 아니면 어디가 남았는지 찾아보세요)

답은 여기 쓰지 않습니다 — 5절에서 검증합니다.

연습문제

문제 1. 다음 중 인증에 해당하는 것과 인가에 해당하는 것을 나눠 보세요: ① 출입증 태그 ② 서류실 문이 내 등급에서만 열림 ③ 공항 여권 확인 ④ 비행기 좌석 등급별 라운지 이용

문제 2. su defender와 su - defender의 차이는 무엇이며, 왜 후자를 습관으로 삼아야 할까요?

문제 3. attacker로 전환했는데 defender의 600 파일이 읽혔습니다. 실험이 잘못된 것일까요? 가장 먼저 의심하고 확인해야 할 것은 무엇일까요?

문제 4. 서버 관리자가 /etc/passwd에 모르는 계정이 등록된 것을 발견했습니다. 왜 이것이 침해의 강력한 신호인지, 오늘 실험과 연결해 설명해 보세요.

5. 모범 답안과 완료 기준

미션 모범 답안

grep "^lee" /etc/passwd      # 내 계정 줄 (이름은 여러분의 것으로)
id
ls -a /etc/skel
nano authz-report.txt        # 네 장면을 인가 관점으로 작성
sudo deluser --remove-home attacker
sudo deluser --remove-home defender
grep -c attacker /etc/passwd

(마지막 출력은 출력 예시 — 계정이 완전히 삭제됐다면 0입니다.)

검증하는 법: ① /etc/passwd의 내 줄 UID(보통 1000)와 id 출력의 uid가 일치해야 합니다. ② .bashrc 확인. ③ 보고서의 각 문단에 "인가(권한)가 허용/거부를 결정했다"는 표현이 들어갔는지 확인하세요 — 인증(로그인)과 섞이지 않아야 합니다. ④ 마지막 grep -c가 0이면 정리 완료입니다. 참고로 3-1절 실측에서 보았듯 /etc/passwd 한 줄은 계정:x:UID:GID:설명:홈:셸 형식입니다.

연습문제 해답

문제 1 해답. 인증은 ①③(신원 확인), 인가는 ②④(확인된 신원에 따른 행위 허용)입니다. 출입증과 여권은 "나를 증명"하는 것이고, 문이 열리는 등급과 라운지 이용은 "증명된 나에게 허용된 것"입니다.

문제 2 해답. -(하이픈)은 "로그인 셸"을 뜻합니다 — 환경 변수와 작업 폴더까지 그 사용자로 로그인한 것처럼 전부 바뀝니다. 하이픈 없이 전환하면 계정만 바뀌고 환경은 이전 사용자 것이라 경로·설정이 꼬입니다. 그래서 습관적으로 su -를 씁니다.

문제 3 해답. 실험이 잘못된 게 아니라 대부분 실험 조건이 오염된 것입니다. 습관적으로 sudo cat을 쳤거나(root로 읽으면 당연히 읽힙니다), 실제로는 defender나 원래 계정 상태일 수 있습니다. 실험 전에 반드시 whoami로 "지금 내가 누구인가"를 확인하세요 — 실험의 공정성은 거기서 시작합니다.

문제 4 해답. 공격자는 침투 성공 후 "다음에 또 오기 위해" 자기만의 계정을 몰래 만들어 두는 경우가 많습니다 — 오늘 여러분이 attacker를 만든 것과 같은 손놀림입니다. 그래서 모르는 계정의 존재는 침해의 강력한 신호이고, 계정 명단 점검이 서버 보안 점검의 기본 항목입니다. 문은 열어 주는 것보다 닫고 확인하는 것이 더 중요한 일입니다.

완료 기준 체크리스트

[ ] 인증과 인가의 차이를 예를 들어 설명할 수 있다
[ ] /etc/passwd 한 줄의 필드들(계정·UID·홈·셸)을 읽을 수 있다
[ ] adduser로 계정을 만들고 deluser –remove-home으로 정리할 수 있다
[ ] su -의 하이픈 의미를 설명할 수 있다
[ ] /etc/skel의 역할을 설명할 수 있다
[ ] 600/644 실험으로 권한이 방어벽임을 체감했다
[ ] 미션: 권한 경계 보고서와 잔재 검증(grep -c = 0)을 완수했다

6. 흔한 실수와 해결

벽 1. "adduser가 묻는 Full Name이 뭔가요?"

증상: 계정 생성 중 Full Name, Room Number 같은 항목을 물어서 당황합니다.
원인: 옛날 사무실 전화번호부 시절의 유산으로, 전부 선택 사항입니다.
해결: 전부 Enter로 건너뛰면 됩니다. 비어 있어도 계정은 잘 만들어집니다.

벽 2. "su – defender를 했는데 이상한 오류가 나와요."

증상: 전환 직후 오류가 뜨거나 홈 폴더가 아닌 곳에 있습니다.
원인: su에 -를 빼먹은 경우가 많습니다. 환경 변수가 이전 사용자 것 그대로라 꼬입니다.
해결: exit로 나온 뒤 su - defender처럼 하이픈을 꼭 붙이세요. 하이픈 하나가 "로그인 셸" 여부를 가릅니다.

벽 3. "attacker인데도 defender의 파일이 읽혀요!"

증상: chmod 600인데 cat이 성공합니다.
원인: 대부분 sudo를 습관적으로 붙였거나, 실제로는 다른 계정 상태입니다. sudo cat이면 root로 읽는 것이라 당연히 읽힙니다.
해결: 실험 전에 반드시 whoami로 현재 계정을 확인하세요.

벽 4. "deluser로 지웠는데 /home에 폴더가 남아 있어요."

증상: 계정은 사라졌는데 홈 폴더가 남아 있습니다.
원인: --remove-home 옵션을 빼먹었거나, 홈 안에 다른 소유자의 파일이 섞여 있거나, 삭제 당시 그 계정으로 실행 중인 프로세스가 있으면 정리가 실패할 수 있습니다.
해결: ps aux | grep 계정명으로 잔여 프로세스를 확인하세요. 수동 정리가 필요하면 sudo rm -r /home/계정명을 쓰되 — rm -r은 폴더째 복구 불가능하게 지웁니다 — 정말 실험 계정의 것인지 세 번 확인하고 지우세요. 실무에서도 "삭제 후 확인"까지가 절차입니다.

7. 정리

오늘의 개념

개념	한 줄 설명
인증(authentication)	"너 누구야?" — 신원 확인 (로그인)
인가(authorization)	"뭘 해도 돼?" — 행위 허용 결정 (권한 문자열, sudoers)
UID	사용자의 내부 번호 — 0은 root, 1000~은 사람 계정
홈 디렉토리	계정의 전용 방 — /home/계정명
/etc/skel	새 계정의 방에 복사되는 기본 가구 보관함

오늘의 명령어

명령	하는 일
`sudo adduser 이름`	사람용 계정 만들기 (홈·그룹·비밀번호까지)
`su - 계정`	사용자 전환 (하이픈 = 로그인 셸)
`id`	내 UID·그룹 확인
`head`/`tail /etc/passwd`	사용자 명단 읽기
`sudo deluser --remove-home 이름`	계정+홈 삭제 (⚠️ 복구 불가, 이름 확인 필수)

명령어보다 중요한 감각

"파일의 권한"(Step 23)과 "사람의 경계"(오늘)가 맞물려 돌아가는 것이 리눅스 보안의 실체입니다. 원리를 아는 사람은 낯선 시스템에서도 같은 질문을 던질 수 있습니다. "이 파일은 누구 것인가, 누가 읽을 수 있는가, 이 계정은 무엇을 해도 되는가."

인증과 인가, 이 두 단어는 보안 업계 전체를 관통하는 좌표축입니다. 로그인 시스템의 "MFA(다요소 인증)"는 인증 강화이고, "RBAC(역할 기반 접근 제어)"와 클라우드의 IAM은 인가의 체계화입니다. 침해 사고 보고서의 단골 문장 — "공격자가 정상 계정을 탈취해 내부망에 침투" — 도 인증의 문을 우회한 뒤 그 계정의 인가 범위에서 활동했다는 뜻입니다. 인증은 신원의 확인이고, 인가는 행위의 허용입니다. 이 정의 하나로 수많은 보안 기사가 읽히기 시작할 겁니다.

전부 체크되면 Step 25 완료입니다. 사이드바의 체크박스를 눌러 진도를 저장하세요.