현대 환경에서 비인간 정체성(NHI) 라이프사이클 관리

서론: 비인간 정체성(NHI) 라이프사이클이 주목받아야 하는 이유

비인간 정체성(Non-human identities, NHIs)은 사람이 직접 개입하지 않은 상태에서 시스템, 애플리케이션 또는 자동화 프로세스가 인증하고 다른 리소스와 상호작용할 수 있게 해주는 모든 자격 증명(credential) 또는 정체성 구성 요소를 포괄합니다. NHIs에는 애플리케이션이나 서비스에 전용된 서비스 계정(service accounts), 외부 서비스에 접근하기 위한 정적 토큰인 API 키(API keys), OAuth 토큰 또는 JWT 토큰처럼 수명이 짧은 토큰(short-lived tokens), 그리고 CI/CD 파이프라인, 구성 관리 도구, RPA 워크플로우에서 사용되는 자동화 자격 증명이 포함됩니다. 인프라가 다양하고 자동화 절차가 복잡한 조직에서는 NHIs가 사람 사용자보다 10배 이상 많을 수 있습니다. 중견 조직만 해도 수백 개의 NHIs를 보유할 수 있고, 대규모 기업은 수천 개를 보유할 수 있습니다. NHI 유형과 보안 과제에 대해 더 알아보려면 비인간 정체성 보안.

인간(인) 아이덴티티 라이프사이클 관리는 이미 잘 정립되고 성숙되어 있습니다. HR이 주도하는 워크플로를 통해 IT는 RBAC 역할과 정기적인 액세스 검토를 바탕으로 신규 입사자(joiner), 이직자(mover), 퇴사자(leaver) 직원의 계정 생성(프로비저닝)과 계정 회수(디프로비저닝)를 관리할 수 있습니다. 반면, NHI는 정의된 관리 구조가 없습니다. NHI는 종종 개발자나 DevOps 팀이 필요에 따라 임시 방식으로 생성하고, 편의를 위해 과도하거나 광범위한 권한을 부여하며, 문서화된 소유권 없이 방치되고, 거의 교체되지 않는 정적 자격 증명(static credentials)으로 구성되는 경우가 많습니다.

공식적인 NHI 라이프사이클 관리가 없으면, 조직은 세 가지 문제에 직면합니다:

• 아이덴티티 스프롤(Identity sprawl): 인프라 전반에 걸친 NHI의 통제되지 않은 확산으로 인해 거버넌스가 극도로 어려워집니다. 찾을 수 없는 것은 검토하고 보호할 수 없기 때문입니다.
• 고아가 된 자격 증명(Orphaned credentials): 정당한 소유자나 목적을 잃었지만 여전히 활성 상태인 NHI입니다. 어떤 팀도 이를 적극적으로 사용하지 않기 때문에, 공격자가 악용할 수 있는 숨겨진 위험으로 남습니다.
• 보안 사각지대(Security blind spots): NHI는 일반적으로 SIEM 또는 SOAR와 같은 보안 도구의 모니터링 범위 밖에 남아 있습니다. 이들 도구는 사람 계정의 의심스러운 활동을 탐지하도록 튜닝되어 있기 때문입니다. 또한 아이덴티티 거버넌스 플랫폼도 사람 계정에 초점을 맞추며 대체로 NHI를 포함하지 않습니다. 그 결과, 상당한 공격 표면이 그대로 노출됩니다.

이 문서는 NHI 라이프사이클의 5단계, 즉 발견 및 생성부터 모니터링, 위험 관리, 그리고 안전한 폐기(디커미셔닝)까지를 다룹니다.

오늘날의 IT 생태계에서 비(非)인간 정체성(NHI) 정의하기

비(非)인간 정체성(Non-human identities, NHIs)은 자율적으로 작동하는 머신, 애플리케이션, 서비스, 컨테이너, 스크립트, 자동화 프로세스에 할당되는 디지털 정체성입니다. 사람의 개입 없이 NHIs는 인증을 수행하고, 특정 권한에 대해 인가를 받으며, 리소스에 접근하고, IT 시스템 내에서 프로그래밍 방식으로 작업을 수행합니다. 예를 들어 AWS에서 호스팅되는 애플리케이션은 IAM 역할을 사용해 스토리지 파일에 접근할 수 있고, Kubernetes에서 실행되는 마이크로서비스는 서비스 계정을 사용해 다른 서비스와 통신할 수 있습니다.

NHIs는 API 키, 공유 시크릿, 인증서, JWT 또는 OAuth 토큰, 워크로드 아이덴티티 같은 기계 친화적인 메커니즘으로 인증합니다. 사람의 계정과 달리 NHIs는 대화형으로 로그인하지 않으며, 전통적인 의미의 비밀번호를 사용하지 않고, 종종 저장된 자격 증명에 의존합니다. 자동으로 실행되기 때문에 NHIs는 매우 빠른 속도로 수백~수천 건의 작업을 수행할 수 있으며, 사람의 아이덴티티와 동일한 보안 통제와 표준으로 관리되어야 합니다.

