Microsoft 365

MDE와 Endpoint DLP를 이해하기 위한 디바이스 온보딩 개념 정리

Pepuri 2026. 5. 3. 22:15

이번 글에서는 디바이스 온보딩(Device Onboarding) 에 대해 정리해보려고 합니다.

이전에도 Deploy 관점에서 작성한 시리즈 글들이 있으니 참고하시면 좋을 것 같습니다.

2023.10.14 - [Microsoft Defender XDR/MDE] - Deploy Microsoft Defender for Endpoint (MDE). (0). Introduction

Microsoft Defender for Endpoint, 흔히 MDE를 조금이라도 다뤄보셨다면 “온보딩”이라는 표현을 많이 들어보셨을 것입니다. MDE는 이미 오래전부터 사용되어 온 기술이고, 실무에서는 간단히 MDE = EDR처럼 표현하기도 합니다.

그런데 이번 글에서 온보딩을 다루는 이유는 단순히 MDE 때문만은 아닙니다.

제가 더 중요하게 보고 있는 목적은 Endpoint DLP를 이해하기 위한 기반으로서 디바이스 온보딩을 정리하는 것입니다.

Endpoint DLP는 Microsoft Purview 영역에 있는 기능이지만, 실제 엔드포인트에서 동작하기 위해서는 디바이스가 Microsoft Defender for Endpoint 기반으로 온보딩되어 있어야 합니다. 따라서 Endpoint DLP를 제대로 이해하려면 먼저 MDE 온보딩 구조를 이해할 필요가 있습니다.

1. 온보딩에 대한 이해

1) 왜 Endpoint DLP에서 디바이스 온보딩이 필요한가?

Microsoft Learn의 Endpoint DLP 기술 자료를 보면 시작 단계에서부터 디바이스 온보딩이 필요하다고 안내합니다.

이유를 이해하려면 먼저 Microsoft Defender의 전체적인 개념을 간단히 볼 필요가 있습니다.

Microsoft 365 E5 보안 영역에서 Defender는 크게 다음과 같은 대상을 보호합니다.

메일
클라우드 앱
디바이스
Identity

제가 이해하는 Defender XDR의 핵심 개념은 다음과 같습니다.

여러 보안 영역에서 시그널을 수집하고, 로그를 모은 뒤, 이 로그 간의 상관관계를 분석하여 대응하는 구조

즉, Defender XDR은 단순히 개별 보안 제품의 집합이 아니라, 여러 영역의 신호를 모아 하나의 흐름으로 분석하고 대응하는 체계라고 볼 수 있습니다.

2) 클라우드 리소스와 디바이스의 차이

메일, 클라우드 앱, Entra ID Protection과 같은 영역은 이미 클라우드에 존재하는 리소스입니다.

예를 들어 Exchange Online, SharePoint Online, Microsoft Entra ID는 Microsoft 365 클라우드 안에서 동작합니다. 따라서 별도의 클라이언트 설치 없이도 서비스 간 연결을 통해 로그와 시그널을 수집할 수 있습니다.

반면 디바이스는 다릅니다.

Windows 11 클라이언트나 Windows Server와 같은 운영체제는 클라우드 리소스가 아니라 실제 사용자 환경에 존재하는 엔드포인트입니다. 이 장치에서 보안 시그널을 수집하려면 해당 장치를 Microsoft Defender for Endpoint에 연결하는 절차가 필요합니다.

이 절차를 디바이스 온보딩이라고 부릅니다.

Defender for Identity도 최근 구조가 많이 변경되었고, 기본적으로 관련 환경을 온보딩한 뒤 시그널을 수집하는 방식으로 이해할 수 있습니다.

정리하면 Defender의 핵심은 다음과 같습니다.

시그널을 수집한다.
로그를 모은다.
여러 로그의 상관관계를 분석한다.
탐지와 대응을 수행한다.

