개인 공부용.
MDM + CA 인증서를 활용한 기기 인증 구조

전체 구조 설명
핵심 개념
MDM(Jamf/Intune)은 기기 관리 플랫폼이고, CA 인증서는 그 기기가 "조직이 관리하는 진짜 기기"임을 증명하는 디지털 신분증입니다. 이 둘의 조합으로 "관리된 기기만 SaaS 접근 가능" 이라는 정책이 구현됩니다.
① 인증서 발급 흐름 (MDM → CA → 기기)
MDM이 기기에 인증서를 밀어 넣는 과정입니다.
Jamf (macOS/iOS): Configuration Profile에 SCEP Payload를 포함시켜 배포. 기기가 프로파일을 받으면 자동으로 Issuing CA에 인증서 요청(CSR) 전송 → 서명된 인증서를 키체인에 저장.
Intune (Windows/Android): SCEP Certificate Profile 또는 PKCS Certificate Profile 방식. Windows는 NDES(Network Device Enrollment Service)를 통해 Microsoft CA와 연동. Android는 Android Enterprise로 Work Profile에 인증서 격리.
인증서에는 CN=기기ID (또는 UPN), SAN, Issuing CA 서명, 만료일 등이 포함됩니다.
② CA 인증서 신뢰 체인 (Root → Issuing)
Root CA (오프라인, 최상위)
└─ Issuing CA (온라인, 기기 인증서 서명)
└─ 기기 인증서 (각 엔드포인트 1개씩)
IdP와 SaaS는 Root CA의 공개키만 신뢰 목록에 등록해두면, 그 하위에서 발급된 모든 기기 인증서를 자동으로 신뢰합니다.
③ SaaS 접근 시 인증서 검증 (mTLS / Certificate-Based Auth)
기기가 SaaS에 접근할 때 IdP(Entra ID, Okta 등)의 Conditional Access 정책이 개입합니다.
- 기기 → IdP: 클라이언트 인증서(TLS handshake)를 제시
- IdP 검증 항목:
- 인증서 발급자가 신뢰하는 CA인가? (신뢰체인 확인)
- 인증서가 유효기간 내인가?
- CRL/OCSP에서 폐기되지 않았는가?
- 인증서의 CN/SAN이 해당 사용자/기기와 일치하는가?
- 검증 통과 → 액세스 토큰 발급 → SaaS 접근 허용
④ 미관리 기기 차단
인증서가 없는 개인 기기나 외부 기기는 클라이언트 인증서를 제시할 수 없으므로, Conditional Access 정책에서 TLS handshake 단계에서 차단됩니다. 아이디/패스워드를 알고 있어도 접근 불가.
Jamf vs Intune 비교
| 주요 플랫폼 | macOS, iOS | Windows, Android, iOS |
| 인증서 프로토콜 | SCEP | SCEP / PKCS#12 |
| CA 연동 | ADCS, 3rd-party CA | NDES + ADCS, PKCS |
| IdP 연동 | Jamf Connect (Okta/Entra ID) | Entra ID 네이티브 통합 |
| 정책 엔진 | Smart Groups + Config Profiles | Conditional Access 정책 |
Intune + Entra ID 조합은 M365 환경에서 가장 타이트하게 통합되고, Jamf는 macOS 관리 깊이가 더 뛰어나서 보통 혼용(Jamf for Mac, Intune for Windows)하는 구조가 많습니다.
'C.S. > Security' 카테고리의 다른 글
| SECON 2026 의 SASE 및 유사기술 업체 목록 (0) | 2026.03.12 |
|---|---|
| AI 가 추천하는 SECON 2026 전시부스 15곳 (0) | 2026.03.12 |
| SECON 2026 양자보안 관련 업체 목록 (0) | 2026.03.12 |
| CA 서버, RA 서버 차이 (0) | 2026.02.24 |
| LDAP (Lightweight Directory Access Protocol) (0) | 2026.01.13 |





























