Mục lục

Data Governance trong eCommerce: Thiết lập Row‑Level Security (RLS) để quản lý vùng dữ liệu

Mục tiêu: Cung cấp hướng dẫn chi tiết, “cầm lên làm được ngay”, cho các team Dev/BA/PM muốn triển khai chính sách bảo mật dữ liệu cấp dòng (Row‑Level Security) trong môi trường eCommerce quy mô 100‑1000 tỷ VNĐ/tháng.

1. Giới thiệu và tầm quan trọng của Data Governance trong eCommerce

Theo Statista 2024, doanh thu eCommerce Việt Nam đạt 150 tỷ USD (~3.600 tỷ VNĐ) và dự kiến tăng 12 % mỗi năm. Khi khối lượng giao dịch và dữ liệu khách hàng tăng nhanh, việc định danh, phân quyền và giám sát truy cập dữ liệu trở thành yếu tố quyết định độ tin cậy và tuân thủ pháp luật (GDPR, CCPA, quy định bảo vệ dữ liệu cá nhân VN 2023).

Row‑Level Security (RLS) cho phép:

Giới hạn mỗi người dùng chỉ xem dữ liệu thuộc khu vực (region) hoặc cửa hàng (store) được phân quyền.
Giảm rủi ro rò rỉ dữ liệu nội bộ (ví dụ: nhân viên miền Bắc không thể truy cập đơn hàng miền Nam).
Tăng tính auditability: mọi truy vấn đều được ghi log kèm “region_id” của người thực hiện.

2. Kiến trúc tổng quan và workflow vận hành

+-------------------+      +-------------------+      +-------------------+
|   Frontend (SPA)  | ---> |   API Gateway     | ---> |   Auth Service    |
+-------------------+      +-------------------+      +-------------------+
                                 |                         |
                                 v                         v
                         +-------------------+   +-------------------+
                         |   Business Logic  |   |   RLS Policy DB   |
                         +-------------------+   +-------------------+
                                 |                         |
                                 v                         v
                         +-------------------+   +-------------------+
                         |   PostgreSQL      |   |   Audit Log DB    |
                         +-------------------+   +-------------------+

Workflow (text art)

[User] → (Login) → [Auth Service] → JWT (region_id) → 
[API Gateway] → (Validate JWT) → 
[Business Logic] → (Apply RLS) → PostgreSQL → (Result) → 
[Frontend] → Display

Auth Service phát hành JWT chứa region_id.
API Gateway kiểm tra JWT, truyền region_id tới DB thông qua SET SESSION hoặc application_name.
PostgreSQL áp dụng policy USING (region_id = current_setting('app.region_id')::int) cho mỗi bảng quan trọng (orders, customers, payments).

3. Lựa chọn công nghệ (Tech Stack) cho Row‑Level Security

Tiêu chí	PostgreSQL + RLS	MySQL 8.0 + Views	Snowflake + Secure Views	MongoDB + Realm Rules
Hiệu năng 🏎️	99.8 % (tối ưu index)	95 % (view overhead)	98 % (columnar)	96 % (document)
Chi phí (30 tháng)	1 200 USD	1 000 USD	2 500 USD	1 400 USD
Khả năng mở rộng	Horizontal sharding	Replication only	Auto‑scale cloud	Sharding via Atlas
Hỗ trợ RLS native	✅	❌ (view)	✅ (Secure Views)	✅ (Realm)
Công cụ quản lý	pgAdmin, Prisma	MySQL Workbench	SnowSQL, Snowsight	MongoDB Compass
Độ phức tạp triển khai	Trung bình	Cao (maintain view)	Cao (cloud config)	Trung bình
Tích hợp CI/CD	Docker, GitHub Actions	Docker, GitLab CI	Terraform, GitHub Actions	Docker, CircleCI

Lựa chọn đề xuất: PostgreSQL 15 + Prisma ORM vì hỗ trợ RLS native, chi phí thấp, và dễ tích hợp vào pipeline CI/CD hiện có.

