SPN과 Active Directory 및 보안에서의 역할

서비스 프린시펄 이름(Service Principal Names, SPNs)은 Active Directory 에서 Kerberos 인증을 위해 서비스 인스턴스를 서비스 계정에 매핑하는 데 사용되는 고유 식별자입니다. 이 문서에서는 SPN 구조, 등록 방법, 고유성 요구 사항, 도구(예: setspn), 그리고 보안상의 영향에 대해 설명합니다. 또한 Kerberoasting 같은 공격, 모범 사례, 탐지 방법, 하이브리드·클라우드·컨테이너 환경에서의 고급 사용 사례를 다룹니다.

서비스 프린시펄 이름(Service Principal Names, SPNs) 소개

SPN이란 무엇인가요? Active Directory를 어느 정도 경험한 Windows 관리자라도, 도메인 환경에서 Service Principal Names가 어떤 역할을 하는지 모를 수 있습니다. 보안 주체 이름(security principal name, SPN)은 특정 서비스 인스턴스를 해당 서비스를 실행하는 계정에 연결하는 고유 식별자이며, 이를 통해 클라이언트가 Active Directory(AD) 내에서 올바른 서비스에 인증하고 연결할 수 있게 해줍니다. 이는 여러 인스턴스의 서비스가 서로 다른 서버에서 실행될 수 있는 대규모 엔터프라이즈 환경에서 특히 중요합니다. 이 글에서는 Active Directory SPN이 무엇인지, 보안 측면에서 어떤 기여를 하는지, 그리고 오늘날 현대 네트워크에서 그 사용 범위가 어떻게 계속 확장되고 있는지를 살펴보겠습니다.

Kerberos 인증에서 SPN의 역할

비행기를 탑승하거나 영화관에 입장하려면 티켓이 필요하듯, Active Directory(AD) 내 리소스에 접근하려면 티켓이 필요합니다. 클라이언트가 AD에서 호스팅되는 서비스에 대한 접근을 요청하면, 프로세스는 다음과 같이 진행됩니다:

1. 서비스를 사용하려는 클라이언트가 해당 서비스에 대한 SPN을 생성합니다
2. 클라이언트가 해당 SPN을 사용해 도메인 컨트롤러에 티켓을 요청합니다
3. 도메인 컨트롤러가 해당 SPN에 대해 Active Directory를 검색합니다
4. 해당 항목을 찾으면 도메인 컨트롤러가 서비스 티켓을 발급합니다
5. 클라이언트는 이 티켓을 사용해 비밀번호 없이 서비스에 인증합니다

기초를 한 단계씩 살펴보기

SPN의 구성 요소

SPN은 여러 구성 요소로 이루어져 있으며, 이들을 결합하면 특정 서비스에 대한 완전한 식별 정보를 제공합니다:

1. 서비스 클래스: 이는 서비스 인스턴스의 이름입니다. 예를 들어 Microsoft SQL Server의 경우 “MSSQLSvc”, 웹 서비스의 경우 “www”입니다.
2. 호스트명: 서비스가 실행 중인 서버 또는 호스트를 지정합니다. Windows 머신의 NetBIOS 이름(예: “FilerServer”)이거나 “fileserver.company.com”처럼 정규화된 도메인 이름일 수 있습니다.
3. 계정: 서비스와 연결된 Active Directory 계정입니다. 이는 SPN 문자열 자체의 일부가 아니라, 서비스 프린シパル 이름이 등록되는 계정입니다.
4. 포트 (선택): 서비스가 표준이 아닌 포트에서 실행되는 경우 SPN에 지정할 수 있습니다.

Active Directory에서 흔히 사용되는 일반적인 SPN 예시

• 웹 서비스 – HTTP/webserver.netwrix.com
• SQL Server – MSSQLSvc/myhost.redmond.microsoft.com:1433
• 파일 공유 – CIFS/fileserver.contoso.com
• 원격 데스크톱 서비스 – TERMSRV/rdserver.abcdomain.com
• LDAP 인증 – LDAP/domaincontroller.fabricam.com

SPN과 Active Directory: 연결 관계

SPN이 Active Directory 개체와 통합되는 방식

SPN은 사용자 계정, 서비스 계정, 컴퓨터 개체와 같은 AD 개체와 연결된 속성입니다. SPN은 어떤 계정에서 어떤 서비스가 실행되는지를 나타내는 라벨 역할을 합니다. 이러한 연결을 통해 컴퓨터는 네트워크를 통해 비밀번호를 전송하지 않고도 Kerberos를 사용해 보안 인증을 수행할 수 있습니다. 서비스가 설치되거나 구성될 때, Kerberos가 인증 요청을 올바른 계정에 매핑할 수 있도록 SPN을 등록합니다. SPN이 적절히 구성되지 않으면 Kerberos 인증이 실패하여 인증 오류가 발생하고 서비스가 중단될 수 있습니다.

servicePrincipalName 속성에 SPN 저장

SPN은 개체의 servicePrincipalName 특성의 일부로서 Active Directory에 저장됩니다. 이 특성은 컴퓨터 계정과 서비스 계정에 존재합니다. 아래 스크린샷에 표시된 것처럼, Active Directory Users and Computers 를 사용하여 개체의 고급 속성에서 이 특성을 확인할 수 있습니다.

이 특성에는 해당 개체에 할당된 SPN 목록이 저장됩니다. 각 SPN 항목은 서비스 유형, 호스트, 그리고 선택적인 포트 번호를 포함하는 구조화된 형식을 따릅니다.

명령을 사용하면 AD 개체의 SPN을 확인할 수 있습니다: setspn –L hostname. 아래 예시에서는 이 명령을 사용하여 ABCDomain.com 이라는 도메인에 대해 도메인 컨트롤러가 생성한 SPN 목록을 확인합니다.

