Files
vpd-permission-poc/database/adb/07_end_users.sql

78 lines
3.3 KiB
SQL

-- ============================================================
-- 07_end_users.sql
-- Create the FOUR end-user accounts with MINIMAL privileges.
-- Add a LOGON trigger that loads each user's context automatically.
-- Run as ADMIN.
--
-- DEFINE: &VPDUSER_MY_PASSWORD, &VPDUSER_PG_PASSWORD,
-- &VPDUSER_BOTH_PASSWORD, &VPDUSER_NONE_PASSWORD
-- ============================================================
SET ECHO OFF
SET FEEDBACK ON
SET DEFINE ON
SET VERIFY OFF -- 비번이 'new 1:' 라인으로 echo 되는 것을 막음 (leak 방지)
PROMPT === Creating end-user accounts ===
-- Passwords come from .env (DEFINE) so they aren't hardcoded in source.
-- Production should use IAM / proxy auth / mTLS instead of static passwords.
CREATE USER vpduser_my IDENTIFIED BY "&VPDUSER_MY_PASSWORD";
CREATE USER vpduser_pg IDENTIFIED BY "&VPDUSER_PG_PASSWORD";
CREATE USER vpduser_both IDENTIFIED BY "&VPDUSER_BOTH_PASSWORD";
CREATE USER vpduser_none IDENTIFIED BY "&VPDUSER_NONE_PASSWORD";
-- Login privilege only. No QUOTA — these users never create objects.
GRANT CREATE SESSION TO vpduser_my;
GRANT CREATE SESSION TO vpduser_pg;
GRANT CREATE SESSION TO vpduser_both;
GRANT CREATE SESSION TO vpduser_none;
PROMPT === Granting SELECT on the policy-protected views ONLY ===
-- We deliberately grant SELECT on BOTH views to all four users.
-- The VPD policy decides what they actually see — including 0 rows
-- when there is no permission row. This is what makes the demo a
-- clean security boundary: revoking access doesn't mean revoking
-- the GRANT; it means removing the row in `permission`.
GRANT SELECT ON v_customers_pg TO vpduser_my;
GRANT SELECT ON v_customers_my TO vpduser_my;
GRANT SELECT ON v_customers_pg TO vpduser_pg;
GRANT SELECT ON v_customers_my TO vpduser_pg;
GRANT SELECT ON v_customers_pg TO vpduser_both;
GRANT SELECT ON v_customers_my TO vpduser_both;
GRANT SELECT ON v_customers_pg TO vpduser_none;
GRANT SELECT ON v_customers_my TO vpduser_none;
-- ctx_pkg is bound to the secure context; calling it is harmless
-- (the package always loads ONLY the caller's own permissions).
GRANT EXECUTE ON ctx_pkg TO vpduser_my;
GRANT EXECUTE ON ctx_pkg TO vpduser_pg;
GRANT EXECUTE ON ctx_pkg TO vpduser_both;
GRANT EXECUTE ON ctx_pkg TO vpduser_none;
-- NOTE on what we are deliberately NOT granting:
-- * NO grant on app_user / permission / etc. -> users can't read who-can-see-what
-- * NO grant on the underlying @dblink tables -> can't bypass the view
-- * NO grant on DBMS_RLS -> can't alter/drop the policy
-- * NO EXEMPT ACCESS POLICY -> can't escape VPD
-- * NO CREATE TABLE / CREATE MATERIALIZED VIEW -> can't snapshot filtered data
-- * NO DBA / PDB_DBA / RESOURCE roles -> least privilege
PROMPT === Creating LOGON trigger that auto-loads context ===
CREATE OR REPLACE TRIGGER vpd_logon_trg
AFTER LOGON ON DATABASE
BEGIN
-- Only fire for our application end-users. ADMIN logons keep normal behavior.
IF SYS_CONTEXT('USERENV','SESSION_USER') IN
('VPDUSER_MY','VPDUSER_PG','VPDUSER_BOTH','VPDUSER_NONE') THEN
admin.ctx_pkg.init;
END IF;
EXCEPTION
WHEN OTHERS THEN
-- Never block login on a context-loading error; fail closed (no perms loaded
-- means policy returns 1=0, i.e. no rows). Log if you have an audit table.
NULL;
END;
/
PROMPT === End-users ready ===
EXIT;