252. 암호화 해시 솔트 감리 (Encryption Hash Salt Audit)

핵심 인사이트 (3줄 요약)

1. 본질: 중요 정보 보호는 목적에 따라 암호화(Encryption)와 해시(Hash)를 구분 적용해야 하며, 양방향·단방향을 혼동하면 보안 설계가 근본적으로 무너진다.
2. 가치: 비밀번호 솔트(Salt) 미적용 시 레인보우 테이블(Rainbow Table) 공격으로 전체 사용자 계정이 동시에 탈취되며, 솔트 적용만으로 이 위험을 원천 차단한다.
3. 판단 포인트: DB 내 비밀번호 컬럼이 SHA-256 단순 해시인지 vs. BCrypt/PBKDF2처럼 솔트+반복 연산이 적용된 해시인지가 감리 핵심 판단 기준이다.

Ⅰ. 개요 및 필요성

개인정보보호법(Personal Information Protection Act)과 정보통신망법은 주민등록번호·비밀번호·바이오정보 등의 암호화 저장을 의무화하고 있다. 공공정보화사업 감리에서 암호화·해시·솔트 적용 여부는 보안 점검의 최우선 항목이다.

┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│ Problem      │──▶│ Core Idea    │──▶│ Expected Gain │
└──────────────┘    └──────────────┘    └──────────────┘

• 📢 섹션 요약 비유: 비밀번호를 양방향 암호화로 저장하는 것은 "금고에 열쇠와 돈을 같이 넣어두는 것"이다. 단방향 해시만이 유일한 안전한 선택이다.

Ⅱ. 아키텍처 및 핵심 원리

┌────────────────────────────────────────────────────────────┐
│              비밀번호 해시 + 솔트 저장 흐름                  │
│                                                            │
│  사용자 입력: "password123"                                  │
│       │                                                    │
│       ▼                                                    │
│  ┌──────────────────────────────────┐                      │
│  │  솔트 생성 (16바이트 난수)         │                      │
│  │  Salt = "a8f3c2e1b7d9f4a2..."    │                      │
│  └──────────────┬───────────────────┘                      │
│                 │                                          │
│                 ▼                                          │
│  ┌──────────────────────────────────┐                      │
│  │  Hash( "password123" + Salt )    │                      │
│  │  또는 BCrypt(password, salt, 12) │  ← 반복 횟수(Cost) 12  │
│  └──────────────┬───────────────────┘                      │
│                 │                                          │
│                 ▼                                          │
│  DB 저장: { salt: "a8f3c2...", hash: "9b2f4a..." }         │
│                                                            │
│  검증 시: Hash( 입력값 + 저장된 Salt ) == 저장된 Hash?       │
└────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────┐
│  솔트 미적용 (취약)                           │
│                                             │
│  "password123" → SHA-256 → 0x5baa61...      │
│  "password123" → SHA-256 → 0x5baa61...      │
│  (동일 비밀번호 = 동일 해시 → 테이블 조회 가능) │
└─────────────────────────────────────────────┘

┌─────────────────────────────────────────────┐
│  솔트 적용 (안전)                             │
│                                             │
│  "password123" + Salt_A → 0x9b2f4a...       │
│  "password123" + Salt_B → 0xc7d3e8...       │
│  (동일 비밀번호도 다른 해시 → 테이블 무효화)   │
└─────────────────────────────────────────────┘

• 📢 섹션 요약 비유: BCrypt의 반복 연산(Cost)은 "금고를 열려면 열쇠를 만 번 돌려야 하는" 구조다. 공격자 입장에서는 수십억 번 시도가 수천 년이 걸린다.

Ⅲ. 비교 및 연결

┌────────────────────────────────────────────────────────────┐
│              암호화 키 관리 3계층 구조                       │
│                                                            │
│  ┌────────────────────────────┐                            │
│  │  마스터 키 (Master Key)     │  ← HSM/KMS 관리            │
│  └─────────────┬──────────────┘                            │
│                │ 암호화                                     │
│                ▼                                           │
│  ┌────────────────────────────┐                            │
│  │  데이터 암호화 키 (DEK)     │  ← 애플리케이션 레이어      │
│  └─────────────┬──────────────┘                            │
│                │ 암호화                                     │
│                ▼                                           │
│  ┌────────────────────────────┐                            │
│  │  실제 데이터 (암호문)        │  ← DB 저장                 │
│  └────────────────────────────┘                            │
│                                                            │
│  HSM: Hardware Security Module                             │
│  KMS: Key Management Service                               │
└────────────────────────────────────────────────────────────┘

• 📢 섹션 요약 비유: 암호화 키를 데이터와 같은 DB에 저장하는 것은 "금고 비밀번호를 금고 안에 넣어두는 것"이다. 키는 반드시 분리된 HSM(Hardware Security Module)에 보관해야 한다.

Ⅳ. 실무 적용 및 기술사 판단

1. DB 스키마 확인: 비밀번호 컬럼의 데이터 길이 확인

   • MD5: 32자, SHA-256: 64자, BCrypt: 60자 ($2a$ 접두사 포함)
   • 컬럼 길이가 32자이면 MD5 사용 의심 → 즉시 지적

2. 소스코드 확인: MessageDigest.getInstance("MD5") 등 취약 알고리즘 탐색

3. 실제 비밀번호 테스트: 알려진 평문("admin1234")의 해시 값이 레인보우 테이블에 존재하는지 확인

4. 솔트 저장 위치: 솔트가 해시 값과 같은 필드에 저장되는지, 별도 컬럼에 저장되는지 확인 (BCrypt는 해시에 솔트를 포함하여 저장)

판단 체크리스트

1. 위험 시나리오와 점검 범위가 문서로 합의되었는가?
2. 지표·증적·로그가 재현 가능하게 수집되는가?
3. 예외 상황과 오탐·미탐 처리 절차가 있는가?
4. 재시험 또는 후속 조치 기준이 수치로 정의되었는가?

• 📢 섹션 요약 비유: MD5 해시를 사용하는 것은 "자물쇠 제조사가 폐업한 구형 자물쇠"를 쓰는 것이다. 이미 열쇠 복제법이 공개된 만큼 즉시 교체가 필요하다.

Ⅴ. 기대효과 및 결론

체계적인 암호화·해시·솔트 감리를 통해 개인정보 침해 시에도 피해를 최소화하고 법적 의무를 이행할 수 있다. 특히 BCrypt/PBKDF2 적용은 무차별 대입(Brute Force) 공격 비용을 기하급수적으로 높여 현실적 공격을 불가능하게 만든다. 국내 개인정보 침해 사고의 약 30%가 평문 또는 취약 해시 저장에서 기인하며, 솔트+적응형 해시 적용만으로도 대부분의 대규모 유출 피해를 방지할 수 있다.

확장 방향은 ① Policy as Code, ② Continuous Audit, ③ 인공지능(AI, Artificial Intelligence) 기반 이상 탐지와 결합하는 것이다.

• 📢 섹션 요약 비유: BCrypt는 "금고를 열 때마다 퍼즐을 풀어야 하는 구조"다. 정상 사용자는 1번만 풀면 되지만, 공격자는 수억 번을 풀어야 하므로 현실적으로 포기하게 된다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

비밀 관리 → 암호화 해시 솔트 감리 → KDF·HSM 운영

👶 어린이를 위한 3줄 비유 설명

1. 비밀번호를 그냥 저장하는 건 일기장에 "내 비밀번호는 1234야"라고 쓰는 것과 같아.
2. 솔트는 음식에 소금을 넣듯 비밀번호에 랜덤 재료를 섞어서 같은 비밀번호도 완전히 다른 맛이 나게 하는 거야.
3. BCrypt는 그 섞은 음식을 만 번 더 끓이는 것처럼, 해커가 맛을 알아내려면 엄청난 시간이 걸려서 포기하게 만들어.