화이트리스트
더 많은 작업
Whitelist; White List
보안에서 화이트리스트란 기본 정책이 모두 차단인 상황에서 예외적으로 접근이 가능한 대상을 지정하는 방식 또는 그 지정된 대상들을 말한다.
블랙리스트는 반대로 기본 정책이 모두 허용인 상황에서 예외적으로 차단하는 대상을 지정하는 것으로, 화이트리스트의 반대말이다.
- 화이트리스트가 블랙리스트에 비해 보안성이 우수하지만 가용성이나 편의성은 블랙리스트 방식이 더 우수하다.
| 구분 | 화이트리스트 (허용 목록) | 블랙리스트 (차단 목록) |
|---|---|---|
| 기본 동작 | 기본 거부(default deny), 목록에 있는 것만 허용 | 기본 허용(default allow), 목록에 있는 것만 차단 |
| 알려지지 않은 위협 | 목록에 없으므로 차단된다 | 목록에 오르기 전까지 통과한다 |
| 관리 부담 | 정상 대상을 모두 파악하고 계속 갱신해야 한다 | 새 위협이 나올 때마다 목록을 갱신해야 한다 |
| 오탐·업무 영향 | 등록하지 않은 정상 프로그램이 막혀 업무 불편이 생길 수 있다 | 업무 영향은 적다 |
| 적합한 곳 | 기능이 고정된 서버, 산업제어시스템, POS 단말, 키오스크, 고위험 업무 PC | 다양한 프로그램을 쓰는 일반 사용자 PC, 이메일 스팸 필터 |
| 예 | 애플리케이션 허용 목록, 방화벽의 기본 거부 규칙, 허용 IP 목록 | 백신의 시그니처, 악성 URL·IP 차단 목록 |
CISSP 출제 기준(7.7)은 'Whitelisting/blacklisting'이라는 표현을 쓴다. 한편 마이크로소프트 문서 등 최근의 업계 문서에서는 같은 개념을 허용 목록(allowlist)과 차단 목록(blocklist 또는 denylist)으로 부르는 경우가 늘었다. 뜻은 같으므로 어느 표현이 나와도 같은 개념으로 이해하면 된다.
애플리케이션 허용 목록(application allowlisting, application whitelisting)은 조직이 승인한 프로그램과 구성 요소(실행 파일, 라이브러리, 스크립트, 설치 파일)만 실행되게 하고 나머지는 모두 막는 통제이다. NIST SP 800-167(2015)은 이를 악성코드, 라이선스 없는 소프트웨어, 기타 승인되지 않은 소프트웨어의 실행을 막는 기술로 설명하며, 알려진 나쁜 것을 막고 나머지를 허용하는 백신의 차단 목록 방식과 반대로 알려진 좋은 것만 허용하고 나머지를 막는다고 대비한다. 시그니처가 아직 없는 신종 악성코드나 랜섬웨어의 실행 파일도 목록에 없으면 실행되지 않는다는 점이 가장 큰 장점이다.
NIST SP 800-167은 허용 목록에 쓸 수 있는 파일 속성으로 파일 경로, 파일 이름, 파일 크기, 전자서명(게시자), 암호 해시를 들고 각각의 강약을 설명한다.
| 규칙 기준 | 방식 | 장점 | 약점 |
|---|---|---|---|
| 해시 (hash) | 파일의 암호 해시 값이 목록과 같을 때만 허용 | 파일이 어디에 있든 정확히 식별한다. 한 바이트만 바뀌어도 다른 파일로 본다. | 패치·업데이트마다 해시가 바뀌어 목록을 계속 갱신해야 한다. |
| 경로 (path) | 특정 폴더나 경로에 있는 파일을 허용 (예: Program Files 아래) | 새 버전과 패치도 따로 등록할 필요가 없어 관리가 쉽다. | 그 경로에 사용자가 파일을 쓸 수 있으면 악성코드를 넣어 우회한다. 엄격한 쓰기 권한 통제가 전제이다. |
| 서명 (signature, publisher) | 코드 서명 인증서의 게시자, 제품 이름, 파일 이름, 버전으로 허용 | 업데이트해도 같은 게시자 서명이면 계속 허용되어 관리 부담이 적다. | 신뢰한 게시자의 모든 프로그램이 허용될 수 있고, 서명 키가 탈취되면 악성코드도 통과한다. 서명 없는 사내 프로그램은 따로 처리해야 한다. |
| 파일 이름·크기 | 이름이나 크기로 식별 | 간단하다 | 쉽게 위조되므로 단독으로 쓰지 않고 다른 속성과 조합한다. |
- 실무에서는 운영체제와 주요 상용 소프트웨어는 서명 규칙, 서명이 없는 사내 도구는 해시 규칙, 관리자만 쓸 수 있는 설치 경로는 경로 규칙으로 섞어 쓴다.
- 정상 파일을 악용하는 공격(LOLBins, Living off the Land)은 허용된 프로그램을 이용하므로, 스크립트 엔진이나 관리 도구처럼 악용되기 쉬운 프로그램은 필요 없는 사용자에게 막는 규칙을 더한다.
윈도우에는 두 가지 애플리케이션 제어 기술이 있다.
| 구분 | AppLocker | App Control for Business (WDAC) |
|---|---|---|
| 규칙 기준 | 게시자(서명 인증서에서 얻은 게시자 이름, 제품 이름, 파일 이름, 버전), 경로, 파일 해시 | 서명 인증서 속성, 파일 속성, 해시, 경로, 평판(Intelligent Security Graph) 등 |
| 적용 범위 | 컴퓨터의 전체 사용자 또는 특정 사용자·그룹 | 장치 전체(모든 사용자). 드라이버와 커널 코드까지 통제 |
| 보안 기능 지위 | 승인되지 않은 소프트웨어 실행 방지 도구이지만, 마이크로소프트 보안 대응 센터(MSRC)의 서비스 기준상 보안 기능에는 해당하지 않는다 | MSRC 서비스 기준상 보안 기능으로 설계되었다 |
| 쓰임 | 사용자·그룹별로 다른 규칙이 필요한 경우, 보조 통제 | 새 배포의 기본 선택, 강한 실행 통제 |
- 마이크로소프트는 애플리케이션 제어가 백신을 대체하지 않으며 함께 운영해야 한다고 안내한다.
- 리눅스에서는 fapolicyd, SELinux 정책, 실행 권한이 없는 파티션 마운트(noexec)로 비슷한 효과를 낸다.
애플리케이션 허용 목록은 효과가 크지만 운영 부담 때문에 실패하는 경우가 많다.
- 목록 작성: 현재 쓰는 프로그램 목록(소프트웨어 자산 목록)이 정확해야 한다. 기준 이미지(골든 이미지)에서 목록을 뽑는 방법이 흔하다.
- 감사 모드부터: 처음에는 차단하지 않고 기록만 남기는 감사(audit) 모드로 운영해, 차단될 프로그램을 파악하고 규칙을 다듬은 뒤 강제(enforcement) 모드로 바꾼다. NIST SP 800-167도 이런 단계적 도입을 권한다.
- 변경 연계: 새 프로그램 도입과 업데이트가 변경 관리 절차를 거치게 하고, 승인되면 목록에 반영한다. 패치 관리 주기에 맞춰 해시 규칙을 갱신한다.
- 예외 처리: 업무에 필요한 프로그램이 막혔을 때 빠르게 요청·승인하는 창구가 없으면 사용자가 우회를 시도하거나 정책을 꺼 버린다.
- 대상 우선순위: 기능이 고정된 서버, 관리자 PC, 산업제어시스템처럼 바뀌는 프로그램이 적고 위험이 큰 곳부터 적용한다.
- 화이트리스트(허용 목록)는 기본 거부, 블랙리스트(차단 목록)는 기본 허용이다. 알려지지 않은 악성코드 실행을 막는 데는 허용 목록이 더 효과적이다.
- 규칙 기준의 장단점을 구분한다: 해시는 정확하지만 업데이트마다 갱신, 경로는 쉽지만 쓰기 권한이 있으면 우회, 서명은 관리가 쉽지만 게시자 전체를 신뢰.
- 기능이 고정된 시스템(서버, POS, 산업제어시스템)에 허용 목록이 가장 알맞다.
- 허용 목록은 백신을 대체하지 않는다. 함께 쓰는 심층 방어 수단이다.
- 도입은 감사 모드 → 규칙 조정 → 강제 모드 순서로 한다. 운영 부담을 줄이려면 변경·패치 관리와 연계한다.
- 시험 문제에는 whitelisting/blacklisting과 allowlist/denylist가 섞여 나올 수 있다. 같은 개념이다.
- NIST SP 800-167, Guide to Application Whitelisting – NIST (2015)
- Application Control for Windows – Microsoft Learn
- AppLocker overview – Microsoft Learn
- App Control and AppLocker Overview – Microsoft Learn