chore: Worker Link tenant 무결성과 PostgreSQL RLS 보강

[krestar]

왜 필요한가요?

Worker Link 관련 자식 테이블은 기존 단일 FK만으로 응답·파일·멱등성 기록이 서로 다른 사업장에 연결되는 것을 DB에서 완전히 차단하지 못했습니다.

PR #87에서 추가된 worker_document.task_id 또한 (task_id, company_id) FK만으로는 같은 사업장에 속한 다른 근로자의 Task를 WorkerDocument에 연결할 수 있었습니다.

또한 Worker Link RLS 정책과 token bootstrap을 실제 Worker Link 스키마에 맞게 완성하고, 제한 runtime role에서 tenant 격리가 유지되는지 PostgreSQL로 검증할 필요가 있습니다.

• Refs [Security] PostgreSQL RLS 기반 사업장 2차 격리 안전 도입 #34
• Follow-up to feat: 근로자 보안 링크(Worker Link) 발급, 안내, 문서제출, 응답제출 구현 #76, [AI Run] 발화문 분석과 누락 정보 API·실행 이력 구현 #82, feat: WorkerDocument-Task 연결 및 taskId 필터 지원 #87

#34의 실제 runtime/migration role 구성, 최소 GRANT, Secret 주입, RLS 활성화 및 staging smoke는 #9와 연계된 후속 작업으로 남습니다. 따라서 이 PR은 #34를 자동으로 닫지 않습니다.

무엇이 바뀌나요?

• API·도메인·DB 변경:

  • V16 공통 migration에서 worker_response_upload와 worker_document_upload_idempotency에 company_id를 추가합니다.
  • 기존 데이터를 신뢰 가능한 부모 관계에서 backfill한 뒤 NOT NULL로 전환합니다.
  • Worker Link, Worker Response, StoredFile 및 자식 테이블에 tenant-aware 복합 UNIQUE·FK를 적용합니다.
  • worker_link.replaces_link_id를 동일 사업장 복합 FK와 ON DELETE RESTRICT로 전환합니다.
  • 동일 StoredFile이 여러 Worker Response에 연결되지 않도록 복합 UNIQUE를 추가합니다.
  • worker_document(task_id, worker_id, company_id) 복합 FK로 같은 사업장의 다른 근로자 Task 연결을 차단합니다.
  • 문서 등록 시 Task 존재 여부와 Task–Worker 일치 여부를 Application Service에서도 검증합니다.
  • Worker Response 업로드와 문서 업로드 멱등성 저장·조회 경로에 company_id를 전달합니다.

• 권한·Workflow 변경:

  • Worker Link 발급 transaction에서 ActorContext.companyId를 PostgreSQL tenant context에 바인딩합니다.
  • V17 PostgreSQL migration에서 Worker Response Upload 정책을 직접 company_id 비교 방식으로 전환합니다.
  • Worker Document Upload Idempotency 테이블에 tenant RLS 정책을 추가합니다.
  • Worker Link bootstrap은 token hash가 일치하면서 ACTIVE이고 DB 시각 기준 미만료인 링크만 company_id를 반환합니다.
  • V17에서는 ENABLE ROW LEVEL SECURITY를 실행하지 않습니다.

• AI·외부 연동 변경:

  • 변경 없음

• 문서·배포 변경:

  • PostgreSQL RLS rollout 문서에 V16 최초 배포 전제와 V17 적용 범위를 기록합니다.
  • V16은 pre-V16 애플리케이션과 동시에 같은 DB에 쓰는 상황에 backward-compatible하지 않습니다.
  • 현재는 운영 DB·운영 트래픽·구버전 Pod가 없는 최초 배포 전이므로 해당 전제를 충족합니다.
  • 실제 role·GRANT·Secret·RLS 활성화와 staging smoke는 #9와 연계합니다.
  • RLS 활성화는 조건 충족 후 별도의 forward-only Flyway migration으로 수행하며 버전 번호를 현재 예약하지 않습니다.

어떻게 검증했나요?

• .\gradlew.bat clean test
• .\gradlew.bat build
• /health와 Swagger UI 확인
• 정상 요청
• 잘못된 입력
• 권한 부족
• 다른 사업장 접근 차단
• 필요한 상태 전이·Idempotency

Demo Seed 활성/비활성(clean Docker psql DB 환경) run 정상 작동도 확인하였습니다.

실행한 주요 PostgreSQL 테스트:

.\gradlew.bat test `
  --tests "com.fowoco.server.PostgreSqlMigrationTests" `
  --tests "com.fowoco.server.common.security.PostgreSqlRlsIsolationTest"

검증 결과:

• V16 기존 데이터 backfill과 NOT NULL 전환
• NULL·orphan·교차 tenant 관계가 있는 migration 실패
• 같은 사업장 다른 근로자의 Task 연결 차단
• StoredFile의 다중 Worker Response 연결 차단
• 제한 runtime role에서 tenant context 누락 시 fail-closed
• company A context에서 company B 행 조회·생성 차단
• Worker Response Upload와 업로드 멱등성 테이블 RLS 차단
• transaction 종료 후 tenant context 비누수
• ACTIVE·미만료 Worker Link만 bootstrap 성공
• REVOKED·실제 만료·미등록 token hash bootstrap 차단
• migration 적용 후에도 RLS가 비활성 상태임을 확인

보안·개인정보

• DTO·로그·AI 입력에 불필요한 개인정보가 없습니다.
• JWT, Worker Link 원본 토큰, API Key, 비밀번호가 없습니다.
• 모든 사업장 데이터 접근에 company_id 범위를 검사합니다.
• AI 결과가 자동 승인·발송되지 않습니다.
• 기존 Worker Link 중요 변경은 AuditLog와 request_id로 추적됩니다.
• ADR-0004의 단계적 RLS 도입 계약을 유지합니다.
• Server에 Prompt Builder·Provider SDK·모델 routing을 추가하지 않았습니다.

API·DB·운영 영향

• 외부 API 계약 변경이 없어 Swagger/OpenAPI·Notion 갱신이 필요하지 않습니다.
• V16의 배포 호환성 전제를 본문과 rollout 문서에 명시했습니다.
• DB 변경에 Flyway V16·V17 migration이 있습니다.
• migration 번호와 소유 Issue를 확인했고 다른 기능의 테이블을 미리 만들지 않았습니다.
• 새로운 credential이나 Secret을 저장소에 추가하지 않았습니다.
• 배포 후 Smoke Test와 forward-only 복구 절차를 rollout 문서에 기록했습니다.

배포 주의사항

• V16과 대응 애플리케이션 코드는 같은 릴리스로 배포해야 합니다.
• pre-V16 애플리케이션과 V16 스키마의 동시 쓰기는 지원하지 않습니다.
• V17은 정책과 bootstrap만 준비하며 RLS를 활성화하지 않습니다.
• 실제 RLS 활성화는 #9의 runtime role·최소 GRANT·Secret·staging 검증이 끝난 뒤 별도 migration으로 진행합니다.

화면 또는 응답 예시

외부 API 응답 형식 변경은 없습니다.

[hywznn]

미안해요 재성님 제가 나중에 머지했어야했네요 ...