6.3 KiB
kind, slug, title, topic, project, status, sourceRevision, basisVersion, rootTreeNode, evidenceCapturedOn, assets, evidence, source
| kind | slug | title | topic | project | status | sourceRevision | basisVersion | rootTreeNode | evidenceCapturedOn | assets | evidence | source | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CONCEPT | rls-three-preconditions | PostgreSQL RLS 적용 여부를 가르는 분기 | multitenancy-isolation | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | PostgreSQL 16 · 리비전 21234e38 | concept:rls-three-preconditions | 2026-09-01 |
|
|
|
PostgreSQL RLS 적용 여부를 가르는 분기
PostgreSQL의 행 수준 보안은 ENABLE ROW LEVEL SECURITY, role의 우회 권한, table owner 여부, FORCE ROW LEVEL SECURITY, 적용 가능한 policy 유무에 따라 동작이 갈린다. 이 값들을 항상 동시에 참이어야 하는 세 전제로 묶으면 default deny와 owner 예외를 잘못 설명하게 된다.
관계
- RLS 검증에서 구분해야 할 우회와 미적용 경로 검증기가 읽는 값이 PostgreSQL의 어느 적용 분기에 해당하는지 확인한 사례다.
- Hibernate filter는 보안 경계가 아니다 ORM 기능을 격리 경계로 쓸 때의 문제를 다룬 규칙이다.
- 격리 설정은 트랜잭션 로컬이어야 한다 테넌트 바인딩이 세션에 남지 않게 하는 규칙이다.
본문
PostgreSQL RLS는 동시에 만족해야 할 세 조건이 아니라 적용 여부를 결정하는 분기로 보는 편이 정확하다.
RLS 적용 여부를 결정하는 순서
:::evidence key="rls-three-preconditions-diagram" alt="RLS 활성 여부에서 시작해 BYPASSRLS·superuser 우회, table owner와 FORCE RLS, applicable policy 유무를 구분하는 분기" caption="PostgreSQL RLS 적용 여부를 가르는 분기" zoom="false" :::
ENABLE ROW LEVEL SECURITY가 꺼져 있으면 policy는 적용되지 않는다.- RLS가 켜져 있어도 superuser와
BYPASSRLSrole은 우회한다. - 일반 non-owner role은 policy 대상이다.
- table owner는 기본적으로 우회하지만
FORCE ROW LEVEL SECURITY를 켜면 policy 대상이 된다. - policy 대상인데 적용 가능한 policy가 없으면 default deny가 적용되어 row가 보이거나 수정되지 않는다.
- 적용 가능한 policy가 있으면
USING과WITH CHECK가 실제 row 가시성과 쓰기를 결정한다.
검증기가 읽는 값과 PostgreSQL 의미를 분리한다
:::evidence key="rls-three-preconditions" alt="분석 문서 final/document.md 에서 이 기록의 근거 절을 그대로 잘라낸 18줄. 코드베이스를 측정한 것이 아니라 원본 판정이 무엇을 적었는지를 보여 준다." caption="final/document.md 발췌 — 18줄" zoom="true" :::
두 번째 인자 true 가 fail-closed 를 만든다
policy가 current_setting('app.tenant_id', true)를 쓴다 — 두 번째 인자 true가 미설정 시 raise 대신 NULL을 반환하고, NULL은 절대 tenant_id와 같지 않다.
:::note
실제 RLS 환경에서 각 적용 분기를 하나씩 재현하지 않았다
:::
기존 verifier javadoc이 적은 세 경우
/**
* Proves the runtime role cannot bypass row-level security (experimental plan Task 3).
*
* <p>Three ways RLS silently does nothing, all checked here:
*
* <ul>
* <li>The table has no policy, or RLS was never enabled on it.
* <li>The runtime role has {@code BYPASSRLS}.
* <li>The runtime role <em>owns</em> the table — table owners are exempt from RLS unless the
* table is set to {@code FORCE ROW LEVEL SECURITY}, which is the one people forget.
* </ul>
*
* <p>Each of those produces a system where every query returns every tenant's rows while the
* policies look correctly configured.
*/
위 javadoc은 현재 검증기가 의도한 모델을 보여 주지만, ‘세 경우 모두 모든 row를 반환한다’는 일반화는 PostgreSQL 의미와 맞지 않는다. 특히 RLS가 켜진 상태에서 applicable policy가 없으면 일반 role에는 default deny가 적용된다.
| 확인 항목 | PostgreSQL에서의 의미 |
|---|---|
| RLS 활성 여부 | 꺼져 있으면 policy가 적용되지 않는다 |
superuser / BYPASSRLS |
RLS를 우회한다 |
| table owner | 기본적으로 우회하며 FORCE ROW LEVEL SECURITY가 owner 동작을 바꾼다 |
| applicable policy | 없으면 policy 대상 role에는 default deny가 적용된다 |
소유자 면제가 왜 함정인가
테이블 소유자는 기본적으로 RLS policy를 우회한다. owner도 policy 대상이어야 한다면 FORCE ROW LEVEL SECURITY를 켠다. 이 설정은 superuser나 BYPASSRLS role의 우회를 없애는 옵션이 아니다.
스키마를 만든 migration role이 해당 table owner가 되는 경우가 있다. 이때 중요한 것은 migration role이라는 이름이 아니라 owner 여부다. superuser나 BYPASSRLS 여부는 별도의 role 속성이고, 검증에 같은 owner role을 쓰면 owner bypass가 policy 적용 여부를 가릴 수 있다.
:::danger
migration role이 해당 table owner이고 FORCE ROW LEVEL SECURITY가 꺼진 상태에서 그 롤로 테스트하면 owner bypass 때문에 policy가 적용되지 않은 채 테스트가 통과할 수 있다. migration role이라는 이름 자체는 bypass 조건이 아니다. superuser나 BYPASSRLS라면 그 속성 때문에 별도로 우회한다.
:::
롤 속성은 시작에서 확인해야 한다
BYPASSRLS 는 테이블 속성이 아니라 롤 속성이다. 스키마를 아무리 살펴도 나오지 않는다.
그래서 시작 시점에 단언한다. 런타임 롤이 그 속성을 갖지 않는지 데이터베이스에 물어본다.
미설정 시 fail-closed
정책이 세션 설정을 읽을 때 두 번째 인자를 참으로 준다.
current_setting('app.tenant_id', true)
그 인자가 참이면 설정이 없을 때 예외를 던지는 대신 널을 돌려준다. 그리고 널은 어떤 테넌트 식별자와도 같지 않다.
즉 테넌트 바인딩을 잊은 세션은 아무 행도 보지 못한다. 모든 행을 보는 것이 아니라.