4. Thiết kế chi phí 30 tháng và dự báo tài chính

4.1 Bảng chi phí chi tiết (USD)

Mục	Tháng 1‑12	Tháng 13‑24	Tháng 25‑30	Tổng cộng
PostgreSQL Cloud (RDS)	300 USD	300 USD	300 USD	1 800 USD
Prisma + License	150 USD	150 USD	150 USD	900 USD
Auth Service (Keycloak)	200 USD	200 USD	200 USD	600 USD
API Gateway (Kong)	250 USD	250 USD	250 USD	750 USD
CI/CD (GitHub Actions)	100 USD	100 USD	100 USD	300 USD
Monitoring (Grafana Cloud)	120 USD	120 USD	120 USD	360 USD
Tổng chi phí	1 120 USD	1 120 USD	1 120 USD	3 360 USD

Công thức tính tổng chi phí
Tổng chi phí = Σ (Chi phí mục × Số tháng)

4‑2 ROI (Return on Investment)

Total_Benefits: giảm 0.8 % rủi ro vi phạm dữ liệu → 0.8 % × 150 tỷ USD = 1.2 tỷ USD (ước tính).
Investment_Cost: 3.36 tỷ USD (30 tháng).

ROI ≈ (1.2 tỷ – 3.36 tỷ) / 3.36 tỷ × 100 % ≈ – 71 % (đây là chi phí phòng ngừa; lợi ích phi tài chính (độ tin cậy, tuân thủ) không thể định lượng trực tiếp).

5. Lộ trình triển khai (Timeline) và Gantt chart

5.1 Bảng Timeline (tuần)

Phase	Tuần 1‑2	Tuần 3‑4	Tuần 5‑6	Tuần 7‑8	Tuần 9‑10
1️⃣ Phân tích yêu cầu	✅
2️⃣ Thiết kế RLS policy		✅	✅
3️⃣ Xây dựng CI/CD		✅	✅	✅
4️⃣ Triển khai môi trường			✅	✅	✅
5️⃣ Kiểm thử & audit				✅	✅
6️⃣ Go‑live & chuyển giao					✅

5.2 Gantt chart (ASCII)

Phase 1: Requirement   |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■|
Phase 2: Design RLS    |          ■■■■■■■■■■■■■■■■■■■■■■■■■|
Phase 3: CI/CD Setup   |                ■■■■■■■■■■■■■■■|
Phase 4: Deploy Infra  |                     ■■■■■■■■■■■■■■■■■■■■■■■|
Phase 5: Test & Audit  |                                 ■■■■■■■■■■■■■■■■■■■■■■■|
Phase 6: Go‑Live       |                                             ■■■■■■■■■■■■■■■■■■■■■■■|

Dependency: Phase 2 phụ thuộc vào Phase 1; Phase 3 có thể chạy song song với Phase 2; Phase 4 chỉ bắt đầu sau khi CI/CD đã sẵn sàng; Phase 5 cần môi trường hoàn chỉnh; Phase 6 chỉ thực hiện khi Phase 5 đạt “Pass”.

6. Các bước triển khai chi tiết (6 Phase)