AD 포리스트에서 SPN 고유성의 중요성

각 서비스 주체 이름(service principal name)은 전체 Active Directory 포리스트에서 반드시 고유해야 합니다. 이러한 고유성 덕분에 Kerberos가 서비스 요청을 적절한 계정으로 올바르게 라우팅할 수 있습니다. 서로 다른 계정에 중복된 SPN이 있으면 인증 충돌이 발생하여 예측할 수 없는 동작 또는 인증 실패로 이어질 수 있습니다.

SPN 구성: 단계별 가이드

SPN 구성을 위한 필요 도구

SPN 구성을 위한 주요 도구는 Windows Server 운영 체제에 기본 제공되는 setspn.exe입니다. 이 명령줄 도구를 사용하면 관리자가 Active Directory 서비스 계정에 대한 서비스 주체 이름(SPN)을 읽고, 수정하고, 삭제할 수 있습니다.

이전에 예시에서는 setspn -L을 사용하여 컴퓨터 개체의 SPN을 확인했습니다. SPN을 추가하려면 setspn -S도 사용할 수 있습니다. 예를 들어 webserver1이라는 컴퓨터에 HTTP SPN을 추가하려면 다음 명령을 사용합니다:

setspn -S HTTP/webserver1.abcdomain.com abcdomain\serviceaccount

중복 항목이 생성되지 않도록 setspn -S 명령은 새 SPN을 만들기 전에 기존에 동일한 SPN이 있는지 자동으로 확인합니다.

SPN을 제거하려면 setspn -D 명령을 사용하세요. 또한 SPN에 대해 PowerShell을 여러 방식으로 사용할 수도 있습니다. 예를 들어, 다음 PowerShell cmdlet은 Active Directory에 등록된 모든 SPN을 찾습니다:

Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName | Select-Object Name, servicePrincipalName

이 명령은 모든 중복 SPN을 감지합니다.

$SPNs = Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName |

Select-Object -ExpandProperty servicePrincipalName

SPN 등록을 위한 모범 사례

• SPN 등록을 위해 서비스 계정에 최소한의 필요한 권한만 부여
• 새 SPN을 등록하기 전에 PowerShell로 중복 여부를 확인하세요:
• SPN에 대해 정기적인 감사를 수행하여 불필요하거나 오래된 항목을 식별하고 제거
• SPN을 추가할 때 표준화된 SPN 명명 형식을 사용하세요

일반적인 SPN 문제 해결 방법

중복된 SPN은 인증 실패를 유발할 수 있으므로 반드시 해결해야 합니다. SPN 충돌을 의미할 수 있으니 사용자들이 간헐적인 액세스 문제를 보고하는지 주의하세요. 아래 스크린샷과 같이 setspn -x 명령을 사용하면 단일 도메인 내의 중복을 찾을 수 있습니다.

전체 포리스트를 검색하려면 setspn -F 명령을 사용하세요. 중복 SPN을 해결하려면:

1. 중복 SPN을 보유한 계정을 식별하세요.
2. 어떤 계정이 SPN을 합법적으로 보유해야 하는지 확인합니다.
3. setspn -D <SPN> <AccountName> 명령을 사용하여 잘못된 계정에서 SPN을 제거합니다8.
4. setspn -S <SPN> <AccountName> 명령을 사용하여 올바른 계정에 SPN을 추가합니다

중복 외에도 다음과 같은 SPN 오구성 사례가 흔합니다:

• 서비스에 대한 SPN 누락
• 잘못된 계정에 등록된 SPN
• 서버 이름 변경 후 오래된 SPN

(이미 다룬 동일한 도구를 여기서 다시 나열할 필요가 없습니다.)

고급 SPN 개념

다중 서비스 및 다중 호스트 환경에서 SPN의 역할

서비스 계정은 Windows Server에서 실행되는 서비스용으로 생성되는 전문 사용자 계정입니다. 이는 Internet Information Services (IIS)와 같은 중요 애플리케이션에서 도메인 계정을 분리하고 보호하는 데 도움이 됩니다. 복잡한 환경에서는 여러 서비스가 동일한 시스템에서 실행되는 경우가 많으며, 각 서비스는 올바른 인증을 위해 서로 다른 Service Principal Names (SPNs)가 필요합니다.

대표적인 예로, 웹 애플리케이션을 호스팅하는 서버에서 SQL Server와 IIS가 모두 실행될 수 있습니다. 각 서비스는 올바른 Kerberos 인증을 보장하기 위해 자체 SPN이 필요합니다:

• IIS의 경우: HTTP/servername.domain.com
• SQL Server의 경우: MSSQLSvc/servername.domain.com:1433

여러 호스트 환경에서는 서비스가 로드 밸런싱 또는 장애 조치(failover)를 위해 여러 서버에 걸쳐 실행되므로 SPN 구성이 더 복잡해집니다. 예를 들어, 공유 DNS 이름 아래에 여러 서버(Web01, Web02, Web03)에서 웹 애플리케이션이 호스팅되는 상황을 생각해 볼 수 있습니다. 이 경우 모든 호스트에서 원활한 인증이 가능하도록 SPN을 단일 서비스 계정에 등록해야 합니다:

특수한 경우: HOST SPN과 고유한 동작 방식

HOST SPN은 Active Directory에서 컴퓨터 개체에 자동으로 등록되는 SPN의 특수한 유형입니다. 이들은 해당 머신의 로컬 시스템 또는 네트워크 서비스 계정에서 실행되는 서비스에 대한 포괄(캐치올) 식별자로 동작합니다. 그 결과 많은 표준 Windows 서비스의 관리를 더 쉽게 만들고, 수동 SPN 구성의 필요성을 줄여 줍니다.

