2027년 ISMS 인증제 개편으로 비인간 식별자(NHI) 전체 생명주기 관리 의무화
깃허브·슬랙 등에 방치된 자격증명 조사부터 자동화 파이프라인 구축까지 단계별 로드맵

[보안뉴스= 김동현 OWASP 서울 챕터 리더] 과학기술정보통신부와 개인정보보호위원회가 공동 발표한 정보보호 관리체계(ISMS: Information Security Management System) 인증제도 실효성 강화방안에서 ‘비인가’라는 단어가 반복 등장한다.


[출처: 제미나이 생성형 이미지 활용, 김동현 제공]

비인가 구성요소 탐지와 비인가 계정 탐지 그리고 액세스 토큰과 API키의 생명주기 관리 같은 표현들이 바로 그것이다. 여기서 가리키는 대상은 비인간 식별자(NHI: Non-Human Identity)로 서비스 계정과 봇, CI/CD 파이프라인 토큰, API 키를 아우른다.

지금까지 국내 ISMS 인증체계는 인간 계정을 중심으로 설계됐는데, 이번 개편은 그 전체를 조정한다. 바로 이 비인간 식별자에 대한 내용이 담겼기 때문이다.

1. 왜 규제가 바뀌었나: NHI의 구조적 취약점
이번 개편의 배경에는 인증제도의 실효성에 대한 문제 제기가 있다. 지난 3년간 ISMS·ISMS-P 인증을 보유한 기업 가운데 179개사, 약 14%에서 침해사고가 벌어졌다. 쿠팡 개인정보 유출 사태 이후 인증의 실효성을 둘러싼 논의가 이어졌고, 정부는 서면 위주의 스냅샷 방식 심사가 실질적인 보안 검증에 한계가 있다고 판단했다.

사고의 원인을 들여다보면 공통된 패턴이 있다. 인간 계정의 패스워드 탈취보다 장기간 관리되지 않은 API 키와 토큰, 서비스 계정 자격증명 탈취·노출 등이 초기 침입 경로로 활용되는 사례가 반복적으로 확인된다는 것이다. 깃허브(GitHub) 같은 공개 저장소에 실수로 커밋된 API 키나 슬랙(Slack) 채널에 공유되고 방치된 토큰, 퇴직자 서비스 계정에 연결된 클라우드 접근 권한 같은 경우다.

여기서 NHI의 구조적 특성이 드러난다. 인간 계정과 달리 NHI는 로그인 실패 알림이 없고, 다중인증(MFA) 적용도 어렵다. 퇴직자의 계정은 인사 프로세스와 연동돼 비활성화되지만, 그 퇴직자가 재직 중 발급한 API 키는 별도로 추적하지 않으면 남아 있게 된다.

클라우드 전환과 함께 마이크로서비스 간 통신과 서드파티 SaaS 연동, 자동화 파이프라인이 늘어났는데, 이 연결 지점들에 NHI가 존재한다. 글로벌 조사에 따르면 대부분의 기업에서 인간 계정 대비 비인간 계정의 비율이 1:149를 넘어섰다. 하지만 국내 ISMS 인증 심사에서 이 영역은 거의 다뤄지지 않았다.

2. 무엇이 달라지나: 3단계 차등화와 강화된 인증 기준
이번 개편의 핵심은 인증 기준의 3단계 차등화다. 기존 인증은 모든 기업에 동일한 기준이 적용됐지만, 앞으로 기업의 규모와 위험도에 따라 △강화인증(Advanced) △표준인증(Standard) △간편인증(Lite)으로 구분된다.

강화인증 군에는 기존 표준인증 기준 101개에 더해 20개의 강화 기준이 추가 적용된다. 대상(안)은 매출액 1조원 이상의 주요 인터넷 서비스 제공자(ISP)와 데이터센터(IDC), 매출액 3조원 이상의 정보통신서비스 제공자다. 시행 시점은 2027년으로 관련 고시 개정을 통해 의무 적용된다. 인증기준서 개선은 올해 하반기부터 시작되고 강화 기준 가이드라인도 같은 시기에 배포될 예정이다.

20개 강화 기준 가운데 NHI 보안과 직접 연관된 항목은 두 가지가 있다.

첫째는 자동화된 계정 관리로, 정보시스템 계정의 생성과 수정, 비활성화, 삭제를 아우른 생명주기 전반을 자동화된 메커니즘으로 관리하고 계정 상태 변경을 실시간으로 반영하라는 요구 사항이다. 수동 대장이나 분기별 일괄 점검 방식으로는 충족하기 어려운 기준이다. 프로비저닝(Provisioning)과 디프로비저닝(Deprovisioning)이 자동화된 파이프라인으로 연결되어야 하며, 여기서 ‘계정’은 인간 계정에 한정되지 않고 서비스 계정과 시스템 계정, CI/CD 파이프라인 계정이 포함된다.

