로그인 클레임은 로그인할 때만 갱신됩니다. 퇴사자는 다시 로그인하지 않으므로, 그 사람의 권한을 다시 확인하거나 회수할 계기도 생기지 않습니다.
엔터프라이즈 PAM을 도입할 때 SSO, MFA, 디렉터리 동기화는 보통 IdP(신원 제공자)가 맡습니다. Okta, Auth0, Entra ID가 사용자의 신원과 인증 여부를 확인합니다. 이 기능은 대체로 이미 갖춰져 있어 PAM의 차이를 가르는 지점은 아닙니다.
IdP는 "이 사용자는 인증됐고 이 그룹에 속한다"는 정보를 클레임으로 넘깁니다. 클레임은 권한이 아닙니다. 역할도 아닙니다. 서버 db-prod-04에서 쓸 리눅스 계정은 더더욱 아닙니다. PAM은 클레임을 받아 내부 사용자를 등록하고, 역할을 적용한 뒤 실제 호스트 계정까지 연결합니다. 이 과정을 신원 매핑이라고 합니다.
- 클레임 → PAM 내부 사용자. IdP의 인증 정보가 PAM 내부 사용자로 등록됩니다.
- PAM 내부 사용자 → RBAC 역할. 그룹 멤버십을 바탕으로 적용할 권한을 정합니다.
- RBAC 역할 → 호스트 계정. 이 사용자가 어느 호스트의 어떤 OS 로컬 계정으로 접속할지 정합니다.
- 퇴사 이벤트 → 앞선 세 단계의 해제. 퇴사하면 그 사람에게 연결된 권한도 모두 회수돼야 합니다.
구매자가 이 연결을 직접 묻는 일은 드뭅니다. 하지만 "SSO를 지원하나요"만으로는 충분하지 않습니다. 네 단계가 실제로 이어지는지, 아니면 첫 단계만 자동화한 채 나머지는 사람이 처리한다고 가정하는지 확인해야 합니다.
클레임 형식과 갱신 시점이 만드는 차이
첫 단계에서 클레임을 전달하는 방식은 크게 두 가지입니다. 이 선택에 따라 나중에 생기는 문제가 달라집니다.
Okta의 방식은 가공하지 않은 groups 클레임을 그대로 싣는 것입니다. ID 토큰에 그룹 이름을 담은 JSON 배열을 실어 보내는 방식이고, 대부분의 플로우에서 사용자당 최대 100개 그룹으로 제한됩니다. 이를 넘으면 요청 자체가 실패합니다. 다만 PAM이 쓰는 authorization-code 플로우는 이 제한에서 예외입니다.
Entra ID의 원본 groups 클레임도 다른 방식으로 비슷한 한계에 부딪힙니다. 발급 개수는 JWT당 200개, SAML 어설션당 150개로 제한됩니다. 이 한도를 넘으면 목록을 잘라내는 대신 클레임 자체가 초과 표시로 바뀝니다. 그러면 애플리케이션은 Microsoft Graph에서 멤버십을 따로 조회해야 합니다.
Entra의 더 깔끔한 대안인 App Roles는 Microsoft가 이 그룹 오버리지 경로를 피하는 방법으로 문서화한 패턴입니다. 먼저 애플리케이션이 자체 앱 등록에 역할을 선언하고, 그다음 고객이 Entra에서 디렉터리 그룹을 그 역할에 할당하면, 토큰에는 미리 해석한 값으로 구성된 roles 클레임이 실립니다. 다만 그룹을 앱 역할에 할당하려면 Entra ID P1 이상이 필요하고, 무료 테넌트에서는 쓸 수 없습니다. 그룹 클레임을 쓰면 애플리케이션이 대규모로 그룹과 역할의 관계를 직접 해석해야 하고, 그 과정에서 크기 제한에 부딪힐 수 있습니다. 역할 클레임에서는 고객사 관리자가 이미 관리하는 IdP가 이 해석을 맡습니다.
또 하나는 갱신 시점입니다. 로그인 토큰의 클레임은 사용자가 다시 로그인할 때만 바뀝니다. SCIM 프로비저닝은 다릅니다. IdP가 로그인과 무관하게, 자체 일정에 따라 멤버십 변경을 애플리케이션에 기록합니다. HR이 디렉터리에 퇴사 처리를 하면 그 변경도 사용자가 다시 로그인하기를 기다리지 않고 전파됩니다. 로그인 때만 반영하는 연동은 새 입사자를 추가하는 데는 쓸 수 있습니다. 하지만 다시 로그인하지 않는 퇴사자의 권한은 구조적으로 회수할 수 없습니다. 변경을 알릴 계기가 없기 때문입니다. 성숙한 환경에서는 SCIM으로 계정 생애주기를 관리하고, 토큰 클레임으로 로그인 시점의 권한을 해석합니다.
퇴사 시 발생하는 오류는 쉽게 드러나지 않습니다
마지막 단계에는 두 과정이 함께 있습니다. 온보딩은 입사하거나 부서를 옮길 때 접근 권한을 부여하는 일이고, 오프보딩은 퇴사할 때 그 권한을 모두 회수하는 일입니다. 두 과정은 실패하는 방식도 다릅니다. 온보딩에서 RBAC 연결이 잘못되면 필요한 서버에 접속하지 못한 사용자가 바로 문의합니다. 보통 당일 지원 티켓으로 드러나고 수정됩니다.
제대로 연결된 퇴사자 권한 회수 체인은 계정 상태만 바꾸는 일이 아닙니다. 트리거가 발동하면 그 사람에게 연결된 모든 활성 세션을 종료하고, 이미 발급한 자격증명을 다시 쓰지 못하게 막습니다. "오프보딩됐다"는 것은 "비활성으로 표시됐다"가 아니라 "종료되고 잠겼다"는 뜻입니다. 이 체인이 깨져도 겉으로는 아무 일도 일어나지 않습니다. 계정은 몇 달 동안 쓰이지도 회수되지도 않은 채 남아 있다가, SOC 2 접근 권한 검토나 사고 사후 분석에서 퇴사자 명단과 아직 활성 상태인 계정을 대조할 때야 드러납니다. HIPAA도 이 간극을 보여 줍니다. 정기 평가를 요구하지만(§164.308(a)(8)) 주기는 명시하지 않습니다. 종료 절차 규정(§164.308(a)(3)(ii)(C))도 addressable 항목이어서 기업이 방식을 정합니다. 둘 다 기한이나 주기를 정해 두지 않아, 오래된 계정이 문제가 될 만큼 남아 있을 수 있습니다. 네 번째 단계는 들어올 때는 요란하게, 나갈 때는 조용하게 실패합니다.
이 조용한 실패는 모든 작업이 상시 접근이 아니라 매번 새로 인증한 세션을 요구하는 순간, 두 가지 구체적인 지점으로 좁혀집니다. 퇴사 시점에 이미 열려 있던 세션, 그리고 애초에 세션을 거치지 않은 자격증명입니다. 낡은 역할이나 호스트 계정 매핑이 남아 있어도, 다시 들어오려면 이미 그 사람이 떠났다는 걸 아는 IdP를 상대로 신원을 다시 증명해야 한다면 그 자체로는 아무 권한도 주지 않습니다. 이 부분은 하위 PAM 정리와 달리, 조직이 첫날부터 실제로 제대로 처리하는 오프보딩 단계이기도 합니다. 퇴사 트리거가 그 즉시 죽여야 하는 것은 "하위의 모든 기록을 정리하라"보다 좁습니다. 그 순간 이미 열려 있던 세션, 그리고 애초에 세션을 거치지 않은 서비스 토큰이나 장기 자격증명입니다.
호스트 계정을 정하는 단계도 따로 봐야 합니다
역할을 정했다고 연결이 끝나는 것은 아닙니다. "이 사용자가 db-prod-04에 접근할 수 있다"는 권한과, 실제로 어느 OS 로컬 계정으로 접속하는지는 별도 결정입니다. 이 지점에는 소유자를 알 수 없는 계정이 남기 쉽습니다. ubuntu, ec2-user, 여러 명이 함께 쓰는 서비스 계정이 그런 사례입니다.
Alpacon을 거치는 ubuntu, ec2-user 같은 공유 계정은 RBAC 통제를 받고, 실제 로그인한 사람과 연결되어 세션 기록에 남습니다. 소유자를 기억하지 못한다는 이유로 관리 대상에서 빠지지 않습니다.
실행 제어는 그 다음 단계의 문제입니다
클레임·역할·호스트 계정의 연결은 PAM이라면 기본으로 갖춰야 할 기능입니다. 구매자도 이 연결이 정상일 것이라 기대합니다. 다음으로 봐야 할 것은 호스트 계정이 실제로 어떤 명령을 실행할 수 있는지입니다. 이는 사용자 신원을 확인하는 문제와 다릅니다. Alpacon은 에이전트가 command API로 보내는 명령에 위험 점수를 매기고, 애매한 구간의 명령은 텍스트뿐 아니라 세션에서 선언한 작업 목적과도 비교합니다.
지난 접근 권한 검토에서 퇴사한 지 세 달이 지난 사람의 계정이 아직 남아 있는지 아무도 답하지 못했다면, 권한 회수 과정이 끊긴 것입니다. 신원 매핑은 사용자를 호스트 계정까지 연결합니다. 그 뒤에 어떤 명령을 실행할 수 있는지는 실행 제어가 다뤄야 합니다.