아래 표는 HOST SPN을 사용해야 하는 경우와 Custom SPN을 사용해야 하는 경우를 요약합니다:

팁: AD에서 관리하므로 HOST SPN을 수동으로 수정해서는 안 됩니다.

SPN과 보안상의 영향

AD 환경에서 SPN 보안이 중요한 이유

SPN에서 보안이 중요한 이유는 간단합니다. 서비스 계정은 종종 높은 권한을 가집니다. 또한 네트워크 내의 중요 시스템에 지속적으로 액세스할 수 있으며, 한 번 생성되면 종종 잊혀지곤 합니다. 이 모든 것이 공격자에게 이들을 고가치 목표로 만듭니다. SPN을 손상시키면 중요한 서비스에 대한 무단 액세스로 이어질 수 있고, 잠재적으로 공격자가 네트워크 내에서 수평 이동하여 권한을 상승시키는 것을 허용할 수 있습니다

취약한 SPN은 어떻게 악용될 수 있는가

SPN이 약하게 구성되어 있으면 Kerberoasting 같은 공격을 통해 악용될 수 있습니다. 공격자가 이러한 공격을 수행하는 방법은 다음과 같습니다:

• 도메인 권한이 최소인 공격자는 어떤 SPN에 대해서도 서비스 티켓을 요청할 수 있습니다. Requests service tickets for these SPNs
• 서비스 계정의 비밀번호 해시로 암호화된 서비스 티켓은 추출한 뒤 오프라인에서 암호 크래킹에 사용할 수 있습니다.
• 이 티켓을 대상으로 오프라인 비밀번호 크래킹을 수행합니다. 비밀번호가 약한 경우 공격자는 이를 크래킹하여 서비스 계정에 대한 접근 권한을 얻을 수 있으며, 종종 권한이 상승된 상태로 이어집니다.

공격자가 서비스 계정의 비밀번호를 크래킹한 뒤, 해당 계정에 높은 권한이 있다면 네트워크를 통해 옆으로(수평적으로) 이동하거나 접근 권한을 에스컬레이션할 수 있습니다.

SPN 및 서비스 계정을 보호하기 위한 모범 사례

다음은 SPN과 관련된 보안 위험을 완화하기 위한 모범 사례 목록입니다:

• SPN이 있는 계정에는 길고 복잡한 비밀번호를 사용하고 정기적으로 비밀번호를 변경하세요
• Domain Admins 같은 고권한 계정에는 SPN을 할당하지 마세요
• 서비스 계정을 해당 기능을 수행하는 데 필요한 권한으로만 제한하세요
• 서비스 계정에 대한 대화형 로그온을 비활성화하세요
• PowerShell에서 SPN 관련 명령이 예상치 못하게 사용되는지 모니터링하세요.
• 도메인 인증을 받은 모든 사용자는 SPN을 검색할 수 있으므로, Active Directory에서 권한을 변경하여 이러한 쿼리를 수행할 수 있는 대상을 제한해야 합니다.

SPN 악용 탐지 및 완화

SPN 관련 활동 모니터링 및 감사

AD 환경을 지속적으로 모니터링하고 Kerberos 관련 이벤트를 감사하면 SPN 악용을 예방하는 데 매우 효과적일 수 있습니다. 다음과 같은 항목을 탐지해야 합니다.

• 공격자가 LDAP 도구를 사용해 AD에 대해 SPN을 조회할 수 있으므로, 비정상적인 SPN 열거 요청
• 서비스 티켓 요청이 갑자기 급증하면 진행 중인 공격을 의미할 수 있으므로, 빈번한 Kerberos 티켓 요청
• 일반적으로 지정된 위치가 아닌 예상치 못한 위치에서의 서비스 계정 로그인
• 반복된 실패는 무차별 대입(brute-force) 또는 password spraying 시도를 시사하므로, 인증 실패 시도

SPN 기반 공격에 대한 완화 전략 구현

조직이 Windows Active Directory 환경에서 운영 중이라면, SPN 악용 및 Kerberoasting 공격의 위험을 최소화하기 위해 다음과 같은 예방적 보안 제어를 고려해야 합니다.

• 서비스 계정에는 길고 복잡한 비밀번호를 사용하세요(절대 최소 14자)
• 서로 다른 계정 간에 비밀번호를 재사용하지 말고, 비밀번호를 정기적으로 교체하세요
• 계정 권한을 제한하려면 최소 권한의 원칙 을 적용하세요.
• 공격 가능 기간을 최소화하기 위해 Kerberos 티켓 수명을 더 짧게 설정하세요
• 정기적으로 SPN을 검토하고 오래되었거나 불필요한 SPN을 제거하세요
• 강력한 서비스 계정 관리, 정교한 모니터링, 정기적인 교육 프로그램을 결합한 다계층 방어 전략을 채택하세요.

그룹 관리 서비스 계정과 강력한 암호화 방법 사용

자동화된 암호 관리의 이점을 얻기 위해 그룹 관리 서비스 계정(Group Managed Service Accounts, gMSAs)을 구현하세요. 그룹 관리 서비스 계정(Group Managed Service Accounts, gMSAs)은 기존 서비스 계정에 비해 향상된 보안 기능을 제공하는 Active Directory의 특수 서비스 계정입니다. 이들은 특히 SQL Server, IIS 웹 애플리케이션, 예약 작업 등과 같은 서비스를 실행하는 도메인 가입 서버에 유용하며, 특정 권한을 가진 보안 컨텍스트에서 실행되어야 하는 기타 서비스에도 적합합니다. gMSAs를 활용하면 수동 암호 할당을 제거하고 자격 증명 탈취 위험을 줄일 수 있습니다. 암호화와 관련해서는 Active Directory에서 DES와 RC4 같은 더 약한 암호화 유형을 비활성화하는 동시에 강력한 AES128/AES256 Kerberos 암호화를 적용하세요.

