Oracle 8 — Bảo mật, người dùng & vận hành

Bài này khép lại series Oracle chuyên sâu. Sau khi đã đi qua kiến trúc và tính sẵn sàng cao với RAC/Data Guard, phần cuối cùng và thường bị xem nhẹ nhất là bảo mật và vận hành — mảng quyết định liệu một Oracle Database "core" của ngân hàng có sống sót qua một cuộc kiểm tra an ninh, một đợt kiểm toán tuân thủ, hay một sự cố rò rỉ dữ liệu hay không.

Oracle là một trong những hệ CSDL có bộ công cụ bảo mật đầy đủ nhất thị trường: từ quản lý truy cập tinh vi, mã hoá trong suốt (TDE), kiểm toán tập trung (Unified Auditing), đến che dữ liệu ở mức dòng (VPD) và mức hiển thị (Data Redaction). Bài viết đi lần lượt qua các lớp này rồi kết bằng chủ đề khai thác dữ liệu ra ngoài — làm sao đưa dữ liệu Oracle sang data warehouse (DWH)/lake một cách an toàn.

Lưu ý đọc bài: Sandbox SQL của Knowledge Base chạy trên PostgreSQL. Toàn bộ lệnh Oracle trong bài (TDE, AUDIT POLICY, DBMS_RLS, expdp...) KHÔNG chạy được ở đây và được đánh dấu (minh hoạ — Oracle, không chạy trong sandbox Postgres). Bài này không có ví dụ "▶ Chạy được".

Bức tranh tổng thể: các lớp bảo mật

Bảo mật Oracle không phải một công tắc mà là nhiều lớp phòng thủ (defense in depth) xếp chồng. Một request đi từ ngoài vào phải vượt qua lần lượt: xác thực → phân quyền → dữ liệu được mã hoá khi lưu → mọi hành động bị ghi vết → và dữ liệu nhạy cảm bị lọc/che trước khi trả về.

Mấu chốt: mỗi lớp độc lập. Kẻ tấn công lấy được mật khẩu (vượt lớp 1) vẫn bị chặn bởi quyền hạn (lớp 2); DBA có quyền cao vẫn có thể bị Database Vault chặn không cho đọc dữ liệu nghiệp vụ; kẻ trộm cả file datafile vẫn chỉ thấy khối byte mã hoá (lớp TDE).

Lớp 1–2: Quản lý truy cập

User, privilege, role

Ba khái niệm nền tảng:

• User (schema): một tài khoản đăng nhập, đồng thời là một schema chứa các đối tượng (table, view, procedure...) do user đó sở hữu. Ở Oracle, user và schema gần như đồng nghĩa.
• Privilege (quyền): có hai loại.
  • System privilege — quyền làm một việc ở cấp hệ thống: CREATE SESSION, CREATE TABLE, SELECT ANY TABLE, CREATE USER...
  • Object privilege — quyền trên một đối tượng cụ thể: SELECT/INSERT/UPDATE/DELETE trên một bảng, EXECUTE trên một procedure.
• Role (vai trò): một nhóm quyền đặt tên được, cấp cho user để dễ quản lý. Thay vì cấp 20 quyền lẻ cho 50 nhân viên, bạn gom chúng vào một role rồi cấp role đó.

-- (minh hoạ — Oracle, không chạy trong sandbox Postgres)

-- Tạo user mới với quota và tablespace mặc định
CREATE USER app_ro IDENTIFIED BY "Str0ng#Pass"
  DEFAULT TABLESPACE users
  QUOTA 0 ON users;              -- read-only: không cho tạo dữ liệu

GRANT CREATE SESSION TO app_ro; -- system privilege: được đăng nhập

-- Tạo role gom quyền đọc báo cáo
CREATE ROLE report_reader;
GRANT SELECT ON sales.orders     TO report_reader;  -- object privilege
GRANT SELECT ON sales.customers  TO report_reader;

-- Cấp role cho user
GRANT report_reader TO app_ro;

-- Thu hồi
REVOKE report_reader FROM app_ro;

GRANT, REVOKE và PUBLIC

GRANT cấp quyền, REVOKE thu hồi. Có hai bẫy phổ biến:

