From 669bd7aab08884b0097e494cf68f350628c67438 Mon Sep 17 00:00:00 2001 From: kevin Date: Wed, 17 Jun 2026 09:34:39 +0900 Subject: [PATCH] =?UTF-8?q?Update=20=EB=B0=94=EB=A1=A0SSO=EC=A1=B0?= =?UTF-8?q?=EC=A7=81=EB=8F=84=20=EA=B4=80=EB=A0=A8=20=EA=B2=80=ED=86=A0.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 바론SSO조직도 관련 검토.md | 580 +++++++++++++++++++++++++++++++++++-- 1 file changed, 552 insertions(+), 28 deletions(-) diff --git a/바론SSO조직도 관련 검토.md b/바론SSO조직도 관련 검토.md index ec0423f..998c5a6 100644 --- a/바론SSO조직도 관련 검토.md +++ b/바론SSO조직도 관련 검토.md @@ -1,17 +1,63 @@ # Baron SSO 조직도 관리 개선 제안 +## 문서 요약 + +이 문서는 Baron SSO를 단순 로그인 시스템이 아니라 여러 자회사의 조직도, 직원 상태, 서비스 접근 권한을 통합 관리하는 기준 시스템으로 확장하기 위한 제안서다. + +주요 내용은 다음과 같다. + +- 여러 자회사별 조직도를 회사 단위로 분리하여 관리한다. +- 조직도는 부서/팀에 고정하지 않고 본부, 부문, 부서, 팀, 셀 등 유연한 조직 단위 계층으로 관리한다. +- 조직 변경은 권한이 있는 담당자만 요청할 수 있고, 승인 후 각 회사 DB에 제한적으로 반영한다. +- 각 회사 DB 컬럼 구조가 다르므로 회사별 조직 매핑 정책과 DB 반영 어댑터를 둔다. +- 회원가입은 각 회사 인사 DB의 발령상태와 재직상태를 기준으로 허용 여부를 판단한다. +- SSO 로그인 가능 여부와 실제 업무 시스템 접근 가능 여부를 분리하여 관리한다. +- 직원 사진은 원본을 각 회사에 두고 SSO는 표준 썸네일과 메타데이터만 관리하는 방안을 권장한다. +- 완성된 조직도는 링크, 임베드, 이미지 형태로 인트라넷이나 모바일 페이지에 표시할 수 있게 한다. +- 모든 조직 변경, 권한 변경, 로그인, 사진 조회, 외부 표시 이력은 감사 로그로 남긴다. + +## 목차 + +1. [제안 목적](#1-제안-목적) +2. [기본 방향](#2-기본-방향) +3. [단계별 추진안](#3-단계별-추진안) + - [현재 사용자 기준 정리](#31-현재-사용자-기준-정리) + - [조직도 기준 데이터 정의](#32-조직도-기준-데이터-정의) + - [조직도 원천 시스템 결정](#33-조직도-원천-시스템-결정) + - [회사별 조직도 관리 화면 설계](#34-회사별-조직도-관리-화면-설계) + - [조직도 UI 오픈소스 적용 방안](#35-조직도-ui-오픈소스-적용-방안) + - [조직도 공유 및 외부 표시 방안](#36-조직도-공유-및-외부-표시-방안) + - [직원 사진 관리 및 표시 방안](#37-직원-사진-관리-및-표시-방안) + - [조직도 변경 권한 정책 정의](#38-조직도-변경-권한-정책-정의) + - [조직도 동기화 및 DB 반영 방식 설계](#39-조직도-동기화-및-db-반영-방식-설계) + - [회원가입 정책 정의](#310-회원가입-정책-정의) + - [SSO 로그인 및 서비스별 접근 권한 정책 정의](#311-sso-로그인-및-서비스별-접근-권한-정책-정의) + - [서비스별 접근 권한 관리자 기능](#312-서비스별-접근-권한-관리자-기능) + - [관리자 화면 구성](#313-관리자-화면-구성) + - [감사 로그와 이력 관리](#314-감사-로그와-이력-관리) +4. [우선순위](#4-우선순위) +5. [후속 진행 작업](#5-후속-진행-작업) +6. [기대 효과](#6-기대-효과) +7. [참고 오픈소스 후보](#7-참고-오픈소스-후보) + ## 1. 제안 목적 -Baron SSO에 접근하는 사내 직원을 조직도 기준으로 관리하고, 조직/직책/재직상태에 따라 접근 권한을 체계적으로 통제한다. +Baron SSO에 접근하는 사내 직원을 회사별 조직도 기준으로 관리하고, 조직/직책/재직상태에 따라 접근 권한을 체계적으로 통제한다. -이번 개선은 단순히 관리자 화면을 추가하는 작업이 아니라, SSO 접근 권한의 기준 데이터를 정비하고 향후 자동 권한 관리로 확장하기 위한 기반 작업이다. +이번 개선은 단순히 관리자 화면을 추가하는 작업이 아니라, 여러 자회사의 조직도와 인사정보를 SSO 접근 관리 기준으로 정비하고 향후 자동 권한 관리로 확장하기 위한 기반 작업이다. + +또한 각 회사의 인사담당자 또는 조직관리 담당자가 회사별 조직도를 시각적으로 관리하고, 승인된 조직 변경 사항을 각 회사 DB의 조직 귀속 정보에 제한적으로 반영하는 방안까지 함께 검토한다. ## 2. 기본 방향 - Baron SSO 접근 사용자를 조직도 기준으로 식별한다. +- 여러 자회사를 회사 단위로 구분하고, 각 회사별 조직도를 독립적으로 관리한다. +- 조직도는 본부, 부문, 부서, 팀, 셀 등 회사별 조직 단위의 계층 구조로 시각화하고, 권한이 있는 담당자만 수정할 수 있게 한다. - 재직상태, 부서, 직책, 권한 그룹을 기준으로 로그인 가능 여부와 서비스 접근 범위를 관리한다. -- 조직도 원천 데이터는 하나의 기준 시스템에서 가져오는 것을 원칙으로 한다. -- 초기에는 수동 관리 또는 파일 업로드 방식으로 시작하고, 이후 API 또는 배치 동기화 방식으로 확장한다. +- 조직도 원천 데이터는 회사별 인사정보 또는 조직관리 DB를 기준으로 하되, SSO에서는 접근 통제에 필요한 조직 정보를 통합 관리한다. +- 조직도 변경 사항은 검증과 승인 절차를 거친 뒤 각 회사 DB에 반영한다. +- 각 회사 DB 반영 대상은 개인정보 전체가 아니라 조직단위코드, 상위조직코드, 직책코드, 소속상태 같은 조직 귀속 정보로 제한한다. +- 초기에는 수동 관리 또는 파일 업로드 방식으로 시작하고, 이후 회사별 API 또는 배치 동기화 방식으로 확장한다. - 모든 권한 변경과 로그인 이력은 감사 로그로 남긴다. ## 3. 단계별 추진안 @@ -31,6 +77,13 @@ Baron SSO에 접근하는 사내 직원을 조직도 기준으로 관리하고, - 재직상태 - SSO 권한 - 최종 로그인일 +- 소속 회사 +- 부서코드 +- 팀코드 +- 조직단위코드 +- 상위조직코드 +- 사진 보유 여부 +- 사진 갱신일 이 단계에서는 퇴사자, 휴직자, 부서 미지정자, 중복 계정, 공용 계정을 식별한다. @@ -44,24 +97,60 @@ Baron SSO에서 사용할 조직도 기준 항목을 정의한다. - 회사 - 본부 +- 부문 - 부서 +- 부서코드 - 팀 -- 상위부서 -- 부서장 +- 팀코드 +- 셀 +- 셀코드 +- 조직단위코드 +- 조직단위유형 +- 상위조직코드 +- 조직장 - 사번 - 이름 - 이메일 - 직급 - 직책 +- 직책코드 - 재직상태 +- 발령상태 +- 입사일 +- 퇴사일 +- 사진 파일 식별자 +- 사진 버전 +- 사진 갱신일 이때 권한 제어에 필요한 항목과 단순 조회용 항목을 분리한다. -예를 들어 `부서`, `직책`, `재직상태`는 권한 판단에 직접 사용할 수 있고, `직급`은 감사 또는 조회 목적으로만 사용할 수 있다. +예를 들어 `회사`, `조직단위코드`, `상위조직코드`, `직책코드`, `재직상태`, `발령상태`는 권한 판단과 각 회사 DB 반영에 직접 사용할 수 있고, `직급`은 감사 또는 조회 목적으로만 사용할 수 있다. + +조직도는 부서/팀으로 고정하지 않고, 회사별 조직 레벨을 설정할 수 있게 한다. + +예시는 다음과 같다. + +```text +회사 -> 본부 -> 부문 -> 부서 -> 팀 -> 셀 +회사 -> 사업부 -> 부서 -> 파트 +회사 -> 센터 -> 그룹 -> 팀 +``` + +이를 위해 조직 단위는 공통적으로 다음 구조를 가진다. + +| 항목 | 설명 | +| --- | --- | +| 조직단위코드 | 회사 내에서 조직 단위를 식별하는 코드 | +| 조직단위명 | 화면에 표시할 조직명 | +| 조직단위유형 | 본부, 부문, 부서, 팀, 셀, 파트 등 | +| 상위조직코드 | 계층 구조를 만들기 위한 상위 조직 코드 | +| 회사코드 | 조직 단위가 속한 회사 | +| 조직장 사용자 ID | 해당 조직 단위의 책임자 | +| 사용 여부 | 폐지된 조직인지 여부 | ### 3.3 조직도 원천 시스템 결정 -조직도와 직원 정보의 원천 시스템을 결정한다. +조직도와 직원 정보의 원천 시스템을 회사별로 결정한다. 후보는 다음과 같다. @@ -71,23 +160,207 @@ Baron SSO에서 사용할 조직도 기준 항목을 정의한다. - AD/LDAP - 별도 조직도 관리 시스템 -핵심 원칙은 조직도 원본을 하나만 두는 것이다. +핵심 원칙은 각 회사별 조직도 원본을 명확히 정하는 것이다. -Baron SSO가 직접 조직도를 독립적으로 관리하기보다는, 원천 시스템의 조직/직원 정보를 받아와 동기화하는 방식이 안정적이다. +Baron SSO가 모든 회사의 인사 원장을 대체하는 구조는 위험하다. 따라서 SSO에서는 접근 통제에 필요한 조직 정보를 관리하고, 실제 회사별 인사정보 변경은 정해진 항목에 한해 각 회사 DB와 연동하는 방식이 안정적이다. 원천 시스템 연동이 당장 어렵다면 초기에는 관리자 업로드 방식으로 시작할 수 있다. -### 3.4 조직도 동기화 방식 설계 +### 3.4 회사별 조직도 관리 화면 설계 + +조직도는 회사별로 분리하여 조회하고 관리한다. + +화면은 회사별 조직 단위의 계층 구조를 한눈에 볼 수 있도록 트리 또는 조직도 형태로 제공한다. + +주요 기능은 다음과 같다. + +- 회사별 조직도 조회 +- 조직 단위 생성, 수정, 이동 +- 조직 단위 유형 관리 +- 상위 조직 변경 +- 직원의 소속 조직 이동 +- 변경 전/후 비교 +- 변경사항 임시 저장 +- 승인 후 각 회사 DB 반영 +- 반영 성공/실패 결과 확인 + +이 화면은 단순 조직도 조회 화면이 아니라 `회사별 조직 귀속 정보 관리 화면`으로 정의한다. + +### 3.5 조직도 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.6 조직도 공유 및 외부 표시 방안 + +각 회사의 완성된 조직도는 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.7 직원 사진 관리 및 표시 방안 + +조직도와 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.8 조직도 변경 권한 정책 정의 + +조직도의 변경은 각 회사에서 정해진 인원만 가능해야 한다. + +권한은 조회 권한과 변경 권한을 분리하고, 회사별로 적용 범위를 제한한다. + +권한 역할 예시는 다음과 같다. + +```text +전체 관리자 +- 전체 자회사 조직도 조회/관리 +- 회사별 담당자 지정 +- 변경 이력 조회 + +회사 관리자 +- 소속 회사 조직도 조회 +- 소속 회사 조직 단위 생성, 수정, 이동 요청 +- 소속 회사 직원 소속 조직 이동 요청 + +승인자 +- 조직 변경 요청 승인/반려 +- 승인 후 각 회사 DB 반영 승인 + +조회자 +- 조직도 조회만 가능 +- 변경 불가 +``` + +권한 제한 원칙은 다음과 같다. + +- A회사 담당자는 A회사 조직도만 수정할 수 있다. +- B회사 조직도는 B회사 담당자 또는 전체 관리자만 수정할 수 있다. +- 개인 고유정보는 조직도 화면에서 직접 수정하지 않는다. +- 조직 귀속 정보만 변경 대상으로 허용한다. +- 승인 전에는 각 회사 DB에 반영하지 않는다. +- 모든 변경 전/후 이력과 작업자를 기록한다. + +### 3.9 조직도 동기화 및 DB 반영 방식 설계 초기 단계에서는 CSV 또는 Excel 업로드 방식으로 시작하고, 이후 API 또는 배치 동기화로 확장한다. 권장 흐름은 다음과 같다. ```text -인사/조직도 시스템 --> 직원/부서 정보 동기화 --> Baron SSO 사용자/조직 테이블 반영 --> SSO 로그인 시 재직상태와 권한 확인 +각 회사 인사/조직도 DB +-> Baron SSO 조직도 관리 화면 +-> 조직 변경 임시 저장 +-> 유효성 검증 +-> 승인 +-> 각 회사 DB의 조직 귀속 정보 반영 +-> 반영 결과 기록 +-> SSO 권한/접근 정책 갱신 ``` 동기화 주기는 다음 기준으로 제안한다. @@ -96,7 +369,123 @@ Baron SSO가 직접 조직도를 독립적으로 관리하기보다는, 원천 - 안정화 이후: 수시 배치 또는 API 연동 - 보안 중요 이벤트: 퇴사자, 관리자 권한 변경 등은 가능한 빠르게 반영 -### 3.5 접근 권한 정책 정의 +각 회사 DB에 반영할 수 있는 항목은 다음과 같이 제한한다. + +- 조직단위코드 +- 상위조직코드 +- 조직단위유형 +- 부서코드 +- 팀코드 +- 셀코드 +- 직책코드 +- 소속상태 + +기존 회사 DB가 부서코드와 팀코드 중심으로 구성되어 있다면 `조직단위코드`를 회사별 기존 코드 체계에 매핑한다. + +각 회사 DB에 반영하지 않는 항목은 다음과 같다. + +- 이름 +- 주민등록번호 등 고유식별정보 +- 연락처 +- 주소 +- 급여 정보 +- 기타 민감 개인정보 + +회사별 DB 구조가 다를 수 있으므로 회사별 연동 어댑터를 두는 방식을 권장한다. + +```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.10 회원가입 정책 정의 + +Baron SSO 회원가입은 각 회사 인사 DB에 존재하는 직원인지 확인한 뒤 허용해야 한다. + +특히 발령상태에 따라 가입 가능 여부를 정책으로 명확히 정의한다. + +회원가입 정책 예시는 다음과 같다. + +| 인사 DB 상태 | 회원가입 가능 여부 | 설명 | +| --- | --- | --- | +| 발령완료 | 가능 | 정상 소속, 조직단위코드가 확정된 직원 | +| 발령대기 | 조건부 가능 또는 불가 | 입사 예정자, 소속 조직 미확정자는 제한 가입 또는 가입 대기 처리 | +| 입사예정 | 조건부 가능 | 교육, 온보딩 시스템만 접근이 필요한 경우 제한 가입 가능 | +| 휴직 | 원칙적 불가 또는 관리자 승인 | 기존 계정이 있는 경우 로그인 정책에서 별도 통제 | +| 퇴사 | 불가 | 신규 가입 불가 | +| 인사 DB 미존재 | 불가 | 사번/이메일이 확인되지 않는 사용자 | + +권장 가입 흐름은 다음과 같다. + +```text +회원가입 요청 +-> 회사 선택 +-> 사번/이메일/휴대폰 등 본인 확인 +-> 각 회사 인사 DB 상태 조회 +-> 발령상태/재직상태 검증 +-> 가입 가능 여부 결정 +-> 기본 접근 권한 부여 +-> 가입 이력 기록 +``` + +가입 시 기본 원칙은 다음과 같다. + +- 각 회사 인사 DB에 존재하는 직원만 가입할 수 있다. +- 발령완료 직원은 정상 가입을 허용한다. +- 발령대기 또는 입사예정자는 제한 가입 또는 가입 대기 상태로 관리한다. +- 퇴사자는 신규 가입을 차단한다. +- 조직단위코드가 없는 사용자는 기본 시스템 접근을 제한한다. +- 가입 후 부여되는 기본 권한은 회사, 재직상태, 발령상태, 소속 조직 기준으로 결정한다. + +### 3.11 SSO 로그인 및 서비스별 접근 권한 정책 정의 조직도 관리는 최종적으로 SSO 접근 권한 정책과 연결되어야 한다. @@ -115,24 +504,105 @@ Baron SSO가 직접 조직도를 독립적으로 관리하기보다는, 원천 관리자 권한은 조직도 정보와 별도 승인 이력을 함께 기준으로 판단하는 것을 권장한다. -### 3.6 관리자 화면 구성 +로그인 가능 여부와 서비스별 접근 가능 여부는 분리해서 판단한다. -초기 관리자 화면은 복잡한 조직도 편집 기능보다 SSO 접근 통제에 필요한 조회와 상태 확인 중심으로 구성한다. +예를 들어 SSO 로그인은 허용하되, 실제 접근 가능한 시스템은 직원 상태와 권한 정책에 따라 다르게 제한할 수 있다. + +상태별 정책 예시는 다음과 같다. + +| 직원 상태 | SSO 로그인 | 시스템 A | 시스템 B | 시스템 C | 설명 | +| --- | --- | --- | --- | --- | --- | +| 재직 | 가능 | 가능 | 가능 | 가능 | 기본적으로 모든 업무 시스템 접근 가능 | +| 휴직 | 가능 또는 제한 | 가능 | 가능 | 불가 | 급여/인사 확인 등 일부 시스템만 허용 가능 | +| 퇴사 1년 이내 | 불가 또는 제한 | 불가 | 불가 | 가능 | 퇴직정산, 증명서 발급 등 특수 시스템만 허용 가능 | +| 퇴사 1년 초과 | 불가 | 불가 | 불가 | 불가 | 모든 접근 차단 | +| 발령대기 | 가능 또는 대기 | 가능 | 불가 | 불가 | 온보딩 또는 교육 시스템만 허용 가능 | + +서비스별 접근 제한은 다음 기준을 조합해 판단한다. + +- 회사 +- 재직상태 +- 발령상태 +- 조직단위코드 +- 상위조직코드 +- 조직단위유형 +- 부서코드 +- 팀코드 +- 직책코드 +- 권한 그룹 +- 개별 사용자 예외 권한 +- 접근 허용 기간 + +권한 판단 흐름은 다음과 같다. + +```text +SSO 로그인 요청 +-> 사용자 식별 +-> 각 회사 인사 DB 또는 SSO 동기화 정보에서 현재 상태 확인 +-> SSO 로그인 가능 여부 판단 +-> 대상 시스템 접근 정책 조회 +-> 상태/회사/소속 조직/권한 그룹/예외 권한 평가 +-> 접근 허용 또는 차단 +-> 접근 이력 기록 +``` + +재직자라 하더라도 모든 시스템에 자동 접근시키지 않고, 시스템별 접근 권한을 별도로 관리할 수 있어야 한다. + +예를 들어 재직자 중에서도 특정 부서만 회계 시스템에 접근하거나, 특정 직책 이상만 관리자 시스템에 접근하도록 제한할 수 있다. + +### 3.12 서비스별 접근 권한 관리자 기능 + +서비스별 접근 정책을 관리할 수 있는 관리자 페이지를 제공한다. + +주요 기능은 다음과 같다. + +- SSO 연동 시스템 목록 관리 +- 시스템별 접근 가능 회사 설정 +- 시스템별 접근 가능 재직상태 설정 +- 시스템별 접근 가능 발령상태 설정 +- 시스템별 접근 가능 조직 단위 설정 +- 시스템별 접근 가능 직책/권한 그룹 설정 +- 사용자별 예외 허용/차단 설정 +- 예외 권한 만료일 설정 +- 접근 정책 변경 전/후 비교 +- 정책 변경 승인/반려 +- 시스템별 접근 가능 사용자 목록 조회 +- 사용자별 접근 가능 시스템 목록 조회 + +관리자 화면에서는 `기본 정책`과 `예외 정책`을 구분해서 보여주는 것이 좋다. + +기본 정책은 회사/상태/조직/직책 기준으로 자동 적용하고, 예외 정책은 특정 사용자에게 기간을 정해 수동 부여한다. + +### 3.13 관리자 화면 구성 + +초기 관리자 화면은 SSO 접근 통제에 필요한 조회와 상태 확인을 기본으로 구성하고, 이후 회사별 조직도 편집 기능을 확장한다. 우선 구현 대상은 다음과 같다. +- 회사별 조직도 조회 +- 회사별 조직도 변경 요청 - 직원 목록 조회 - 부서별 사용자 조회 - 사용자 상세 정보 확인 - 재직상태별 필터 +- 발령상태별 필터 - SSO 접근 가능/불가 상태 표시 +- 사용자별 접근 가능 시스템 표시 +- 시스템별 접근 가능 사용자 표시 +- 직원 사진 동기화 상태 조회 +- 직원 사진 표시/비공개 상태 관리 - 권한 그룹 매핑 +- 서비스별 접근 정책 관리 +- 사용자별 예외 접근 권한 관리 +- 회사별 조직도 담당자 지정 +- 조직 변경 승인/반려 +- 각 회사 DB 반영 결과 조회 - 조직도 동기화 이력 조회 - 수동 예외 권한 등록 팀장 보고 시에는 단순한 `조직도 화면`이 아니라 `SSO 접근 통제 화면`으로 설명하는 것이 적절하다. -### 3.7 감사 로그와 이력 관리 +### 3.14 감사 로그와 이력 관리 SSO는 보안 영역이므로 변경 이력과 접근 이력을 반드시 남겨야 한다. @@ -140,10 +610,25 @@ SSO는 보안 영역이므로 변경 이력과 접근 이력을 반드시 남겨 - 로그인 성공 이력 - 로그인 실패 이력 +- 회원가입 요청 이력 +- 회원가입 승인/차단 이력 +- 상태 기준 로그인 차단 이력 +- 서비스별 접근 허용/차단 이력 - 퇴사자 로그인 시도 이력 - 조직 정보 변경 이력 - 권한 변경 이력 +- 서비스별 접근 정책 변경 이력 +- 사용자별 예외 권한 변경 이력 - 관리자 수동 변경 이력 +- 조직도 변경 요청 이력 +- 조직도 변경 승인/반려 이력 +- 각 회사 DB 반영 요청 이력 +- 각 회사 DB 반영 성공/실패 이력 +- 조직도 링크/임베드 접근 이력 +- 조직도 이미지 내보내기 이력 +- 직원 사진 동기화 이력 +- 직원 사진 조회 이력 +- 직원 사진 비공개/기본 이미지 전환 이력 - 동기화 성공/실패 이력 감사 로그는 보안 사고 대응, 내부 감사, 권한 변경 원인 추적에 활용할 수 있다. @@ -153,28 +638,67 @@ SSO는 보안 영역이므로 변경 이력과 접근 이력을 반드시 남겨 가장 먼저 진행해야 할 작업은 다음 세 가지다. 1. 현재 SSO 사용자 목록 정리 -2. 재직상태 기준 로그인 허용/차단 정책 확정 -3. 조직도 원천 데이터 결정 +2. 회원가입 가능 상태와 차단 상태 정책 확정 +3. 재직상태 기준 로그인 허용/차단 정책 확정 +4. 회사별 조직도 원천 데이터 결정 +5. 회사별 조직도 변경 담당자와 승인자 지정 +6. 각 회사 DB에 반영 가능한 조직 귀속 항목 확정 +7. 서비스별 접근 권한 정책 기준 확정 +8. 직원 사진 원천과 SSO 표시 방식 확정 +9. 회사별 조직도 계층과 DB 컬럼 매핑 정책 확정 -이 세 가지가 결정되면 관리자 화면, 조직도 동기화, 권한 그룹 관리 작업을 순차적으로 진행할 수 있다. +이 항목들이 결정되면 관리자 화면, 조직도 동기화, 권한 그룹 관리, 각 회사 DB 반영 기능을 순차적으로 진행할 수 있다. ## 5. 후속 진행 작업 후속 작업은 다음 순서로 진행하는 것을 제안한다. 1. 현재 SSO 사용자 현황 추출 -2. 조직도 기준 항목 정의 -3. 인사/조직도 원천 시스템 확인 +2. 회사별 조직도 기준 항목 정의 +3. 회사별 인사/조직도 원천 시스템 확인 4. 사용자-조직 매핑 테이블 설계 -5. 퇴사자/휴직자 로그인 차단 정책 적용 -6. 관리자 조회 화면 추가 -7. 조직도 동기화 배치 또는 API 구현 -8. 권한 변경 및 로그인 감사 로그 보강 +5. 회원가입 가능 상태 정책 정의 +6. 로그인 가능 상태 정책 정의 +7. 서비스별 접근 권한 정책 정의 +8. 회사별 조직도 변경 권한 정책 정의 +9. 조직도 변경 승인 절차 정의 +10. 각 회사 DB 반영 가능 항목 확정 +11. 회사별 조직 계층과 DB 컬럼 매핑 정책 정의 +12. 조직도 UI 오픈소스 후보 기술 검토 +13. 조직도 링크/임베드/이미지 제공 방식 확정 +14. 직원 사진 원천/동기화/표시 정책 확정 +15. 퇴사자/휴직자 로그인 차단 정책 적용 +16. 서비스별 접근 정책 관리자 화면 추가 +17. 관리자 조회 화면 추가 +18. 회사별 조직도 관리 화면 추가 +19. 조직도 동기화 배치 또는 API 구현 +20. 직원 사진 썸네일 동기화 구현 +21. 각 회사 DB 반영 어댑터 구현 +22. 권한 변경 및 로그인 감사 로그 보강 ## 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