비인간 정체성(NHI) 설명과 이를 보호하는 방법

대부분의 조직은 환경에서 실행 중인 비인간 정체성(Non-human identities, NHIs)에 대해 완전한 목록을 만들지 못합니다. 서비스 계정, API 키, 애플리케이션 자격 증명은 Active Directory(AD)와 클라우드 플랫폼 전반에 걸쳐 누적되며, 종종 명확한 소유자, 문서화된 목적, 또는 정해진 검토 주기가 없습니다.

이러한 공백은 실제 위험으로 이어집니다. Netwrix 2025 Cybersecurity Trends Report에 따르면, 지난해 계정이 침해된 조직은 46%로, 2020년의 16%에 비해 증가했습니다. 서비스 계정과 토큰 같은 기기 간(machine-to-machine) 정체성은 이러한 추세에서 점점 더 큰 요인으로 자리잡고 있으며, 대부분의 중견(미드마켓) IT 팀은 이를 효과적으로 관리할 수 있을 만큼의 가시성이 부족합니다.

사이버보안에서 비인간 정체성(Non-human identities)이란 무엇이며, 왜 중요한가요?

비인간 정체성(Non-human identities, NHIs)은 사람이 개입하지 않고도 기계, 애플리케이션, 자동화 프로세스가 인증하고 리소스에 접근할 수 있도록 해주는 디지털 자격 증명입니다. 서비스 계정, API 키, 관리형 정체성(managed identities), OAuth 토큰, AI 에이전트 모두 NHI 범주에 포함됩니다.

그 수는 빠르게 증가하고 있습니다. 모든 클라우드 리소스, CI/CD 파이프라인, 자동화 워크플로, AI 통합은 자격 증명과 권한이 필요한 새로운 NHI를 만들어냅니다. 대부분의 조직에서는 기계(머신) 정체성이 사람 사용자보다 10:1 이상 배 더 많습니다.

오전 2시에 백업 소프트웨어가 데이터베이스에 연결할 때, 비밀번호를 직접 입력하지는 않습니다. 저장된 자격 증명을 사용하는 서비스 계정으로 인증을 수행하죠. 이것이 NHI입니다. 티켓팅 시스템이 CRM 데이터를 가져오는 데 사용하는 API 키나, 직원 기록을 Entra ID에 동기화하는 OAuth 토큰에도 똑같이 해당됩니다.

Netwrix의 최고 제품 책임자(Chief Product Officer)인 Jeff Warren이 2025 사이버보안 트렌드 보고서에서 언급했듯이, 신원(아이덴티티) 기반 공격은 더 큰 비중을 차지할 가능성이 높습니다. 그중에서도 새로운 공격 경로로 “서비스 계정과 토큰 같은 머신-투-머신 아이덴티티의 악용”이 부상하고 있습니다.

사람의 정체성(아이덴티티) 대 비(非)인간 정체성

사람의 정체성과 비(非)인간 정체성은 소유, 인증, 관리, 모니터링 방식이 다릅니다:

• 소유: 사람의 신원에는 명확한 소유자가 있습니다. NHI는 종종 소유가 공유되거나 불명확하여, 책임성(accountability)을 강제하기가 어렵습니다.
• 인증: 사람은 MFA와 함께 비밀번호를 사용합니다. NHI는 키, 토큰, 인증서를 사용하며 MFA는 적용되지 않습니다.
• 라이프사이클: 사람의 신원은 HR이 주도하는 프로세스(온보딩, 역할 변경, 퇴사/오프보딩)를 따릅니다. NHI는 이에 해당하는 라이프사이클 관리 없이 개발자와 관리자가 수시로(ad hoc) 생성합니다.
• 행동: 사람의 접근은 상호작용적이며 변동성이 있습니다. NHI의 접근은 프로그램 기반이고 반복적이어서, 이상 징후 탐지는 기준선을 잡기는 더 쉽지만 대규모로 검토하기는 더 어렵습니다.