NHI는 오늘날의 복잡한 IT 인프라에서 필수적입니다. 현대적인 조직은 클라우드 네이티브 배포 아키텍처를 도입해야 하며, 마이크로서비스와 DevOps 방식은 기반으로서 기계 간 통신이 필요합니다.

• API 상호작용: 현대 애플리케이션은 API에 크게 의존합니다. 애플리케이션은 API를 사용하여 데이터베이스, 결제 게이트웨이, 스토리지 서비스, 모니터링 도구, 그리고 타사 SaaS 플랫폼과 통신합니다. 이러한 상호작용 각각은 NHI로 구동되며 인증이 필요합니다.
• DevOps 및 CI/CD 파이프라인: 지속적 통합 및 지속적 배포 파이프라인은 소프트웨어 빌드, 테스트, 배포를 자동화합니다. 이러한 파이프라인은 NHI 에이전트를 사용해 소스 코드 저장소, 아티팩트 레지스트리, 컨테이너 플랫폼, 배포용 클라우드 환경, 그리고 알림 도구에 인증합니다. 각 상호작용에는 서로 다른 NHI로 인증이 필요하며, 이러한 ID는 종종 권한이 높습니다.
• 클라우드 워크로드: 클라우드 네이티브 환경에서는 가상 머신, 컨테이너, 서버리스 함수, Kubernetes 포드 같은 워크로드를 동적으로 생성하고 제거합니다. 이러한 워크로드에는 스토리지에 접근하고 데이터베이스를 조회하며 메시징 서비스에 접근할 수 있도록 NHI가 할당됩니다. 생성, 변경, 폐기되는 모든 NHI는 적절한 가시성을 바탕으로 수명 주기 관리를 필요로 합니다.
• 예약 작업 및 자동화: 클라우드와 DevOps를 넘어, 전통적인 IT 환경 역시 배치 처리 작업, 예약 스크립트, 데이터 동기화 작업, 백업 서비스, 모니터링 에이전트를 위해 NHI에 의존합니다. 이러한 자동화 작업은 권한이 높은 서비스 계정에서 실행되며, 대개 주기적으로 교체되거나 모니터링되지 않고 적절히 제한되지도 않습니다.

조직이 관리하는 대표적인 비(非)인간 ID 유형

서비스 계정 및 애플리케이션 ID: 이러한 ID는 애플리케이션, 서비스, 프로세스가 인증하고 리소스에 안전하게 액세스할 수 있도록 특정 목적에 맞게 생성된 전용 비(非)대화형 계정입니다. 예를 들어 급여 애플리케이션이 서비스 계정을 사용해 SQL 데이터베이스에 연결하여 직원 데이터를 조회하면, 인사 변경과 무관하게 업무 연속성을 보장할 수 있습니다. 보통 고정된 자격 증명(크리덴셜) 또는 키로 구성되며, 거의 변경되지 않는 경우가 많고 시간이 지나면서 과도한 권한이 누적되기 쉽습니다. 또한 여러 애플리케이션과 환경에 걸쳐 자주 공유됩니다.

API 키, 토큰, 인증서: 이러한 ID는 기계-대-기계(machine-to-machine) 상호작용에 사용됩니다. 사용자 이름과 비밀번호로 로그인하는 대신, 애플리케이션과 서비스는 이러한 ID를 사용해 자신을 안전하게 식별합니다. API 키는 호출 애플리케이션을 식별하고 권한을 부여하기 위해 서비스(AWS, Entra ID, Stripe 등)에서 발급하는 정적인 비밀 문자열인 경우가 많습니다. OAuth 또는 JSON Web Tokens(JWT)는 인증 이벤트 이후 발급되는 단기(짧은 수명)의 토큰으로, 추가 검증 없이 보유자에게 액세스를 제공합니다. PKI 기반 인증서는 상호 TLS 인증, 코드 서명, 서비스 메시 통신에 사용됩니다. 이 인증서에는 만료일이 포함되어 있지만, 관리되지 않는 인증서는 서비스 중단의 주요 원인 중 하나입니다.

클라우드 워크로드 및 컨테이너 ID: NHIs는 가상 머신, 컨테이너, 서버리스 함수, 그리고 Kubernetes 파드에 동적으로 할당됩니다. 이러한 워크로드는 서로 간에도 상호작용하고, 클라우드 외부에서는 다른 클라우드 플랫폼 또는 온프레미스 인프라와도 상호작용합니다. 관리형 ID는 하드코딩된 시크릿의 필요성을 줄여주지만, 이 워크로드가 사용하는 IAM 역할과 연관된 권한이 잘못 구성되어 있으면 공격자의 주요 표적이 됩니다.

DevOps, CI/CD 및 자동화 ID: DevOps 환경은 자동화 ID에 크게 의존합니다. Jenkins, GitHub Actions, GitLab CI, CircleCI 같은 CI/CD 파이프라인 도구는 코드를 체크아웃하고, 아티팩트를 푸시하며, 클라우드 환경에 배포하고, 인프라를 업데이트하기 위해 자격 증명이 필요합니다. Terraform과 Ansible 같은 인프라스트럭처-에이-코드(Infrastructure-as-Code, IaC) 도구는 광범위한 권한을 가진 클라우드 제공업체 자격 증명을 요구합니다. 만약 이 자동화 ID가 손상되면, 공격자는 프로덕션 환경에 즉시 제어 권한을 가질 수 있습니다.