Endpoint DLP도 Purview 기능이지만, 엔드포인트에서 파일 사용, 복사, 업로드, 앱 사용 등의 행위를 감지하고 제어해야 하므로 디바이스 측 시그널이 필요합니다.

따라서 Endpoint DLP를 이해하려면 MDE 온보딩을 먼저 이해해야 합니다.

3) MDE 온보딩과 Endpoint DLP의 관계

Microsoft Defender for Endpoint와 Endpoint DLP는 서로 다른 포털과 관리 영역에 있는 것처럼 보이지만, 엔드포인트 관점에서는 매우 밀접하게 연결되어 있습니다.

실무적으로는 다음과 같이 이해하면 쉽습니다.

MDE는 엔드포인트 보안 시그널을 수집하고 EDR로 동작한다.
Endpoint DLP는 엔드포인트에서 데이터 유출 행위를 감지하고 제어한다.
두 기능 모두 엔드포인트에서 동작하기 위해 디바이스 온보딩이 필요하다.
Endpoint DLP는 MDE 온보딩 기반 위에서 동작한다고 이해할 수 있다.

즉, Endpoint DLP를 설정하기 전에 먼저 디바이스가 Defender for Endpoint에 온보딩되어 있어야 합니다.

이번 글에서는 디바이스를 온보딩하는 가장 기본적인 절차부터 정리합니다.

4) 온보딩 방식의 큰 구분

MDE 온보딩 문서를 보면 배포 전 준비, 역할 할당, 환경 확인 등의 단계가 있습니다.

실무적으로는 먼저 현재 환경이 어떤 형태인지 확인해야 합니다.

대표적으로 다음과 같이 나눌 수 있습니다.

구분	설명
Cloud-native	Active Directory 없이 Microsoft Entra ID와 Intune 중심으로 관리하는 환경
Co-management	Configuration Manager와 Intune을 함께 사용하는 환경
On-premises	Active Directory와 Group Policy 중심으로 관리하는 환경

이 글에서는 크게 두 가지 흐름을 기준으로 설명합니다.

방식	설명
Intune 기반 등록	디바이스를 Intune에 등록한 뒤 Defender로 온보딩하는 방식
Group Policy 기반 온보딩	AD GPO를 통해 온보딩 스크립트 또는 정책을 적용하는 방식

제가 실무적으로 설명할 때는 Intune을 통해 장치를 등록하고 관리하는 흐름을 Intune 온보딩이라고 부르고, Group Policy 기반으로 온보딩은 MDE 온보딩 이라고 부릅니다.

이 글에서도 동일하게 표현하겠습니다.

5) 기본 테스트 환경

이번 글에서 사용하는 기본 환경은 다음과 같습니다.

Active Directory가 구성되어 있음
Entra ID Connect를 통해 AD 개체가 Microsoft Entra ID로 동기화됨
디바이스는 Hybrid Join 상태로 구성 가능
Intune은 새 테스트 테넌트 기준으로 처음부터 설정
이후 Intune 온보딩 및 MDE 온보딩을 진행

참고로

Entra ID에 디바이스 개체가 동기화되어 있다고 해서, 해당 디바이스가 Intune에 등록된 것은 아닙니다.

Entra ID Connect는 말 그대로 개체를 동기화하는 역할을 합니다. 디바이스 개체를 Entra ID에 등록할 수는 있지만, 그것이 곧 Intune 관리나 보안 시그널 수집을 의미하지는 않습니다.

따라서 다음 두 개념은 구분해야 합니다.

구분	의미
Entra ID에 디바이스 등록	디바이스 개체가 Entra ID에 존재하는 상태
Intune에 디바이스 등록	디바이스가 MDM 관리 대상으로 등록된 상태

실제 운영 환경에서도 Entra ID에는 디바이스가 보이지만, Intune에는 보이지 않는 경우가 있습니다.

이 경우 해당 장치는 아직 Intune MDM Enrollment가 완료되지 않은 상태라고 볼 수 있습니다.

