RD 게이트웨이에 대한 MFA 설정 방법: 아키텍처, 단계 및 모범 사례

소개

원격 데스크톱 게이트웨이(RD 게이트웨이)는 HTTPS를 통해 RDP를 보호하지만, 비밀번호만으로는 피싱, 자격 증명 스터핑 또는 무차별 대입 공격을 막을 수 없습니다. 다단계 인증(MFA)을 추가하면 세션이 설정되기 전에 사용자 신원을 확인하여 그 격차를 해소합니다. 이 가이드에서는 MFA가 RD 게이트웨이 및 NPS와 통합되는 방법, 정확한 구성 단계, 그리고 배포를 대규모로 신뢰할 수 있도록 유지하는 운영 팁을 배울 수 있습니다.

RD 게이트웨이에 MFA가 필요한 이유는 무엇인가요?

RD 게이트웨이는 중앙 집중화 및 감사합니다. 원격 액세스 그러나 스스로 도난당한 자격 증명을 무력화할 수는 없습니다. 자격 증명 스터핑과 피싱은 특히 레거시 프로토콜과 광범위한 노출이 있는 경우 단일 요소 방어를 일상적으로 우회합니다. RDG 인증 계층에서 MFA를 시행하면 대부분의 일반적인 공격을 차단하고 표적 침입의 비용을 극적으로 증가시킵니다.

인터넷에 노출된 RDP의 주요 위험은 비밀번호 재사용, 무차별 대입 시도, 토큰 재생, 잘못 구성된 TLS를 통한 세션 하이재킹입니다. MFA는 자격 증명 재생에 저항하는 두 번째 요소를 요구함으로써 이러한 위험에 대응합니다.

많은 프레임워크—NIST 800-63, ISO/IEC 27001 통제 및 다양한 사이버 보험 기준—암묵적으로 또는 명시적으로 MFA를 기대합니다. 원격 액세스 경로. RDG에서 MFA를 구현하면 배포 스택을 재구성하지 않고도 제어 의도와 감사자의 기대를 모두 충족합니다.

MFA가 RD 게이트웨이 아키텍처에 어떻게 적합합니까?

제어 평면은 간단합니다: 사용자가 RDG를 통해 RDP를 시작합니다; RDG는 RADIUS를 통해 NPS에 인증을 전송합니다; NPS는 정책을 평가하고 MFA 제공자를 호출합니다; 성공 시, NPS는 Access-Accept를 반환하고 RDG는 연결을 완료합니다. 내부 자산에 대한 권한 부여는 여전히 RD CAP/RD RAP에 의해 관리되므로 신원 증명은 방해가 아니라 추가적입니다.

• 인증 흐름 및 결정 지점
• 원격 사용자를 위한 UX 고려사항

인증 흐름 및 결정 지점

주요 결정 사항에는 MFA 로직이 실행되는 위치(NPS와 Entra MFA 확장 또는 타사 RADIUS 프록시), 허용되는 요소, 실패 처리 방법이 포함됩니다. NPS에 대한 결정을 중앙 집중화하면 감사 및 변경 관리가 간소화됩니다. 대규모 환경의 경우 정책 평가를 RDG 용량과 분리하고 유지 관리 창을 간소화하기 위해 전용 NPS 쌍을 고려하십시오.

원격 사용자를 위한 UX 고려사항

푸시 및 앱 기반 알림은 가장 신뢰할 수 있는 경험을 제공합니다. RDP 자격 증명 흐름. 보조 프롬프트 UI가 없는 경우 SMS 및 음성이 실패할 수 있습니다. 예상되는 프롬프트, 시간 초과 및 거부 사유에 대해 사용자에게 교육하여 지원 티켓을 줄이십시오. 높은 대기 시간 지역에서는 진정한 남용을 숨기지 않으면서 잘못된 실패를 피하기 위해 도전 시간 초과를 적절히 연장하십시오.

필수 조건 체크리스트란 무엇인가요?