실무 적용 및 사용 사례

앞서 언급했듯이 SPN은 웹 애플리케이션과 데이터베이스에 대한 Kerberos 인증에 사용됩니다. IIS는 “HTTP/ServerName” 형식의 SPN을 사용하며, 이는 애플리케이션 풀을 실행하는 도메인 계정에 매핑됩니다. 반면 “MSSQLSvc/host.domain.com:1433”는 SQL 서비스 계정의 예입니다. 그러나 기업이 점점 더 하이브리드 네트워크 아키텍처를 채택함에 따라 Service Principal Names (SPNs)의 역할은 전통적인 사용 사례를 넘어 변화하고 있습니다. 오늘날에는 온프레미스 리소스와 클라우드 네이티브 애플리케이션 간의 보안 인증을 SPN이 가능하게 하는 사례도 보이고 있습니다. 그 밖의 예시는 다음과 같습니다:

• SPN은 컨테이너화된 환경에 배치된 컨테이너화 애플리케이션 및 서비스에 대한 ID와 액세스를 관리하는 데 사용되고 있습니다.
• 엣지 환경에서는 엣지 디바이스와 중앙 집중형 클라우드 리소스 간의 보안 통신을 지원하기 위해 SPN을 사용합니다.
• Azure AD Connect는 온프레미스 AD와 Azure AD 간의 동기화 서비스를 위해 SPN을 사용합니다.

오늘날 기업 환경에서도 SPN의 사용이 점점 늘어나고 있습니다. 예를 들어 보안 팀은 SPN 사용 로그를 모니터링하여 승인되지 않은 액세스 시도나 Kerberos 실패를 탐지하고 있습니다. 그 밖의 예시는 다음과 같습니다:

• 단일 로그온(Single Sign-On, SSO): SPN은 여러 애플리케이션과 서비스 전반에서 Kerberos 기반 SSO를 가능하게 합니다.
• 애플리케이션 통합: SPN은 서로 다른 엔터프라이즈 애플리케이션과 서비스 간의 보안 통신을 돕습니다.
• 위임 인증: SPN은 다중 계층 애플리케이션에서 서비스가 사용자 대신 인증하도록 해줍니다.

결론

서비스 프린시펄 이름(Service Principal Names, SPN)은 Active Directory의 탄생과 함께부터 Kerberos 인증의 핵심 기반이었습니다. 네트워크 사용자가 의존하는 여러 전통적인 서비스에서 SPN은 기본 요소로 자리해 왔으며, 수많은 백그라운드 서비스 전반에서 보안되고 원활한 운영을 보장하는 데 중요한 역할을 합니다. 조직이 계속 확장되고 진화함에 따라 SPN의 활용 범위는 클라우드 통합, IoT 같은 영역으로까지 넓어지고 있습니다. 오늘날 기업에서 보안에 대한 강조가 커지는 가운데, SPN은 새 기술과 계속 확장되는 디지털 환경에서의 보안 과제에 맞춰 진화하면서 더 큰 역할을 하게 될 가능성이 큽니다.

SPN이란 무엇인가요?

Service Principal Name(SPN)는 특정 서비스 인스턴스를 실행하는 Active Directory 계정과 연결하는 고유 식별자입니다. SPN은 전체 Active Directory 포리스트에서 고유해야 합니다.

두 계정이 동일한 SPN을 보유하고 있으면 도메인 컨트롤러가 어느 계정에 티켓을 발급해야 할지 판단할 수 없어 인증이 실패합니다. SPN을 보유한 계정이 없으면 요청이 완전히 실패하며, 클라이언트는 일반적으로 자체 위험이 있는 NTLM으로 대체합니다.

개인 사용자 계정에 등록된 SPN은 관리되는 서비스 계정이 아닌 경우 공격이 가능해집니다. 방어책은 서비스 계정 위생입니다. Group Managed Service Accounts를 사용하세요. SPN이 여전히 있는 모든 계정에 대해 길고 무작위로 생성된 비밀번호를 적용하세요. 공격을 드러내는 티켓 요청 급증을 감지하려면 이벤트 ID 4769를 모니터링하세요.

Kerberos 인증에서 SPN의 역할

이들은 또한 Kerberoasting의 공격 표면입니다. 도메인 인증 사용자는 누구나 SPN이 포함된 계정에 대해 Kerberos 서비스 티켓을 요청하고 오프라인에서 이를 해독하여 계정 비밀번호를 얻을 수 있으며, 잠금 임계값을 초과하지 않습니다.

1. 클라이언트는 액세스하려는 서비스에 대한 SPN을 생성합니다.

SQL Server, IIS, Exchange 및 맞춤형 애플리케이션이 실행되는 Active Directory 환경에서는 각 서비스가 매 요청마다 사용자에게 자격 증명을 묻거나 구성 파일에 비밀번호를 포함하지 않고 인증할 수 있어야 합니다. Service Principal Names가 이를 가능하게 합니다.

클라이언트가 서비스 접근을 요청하면 Kerberos 인증 흐름은 정의된 순서를 따릅니다:

SPN은 컴퓨터 객체와 서비스 계정에 다중 값 속성인 servicePrincipalNameExpand으로 존재합니다. 이 속성의 각 항목은 하나의 등록된 서비스를 나타냅니다. 여러 서비스를 실행하는 계정이나 여러 호스트 이름을 통해 접근 가능한 서비스는 여러 SPN 항목을 가집니다.