2. Intune Enrollment

먼저 Microsoft Entra 관리 센터에서 Intune 등록을 위한 기본 설정을 진행합니다.

2.1. Microsoft Intune 활성화

Entra 관리 센터에서 다음 위치로 이동합니다.

Microsoft Entra admin center
→ Mobility
→ Microsoft Intune

여기에서 MDM user scope를 설정합니다.

테스트 환경에서는 다음과 같이 설정합니다.

MDM user scope: All

이 설정은 어떤 사용자에게 MDM 등록을 허용할 것인지 범위를 정하는 설정입니다.

실제 운영 환경에서는 특정 사용자 그룹으로 제한할 수 있지만,

이번 글에서는 온보딩 개념을 설명하는 것이 목적이므로 All로 진행합니다.

설정을 변경한 뒤 Save를 클릭합니다.

이제 Intune에서 장치를 등록할 준비가 완료된 상태입니다.

2.2. AD Joined 디바이스를 Intune에 자동 등록하기

Active Directory에 조인된 디바이스를 Intune에 등록하려면 Group Policy를 사용할 수 있습니다.

쉽게 표현하면 다음과 같습니다.

AD에 조인된 Windows 디바이스에게 “너는 Intune에도 등록해야 한다”는 정책을 내려주는 과정

이번 예시에서는 AD에 다음과 같은 OU가 있다고 가정합니다.

그리고 이 OU 안에 AD 조인된 PC가 등록되어 있습니다.

이제 이 장치를 Intune에 자동 등록하도록 GPO를 생성합니다.

2.3. GPO 생성 및 MDM 자동 등록 설정

Domain Controller에서 Group Policy Management를 열고, 대상 OU에 새 GPO를 생성합니다.

GPO 편집기에서 다음 경로로 이동합니다.

Computer Configuration
→ Policies
→ Administrative Templates
→ Windows Components
→ MDM

여기에서 다음 설정을 엽니다.

Enable automatic MDM enrollment using default Azure AD credentials

설정을 다음과 같이 변경합니다.

Enabled
Credential Type: User Credential

2.4. 정책 반영 및 등록 확인

정책이 정상적으로 적용되면 Windows 설정에서 등록 상태를 확인할 수 있습니다.

Settings
→ Accounts
→ Access work or school

정상적으로 등록된 경우 회사 또는 조직에 의해 관리되고 있다는 정보가 표시됩니다.

또는 명령어로도 확인할 수 있습니다.

dsregcmd /status

출력 결과에서 다음과 같은 정보를 확인할 수 있습니다.

Managed by Intune

2.5. Task Scheduler를 통한 등록 동작 확인

장치 등록이 정상적으로 진행되지 않는 경우 Task Scheduler를 확인해볼 수 있습니다.

Windows에서는 MDM 등록과 관련된 작업이 스케줄링되어 동작합니다.

확인 위치는 다음과 같습니다.

Task Scheduler
→ Microsoft
→ Windows
→ EnterpriseMgmt

이 위치에서 디바이스 등록과 관련된 트리거와 작업을 확인할 수 있습니다.

따라서 Intune 등록이 예상대로 진행되지 않는 경우, 이 영역을 확인하면 문제 원인을 파악하는 데 도움이 될 수 있습니다.

2.6. Entra ID와 Intune에서 등록 상태 확인

GPO를 통해 MDM 등록이 완료되면 먼저 Entra 관리 센터에서 등록 상태가 확인될 수 있습니다.

이후 일정 시간이 지나면 Intune 관리 센터에서도 디바이스가 표시됩니다.

Entra ID에는 먼저 등록 상태가 반영되고, Intune에는 조금 늦게 표시될 수 있습니다.

따라서 등록 직후 Intune에 바로 보이지 않는다고 해서 반드시 실패한 것은 아닙니다.

일정 시간이 지난 뒤 다시 확인해야 합니다.

2.7. Entra ID Joined 디바이스 등록 방식

