Mã hóa Toàn bộ Ổ đĩa trên VPS

Mã hóa toàn bộ ổ đĩa chỉ trả lời đúng một câu hỏi: đối thủ có được gì khi họ đang giữ ổ lưu trữ của bạn và máy đã tắt? Mọi câu hỏi khác bạn có thể có — nhà cung cấp nhìn thấy gì, điều gì xảy ra nếu một server đang chạy bị tịch thu, liệu bản sao lưu của bạn có an toàn không — đều có câu trả lời khác, và việc gộp tất cả thành một là cách người ta kết thúc với một lớp mã hóa chẳng bảo vệ được gì.

Sự phân biệt đó đáng để nói thẳng, bởi vì cụm "được mã hóa bằng LUKS" xuất hiện trên mọi trang hosting-vì-quyền-riêng-tư trong ngành này, kể cả trang của chúng tôi. Đó là một biện pháp kiểm soát thật, gần như không tốn gì để vận hành, và cũng là biện pháp kiểm soát bị thổi phồng nhất trong hosting. Hướng dẫn này trình bày những gì mã hóa dữ liệu lưu trữ thực sự ngăn chặn được trên một server đi thuê, ba cách bố trí đáng triển khai cùng các lệnh cho từng cách, hai cài đặt thực sự quan trọng trên một VPS nhỏ, và một loạt sai lầm biến toàn bộ nỗ lực đó thành vật trang trí.

Mã hóa dữ liệu lưu trữ thực sự bảo vệ chống lại điều gì

Mã hóa dữ liệu lưu trữ nghĩa là các byte trên thiết bị lưu trữ là ciphertext bất cứ khi nào volume đang đóng. Đó là một tuyên bố hẹp, và giá trị của nó phụ thuộc vào đúng một biến số: khóa đang ở đâu vào thời điểm đối thủ xuất hiện.

Hãy đọc điều đó như một định nghĩa, không phải một sự thất vọng. Loại bỏ nhóm rủi ro "ổ đĩa bị rút ra" đáng giá một giờ công sức chính vì đó là nhóm rủi ro bạn không có biện pháp phòng vệ nào khác, và cũng là nhóm xảy ra mà không cần ai nhắm vào bạn: phần cứng hỏng và bị trả lại, mảng ổ đĩa bị ngừng sử dụng, volume được cấp lại cho khách thuê kế tiếp. Mã hóa biến tất cả những điều đó thành chuyện không đáng bận tâm.

Vì sao VPS không phải là laptop

Trên laptop, thiết kế là điều hiển nhiên. Bạn gõ passphrase lúc khởi động, khóa chỉ tồn tại trong RAM trong khi máy đang thức, và tắt máy là kết thúc câu chuyện. Một server không có ai ngồi trước console. Một thứ gì đó phải cung cấp khóa ở mỗi lần khởi động, và mỗi ứng viên cho "thứ gì đó" ấy đều đánh đổi giữa tính sẵn sàng và mức bảo vệ:

• Một con người gõ khóa vào. Cách bố trí mạnh nhất, vì khóa không bao giờ nằm nghỉ trên máy — nhưng server không thể tự khởi động lại mà không có bạn, và bạn cần một lối vào trước khi hệ điều hành tồn tại.
• Máy tự giữ khóa. Tiện lợi, và trong hầu hết các cấu hình tự chế thì lại tự phá hỏng mục đích của chính nó: một tệp khóa nằm trên cùng ổ đĩa ảo nghĩa là ai giữ ổ đĩa thì giữ luôn khóa.
• Một máy khác trao khóa cho nó. Mở khóa ràng buộc theo mạng, thường là Clevis với một server Tang. Server chỉ tự mở khóa khi nó vẫn còn kết nối được tới một host bạn kiểm soát — đây là một đặc tính thực sự hữu ích, và là sự dịch chuyển của niềm tin chứ không phải loại bỏ nó.