• WITH ADMIN OPTION / WITH GRANT OPTION: cho phép người nhận cấp lại quyền cho người khác. Dùng dè dặt — nó làm quyền lan không kiểm soát.
• PUBLIC: là "pseudo-role" đại diện cho mọi user. GRANT SELECT ON t TO PUBLIC mở bảng cho tất cả. Đây là nguồn lỗ hổng kinh điển; nhiều gói cài đặt mặc định cấp quyền cho PUBLIC (ví dụ EXECUTE trên một số package hệ thống). Rà soát và thu hồi các grant PUBLIC không cần thiết là bước hardening đầu tiên.

Profile: giới hạn tài nguyên và chính sách mật khẩu

Profile là tập giới hạn gán cho user, phục vụ hai mục đích:

• Giới hạn tài nguyên: số session đồng thời, thời gian CPU tối đa một lời gọi, thời gian idle trước khi bị ngắt...
• Chính sách mật khẩu: độ dài đời mật khẩu, số lần thử sai trước khi khoá tài khoản, số lần tái sử dụng mật khẩu cũ, hàm kiểm tra độ mạnh.

-- (minh hoạ — Oracle, không chạy trong sandbox Postgres)
CREATE PROFILE secure_app LIMIT
  FAILED_LOGIN_ATTEMPTS 5        -- khoá sau 5 lần sai
  PASSWORD_LIFE_TIME    90       -- mật khẩu hết hạn sau 90 ngày
  PASSWORD_REUSE_MAX    5        -- không dùng lại 5 mật khẩu gần nhất
  PASSWORD_LOCK_TIME    1        -- khoá 1 ngày sau khi vượt số lần sai
  IDLE_TIME             30       -- ngắt session idle quá 30 phút
  SESSIONS_PER_USER     10;

ALTER USER app_ro PROFILE secure_app;

Nguyên tắc least privilege

Kim chỉ nam: cấp đúng những gì cần, không hơn. Cụ thể trong thực tế:

• Ứng dụng nên dùng tài khoản chức năng riêng, không dùng tài khoản có quyền cao (SYSTEM, SYS).
• Tách quyền đọc và ghi: service báo cáo chỉ cần role read-only.
• Không cấp ANY (SELECT ANY TABLE, DROP ANY TABLE) trừ khi thật sự cần — đây là các quyền "chọc thủng" mọi schema.
• Rà soát định kỳ ai đang giữ quyền gì (DBA_ROLE_PRIVS, DBA_SYS_PRIVS, DBA_TAB_PRIVS).

Lớp 3: Mã hoá với TDE

TDE là gì

TDE — Transparent Data Encryption mã hoá dữ liệu khi lưu (at rest): nội dung datafile, backup và redo log trên đĩa đều là byte đã mã hoá. "Transparent" nghĩa là ứng dụng không cần sửa gì — Oracle tự mã hoá khi ghi và giải mã khi đọc, hoàn toàn trong lòng database. Kẻ đánh cắp file vật lý không đọc được gì nếu không có khoá.

TDE bảo vệ dữ liệu lúc lưu, không phải lúc truy vấn: một user đã đăng nhập hợp lệ và có quyền vẫn thấy dữ liệu rõ. Đừng nhầm TDE với kiểm soát truy cập.

Keystore/wallet và master key

Kiến trúc khoá của TDE gồm hai tầng:

• Master encryption key — nằm trong keystore (wallet) bên ngoài database, hoặc trong external keystore như Oracle Key Vault/OCI Vault. Cấu hình vị trí qua tham số WALLET_ROOT và TDE_CONFIGURATION.
• Table/tablespace key — khoá thực sự mã hoá dữ liệu, được master key bảo vệ và cất trong data dictionary.

Keystore phải được mở thì database mới giải mã được dữ liệu. Đây cũng là điểm vận hành: sau restart, keystore cần mở lại (auto-login wallet giúp tự mở).

-- (minh hoạ — Oracle, không chạy trong sandbox Postgres)

-- 1) Tạo và mở software keystore (chạy ở SYSKM/qua ADMINISTER KEY MANAGEMENT)
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE IDENTIFIED BY "wallet_pw";
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "wallet_pw";

-- 2) Đặt master encryption key
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "wallet_pw" WITH BACKUP;

