SaaS 접근권한 검토는 분기 이벤트가 아니라 퇴사·이동 흐름이다

SaaS가 늘어나면 계정은 인사 시스템보다 빠르게 퍼진다. 중앙 IdP에 연결된 앱은 퇴사 시 로그인이 막힐 수 있지만, 이메일로 직접 가입한 도구, 개인 카드로 결제한 서비스, 외부 협력사가 초대한 게스트 계정은 같은 흐름에서 빠지기 쉽다. 분기 검토만 믿으면 부서 이동 후에도 관리자 권한이 남고, 계약이 끝난 외주 인력이 공유 문서와 API 토큰을 계속 사용할 수 있다.

접근 검토의 목표는 “계정 수를 줄였다”가 아니라 현재 업무 책임과 실제 권한이 일치한다는 증거를 남기는 것이다. 이를 위해서는 사람 계정뿐 아니라 서비스 계정, 봇, OAuth 애플리케이션, 공유 링크, 장기 세션을 하나의 권한 표면으로 봐야 한다.

분기 검토보다 먼저 만들어야 할 이벤트 흐름

이벤트	즉시 처리할 항목	완료 증거
입사	기본 그룹, MFA·패스키, 최소 앱 할당	인사 이벤트와 계정 생성 ID
부서·직무 이동	이전 그룹 제거 후 새 역할 부여	전후 권한 diff와 승인자
휴직	로그인·세션 제한, 대리 업무 범위 지정	시작·종료일과 임시 소유자
외주 계약 종료	게스트, 공유 링크, API 키 폐기	계약 ID와 폐기 로그
퇴사	계정 차단, 세션·토큰 취소, 데이터 이전	처리 시각과 데이터 인수자

순서도 중요하다. 퇴사 처리에서 메일 계정만 먼저 삭제하면 SaaS 데이터의 새 소유자를 지정하지 못할 수 있다. 반대로 데이터 이전만 하고 세션을 남기면 이미 로그인된 브라우저가 계속 작동할 수 있다. 조직은 “차단 → 세션·토큰 폐기 → 데이터 소유권 이전 → 계정 삭제 또는 보존”처럼 앱 특성에 맞춘 순서를 정해야 한다.

인벤토리는 구매 목록이 아니라 로그인 경로 목록이다

재무팀의 구독 목록만으로는 무료 SaaS와 개인 결제를 찾기 어렵다. 최소한 다음 네 신호를 합쳐야 한다.

1. IdP의 SAML/OIDC 애플리케이션과 로그인 로그
2. CASB·DNS·프록시에서 관찰한 SaaS 도메인
3. 법인카드와 경비 처리 내역
4. 이메일 수신함의 초대·인증·결제 알림

각 앱에는 업무 소유자, 기술 관리자, 데이터 등급, 인증 방식, 사용자 동기화 방식, 감사 로그 보존 기간, 계약 종료일을 붙인다. 소유자가 없는 앱은 위험을 평가할 사람이 없으므로 신규 사용자 추가를 멈추고, 데이터를 확인한 뒤 통합 또는 폐기 대상으로 분류한다.

검토 대상은 사용자 계정보다 넓다

관리자와 권한 그룹

전역 관리자, 결제 관리자, 사용자 관리자처럼 피해 범위가 큰 역할은 일반 사용자 검토와 분리한다. 상시 관리자 대신 필요할 때만 승격하는 방식이 가능한지 확인하고, 관리자 권한 사용 로그와 비상 계정의 보관 책임자를 지정한다.

OAuth 승인과 API 토큰

사용자가 캘린더·드라이브·메일 접근을 외부 앱에 승인하면 비밀번호를 바꿔도 토큰이 남을 수 있다. 고위험 권한 범위, 검증되지 않은 게시자, 장기간 사용하지 않은 승인, 퇴사자 명의의 통합을 별도 목록으로 만든다. 서비스 계정은 개인 이메일을 소유자로 두지 말고 팀과 시스템을 소유자로 기록한다.

게스트와 공개 공유

게스트가 로그인하지 않아도 작동하는 공개 링크는 사용자 목록에 나타나지 않는다. 외부 도메인 공유, “링크가 있는 모든 사용자” 설정, 대량 다운로드가 가능한 데이터룸을 함께 검토한다. 협력사 프로젝트가 끝났다면 게스트 제거와 링크 만료를 같은 티켓에서 처리한다.

