NTLM과 Kerberos 이해하기: 핵심 차이점과 사용 사례

NTLM과 Kerberos 소개

공유를 위해 회사의 모든 리소스를 네트워크로 연결하는 것은 가치가 있지만, 승인된 사용자와 디바이스만 이러한 리소스에 액세스할 수 있는지 확인할 방법이 필요합니다. 인증은 사용자와 디바이스가 자신의 신원을 증명할 수 있는 방법을 제공함으로써 이 목적을 충족합니다.

Windows 환경에서는 두 가지 주요 인증 프로토콜이 사용됩니다. NTLM( New Technology LAN Manager )과 Kerberos입니다.

• NTLM은 오래된 챌린지-응답 기반 인증 프로토콜로, 현재도 레거시 시스템과 폴백(대체) 시나리오에서 사용됩니다.
• Kerberos는 티켓과 암호화를 활용해 Active Directory (AD) 환경에서 신원을 검증하는, 더 안전하고 효율적인 인증 프로토콜입니다.

이 글에서는 NTLM 대 Kerberos를 살펴보고, 가능하다면 Kerberos를 구현하는 것이 왜 중요한지 설명하겠습니다.

NTLM이란 무엇인가요?

NTLM은 Microsoft가 사용자 인증과 데이터 무결성 및 기밀성 보호를 위해 개발한 보안 프로토콜 모음입니다. 과거에는 오래된 Windows 버전에서 기본 인증 프로토콜로 사용되었지만, 오늘날에는 작업 그룹 환경, 로컬 계정 및 레거시 애플리케이션과 같은 제한된 시나리오에만 적용이 제한됩니다.

NTLM 인증은 다음과 같은 챌린지-응답(challenge response) 메커니즘을 통해 수행됩니다.

1. 클라이언트가 사용자 이름과 비밀번호를 사용해 로그인 요청을 보냅니다.
2. 서버는 챌린지(16바이트 무작위 숫자)로 응답합니다.
3. 클라이언트는 사용자의 해시된 비밀번호를 암호화 키로 사용해 챌린지를 암호화한 뒤, 이를 서버로 다시 전송합니다.
4. 서버는 Security Account Manager (SAM) 데이터베이스에 저장된 자격 증명과 응답을 대조해 확인합니다. 응답이 올바르면 인증이 허용됩니다.

변형: NTLMv1 vs NTLMv2

NTLM은 두 가지 버전이 있습니다. NTLM v1에는 더 취약한 해싱 알고리즘이 포함되어 있어 보안 침해에 더 쉽게 노출됩니다. 비교적 단순한 챌린지-응답 시스템은 패스-더-해시 공격과 레인보우 테이블 공격에 모두 취약합니다. 1993년 프로토콜의 또 다른 약점은 클라이언트가 서버의 신원을 확인할 수 없다는 점이며, 이로 인해 중간자(Man-in-the-Middle) 공격이 가능해집니다.

NTLMv2는 나중에 NTLMv1의 업그레이드 버전으로 개발되었습니다. 128비트 암호화(56비트 대신)를 지원하며, 가변 길이 챌린지와 클라이언트 측 타임스탬프 등 여러 보안 강화 기능을 추가했습니다. 이러한 개선에도 불구하고 Microsoft는 NTLM에서 완전히 벗어나고 있으며, 2023년 10월에 NTLMv2를 포함한 모든 NTLM 버전을 곧 사용 중단(Deprecated)할 계획을 발표했습니다.

Kerberos란 무엇인가요?

Kerberos는 비밀키 암호화를 통해 클라이언트-서버 애플리케이션에 강력한 보안을 제공하도록 설계된 네트워크 인증 프로토콜입니다. 사용자의 비밀번호를 네트워크를 통해 그대로 전송하는 대신, 유효 기간이 제한된 암호화 티켓을 사용합니다. 이는 도메인 컨트롤러에서 실행되며 Windows 2000부터 Windows 도메인에서 기본 인증 프로토콜로 사용되어 왔습니다. 덧붙이자면, 이 프로토콜은 그리스 신화에 나오는 저승의 삼두(三頭) 경비견 케르베로스(Cerberus)에서 이름을 따왔으며, 강력한 보안을 제공하는 역할을 반영합니다.