-- 3a) Mã hoá theo CỘT
CREATE TABLE customers (
  id      NUMBER,
  name    VARCHAR2(100),
  ssn     VARCHAR2(20) ENCRYPT USING 'AES256'   -- cột nhạy cảm được mã hoá
);
ALTER TABLE accounts MODIFY (card_no ENCRYPT);

-- 3b) Mã hoá cả TABLESPACE (khuyến nghị: đơn giản, phủ toàn bộ)
CREATE TABLESPACE secure_ts
  DATAFILE '/u02/oradata/secure01.dbf' SIZE 1G
  ENCRYPTION USING 'AES256' ENCRYPT;

Cột vs tablespace: mã hoá theo tablespace là lựa chọn phổ biến hơn vì đơn giản, không có ràng buộc (mã hoá cột không dùng được với foreign key tham chiếu chéo, một số kiểu index...). Nếu chỉ vài cột PII cần bảo vệ và muốn overhead tối thiểu thì dùng column encryption.

Mã hoá trên đường truyền và Data Pump

TDE lo dữ liệu at rest; còn dữ liệu in transit giữa client và server thì dùng Native Network Encryption (cấu hình trong sqlnet.ora) hoặc TLS cho listener. Khi export bằng Data Pump, dùng tuỳ chọn encryption để file dump cũng được mã hoá — nếu không, file .dmp là bản sao rõ của dữ liệu, một lỗ rò rất hay bị bỏ sót:

-- (minh hoạ — Oracle, không chạy trong sandbox Postgres) — export có mã hoá
-- expdp app/*** schemas=SALES directory=DP_DIR dumpfile=sales.dmp \
--   ENCRYPTION=ALL ENCRYPTION_ALGORITHM=AES256 ENCRYPTION_MODE=PASSWORD

Lớp ghi vết: Kiểm toán (Audit)

Traditional auditing vs Unified Auditing

Oracle có hai thế hệ kiểm toán:

• Traditional auditing (trước 12c): dùng AUDIT/NOAUDIT, ghi vết rải rác ở nhiều nơi (SYS.AUD$, file OS, FGA_LOG$). Khó quản lý và tốn hiệu năng.
• Unified Auditing (từ 12c): gom tất cả vết kiểm toán vào một bảng duy nhất AUD$UNIFIED thuộc schema nội bộ AUDSYS, truy vấn qua view UNIFIED_AUDIT_TRAIL. Quản lý bằng audit policy có tên, bật/tắt linh hoạt, kèm điều kiện.

Trên database mới, mặc định là mixed mode (cả hai engine cùng chạy) để tương thích ngược. Oracle khuyến nghị chuyển sang pure unified auditing khi đã quen — có thể kiểm tra trạng thái qua view V$OPTION (giá trị của "Unified Auditing").

Vai trò AUDIT_ADMIN và cách dùng

Quản lý policy cần role AUDIT_ADMIN (hoặc quyền AUDIT SYSTEM); còn AUDIT_VIEWER chỉ để đọc vết. Việc tách người tạo policy khỏi người bị kiểm toán chính là ý nghĩa của separation of duties trong audit.

-- (minh hoạ — Oracle, không chạy trong sandbox Postgres)

-- Tạo policy: kiểm toán mọi hành động trên bảng nhạy cảm + các lệnh quyền cao
CREATE AUDIT POLICY sensitive_access_pol
  ACTIONS SELECT, UPDATE, DELETE ON sales.customers,
          CREATE USER, DROP USER, GRANT, ALTER SYSTEM;

-- Bật policy (có thể giới hạn theo user hoặc kết quả thành công/thất bại)
AUDIT POLICY sensitive_access_pol;
AUDIT POLICY sensitive_access_pol BY app_ro WHENEVER NOT SUCCESSFUL;

-- Xem vết
SELECT event_timestamp, dbusername, action_name, object_name
FROM   unified_audit_trail
WHERE  unified_audit_policies = 'SENSITIVE_ACCESS_POL'
ORDER  BY event_timestamp DESC;

Fine-Grained Auditing (FGA)

AUDIT POLICY bắt ở mức "ai làm gì trên bảng nào". Khi cần điều kiện tinh — ví dụ "chỉ ghi vết khi ai đó đọc cột salary của những người lương > 200 triệu" — dùng FGA qua DBMS_FGA.ADD_POLICY, cho phép đặt audit condition và relevant columns. FGA còn gọi được handler tuỳ biến (gửi cảnh báo).

Nơi lưu vết và vòng đời

Vết Unified Auditing nằm trong tablespace nội bộ (mặc định SYSAUX, nên chuyển sang tablespace riêng cho DB lớn) và phải được quản lý vòng đời: dọn vết cũ bằng DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL, đặt lịch archiving. Vết audit không dọn sẽ làm đầy SYSAUX và kéo cả database dừng ghi.

Lớp 3–4: Che và ẩn dữ liệu

VPD (Virtual Private Database) — bảo mật mức dòng

VPD (còn gọi row-level security của Oracle) tự động thêm một predicate WHERE vào mọi câu lệnh chạm bảng, dựa trên ngữ cảnh người dùng. Cơ chế: bạn viết một policy function trả về một chuỗi predicate, gắn nó vào bảng qua DBMS_RLS.ADD_POLICY. Từ đó, bất kể user truy vấn bằng cách nào, Oracle chèn predicate vào lúc parse — không thể lách bằng cách viết lại SQL.

-- (minh hoạ — Oracle, không chạy trong sandbox Postgres)

-- 1) Hàm policy trả về predicate: chỉ thấy dòng thuộc org của mình
CREATE OR REPLACE FUNCTION sales_org_predicate(
  schema_name IN VARCHAR2, table_name IN VARCHAR2
) RETURN VARCHAR2 AS
BEGIN
  RETURN 'org_id = SYS_CONTEXT(''app_ctx'', ''org_id'')';
END;
/

-- 2) Gắn policy vào bảng
BEGIN
  DBMS_RLS.ADD_POLICY(
    object_schema   => 'SALES',
    object_name     => 'ORDERS',
    policy_name     => 'ORDERS_ROW_SEC',
    function_schema => 'SALES',
    policy_function => 'SALES_ORG_PREDICATE',
    statement_types => 'SELECT,UPDATE,DELETE',
    update_check    => TRUE,          -- không cho ghi dòng ngoài phạm vi mình
    policy_type     => DBMS_RLS.CONTEXT_SENSITIVE
  );
END;
/

Từ đây, SELECT * FROM sales.orders của user A thực chất chạy như ... WHERE org_id = <org của A>. Tham số policy_type (STATIC, CONTEXT_SENSITIVE, DYNAMIC...) chi phối việc cache predicate để cân bằng bảo mật và hiệu năng; sec_relevant_cols cho phép chỉ áp policy khi truy vấn chạm cột nhạy cảm.

So với PostgreSQL RLS: ý tưởng giống nhau (thêm predicate mức dòng), nhưng Postgres khai báo bằng CREATE POLICY ... USING (...) thuần SQL, dạng khai báo (declarative); VPD của Oracle mạnh và linh hoạt hơn nhờ policy function bằng PL/SQL (logic tuỳ ý, dùng application context), đổi lại phức tạp hơn và cần code.

Data Redaction — che khi hiển thị

VPD lọc dòng; Data Redaction (DBMS_REDACT) che giá trị cột khi hiển thị mà không đổi dữ liệu gốc dưới đĩa. Ví dụ chỉ hiện 4 số cuối thẻ, thay số CMND bằng XXX. Khác biệt then chốt: redaction biến đổi cái người dùng thấy ngay khi trả kết quả; dữ liệu thật trong bảng không đổi và các phép tính/predicate của VPD vẫn chạy trên giá trị thật.

-- (minh hoạ — Oracle, không chạy trong sandbox Postgres)
BEGIN
  DBMS_REDACT.ADD_POLICY(
    object_schema  => 'SALES',
    object_name    => 'CUSTOMERS',
    column_name    => 'card_no',
    policy_name    => 'REDACT_CARD',
    function_type  => DBMS_REDACT.PARTIAL,          -- che một phần
    function_parameters => 'VVVVFVVVVFVVVVFVVVV,VVVV-VVVV-VVVV-VVVV,*,1,12',
    expression     => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') != ''PAYMENT_SVC'''
  );
END;
/

Vài điểm cần nhớ khi so VPD và Data Redaction: Data Redaction hoạt động ở mức cột, cho nhiều kiểu che (full/partial/random/regexp), nhưng chỉ một policy trên một object và không hỗ trợ mức dòng — muốn lọc dòng vẫn phải dùng VPD. VPD trước đây chỉ che kiểu NULL nên nhiều ứng dụng không dùng được cho việc "che hiển thị". Thực tế hai thứ bổ sung nhau: VPD chặn dòng, Redaction che ô.

Data Masking cho môi trường non-prod

Redaction che lúc hiển thị trên production. Còn khi copy dữ liệu sang môi trường test/dev, ta cần Data Masking (static masking) — thay hẳn giá trị nhạy cảm bằng dữ liệu giả bền vững (ví dụ đổi toàn bộ số CMND thật thành số giả có định dạng đúng). Dev không bao giờ chạm dữ liệu PII thật. Đây là một yêu cầu tuân thủ phổ biến (GDPR, PCI-DSS).

Database Vault và Label Security

• Database Vault giải bài toán "DBA thấy mọi thứ": mặc định tài khoản có quyền cao (SYS, SYSTEM, người có SELECT ANY TABLE) đọc được dữ liệu nghiệp vụ. Database Vault tạo realm bao quanh các đối tượng nhạy cảm và command rule để DBA vận hành hệ thống nhưng không đọc được dữ liệu — tách bạch quyền quản trị và quyền truy cập dữ liệu (separation of duties thực thụ). Đây là nền tảng khi cần chứng minh với auditor rằng "ngay cả DBA cũng không thể xem dữ liệu khách hàng".
• Label Security (OLS): gán nhãn phân loại (ví dụ: Public / Confidential / Secret) cho từng dòng và từng user, Oracle so nhãn để quyết định quyền đọc. Phù hợp mô hình mật đa cấp (chính phủ, quốc phòng). Với đa số hệ thống doanh nghiệp, VPD đã đủ; OLS chỉ nhắc để biết tồn tại.

Vận hành

• Data Pump (expdp/impdp): công cụ export/import chuẩn của Oracle — sao chép schema/bảng, di chuyển dữ liệu giữa các database, tạo bản logic backup. Nhớ bật encryption khi dump chứa PII (đã nói ở phần TDE).
• SQL*Plus / SQLcl: SQL*Plus là CLI kinh điển; SQLcl là bản hiện đại (Java, hỗ trợ lịch sử lệnh, format JSON/CSV, script). Dùng để chạy script vận hành, patch, migration.
• Enterprise Manager (OEM): bảng điều khiển giám sát tập trung — hiệu năng, chờ (wait events), dung lượng, cảnh báo, quản lý nhiều database. Tương đương ý tưởng giám sát ở bài bảo trì PostgreSQL nhưng ở quy mô fleet.
• Patch & nâng cấp: Oracle phát hành Release Update (RU) theo quý — cập nhật bảo mật và sửa lỗi tích luỹ. Nề nếp vận hành tốt: áp RU định kỳ, test ở non-prod trước, dùng rolling patch với RAC để giảm downtime (xem RAC/Data Guard).

Khai thác dữ liệu ra ngoài (an toàn)

Oracle core thường là hệ nguồn (system of record); dữ liệu cần chảy sang DWH/lake để phân tích mà không được cắm truy vấn phân tích nặng thẳng vào DB giao dịch. Các cách chính:

• Data Pump / ETL theo batch: đơn giản nhưng độ trễ cao, tải nặng vào cửa sổ chạy.
• CDC (Change Data Capture): bắt thay đổi (insert/update/delete) từ redo log rồi stream ra ngoài gần thời gian thực, tải rất nhẹ lên DB nguồn. Đây là chuẩn hiện đại. Trên Oracle, hai lựa chọn phổ biến:
  • Oracle GoldenGate — sản phẩm CDC/replication thương mại của Oracle, đọc redo, áp dụng thay đổi sang đích (kể cả non-Oracle).
  • Debezium — CDC mã nguồn mở, đẩy thay đổi vào Kafka.
• Chi tiết cơ chế redo/LogMiner, GoldenGate và Debezium đã có trong series Oracle CDC; phần vận chuyển qua Kafka.

Bảo mật khi trích xuất là phần rất dễ bị bỏ quên: dữ liệu rời khỏi vòng bảo vệ của Oracle (TDE, VPD, Vault) là mất luôn các lớp đó. Nguyên tắc:

• Mask/tokenize PII ngay trong pipeline trước khi đổ vào lake — số CMND, thẻ, số điện thoại không nên tồn tại ở dạng rõ trong DWH nếu không cần.
• Mã hoã đường truyền và at-rest ở đích: TLS cho Kafka, mã hoá bucket của lake.
• Least privilege cho tài khoản CDC: tài khoản GoldenGate/Debezium chỉ cần quyền đọc redo và các bảng cần thiết, không hơn.
• Ghi vết: chính hoạt động trích xuất cũng nên nằm trong audit policy.

Use case thực tế

Tình huống: một ngân hàng có Oracle core lưu tài khoản khách hàng, cần vừa siết bảo mật cho DB core vừa đưa dữ liệu sang data lake để đội phân tích rủi ro dùng.

Siết DB core:

1. Least privilege + profile: ứng dụng dùng tài khoản chức năng riêng; service báo cáo chỉ có role read-only; áp profile khoá tài khoản sau 5 lần sai, ép đổi mật khẩu 90 ngày; thu hồi mọi grant PUBLIC thừa và các quyền ANY.
2. TDE: mã hoá tablespace chứa dữ liệu khách hàng (AES256), keystore đặt trong Oracle Key Vault; bật encryption cho mọi backup và Data Pump dump.
3. Unified Auditing: policy ghi vết mọi SELECT/UPDATE/DELETE trên bảng khách hàng, mọi GRANT, mọi login thất bại; vết đẩy sang tablespace riêng, dọn tự động sau 1 năm; tách người quản trị audit (AUDIT_ADMIN) khỏi DBA thường.
4. VPD + Redaction + Vault: VPD lọc để nhân viên chi nhánh chỉ thấy khách của chi nhánh mình; Data Redaction che số thẻ (chỉ hiện 4 số cuối) trừ service thanh toán; Database Vault chặn cả DBA đọc bảng khách hàng.

Trích xuất an toàn sang lake:

5. CDC bằng GoldenGate đọc redo, tải nhẹ lên core; bước masking trong pipeline thay PII bằng token trước khi vào Kafka; lake mã hoá at-rest; tài khoản CDC least privilege và bị audit.

Kết quả: DB core vừa an toàn theo defense-in-depth, vừa cấp dữ liệu cho phân tích mà không rò PII và không đụng đến hiệu năng giao dịch.

Ghi nhớ

• Bảo mật là nhiều lớp: xác thực → phân quyền → mã hoá at-rest → audit → che dữ liệu. Mỗi lớp độc lập; đừng dựa vào một lớp duy nhất.
• Least privilege là gốc: role gom quyền, tách read/write, tránh ANY và grant PUBLIC; dùng profile cho chính sách mật khẩu và tài nguyên.
• TDE bảo vệ dữ liệu at rest (đĩa, backup, dump) — không phải kiểm soát truy cập. Nhớ mã hoá cả network và Data Pump. Ưu tiên mã hoá theo tablespace.
• Unified Auditing gom vết vào AUD$UNIFIED, quản lý bằng audit policy (role AUDIT_ADMIN); dùng FGA khi cần điều kiện tinh; phải dọn vết để không đầy SYSAUX.
• VPD = row-level security bằng policy function (predicate động, không lách được); Data Redaction = che cột khi hiển thị; Data Masking = thay dữ liệu cho non-prod. Ba thứ bổ sung nhau.
• Database Vault tách quyền DBA khỏi quyền đọc dữ liệu — chìa khoá cho tuân thủ "DBA không xem được dữ liệu".
• Trích xuất ra ngoài bằng CDC/GoldenGate/Debezium (nối series Oracle CDC + Kafka): tải nhẹ, gần real-time — nhưng mask PII và mã hoá vì dữ liệu rời khỏi các lớp bảo vệ của Oracle.

Bài trước trong series: Oracle 7 — RAC & Data Guard (HA). Xem lại nền tảng ở Oracle 1 — Kiến trúc. Đây là bài cuối của series Oracle chuyên sâu.