Phase	Mục tiêu	Công việc con	Người chịu trách nhiệm	Thời gian	Dependency
1. Phân tích yêu cầu	Xác định vùng dữ liệu, quyền truy cập	1. Thu thập danh sách region/store 2. Định danh các bảng nhạy cảm 3. Xác định vai trò (admin, manager, staff) 4. Đánh giá quy định pháp lý 5. Lập bản mô tả RLS yêu cầu 6. Đánh giá impact trên reporting	Business Analyst	Tuần 1‑2	–
2. Thiết kế RLS policy	Xây dựng policy SQL & mô hình RBAC	1. Định nghĩa `region_id` trong JWT 2. Tạo hàm `set_region()` trong DB 3. Viết policy `USING (region_id = current_setting('app.region_id')::int)` 4. Kiểm tra tương thích với Prisma 5. Định nghĩa audit trigger 6. Tài liệu policy spec	Solution Architect	Tuần 3‑4	Phase 1
3. Xây dựng CI/CD	Tự động hoá build, test, deploy	1. Dockerfile cho PostgreSQL + extensions 2. GitHub Actions workflow (build, test, push) 3. Terraform script tạo RDS 4. Helm chart cho Kong API Gateway 5. Kiểm thử unit policy bằng pgTAP 6. Thiết lập secret management (AWS Secrets Manager)	DevOps Engineer	Tuần 4‑6	Phase 2
4. Triển khai môi trường	Đưa infra lên cloud, cấu hình RLS	1. Provision RDS (multi‑AZ) 2. Deploy Auth Service (Keycloak) 3. Cấu hình Kong JWT plugin 4. Apply DB migrations (Flyway) 5. Load seed data (region mapping) 6. Kiểm tra connectivity	Cloud Engineer	Tuần 6‑9	Phase 3
5. Kiểm thử & audit	Đảm bảo chính sách hoạt động đúng	1. Test case: staff A (region 1) không thấy order region 2 2. Pen‑test JWT tampering 3. Load test 10 k QPS 4. Audit log verification 5. Review compliance checklist 6. Sign‑off from Legal	QA Lead & Security Analyst	Tuần 9‑10	Phase 4
6. Go‑live & chuyển giao	Đưa vào production, bàn giao tài liệu	1. Deploy to prod (blue‑green) 2. Switch DNS 3. Monitor KPI (latency, error rate) 4. Training cho ops 5. Bàn giao tài liệu (15 mục) 6. Post‑mortem & lessons learned	Project Manager	Tuần 11‑12	Phase 5

7. Rủi ro, phương án B và C

Rủi ro	Mức độ	Phương án A (Giảm thiểu)	Phương án B (Dự phòng)	Phương án C (Khôi phục)
JWT bị giả mạo (tampering)	Cao	Sử dụng RSA‑256, rotate keys mỗi 30 ngày	Deploy WAF (Cloudflare) để block abnormal JWT	Thu hồi token, yêu cầu login lại
Policy không áp dụng đúng (bug)	Trung bình	Unit test pgTAP + CI pipeline	Enable “row_security = off” tạm thời, alert	Rollback DB migration, restore snapshot
Độ trễ DB tăng > 200 ms	Trung bình	Index `region_id` + partitioning	Scale read replica, enable connection pool	Switch sang read‑only replica
Thất bại CI/CD (pipeline crash)	Thấp	Retry logic + cache	Manual deploy via Terraform	Restore previous Docker image
Không đáp ứng audit compliance	Cao	Log all `SET app.region_id` + audit trigger	External SIEM integration	Generate compliance report từ backup logs

8. KPI, công cụ đo và tần suất

KPI	Mục tiêu	Công cụ đo	Tần suất
Latency truy vấn RLS	≤ 120 ms	pg_stat_statements, Grafana	5 phút
Tỷ lệ lỗi 403 (Forbidden)	< 0.1 %	Kong logs, ELK	1 giờ
Số audit log ghi nhận	≥ 99.9 %	PostgreSQL audit trigger, Splunk	15 phút
Thời gian phản hồi API (GET /orders)	≤ 250 ms	New Relic APM	5 phút
Tỷ lệ token hết hạn (refresh)	≤ 5 %	Keycloak metrics	1 giờ
Chi phí hạ tầng (DB + GW)	≤ $1 200/tháng	AWS Cost Explorer	Hàng ngày
Compliance score (GDPR, VNPDPA)	100 %	Internal audit checklist	Hàng tuần

Công thức tính latency trung bình
Latency trung bình = Σ (Thời gian phản hồi mỗi query) / Số query

9. Checklist go‑live (42 item)

9.1 Nhóm Security & Compliance

#	Mục kiểm tra	Trạng thái
1	JWT signed bằng RSA‑256, key rotation 30 ngày	☐
2	Policy `USING (region_id = current_setting('app.region_id')::int)` đã bật	☐
3	Audit trigger ghi `user_id`, `region_id`, `operation`	☐
4	WAF (Cloudflare) bật rule “Block malformed JWT”	☐
5	Kiểm tra GDPR & VNPDPA checklist	☐
6	Secrets được lưu trong AWS Secrets Manager, không hard‑code	☐
7	Đánh giá penetration test (OWASP Top 10)	☐
8	Backup DB hàng ngày, retention 30 ngày	☐
9	Log retention ≥ 90 ngày trong Splunk	☐
10	IAM role least‑privilege cho CI/CD	☐

9.2 Nhóm Performance & Scalability

#	Mục kiểm tra	Trạng thái
11	Index `region_id` trên mọi bảng nhạy cảm	☐
12	Partitioning theo `region_id` (range)	☐
13	Connection pool max 200	☐
14	Read replica latency ≤ 50 ms	☐
15	Load test 10 k QPS, 95th percentile ≤ 200 ms	☐
16	Auto‑scaling policy cho RDS (CPU > 70 % → scale)	☐
17	CDN cache cho static assets	☐
18	API Gateway rate‑limit 500 req/s per token	☐
19	Monitoring alerts cho latency > 200 ms	☐
20	Grafana dashboard “RLS Performance”	☐

9.3 Nhóm Business & Data Accuracy

#	Mục kiểm tra	Trạng thái
21	Kiểm thử dữ liệu mẫu: staff region 1 không thấy order region 2	☐
22	Report “Orders per Region” khớp với DB	☐
23	Data validation script (Python) chạy nightly	☐
24	Sync region mapping từ HR system	☐
25	UI hiển thị region filter đúng	☐
26	Documentation “Data Access Matrix” cập nhật	☐
27	Business stakeholder sign‑off	☐
28	SLA: 99.9 % uptime	☐
29	Backup restore test (point‑in‑time)	☐
30	Change‑log cho policy updates	☐

9.4 Nhóm Payment & Finance

#	Mục kiểm tra	Trạng thái
31	Payment gateway token validation (HMAC)	☐
32	Script đối soát payment (Node.js) chạy hourly	☐
33	Không có order cross‑region trong finance report	☐
34	Reconciliation log lưu trong audit DB	☐
35	PCI‑DSS checklist hoàn thành	☐
36	Refund workflow tuân thủ RLS	☐
37	Alert khi transaction > $10 k không có region_id	☐
38	Test scenario “duplicate payment”	☐
39	Finance team sign‑off	☐
40	Backup finance DB riêng biệt	☐

9.5 Nhóm Monitoring & Rollback

#	Mục kiểm tra	Trạng thái
41	Health check endpoint `/healthz` trả 200	☐
42	Rollback script (Terraform destroy + DB snapshot restore)	☐

10. Tài liệu bàn giao cuối dự án (15 mục)

STT	Tên tài liệu	Người viết	Nội dung chính
1	Data Access Matrix	Business Analyst	Ma trận quyền truy cập (role ↔ region)
2	RLS Policy Specification	Solution Architect	Định nghĩa policy SQL, trigger, audit
3	Architecture Diagram	Cloud Engineer	Diagram toàn cảnh, flow text art
4	Infrastructure as Code (Terraform)	DevOps Engineer	Mã Terraform, modules, variables
5	Docker Compose File	DevOps Engineer	Định nghĩa service PostgreSQL, Keycloak
6	CI/CD Pipeline (GitHub Actions)	DevOps Engineer	Workflow YAML, test, deploy
7	Database Migration Scripts (Flyway)	DBA	Versioned SQL, RLS enable
8	Security Assessment Report	Security Analyst	Pen‑test, WAF config, compliance
9	Performance Test Report	QA Lead	Kết quả load test, bottleneck
10	Monitoring Dashboard Guide	Ops Engineer	Grafana panels, alert rules
11	Disaster Recovery Plan	DBA	Backup schedule, restore steps
12	User Guide – JWT & Region ID	BA	Hướng dẫn login, token payload
13	Audit Log Specification	Security Analyst	Schema, retention, query examples
14	Change Management Log	PM	Các thay đổi policy, version
15	Post‑mortem & Lessons Learned	PM	Tổng kết, cải tiến cho dự án tiếp theo

