Website được thiết kế tối ưu cho thành viên chính thức. Hãy Đăng nhập hoặc Đăng ký để truy cập đầy đủ nội dung và chức năng. Nội dung bạn cần không thấy trên website, có thể do bạn chưa đăng nhập. Nếu là thành viên của website, bạn cũng có thể yêu cầu trong nhóm Zalo "CNTT" các nội dung bạn quan tâm.

Bài 35. Mã hóa và quản lý khóa (Key Management)

ICT

1. Vì sao mã hóa backup là bắt buộc, không phải tùy chọn?

Một thực tế đáng lo ngại:

  • Nhiều hệ thống backup đầy đủ

  • Nhưng dữ liệu backup để plain text

  • Ai có file backup là có toàn bộ dữ liệu

Trong bối cảnh:

  • Ransomware

  • Lộ dữ liệu

  • Tuân thủ pháp lý (GDPR, dữ liệu cá nhân, y tế)

Backup không mã hóa nguy hiểm hơn không backup.

📌 Backup thường chứa toàn bộ hệ thống ở dạng cô đọng nhất.


2. Mã hóa trong backup bảo vệ điều gì?

Mã hóa bảo vệ backup khi:

  • Backup bị đánh cắp

  • Storage bị lộ

  • Cloud account bị xâm nhập

  • Nhân sự nội bộ truy cập trái phép

📌 Mã hóa là tuyến phòng thủ cuối cùng.


3. Hai lớp mã hóa trong backup

3.1. Mã hóa khi truyền (Encryption in transit)

Bảo vệ dữ liệu:

  • Trên mạng nội bộ

  • Khi đẩy off-site

  • Khi upload cloud

Cơ chế phổ biến:

  • SSH

  • TLS

  • VPN

📌 Không bao giờ truyền backup ở dạng plain text.


3.2. Mã hóa khi lưu trữ (Encryption at rest)

Bảo vệ dữ liệu:

  • Trên NAS

  • Trên server backup

  • Trên cloud / object storage

Cơ chế:

  • Tool backup mã hóa sẵn (Borg, Restic)

  • GPG / AES

  • Encryption của storage (bổ trợ, không thay thế)


4. Mã hóa ở đâu là đúng?

Một nguyên tắc rất quan trọng:

Mã hóa càng gần nguồn tạo dữ liệu càng tốt.

Khuyến nghị:

  • Mã hóa trước khi rời khỏi server nguồn

  • Không phụ thuộc hoàn toàn vào encryption của cloud

📌 Client-side encryption luôn an toàn hơn server-side encryption.


5. Key Management – vấn đề khó hơn mã hóa

Mã hóa thì dễ, giữ khóa mới khó.

Các rủi ro thực tế:

  • Lưu key cùng backup

  • Chỉ một người giữ key

  • Mất key khi nhân sự nghỉ việc

  • Không ai biết key ở đâu

📌 Mất key = mất backup vĩnh viễn.


6. Nguyên tắc quản lý khóa (Key Management)

6.1. Tách biệt key và dữ liệu

  • Key không bao giờ lưu chung nơi với backup

  • Không commit key vào Git

  • Không để key trong script public


6.2. Phân quyền truy cập key

  • Không phải ai backup cũng có quyền restore

  • Key restore phải kiểm soát chặt

📌 Tách vai trò backuprestore.


6.3. Có bản sao key an toàn

  • Backup key offline

  • Lưu trong két, vault, HSM (nếu có)

  • Có quy trình truy cập khi khẩn cấp

📌 Backup mà không backup key là sai lầm chí mạng.


7. Password-based vs Key-based encryption

7.1. Password-based

  • Dễ triển khai

  • Phụ thuộc con người

Rủi ro:

  • Quên

  • Yếu

  • Truyền miệng


7.2. Key-based

  • An toàn hơn

  • Phù hợp hệ thống lớn

Yêu cầu:

  • Quản lý vòng đời key

  • Rotation định kỳ

📌 Hệ thống chuyên nghiệp nên ưu tiên key-based.


8. Quản lý khóa trong các công cụ backup phổ biến

8.1. BorgBackup

  • Repository key

  • Có keyfile / passphrase

  • Phải backup key riêng


8.2. Restic

  • Password-based

  • Không có password = không truy cập được repo

📌 Restic không thể phục hồi nếu mất password.


9. Key rotation và vòng đời khóa

Cần xác định:

  • Key dùng bao lâu

  • Khi nào đổi key

  • Backup cũ xử lý thế nào

📌 Không đổi key mãi mãi, nhưng đổi cũng phải có kế hoạch.


10. Mã hóa và tuân thủ (Compliance)

Trong nhiều lĩnh vực:

  • Y tế

  • Tài chính

  • Dịch vụ công

Mã hóa backup là:

  • Yêu cầu bắt buộc

  • Điều kiện audit

  • Trách nhiệm pháp lý

📌 “Có backup” nhưng không mã hóa có thể vẫn vi phạm quy định.


11. Sai lầm phổ biến

  • Tin vào encryption của cloud

  • Lưu key cùng backup

  • Không backup key

  • Không test restore với key


12. Checklist mã hóa và quản lý khóa

BẮT BUỘC

  • Mã hóa at-rest

  • Mã hóa in-transit

  • Tách key và dữ liệu

RẤT NÊN

  • Backup key offline

  • Phân quyền truy cập key

  • Test restore định kỳ


 

Backup không có mã hóa là rủi ro.
Mã hóa không có quản lý khóa là thảm họa.

Một hệ thống backup trưởng thành:

  • Mã hóa đúng chỗ

  • Quản lý khóa nghiêm túc

  • Có thể restore khi cần, nhưng không ai đọc được khi không được phép