Posted inDatabase

Mã hóa Dữ liệu PostgreSQL: Bảo vệ Thông tin Nhạy cảm với pgcrypto và Mã hóa Cấp Cột

Database tutorial - IT technology blog
Database tutorial - IT technology blog

Lúc 2:47 sáng, tôi nhận được tin nhắn trên Slack. Một security group cấu hình sai đã khiến máy chủ PostgreSQL bị lộ ra ngoài internet trong khoảng bốn tiếng. Máy chủ đó chứa bảng users với email, số điện thoại và số định danh chính phủ được lưu dưới dạng văn bản thường. Không có bằng chứng về việc bị tấn công — nhưng điều đó không quan trọng. Dữ liệu vẫn ở đó, không được bảo vệ, và nếu ai đó đã lấy backup trong khoảng thời gian đó, họ chỉ cần một lệnh pg_restore là đọc được tất cả.

Sự cố đó đã thay đổi cách tôi tiếp cận bảo mật cơ sở dữ liệu. Tôi đã làm việc với MySQL, PostgreSQL và MongoDB trong nhiều dự án khác nhau — mỗi hệ thống có cách tiếp cận riêng để bảo vệ dữ liệu lưu trữ. PostgreSQL cung cấp cho bạn bộ tùy chọn chi tiết nhất. Vấn đề là chọn đúng phương pháp phù hợp với mô hình mối đe dọa của bạn, chứ không phải chỉ bật tùy chọn nào đó trên console cloud.

Bốn Phương pháp Mã hóa

Trước khi viết bất kỳ SQL nào, bạn cần hiểu mình đang thực sự bảo vệ khỏi điều gì. Mỗi lớp mã hóa bảo vệ trước một vector tấn công khác nhau.

1. Full-Disk Encryption (FDE)

LUKS trên Linux, BitLocker trên Windows. Toàn bộ phân vùng đĩa được mã hóa ở cấp block device. PostgreSQL và hệ điều hành không nhìn thấy gì — kernel xử lý giải mã minh bạch sau khi khởi động. Nhà cung cấp cloud của bạn có thể đã bật tính năng này theo mặc định: AWS RDS sử dụng AES-256 ở lớp lưu trữ nếu bạn chọn tùy chọn đó. Google Cloud SQL và Azure Database for PostgreSQL cũng tương tự.

2. Mã hóa Cấp Filesystem

Các công cụ như eCryptfs hoặc fscrypt mã hóa ở lớp filesystem thay vì block device. Bạn trỏ chúng vào thư mục dữ liệu của PostgreSQL (/var/lib/postgresql/) cụ thể. Chi tiết hơn FDE một chút, nhưng về mặt vận hành thì tương tự.

3. Transparent Data Encryption (TDE)

Các bản phân phối PostgreSQL enterprise — EDB Postgres Advanced Server, Percona Distribution for PostgreSQL — cung cấp TDE. Nó mã hóa các file dữ liệu và WAL ở cấp cluster mà không cần thay đổi SQL của bạn. Community PostgreSQL không đi kèm TDE nguyên bản tính đến phiên bản 16, mặc dù có các bản vá. Đây là tính năng của bản phân phối trả phí.

4. Mã hóa Cấp Cột với pgcrypto

Đây là lớp thực sự quan trọng khi ai đó có thông tin xác thực cơ sở dữ liệu. pgcrypto là một extension của PostgreSQL cung cấp các hàm mật mã trực tiếp trong SQL. Bạn mã hóa các cột cụ thể chứa dữ liệu nhạy cảm. Cơ sở dữ liệu lưu trữ bản mã; chỉ có ứng dụng giữ khóa mới đọc được giá trị gốc.

Ưu điểm, Nhược điểm và Đánh đổi Thực tế

