'svc-' 계정이 시한폭탄인 이유

By Mirko Peters · 2026-08-11

Automatically translated with AI from the original post. Read the English original

Titelbild: Why Your 'svc-' Accounts Are a Ticking Time Bomb

팟캐스트에 다시 오신 것을 환영합니다. 엔터프라이즈 보안 아키텍처를 깊이 다루는 시리즈를 계속 이어 갑니다. 대부분의 조직에서 Active Directory나 Microsoft Entra ID 디렉터리를 살펴보면 "svc-", "app-", "admin-bot"으로 시작하는 계정이 어지럽게 쌓여 있을 것입니다. 이런 계정은 시스템을 가동하고, 데이터가 흐르게 하고, 자동화를 실행합니다. 하지만 동시에 현대적인 보안 상태에서 가장 큰 사각지대이기도 합니다. 이번 블로그 글에서는 최근 팟캐스트의 내용을 확장하여, 기존 서비스 계정이 제로 트러스트 아키텍처를 왜 근본적으로 무력화하는지, 그리고 Microsoft Entra Workload Identities로 이전하는 것이 왜 유일한 해결책인지 살펴보겠습니다.

이 주제를 음성으로 자세히 듣고 싶다면 함께 제작한 팟캐스트 에피소드 Replace Service Accounts with Entra Workload Identities를 들어 보시기 바랍니다. 이제 사람이 아닌 주체의 위험이 어떻게 발생하는지, 그리고 이를 완전히 제거하는 방법을 자세히 살펴보겠습니다.

TL;DR

고정 시크릿과 광범위한 권한을 가진 서비스 계정은 가장 큰 ID 격차입니다. (Microsoft Entra ID의) Workload Identities는 사람이 아닌 모든 주체에게 최소 권한, 수명 주기, 조건부 액세스 정책, 자격 증명 교체, 전체 감사 추적을 갖춘 관리 가능한 ID를 제공합니다. 그리고 자동화를 중단하지 않고도 이를 실현할 수 있습니다.

서비스 계정이 실패하는 이유(그리고 제로 트러스트를 무너뜨리는 이유)

기존 서비스 계정 모델은 이제 존재하지 않는 네트워크 경계를 전제로 설계되었습니다. 신뢰가 기기가 사내 LAN에 연결되어 있는지로 정의되던 시절에는 구성 파일에 저장된 고정 암호도 그럭저럭 용인되었습니다. 오늘날 이 설계 철학은 명백한 위험 요소입니다.

고정 시크릿과 MFA 부재 -> 쉽게 탈취당하고, 안전하게 교체하기도 어렵습니다
기본적으로 과도한 권한 -> "일단 동작하게 만들기" 위해 부여한 권한이 영구적으로 남습니다
수명 주기 관리 부재 -> 소유자가 없거나 잊힌 계정이 마이그레이션과 조직 개편을 거치면서도 살아남습니다
감사 가능성 부족 -> "누가, 왜 이 계정을 사용했는가?"에 대한 답은 추측과 스크린샷에 의존합니다
예외를 당연시하는 문화 -> 봇을 위한 CA/MFA 제외 설정이 조용히 공격 표면을 넓힙니다

Managed Identities: 좋은 첫걸음이지만 Azure에 묶여 있습니다

조직이 정적 서비스 계정의 위험성을 인식하면, 많은 경우 첫 번째 대안으로 Azure Managed Identities를 떠올립니다. Managed Identities는 Azure에서 호스팅되는 리소스에 대해 시크릿 자체를 없애 준다는 점에서 큰 진전이지만, 분명한 한계도 있습니다.

✅ Azure 네이티브 리소스(Functions, VM, Logic Apps)에 대한 시크릿 없는 액세스
❌ 하이브리드/서드파티 대상에 대한 제약, 약한 소유자 매핑, 제한적인 거버넌스 가시성
❌ Azure 외부 환경에서는 CA/권한 부여 범위가 일관되지 않습니다

Workload Identities: 실제로 얻을 수 있는 것

바로 여기서 Microsoft Entra Workload Identities가 등장합니다. 사람이 아닌 주체를 이류 시민으로 취급하거나 Azure 전용 제약에 얽매이게 하는 대신, Workload Identities는 애플리케이션, 스크립트, 자동화된 서비스를 일급 보안 주체로 격상합니다.

일급 비인간 ID(앱, 스크립트, 커넥터, RPA, 통합)
범위가 제한된 권한(Graph/리소스 역할, 앱 전용 인증)과 최소 권한
비즈니스 프로세스와 연계된 수명 주기(소유자, 검토 주기, 폐기 절차)
워크로드를 위한 조건부 액세스(위험 및 컨텍스트 기반 게이트, 지원되는 경우 세션 제어)
자격 증명 위생(단기 시크릿, 인증서, 키 교체 정책)
통합 가시성(로그인, 토큰, 리소스 액세스, 변경 기록) -> 감사에 바로 대응 가능

