[Zero Trust - IAM] IAM과 IGA: Privilege Creep이 생기는 이유와 접근 권한 거버넌스 설계

신입 개발자 David가 입사했다. 온보딩 과정에서 필요하다는 이유로 운영 데이터베이스 읽기 권한, 배포 파이프라인 접근 권한, 내부 대시보드 편집 권한을 받았다. 3개월 후 팀이 바뀌었다. 6개월 후 그가 담당하던 프로젝트가 종료됐다. 1년 후 David는 퇴사했다.

1년이 지난 시점에서 IAM 시스템에 물어보면 David의 계정은 여전히 활성 상태고 세 개의 시스템 모두 접근 가능하다고 답한다.

아무도 권한을 회수하지 않았기 때문이다.

 

이것이 Privilege Creep — 시간이 지나면서 필요 없어진 권한이 조용히 쌓이는 현상이다.

IAM 시스템에 이 문제를 물어보면 답하지 못한다. IAM은 "지금 이 순간 David가 접근 가능한가?"를 판단하도록 설계됐지, "이 권한이 아직도 적절한가?"를 검증하도록 만들어진 시스템이 아니기 때문이다.

 

Zero Trust의 핵심 원칙 중 하나는 Least Privilege — 필요한 권한만 부여하고, 그 이상은 허용하지 않는다. 그런데 IAM이 권한 결정의 근거로 삼는 데이터베이스 자체가 오래된 정보로 오염돼 있다면, "Never Trust, Always Verify"는 이름만 남는다.

틀린 데이터를 실시간으로 검증해봐야 틀린 결론이 나올 뿐이다.

 

IAM이 올바르게 동작하려면 그 데이터 정합성을 지속적으로 유지하는 별도의 시스템이 필요하다.

---

IAM이 하는 일

Identity and Access Management(IAM)의 역할은 명확하다. 접근 요청이 들어왔을 때 신원을 확인하고 허용할지 거부할지를 실시간으로 결정한다. 이 전 포스트에서 다룬 권한 모델(RBAC, ABAC, ReBAC)은 모두 이 결정의 논리를 다룬다.

ReBAC - Zanzibar는 이 결정을 Google 규모에서 수 밀리초 안에 처리하는 방법이었다.

 

IAM이 내리는 결정의 구조는 항상 동일하다. 요청자의 신원이 확인되면, 해당 신원에 연결된 권한 정보를 조회하고, 정책에 따라 허용 또는 거부를 반환한다. 이 파이프라인을 정확하고 빠르게 처리하는 것이 IAM의 핵심 역할이다.

 

여기서 중요한 전제가 하나 있다. IAM은 권한 데이터베이스가 지금도 옳다고 가정하고 그 위에서 동작한다. "David가 운영 DB에 접근할 수 있는가?"라는 질문에 IAM은 저장된 권한 레코드를 확인해 허용 또는 거부를 반환한다. 그 레코드가 1년 전에 만들어졌고 그사이 David가 팀을 옮기고 퇴사했더라도, 레코드가 삭제되지 않는 한 IAM은 여전히 허용을 반환한다. IAM은 데이터의 정확성을 보장하는 시스템이 아니라, 주어진 데이터를 바탕으로 빠르게 결정을 내리는 시스템이다.

---

IAM이 답할 수 없는 질문

IAM이 처리하지 못하는 질문들이 있다.

• "David가 운영 DB 읽기 권한을 갖고 있는데, 이 권한이 지금도 그의 업무에 필요한가?" IAM은 이 질문에 관심이 없다. 권한이 존재한다는 사실만 알 뿐이다.
• "지난 6개월 동안 어떤 권한이 어떤 근거로 부여됐는가?" IAM은 현재 상태를 관리하지, 변경 이력의 정당성을 추적하지 않는다.
• "같은 사람이 구매 요청과 구매 승인 권한을 동시에 갖고 있는가?" IAM은 개별 접근 요청을 처리하지, 권한 조합이 비즈니스 규칙에 위배되는지 검토하지 않는다.
• "지금 활성화된 서비스 계정 중 담당자가 퇴사한 계정이 몇 개인가?" 일반 사용자 계정보다 더 위험한 것이 서비스 계정(사람이 아닌 시스템 간 통신에 쓰이는 자동화 계정)이다. 서비스 계정은 만료되지 않는 자격증명을 갖는 경우가 많고, 담당자가 퇴사해도 시스템 간 의존성 때문에 삭제되지 않고 남는다. IAM은 서비스 계정의 소유권 적절성을 판단하지 않는다.