Full-Disk Encryption
Bảo vệ khỏi việc đánh cắp đĩa vật lý và snapshot cloud bị lấy trộm. Không cần thay đổi code, dễ dàng bật trên các dịch vụ managed. Nhưng nó hoàn toàn vô dụng nếu ai đó có quyền truy cập cấp cơ sở dữ liệu — một session hợp lệ đọc dữ liệu thường như bình thường. Nếu thông tin xác thực PostgreSQL của bạn bị rò rỉ, FDE không có tác dụng gì. Nó bảo vệ trước trường hợp “ai đó lấy trộm ổ cứng từ trung tâm dữ liệu”, không phải “ai đó lấy được mật khẩu cơ sở dữ liệu”.

Filesystem Encryption
Hạn chế tương tự FDE khi cơ sở dữ liệu đang chạy. Tạo thêm overhead I/O đáng kể trên các workload cao. Phạm vi bảo vệ hẹp: backup offline và đĩa bị đánh cắp. Không đáng với độ phức tạp cho hầu hết các nhóm khi FDE đã có sẵn.

TDE
Minh bạch, không cần thay đổi ứng dụng, bảo vệ file dữ liệu và WAL backup khi lưu trữ. Nhược điểm: yêu cầu bản phân phối trả phí hoặc bản build tùy chỉnh có vá. Tăng độ phức tạp quản lý khóa ở cấp máy chủ. Không thực tế cho các nhóm chạy community PostgreSQL với ngân sách hạn chế.

Mã hóa Cấp Cột (pgcrypto)
Đây là phương pháp thực sự ngăn chặn tình huống lúc 2 giờ sáng. Một DBA có quyền truy cập toàn bộ bảng chỉ thấy bản mã cho các cột được mã hóa. Backup pg_dump bị đánh cắp vô dụng nếu không có khóa ứng dụng. Bạn chỉ mã hóa các trường quan trọng — không phải toàn bộ bảng — nên tác động đến hiệu năng được giới hạn. Chi phí: thay đổi ứng dụng, không có index B-tree tiêu chuẩn trên các cột được mã hóa, và quản lý khóa hoàn toàn là trách nhiệm của bạn.

Thiết lập Được Khuyến nghị

Đối với ứng dụng production xử lý PII — số an sinh xã hội, CMND/CCCD, số tài khoản tài chính, hồ sơ y tế — câu trả lời không phải là chọn một phương pháp. Mà là kết hợp nhiều lớp:

  • Bật FDE hoặc mã hóa cấp lưu trữ ở lớp hạ tầng. Trên các dịch vụ managed, đây là một checkbox khi tạo cluster — không tốn gì và nên luôn bật.
  • Dùng mã hóa cấp cột cho các trường cụ thể có trách nhiệm pháp lý nếu bị lộ.
  • Lưu trữ khóa mã hóa ứng dụng hoàn toàn tách biệt khỏi cơ sở dữ liệu — không bao giờ trong cùng instance PostgreSQL.

Hầu hết các nhóm bỏ qua mã hóa cấp cột. Đó là điều họ hối tiếc. Đây là cách triển khai.

Hướng dẫn Triển khai: Mã hóa Cấp Cột với pgcrypto

Bước 1: Kích hoạt Extension

-- Chạy với quyền superuser
CREATE EXTENSION IF NOT EXISTS pgcrypto;

-- Xác nhận cài đặt
SELECT name, default_version FROM pg_available_extensions WHERE name = 'pgcrypto';

Bước 2: Thiết kế Schema

Các cột được mã hóa phải dùng kiểu bytea, không phải TEXT. Bản mã là dữ liệu nhị phân, và lưu trữ nó dưới dạng text sẽ gây ra vấn đề mã hóa ký tự.

CREATE TABLE users (
    id          SERIAL PRIMARY KEY,
    email       TEXT NOT NULL UNIQUE,  -- có thể tìm kiếm, không nhạy cảm
    full_name   TEXT,
    ssn_enc     BYTEA,                  -- Số An sinh Xã hội (đã mã hóa)
    tax_id_enc  BYTEA,                  -- Mã số Thuế (đã mã hóa)
    created_at  TIMESTAMPTZ DEFAULT NOW()
);

Bước 3: Mã hóa Dữ liệu khi Thêm