이번에는 Active Directory를 사용하지 않는 환경을 가정해보겠습니다.

AD가 없는 환경에서는 Entra ID Join을 통해 디바이스를 등록할 수 있습니다.

Windows 초기 설정 단계에서 Entra ID Join을 진행할 수도 있고, 이미 Workgroup으로 사용 중인 PC라면 Windows 설정에서 직접 연결할 수도 있습니다.

경로는 다음과 같습니다.

Settings
→ Accounts
→ Access work or school
→ Connect

여기에서 다음 옵션을 선택합니다.

Join this device to Microsoft Entra ID

과거에는 Azure AD Join이라고 불렸지만, 현재는 Microsoft Entra ID Join이라는 명칭을 사용합니다.

이후 사용자 계정을 입력하고 절차를 진행하면 디바이스가 Entra ID에 조인되고, Intune 등록도 함께 진행될 수 있습니다.

3. Defender 포털 프로비저닝

3.1. Microsoft Defender 포털 프로비저닝

Defender 설정을 진행하기 위해 Microsoft Defender 포털로 이동합니다.

Microsoft Defender portal
→ System
→ Settings

잠시 뒤, 아래와 같이 프로비저닝이 진행됩니다.

새로운 테스트 테넌트에서는 Defender XDR 공간이 아직 프로비저닝되어 있지 않을 수 있습니다.

이 경우 Defender 환경을 먼저 프로비저닝해야 합니다.

프로비저닝은 최초 1회만 필요하며, 완료까지 시간이 조금 걸릴 수 있습니다.

이 영역은 Entra ID나 Intune 관리 센터와는 별도의 Defender 백엔드 공간을 준비하는 과정으로 이해하면 됩니다.

3.2. Microsoft Intune connection 활성화

Defender XDR 프로비저닝이 완료되면 이제 Intune과 Microsoft Defender for Endpoint를 연결해야 합니다.

이 단계가 흔히 말하는 Intune connection입니다.

즉, 지금까지는 디바이스를 Intune에 등록하는 작업을 했고, 이제부터는 Intune과 Defender for Endpoint 사이의 서비스 간 연결을 구성하는 단계입니다.

설정 위치는 Microsoft Defender 포털에서 다음 경로로 이동합니다.

Microsoft Defender portal
→ Settings
→ Endpoints
→ General
→ Advanced features

여기에서 다음 항목을 찾습니다.

Microsoft Intune connection

해당 값을 On으로 변경한 뒤 저장합니다.

Microsoft Intune connection: On

이 설정을 켜면 Intune과 Defender for Endpoint가 연결되고, 이후 Intune에서 Defender for Endpoint 관련 온보딩 패키지를 자동으로 가져오거나 EDR 정책을 배포할 수 있는 기반이 마련됩니다.

3.3. Intune 관리 센터에서 연결 상태 확인

Defender 포털에서 Microsoft Intune connection을 활성화한 뒤에는 Intune 관리 센터에서 연결 상태를 확인합니다.

경로는 다음과 같습니다.

Microsoft Intune admin center
→ Endpoint security
→ Setup
→ Microsoft Defender for Endpoint

연결이 완료되면 Intune 관리 센터에서 어떤 플랫폼을 Microsoft Defender for Endpoint와 연계할지 설정할 수 있습니다.

경로는 다음과 같습니다.

Microsoft Intune admin center
→ Endpoint security
→ Microsoft Defender for Endpoint

여기에서 지원되는 플랫폼에 대해 Defender for Endpoint 연결을 활성화합니다.

예를 들어 Windows 디바이스를 대상으로 한다면 다음 항목을 활성화합니다.

Connect Windows devices to Microsoft Defender for Endpoint: On

이 연결 설정은 Defender와 Intune의 통합을 위한 설정이며, 실제 Windows 디바이스가 Defender for Endpoint로 시그널을 보내도록 만드는 EDR 온보딩 정책 배포와는 구분해서 이해해야 합니다.

