Bảo mật, Tuân thủ & Kiểm toán (Security, Compliance & Audit)

Tại sao bảo mật trong Core Banking khác với mọi hệ thống khác?

Trong một ứng dụng thông thường, lỗ hổng bảo mật có thể dẫn đến rò rỉ dữ liệu. Trong Core Banking, lỗ hổng bảo mật dẫn đến mất tiền trực tiếp — tiền của hàng triệu khách hàng. Đây là lý do tại sao ngành ngân hàng có các tiêu chuẩn bảo mật khắt khe nhất thế giới.

PCI-DSS — Chuẩn Bảo mật Dữ liệu Thẻ

PCI-DSS (Payment Card Industry Data Security Standard) là bộ tiêu chuẩn bắt buộc cho mọi tổ chức lưu trữ, xử lý hoặc truyền dữ liệu thẻ thanh toán (Visa, Mastercard, JCB…). Vi phạm PCI-DSS có thể dẫn đến phạt tiền hàng triệu USD và bị cấm xử lý thanh toán thẻ.

12 Yêu cầu cốt lõi của PCI-DSS v4.0

Xử lý dữ liệu thẻ đúng cách

Dữ liệu thẻ được phân loại:

╔══════════════════════════════════════════════════════════╗
║  KHÔNG BAO GIỜ ĐƯỢC LƯU TRỮ                             ║
║  • CVV/CVV2/CVC (mã 3-4 số sau thẻ)                     ║
║  • PIN block                                              ║
║  • Track 1/Track 2 data (dải từ trên thẻ vật lý)        ║
╠══════════════════════════════════════════════════════════╣
║  ĐƯỢC LƯU nhưng PHẢI MÃ HÓA                             ║
║  • PAN (Primary Account Number = số thẻ 16 số)          ║
║    → Tokenization hoặc AES-256 encryption                ║
║  • Ngày hết hạn                                           ║
║  • Tên chủ thẻ                                            ║
╚══════════════════════════════════════════════════════════╝

Tokenization — Kỹ thuật thay thế số thẻ

Thay vì lưu số thẻ thật, hệ thống tạo ra một token vô nghĩa. Token này không thể dùng để thực hiện giao dịch trực tiếp nếu bị đánh cắp.

Số thẻ thật:  4111 1111 1111 1111
Token:        8293 4721 9834 5612  (random, không có nghĩa toán học)

Mapping (trong HSM hoặc Token Vault):
  8293 4721 9834 5612 → 4111 1111 1111 1111

AML & CFT — Chống Rửa Tiền và Tài trợ Khủng bố

AML (Anti-Money Laundering) và CFT (Countering Financing of Terrorism) là nghĩa vụ pháp lý của mọi ngân hàng. Developer Core Banking phải xây dựng các cơ chế phát hiện tự động.

Các kỹ thuật phát hiện

1. Transaction Monitoring Rules (Rule-based):

Quy tắc ví dụ:
- Giao dịch tiền mặt > 300 triệu VNĐ → Báo cáo STR (Suspicious Transaction)
- Cùng một tài khoản nhận > 10 giao dịch < 300 triệu trong 24h (Structuring)
- Chuyển tiền đến quốc gia nằm trong danh sách FATF High-Risk

2. Customer Risk Scoring:

type CustomerRiskScore struct {
    CIFNumber     string
    Score         int     // 0-100
    RiskLevel     string  // "LOW", "MEDIUM", "HIGH"
    Factors       []string
    // ["PEP", "HIGH_RISK_COUNTRY", "CASH_INTENSIVE_BUSINESS"]
    LastUpdated   time.Time
}

3. Sanctions Screening: Kiểm tra mọi giao dịch và khách hàng so với danh sách trừng phạt quốc tế:

• OFAC (US Treasury)
• UN Security Council
• EU Consolidated List
• Danh sách NHNN Việt Nam

Thiết kế Hệ thống Kiểm toán (Audit Trail)

