계약직 디자이너 Jake가 프로젝트에 합류했다. 접근 권한이 설정됐고, MFA도 활성화돼 있다. 그는 매일 개인 맥북으로 접속해 작업한다.
그의 신원 확인은 매번 통과한다. 그런데 IT 팀은 이 맥북의 존재를 모른다. MDM에 등록되지 않았고, EDR도 없다. macOS 업데이트는 8개월 전에 멈췄다. 개인 앱 수십 개가 설치돼 있는데, 그 중 하나의 공급업체가 지난달 공급망 공격을 당했다는 사실이 공개됐다. Jake는 모른다.
공격자가 이미 Jake의 맥북에 들어와 있다고 가정하자. 이 시점에서 공격자의 선택지는 두 가지다. 하나는 키 로거로 Jake의 자격증명을 수집한 뒤 다른 기기에서 직접 로그인하는 것. 다른 하나는 Jake의 기기에서 세션 토큰을 탈취해 Jake가 이미 인증된 세션을 가로채는 것. 두 경우 모두 신원 확인 관점에서는 Jake의 정상 접근과 구별되지 않는다.
신원(identity)은 "이 사람이 맞는가"에 답한다. 하지만 그 사람의 기기가 이미 침해된 상태라면, 그 신원 확인은 무의미해진다.
신뢰의 전제가 바뀌어야 한다
"네트워크 위치로 신뢰를 판단하는 것"에는 한계가 있다. 내부망에 있다고 신뢰할 수 없다. 같은 논리가 기기에도 그대로 적용된다. 회사 소유 기기라고 신뢰할 수 없고, 신원이 맞는 사람이 쓰는 기기라고 신뢰할 수 없다.
전통적 접근 제어 모델은 기기를 신뢰 판단의 변수로 보지 않았다. 올바른 자격증명으로 올바른 네트워크에서 접속하면 신뢰했다. 그런데 기기 자체가 침해되면 이 전제가 무너진다. 공격자는 침해된 기기에서 자격증명을 탈취하거나, 그 기기를 발판 삼아 내부 리소스에 직접 접근한다.
Zero Trust에서 기기는 신원과 별개의 신뢰 변수다.
올바른 사람이 신뢰할 수 있는 기기로 접근하는가
이 두 조건이 함께 충족돼야 한다.
Device Posture(기기 상태)는 기기가 신뢰할 수 있는 상태인지를 접근 시점에 평가하는 메커니즘이다.
Device Posture가 측정하는 것
Device Posture는 기기의 단일 속성이 아니라 여러 신호의 조합이다. 각 신호가 무엇을 측정하고, 왜 그것이 신뢰 판단에 필요한지를 이해해야 정책 설계가 가능하다.
- OS 및 패치 상태: 알려진 취약점(CVE)은 OS 버전과 패치 수준에 직결된다. 패치되지 않은 취약점은 공격자에게 기기 침투의 초기 경로를 제공한다. 특히 커널 권한 상승 취약점이 미패치 상태라면, 사용자 권한으로 실행된 프로세스가 시스템 전체를 장악할 수 있다. "8개월 전 마지막 업데이트"는 그 기간에 공개된 모든 CVE에 노출된 상태라는 의미다.
- 보안 소프트웨어: EDR(Endpoint Detection and Response)은 단순한 바이러스 백신이 아니다. 행동 기반 탐지, 프로세스 실행 흐름 추적(어떤 부모 프로세스에서 실행됐는지), 메모리 분석으로 알려지지 않은 위협도 식별한다. 이것이 중요한 이유는 EDR이 없는 기기가 "위협 없음"이 아니라 "위협을 알 수 없는 상태"라는 점이다. 이 구별이 Posture 평가에서 핵심이다. EDR이 "정상"이라고 보고한 기기와 EDR 자체가 없어서 아무 신호도 없는 기기는 전혀 다른 신뢰 수준을 가진다.
- 기기 설정: 디스크 암호화(FileVault, BitLocker)는 기기 분실 시 데이터 유출을 막는다. 화면 잠금 정책은 물리적 접근을 제한한다. 탈취된 기기는 OS 보안 모델 자체가 무력화된 상태다. 탈취된 Android 기기에서는 시스템 수준의 권한을 획득한 프로세스가 다른 앱의 샌드박스를 우회해 해당 앱의 데이터 디렉토리에 직접 접근할 수 있다. 브라우저나 인증 앱이 저장한 세션 토큰도 여기에 포함된다.
- 관리 상태: MDM(Mobile Device Management)에 등록된 기기는 IT 팀이 설정한 기업 정책이 적용되고 있다는 것을 의미한다. 등록되지 않은 기기는 회사가 어떤 소프트웨어가 설치됐는지, 어떤 설정이 적용됐는지 전혀 알 수 없다. 또한 기기 인증서의 유무는 "이 기기가 실제로 우리 조직에서 발급한 인증서를 보유하고 있는가"를 암호학적으로 확인할 수 있는 강력한 신뢰 지표다.
신호가 정책 결정에 닿는 경로
Device Posture를 측정하는 것 자체가 목표가 아니다. 측정한 결과가 접근 결정에 실제로 반영되어야 한다. 신호가 기기에서 정책 결정 엔진(PDP)까지 전달되는 경로가 아키텍처의 핵심이다.
실무에서 사용되는 경로는 크게 세 가지다.
MDM → IdP → 토큰 클레임: MDM이 기기의 정책 준수 여부를 평가하고, 그 결과를 IdP에 푸시한다. 사용자가 인증할 때 IdP는 해당 기기의 준수 상태를 OIDC 토큰의 클레임 또는 SAML 어설션의 속성(attribute)으로 포함한다. 게이트웨이는 이 값을 확인해 접근을 허용하거나 거부한다.
Microsoft Intune과 Azure AD의 Conditional Access, Jamf와 Okta의 연동이 이 패턴이다. 구현이 단순하고 기존 인증 흐름을 크게 바꾸지 않아도 된다는 장점이 있다.
단, 이 방식에는 신호 신선도(freshness) 문제가 있다. MDM과 IdP 사이의 동기화 주기가 보통 수분~수 시간이다. 기기가 Compliant 상태를 잃더라도 다음 동기화 전까지는 토큰에 compliant: true가 남아있다. 세션 중에 EDR이 비활성화됐어도 토큰에는 여전히 정상 상태가 기록돼 있다.
기기 에이전트 → 직접 보고: 기기에 설치된 ZTNA 에이전트(Cloudflare WARP, Zscaler Client Connector 등)가 접근 요청마다 또는 주기적으로 현재 Posture 상태를 ZTNA 플랫폼의 중앙 Posture 저장소에 전송한다. 게이트웨이는 접근 요청 시 이 저장소를 조회해 최신 상태를 확인한다. MDM 경로보다 데이터가 훨씬 신선하지만, 에이전트를 모든 기기에 배포해야 하고 에이전트 자체의 무결성 문제가 남는다.
기기 인증서 (mTLS): 조직 CA가 발급하고 MDM을 통해 배포된 기기 인증서를 TLS 핸드셰이크 시 클라이언트 인증서로 제시한다. 게이트웨이는 인증서의 서명을 조직 CA 공개키로 검증한다. 인증서가 유효하면 이 기기가 조직의 MDM에 등록됐다는 것을 암호학적으로 확인할 수 있다. 별도 에이전트 없이 동작하고 위조가 어렵다는 장점이 있지만, 인증서가 있다고 해서 현재 Posture가 양호하다는 의미는 아니며 MDM 등록 여부만을 증명한다.
이 세 경로를 조합해서 사용해야 한다. 인증서로 MDM 등록 여부를 확인하고, 에이전트 또는 MDM 동기화로 현재 Posture를 확인한다.
신호가 충돌할 때
여러 경로에서 신호를 수집할 때 서로 충돌하는 상황이 생긴다.
MDM(Mobile Device Management)이 "이 기기는 정책 준수 상태"라고 보고하는데, EDR(Endpoint Detection and Response)이 "활성 위협 탐지됨"을 알렸다. 무엇을 믿어야 하는가.
일반적인 처리 원칙은 가장 보수적인 신호를 따른다는 것이다. MDM 준수 상태는 기기 설정에 대한 신호이고, EDR 위협 탐지는 실시간 공격에 대한 신호다. 이 두 신호는 서로 다른 차원을 측정한다. 설정이 정상이더라도 실시간 공격이 감지됐다면, 접근을 차단하거나 세션을 즉시 종료하는 것이 맞다.
또 다른 충돌은 신호 부재다. 에이전트가 설치돼 있지 않아서 신호가 없다면, 이것은 "정상"이 아니라 "알 수 없음(Unknown)"이다. Unknown 상태를 어떻게 처리할지는 정책 설계의 핵심 결정이다. 많은 조직이 처음에 Unknown을 Partial과 같이 처리하고, 시간이 지나면서 Non-compliant와 동일하게 처리하는 방향으로 강화한다.
Posture 기반 접근 정책
Posture 평가 결과를 접근 결정에 반영하는 방식은 단순한 허용/거부가 아니다. 리소스의 민감도와 기기의 Posture 수준을 교차해 접근 범위를 결정한다.
| 기기 상태 | 낮은 민감도 리소스 (사내 Wiki, 이메일) | 중간 민감도 (소스코드, 내부 API) | 높은 민감도 (프로덕션 DB, 고객 데이터) |
| Compliant | 접근 허용 | 접근 허용 | 접근 허용 |
| Partial | 접근 허용 | 접근 허용 | 차단 |
| Non-compliant | 읽기 전용 제한 또는 등록 유도 | 차단 | 차단 |
| Unknown | 읽기 전용 제한 또는 등록 유도 | 차단 | 차단 |
이 구조에서 몇 가지 설계 결정이 중요하다.
- 등록 유도 vs 단순 차단: Non-compliant 또는 Unknown 기기를 그냥 차단하면 "왜 안 되는지" 모르는 사용자가 IT 티켓을 쏟아낸다. 대신 등록 안내 페이지(enrollment page)로 리다이렉트하면, 사용자가 무엇을 해야 하는지 알고 스스로 해결할 수 있다. 초기 도입 시에는 이 방식이 저항을 크게 줄인다.
- Partial 상태의 정의: 어떤 항목이 미충족됐을 때 Partial로 분류할지는 조직마다 다르다. "EDR은 설치됐지만 서명이 24시간 이상 업데이트 안 됨"을 Partial로 볼 수도 있고, Non-compliant로 볼 수도 있다. 이 기준이 관대하면 의미가 없고, 너무 엄격하면 Partial 기기가 늘어나 운영 부담이 커진다.
Jake의 시나리오를 이 정책에 대입하면: MDM 미등록 + EDR 없음 + OS 패치 8개월 경과. MDM 미등록은 Unknown, EDR 없음과 OS 미패치는 Non-compliant다. 신원이 유효해도 프로덕션 시스템 접근은 차단되고, 기기 등록 페이지로 안내된다.
그런데 이 정책 매트릭스가 접근 시점에 한 번만 평가된다면 충분한가. 로그인 당시 Compliant였던 기기가 세션 도중 상태를 바꿀 수 있다.
연속 평가 — 로그인 이후에도 검증은 계속된다
Posture 체크를 로그인 시점에만 하는 것은 "한 번 인증하면 세션이 끝날 때까지 신뢰한다"는 정적 모델과 같은 구조적 한계를 가진다. 로그인 당시의 기기 상태가 세션 내내 유지된다는 보장이 없다. Device Posture도 세션 전체에서 지속적으로 평가돼야 한다.
세션 중에 Posture가 바뀌는 시나리오는 현실적으로 발생한다. EDR이 세션 중에 비활성화됐다. 의심스러운 프로세스가 감지됐다. OS 방화벽이 꺼졌다. 이 변화가 로그인 이후에 발생했더라도 즉각적인 재평가가 필요하다.
이를 Continuous Posture Assessment(지속 상태 평가)라고 한다. "Never Trust, Always Verify"가 로그인 이후에도 적용된다는 것이 Zero Trust의 핵심이고, Device Posture의 연속 평가는 그 구현이다.
연속 평가에서 실무적으로 중요한 것은 평가 주기와 세션 만료의 균형이다. 에이전트가 1분마다 상태를 보고하면 신선도는 높지만 네트워크와 CPU 오버헤드가 커진다. 15분 주기는 오버헤드가 적지만, 그 15분 사이에 기기가 침해됐다면 감지가 늦어진다. 리소스 민감도에 따라 주기를 다르게 설정하는 것이 현실적이다 — 프로덕션 DB 세션은 5분, 사내 Wiki 세션은 30분.
개인 기기 허용의 트레이드오프
Device Posture를 엄격하게 적용하면 MDM에 등록된 기업 관리 기기만 접근 가능하다. 그런데 현실에서는 계약직, 외부 협력사, 임원, 원격 근무자 등 다양한 사유로 개인 기기가 사용된다.
MDM 전체 관리 방식은 개인 기기에 적용하기 어렵다. MDM을 개인 기기에 설치하면 IT 팀이 개인 사진, 앱 목록, 위치 정보에 접근할 수 있게 되고, 원격 초기화 권한도 생긴다. 직원 입장에서는 개인 기기에 회사 관리 소프트웨어를 설치하는 것에 심리적 저항이 크고, 퇴사 시 개인 데이터가 함께 삭제될 수 있다는 우려가 있다.
이럴 때 두 가지 절충 방안이 있다.
- 업무 영역 분리 (Android Work Profile / iOS User Enrollment): 기기 전체를 관리하는 대신, 업무 앱과 데이터를 격리된 영역으로 운영한다. Android의 Work Profile은 OS 수준에서 업무 영역을 별도 공간으로 분리하고, iOS의 User Enrollment는 별도 APFS 볼륨을 생성해 업무 데이터를 격리한다. MDM은 이 업무 영역만 관리하고 개인 영역에는 접근하지 않는다. 직원은 "회사가 내 개인 사진을 볼 수 없다"는 것을 확인할 수 있다. 퇴사 시에도 업무 영역만 삭제된다.
- 접근 범위 제한: 개인 기기는 아예 저위험 리소스(이메일, 사내 Wiki, 읽기 전용 문서)만 접근 가능하도록 정책으로 제한한다. 소스코드 저장소, 프로덕션 시스템, 고객 데이터는 MDM에 등록된 기기에서만 접근 가능하다. Posture 체크보다 "관리 기기인가 개인 기기인가"의 구분이 주요 게이트가 된다. 구현이 단순하고 직원 프라이버시 우려가 없다. 단, 개인 기기로 고위험 리소스가 필요한 사용자는 기업 기기를 지급받아야 한다.
어떤 방식을 선택할지는 조직의 직원 구성, 작업 유형, 법적 요구사항에 따라 달라진다. 중요한 것은 "모두 허용"과 "모두 차단" 사이의 어딘가에 있는 합리적인 선을 명확히 긋는 것이다.
도입 전에 생각해볼 것들
Device Posture 도입에서 가장 큰 실수는 처음부터 모든 기기에 엄격한 기준을 적용하는 것이다. 기기 상태를 파악하기도 전에 Non-compliant 기기를 차단하면 정상 업무가 광범위하게 중단된다.
- 먼저 현황을 파악한다. 현재 어떤 기기들이 어떤 리소스에 접근하고 있는가. MDM에 등록된 기기가 몇 대인가. 등록되지 않은 기기가 접근하는 리소스 중 민감한 것은 무엇인가. 이 파악 없이 정책을 적용하면 어디가 끊기는지 예측할 수 없다.
- 리소스 민감도 기준으로 우선순위를 잡는다. 프로덕션 시스템, 소스코드 저장소, 고객 데이터부터 시작한다. 이 리소스들에 대한 Posture 요건을 먼저 설정하고, 사내 Wiki나 이메일 같은 낮은 민감도 리소스는 나중에 강화한다.
- 단계적으로 전환한다. 처음에는 Posture 체크를 감사(audit) 모드로 운영한다. 차단 없이 위반 사항만 기록하면서 어떤 기기가 어떤 요건을 충족하지 못하는지 데이터를 수집한다. 이 데이터를 바탕으로 조직 내에서 가장 많이 발생하는 Posture 문제(MDM 미등록, OS 패치 지연 등)를 파악하고, 해결 방법을 안내한 뒤 실제 정책을 적용한다.
Device Posture는 신원 확인과 결합할 때 의미가 온전해진다. "올바른 사람이 신원 확인을 통과했는가"와 "그 사람이 사용하는 기기가 신뢰할 수 있는 상태인가"가 함께 성립해야 Zero Trust의 접근 결정이 완성된다.
참고 자료
- Microsoft Intune — 기기 준수 정책: https://learn.microsoft.com/en-us/mem/intune/protect/device-compliance-get-started
- Azure AD Conditional Access — 기기 준수 조건: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-conditions#device-platforms
- Jamf — 기기 준수 연동: https://docs.jamf.com/jamf-pro/documentation/Compliance_Reporter.html
- NIST SP 800-124 Rev.2 — 모바일 기기 보안 가이드: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-124r2.pdf
- NIST SP 800-207 Zero Trust Architecture: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf