1. Secure View란?
- 기반 테이블(underlying table) 또는 뷰의 내부 구조적 세부사항(internal structural details) 에 대한 접근을 제한하도록 설계된 뷰
- 데이터 프라이버시(민감 데이터 보호) 목적으로 사용
- ⚠️ 단순 쿼리 편의(query convenience) 목적의 뷰에는 사용하지 말 것
2. 핵심 특징 ⭐
① Standard / Materialized View 모두 secure 지정 가능
- 일반 뷰(Standard View)와 구체화 뷰(Materialized View) 둘 다 secure로 지정 가능
② SECURE 키워드로 생성
- View DDL에
SECURE 키워드를 추가하여 생성
CREATE OR REPLACE SECURE VIEW MY_SEC_VIEW AS
SELECT COL1, COL2, COL3 FROM MY_TABLE;
기존 뷰 ↔ secure 뷰 전환: ALTER VIEW / ALTER MATERIALIZED VIEW에서 SECURE set/unset
③ 뷰 정의(definition)는 객체 소유자(owner)에게만 공개
- secure view의 정의(definition/text)는 인가된 사용자(소유 role)만 볼 수 있음
- 일반(non-secure) 뷰는 정의가 다른 사용자에게도 노출됨
- 정의 확인 명령/인터페이스:
SHOW VIEWS;
GET_DDL();
- Information Schema
- Account Usage
④ Query Optimization 우회(bypass) ⭐⭐
- Secure view는 기반 테이블 데이터를 무심코 노출시킬 수 있는 쿼리 최적화(query optimizations)를 우회함
- 일반 뷰는 옵티마이저가 WHERE 절 술어(predicate)를 재정렬할 수 있어, 사용자 필터가 인가(authorization) 술어보다 먼저 실행될 위험이 있음
- Secure view는 이를 막아 데이터가 노출되지 않도록 보장
- 🔻 트레이드오프: 최적화를 건너뛰므로 쿼리 성능이 저하될 수 있음
3. Query Optimizer 동작
일반 뷰: 사용자 → Filter → Authorization (Filter가 먼저 실행될 수 있음 → 노출 위험)
Secure View: Authorization을 먼저 보장 (Filter 재정렬 차단)
🎯 핵심 포인트
| 항목 | 핵심 |
|---|
| 생성 방법 | DDL에 SECURE 키워드 |
| 적용 대상 | Standard + Materialized View 둘 다 |
| 정의(definition) 가시성 | 객체 소유자(owner)만 확인 가능 |
| 보안 핵심 | Query Optimizer의 predicate 재정렬 최적화 우회 |
| 단점 | 쿼리 성능 저하 가능 |
| 정의 확인 도구 | SHOW VIEWS / GET_DDL() / Information Schema / Account Usage |
💡 추가
- Secure UDF / Stored Procedure도 동일 원리 (
SECURE 키워드로 옵티마이저 최적화 우회)
- 같은 테이블을 secure UDF로만 접근시킨다면, 그 테이블을 쓰는 뷰도 secure로 만드는 것이 권장됨