Windows 서비스 계정 선정 ── LocalSystem, 가상 계정, gMSA

「당분간 LocalSystem으로 돌리던 사내 서비스가 보안 감사에서 『과도한 권한』으로 지적받았다. 무엇으로 바꿔야 하는가」「서비스가 공유 폴더에 접근하지 못해 도메인 사용자로 돌리고 있다. 비밀번호가 만료되면 서비스가 멈추므로 만료 없음으로 두고, 런북에 평문으로 적어 두었다」── 고객의 Windows 서비스 상담에서 이 두 가지는 단골입니다.

양쪽 현장에 공통인 것은, 서비스의 로그온 계정이 「설계 판단」이 아니라 「우연히 돌아간 설정」으로 고정되어 있다는 점입니다. Windows 서비스는 반드시 어떤 계정의 보안 컨텍스트에서 움직이며, 그 계정이 로컬에서 무엇을 할 수 있는지, 네트워크 너머에서 누구로 보이는지, 비밀번호를 누가 관리하는지를 전부 결정합니다. 여기를 기본값으로 두면, 한 서비스의 취약점이 머신 전체의 장악으로 직결되고, 평문 비밀번호가 런북과 스크립트에 흩어집니다.

flowchart TB
    accTitle: 로그온 계정이 결정하는 세 가지
    accDescr: 서비스는 반드시 어떤 계정의 보안 컨텍스트에서 움직이며, 그 계정이 로컬에서 할 수 있는 일, 네트워크 너머에서 누구로 보이는지, 비밀번호를 누가 관리하는지를 모두 결정한다
    acct["서비스의 로그온 계정"] --> local["로컬에서 무엇을 할 수 있는가"]
    acct --> net["네트워크 너머에서 누구로 보이는가"]
    acct --> pwd["비밀번호를 누가 관리하는가"]

그림 1: 로그온 계정 선정은 로컬 권한, 네트워크 신원, 비밀번호 관리를 동시에 결정하는 설계 판단이다.

실질적인 선택은 여섯 가지입니다 ── LocalSystem, LocalService, NetworkService, 가상 계정(NT SERVICE\<서비스 이름="">), 도메인 사용자, 그리고 gMSA(그룹 관리 서비스 계정). 중소기업 정보시스템 담당자와 Windows 앱 개발자를 대상으로, 이 글은 여섯 가지의 권한·네트워크 신원·비밀번호 관리를 한 장의 표로 정리하고, 2026년 8월 시점의 Microsoft Learn 1차 정보를 바탕으로 판단 흐름까지 요약합니다.

서비스 자체의 만드는 법(태스크 스케줄러와 서비스의 구분, .NET Worker Service로 구현)은 「Windows 서비스 만드는 방법과 운영」에서 다룹니다. 이 글은 사고가 가장 많은 「로그온 계정」에 집중합니다.

1. 먼저 결론

• 고민되면, 단일 머신 안에서 끝나는 서비스는 가상 계정, 도메인 안 리소스에 서비스 고유 신원으로 접근하는 서비스는 gMSA가 제1 후보입니다. Microsoft도 가능한 한 관리되는 계정(MSA / 가상 계정)을 쓰라는 지침을 줍니다.¹²
• LocalSystem을 「돌아가니까」로 고르지 마십시오. 토큰에 SYSTEM과 BUILTIN\Administrators가 들어가고 SeDebugPrivilege 같은 강한 특권을 가지므로, 장악당하면 그 머신의 거의 전부를 잃습니다. sc.exe create의 기본값이 LocalSystem인 것이 이 사고의 온상입니다.³⁴
• LocalService와 NetworkService의 차이는 네트워크 신원입니다. 로컬 권한은 둘 다 최소이지만, 원격에는 LocalService가 익명으로, NetworkService가 컴퓨터 계정으로 보입니다.⁵
• **가상 계정(NT SERVICE\<서비스 이름="">)은 비밀번호 관리가 필요 없으면서 서비스마다 신원을 분리할 수 있는 현대의 기본값입니다.** ACL에 「NT SERVICE\\서비스 이름」을 직접 지정할 수 있고, SQL Server의 기본 서비스 계정도 이것입니다.[^understand-service-accounts][^sql-service-accounts]
• LocalSystem, NetworkService, 가상 계정이 네트워크에 나갈 때는 컴퓨터 계정(DOMAIN\컴퓨터 이름$)이 됩니다. 공유 폴더나 SQL Server의 ACL에 PC$를 부여하면 도메인 사용자를 쓰지 않아도 되는 경우가 많습니다.³⁶
• 도메인 사용자를 서비스에 쓰는 구성은 비밀번호 운영과 Kerberoasting 양쪽에서 부채가 됩니다. SCM은 저장한 비밀번호로 로그온하므로 만료는 기동 실패가 되고, 그것을 피하는 「만료 없음 + 평문 메모」는 공격자에게 선물이 됩니다.⁷⁸
• gMSA는 Active Directory가 비밀번호를 자동 생성·자동 순환합니다. 요건은 도메인과 KDS 루트 키이며, 서비스에는 「DOMAIN\계정 이름$」을 비밀번호 칸을 비운 채로 설정합니다. 지원하지 않는 앱이 있으므로 사전 검증이 필요합니다.⁹¹⁰
• 계정을 바꾸면 프로필, %TEMP%, DPAPI의 전제가 바뀝니다. 옛 계정의 DPAPI로 보호한 데이터는 새 계정으로 복호화할 수 없습니다.
• 현황 재고는 서비스 목록의 로그온 계정과 이벤트 ID 4624(로그온 유형 5)로 확인할 수 있습니다.¹¹

한 문장으로 정리하면, 이 글의 결론은 「서비스에 사람용 비밀번호를 주지 않는」 구성(기본 제공 계정, 가상 계정, gMSA)을 기본으로 두고, 도메인 사용자는 최후의 수단으로 다룬다입니다.

2. 선택지의 전체상 ── 여섯 로그온 계정을 한 장의 표로

전제를 한 단만 복습합니다. 서비스 기동 시 서비스 제어 관리자(SCM)는 구성된 계정으로 로그온하고, 성공하면 액세스 토큰을 만들어 서비스 프로세스에 할당합니다. 이후 파일이나 파이프 등 모든 리소스 접근은 이 토큰과 ACL의 대조로 판정됩니다.⁷ 따라서 로그온 계정 선정은 서비스 프로세스에 넘기는 토큰의 내용을 정하는 설계입니다. 여섯 선택지를 늘어놓습니다.

flowchart TB
    accTitle: 서비스 기동 시 SCM이 하는 일
    accDescr: SCM은 구성된 계정으로 로그온하고, 성공하면 액세스 토큰을 만들어 서비스 프로세스에 할당하며, 이후 리소스 접근은 토큰과 ACL의 대조로 판정된다
    scm["SCM"] --> logon["구성된 계정으로 로그온"]
    logon --> token["액세스 토큰을 만든다"]
    token --> proc["서비스 프로세스에 할당한다"]
    proc --> access["파일이나 파이프에 접근"]
    access --> check{"ACL이 허용하는가?"}
    check -->|예| ok["접근 성공"]
    check -->|아니오| deny["접근 거부"]

