운영체제 아주 쉬운 세가지 이야기 20주차(Authentication(인증) )

“인증(Authentication)”은 보안의 출발점입니다.
OS든 백엔드 서버든, 결국 중요한 질문은 같습니다.

“요청한 놈이 누구냐?”
이걸 알아야 “해줘도 되는 요청인지(인가/권한)”를 결정할 수 있습니다.

---

1) 인증이 왜 OS에서 핵심인가?

운영체제(OS)는 파일 열기, 네트워크 쓰기, 프로세스 생성 같은 위험한 기능을 제공합니다.
이걸 아무나 하게 두면 시스템이 바로 무너져요.

그래서 OS는 “해줄까 말까” 판단해야 하는데, 그 판단에서 제일 중요한 힌트는 요청자의 정체입니다.

• 관리자(root)가 요청한 것인지
• 일반 사용자 계정이 요청한 것인지
• 웹서버 같은 서비스 계정이 요청한 것인지
• 정체불명의 프로그램이 요청한 것인지

이 “정체 확인 과정”이 바로 Authentication입니다.

---

2) 보안 모델에서 반드시 알아야 할 4개 용어

(1) Principal(주체)

“누구의 권한인지”의 기준이 되는 존재입니다. 사람일 수도 있고 서비스일 수도 있어요.

• 사용자(User)
• 그룹(Group)
• 서비스 계정(Web server, DB user 등)

(2) Agent(대리자)

Principal이 직접 OS에 요청하는 게 아니라, 프로세스가 대신 요청합니다.
이 “실제로 행동하는 프로세스”가 Agent입니다.

(3) Object(대상)

접근하려는 자원입니다.

• 파일/디렉토리
• 소켓
• 메모리 페이지
• 장치(Device)

(4) Credential(증명/권한 표식)

OS가 프로세스를 보면서 “너는 누구다”라고 판단할 수 있도록 붙여둔 신분증 같은 정보입니다.
예: UID/GID, 권한 상태, 토큰/세션 기반 정보 등

인증에서 가장 무서운 건 “한 번 잘못 인증되면, 그 다음부터 OS가 계속 믿어버린다”는 점입니다.
즉, 인증 실수는 오래 갑니다.

---

3) 프로세스의 “정체”는 어떻게 붙는가?

멀티유저 OS에서 핵심은 이겁니다.

프로세스는 반드시 “누구 소유인지”를 가져야 한다.

대부분의 OS는 간단한 원칙을 씁니다.

✅ 자식 프로세스는 부모의 identity를 상속한다

• 부모 프로세스 A가 자식 프로세스 B를 만들면
• OS는 A의 UID/GID 같은 신분 정보를 보고
• B에게 그대로 복사해 줍니다

그래서 사용자가 로그인하면 그 사용자의 셸(shell)이 생기고,
그 셸이 실행하는 모든 프로그램은 기본적으로 같은 사용자 신분을 갖게 되는 구조입니다.

---

4) 그럼 “맨 처음 로그인 프로세스”는 어디서 신분을 받나?

여기서 질문이 하나 생깁니다.

“상속이 기본이면, 최초로 사용자 세션을 시작하는 프로세스는 누가 만들고 누가 신분을 붙이나?”

답은 OS가 준비한 “로그인 담당 메커니즘”입니다.

1. OS는 부팅 시 로그인 관련 프로그램(예: login/sshd/GUI login)을 준비
2. 사용자가 인증 정보를 입력
3. 검증 성공하면 OS가 해당 사용자 신분(UID/GID)을 가진 프로세스를 시작
4. 그 프로세스가 이후 자식 프로세스를 계속 만들며 identity가 퍼짐

---

5) 인증 방식 3종 세트 (Know / Have / Are)

인증을 “증거의 종류”로 나눕니다. 보안에서 완전 정석이에요.

• What you know: 아는 것 (비밀번호/PIN)
• What you have: 가진 것 (토큰/폰/보안키)
• What you are: 너 자신 (지문/얼굴/홍채/음성)

각각 장단점이 있고, 하나만 쓰면 약점이 뚜렷합니다.
그래서 현실은 대부분 Multi-Factor Authentication(MFA)로 조합합니다.

---

6) What you know: 비밀번호 인증을 “실무 수준”으로 이해하기

6-1. 비밀번호를 평문으로 저장하면 왜 망하나?