Có một khác biệt thứ hai mà hầu hết các hướng dẫn bỏ qua. Trên VPS, /boot và initramfs là plaintext, chúng nằm trên ổ lưu trữ mà nhà cung cấp cuối cùng vẫn kiểm soát, và không có chuỗi khởi động (boot chain) nào bạn có thể xác minh — không có TPM thuộc về bạn, không có measured boot, không có gì để chứng thực (attest). Một nhà cung cấp muốn lấy passphrase của bạn có thể sửa đổi initramfs và thu thập nó vào lần mở khóa tiếp theo của bạn. Đó không phải là mô tả về bất cứ điều gì chúng tôi làm; đó là mô tả về những gì kiến trúc này cho phép, và đó là cách duy nhất trung thực để suy luận về một chiếc máy tính bạn đi thuê. So sánh VPS và dedicated của chúng tôi đi qua cùng ranh giới niềm tin đó từ phía phần cứng, và câu trả lời trung thực của chúng tôi về tính ẩn danh của offshore hosting áp dụng cùng kỷ luật đó cho mảng tiếp thị xung quanh nó.

Ba cách bố trí đáng triển khai

Không có một cấu hình đúng duy nhất — chỉ có cấu hình mà bạn chấp nhận sống chung với kiểu thất bại của nó. Ba cách sau đây bao quát gần như mọi trường hợp thực tế.

Hãy bắt đầu với cách thứ nhất trừ khi bạn có lý do cụ thể để không làm vậy. Nó mang lại phần lớn sự bảo vệ với chỉ một phần nhỏ rủi ro vận hành, và nó có đặc tính mà hai cách kia không có: không gì trong đó có thể ngăn server quay lại trực tuyến. Cách bố trí thứ ba là cách duy nhất mà passphrase là một sự thật nhà cung cấp không thể chạm tới, chứ không phải một lời hứa mà nhà cung cấp đưa ra — đó là lý do các máy chủ dedicated của chúng tôi thiết lập LUKS ngay khi cài đặt với một passphrase mà chúng tôi không bao giờ nhìn thấy.

Mã hóa một volume dữ liệu trên VPS đang chạy

Đây là cách bố trí nên dùng đầu tiên. Không có gì bị cài lại, không có gì trong quy trình khởi động thay đổi, và nếu bạn mắc lỗi thì hậu quả tệ nhất chỉ là một tệp container mà bạn vứt bỏ. Mười lăm phút trên một server Debian hoặc Ubuntu đang chạy thật.

• Cài công cụ. apt install cryptsetup. Nếu gói của bạn đi kèm một block device thứ hai, hãy dùng thẳng nó và bỏ qua bước tiếp theo.
• Tạo một container. Trên một VPS chỉ có một ổ đĩa, cách thực tế là dùng một tệp: fallocate -l 40G /var/lib/vault.img. Nó hoạt động như một ổ đĩa và có thể mở rộng sau này.
• Định dạng nó thành LUKS2. cryptsetup luksFormat --type luks2 /var/lib/vault.img. Cứ dùng mặc định cho cipher; phần bên dưới sẽ nói về tham số duy nhất đáng chỉnh trên một server nhỏ.
• Mở nó ra và đặt một hệ thống tệp lên trên. cryptsetup open /var/lib/vault.img vault cho bạn /dev/mapper/vault; rồi mkfs.ext4 /dev/mapper/vault và mount /dev/mapper/vault /srv/vault.
• Di chuyển dữ liệu quan trọng, rồi trỏ các dịch vụ vào đó. Một bind mount, hoặc một lệnh rsync với dịch vụ đã dừng, thường sạch sẽ hơn symlink — database đặc biệt không thích bị "đi theo" như vậy.
• Sao lưu header của LUKS. cryptsetup luksHeaderBackup /var/lib/vault.img --header-backup-file vault-header.bin, rồi chuyển tệp đó ra khỏi server. Chỉ vài kilobyte hỏng ở đầu container cũng phá hủy vĩnh viễn mọi byte phía sau nó, và đây là biện pháp bảo hiểm duy nhất tồn tại.
• Đóng nó lại và chứng minh bạn có thể quay lại được. umount /srv/vault && cryptsetup close vault, rồi mở lại từ ghi chú của bạn thay vì từ trí nhớ. Hãy làm điều này trước khi có bất cứ thứ gì giá trị bên trong.

Sau khi khởi động lại, vault vẫn đóng cho đến khi bạn đăng nhập và mở nó. Đó không phải là một hạn chế cần khắc phục — đó chính là toàn bộ mục đích. Một volume tự mở là một volume có khóa nằm ngay trên máy.

Mã hóa toàn bộ root với mở khóa từ xa qua SSH

Khi yêu cầu là không điều gì đọc được sống sót qua một cuộc tịch thu lúc máy đã tắt — log, lịch sử shell, danh sách gói, hình dạng của những gì bạn đang chạy — thì hệ thống tệp root cũng phải nằm trong container. Vấn đề khi đó trở thành làm sao đưa được passphrase vào một máy chưa khởi động xong, và câu trả lời là một SSH server tí hon sống trong initramfs.

• Cài đặt mã hóa ngay từ đầu. Khởi động trình cài đặt bản phân phối qua tải lên ISO tùy chỉnh và chọn phân vùng có hướng dẫn với LVM mã hóa. Chuyển đổi một hệ thống tệp root đang chạy tại chỗ là điều khả thi nhưng không đáng mạo hiểm.
• Thêm SSH server tiền khởi động. apt install dropbear-initramfs, rồi đặt public key của bạn vào /etc/dropbear/initramfs/authorized_keys. Đây là một bộ khóa riêng biệt với SSH thông thường của bạn — hãy dùng một khóa dành riêng cho việc này.
• Khóa chặt nó lại. Trong /etc/dropbear/initramfs/dropbear.conf, đặt DROPBEAR_OPTIONS="-I 180 -j -k -p 2222 -s": không cho đăng nhập bằng mật khẩu, không port forwarding, có cổng riêng, và một thời gian chờ (idle timeout) để một phiên bị treo không thể giữ quá trình khởi động mãi ở trạng thái mở.
• Cấp mạng cho initramfs. Thêm một tham số ip= tĩnh vào GRUB_CMDLINE_LINUX trong /etc/default/grub — có dạng ip=address::gateway:netmask::interface:off. Dựa vào DHCP ở giai đoạn này là cách người ta tự khóa mình ngoài máy.
• Build lại và khởi động lại. update-initramfs -u && update-grub, rồi khởi động lại và kết nối bằng ssh -p 2222 root@your-server và chạy cryptroot-unlock. Client của bạn sẽ cảnh báo về một host key lạ: initramfs có host key riêng của nó, điều này là bình thường và đáng để ghim vào một mục known_hosts riêng.
• Kiểm thử đường dẫn thất bại trước khi bạn dựa vào nó. Cài một bản cập nhật kernel, khởi động lại, mở khóa lần nữa. Nâng cấp kernel sẽ tái tạo lại initramfs, và đó chính xác là lúc một cấu hình sai sẽ lộ ra.

Hai cài đặt thực sự quan trọng, và cái bẫy VPS nhỏ

LUKS2 mặc định dùng AES-XTS với khóa 512-bit và dẫn xuất khóa Argon2id. Cả hai đều đúng đắn. Tự chỉnh tay cipher là cách vừa làm chậm vừa làm yếu đi cùng lúc, và internet đầy rẫy những dòng lệnh sao chép lại làm đúng điều đó. Tuy nhiên, có hai điều đáng để bạn chú ý.

Hiệu năng không phải vấn đề — cho đến khi nó là vấn đề

Kiểm tra tăng tốc phần cứng bằng grep -m1 -o aes /proc/cpuinfo và đo bằng cryptsetup benchmark. Trên bất kỳ CPU nào có AES-NI — tức là mọi node chúng tôi vận hành — AES-XTS xử lý vài gigabyte mỗi giây trên mỗi core, vượt xa những gì một ổ đĩa ảo đơn lẻ có thể cung cấp, nên chi phí nhìn thấy được chỉ là vài phần trăm CPU khi I/O nặng và độ trễ tăng nhẹ. Không có AES-NI thì bức tranh đảo ngược và mã hóa trở thành nút thắt cổ chai; đó là trường hợp duy nhất một cipher thay thế là một quyết định thực sự chứ không phải làm theo phong trào.

Bộ nhớ của Argon2id là thứ hay cắn người

Argon2id cố tình ngốn nhiều bộ nhớ, và cryptsetup hiệu chỉnh nó vào lúc format dựa trên lượng RAM của máy bạn đang format trên đó. Format một volume trên một workstation 32 GB, chuyển nó sang một VPS 1 GB, và việc mở khóa có thể thất bại hoàn toàn vì lượng bộ nhớ mà hàm dẫn xuất khóa đòi hỏi không có sẵn ở đó — còn tệ hơn nữa bên trong một initramfs, nơi có sẵn ít bộ nhớ hơn nhiều so với trong một hệ thống đang chạy. Trên các instance nhỏ, hãy ghim nó lại: cryptsetup luksFormat --type luks2 --pbkdf argon2id --pbkdf-memory 262144 /dev/vdb giới hạn ở mức 256 MB. Thấp hơn là một sự suy giảm thực sự về khả năng chống lại brute force ngoại tuyến, nên hãy bù lại bằng một passphrase dài hơn.

Một cờ tùy chọn đáng để bạn cân nhắc có ý thức thay vì copy-paste: --allow-discards cho phép TRIM đi qua tới thiết bị bên dưới, điều này tốt cho độ bền SSD và hiệu năng ổn định lâu dài, nhưng cũng để lộ ra volume đang được dùng bao nhiêu và gần đúng ở đâu. Mặc định nó tắt. Hãy bật nó khi bạn biết rõ nó làm lộ điều gì.

Swap, log, snapshot — những phần người ta hay quên

Một vault đã mã hóa nhưng có plaintext rò rỉ xung quanh là kiểu thất bại phổ biến nhất, và nó vẫn vô hình cho đến khi có ai đó nhìn vào.

• Swap. Bất cứ thứ gì trong bộ nhớ đều có thể bị paging ra đĩa, kể cả dữ liệu bạn đã cẩn thận đặt trong vault. Hoặc tắt swap, hoặc cấp cho nó một khóa ngẫu nhiên ở mỗi lần khởi động bằng một dòng /etc/crypttab như swap /dev/vdb1 /dev/urandom swap,cipher=aes-xts-plain64,size=256.
• Mọi thứ ghi vào nơi bạn chưa nhìn tới. /var/log, /tmp, thư mục dữ liệu database, /var/lib/docker, lịch sử shell, journal của systemd. Mã hóa /srv/vault trong khi PostgreSQL vẫn ghi vào /var/lib/postgresql thì chẳng đạt được gì cả. Hãy liệt kê hết trước khi mã hóa.
• Snapshot. Một snapshot ở cấp block của một volume đã mã hóa là ciphertext nên không sao. Một snapshot bắt lại trạng thái bộ nhớ lại là một thứ hoàn toàn khác và có thể chứa khóa. Hãy biết panel của nhà cung cấp bạn chụp loại nào trước khi dùng nó.
• Sao lưu. Đích đến là nơi sai để giải quyết vấn đề này. Các công cụ như restic và BorgBackup mã hóa ngay tại nguồn bằng một khóa mà đích đến không bao giờ thấy, đó là lý do một máy chủ sao lưu có thể là một máy bình thường ở một khu vực pháp lý khác thay vì phải là một máy đáng tin cậy.
• Phần plaintext bạn đã gửi đi đâu đó rồi. Mã hóa dữ liệu lưu trữ không có tác dụng hồi tố. Bất cứ thứ gì đã được sao chép, gửi mail hay đồng bộ đi nơi khác đều nằm ngoài ranh giới bạn vừa vẽ ra.