비밀번호 정책, MFA, SSO, 액세스 리뷰는 NHI에 그대로 적용되기 어렵습니다. 그래서 머신 아이덴티티에는 자체적인 거버넌스 접근 방식이 필요합니다.

관련 용어인 “machine identity(머신 아이덴티티)”는 서버, VM, 인증서와 같은 인프라 수준의 정체성을 구체적으로 가리킵니다. NHI는 더 광범위하여, 여기에 더해 API 키, 토큰, 봇 같은 애플리케이션 수준의 자격 증명까지 포함합니다.

비인간 정체성 인증 방법

NHI는 대화형 로그인 대신 프로그램 방식으로 인증하며, 다음의 4가지 주요 방법을 사용합니다.

• 토큰 기반: API 키, 베어러 토큰, JWT 토큰
• 키 기반: SSH 키와 서비스 계정 키
• 인증서 기반: X.509 인증서와 상호 TLS(mTLS)
• 워크로드 ID 페더레이션: AWS IAM 역할, Azure 관리 ID, GCP 서비스 계정과 같은 클라우드 네이티브 메커니즘

네 가지 모두에서 공통적인 치명적 위험은 MFA와 SSO가 적용되지 않는다는 점입니다. 자격 증명이 유출되면 악용을 막기 위한 두 번째 요소가 없고, 공격자는 해당 ID가 보유한 권한을 그대로 상속받습니다.

비(非)인간 아이덴티티의 일반적인 유형

환경에 존재하는 다양한 유형의 NHIs를 이해하는 것은 이를 효과적으로 관리하기 위한 첫 번째 단계입니다. 다음 범주는 온프레미스와 클라우드 환경 전반에서 접하게 될 가장 일반적인 비(非)인간 신원(identities)을 나타냅니다.

1. 서비스 계정과 애플리케이션 정체성(identities)

서비스 계정은 사람이 사용하는 자격 증명 없이도 애플리케이션이 작업을 수행할 수 있도록 해주는 전용 계정입니다. 백업 소프트웨어는 이를 사용해 SQL Server 데이터베이스에 액세스하고, 모니터링 도구는 이를 사용해 성능 데이터를 수집합니다. AD 환경에서는 이러한 계정이 ServicePrincipalName (SPN) 속성으로 식별됩니다.

핵심 보안 과제는 비밀번호가 거의 변경되지 않는다는 점입니다. 최신 모범 사례는 Group Managed Service Accounts (gMSAs) 로 마이그레이션하는 것입니다. 이 방식은 Active Directory를 통해 비밀번호를 자동으로 관리하고, 수동적인 관리자 개입을 없애줍니다.

애플리케이션 정체성(identities)은 이 개념을 클라우드 네이티브 환경으로 확장합니다. 클라우드 플랫폼은 애플리케이션에 전용 정체성을 할당하여 API, 데이터베이스 및 기타 클라우드 리소스에 액세스할 수 있게 합니다.

2. API 키와 시크릿

API 키와 시크릿은 동일한 기본 기능을 합니다. 즉, 사람의 개입 없이 한 시스템이 다른 시스템에 인증할 수 있게 해줍니다. 이러한 정보는 내부 도구, SaaS 통합, 그리고 타사 서비스 연결에 포함되어, 누군가가 로그인할 필요 없이 프로그램 방식의 액세스를 제공할 수 있습니다.

이러한 제3자 범주는 대부분의 팀이 생각하는 것보다 훨씬 더 넓습니다. 예를 들어 프린터가 소모품 모니터링을 위해 제조사와 통신하거나, 제조 장비가 원격 유지보수를 위해 OEM에 텔레메트리를 전송하는 경우, 이러한 연결은 조직 경계를 넘어 인증을 수행하는 API 키 또는 내장 자격 증명에 의존합니다. 이처럼 공급업체가 관리하는 NHIs는 종종 표준 ID 거버넌스의 범위 밖에 놓이는데, 이는 귀하의 IT 팀이 아니라 공급업체가 제공(프로비저닝)하기 때문입니다.