비교 매트릭스(한눈에 보기)

기능	서비스 계정	Managed Identity	Workload Identity
시크릿	고정 암호	시크릿 없음(Azure)	시크릿 없음/단기 + 교체
범위	광범위/사용자와 유사	Azure 중심	모든 워크로드(앱/스크립트/커넥터)
CA / 위험	거의 적용되지 않음	제한적	지원되는 경우 정책 기반
수명 주기	임시 관리	기본	소유자 + 검토 + 폐기
감사	부족함	Azure 로그	중앙 집중식 로그인 및 권한 추적

아키텍처 패턴(일반적인 사용 사례)

워크로드 ID를 구현하려면 이를 아키텍처 패턴에 올바르게 매핑해야 합니다. 가장 일반적인 엔터프라이즈 워크로드에 이것이 어떻게 적용되는지 정리하면 다음과 같습니다:

Power Platform 커넥터 / 클라우드 흐름 -> 통합마다 워크로드 ID를 할당하고, 필요한 Graph/Dataverse 범위에만 권한을 부여합니다.
라인 오브 비즈니스 앱(웹 API, 데몬) -> 앱 등록 + 인증서를 사용하고, 앱 역할과 앱 전용 Graph를 활용합니다. 해당하는 경우 조건부 액세스를 적용합니다.
자동화 스크립트(Azure Automation, GitHub Actions, DevOps) -> 연합 자격 증명(OIDC)을 사용하고, 저장된 비밀은 사용하지 않습니다.
테넌트 간 / B2B 작업 -> 테넌트 경계마다 전용 워크로드 ID를 두고, 권한과 로깅을 분리합니다.

마이그레이션 플레이북(90일, 부담 없이 진행)

수백 개의 레거시 서비스 계정을 처리하는 일은 막막하게 느껴질 수 있습니다. 그래서 위험 감소에 초점을 맞춘 90일짜리 체계적인 마이그레이션 플레이북이 필요합니다.

1단계 — 발견 및 분류(0~3주차)

사람이 아닌 로그인 및 개체를 목록화합니다: svc-*, app-*, 공유 사서함, 앱 등록, 90일 이내에 만료되는 비밀.
각 항목을 소유자, 업무 목적, 대상, 권한, 긴급 액세스 계정 종속성에 매핑합니다.
위험도 순위를 매깁니다: 고정 암호, 전역 역할, 소유자 없음, 최근 교체 이력 없음.

2단계 — 고위험 항목 우선 전환(4~8주차)

통합마다 워크로드 ID를 새로 만듭니다(재사용하지 않습니다).
암호 인증을 인증서 또는 연합 자격 증명으로 교체하고 교체 주기를 설정합니다.
앱 전용 권한으로 전환하고, 필요하지 않은 사용자 위임 권한은 제거합니다.
워크로드 로그인에 대해 (지원되는 경우) 조건부 액세스 정책을 적용합니다.
액세스 검토(분기별)를 구현하고, CMDB/ITSM에서 소유권을 관리합니다.

3단계 — 폐기 및 거버넌스 적용(9~12주차)

기존 서비스 계정을 비활성화하고 14일간 모니터링한 후 삭제합니다.
생성 표준을 적용합니다: 명명 규칙, 소유자, 데이터 분류, 검토 주기.
알림을 추가합니다: 비정상 로그인, 30/60/90일 이상 비활성 ID, 만료 예정 비밀.
ID 점검을 CI/CD에 포함합니다(코드형 정책).

조건부 액세스 및 권한(실용적인 가드레일)

최신 ID 플랫폼의 가장 강력한 기능 중 하나는 사람이 아닌 주체에 맞춘 가드레일을 적용할 수 있다는 점입니다. 사람용 정책과 워크로드용 정책을 분리하면, 악성 트래픽은 계속 차단하면서도 봇이 '불가능한 이동' 경고를 유발하는 일을 막을 수 있습니다.

사람 ID와 워크로드 ID에 대해 정책을 분리하고, 워크로드의 대화형 로그온을 차단합니다.
가능한 경우 앱 전용 액세스에 대해 명명된 위치 / 네트워크 제한을 적용합니다.
기간이 정해진 권한 부여(사용 가능한 경우 앱 역할에 대한 PIM, 예약된 액세스 검토)를 적용합니다.
범위: 디렉터리 전체 권한보다 앱 역할 또는 리소스별 역할을 우선 사용합니다.