깨끗한 설정은 검증된 플랫폼 역할과 신원 위생으로 시작됩니다. RDG가 지원되는 Windows Server에서 안정적인지 확인하고 롤백 경로를 계획하십시오. 사용자 액세스를 범위 지정하기 위한 디렉터리 그룹을 확인하고 관리자가 정책 변경을 인증서 또는 네트워크 문제와 구별할 수 있는지 검증하십시오.

• 역할, 포트 및 인증서
• 디렉토리 및 아이덴티티 준비 상태

역할, 포트 및 인증서

신뢰할 수 있는 AD 연결이 있는 서버에 NPS 역할을 배포하십시오. 표준화하십시오. RADIUS UDP 1812/1813 및 이전 1645/1646 사용을 문서화합니다. RDG에서 HTTPS 리스너에 대해 공개적으로 신뢰할 수 있는 TLS 인증서를 설치하고 약한 프로토콜 및 암호를 제거합니다. 공유 비밀은 티켓이나 데스크탑 메모가 아닌 금고에 기록합니다.

디렉토리 및 아이덴티티 준비 상태

RDG 허용 사용자 및 관리자를 위한 전용 AD 그룹을 생성하고 "도메인 사용자" 범위를 피하십시오. Entra ID를 사용하는 경우 사용자가 MFA에 등록되어 있는지 확인하십시오. 타사 공급자의 경우, 광범위한 등록 전에 신원을 동기화하고 파일럿 사용자를 끝에서 끝까지 테스트하십시오. RDG, NPS 및 MFA 플랫폼 간에 사용자 이름 형식(UPN vs sAMAccountName)을 정렬하여 무음 불일치를 피하십시오.

RD 게이트웨이에 대한 MFA의 단계별 구성은 무엇인가요?

• NPS 설치 및 등록
• RD 게이트웨이를 RADIUS 클라이언트로 추가하십시오.
• NPS 정책 생성 (CRP 및 NP)
• MFA 확장 프로그램 또는 타사 에이전트 설치
• 중앙 NPS(RD CAP 스토어)에 RD 게이트웨이 포인트 설정
• MFA 종단 간 테스트

1단계 — NPS 설치 및 등록

네트워크 정책 및 액세스 서비스 역할을 설치하려면 열기 nps.msc NPS를 Active Directory에 등록하여 사용자 속성을 읽을 수 있도록 합니다. 확인하십시오. 네트워크 정책 서버 (IAS) 서비스가 실행 중이며 서버가 낮은 대기 시간으로 도메인 컨트롤러에 도달할 수 있습니다. 로그 및 정책을 위해 NPS FQDN/IP를 기록해 두십시오.

선택적 명령:

Install-WindowsFeature NPAS -IncludeManagementTools nps.msc

실행 netsh nps 등록된 서버 추가

Get-Service IAS | Start-Service  
Test-Connection -Count 4 -ComputerName (Get-ADDomainController -Discover).HostName

2단계 — RD 게이트웨이를 RADIUS 클라이언트로 추가

RADIUS 클라이언트에서 IP/FQDN으로 RD 게이트웨이를 추가하고 친숙한 이름(예: RDG01 ), 그리고 공유된 긴 비밀 키를 사용하십시오. NPS 서버에서 UDP 1812/1813을 열고 도달 가능성을 확인하십시오. 여러 RDG를 실행하는 경우 각 RDG를 명시적으로 추가하십시오(서브넷 정의는 가능하지만 잘못 범위 지정하기가 더 쉽습니다).

선택적 명령

클라이언트 추가: netsh nps add client name="RDG01" address=10.0.10.20 sharedsecret="VeryLongVaultedSecret" vendor=standard enable=YES

netsh advfirewall firewall add rule name="RADIUS Auth (UDP 1812)" dir=in action=allow protocol=UDP localport=1812  
netsh advfirewall firewall add rule name="RADIUS Acct (UDP 1813)" dir=in action=allow protocol=UDP localport=1813

3단계 — NPS 정책 만들기 (CRP 및 NP)