탐지 신호와 조사 순서

탐지 신호	가능한 원인	첫 확인
퇴사 후 로그인 성공	비연동 계정 또는 살아 있는 세션	IdP·SaaS 감사 로그와 세션 목록
부서 이동 후 관리자 유지	그룹 중첩 또는 수동 부여	전후 그룹·직접 역할 diff
새 OAuth 앱의 광범위 권한	업무 통합 또는 악성 동의	승인자, 범위, 게시자, 사용 IP
야간 대량 다운로드	백업·마이그레이션 또는 유출	계정, 파일 등급, 목적지, 변경 티켓
소유자 없는 서비스 계정	담당자 이동 또는 오래된 자동화	최근 사용일과 호출 워크로드

경보가 울리면 계정을 바로 삭제하기보다 업무 영향을 먼저 분류한다. 의심스러운 세션과 토큰은 폐기하되, 고객 지원·결제·배포 자동화 계정이라면 대체 자격증명을 발급하고 작업 소유자를 확인한 뒤 차단해야 한다.

분기 검토는 자동화의 실패를 찾는 시간이다

정기 검토에서는 전 직원을 다시 승인받기보다 다음 예외에 집중한다.

• 인사 시스템과 IdP의 상태가 다른 사용자
• 30~90일 동안 사용하지 않은 계정과 토큰
• 직접 부여된 관리자 권한
• 소유자 또는 만료일이 없는 게스트
• SCIM에서 제외된 앱과 수동 계정
• 반복적으로 연장되는 예외

검토자는 “유지”만 누르지 못하게 사유를 선택하거나 적도록 하고, 고위험 권한은 업무 관리자와 시스템 소유자가 각각 승인하게 한다. 결과에는 검토 범위, 기준 시각, 제외 항목, 변경 건수, 미해결 예외를 남겨야 다음 분기와 비교할 수 있다.

실패 모드와 복구 계획

가장 흔한 실패는 자동 회수가 너무 넓게 작동해 공용 계정이나 긴급 대응 계정을 잠그는 경우다. 배포 전에는 파일럿 그룹과 dry-run 보고서를 사용하고, “삭제”보다 “로그인 차단”을 먼저 적용한다. 롤백은 임시로 모든 권한을 되돌리는 것이 아니라, 승인된 사용자에게 필요한 역할만 재부여하는 절차여야 한다.

자동화가 멈췄는지 알 수 있는 지표도 필요하다. 인사 이벤트 대비 처리 성공률, 퇴사 후 차단까지 걸린 시간, 소유자 없는 계정 수, 만료된 예외 수, 직접 관리자 권한 수를 주간으로 확인한다.

운영 체크리스트

• 인사 시스템의 입사·이동·휴직·퇴사 이벤트가 IdP와 연결돼 있다.
• SCIM 미지원 또는 미연동 SaaS 목록과 수동 처리 책임자가 있다.
• 관리자, 게스트, 서비스 계정, OAuth 승인, 공유 링크를 함께 검토한다.
• 퇴사 처리에서 세션과 장기 토큰을 실제로 폐기한다.
• 예외에는 소유자·사유·만료일·보완 통제가 있다.
• 자동 회수 전 dry-run 결과와 업무 영향 소유자를 확인한다.
• 분기 검토 결과를 전분기와 비교할 수 있는 지표로 남긴다.

인증 수단과 계정 복구까지 함께 정비하려면 패스키 도입 전 헬프데스크 플레이북을, 웹 기반 고위험 업무를 별도로 통제하려면 브라우저 격리 위험 모델을 이어서 볼 수 있다. 접근 경계를 더 넓게 설계할 때는 제로 트러스트 신원 경계가 도움이 된다.

참고 기준

• NIST SP 800-53 Rev. 5: Account Management
• CISA Secure Cloud Business Applications Project
• CIS Critical Security Controls v8.1

SaaS 접근 검토가 성숙했다는 신호는 분기 보고서가 두꺼워지는 것이 아니다. 사람이 이동하거나 계약이 끝났을 때 권한이 정해진 시간 안에 줄어들고, 자동화에서 빠진 예외가 누구의 책임인지 바로 드러나는 것이다.