Kerberos는 “Single Sign-On”(SSO)의 원칙에 따라 동작하며, 티켓 발급 시스템을 사용해 사용자를 인증하고 네트워크를 통해 비밀번호를 반복해서 전송하지 않아도 리소스에 접근할 수 있도록 합니다. 한 번 인증이 완료되면, 사용자가 리소스에 접근하려 할 때마다 할당된 티켓을 제시해야 합니다. 다음은 인증 절차입니다.

• 사용자가 로그인하면, 클라이언트가 도메인 컨트롤러(DC)에서 호스팅되는 Key Distribution Center(KDC)로 Authentication Service Request(AS-REQ)를 전송합니다.
• KDC는 사용자의 신원을 확인하고, 암호화된 Ticket Granting Ticket(TGT)을 포함하는 Authentication Service Response(AS-REP)를 응답합니다.
• TGT는 KDC의 비밀 키로 암호화되며, 제한된 시간 동안만 유효합니다(일반적으로 10시간).
• 클라이언트가 서비스를 사용해야 할 때, TGT를 사용해 Ticket Granting Service (TGS)로부터 서비스 티켓을 요청합니다.
• TGS는 특정 서비스에 대한 티켓을 발급하며, 이 티켓은 해당 서비스의 비밀 키로 암호화됩니다.
• 클라이언트는 이 티켓을 서비스에 제시하여 인증을 받고 액세스 권한을 얻습니다.

보시다시피 Key Distribution Center (KDC)는 Kerberos 인증이 작동하는 방식에서 매우 중요한 부분입니다. KDC를 먼저 사용자의 신원을 확인한 다음, 서로 다른 리소스에 접근하는 데 필요한 특정 패스를 제공하는 보안 검문소라고 생각해 보세요.

NTLM과 Kerberos의 주요 차이점

NTLM과 Kerberos는 모두 인증 프로토콜이지만, 보안과 성능에 영향을 주는 서로 매우 다른 메커니즘과 보안 기능을 가지고 있습니다. 두 프로토콜이 어떤 점에서 서로 다른지 몇 가지 살펴보겠습니다.

인증 메커니즘

NTLM은 사용자가 네트워크 리소스에 접근할 때마다 사용자 신원을 확인하기 위해 챌린지-응답(질문-응답) 시스템을 사용합니다. 반면 Kerberos는 티켓을 사용합니다. 한 번 로그인하면 사용자는 Ticket Granting Ticket (TGT)를 받습니다. 어떤 리소스에 접근해야 할 때, 사용자는 이 TGT를 제시하여 서비스 티켓을 발급받습니다. 그런 다음 서비스 티켓을 사용해 비밀번호를 전송하지 않고도 네트워크 리소스에 접근할 수 있습니다.

보안 기능

NTLM은 비밀번호 해시를 저장하기 위해 MD4 또는 MD5 해싱 알고리즘을 사용하며, 클라이언트만 서버에 인증하므로 상호 인증을 지원하지 않습니다. 이러한 보안 기능이 부족한 NTLM은 여러 유형의 공격에 취약합니다. Kerberos는 다음을 통해 훨씬 더 강력한 보안을 제공합니다:

• 더 나은 보호를 위한 AES 암호화
• 클라이언트와 서버가 서로를 검증하는 상호 인증
• 크래킹 시도를 막기 위한 비밀번호 솔팅(salting)
• 재전송(Replay) 공격을 방지하는 시간 제한 인증 토큰
• 비밀번호가 네트워크를 통해 전송되지 않으므로 pass-the-hash 공격을 방어합니다

성능과 효율