1. 클라이언트가 해당 SPN을 사용하여 도메인 컨트롤러에 서비스 티켓을 요청합니다.
2. 클라이언트는 인증을 위해 서비스에 티켓을 제시하며, 네트워크를 통해 비밀번호가 전송되지 않습니다.
3. 도메인 컨트롤러가 Active Directory에서 SPN을 조회합니다.
4. 찾으면 도메인 컨트롤러가 서비스 계정의 자격 증명으로 암호화된 서비스 티켓을 발급합니다.

SPN 구조 및 구성 요소

이 순서가 SPN 정확도가 중요한 이유입니다. SPN이 없거나 중복되었거나 잘못 구성되면 3단계에서 조회가 중단되어 인증이 실패하거나 NTLM으로 대체됩니다.

SPN의 구성 요소

SPN은 단일 값이 아니라 여러 구성 요소로 이루어진 구조화된 문자열입니다. 올바른 등록, 문제 해결 및 보안 검토를 위해 이 구조를 이해하는 것이 중요합니다.

각 SPN은 서비스, 실행 중인 호스트, 선택적으로 사용하는 포트를 식별하는 정의된 형식을 따릅니다. 구성 요소는 다음과 같습니다:

Active Directory의 일반적인 SPN 형식

• 계정: 서비스와 연결된 Active Directory 계정입니다. 이는 SPN 문자열 자체의 일부가 아니며 SPN이 등록된 개체입니다.
• 포트 (선택 사항): 서비스가 비표준 포트에서 실행될 때 포함됩니다(예: MSSQLSvc/host.domain.com:1433Expand).
• 서비스 클래스: 서비스 유형 이름, 예: MSSQLSvcExpand는 Microsoft SQL Server용이며 HTTPExpand는 웹 서비스용입니다.
• 호스트 이름: 서비스가 실행 중인 서버 또는 호스트로, NetBIOS 이름(예: FileServerExpand) 또는 완전한 도메인 이름(예: fileserver.company.comExpand)으로 표현됩니다.

형식 ServiceClass/Hostname: PortExpand 은 서비스 유형 전반에 걸쳐 예측 가능하고 인식 가능한 문자열을 생성합니다. 일반적인 예는 다음과 같습니다:

• 웹 서비스: HTTP/webserver.netwrix.comExpand
• SQL Server: MSSQLSvc/myhost.redmond.microsoft.com:1433Expand
• 파일 공유: CIFS/fileserver.contoso.comExpand
• 원격 데스크톱 서비스: TERMSRV/rdserver.abcdomain.comExpand

Active Directory가 SPN을 저장하고 해결하는 방법

• LDAP 인증: LDAP/domaincontroller.fabrikam.comExpand

servicePrincipalName 속성

SPN은 사용자 계정, 서비스 계정 또는 컴퓨터 객체와 같은 AD 객체와 연결된 속성입니다. 이는 어떤 서비스가 어떤 계정에서 실행되는지 표시하는 라벨 역할을 합니다. 이 연결을 통해 컴퓨터는 네트워크를 통해 비밀번호를 전송하지 않고도 Kerberos를 사용하여 안전하게 인증할 수 있습니다.

서비스를 설치하거나 구성하면 Kerberos가 인증 요청을 올바른 계정과 매핑할 수 있도록 SPN이 등록됩니다. 제대로 구성된 SPN이 없으면 Kerberos 인증이 실패하여 인증 오류 및 서비스 중단이 발생할 수 있습니다.

클라이언트가 서비스에 대한 액세스를 요청하면 해당 서비스에 대한 SPN을 생성하여 도메인 컨트롤러에 제출하고, DC는 디렉터리에서 해당 SPN을 조회합니다. 찾으면 Kerberos 서비스 티켓을 발급합니다. 네트워크를 통해 비밀번호는 전송되지 않습니다.

SPN 고유성이 올바른 서비스 해결을 가능하게 하는 방법

setspn –L hostname 명령을 사용하여 AD 객체의 SPN을 볼 수 있습니다. 아래 예에서는 도메인 컨트롤러가 ABCDomain.com이라는 도메인에 대해 생성한 SPN 목록을 보기 위해 이 명령을 사용했습니다.

SPN은 객체의 servicePrincipalName 속성의 일부로 Active Directory에 저장됩니다. 이 속성은 컴퓨터 계정과 서비스 계정에 존재하며 해당 객체에 등록된 모든 SPN 목록을 포함합니다. Active Directory Users and Computers의 객체 속성 탭에서 확인할 수 있습니다. 아래 스크린샷을 참조하세요.

HOST SPNs 및 AD가 자동으로 관리할 때

아래 표는 HOST SPNs와 사용자 지정 SPNs를 사용할 때를 요약한 것입니다:

HOST SPN은 Active Directory가 컴퓨터 객체에 자동으로 등록하는 특별한 SPN 범주입니다. 이는 로컬 시스템 또는 네트워크 서비스 계정에서 실행되는 서비스에 대한 범용 식별자로 작용하며, 수동 SPN 항목 없이도 많은 표준 Windows 서비스를 포함합니다.

인증 문제를 해결할 때 중복 SPN은 가장 먼저 확인해야 할 항목 중 하나입니다. setspn -XExpand를 사용하여 도메인 내 중복을 감지하고, setspn -FExpand를 사용하여 전체 포리스트를 검색하세요.

각 SPN은 전체 Active Directory 포리스트에서 고유해야 합니다. 이 고유성은 Kerberos authentication이 서비스 요청을 올바른 계정으로 라우팅할 수 있게 합니다. 두 계정이 동일한 SPN을 보유하면 도메인 컨트롤러가 어느 것을 사용할지 결정할 수 없어 인증 실패, 간헐적 로그인 오류 및 서비스 연결 장애가 발생합니다.

HOST SPN을 수동으로 수정하지 마십시오. Active Directory가 자동으로 관리하며 변경 시 핵심 서비스에 지장이 있을 수 있습니다.

SPN 구성 및 관리 방법