RDG 클라이언트 IPv4 주소에 범위가 지정된 연결 요청 정책을 만듭니다. Microsoft Entra MFA(NPS 확장을 통한)에서 이 서버에서 인증하거나 원격 RADIUS(타사 MFA 프록시용)로 전달을 선택합니다. 그런 다음 AD 그룹(예: 포함된 네트워크 정책을 만듭니다. GRP_RDG_사용자 액세스가 허용되었습니다. 두 정책이 일반 규칙 위에 위치하도록 하십시오.

선택적 명령

# 사용자가 허용된 그룹에 있는지 확인
Get-ADUser user1 -Properties memberOf |
  Select-Object -ExpandProperty memberOf |
  Where-Object { $_ -like "*GRP_RDG_Users*" }

참조를 위한 수출 정책 스냅샷: reg export "HKLM\SYSTEM\CurrentControlSet\Services\IAS\Policy" C:\NPS-Policy.reg /y

4단계 — MFA 확장 프로그램 또는 타사 에이전트 설치

Microsoft Entra MFA의 경우, NPS 확장을 설치하고, 테넌트 바인딩 스크립트를 실행한 후 NPS를 재시작하십시오. 사용자가 MFA에 등록되어 있고 푸시/앱 방법을 선호하는지 확인하십시오. 타사 MFA의 경우, 공급업체의 RADIUS 프록시/에이전트를 설치하고, 엔드포인트/공유 비밀을 구성한 후 CRP를 해당 원격 그룹으로 지정하십시오.

선택적 명령

# Entra MFA NPS 확장 바인드
Set-Location "C:\Program Files\Microsoft\AzureMfa\"
.\AzureMfaNpsExtnConfigSetup.ps1
Restart-Service IAS

유용한 로깅 조정기 (0–3)  
New-Item -Path HKLM:\SOFTWARE\Microsoft\AzureMfa -Force | Out-Null  
New-ItemProperty HKLM:\SOFTWARE\Microsoft\AzureMfa -Name LOG_LEVEL -Value 2 -PropertyType DWord -Force | Out-Null

원격 RADIUS 그룹 및 서버 구성: netsh nps add remoteradiusservergroup name="MFA-VENDOR"
netsh nps add remoteradiusserver name="MFA-VENDOR" address=10.0.20.50 authport=1812 sharedsecret="AnotherVaultedSecret"

5단계 — RD 게이트웨이를 중앙 NPS(RD CAP 스토어)에 지정합니다.

RD 게이트웨이 서버에서 RD CAP 저장소를 NPS를 실행하는 중앙 서버로 설정하고, NPS 호스트 + 공유 비밀을 추가한 후 연결성을 확인합니다. RD CAP을 허용된 사용자 그룹에 맞추고 RD RAP을 특정 컴퓨터/컬렉션에 맞춥니다. MFA가 성공하지만 접근이 실패하는 경우, 먼저 RAP 범위를 확인하십시오.

6단계 — MFA 종단 간 테스트

외부 클라이언트에서 RDG를 통해 알려진 호스트에 연결하고 하나의 MFA 프롬프트, NPS 6272(액세스 허용) 및 성공적인 세션을 확인합니다. 또한 오류 명확성과 지원 준비 상태를 검증하기 위해 부정 경로(그룹에 없음, 등록되지 않음, 잘못된 요소, 만료된 토큰)를 테스트합니다.

MFA를 위한 RD 게이트웨이의 문제 해결 플레이북이란 무엇인가요?

문제 해결은 네트워크, 정책 및 신원 계층을 분리할 때 가장 빠릅니다. RADIUS 도달 가능성과 포트 검사를 시작한 다음 정책 일치를 검증하고 MFA 등록 및 요소 유형을 검토하십시오. 제어된 조건에서 테스트 계정을 유지하여 변경 기간 동안 일관되게 결과를 재현할 수 있습니다.

• 프롬프트, 루프 또는 타임아웃 없음
• 정책 일치 및 그룹 범위
• 실제로 사용할 수 있는 로깅 및 텔레메트리
• 보안 강화 및 운영 모범 사례
• 주변, TLS, 및 최소 권한
• 모니터링, 경고 및 변경 관리
• 회복력 및 복구

프롬프트, 루프 또는 타임아웃 없음

프롬프트가 없다는 것은 정책 주문 또는 MFA 등록의 간극을 나타냅니다. 루프는 NPS와 프록시 간의 공유 비밀 불일치 또는 포워딩 재귀를 나타냅니다. 타임아웃은 일반적으로 차단된 UDP 1812/1813, 비대칭 라우팅 또는 지나치게 공격적인 IDS/IPS 검사를 가리킵니다. 어떤 홉이 실패하는지 확인하기 위해 로그의 상세도를 일시적으로 증가시키십시오.

정책 일치 및 그룹 범위

연결 요청 정책이 RDG 클라이언트를 대상으로 하고 모든 포괄적 규칙 이전에 적용되는지 확인하십시오. 네트워크 정책에서 정확한 AD 그룹과 그룹 중첩 동작을 확인하십시오. 일부 환경에서는 토큰 부풀림 완화 또는 직접 멤버십이 필요합니다. UPN과 NT 스타일 이름 간의 사용자 이름 정규화 문제를 주의하십시오.

실제로 사용할 수 있는 로깅 및 텔레메트리

NPS 회계를 사용하여 상관 관계를 분석하고 RDG 운영 로그를 활성화 상태로 유지하십시오. MFA 플랫폼에서 사용자별 프롬프트, 거부 및 지리/IP 패턴을 검토하십시오. 경량 대시보드를 설정하십시오: 인증 볼륨, 실패율, 주요 실패 원인 및 평균 도전 시간. 이러한 지표는 용량과 관련하여 안내합니다. 보안 조정.

보안 강화 및 운영 모범 사례

MFA는 필요하지만 충분하지 않습니다. 네트워크 분할, 현대 TLS, 최소 권한 및 강력한 모니터링과 결합하십시오. 짧고 강제된 기준을 유지하십시오. 하드닝은 일관되게 적용되고 패치 및 업그레이드 후 검증될 때만 효과가 있습니다.

주변, TLS, 및 최소 권한

RDG를 LAN으로의 필수 흐름만 있는 강화된 DMZ 세그먼트에 배치하십시오. RDG에 신뢰할 수 있는 공인 인증서를 사용하고 레거시를 비활성화하십시오. TLS 약한 암호를 사용하고 있습니다. 전용 AD 그룹을 통해 RDG 액세스를 제한하고, 광범위한 권한 부여를 피하며, RD RAP이 사용자에게 실제로 필요한 시스템과 포트만 매핑되도록 합니다.

모니터링, 경고 및 변경 관리

인증 실패의 급증, 비정상적인 지리적 위치 또는 사용자당 반복적인 프롬프트에 대한 경고. NPS, RDG 및 MFA 플랫폼에서 승인 기록과 함께 구성 변경 사항을 기록합니다. 정책을 코드로 취급: 소스 제어에서 변경 사항을 추적하거나 최소한 변경 등록부에서 추적하고, 프로덕션 전환 전에 스테이징 환경에서 테스트합니다.

회복력 및 복구

NPS를 중복 실행하고 RDG를 구성하여 여러 RADIUS 서버를 참조하도록 합니다. 각 구성 요소에 대한 fail-open과 fail-closed 동작을 문서화합니다. 외부 액세스의 경우 기본값을 fail-closed로 설정합니다. NPS 구성, RDG 정책 및 MFA 설정을 백업합니다. 복구를 연습하며, 여기에는 재구성 후 MFA 확장 또는 에이전트의 인증서 교체 및 재등록이 포함됩니다.

결론

RD 게이트웨이에 MFA를 추가하면 인터넷에 노출된 RDP에서 가장 큰 취약점인 자격 증명 남용을 해결할 수 있습니다. NPS에서 정책을 중앙 집중화하고 Entra MFA 또는 타사 RADIUS 공급자를 통합함으로써 RD CAP/RD RAP 모델을 방해하지 않고 강력한 신원 증명을 시행할 수 있습니다. 목표 테스트로 검증하고 지속적으로 모니터링하며 MFA를 강화된 TLS, 최소 권한 및 복원력 있는 NPS/RDG 설계와 결합하십시오.