퇴사자·프로젝트 종료 후에도 살아있는 ‘좀비 NHI’ 수두룩
정적 시크릿 의존하는 구조적 한계 극복해야
[보안뉴스= 김동현 OWASP 서울 챕터 리더] 보안의 사각지대에 있던 API 키, 서비스 계정 등 ‘비인간 신원(NHI·Non-Human Identities)’은 해커들의 ‘가성비’ 높은 통로가 되고 있다. 지난해 OWASP는 NHI 보안 위협을 2025년 Top 10으로 선정했다. 해당 발표는 NHI 보안 위협을 체계적으로 정리한 최초의 프레임워크이자. 그동안 보안 업계가 외면해온 거대한 사각지대를 공식적으로 인정했다.
NHI란 무엇인가?
'NHI'는 사람이 아닌 주체가 시스템에 접근할 때 사용하는 ‘디지털 자격증명’을 말한다. API 키나 서비스 계정, OAuth 토큰, 인증서, SSH 키, 데이터베이스 연결 문자열, 암호화 키 등이 모두 NHI에 해당한다.
우리가 매일 사용하는 시스템 뒤단에는 수많은 NHI가 작동한다. 백엔드 서버가 데이터베이스에 접속할 때나 마이크로 서비스들이 통신할 때, CI/CD 파이프라인이 클라우드에 배포할 때, 외부 SaaS와 연동될 때. 이 모든 순간에 NHI 인증이 작동한다. 사람이 로그인할 때 ID와 비밀번호를 입력하듯, 시스템은 NHI를 통해 ‘나는 접근 권한이 있는 정당한 주체’임을 증명한다.
클라우드 보안 연합(CSA)의 2024년 보고서에 따르면, NHI는 인간 계정 대비 45배에서 100배 이상 존재한다. 하지만 NHI 관련 보안에 자신감을 보인 조직은 단 15%에 불과했다. 69%는 NHI 공격에 대한 우려를, API 키 오프보딩 프로세스를 갖춘 조직은 20%에 그쳤다. 게다가 대다수 기업은 자사의 NHI의 30% 정도만 파악하고 있다는 점이다. 나머지 70%는 관리 사각지대에 방치되어 있다.
NHI는 왜 다른가
NHI 보안이 어려운 근본적 이유는 일반적인 사람들의 계정과 다른 본질적인 차이 때문이다.
첫째, 다중 인증(MFA·Multi-Factor Authentication)을 적용할 수 없다. 사람은 OTP나 생체인증 등 추가 인증 수단을 사용하지만 서비스 계정이나 API 키는 정적인 시크릿(Secret)에 의존할 수밖에 없다. 이 시크릿이 유출되면 별도의 방어선 없이 시스템 접근이 가능해진다. 회사 대표의 비밀번호가 유출돼도 MFA가 막아주지만, 클라우드 전체 관리 권한을 가진 API 키 하나가 유출되면 기업의 존립 자체가 위태로워질 수 있다.
둘째, 규모와 분산성의 문제다. NHI는 개발팀과 인프라팀, 외부 벤더 등이 클라우드·SaaS·온프레미스 등 다양한 환경에서 분산 생성된다. 최근 AI 서비스 확산으로 상황은 더욱 복잡해졌다. 챗GPT나 클로드, 제미나이 같은 AI 도구에 외부 서비스를 연동하려면 API 키가 필요하고, 이제는 개발자가 아닌 일반 직원도 업무 자동화를 위해 NHI를 생성하는 시대가 됐다.
셋째, 소유권이 불분명하다. 일반적인 인간 계정은 IDP(Identity Provider)와 HR 시스템이 연동되어 입사부터 퇴사까지 생애주기가 관리된다. 하지만 NHI는 이 체계 밖에 있다. API 키를 누가 만들었고, 왜 만들었는지, 지금도 사용 중인지 등 아무도 모르는 경우가 허다하다. 담당자가 퇴사하거나 프로젝트가 종료되도 NHI는 활성 상태로 남아 ‘좀비 ID’가 된다.
보안팀의 구조적 딜레마
NHI 보안의 가장 큰 장벽은 기술이 아니다. 조직 내 ‘영역’의 문제다.
보안팀은 전통적으로 AD, IAM, SSO, MFA 등 인간 계정을 관리했다. 반면 NHI는 개발팀이 애플리케이션 구축 과정에서 생성한다. 데이터베이스 연결 문자열이나 외부 API 호출 키, 마이크로서비스 간 토큰까지. 이러한 자격증명은 애플리케이션 동작에 필수적이라 보안팀이 함부로 손대기 힘들다. 서비스 장애까지 이어질 수 있기 때문이다. 이 때문에 NHI의 주된 활동 무대는 ‘보안팀이 볼 수 없는’ 감춰진 영역으로 남는다.
OWASP NHI Top 10은 이러한 위험을 구체적으로 정리했다. 서비스 폐기 후에도 NHI가 방치되는 ‘부적절한 오프보딩’이나 소스코드나 설정 파일에 평문으로 저장되는 ‘시크릿 유출’, 필요 이상의 권한을 가진 ‘과도한 권한’. 만료 기간 없이 운영되는 ‘장기 유효 시크릿’ 등이 핵심 위험 요소로 꼽힌다.
해외 사례로 살펴본 NHI 침해
공격자들은 이미 이 사각지대를 정조준하고 있다.
지난 2022년 우버(Uber)는 파워셀 스크립트 내 하드코딩된 관리자 자격증명 하나가 유출되면서 사내 시스템 전체에 접근할 수 있었고, AWS 콘솔까지 침투를 허용했다. 우버는 이 사고로 1년 반 동안 사내 모든 쉐도우 NHI를 찾는 전수조사를 진행했다.
지난해에는 대형 침해가 연이어 터졌다. 1월 마이크로소프트는 관리되지 않았던 레거시 OAuth 앱을 통해 러시아 해커의 침투를 허용했다. 테스트 테넌트(Test Tenant)에서 시작된 공격은 과도한 권한을 가진 NHI를 통해 프로덕션까지 확대됐다. 5월 스노우플레이크(Snowflake)에서는 약 165개 고객사 인스턴스가 침해당했다. 이 중에는 티켓마스터나 산탄데르 은행 같은 초대형 고객사 데이터가 영향을 받았다. 12월에는 비욘드트러스트(BeyondTrust)의 API 키 침해가 미국 재무부 시스템까지 영향을 줬다.
이들 사건의 공통점은 명확하다. 공격자들이 제로데이나 정교한 기술을 사용한 것이 아닌, 관리되지 않고 과도한 권한을 가진 NHI를 통해 ‘정문’으로 당당히 걸어서 들어갔다.
AI 에이전트의 확장, NHI 위협도 늘어
NHI 위협은 AI 에이전트 확산으로 새로운 국면에 접어들었다. 특히 모델 컨텍스트 프로토콜(MCP)의 급속한 확산에 주목할 필요가 있다, MCP는 AI 모델이 깃허브나 지라, 슬랙 등 외부 시스템과 상호 작용하는 방식을 표준화한 프로토콜이기 때문이다.
여기서 중요한 지점은 MCP 서버가 외부 시스템에 접근하기 위해 사용하는 것이 NHI라는 점이다. 깃허브의 API 키, 지라의 OAuth 토큰, 슬랙 봇 토큰 등이 MCP 서버에서 AI 에이전트의 권한을 부여한다. 문제는 이 NHI들이 mcp.json 같은 설정 파일에 평문으로 저장된 경우가 많고, OAuth 대신 만료 없는 정적 API 키에 의존한다는 것이다. 전동적인 NHI 문제가 AI 에이전트 환경에서 그대로 재현되고 있다.
2025년 5월과 6월 인베리언트랩(Invariant Labs)과 카토네트웍스(Cato Networks)가 프롬프트 인젝션을 통한 데이터 유출 개념증명(PoC)을 공개했다. 여기서 주목할 점은 공격이 성공한 원인이다. 프롬프트 인젝션은 공격 벡터였지만, 실제 피해를 만든 건 MCP 서버에 있던 NHI가 과도한 권한을 가지고 있었기 때문이다. 만약 특정 저장소에만 접근할 수 있는 토큰을 사용했다면 피해는 제한적이었을 것이다.
다행인 점은 실제 침해로 이어진 사례는 발견되지 않았단 점이다. 그럼에도 PoC들이 보여주는 교훈은 분명하다. AI 에이전트 환경에서도 NHI에 최소 권한 원칙을 적용하고, 정기적으로 권한을 검토해야 한다는 것이다.
현실적인 NHI 위협 해결 방안
현장에서 가장 많이 들리는 이야기는 “키 로테이션이 현실적으로 불가능하다”는 내용이다. 그러나 로테이션보다 더 급한 문제가 있다. “지금 어떤 키를 어디에 쓰고 있는지”를 확인하는 가시성 확보다.
우버가 침해 이후 1년 반을 투자한 만큼 NHI는 IT 자산처럼 관리대장화 하는 것이 첫걸음이다. 어떤 서비스 계정이 있는지, 누가 생성했는지, 언제 마지막으로 사용됐는지, 어떤 권한을 가지고 있는지, 이것이 파악돼지 않으면 어떤 정책도 세울 수 없다.
다음으로 시크릿 관리 체계 도입이다. 소스코드나 설정 파일에 하드코딩된 시크릿을 시크릿 매니저(Secret Manager)로 이전한다. 단, 해당 매니저에 접근하기 위한 자격증명은 여전히 필요하므로, 이 접근 권한을 최소화하고 감사 로그를 남기는 작업이 함께 진행되야 한다.
로테이션이 어려운 암호화 키는 봉투 암호화(Envelope Encryption) 구조 도입을 검토할 수 있다. 데이터 암호화 키(DEK)를 별도의 키 암호화 키(KEK)로 감싸는 방식이다. KEK만 주기적으로 교체하면 전체 데이터 재암호화 없이 보안성을 유지할 수 있다.
궁극적으로는 정적인 장기 자격증명 자체를 줄여나가는 방향, 이른바 ‘키리스 아키텍처’(Keyless Architecture)로의 전환을 고려해야 한다. AWS의 IAM Role Anywhere나 깃허브 Actions의 OIDC 연동처럼, 필요한 순간에만 짧은 유효기간의 자격증명을 발급받는 구조다. 저장된 키가 없어 유출될 키가 없다.
NHI는 더 이상 “나중에 챙기면 되는” 영역이 아니다. OWASP가 Top 10을 발표하고, 마이크로소프트와 스노우플레이크, 우버 같은 글로벌 기업들이 잇따라 침해 당한 점은 이 위협이 ‘현재진행형’이라는 강력한 방증이다.
보안팀이 손댈 수 없었던 영역, 개발팀이 보안을 고려하지 않았던 영역. 이제 경계를 허물고, NHI를 보안 전략의 핵심 축으로 가져와야 할 시점이다.
[글_ 김동현 OWASP 서울 챕터 리더]
필자 소개_
- OWASP 서울 챕터 리더
- 화이트햇스쿨 멘토
- 크리밋 대표이사
정적 시크릿 의존하는 구조적 한계 극복해야
[보안뉴스= 김동현 OWASP 서울 챕터 리더] 보안의 사각지대에 있던 API 키, 서비스 계정 등 ‘비인간 신원(NHI·Non-Human Identities)’은 해커들의 ‘가성비’ 높은 통로가 되고 있다. 지난해 OWASP는 NHI 보안 위협을 2025년 Top 10으로 선정했다. 해당 발표는 NHI 보안 위협을 체계적으로 정리한 최초의 프레임워크이자. 그동안 보안 업계가 외면해온 거대한 사각지대를 공식적으로 인정했다.
NHI란 무엇인가?
'NHI'는 사람이 아닌 주체가 시스템에 접근할 때 사용하는 ‘디지털 자격증명’을 말한다. API 키나 서비스 계정, OAuth 토큰, 인증서, SSH 키, 데이터베이스 연결 문자열, 암호화 키 등이 모두 NHI에 해당한다.
우리가 매일 사용하는 시스템 뒤단에는 수많은 NHI가 작동한다. 백엔드 서버가 데이터베이스에 접속할 때나 마이크로 서비스들이 통신할 때, CI/CD 파이프라인이 클라우드에 배포할 때, 외부 SaaS와 연동될 때. 이 모든 순간에 NHI 인증이 작동한다. 사람이 로그인할 때 ID와 비밀번호를 입력하듯, 시스템은 NHI를 통해 ‘나는 접근 권한이 있는 정당한 주체’임을 증명한다.
클라우드 보안 연합(CSA)의 2024년 보고서에 따르면, NHI는 인간 계정 대비 45배에서 100배 이상 존재한다. 하지만 NHI 관련 보안에 자신감을 보인 조직은 단 15%에 불과했다. 69%는 NHI 공격에 대한 우려를, API 키 오프보딩 프로세스를 갖춘 조직은 20%에 그쳤다. 게다가 대다수 기업은 자사의 NHI의 30% 정도만 파악하고 있다는 점이다. 나머지 70%는 관리 사각지대에 방치되어 있다.
[자료: 생성형 AI 이미지]
NHI는 왜 다른가
NHI 보안이 어려운 근본적 이유는 일반적인 사람들의 계정과 다른 본질적인 차이 때문이다.
첫째, 다중 인증(MFA·Multi-Factor Authentication)을 적용할 수 없다. 사람은 OTP나 생체인증 등 추가 인증 수단을 사용하지만 서비스 계정이나 API 키는 정적인 시크릿(Secret)에 의존할 수밖에 없다. 이 시크릿이 유출되면 별도의 방어선 없이 시스템 접근이 가능해진다. 회사 대표의 비밀번호가 유출돼도 MFA가 막아주지만, 클라우드 전체 관리 권한을 가진 API 키 하나가 유출되면 기업의 존립 자체가 위태로워질 수 있다.
둘째, 규모와 분산성의 문제다. NHI는 개발팀과 인프라팀, 외부 벤더 등이 클라우드·SaaS·온프레미스 등 다양한 환경에서 분산 생성된다. 최근 AI 서비스 확산으로 상황은 더욱 복잡해졌다. 챗GPT나 클로드, 제미나이 같은 AI 도구에 외부 서비스를 연동하려면 API 키가 필요하고, 이제는 개발자가 아닌 일반 직원도 업무 자동화를 위해 NHI를 생성하는 시대가 됐다.
셋째, 소유권이 불분명하다. 일반적인 인간 계정은 IDP(Identity Provider)와 HR 시스템이 연동되어 입사부터 퇴사까지 생애주기가 관리된다. 하지만 NHI는 이 체계 밖에 있다. API 키를 누가 만들었고, 왜 만들었는지, 지금도 사용 중인지 등 아무도 모르는 경우가 허다하다. 담당자가 퇴사하거나 프로젝트가 종료되도 NHI는 활성 상태로 남아 ‘좀비 ID’가 된다.
보안팀의 구조적 딜레마
NHI 보안의 가장 큰 장벽은 기술이 아니다. 조직 내 ‘영역’의 문제다.
보안팀은 전통적으로 AD, IAM, SSO, MFA 등 인간 계정을 관리했다. 반면 NHI는 개발팀이 애플리케이션 구축 과정에서 생성한다. 데이터베이스 연결 문자열이나 외부 API 호출 키, 마이크로서비스 간 토큰까지. 이러한 자격증명은 애플리케이션 동작에 필수적이라 보안팀이 함부로 손대기 힘들다. 서비스 장애까지 이어질 수 있기 때문이다. 이 때문에 NHI의 주된 활동 무대는 ‘보안팀이 볼 수 없는’ 감춰진 영역으로 남는다.
OWASP NHI Top 10은 이러한 위험을 구체적으로 정리했다. 서비스 폐기 후에도 NHI가 방치되는 ‘부적절한 오프보딩’이나 소스코드나 설정 파일에 평문으로 저장되는 ‘시크릿 유출’, 필요 이상의 권한을 가진 ‘과도한 권한’. 만료 기간 없이 운영되는 ‘장기 유효 시크릿’ 등이 핵심 위험 요소로 꼽힌다.
해외 사례로 살펴본 NHI 침해
공격자들은 이미 이 사각지대를 정조준하고 있다.
지난 2022년 우버(Uber)는 파워셀 스크립트 내 하드코딩된 관리자 자격증명 하나가 유출되면서 사내 시스템 전체에 접근할 수 있었고, AWS 콘솔까지 침투를 허용했다. 우버는 이 사고로 1년 반 동안 사내 모든 쉐도우 NHI를 찾는 전수조사를 진행했다.
지난해에는 대형 침해가 연이어 터졌다. 1월 마이크로소프트는 관리되지 않았던 레거시 OAuth 앱을 통해 러시아 해커의 침투를 허용했다. 테스트 테넌트(Test Tenant)에서 시작된 공격은 과도한 권한을 가진 NHI를 통해 프로덕션까지 확대됐다. 5월 스노우플레이크(Snowflake)에서는 약 165개 고객사 인스턴스가 침해당했다. 이 중에는 티켓마스터나 산탄데르 은행 같은 초대형 고객사 데이터가 영향을 받았다. 12월에는 비욘드트러스트(BeyondTrust)의 API 키 침해가 미국 재무부 시스템까지 영향을 줬다.
이들 사건의 공통점은 명확하다. 공격자들이 제로데이나 정교한 기술을 사용한 것이 아닌, 관리되지 않고 과도한 권한을 가진 NHI를 통해 ‘정문’으로 당당히 걸어서 들어갔다.
AI 에이전트의 확장, NHI 위협도 늘어
NHI 위협은 AI 에이전트 확산으로 새로운 국면에 접어들었다. 특히 모델 컨텍스트 프로토콜(MCP)의 급속한 확산에 주목할 필요가 있다, MCP는 AI 모델이 깃허브나 지라, 슬랙 등 외부 시스템과 상호 작용하는 방식을 표준화한 프로토콜이기 때문이다.
여기서 중요한 지점은 MCP 서버가 외부 시스템에 접근하기 위해 사용하는 것이 NHI라는 점이다. 깃허브의 API 키, 지라의 OAuth 토큰, 슬랙 봇 토큰 등이 MCP 서버에서 AI 에이전트의 권한을 부여한다. 문제는 이 NHI들이 mcp.json 같은 설정 파일에 평문으로 저장된 경우가 많고, OAuth 대신 만료 없는 정적 API 키에 의존한다는 것이다. 전동적인 NHI 문제가 AI 에이전트 환경에서 그대로 재현되고 있다.
2025년 5월과 6월 인베리언트랩(Invariant Labs)과 카토네트웍스(Cato Networks)가 프롬프트 인젝션을 통한 데이터 유출 개념증명(PoC)을 공개했다. 여기서 주목할 점은 공격이 성공한 원인이다. 프롬프트 인젝션은 공격 벡터였지만, 실제 피해를 만든 건 MCP 서버에 있던 NHI가 과도한 권한을 가지고 있었기 때문이다. 만약 특정 저장소에만 접근할 수 있는 토큰을 사용했다면 피해는 제한적이었을 것이다.
다행인 점은 실제 침해로 이어진 사례는 발견되지 않았단 점이다. 그럼에도 PoC들이 보여주는 교훈은 분명하다. AI 에이전트 환경에서도 NHI에 최소 권한 원칙을 적용하고, 정기적으로 권한을 검토해야 한다는 것이다.
현실적인 NHI 위협 해결 방안
현장에서 가장 많이 들리는 이야기는 “키 로테이션이 현실적으로 불가능하다”는 내용이다. 그러나 로테이션보다 더 급한 문제가 있다. “지금 어떤 키를 어디에 쓰고 있는지”를 확인하는 가시성 확보다.
우버가 침해 이후 1년 반을 투자한 만큼 NHI는 IT 자산처럼 관리대장화 하는 것이 첫걸음이다. 어떤 서비스 계정이 있는지, 누가 생성했는지, 언제 마지막으로 사용됐는지, 어떤 권한을 가지고 있는지, 이것이 파악돼지 않으면 어떤 정책도 세울 수 없다.
▲김동현 OWASP 서울 챕터 리더
로테이션이 어려운 암호화 키는 봉투 암호화(Envelope Encryption) 구조 도입을 검토할 수 있다. 데이터 암호화 키(DEK)를 별도의 키 암호화 키(KEK)로 감싸는 방식이다. KEK만 주기적으로 교체하면 전체 데이터 재암호화 없이 보안성을 유지할 수 있다.
궁극적으로는 정적인 장기 자격증명 자체를 줄여나가는 방향, 이른바 ‘키리스 아키텍처’(Keyless Architecture)로의 전환을 고려해야 한다. AWS의 IAM Role Anywhere나 깃허브 Actions의 OIDC 연동처럼, 필요한 순간에만 짧은 유효기간의 자격증명을 발급받는 구조다. 저장된 키가 없어 유출될 키가 없다.
NHI는 더 이상 “나중에 챙기면 되는” 영역이 아니다. OWASP가 Top 10을 발표하고, 마이크로소프트와 스노우플레이크, 우버 같은 글로벌 기업들이 잇따라 침해 당한 점은 이 위협이 ‘현재진행형’이라는 강력한 방증이다.
보안팀이 손댈 수 없었던 영역, 개발팀이 보안을 고려하지 않았던 영역. 이제 경계를 허물고, NHI를 보안 전략의 핵심 축으로 가져와야 할 시점이다.
[글_ 김동현 OWASP 서울 챕터 리더]
필자 소개_
- OWASP 서울 챕터 리더
- 화이트햇스쿨 멘토
- 크리밋 대표이사
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
조재호기자 기사보기
.jpg)