둘째는 인증 정보 관리다. 액세스 토큰과 API 키를 아우른 인증 정보의 전체 생명주기를 체계적으로 관리하라는 조항이다. 발급과 갱신, 폐기의 전 과정이 포함되며, 이는 조직 내 모든 API 키와 토큰의 인벤토리가 있다는 전제에서 시작한다. 오늘날 자격증명은 개발자 로컬 환경과 CI/CD 설정 파일, 클라우드 환경변수, 협업 도구에 분산된 경우가 많다.

심사 전 확인할 실무 체크리스트
다가올 2027년 강화인증 기준 심사는 기존과 달라진다. 취약점 점검 전문 인력을 투입해 최대 500대의 자산을 직접 점검하는 현장 실증형 심사로 전환된다. 서면 증적 중심의 심사와는 성격이 달라진 것이다.

먼저 인벤토리 점검은 깃허브와 깃랩 등 공개 저장소 전수 스캔에서 출발한다. 현재 파일만 스캔해서는 부족하다. 실수로 커밋된 API 키는 이후 삭제하더라도 커밋 히스토리에 남기 때문이다. 슬랙과 컨플루언스, 지라, 노션 등의 내부 협업 도구도 마찬가지다. API key나 token, secret 등 키워드 검색을 해보면 임시로 공유된 채 방치된 자격증명이 적잖게 발견된다. 깃허브 액션스와 깃랩 CI 시크릿 목록, 클라우드 신원·접근관리(IAM) 액세스 키, 컨테이너 이미지 내 환경변수까지 포함해야 인벤토리의 범위가 채워진다.

다음은 생명주기 점검이다. 마지막 사용일 기준으로 90일 이상 미사용된 자격증명은 폐기 검토 대상으로 볼 수 있다. 무기한으로 발급된 키는 목록화하고 유효기간 설정을 검토해야 한다. 계정 비활성화와 해당 계정이 발급한 API 키의 폐기는 별개의 작업이다. 인사 프로세스와 자격증명 폐기 프로세스가 없다면, 퇴직이나 직무 변경 시 보안팀에 알림이 전달되는 절차를 먼저 고려할 수 있다.

마지막은 탐지와 증적이다. 비정상적인 시간이나 지역에서의 자격증명 사용, 단시간 내 대량의 API 호출과 같은 이상 패턴에 대한 알림 설정 여부를 확인해야 한다. 심사 증적은 정책 문서만으로 충분하지 않은 가능성이 높기에 자격증명 인벤토리 목록과 지난 1년간 갱신·폐기 이력, 이상 탐지 로그, 대응 이력, 자동 순환 설정 화면 등 운영 데이터가 필요하다.

리스크 기반 4단계 대응 타임라인

▲ 김동현 OWASP 서울 챕터 리더 [출처: 김동현 리더]
이번 ISMS 강화 인증 기준 도입은 국내 보안 규제가 ‘서류 기반 컴플라이언스’에서 ‘실질적 보안 역량 검증’으로 전환하는 분기점이다. 그 중심에 액세스 토큰과 API 키 등 비인간 식별자의 생명주기 관리가 있다. 의무 시행까지 여유를 부릴 상황도 아니다. 인벤토리 파악, 자동화 체계 구축, 심사 대비 내부 프로세스 정비까지 고려하면 지금 당장 시작해도 빠듯한 일정이다.

[즉시] 노출 여부 점검 및 고위험 키 차단 단계다. 공개 저장소 히스토리를 포함해 전수 스캔과 퇴직자 발급 키 미폐기 여부 확인에서 시작한다. 노출된 키는 삭제가 아닌 폐기 후 재발급이 원칙이다.

[3개월 내] 전체 자격증명 인벤토리 파악 및 리스크 분류 단계다. 조직 내 API 키와 토큰, 서비스 계정을 목록화하고 권한 수준과 유효기간, 사용 여부를 기준으로 고위험 자격증명을 우선 처리하는 방식이 현실적이다. 한 번에 완벽한 인벤토리를 구축하려기보다, 지금 위험한 항목을 먼저 식별하는 접근에 가깝다.

[6~12개월 내] 자동화 파이프라인 구축 단계다. 자격증명의 탐지·순환(Rotation)부터 폐기, 감사 로그의 자동화를 단계적으로 처리한다. 인사 프로세스 연동된 자격증명 폐기나 CI/CD 파이프라인 내 하드코딩 탐지 순으로 우선순위를 잡는 방식 등을 고려해볼 수 있다.

[2027년 시행 대비] 심사 준비 단계에서는 심사 방식의 변화에 맞춘 대응이 필요하다. 정책 문서의 구비와 실제 운영 여부는 별개의 영역으로 심사관이 확인할 운영 데이터와 로그, 자동화 설정 화면이 준비되어 있어야 한다.

NHI 보안은 더 이상 최첨단 보안팀의 전유물이 아니다. 2027년부터는 ISMS 인증심사에서 직접 검증받아야 하는 의무 관리 영역이다.

[글_ 김동현 OWASP 서울 챕터 리더]

<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>