3.4. EDR 온보딩 정책 배포

이제 실제 Windows 디바이스를 Microsoft Defender for Endpoint에 온보딩해야 합니다.

Intune에서 EDR 온보딩 정책을 만들기 위해 다음 경로로 이동합니다.

Microsoft Intune admin center
→ Endpoint security
→ Endpoint detection and response

여기에서 새 정책을 생성합니다.

Create Policy

정책 생성 시 플랫폼과 프로필은 다음과 같이 선택합니다.

Platform: Windows
Profile: Endpoint detection and response

정책 이름을 지정합니다.

이후 Configuration settings에서 Microsoft Defender for Endpoint 클라이언트 구성 패키지 유형을 선택합니다.

Intune과 Defender for Endpoint 연결이 정상적으로 완료되어 있다면 다음 옵션을 사용할 수 있습니다.

Microsoft Defender for Endpoint client configuration package type:
Auto from connector

Auto from connector는 Intune이 Defender for Endpoint에서 최신 온보딩 패키지를 자동으로 가져와 사용하는 방식입니다.

온보딩 대상 그룹을 지정합니다.

따라서 별도로 Defender 포털에서 온보딩 패키지를 다운로드해서 업로드하지 않아도 됩니다.

3.5. Auto from connector의 의미

Auto from connector는 Intune과 Defender for Endpoint가 정상적으로 연결되어 있을 때 사용할 수 있는 권장 방식입니다.

이 방식의 장점은 다음과 같습니다.

Intune이 Defender for Endpoint에서 최신 온보딩 패키지를 자동으로 가져옴
별도의 수동 패키지 다운로드가 필요 없음
EDR 정책 생성 시 최신 온보딩 구성을 사용할 수 있음
Intune 관리 디바이스에 정책으로 배포 가능

반대로 Intune과 Defender for Endpoint 연결이 되어 있지 않거나,

특수한 환경에서는 수동 온보딩 패키지를 사용할 수 있습니다.

수동 방식에서는 Microsoft Defender 포털에서 온보딩 패키지를 다운로드한 뒤 Intune 정책에 직접 넣어야 합니다.

하지만 일반적인 Intune 기반 배포에서는 Auto from connector 방식을 사용하는 것이 더 간단합니다.

3.6. 온보딩 상태 확인

아래와 같이 온보딩 상태를 확인합니다.

4. MDE 온보딩

4.1. MDE 온보딩의 의미

이제부터 진행하는 단계는 제가 구분해서 부르는 MDE 온보딩입니다.

앞에서 설명한 Intune 등록은 디바이스를 Intune 관리 대상으로 만드는 과정이었습니다.

반면 여기서 말하는 MDE 온보딩은 Intune에 등록하지 않고, Microsoft Defender for Endpoint 온보딩 패키지를 Group Policy로 배포해서 장치를 Defender for Endpoint에 직접 연결하는 방식입니다.

이 방식으로 온보딩된 장치는 Intune에 MDM 등록된 장치가 아니기 때문에, 관리 상태를 확인했을 때 Managed by Intune이 아니라 Managed by MDE 형태로 이해할 수 있습니다.

4.2. 왜 Group Policy 방식의 MDE 온보딩이 필요한가?

모든 환경에서 Intune을 바로 사용할 수 있는 것은 아닙니다.

기존 Active Directory 기반으로 운영 중이며, 여러가지 특수한 환경에 의해서 Intune Enrollment 정책을 배포하기 어려운 환경은 존재합니다.

MDE 온보딩이 필요한 환경은 다음과 같습니다.

디바이스는 AD Join 상태임
Intune MDM Enrollment는 아직 적용하지 않음/못함
기존 GPO 기반 운영 체계를 유지하고 있음
먼저 Defender for Endpoint만 빠르게 온보딩하고 싶음
서버 또는 일부 업무망 장치는 Intune 등록이 어려움