Khóa nằm ở đâu chính là toàn bộ thiết kế

Mỗi cách bố trí ở trên thực chất là một tuyên bố về quyền quản lý khóa. Có bốn lựa chọn tồn tại và chúng không tương đương nhau:

• Trong đầu bạn, gõ vào ở mỗi lần khởi động. Bảo vệ tối đa, ma sát vận hành tối đa. Máy thực sự không thể đọc được nếu không có bạn.
• Trong một tệp trên chính máy đã mã hóa. Chỉ bảo vệ chống lại việc bán lại ổ đĩa một cách ngây thơ, và không gì khác. Nếu tệp đó nằm trên /boot dạng plaintext, nó chẳng bảo vệ được gì cả — sai lầm phổ biến nhất trong mã hóa tự triển khai.
• Trên một máy bạn kiểm soát, lấy về qua mạng. Clevis ràng buộc với một server Tang: clevis luks bind -d /dev/vdb tang '{"url":"https://tang.example.net"}'. Server khởi động không cần người can thiệp miễn là nó còn kết nối được về nhà, và từ chối mở khóa ở bất kỳ nơi nào khác. Tuyệt vời cho các hạm đội headless, và nó biến host Tang thành thứ phải được bảo vệ.
• Trong một TPM. Có ý nghĩa trên phần cứng bạn thực sự sở hữu. Trên một VPS, TPM ảo được cung cấp bởi chính hypervisor mà bạn đang cố loại trừ, nên nó giải quyết vấn đề tiện lợi chứ không phải niềm tin.

Một phép thử giải quyết được hầu hết các thiết kế: nếu máy có thể đạt tới màn hình đăng nhập mà không cần bạn, thì khóa đang nằm trên máy. Đó có thể là một sự đánh đổi hoàn toàn hợp lý — rất nhiều khối lượng công việc muốn khởi động lại không cần người can thiệp hơn là muốn khả năng chống lại một đối thủ quyết tâm. Hãy đưa ra lựa chọn đó một cách có chủ đích, và đừng mô tả kết quả như thể nó là thứ nó không phải.

Nhà cung cấp của bạn thấy được gì, và khu vực pháp lý bắt đầu từ đâu

Trên một VPS, một hypervisor nằm ngay bên dưới bạn. Chúng tôi không đọc bộ nhớ của guest, và chúng tôi không giữ log traffic, log kết nối hay log DNS, cũng không có dấu vết console — nhưng đó là các chính sách, và cách nói trung thực là một VPS yêu cầu bạn phải tin tưởng vào chúng. Trên bare metal thì không có hypervisor nào giữa bạn và silicon: mã hóa toàn bộ ổ đĩa được thiết lập ngay khi cài đặt với một passphrase chúng tôi không bao giờ nhận được là một đặc tính vật lý của máy, chứ không phải một sự đảm bảo từ chúng tôi. Sự khác biệt đó, chứ không phải việc chọn cipher, mới là điều bạn thực sự đang lựa chọn giữa hai bên.

Đó là lý do vì sao mã hóa và khu vực pháp lý là hai nửa của cùng một câu trả lời. Mã hóa quyết định một bản sao ổ đĩa của bạn đáng giá bao nhiêu; khu vực pháp lý quyết định ai có thể buộc máy phải được giao nộp, thông qua quy trình nào và nhanh tới đâu. Chúng tôi vận hành ở bảy khu vực pháp lý — Iceland, Thụy Sĩ, Panama, Romania, Moldova, Hà Lan và Nga — và lý do lựa chọn giữa các nơi đó nằm trong hướng dẫn khu vực pháp lý của chúng tôi, hoặc ở dạng ngắn gọn hơn qua công cụ chọn khu vực pháp lý và trang địa điểm.

