그룹 관리 서비스 계정 보안

그룹 관리 서비스 계정 개요

일반 사용자 계정을 서비스 계정으로 사용하는 기존 방식은 비밀번호 관리 책임을 사용자에게 전가합니다. 그 결과 계정 비밀번호가 수년 동안 그대로 유지되는 경우가 많아지며, 이는 무차별 대입 공격(brute force)과 오용에 매우 취약하게 만듭니다. 그룹 관리 서비스 계정(gMSAs)은 자동 작업, 서비스 및 애플리케이션을 실행하는 더 안전한 방법을 제공합니다.

gMSA는 Windows Server 2016에 도입되었으며, Windows Server 2012 이상에서 활용할 수 있습니다. gMSA 비밀번호는 Windows에서 완전히 처리합니다. 비밀번호는 무작위로 생성되고 자동으로 주기적으로 교체됩니다. 또한 서비스 계정 자체가 런타임에 비밀번호 정보를 조회할 서버에 ‘설치’되기 때문에, 어떤 사용자도 비밀번호를 알 필요가 없습니다. Active Directory 그 결과, gMSA는 서비스 계정으로 사용되는 사용자 계정보다 오용 및 유출(침해) 가능성에 훨씬 덜 취약합니다.

그룹 관리 서비스 계정 보안

gMSA는 Active Directory의 특정 개체 유형입니다. 즉 msDS-GroupManagedServiceAccount 입니다. 이 개체들은 비밀번호와 비밀번호의 주기적 교체(로테이션)와 관련된 특별한 특성(속성)을 가집니다. LAPS 와 마찬가지로, gMSA 특성이 이를 액세스해야 하는 Active Directory 개체에만 제한되도록 잠가 두는 것이 중요합니다.

gMSA 특성 및 권한

gMSA에는 다음과 같은 특성이 있습니다.

• msDS-ManagedPassword— gMSA의 비밀번호를 포함하는 BLOB
• msDS-ManagedPasswordID— 현재 gMSA 비밀번호를 생성하는 데 사용되는 키 ID
• msDS-ManagedPasswordPreviousID— 이전 gMSA 비밀번호를 생성하는 데 사용된 키 ID
• msDS-GroupMSAMembership— gMSA의 비밀번호를 조회할 권한이 있는 개체 목록
• msDS-ManagedPasswordInterval— 비밀번호를 순환(교체)하는 주기(일)

암호 정보는 msDS-ManagedPassword 특성에 저장되므로, 환경에서 누가 암호를 조회할 수 있는지 반드시 확인해야 합니다. 이 정보는 msDS-GroupMSAMembership 특성에 설정됩니다.

다만 Active Directory 권한이 함께 적용되므로, 이 특성만으로는 조금 더 복잡합니다. 어떤 이유로든 사용자 또는 개체가 msDS-GroupMSAMembership 계정을 통해 암호를 조회할 수 있는 권한이 구성되어 있다면, gMSA의 msDS-ManagedPassword 특성에 대해 ‘Read’ 권한도 여전히 필요합니다.

즉, gMSA 암호를 보호하는 방법에는 두 가지 경로가 있습니다.

• 암호를 조회할 수 있는 권한을 필요한 개체만 갖도록 하고, 해당 개체가 msDS-GroupMSAMembership에 존재하는지 확인하세요.
• 접근이 필요한 관리 사용자와 gMSA가 설치된 컴퓨터 계정만 해당 특성을 읽을 수 있는 권한을 갖도록 하세요. 또한, gMSA 및 해당 특성을 수정할 수 있는 권한은 관리자에게만 있어야 하므로, 누구도 msDS-GroupMSAMembership 특성에 자신을 추가할 수 없게 하세요.

이상적으로는 공격자가 위의 두 시나리오 중 어느 하나를 악용할 수 있는 선택지를 갖지 못하도록, gMSA를 두 경로 모두를 통해 잠가 두는 것이 좋습니다. 아래에서는 gMSA에 대한 권한 또는 구성이 제대로 관리되지 않을 경우, 해당 계정이 손상되고 권한 상승 또는 측면 이동으로 이어질 수 있는 과정을 살펴보겠습니다.

gMSA 비밀번호 악용

gMSA를 악용하는 것은 개념적으로 비교적 간단합니다. 먼저 Mimikatz 같은 도구를 사용해 비밀번호를 얻거나, Active Directory의 보안이 취약한 구성 때문에 이를 직접 조회할 수 있습니다. gMSA는 서비스 계정이므로 대개 비교적 권한이 크기 때문에, 그 다음에는 보통 측면 이동을 하거나 권한을 상승시킬 수 있습니다.

예시 시나리오를 살펴보겠습니다.

1. 먼저 피싱 같은 기법을 통해 일반 Windows 사용자 계정 ‘notadmin’을 침해합니다. 이 계정은 Active Directory에서 권한이 거의 없지만, 우리가 침투한 컴퓨터에서는 로컬 관리자입니다.

2. 다음으로, gMSA가 존재하는지 확인해 보겠습니다. Windows PowerShell cmdlet에 액세스할 수 있다면 이는 매우 간단합니다. 간단한 스크립트를 실행하면 Active Directory에 있는 모든 관리되는 서비스 계정을 얻을 수 있습니다:

      Get-ADServiceAccount -Filter *
      