AI 에이전트 및 자율 시스템 정체성: 조직이 AI 기반 자동화를 더 빠르게 도입함에 따라, 새로운 유형의 NHI가 등장하고 있습니다. 이러한 AI 에이전트와 자율 시스템 정체성은 엔터프라이즈 시스템과 상호작용하는 AI 코파일럿, 운영 작업을 수행하는 지능형 봇, 데이터 파이프라인에 접근하는 머신러닝 모델, 양식 작성 및 데이터 변환을 수행하는 로보틱 프로세스 자동화(RPA) 봇을 의미합니다. 조직은 이러한 AI 에이전트를 배포할 때 신중해야 하며, 감사 추적(audit trail)과 함께 액세스 범위를 제어하고 모니터링하는 정체성 수명주기 관리 시스템을 정의해야 합니다.

인간 vs. 비인간 정체성: 수명주기 비교

인간과 비인간 정체성 모두 거버넌스가 필요하지만, 수명주기는 구조, 소유권, 위험 프로파일, 운영 동작 방식에서 본질적으로 다릅니다. 기존 IAM 프로세스는 주로 사람 사용자용으로 설계되었으며, NHIs에 그대로 적용하면 종종 적절한 통제를 제공하지 못합니다.

전통적인 IAM 워크플로는 사람의 고용 수명주기를 중심으로 설계됩니다. 계정 소유권이 명확하고, HR 상태가 이벤트를 트리거한다고 가정합니다. 그러나 NHI는 이러한 패턴을 따르지 않으므로, HR 기록이 없고 관리자가 없으며 대화형 로그인 이벤트가 없고, 자연스러운 오프보딩(퇴사/해제) 타임라인도 없기 때문에 목적에 맞게 설계된 수명주기 관리가 필요합니다.

비인간 정체성 수명주기에는 실제로 무엇이 포함되는가

NHI는 사람 사용자와 마찬가지로 구조화된 라이프사이클 관리가 필요하지만, 자동화, 기계 대 기계 통신, 고속 확장성과 같은 시나리오에 맞게 관리 방식이 달라져야 합니다. 다음은 NHI 라이프사이클의 5가지 핵심 단계입니다:

라이프사이클 접근 방식으로 NHI를 관리하면 보안 사각지대가 발생하지 않도록 보장할 수 있습니다. 각 단계는 보안 통제로 기능합니다. 즉, 식별(발견)이 없으면 섀도우 정체성이 생기고, 프로비저닝이 약하면 권한이 서서히 확대(Privilege creep)되며, 모니터링이 없으면 침해가 탐지되지 않은 채로 남고, 자격 증명 로테이션이 없으면 유출된 한 개의 키로 지속적인 접근 권한이 부여되며, 디커미셔닝이 없으면 고아 상태의 자격 증명이 남아 탐지되지 않은 영속적 백도어를 만들어냅니다.

1단계: 비(非)인간 정체성의 식별 및 인벤토리

식별(Discovery)은 비(非)인간 정체성을 관리하기 위한 중요한 첫 단계입니다. 보안에서 가장 첫 번째 규칙은 "볼 수 없는 것은 보호할 수 없다"이기 때문입니다. 어떤 거버넌스, 정책, 또는 보안 통제를 적용하기 전에, 조직은 환경 전반에 존재하는 모든 NHI에 대해 포괄적이고 정확하며 지속적으로 업데이트되는 인벤토리를 구축해야 합니다.

검색(디스커버리)에 필요한 요소

지속적인 스캔: NHIs는 정적인 것이 아닙니다. 개발자는 필요에 따라 서비스 계정을 프로비저닝하고, CI/CD 파이프라인은 수명이 짧은 토큰을 생성하며, 클라우드 네이티브 워크로드는 새로운 정체성을 동적으로 만듭니다. 시점 기준 감사는 거의 즉시 구식이 되어버리는 스냅샷을 포착하게 됩니다. 효과적인 디스커버리는 일정 또는 이벤트 기반으로 실행되는 지속적이고 자동화된 스캔이 필요하며, 새로 생성되는 정체성이 나타나는 즉시 이를 감지해야 합니다.

환경 전반에 대한 범위: 현대적인 조직은 하이브리드 및 멀티클라우드 환경 전반에서 운영됩니다. 디스커버리는 온프레미스 디렉터리(예: Active Directory), AWS/Azure/GCP의 클라우드 IAM 시스템, SaaS 플랫폼, 컨테이너 오케스트레이션 시스템, 시크릿(암호) 볼트까지 지속적으로 스캔해야 합니다. 디스커버리가 한두 개의 환경에만 제한된다면, NHI 공격 표면의 상당 부분이 보이지 않은 채로 남게 됩니다.

특성(어트리뷰트) 매핑: 디스커버리는 단순히 정체성을 나열하는 것만이 아닙니다. 보안 및 거버넌스 제어를 적용하려면 각 정체성의 전체 맥락을 함께 파악해야 합니다. 여기에는 모든 NHI에 대해 누가(어느 팀 또는 개인)가 소유자인지, 해당 정체성이 수행하는 비즈니스 기능이 무엇인지, 어떤 시스템이나 서비스가 그것에 의존하는지, 그리고 자격 증명이 마지막으로 언제 로테이션되었는지를 포함한 핵심 특성을 매핑하는 작업이 포함됩니다.

자주 발생하는 디스커버리 과제

1. HR 시스템이나 주요 ID 제공자에 중앙 집중된 사람의 정체성과 달리, NHI는 한 곳에 존재하는 경우가 드뭅니다. NHI는 클라우드 플랫폼의 IAM 콘솔, 서버의 로컬 서비스 계정 구성, 볼트에 저장된 시크릿, 구성 파일이나 코드 저장소에 포함된 API 키 등 다양한 곳에 존재합니다. 이러한 ID 스패rawl(분산)은 전문적인 NHI 관리 도구 없이는 정확한 실체(인벤토리)를 파악하기 어렵게 만듭니다.
2. HR 시스템에서 중앙 디렉터리로 동기화되는 사람의 정체성과 달리, NHI는 일반적으로 권위 있는(공식) 원천 시스템이 없습니다. 여러 정체성이 동일한 기능을 수행할 수 있고, 애플리케이션이 퇴역(종료)된 뒤에도 고아 상태의 정체성이 계속 활성 상태로 남으며, 중복된 자격 증명이 환경 전반에 존재할 수 있습니다. 따라서 보안 팀은 여러 소스에서 데이터를 수집하고 상호 연관 분석하여 통합 인벤토리 플랫폼을 구축해야 합니다.
3. NHI 식별(발견)에서 가장 어려운 상황 중 하나가 섀도(Shadow) 아이덴티티입니다. 개발자와 DevOps 엔지니어는 정식 프로비저닝 프로세스 외부에서 빠른 수정, 테스트, 신속한 배포를 위해 아이덴티티를 자주 생성합니다. 이러한 아이덴티티는 적절한 문서화와 범위(scope)가 부족하여 위험도가 높고 발견하기도 어렵습니다.

2단계: 보안 프로비저닝 및 액세스 권한 할당

첫 번째 방어선은 프로비저닝 단계입니다. NHI가 어떻게 생성되었는지가 수명주기 전반에 걸친 위험 프로파일을 결정합니다. 문서화되어 있지 않고 명확한 소유자가 없는 과도한 권한을 가진 아이덴티티는, 탐지되지 않은 채 수년간 지속될 수 있는 리스크가 됩니다.

프로비저닝 모범 사례

생성 워크플로우를 표준화하세요: 모든 NHI는 미리 정의되어 반복 가능한 프로세스를 통해 생성되어야 하며, 액세스는 역할 기반 액세스 제어 또는 속성 기반 액세스 제어 모델과 일치해야 합니다. 즉, 서비스 계정, API 키, CI/CD 파이프라인 토큰과 같은 일반적인 ID 유형에 대해 승인된 템플릿을 구축하여 거버넌스 정책 외부에서 어떤 NHI도 환경에 들어오지 않도록 해야 합니다.

처음부터 최소 권한을 적용하세요: NHI 프로비저닝에서 가장 큰 위험 중 하나는 개발 단계에서 광범위한 액세스 권한을 부여했다가, 운영 단계에서 영구적으로 유지되게 되는 것입니다. 최소 권한 은 아이덴티티를 생성할 때 적용해야 합니다. 정확한 시스템 및 API 요구사항을 정의하고, 어떤 권한을 부여할지 신중하게 평가하며, 클라우드 IAM 정책에서 와일드카드 권한을 피하고, 최소 액세스부터 시작하세요.

소유권을 지정하세요: 모든 NHI는 명확한 소유권을 정립하기 위해 개인, 역할 또는 팀과 연결되어야 합니다. 소유권은 Change Management Database (CMDB) 및 IAM 플랫폼에서 정기적으로 업데이트되어야 하며, 필요한 변경 사항은 소유자와 상의하고 소유자의 승인을 받아야 합니다. 소유자가 조직을 떠나는 경우, 소유권은 즉시 재할당되어야 합니다.

만료일을 설정하세요: 많은 NHI는 일시적인 프로젝트, 마이그레이션, 테스트 환경, 벤더 통합, 단기 자동화 작업을 위해 생성되지만, 필요가 끝난 후 비활성화되는 경우는 거의 없습니다. 각 NHI에 시간 제한( Time to Live, TTL )을 할당하세요. 만료되면 소유자가 계속 필요로 하는지 검토해야 하며, 승인되지 않으면 해당 NHI는 시스템에서 자동으로 제거되어야 합니다.

피해야 할 프로비저닝(Provisioning) 함정

