[RosieOh]

Refs #49

#49 의 체크리스트를 코드와 대조하다 둘 나왔습니다. 둘 다 S3 전환 결정과 무관하게 지금 고쳐야 하는 것입니다.

1. 첨부를 지워도 저장된 파일이 남았다

FileStorageService.delete(key) 는 처음부터 있었지만 부르는 곳이 없었습니다.

경로	지워지는 것	남는 것
DELETE /health/records/attachments/{id}	첨부 행	파일
DELETE /health/records/{id}	기록 + 첨부 행 (cascade)	파일

두 번째는 엔티티의 cascade = ALL, orphanRemoval = true 가 첨부 행만 지우기 때문입니다.

남은 파일은 가리키는 행이 없어 조회할 길이 없으니 당장 새어 나가지는 않습니다. 문제는 진단서·처방전 같은 민감정보가 "지웠다" 고 생각한 뒤에도 서버에 남는다는 점입니다.

구현에서 신경 쓴 두 가지:

• 기록 삭제는 지우기 전에 키를 모아 둡니다. 행이 사라지면 그 파일을 가리키는 것이 없어져 지울 기회도 없어집니다
• 순서는 "행 먼저, 파일 나중" 입니다. 파일 삭제가 실패해도 남은 파일을 가리키는 행이 없어 접근 경로가 없습니다. 반대 순서라면 파일은 사라졌는데 행이 남아 다운로드가 깨집니다

남의 첨부 id 로 파일을 지우면 삭제가 공격 수단이 되므로, 소유권 확인이 먼저인 것도 테스트로 고정했습니다.

2. 로그인한 아무나 정적 경로로 남의 첨부를 받을 수 있었다

업로드 루트 전체(/files/**)가 정적 리소스로 서빙되고 있었습니다. 보안 설정은 /files/profile-images/** 만 공개로 두고 나머지는 인증을 요구하며, 주석도 이렇게 적고 있었습니다.

업로드 루트(/files/**) 전체를 열지 않는 이유는 같은 저장소에 건강기록 첨부가 들어 있기 때문이다. 그쪽은 민감정보라 주소만 알면 열리는 상태로 두면 안 되고, 인증을 거치는 별도 다운로드 경로가 필요하다.

그런데 인증만으로는 부족했습니다. 인증을 거치는 다운로드 경로는 소유권까지 확인하는데, 정적 경로는 로그인한 아무나 통과시켰습니다. 주소를 알게 된 다른 회원이 남의 진단서를 그대로 받아갈 수 있었습니다.

파일명이 UUID 라 추측은 어렵지만, 추측이 유일한 방어라면 방어가 아닙니다.

정적 서빙을 profile-images 하위로만 좁혔습니다. 리소스 핸들러의 location 자체를 그 디렉터리로 내리므로 보안 설정의 경로 규칙과 어긋날 여지도 없습니다.

프로필 이미지는 공개로 유지합니다 — <img src> 로 불러가므로 인증 헤더를 붙일 수 없고 원래 화면에 노출되는 값입니다. "차단이 과하면 프로필 이미지가 깨진다" 도 테스트로 고정했습니다.

테스트는 실제 파일을 만들어 둡니다. 없으면 "차단됨" 과 "파일이 없음" 이 둘 다 404 라 구분할 수 없습니다.

숫자

• 전체 테스트 657개, 실패 0
• ArchUnit baseline 241 유지