3. 스크립트를 약간 수정하면 gMSA 암호를 조회할 수 있는 사람이 누구인지 식별할 수 있습니다:

      Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword
      

보시는 것처럼, Kevin Joyce 계정만이 이러한 서비스 계정의 암호를 조회할 수 있습니다:

4. 이러한 서비스 계정이 어떤 특권 그룹의 구성원인지 확인함으로써, 우리가 원하는 대상의 범위를 좁힐 수 있습니다. 그리고 거기서부터 개체 중 하나에 설정된 권한을 더 깊이 파고들 수 있습니다:

      Get-ADServiceAccount -Filter * -Properties memberof
      

여기 결과를 보면 gMSA 서비스 계정이 Domain Admins의 구성원인 것을 확인할 수 있습니다. 따라서 이 계정을 대상으로 악용을 시도할 것입니다.

5. Microsoft LAPS에 관한 게시물에 제공된 스크립트를 수정하여, 특정 gMSA 속성에 대해 Full Control, Write All Properties 또는 Write Property 권한이 있는 관리되는 서비스 계정에 대한 모든 개체의 목록을 얻을 수 있었습니다. 아래에 출력 결과가 있으며, 스크립트는 하단에 연결되어 있습니다.

6. 보시다시피 notadmin 계정에는 gMSA 계정에 대한 Full Control 권한이 있습니다. 이를 통해 msDS-GroupMSAMembership 속성을 수정할 수 있으며, 그러면 관리되는 서비스 계정의 비밀번호를 검색할 수 있습니다:

      Set-ADServiceAccount -Identity gmsa -PrincipalsAllowedToRetrieveManagedPassword notadmin
      

7. 이제 실제로 비밀번호를 조회할 수 있으니, 이를 가지고 무엇을 할 수 있는지 살펴보겠습니다:

      Get-ADServiceAccount -Identity gmsa -properties msds-ManagedPassword
      

      $pwd = Get-ADServiceAccount -identity gMSA -Properties msds-ManagedPassword
      

8. 해당 속성에 저장된 값은 비밀번호 자체가 아니라 비밀번호의 데이터를 포함하는 BLOB입니다. 따라서 DSInternals 같은 도구를 사용해 비밀번호를 디코딩해야 합니다:

      $pw = ConvertFrom-ADManagedPasswordBlob $pwd.’msds-managedpassword’
ConvertTo-NTHash $pw.securecurrentpassword
      

이렇게 하면 SecureCurrentPassword와 CurrentPassword를 얻을 수 있습니다. CurrentPassword는 유용해 보이지 않는데, 그 이유는 모든 문자가 UTF-16이기 때문입니다. SecureCurrentPassword는 NTLM 해시로 변환할 수 있으며, 이를 패스 더 해시(pass the hash) 공격에 사용해 mimikatz로 권한을 상승시킬 수 있습니다.

9. 패스 더 해시(pass the hash)를 하려면, mimikatz를 실행하고 다음 명령어를 사용하기만 하면 됩니다:

      sekurlsa::pth /user:gmsa /domain:sbpmlab.net /ntlm:a99afa608b79a3c539a969212c505ea9
      

10. 이제 Domain Admins의 구성원이었던 gMSA 서비스 계정으로 실행되는 셸을 확보했으므로, Active Directory를 손상시키기 위해 원하는 대로 무엇이든 할 수 있습니다. 가장 빠른 방법 중 하나이면서도 아마 가장 눈에 띄는(조금은 시끄러운) 방법은 DCSync 공격을 실행하고 krbtgt 계정의 해시를 훔치는 것입니다:

      lsadump::dcsync /user:krbtgt /domain:sbpmlab.net
      

gMSA 보호 및 모니터링

gMSA 악용을 방지하고 탐지하기 위해 사용할 수 있는 전략이 있습니다.

권한

가장 명백하고(논쟁의 여지가 있지만) 가장 중요한 보호 방법은 그룹 관리 서비스 계정에 적절한 권한이 설정되도록 하는 것입니다. 이러한 개체에 누가 쓰기 권한을 가지고 있는지 이해하는 것은 이를 보호하는 데 중요합니다. 이론적으로 암호를 조회할 수 있는 사람을 제어하는 속성에 자신을 추가할 수 있는 사람은 이미 해당 계정을 장악하고 그 권한을 남용할 수 있는 접근 권한을 갖고 있는 셈입니다.

다음으로, 이러한 계정에서 암호를 조회할 수 있는 권한을 가진 사람이 누구인지, 그리고 정확히 누가 그러한 접근이 필요한지 파악해야 합니다. 실제로 gMSA의 암호를 가져올 수 있어야 하는 유일한 계정은 gMSA가 설치된 컴퓨터 계정입니다.

이벤트 로그

기본 이벤트 로그에서 확인할 수 있는 이벤트가 하나 있으며, 이를 통해 gMSA 계정의 암호를 누가 조회하고 있는지 식별하는 데 도움이 됩니다. 도메인에 대해 ‘Audit directory service access’ 정책을 활성화하고 모니터링하려는 gMSA에 SACL을 구성하면, 사용자가 msDS-ManagedPassword 속성을 조회할 때 이벤트 로그가 생성됩니다:

