핵심 인사이트 (3줄 요약)
- 본질: **보호(Protection)**는 운영체제 커널 내부에서 정상 프로세스들이 서로의 메모리나 자원에 실수로 침범하지 못하게 막는 **내부 교통정리 체계(Internal Mechanism)**이고, **보안(Security)**은 해커나 바이러스 등 외부 적의 침입을 차단하는 **외곽 방어망(External Policy)**이다.
- 가치: 이 **이중 방어 체계(Dual Defense Architecture)**덕분에, 비밀번호 인증을 뚫고 들어온 해커조차도 OS 커널의 파일 접근 권한(보호)에 묶여 아무것도 하지 못하고 거부당하는 다층 방어(Defense in Depth)를 구현할 수 있다.
- 한계: 보호(Protection) 체계가 아무리 잘 설계되어 있어도, 관리자 계정 탈취와 같은 보안(Security) 침해가 발생하면 내부의 모든 보호 장치가 무력화되는 단일 실패점(Cascading Failure) 위험을 항상 안고 있다.
Ⅰ. 개요 및 필요성
1.1 보호(Protection)의 개념
**보호(Protection)**는 성(OS) 안에서 실행되는 프로세스들 간의 규칙이다. 워드 프로세서가 엑셀 프로세스의 메모리 주소 공간에 무단으로 접근하려고 하면, 커널의 MMU(Memory Management Unit)가 이를 차단하여 **세그멘테이션 폴트(Segmentation Fault)**를 발생시킨다.
1.2 보안(Security)의 개념
**보안(Security)**은 성 밖에서 침입하려는 해커나 악성 트래픽을 차단하는 외곽 철조망이다. 방화벽(Firewall), 패스워드 인증, 암호화(Encryption), IDS/IPS 등이 해당한다.
1.3 분리된 경계망의 필요성
1970년대 초반에는 컴퓨터에 사용자가 1명이라 외부 보안만으로 충분했다. 그러나 인터넷과 다중 사용자(Multi-User) 환경이 도입되면서, 이미 인증된 정상 사용자들조차 서로의 디렉터리를 침범하는 문제가 발생했다. 따라서 **외곽 보안(Security)**과 **내부 보호(Protection)**가 모두 필수적이다.
- 📢 섹션 요약 비유: 복잡한 창고에서 필요한 물건을 찾기 위해 먼저 구역과 표지판을 세우는 것과 같다.
Ⅱ. 아키텍처 및 핵심 원리
2.1 메커니즘(Mechanism)과 정책(Policy)의 분리
보호와 보안을 구현하기 위해서는 **"기계 장치(메커니즘)"**와 **"그 장치를 조작하는 규칙(정책)"**이 분리되어야 한다.
| 구분 | 메커니즘 (Mechanism) | 정책 (Policy) |
|---|---|---|
| 역할 | "어떻게(How) 막을 것인가?" | "무엇을(What/Who) 막을 것인가?" |
| 변경 빈도 | 커널 재부팅 없이는 변경 불가 | 설정 파일로 유동적 변경 가능 |
| 예시 | rwx 비트 해석 및 차단 커널 코드 | 人事팀 폴더에 대해 인사팀 그룹만 읽기 권한 부여 |
2.2 분리 실패 사례: MS-DOS
과거 Windows 95 커널에서는 "누가 C드라이브를 지울 수 있는가"가 OS 코드에 하드코딩되어 있었다. 따라서 "외주 직원에게 B드라이브 접근 차단" 정책을 추가하려면 OS 자체를 재설계해야 하는 극악의 종속성이 발생했다.
- 📢 섹션 요약 비유: 공장 컨베이어벨트가 어떤 순서로 부품을 받아 가공하고 내보내는지 설계도를 펼쳐 보는 것과 같다.
Ⅲ. 비교 및 연결
3.1 보안(Security)만 믿다가 발생한 사고
주니어 엔지니어가 AWS에 서버를 띄우고 Security Group으로 외부 접근을 차단했다. 그러나 내부 프로세스의 IAM 권한이 과도하게 부여되어 있어, USB로 감염된 내부 PC가 해킹당했을 때 데이터베이스 전체가 삭제되는 사고가 발생했다.
3.2 이중 방어 체계 적용
| 단계 | 유형 | 적용 기술 |
|---|---|---|
| 1차 방어 | Security (보안) | Security Group / NACL로 외부 차단 |
| 2차 방어 | Protection (보호) | Least Privilege 기반 IAM Role으로 내부 권한 최소화 |
- 📢 섹션 요약 비유: 비슷해 보이는 공구를 나란히 놓고 언제 망치를 쓰고 언제 드라이버를 써야 하는지 구분하는 것과 같다.
Ⅳ. 실무 적용 및 기술사 판단
-
보호(Protection) 체계는 내부 프로세스 간 접근을 제어하여,万一(만약) 악성 코드가 시스템에 감염되어도 영향 범위를 제한한다.
-
보안(Security) 체계는 외부 침입을 차단하여, 내부 보호 체계가 무력화되는 것을 방지한다.
-
두 체계의 **분리 설계(Mechanism vs Policy)**는 1970년대 이래로 유닉스 시스템의 핵심 설계 원칙으로 이어져 왔다.
-
📢 섹션 요약 비유: 운전자가 도로 상황에 따라 기어와 브레이크를 다르게 선택하는 것처럼 조건별 판단이 중요하다.
Ⅴ. 기대효과 및 결론
보호 (Protection) vs 보안 (Security)의 개념 차이은 운영체제 보호와 보안 메커니즘을 이해하는 연결 고리 역할을 한다. 이 개념을 익히면 시스템 동작을 더 예측 가능하게 설명할 수 있지만, 만능 해법은 아니므로 적용 전제와 한계를 함께 기억해야 한다. 앞으로는 보호 도메인 (Protection Domain)처럼 더 세분화된 기술과 결합되며 자동화·최적화 방향으로 발전한다.
- 📢 섹션 요약 비유: 도구의 장점만 외우는 것이 아니라 어디까지 믿고 어디서 보완해야 하는지 기억하는 정리 노트와 같다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| 스파스 파일 (Sparse File) 저장 공간 절약 기술 | 현재 개념으로 들어오기 전에 함께 이해하면 경계가 선명해지는 기반 개념이다. |
| 리눅스 inotify 시스템 | 현재 개념이 등장하게 만든 직접적인 선행 흐름이다. |
| 보호 도메인 (Protection Domain) | 현재 개념이 구현·세분화될 때 바로 연결되는 후속 개념이다. |
| 접근 제어 행렬 (Access Matrix) | 확장 학습이나 심화 비교로 이어지는 다음 단계의 키워드다. |
📈 관련 키워드 및 발전 흐름도
[리눅스 inotify 시스템]
│
▼
[보호 (Protection) vs 보안 (Security)의 개념 차이]
│
├──▶ [보호 도메인 (Protection Domain)]
└──▶ [접근 제어 행렬 (Access Matrix)]
이 흐름도는 선행 개념에서 현재 개념으로 넘어온 뒤, 구현 세분화와 후속 확장으로 이어지는 학습 순서를 압축해 보여준다.
👶 어린이를 위한 3줄 비유 설명
-
**보호(Protection)**는 아파트 건물 내부의 방문록 시스템과 같다. 入주민(거주자)끼리 서로의 집에勝手(마음대로) 들어가지 못하게 각 문에 자물쇠를 채워두는 것과 같다.
-
**보안(Security)**는 건물의 정문 경비 시스템과 같다.택배 기사로 위장한 도둑이 건물에 들어오지 못하게 1층에서 확인하고 쫓아내는 것과 같다.
-
둘 다 중요한 이유: 정문 경비(보안)가 도둑을 막아도,万一(만약) 도둑이 거주자로 위장하여 들어왔다면, 각 집의 자물쇠(보호)가 없으면 금고 속 보석을 털어갈 수 있다. 그래서 두 가지 시스템이 모두 필요하다.