이 경우 Intune을 먼저 구성하지 않아도, Group Policy를 통해 Microsoft Defender for Endpoint 온보딩 패키지를 배포할 수 있습니다.

이 방식이 바로 제가 말하는 MDE 온보딩입니다.

흐름은 다음과 같습니다.

AD Joined Device
→ Group Policy
→ MDE Onboarding Script 실행
→ Microsoft Defender for Endpoint 서비스 연결
→ Defender 포털에 장치 표시
→ Managed by MDE 상태로 보안 설정 관리 가능

4.3. Defender 포털에서 Group Policy용 온보딩 패키지 다운로드

먼저 Microsoft Defender 포털에서 온보딩 패키지를 다운로드합니다.

경로는 다음과 같습니다.

Microsoft Defender portal
→ Settings
→ Endpoints
→ Device management
→ Onboarding

여기에서 운영체제를 선택합니다.

Operating system: Windows 10 and Windows 11

또는 서버를 대상으로 한다면 해당 Windows Server 운영체제를 선택합니다.

배포 방식은 다음과 같이 선택합니다.

Deployment method: Group Policy

그 다음 온보딩 패키지를 다운로드합니다.

Download onboarding package

압축을 해제하면 다음과 같은 파일을 확인할 수 있습니다.

WindowsDefenderATPOnboardingScript.cmd

이 스크립트가 실제 장치를 Microsoft Defender for Endpoint에 온보딩하는 데 사용됩니다.

4.4. 온보딩 스크립트 공유 경로 준비

Group Policy에서 클라이언트가 스크립트를 실행하려면, 대상 장치가 접근할 수 있는 공유 경로가 필요합니다.

예를 들어 파일 서버에 다음과 같은 공유 폴더를 만들 수 있습니다.

\\fileserver.contoso.com\MDEOnboarding

해당 공유 폴더에 온보딩 스크립트를 복사합니다.

\\fileserver.contoso.com\MDEOnboarding\WindowsDefenderATPOnboardingScript.cmd

이때 중요한 점은 대상 컴퓨터 계정이 해당 경로에 접근할 수 있어야 한다는 것입니다.

저는 테스트 목적으로 Everyone read 권한으로 설정하였습니다.

운영 환경에서는 보안 정책에 따라 권한을 더 엄격하게 구성할 수 있습니다.

중요한 것은 클라이언트 장치가 GPO를 통해 해당 스크립트를 실행할 수 있어야 한다는 점입니다.

4.5. Group Policy에서 Scheduled Task 생성

이제 Group Policy Management Console에서 새 GPO를 생성합니다.

GPO를 편집한 뒤 다음 경로로 이동합니다.

Computer Configuration
→ Preferences
→ Control Panel Settings
→ Scheduled Tasks

여기에서 새 작업을 생성합니다.

New
→ Immediate Task (At least Windows 7)

이 방식은 GPO가 적용될 때 대상 장치에서 즉시 작업을 실행하는 구조입니다.

4.6. Scheduled Task 일반 설정

Scheduled Task의 General 탭에서 다음과 같이 설정합니다.

Change User or Group

또는 UI에서 SYSTEM을 입력한 뒤 Check Names를 클릭하면 다음과 같이 확인될 수 있습니다.

NT AUTHORITY\SYSTEM

옵션은 다음과 같이 설정합니다.

Run whether user is logged on or not
Run with highest privileges

이 설정을 사용하는 이유는 온보딩 스크립트가 사용자 권한이 아니라 시스템 권한으로 실행되어야 하기 때문입니다.

Actions 탭에서 새 작업을 추가합니다.

Actions
→ New

Action에서 다음과 같이 경로를 입력합니다.

Program/script에는 온보딩 스크립트의 UNC 경로를 입력합니다.

\\fileserver.contoso.com\MDEOnboarding\WindowsDefenderATPOnboardingScript.cmd