1단계: 서비스 및 대상 계정 식별

2단계: 기존 또는 중복 SPN 확인

올바른 SPN 구성은 Kerberos 인증이 작동하기 위한 전제 조건입니다. 이 프로세스는 서비스 유형에 관계없이 일관된 순서를 따르며, 단계를 건너뛰는 것이 SPN 관련 문제의 가장 흔한 원인입니다.

등록하기 전에 SPN이 다른 계정에 이미 존재하지 않는지 확인하세요. 디렉터리를 조회하려면 다음 명령어를 사용하세요:

중복된 SPN을 등록하면 인증 실패가 발생할 수 있으며 사후 진단이 어려울 수 있습니다.

3단계: setspn으로 SPN 등록

SPN을 등록하기 전에 두 가지를 확인하세요: 필요한 서비스 클래스와 형식, 그리고 서비스를 실행할 Active Directory 계정입니다. 표준 서비스(SQL Server, IIS, Exchange)의 경우 서비스 클래스가 잘 문서화되어 있습니다. 계정은 전용 Active Directory service account 또는 가능하면 공유나 개인 계정 대신 Group Managed Service Account (gMSA)를 사용하는 것이 좋습니다.

비표준 포트에서 실행 중인 SQL Server의 경우:

다음 명령어를 사용하세요 setspn -SExpand (안전 추가) SPN을 등록하려면. -S 플래그는 항목을 생성하기 전에 중복을 자동으로 확인하여 이전 -A 플래그보다 안전합니다:

4단계: 등록 확인

PowerShell에서 Set-ADUser 또는 Set-ADComputer cmdlet을 사용하여 SPN을 등록할 수도 있으며, 이는 스크립트 배포나 대량 등록에 유용합니다.

PowerShell을 사용하여 확인할 수도 있습니다:

등록 후 SPN이 올바른 계정에 표시되는지 확인하세요:

출력에는 새로 등록된 SPN과 해당 계정에 이미 할당된 다른 SPN들이 함께 나열되어야 합니다.

5단계: Kerberos 인증 테스트

일반적인 SPN 잘못된 구성 수정

대부분의 SPN 문제는 소수의 범주에 속합니다. 각각은 대상이 명확한 해결책이 필요합니다:

Windows 이벤트 뷰어에서 성공적인 Kerberos 서비스 티켓 요청은 이벤트 ID 4769로 표시됩니다. 인증이 NTLM으로 대체되는 경우 SPN이 누락되었거나 잘못되었거나 잘못된 계정에 등록되었을 가능성이 높습니다.

SPN이 등록되면 Kerberos 인증이 성공하는지 테스트하세요. 도메인 자격 증명을 사용하여 서비스에 연결한 후 klistExpand를 실행하여 DC가 Kerberos 서비스 티켓(NTLM 티켓 아님)을 발급했는지 확인하세요.

SPN 등록 모범 사례

• 중복된 SPN: 다음을 사용하세요 setspn -DExpand 잘못된 계정에서 SPN을 제거한 후 올바른 계정에 남아 있는지 확인하세요. 서버 이름 변경 또는 계정 마이그레이션 후에 중복이 자주 발생합니다.
• 서버 이름 변경 후 오래된 SPN: 이전 호스트 이름을 참조하는 오래된 SPN은 제거하고 현재 이름으로 새로 등록해야 합니다.
• 누락된 SPN: Kerberos가 실패하고 NTLM으로 대체될 경우, setspn -QExpand 명령어로 SPN이 존재하는지 확인하세요. 없으면 등록하세요.
• 잘못된 계정에 등록된 SPN: 다음 명령어로 제거하세요 setspn -DExpand 그리고 올바른 서비스 계정에 다시 등록하세요.

SPN 관리를 위한 일관된 관행을 확립하면 운영 실패와 보안 위험을 모두 줄일 수 있습니다:

• 부적절한 계정에 등록된 SPN을 식별하기 위해 정기적인 PowerShell 감사를 실행하세요.
• SPN은 개인 사용자 계정이나 Domain Admin 계정이 아닌 전용 서비스 계정에 할당하세요.
• 등록 시 실수로 중복되는 것을 방지하려면 setspn -SExpand (–A가 아닌)를 사용하세요.
• 감사를 간소화하기 위해 환경 전반에 표준화된 명명 형식을 사용하세요.

잘못 구성된 SPN의 보안 위험

Kerberoasting

• 계정에 최소 권한만 부여하세요. SPN 등록에는 servicePrincipalNameExpand 속성에 대한 쓰기 권한이 필요하며, 이는 광범위하게 부여되어서는 안 됩니다.

SPN과 연결된 서비스 계정은 Active Directory에서 가장 많이 표적이 되는 ID 중 하나입니다. 일반 사용자 계정과 달리, 이들은 종종 높은 권한을 가지며, 중요한 시스템에 지속적으로 접근할 수 있고, 생성 후 거의 검토되지 않습니다. 이러한 조합은 잘못 구성된 SPN과 관련된 보안 위험을 만듭니다.

실버 티켓 공격

공격자는 티켓을 요청하고 추출하여 오프라인 비밀번호 크래킹을 수행할 수 있으며, 잠금이 발생하거나 네트워크에 큰 소음을 발생시키지 않습니다.

Kerberoasting는 가장 널리 사용되는 SPN 기반 공격 기법입니다. 도메인 인증을 받은 모든 사용자, 낮은 권한 계정을 포함하여, 디렉터리 내의 모든 SPN에 대해 Kerberos 서비스 티켓을 요청할 수 있습니다. 해당 티켓은 서비스 계정의 비밀번호 해시로 암호화됩니다.

