기업 SaaS 계정 생성·회수 자동화하는 법
- 인사 시스템을 사용자 상태의 기준 원장으로 정합니다.
- 부서와 직무별 그룹으로 SaaS 계정을 자동 할당합니다.
- 퇴사 후 세션·토큰과 비연동 앱까지 회수 여부를 검증합니다.
기업 SaaS 계정 자동화의 핵심은 인사 시스템의 입사·이동·퇴사 정보를 기준 원장으로 삼고, 이를 아이덴티티 제공자(IdP, 사용자 인증과 계정을 중앙 관리하는 시스템)와 SaaS에 전달하는 것입니다. 계정 생성은 직무와 소속 그룹을 기준으로 필요한 앱만 할당하고, 퇴사 때는 로그인 차단과 앱 권한·세션·토큰 회수를 별도로 확인해야 합니다. 싱글 사인온(SSO, 한 번의 인증으로 여러 서비스에 로그인하는 방식)만 도입해도 SaaS 계정이 모두 자동 생성·삭제되는 것은 아닙니다.
자동화의 출발점은 사용자 원장과 권한 기준입니다
사람 상태와 앱 권한의 기준을 정하세요
인사 시스템(HRIS) 또는 승인된 사용자 디렉터리 중 어디가 재직 상태, 입사일, 부서, 직무, 고용 형태를 확정하는지 먼저 정합니다. 같은 정보를 여러 시스템에서 수동 수정하면 퇴사 처리가 한쪽에만 반영되거나 권한이 다시 살아나는 불일치가 생길 수 있습니다. 계정의 고유 식별자는 이메일 주소보다 변경 가능성이 낮은 사번 또는 디렉터리 객체 ID를 우선 검토하고, 이메일과 이름은 속성으로 관리합니다.
역할과 그룹에 앱 접근을 연결하세요
부서·직무·프로젝트별 접근 그룹을 만들고, 각 그룹이 어떤 SaaS와 라이선스 등급을 받는지 앱 소유자와 합의합니다. 기본 그룹에는 업무에 필요한 최소 권한만 넣고, 관리자 역할이나 민감 데이터 접근은 별도 승인과 만료일을 둡니다. 개인별 예외 권한은 사유, 승인자, 만료일을 기록해야 이동이나 퇴사 때 찾아 회수할 수 있습니다.
기억할 기준: 계정 생성 자동화와 로그인 통합은 서로 다른 흐름입니다. SSO 연결 여부만으로 대상 SaaS의 계정 생성·비활성화가 완료됐다고 판단하지 마세요.
계정 생성부터 회수까지 실제 적용 순서
1단계: 사용자 이벤트와 필수 속성을 정리합니다
입사, 부서 이동, 휴직, 퇴사 이벤트를 정의하고 이벤트마다 필요한 속성과 승인자를 정합니다. 입사일 전 선행 생성이 필요한 앱은 예약 프로비저닝으로 처리하되, 실제 업무 시작 전까지 로그인을 제한할지 결정합니다. 이동 이벤트에서는 새 권한을 더하는 것뿐 아니라 이전 부서의 그룹과 관리자 역할을 제거하는 규칙도 함께 설계합니다.
2단계: IdP 그룹과 SaaS 프로비저닝을 연결합니다
표준 연동이 가능한 앱은 SCIM(System for Cross-domain Identity Management, 서비스 간 사용자·그룹 정보를 주고받는 표준 프로토콜) 지원 범위와 생성·수정·비활성화 동작을 확인한 뒤 연결합니다. 앱마다 지원 속성, 그룹 동기화, 비활성화 의미가 다를 수 있습니다. SCIM 미지원 앱은 공식 API, 관리 콘솔 작업 큐 또는 승인된 수동 절차로 보완하고, 이 예외 목록을 중앙에서 관리합니다. RFC 7644 SCIM 표준과 Microsoft Entra 직원 라이프사이클 자동화 안내를 연동 설계의 출발 자료로 참고할 수 있습니다.
3단계: 퇴사 이벤트에 차단·회수 작업을 연결합니다
퇴사 승인 이벤트가 발생하면 정해진 시점에 IdP 로그인을 차단하고, SaaS 그룹·역할·라이선스와 세션을 회수하는 작업을 실행합니다. 앱 계정 비활성화만으로 기존 세션이나 개인이 발급한 API 키가 폐기되는지 단정할 수 없으므로 앱별 동작을 확인하세요. 공유 계정, 서비스 계정, 자동화 봇, OAuth 토큰과 API 키는 개인 계정과 별도 소유자를 두고 교체·폐기 절차를 지정합니다.
4단계: 완료 응답을 검증하고 실패를 재처리합니다
작업 요청이 성공했다는 응답만으로 끝내지 말고 대상 앱에서 계정 비활성화, 그룹 제거, 세션 종료가 실제 반영됐는지 확인합니다. API 오류, 동기화 지연, 권한 부족은 재시도 횟수와 담당자 에스컬레이션 기준을 정해 미처리 큐로 보냅니다. 인사 이벤트 ID, 대상 계정 ID, 앱, 실행 시각, 결과 코드, 재처리 이력을 연결하면 한 건의 퇴사 처리가 어디서 막혔는지 추적하기 쉽습니다.
- 입사·이동·퇴사 이벤트를 원장에서 확인합니다.
- 규칙에 따라 그룹과 대상 SaaS 작업을 실행합니다.
- 앱별 결과와 세션·토큰 회수 여부를 검증합니다.
- 실패 건을 담당자에게 알리고 재처리 결과를 기록합니다.
SSO·SCIM만으로 놓칠 수 있는 접근 경로
SSO는 인증 경로를 통제하지만, 앱 자체 계정이나 로컬 로그인, 별도 발급 토큰까지 자동으로 관리한다고 보장하지 않습니다. SCIM도 공급자와 앱의 구현에 따라 비활성화 방식과 반영 시점이 달라질 수 있습니다. 따라서 앱 목록에 연동 방식과 회수 방법을 기록하고, 중요 앱은 테스트 계정으로 입사·이동·퇴사 시나리오를 각각 확인해야 합니다.
- 비연동 SaaS: 부서 자체 결제 앱, 초대 기반 계정, 로컬 비밀번호 로그인을 확인합니다.
- 잔존 자격 증명: API 키, 개인 액세스 토큰, OAuth 승인, 앱 비밀번호와 활성 세션을 점검합니다.
- 업무 연속성 예외: 인수인계가 필요하면 퇴사자 계정을 공유하지 말고, 승인된 담당자에게 제한된 역할을 새로 부여합니다.
- 데이터 소유권: 퇴사자 개인 공간의 파일·대시보드·워크플로 소유권 이전과 보존 기준을 정합니다.
운영 지표와 감사 기록을 남기는 방법
자동화가 잘 작동하는지는 계정 생성 성공률만으로 판단하기 어렵습니다. 입사일 기준 첫날 접근 준비 여부, 퇴사 이벤트부터 차단까지 걸린 시간, 앱별 회수 실패 건수와 미처리 시간, 발견된 미승인 SaaS 수를 함께 살펴보세요. 라이선스 회수와 사용률 확인은 기업 SaaS 라이선스 사용률 계산법과 연결해 비용 관리에도 활용할 수 있습니다.
감사 기록에는 요청을 만든 이벤트, 승인자, 자동화 규칙 버전, 대상 앱과 계정 식별자, 실행 결과, 재시도 및 예외 승인 근거를 포함합니다. 로그 보관·접근 정책은 업무상 필요한 담당자만 열람하도록 하고, 개인정보가 불필요하게 복제되지 않게 설계하세요. 개인정보 처리 시스템의 접속기록 기준이 적용되는 환경이라면 개인정보 접속기록 보관 기간과 이상행위 점검 방법도 확인할 수 있습니다.
| 대상 | 자동화 기준 | 완료 확인 |
|---|---|---|
| 입사자 | 직무·부서 그룹에 따른 최소 앱 할당 | 대상 앱 계정과 로그인 가능 여부 |
| 부서 이동 | 새 그룹 추가와 이전 권한 제거 | 이전 관리자·민감 권한 잔존 여부 |
| 퇴사자 | 로그인 차단과 앱·세션·토큰 회수 | 앱 응답, 미처리 큐, 예외 기록 |
주의: 자동화 작업의 성공 로그와 실제 접근 차단은 같은 증거가 아닙니다. 중요 SaaS는 대상 앱에서 회수 상태를 확인하고 실패 시 담당자가 처리하도록 운영하세요.
자주 묻는 질문
Q. SSO를 도입하면 퇴사자 SaaS 계정도 자동 삭제되나요?
아닙니다. SSO는 주로 인증을 연결합니다. 계정 비활성화나 삭제, 그룹·라이선스 회수는 SCIM이나 앱 API 등 별도 프로비저닝 연동과 검증이 필요합니다.
Q. 모든 SaaS에 SCIM을 적용해야 하나요?
모든 앱이 SCIM을 지원하거나 같은 기능을 제공하는 것은 아닙니다. 지원 여부와 비활성화 동작을 확인하고, 미지원 앱은 API나 통제된 수동 작업으로 보완해 예외와 완료 증거를 관리하세요.
Q. 퇴사자의 계정을 삭제하는 대신 비활성화해도 되나요?
보존할 데이터와 재사용 가능한 계정 정책, 앱의 비활성화 의미에 따라 달라집니다. 우선 인증과 접근을 차단하고, 데이터 소유권 이전과 보존 기준을 적용한 뒤 삭제 여부를 결정하세요.
Q. 자동화가 실패하면 어떻게 대응해야 하나요?
실패를 미처리 큐와 담당자 알림으로 연결하고, 재시도와 수동 회수 절차를 마련하세요. 특히 민감 데이터 접근 앱은 대상 앱에서 차단 여부를 확인한 뒤 사건 ID와 처리 결과를 기록해야 합니다.