Dùng pgp_sym_encrypt() cho mã hóa đối xứng. Khóa đến từ cấu hình ứng dụng của bạn — không bao giờ hardcode trong file SQL hoặc script migration.

-- Truyền khóa mã hóa qua tham số cấp session
SET app.encryption_key = 'your-32-byte-random-key-here';

-- Thêm bản ghi với SSN đã mã hóa
INSERT INTO users (email, full_name, ssn_enc)
VALUES (
    '[email protected]',
    'Alice Johnson',
    pgp_sym_encrypt('123-45-6789', current_setting('app.encryption_key'))
);

Bước 4: Đọc Dữ liệu Đã Mã hóa

-- Giải mã trong SELECT — chỉ hoạt động với khóa đúng
SELECT
    email,
    full_name,
    pgp_sym_decrypt(ssn_enc, current_setting('app.encryption_key')) AS ssn
FROM users
WHERE id = 1;

-- Cố giải mã với khóa sai sẽ báo lỗi (không thất bại âm thầm)
SELECT pgp_sym_decrypt(ssn_enc, 'wrong-key') FROM users WHERE id = 1;
-- LỖI:  Sai khóa hoặc dữ liệu bị hỏng

Bước 5: Tích hợp Ứng dụng Python

import psycopg2
import os

ENCRYPTION_KEY = os.environ.get('DB_ENCRYPTION_KEY')  # Lấy từ biến môi trường hoặc vault

conn = psycopg2.connect(os.environ['DATABASE_URL'])
cur = conn.cursor()

# Đặt khóa cho session này trước khi thực hiện các thao tác mã hóa
cur.execute("SET app.encryption_key = %s", (ENCRYPTION_KEY,))

# Chèn dữ liệu đã mã hóa
cur.execute("""
    INSERT INTO users (email, full_name, ssn_enc)
    VALUES (%s, %s, pgp_sym_encrypt(%s, current_setting('app.encryption_key')))
""", ('[email protected]', 'Bob Smith', '987-65-4321'))

# Đọc dữ liệu đã giải mã
cur.execute("""
    SELECT email, pgp_sym_decrypt(ssn_enc, current_setting('app.encryption_key'))
    FROM users WHERE email = %s
""", ('[email protected]',))

row = cur.fetchone()
print(f"Email: {row[0]}, SSN: {row[1]}")

conn.commit()
cur.close()
conn.close()

Bước 6: Tạo Khóa Mã hóa Mạnh

Mã hóa pgcrypto chỉ mạnh bằng khóa của nó. Để tạo khóa tương thích AES 256-bit:

# Tạo khóa 32-byte ngẫu nhiên an toàn về mặt mật mã
openssl rand -base64 32
# Ví dụ output: tG8k2mP9xLqR4nY7vW1sA3bH6jE0cF5d=

# Hoặc dùng Python
python3 -c "import secrets; print(secrets.token_urlsafe(32))"

Khi làm việc với khóa mã hóa trên máy cục bộ trong quá trình thiết lập, tôi dùng Hash Generator tại toolcraft.app để nhanh chóng xác minh checksum SHA-256 của các file khóa và export cấu hình. Lý do tôi chọn nó cụ thể: nó chạy hoàn toàn phía client trong trình duyệt — dữ liệu khóa không bao giờ chạm đến máy chủ từ xa. Chi tiết này quan trọng khi bạn đang xử lý bí mật mật mã trong một buổi thiết lập muộn.

Bước 7: Xác nhận Thiết lập Toàn bộ

-- Xác nhận cột lưu trữ bản mã, không phải văn bản có thể đọc được
SELECT ssn_enc FROM users WHERE email = '[email protected]';
-- Trả về dữ liệu nhị phân: \xcb6a3d9f2b...

-- Xác nhận khóa đúng giải mã thành công
SELECT pgp_sym_decrypt(ssn_enc, current_setting('app.encryption_key'))
FROM users WHERE email = '[email protected]';
-- Trả về: 123-45-6789

Quản lý Khóa: Nơi Hầu hết Các Nhóm Mắc Sai lầm

