feat(database): PostgreSQL RLS 접근 거부 관측과 제한 역할 E2E 검증

[krestar]

관련 Issue

• Refs [Security] PostgreSQL RLS 기반 사업장 2차 격리 안전 도입 #34

이번 PR은 운영·staging runtime role 발급이나 RLS 활성화 migration까지 포함하지 않습니다.
해당 작업은 #9와 staging 검증에서 이어서 진행합니다.

무엇을 바꾸나요?

• PostgreSQL SQLSTATE 42501을 cause chain과 SQLException#getNextException() chain에서 분류합니다.
• 확인된 DB 접근 거부를 기존 내부 서버 오류 응답 형태로 안전하게 반환하고,
  route pattern 기반 구조화 로그와 저카디널리티 metric으로 관측합니다.
• 일반적인 ObjectOptimisticLockingFailureException은 기존 CONCURRENT_MODIFICATION 계약을 유지합니다.
• 공유 PostgreSQL 보안 테스트에 bounded advisory lock과 테이블별 RLS/FORCE 상태 snapshot·복원을 적용합니다.
• 제한 역할과 명시적 최소 GRANT로 Worker Repository의 silent filtering, INSERT 안전 실패, UPDATE·DELETE 불변성을 검증합니다.
• 제한 역할로 실제 Spring 애플리케이션을 기동해 Login, Refresh Token, Worker Link, Worker API의 정상 흐름과 tenant A/B 격리를 검증합니다.
• test-only unbound Worker INSERT를 통해 HTTP 500, 안전한 응답·로그·metric, DB 불변성을 함께 확인합니다.
• PostgreSQL rollout 문서에 CI fixture와 실제 staging 역할의 경계, 적용 순서, smoke test 및 forward-only 복구 절차를 기록합니다.

주요 보안 계약

• 42501만 DATABASE_ACCESS_DENIED 관측 대상으로 분류합니다.
• SQL, bound parameter, token, email, company ID, DB 객체명과 원본 예외 메시지를 응답·일반 로그·metric tag에 노출하지 않습니다.
• RLS USING에 따른 SELECT empty 및 UPDATE·DELETE 0건은 silent filtering으로 취급하며 42501로 오분류하지 않습니다.
• 제한 역할은 NOSUPERUSER, NOBYPASSRLS, NOINHERIT이고 table owner나 migration role member가 아닙니다.
• 테스트 종료 시 Spring context와 connection pool을 먼저 닫고, fixture 데이터·권한·역할·RLS 상태·advisory lock 순으로 안전하게 정리합니다.

어떻게 검증했나요?

아래 테스트는 사용자가 로컬에서 직접 실행해 통과를 확인했습니다.

.\gradlew.bat test --tests "*PostgreSqlWorkerRepositoryRlsTest"
.\gradlew.bat test --tests "*PostgreSqlRestrictedRoleHttpE2ETest"
.\gradlew.bat test --tests "*OutboxIntegrationTest"
.\gradlew.bat clean test

• 전체 suite: 297개 테스트 통과
• 전체 suite는 최종적으로 연속 2회 통과했습니다.
• 최초 전체 실행에서 Outbox 시간 경계 실패가 발견되어 테스트 전용 고정 UTC Clock으로 안정화했습니다.
• 이후 한 차례 기존 AuthSecurityIntegrationTest.replayingAUsedRefreshTokenRevokesTheWholeFamily()가 간헐 실패했으나, 같은 코드로 이어진 전체 실행 2회는 통과했습니다.

API·DB·운영 영향

• 외부 API schema와 정상 응답 계약은 변경하지 않습니다.
• 확인된 PostgreSQL 접근 거부는 기존 내부 서버 오류 계열 응답을 유지하면서 관측 정보만 추가합니다.
• Flyway migration, 실제 runtime credential, Secret, 환경별 GRANT와 RLS 활성화는 포함하지 않습니다.
• staging에서는 실제 runtime role의 최소 GRANT와 bootstrap 함수 실행 권한을 별도로 확정해야 합니다.

후속 작업

• #9에서 실제 dev·staging·prod runtime role, 최소 GRANT, credential와 Secret을 구성합니다.
• 별도 forward migration으로 RLS를 활성화하고 staging smoke test를 수행합니다.
• staging 검증 전에는 #34를 자동 종료하지 않습니다.

[hywznn]

ㅎㅇ

[hywznn]

확인했습니다!
DB 접근 권한 오류 발생 시 SQL이나 테이블명 같은 내부 정보가 응답과 로그에 노출되지 않고, 기존 낙관적 락 응답도 그대로 유지되는 것을 확인했습니다.
데모 기준으로 기존 기능에 영향을 주는 부분은 없어 보입니다. 👍

참고로 코드 문제는 아니지만, 열린 PR인 #100·#102도 PostgreSqlRlsIsolationTest.java를 수정하고 있어서 나중에 병합하는 PR에서 충돌 정리는 필요합니다.

[hywznn]

최신 main 반영 후 충돌 해결 내용을 확인
RLS 상태 보관·복원 구조와 약관 동의·비밀번호 재설정 테이블 검증이 함께 유지되며, 로컬 전체 테스트와 PostgreSQL 기반 Server CI가 통과 확인