그림 2: 서비스의 모든 리소스 접근은 기동 시 SCM이 만든 토큰과 ACL의 대조로 결정된다.

LocalSystem, LocalService, NetworkService, 가상 계정은 모두 비밀번호라는 개념 자체가 없습니다. SCM에 저장한 비밀번호로 로그온하는(= 만료와 유출이 가능한) 것은 도메인 사용자와 로컬 사용자뿐입니다.⁷³

아래에서 이 표를 한 행씩 파고듭니다.

3. LocalSystem의 무엇이 문제인가

3.1. 「관리자로 실행」보다 더 강하다

LocalSystem(표시 이름 Local System, NT AUTHORITY\SYSTEM)은 SCM이 쓰는 미리 정의된 계정이며, 로컬 컴퓨터에서 광범위한 권한을 가집니다. 토큰에는 NT AUTHORITY\SYSTEM과 BUILTIN\Administrators의 SID가 들어가고, 시스템의 대부분 개체에 접근할 수 있습니다. 나아가 다른 프로세스를 디버그할 수 있는 SeDebugPrivilege, OS의 일부로서 동작하는 SeTcbPrivilege가 기본으로 켜져 있습니다.³

이 강함은 장악당했을 때 피해의 크기와 동의어입니다. LocalSystem으로 도는 서비스에 임의 코드 실행 취약점이 하나 있으면, 공격자는 한숨에 그 머신의 모든 사용자 파일 읽기·변조(SYSTEM은 NTFS에서 기본으로 모든 권한⁵), SeDebugPrivilege로 다른 프로세스 메모리 읽기, 거기서 자격 정보 탈취와 측면 이동(Pass-the-Hash 등의 출발점)까지 도달합니다. 자격 정보 탈취와 측면 이동의 사슬은 「그림으로 이해하는 NTLM과 Kerberos」와 「Windows LAPS 실무 가이드」에서 다룹니다.

flowchart TB
    accTitle: LocalSystem 서비스가 장악당했을 때의 피해
    accDescr: LocalSystem으로 도는 서비스에 임의 코드 실행 취약점이 하나 있으면, 공격자는 모든 사용자 파일의 읽기·변조, 다른 프로세스 메모리 읽기, 자격 정보 탈취와 측면 이동까지 도달한다
    vuln["임의 코드 실행 취약점 하나"] --> sys["공격자가 SYSTEM 권한을 얻는다"]
    sys --> files["파일 읽기·변조"]
    sys --> mem["다른 프로세스 메모리 읽기"]
    sys --> cred["자격 정보 탈취"]
    cred --> lateral["다른 머신으로 측면 이동"]

그림 3: LocalSystem 서비스의 취약점 하나가, 한숨에 머신 전체 장악과 측면 이동의 출발점까지 이어진다.

3.2. 왜 아직도 고르는가

이유는 단순합니다. 기본값이고, 액세스 거부가 나타나지 않기 때문입니다. sc.exe create에서 obj=를 생략한 기본값은 LocalSystem이며,⁴ 많은 옛 샘플 코드와 설치 프로그램 템플릿도 여전히 LocalSystem을 전제합니다. 개발 중에 권한 오류에서 자유로울 수 있으므로, 「돌아갔으니 그대로 두자」를 양산하는 구조가 있습니다. Microsoft 자신의 문서도 대부분의 서비스는 이 정도의 권한 수준이 필요하지 않으며, 필요하지 않다면 LocalService나 NetworkService 사용을 검토하라고 말합니다.³

flowchart TB
    accTitle: LocalSystem이 계속 골라지는 구조
    accDescr: sc.exe create의 기본값이 LocalSystem이고 옛 샘플과 템플릿도 LocalSystem을 전제하므로, 개발 중 액세스 거부가 나타나지 않고 돌아갔으니 그대로라는 구성이 양산된다
    def["sc.exe create의 기본값"] --> lsys["LocalSystem으로 생성"]
    old["옛 샘플과 템플릿"] --> lsys
    lsys --> noerr["개발 중 액세스 거부 없음"]
    noerr --> asis["돌아갔으니 그대로 둔다"]
    asis --> mass["과도한 권한의 서비스가 양산된다"]

그림 4: 기본값과 「액세스 거부 없음」이라는 개발 경험이 LocalSystem으로 고정된 서비스를 양산한다.

3.3. TrustedInstaller와의 차이 ── LocalSystem도 무제한은 아니다

LocalSystem을 「Windows 최강 계정」이라고 부르는 것은 정확하지 않습니다. Windows Vista 이후의 Windows 리소스 보호(WRP)는 중요한 OS 시스템 파일, 폴더, 레지스트리 키의 변경을 TrustedInstaller(Windows Modules Installer 서비스)에만 허용하며, SYSTEM이나 관리자라도 재작성은 액세스 거부가 됩니다.¹² Explorer의 「TrustedInstaller의 사용 권한이 필요합니다」가 이 메커니즘입니다. 반대로 말하면 LocalSystem은 WRP 보호 영역 밖의 거의 전부에 도달할 수 있고, 업무 서비스에 그것을 줄 이유는 보통 없습니다.

flowchart TB
    accTitle: WRP 보호 영역과 TrustedInstaller의 관계
    accDescr: WRP가 보호하는 중요 시스템 파일과 레지스트리 키의 변경은 TrustedInstaller에만 허용되며, SYSTEM이나 관리자라도 액세스 거부가 된다
    ti["TrustedInstaller"] -->|변경 가능| wrp["WRP 보호 시스템 파일 등"]
    sysadm["SYSTEM과 관리자"] -->|액세스 거부| wrp
    sysadm -->|거의 전부 허용| other["WRP 보호 영역 밖"]

그림 5: LocalSystem도 무제한은 아니며, WRP 보호 영역의 변경은 TrustedInstaller에만 허용된다.

3.4. LocalSystem이 타당한 경우

예외적으로 타당한 것은 필요한 권한이 애초에 관리자급을 넘는 서비스입니다 ── 장치 드라이버와 밀접하게 동작하거나, OS 보안 기반을 조작하거나, 다른 서비스나 세션을 관리하는 경우 등. 백업 에이전트나 EDR 같은 소프트웨어가 해당합니다. 그때에도 그 권한을 정말로 쓰는 코드 경로가 있는지 확인하고, 권한이 필요한 작업을 분리할 수 있는지를 검토할 가치가 있습니다(구분하는 법은 「Windows의 관리자 특권이 필요해지는 것은 언제인가」를 보십시오).

4. LocalService와 NetworkService ── 최소 권한의 기본 제공 계정

LocalService(NT AUTHORITY\LOCAL SERVICE, SID: S-1-5-19)와 NetworkService(NT AUTHORITY\NETWORK SERVICE, SID: S-1-5-20)는 저권한 서비스를 위해 준비된 기본 제공 계정입니다. 둘 다 로컬에서는 최소 권한만 가지며, Users 그룹 구성원보다 크게 할 수 있는 일이 없습니다.⁵¹