보안 취약점이 많기는 하지만 NTLM은 Kerberos보다 더 적은 리소스를 필요로 합니다. 일반적으로 초기 인증에 더 빠르며, 규모가 작고 단순한 네트워크 환경에서는 효율이 더 높은 편입니다. 더 많은 리소스가 필요하긴 하지만, Kerberos는 캐시된 티켓을 사용해 이후 인증에서 상당한 시간을 절약하므로 대규모의 복잡한 환경에 훨씬 더 적합합니다.

위임과 가장(impersonation) 지원

NTLM은 가장(impersonation)만 지원하며, 로컬 시스템에서 서버 프로세스가 클라이언트의 보안 컨텍스트를 일시적으로 대신 맡을 수 있게 해줍니다. Kerberos는 가장(impersonation)과 인증의 위임(delegation) 모두를 지원합니다. 위임(delegation)을 통해 서비스는 도메인 사용자를 대신해 다른 서비스에 접근할 수 있습니다.

Windows 환경에서의 호환성 및 구현

Kerberos는 현대적인 Windows Active Directory 도메인에서 기본 인증 프로토콜이라는 점을 알아두세요. Microsoft는 Kerberos가 사용 불가능할 때에만 제한적으로 사용되는 NTLM을 완전히 대체하려는 의도를 가지고 있습니다.

보안상의 영향

NTLM의 취약점

이제 NTLM의 취약점과, 그 사용이 왜 매우 제한되어야 하는지에 대해 조금 더 자세히 살펴보겠습니다.

• NTLM은 패스-더-해시(pass-the-hash) 공격에 취약합니다. 공격자는 실제 비밀번호를 알지 못하더라도, 캡처한 비밀번호 해시를 사용해 인증할 수 있습니다.
• NTLM, 특히 NTLMv1은 MD4 해싱 알고리즘을 사용합니다. MD4는 약한 것으로 간주되며 레인보우 테이블 공격에 취약합니다. 이러한 약점 때문에 공격자는 비밀번호 해시를 더 쉽게 크랙하고 무단 액세스를 얻을 수 있습니다.
• NTLM의 챌린지-응답(challenge-response) 프로세스는 예측 가능하므로, 서명이나 암호화와 같은 추가 보안 조치가 구현되어 있지 않으면 리플레이(replay) 공격에 취약해집니다.

케르베로스가 더 안전한 이유

케르베로스는 이전 프로토콜의 한계를 보완하는 향상된 보안 기능을 갖춘 더 현대적인 인증 프로토콜입니다. 그중 일부 기능은 다음과 같습니다:

• 티켓 기반 인증은 네트워크를 통해 비밀번호를 전송할 필요를 없애므로, 비밀번호가 가로채질 위험을 줄여줍니다.
• AES 암호화와 같은 고급 암호화는 무차별 대입 공격(브루트 포스) 같은 무단 액세스 시도에 대한 전반적인 내성을 강화합니다.
• Kerberos가 스마트 카드나 생체 인식과 같은 추가 인증 요소를 사용할 수 있도록 하는 다중 인증(MFA) 지원으로, 비밀번호만 사용하는 것보다 한층 더 강화된 보안 계층을 제공합니다.

아래 차트는 NTLM과 Kerberos의 차이점을 요약한 것입니다.

NTLM과 Kerberos 중 언제 무엇을 사용해야 하나요?

Kerberos는 선호되는 인증 방법이지만, 일부 시나리오에서는 여전히 NTLM이 필요합니다. 예를 들어 서버가 도메인 컨트롤러와의 연결을 잃으면 로컬 로그인 인증이 필요해집니다. 중앙 집중식 도메인 컨트롤러가 없는 소규모 사무실 또는 홈 오피스 환경에서도 독립 실행형 컴퓨터에서 기본 계정 보안을 위해 NTLM에 의존합니다. 많은 레거시 애플리케이션은 여전히 NTLM 인증에 의존합니다. NTLM은 예외적인 상황에서 사용할 수 있는 대체(백업) 옵션이라고 생각하세요. Windows Active Directory 환경에서 작업하는 경우, 가능한 한 NTLM 사용을 피하고 Kerberos 인증을 강제하여 보안을 강화하고 위임을 지원하며 서비스 전반에서 원활한 인증이 가능하도록 해야 합니다.