RC4 암호화는 RC4로 암호화된 Kerberos 티켓이 최신 AES 보호 티켓보다 더 쉽게 해독되기 때문에 이 공격을 훨씬 빠르게 만듭니다. 이 때문에 Microsoft는 AD 환경에서 RC4를 적극적으로 폐기하고 있습니다.

서비스 계정이 약하거나 재사용된 비밀번호를 사용하는 경우, 공격자는 평문 자격 증명을 복구하여 종종 권한이 상승된 상태로 서비스에 접근할 수 있습니다.

손상된 서비스 계정을 통한 측면 이동

SPN 기반 공격에 대응하는 방법

고권한 SPN을 통한 권한 상승

과도한 권한이 부여된 계정, 특히 Domain Admin 권한이나 중요한 시스템에 대한 무제한 접근 권한이 있는 계정에 등록된 SPN은 가장 위험한 구성입니다. 이러한 계정 중 하나에 대한 성공적인 Kerberoasting 공격은 단순히 서비스를 손상시키는 것이 아니라 공격자에게 도메인 수준의 제어 권한을 부여할 수 있습니다.

Kerberoasting 및 SPN 열거 탐지

Kerberoasting의 자연스러운 후속 조치는 silver ticket 공격. 공격자가 서비스 계정의 비밀번호 해시를 해독하면 도메인 컨트롤러와 추가 상호작용 없이 완전히 오프라인 상태에서 Kerberos 서비스 티켓을 위조할 수 있습니다. 이 silver ticket는 대상 서비스에 지속적인 접근 권한을 부여하며, DC를 완전히 우회하기 때문에 탐지가 매우 어렵습니다.

서비스 계정은 일반적으로 여러 시스템에 대한 액세스 권한을 보유합니다. 공격자가 하나를 침해하면 측면 이동이 환경 전반에 걸쳐 가능해집니다. 서비스 계정은 표준 모니터링 및 이상 탐지 규칙에서 종종 제외되기 때문에 이 이동은 장기간 감지되지 않을 수 있습니다.

AD 환경의 지속적인 모니터링은 첫 번째 방어선입니다. 주의해야 할 지표는 다음과 같습니다:

SPN 기반 공격에 대한 방어는 세 가지 영역에서 작동합니다: 조기 남용 감지, 발생 시 효과적인 대응, 그리고 사고 발생 전에 공격 표면을 줄이기 위한 환경 강화.

• 비정상적인 SPN 열거 쿼리입니다. 공격자는 일반적으로 정찰 중에 도메인의 모든 SPN을 나열하기 위해 LDAP 도구를 사용합니다.
• 예상치 못한 호스트나 비정상적인 시간에 발생한 서비스 계정 로그인.

Active Directory에서 권한을 수정하여 SPN을 조회할 수 있는 대상을 제한하면 권한이 낮은 공격자가 사용할 수 있는 정찰 시간이 줄어듭니다.

SPN 남용 차단 및 대응

• 이벤트 ID 4769(케르베로스 서비스 티켓 요청)의 급격한 증가, 특히 RC4 암호화(암호화 유형 0x17)를 사용하는 경우는 공격자가 더 빠른 크래킹을 위해 RC4 티켓을 선호하므로 Kerberoasting을 강력히 나타냅니다.
• 반복된 인증 실패 시도는 무차별 대입 공격 또는 password-spraying 공격 으로 인해 자격 증명이 탈취되었음을 나타낼 수 있습니다.

SPN 기반 남용이 감지되면 공격자가 손상된 자격 증명을 사용하는 능력을 제한하는 것이 우선입니다:

• 영향을 받은 서비스 계정 비밀번호를 길고 무작위로 생성된 자격 증명으로 즉시 재설정하세요.
• 계정이 기능에 필요한 것보다 더 많은 권한을 가지고 있는지 검토하고 권한을 줄이세요.
• 서비스 계정이 접근할 수 있는 모든 시스템을 검토하고 최근 활동을 감사하여 횡적 이동 징후를 확인하세요.

SPN 활성화 서비스 계정 강화

사전 강화는 SPN 기반 공격을 가능하게 하는 많은 조건을 제거합니다:

• 서비스 계정에는 길고 무작위로 생성된 비밀번호(최소 25자)를 사용하고, 정해진 일정에 따라 교체하세요.
• 서비스 계정의 Kerberos 암호화 키를 재설정하여 계정에 발급된 활성 Kerberos 티켓을 모두 취소하세요(krbtgt 재설정은 silver ticket 완화에 필요하지 않으며, 서비스 계정 암호 재설정으로 위조된 티켓이 무효화됩니다).
• 서비스 계정에 대한 대화형 로그인을 비활성화하여 계정이 손상될 경우 유용성을 제한하세요.
• 최소 권한 원칙을 적용하세요. 최소 권한 원칙. 서비스 계정은 자신의 기능에 필요한 시스템과 데이터에만 접근해야 합니다.

gMSA 및 AES 암호화를 사용하여 지속적인 위험 제거

• 가능한 경우 Group Managed Service Accounts로 마이그레이션하세요. 이들은 비밀번호 관리를 자동화하고 Kerberoasting을 훨씬 어렵게 만듭니다.

Group Managed Service Accounts (gMSA)는 수동 암호 관리를 완전히 없애는 특수 서비스 계정입니다. Active Directory는 gMSA 암호를 자동으로 관리하며, 서비스 및 도메인 관리자가 직접 보거나 다루지 않는 길고 무작위로 생성된 자격 증명을 정의된 일정에 따라 주기적으로 변경합니다.

하이브리드 및 최신 환경의 SPN

기본적으로 Windows는 gMSA 비밀번호를 30일마다 변경하며, 이 간격은 msDS‑ManagedPasswordInterval 속성(또는 gMSA 생성 시 ManagedPasswordIntervalInDays 매개변수)으로 제어되며, 생성 시에만 설정할 수 있습니다.

