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은 새 기술과 계속 확장되는 디지털 환경에서의 보안 과제에 맞춰 진화하면서 더 큰 역할을 하게 될 가능성이 큽니다.