사용 중인 프로토콜 확인

Windows 이벤트 뷰어는 개별 서버 또는 도메인 환경에서 인증 활동을 조사하는 데 유용한 도구입니다. 인증 유형을 확인하려면 보안 이벤트 로그를 확인하세요. 각 이벤트에는 고유한 이벤트 ID가 있습니다. 예를 들어 이벤트 ID 4776은 NTLM 인증을 의미합니다. 이 이벤트 로그 항목에는 사용된 계정과 인증 소스 등, 인증 시도에 대한 자세한 정보가 포함됩니다. 아래 스크린샷은 독립 실행형 머신의 로컬 Administrator 계정에 대한 NTLM 인증의 이벤트 ID 4776을 보여줍니다.

도메인 컨트롤러에서는 이벤트 ID 4768을 확인할 수 있는데, 이는 Kerberos를 의미합니다. 아래 스크린샷은 도메인 컨트롤러에서의 예를 보여줍니다.

명령 프롬프트를 열고 “klist”를 입력하면 Kerberos 티켓이 존재하는지 확인할 수 있습니다. 존재한다면, 아래에 표시된 것처럼 Kerberos가 사용되고 있다는 뜻입니다.

Wireshark 같은 패킷 분석 도구를 사용해 네트워크 트래픽을 캡처하고 분석할 수도 있습니다. Kerberos 트래픽은 일반적으로 포트 88을 사용하며, NTLM은 보통 NetBIOS 포트를 사용합니다.

NTLM에서 Kerberos로 전환

Windows 컴퓨터에서 NTLM을 비활성화하면 보안이 더 강화되지만, 해당 단계가 운영에 지장을 주지 않을 것이라고 완전히 확신할 때만 진행해야 합니다. 이전 섹션에 설명된 대로 이벤트 뷰어를 사용하여 NTLM이 어떻게 사용되고 있는지 확인하세요. 최소한 일부 컴퓨터에서는 NTLM이 필요하지 않다는 것이 확실하다면, 비활성화 프로세스를 시작할 수 있습니다.

Group Policy Management 콘솔을 열고 다음 경로로 이동합니다. 컴퓨터 구성 > 정책 > Windows 설정 > 보안 설정 > 로컬 정책 > 보안 옵션. 그런 다음 다음 정책을 수정합니다:

• 네트워크 보안: NTLM 제한: 들어오는 NTLM 트래픽 > 아래 스크린샷과 같이 모든 계정 거부로 설정합니다.

이것은 중요한 단계이므로, 아래의 팝업 창에 표시된 것처럼 Windows에서 의도를 확인하라는 메시지를 표시합니다:

또한 두 가지 정책을 추가로 구성해야 합니다.

• 네트워크 보안: NTLM 제한: 이 도메인의 NTLM 인증 > 모든 계정 거부로 설정
• 네트워크 보안: LAN Manager 인증 수준 > NTLMv2 응답만 보내기로 설정. 아래 스크린샷에 표시된 것처럼 LM & NTLM을 거부합니다:

정책은 처음에 테스트 또는 운영 환경이 아닌 환경에 배포하고, 철저히 테스트하십시오. 정책을 모든 컴퓨터에 한 번에 배포하지 마세요. 운영에 중단이 발생하지 않도록 배포를 점진적으로 분산하십시오. 이벤트 로그를 반드시 모니터링하세요.

마이그레이션에서 흔히 발생하는 문제 해결

Kerberos를 지원하지 않을 수 있는 일부 레거시 애플리케이션이 있을 수 있습니다. Kerberos 호환을 허용하는 업데이트가 있는지 조사해 보세요. 애플리케이션이 반드시 NTLM을 사용해야 한다면, NTLM 액세스를 특정 계정 또는 호스트로 제한하세요.