Mọi thao tác trong Core Banking phải có dấu vết kiểm toán không thể xóa hoặc sửa. Đây là yêu cầu pháp lý bắt buộc.

Bảng Audit Log

CREATE TABLE audit_logs (
    id              UUID        PRIMARY KEY DEFAULT gen_random_uuid(),
    entity_type     VARCHAR(50) NOT NULL,   -- 'ACCOUNT', 'CUSTOMER', 'TRANSACTION'
    entity_id       VARCHAR(50) NOT NULL,   -- ID của đối tượng bị thay đổi
    action          VARCHAR(50) NOT NULL,   -- 'CREATE', 'UPDATE', 'DELETE', 'VIEW'
    actor_id        VARCHAR(50) NOT NULL,   -- ID của user/system thực hiện
    actor_type      VARCHAR(20) NOT NULL,   -- 'STAFF', 'CUSTOMER', 'SYSTEM', 'API'
    ip_address      INET,
    before_state    JSONB,                  -- Trạng thái trước khi thay đổi
    after_state     JSONB,                  -- Trạng thái sau khi thay đổi
    created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    
    -- Không có cột updated_at — audit log là immutable
    -- Không bao giờ UPDATE hay DELETE bảng này
);

-- Immutable bằng PostgreSQL Row Security
ALTER TABLE audit_logs ENABLE ROW LEVEL SECURITY;
CREATE POLICY audit_insert_only ON audit_logs FOR INSERT WITH CHECK (true);
-- Chỉ INSERT, không SELECT nếu không có quyền, không UPDATE/DELETE

Append-Only Pattern cho Ledger

-- Thêm trigger ngăn UPDATE/DELETE vào ledger
CREATE OR REPLACE FUNCTION prevent_ledger_modification()
RETURNS TRIGGER AS $$
BEGIN
    RAISE EXCEPTION 'Ledger entries are immutable. Use reversal entries to correct errors.';
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER ledger_immutability_guard
    BEFORE UPDATE OR DELETE ON ledger_entries
    FOR EACH ROW EXECUTE FUNCTION prevent_ledger_modification();

Mã hóa Dữ liệu Nhạy cảm

Phân loại dữ liệu theo mức độ nhạy cảm

HSM — Hardware Security Module

HSM là thiết bị phần cứng chuyên dụng để thực hiện các thao tác mã hóa nhạy cảm nhất (mã hóa PIN, tạo key thẻ, ký số). Khóa mã hóa không bao giờ rời khỏi HSM dưới dạng plaintext.

Luồng xử lý PIN (khi rút tiền ATM):
1. Máy ATM: PIN → mã hóa bằng PIN Encryption Key (PEK) → gửi PIN Block
2. Core Banking → gửi PIN Block đến HSM
3. HSM: giải mã PIN Block → verify PIN → trả về kết quả "VALID"/"INVALID"
4. PIN plaintext KHÔNG BAO GIỜ xuất hiện trong application code

Data Residency & Privacy (Theo quy định Việt Nam)

• Thông tư 09/2020/TT-NHNN: Dữ liệu khách hàng cá nhân phải được lưu trữ trong lãnh thổ Việt Nam.
• Luật An ninh mạng 2018: Dữ liệu quan trọng phải lưu trữ tại Việt Nam.
• Nghị định 13/2023/NĐ-CP: Bảo vệ dữ liệu cá nhân, yêu cầu đồng ý (consent) và quyền xóa dữ liệu.

Thiết kế hệ thống phải có khả năng xác định rõ dữ liệu nào của khách hàng nào đang ở đâu, và thực thi yêu cầu xóa/ẩn danh hóa (anonymization) khi có yêu cầu.

Đây là phần cuối cùng về lý thuyết. Giờ đã đến lúc áp dụng tất cả những gì đã học. Đọc tiếp Phần 7 — Thực hành: Xây dựng Mini Core Banking từ đầu để bắt tay vào code thực sự.