Files
vpd-permission-poc/docs/design/702-hmm-backoffice-identity

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

화면 및 호환성

  • /usersHMM_HR_EMPLOYEES를 사용자 목록으로 표시한다. 활성/비활성은 employment_statusACTIVE/INACTIVE에 매핑한다.
  • /groupsHMM_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_* 테이블은 운영 데이터가 생긴 뒤에는 삭제하지 않으며, 문제 발생 시 화면 매퍼만 이전 버전으로 복구한다.