이 설정을 켜고 새 SACL을 생성하면 이벤트 ID 4662가 포함된 이벤트 로그가 생성됩니다. 예시는 다음과 같습니다:

보시다시피 이 로그에는 ‘notadmin’ 계정이 gMSA 계정의 속성을 읽었다고 기록되어 있습니다. 읽힌 속성은 Active Directory용 스키마에 저장된 GUID이지만, ADSI 편집을 사용하면 강조 표시된 GUID이 msDS-ManagedPasssword 특성에 해당함을 확인할 수 있습니다.

어떤 형태로든 이벤트 로그 포워딩을 하거나 SIEM 솔루션을 사용하고 있다면, 이 로그는 누가 이러한 속성에 액세스하고 있는지 파악하는 데 매우 유용할 것입니다.

Netwrix StealthDEFEND

또 다른 방법은 Netwrix StealthDEFEND 같은 도구입니다. Netwrix StealthDEFEND 는 기본(네이티브) 이벤트 로그에 의존하지 않으며, gMSA 암호 액세스 및 고위험 권한 할당을 바로 즉시 탐지할 수 있습니다. 예를 들어 위에 표시된 시나리오는 ‘notadmin’ 계정이 암호를 조회했을 때 다음과 같은 위협을 생성합니다:

또한 Netwrix StealthDEFEND를 사용하면 gMSA 오용이 감지될 때 실행할 플레이북을 손쉽게 만들 수 있습니다. 플레이북에는 가해자 사용자 계정이 MFA 요청에 응답하도록 요구하는 것, 계정을 비활성화하는 것, 또는 ServiceNow 인시던트를 생성하는 것과 같은 여러 단계가 포함될 수 있습니다.

부록

gMSA 권한 코드:

      <#
Author: Kevin Joyce
Requirements: Active Directory PowerShell module, Domain Administrator privileges (to ensure the capability to get attribute GUIDs and view all permissions on all gMSA objects)
Description: Looks up permissions within Active Directory on a gMSA to determine access to modify the gMSA attribute (ms-ds-GroupMSAMembership).
Usage: populate the $target variable with the samaccountname of a gMSA.
To output the results to a text file run the following .gMSA_Permissions_Collection.ps1 > output.txt
#>
Import-Module ActiveDirectory
##Get the GUID of the extended attribute ms-ds-GroupMSAMembership from Schema
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-ds-GroupMSAMembership)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}

<# **REPLACE DN VARIABLE BELOW**
Declare the samaccountname of the gMSA to search for#>
$target = 'gmsa'

##Get distinguished name of all gMSAs objects from the OU
$gMSAs = Get-ADServiceAccount -identity $target


<#Get objects that have specific permissions on the target(s): 
Full Control(GenericAll) 
Write all Properties (WriteProperty where ObjectType = 00000000-0000-0000-0000-000000000000 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object { (($_.AccessControlType -eq 'Allow') -and ($_.activedirectoryrights -in ('GenericAll') -and $_.inheritancetype -in ('All', 'None')) -or (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -eq '00000000-0000-0000-0000-000000000000')))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -autosize 
}
<#Get objects that have specific permissions on the target(s) and specifically the gMSA attribute:
WriteProperty 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object {(($_.AccessControlType -eq 'Allow') -and (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -in $schemaIDGUID.Keys)))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -AutoSize
}
      

원문 보기gMSA_Permissions_Collection.ps1 에 의해 호스팅됨 GitHub

자주 묻는 질문

gMSA란 무엇인가요?

관리형 서비스 계정(Managed Service Accounts, MSA)과 유사하게, 그룹 관리형 서비스 계정(Group Managed Service Accounts, gMSAs)은 서비스를 보호하고 액세스 관리를 지원하는 데 사용되는 관리 도메인 계정입니다. gMSA 기능은 도메인 컨트롤러(DC)가 자동으로 비밀번호를 관리하고, 서비스 주체 이름(Service Principal Name, SPN) 관리를 간소화하며, 관리를 다른 관리자에게 위임할 수 있도록 해 Active Directory 보안을 개선하는 동시에, 높은 권한(특권) 액세스를 가진 계정을 최소화합니다.

MSA와 gMSA의 차이점은 무엇인가요?

MSA와 달리, gMSA는 여러 컴퓨터에 연결할 수 있습니다.

그룹 관리 서비스 계정(gMSA)을 찾는 방법은 무엇인가요?

도메인 컨트롤러에서 gMSA 목록을 보려면 서버 관리자(Server Manager) > 도구(Tools) > Active Directory Users and Computers > Managed Service Accounts를 여세요.

gMSA를 Domain Admin으로 지정할 수 있나요?

예, gMSA 계정은 Domain Admins의 구성원이 될 수 있습니다. 하지만 이와 같은 방식은 정보 보안에 위험할 수 있습니다.

gMSA를 어떻게 생성하나요?

그룹 관리 서비스 계정은 New-ADServiceAccount cmdlet으로 생성합니다.