컴플라이언스 감사가 시작되면 이 질문들이 한꺼번에 쏟아진다. SOC 2, ISO 27001, HIPAA 같은 프레임워크는 정기적인 접근 권한 검토(Access Review)를 요구한다. "우리 시스템의 모든 권한이 적절하게 부여됐고, 주기적으로 검토됐으며, 불필요한 권한은 회수됐다"는 것을 증명해야 한다. IAM만으로는 이 증명을 만들 수 없다.

---

IGA의 등장

Identity Governance and Administration(IGA)는 이 질문들에 답하기 위한 시스템이다. 이름에 Governance와 Administration이 함께 들어 있는 것은 이유가 있다.

 

Administration은 프로비저닝, 디프로비저닝, 권한 변경과 같은 계정과 권한을 운영하는 것이다.

Governance는 정책 준수, 감사, 리스크 관리과 같은 운영이 올바르게 이루어지고 있는지 검증하는 것이다.

 

많은 조직이 Administration은 어느 정도 갖추고 있지만 Governance는 없다. 계정을 만들 수는 있지만 그 계정이 여전히 적절한지 검토하는 체계가 없는 것이다.

 

IAM이 "지금 접근 가능한가?"를 묻는다면, IGA는 "이 접근이 여전히 정당한가?"를 묻는다. 이 두 질문은 다른 시점에서, 다른 방법으로 답해야 한다. IAM은 요청 시점에 실시간으로 판단하지만, IGA는 주기적으로(분기, 반기, 연간) 권한 전체를 점검한다.

 

IGA가 다루는 영역은 세 가지다.

• 접근 권한 검증(Access Certification): 현재 존재하는 모든 권한이 적절한지 주기적으로 확인한다. 리뷰어가 각 권한에 대해 유지 또는 회수를 결정하고, 그 결정이 감사 로그로 남는다.
• Identity Lifecycle: 입사·부서 이동·퇴사 시 계정과 권한을 자동으로 처리한다. 사람이 수동으로 개입하지 않아도 권한이 올바르게 조정된다.
• Separation of Duties(SoD): 충돌하는 권한 조합을 탐지한다. 단일 권한의 문제가 아니라, 특정 조합이 만들어내는 리스크를 다룬다. (이후에 계속 등장하는 단어이니 기억해두자.)

---

Access Certification — 권한 검증이 동작하는 방식

Access Certification은 IGA의 핵심 워크플로우다. 주기적으로 실행되는 Certification Campaign을 통해 모든 권한의 정당성을 검토한다.

캠페인이 시작되면 IGA는 리뷰어(해당 팀의 관리자 또는 리소스 오너)에게 해당 리뷰어의 검토 대상 접근 목록을 발송한다. 리뷰어는 각 항목에 대해 세 가지 결정을 내릴 수 있다.

• 승인 — 이 권한은 여전히 필요하다.
• 거부 — 이 권한은 회수되어야 한다.
• 위임 — 다른 사람이 검토해야 한다.

거부된 권한은 SCIM(System for Cross-domain Identity Management), Active Directory, 각 앱의 API 등 프로비저닝 시스템을 통해 자동으로 회수된다. 리뷰어가 기한 내에 응답하지 않으면 상위 관리자에게 알림이 가거나, 정책에 따라 자동 거부 처리되는 에스컬레이션 규칙이 적용된다.

 

모든 결정과 그 근거는 감사 로그로 보관된다. "이 권한은 2024년 3월 15일, 홍길동 팀장이 업무상 필요하다고 판단해 유지됐다"는 기록이 남는다. 컴플라이언스 감사 때 이 로그가 증거가 된다.

 

캠페인 설계 — 무엇을 얼마나 자주 검토할 것인가