gMSA를 지원하지 않는 서비스의 경우 AES-128 또는 AES-256 Kerberos 암호화를 적용하고 Active Directory에서 더 약한 RC4 및 DES 암호화 유형을 명시적으로 비활성화하세요. RC4 암호화는 Kerberoasting 공격에서 기본으로 사용되며, 이를 제거하면 요청이 AES를 사용하도록 강제되어 오프라인 크래킹에 훨씬 더 강력합니다.

• Domain Admin 또는 기타 고권한 그룹 멤버십이 있는 계정에 SPN을 절대 할당하지 마십시오.

SPN 및 Microsoft Entra Connect

조직이 하이브리드 아키텍처와 컨테이너화된 워크로드를 채택함에 따라 SPN의 역할은 기존 온프레미스 Active Directory를 넘어 확장되었습니다. SPN은 Kerberos 인증이 사용되는 모든 곳에서 여전히 중요하며, 일부 새로운 환경에서는 원래 AD 설계에 없던 인증 패턴을 가능하게 합니다.

컨테이너화된 환경의 SPN

다계층 애플리케이션에서 위임된 인증

Microsoft Entra Connect는 온프레미스 Active Directory와 Entra ID(이전 Azure AD) 간의 동기화 서비스에 SPN을 사용합니다. 동기화 서비스 계정은 두 디렉터리에 인증하기 위해 올바르게 구성된 SPN이 필요합니다. 잘못 구성되었거나 누락된 SPN은 디렉터리 동기화를 조용히 중단시켜 하이브리드 환경 전반에 걸쳐 ID 데이터가 오래되게 만들 수 있습니다.

Kerberos 위임는 서비스가 사용자를 대신해 하위 리소스에 인증할 수 있도록 합니다. 이는 웹 프런트엔드가 사용자의 신원을 백엔드 데이터베이스에 전달해야 하는 다계층 애플리케이션에서 일반적입니다.

Windows Server에서 실행되는 컨테이너화된 작업 부하는 gMSA 및 확장하여 SPN을 Active Directory security에 사용할 수 있습니다. 도메인에 가입된 호스트에서 Kubernetes 및 Docker 배포는 gMSA 자격 증명을 요청하도록 구성할 수 있어, 컨테이너화된 서비스가 컨테이너 이미지에 자격 증명을 포함하지 않고 Kerberos를 사용해 AD 통합 리소스에 인증할 수 있습니다.

SPN은 이 과정에서 핵심입니다: 위임은 SPN을 보유한 서비스 계정에 구성되며, 인증 체인의 각 단계는 올바르게 등록된 SPN에 의존합니다.

SPN은 기본적이며 점점 더 표적이 되고 있습니다

서비스가 모든 사용자로 가장하여 모든 리소스에 접근할 수 있는 무제한 위임은 심각한 공격 표면을 나타내며 가능한 경우 제한된 위임 또는 리소스 기반 제한 위임으로 대체해야 합니다.

Service Principal Names는 Active Directory가 시작된 이래 Kerberos 인증의 핵심 요소였습니다. 올바르게 구성되고 정기적으로 감사되며 엄격하게 관리될 때만 기업 환경 전반에서 안전한 비밀번호 없는 서비스 인증을 가능하게 합니다.

Netwrix는 두 가지 최우선 SPN 보안 과제인 진행 중인 공격 감지와 위험을 초래하는 AD 변경 사항에 대한 가시성 유지에 특화된 도구를 제공합니다.

Netwrix가 도울 수 있는 방법

조직이 하이브리드 인프라, 컨테이너 및 클라우드 통합 Identity 시스템으로 확장됨에 따라 SPN이 더 많은 위치에 나타나고 이전보다 더 광범위한 액세스 권한이 있는 계정에 연결되고 있습니다.

위협 계산이 그에 따라 변화했습니다. Kerberoasting은 SPN이 널리 퍼져 있고 모니터링이 부족하기 때문에 기업 침해에서 가장 일반적으로 관찰되는 측면 이동 기법 중 하나가 되었습니다. 이전에 인증 실패를 일으켰던 잘못된 구성은 이제 공격 표면의 일부가 되었습니다.

SPN의 구조, AD가 이를 해결하는 방법, 공격자가 취약한 구성을 악용하는 방식을 이해하는 것이 이를 보호하는 첫걸음입니다. 이 글에서 다룬 운영 단계는 기초를 제공합니다. 이를 바탕으로 지속적인 모니터링, 정기적인 SPN 감사, 가능하다면 gMSA로의 이전이 조직이 위협에 앞서 나가는 데 도움이 됩니다.

Netwrix Threat Manager는 온프레미스 Active Directory 및 Entra ID 전반에서 Kerberoasting, SPN 열거 쿼리 및 의심스러운 서비스 티켓 요청을 포함한 ID 기반 공격을 탐지합니다.

계정 수준의 이상 활동과 상관관계가 있습니다. 권한이 낮은 사용자가 갑자기 50개의 서비스 티켓을 요청하면 보안 팀은 이를 개별 로그 항목이 아닌 단일 통합 경고로 인식합니다.

데모 요청하여 Netwrix가 SPN 남용을 감지하고 AD 변경 사항을 실시간으로 감사하며 공격자가 악용하기 전에 공격 표면을 줄이는 데 어떻게 도움이 되는지 확인하세요.

Netwrix Auditor는 AD 환경 전반의 servicePrincipalName 속성에 대한 모든 변경 사항을 이전 및 이후 값과 각 변경에 책임이 있는 계정과 함께 추적합니다. 높은 권한 계정에 SPN이 등록되거나 서비스 계정에서 예기치 않게 제거되면 Auditor가 즉시 해당 변경 사항을 표시합니다.