SQL ở trên hoạt động tốt. Quản lý khóa là nơi các hệ thống production thất bại âm thầm.

  • Không bao giờ lưu khóa mã hóa trong chính PostgreSQL. Nếu nó nằm trong bảng, stored procedure, hoặc tham số postgresql.conf được đưa vào backup, bạn đã mã hóa dữ liệu nhưng lại để chìa khóa trong cùng chiếc hộp.
  • Dùng secrets manager. AWS Secrets Manager, HashiCorp Vault, hoặc GCP Secret Manager. Ngay cả một file .env được cấu trúc đúng cách và loại trừ khỏi git còn tốt hơn hardcode.
  • Xoay vòng khóa theo lịch. Xây dựng script mã hóa lại, giải mã các hàng bằng khóa cũ và mã hóa lại bằng khóa mới. Đây là overhead vận hành, nhưng PCI-DSS và HIPAA đều yêu cầu quy trình xoay vòng khóa.
  • Dùng khóa riêng biệt cho mỗi phân loại dữ liệu. Khóa khác nhau cho SSN so với số tài khoản tài chính. Một khóa bị xâm phạm không lộ ra tất cả.

Để tạo khóa và mật khẩu ban đầu mạnh trong quá trình thiết lập, công cụ tạo mật khẩu của toolcraft.app cho phép bạn tạo chuỗi ngẫu nhiên về mặt mật mã với bất kỳ độ dài nào và toàn quyền kiểm soát bộ ký tự. Nguyên tắc tương tự — chỉ phía client, nên không có gì bạn tạo ra được ghi lại ở bất kỳ đâu.

Cân nhắc về Hiệu năng

Mã hóa cấp cột có chi phí thực sự đáng biết trước:

  • Không có index B-tree trên các cột được mã hóa. Bạn không thể thực hiện WHERE ssn_enc = pgp_sym_encrypt('123-45-6789', key) một cách hiệu quả. Cách giải quyết là lưu HMAC của giá trị trong một cột có index riêng biệt để tra cứu khớp chính xác.
  • Overhead CPU khi mã hóa/giải mã — AES-NI xử lý các thao tác riêng lẻ trong microsecond, nhưng giải mã hàng chục nghìn hàng trong quá trình quét toàn bảng tạo thêm độ trễ đo được. Tránh chạy các truy vấn phân tích dạng bulk trên các cột được mã hóa nếu có thể.
  • Tăng dung lượng lưu trữ — định dạng OpenPGP của pgcrypto thêm khoảng 50-100 byte header và salt overhead cho mỗi giá trị, cộng với padding khối AES làm tròn đến ranh giới 16 byte. Một SSN 11 ký tự được mã hóa thành khoảng 110-130 byte trên đĩa.

Đối với hầu hết các ứng dụng bảo vệ một vài trường nhạy cảm, phép tính rất đơn giản. Mã hóa năm cột sẽ kết thúc công ty của bạn nếu bị rò rỉ. Để phần còn lại là các cột index bình thường.

Bài Học Lúc 2 Giờ Sáng

Quay lại sự cố đó. Máy chủ đã có FDE được bật — không quan trọng, vì kẻ tấn công giả định có thông tin xác thực cơ sở dữ liệu, không phải quyền truy cập đĩa vật lý. Mã hóa cấp cột trên các cột số định danh chính phủ sẽ có nghĩa là tình huống tệ nhất chỉ là lộ bản mã, không phải văn bản thường. Một vi phạm tiềm năng trở thành báo cáo sự cố có thể bào chữa được thay vì một hồ sơ pháp lý.

Bắt đầu với ba cột: trường lưu trữ định danh nhạy cảm nhất, trường lưu dữ liệu tài chính, và trường mà đội tuân thủ của bạn sẽ gọi dậy lúc 2 giờ sáng vì. Bật pgcrypto, chuyển những cột đó sang bytea, cập nhật lớp ứng dụng để mã hóa khi ghi và giải mã khi đọc. Đó là công việc của một cuối tuần để có sự bảo vệ mà FDE đơn thuần không bao giờ có thể cung cấp.

Share:
Tags: