티스토리 뷰

정보보안/Cloud

OWASP NHI Top 10 한 번에 정리 | 비인간 신원 실제 사례

실더 2026. 10. 27. 18:00

📌 3줄 요약

1. NHI(비인간 신원)는 API 키, 서비스 계정, OAuth 토큰처럼 사람이 아닌 프로그램이 쓰는 계정입니다. 조사마다 차이는 있지만 사람 계정보다 수십 배 많습니다.

2. OWASP NHI Top 10은 이 계정들에서 생기는 10대 위험을 정리한 첫 공식 목록입니다. 1위는 '다 쓴 계정을 지우지 않는 것(부적절한 폐기)'입니다.

3. 대응의 뼈대는 하나입니다. 찾고 → 주인을 정하고 → 권한을 줄이고 → 수명을 짧게 → 안 쓰면 바로 폐기.

혹시 2~3년 전에 테스트용으로 만든 API 키, 지금도 살아 있지 않나요?

퇴사한 동료가 만든 배포용 서비스 계정, 마케팅팀이 연결해 둔 외부 SaaS 토큰은요? 이런 계정은 비밀번호 정책도, MFA도, 퇴사 절차도 거치지 않습니다. 그래서 공격자에게는 사람 계정보다 훨씬 '가성비 좋은' 출입문이 됩니다.

이 글에서는 OWASP NHI Top 10의 10가지 항목을 정의 → 쉬운 예시 → 실제 사고 → 막는 법 순서로 하나씩 풀어 보겠습니다.

🧭 NHI(비인간 신원)란 무엇인가

OWASP는 NHI를 애플리케이션, 워크로드, API, 봇, 자동화 시스템 같은 소프트웨어가 자원에 접근할 때 쓰는 신원으로 정의합니다. 사람이 아이디·비밀번호로 로그인하듯, 프로그램은 키·토큰·인증서로 로그인합니다.

문제는 NHI가 사람 계정과 성격이 전혀 다르다는 점입니다. 사람에게 당연히 적용하던 보안 장치가 NHI에는 잘 적용되지 않습니다.

유형 이런 것들이 NHI입니다
서비스 계정 백엔드 시스템끼리 연결할 때 쓰는 계정 (DB 접속 계정, 배치 작업 계정 등)
API 키·토큰 마이크로서비스가 DB나 외부 API를 호출할 때 쓰는 키, 접근 토큰
클라우드 역할 자동화 서비스가 클라우드 자원에 접근할 때 부여받는 역할(Role)
OAuth 앱 외부 SaaS를 사내 메일·CRM·드라이브에 연결할 때 승인하는 앱과 그 토큰
인증서·키 서버 간 통신용 인증서, 암호화 키, SSH 키

규모도 큽니다. 업계 조사에 따라 사람 계정의 10~50배, 많게는 100배 안팎으로 추정됩니다. 보안뉴스에 실린 OWASP 서울 챕터 칼럼은 이런 NHI를 퇴사·프로젝트 종료 뒤에도 살아 있는 '좀비 NHI'라고 표현하기도 했습니다.

🧭 OWASP NHI Top 10 한눈에 보기

OWASP NHI Top 10은 2024년 12월 24일 공개된 '2025'판이 현재 최신입니다(2026년 10월 확인 기준). 순위는 악용 난이도, 확산 정도, 탐지 난이도, 영향도를 기준으로 매겼습니다.

코드 위험 한 줄 설명
NHI1 부적절한 폐기
Improper Offboarding		 안 쓰는 계정·키를 지우지 않고 방치
NHI2 시크릿 유출
Secret Leakage		 키·토큰이 코드, 설정 파일, 메신저에 노출
NHI3 취약한 서드파티 NHI
Vulnerable Third-Party NHI		 외부 SaaS·IDE 확장에 준 권한이 그쪽 침해로 악용
NHI4 안전하지 않은 인증
Insecure Authentication		 낡거나 약한 인증 방식 사용
NHI5 과도한 권한
Overprivileged NHI		 하는 일보다 훨씬 큰 권한 부여
NHI6 클라우드 배포 설정 미흡
Insecure Cloud Deployment Configurations		 CI/CD의 정적 키 노출, OIDC 조건 누락
NHI7 장기 시크릿
Long-Lived Secrets		 만료가 없거나 너무 먼 키·토큰
NHI8 환경 분리 실패
Environment Isolation		 테스트와 운영이 같은 NHI를 공유
NHI9 NHI 재사용
NHI Reuse		 여러 서비스가 하나의 NHI를 같이 사용
NHI10 사람의 NHI 사용
Human Use of NHI		 사람이 수작업에 서비스 계정을 사용

10개를 따로 외우기보다 NHI가 태어나서 사라질 때까지의 수명주기에 올려 보면 훨씬 쉽게 정리됩니다. 아래 그림은 이해를 돕기 위해 필자가 분류한 것으로, OWASP 공식 분류는 아닙니다.

🔐 10대 위험, 실제 사고로 이해하기

각 항목은 '정의 → 쉬운 예시 → 실제 사례 → 막는 법' 순서로 정리했습니다. 공개 사고가 없는 항목은 일반화한 가상 예시로 설명합니다.

NHI1. 부적절한 폐기 (Improper Offboarding)

더 이상 필요 없는 서비스 계정이나 접근 키를 비활성화·삭제하지 않고 남겨 두는 것입니다. OWASP는 이 항목을 악용은 쉽고, 매우 흔하며, 탐지는 어렵다고 평가했습니다. 1위인 이유입니다.

구분 내용
쉬운 예시 퇴사한 개발자가 만든 배포용 키, 종료된 프로젝트의 서비스 계정이 아무도 모른 채 살아 있는 상태
실제 사례 Cloudflare (2023) — Okta 사고 이후 수천 건의 자격증명을 교체했지만, '쓰지 않는 줄 알았던' 서비스 토큰 1개와 서비스 계정 3개를 놓쳤습니다. 공격자는 이 계정으로 내부 Atlassian(Jira·Confluence)에 접근했습니다.
막는 법 퇴사·프로젝트 종료 때 연결된 NHI까지 함께 점검, 인사 시스템과 IAM 연동으로 폐기 자동화, 활성 NHI의 사용 이력 정기 감사

이 사고 이후 Cloudflare는 운영 환경 자격증명 5,000건 이상을 전부 교체했습니다. '안 쓰는 것 같다'는 추측은 폐기 근거가 아니라 위험 신호라는 교훈을 남겼습니다.

NHI2. 시크릿 유출 (Secret Leakage)

API 키, 토큰, 암호화 키, 인증서가 소스코드, 평문 설정 파일, 공용 채팅방처럼 허가되지 않은 곳에 남는 것입니다.

구분 내용
쉬운 예시 테스트하려고 코드에 키를 그대로 적고 커밋, 장애 대응 중 메신저에 토큰을 붙여넣기
실제 사례 Toyota T-Connect (2022 공개) — 개발 협력사가 사이트 소스 일부를 공개 GitHub에 올렸고, 그 안에 데이터 서버 접근 키가 있었습니다. 2017년 12월부터 2022년 9월까지 약 5년간 노출됐고, 고객 296,019명의 이메일과 고객관리번호가 접근 가능한 상태였습니다.
막는 법 커밋 전·CI 단계에 시크릿 스캐너 적용, 키는 시크릿 금고(Vault)에 보관, 유출되면 삭제가 아니라 즉시 폐기·재발급

NHI3. 취약한 서드파티 NHI (Vulnerable Third-Party NHI)

IDE 확장 프로그램이나 외부 SaaS에 넘겨준 자격증명·권한이, 그 서드파티가 뚫리면서 악용되는 위험입니다. 내 시스템이 멀쩡해도 피해를 입습니다.

구분 내용
쉬운 예시 마케팅팀이 챗봇 SaaS를 연결하면서 CRM 전체 읽기 권한을 OAuth로 승인
실제 사례 Salesloft Drift (2025) — 공격 그룹 UNC6395가 Drift–Salesforce 연동 OAuth 토큰을 손에 넣고, 2025년 8월 8일~18일 여러 기업의 Salesforce에서 대량의 데이터를 빼냈습니다. 빼낸 데이터 안에서 AWS 키, 비밀번호 같은 또 다른 시크릿도 찾았습니다. 8월 20일 Drift 관련 토큰이 일괄 폐기됐습니다.
막는 법 연동된 서드파티 앱·토큰 목록화, 승인 권한 최소화, 공급사 침해 소식이 나오면 즉시 토큰 폐기·재발급

NHI4. 안전하지 않은 인증 (Insecure Authentication)

서비스를 연동할 때 이미 폐기됐거나, 알려진 공격에 약하거나, 오래된 인증 방식을 쓰는 것입니다. 한 건의 대형 사고보다 '아직도 흔히 남아 있는 설정'으로 이해하는 편이 빠릅니다.