gMSA의 객체 권한은 해당 자동화가 안전하게 유지되는지를 결정합니다. 일반 계정이 비밀번호 검색을 제어하는 속성에 대한 쓰기 권한을 가지고 있으면, 해당 자격 증명을 읽을 권한을 스스로 부여하고 서비스 ID의 기존 권한과 계정이 가진 모든 특권 그룹 멤버십을 포함하여 행동할 수 있습니다.

그 하나의 권한이 종종 강화된 배포와 도메인 전체 침해 사이를 가로막는 유일한 요소입니다.

서비스 계정은 비인간적 신원이며, 조직의 76%가 이를 완전히 관리하거나 모니터링하지 않는다고 Netwrix 2026 Data and Identity Security Report에 나와 있습니다. 그룹 관리 서비스 계정은 비밀번호를 사람의 손에서 제거하지만, 어떤 주체가 이를 가져올 수 있는 주체를 다시 쓸 수 있다면 여전히 신원을 탈취할 수 있습니다.

그룹 관리 서비스 계정(gMSA)이란 무엇인가요?

gMSA 작동 방식

gMSA의 비밀번호는 이를 사용하는 모든 호스트에서 동일한 순서로 이동합니다.

1. 각 도메인 컨트롤러의 Key Distribution Service(KDS)는 도메인의 모든 gMSA에 대한 암호를 계산하는 데 사용되는 비밀을 보유합니다.

그룹 관리 서비스 계정은 관리되는 Active Directory domain 계정으로, 서비스, 애플리케이션 및 예약된 작업을 실행하는 데 사용됩니다. Windows는 무작위 비밀번호를 생성하고 자동으로 변경하며, 권한이 있는 호스트는 실행 시 Active Directory에서 자격 증명을 가져오므로 관리자는 비밀번호를 알거나 파일에 저장할 필요가 없습니다.

1. 호스트는 이전 비밀번호도 가져와서 회전이 전파되는 짧은 시간 동안 인증이 작동하도록 유지합니다.

gMSA는 Windows Server 2012 이전 버전의 Windows 운영 체제에는 적용되지 않으므로 Windows Server 2012 이상이 필요합니다. gMSA는 여러 컴퓨터에서 하나의 서비스 ID를 지원하는 반면, 독립 실행형 관리 서비스 계정은 하나의 컴퓨터만 지원하고 일반 사용자 계정은 암호 관리를 관리자에게 맡깁니다.

1. 모든 권한 있는 호스트가 동일한 도메인 주체로 인증되기 때문에, gMSA는 여러 호스트에서 동일한 ID를 공유하는 서비스의 Service Principal Name(SPN) 관리도 간소화합니다.
2. Windows는 기본적으로 30일마다 비밀번호를 자동으로 변경하며, 호스트가 사전 통지나 수동 개입을 필요로 하지 않습니다.
3. 권한이 부여된 호스트가 도메인 컨트롤러에 연락하여 해당 비밀에서 계산된 현재 비밀번호를 실행 시점에 가져오며, 로컬에 저장하지 않습니다.

gMSA와 다른 서비스 계정 유형 비교

이 속성들은 함께 호스트에게 비밀번호를 어떻게 가져올지 알려주며, msDS-GroupMSAMembershipExpand 는 공격자가 다시 써야 하는 것으로, 아래 단계별 설명에서 악용하는 잘못된 구성입니다.

Active Directory는 개체 클래스 msDS-GroupManagedServiceAccountExpand를 가진 gMSA를 나타내며, 이 스키마 속성은 비밀번호와 검색 제어를 저장합니다.

Windows는 여러 주체를 제공합니다 서비스 실행용이며, 각각은 다른 서비스를 지원하고 비밀번호를 다르게 관리합니다. 애플리케이션의 인증 요구 사항과 배포 모델에 따라 계정 유형을 선택하세요.

sMSA와 달리 gMSA는 여러 컴퓨터에서 공유할 수 있어 서버 팜과 부하 분산 서비스에 적합합니다. 둘 다 Windows와 Active Directory가 암호 관리를 처리할 수 있도록 하는 관리 서비스 계정입니다.

gMSA가 중요한 이유

Microsoft는 gMSA 암호가 기계에서 생성되고 자동으로 교체되지만 기계에 묶여 있지 않아 손상된 호스트에서 여전히 읽을 수 있으며, gMSA는 dMSA로 직접 마이그레이션할 수 없다고 언급합니다.

Windows Server 2025는 delegated managed service account (dMSA)를 추가하여 기존 서비스 계정을 관리되고 무작위화된 키가 있는 머신 계정으로 이전하고 인증을 장치 ID에 연결합니다.

아무도 관리할 필요 없는 강력한 비밀번호

일반 사용자 계정을 서비스 계정으로 사용하면 비밀번호 생성, 배포 및 교체가 관리자에게 맡겨지고, 비밀번호는 누군가 교체할 때까지 변경되지 않습니다. gMSA는 이 수동 수명 주기를 도메인 관리 생성 및 검색으로 대체합니다.

비밀번호는 여전히 각 호스트에 도달해야 하므로 호스트 권한 부여와 호스트 보안이 자격 증명 보호의 일부가 됩니다.