Kerberos 인증에는 정확한 DNS 확인(해석)과 네트워크 전반에 걸친 시간 동기화가 필요하다는 점에 유의하세요. 모든 도메인 컨트롤러, 클라이언트, 서비스가 적절한 DNS 설정과 NTP 시간 동기화로 구성되어 있는지 확인하십시오. 또한 인증 프로세스의 변경 사항, 특히 Single Sign-On (SSO) 기능과 관련해 사용자에게 교육해야 할 수도 있습니다.

인증 프로토콜을 보호하기 위한 모범 사례

• NTLM 사용을 반드시 필요한 경우로만 제한
• 이상한 인증 패턴이나 실패한 로그인 시도가 있는지 로그를 계속 모니터링하고, Windows Event Viewer 같은 도구를 사용해 인증과 관련된 Event ID를 추적하세요
• 취약점을 완화하기 위해 인증 프로세스에 관여하는 모든 시스템에 보안 패치와 업데이트를 정기적으로 적용하세요.
• 보안 점검을 수행하여 Kerberos 강제 적용 정책을 확인하고 승인되지 않은 NTLM 사용을 탐지하세요.
• 복잡한 비밀번호 정책을 구현해 계정 보안을 강화하고 이를 다중 요소 인증으로 보완하세요.
• 서비스 프린시펄 이름(Service Principal Name, SPN)을 정기적으로 감사하세요

실제 사용 사례 및 예시

기업이 계속 확장되고 복잡성이 커지는 동시에 Kerberos도 그에 맞춰 확장할 수 있도록 설계되었습니다. 사용자는 Single Sign-On(SSO)을 통해 한 번의 인증만으로 여러 서비스에 액세스할 수 있습니다. 이 프로토콜은 클라이언트와 서버가 서로의 신원을 확인하는 상호 인증을 제공하며, 자격 증명의 직접 전송을 막는 티켓 기반 시스템을 사용합니다. 이러한 방식은 보안을 강화할 뿐 아니라 서비스 위임도 지원하여, 복잡한 다계층 애플리케이션이 사용자를 대신해 리소스에 안전하게 접근할 수 있도록 합니다.

Kerberos와 하이브리드 환경

Microsoft는 하이브리드 네트워크 아키텍처가 증가하고 있다는 추세를 인정하고 있으며, 온프레미스와 클라우드 인프라를 아우르는 보다 유연하고 복잡한 네트워크 환경을 지원하도록 Kerberos를 조정하고 있습니다. 클라우드 기반 SSO 솔루션을 도입하는 조직의 경우, Kerberos를 최신 인증 프로토콜과 함께 사용하여 온프레미스 및 클라우드 리소스에 모두 원활하게 액세스할 수 있습니다. 또 다른 예로, Windows Hello for Business는 하이브리드 장치 구성을 필요로 하지 않고, 클라우드에 조인된 워크스테이션에서 Kerberos 인증을 사용해 온프레미스 리소스에 접근할 수 있도록 합니다.

레거시 애플리케이션

아직도 Kerberos가 널리 도입되기 전에 개발된 레거시 애플리케이션이 존재하며, 이들에는 따라서 NTLM이 필요합니다. 이러한 애플리케이션에 대해 고려할 사항 중 하나는, 자체적으로는 최신 Kerberos 인증을 완전히 지원하지 않는 Windows 2003 또는 2008 서버에서 실행하는 것입니다. 레거시 앱의 예는 다음과 같습니다:

• 일부 전사적 자원 관리(ERP) 및 인사(인사관리) 애플리케이션(특히 2000년대 이전에 개발된 경우)
• NTLM을 기본값으로 사용하는, 이전 버전의 IIS 또는 SMB에서 실행되는 레거시 Windows 기반 파일 서버 및 인트라넷 포털.
• Kerberos 위임을 지원하지 않는 오래된 원격 데스크톱 및 VPN 솔루션Kerberos delegation