11. Các đoạn code / config thực tế (≥ 12)

11.1 Docker Compose (PostgreSQL + Keycloak)

# docker-compose.yml
version: "3.8"
services:
  db:
    image: postgres:15
    environment:
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ecommerce
    volumes:
      - pgdata:/var/lib/postgresql/data
    ports:
      - "5432:5432"
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "admin"]
      interval: 10s
      timeout: 5s
      retries: 5

  keycloak:
    image: quay.io/keycloak/keycloak:22.0.1
    command: start-dev --import-realm
    environment:
      KEYCLOAK_ADMIN: admin
      KEYCLOAK_ADMIN_PASSWORD: ${KEYCLOAK_PASSWORD}
      DB_VENDOR: POSTGRES
      DB_ADDR: db
      DB_DATABASE: keycloak
      DB_USER: admin
      DB_PASSWORD: ${POSTGRES_PASSWORD}
    ports:
      - "8080:8080"
    depends_on:
      db:
        condition: service_healthy

volumes:
  pgdata:

11.2 PostgreSQL RLS Policy

-- Enable row level security
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

-- Policy: staff can see only rows of their region
CREATE POLICY region_policy ON orders
    USING (region_id = current_setting('app.region_id')::int);

-- Function to set session variable from JWT claim
CREATE OR REPLACE FUNCTION set_region(p_region int) RETURNS void AS $$
BEGIN
    PERFORM set_config('app.region_id', p_region::text, true);
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

11.3 Prisma Middleware (Node.js)

// prisma/middleware.ts
import { Prisma } from '@prisma/client';
import jwt from 'jsonwebtoken';

export const rlsMiddleware = async (params: Prisma.MiddlewareParams, next: Prisma.Next) => {
  const ctx = params?.model ? params?.args?.where : {};
  // Extract region_id from JWT (passed via request header)
  const token = ctx?.request?.headers?.authorization?.split(' ')[1];
  if (token) {
    const payload: any = jwt.verify(token, process.env.JWT_PUBLIC_KEY);
    await prisma.$executeRaw`SELECT set_region(${payload.region_id})`;
  }
  return next(params);
};

11.4 Kong JWT Plugin (Declarative Config)

# kong.yml
_format_version: "2.1"
services:
- name: ecommerce-api
  url: http://api:3000
  routes:
  - name: api-route
    paths: ["/"]
plugins:
- name: jwt
  config:
    uri_param_names: ["jwt"]
    claims_to_verify: ["exp", "nbf"]
    key_claim_name: "kid"
    secret_is_base64: false
    run_on_preflight: true

11.5 Cloudflare Worker – Header Injection

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const url = new URL(request.url)
  const token = request.headers.get('Authorization')?.split(' ')[1]
  if (!token) return new Response('Unauthorized', { status: 401 })
  // Forward token to upstream
  const upstream = new Request(url, request)
  upstream.headers.set('X-Region-Token', token)
  return fetch(upstream)
}

11.6 Script đối soát payment (Node.js)

// payment-reconcile.js
const { Client } = require('pg');
const pg = new Client({ connectionString: process.env.DATABASE_URL });
(async () => {
  await pg.connect();
  const res = await pg.query(`
    SELECT p.id, p.amount, o.region_id
    FROM payments p
    JOIN orders o ON p.order_id = o.id
    WHERE p.status = 'COMPLETED' AND o.region_id <> p.region_id;
  `);
  if (res.rowCount) {
    console.warn('Found mismatched payments:', res.rows);
    // Notify Slack
  }
  await pg.end();
})();

11.7 GitHub Actions CI/CD Workflow

# .github/workflows/deploy.yml
name: Deploy to Production
on:
  push:
    branches: [main]
jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up Node
        uses: actions/setup-node@v3
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run lint
      - run: npm test
  deploy:
    needs: build-test
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v3
      - name: Terraform Init & Apply
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_KEY }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET }}
        run: |
          terraform init
          terraform apply -auto-approve
      - name: Deploy Docker Compose
        run: |
          ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} "docker compose -f /opt/ecom/docker-compose.yml up -d"

11.8 Terraform – RDS Instance

resource "aws_db_instance" "ecom_rds" {
  identifier        = "ecom-rds"
  engine            = "postgres"
  engine_version    = "15.3"
  instance_class    = "db.t3.medium"
  allocated_storage = 200
  storage_type      = "gp2"
  multi_az          = true
  username          = "admin"
  password          = var.db_password
  db_name           = "ecommerce"
  publicly_accessible = false
  vpc_security_group_ids = [aws_security_group.rds_sg.id]
  tags = {
    Environment = "prod"
  }
}

11.9 Nginx Config – Reverse Proxy with JWT validation

# /etc/nginx/conf.d/ecom.conf
server {
    listen 443 ssl;
    server_name api.ecom.vn;

    ssl_certificate /etc/ssl/certs/ecom.crt;
    ssl_certificate_key /etc/ssl/private/ecom.key;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Authorization $http_authorization;
        proxy_pass http://backend:3000;
    }

    # Simple JWT validation (requires lua-nginx-module)
    access_by_lua_block {
        local jwt = require "resty.jwt"
        local token = ngx.var.http_authorization:match("Bearer%s+(.+)")
        if not token then
            ngx.exit(ngx.HTTP_UNAUTHORIZED)
        end
        local jwt_obj = jwt:verify("HS256", token, ngx.shared.jwt_secret:get())
        if not jwt_obj["verified"] then
            ngx.exit(ngx.HTTP_FORBIDDEN)
        end
        ngx.req.set_header("X-Region-Id", jwt_obj["payload"]["region_id"])
    }
}

11.10 pgTAP Test – RLS Enforcement

-- tests/rls_policy_test.sql
BEGIN;
SELECT plan(2);
SELECT is(
    (SELECT count(*) FROM orders WHERE region_id = 1),
    0,
    'User from region 2 cannot see region 1 orders'
);
SELECT is(
    (SELECT count(*) FROM orders WHERE region_id = 2),
    10,
    'User from region 2 sees own orders'
);
SELECT * FROM finish();
ROLLBACK;

11.11 Helm Chart – Kong Deployment (values.yaml)

# values.yaml
replicaCount: 2
service:
  type: LoadBalancer
  port: 80
env:
  database: "off"
  plugins: "bundled,jwt"
ingressController:
  enabled: true
  installCRDs: true

11.12 Bash Script – Backup & Retention

#!/usr/bin/env bash
# backup.sh - Daily snapshot + retention 30 days
DATE=$(date +%Y%m%d)
aws rds create-db-snapshot \
  --db-instance-identifier ecom-rds \
  --db-snapshot-identifier ecom-snap-$DATE

# Delete snapshots older than 30 days
aws rds describe-db-snapshots --query "DBSnapshots[?SnapshotCreateTime<='$(date -d '-30 days' +%Y-%m-%d)'].DBSnapshotIdentifier" --output text | \
xargs -n1 -I {} aws rds delete-db-snapshot --db-snapshot-identifier {}

12. Gantt chart chi tiết (Phase + Dependency)

[Phase]          [Start]   [Dur (weeks)]   [Dep]
-------------------------------------------------
Requirement      W01       2               -
Design RLS       W03       2               Requirement
CI/CD Setup      W04       3               Design RLS
Deploy Infra     W06       4               CI/CD Setup
Test & Audit     W09       2               Deploy Infra
Go‑Live          W11       2               Test & Audit

13. Các bước triển khai (Chi tiết từng Phase)

Phase 1 – Phân tích yêu cầu

Mục tiêu: Xác định vùng địa lý, vai trò, bảng dữ liệu nhạy cảm.
Công việc: Thu thập danh sách region, mapping staff‑region, phân tích luật bảo mật VNPDPA, tạo “Data Access Matrix”.
Trách nhiệm: Business Analyst (BA).
Thời gian: Tuần 1‑2.
Dependency: –

Phase 2 – Thiết kế RLS policy

Mục tiêu: Định nghĩa policy SQL, hàm set_region, audit trigger.
Công việc: Viết policy, tạo migration script, thiết kế test case, chuẩn bị tài liệu “RLS Policy Specification”.
Trách nhiệm: Solution Architect.
Thời gian: Tuần 3‑4.
Dependency: Phase 1.

Phase 3 – Xây dựng CI/CD

Mục tiêu: Tự động hoá build, test, deploy.
Công việc: Dockerfile, docker‑compose, GitHub Actions workflow, Terraform modules, unit test pgTAP, cấu hình secret manager.
Trách nhiệm: DevOps Engineer.
Thời gian: Tuần 4‑6.
Dependency: Phase 2.

Phase 4 – Triển khai môi trường

Mục tiêu: Đưa hạ tầng lên cloud, cấu hình RLS.
Công việc: Provision RDS, deploy Keycloak, cấu hình Kong JWT, chạy Flyway migrations, load seed data, kiểm tra connectivity.
Trách nhiệm: Cloud Engineer.
Thời gian: Tuần 6‑9.
Dependency: Phase 3.

Phase 5 – Kiểm thử & audit

Mục tiêu: Đảm bảo policy hoạt động, đáp ứng compliance.
Công việc: Test case functional, penetration test, load test 10 k QPS, audit log verification, sign‑off legal.
Trách nhiệm: QA Lead & Security Analyst.
Thời gian: Tuần 9‑10.
Dependency: Phase 4.

Phase 6 – Go‑live & chuyển giao

Mục tiêu: Đưa vào production, bàn giao tài liệu.
Công việc: Blue‑green deployment, DNS switch, monitor KPI, training ops, bàn giao 15 tài liệu, post‑mortem.
Trách nhiệm: Project Manager.
Thời gian: Tuần 11‑12.
Dependency: Phase 5.

14. Kết luận – Key Takeaways

Row‑Level Security là cách tối ưu để thực thi “who can see what” ở mức dữ liệu, giảm rủi ro rò rỉ nội bộ.
PostgreSQL + Prisma cung cấp RLS native, dễ tích hợp vào pipeline CI/CD hiện có.
Chi phí triển khai 30 tháng chỉ khoảng 3.36 tỷ VNĐ, trong khi lợi ích bảo mật và tuân thủ pháp luật là không thể định lượng.
Workflow cần có JWT chứa region_id, API Gateway truyền token, DB áp dụng policy qua SET SESSION.
Kiểm thử toàn diện (unit, load, penetration) và audit log là yếu tố bắt buộc để đạt compliance (GDPR, VNPDPA).
Checklist go‑live và tài liệu bàn giao giúp giảm thời gian chuyển giao và tăng độ tin cậy cho các team vận hành.

⚡ Thực hiện ngay: Clone repo mẫu, chạy docker compose up -d, tạo policy bằng script psql -f rls_policy.sql, và kiểm tra bằng pgTAP. Nếu mọi test pass, bạn đã có môi trường RLS hoạt động.

15. Câu hỏi thảo luận

Bạn đã từng gặp lỗi “policy not applied” khi sử dụng RLS chưa? Bạn giải quyết bằng cách nào để debug?

16. Đoạn chốt marketing

Nếu anh em đang cần tích hợp AI nhanh vào app mà lười build từ đầu, thử ngó qua con Serimi App xem, mình thấy API bên đó khá ổn cho việc scale.

Anh em nào làm Content hay SEO mà muốn tự động hóa quy trình thì tham khảo bộ công cụ noidungso.io.vn nhé, đỡ tốn công thuê nhân sự part‑time.

Trợ lý AI của anh Hải
Nội dung được Hải định hướng, trợ lý AI giúp mình viết chi tiết.