로깅 및 감사(감사자에게 보여줄 내용)

컴플라이언스 담당자와 감사자는 더 이상 백엔드 스크립트에 누가 액세스할 수 있는지에 대한 스프레드시트나 구두 확인을 받아들이지 않습니다. 중앙 집중식 로깅으로 거버넌스를 즉시 입증할 수 있어야 합니다.

앱/워크로드 소유자, 목적, 데이터 민감도
로그인 로그(서비스 주체 로그인), 토큰 대상, IP, 클라이언트 앱
역할 할당(승인자, 인증 시점)
자격 증명 이력(유형, 마지막 교체, 만료)
수명 주기: 생성/수정/비활성화/삭제 및 변경 주체

KPI 대시보드(개선 효과 입증)

경영진의 지속적인 지지를 확보하려면 사람이 아닌 ID의 위험 감소를 시간에 따라 보여주는 핵심 성과 지표를 추적하고 보고합니다.

소유자 및 검토 주기가 지정된 사람이 아닌 ID 비율(목표 ≥ 95%)
소유자가 없는 서비스 계정(목표 -> 0)
90일 이상 된 비밀(목표 -> 0; 인증서/연합 자격 증명 우선)
앱 전용 역할의 범위("Directory.ReadWrite.All" 개수 -> 감소 추세)
사람이 아닌 액세스에 대한 감사 결과(분기별 감소)

제거해야 할 안티패턴

환경을 정리하면서 팀이 예전 습관으로 돌아가지 않도록 해야 합니다. 다음 안티패턴은 즉시 근절해야 합니다:

하나의 범용 서비스 계정을 여러 시스템에서 재사용하는 행위
스크립트, web.config 또는 Key Vault에 암호를 넣어 두고 순환 정책을 적용하지 않는 경우
작업이 계속 돌아가도록 "만약을 대비해" 전역 관리자 / 소유자 권한을 부여하는 경우
만료되지 않고 계속 유지되는 "임시" 조건부 액세스 예외

빠른 성과 (이번 주)

보안 태세를 개선하는 데 대규모 프로젝트가 시작될 때까지 기다릴 필요는 없습니다. 이번 주에 바로 실행할 수 있는 빠른 성과 네 가지를 소개합니다.

사람이 아닌 모든 ID에 소유자, 시스템, 데이터 분류 태그를 지정합니다.
위험도가 높은 작업 하나를 연합 자격 증명으로 전환합니다(GitHub OIDC -> Entra).
Power Automate의 공유 서비스 계정 하나를 워크로드 ID로 교체합니다.
만료되었거나 곧 만료될 비밀이 있는 서비스 주체의 보고서를 만들고 알림을 예약합니다.

자주 묻는 질문 (빠른 답변)

워크로드 ID가 기존 온프레미스 작업을 깨뜨리나요?
아닙니다. 앱 전용 인증, 인증서 또는 브로커 서비스로 연결하고, 암호는 단계적으로 폐기하면 됩니다.

사람이 아닌 로그인에도 조건부 액세스를 적용할 수 있나요?
지원되는 흐름(서비스 주체 로그인)에는 적용할 수 있습니다. 해당하는 경우 네트워크, 위치, 디바이스 신호를 활용하고 대화형 로그인은 차단하세요.

무분별한 증가를 어떻게 방지하나요?
팀별이 아니라 통합(integration)마다 워크로드 ID 하나를 두세요. 생성 시점에 명명 규칙, 소유자, 검토를 적용하고, 비활성 상태인 항목은 자동으로 정리하세요.

Power Platform은 어떻게 하나요?
커넥터와 Dataverse에는 서비스 주체 / 워크로드 ID를 사용하고, 공유 사용자 계정 사용은 중단하세요.

결론

비밀을 순환시키는 것만으로는 서비스 계정 위험에서 벗어날 수 없습니다. Entra 워크로드 ID를 활용하면 사람에게 이미 요구하고 있는 제로 트러스트, 수명 주기, 감사 모델을 사람이 아닌 액세스에도 적용할 수 있으며, 장애나 과도한 수작업 없이 가능합니다. 가장 위험한 "svc-" 계정부터 시작해 거버넌스가 적용된 워크로드 ID로 전환하고, 예외를 다시 예외 상황으로 만드세요.

이 글이 도움이 되셨다면 팟캐스트 에피소드 Replace Service Accounts with Entra Workload Identities에서 전체 논의도 확인해 보세요. 엔터프라이즈 Microsoft 365 및 Azure 보안 전략에 대한 더 깊이 있는 내용을 원하신다면 쇼를 구독해 주세요!