• 과도한 권한: 납기 압박 속에서 팀들은 “그냥 작동하게 하려고” 과도한 권한을 부여하는 경우가 흔합니다. 시스템이 제대로 작동하기 시작하면 과도한 권한은 거의 줄어들지 않으며, 숨겨진 권한 상승 경로를 만들어 수평 이동(lateral movement)의 기회가 되거나 심각한 컴플라이언스 위반으로 이어질 수 있습니다.
• 기존 NHI의 권한을 복사하기: 새 신원을 만들 때 승인된 방식이라고 가정하면 기존 신원에서 권한을 복사하는 것이 더 쉽습니다. 그러나 이는 공식적으로 승인된 적이 없는 오래되었거나 과도한 권한을 그대로 상속받는 문제 같은 것들을 만들어냅니다.
• 문서화와 소유권 없이 NHI를 생성하기: 문서 없이 NHI를 만들고 인벤토리가 업데이트되지 않으면, 보안 팀은 범위에 포함할 수 없고 위험 평가는 오래되어 버리며, 사고 대응이나 해제(또는 폐기) 계획도 없습니다.

3단계: 지속적인 모니터링과 행위 기반 감독

NHI가 프로비저닝되면 보안 작업은 여기서 끝나지 않습니다. 주기적으로 정적인 액세스 검토만 수행하는 것이 아니라, 권한이 어떻게 사용되는지, 시간이 지나면서 역할과 권한이 어떻게 변화하는지를 지속적으로 모니터링하는 방향으로 전환됩니다. 지속적인 모니터링을 통해 NHI가 수행하는 작업이 NHI가 수행해야 하는 작업과 일치하는지 확인할 수 있으며, 편차가 감지되면 조사와 대응 조치를 통해 그 편차가 사고로 이어지기 전에 중단할 수 있습니다.

모니터링할 항목

사용 패턴:NHI가 얼마나 자주, 어떤 맥락에서 작동하는지 이해하고 모니터링하는 것은 연결된 위험을 이해하기 위한 기반이 됩니다. NHI가 매일 활성 상태인가요, 아니면 주 또는 월의 마지막 며칠에만 활성 상태인가요? NHI가 시간당 100건의 요청을 처리하고 있다가 갑자기 10,000건으로 급증하는 원인은 무엇일까요? 일반적인 운영 시간대 밖에서 사용 빈도나 호출(콜)량이 급증한다면, 침해 또는 오용을 의미할 수 있습니다. 또한 NHI가 오랫동안 비활성 상태라면, 자격 증명이 해지되지 않은 채로 폐기(중단)된 서비스일 수 있습니다.

액세스 범위:NHI가 접근하는 대상(리소스, API, 데이터 저장소, 서비스 등)을 모니터링하는 것은 가시성을 확보하고 실제 런타임 동작이 의도된 액세스 설계와 일치하는지 확인하는 데 매우 중요합니다. NHI가 정상적으로 작동하더라도 과도한 액세스는 잠재적 위험이 될 수 있습니다. 액세스 범위에 대한 가시성에는 주기적인 액세스 검토, 역할 할당, 그리고 액세스 중요도에 기반한 위험 점수 산정이 포함되어야 합니다.

이상 징후 변화:모든 액세스 변경 사항, 특히 예상치 못했거나 승인되지 않은 변경은 보안 팀에 경고 신호가 되어야 합니다. 여기에는 새로운 역할 할당, 정책 첨부, 그룹 멤버십 변경, 또는 변경 관리 워크플로우에 포함되지 않았던 비밀(시크릿) 액세스 부여가 포함됩니다. NHI는 스스로 요청을 시작할 수 없으므로, 예기치 않은 액세스 변경은 악의적인 행위, 내부자 남용, 또는 자동화 오구성의 가능성으로 간주해야 하며 즉시 조사해야 합니다.

권한 드리프트: 시간이 지남에 따라 NHI는 서로 다른 작업 또는 임시 프로젝트에 대한 권한을 누적해, 원래 의도했던 것보다 더 많은 액세스 권한을 갖게 되는 경향이 있습니다. 흔한 원인으로는 프로젝트 범위의 확장, 문제 해결을 위해 추가했으나 제거되지 않은 임시 액세스, 복잡한 그룹 중첩으로 인한 역할 상속 변화 등이 있습니다. 권한 드리프트는 현재 권한을 기준 권한 템플릿과 비교하여 엄격하게 모니터링해야 합니다.

로깅 및 컴플라이언스

NHI 활동 로그는 선택 사항이 아닙니다. 이는 컴플라이언스 요구사항, 감사 준비, 그리고 사고 대응 측면에서 인간의 활동 로그만큼이나 중요합니다. PCI DSS, HIPAA, SOC 2, GDPR 같은 프레임워크는 사람 계정이든 비(非)인간 정체성이든 시스템 액세스에 대한 추적성, 책임성, 그리고 감사 로그를 요구합니다.

• 추적성: 모든 자동화된 작업은 소유권을 정할 수 있도록 특정 정체성에 귀속될 수 있어야 합니다.
• 감사 증적: 조직은 민감한 시스템에 누가 액세스했는지, 액세스가 언제 발생했는지, 어떤 작업이 수행되었는지, 그리고 액세스가 승인된 것이었는지를 입증할 수 있어야 합니다.
• 사고 조사: 보안 침해에 대한 포렌식 조사에서는 신원 로그가 자격 증명이 손상되었는지 여부를 판단하고, 측면 이동을 추적하며, 데이터 유출의 범위를 파악하고, 공격 이벤트를 재구성하기 위한 명확한 타임라인을 구축하는 데 도움이 됩니다.

4단계: 자격 증명 위험 관리

장기간 유지되는 시크릿은 비(非)인간 신원 보안에서 가장 위험한 요소 중 하나이며, 전반적인 시스템 차원의 리스크를 의미합니다. 비인간(NHI) 자격 증명은 정책에 의해 비밀번호 변경이 강제되고 MFA가 추가 보안 계층을 제공하는 사람의 자격 증명과 달리, 수개월 또는 심지어 수년 동안 그대로 유지되는 경우가 많습니다. 이러한 자격 증명이 유출되면 권한이 명시적으로 취소되거나 해당 신원이 삭제될 때까지, 공격에 즉시 활용 가능한 상태로 남습니다.

왜 로테이션이 중요한가

탐지되지 않은 노출: 자격 증명은 로그, 개발자 환경, 또는 정교한 기법 등을 통해 경고 없이 유출될 수 있습니다. 시크릿이 실수로 Git에 커밋되거나, 잘못 구성된 클라우드 스토리지 버킷을 통해 노출되거나, 메모리나 로그에서 추출되면, 공격자는 지속적인 액세스를 확보하고 조직은 이미 침해가 발생했는지조차 모르게 됩니다.

로테이션은 피해 범위를 제한합니다: 로테이션은 가능한 침해에 대한 시간 제한 역할을 합니다. 자격 증명을 자주 변경하면, 은밀하게 접근하던 공격자는 자동으로 권한이 회수됩니다. 예를 들어 키를 24시간마다 로테이션하면, 훔친 키는 다음 날에는 쓸모가 없어집니다. 15분 동안만 유효한 단기 토큰은 노출 시간을 15분으로만 제한합니다. 원칙은 간단합니다. 비밀이 오래 유지될수록, 탐지되지 않은 어떤 공격 경로를 통해 노출되었을 가능성이 더 커집니다.

컴플라이언스와 거버넌스: 최신 보안 및 컴플라이언스 프레임워크는 자격 증명 관리 통제를 명시적으로 요구하며, 더 이상 자격 증명 로테이션을 있으면 좋은 옵션이 아니라 필수 통제로 간주합니다. 감사(감사인)는 서비스 계정 자격 증명이 얼마나 자주 로테이션되는지, 로테이션이 자동화되어 있는지 여부, 비밀(시크릿)이 노출되면 어떤 일이 발생하는지에 대한 증빙을 필요로 합니다.

로테이션 모범 사례

로테이션 정책을 정의합니다: 수동 자격 증명 로테이션은 설계상 신뢰할 수 없습니다. 팀이 잊어버리거나, 명확한 책임 주체가 없을 수 있기 때문입니다. 공식적인 로테이션 정책에는 어떤 자격 증명을 로테이션해야 하는지, 자격 증명 유형별 최대 유효 기간, 로테이션의 소유자(책임자)가 누구인지, 어떤 도구를 사용해야 하는지가 정의되어야 합니다. 정책 기반 로테이션은 다양한 환경 전반에서 일관성을 보장하고, 명확한 감사 추적(이력)을 생성합니다.

로테이션 일정을 설정합니다: 모든 자격 증명이 동일한 위험을 갖는 것은 아니므로, 로테이션 주기도 그에 맞게 설정해야 합니다. 권한이 높은 서비스 계정은 매일 또는 매주 로테이션하고, 광범위한 권한을 가진 클라우드 API 키는 매주 또는 매월 로테이션하며, 사용자 액세스 토큰은 짧은 수명으로 유지해야 합니다(일이 아니라 분 단위로 유효). 목표는 로테이션을 주기적인 긴급 대응 통제가 아니라 백그라운드 프로세스로 만들자는 것입니다.

노출 징후에 즉시 대응: 회전(Rotation)은 시간 기반에만 그쳐서는 안 되며, 지속적인 모니터링을 바탕으로 이벤트 기반으로도 이루어져야 합니다. 조직은 침해가 의심되거나 확인되는 즉시 작동하는 자격 증명(credentials) 사고 대응 절차를 정의해 두어야 합니다. 노출이 감지되면 자동화된 프로세스가 손상된(침해된) 자격 증명을 즉시 폐기(철회)하고, 새 시크릿(secret)을 생성하며, 모든 종속 서비스에 이를 반영(업데이트)한 뒤, 관련 기록을 남기고 이해관계자에게 알림을 보내야 합니다.

5단계: 비(非)인간 ID의 폐기 및 오프보딩

폐기(Decommissioning)는 비(非)인간 ID 라이프사이클에서 가장 소홀히 다뤄지는 단계인 경우가 많습니다. 조직이 프로비저닝과 모니터링에 집중하는 동안, NHI 퇴직(은퇴, retirement)은 대체로 비공식 캠페인 기간에 이루어지거나 아예 이루어지지 않는 경우가 많습니다. 그 결과, 수많은 고아(Orphaned) NHI가 유령 계정(ghost accounts) 형태로 시스템에 그대로 남아 숨겨진 공격 표면을 만들어냅니다.

폐기를 위한 NHI 식별

효과적인 폐기(Decommissioning)는 가시성(visibility)에서 시작됩니다. 조직은 더 이상 존재해서는 안 되는 NHI를 사전에(선제적으로) 탐지해야 합니다.

사용하지 않는 ID(계정): 많은 NHIs는 단기 프로젝트, 임시 통합, 테스트 환경 또는 마이그레이션 계획을 위해 생성됩니다. 이러한 프로젝트가 종료되면, 해당 NHIs는 유효한 자격 증명(credential)과 함께 시스템에 그대로 남아 있을 수 있습니다. 예를 들어 정의된 기간(30일, 60일 또는 90일) 동안 인증 이벤트가 전혀 발생하지 않는지 등을 기준으로, NHI가 더 이상 사용되지 않는 시점을 판단하는 정책이 필요합니다.

고아(오너 없는) ID(계정): NHIs는 소유자 또는 담당 팀이 조직을 떠나거나 다른 프로젝트로 재배정되거나, NHI가 생성되었던 애플리케이션이 NHI 정리(NHI cleanup) 없이 폐기되는 경우에 고아 상태가 됩니다. 소유자가 없으면 접근 권한을 검토하거나, 자격 증명을 주기적으로 교체(rotate)하거나, 비정상 활동을 모니터링할 사람이 없습니다. 고아 ID는 시스템 내에서는 합법적으로 보이지만 감독(오버사이트)이 전혀 없기 때문에 특히 위험합니다.

중복된 ID(계정): 분산형 DevOps 환경에서는 여러 팀이 동일한 작업을 위해 각기 다른 ID를 생성할 수 있습니다. 그 결과 중복된 서비스 계정, API 키의 중첩, 또는 유사한 접근 권한을 가진 여러 자격 증명(credential)이 생길 수 있습니다. 중복된 ID는 감사(로그) 기록을 유지하기가 더 어려워지고, 한 ID의 접근을 해제해도 접근 위험이 완전히 제거되지 않기 때문에 복잡성과 위험을 증가시킵니다.

안전한 폐기(데커미ショニング) 프로세스

NHI를 신중한 검증 없이 제거하는 것 자체가 하나의 위험입니다. 운영 환경에서 애플리케이션이나 의존 서비스가 중단될 수 있습니다. 폐기(데커미쇼닝) 프로세스는 체계적인 방식으로 수행해야 합니다.

1. 식별 및 프로파일링: 자동화된 검색(디스커버리) 도구를 사용해 비활성 상태이거나 유효한 소유자가 없는 경우, 연결된 애플리케이션 또는 서비스가 더 이상 사용되지 않는 경우, 또는 NHI가 중복된 정체성(다중/중복 ID)으로 확인된 경우를 기준으로 정체성을 표시(플래그)합니다. 식별된 NHIs는 애플리케이션 소유자, 보안, DevOps 팀에 검토를 위해 전달해야 합니다.
2. 의존성(데펜던시) 검증: NHI를 비활성화하거나 삭제하기 전에, 해당 NHI가 백그라운드 작업, 예약된 자동화 작업, 제3자 연동, 재해 복구 프로세스, 레거시 시스템을 실제로 지원하고 있지 않은지 확인합니다. 의존성 점검에는 인증 로그 검토, CI/CD 구성 확인, 인프라스트럭처-에스-코드(infrastructure-as-code) 템플릿 스캔, 애플리케이션 소유자와의 협의가 필요합니다.
3. 삭제 전 비활성화: 즉시 삭제하지 마세요. 모범 사례는 단계적으로 제거하는 것입니다. 먼저 인증 기능을 비활성화하고, 실패 또는 시스템 오류가 발생하는지 모니터링한 뒤, 정해진 유예 기간(7~30일)을 허용합니다. 영향이 없다면 영구 삭제합니다. 이를 통해 팀이 잠재적 영향을 검증할 수 있고, 신속한 롤백도 가능해집니다.
4. 감사 목적의 제거 기록: 모든 폐기(디커미셔닝) 단계가 완료되면 하드 삭제를 수행하고, 감사 추적을 위해 이 작업이 SIEM 플랫폼 로그에 기록되도록 합니다. 고유 식별자가 포함된 해당 정체성의 이름, 연결된 시스템 및 권한, 제거 사유, 검토 및 승인 워크플로우 상세, 삭제 날짜 등 필요한 정보를 문서로 남기세요.

NHI 라이프사이클 관리에서 흔히 발생하는 함정

Netwrix가 NHI 라이프사이클 관리를 지원하는 방법

Netwrix Identity Manager 단일 플랫폼에서 자동화된 라이프사이클 프로세스로 사람 계정과 비(非)인간 정체성(Non-human identities)을 모두 관리하는 포괄적인 ID 거버넌스 및 관리(IGA) 프레임워크를 제공합니다. Netwrix Identity Manager는 모든 정체성 유형을 포함하는 중앙 집중식 정체성 저장소를 구축하여, 통합 인벤토리를 만들고 이것이 정체성 라이프사이클 관리를 위한 기반이 됩니다.

검색 및 인벤토리: NHIs를 포함한 모든 유형의 ID가 중앙 집중식 Identity manager 저장소로 동기화되어 가시성을 제공하고 ID 스프롤을 줄입니다. 커넥터는 서로 다른 디렉터리(Active Directory, Microsoft Entra ID)와 비즈니스 애플리케이션에서 ID 및 엔터틀먼트 데이터를 가져와, 사람의 ID와 함께 NHIs도 거버넌스 범위에 포함되도록 합니다.

통제된 프로비저닝: 모든 정체성에 대해 표준화된 프로비저닝 워크플로가 정의되어, 과도한 권한을 동반한 임시(애드혹) 프로비저닝을 줄입니다. 정체성 생성 요청이 들어오면 정책 기반 워크플로가 트리거되어 최소 권한 원칙을 적용, 정체성 역할에 필요한 접근 권한만 프로비저닝합니다. 역할 기반 접근 제어(RBAC)는 정체성이 자신의 기능에 적절한 권한만 받도록 보장합니다.

지속적인 모니터링 및 검토: Netwrix Identity Manager는 관리하는 모든 정체성에 대해 권한(Entitlements), 변경 이벤트, 그리고 컴플라이언스 상태를 추적합니다. 또한 내장된 액세스 인증 캠페인 기능을 제공하며, 위험 분석을 통해 NHIs가 과도한 권한을 축적하는 시점을 감지하고 액세스 패턴 및 리소스 사용량을 모니터링합니다. 이 제품은 사람이든 비사람이든(예: 서비스 계정/비인간 정체성) 활동이 없거나 고아가 된 정체성, 권한 확산(privilege creep), 그리고 직무분리(Segregation of Duties) 위반을 탐지하는 데 도움을 줍니다.

권한 복구 및 정리: Netwrix Identity Manager를 통해 조직은 각 정체성의 권한을 정책 규칙과 비교해 분석할 수 있습니다. 더 이상 액세스가 필요하지 않거나 정책이 허용하는 범위를 초과하는 권한을 가진 NHIs는 복구 대상(리메디에이션)으로 플래그를 지정할 수 있습니다. 또한 90일(예: 90일) 같은 특정 기간 동안 로그인하지 않은 사용하지 않는 계정, 소유자가 존재하지 않는 고아 NHIs, 또는 액세스 인증 중에 드러난 과도한 권한을 식별하기 위한 규칙을 정의할 수 있습니다.

라이프사이클 종료: Netwrix Identity Manager는 조이너-무버-리버러(Joiner-mover-leaver, JML) 프로세스를 수용하는 포괄적인 워크플로를 통해 프로비저닝, 업데이트, 그리고 디프로비저닝 단계를 자동화합니다. 애플리케이션이나 서비스가 퇴역(중단)되거나, 프로젝트가 종료되거나, 사람이 소유자가 퇴사하거나 다음 프로젝트로 이동하는 경우 Netwrix Identity Manager는 연결된 NHIs의 권한이 회수(revoked)되고 결국 삭제(deleted)되도록 보장합니다.

결론: 아이덴티티 스프롤(sprawl)에서 라이프사이클 제어로

현대 IT 인프라에서 비인간(Non-human) 아이덴티티는 지배적인 아이덴티티 유형이 되었으며 사라지지 않고 있습니다. 이들은 기하급수적으로 늘어나고 있습니다. 새로운 자동화 메커니즘, 클라우드 워크로드, 그리고 AI 에이전트가 모두 계속 커지는 NHI(NHI) 규모에 더해집니다. 모놀리식 애플리케이션 설계에서 마이크로서비스로 전환되면서, 다른 서비스와 통신하는 각 하위 서비스마다 여러 아이덴티티가 필요해졌습니다. 가상 머신, 서버리스 함수, 컨테이너, 관리형 서비스 같은 클라우드 워크로드도 모두 더 많은 NHI를 요구합니다. DevOps 파이프라인은 서비스 프린서플, 배포 토큰, Git 통합, API 자격 증명, 빌드 에이전트에 크게 의존합니다. 현재 NHI는 인간 아이덴티티를 10대 1의 비율로 앞지르고 있으며, 그 비율은 계속 상승하고 있습니다.

NHI 라이프사이클 관리는 늘어나는 위험인 NHIs를 관리되는 자산(자산 클래스)으로 전환하고, 조직이 NHIs가 지니는 규모와 영향에 맞춰 보다 효과적인 통제로 이를 관리할 수 있도록 합니다. 각 단계(검색, 프로비저닝, 모니터링, 로테이션, 폐기/종료)를 다룸으로써 조직은 아이덴티티 스프롤을 줄이고, 최소 권한을 강제하며, 전통적인 IAM이 NHIs에 대해 해결하지 못하는 보안 격차를 메울 수 있습니다.