0x01 정보보안 원칙 (Information Security Principles)
1. CIA Triad (기밀성, 무결성, 가용성)
Confidentiality
/\
/ \
/ \
/ CIA \
/ Triad \
/__________\
Integrity Availability
1.1 기밀성 (Confidentiality)
- 정의: 인가된 사람만이 정보에 접근할 수 있도록 통제하는 보안 원칙
- Oxford 사전 정의: "The state of keeping or being kept secret or private"
ENIGMA 사례 분석
- 배경: 2차 세계대전 중 독일군의 암호 통신
- 암호화 방식: Caesar Cipher (치환 암호)
- 복잡도: 158,962,555,217,826,360,000개의 가능한 설정
- 설정 변경: 매일 변경
Alan Turing의 해독 방법:
- 암호화 특성 활용: 문자는 자기 자신으로 암호화되지 않음 (A→A 불가능)
- Known-plaintext attack: 예측 가능한 평문 활용
- 메시지 시작부: "HEIL HITLER"
- 날씨 예보 형식: "WETTER", "REGEN", "HEUTE"
💡 추가 정보: Known-plaintext attack은 현대 암호학에서도 중요한 공격 벡터입니다. 이는 암호 시스템이 알려진 평문-암호문 쌍에 대해서도 안전해야 함을 의미합니다.
1.2 무결성 (Integrity)
- 정의: 데이터나 메시지가 무단으로 변경되지 않았음을 보장하는 보안 원칙
- Oxford 사전 정의: "internal consistency or lack of corruption in electronic data"
구현 방식의 진화
과거: 물리적 봉인 (Seal on envelope)
↓
현재: 디지털 서명 + HMAC
HTTPS에서의 무결성 보장
- 암호화: 대칭키를 사용한 메시지 암호화/복호화
- 무결성: HMAC (SHA-2 기반)으로 메시지 변조 감지
- 방어 대상: 도청자(Eavesdroppers), 중간자 공격(MITM)
1.3 가용성 (Availability)
- 정의: 정보 시스템이 필요할 때 서비스를 제공할 수 있어야 함
- 주요 위협: DDoS (Distributed Denial of Service) 공격
정상 상태: 사용자 → 서버 (정상 처리)
DDoS 공격: 봇넷 →→→→→ 서버 (과부하로 서비스 불가)
💡 추가 정보: 가용성 보장 방법
- 로드 밸런싱 (부하 분산)
- CDN (Content Delivery Network)
- 레이트 리미팅 (요청 제한)
- 이중화/백업 시스템
1.4 부인 방지 (Non-Repudiation)
- 정의: 특정 행동을 했음을 부인할 수 없도록 증거를 만드는 보안 원칙
구현 메커니즘
-
디지털 서명
- 데이터 무결성 보장
- 발신자 신원 확인
- 나중에 부인 불가능
-
타임스탬프
- 특정 시점의 데이터 상태 증명
- 문서의 마지막 수정 시각 보장
코드 서명 예시
개발자 → [앱 + 개발자 서명 + 타임스탬프] → 사용자
↑
개발자 인증서 (CA가 서명)
2. 인증과 접근 제어
2.1 인증 (Authentication)
- 정의: "당신이 주장하는 그 사람이 맞는지" 확인하는 과정
인증 방식
- 지식 기반: ID/패스워드
- 생체 인증: Face ID, 지문
- 소유 기반: 여권, 스마트카드
- 암호 기반: 공개키 암호
2.2 접근 제어 (Access Control)
- 정의: 컴퓨팅 환경에서 자원에 대한 접근을 규제
Linux/Unix ACL 예시
drwx------@ 74 hjlee staff 2368 Dec 1 01:27 Library
│││└─────── others 권한 (없음)
││└──────── group 권한 (없음)
│└───────── owner 권한 (읽기/쓰기/실행)
└────────── 디렉토리 표시
Icampus 접근 제어 모델
- MAC (Mandatory Access Control): 시스템이 정책 강제
- RBAC (Role-based Access Control): 역할에 따른 권한 부여
💡 추가 정보: 접근 제어 모델 비교
- DAC (Discretionary): 소유자가 권한 결정
- MAC (Mandatory): 시스템이 정책 강제
- RBAC (Role-based): 역할 기반 권한
- ABAC (Attribute-based): 속성 기반 권한
3. 보안 설계 원칙 (Saltzer & Schroeder, 1975)
3.1 최소 권한 원칙 (Least Privilege)
정의: 기능 수행에 필요한 최소한의 권한만 부여
Chrome 브라우저 예시:
┌─────────────────┐
│ Browser Kernel │ ← 전체 권한 (파일, 네트워크)
├─────────────────┤
│ Rendering Engine│ ← 제한된 권한 (샌드박스)
└─────────────────┘
3.2 안전한 기본값 원칙 (Fail-Safe Defaults)
정의: 명시적 허가 없이는 기본적으로 접근 거부
올바른 접근:
요청 → 권한 확인 → [허가 목록에 있음?] → YES → 허용
↓
NO → 거부 (기본값)
CVE 사례 분석
| CVE 번호 | 문제점 | 올바른 기본값 |
|---|---|---|
| CVE-2019-19251 | Last.fm 앱 SSL 기본 비활성화 | SSL 기본 활성화 |
| CVE-2019-16913 | PC Protect 폴더 전체 권한 | 제한된 권한 |
| CVE-2017-10719 | IoT 기기 동일 기본 Wi-Fi 자격증명 | 기기별 고유 자격증명 |
3.3 메커니즘 경제성 원칙 (Economy of Mechanism)
정의: 보안 메커니즘은 가능한 한 단순해야 함
복잡한 시스템의 문제점:
이해 ↘
↘
모델링 → 오류 가능성 증가 → 보안 취약점
↗
구현 ↗
3.4 완전한 중재 원칙 (Complete Mediation)
정의: 모든 접근은 매번 권한 검사를 거쳐야 함
시스템 아키텍처
┌─────────────────────────────┐
│ User Programs │ ← 직접 하드웨어 접근 불가
├─────────────────────────────┤
│ C Runtime (libc/CRT) │ ← 시스템 콜 래퍼
├─────────────────────────────┤
│ System Call Interface │ ← 권한 검사 수행
├─────────────────────────────┤
│ Kernel Space │ ← 하드웨어 직접 제어
├─────────────────────────────┤
│ Hardware │
└─────────────────────────────┘
💡 추가 정보: x86-64 Linux는 313개의 시스템 콜 제공 (sys_open, sys_read, sys_socket 등)
3.5 공개 설계 원칙 (Open Design)
정의: 보안은 설계의 비밀이 아닌 키의 비밀에 의존해야 함
나쁜 예 (Security by Obscurity):
보안 = 알고리즘 비밀 + 키 비밀
↓ 알고리즘 노출 시
보안 붕괴
좋은 예 (Kerckhoffs's Principle):
보안 = 공개된 알고리즘 + 키 비밀
↓ 알고리즘 공개되어도
키만 안전하면 보안 유지
3.6 권한 분리 원칙 (Separation of Privilege)
정의: 단일 조건이 아닌 다중 조건으로 권한 부여
Chrome 브라우저 프로세스 모델
Browser Process (높은 권한)
├── Renderer Process 1 (샌드박스)
├── Renderer Process 2 (샌드박스)
└── Plugin Process (제한된 권한)
x86 권한 레벨
Ring 0: Kernel (최고 권한)
Ring 1: (미사용) ← Lord of the x86 Rings 연구
Ring 2: (미사용) ← 중간 권한 레벨 활용 제안
Ring 3: User (최저 권한)
3.7 최소 공통 메커니즘 원칙 (Least Common Mechanism)
정의: 공유 자원을 최소화하여 간섭 방지
캐시 사이드채널 공격
Microsoft 인터뷰 문제 비유:
1. Switch1 켜고 5분 대기 → 끄기
2. Switch2 켜고 방 입장
3. 결과: 꺼짐(차가움)=Switch3, 켜짐=Switch2, 꺼짐(뜨거움)=Switch1
캐시 공격 적용:
1. FLUSH: 캐시 비우기 (전구 식히기)
2. 피해자 실행 (전구 사용)
3. RELOAD: 캐시 확인 (뜨거운 전구 찾기)
3.8 심리적 수용성 원칙 (Psychological Acceptability)
정의: 보안이 사용을 방해하지 않아야 함
실패 사례: 한국 웹사이트 보안 플러그인
사용자 경험:
접속 시도 → 플러그인 설치 요구 → 복잡한 설치 → 사용자 이탈
↓
보안 효과 감소
Usable Security 연구
- 다학제적 접근 (CS + HCI)
- 예시: "Going Incognito in the Metaverse" (UIST '23)
3.9 심층 방어 원칙 (Defense in Depth)
정의: 다층 보안으로 단일 실패점 방지
사용자 인증 예시
Layer 1: 강력한 패스워드 정책
↓ 통과 시
Layer 2: 이상 접속 탐지
↓ 통과 시
Layer 3: 2단계 인증 (2FA)
↓ 모두 통과
접근 허용
4. 보안 설계 원칙 적용 사례
4.1 OpenSSH 권한 분리
문제점
기존 sshd (모놀리식):
[sshd - root 권한] ← 취약점 하나로 전체 시스템 장악 가능
해결책: 프로세스 격리
개선된 sshd:
[Monitor - root] ← 인증만 담당
↓
[Unprivileged sshd] ← 네트워크 통신
↓
[User shell] ← 사용자 권한
프로세스 격리의 장점:
- 별도 주소 공간 (메모리 오류 격리)
- 다른 권한 레벨 (uid 차별화)
- 다른 샌드박스 설정 (seccomp, SELinux)
4.2 신뢰 실행 환경 (TEE)
일반 실행 환경 신뢰 실행 환경
┌─────────────┐ ┌──────────────┐
│ Untrusted │ │ Enclave │
│ Code │ ←──→ │ Trusted Code │
└─────────────┘ └──────────────┘
↑
하드웨어 보호
구현 기술:
- Intel SGX
- ARM TrustZone
- Intel TDX
- AMD SEV
활용 분야:
- DRM (디지털 저작권 관리)
- 보안 결제
- 클라우드 기밀 컴퓨팅
4.3 커널 설계 철학
Tannenbaum-Torvalds 논쟁 (1992)
Microkernel (이론적 우수성) Monolithic (실용성)
┌──────────┐ ┌──────────┐ ┌────────────────┐
│File Svc │ │Net Svc │ │ │
└──────────┘ └──────────┘ │ 모든 서비스 │
┌──────────┐ ┌──────────┐ │ 커널 내 통합 │
│Device Drv│ │Other Svc │ │ │
└──────────┘ └──────────┘ └────────────────┘
↓ IPC 통신 ↓ ↓
┌─────────────────────┐ ┌────────────────┐
│ Microkernel │ │ Monolithic │
└─────────────────────┘ └────────────────┘
결과: 구현 단순성(메커니즘 경제성)으로 Monolithic 승리
예상 시험문제
1. CIA Triad 종합 문제
문제: 온라인 뱅킹 시스템에서 CIA Triad 각 요소를 보장하는 구체적인 기술을 설명하시오.
모범답안:
-
기밀성 (C):
- SSL/TLS 암호화 통신
- AES 대칭키 암호화
- 세션 관리 및 타임아웃
-
무결성 (I):
- 거래 내역 해시 체인
- 디지털 서명으로 거래 승인
- HMAC으로 메시지 변조 감지
-
가용성 (A):
- 다중 서버 이중화
- DDoS 방어 시스템
- 로드 밸런싱
- 정기적 백업 및 복구 계획
2. 보안 설계 원칙 적용
문제: 새로운 모바일 결제 앱을 설계한다고 할 때, 최소 5개의 보안 설계 원칙을 적용하여 설계하시오.
모범답안:
- 최소 권한: 결제 기능만 필요한 권한 요청 (카메라, 인터넷만)
- 안전한 기본값: 생체인증 기본 활성화, 자동 로그아웃 설정
- 권한 분리: 결제 프로세스와 UI 프로세스 분리
- 완전한 중재: 모든 거래마다 인증 요구
- 심층 방어: PIN + 생체인증 + 거래 알림
- 심리적 수용성: 간편한 생체인증으로 보안과 편의성 균형
3. 캐시 사이드채널 공격
문제: Flush+Reload 공격의 3단계를 설명하고, 이 공격이 "최소 공통 메커니즘" 원칙과 어떤 관련이 있는지 서술하시오.
모범답안: Flush+Reload 3단계:
- Flush: 공격자가 타겟 메모리 라인을 캐시에서 제거
- Wait: 피해자가 해당 메모리에 접근하기를 대기
- Reload: 해당 메모리 접근 시간을 측정하여 피해자의 접근 여부 판단
최소 공통 메커니즘 원칙과의 관계:
- L3 캐시는 여러 프로세스가 공유하는 자원
- 이 공유 메커니즘을 통해 한 프로세스가 다른 프로세스의 행동을 추론 가능
- 원칙 위반: 민감도가 다른 프로세스들이 캐시를 공유함
4. 프로세스 격리와 권한 분리
문제: OpenSSH가 단일 프로세스에서 다중 프로세스 구조로 변경한 이유와 각 프로세스의 역할을 설명하시오.
모범답안: 변경 이유:
- 기존: 전체가 root 권한 → 취약점 하나로 시스템 전체 장악
- 개선: 권한 분리로 피해 범위 제한
프로세스별 역할:
- Monitor (root): 인증만 담당, 최소한의 코드
- Unprivileged sshd: 네트워크 통신, 암호화/복호화
- User process: 실제 사용자 명령 실행, 사용자 권한으로 실행
적용된 원칙: 최소 권한, 권한 분리, 심층 방어
5. 보안과 사용성의 균형
문제: "심리적 수용성 원칙"이 왜 중요한지 실패 사례를 들어 설명하고, 올바른 적용 방안을 제시하시오.
모범답안: 중요성: 보안이 너무 복잡하면 사용자가 우회하거나 비활성화
실패 사례: 한국 웹사이트의 보안 플러그인
- 문제: 복잡한 설치 과정, 잦은 업데이트, 특정 브라우저만 지원
- 결과: 사용자 이탈, 보안 플러그인 우회 방법 검색
올바른 적용:
- 투명한 보안: 백그라운드에서 자동 작동
- 직관적 UI: 복잡한 보안 설정을 간단한 선택으로
- 점진적 보안: 사용자 수준에 맞춰 보안 강도 조절
- 명확한 피드백: 보안 상태를 시각적으로 표시
6. 마이크로커널 vs 모놀리식 커널
문제: 보안 관점에서 마이크로커널의 장점과, 그럼에도 불구하고 모놀리식 커널이 널리 사용되는 이유를 설명하시오.
모범답안: 마이크로커널의 보안 장점:
- 서비스별 프로세스 분리 (권한 분리)
- 각 서비스 최소 권한으로 실행
- 한 서비스 손상이 전체로 확산되지 않음
- 공격 표면(Attack Surface) 최소화
모놀리식이 선택된 이유:
- 성능: IPC 오버헤드 없음
- 구현 단순성: 함수 호출로 모든 기능 접근
- 개발 속도: 빠른 프로토타이핑 가능
- 디버깅 용이성: 전체 시스템을 한 곳에서 추적
결론: "메커니즘 경제성" 원칙이 실용성에서 더 중요하게 작용
핵심 요약
- CIA Triad는 정보보안의 기본 목표를 정의
- 9가지 보안 설계 원칙은 1975년 제시되었지만 현재도 유효
- 보안 설계는 여러 원칙의 균형점을 찾는 것이 중요
- 이론과 실제의 차이를 이해하고 적절한 타협점 필요
- 인간 요소를 고려한 보안 설계가 성공적인 보안 시스템의 핵심