805 lines
42 KiB
Markdown
805 lines
42 KiB
Markdown
# Baron SSO 조직도 관리 개선 제안 - 기존 정책 통합 반영본
|
|
|
|
## 문서 요약
|
|
|
|
이 문서는 Baron SSO를 단순 로그인 시스템이 아니라 여러 자회사의 조직도, 직원 상태, 서비스 접근 권한을 통합 관리하는 기준 시스템으로 확장하기 위한 제안서다.
|
|
|
|
주요 내용은 다음과 같다.
|
|
|
|
> 이 문서는 현재 Baron SSO에 이미 존재하는 `Tenant`, `UserGroup`, `Keto ReBAC`, `OrgFront`, `AdminFront`, outbox 정책을 전제로 한다.
|
|
> 특히 아래 항목들은 기존 정책을 대체하는 내용이 아니라, 기존 정책 위에 추가로 제안하는 개선안이다.
|
|
|
|
- 여러 자회사는 `COMPANY` 테넌트로 구분하되, 실제 업무 조직은 `COMPANY_GROUP` 하위의 논리 조직 테넌트로도 관리할 수 있게 한다.
|
|
- 조직도는 부서/팀에 고정하지 않고 본부, 부문, 부서, 팀, 셀 등 유연한 조직 단위 계층으로 관리한다.
|
|
- 본부장, 부문장, 부서장, 팀장, 셀장 같은 조직장 역할은 Keto의 `owners/admins/members` 관계와 회사별 표시 정책을 조합해 선택적으로 관리한다.
|
|
- 조직 변경은 권한이 있는 담당자만 요청할 수 있고, 승인 후 Baron DB와 Keto outbox를 먼저 정합화한 뒤 각 회사 DB 또는 외부 Directory에 제한적으로 반영한다.
|
|
- 각 회사 DB 컬럼 구조가 다르므로 회사별 조직 매핑 정책과 외부 반영 어댑터를 둔다.
|
|
- 회원가입은 각 회사 인사 DB의 발령상태와 재직상태를 기준으로 허용 여부를 판단한다.
|
|
- SSO 로그인 가능 여부와 실제 업무 시스템 접근 가능 여부를 분리하여 관리한다.
|
|
- 직원 사진은 원본을 각 회사에 두고 SSO는 표준 썸네일과 메타데이터만 관리하는 방안을 권장한다.
|
|
- 완성된 조직도는 링크, 임베드, 이미지 형태로 인트라넷이나 모바일 페이지에 표시할 수 있게 한다.
|
|
- 모든 조직 변경, 권한 변경, 로그인, 사진 조회, 외부 표시 이력은 감사 로그로 남긴다.
|
|
|
|
## 목차
|
|
|
|
1. [제안 목적](#1-제안-목적)
|
|
2. [기본 방향](#2-기본-방향)
|
|
3. [단계별 추진안](#3-단계별-추진안)
|
|
- [현재 사용자 기준 정리](#31-현재-사용자-기준-정리)
|
|
- [조직도 기준 데이터 정의](#32-조직도-기준-데이터-정의)
|
|
- [조직도 원천 시스템 결정](#33-조직도-원천-시스템-결정)
|
|
- [회사별 조직도 관리 화면 설계](#34-회사별-조직도-관리-화면-설계)
|
|
- [조직장 역할 관리 방안](#35-조직장-역할-관리-방안)
|
|
- [조직도 UI 오픈소스 적용 방안](#36-조직도-ui-오픈소스-적용-방안)
|
|
- [조직도 공유 및 외부 표시 방안](#37-조직도-공유-및-외부-표시-방안)
|
|
- [직원 사진 관리 및 표시 방안](#38-직원-사진-관리-및-표시-방안)
|
|
- [조직도 변경 권한 정책 정의](#39-조직도-변경-권한-정책-정의)
|
|
- [조직도 동기화 및 DB 반영 방식 설계](#310-조직도-동기화-및-db-반영-방식-설계)
|
|
- [회원가입 정책 정의](#311-회원가입-정책-정의)
|
|
- [SSO 로그인 및 서비스별 접근 권한 정책 정의](#312-sso-로그인-및-서비스별-접근-권한-정책-정의)
|
|
- [서비스별 접근 권한 관리자 기능](#313-서비스별-접근-권한-관리자-기능)
|
|
- [관리자 화면 구성](#314-관리자-화면-구성)
|
|
- [감사 로그와 이력 관리](#315-감사-로그와-이력-관리)
|
|
4. [우선순위](#4-우선순위)
|
|
5. [후속 진행 작업](#5-후속-진행-작업)
|
|
6. [기대 효과](#6-기대-효과)
|
|
7. [참고 오픈소스 후보](#7-참고-오픈소스-후보)
|
|
## 0. 현재 Baron SSO 정책/구현과의 정합성 요약
|
|
|
|
현재 Baron SSO 소스와 문서에는 조직도 관련 기반이 이미 존재한다. 따라서 본 제안은 별도 신규 조직도 시스템을 처음부터 만드는 방향이 아니라,
|
|
기존 `Tenant`, `UserGroup`, `Keto ReBAC`, `OrgFront`, `AdminFront`, outbox 구조를 확장하는 방향으로 정리한다.
|
|
|
|
확인된 기존 기준은 다음과 같다.
|
|
|
|
- 조직 단위는 기본적으로 `Tenant`로 표현한다.
|
|
- 법인/회사 구분은 `COMPANY`, 그룹사는 `COMPANY_GROUP`, 사내 논리 조직은 `USER_GROUP` 또는 현재 코드의 `ORGANIZATION` 타입을 사용한다.
|
|
- 조직 계층은 `Tenant.parentId`와 Keto의 `Tenant:<child>#parents@Tenant:<parent>` 관계로 표현한다.
|
|
- 조직 구성원은 `Tenant:<groupId>#members@User:<userId>` 관계로 표현한다.
|
|
- 조직장/관리자는 `owners`, `admins` 관계를 사용하고, 권한 검증은 Keto ReBAC를 기준으로 한다.
|
|
- 변경 이벤트는 즉시 외부 시스템에 직접 쓰기보다 Baron DB와 outbox에 기록한 뒤 비동기 동기화하는 구조를 우선한다.
|
|
- `OrgFront`는 조직도 표시 계층이고, 조직도 데이터는 Backend API에서 취합해 제공한다.
|
|
- 외부 시스템 연동은 Worksmobile 연동처럼 회사/테넌트 단위 설정과 outbox 기반 동기화 방식을 따르는 것이 기존 방향과 맞다.
|
|
|
|
따라서 이 문서에서 말하는 `회사별 조직도 관리`는 모든 조직을 반드시 각 법인 하위에만 둔다는 뜻이 아니다. 법인 소속은 사용자 속성으로 유지하면서, 여러 법인 직원이 같은 논리 조직에 속할 수 있는 매트릭스 조직 구조도 허용한다. 회사별 담당자는 자신에게 부여된 `Tenant manage/view` 권한 범위 안에서 해당 조직 또는 하위 조직을 관리한다.
|
|
### 0.1 기존 정책 대비 추가 제안 핵심
|
|
|
|
아래 항목은 현재 Baron SSO 정책을 확인한 뒤, 그 정책에 반하지 않는 선에서 추가로 제안하는 개선 사항이다.
|
|
|
|
| 구분 | 현재 Baron SSO 정책/구현 | 추가 제안 방향 |
|
|
| --- | --- | --- |
|
|
| 조직 모델 | 조직 단위를 `Tenant`, `UserGroup`, `ORGANIZATION` 개념으로 표현 | 회사별/그룹사별 조직관리 화면에서 `본부/부문/부서/팀/셀` 등 표시 정책을 명확화 |
|
|
| 매트릭스 조직 | 법인 소속과 논리 조직을 분리할 수 있는 정책 존재 | 여러 자회사 직원이 같은 논리 조직에 속하는 경우를 공식 운영 시나리오로 반영 |
|
|
| 조직장 | Keto `owners/admins/members` 관계로 권한 표현 가능 | `본부장/부문장/부서장/팀장/셀장` 같은 화면 표시명과 승인 역할 정책 추가 |
|
|
| 조직 변경 | `Tenant.parentId`, Keto `parents`, outbox 기반 동기화 구조 존재 | 변경 요청, 승인/반려, 변경 전후 비교, 외부 DB 반영 미리보기 프로세스 추가 |
|
|
| 외부 반영 | Worksmobile 동기화 구조 존재 | 각 자회사 인사 DB 컬럼 구조별 매핑 어댑터를 추가 제안 |
|
|
| 조직도 표시 | OrgFront, public orgchart, embed picker 기반 존재 | 인트라넷/모바일용 링크, iframe, 이미지 내보내기 운영 정책 보강 |
|
|
| 사용자 상태 | `active`, `suspended`, `temporary_leave`, `preboarding`, `archived` 등 상태 정책 존재 | 상태별 SSO 로그인 가능 여부와 서비스별 접근 가능 여부를 분리 관리 |
|
|
| 직원 사진 | 조직도 사진 정책은 명확히 확인되지 않음 | 원본은 각 회사 보관, SSO는 표준 썸네일/메타데이터만 관리하는 정책 추가 |
|
|
| 관리자 화면 | AdminFront에 조직/멤버/권한 관리 기능 일부 존재 | 조직 담당자 전용 승인 화면, 정책 관리 화면, 감사 이력 화면을 추가 제안 |
|
|
|
|
이 표의 `추가 제안 방향`은 현재 구현을 부정하는 것이 아니라, 기존 구조를 운영 가능한 수준으로 구체화하기 위한 보강안이다.
|
|
|
|
## 1. 제안 목적
|
|
|
|
Baron SSO에 접근하는 사내 직원을 회사별 조직도 기준으로 관리하고, 조직/직책/재직상태에 따라 접근 권한을 체계적으로 통제한다.
|
|
|
|
이번 개선은 단순히 관리자 화면을 추가하는 작업이 아니라, 여러 자회사의 조직도와 인사정보를 SSO 접근 관리 기준으로 정비하고 향후 자동 권한 관리로 확장하기 위한 기반 작업이다.
|
|
|
|
또한 각 회사의 인사담당자 또는 조직관리 담당자가 회사별 조직도를 시각적으로 관리하고, 승인된 조직 변경 사항을 각 회사 DB의 조직 귀속 정보에 제한적으로 반영하는 방안까지 함께 검토한다.
|
|
|
|
단, Baron SSO가 각 회사 인사 DB의 원장을 대체하지 않는다. Baron SSO는 인증/인가와 조직 표시, 권한 판단에 필요한 read model과 관계 정보를 관리하고, 원천 인사정보와 외부 Directory 반영은 회사별 정책과 동기화 어댑터를 통해 제한적으로 처리한다.
|
|
|
|
## 2. 기본 방향
|
|
|
|
- Baron SSO 접근 사용자를 조직도 기준으로 식별한다.
|
|
- 여러 자회사를 회사 테넌트로 구분하되, 실제 업무 조직은 회사 하위 또는 그룹사 하위 논리 조직으로 유연하게 구성한다.
|
|
- 조직도는 본부, 부문, 부서, 팀, 셀 등 조직 단위의 계층 구조로 시각화하고, 권한이 있는 담당자만 수정할 수 있게 한다.
|
|
- 재직상태, 부서, 직책, 권한 그룹을 기준으로 로그인 가능 여부와 서비스 접근 범위를 관리한다.
|
|
- 조직도 원천 데이터는 회사별 인사정보 또는 조직관리 DB를 기준으로 하되, SSO에서는 접근 통제에 필요한 조직 정보를 통합 관리한다.
|
|
- 조직도 변경 사항은 검증과 승인 절차를 거친 뒤 Baron DB/Keto 관계를 먼저 갱신하고, 필요한 경우 각 회사 DB 또는 외부 Directory에 반영한다.
|
|
- 각 회사 DB 반영 대상은 개인정보 전체가 아니라 조직단위코드, 상위조직코드, 직책코드, 소속상태 같은 조직 귀속 정보로 제한한다.
|
|
- 초기에는 CSV 업로드와 기존 AdminFront 관리 기능을 보강하는 방식으로 시작하고, 이후 회사별 API 또는 배치 동기화 방식으로 확장한다.
|
|
- 모든 권한 변경과 로그인 이력은 감사 로그로 남긴다.
|
|
|
|
## 3. 단계별 추진안
|
|
|
|
### 3.1 현재 사용자 기준 정리
|
|
|
|
먼저 현재 Baron SSO에 접근 가능한 사용자 목록을 정리한다.
|
|
|
|
관리 대상 항목은 다음과 같다.
|
|
|
|
- 사번
|
|
- 이름
|
|
- 이메일
|
|
- 부서
|
|
- 직급
|
|
- 직책
|
|
- 재직상태
|
|
- SSO 권한
|
|
- 최종 로그인일
|
|
- 소속 회사
|
|
- 부서코드
|
|
- 팀코드
|
|
- 조직단위코드
|
|
- 상위조직코드
|
|
- 사진 보유 여부
|
|
- 사진 갱신일
|
|
|
|
이 단계에서는 퇴사자, 휴직자, 부서 미지정자, 중복 계정, 공용 계정을 식별한다.
|
|
|
|
산출물은 `현재 SSO 사용자 현황표`로 관리한다.
|
|
|
|
### 3.2 조직도 기준 데이터 정의
|
|
|
|
Baron SSO에서 사용할 조직도 기준 항목을 정의한다. 이 항목은 기존 `Tenant/UserGroup` 모델을 대체하는 신규 원장이 아니라, 기존 모델에 어떤 값을 매핑하고 어떤 운영 정책을 추가할지 정리하기 위한 제안이다. 기존 정책에 맞춰 조직 단위의 저장 기준은 `Tenant`이며, 표시와 운영 메타데이터는 `user_groups` 또는 `Tenant.config`로 확장하는 방향을 우선한다.
|
|
|
|
최소 관리 항목은 다음과 같다.
|
|
|
|
- 회사
|
|
- 본부
|
|
- 부문
|
|
- 부서
|
|
- 부서코드
|
|
- 팀
|
|
- 팀코드
|
|
- 셀
|
|
- 셀코드
|
|
- 조직단위코드
|
|
- 조직단위유형
|
|
- 상위조직코드
|
|
- 조직장
|
|
- 사번
|
|
- 이름
|
|
- 이메일
|
|
- 직급
|
|
- 직책
|
|
- 직책코드
|
|
- 재직상태
|
|
- 발령상태
|
|
- 입사일
|
|
- 퇴사일
|
|
- 사진 파일 식별자
|
|
- 사진 버전
|
|
- 사진 갱신일
|
|
|
|
이때 권한 제어에 필요한 항목과 단순 조회용 항목을 분리한다.
|
|
|
|
예를 들어 `회사`, `조직단위코드`, `상위조직코드`, `직책코드`, `재직상태`, `발령상태`는 권한 판단과 각 회사 DB 반영에 직접 사용할 수 있고, `직급`은 감사 또는 조회 목적으로만 사용할 수 있다.
|
|
|
|
조직도는 부서/팀으로 고정하지 않고, 회사별 조직 레벨을 설정할 수 있게 한다.
|
|
|
|
예시는 다음과 같다.
|
|
|
|
```text
|
|
회사 -> 본부 -> 부문 -> 부서 -> 팀 -> 셀
|
|
회사 -> 사업부 -> 부서 -> 파트
|
|
회사 -> 센터 -> 그룹 -> 팀
|
|
```
|
|
|
|
이를 위해 조직 단위는 공통적으로 다음 구조를 가진다. 실제 구현에서는 신규 테이블을 우선 만들기보다 기존 `Tenant.id`, `Tenant.parentId`, `Tenant.type`, `Tenant.config.orgUnitType` 및 `user_groups.unitType`과 매핑한다.
|
|
|
|
| 항목 | 설명 |
|
|
| --- | --- |
|
|
| 조직단위코드 | 회사 내에서 조직 단위를 식별하는 코드 |
|
|
| 조직단위명 | 화면에 표시할 조직명 |
|
|
| 조직단위유형 | 본부, 부문, 부서, 팀, 셀, 파트 등 |
|
|
| 상위조직코드 | 계층 구조를 만들기 위한 상위 조직 코드 |
|
|
| 회사코드 | 조직 단위가 속한 회사 |
|
|
| 조직장 사용자 ID | 해당 조직 단위의 책임자 |
|
|
| 사용 여부 | 폐지된 조직인지 여부 |
|
|
|
|
조직장 역할은 조직단위유형에 따라 화면 표시명을 자동 해석할 수 있다. 권한상 조직장은 별도 문자열 역할보다 Keto `owners` 또는 `admins` 관계를 기준으로 판단한다.
|
|
|
|
예를 들어 조직단위유형이 `본부`이면 조직장은 `본부장`, `부문`이면 `부문장`, `팀`이면 `팀장`, `셀`이면 `셀장`으로 표시할 수 있다.
|
|
|
|
### 3.3 조직도 원천 시스템 결정
|
|
|
|
조직도와 직원 정보의 원천 시스템을 회사별로 결정한다.
|
|
|
|
후보는 다음과 같다.
|
|
|
|
- 인사 시스템
|
|
- 그룹웨어
|
|
- ERP
|
|
- AD/LDAP
|
|
- 별도 조직도 관리 시스템
|
|
|
|
핵심 원칙은 각 회사별 조직도 원본을 명확히 정하는 것이다.
|
|
|
|
Baron SSO가 모든 회사의 인사 원장을 대체하는 구조는 위험하며, 기존 Baron 정책상 Kratos는 인증 주체, Backend DB는 read model, Keto는 권한 관계 원장으로 역할을 분리해야 한다. 따라서 SSO에서는 접근 통제에 필요한 조직 정보를 관리하고, 실제 회사별 인사정보 변경은 정해진 항목에 한해 각 회사 DB와 연동하는 방식이 안정적이다.
|
|
|
|
원천 시스템 연동이 당장 어렵다면 초기에는 관리자 업로드 방식으로 시작할 수 있다.
|
|
|
|
### 3.4 회사별 조직도 관리 화면 설계
|
|
|
|
조직도는 회사별로 분리하여 조회하고 관리한다.
|
|
|
|
화면은 회사별 조직 단위의 계층 구조를 한눈에 볼 수 있도록 트리 또는 조직도 형태로 제공한다.
|
|
|
|
주요 기능은 다음과 같다.
|
|
|
|
- 회사별 조직도 조회
|
|
- 조직 단위 생성, 수정, 이동
|
|
- 조직 단위 유형 관리
|
|
- 상위 조직 변경
|
|
- 직원의 소속 조직 이동
|
|
- 변경 전/후 비교
|
|
- 변경사항 임시 저장
|
|
- 승인 후 각 회사 DB 반영
|
|
- 반영 성공/실패 결과 확인
|
|
|
|
이 화면은 단순 조직도 조회 화면이 아니라 `조직 귀속 정보 관리 화면`으로 정의한다. 현재 AdminFront의 조직/테넌트 관리 화면과 OrgFront의 조회 화면을 우선 재사용하고, 부족한 변경 요청·승인·미리보기 기능을 추가하는 방향이 적절하다.
|
|
|
|
### 3.5 조직장 역할 관리 방안
|
|
|
|
> 추가 제안: 현재 Keto 관계(`owners/admins/members`)로 표현 가능한 권한 구조에, 사람이 이해하기 쉬운 조직장 표시명과 승인 역할 정책을 덧붙인다.
|
|
|
|
조직도에는 본부장, 부문장, 부서장, 팀장, 셀장처럼 각 조직 단위의 책임자를 표시하고 관리할 수 있어야 한다.
|
|
|
|
다만 모든 회사와 모든 조직 단계에 반드시 조직장이 존재하는 것은 아니므로, 조직장 역할은 필수값이 아니라 회사별 설정에 따른 선택 항목으로 관리한다.
|
|
|
|
권장 구조는 다음과 같다.
|
|
|
|
```text
|
|
조직단위유형
|
|
-> 조직장 역할명 설정
|
|
-> 조직장 지정 여부 설정
|
|
-> 조직장 사용자 매핑
|
|
-> 조직도/권한 정책/승인 정책에서 활용
|
|
```
|
|
|
|
조직장 역할 설정 예시는 다음과 같다. 이 표의 역할명은 화면 표시와 승인 정책용 명칭이며, 실제 권한 부여는 Keto `owners/admins/members` 관계로 저장한다.
|
|
|
|
| 조직단위유형 | 표시 역할명 | 조직장 필수 여부 | 설명 |
|
|
| --- | --- | --- | --- |
|
|
| 본부 | 본부장 | 선택 | 회사에 따라 본부장이 없을 수 있음 |
|
|
| 부문 | 부문장 | 선택 | 부문 조직을 쓰는 회사에서만 사용 |
|
|
| 부서 | 부서장 | 선택 또는 필수 | 일반적으로 많이 사용 |
|
|
| 팀 | 팀장 | 선택 또는 필수 | 팀 단위 승인/조회 권한에 활용 가능 |
|
|
| 셀 | 셀장 | 선택 | 셀 조직을 쓰는 회사에서만 사용 |
|
|
|
|
운영 정책은 다음과 같다.
|
|
|
|
- 조직장 역할명은 회사별로 다르게 설정할 수 있다.
|
|
- 특정 조직단위유형에는 조직장을 두지 않도록 설정할 수 있다.
|
|
- 한 조직 단위에 조직장을 1명만 둘지, 복수 책임자를 허용할지 회사별로 정한다.
|
|
- 조직장이 공석인 조직 단위는 조직도에서 `공석` 또는 미표시로 처리한다.
|
|
- 조직장 변경은 조직 변경 이력과 동일하게 변경 전/후 이력을 남긴다.
|
|
- 조직장 정보는 서비스별 접근 권한이나 승인권자 판단에 활용할 수 있다.
|
|
|
|
예를 들어 팀장이 지정된 팀은 해당 팀 소속 직원의 특정 요청 승인자로 사용할 수 있고, 본부장이 없는 회사는 본부장 역할을 비활성화할 수 있다.
|
|
|
|
### 3.6 조직도 UI 오픈소스 적용 방안
|
|
|
|
조직도 화면은 직접 처음부터 구현하기보다 검증된 오픈소스 라이브러리를 활용하는 방안을 우선 검토한다.
|
|
|
|
후보는 다음과 같다.
|
|
|
|
| 후보 | 특징 | 적용 방향 |
|
|
| --- | --- | --- |
|
|
| `d3-org-chart` | D3 기반 조직도 라이브러리이며 확대/축소, 노드 추가/삭제, 검색, 내보내기, React/Vue/Angular 연동 예제가 있다. | 회사별 조직도 조회 화면과 임베드용 조직도에 우선 검토한다. |
|
|
| `OrgChart` | jQuery 기반 조직도 플러그인이며 드래그 앤 드롭으로 구조 변경, JSON 저장, 이미지/PDF 내보내기, 모바일 터치를 지원한다. | 조직 담당자가 조직 단위 이동을 직관적으로 수행하는 편집 화면에 우선 검토한다. |
|
|
| `React Flow` | React 기반 노드 편집 UI 라이브러리이며 노드 이동, 연결선, 미니맵, 컨트롤 등 편집 도구 구성에 강하다. | 기존 프론트엔드가 React 계열이거나 조직도 외 추가 워크플로우 편집이 필요할 때 검토한다. |
|
|
| `Treant.js` | SVG 기반 트리 다이어그램 라이브러리이며 단순 조직도 표현에 적합하다. | 수정 기능보다 가벼운 조회 전용 화면이 필요할 때 검토한다. |
|
|
|
|
권장 적용안은 다음과 같다.
|
|
|
|
- 조회/공유용 조직도는 `d3-org-chart`를 우선 검토한다.
|
|
- 조직 담당자 편집 화면은 `OrgChart` 또는 `React Flow`를 비교 검토한다.
|
|
- 드래그 앤 드롭으로 조직 단위 이동을 처리하더라도 즉시 DB에 반영하지 않고 변경 요청으로 저장한다.
|
|
- 노드 이동, 조직 단위 생성, 직원 소속 이동은 모두 변경 전/후 비교 화면을 거친다.
|
|
- 최종 반영은 승인 후 회사별 DB 반영 어댑터를 통해 수행한다.
|
|
|
|
### 3.7 조직도 공유 및 외부 표시 방안
|
|
|
|
각 회사의 완성된 조직도는 Baron SSO 내부에서만 보는 것이 아니라 각 회사 인트라넷, 모바일 페이지, 그룹웨어 등에서도 표시할 수 있게 한다.
|
|
|
|
제공 방식은 다음 세 가지를 제안한다.
|
|
|
|
| 방식 | 설명 | 활용 예 |
|
|
| --- | --- | --- |
|
|
| 링크 공유 | 회사별 조직도 조회 URL을 발급한다. | 각 회사 인트라넷 메뉴에서 조직도 링크로 연결 |
|
|
| 임베드 위젯 | `iframe` 또는 스크립트 형태로 조직도를 외부 페이지에 삽입한다. | 인트라넷 메인, 모바일 웹, 그룹웨어 조직도 메뉴에 표시 |
|
|
| 이미지 내보내기 | 현재 조직도를 PNG/SVG/PDF 형태로 생성한다. | 공지, 보고자료, 모바일 이미지 조회, 변경 전/후 기록 |
|
|
|
|
공유 URL 예시는 다음과 같다.
|
|
|
|
```text
|
|
https://sso.example.com/org-chart/companies/{companyCode}
|
|
https://sso.example.com/org-chart/companies/{companyCode}/embed
|
|
https://sso.example.com/org-chart/companies/{companyCode}/export.png
|
|
```
|
|
|
|
외부 표시 시 보안 조건은 다음과 같다.
|
|
|
|
- 조직도 공개 범위는 회사별로 설정한다.
|
|
- 사내망 또는 SSO 인증 사용자에게만 노출한다.
|
|
- 임베드 토큰을 발급하여 허용된 인트라넷 도메인에서만 표시한다.
|
|
- 모바일 페이지에서는 개인정보 노출을 줄이고 조직 단위 중심으로 표시한다.
|
|
- 외부 표시용 조직도는 조회 전용으로 제공하고 변경 기능은 Baron SSO 관리자 화면에서만 허용한다.
|
|
- 이미지 내보내기 파일에는 생성일, 회사코드, 조직도 버전 정보를 포함한다.
|
|
|
|
조직도 변경 이후 외부 표시 갱신 흐름은 다음과 같다.
|
|
|
|
```text
|
|
조직도 변경 승인
|
|
-> 각 회사 DB 반영
|
|
-> Baron SSO 조직도 버전 갱신
|
|
-> 인트라넷/모바일 임베드 화면 자동 갱신
|
|
-> 필요 시 PNG/SVG/PDF 이미지 재생성
|
|
```
|
|
|
|
### 3.8 직원 사진 관리 및 표시 방안
|
|
|
|
> 추가 제안: 현재 조직도 정책에서 명확히 드러나지 않는 직원 사진 관리 기준을 별도 운영 정책으로 추가한다.
|
|
|
|
조직도와 SSO 로그인 화면에서 직원 사진을 표시하려면 사진 파일의 원천, 저장 방식, 노출 범위를 별도 정책으로 정의해야 한다.
|
|
|
|
사진은 개인을 식별할 수 있는 정보이므로 Baron SSO가 각 회사의 원본 사진 저장소를 대체하는 구조는 권장하지 않는다.
|
|
|
|
검토 가능한 방식은 다음과 같다.
|
|
|
|
| 방식 | 장점 | 단점 |
|
|
| --- | --- | --- |
|
|
| SSO 서버로 사진 파일을 가져와 통일 관리 | 조직도, 모바일, 인트라넷에서 빠르고 일관되게 표시 가능 | SSO가 개인정보성 파일을 보관하므로 보안, 삭제, 접근통제 부담 증가 |
|
|
| 각 회사가 사진 파일을 보관하고 SSO는 파일명만 관리 | 원본 사진 관리 책임이 각 회사에 남음 | 회사별 경로/권한/파일명 규칙 차이로 표시 실패 가능성이 높고, 모바일/외부 임베드 연동이 복잡함 |
|
|
| 원본은 각 회사가 보관하고 SSO는 표준 썸네일과 메타데이터만 관리 | 원본 책임은 각 회사에 두면서 SSO 화면에서는 안정적으로 표시 가능 | 사진 동기화 배치/API와 캐시 무효화 정책이 필요함 |
|
|
|
|
권장안은 `원본은 각 회사 보관, SSO는 표준 썸네일과 메타데이터 관리` 방식이다.
|
|
|
|
권장 구조는 다음과 같다.
|
|
|
|
```text
|
|
각 회사 인사/사진 저장소
|
|
-> 사진 원본 또는 변경 이벤트 제공
|
|
-> Baron SSO 사진 동기화
|
|
-> 표준 썸네일 생성
|
|
-> SSO 보안 저장소에 저장
|
|
-> 조직도/로그인/인트라넷 임베드 화면에서 표시
|
|
```
|
|
|
|
SSO에서 관리할 사진 정보는 다음으로 제한한다.
|
|
|
|
- 회사코드
|
|
- 사번 또는 사용자 식별자
|
|
- 사진 파일 식별자
|
|
- 사진 버전
|
|
- 사진 해시값
|
|
- 사진 갱신일
|
|
- 기본 이미지 사용 여부
|
|
- 사진 공개 범위
|
|
|
|
사진 파일명은 회사 간 중복을 피하기 위해 공통 규칙을 사용한다.
|
|
|
|
```text
|
|
{companyCode}_{employeeNo}_{photoVersion}.jpg
|
|
```
|
|
|
|
단, 화면이나 API에서는 실제 파일명을 직접 노출하지 않고 SSO의 사진 조회 URL을 사용한다.
|
|
|
|
```text
|
|
https://sso.example.com/photos/users/{userId}
|
|
https://sso.example.com/photos/users/{userId}?size=thumbnail
|
|
```
|
|
|
|
운영 정책은 다음과 같다.
|
|
|
|
- 원본 사진은 각 회사 인사 시스템 또는 사진 저장소를 기준으로 한다.
|
|
- SSO는 조직도 표시용 표준 크기 썸네일만 보관한다.
|
|
- 사진이 없는 직원은 기본 이미지를 표시한다.
|
|
- 퇴사자 또는 접근 제한 대상자의 사진은 정책에 따라 비공개 또는 기본 이미지로 대체한다.
|
|
- 사진 변경 시 사진 버전을 올려 캐시를 무효화한다.
|
|
- 외부 임베드 조직도에서는 권한이 허용된 사용자에게만 사진을 표시한다.
|
|
- 사진 다운로드는 기본 차단하고, 필요한 경우 관리자 권한과 감사 로그를 요구한다.
|
|
|
|
개인정보 보호 관점에서 사진 원본을 SSO에 장기 보관하는 방식은 피하고, 표시 목적에 필요한 최소 크기와 최소 정보만 관리하는 것이 적절하다.
|
|
|
|
### 3.9 조직도 변경 권한 정책 정의
|
|
|
|
조직도의 변경은 각 회사 또는 조직 테넌트에서 정해진 인원만 가능해야 한다. 기존 Baron 정책에 맞춰 변경 권한은 `Tenant view/manage` 및 Keto ReBAC 관계로 판정한다.
|
|
|
|
권한은 조회 권한과 변경 권한을 분리하고, 회사별로 적용 범위를 제한한다.
|
|
|
|
권한 역할 예시는 다음과 같다. 실제 구현에서는 이 역할을 직접 문자열 권한으로만 만들기보다 `owners`, `admins`, `members`, `RelyingParty#access` 관계와 관리자 화면의 표시 역할로 분리한다.
|
|
|
|
```text
|
|
전체 관리자
|
|
- 전체 자회사 조직도 조회/관리
|
|
- 회사별 담당자 지정
|
|
- 변경 이력 조회
|
|
|
|
회사 관리자
|
|
- 소속 회사 조직도 조회
|
|
- 소속 회사 조직 단위 생성, 수정, 이동 요청
|
|
- 소속 회사 직원 소속 조직 이동 요청
|
|
|
|
승인자
|
|
- 조직 변경 요청 승인/반려
|
|
- 승인 후 각 회사 DB 반영 승인
|
|
|
|
조회자
|
|
- 조직도 조회만 가능
|
|
- 변경 불가
|
|
```
|
|
|
|
권한 제한 원칙은 다음과 같다.
|
|
|
|
- A회사 담당자는 A회사 조직도만 수정할 수 있다.
|
|
- B회사 조직도는 B회사 담당자 또는 전체 관리자만 수정할 수 있다.
|
|
- 개인 고유정보는 조직도 화면에서 직접 수정하지 않는다.
|
|
- 조직 귀속 정보만 변경 대상으로 허용한다.
|
|
- 승인 전에는 각 회사 DB에 반영하지 않는다.
|
|
- 모든 변경 전/후 이력과 작업자를 기록한다.
|
|
|
|
### 3.10 조직도 동기화 및 DB 반영 방식 설계
|
|
|
|
> 추가 제안: 현재 Baron의 outbox/Worksmobile 동기화 방향을 확장하여, 각 자회사 인사 DB에도 제한된 조직 귀속 정보만 반영할 수 있는 어댑터 구조를 제안한다.
|
|
|
|
초기 단계에서는 CSV 또는 Excel 업로드 방식으로 시작하고, 이후 API 또는 배치 동기화로 확장한다.
|
|
|
|
권장 흐름은 다음과 같다.
|
|
|
|
```text
|
|
각 회사 인사/조직도 DB
|
|
-> Baron SSO 조직도 관리 화면
|
|
-> 조직 변경 임시 저장
|
|
-> 유효성 검증
|
|
-> 승인
|
|
-> 각 회사 DB의 조직 귀속 정보 반영
|
|
-> 반영 결과 기록
|
|
-> SSO 권한/접근 정책 갱신
|
|
```
|
|
|
|
동기화 주기는 다음 기준으로 제안한다.
|
|
|
|
- 초기: 1일 1회 배치
|
|
- 안정화 이후: 수시 배치 또는 API 연동
|
|
- 보안 중요 이벤트: 퇴사자, 관리자 권한 변경 등은 가능한 빠르게 반영
|
|
|
|
각 회사 DB 또는 외부 Directory에 반영할 수 있는 항목은 다음과 같이 제한한다. Baron 내부 변경과 외부 반영은 같은 요청에서 직접 동시 처리하지 않고, outbox와 동기화 작업으로 분리하는 방식을 우선한다.
|
|
|
|
- 조직단위코드
|
|
- 상위조직코드
|
|
- 조직단위유형
|
|
- 부서코드
|
|
- 팀코드
|
|
- 셀코드
|
|
- 직책코드
|
|
- 소속상태
|
|
|
|
기존 회사 DB가 부서코드와 팀코드 중심으로 구성되어 있다면 `조직단위코드`를 회사별 기존 코드 체계에 매핑한다.
|
|
|
|
각 회사 DB에 반영하지 않는 항목은 다음과 같다.
|
|
|
|
- 이름
|
|
- 주민등록번호 등 고유식별정보
|
|
- 연락처
|
|
- 주소
|
|
- 급여 정보
|
|
- 기타 민감 개인정보
|
|
|
|
회사별 DB 구조가 다를 수 있으므로 회사별 연동 어댑터를 두는 방식을 권장한다. Worksmobile 연동처럼 테넌트 설정, 매핑 정책, outbox, 재시도/대사 화면을 함께 두는 방식이 기존 구조와 잘 맞는다.
|
|
|
|
```text
|
|
Baron SSO 조직 변경 요청
|
|
-> 공통 변경 모델
|
|
-> A회사 DB 반영 어댑터
|
|
-> B회사 DB 반영 어댑터
|
|
-> C회사 DB 반영 어댑터
|
|
```
|
|
|
|
이 구조를 사용하면 회사별 DB 테이블 구조가 다르더라도 SSO 쪽에서는 공통 변경 요청 모델을 유지할 수 있다.
|
|
|
|
다만 각 회사의 인사 DB는 일반적으로 소속부서코드, 소속팀코드처럼 2개 내지 3개의 컬럼으로 조직 소속을 관리하는 경우가 많다.
|
|
|
|
반면 Baron SSO 조직도는 본부, 부문, 부서, 팀, 셀처럼 더 깊은 계층을 표현할 수 있어야 하므로, SSO의 조직도 계층을 각 회사 DB 컬럼에 그대로 1:1 반영하는 방식은 적절하지 않다.
|
|
|
|
따라서 회사별 `조직 매핑 정책`을 별도로 둔다.
|
|
|
|
```text
|
|
Baron SSO 조직도 계층
|
|
-> 회사별 조직 매핑 정책
|
|
-> 회사별 DB 컬럼 반영 값 산출
|
|
-> 회사별 DB 반영 어댑터 실행
|
|
```
|
|
|
|
회사별 조직 매핑 정책 예시는 다음과 같다.
|
|
|
|
| 회사 | SSO 조직도 예시 | 회사 DB 컬럼 구조 | 반영 방식 |
|
|
| --- | --- | --- | --- |
|
|
| A회사 | 본부 -> 부서 -> 팀 -> 셀 | `dept_code`, `team_code` | 부서는 `dept_code`, 말단 팀 또는 셀은 `team_code`에 반영 |
|
|
| B회사 | 사업부 -> 부서 -> 파트 | `org_code` | 사용자의 최종 소속 조직코드만 `org_code`에 반영 |
|
|
| C회사 | 본부 -> 부문 -> 부서 -> 팀 | `hq_code`, `dept_code`, `team_code` | 본부/부서/팀을 각각 매핑하고 부문은 SSO 내부 계층으로만 관리 |
|
|
|
|
검토해야 할 항목은 다음과 같다.
|
|
|
|
- 각 회사 인사 DB의 조직 관련 컬럼 수
|
|
- 각 컬럼이 의미하는 조직 레벨
|
|
- 회사 DB에 반드시 반영해야 하는 조직 레벨
|
|
- SSO 내부에서만 관리해도 되는 조직 레벨
|
|
- 말단 조직 기준 반영 여부
|
|
- 상위 조직 변경 시 하위 직원 코드 변경 필요 여부
|
|
- 기존 코드 체계와 신규 조직단위코드의 매핑 방식
|
|
- 컬럼 수가 부족한 회사의 처리 방식
|
|
|
|
해결 방안은 다음과 같이 제안한다.
|
|
|
|
- SSO 내부에는 유연한 조직 계층을 보관한다.
|
|
- 각 회사 DB에는 해당 회사가 가진 컬럼 구조에 맞춰 필요한 값만 반영한다.
|
|
- 회사별로 `조직단위코드 -> 회사 DB 컬럼` 매핑 테이블을 둔다.
|
|
- DB 컬럼으로 표현할 수 없는 상위조직, 셀, 파트 등의 계층은 SSO 내부 조직도에서만 관리한다.
|
|
- 각 회사 DB에 반영되는 값은 변경 전 미리보기 화면에서 확인하게 한다.
|
|
- 매핑되지 않은 조직 단위로 직원 이동 시 승인 전 오류 또는 경고를 표시한다.
|
|
|
|
예를 들어 셀 단위가 추가되었지만 A회사 DB에 `cell_code` 컬럼이 없다면, 셀 정보는 SSO 조직도에서만 관리하고 실제 A회사 DB에는 상위 팀의 `team_code`만 반영할 수 있다.
|
|
|
|
### 3.11 회원가입 정책 정의
|
|
|
|
Baron SSO 회원가입은 각 회사 인사 DB에 존재하는 직원인지 확인한 뒤 허용해야 한다.
|
|
|
|
특히 발령상태에 따라 가입 가능 여부를 정책으로 명확히 정의한다.
|
|
|
|
회원가입 정책 예시는 다음과 같다.
|
|
|
|
| 인사 DB 상태 | 회원가입 가능 여부 | 설명 |
|
|
| --- | --- | --- |
|
|
| 발령완료 | 가능 | 정상 소속, 조직단위코드가 확정된 직원 |
|
|
| 발령대기 | 조건부 가능 또는 불가 | 입사 예정자, 소속 조직 미확정자는 제한 가입 또는 가입 대기 처리 |
|
|
| 입사예정 | 조건부 가능 | 교육, 온보딩 시스템만 접근이 필요한 경우 제한 가입 가능 |
|
|
| 휴직 | 원칙적 불가 또는 관리자 승인 | 기존 계정이 있는 경우 로그인 정책에서 별도 통제 |
|
|
| 퇴사 | 불가 | 신규 가입 불가 |
|
|
| 인사 DB 미존재 | 불가 | 사번/이메일이 확인되지 않는 사용자 |
|
|
|
|
권장 가입 흐름은 다음과 같다.
|
|
|
|
```text
|
|
회원가입 요청
|
|
-> 회사 선택
|
|
-> 사번/이메일/휴대폰 등 본인 확인
|
|
-> 각 회사 인사 DB 상태 조회
|
|
-> 발령상태/재직상태 검증
|
|
-> 가입 가능 여부 결정
|
|
-> 기본 접근 권한 부여
|
|
-> 가입 이력 기록
|
|
```
|
|
|
|
가입 시 기본 원칙은 다음과 같다.
|
|
|
|
- 각 회사 인사 DB에 존재하는 직원만 가입할 수 있다.
|
|
- 발령완료 직원은 정상 가입을 허용한다.
|
|
- 발령대기 또는 입사예정자는 제한 가입 또는 가입 대기 상태로 관리한다.
|
|
- 퇴사자는 신규 가입을 차단한다.
|
|
- 조직단위코드가 없는 사용자는 기본 시스템 접근을 제한한다.
|
|
- 가입 후 부여되는 기본 권한은 회사, 재직상태, 발령상태, 소속 조직 기준으로 결정한다.
|
|
|
|
### 3.12 SSO 로그인 및 서비스별 접근 권한 정책 정의
|
|
|
|
> 추가 제안: 기존 사용자 상태 정책과 Keto/RelyingParty 접근 제어를 연결하여, SSO 로그인 가능 여부와 서비스별 접근 가능 여부를 분리 관리한다.
|
|
|
|
조직도 관리는 최종적으로 SSO 접근 권한 정책과 연결되어야 한다.
|
|
|
|
기본 정책 예시는 다음과 같다.
|
|
|
|
```text
|
|
재직자: SSO 로그인 가능
|
|
퇴사자: 로그인 즉시 차단
|
|
휴직자: 기본 차단 또는 별도 예외 승인
|
|
부서 미지정자: 제한 권한 부여
|
|
특정 부서: 특정 서비스 접근 허용
|
|
관리자 권한: 직책 또는 별도 승인 기준으로 부여
|
|
```
|
|
|
|
관리자 권한은 부서 정보만으로 자동 부여하지 않는 것이 안전하다.
|
|
|
|
관리자 권한은 조직도 정보와 별도 승인 이력을 함께 기준으로 판단하는 것을 권장한다. Baron SSO의 기존 방향에 맞춰 최종 접근 판단은 `RelyingParty`와 `Tenant`의 Keto 관계를 기준으로 수행한다.
|
|
|
|
로그인 가능 여부와 서비스별 접근 가능 여부는 분리해서 판단한다.
|
|
|
|
예를 들어 SSO 로그인은 허용하되, 실제 접근 가능한 시스템은 직원 상태와 권한 정책에 따라 다르게 제한할 수 있다.
|
|
|
|
상태별 정책 예시는 다음과 같다.
|
|
|
|
| 직원 상태 | SSO 로그인 | 시스템 A | 시스템 B | 시스템 C | 설명 |
|
|
| --- | --- | --- | --- | --- | --- |
|
|
| 재직 | 가능 | 가능 | 가능 | 가능 | 기본적으로 모든 업무 시스템 접근 가능 |
|
|
| 휴직 | 가능 또는 제한 | 가능 | 가능 | 불가 | 급여/인사 확인 등 일부 시스템만 허용 가능 |
|
|
| 퇴사 1년 이내 | 불가 또는 제한 | 불가 | 불가 | 가능 | 퇴직정산, 증명서 발급 등 특수 시스템만 허용 가능 |
|
|
| 퇴사 1년 초과 | 불가 | 불가 | 불가 | 불가 | 모든 접근 차단 |
|
|
| 발령대기 | 가능 또는 대기 | 가능 | 불가 | 불가 | 온보딩 또는 교육 시스템만 허용 가능 |
|
|
|
|
서비스별 접근 제한은 다음 기준을 조합해 판단한다.
|
|
|
|
- 회사
|
|
- 재직상태
|
|
- 발령상태
|
|
- 조직단위코드
|
|
- 상위조직코드
|
|
- 조직단위유형
|
|
- 부서코드
|
|
- 팀코드
|
|
- 직책코드
|
|
- 권한 그룹
|
|
- 개별 사용자 예외 권한
|
|
- 접근 허용 기간
|
|
|
|
권한 판단 흐름은 다음과 같다.
|
|
|
|
```text
|
|
SSO 로그인 요청
|
|
-> 사용자 식별
|
|
-> 각 회사 인사 DB 또는 SSO 동기화 정보에서 현재 상태 확인
|
|
-> SSO 로그인 가능 여부 판단
|
|
-> 대상 시스템 접근 정책 조회
|
|
-> 상태/회사/소속 조직/권한 그룹/예외 권한 평가
|
|
-> 접근 허용 또는 차단
|
|
-> 접근 이력 기록
|
|
```
|
|
|
|
재직자라 하더라도 모든 시스템에 자동 접근시키지 않고, 시스템별 접근 권한을 별도로 관리할 수 있어야 한다.
|
|
|
|
예를 들어 재직자 중에서도 특정 부서만 회계 시스템에 접근하거나, 특정 직책 이상만 관리자 시스템에 접근하도록 제한할 수 있다.
|
|
|
|
### 3.13 서비스별 접근 권한 관리자 기능
|
|
|
|
> 추가 제안: 현재 ReBAC 정책을 운영자가 직접 관리할 수 있도록 서비스별 접근 정책 관리자 화면을 제안한다.
|
|
|
|
서비스별 접근 정책을 관리할 수 있는 관리자 페이지를 제공한다.
|
|
|
|
주요 기능은 다음과 같다.
|
|
|
|
- SSO 연동 시스템 목록 관리
|
|
- 시스템별 접근 가능 회사 설정
|
|
- 시스템별 접근 가능 재직상태 설정
|
|
- 시스템별 접근 가능 발령상태 설정
|
|
- 시스템별 접근 가능 조직 단위 설정
|
|
- 시스템별 접근 가능 직책/권한 그룹 설정
|
|
- 사용자별 예외 허용/차단 설정
|
|
- 예외 권한 만료일 설정
|
|
- 접근 정책 변경 전/후 비교
|
|
- 정책 변경 승인/반려
|
|
- 시스템별 접근 가능 사용자 목록 조회
|
|
- 사용자별 접근 가능 시스템 목록 조회
|
|
|
|
관리자 화면에서는 `기본 정책`과 `예외 정책`을 구분해서 보여주는 것이 좋다.
|
|
|
|
기본 정책은 회사/상태/조직/직책 기준으로 자동 적용하고, 예외 정책은 특정 사용자에게 기간을 정해 수동 부여한다.
|
|
|
|
### 3.14 관리자 화면 구성
|
|
|
|
초기 관리자 화면은 SSO 접근 통제에 필요한 조회와 상태 확인을 기본으로 구성하고, 이후 회사별 조직도 편집 기능을 확장한다.
|
|
|
|
우선 구현 대상은 다음과 같다.
|
|
|
|
- 회사별 조직도 조회
|
|
- 회사별 조직도 변경 요청
|
|
- 직원 목록 조회
|
|
- 부서별 사용자 조회
|
|
- 사용자 상세 정보 확인
|
|
- 재직상태별 필터
|
|
- 발령상태별 필터
|
|
- SSO 접근 가능/불가 상태 표시
|
|
- 사용자별 접근 가능 시스템 표시
|
|
- 시스템별 접근 가능 사용자 표시
|
|
- 직원 사진 동기화 상태 조회
|
|
- 직원 사진 표시/비공개 상태 관리
|
|
- 조직장 역할 설정
|
|
- 조직장 지정/변경
|
|
- 권한 그룹 매핑
|
|
- 서비스별 접근 정책 관리
|
|
- 사용자별 예외 접근 권한 관리
|
|
- 회사별 조직도 담당자 지정
|
|
- 조직 변경 승인/반려
|
|
- 각 회사 DB 반영 결과 조회
|
|
- 조직도 동기화 이력 조회
|
|
- 수동 예외 권한 등록
|
|
|
|
팀장 보고 시에는 단순한 `조직도 화면`이 아니라 `SSO 접근 통제 화면`으로 설명하는 것이 적절하다.
|
|
|
|
### 3.15 감사 로그와 이력 관리
|
|
|
|
SSO는 보안 영역이므로 변경 이력과 접근 이력을 반드시 남겨야 한다.
|
|
|
|
필수 로그 항목은 다음과 같다.
|
|
|
|
- 로그인 성공 이력
|
|
- 로그인 실패 이력
|
|
- 회원가입 요청 이력
|
|
- 회원가입 승인/차단 이력
|
|
- 상태 기준 로그인 차단 이력
|
|
- 서비스별 접근 허용/차단 이력
|
|
- 퇴사자 로그인 시도 이력
|
|
- 조직 정보 변경 이력
|
|
- 조직장 지정/변경 이력
|
|
- 권한 변경 이력
|
|
- 서비스별 접근 정책 변경 이력
|
|
- 사용자별 예외 권한 변경 이력
|
|
- 관리자 수동 변경 이력
|
|
- 조직도 변경 요청 이력
|
|
- 조직도 변경 승인/반려 이력
|
|
- 각 회사 DB 반영 요청 이력
|
|
- 각 회사 DB 반영 성공/실패 이력
|
|
- 조직도 링크/임베드 접근 이력
|
|
- 조직도 이미지 내보내기 이력
|
|
- 직원 사진 동기화 이력
|
|
- 직원 사진 조회 이력
|
|
- 직원 사진 비공개/기본 이미지 전환 이력
|
|
- 동기화 성공/실패 이력
|
|
|
|
감사 로그는 보안 사고 대응, 내부 감사, 권한 변경 원인 추적에 활용할 수 있다.
|
|
|
|
## 4. 우선순위
|
|
|
|
가장 먼저 진행해야 할 작업은 다음과 같다. 특히 `추가 제안` 항목은 기존 정책 확인 후 보강 개발로 추진한다.
|
|
|
|
1. 현재 SSO 사용자 목록 정리
|
|
2. 회원가입 가능 상태와 차단 상태 정책 확정
|
|
3. 재직상태 기준 로그인 허용/차단 정책 확정
|
|
4. 회사별 조직도 원천 데이터 결정
|
|
5. 회사별 조직도 변경 담당자와 승인자 지정
|
|
6. 각 회사 DB에 반영 가능한 조직 귀속 항목 확정
|
|
7. 서비스별 접근 권한 정책 기준 확정
|
|
8. 직원 사진 원천과 SSO 표시 방식 확정
|
|
9. 회사별 조직도 계층과 DB 컬럼 매핑 정책 확정
|
|
10. 회사별 조직장 역할 사용 여부와 필수 여부 확정
|
|
|
|
이 항목들이 결정되면 관리자 화면, 조직도 동기화, 권한 그룹 관리, 각 회사 DB 반영 기능을 순차적으로 진행할 수 있다.
|
|
|
|
## 5. 후속 진행 작업
|
|
|
|
후속 작업은 다음 순서로 진행하는 것을 제안한다.
|
|
|
|
1. 현재 SSO 사용자 현황 추출
|
|
2. 회사별 조직도 기준 항목 정의
|
|
3. 회사별 인사/조직도 원천 시스템 확인
|
|
4. 사용자-조직 매핑 테이블 설계
|
|
5. 회원가입 가능 상태 정책 정의
|
|
6. 로그인 가능 상태 정책 정의
|
|
7. 서비스별 접근 권한 정책 정의
|
|
8. 회사별 조직도 변경 권한 정책 정의
|
|
9. 조직도 변경 승인 절차 정의
|
|
10. 각 회사 DB 반영 가능 항목 확정
|
|
11. 회사별 조직 계층과 DB 컬럼 매핑 정책 정의
|
|
12. 회사별 조직장 역할 정책 정의
|
|
13. 조직도 UI 오픈소스 후보 기술 검토
|
|
14. 조직도 링크/임베드/이미지 제공 방식 확정
|
|
15. 직원 사진 원천/동기화/표시 정책 확정
|
|
16. 퇴사자/휴직자 로그인 차단 정책 적용
|
|
17. 서비스별 접근 정책 관리자 화면 추가
|
|
18. 관리자 조회 화면 추가
|
|
19. 회사별 조직도 관리 화면 추가
|
|
20. 조직도 동기화 배치 또는 API 구현
|
|
21. 직원 사진 썸네일 동기화 구현
|
|
22. 각 회사 DB 반영 어댑터 구현
|
|
23. 권한 변경 및 로그인 감사 로그 보강
|
|
|
|
## 6. 기대 효과
|
|
|
|
- 퇴사자 또는 휴직자의 SSO 접근을 빠르게 차단할 수 있다.
|
|
- 발령상태와 재직상태에 따라 회원가입 가능 여부를 명확히 통제할 수 있다.
|
|
- 로그인 가능 여부와 실제 시스템 접근 가능 여부를 분리해서 관리할 수 있다.
|
|
- 재직자라도 시스템별 접근 권한을 세밀하게 제한할 수 있다.
|
|
- 휴직자, 퇴사자, 발령대기자에게 필요한 시스템만 제한적으로 허용할 수 있다.
|
|
- 부서 이동이나 조직 변경에 따른 권한 정리를 체계화할 수 있다.
|
|
- 여러 자회사의 조직도를 회사별로 분리하여 관리할 수 있다.
|
|
- 권한이 있는 담당자만 조직도 변경을 요청하거나 승인할 수 있다.
|
|
- 각 회사 DB에는 필요한 조직 귀속 정보만 제한적으로 반영할 수 있다.
|
|
- 회사별 DB 컬럼 수가 달라도 조직 매핑 정책으로 반영 방식을 다르게 적용할 수 있다.
|
|
- 본부장, 부문장, 부서장, 팀장, 셀장 같은 조직장 역할을 회사별 정책에 따라 선택적으로 관리할 수 있다.
|
|
- 완성된 조직도를 각 회사 인트라넷이나 모바일 페이지에서 쉽게 표시할 수 있다.
|
|
- 보고자료나 공지용 조직도 이미지를 별도 수작업 없이 생성할 수 있다.
|
|
- 각 회사 직원 사진을 표준 썸네일 형태로 일관되게 표시할 수 있다.
|
|
- 사진 원본은 각 회사에 유지하면서 SSO는 표시 목적의 최소 정보만 관리할 수 있다.
|
|
- 관리자 권한 부여 기준을 명확히 할 수 있다.
|
|
- SSO 접근 이력과 권한 변경 이력을 감사 관점에서 추적할 수 있다.
|
|
- 향후 자동 권한 관리와 서비스별 접근 제어로 확장할 수 있다.
|
|
|
|
## 7. 참고 오픈소스 후보
|
|
|
|
- `d3-org-chart`: https://github.com/bumbeishvili/org-chart
|
|
- `OrgChart`: https://github.com/dabeng/OrgChart
|
|
- `React Flow`: https://github.com/xyflow/xyflow
|
|
- `Treant.js`: https://github.com/fperucic/treant-js
|
|
|
|
|