결론

IT 솔루션을 선택할 때 보안은 최우선 고려사항이어야 하며, Kerberos vs NTLM의 경우 Kerberos가 분명 더 우수한 선택입니다. 다만 NTLM이 여전히 필요할 수 있는 특정 시나리오를 이해하는 것은 포괄적인 네트워크 관리를 위해 매우 중요합니다.

자주 묻는 질문(FAQ)

NTLM과 Kerberos의 차이점은 무엇인가요?

NTLM과 Kerberos는 모두 Windows 인증 프로토콜이지만, 차이가 큽니다. NTLM은 클라이언트가 비밀번호 해시를 사용해 서버에 대한 신원을 입증하는 단순한 챌린지-응답 메커니즘을 사용합니다. 상호 인증이 없으며, 다양한 공격 유형에 취약합니다. 반면 Kerberos는 상호 인증을 가능하게 하는 보다 정교한 티켓 기반 시스템으로, 강력한 AES 암호화를 사용하고 단일 로그인(SSO) 기능을 제공하며 네트워크 전반에 걸친 비밀번호 전송을 차단합니다. NTLM은 레거시 시스템에서 계속 지원되지만, 보안 기능과 성능이 뛰어나기 때문에 Kerberos는 현대 Windows Active Directory 도메인에서 표준 인증 프로토콜이 되었습니다.

Microsoft는 왜 NTLM에서 Kerberos로 전환했나요?

Microsoft는 더 강력한 보안, 향상된 확장성, 그리고 현대적인 엔터프라이즈 환경에서의 효율성을 필요로 하면서 NTLM에서 Kerberos로 전환했습니다. NTLM의 챌린지-응답 방식은 패스-더-해시(pass-the-hash) 및 릴레이(relay) 공격과 같은 공격에 취약했지만, Kerberos는 더 강력한 암호화, 상호 인증, 티켓 기반 인증을 도입하여 보안 위험을 줄이고 성능을 개선했습니다. 또한 Kerberos는 NTLM에 없는 위임(delegation), Single Sign-On(SSO), 그리고 다중 요소 인증(MFA)과의 통합 같은 고급 기능도 지원합니다. 이 때문에 Kerberos는 오늘날의 현대화된 하이브리드 네트워크에 훨씬 더 적합합니다.

NTLM은 더 이상 사용되지 않나요?

오늘날 NTLM 사용은 강력히 권장되지 않지만, 다음과 같은 제한된 시나리오에서는 필요합니다:

• 구형 Windows 작업 그룹 환경
• Kerberos를 지원하지 않는 레거시 애플리케이션
• 로컬 머신 인증
• Kerberos 인증에 실패했을 때의 대체 인증
• 독립 실행형 머신

NTLM이 로컬 인증에 사용되나요?

다음 시나리오에서는 NTLM이 로컬 Windows 머신 로그온의 주요 인증 프로토콜로 계속 사용됩니다:

1. 로컬 머신 로그인: 도메인 컨트롤러가 없는 워크그룹 환경의 독립 실행형 Windows 시스템의 경우, NTLM은 여전히 기본 인증 프로토콜로 사용됩니다.
2. 워크그룹 환경: 도메인 구조를 구현하지 않은 소규모 네트워크나 가정/재택 사무실에서는, NTLM이 머신 간의 피어 투 피어 인증을 가능하게 합니다.
3. 최소 권한 시나리오: 조직에서는 NTLM을 통해 인증되는 로컬 계정을 자주 사용하여 최소 권한 원칙을 구현합니다. 이러한 방식은 계정이 손상되더라도 해당 계정의 접근 권한을 로컬 머신에만 제한함으로써 잠재적 영향의 범위를 줄입니다.

대체 인증: 도메인 환경에서는 Kerberos 인증이 실패할 경우 NTLM이 대체 메커니즘 역할을 하여, 리소스에 대한 액세스가 계속되도록 보장합니다.