퇴사자 SaaS 접근권한 회수 | SSO 로그인 차단만으로 충분할까
SSO 로그인 차단만으로 퇴사자의 모든 SaaS 접근이 종료됐다고 판단하면 안 됩니다. 중앙 계정의 신규 로그인 차단, 앱이 유지하는 세션, 개인 발급 토큰, 문서 공유 권한은 나눠 확인해야 합니다. Microsoft Entra ID도 애플리케이션이 자체 발급한 세션 토큰을 직접 취소할 수 없다고 설명합니다.
여러 SaaS를 운영하는 IT 관리자와 정보보안 담당자라면 퇴사 처리의 완료 기준을 ‘계정 비활성화’가 아니라 서비스별 회수 대상·실행 담당자·검증 결과가 기록된 상태로 정하는 것이 좋습니다. 아래는 Microsoft Entra, Google Workspace, Azure DevOps의 공식 문서에서 확인한 차이를 바탕으로 구성한 운영 점검안입니다. 공식 문서 확인일은 2026년 11월 3일입니다.
1. 중앙 로그인과 앱 내부 접근을 분리한다
중앙 인증 시스템에서 로그인을 막는 작업과 이미 발급된 인증 수단을 회수하는 작업은 같은 조치가 아닙니다. Microsoft Entra의 사용자 접근 회수 문서는 신규 로그인 차단과 리프레시 토큰 취소를 함께 안내합니다. 관리자 화면의 Account enabled 해제·저장과 Revoke sessions도 별도 단계로 제시하며, 실행에는 적절한 관리자 역할이 필요합니다.
그렇다고 이 두 작업을 마치면 모든 앱 세션이 종료되는 것은 아닙니다. 같은 문서는 Entra가 앱 자체 세션 토큰을 직접 취소할 수 없다고 명시합니다. 따라서 중앙 계정 담당자는 중앙 인증 조치를 수행하고, SaaS 담당자는 앱 안에서 사용자 비활성화나 프로비저닝 해제가 필요한지 별도로 확인하도록 책임을 나누는 편이 명확합니다.
Entra는 자체 세션이나 직접 로그인을 사용하는 앱의 접근 회수에 사용자 프로비저닝 해제가 효과적이라고 설명합니다. 자동 프로비저닝 해제를 지원하지 않는 앱도 수동 처리 절차를 마련하도록 권고합니다. SSO 연결 여부와 자동 회수 가능 여부를 같은 항목으로 기록하지 않는 것이 중요합니다.
- 중앙 인증: 신규 로그인 차단과 토큰 회수 중 어떤 조치를 수행했는가?
- 앱 계정: 해당 SaaS의 사용자가 비활성화되거나 프로비저닝 해제됐는가?
- 앱 세션: 기존 세션 종료 방법과 적용 범위를 공식 문서에서 확인했는가?
- 직접 로그인: 중앙 인증을 거치지 않는 접근 경로도 처리 대상에 포함했는가?
수동 회수가 반복해서 누락된다면 이번 퇴사 건을 처리하는 것과 별개로 HR 연동, 앱별 담당자, 계정 수명주기 자동화 범위를 재설계할 필요가 있습니다. SSO 도입 여부보다 입사·이동·퇴사 이벤트가 어디까지 연결되는지 살펴보는 다음 단계입니다.
2. 비밀번호 변경을 토큰·인증수단 회수로 대체하지 않는다
Google Workspace의 퇴사자 보안 안내는 비밀번호 변경으로 취소되는 OAuth 2.0 토큰을 일부 제품으로 한정하고, 다른 승인 앱의 접근도 검토해 취소하도록 안내합니다. 따라서 ‘비밀번호를 바꿨으니 연결된 앱의 토큰도 모두 취소됐다’는 완료 기준은 적절하지 않습니다.
같은 안내에는 로그인 쿠키 초기화, 보안 키 및 앱 전용 비밀번호 접근 해제도 별도 항목으로 나옵니다. 점검표에서도 비밀번호, 로그인 쿠키, 승인 앱, 보안 키, 앱 전용 비밀번호를 하나의 ‘인증 초기화’ 체크박스로 합치지 않는 편이 누락을 찾기 쉽습니다.
개인 액세스 토큰(PAT)을 사용하는 서비스는 해당 서비스의 취소 방법과 반영 조건을 따로 기록해야 합니다. 예를 들어 Azure DevOps의 PAT 취소 문서에는 토큰이 비활성화되기까지 최대 한 시간이 걸릴 수 있다고 명시돼 있습니다. 이는 Azure DevOps의 문서상 조건이지, 모든 SaaS에 적용되는 공통 대기시간은 아닙니다.
운영 기준 제안: 취소 요청을 실행한 시각과 효력이 반영됐다고 확인한 시각을 구분해 기록하세요. 지연 조건이 있는 서비스는 요청 직후에 ‘회수 완료’로 닫지 말고 후속 확인 담당자를 지정합니다.
3. 계정 정지와 자료·공유 권한 정리를 별도 작업으로 둔다
Google Workspace의 사용자 정지 안내에 따르면 사용자 정지는 조직 Google 서비스 접근을 일시 차단하지만 이메일·문서·캘린더 데이터를 삭제하지 않습니다. 이미 공유 문서의 접근 권한을 받은 협업자는 열람·편집·협업 권한을 유지합니다.
즉, 퇴사자 계정을 정지했다고 해서 그 사람이 공유했던 문서의 다른 사용자 권한까지 회수되는 것은 아닙니다. 문서 소유권, 외부 사용자 권한, 공유 링크를 각각 검토 대상으로 두고, 유지할 업무 공유와 제거할 공유를 자료 책임자가 판단하도록 설계해야 합니다. 공유 링크의 실제 처리 방식은 사용하는 서비스의 문서와 설정을 기준으로 결정해야 합니다.
Google의 퇴사자 보안 안내는 계정을 완전히 삭제하기 전에 보존하려는 데이터를 다른 계정으로 옮기도록 안내합니다. 따라서 접근 차단, 보존 대상 결정, 소유권 이전, 계정 삭제를 하나의 작업으로 묶지 마세요. 특히 인수인계가 끝나지 않았다는 이유로 퇴사자 접근을 계속 허용하는 것과, 접근을 막은 뒤 관리 절차로 자료를 인계하는 것은 구분할 필요가 있습니다.
- 차단 시점: 인사와 보안 담당자가 정한 시각에 맞춰 접근 회수 작업을 시작합니다.
- 보존·이관: 현업 자료 책임자가 보존할 자료와 인수자를 정하고, 관리자가 가능한 이관 절차를 확인합니다.
- 공유 검토: 외부 협업자와 공유 링크의 유지 필요성을 판단하고, 불필요한 권한의 처리 결과를 남깁니다.
- 삭제 승인: 보존·이관 결과와 조직의 보존 기준을 검토한 뒤 별도로 승인합니다.
문서의 저장 위치와 외부 공유를 함께 정리해야 한다면, 계정 회수 이후에는 저장소별 공유 통제와 감사 범위를 살펴볼 차례입니다. 계정 관리와 문서 관리의 책임 경계를 나누는 데 도움이 됩니다.
4. 서비스별 담당자와 증적을 한 표에 연결한다
다음 표는 제품 기능표가 아니라 조직에서 사용할 수 있는 책임 분담안입니다. 실제 담당 부서명과 검증 방법은 서비스의 관리 권한, 제공 기능, 내부 승인 체계에 맞게 정하면 됩니다. 한 사람이 여러 역할을 맡더라도 실행과 검증 결과는 구분해 남기는 것이 좋습니다.
| 회수·검토 대상 | 책임 분담안 | 남길 기록 | 완료 판단 질문 |
|---|---|---|---|
| 중앙 계정·인증 | 인사가 대상·시점을 확정하고 계정 관리자가 실행 | 대상 계정, 차단·토큰 회수 조치, 실행 시각 | 로그인 차단과 세션 관련 조치를 구분했는가? |
| SaaS 계정·앱 세션 | 각 SaaS 관리자가 실행·검증 | 비활성화·프로비저닝 해제 결과, 세션 처리 범위 | 자동화 대상 밖의 앱과 직접 로그인 경로도 확인했는가? |
| 승인 앱·개인 발급 토큰 | 서비스 관리자가 확인하고 업무 책임자가 연동 영향을 검토 | 토큰·연동 식별자, 취소 시각, 반영 확인 결과 | 비밀번호 변경만으로 완료 처리하지 않았는가? |
| 자료·외부 공유 | 자료 책임자가 유지·회수 판단, 관리자가 처리 | 이관 대상·인수자, 공유 권한 검토 결과 | 사용자 정지와 협업자 권한 정리를 구분했는가? |
| 예외·미완료 항목 | 보안 책임자가 위험을 검토하고 승인권자가 결정 | 사유, 담당자, 기한, 다음 확인 시각 | 미완료가 완료 항목에 섞이지 않았는가? |
공유 문서나 처리 티켓에는 토큰 원문·비밀번호 같은 비밀값을 증적으로 복사하지 말고, 작업 대상과 결과를 식별할 수 있는 정보만 남기는 방식을 권합니다.
5. ‘실행됨’과 ‘회수 확인됨’을 구분해 종료한다
관리자 설정 화면은 어떤 상태로 설정했는지를, 감사로그는 기록된 작업이나 이벤트를 보여줍니다. 이 자료를 모았다는 사실만으로 모든 접근 경로가 차단됐다고 결론 내리기보다, 서비스별로 무엇을 확인했고 무엇이 남았는지를 기록해야 합니다.
감사로그 제공 조건도 서비스마다 확인해야 합니다. 앞서 인용한 Azure DevOps 문서는 Microsoft Entra ID에 연결된 조직에서 권한 변경, 리소스 삭제, 로그 접근 등을 추적하는 감사로그를 사용할 수 있다고 설명합니다. 이를 다른 서비스나 모든 플랜의 제공 조건으로 일반화해서는 안 됩니다.
종료 전에는 다음 네 가지를 확인하세요.
- 대상 누락: 중앙 계정 외에 SaaS 계정, 세션, 승인 앱, 개인 발급 토큰, 공유 권한을 검토했는가?
- 검증 범위: 관리자 상태, 제공되는 감사로그, 허가된 접근 확인 중 무엇으로 결과를 확인했는가?
- 잔여 작업: 반영 지연, 수동 회수, 자료 이관 등 남은 항목에 담당자와 기한이 있는가?
- 중단·문의: 필요한 관리 권한이 없거나 취소 효과가 불명확하면 임의로 완료 처리하지 않고 서비스 관리자 또는 공식 지원에 문의했는가?
온라인 접근권한 회수와 이미 내려받은 자료도 구분해야 합니다. Microsoft Entra 문서는 장치의 원격 삭제에는 인터넷 연결이 필요하고, 오프라인 장치는 로컬 저장 데이터에 계속 접근할 수 있다고 설명합니다. 따라서 SaaS 접근 회수 완료를 로컬 자료까지 사라졌다는 증거로 사용하지 마세요. 장치 반납과 로컬 데이터 처리는 별도 업무로 연결하는 것이 적절합니다.
지금 할 일은 사용 중인 SaaS 목록 옆에 ‘계정·세션·토큰·공유 권한’ 네 칸을 추가하는 것입니다. 각 칸에 담당자, 처리 방법의 공식 근거, 실행 시각, 확인 결과를 적으세요. 퇴사 처리의 빈틈은 ‘계정을 막았는가’라는 단일 질문보다, 누가 어떤 접근 경로를 회수하고 무엇으로 확인했는지를 물을 때 드러납니다.
댓글
댓글 쓰기