78 lines
4.5 KiB
Markdown
78 lines
4.5 KiB
Markdown
# HMM 백오피스 사용자·그룹·역할·토큰 관리 전환 (#702)
|
|
|
|
> 상태: Implementing
|
|
> 추적: Redmine #702 / Git 브랜치: `hmm-backoffice`
|
|
> 대상: `hmm-backoffice.cloud-handson.com`, HMMAIPOC / `ADMIN`
|
|
|
|
## 목적
|
|
|
|
기존 KB/VPD 데모의 `CB_*` 사용자·그룹·역할·Bearer 토큰 모델을 HMM HR 데모의 실제 기준
|
|
테이블로 바꾼다. 직원과 조직 정보는 이미 적재된 HMM 테이블을 재사용하고, 접근 제어에만 필요한
|
|
테이블은 `HMM_ACCESS_*` 접두어로 추가한다.
|
|
|
|
## 기준 테이블과 소유권
|
|
|
|
| 관리 기능 | 기준 테이블 | 처리 방식 |
|
|
| --- | --- | --- |
|
|
| 사용자 | `HMM_HR_EMPLOYEES` | 기존 직원 ID·사번·성명·소속팀·재직 상태를 직접 사용 |
|
|
| 조직 참조 | `HMM_ORG_TEAMS` | 직원 생성 시 소속팀 검증에 사용 |
|
|
| 접근 그룹 | `HMM_ACCESS_GROUPS`, `HMM_ACCESS_GROUP_MEMBERS` | HR 조직과 독립적인 논리 접근 그룹을 새로 관리 |
|
|
| 역할 | `HMM_ACCESS_ROLES`, `HMM_EMPLOYEE_ACCESS_ROLES`, `HMM_GROUP_ACCESS_ROLES` | 직원 직접 역할과 그룹 상속 역할을 분리 |
|
|
| 토큰 | `HMM_ACCESS_BEARER_TOKENS` | 원문은 발급 화면에서 한 번만 표시하고 SHA-256 해시만 저장 |
|
|
| 감사 | `HMM_ACCESS_AUDIT` | 사용자·그룹·역할·토큰 변경 이력 저장 |
|
|
| 지식 문서 | `HMM_KNOWLEDGE_DOCUMENTS` | 파일명·원문·BLOB·Abstract·생성일자를 저장 |
|
|
| 지식 청크 | `HMM_KNOWLEDGE_CHUNKS`, `HMM_KNOWLEDGE_TAGS` | 문서별 청크와 정규화된 Tag·벡터를 저장 |
|
|
|
|
`HMM_ORG_TEAMS`는 인사 조직 원장이므로 접근 그룹과 혼합하지 않는다. 이로써 한 직원이 여러
|
|
업무 접근 그룹에 속하면서도 인사 소속팀은 하나로 유지된다.
|
|
|
|
## 데이터 흐름
|
|
|
|
```
|
|
HMM_HR_EMPLOYEES ──< HMM_EMPLOYEE_ACCESS_ROLES >── HMM_ACCESS_ROLES
|
|
│
|
|
└──< HMM_ACCESS_GROUP_MEMBERS >── HMM_ACCESS_GROUPS
|
|
│
|
|
└──< HMM_GROUP_ACCESS_ROLES >── HMM_ACCESS_ROLES
|
|
|
|
HMM_HR_EMPLOYEES ──< HMM_ACCESS_BEARER_TOKENS
|
|
HMM_ACCESS_AUDIT records every backoffice change
|
|
|
|
HMM_KNOWLEDGE_DOCUMENTS ──< HMM_KNOWLEDGE_CHUNKS ──< HMM_KNOWLEDGE_TAGS
|
|
```
|
|
|
|
## 화면 및 호환성
|
|
|
|
- `/users`는 `HMM_HR_EMPLOYEES`를 사용자 목록으로 표시한다. 활성/비활성은
|
|
`employment_status`의 `ACTIVE`/`INACTIVE`에 매핑한다.
|
|
- `/groups`는 `HMM_ACCESS_GROUPS`를 관리한다. HR 팀 이동 기능으로 오해되지 않도록
|
|
논리 접근 그룹임을 화면에 명시한다.
|
|
- `/roles`는 HMM 접근 역할만 관리한다.
|
|
- `/tokens`는 HMM 직원에게 토큰을 발급·회수한다. KB 이해당사자 원장은 참조하지 않는다.
|
|
- `/objects`, `/permissions`, `/masking-rules`, `/probe`, MCP 화면은 삭제하지 않는다. 기존 CB 화면
|
|
계약은 `CB_PROTECTED_*`, `CB_PERMISSION*`, `CB_VECTOR_*` 호환 뷰로 유지하고, 실제 데이터는
|
|
`HMM_ACCESS_*` 및 `HMM_KNOWLEDGE_*`에 저장한다.
|
|
- 애플리케이션 시작 시 `HmmKnowledgeSchemaInitializer`가 HMM 지식 테이블·시퀀스·인덱스를
|
|
멱등적으로 준비하고 `CB_VECTOR_*` 조회 호환 뷰를 갱신한다. 기존 물리 `CB_VECTOR_*` 테이블이
|
|
존재하는 환경은 덮어쓰지 않는다.
|
|
|
|
## 브랜치·배포 기준
|
|
|
|
- Smilegate 기준은 `main`이며, HMM 백오피스의 구현·배포·검증은 `hmm-backoffice` 브랜치만 사용한다.
|
|
- HMM 배포 전에 현재 브랜치명을 확인하고, `main` 또는 `hmm-ai-agent` 브랜치에서는 HMM 백오피스
|
|
JAR를 배포하지 않는다.
|
|
- 메뉴 전수 점검은 로그인 세션으로 원래 메뉴 URL 전체를 순회한다. HTTP 200만으로 통과시키지 않고
|
|
화면 내 `ORA-`, `데이터 처리 오류`, `Whitelabel Error Page`도 함께 검사한다.
|
|
|
|
## 보안·검증
|
|
|
|
- 토큰 원문, DB 비밀번호, Wallet은 테이블·Git·로그에 저장하지 않는다.
|
|
- DDL은 재실행 가능해야 하며 기존 HR 행을 수정하거나 삭제하지 않는다.
|
|
- 배포 전 전체 자동 테스트를 통과시키고, 배포 후 사용자·접근 그룹·역할·토큰뿐 아니라 보호 객체,
|
|
권한, 마스킹, 접근 검증, 지식자료, MCP, 운영 메뉴를 로그인 세션으로 전수 확인한다.
|
|
|
|
## 롤백
|
|
|
|
애플리케이션은 이전 JAR로 되돌릴 수 있다. 새 `HMM_ACCESS_*` 테이블은 운영 데이터가 생긴 뒤에는
|
|
삭제하지 않으며, 문제 발생 시 화면 매퍼만 이전 버전으로 복구한다.
|