Phần mà mã hóa không thể chạm tới là tiết lộ bắt buộc, vì nó nhắm vào bạn chứ không phải vào phần cứng. Vương quốc Anh, Pháp và Úc nằm trong số các quốc gia mà luật pháp có thể buộc một người phải giao nộp khóa giải mã hoặc chịu hình phạt nếu từ chối. Rủi ro đó đi theo nơi bạn đang ở, không phải nơi server đặt, và không cấu hình nào trên máy thay đổi được điều đó. Đăng ký mà không cần giấy tờ tùy thân giới hạn lượng dấu vết giấy tờ tồn tại ngay từ đầu — lý do thực tế, chẳng có gì hào nhoáng, khiến hosting không-KYC và mã hóa luôn xuất hiện cùng nhau trong một cuộc trò chuyện — nhưng đó không phải là một biện pháp phòng vệ trước một tòa án đã biết tên bạn.

Chín sai lầm biến mã hóa thành vật trang trí

• Tự động mở khóa từ một tệp khóa nằm trên cùng ổ đĩa. Phần lớn các server "đã mã hóa", và tương đương với việc để chìa khóa ngay trong ổ khóa.
• Mã hóa một volume mà dữ liệu nhạy cảm không bao giờ chạm tới. Vault thì trống rỗng còn database thì không nằm trong đó.
• Không bao giờ sao lưu header của LUKS. Một sector hỏng ở đầu container và mọi byte phía sau nó biến mất vĩnh viễn.
• Không bao giờ kiểm thử đường mở khóa. Rồi một bản nâng cấp kernel tái tạo lại initramfs và lần khởi động lại tiếp theo trở thành một chiến dịch cứu hộ.
• Format trên một máy lớn rồi mở khóa trên một máy nhỏ. Argon2id đòi hỏi lượng bộ nhớ mà VPS không thể cung cấp, và volume sẽ không mở được.
• Chọn một passphrase như một mật khẩu đăng nhập thông thường. Không gì giới hạn tốc độ của một cuộc tấn công ngoại tuyến ngoại trừ hàm dẫn xuất khóa. Độ dài mới là thứ mua được thời gian.
• Di chuyển plaintext vào mã hóa rồi cho rằng bản gốc đã biến mất. Trên ổ lưu trữ ảo hóa, việc ghi đè không xóa dữ liệu một cách đáng tin cậy.
• Gửi passphrase qua cùng kênh dùng để quản trị máy. OpSec máy chủ nói về vấn đề tương quan (correlation) mà điều đó tạo ra.
• Nhầm lẫn giữa mã hóa của nhà cung cấp với mã hóa của chính bạn. "Toàn bộ hạ tầng đều được mã hóa khi lưu trữ" — kể cả của chúng tôi — bảo vệ hạ tầng. Chỉ một khóa do chính bạn nắm giữ mới bảo vệ bạn khỏi hạ tầng đó.

Vậy có đáng làm trên một VPS không?

Có, với những kỳ vọng đã được hiệu chỉnh đúng mức. Chỉ với một giờ công sức và gần như không có chi phí vận hành đo được, một volume dữ liệu mã hóa loại bỏ hoàn toàn một nhóm rủi ro mà bạn không có cách nào khác để xử lý, và loại bỏ nó vĩnh viễn: phần cứng ngừng sử dụng, ổ lưu trữ được cấp lại, một máy đã tắt nằm trong tay người khác. Hãy làm điều đó trên mọi server chứa bất cứ thứ gì quan trọng, ngay sau checklist gia cố giờ đầu tiên.

Điều nó không làm được là biến một máy tính đi thuê thành máy tính của riêng bạn. Nếu mô hình mối đe dọa của bạn coi chính nhà cung cấp là đối thủ, thì không cipher nào khắc phục được điều đó — câu trả lời là phần cứng dedicated, nơi khóa được gõ qua IPMI và không bao giờ đi qua một hypervisor, một khu vực pháp lý được chọn có chủ đích, và kỷ luật không đặt lên bất kỳ server nào những gì không cần phải có ở đó. Việc khớp đúng biện pháp kiểm soát với mối đe dọa thực sự chính là sự khác biệt giữa quyền riêng tư và vẻ ngoài của quyền riêng tư.