구분 내용
쉬운 예시 MFA를 건너뛰는 '앱 비밀번호'로 메일 연동, 폐기 권고된 OAuth 흐름 사용, 아이디·비밀번호만 보내는 레거시 인증 프로토콜 유지
가상 사례 (특정 조직과 무관) 보고서 자동 발송 스크립트가 관리자 계정의 앱 비밀번호로 메일 서버에 접속. 이 비밀번호가 새면 MFA가 있어도 메일함이 그대로 열림
막는 법 OAuth 2.1·OIDC 같은 표준 방식으로 전환, 레거시 인증 차단, 앱 비밀번호 사용 금지

NHI5. 과도한 권한 (Overprivileged NHI)

NHI에 실제 하는 일보다 훨씬 큰 권한을 주는 것입니다. 평소엔 아무 문제가 없다가, 그 NHI가 털리는 순간 피해 범위가 권한 크기만큼 커집니다.

구분 내용
쉬운 예시 이미지 업로드만 하는 서비스에 스토리지 전체 관리자 권한을 부여
실제 사례 Microsoft AI 연구팀 (2023, Wiz 발견) — 오픈소스 AI 모델을 공유하려고 GitHub에 올린 Azure SAS 토큰이 특정 파일이 아니라 스토리지 계정 전체를 열어 주고 있었고, 삭제·덮어쓰기까지 가능했습니다. 그 결과 직원 PC 백업, Teams 메시지 등 38TB의 내부 데이터가 노출됐습니다.
막는 법 최소 권한 원칙, 실제 사용 이력을 보고 안 쓰는 권한 회수, 정기 권한 검토

NHI6. 클라우드 배포 설정 미흡 (Insecure Cloud Deployment Configurations)

CI/CD 파이프라인이 클라우드에 배포할 때 쓰는 인증 설정 문제입니다. 고정된 키가 저장소·로그·설정 파일로 새거나, 더 안전한 OIDC를 쓰더라도 토큰 검증 조건을 허술하게 두는 경우입니다.

구분 내용
쉬운 예시 배포용 클라우드 액세스 키를 CI 변수에 넣어 두고, 빌드 로그에 디버그 출력으로 키가 찍힘
가상 사례 (특정 조직과 무관) OIDC로 운영 배포 역할을 받도록 바꿨지만, 신뢰 정책에 '어느 저장소의 어느 브랜치인지' 조건을 걸지 않음. 의도하지 않은 워크플로도 운영 역할을 받을 수 있는 상태가 됨
막는 법 정적 키 대신 OIDC 사용, 신뢰 정책에 저장소·브랜치·환경 조건 명시, 운영 배포는 보호된 브랜치에서만 허용

NHI7. 장기 시크릿 (Long-Lived Secrets)

만료일이 아예 없거나 너무 먼 미래로 잡힌 키·토큰·인증서입니다. 한 번 새면 공격자는 시간 제한 없이 들어올 수 있습니다.

구분 내용
쉬운 예시 "매번 바꾸기 귀찮으니" 만료 없음으로 발급한 개인 액세스 토큰
실제 사례 같은 Microsoft SAS 토큰 — 2020년 7월 처음 GitHub에 올라갔고, 2021년 10월 만료일이 2051년 10월로 늘어났습니다. 2023년 6월 Wiz가 발견해 신고한 뒤에야 무효화됐습니다.
막는 법 만료 기한을 짧게, 자동 교체(로테이션) 설정, 가능하면 실행 시점에 발급되는 단기 토큰으로 전환

참고로 Orca Security 분석에서는 GCP Secret Manager에 저장된 시크릿 중 자동 교체 일정을 정해 둔 비율이 0.5%에 불과했습니다. 금고에 넣는 것과 교체하는 것은 별개의 일입니다.

NHI8. 환경 분리 실패 (Environment Isolation)

개발·테스트·운영 환경이 같은 NHI를 함께 쓰거나, 테스트용 NHI가 운영 권한을 가진 상태입니다. 보안이 느슨한 테스트 환경이 운영으로 가는 지름길이 됩니다.

구분 내용
쉬운 예시 "테스트 데이터 맞추기 편하니까" 스테이징 서버에 운영 DB 계정을 그대로 사용
실제 사례 Microsoft – Midnight Blizzard (2024 공개) — 공격자가 MFA가 없던 레거시 테스트 테넌트 계정을 패스워드 스프레이로 장악했습니다. 이어서 사내 운영 환경에 높은 권한을 가진 레거시 테스트 OAuth 앱을 찾아냈고, 이를 이용해 메일함 접근 권한을 얻어 일부 임직원 메일을 열람했습니다.
막는 법 환경마다 NHI 분리, 테스트 NHI에 운영 권한 금지, 테스트 환경에도 운영과 같은 인증 기준 적용