캠페인을 모든 권한에 동일한 주기로 돌리는 것은 비효율적이다. 감사 부담이 분산되지 않고 특정 시점에 몰리고, 리뷰어는 수백 건의 항목을 처리해야 하는 상황이 만들어진다. 성숙한 IGA 운영은 리스크 기반으로 캠페인을 설계한다.

 

고위험 권한(운영 DB 접근, 배포 파이프라인, 감사 로그 수정)은 분기마다 검토한다. 일반 업무 권한은 반기 또는 연간으로 충분하다. 또는 직원이 부서를 이동했거나, 권한이 90일 이상 사용되지 않았거나, SoD 위반에 근접한 권한 조합이 감지됐을 때 즉각 검토를 시작한다와 같은 특정 이벤트를 트리거로 삼는 방법도 효과적이다.

 

캠페인에 컨텍스트를 제공하는 것도 설계의 문제다. "이 권한은 180일째 사용된 기록이 없습니다"는 리뷰어에게 회수의 근거를 준다. "마지막 승인자: 김철수 (현재 퇴사)"는 리뷰어에게 재검토의 필요성을 즉시 전달한다. 이런 컨텍스트 없이 권한 이름만 나열하면 리뷰어는 판단할 방법이 없다.

 

Rubber Stamp — 가장 흔한 실패 패턴

캠페인이 제대로 동작하려면 리뷰어가 실제로 판단을 내려야 한다. 실무에서 가장 자주 목격되는 실패는 리뷰어가 내용을 확인하지 않고 전부 승인을 누르는 rubber stamp 문제이다.

 

이것은 리뷰어의 잘못이 아니라 설계의 문제다. 권한 목록이 수백 건이고, 각 항목이 무엇인지 설명이 없고, 검토 기한은 촉박하다면 리뷰어는 판단할 수 없다. 컴플라이언스 요건은 충족됐다고 기록되지만 실제로는 아무것도 검증되지 않은 상태다.

 

rubber stamp를 구조적으로 방지하는 방법은 두 가지다.

• 첫째, 리뷰어당 검토 항목 수를 관리 가능한 수준으로 제한한다. —  한 캠페인에서 리뷰어 한 명이 30건 이상을 검토하면 품질이 급격히 떨어진다.
• 둘째, 이상 징후가 있는 항목을 자동으로 플래깅해 리뷰어의 주의를 집중시킨다. 모든 항목이 동등하게 취급되면 리뷰어는 어디에 집중해야 할지 모른다.

---

Identity Lifecycle — Joiner·Mover·Leaver

Access Certification이 기존 권한의 적절성을 점검한다면, IGA가 해결해야 하는 또 다른 축은 사람의 상태 변화다. 입사·이동·퇴사가 적절하게 처리되지 않으면 Privilege Creep의 가장 큰 원인이 된다.

Joiner:
신입 직원이 입사할 때 HR 시스템에서 IGA로 이벤트가 전달된다. 직무(role)와 부서(department) 정보를 기반으로 해당 역할에 기본적으로 부여되는 권한 세트가 자동으로 프로비저닝된다(Birthright Access). "영업팀 사원은 CRM 읽기 권한과 Slack 접근 권한을 기본으로 갖는다"는 정책이 사람의 개입 없이 실행된다. Birthright Access가 잘 정의돼 있을수록 온보딩 속도가 빨라지고, 불필요하게 넓은 권한을 수동으로 요청하는 일이 줄어든다.

 

Mover:
부서 이동이나 직책 변경이 가장 다루기 까다롭다. 단순히 새 권한을 추가하는 것이 아니라, 이전 역할의 권한을 먼저 정리하고 새 역할의 권한을 부여하는 순서가 중요하다. 이전 권한을 제거하기 전에 새 권한을 추가하면 일시적으로 두 역할의 권한이 공존하는 구간이 생기고, 이 구간에 SoD 위반이 발생할 수 있다. IGA는 이전 역할 권한 회수 → SoD 검사 → 새 역할 권한 부여 순서를 보장해야 한다.

 

