Add 바론SSO조직도 관련 검토,md
This commit is contained in:
180
바론SSO조직도 관련 검토,md
Normal file
180
바론SSO조직도 관련 검토,md
Normal file
@@ -0,0 +1,180 @@
|
|||||||
|
# Baron SSO 조직도 관리 개선 제안
|
||||||
|
|
||||||
|
## 1. 제안 목적
|
||||||
|
|
||||||
|
Baron SSO에 접근하는 사내 직원을 조직도 기준으로 관리하고, 조직/직책/재직상태에 따라 접근 권한을 체계적으로 통제한다.
|
||||||
|
|
||||||
|
이번 개선은 단순히 관리자 화면을 추가하는 작업이 아니라, SSO 접근 권한의 기준 데이터를 정비하고 향후 자동 권한 관리로 확장하기 위한 기반 작업이다.
|
||||||
|
|
||||||
|
## 2. 기본 방향
|
||||||
|
|
||||||
|
- Baron SSO 접근 사용자를 조직도 기준으로 식별한다.
|
||||||
|
- 재직상태, 부서, 직책, 권한 그룹을 기준으로 로그인 가능 여부와 서비스 접근 범위를 관리한다.
|
||||||
|
- 조직도 원천 데이터는 하나의 기준 시스템에서 가져오는 것을 원칙으로 한다.
|
||||||
|
- 초기에는 수동 관리 또는 파일 업로드 방식으로 시작하고, 이후 API 또는 배치 동기화 방식으로 확장한다.
|
||||||
|
- 모든 권한 변경과 로그인 이력은 감사 로그로 남긴다.
|
||||||
|
|
||||||
|
## 3. 단계별 추진안
|
||||||
|
|
||||||
|
### 3.1 현재 사용자 기준 정리
|
||||||
|
|
||||||
|
먼저 현재 Baron SSO에 접근 가능한 사용자 목록을 정리한다.
|
||||||
|
|
||||||
|
관리 대상 항목은 다음과 같다.
|
||||||
|
|
||||||
|
- 사번
|
||||||
|
- 이름
|
||||||
|
- 이메일
|
||||||
|
- 부서
|
||||||
|
- 직급
|
||||||
|
- 직책
|
||||||
|
- 재직상태
|
||||||
|
- SSO 권한
|
||||||
|
- 최종 로그인일
|
||||||
|
|
||||||
|
이 단계에서는 퇴사자, 휴직자, 부서 미지정자, 중복 계정, 공용 계정을 식별한다.
|
||||||
|
|
||||||
|
산출물은 `현재 SSO 사용자 현황표`로 관리한다.
|
||||||
|
|
||||||
|
### 3.2 조직도 기준 데이터 정의
|
||||||
|
|
||||||
|
Baron SSO에서 사용할 조직도 기준 항목을 정의한다.
|
||||||
|
|
||||||
|
최소 관리 항목은 다음과 같다.
|
||||||
|
|
||||||
|
- 회사
|
||||||
|
- 본부
|
||||||
|
- 부서
|
||||||
|
- 팀
|
||||||
|
- 상위부서
|
||||||
|
- 부서장
|
||||||
|
- 사번
|
||||||
|
- 이름
|
||||||
|
- 이메일
|
||||||
|
- 직급
|
||||||
|
- 직책
|
||||||
|
- 재직상태
|
||||||
|
|
||||||
|
이때 권한 제어에 필요한 항목과 단순 조회용 항목을 분리한다.
|
||||||
|
|
||||||
|
예를 들어 `부서`, `직책`, `재직상태`는 권한 판단에 직접 사용할 수 있고, `직급`은 감사 또는 조회 목적으로만 사용할 수 있다.
|
||||||
|
|
||||||
|
### 3.3 조직도 원천 시스템 결정
|
||||||
|
|
||||||
|
조직도와 직원 정보의 원천 시스템을 결정한다.
|
||||||
|
|
||||||
|
후보는 다음과 같다.
|
||||||
|
|
||||||
|
- 인사 시스템
|
||||||
|
- 그룹웨어
|
||||||
|
- ERP
|
||||||
|
- AD/LDAP
|
||||||
|
- 별도 조직도 관리 시스템
|
||||||
|
|
||||||
|
핵심 원칙은 조직도 원본을 하나만 두는 것이다.
|
||||||
|
|
||||||
|
Baron SSO가 직접 조직도를 독립적으로 관리하기보다는, 원천 시스템의 조직/직원 정보를 받아와 동기화하는 방식이 안정적이다.
|
||||||
|
|
||||||
|
원천 시스템 연동이 당장 어렵다면 초기에는 관리자 업로드 방식으로 시작할 수 있다.
|
||||||
|
|
||||||
|
### 3.4 조직도 동기화 방식 설계
|
||||||
|
|
||||||
|
초기 단계에서는 CSV 또는 Excel 업로드 방식으로 시작하고, 이후 API 또는 배치 동기화로 확장한다.
|
||||||
|
|
||||||
|
권장 흐름은 다음과 같다.
|
||||||
|
|
||||||
|
```text
|
||||||
|
인사/조직도 시스템
|
||||||
|
-> 직원/부서 정보 동기화
|
||||||
|
-> Baron SSO 사용자/조직 테이블 반영
|
||||||
|
-> SSO 로그인 시 재직상태와 권한 확인
|
||||||
|
```
|
||||||
|
|
||||||
|
동기화 주기는 다음 기준으로 제안한다.
|
||||||
|
|
||||||
|
- 초기: 1일 1회 배치
|
||||||
|
- 안정화 이후: 수시 배치 또는 API 연동
|
||||||
|
- 보안 중요 이벤트: 퇴사자, 관리자 권한 변경 등은 가능한 빠르게 반영
|
||||||
|
|
||||||
|
### 3.5 접근 권한 정책 정의
|
||||||
|
|
||||||
|
조직도 관리는 최종적으로 SSO 접근 권한 정책과 연결되어야 한다.
|
||||||
|
|
||||||
|
기본 정책 예시는 다음과 같다.
|
||||||
|
|
||||||
|
```text
|
||||||
|
재직자: SSO 로그인 가능
|
||||||
|
퇴사자: 로그인 즉시 차단
|
||||||
|
휴직자: 기본 차단 또는 별도 예외 승인
|
||||||
|
부서 미지정자: 제한 권한 부여
|
||||||
|
특정 부서: 특정 서비스 접근 허용
|
||||||
|
관리자 권한: 직책 또는 별도 승인 기준으로 부여
|
||||||
|
```
|
||||||
|
|
||||||
|
관리자 권한은 부서 정보만으로 자동 부여하지 않는 것이 안전하다.
|
||||||
|
|
||||||
|
관리자 권한은 조직도 정보와 별도 승인 이력을 함께 기준으로 판단하는 것을 권장한다.
|
||||||
|
|
||||||
|
### 3.6 관리자 화면 구성
|
||||||
|
|
||||||
|
초기 관리자 화면은 복잡한 조직도 편집 기능보다 SSO 접근 통제에 필요한 조회와 상태 확인 중심으로 구성한다.
|
||||||
|
|
||||||
|
우선 구현 대상은 다음과 같다.
|
||||||
|
|
||||||
|
- 직원 목록 조회
|
||||||
|
- 부서별 사용자 조회
|
||||||
|
- 사용자 상세 정보 확인
|
||||||
|
- 재직상태별 필터
|
||||||
|
- SSO 접근 가능/불가 상태 표시
|
||||||
|
- 권한 그룹 매핑
|
||||||
|
- 조직도 동기화 이력 조회
|
||||||
|
- 수동 예외 권한 등록
|
||||||
|
|
||||||
|
팀장 보고 시에는 단순한 `조직도 화면`이 아니라 `SSO 접근 통제 화면`으로 설명하는 것이 적절하다.
|
||||||
|
|
||||||
|
### 3.7 감사 로그와 이력 관리
|
||||||
|
|
||||||
|
SSO는 보안 영역이므로 변경 이력과 접근 이력을 반드시 남겨야 한다.
|
||||||
|
|
||||||
|
필수 로그 항목은 다음과 같다.
|
||||||
|
|
||||||
|
- 로그인 성공 이력
|
||||||
|
- 로그인 실패 이력
|
||||||
|
- 퇴사자 로그인 시도 이력
|
||||||
|
- 조직 정보 변경 이력
|
||||||
|
- 권한 변경 이력
|
||||||
|
- 관리자 수동 변경 이력
|
||||||
|
- 동기화 성공/실패 이력
|
||||||
|
|
||||||
|
감사 로그는 보안 사고 대응, 내부 감사, 권한 변경 원인 추적에 활용할 수 있다.
|
||||||
|
|
||||||
|
## 4. 우선순위
|
||||||
|
|
||||||
|
가장 먼저 진행해야 할 작업은 다음 세 가지다.
|
||||||
|
|
||||||
|
1. 현재 SSO 사용자 목록 정리
|
||||||
|
2. 재직상태 기준 로그인 허용/차단 정책 확정
|
||||||
|
3. 조직도 원천 데이터 결정
|
||||||
|
|
||||||
|
이 세 가지가 결정되면 관리자 화면, 조직도 동기화, 권한 그룹 관리 작업을 순차적으로 진행할 수 있다.
|
||||||
|
|
||||||
|
## 5. 후속 진행 작업
|
||||||
|
|
||||||
|
후속 작업은 다음 순서로 진행하는 것을 제안한다.
|
||||||
|
|
||||||
|
1. 현재 SSO 사용자 현황 추출
|
||||||
|
2. 조직도 기준 항목 정의
|
||||||
|
3. 인사/조직도 원천 시스템 확인
|
||||||
|
4. 사용자-조직 매핑 테이블 설계
|
||||||
|
5. 퇴사자/휴직자 로그인 차단 정책 적용
|
||||||
|
6. 관리자 조회 화면 추가
|
||||||
|
7. 조직도 동기화 배치 또는 API 구현
|
||||||
|
8. 권한 변경 및 로그인 감사 로그 보강
|
||||||
|
|
||||||
|
## 6. 기대 효과
|
||||||
|
|
||||||
|
- 퇴사자 또는 휴직자의 SSO 접근을 빠르게 차단할 수 있다.
|
||||||
|
- 부서 이동이나 조직 변경에 따른 권한 정리를 체계화할 수 있다.
|
||||||
|
- 관리자 권한 부여 기준을 명확히 할 수 있다.
|
||||||
|
- SSO 접근 이력과 권한 변경 이력을 감사 관점에서 추적할 수 있다.
|
||||||
|
- 향후 자동 권한 관리와 서비스별 접근 제어로 확장할 수 있다.
|
||||||
Reference in New Issue
Block a user