NHI9. NHI 재사용 (NHI Reuse)

여러 애플리케이션·서비스가 하나의 NHI를 같이 쓰는 것입니다. 같이 배포되는 구성요소끼리라도 마찬가지입니다. 하나가 뚫리면 그 NHI를 쓰는 곳 전부가 열립니다.

구분 내용
쉬운 예시 현관·사무실·금고를 열쇠 하나로 여는 것과 같습니다
가상 사례 (특정 조직과 무관) 주문·결제·알림 서비스가 DB 계정 하나를 공유. 알림 서비스의 취약점으로 계정이 털리자 결제 테이블까지 노출되고, 로그로는 어느 서비스가 한 일인지 구분도 안 됨
막는 법 서비스 하나에 NHI 하나, 각 NHI에 그 서비스에 필요한 권한만 부여

NHI10. 사람의 NHI 사용 (Human Use of NHI)

개발자나 관리자가 자기 계정 대신 서비스 계정으로 수작업을 하는 것입니다. 권한은 커지고, 로그에는 사람이 한 일과 자동화가 한 일이 섞여 누가 했는지 추적할 수 없게 됩니다.

구분 내용
쉬운 예시 권한 신청이 번거로워 배치용 서비스 계정 비밀번호를 팀원끼리 공유해 콘솔에 로그인
실제 사례 Okta 고객지원 시스템 (2023) — 한 직원이 회사 노트북 크롬에 개인 구글 프로필로 로그인한 상태에서 고객지원 시스템의 서비스 계정을 사용했고, 그 계정의 아이디·비밀번호가 개인 구글 계정에 저장됐습니다. 개인 계정 또는 개인 기기 침해가 가장 유력한 유출 경로로 지목됐고, 고객사 134곳의 파일이 접근됐습니다.
막는 법 서비스 계정의 대화형 로그인 차단·탐지, 사람에게는 개인 계정 + 필요할 때만 권한 상승(JIT), 업무 기기에서 개인 프로필 로그인 제한

⚠️ 많이들 착각하는 3가지

1. "OWASP Top 10 2025"와 같은 목록이다? → 아닙니다.
웹 애플리케이션용 OWASP Top 10:2025는 별도 목록입니다. NHI Top 10은 계정·자격증명의 생성, 권한, 보관, 교체, 폐기 같은 '수명주기 관리 실패'를 다룹니다. 제목에 같은 2025가 붙어 있어 자주 헷갈립니다.

2. 시크릿 금고만 도입하면 끝이다? → 절반도 안 됩니다.
금고는 NHI2(시크릿 유출)를 줄여 줄 뿐입니다. 금고 안의 키가 만료 없이 살아 있고(NHI7), 권한이 과하고(NHI5), 주인이 없으면(NHI1) 위험은 그대로입니다.

3. 사고는 한 항목 때문에 터진다? → 실제로는 연쇄입니다.
가장 의외의 사실은 Okta의 NHI10이 Cloudflare의 NHI1로 이어졌다는 점입니다. 직원이 서비스 계정을 직접 쓰다 유출된 사건(Okta)에서 탈취된 자격증명이, 교체를 놓친 계정을 통해 다른 회사(Cloudflare)의 침입으로 번졌습니다.

사고 겹친 항목
Okta → Cloudflare NHI10 사람의 NHI 사용 → NHI3 서드파티 NHI → NHI1 부적절한 폐기
Microsoft SAS NHI2 시크릿 유출 + NHI5 과도한 권한 + NHI7 장기 시크릿
Midnight Blizzard NHI8 환경 분리 실패 + NHI5 과도한 권한

그래서 점검도 항목별로 따로 하기보다, 한 NHI를 놓고 "주인·권한·수명·환경"을 한 번에 확인하는 편이 효과적입니다.

🛠 조치 방법: NHI 보안 6단계

10개 항목의 대응책은 결국 아래 6단계로 모입니다. 처음부터 완벽할 필요는 없고, 1단계 인벤토리부터 시작하면 나머지가 보이기 시작합니다.