여기서 로컬 경로가 아니라 UNC 경로를 사용하는 것이 좋습니다.

4.7. 클라이언트에서 MDE 온보딩 상태 확인

클라이언트에서 온보딩 상태를 확인하려면 레지스트리와 서비스 상태를 확인할 수 있습니다.

먼저 Sense 서비스가 존재하고 실행 중인지 확인합니다.

Get-Service Sense

정상적으로 실행 중이라면 다음과 유사한 상태를 확인할 수 있습니다.

Status   Name    DisplayName
------   ----    -----------
Running  Sense   Windows Defender Advanced Threat Protection Service

레지스트리에서도 온보딩 상태를 확인할 수 있습니다.

reg query "HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status"

예를 들어 다음 값이 확인되면 온보딩 상태를 판단하는 데 도움이 됩니다.

OnboardingState

일반적으로 OnboardingState 값이 1이면 온보딩된 상태로 볼 수 있습니다.

온보딩이 완료되면 Microsoft Defender 포털에서 장치가 표시되는지 확인합니다.

경로는 다음과 같습니다.

Microsoft Defender portal
→ Assets
→ Devices

정상적으로 온보딩된 장치는 Devices 목록에 표시됩니다.

다만 장치가 즉시 표시되지 않을 수 있습니다.

일반적으로 다음 시간이 필요할 수 있습니다.

GPO 적용
→ Scheduled Task 실행
→ 온보딩 스크립트 실행
→ Sense 서비스 초기화
→ 최초 보안 시그널 전송
→ Defender 포털에 장치 표시

따라서 온보딩 직후 바로 보이지 않더라도 일정 시간 후 다시 확인해야 합니다.

4.8. Integration

MDE 온보딩 장치는 Integration 설정을 통해서 Intune에 MDM 등록된 장치가 아니더라도, Microsoft Defender for Endpoint Security settings management를 통해 일부 Endpoint Security 정책을 받을 수 있습니다.

이 방식은 다음과 같은 환경에서 유용합니다.

서버 장치
Intune 등록이 어려운 기존 AD Joined 장치
GPO 중심으로 운영 중인 환경
빠르게 Defender for Endpoint 온보딩을 먼저 진행해야 하는 환경
Intune MDM 관리 전환 전 중간 단계

Integration을 적용하려면 Defender 포털에서 Enforcement Scope를 확인해야 합니다.

경로는 다음과 같습니다.

Microsoft Defender portal
→ Settings
→ Endpoints
→ Configuration management
→ Enforcement scope

여기에서 Microsoft Defender for Endpoint가 어떤 장치에 보안 설정을 적용할 수 있는지 범위를 지정합니다.

범위는 전체 장치로 설정할 수도 있고, 특정 태그를 가진 장치만 대상으로 제한할 수도 있습니다.

운영 환경에서는 처음부터 전체 장치를 대상으로 하기보다, 테스트용 태그를 사용해서 범위를 제한하는 것이 좋습니다.

Intune 관리 센터에서 적용된 디바이스를 확인할 수 있습니다.

Microsoft Intune admin center
→ Devices
→ All devices

정리하면 다음과 같습니다.

Intune Onboarding
= Intune에 장치를 등록해서 Managed by Intune으로 관리하는 방식

MDE Onboarding
= Group Policy로 Defender for Endpoint에 온보딩하고 Managed by MDE로 관리하는 방식

따라서 기존 AD 기반 환경에서 Endpoint DLP나 Defender for Endpoint를 설명할 때는, 먼저 Group Policy 기반 MDE 온보딩을 통해 장치를 Defender for Endpoint에 연결하고, 이후 Managed by MDE 상태에서 보안 설정을 관리할 수 있다는 흐름으로 설명하는 것이 더 자연스럽습니다.

다음 포스팅과 영상은 Endpoint DLP나 MDE의 새부설정에 대해서 다룰 예정입니다.

저작자표시 비영리 변경금지 (새창열림)