서버 팜 전반에 걸친 하나의 아이덴티티

Kerberos와 같은 상호 인증을 지원하는 인증 프로토콜은 팜에 호스팅된 서비스의 모든 인스턴스가 동일한 principal을 사용해야 합니다. gMSA는 모든 멤버 호스트에 하나의 도메인 principal을 제공하며, 관리자는 호스트 간 비밀번호 동기화 없이 중앙에서 권한을 관리합니다.

무차별 대입 공격 및 오용 노출 감소

gMSA는 Windows가 30일마다 변경하는 무작위로 생성된 240바이트 암호를 사용하여 무차별 대입 공격 또는 사전 공격으로 인한 침해 위험을 최소화합니다. 관리자는 계정과 승인된 호스트를 구성하며 암호를 직접 다루지 않으므로 서비스는 스크립트, 배포 노트 또는 구성 파일에 암호를 복사하지 않고도 강력한 자격 증명을 얻습니다.

Windows 서비스, IIS 애플리케이션 풀 및 예약된 작업은 gMSA로 실행할 수 있으며, Microsoft의 Kerberoasting 가이드에서는 SQL Server도 언급합니다. 애플리케이션 지원은 배포 요구 사항으로 남아 있으므로, 프로덕션에 배포하기 전에 각 서비스를 gMSA로 테스트하세요.

Kerberoasting에 대한 더 안전한 기본값

자동 생성은 사람이 비밀번호를 선택하는 과정을 없애고, 자동 회전은 모든 서비스 호스트에서 정적 자격 증명을 업데이트하는 반복 작업을 제거합니다. Microsoft는 서비스가 사용할 수 없는 경우를 제외하고 온프레미스 서비스에 gMSA를 권장합니다.

남은 책임은 액세스 거버넌스입니다. 비밀번호 복구 권한을 변경할 수 있는 사람은 비밀번호 생성에 참여하지 않고도 자격 증명을 얻을 수 있기 때문입니다.

Kerberoasting 은(는) 도메인 계정이 있는 공격자가 서비스 티켓을 요청하고 서비스 계정의 비밀번호를 오프라인에서 크랙할 수 있게 하므로, 비밀번호 강도가 공격 성공 여부를 결정합니다.

Microsoft의 Kerberoasting 지침은 약한 비밀번호를 가진 계정을 가장 취약한 계정으로 지목하며, 가능한 경우 gMSA 또는 dMSA를 권장합니다. 생성된 비밀번호는 사람이 선택한 취약점을 제거하기 때문입니다.

gMSA를 안전하게 설정하는 방법

Netwrix Threat Manager는 하이브리드 환경 전반에서 자격 증명 도용, 측면 이동 및 권한 상승을 탐지합니다. 데모를 요청하세요.

1. 요구 사항을 확인하세요

gMSA를 배포하기 전에 도메인, 호스트, 관리 및 애플리케이션 요구 사항을 확인하세요.

명시된 허용 호스트 목록으로 계정을 생성한 후 각 호스트에 설치하고 검증하세요.

• 도메인 및 포리스트 기능 수준이 Windows Server 2012 이상으로 설정되어 있으며, Microsoft는 모든 장치에 대해 gMSA 기능을 지원한다고 합니다.
• Windows Server 2012 이상을 실행하는 호스트.
• 관리 시스템의 Active Directory PowerShell 모듈로, gMSA cmdlet을 실행하려면 64비트 아키텍처가 필요합니다.
• 도메인 컨트롤러에서 사용할 수 있는 KDS 루트 키.
• Domain Admins 또는 Enterprise Admins 멤버십, 또는 생성 권한 위임 msDS-GroupManagedServiceAccountExpand 개체.
• Windows 서비스, IIS 애플리케이션 풀 또는 예약된 작업과 같은 gMSA를 지원하는 서비스입니다.

gMSA 생성을 전용 관리 그룹에 위임하고 서비스 ID 자체를 관리 그룹에서 제외하세요.

2. KDS 루트 키를 생성합니다

3. New-ADServiceAccount로 gMSA를 생성합니다

페일오버 클러스터는 gMSA를 지원하지 않지만, 클러스터 서비스에서 실행되는 서비스가 Windows 서비스, 애플리케이션 풀 또는 예약 작업이거나 gMSA를 기본적으로 지원하는 경우 gMSA를 사용할 수 있습니다. Kerberos도 엔드 투 엔드로 작동해야 하므로 각 서비스에 대한 SPN을 등록하고 DNS 기록과 시계를 정확하게 유지하며 관련 시스템 간 Kerberos 트래픽을 허용하세요.

매개변수 이름과 달리 -EffectiveImmediatelyExpand는 복제를 건너뛰지 않습니다. 다른 도메인 컨트롤러는 키가 복제될 때까지 사용할 수 없으며, Microsoft의 키 생성 절차는 도메인 컨트롤러가 gMSA 생성을 허용하기 전에 최대 10시간까지 기다리도록 하므로, 운영 환경에서 이 시간을 허용하세요.

4. 각 호스트에 gMSA를 설치하고 테스트합니다

서비스의 호스트 컴퓨터 계정을 위한 전용 보안 그룹을 만든 다음 New-ADServiceAccountExpand로 gMSA를 생성하고 DNS 호스트 이름과 보안 그룹을 PrincipalsAllowedToRetrieveManagedPasswordExpand에 지정하세요. Microsoft는 gMSA 이름이 도메인이 아닌 포리스트 전체에서 고유해야 한다고 요구합니다.

키를 생성하기 전에 포리스트에 이미 KDS 루트 키가 있는지 확인하세요. 이 키는 포리스트 수준에서 한 번만 필요한 전제 조건입니다. Windows Server 2012 이상 도메인 컨트롤러에서 Add-KdsRootKey -EffectiveImmediatelyExpand를 실행한 후 이벤트 ID 4004Expand가 KDS 이벤트 로그에 기록되었는지 확인하세요.

5. 서비스를 gMSA로 실행되도록 구성합니다

배포에 필요하다면 생성 시 -ManagedPasswordIntervalInDaysExpand로 사용자 지정 비밀번호 간격을 설정하세요. 간격은 생성 시에만 설정할 수 있습니다. 계정의 애플리케이션 소유자와 대상 호스트를 배포 구성과 함께 기록하고, "Limit who can retrieve the password"에서 설명하는 대로 일반 서버 관리 그룹과 일반 사용자가 포함된 그룹은 검색 매개변수에서 제외하세요.

각 멤버 서버를 개별적으로 테스트하세요. 한 서버에서 성공적인 결과가 나왔다고 해서 다른 서버의 그룹 멤버십이나 연결 상태를 보장하지 않습니다. 운영 서비스의 로그인 ID를 변경하기 전에 실패한 검증을 해결하세요.

서비스의 로그온 ID를 Service Control Manager, IIS 애플리케이션 풀 ID 설정 또는 예약 작업 구성에서 설정하고 비밀번호는 비워 둡니다. Windows가 관리되는 자격 증명을 가져옵니다.

공격자가 gMSA 비밀번호를 악용하는 방법

계정에 필요한 애플리케이션 권한을 부여한 후 서비스 시작과 종속 리소스에 대한 액세스를 모두 확인하세요. 계정 테스트 통과는 자격 증명 준비 상태만 증명하므로 작업 부하는 여전히 자체 파일, 데이터베이스 및 기타 리소스 권한이 필요합니다.

각 호스트의 컴퓨터 계정을 보안 그룹에 추가한 다음 Install-ADServiceAccountExpand를 실행하고 Test-ADServiceAccountExpand를 모든 승인된 호스트에서 실행하세요. Test-ADServiceAccountExpand는 호스트가 비밀번호를 가져올 수 있는지 확인합니다.

아래 실험실은 notadminExpand이라는 일반 계정과 잘못 구성된 권한 있는 gMSA를 사용합니다. 도메인 및 계정 이름은 해당 예제 환경에 속합니다.

gMSA와 이를 읽을 수 있는 사람 찾기

공격자는 권한이 부여된 경로나 보안이 취약한 Active Directory 권한을 통해 gMSA 비밀번호를 획득한 후, 해당 계정의 기존 권한으로 인증할 수 있습니다.gMSA 악용는 관리되는 자격 증명에 대해 다른 경로를 취하는 Golden gMSA 공격을 포함한 더 넓은 공격 범위를 다룹니다.

1. Active Directory PowerShell 모듈이 사용 가능하면 공격자는 다음 명령으로 관리되는 서비스 계정을 나열합니다 Get-ADServiceAccount -Filter *Expand.

권한 있는 gMSA와 진입 경로를 찾으세요

1. 속성 PrincipalsAllowedToRetrieveManagedPasswordExpand 를 요청하면 각 계정의 비밀번호를 읽을 수 있는 주체가 표시됩니다.

실험실 결과에서 관리 계정 하나만 비밀번호를 조회할 수 있으므로 notadminExpand는 아직 읽을 수 없습니다. 공격자가 gMSA 객체를 변경할 수 있는 사용자를 조사할 때 이 구성이 중요합니다.

1. 공격자는 서비스 계정이 특권 그룹에 속하는지 memberOfExpand 속성을 조회하여 확인합니다.

실험실의 gMSA는 Domain Admins에 속하므로 공격자가 이를 선택합니다. 기존 멤버십이 이후 단계에 필요한 권한을 제공합니다.

비밀번호 검색 및 해독

1. 객체 권한 검토는 암호 검색 권한 속성에 대해 전체 제어, 모든 속성 쓰기 또는 속성 쓰기 권한이 있는 주체를 식별하며, 이는 Microsoft LAPS에 게시된 접근 방식을 수정한 스크립트를 사용합니다. 아래의 "Find and audit every gMSA" 권한 스크립트도 동일한 검사를 수행합니다.
2. 실험실에서 notadminExpand는 gMSA 객체에 대한 전체 제어 권한을 가지고 있어 Set-ADServiceAccountExpand를 사용하여 자신을 PrincipalsAllowedToRetrieveManagedPasswordExpand에 추가할 수 있습니다.

권한 상승에 비밀번호 사용

1. 속성은 비밀번호 자체가 아닌 비밀번호 데이터를 포함하는 BLOB을 보유하므로 공격자는 이를 DSInternals로 디코딩하며, 현재 및 이전 비밀번호 값을 노출하고 현재 비밀번호를 NT 해시로 변환할 수 있습니다.
2. 공격자는 notadminExpand을(를) 피싱과 같은 기법으로 탈취합니다. 해당 계정은 최소한의 Active Directory 권한을 가지고 있지만 local administrator rights를 탈취한 컴퓨터에서 보유하고 있습니다.
3. 변경 후, notadminExpand가 msDS-ManagedPasswordExpand 속성을 쿼리하고 반환된 객체를 저장할 수 있습니다.

gMSA를 보호하는 방법

하나의 과도하게 넓은 권한인 gMSA 객체에 대한 Full Control이 일반적으로 침해된 계정에서 도메인 전체 자격 증명 위조로 공격이 확산된 원인입니다.

Golden gMSA 공격은 다른 경로를 통해 gMSA의 비밀번호에 접근하며 gMSA exploitation 페이지에서 다룹니다.

gMSA의 검색 권한, 개체 권한 및 서비스 권한을 함께 보호하세요.

1. 복구된 자격 증명으로 공격자는 pass-the-hash를 통해 gMSA로 인증하고 서비스 ID로 프로세스를 시작하여 해당 ID가 가진 모든 권한을 상속합니다.

비밀번호를 검색할 수 있는 사람 제한

gMSA를 변경할 수 있는 사람 제한

1. 랩의 gMSA가 Domain Admins에 속해 있기 때문에 공격자는 복제 권한을 사용하여 DCSync 공격을 krbtgtExpand 계정에 대해 실행할 수 있습니다. 해당 계정의 자격 증명 자료는 도메인의 모든 Kerberos 티켓에 서명하므로, 이를 복구하면 공격자가 이후에 모든 사용자에 대한 티켓을 위조할 수 있습니다.

gMSA를 권한 있는 그룹에서 제외하세요

서비스를 실행하는 컴퓨터 계정만 일반적으로 해당 gMSA 암호를 가져와야 합니다. 다중 서버 배포의 경우 해당 컴퓨터 계정을 포함하는 전용 보안 그룹을 사용하고, PrincipalsAllowedToRetrieveManagedPasswordExpand를 통해 구성하며, 서비스의 호스트 목록이 변경될 때마다 멤버십을 검토하십시오.

계정을 관리해야 하는 관리자에게만 쓰기 권한을 부여하고, 모든 gMSA에 대해 전체 제어, 모든 속성 쓰기 및 속성별 쓰기 권한을 검토하세요. msDS-GroupMSAMembershipExpand을(를) 변경할 권한이 있는 주체는 자신의 비밀번호 검색을 승인할 수 있으며, 이는 위의 안내서가 악용하는 잘못된 구성입니다.

각 gMSA에는 해당 서비스에 필요한 권한만 부여하세요. gMSA는 Domain Admins에 속할 수 있지만, 이 멤버십은 자격 증명을 얻은 누구에게나 도메인 전체 관리자 권한을 부여하며, Microsoft의 완화 지침은 서비스 계정 권한을 검토하고 과도한 액세스를 제거할 것을 권장합니다.

AES 암호화 적용

권한 경로 두 가지 모두를 통해 계정을 보호하세요. msDS-GroupMSAMembershipExpand 속성이 나타내는 주체를 제한하고, 특히 계정 수정 권한이나 검색 권한을 포함하여 gMSA 객체 자체에 대한 디렉터리 접근을 제한하세요.

직접 그룹 구성원 자격과 중첩 그룹이 부여하는 유효 권한을 확인하고, 권한을 제거하기 전에 애플리케이션에 필요한 액세스를 문서화하여 서비스 소유자가 수정된 구성을 검증할 수 있도록 하십시오.

Windows Server 2025를 실행하는 도메인 컨트롤러는 더 이상 RC4 티켓 발급 티켓을 전혀 발급하지 않으므로 RC4에 의존하는 레거시 장치는 인증할 수 없습니다.

모든 gMSA를 찾아 감사하세요

Microsoft는 기본적으로 RC4 Kerberos 암호화를 단계적으로 폐지하고 있습니다. 단순히 사용을 권장하지 않는 것이 아닙니다. 2022년 업데이트로 명시적 암호화 유형이 설정되지 않은 모든 계정에 대해 기본 암호화 유형이 Advanced Encryption Standard (AES)-SHA1으로 이미 변경되었습니다.

각 gMSA의 msDS-SupportedEncryptionTypesExpand 속성을 확인하고 도메인의 대체 기본값에 의존하지 말고 AES가 포함되어 있는지 확인하세요. Microsoft가 제거하는 것이 바로 그 대체 기본값입니다.

AES 지원을 활성화한 후 계정의 비밀번호를 재설정하여 새 키를 생성하고, 이후 인증을 테스트하세요. RC4만 사용하는 gMSA는 단순히 약한 암호화 방식으로 작동하는 대신 Kerberos 인증을 완전히 잃을 수 있습니다.

비밀번호 읽기 모니터링