단계 할 일 줄어드는 위험
1. 인벤토리 클라우드 IAM, CI/CD 변수, OAuth 승인 앱, 서비스 계정을 한 목록으로 모으기 전 항목의 출발점
2. 소유자 지정 NHI마다 책임자 1명, 용도, 사용 환경 기록 NHI1, NHI9
3. 최소 권한 사용 이력을 보고 안 쓰는 권한 회수, 테스트 NHI의 운영 권한 제거 NHI5, NHI8
4. 단기 자격증명 정적 키를 OIDC·워크로드 ID로 대체, 남는 키는 만료·자동 교체 설정 NHI4, NHI6, NHI7
5. 스캔·금고 코드·로그·위키에서 시크릿 탐지, 키는 금고에만 보관 NHI2
6. 감시·폐기 미사용 NHI 정기 정리, 사람의 대화형 로그인·이상 호출 감시, 서드파티 침해 시 즉시 폐기 NHI1, NHI3, NHI10

💡 팁 — 오늘 당장 할 수 있는 한 가지
사내 업무 SaaS(메일, 드라이브, CRM)의 'OAuth 승인 앱 목록'을 열어 보세요. 누가 언제 승인했는지 모르는 앱이 하나라도 있다면, 그게 바로 NHI1과 NHI3이 겹치는 지점입니다.

🎉 정리

사람은 입사하면 계정을 받고 퇴사하면 계정을 반납합니다. NHI에는 이 당연한 절차가 없는 경우가 많습니다. OWASP NHI Top 10은 바로 그 빈틈을 10가지로 나눠 보여 주는 목록입니다.

기억할 것은 하나입니다. 모든 키와 계정에 주인이 있고, 필요한 만큼만 권한이 있고, 정해진 날짜에 사라지게 만드는 것. 이 세 가지만 지켜도 10개 항목 대부분이 함께 줄어듭니다.

✅ 셀프 체크리스트

항목 확인 질문
목록 우리 조직의 NHI가 몇 개인지 대략이라도 답할 수 있는가?
소유자 퇴사자가 만든 NHI가 남아 있지 않은가?
유출 저장소·CI 로그에 시크릿 스캔이 돌고 있는가?
권한 관리자 권한을 가진 NHI 목록을 뽑아 본 적이 있는가?
수명 만료 없는 키·토큰이 있는가? 교체 주기가 정해져 있는가?
환경 테스트용 NHI가 운영 자원에 접근할 수 있지 않은가?
서드파티 외부 SaaS에 승인한 OAuth 권한을 최근 6개월 내 검토했는가?
사람 사용 사람이 서비스 계정으로 콘솔에 로그인하는 일이 없는가?

💬 자주 묻는 질문

Q. NHI와 머신 아이덴티티, 워크로드 아이덴티티는 다른 말인가요?
A. 업계에서는 거의 같은 뜻으로 섞어 씁니다. 사람이 아닌 소프트웨어가 쓰는 신원을 가리킨다는 점은 같습니다.

Q. AI 에이전트도 NHI에 해당하나요?
A. 네. 에이전트가 메일·드라이브·DB에 접근할 때 쓰는 토큰과 권한이 곧 NHI입니다. 프로젝트 기여자들도 AI 에이전트를 서두르며 도입하는 과정에서 권한이 과한 NHI가 늘고 있다고 지적합니다. OWASP의 'Top 10 for Agentic Applications 2026'도 과도한 권한, 시크릿 노출, 장기 자격증명 같은 NHI 위험을 에이전트 위험의 근본 원인으로 연결해 설명합니다.

Q. 작은 회사도 신경 써야 하나요?
A. 오히려 더 중요합니다. 작은 조직일수록 한 사람이 만든 키를 여러 서비스가 같이 쓰고(NHI9), 그 사람이 떠나면 아무도 모르는(NHI1) 경우가 많습니다.

Q. 유출된 키를 저장소에서 지우면 해결되나요?
A. 아닙니다. 커밋 기록과 복제본에 남아 있을 수 있으므로, 키 자체를 폐기하고 새로 발급하는 것이 원칙입니다.

※ 본문의 '가상 사례'는 이해를 돕기 위해 일반화한 예시이며 특정 조직과 무관합니다.

🔗 참고 자료

저작자표시 비영리 변경금지 (새창열림)

'정보보안 > Cloud' 카테고리의 다른 글

CSAP 클라우드 보안인증 총정리, 2027 국정원 단일 검증 전환  (0) 2026.10.27
IMDSv1 비활성화 점검, 계정 기본값만 바꾸면 안 되는 이유  (0) 2026.10.22
Lambda 런타임 지원 종료 점검, 멈추지 않아서 더 위험한 이유  (0) 2026.10.22