## 한 줄 요약 근로자의 법정 실명·연락처 등 민감정보를 기본정보 테이블과 분리해 저장하고, 필요한 역할만 안전하게 조회할 수 있도록 구현합니다. ## 배경 #5(근로자 기본정보·서류 메타데이터 API)에서 아래 판단에 따라 이 범위를 분리했습니다: - ERD·V3 설계 당시 `worker_sensitive_data` 테이블을 구상했으나, DB팀에 "이 테이블을 채우는 API가 별도로 있는지" 질문을 남긴 채 회신 대기 중이었습니다. - 팀 논의 결과 보류중 (PostgreSQL 자체 보안으로 충분하다고 판단). 다만 민감정보는 여전히 기본정보와 물리적으로 분리된 별도 테이블에 저장합니다. - #5 완료조건 대부분(등록·조회·수정, 서류 상태 관리, 목록 조회)이 이 정보 없이도 만족 가능해, #5는 먼저 닫고 이 부분만 후속 이슈로 분리합니다. ## 데이터 범위 ### 근로자 민감정보 (worker_sensitive_data) - 법정 실명 - 연락처 ## 구현 범위 - [ ] `worker_sensitive_data`를 채우는 API가 별도로 있는지 - [ ] `WorkerSensitiveData` 도메인과 migration (평문 컬럼, `worker`와 분리된 별도 테이블) - [ ] 민감정보 조회 API 또는 등록 시 통합 여부 결정 - [ ] 접근 권한 범위 결정 (모든 HR이 볼 수 있는지, 더 제한적인 역할이 필요한지) - [ ] company_id 격리 규칙 적용 (worker와 동일한 패턴) ## 개인정보 원칙 - AI 연동에 이 정보를 전달하지 않습니다. - 목록·요약 API는 이 정보를 반환하지 않습니다 (#5에서 이미 보장됨). - 애플리케이션 레벨 암호화는 하지 않으나, 별도 테이블 분리로 접근을 최소화합니다. - 삭제가 필요한 경우 물리 삭제보다 정책에 따른 비활성화·보존을 우선 검토합니다. ## 완료 조건 - [ ] 민감정보가 `worker` 기본정보 테이블과 물리적으로 분리되어 있습니다. - [ ] 권한 없는 역할은 민감정보를 조회할 수 없습니다. - [ ] 목록·요약 API 응답에 민감정보가 포함되지 않습니다. - [ ] 통합 테스트가 존재합니다. ## 이번 이슈에서 하지 않는 것 - 여권·외국인등록증 번호 저장 (범위에 없음, #5 개인정보 원칙 참고) - 애플리케이션 레벨 암호화 (판단필요) - AI 연동으로의 전달 ## 선행/후속 관계 - 선행 작업: #5 (근로자 기본정보·서류 메타데이터 API) - 상위 목표: #2 - 관련 PR: #40, #49
한 줄 요약
근로자의 법정 실명·연락처 등 민감정보를 기본정보 테이블과 분리해 저장하고,
필요한 역할만 안전하게 조회할 수 있도록 구현합니다.
배경
#5(근로자 기본정보·서류 메타데이터 API)에서 아래 판단에 따라 이 범위를 분리했습니다:
worker_sensitive_data테이블을 구상했으나, DB팀에"이 테이블을 채우는 API가 별도로 있는지" 질문을 남긴 채 회신 대기 중이었습니다.
(PostgreSQL 자체 보안으로 충분하다고 판단). 다만 민감정보는 여전히
기본정보와 물리적으로 분리된 별도 테이블에 저장합니다.
#5는 먼저 닫고 이 부분만 후속 이슈로 분리합니다.
데이터 범위
근로자 민감정보 (worker_sensitive_data)
구현 범위
worker_sensitive_data를 채우는 API가 별도로 있는지WorkerSensitiveData도메인과 migration (평문 컬럼,worker와 분리된 별도 테이블)개인정보 원칙
완료 조건
worker기본정보 테이블과 물리적으로 분리되어 있습니다.이번 이슈에서 하지 않는 것
선행/후속 관계