평문 비밀번호는 언젠가 유출됩니다. (백업, 로그, 침해 사고, DB 덤프…)
그래서 원칙은 단순합니다.

비밀번호 자체를 저장하지 말고 “검증 가능한 형태”만 저장해라.

6-2. Hash(해시): 비밀번호를 “복구 불가능한 형태”로 저장

가입 시:

• DB에는 hash(password)만 저장

로그인 시:

• 입력값을 다시 해시해서 DB의 해시와 비교

6-3. Salt(솔트): 해시를 훔쳐가도 “한 방에 깨지지 않게”

해시만 있어도 공격자는 오프라인에서 무한 대입이 가능합니다.
그래서 계정마다 랜덤값 salt를 섞습니다.

• 저장: hash(password + salt)
• salt는 계정마다 다르게

정리: 실무 기본은 해시 + 솔트입니다.

6-4. 사전 공격(Dictionary Attack)과 방어

사람들은 “쉬운 비밀번호”를 씁니다. 공격자는 단어 리스트로 먼저 때려봅니다.
그래서 방어는 다음이 핵심입니다.

• 로그인 실패 횟수 제한(락/캡차)
• 검증 속도 늦추기(의도적으로)
• 강한 비밀번호 정책(길이/복잡도)

---

7) What you have: 가진 것으로 인증하기

토큰/폰 인증은 “물건”을 가졌다는 증거를 이용합니다.

• OTP(몇 초마다 바뀌는 값)
• 보안키(USB Key)
• 휴대폰 문자/앱 인증

핵심은 “값이 고정되면 결국 비밀번호처럼 털린다”는 점입니다.
그래서 보통 일회용 또는 짧은 주기 코드를 씁니다.

현실 포인트:
폰을 잃어버리면 사용자도 곤란하고, 공격자에게 넘어가면 위험합니다.
그래서 여기서도 MFA가 빛납니다. (가진 것 + 아는 것)

---

8) What you are: 생체 인증(바이오메트릭)은 왜 “완벽”하지 않나?

바이오메트릭은 “완벽히 일치”가 어렵습니다.
조명/각도/컨디션에 따라 같은 사람도 조금 다르게 측정돼요.

✅ 그래서 생기는 문제: False Reject / False Accept

• False Reject: 진짜 주인을 막아버림 (불편)
• False Accept: 가짜를 통과시킴 (사고)

둘은 트레이드오프 관계라 “둘 다 0”으로 만들기 어렵습니다.
서비스 성격에 따라 어디를 더 줄일지 선택해야 합니다.

시니어 한 줄:
“폰 잠금은 편의성이 중요해서 False Reject를 줄이고,
금고/결제는 보안이 중요해서 False Accept를 줄인다.”

---

9) 사람만 인증하는 게 아니다: 서비스 계정(Non-human principal)

OS는 사람뿐 아니라 “서비스”도 principal로 다룹니다.
예: webserver 계정으로 실행되는 nginx/apache

서비스는 보통 키보드로 로그인하지 않습니다.
대신 관리자 권한(sudo 등)을 통해 “특정 계정으로 실행”하도록 통제합니다.

실무에서 가장 중요한 보안 습관:
서비스는 일반 사용자 권한보다 더 낮춰서 실행하고, 필요한 파일/포트만 열게 한다. (Least Privilege)

---

10) 이 챕터에서 반드시 가져가야 할 결론 5개

1. 인증(Authentication)은 “너 누구냐”를 결정하는 과정이다
2. 인증 결과는 프로세스에 identity/credential로 붙고 오래 간다
3. 비밀번호는 평문 저장 금지, 기본은 해시 + 솔트
4. 단일 인증은 약하다 → 보통 MFA로 보완한다
5. 서비스 계정은 “사람이 아닌 principal”이고 최소 권한이 핵심이다

---

11) 한 문단으로 말하기

운영체제에서 인증은 보안 정책 적용의 전제 조건으로, OS가 시스템콜 요청 주체를 식별하기 위해 프로세스에 신분(credential)을 안전하게 부여하는 과정입니다. 사용자는 비밀번호(know), 토큰/폰(have), 생체정보(are) 같은 증거로 인증하며, 각 방식의 약점을 보완하기 위해 다중요소 인증을 활용합니다. 인증이 완료되면 프로세스는 사용자/그룹 identity를 가지며, 이후 생성되는 자식 프로세스들이 이를 상속하여 일관된 접근제어가 가능해집니다.

---