Microsoft가 2026년 5월 Intune 서비스 릴리스에서 조용히 컴플라이언스 보고 명확화를 발표했습니다. 그냥 스크롤 지나치기 쉽지만, 조직이 커스텀 컴플라이언스 정책이나 Android 앱 구성 보고를 사용 중이라면 무엇이 변경되었는지, 그리고 보안 태세에 왜 중요한지 정확히 이해하고 싶을 것입니다.

요약: 컴플라이언스 보고서의 기기 보고 값은 권위적이 아니라 정보 제공용입니다. 실제로 무엇을 의미하는지 살펴봅니다.

변경된 것

2026년 5월 18일 주 업데이트에서 Microsoft는 특정 컴플라이언스 보고서에 나타나는 Setting 열을 관리자가 해석하는 방법을 명확히 하도록 문서를 업데이트했습니다. 이 열은 기기에서 직접 보고된 값을 표시하며, Microsoft의 가이드는 이를 정보 제공용으로만 취급해야 한다고 명시하고, 기기 보고 데이터 검토를 위한 새로운 보안 고려사항을 추가했습니다.

영향받는 시나리오는 다음과 같습니다.

  • 커스텀 컴플라이언스 정책 — PowerShell 스크립트나 다른 프로브가 기기 상태를 수집하여 평가를 위해 Intune에 값을 반환
  • Android 앱 구성 보고 — 관리 앱이 컴플라이언스 인접 보고서에 나타나는 구성 데이터를 반환

이 구분이 중요한 이유

이것은 단순한 문서 정리가 아닙니다. Microsoft가 조직이 컴플라이언스 아키텍처의 신뢰 경계를 어떻게 생각해야 하는지에 대한 시그널입니다.

중요한 아키텍처: Intune은 컴플라이언스 평가자입니다. 정책을 배포하고, 기기 신호를 수집하고, 평가를 실행하고, 이진 isCompliant 플래그를 Microsoft Entra ID의 기기 오브젝트에 기록합니다. Conditional Access는 그 플래그를 읽어 액세스 결정을 내립니다. 인증 시점에 기기에 직접 쿼리하지 않습니다.

Setting 열의 기기 보고 값은 그 평가 중에 기기가 제시한 원시 클레임입니다. 기기가 말한 것이지 Intune이 독립적으로 검증한 것이 아닙니다.

왜 중요한가? 손상된 기기는 이론적으로 조작된 값을 반환할 수 있습니다. 권위 있는 컴플라이언스 신호는 서버 측 평가 결과입니다 — 기기의 자기 보고 데이터가 아닙니다. 이 값이 정보 제공용임을 명확히 함으로써, Microsoft는 중요한 원칙을 강화하고 있습니다: 기기가 자체 컴플라이언스 상태를 정확히 보고할 것이라고 신뢰할 수는 없습니다.

조직이 해야 할 일

커스텀 컴플라이언스 정책을 사용 중이라면:

  • 보고서에 표시되는 스크립트 반환 값은 컴플라이언스의 증거가 아니라 진단 컨텍스트입니다
  • 스크립트를 검토하여 의미 있고 스푸핑하기 어려운 신호를 측정하는지 확인하세요
  • 비정상적인 기기 보고 값을 다른 신호와 교차 참조하세요: Defender for Endpoint 위협 수준, Entra 위험 점수, 하드웨어 증명 데이터
  • 컴플라이언스 태세 중 어떤 부분이 기기 보고 데이터에 의존하고 어떤 부분이 서버 평가 신호에 의존하는지 문서화하세요

Android 앱 구성 보고를 사용 중이라면:

  • 보고서의 앱 반환 구성 데이터는 기기 상태 이해에 도움을 주지만, 컴플라이언스 결정은 Intune의 평가 엔진에 속합니다
  • 서버 측 확인 없이 이 값을 액세스 정책 결정의 주요 신호로 사용하지 마세요

모든 환경에 대해:

  • 비정상적인 기기 보고 값을 합격/불합격 판정이 아닌 조사 트리거로 취급하세요
  • 스크립트 기반 커스텀 컴플라이언스를 보완하기 위해 하드웨어 증명(TPM 기반 신호, 기기 상태 증명)을 계층화하는 것을 고려하세요
  • Conditional Access 정책이 앱 수준 우회가 아닌 Entra의 isCompliant 플래그를 통해 컴플라이언스를 강제하는지 확인하세요

변경되지 않은 것

이 업데이트가 변경하지 않는 것을 명시하는 것이 유용합니다.

  • 컴플라이언스 강제는 여전히 동일하게 작동합니다. Intune이 컴플라이언스를 평가하고, 결과를 Entra ID에 기록하고, Conditional Access가 이를 읽습니다. 파이프라인은 변경되지 않았습니다.
  • 커스텀 컴플라이언스 정책은 여전히 정상적으로 작동합니다. 스크립트는 여전히 실행되고, 출력은 여전히 평가되며, 컴플라이언스 상태는 여전히 Entra에 기록됩니다. Microsoft는 단지 원시 보고 값을 복음이 아닌 컨텍스트로 취급하길 원합니다.
  • Android 앱 구성 정책은 영향을 받지 않습니다. 정책 자체, 배포, 강제 동작은 변경되지 않았습니다.

더 큰 그림

이 업데이트는 Microsoft가 Zero Trust 이야기를 강화하는 더 넓은 패턴의 일부입니다. Zero Trust의 “결코 신뢰하지 않고, 항상 검증한다” 원칙은 기기에도 적용됩니다 — 관리되는 기기도 포함해서요. Microsoft가 구축한 컴플라이언스 아키텍처는 자기 보고 기기 데이터가 약한 고리이기 때문에, 정확히 기기 신뢰를 여러 층의 서버 측 평가를 통해 라우팅합니다.

이를 문서에서 명시적으로 만듦으로써, Microsoft는 조직이 컴플라이언스 프로그램을 더 신중하게 생각하도록 유도하고 있습니다. 커스텀 컴플라이언스 스크립트가 진짜로 위조하기 어려운 신호를 측정하고 있습니까? 여러 신호를 계층화하고 있습니까? Conditional Access 정책이 올바른 통제를 강제하고 있습니까?

대부분의 성숙한 환경에서 답은 그렇습니다 — 하지만 이는 컴플라이언스 정책을 감사하고 Zero Trust 통제가 관리 센터에서 녹색으로 보이는 것이 아니라 의도한 대로 작동하는지 확인하기에 좋은 기회입니다.

이 가이드는 또한 Microsoft의 기기 상태 증명에 대한 지속적 투자와 Intune, Defender for Endpoint, Entra ID Conditional Access 간의 더 깊은 통합과 연결됩니다. 방향은 명확합니다: 더 많은 서버 측 검증, 더 많은 계층화된 신호, 기기가 자신에 대해 말하는 것에 대한 의존 축소.

Intune 변경을 탐색하는 데 도움이 필요하십니까? Big Hat Group은 조직이 컴플라이언스 정책 아키텍처부터 Zero Trust 전략까지 Microsoft Intune 환경을 설계, 배포, 관리하도록 돕습니다. 커스텀 컴플라이언스 정책을 구축 중이거나 Conditional Access 통제를 강화 중이든, 올바르게 구축하도록 도울 수 있습니다. 여기로 연락하세요.

Big Hat Group은 최신 엔드포인트 관리, Microsoft Intune, Microsoft 365 배포를 전문으로 하는 Microsoft 파트너입니다.