운영체제 아주 쉬운 세가지 이야기 20주차(운영체제 보안 intro)

안녕하세요. 오늘은 운영체제 보안의 “뼈대”를 잡아봅니다.
이 글은 OS가 왜 보안의 최종 방어선인지, 그리고 우리가 시스템을 설계할 때 어떤 원칙으로 안전하게 만들 수 있는지 쉽게 풀어 설명합니다.

---

0) OS 보안이 중요한 이유: “바닥이 뚫리면 위는 전부 무너진다”

앱 보안은 열심히 했는데 운영체제가 뚫리면 어떻게 될까요?
그 순간부터 공격자는 “앱 권한”이 아니라, OS가 가진 전체 권한(루트급)으로 움직이게 됩니다.

• 파일을 다 읽고 지울 수 있고
• 프로세스 메모리를 훔쳐볼 수도 있고
• 네트워크를 조작하거나 도청할 수도 있고
• 심지어 서비스를 강제로 죽이거나 굶길 수도 있습니다

그래서 OS 보안은 “보안의 한 파트”가 아니라, 사실상 보안의 기반(Foundation)이에요.

---

1) 보안 목표 3대장: CIA (진짜 기본)

보안은 기술이 아니라 “목표”에서 시작합니다. 거의 모든 보안 요구는 CIA로 정리돼요.

✅ C: Confidentiality (기밀성)

• “보면 안 되는 데이터를 못 보게” 하는 것
• 예: 비밀번호, 토큰, 개인정보, 내부 키/시크릿

✅ I: Integrity (무결성)

• “바뀌면 안 되는 데이터가 안 바뀌게” 하는 것
• 예: 잔액, 권한(role), 주문 수량, 가격
• 보통 무결성에는 진짜 주체가 맞는지(Authenticity)까지 포함됩니다

✅ A: Availability (가용성)

• “정상 사용자가 정상적으로 서비스 이용 가능”해야 합니다
• 예: DDoS, 과도한 트래픽, 자원 고갈(메모리/CPU/DB 커넥션)

현업 팁:
보안 이슈를 만나면 “이게 C/I/A 중 뭐가 깨지는 문제냐?”부터 분류하면 사고가 빨라집니다.

---

2) Policy(정책) vs Mechanism(메커니즘): 설계 감각의 핵심

이 구분을 못 하면 보안 설계가 항상 꼬입니다. 두 단어는 아예 다른 역할이에요.

✅ Policy(정책) = “누가 무엇을 할 수 있나?”

• 예: “관리자만 삭제 가능”
• 예: “A 서비스만 DB 쓰기 가능”

✅ Mechanism(메커니즘) = “그걸 어떻게 강제하나?”

• 예: ACL/권한 체크 로직
• 예: JWT 검증 + Role 기반 인가
• 예: 리눅스 파일 권한(rwx), SELinux, cgroups

“정책은 자주 바뀌고, 메커니즘은 오래 간다.”
그래서 좋은 시스템은 정책 변경이 쉬운 구조로 만들어야 합니다.

---

3) OS가 보안을 강제하는 타이밍: 결국 “시스템 콜”이다

프로세스는 마음대로 디스크에 쓰거나 네트워크를 열 수 없습니다.
커널 기능이 필요하면 반드시 시스템 콜(System Call)로 들어가야 해요.

이 순간 OS는 다음을 할 수 있습니다:

• “누구(PID/UID)가 요청했는지” 확인하고
• “이 요청이 정책상 허용되는지” 검사하고
• 허용이면 실행, 아니면 에러 반환

즉, 시스템 콜은 OS가 “검문소”를 세울 수 있는 지점입니다.

---

4) Security vs Fault Tolerance: “실수”와 “악의”는 다르다

운영체제는 원래 “다른 프로세스가 내 메모리를 실수로 덮어쓰지 못하게” 보호합니다.
이건 fault tolerance(실수/버그 방어)에 가까워요.

하지만 보안(Security)은 상대가 의도적으로 뚫으려고 달려듭니다.

• 실수 방어: “웬만하면 안 깨지게”
• 보안 방어: “상대가 깨려고 하는데도 버텨야”

그리고 중요한 현실이 하나 있습니다.
우리는 완벽한 격리를 원하지 않는다는 점이에요.

• 프로세스는 파일 시스템을 공유하고
• IPC로 통신도 하고
• 네트워크도 써야 합니다

문제는 바로 여기서 생깁니다.
“정상적인 공유 기능”이 곧 “공격 경로”가 될 수 있다는 것.

---

5) 공격자는 똑똑하지만 “게으르다”: Weakest Link 법칙

현장에서 가장 자주 맞는 말 하나만 꼽으라면 이겁니다.

공격자는 제일 쉬운 길로 들어온다.
그러니 우리는 “가장 약한 고리”를 찾아 보강해야 한다.

여기서 약한 고리는 의외로 코드가 아닐 때가 많습니다.

• 운영자가 쓰는 관리자 페이지
• “임시로 열어둔” 디버그 엔드포인트
• 권한이 과도한 계정(DB root)
• 사람(피싱, 사회공학)

결국 보안은 “가장 약한 부분”을 강화하는 싸움이에요.

---

6) 보안 설계 원칙 8개 (Saltzer & Schroeder): 실무 체크리스트

이 8개는 운영체제뿐 아니라, 백엔드/대규모 시스템에도 그대로 적용됩니다.
“외워라”가 아니라 “개발할 때 계속 체크”해야 합니다.

1) Economy of mechanism (단순하게)

시스템이 복잡해질수록 버그가 늘고, 보안 취약점도 늘어요.
작고 단순한 구조가 가장 강력한 보안입니다.

2) Fail-safe defaults (기본값은 거부)

기본은 Deny.
허용은 명시적으로 Allow.

// 좋은 기본값 예시
// 공개되지 않은 API는 기본적으로 인증/인가 필요

3) Complete mediation (매번 검사)

“한 번만 확인하고 캐시로 계속 통과”는 사고를 부릅니다.
민감한 자원 접근은 항상 검사가 원칙입니다.

4) Open design (설계는 공개돼도 안전해야)

“설계를 숨기면 안전하다”는 환상입니다.
공격자는 결국 알아냅니다. 알아도 못 뚫게 만들어야 합니다.

5) Separation of privilege (중요한 건 2중 조건)

중요한 작업은 “조건 1개”로 끝내면 위험합니다.
예: 2FA, 승인 프로세스, 2인 승인 등

6) Least privilege (최소 권한)

필요한 권한만 주세요.
권한이 크면 실수 한 번이 재앙이 됩니다.

• API 서버가 DB root 계정 사용 ❌
• 서비스별 최소 권한 계정 ✅

7) Least common mechanism (공유 최소화)

공유되는 구조가 많을수록 공격면이 커집니다.
예: 프로세스마다 페이지 테이블을 분리하는 이유도 같은 맥락입니다.

8) Acceptability (사용 가능해야)

보안이 너무 불편하면 사람은 우회합니다.
“안 쓰이는 보안”은 없는 거랑 똑같아요.

---

7) 오늘부터 바로 써먹는 적용 예시

✅ 최소 권한(Least privilege) 바로 적용

• DB 계정 분리: 읽기 전용 / 쓰기 전용
• 스토리지 권한 최소화: S3 bucket policy 좁히기
• 서버 OS 권한: root로 앱 실행 금지

✅ Complete mediation(매번 검사) 실수 방지

• 인가 체크를 컨트롤러마다 흩뿌리지 말고 미들웨어/필터로 강제
• 리소스 소유권 검사: “내 글인지” 매 요청마다 확인

✅ Fail-safe defaults(기본 Deny) 습관화

• 새 기능/새 API는 기본적으로 보호된 상태로 배포
• 서버 방화벽/보안그룹도 기본 deny

---

8) 한 문장 요약

운영체제 보안은 CIA(기밀성/무결성/가용성) 목표를 바탕으로, 정책(무엇을 허용할지)과 메커니즘(어떻게 강제할지)을 분리해 설계하고, 시스템 콜/가상화 같은 경계에서 접근제어를 수행하며, 단순성/최소권한/기본거부 같은 원칙으로 약한 고리를 강화하는 문제입니다.

---

마무리: 이 글을 읽고 반드시 남아야 하는 3가지

• 보안은 목표(CIA)부터 잡고 시작한다
• 정책 vs 메커니즘을 분리해서 설계한다
• 약한 고리부터 보강하는 게 실전 보안이다