Leaver:
퇴사가 가장 위험하다. David 사례처럼 퇴사자 계정이 남아있으면 보안 사고의 직접적인 원인이 된다. IGA는 HR 시스템의 퇴사 이벤트를 받아 즉시 모든 시스템의 접근을 차단해야 한다. 여기서 주의할 점은 HR 시스템과 IT 시스템 사이의 타이밍 갭이다. HR에 퇴사가 기록되는 시점과 IT 시스템에 전달되는 시점 사이에 지연이 있으면 그 구간이 위험하다. HR 시스템과 IGA를 실시간으로 연동해 이 갭을 최소화하는 것이 설계 목표다.

 

직원이 퇴사를 할 경우, 계정 삭제가 아니라 비활성화를 먼저 하는데 여기에는 이유는 두 가지 이유가 있다.

• 첫째, 감사를 위한 이력 보존이다. 퇴사자가 재직 중 어떤 권한으로 무엇에 접근했는지의 기록은 보안 사고 조사 때 필요하다.
• 둘째, 시스템 의존성 파악이다. 사용자 계정이 특정 서비스의 owner로 등록돼 있는 경우, 계정을 즉시 삭제하면 서비스가 중단될 수 있다.

따라서 비활성화 후 의존성을 확인하고 소유권을 이전하는 것이 안전한 순서다.

 

서비스 계정과 자동화 계정

Leaver 시나리오에서 간과되기 쉬운 것이 서비스 계정이다. David가 운영하던 자동화 스크립트나 모니터링 에이전트가 그의 자격증명으로 실행되고 있었다면, David의 계정이 비활성화된 후 그 스크립트에서 인증 오류가 발생한다. 반대로 David 전용으로 발급된 API 키가 팀의 공유 문서에 그대로 남아있다면, 계정이 비활성화돼도 그 키는 살아있다.

 

서비스 계정은 만료 정책이 없는 경우가 많고, 담당자가 퇴사해도 소유권이 자동으로 이전되지 않는다. 사용자 계정 중심으로 설계된 IGA 프로세스는 이 부분에서 구멍이 생긴다. 서비스 계정 인벤토리 관리와 소유권 추적을 IGA 범위에 포함시키는 것이 성숙한 운영의 기준이다.

---

Separation of Duties — 권한 조합이 만드는 위험

SoD(직무 분리, Separation of Duties)는 단일 권한이 아니라 권한의 조합이 위험한 문제를 다룬다.

"구매 요청 권한"은 그 자체로 문제없다. "구매 승인 권한"도 그 자체로 문제없다. 그런데 이 두 권한이 같은 사람에게 있으면, 그 사람은 자신이 만든 구매 요청을 스스로 승인할 수 있다. SOX(Sarbanes-Oxley)나 PCI DSS 같은 규정이 SoD를 명시적으로 요구하는 이유도 이것이다.

재무 데이터를 기록하는 사람과 그 기록을 검증하는 사람이 동일인이면 내부 통제가 무력화된다.

정적 SoD와 동적 SoD

SoD는 두 가지 레벨에서 동작한다.

 

정적 SoD(Static SoD)는 특정 권한 쌍을 같은 사람이 동시에 보유할 수 없다는 규칙이다. "구매 요청 권한"과 "구매 승인 권한"의 동시 보유 금지가 여기에 해당한다. 권한이 부여되는 시점에 검사하고, 주기 스캔으로 기존 조합을 점검한다.

 

동적 SoD(Dynamic SoD)는 더 세밀하다. 같은 사람이 두 권한을 보유하는 것 자체는 허용하되, 동일한 트랜잭션 안에서 두 역할을 동시에 수행하는 것을 금지한다. 구매 요청서를 직접 만든 사람이 그 동일한 요청서를 승인하는 것은 금지하되, 다른 사람이 만든 요청서는 승인할 수 있다. 소규모 팀에서 구매 요청자와 승인자를 완전히 분리하기 어려울 때, 이처럼 트랜잭션 단위로 역할 중복을 차단하는 것이 Dynamic SoD의 실용적 구현이다.

탐지와 처리

IGA는 SoD 위반을 두 시점에서 잡는다.

첫째, 권한 부여 시점에 기존 권한과의 충돌 여부를 즉시 검사한다.

둘째, 주기적 스캔으로 시간이 지나면서 형성된 위반 조합을 찾는다.

 