이 모든 경우에 공통된 과제는 그것들이 정적이라는 점입니다. 사용자 계정에 연결된 비밀번호와 달리, 대부분의 시스템에서 API 키는 기본적으로 만료되지 않으며, 설정 파일, 코드 저장소, 환경 변수, 심지어 채팅 로그에까지 그대로 남게 되는 경향이 있습니다.

비밀번호, 연결 문자열, 암호화 키를 포함해, 금고(vault)나 설정 파일에 저장된 시크릿도 마찬가지입니다. 이러한 자격 증명은 어떤 API 키와 동일한 수준의 액세스 위험을 가지지만, 종종 더 적은 수준의 점검을 받습니다.

유출되면 이러한 자격 증명 중 어떤 것이든 즉시 악용될 수 있으며, 조직은 실제로 이미 사용되기 전까지는 노출된 사실을 종종 알지 못합니다. 손상된 자격 증명이 제3자 통합에 속한 것이라면, 영향 범위는 여러분의 환경을 넘어 NIS2 및 DORA와 같은 프레임워크가 규율하는 벤더 관계까지 확장됩니다. 두 프레임워크 모두 디지털 서비스 의존성에 대해 공급망 위험 통제 수단을 의무화합니다.

3. 관리형 ID

관리형 ID는 Azure에서 NHI 인증을 위한 Microsoft의 최신 접근 방식입니다. 시스템 할당 관리형 ID는 특정 Azure 리소스에 직접 연결되며, 자격 증명을 저장할 필요 자체를 없애 줍니다. 사용자 할당 관리형 ID는 여러 리소스 간에 공유할 수 있습니다.

하지만 관리형 ID는 Azure 생태계 내에서만 문제를 해결해 줍니다. 하이브리드 환경을 운영하는 조직은 관리형 ID로 커버되지 않는 온프레미스 서비스 계정과 크로스 플랫폼 자격 증명에 대한 가시성도 여전히 필요합니다.

4. OAuth 토큰

OAuth 토큰 애플리케이션 간에 위임된 액세스를 가능하게 합니다. 예를 들어, HR 플랫폼이 직원 데이터를 identity provider(인증 공급자)로 동기화하거나, 보고 도구가 SaaS CRM에서 기록을 가져올 때, 이러한 연결은 지속적인 액세스를 유지하기 위해 OAuth refresh tokens에 의존합니다.

이러한 토큰은 의도한 것보다 수명이 더 긴 경우가 많으며, 팀이 더 많은 도구를 서로 연결할수록 SaaS 통합 전반에 걸쳐 누적됩니다.

5. 클라우드 워크로드 및 컨테이너 ID

워크로드 아이덴티티는 컨테이너화된 애플리케이션, 서버리스 함수, 클라우드 워크로드에 할당되는 자격 증명을 포함합니다. Kubernetes 배포, Azure Container Instances, AWS Lambda 함수 모두 다른 서비스에 액세스하기 위해 자격 증명이 필요합니다.

클라우드 플랫폼은 VM, 컨테이너, 서버리스 함수, Kubernetes pod 등 이러한 워크로드에 ID를 할당하여 클라우드 리소스, 스토리지, API에 액세스할 수 있게 합니다. 이 워크로드 아이덴티티는 빠르게 생성되고 삭제되며, 보안 팀이 이를 추적할 수 있는 능력을 종종 능가합니다.

6. 머신 및 장치 ID

물리적 및 가상 머신, IoT 디바이스, 인프라 구성 요소는 모두 저마다의 신원을 지닙니다. 인증서는 이러한 머신 신원을 자주 인증하며, 애플리케이션 수준의 자격 증명을 넘어 확장되는 동시에 그와 겹치는 NHI 거버넌스의 한 계층을 형성합니다. IoT 도입이 늘어날수록 이 신원(아이덴티티)도 함께 증가합니다.

7. 봇과 AI 에이전트

봇과 AI 에이전트 는 가장 새롭고 빠르게 확장되는 비(非)인간 아이덴티티 범주를 의미합니다. 예:

• Microsoft Copilot이 유용하려면 파일과 이메일에 대한 액세스 권한이 필요합니다
• 로보틱 프로세스 자동화(RPA) 봇은 업무 애플리케이션과 상호작용하기 위해 자격 증명이 필요합니다.
• CI/CD 봇은 코드를 배포하려면 액세스 권한이 필요합니다.
• 오케스트레이션 도구와 AI 에이전트는 비인간 신원으로 동작하며, 자동화 워크플로를 가능하게 하기 위해 종종 광범위한 액세스 권한을 갖습니다.

이들 각각은 다른 어떤 NHI와도 동일한 수준의 거버넌스를 필요로 하는 아이덴티티 관계를 만들어내지만, 보안 검토 없이 업무 팀이 빠르게 프로비저닝하는 경우가 많습니다.

추가적인 위험은 AI 도구가 코드 저장소와 개발 환경과 상호작용한다는 점입니다. 그 결과 프롬프트, 출력물, 로그에 자격 증명이 의도치 않게 노출되어, 기존의 보안 비밀(시크릿) 스캐닝이 항상 잡아내지 못하는 유출 경로가 만들어질 수 있습니다.

이러한 각 ID 유형은 서로 다른 관리 접근 방식이 필요하지만, 모두 공통적인 거버넌스 과제를 공유합니다. 소유자 추적, 자격 증명 로테이션, 더 이상 필요하지 않을 때의 폐기입니다.

환경에서 비(非)인간 ID를 발견하는 방법

NHIs를 관리(거버넌스)하기 전에 먼저 찾아야 합니다. 체계적인 검색/발견 프로세스는 문제의 범위를 이해하는 데 도움이 되지만, 대부분의 조직은 곧 수동 방식만으로는 표면만 긁는 수준에 그친다는 사실을 빠르게 깨닫게 됩니다.

ID 제공자부터 시작하세요

Active Directory에서 Service Principal Name을 가진 계정, 단독 관리 서비스 계정, 그룹 관리 서비스 계정을 조회합니다.

클라우드 환경에서는 아이덴티티 제공자의 관리자 콘솔에서 서비스 프린서펄, 앱 등록, 관리형(Managed) 아이덴티티의 목록을 가져오세요. 각 아이덴티티에 대해 다음 네 가지 속성에 집중하세요: 어떤 애플리케이션이 이를 사용하는지, 어떤 자격 증명을 보유하는지, 어떤 리소스에 접근할 수 있는지, 그리고 누가 이를 소유(관리)하는지.

코드 및 자동화 레이어까지 확장하기

DevOps 팀과 협력하여 CI/CD 파이프라인 구성, 인프라스트럭처-에스-코드(Infrastructure-as-Code) 템플릿, 환경 변수에 저장된 자격 증명을 식별하세요. 리포지토리 스캐닝 도구는 버전 관리에 커밋된 하드코딩된 자격 증명과 API 키를 표시할 수 있습니다. 이는 종종 추적되지 않은 NHIs(Non-Human Identities)가 가장 많이 존재하는 지점이기도 합니다.

SaaS 통합을 점검하세요

SaaS 애플리케이션 전반에서 OAuth 승인(grants)과 API 연결을 검토하세요. 많은 조직이 팀이나 회사에서 이미 떠난 사람들이 몇 달 또는 몇 년 전에 설정해 둔 통합에서 수십 개의 활성 OAuth 토큰이 발견되는 것을 경험합니다.

찾은 내용을 문서화하세요

발견한 모든 NHI에 대해 소유자(팀이 아닌 개인), 업무상 정당성, 자격 증명 유형 및 로테이션 상태, 그리고 여전히 필요하다는 것을 누군가가 마지막으로 확인한 시점을 기록하세요. 이 인벤토리는 그 이후의 모든 활동을 위한 기반이 됩니다.

중요한 주의 사항이 하나 있습니다. 수동 검색은 ‘실시간 인벤토리’가 아니라 특정 시점의 스냅샷을 제공한다는 점입니다. 환경은 매일 변하며, 분기별 내보내기만으로는 지난 화요일 누군가가 생성한 서비스 계정을 놓칠 수 있습니다.

지속적이고 자동화된 검색이 있어야만, 자신의 NHI(비인간 계정) 수를 실제로 알고 있는 조직과, 그저 알고 있다고 ‘추정’하는 조직을 구분할 수 있습니다.

비인간(Non-human) 신원을 보안하고 거버넌스하는 방법

비인간 신원 관리(Non-human identity management, NHIM)는 전통적인 Identity and Access Management(IAM) 및 Privileged Access Management(PAM)가 처리하도록 설계되지 않은 기계(머신) 신원을 찾아내고, 이를 관리(거버넌스)하며, 보안을 강화하는 실무입니다.

즉, 사람이 개입하지 않는 상황에서도 접근 권한을 관리(거버넌스)하고, MFA를 사용할 수 없는 자격 증명을 관리하며, HR 프로세스가 아니라 개발자와 자동화에 의해 생성되는 신원에 대해 소유권을 추적해야 한다는 뜻입니다.

환경 안에 무엇이 존재하는지 파악했다면, 거버넌스는 그것이 통제된 상태로 유지되도록 보장합니다. 효과적인 NHI 보안은 기계 신원을 신원 보안 프로그램의 ‘우선 순위 대상’으로 취급하고, 수명 주기의 모든 단계에 대해 정의된 정책을 적용합니다.

실제로는 다음과 같은 모습입니다:

• 생성 시 모든 NHI에 소유자를 지정하세요: 어떤 신원도 접근 권한과 수명 주기에 대해 책임지는 ‘특정 개인(배포 리스트가 아님, 팀 별칭도 아님)’ 없이 존재해서는 안 됩니다. 소유권을 프로비저닝 프로세스에서 필수 항목으로 지정하세요.
• 첫날부터 최소 권한을 적용하세요: 각 NHI가 본래 기능을 수행하는 데 필요한 특정 권한만 부여하되, 가능한 한 가장 좁은 리소스 수준으로 범위를 제한합니다. 단일 애플리케이션에만 접근이 필요한 서비스 계정에는 구독 전체 또는 도메인 전체 권한을 부여하지 마세요.
• 가능한 경우 자격 증명(credential) 교체를 자동화하세요: gMSA는 온프레미스 AD 워크로드에 대해 이를 자동으로 처리합니다. 클라우드 서비스 프린시펄과 API 키의 경우에는 교체(로테이션)를 배포 파이프라인에 내장하거나, 비밀 관리(secrets management) 솔루션을 사용하세요.

적절한 교체 주기는 자격 증명 유형과 노출 위험에 따라 달라집니다. 예를 들어 NIST, CIS , 그리고 PCI DSS는 권한이 높은 계정(privileged accounts)에 대해 일률적인 교체 기간을 의무화하지 않습니다.

• 행동 이상 징후를 모니터링하세요: 평소와 다른 패턴으로 갑자기 리소스에 접근하는 서비스 계정이나, 익숙하지 않은 위치에서 인증하는 API 키는 경고를 발생시켜야 합니다. 모든 이벤트를 일일이 검토하려고 하기보다는, 이미 수립된 기준선(baselines)에서 벗어나는지에 모니터링의 초점을 맞추세요.
• 적극적으로 폐기(Decommission)하세요: 사용하지 않는(NHI가 오래된) 계정은 어떤 환경에서든 가장 악용되기 쉬운 약점 중 하나입니다. 프로세스에 폐기 트리거를 포함하세요. 예를 들어 90일 동안 인증하지 않은 ID가 있으면 검토 대상으로 표시합니다. 소유자가 그 필요성을 설명하지 못하면 비활성화합니다. 또 30일 동안 아무도 알아차리지 못하면 제거합니다.
• 정기적인 일정에 따라 액세스를 인증하세요: NHI 소유자에게 각 identity가 여전히 현재 권한이 필요한지 재확인하도록 요구하세요. 연례 검토는 시작점이지만, privileged identities에는 분기별 검토가 더 적합합니다.

이러한 통제는 주요 컴플라이언스 프레임워크에 이미 내장된 요구사항과 직접적으로 매핑됩니다:

• CMMC Level 2는 non-human ones를 포함한 모든 identity에 대해 액세스 제어와 계정 관리를 요구합니다
• SOC 2 트러스트 서비스 기준은 non-human identities까지 확장되는 액세스 제어를 요구합니다
• HIPAA는 automated processes 및 service accounts에 의한 액세스를 포함하여 Protected Health Information에 대한 모든 액세스에 대해 감사 로그(audit trails)를 의무화합니다
• NIS2(EU)는 조직이 ICT 공급망 위험을 관리하도록 요구하며, 여기에는 환경에 액세스하는 제3자 서비스 자격 증명과 벤더가 관리하는(제공하는) 아이덴티티가 포함됩니다.
• DORA(유럽의 금융 부문)는 ICT 제3자 위험 관리를 의무화하며, 해당 서비스가 사용하는 머신 아이덴티티를 포함해 디지털 서비스 의존성을 모니터링하고 관리하기 위한 구체적인 요구사항을 규정합니다.

NHI 거버넌스를 구축하고 있다면, 동시에 컴플라이언스 증거도 구축하고 있는 것입니다.

Netwrix가 비인간 아이덴티티 보안을 지원하는 방법

위의 모든 거버넌스 활동은 한 가지에 달려 있습니다. 바로 환경에 어떤 비인간 아이덴티티가 존재하는지, 그리고 그들이 무엇을 하고 있는지 아는 것입니다. 대부분의 조직이 스스로 메우기 어려워하는 바로 그 공백이며, 그 지점에 Netwrix가 들어맞습니다.

Netwrix 1Secure platform 는 Active Directory 및 클라우드 환경 전반에서 ID 보안 상태(포스처)에 대한 지속적인 가시성을 제공합니다. 특히 비(非)인간 ID의 경우, 조직 정책을 위반하는 비활성 계정, 오래된 계정, 과도하게 허용적인 액세스 구성들을 드러내어 보안 팀이 분기별 스냅샷이 아닌 현재 상태를 파악할 수 있도록 합니다.

수동 쿼리가 특정 시점의 내보내기(익스포트)를 제공하는 반면, 1Secure는 새 ID가 생성되거나 기존 ID가 변경될 때마다 지속적인 관점을 유지합니다.

특히 Active Directory의 경우, Netwrix Auditor 는 서비스 계정에 대한 변경 사항을 추적하고 인증 이벤트를 모니터링하며 그룹 정책(Group Policy) 수정 사항을 감사하여, 기본 제공 도구가 놓치기 쉬운 가시성의 공백을 메웁니다.

누군가가 새 서비스 계정을 생성하거나, 해당 계정의 그룹 멤버십을 변경하거나, 대화형 로그온(Interactive logon)을 시도하면 Auditor가 이를 표시(플래그)합니다. 팀은 NHI 활동에 관한 감사 질문에 대해, HIPAA , SOC 2, 및 CMMC 같은 규정 준수 프레임워크에 직접 매핑되는 사람이 읽을 수 있는 보고서로 답변을 시작할 수 있습니다.

더 높은 권한이 필요한 특권 비(非)인간 ID의 경우, Netwrix Privilege Secure 는 감사 추적을 위한 전체 세션 기록(full session recording)과 함께, 적시(just-in-time) 프로비저닝을 통해 상시(standing) 특권을 없앱니다. 서비스 계정이 24시간 내내 지속적인 관리자 액세스를 보유하는 대신, Privilege Secure는 권한이 필요한 순간에만 높은 권한을 부여하고 작업이 완료되면 자동으로 권한을 회수합니다.

비인간(Non-human) ID에 대한 가시성 격차를 해소할 준비가 되셨나요? 데모를 예약하세요 환경에서 Netwrix가 어떻게 작동하는지 확인해 보세요.