둘의 차이는 한 점입니다. 네트워크 너머에서 누구로 보이는가입니다.⁵

• LocalService: 원격에 익명 자격 정보로 연결합니다. 인증이 필요한 리소스에는 접근할 수 없습니다.
• NetworkService: 원격에 컴퓨터의 자격 정보를 제시합니다(도메인 환경에서는 DOMAIN\컴퓨터 이름$).

구분은 「네트워크에 나가지 않거나, 나가도 신원이 필요 없으면」 LocalService, 「도메인 안 리소스에 머신의 신원으로 접근하고 싶으면」 NetworkService입니다.

flowchart TB
    accTitle: LocalService와 NetworkService의 차이
    accDescr: 로컬 권한은 둘 다 최소이지만, 원격에는 LocalService가 익명 자격 정보로 연결하고 NetworkService가 컴퓨터의 자격 정보를 제시한다
    ls["LocalService"] --> anon["익명 자격 정보로 연결"]
    anon -.-> ng["인증이 필요한 리소스는 불가"]
    ns["NetworkService"] --> comp["컴퓨터의 자격 정보를 제시"]
    comp -.-> pc["도메인 환경에서는 PC$로 보인다"]

그림 6: 로컬 권한은 같은 최소이지만, 네트워크 너머에서 보이는 신원은 익명과 컴퓨터 계정으로 갈린다.

다만 이 둘에는 현대적 관점의 약점이 있습니다. 같은 계정을 많은 서비스가 공유합니다. 다섯 서비스가 LocalService로 돌면, ACL이 계정 단위인 한 다섯이 서로의 리소스에 접근할 수 있습니다. SQL Server가 Local Service 계정을 지원하지 않는 것도 같은 이유입니다. 공유 계정이라 다른 서비스와 분리할 수 없기 때문입니다.¹

flowchart TB
    accTitle: 공유 계정은 분리할 수 없다
    accDescr: 여러 서비스가 같은 LocalService를 공유하면, ACL이 계정 단위인 한 서로의 리소스에 접근할 수 있다
    sva["서비스 A"] --> acct["같은 LocalService"]
    svb["서비스 B"] --> acct
    svc["서비스 C"] --> acct
    acct --> mutual["서로의 리소스에 접근 가능"]
    mutual -.-> reason["ACL이 계정 단위이기 때문"]

그림 7: 같은 계정을 공유하는 서비스는 ACL로 서로의 리소스에서 분리할 수 없다.

이 「저권한을 유지하면서 서비스마다 분리」를 푸는 것이 다음 주제, 가상 계정입니다.

5. 가상 계정(NT SERVICE\<서비스 이름="">) ── 현대의 기본값

5.1. 비밀번호 없이 서비스별 신원을 가질 수 있다

가상 계정은 Windows Server 2008 R2 / Windows 7 이후 쓸 수 있는 「관리되는 로컬 계정」입니다. 특성은 세 가지입니다.⁶

• 계정은 자동으로 관리되며, 생성도 비밀번호 설정도 필요 없습니다
• 이름은 NT SERVICE\<서비스 이름>이며, 서비스마다 고유한 신원이 됩니다
• 도메인 환경에서는 컴퓨터 계정의 자격 정보(DOMAIN\컴퓨터 이름$)로 네트워크에 접근할 수 있습니다

즉 LocalService/NetworkService의 「비밀번호 관리 없음」 장점을 유지하고, 「계정이 공유되어 분리할 수 없다」는 단점을 제거합니다. SQL Server 설치가 NT SERVICE\MSSQLSERVER 같은 가상 계정을 기본으로 하는 것도 이 때문입니다.¹

flowchart TB
    accTitle: 가상 계정이 양립시키는 것
    accDescr: 가상 계정은 LocalService와 NetworkService의 비밀번호 관리 없음 장점을 유지하고, 공유되어 분리할 수 없다는 단점을 제거하며, 서비스마다 고유한 신원을 가진다
    merit["장점（비밀번호 관리 없음）"] -->|유지| va["가상 계정"]
    demerit["단점（공유되어 분리 불가）"] -->|제거| va
    va --> ident["서비스마다 고유한 신원"]
    va --> auto["생성도 비밀번호 설정도 불필요"]

그림 8: 가상 계정은 기본 제공 계정의 장점을 유지하고, 공유되어 분리할 수 없다는 단점만 제거한다.

5.2. ACL에 「NT SERVICE\서비스 이름」을 직접 쓸 수 있다

실무의 편리함은 이름만으로 그 서비스만 ACL에 추가할 수 있다는 점입니다. 「이 데이터 폴더는 이 서비스만 쓸 수 있다」를 그룹 생성도 비밀번호 관리도 없이 실현할 수 있습니다.

# Change the service's logon account to a virtual account
# The value of obj= is "NT SERVICE\service-name". Do not specify a password
sc.exe config MyAppService obj= "NT SERVICE\MyAppService"

# Confirm the configuration (check SERVICE_START_NAME)
sc.exe qc MyAppService

# Grant modify rights on the data folder to this service only
icacls "C:\ProgramData\MyApp" /grant "NT SERVICE\MyAppService:(OI)(CI)M"

GUI에서는 services.msc에서 서비스 속성 → 「로그온」 탭 → 「이 계정」에 NT SERVICE\서비스 이름을 넣고, 비밀번호 칸은 비워 둡니다(가상 계정이나 MSA는 비밀번호를 지정하지 않는 것이 SCM의 사양입니다). 변경 후 서비스를 다시 시작하면 적용됩니다.

5.3. 제약 ── 머신 밖에서는 「그 서비스」가 아니다

가상 계정의 신원은 머신 로컬이며 도메인에서는 인식되지 않습니다. 네트워크에서는 뒤에서 말하듯 컴퓨터 계정으로 축소되므로, 원격은 「어느 서비스인지」를 구분할 수 없고, 여러 서버에서 같은 신원을 공유할 수도 없습니다.¹⁰

flowchart TB
    accTitle: 가상 계정의 신원은 머신 밖에서 축소된다
    accDescr: 머신 안에서는 서비스마다 고유한 가상 계정도 네트워크에서는 컴퓨터 계정으로 축소되어, 원격은 어느 서비스인지 구분할 수 없다
    vaa["가상 계정 A"] --> pc["컴퓨터 계정 PC$"]
    vab["가상 계정 B"] --> pc
    pc --> remote["원격에 보이는 신원"]
    remote -.-> nodist["어느 서비스인지 구분 불가"]

그림 9: 머신 안에서는 고유한 신원이라도, 네트워크 너머에서는 모든 서비스가 같은 PC$로 보인다.

이 제약 ── 네트워크 너머에서 서비스 고유 신원이 필요하거나, 여러 서버에서 같은 신원이 필요해지는 순간이 gMSA(8장)가 호출되는 때입니다.

6. 네트워크에 나갈 때의 신원 ── 컴퓨터 계정(PC$)의 실무

6.1. 「서비스가 공유 폴더에 접근하지 못한다」는 오해

도메인에 가입한 머신에서 LocalSystem, NetworkService, 가상 계정으로 도는 서비스가 원격 리소스에 접근할 때, 컴퓨터 계정(DOMAIN\컴퓨터 이름$)으로 인증합니다.³⁶ 글 머리의 「공유 폴더에 접근하지 못해 도메인 사용자로 만들었다」는 상담의 상당수는 사실 이것으로 해결됩니다. 대상 ACL이 PC$를 허용하지 않았을 뿐입니다.

flowchart TB
    accTitle: 컴퓨터 계정으로서의 원격 접근
    accDescr: 도메인 가입 머신의 LocalSystem, NetworkService, 가상 계정 서비스는 원격에 컴퓨터 계정으로 인증하며, 대상 ACL이 PC$를 허용하면 접근할 수 있다
    svc["서비스（LocalSystem, 가상 계정 등）"] --> auth["PC$로 인증"]
    auth --> acl{"대상 ACL이 PC$를 허용하는가?"}
    acl -->|예| ok["공유 폴더나 DB 접근 성공"]
    acl -->|아니오| ng["접근 거부"]

그림 10: 도메인 환경에서는 대상 ACL에 PC$만 부여해도 도메인 사용자 없이 원격 접근이 성립한다.

파일 서버 측의 부여는 평범한 ACL 조작과 같습니다. 계정 이름으로 컴퓨터 이름$을 지정합니다(GUI 개체 선택 대화상자에서는 개체 유형에 「컴퓨터」를 포함하십시오).

# On the file-server side: grant a service on APPSV01 modify rights on the shared folder
# You need to grant both share permissions and NTFS permissions
Grant-SmbShareAccess -Name "AppData" -AccountName "CORP\APPSV01$" -AccessRight Change -Force
icacls "D:\Shares\AppData" /grant "CORP\APPSV01$:(OI)(CI)M"

SQL Server도 같습니다. 컴퓨터 계정을 로그인으로 만들면 연결 문자열은 Integrated Security=true로 비밀번호 없이 통과합니다.

-- On the DB-server side: permit Windows integrated authentication from a service on APPSV01
CREATE LOGIN [CORP\APPSV01$] FROM WINDOWS;

6.2. PC$ 방식의 한계를 알아 두기

이 방식에는 한계가 두 가지입니다.

1. 입도는 머신 단위입니다. 같은 머신에서 도는 LocalSystem, NetworkService, 모든 가상 계정 서비스가 원격에서는 같은 PC$로 보입니다. 대상에서 「이 서비스만 허용」할 수 없고, 어느 서비스가 그 계정을 썼는지도 감사할 수 없습니다.²
2. 작업 그룹 환경에서는 쓸 수 없습니다. 컴퓨터 계정은 Active Directory 개체이므로, 도메인에 가입하지 않은 머신에는 없습니다. 대상 계정의 자격 정보를 명시적으로 다루는 설계가 필요합니다.

한계 1을 넘고 싶을 때 2026년의 답은 다음 장의 도메인 사용자가 아니라… 그 문제를 건너뛰고 gMSA로 가는 것입니다.

flowchart TB
    accTitle: PC$ 방식의 두 한계
    accDescr: PC$ 인증은 입도가 머신 단위라 서비스별 허용이나 감사가 불가능하고, 작업 그룹 환경에는 컴퓨터 계정 자체가 없어 쓸 수 없다
    pcs["PC$ 방식"] --> lim1["한계 1: 머신 단위"]
    pcs --> lim2["한계 2: 작업 그룹 불가"]
    lim1 -.-> noaudit["서비스별 허용·감사 불가"]
    lim2 -.-> nocred["명시적 자격 정보를 쓴다"]
    lim1 --> gmsa["이 너머: gMSA"]

그림 11: 머신 단위 입도와 도메인 전제라는 두 한계를 넘고 싶으면, 도메인 사용자를 건너뛰고 gMSA로 간다.

7. 도메인 사용자를 서비스에 쓰는 문제

7.1. 비밀번호의 구조적 문제

서비스에 도메인 사용자(또는 로컬 사용자)를 할당하면, SCM은 그 비밀번호를 저장하고 기동마다 그것으로 로그온합니다. SCM은 만료를 관리하지 않으므로 비밀번호가 만료되면 로그온이 실패하고 서비스가 기동하지 않습니다.⁷

거기서 현장에서 자주 보는 악순환이 시작됩니다.

1. 만료 때문에 서비스가 멈추는 사고가 난다
2. 재발 방지로 「비밀번호 만료 없음」을 설정한다
3. 변경 절차가 자리 잡지 않고, 같은 비밀번호가 여러 서버의 런북, 스크립트, 태스크 스케줄러에 평문으로 적힌다
4. 사람이 떠나도 비밀번호를 바꾸지 않는다(바꾸면 무엇이 멈출지 모른다)

flowchart TB
    accTitle: 도메인 사용자 운영의 악순환
    accDescr: 비밀번호가 만료되어 서비스가 멈추고, 재발 방지로 만료 없음을 설정하고, 평문 비밀번호가 런북과 스크립트에 퍼지며, 사람이 떠나도 바꿀 수 없다
    expire["1. 만료로 서비스가 멈춘다"] --> forever["2. 재발 방지로 만료 없음을 설정"]
    forever --> spread["3. 평문 비밀번호가 퍼진다"]
    spread -.-> where["런북, 스크립트, 작업"]
    spread --> stuck["4. 사람이 떠나도 바꿀 수 없다"]

그림 12: 만료 사고에서 시작해, 만료 없음과 평문 비밀번호의 확산이 고착된다.

Microsoft도 서비스에 도메인 계정을 쓰는 구성은 비밀번호와 SPN의 수동 관리에 상당한 운영 노력이 들고, 유지보수가 서비스 정지로 이어질 수 있다고 지적합니다.¹

7.2. Kerberoasting ── 서비스 계정이 표적이 된다

도메인 사용자 서비스 계정에 특유한 또 하나의 공격이 Kerberoasting입니다. Kerberos 인증을 받는 서비스는 로그온 계정에 SPN(서비스 주체 이름)을 등록합니다. 도메인의 인증된 사용자는 누구나 SPN이 등록된 계정에 서비스 티켓을 요청할 수 있으므로, 공격자는 티켓을 얻어 비밀번호의 오프라인 무차별 대입을 시도합니다. 사람이 정한 10~16자 비밀번호는 이 공격을 견디지 못합니다.

flowchart TB
    accTitle: Kerberoasting의 흐름
    accDescr: SPN이 등록된 서비스 계정에 대한 서비스 티켓은 인증된 사용자라면 누구나 요청할 수 있으므로, 공격자는 티켓을 얻어 비밀번호의 오프라인 무차별 대입을 시도한다
    atk["도메인의 인증된 사용자"] --> req["SPN에 대한 티켓을 요청"]
    req --> tkt["서비스 티켓을 얻는다"]
    tkt --> brute["오프라인 무차별 대입"]
    brute --> weak["10~16자 정도는 깨진다"]

그림 13: 인증된 사용자라면 누구나 티켓을 요청할 수 있고, 사람이 정한 길이의 비밀번호는 오프라인 무차별 대입을 견디지 못한다.

유효한 대응은 비밀번호를 사람이 추측하거나 깨뜨릴 수 없는 강도로 만드는 것입니다. Microsoft도 긴 비밀번호를 강제하는 것과, 비밀번호가 긴 머신 생성 난수가 되는 gMSA 사용을 열거합니다.⁸ 같은 문서는 Kerberos armoring(FAST)도 언급하지만, FAST는 사전 인증 데이터와 KDC 스푸핑 저항을 보호할 뿐, 인증된 사용자가 SPN에 서비스 티켓을 요청하는 것을 막지 않으므로 서비스 계정 비밀번호 강도의 대체재가 아닙니다. SPN과 Kerberos의 관계, 인증이 NTLM으로 떨어지는 조건은 「그림으로 이해하는 NTLM과 Kerberos」에 그림으로 정리되어 있습니다.

7.3. 그래도 도메인 사용자를 쓸 때

애플리케이션이 gMSA를 지원하지 않는 등의 이유로 도메인 사용자를 쓸 수밖에 없다면, 다음을 최소 완화로 다루십시오.

• 비밀번호를 무작위로 생성한 25자 이상으로 만들고, 비밀번호 관리 도구 외(런북, 스크립트, 공유 Excel)에는 적지 마십시오
• 서비스 전용 계정으로 만들고 서비스마다 나눕니다(사람 계정과 공유하지 마십시오²)
• 대화형 로그온과 원격 데스크톱을 거부하고, 「서비스로 로그온」만 허용하십시오
• 소속 그룹을 최소화하십시오(Domain Admins에 넣는 것은 논외입니다)
• 정기 순환 절차를 만들고 변경이 영향을 주는 곳을 대장에 넣으십시오

이 전부를 해도 gMSA로 이전하는 것보다 덜 안전하고 덜 쉽습니다 ── 그것이 다음 장입니다.

8. gMSA ── 비밀번호 관리를 Active Directory에 맡기기

8.1. 메커니즘과 효과

gMSA(그룹 관리 서비스 계정)는 비밀번호 관리를 도메인 컨트롤러에 맡기는 도메인 계정입니다. 비밀번호는 도메인 컨트롤러가 KDS(Key Distribution Service) 루트 키에서 계산하며, 허용된 호스트만 얻습니다.¹³

flowchart TB
    accTitle: gMSA가 비밀번호를 관리하는 방법
    accDescr: 도메인 컨트롤러가 KDS 루트 키에서 비밀번호를 계산하고, 허용된 호스트만 얻어 서비스 실행에 쓰며, 비밀번호는 기본 30일마다 자동 순환된다
    kds["KDS 루트 키"] --> dc["DC가 비밀번호를 계산"]
    dc --> host["허용된 호스트가 얻는다"]
    host --> svc["서비스 실행에 사용"]
    dc -.-> rot["기본 30일마다 자동 순환"]

그림 14: 도메인 컨트롤러가 비밀번호의 생성, 배포, 갱신을 맡고, 사람은 비밀번호를 모른 채로 운영할 수 있다.

효과는 명확합니다.⁹

• 240바이트의 무작위 생성 비밀번호: 무차별 대입과 사전 공격이 비현실적이 되고, Kerberoasting 저항이 크게 오릅니다
• 기본 30일마다 자동 순환: 사람이 변경을 계획할 필요가 없고, 서비스를 멈출 필요도 없습니다
• 여러 서버에서 같은 신원을 공유할 수 있습니다: 부하 분산 아래의 서버 팜이 같은 주체로 상호 인증할 수 있습니다
• 더 단순한 SPN 관리: SPN의 등록과 관리도 위임·단순화할 수 있습니다

사람은 비밀번호를 모른 채로 운영할 수 있습니다 ── Windows LAPS가 로컬 관리자 비밀번호에 하는 일을 서비스 계정에 하는 메커니즘으로 받아들이면, 위치가 잡히기 쉽습니다.

8.2. 요건

gMSA에는 전제가 있습니다.¹⁰

• Active Directory 도메인 환경(작업 그룹에서는 불가)
• 도메인 및 포리스트 기능 수준 Windows Server 2012 이상
• KDS 루트 키가 이미 만들어져 있을 것
• gMSA 이름은 도메인이 아니라 포리스트에서 고유해야 합니다
• 비밀번호 변경 간격은 생성 시에만 설정할 수 있습니다

KDS 루트 키 생성은 한 번이면 되지만, 생성 후 최대 10시간은 모든 도메인 컨트롤러로의 복제를 기다리므로 gMSA를 만들 수 없습니다. 복제가 끝나기 전에 비밀번호 검색이 실패하는 사고를 막는 안전 장치입니다.¹⁴

flowchart TB
    accTitle: KDS 루트 키 생성부터 gMSA 생성까지
    accDescr: KDS 루트 키를 만든 뒤 모든 도메인 컨트롤러로의 복제를 기다리므로 최대 10시간은 gMSA를 만들 수 없고, 복제가 끝나면 만들 수 있다
    add["KDS 루트 키를 만든다"] --> wait["복제 대기 최대 10시간"]
    wait -.-> why["검색 실패 사고를 막는 안전 장치"]
    wait --> done["모든 DC로의 복제가 끝남"]
    done --> ok["gMSA를 만들 수 있다"]

그림 15: 루트 키 생성 후 최대 10시간의 대기는, 복제가 끝나지 않은 채의 검색 실패를 막기 위한 대기 시간이다.

# Run as a domain administrator, on a domain controller (or an administrative
# workstation with the AD PowerShell module)

# Confirm whether a KDS root key exists, and create one if not (once per forest)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # Actually usable after up to 10 hours

8.3. 생성부터 구성까지의 절차

절차는 네 단계입니다. 「① 검색이 허용된 그룹을 만든다 → ② gMSA를 만든다 → ③ 서버에 설치한다 → ④ 서비스에 설정한다」.¹⁰

flowchart TB
    accTitle: gMSA 도입의 네 단계
    accDescr: 비밀번호 검색이 허용된 그룹 생성, gMSA 생성, 각 서버에 설치, 서비스의 로그온 계정으로 설정의 네 단계로 도입한다
    st1["① 검색이 허용된 그룹을 만든다"] --> st2["② gMSA를 만든다"]
    st1 -.-> add["서버의 PC$를 추가"]
    st2 --> st3["③ 각 서버에 설치"]
    st3 -.-> test["Test 명령으로 검색을 검증"]
    st3 --> st4["④ 서비스에 설정"]

그림 16: 그룹 생성부터 서비스 설정까지, gMSA 도입은 네 단계로 진행된다.

# ① Create a security group permitted to retrieve the password,
#    and add the computer accounts of the servers that will run the service
New-ADGroup -Name "GG-SvcBatchHosts" -GroupScope Global
Add-ADGroupMember -Identity "GG-SvcBatchHosts" -Members "APPSV01$", "APPSV02$"
# Group membership is evaluated at computer logon, so
# restarting the target servers after adding is the reliable approach

# ② Create the gMSA
New-ADServiceAccount -Name "svc-batch" `
    -DNSHostName "svc-batch.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG-SvcBatchHosts"

# ③ On each server that will run the service, install the gMSA and validate
Install-ADServiceAccount -Identity "svc-batch"
Test-ADServiceAccount -Identity "svc-batch"   # True means retrieval is working

# ④ Set it as the service's logon account. Append $ to the name, and do not specify a password
sc.exe config MyBatchService obj= "CORP\svc-batch$"
Restart-Service MyBatchService

services.msc에서 설정할 때도 계정 이름은 CORP\svc-batch$처럼 ── 끝에 $를 붙이고, 비밀번호 칸은 비웁니다. MSA 계열 계정은 대화형 로그온에 쓸 수 없습니다.¹ 그다음 공유 폴더나 SQL Server의 ACL에 PC$ 대신 CORP\svc-batch$를 부여하면, 서비스 고유 신원으로의 네트워크 접근이 비밀번호 없이 완성됩니다.

8.4. 지원하지 않는 앱이 있다

주의점으로, 모든 소프트웨어가 gMSA로 도는 것은 아닙니다. Windows 서비스, IIS 애플리케이션 풀, 태스크 스케줄러 작업처럼 표준 메커니즘으로 로그온 신원을 구성하는 것은 폭넓게 지원되지만, 장애 조치 클러스터링 자체가 gMSA를 지원하지 않거나, 내부가 비밀번호를 요구하는 앱은 쓸 수 없는 제약이 있습니다.¹⁰ Microsoft도 운영 전에 테스트 환경에서 gMSA로서의 동작을 확인하라고 분명히 말합니다.⁹

flowchart TB
    accTitle: gMSA 지원 여부를 가리는 법
    accDescr: 표준 메커니즘으로 로그온 신원을 구성하는 앱은 gMSA를 폭넓게 지원하지만, 장애 조치 클러스터링과 내부가 비밀번호를 요구하는 앱은 쓸 수 없으므로 운영 전 테스트 환경에서 확인한다
    app["대상 앱"] --> how{"로그온은 어떻게 설정되는가?"}
    how -->|표준 메커니즘| okapp["gMSA 지원"]
    okapp -.-> ex1["서비스, IIS, 작업"]
    how -->|비밀번호를 요구| ngapp["gMSA 불가"]
    ngapp -.-> ex2["장애 조치 클러스터링"]
    okapp --> test["운영 전 테스트"]

그림 17: 표준 메커니즘으로 로그온을 구성하는 앱은 폭넓게 지원되지만, 지원되지 않는 설계도 있으므로 운영 전 검증이 필수이다.

형제 계정도 있습니다. 단일 서버용 sMSA(독립 관리 서비스 계정), Windows Server 2025에서 도입된 dMSA(위임 관리 서비스 계정, 장치 신원에 묶어 자격 정보 탈취에 대응). 새로 만들 때는 gMSA를 기본으로 두고 요건에 따라 검토하십시오.⁶

9. 부수되는 설계 ── 로그온 권리, 프로필, DPAPI, 감사

계정과 함께 바뀌는 네 가지를 더 기억해 두십시오.

9.1. 「서비스로 로그온」 권리(SeServiceLogonRight)

서비스로 기동하려면 계정에 「서비스로 로그온」 사용자 권리가 필요합니다. LocalSystem, LocalService, NetworkService는 내장되어 있지만, 그 외의 계정(도메인 사용자, gMSA 등)은 명시적 할당이 필요합니다.¹⁵

services.msc GUI의 「로그온」 탭에서 설정하면, 스냅인이 이 권리를 자동으로 부여합니다. 반면 CreateService / ChangeServiceConfig(sc.exe config가 부르는 API)는 지정한 계정에 이 권리가 있는지 검증하지 않습니다. 스크립트로 구성한 서비스가 기동 시 「로그온 실패로 서비스가 시작되지 않았습니다」로 멈추는 전형적인 원인이 이것입니다. 도구의 부수 효과에 기대지 말고, 배포 절차에 로컬 보안 정책(secpol.msc)의 「서비스로 로그온」 추가, 또는 GPO/Intune을 통한 구성을 명시적으로 넣으십시오(이 권리를 그룹 정책으로 구성하는 환경에서는 정책이 적용되면 로컬 부여가 덮어쓰이므로 그것도 주의가 필요합니다). 반대로 서비스 전용 계정의 표준 수는 「로컬 로그온 거부」를 함께 설정하는 것입니다.

flowchart TB
    accTitle: 「서비스로 로그온」 권리의 구성 경로에 따른 차이
    accDescr: services.msc GUI는 권리를 자동 부여하지만, sc.exe config가 부르는 API는 권리를 검증하지 않으므로, 권리가 없는 계정은 기동 시 로그온 실패로 서비스가 멈춘다
    gui["services.msc에서 설정"] --> auto["권리가 자동 부여된다"]
    auto --> okgui["서비스가 기동할 수 있다"]
    cli["sc.exe config로 설정"] --> noval["권리가 검증되지 않는다"]
    noval --> has{"권리가 있는가?"}
    has -->|예| okcli["서비스가 기동할 수 있다"]
    has -->|아니오| stop["로그온 실패로 멈춘다"]
    stop -.-> fix["secpol.msc 또는 GPO로 명시 부여"]

그림 18: GUI는 권리를 자동 부여하지만, 스크립트 구성은 검증하지 않으므로 절차에 명시적 부여를 넣어야 한다.

9.2. 프로필, %TEMP%, HKEY_CURRENT_USER가 바뀐다

SCM은 서비스 기동 시 그 계정의 사용자 프로필을 로드합니다.⁷ 따라서 실제 %TEMP%, %APPDATA%, HKEY_CURRENT_USER는 로그온 계정마다 다른 것이며, 계정을 바꾸면 옛 계정 프로필에 저장한 설정과 캐시가 「사라진」 것처럼 보입니다.

설계상의 대응은 단순합니다. 서비스 데이터를 프로필 아래가 아니라 C:\ProgramData\<앱 이름> 같은 명시적 경로에 두고, 그 ACL을 로그온 계정에 부여하십시오. 그렇게 하면 계정 변경에 데이터 이전이 따라오지 않습니다.

flowchart TB
    accTitle: 프로필 의존과 데이터 배치의 대응
    accDescr: 실제 프로필은 로그온 계정마다 다르므로 계정을 바꾸면 옛 프로필의 데이터가 사라진 것처럼 보이지만, 명시적 경로에 두고 ACL을 부여하면 이전이 필요 없다
    sw["로그온 계정 전환"] --> newprof["다른 프로필이 로드된다"]
    newprof --> lost["옛 데이터가 사라진 것처럼 보인다"]
    lost -.->|대응| fix["ProgramData 아래에 둔다"]
    fix --> acl["로그온 계정에 ACL을 부여"]
    acl --> nomig["계정이 바뀌어도 이전 없음"]

그림 19: 프로필을 피하고 데이터를 명시적 경로에 두면, 계정 변경에 데이터 이전이 따라오지 않는다.

9.3. DPAPI로 보호한 데이터는 계정에 묶인다

더 놓치기 쉬운 것이 DPAPI입니다. 사용자 범위 DPAPI(CryptProtectData 또는 .NET의 ProtectedData)로 암호화한 데이터는, 원칙적으로 보호한 것과 같은 계정으로만 복호화할 수 있습니다. 계정을 바꾸는 순간 저장해 둔 연결 문자열이나 API 키를 읽을 수 없게 됩니다 ── 그것은 DPAPI가 제 일을 하는 것이지만, 이행 절차에 없으면 장애가 됩니다.

flowchart TB
    accTitle: DPAPI 보호 데이터와 계정 변경의 관계
    accDescr: 사용자 범위 DPAPI로 보호한 데이터는 보호한 것과 같은 계정으로만 복호화할 수 있으므로, 로그온 계정을 바꾼 뒤에는 비밀을 다시 입력해야 한다
    protect["옛 계정으로 DPAPI 보호"] --> data["보호된 연결 문자열 등"]
    data --> who{"어느 계정이 복호화하는가?"}
    who -->|같은 옛 계정| okdec["복호화 가능"]
    who -->|새 계정| ngdec["복호화 불가"]
    ngdec --> re["비밀을 다시 입력"]

그림 20: DPAPI로 보호한 데이터는 보호한 계정에 묶이며, 계정 전환 뒤에는 다시 입력해야 한다.

대응은 이행 계획에 「계정 전환 후 비밀을 다시 입력한다」는 절차를 넣는 것입니다(어디에 저장할지의 설계는 「Windows 앱에서 설정 파일에 기밀 정보를 평문으로 저장하지 않기 위한 베스트 프랙티스」를 보십시오). 또한 gMSA나 PC$로 Windows 통합 인증을 끝낼 수 있는 구성은 비밀 저장 자체를 없앨 수 있습니다. 올바른 순서는 「어디에 저장할까」보다 먼저 「저장하지 않고 끝낼 수 있을까」를 검토하는 것입니다.

그리고 서비스가 「호출한 사용자의 권한으로」 처리하고 싶다면, 계정을 더 강하게 만드는 것이 아니라 가장을 씁니다. 그것은 「Windows 위장 토큰을 올바르게 다루기」를 보십시오.

9.4. 감사 ── 4624 로그온 유형 5를 본다

서비스 기동은 보안 이벤트 로그에 이벤트 ID 4624(계정이 성공적으로 로그온됨)의 로그온 유형 5(Service: SCM이 서비스를 시작함)로 기록됩니다. 이벤트의 「Virtual Account」 필드는 로그온이 MSA / 가상 계정에 의한 것인지 나타내므로, 관리 계정의 사용을 감시하는 데도 쓸 수 있습니다.¹¹

flowchart TB
    accTitle: 서비스 기동을 감사하는 흐름
    accDescr: SCM이 서비스를 시작하는 것은 이벤트 ID 4624 로그온 유형 5로 기록되며, Virtual Account 필드로 관리 계정에 의한 로그온인지 식별할 수 있다
    start["SCM이 서비스를 시작한다"] --> ev["이벤트 ID 4624를 기록"]
    ev --> type5["로그온 유형 5（Service）"]
    type5 --> vafield["Virtual Account 필드"]
    vafield --> watch["관리 계정 감시"]

그림 21: 서비스 기동은 로그온 유형 5의 4624로 기록되며, 관리 계정의 사용까지 추적할 수 있다.

현황 재고는 서비스 목록의 로그온 계정을 집계하는 것이 빠른 방법입니다.

# Aggregate which services are running as which account
Get-CimInstance Win32_Service |
    Group-Object StartName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

# Inventory non-standard services running as LocalSystem (tell in-house / third-party by the path)
Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -eq 'LocalSystem' -and $_.PathName -notlike '*\Windows\*' } |
    Select-Object Name, DisplayName, PathName

이 출력에 「LocalSystem으로 도는 업무 서비스」와 「도메인 사용자로 도는 서비스」가 늘어서면, 다음 장의 판단 흐름이 호출됩니다.

10. 판단 흐름 ── 네 질문으로 정한다

지금까지의 내용을 선택 절차로 정리합니다. 네 질문에 순서대로 답하십시오.

flowchart TB
    accTitle: 로그온 계정의 판단 흐름
    accDescr: 네트워크 접근 여부, 도메인 가입, 머신 수준 신원으로 충분한지, gMSA 지원의 네 질문에 순서대로 답해 로그온 계정을 정한다
    q1{"상대에 Windows 인증?"} -->|아니오| va["가상 계정"]
    va -.-> sys["필요하면 LocalSystem"]
    q1 -->|예| q2{"도메인 가입?"}
    q2 -->|아니오| cred["저장 자격 정보를 보호"]
    q2 -->|예| q3{"머신 수준으로 충분한가?"}
    q3 -->|예| pcacl["가상 계정 + PC$"]
    q3 -->|아니오| q4{"앱이 gMSA를 지원?"}
    q4 -->|예| gmsa["gMSA"]
    q4 -->|아니오| du["사용자 + 완화"]

그림 22: 네 질문에 순서대로 답하면 여섯 선택지 중 무엇을 써야 하는지 정해진다.

질문 1: 그 서비스는 네트워크의 다른 머신(공유 폴더, DB, API 등)에 Windows 인증으로 접근합니까?

아니면 가상 계정이 기본입니다. 특수한 로컬 권한이 필요할 때만 그 필요를 확인한 뒤 LocalSystem을 검토하십시오.

질문 2: (접근한다면) 머신이 도메인에 가입되어 있습니까?

작업 그룹에서는 PC$도 gMSA도 쓸 수 없습니다. 대상 계정의 자격 정보를 명시적으로 다루는 설계(저장소를 DPAPI 등으로 보호)를 쓰거나, 도메인 가입을 검토하십시오.

질문 3: (도메인에서) 머신 수준 신원(PC$)으로 충분합니까?

충분하면 가상 계정(또는 NetworkService) + 대상 ACL에 PC$ 부여로 완성입니다. 서비스 고유 신원이 필요하거나, 여러 서버에서 공통 신원이 필요하면 질문 4로 가십시오.

질문 4: 애플리케이션이 gMSA를 지원합니까?

지원하면(SCM, IIS 앱 풀, 태스크 스케줄러처럼 표준 메커니즘으로 로그온을 구성하는 것은 대체로 지원합니다) gMSA. 검증 환경에서의 동작 확인을 잊지 마십시오. 아무리 해도 미지원이면, 7.3절의 완화를 모두 적용한 뒤 전용 도메인 사용자를 쓰십시오.

표로 보면 다음과 같습니다.

11. 정리

• 서비스의 로그온 계정은 로컬 권한, 네트워크 신원, 비밀번호 관리를 동시에 결정하는 설계 판단입니다. 기본값(LocalSystem)으로 두지 마십시오.
• LocalSystem은 SYSTEM+Administrators 토큰과 강한 특권을 가지며, 장악당했을 때 피해가 최대화됩니다. 대부분의 업무 서비스는 이 권한이 필요하지 않습니다.
• LocalService와 NetworkService는 둘 다 저권한이며, 차이는 네트워크 신원(익명, 또는 컴퓨터 계정)입니다. 다만 계정을 여러 서비스가 공유하므로 분리할 수 없습니다.
• 가상 계정(NT SERVICE\<서비스 이름="">)은 비밀번호 관리가 필요 없으면서 서비스마다 분리할 수 있는 현대의 기본값입니다. ACL에 직접 지정할 수 있고, 구성은 로그온 계정 이름만 바꾸면 됩니다.
• LocalSystem, NetworkService, 가상 계정은 도메인 환경에서 네트워크에 DOMAIN\PC$로 나갑니다. 공유 폴더나 SQL Server의 ACL에 PC$를 부여하면 도메인 사용자를 쓰지 않아도 되는 경우가 많습니다.
• 도메인 사용자를 서비스에 쓰면 만료로 인한 정지, 평문 비밀번호의 확산, Kerberoasting이라는 구조적 문제가 있습니다. 쓸 때는 전용 계정 + 긴 난수 비밀번호 + 로그온 제한이 필요합니다.
• gMSA는 AD가 비밀번호를 자동 생성·순환하는 메커니즘이며, 요건은 도메인, 기능 수준 2012 이상, KDS 루트 키입니다. 서비스에는 「DOMAIN\이름$」을 비밀번호 칸을 비운 채로 설정합니다.
• 계정을 바꿀 때는 「서비스로 로그온」 권리, 프로필과 %TEMP%의 이동, DPAPI 보호 데이터의 재입력을 이행 절차에 넣으십시오. 감사는 이벤트 ID 4624 로그온 유형 5로 확인할 수 있습니다.

다음에 서비스를 설치할 때, 로그온 설정 화면에서 잠깐 멈추고 이것을 다시 물으십시오. 이 서비스는 누구로서, 어디까지 접근할 수 있어야 하는가? 답은 이 글의 판단표 어느 한 행이어야 합니다.

관련 기사

• Windows 서비스 만드는 방법과 운영 ── 태스크 스케줄러와의 구분 사용부터 BackgroundService의 서비스화까지
• Windows의 관리자 특권이 필요해지는 것은 언제인가 - UAC, 보호 영역, 설계상의 구분 방법
• Windows 위장 토큰을 올바르게 다루기 - 스레드 단위 권한 대여와 안전한 복원 방법
• 그림으로 이해하는 NTLM과 Kerberos ── 왜 인증은 NTLM으로 ‘떨어지는가’
• Windows LAPS 실무 가이드 ── 전 PC 공통 로컬 관리자 비밀번호를 그만두기
• Windows 앱에서 설정 파일에 기밀 정보를 평문으로 저장하지 않기 위한 베스트 프랙티스

관련 상담 영역

합동회사 코무라소프트는 Windows 서비스와 상주 앱의 로그온 계정 설계와 최소 권한 강화, LocalSystem을 전제로 만든 기존 서비스를 가상 계정이나 gMSA로 이전하는 작업, 계정 변경 후 액세스 거부·DPAPI·프로필로 인한 장애 조사를 다룹니다. 「감사에서 지적받았는데 어디서부터 시작해야 할지 모르겠다」는 단계부터여도 괜찮습니다.

• Windows 앱 개발
• 장애 조사 & 원인 분석
• 기술 상담 & 설계 리뷰
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

당분간 LocalSystem으로 돌리던 서비스는 지금 당장 바꿔야 합니까?

일률적으로 즉시 변경이 정답은 아닙니다. 먼저 그 서비스가 정말로 LocalSystem급 로컬 권한(관리자를 넘는 강한 특권)을 필요로 하는지 확인하십시오. 파일 읽기쓰기와 네트워크 통신 정도라면, 가상 계정(NT SERVICE\서비스 이름)으로 옮기는 것이 제1 후보입니다. 이행 시에는 필요한 폴더와 레지스트리 키에 대한 액세스 부여, 프로필이나 DPAPI에 의존하는 데이터의 취급, 「서비스로 로그온」 권리의 유무를 확인합니다. 검증 환경에서 기동과 주요 기능을 확인한 뒤 운영을 전환하십시오.

가상 계정과 NetworkService 중 어느 쪽을 고를까요?

새로 고른다면 가상 계정을 권합니다. 네트워크에서는 둘 다 컴퓨터 계정(DOMAIN\컴퓨터 이름$)으로 보이고, 로컬 권한이 작은 점도 비슷합니다. 다만 NetworkService는 여러 서비스가 공유하므로, ACL로 「이 서비스만 허용」하는 분리를 할 수 없습니다. 가상 계정은 서비스마다 고유한 신원을 가지며, ACL에 NT SERVICE\서비스 이름을 직접 지정할 수 있습니다. SQL Server 등 최근 Microsoft 제품의 기본값도 가상 계정입니다.

gMSA를 작업 그룹 환경(도메인 없음)에서 쓸 수 있습니까?

쓸 수 없습니다. gMSA는 Active Directory 도메인 컨트롤러가 비밀번호를 생성·관리하는 메커니즘이며, 도메인과 KDS 루트 키 생성이 전제입니다. 작업 그룹 환경에서는 가상 계정 또는 LocalService/NetworkService로 로컬 처리를 끝내는 것이 기본입니다. 다른 머신에 접근해야 하면, 대상에 준비한 계정의 자격 정보를 명시적으로 쓰는 등 다른 설계가 필요합니다. 컴퓨터 계정(PC$)으로서의 네트워크 접근도 도메인 환경에서만 성립하는 이야기입니다.

서비스의 로그온 계정을 바꿨더니, 저장해 두었던 설정과 자격 정보를 읽을 수 없게 되었습니다. 왜입니까?

로그온 계정마다 고유한 사용자 프로필, %TEMP%, HKEY_CURRENT_USER, DPAPI 키가 묶여 있기 때문입니다. 특히 사용자 범위 DPAPI(CryptProtectData 등)로 보호한 데이터는 원칙적으로 보호한 것과 같은 계정으로만 복호화할 수 있습니다. 프로필 아래(AppData 등)에 저장한 파일도 새 계정에서는 다른 경로가 됩니다. 계정을 바꾸기 전에 DPAPI 보호 데이터의 재작성 절차(API 키 재입력 등)와 프로필 아래 파일의 이전을 계획하십시오.

서비스가 공유 폴더에만 접근하면 된다면, 도메인 사용자가 필요합니까?

많은 경우 필요하지 않습니다. 도메인 환경에서는 LocalSystem, NetworkService, 가상 계정으로 도는 서비스가 원격에 컴퓨터 계정(DOMAIN\컴퓨터 이름$)으로 인증됩니다. 공유 폴더의 공유 권한과 NTFS 권한에 그 PC$를 추가하면 읽고 쓸 수 있습니다. 서비스 고유 신원으로 접근 제어하고 싶거나, 여러 서버에서 같은 신원이 필요하면 도메인 사용자가 아니라 gMSA를 검토하십시오.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.