document-haness/docs/clean-architecture-backend-template/tech-log-studio/messaging-and-outbox/case/case-analysis-finding-a19-f009.md

kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, body, assets, evidence, source

kind	slug	title	topic	project	status	sourceRevision	rootTreeNode	evidenceCapturedOn	body	assets	evidence	source
CASE	analysis-finding-a19-f009	접근 검사가 두 갈래로 존재하고, 조립된 쪽이 진단이 약한 쪽이다 (§8.3)	messaging-and-outbox	clean-architecture-backend-template	게시 전	21234e38cdb9a926cbc92bb97a2aee2e4a7d2916	case:analysis-finding-a19-f009	2026-09-01	case-analysis-finding-a19-f009.body.md	key file analysis-finding-a19-f009 ../../../final/evidence/rendered/analysis-finding-a19-f009.svg	../../../final/evidence/raw/analysis-finding-a19-f009.txt	원본 분석 절은 analysis/19-messaging-platform.md#L511 이다.

접근 검사가 두 갈래로 존재하고, 조립된 쪽이 진단이 약한 쪽이다 (§8.3)

같은 권한 검사가 두 형태로 있다. 조립된 쪽은 거부를 설정 분류로 돌려주고, 조립되지 않은 쪽은 전용 인가 예외를 던진다. 검사 자체는 조립된 쪽에서 수행되므로 보안 구멍은 아니다.

관계

• 중복 장치를 찾으면 어느 쪽이 조립됐는지 먼저 확인한다 이 사례가 그 규칙의 형태다.
• 브로커 권한 매니페스트의 자기 점검이 존재하지 않는다 같은 가족의 다른 권한 사례다.
• 권한 거부와 설정 실수가 같은 버킷에 들어간다 기록하는 이유다.

문제

같은 권한 검사가 두 형태로 있다.

어느 쪽이 조립되었고 두 쪽의 차이가 무엇인지 확인했다.

결론

조립된 쪽은 발행자가 접근 정책을 직접 부르는 형태다.

발행이 허용되지 않으면 발행 금지 코드와 메시지를 담은 거부 결과를 돌려준다. 실패 분류가 설정이고 재시도 불가다.

조립되지 않은 쪽은 전용 검증기다. 주 참조도 테스트 참조도 0 이다.

발행이 허용되지 않으면 전용 인가 예외를 던진다. 코드와 함께 자격증명이 그 목적지에 발행할 수 없다는 메시지를 담는다.

그 클래스의 자바독이 존재 이유를 적는다.

브로커의 권한 검사보다 먼저 돌고, 일으키는 실패가 논리 목적지와 역할을 이름으로 부른다는 것이다.

브로커 권한 거부는 애플리케이션 문맥이 없는 연결 수준 오류로 도착하며, 그래서 어느 모듈이 어디로 발행하려 했는가가 로그 한 줄이 아니라 조사가 된다는 것이다.

두 경로의 차이는 분류다.

조립된 쪽은 인가 거부를 설정으로 분류한다. 조립되지 않은 쪽은 전용 인가 예외를 던진다.

핵심 계약의 예외 스물여섯 종에 그 인가 예외가 명시적으로 있는데, 실제 발행 경로는 그 타입을 쓰지 않는다.

권한 거부가 설정으로 집계되면 설정 실수와 권한 침해 시도가 같은 갈래에 들어간다.

실제 검사 자체는 조립된 쪽에서 수행되므로 보안 구멍은 아니다.

분류와 진단의 문제이고, 중복 장치 중 조립되지 않은 쪽이 더 정확한 분류를 갖고 있다.

판정은 P3 다.

검증 환경

확인 방식 : 두 경로의 구현과 참조 계수 대조 소스 수정 : x

재현 조건

원문은 final/evidence/raw/252 계열에 있다.

1. 발행자에서 권한 검사를 부르는 지점을 읽는다.
2. 거부 결과의 분류와 재시도 여부를 확인한다.
3. 전용 검증기의 구현과 자바독을 읽는다.
4. 그 검증기의 참조를 센다.
5. 핵심 계약의 예외 목록에 인가 예외가 있는지 확인한다.

본문

같은 권한 검사가 두 형태로 있다.

조립된 쪽

DefaultMessagePublisher가 DestinationAccessPolicy를 직접 호출한다.

if (!access.mayPublish(destination.name())) {
  return rejected("PUBLISH_FORBIDDEN",
      "this application may not publish to '" + destination.name().value() + '\'', startedAt);
}

FailureCategory.CONFIGURATION · retryable=false인 PublishResult를 돌려준다.

DefaultMessagePublisher 참조 위치

:::evidence key="analysis-finding-a19-f009" alt="코드베이스에서 DefaultMessagePublisher 를 검색한 출력 6줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="DefaultMessagePublisher 코드베이스 검색 — 6줄 · exit 0" zoom="true" :::

조립되지 않은 쪽

DestinationAccessValidator(main 참조 0건, 테스트 0건)가 전용 예외를 던진다.

public void requirePublish(DestinationName destination) {
  if (!policy.mayPublish(destination)) {
    throw new MessageAuthorizationException("DESTINATION_PUBLISH_DENIED",
        "the producer credential may not publish to " + destination.value());
  }
}

조립된 쪽이 진단이 약한 쪽이다. P3.

확인하지 못한 것

권한 거부를 발생시켜 집계 갈래를 확인하지 않았다. 분류 상수상 그 결과가 나온다.