원본 스크립트: gMSA_Permissions_Collection.ps1.

결과 이벤트는 주체 계정, 대상 디렉터리 객체 및 액세스한 속성을 식별합니다.

아래 권한 스크립트는 gMSA의 msDS-GroupMSAMembershipExpand 속성에 대해 전체 제어 또는 속성 쓰기 권한을 가진 계정을 보고합니다. 위 단계 5의 검사는 공격자 측에서 실행됩니다. 관리자는 상속, 그룹 구성원 및 실제 액세스를 검토하여 누가 해당 권한을 유지해야 하는지 결정해야 합니다.

다음으로 관리되는 서비스 계정을 나열합니다 Get-ADServiceAccount -Filter *Expand, 그런 다음 ObjectClassExpand가 msDS-GroupManagedServiceAccountExpand인 객체로 필터링하여 gMSA와 독립 실행형 관리 서비스 계정을 구분합니다.

더 이상 사용하지 않는 gMSA를 제거하세요

감사 디렉터리 서비스 액세스 정책을 활성화하고 gMSA에서 시스템 액세스 제어 목록(SACL)을 구성하여 모니터링하면 이벤트 ID 4662Expand가 주체가 msDS-ManagedPasswordExpand를 읽을 때마다 생성됩니다.

속성 식별자는 이벤트에서 스키마 GUID로 나타나며, ADSI Edit는 해당 GUID가 msDS-ManagedPasswordExpand에 해당하는지 확인할 수 있습니다.

도메인 컨트롤러 로그를 보안 정보 및 이벤트 관리(SIEM) 시스템으로 전달하고, 계정의 승인된 서비스 호스트와 비밀번호 읽기 내역을 비교하며, 예상치 못한 사용자 또는 컴퓨터에 의한 조회를 조사하세요.

Netwrix가 gMSA 보안을 지원하는 방법

gMSA 관리 보호

환경에 몇 개 이상의 gMSA가 있으면 수동으로 검색 권한과 감사 로그를 검토하는 것은 확장되지 않습니다. 이 세 가지 Netwrix 제품은 계정에 대한 관리 액세스를 다루고, 자격 증명 오용을 감지하며, 여전히 과도한 권한을 가진 계정을 지속적으로 가시화합니다.

사용하지 않는 gMSA를 이전 호스트에서 Uninstall-ADServiceAccountExpand로 제거하세요. 호스트 제거와 디렉터리 계정 삭제는 별개의 수명 주기 작업입니다. AD 개체를 삭제하기 전에 모든 종속 워크로드가 이전되었거나 종료되었는지 확인하고, 동일한 변경 작업의 일부로 오래된 호스트 권한 및 관련 리소스 권한을 제거하세요.

비정상적인 서비스 계정 동작 감지

Netwrix Privilege Secure를 통해 해당 구역은 작업 완료 시 제거되는 임시 계정을 통해 즉시 액세스를 부여했으며, 수개월이 아닌 며칠 만에 중요한 시스템에 Privileged Access Management를 구현했습니다.

Netwrix Privilege Secure는 gMSA와 같은 권한 있는 객체에 대한 상시 액세스를 임시 작업 범위 계정으로 대체합니다. Eastern Carver County Schools는 Red Teams가 과도하고 불필요한 권한 액세스를 통해 중요한 시스템에 반복적으로 접근하는 것을 목격했습니다.

권한이 과도하거나 오래된 서비스 계정을 찾으세요

Netwrix Threat Manager는 하이브리드 환경 전반에서 자격 증명 탈취, 측면 이동 및 권한 상승을 탐지합니다. 도난당한 관리 암호로 인증하는 공격자가 gMSA와 같은 서비스 ID의 기존 권한을 행사하는지 여부를 조사하세요.

자동 회전을 엄격한 검색 권한과 결합하세요

Netwrix Access Analyzer는 중첩된 그룹 멤버십을 해석하고 Active Directory 객체에 대한 유효 권한을 분석하며, 보고서에서는 오래된 수탁자 계정도 표시합니다. 이러한 결과를 사용하여 gMSA 검색 및 객체 권한을 검토하고 정리 후보를 식별하세요.

자동 비밀번호 교체와 엄격한 조회 권한은 별개의 제어 수단이며, gMSA는 두 가지 모두 충족될 때만 안전합니다. 위의 설명은 권한 중 하나만 누락될 때 무슨 일이 발생하는지 보여줍니다: 일반적으로 침해된 계정이 Domain Admin 자격 증명을 상속받아 도메인 전체에 대한 티켓을 위조하며, 비밀번호가 해킹되거나 추측된 적은 없습니다.

권한 검토를 일회성 설정 단계가 아닌 반복 작업으로 처리하세요. 새로운 호스트, 그룹 구성원 변경, 서비스 마이그레이션마다 동일한 경로가 다시 열릴 수 있기 때문입니다.

데모 요청하여 Netwrix Privilege Secure가 특권 계정에 대한 상시 액세스를 제거하고, Netwrix Threat Manager가 서비스 계정 남용을 감지하며, Netwrix Access Analyzer가 과도한 권한 계정을 식별하는 방법을 확인하세요.