Row Level Security (RLS) — 행 단위 보안 · 멀티테넌트 설계
📋 실습 안내
✏️ CODE EDITOR (JSX)
▶ 실행 버튼을 눌러 코드를 테스트하세요.
👁️ 내 미리보기
내 코드 실행 결과
🎯 완성 미리보기
목표
위 에디터 코드를 수정해서 이 결과물과 똑같이 만들어보세요!
💡 TODO 주석을 채워서 위 결과물처럼 동작하게 만들어보세요
🤖 AI 선생님에게 질문하기
이번 강의 전용
▼
선생님이 답변 중이에요...
⚠️ 학습 관련 질문만 답변합니다. 관련 없는 질문은 자동으로 학습으로 유도됩니다.
Q1. Row Level Security(RLS)를 테이블에 활성화하는 명령어는?
💡 ALTER TABLE ... ENABLE ROW LEVEL SECURITY 명령으로 RLS를 활성화합니다. 활성화 후 반드시 CREATE POLICY로 접근 Policy를 정의해야 합니다. Policy 없이 활성화하면 아무 행도 보이지 않습니다.
Q2. RLS Policy에서 USING 절과 WITH CHECK 절의 차이는?
💡 USING(expr)는 SELECT/UPDATE/DELETE 시 기존 행에 대한 가시성 필터입니다. WITH CHECK(expr)는 INSERT/UPDATE 시 새로 작성할 행이 조건을 만족하는지 검증합니다.
Q3. FORCE ROW LEVEL SECURITY 설정의 목적은?
💡 기본적으로 테이블 소유자(owner)는 RLS를 우회합니다. FORCE ROW LEVEL SECURITY 설정 시 소유자도 Policy의 적용을 받습니다. 단, 슈퍼유저와 BYPASSRLS 역할은 여전히 우회합니다.
Q4. 멀티테넌트 환경에서 RLS Policy를 사용할 때 성능을 위해 반드시 해야 하는 것은?
💡 RLS Policy는 내부적으로 WHERE tenant_id = ? 조건을 추가합니다. tenant_id에 인덱스가 없으면 모든 쿼리가 전체 테이블 순차 스캔을 수행하여 성능이 크게 저하됩니다.
Q5. current_setting('app.tenant_id') 함수가 RLS Policy에서 하는 역할은?
💡 SET app.tenant_id = '42'로 설정한 사용자 정의 파라미터를 current_setting('app.tenant_id')으로 읽습니다. 애플리케이션은 쿼리 실행 전 SET 명령으로 현재 테넌트 ID를 세션에 주입합니다.
😅
아쉽네요!
점수: 0점 — 70점 이상이 되어야 통과합니다.