Mover 시나리오가 특히 위험하다 — 부서 이동 시 이전 역할의 권한이 완전히 회수되지 않은 채로 새 역할의 권한이 추가되면 충돌이 생긴다.

위반이 감지됐을 때 처리 경로는 두 시점에 따라 달라진다.

 

권한 부여 시점에서 감지된 경우에는 요청 자체가 차단되거나, 정책에 따라 예외 승인(exception approval) 프로세스(리스크를 인지한 상위 관리자가 수용 여부를 명시적으로 판단하는 절차다)로 넘어간다.

주기 스캔에서 발견된 경우에는 관련 관리자에게 알림이 전달되고, 지정된 기한 안에 두 충돌 권한 중 하나를 제거해야 한다. 기한이 지나도 처리되지 않으면 자동 회수 정책이 실행된다.

 

SoD를 설계할 때 현실적인 제약도 있다. 작은 팀에서는 인원 부족으로 충돌 쌍을 완전히 분리하기 어려운 경우가 있다. 이때는 SoD를 포기하는 것이 아니라 해당 트랜잭션에 대해 추가 로깅을 강화하거나, 주기적으로 제3자 감사를 수행하거나, 특정 금액 이상의 거래에만 이중 승인을 요구하는 식의 보완 통제(compensating control)로 대신한다.

---

IAM과 IGA의 역할 구분

두 시스템이 실제로 어떻게 나뉘는지를 정리하면 이렇다.

	IAM	IGA
핵심 질문	지금 접근 가능한가?	이 접근이 여전히 적절한가?
동작 시점	요청 시 실시간	주기적 (분기·반기·연간)
관심 대상	개별 접근 요청	권한 전체의 정당성
주요 기능	인증(Authentication)·인가·정책 집행	검토·인증(Certification)·수명주기(Lifecycle)·SoD
감사 산출물	접근 로그	권한 변경 이력·검토 결과

 

이 둘은 경쟁 관계가 아니라 역할이 다른 보완 관계다. IAM이 없으면 접근 제어 자체가 불가능하고, IGA가 없으면 IAM이 관리하는 데이터가 시간이 지나면서 오염된다. Zero Trust의 관점에서 보면 IAM은 "지금 이 순간"을 검증하는 시스템이고, IGA는 "검증의 전제가 되는 권한 데이터"를 신뢰할 수 있게 유지하는 시스템이다.

---

적용 판단 기준

규모가 작은 팀에서는 IGA 없이 IAM만으로 충분할 수 있다. 20명 이하의 팀에서는 관리자가 직접 권한 변경을 추적할 수 있고, 퇴사자 처리도 수동으로 가능하다.

 

IGA가 필요해지는 시점은 다음 세 조건 중 하나라도 성립할 때다.

 

첫째, 직원 수가 수백 명을 넘어가 수동 추적이 불가능해질 때.

둘째, SOC 2, ISO 27001, HIPAA, 금융 감독 규정처럼 정기 접근 검토를 요구하는 컴플라이언스 대상이 됐을 때.

셋째, 퇴사자 계정이 자동으로 정리되지 않아 orphaned account(담당자 없이 방치된 계정) 문제가 반복될 때.

 

IGA 도입은 단계적으로 접근하는 것이 현실적이다.

• 1단계 JML 자동화 — 직원이 입사·이동·퇴사할 때 권한이 자동으로 처리되는 것만 갖춰도 Privilege Creep의 주된 원인을 차단한다.
• 2단계 Access Certification — JML로 처리되지 못한 잔여 권한을 주기적으로 검토하는 체계를 구축한다.
• 3단계 SoD와 분석 — 권한 조합 리스크를 관리하고, 미사용 권한을 자동으로 탐지하며, 이상 패턴을 감지하는 방향으로 발전한다.

IGA를 도입할 때 가장 많이 겪는 실패는 기술 도입을 먼저 하는 것이다. "어떤 직무가 어떤 권한을 가져야 하는가"라는 역할 모델이 정의되지 않으면 IGA 시스템이 있어도 Certification Campaign에서 리뷰어가 "잘 모르겠으니 다 승인"을 누른다. 도구보다 먼저 역할 모델 정의가 선행돼야 한다.