An toàn dữ liệu trên VPS, Dedicated và Hybrid Cloud: Sai lầm phổ biến và cách phòng tránh

Khởi đầu thảm họa: Cái mail "tài khoản của bạn bị truy cập trái phép"

Hồi mình còn non tay, có lần mình cài cái game server Minecraft cho thằng em trai. Nó mê lắm, cứ gọi điện hỏi suốt ngày. Mình cũng cặm cụi cấu hình VPS, mở cổng, cài plugin đủ kiểu. Cứ tưởng xong xuôi là ngon rồi, anh em cứ thế mà chiến thôi. Mà lúc đó mình tin sái cổ mấy cái mặc định của VPS. "Chắc hãng họ làm chuẩn rồi, có gì đâu mà lo".

Rồi một buổi sáng đẹp trời, mình nhận được một cái email. Tiêu đề nó cứ là lạ: "Your account has been accessed from an unusual location". Mồ hôi lạnh bắt đầu túa ra. Kiểm tra lại thì đúng là VPS của mình bị truy cập thật, một vài file cấu hình bị thay đổi, may mà dữ liệu game chưa mất. Lần đó hú hồn, một bài học nhớ đời về việc không bao giờ được chủ quan với an toàn dữ liệu.

Kinh nghiệm "đau thương" đó khiến mình phải nhìn nhận lại toàn bộ quy trình vận hành. Dù bạn đang chạy server game cá nhân trên VPS, hay cả một hệ thống lớn trên Dedicated Server và Hybrid Cloud, những rủi ro về mất mát hay rò rỉ dữ liệu luôn rình rập. Đôi khi, nó đến từ những sai lầm nhỏ nhất, những cái mình "tưởng là an toàn".

Backup đã. Rồi muốn làm gì thì làm.

Nói thật, cái này ai cũng biết, nhưng nhiều người vẫn quên hoặc làm qua loa. Mình có thằng bạn, server game cả trăm người chơi mà backup chỉ copy tay folder world ra Desktop mỗi tuần. Đến khi ổ cứng VPS lăn đùng ra chết, mất cả tháng trời công sức của bao nhiêu người chơi.

Backup không chỉ là có bản sao. Quan trọng là bản sao đó có an toàn không, và có khôi phục được không. Một cái nhiều bạn hay quên là backup cần phải được mã hóa. "Check that data is encrypted 'at rest'. Surprisingly few VPS providers use (or even allow) full disk encryption. That's because web servers are rarely 'at rest', but they forget about backups. Backups really should ALWAYS be encrypted if you're serious about protecting user data and privacy." – cái này mình đọc được trên một topic ở Web Hosting Talk. Hoàn toàn đúng. Dù là file `.jar` game server hay cơ sở dữ liệu người dùng, nếu backup không mã hóa, ai đó tóm được cái file đó là xong.

Mình thường dùng những tool như `DriveBackupV2` cho server game để backup tự động ra các storage ngoài (như AWS S3 hoặc MinIO tự host). Nhưng dù tool có "xịn" đến mấy, cái ổ đĩa hay S3 bucket chứa backup đó phải được mã hóa. Đừng chấp nhận cài đặt mặc định.

Bạn có nghĩ "mặc định" là "an toàn" không? Sai lầm chết người đó.

Đây là sai lầm mà mình tin là phổ biến nhất, và nó chính là thủ phạm trong cái vụ game server "hú hồn" của mình ngày xưa. "Don’t simply accept the default settings." – Một lời khuyên ngắn gọn nhưng cực kỳ giá trị từ blog FRSecure về các lỗi bảo mật trên cloud. Mà nó đúng cho cả VPS hay Dedicated.

Vấn đề 1: Mã hóa và Giao thức truyền tải

Hồi đó mình cứ chạy server game, bật cổng lên là xong. Ai dè mình đang truyền dữ liệu "trần trụi" qua HTTP. Một bài trên Web Hosting Talk có nhắc: "default setups often use obsolete ciphers and allow unencrypted connections (http instead of https)". Mình đúng là cái "default setup" đó luôn.

Kể cả bạn chạy web hay API, việc ép buộc HTTPS là tối quan trọng. "Cloud storage instances largely allow both HTTP and HTTPS requests for access by default. You must configure your cloud environment to deny HTTP requests." (FRSecure). Mình thường làm thế này, với Nginx chẳng hạn, mình sẽ redirect hết HTTP sang HTTPS. Đơn giản mà hiệu quả.

1|server {
2|    listen 80;
3|    server_name example.com www.example.com;
4|    return 301 https://$host$request_uri;
5|}
6|
7|server {
8|    listen 443 ssl;
9|    server_name example.com www.example.com;
10|    # ... cấu hình SSL và các thứ khác ...
11|}

Mã hóa dữ liệu "nằm yên" (at rest) cũng vậy. Nó thường bị tắt mặc định. Với những dữ liệu nhạy cảm, mình luôn bật full disk encryption hoặc mã hóa cấp ứng dụng. "Encryption – While provided as an option, encryption is typically disabled by default. You must enable it." (FRSecure).

Vấn đề 2: Lỗ hổng từ mạng và quyền truy cập

Mấy cái firewall hay Security Group trên Cloud thường cho "unrestricted" inbound/outbound traffic ban đầu. "Network Architecture – By default, virtual networks typically have inbound and outbound subnet filtering set to ‘unrestricted’. Restrictions must be applied, otherwise, new instances created in that subnet will inherit the same default permissions." (FRSecure). Cứ để vậy là các cổng của bạn mở toang, "mời" hacker ghé thăm.

Mình đã từng dùng lệnh này để kiểm tra các cổng đang mở trên server:

1|netstat -tuln

Nếu thấy có cổng lạ nào đó đang lắng nghe (Listen) mà mình không hề biết, hoặc không có nhu cầu dùng, là phải đóng ngay. Với `iptables` hay Security Group, nguyên tắc là "cấm hết trừ những cái cần thiết".

Và quyền truy cập (IAM). "Insufficient Identity and Access Management (IAM) – Weak controls over user access, opening the door to unauthorized usage." (FRSecure). Đừng cho ai quyền root nếu họ chỉ cần quyền xem log. Tạo user riêng, gán quyền tối thiểu cần thiết.

Con người là mắt xích yếu nhất (luôn luôn).

Dù có công nghệ xịn đến đâu, hệ thống phức tạp đến mấy, con người vẫn là điểm yếu lớn nhất. Mình từng thấy một case trên forum Web Hosting Talk: "The main risk by far comes from the humans using the installed software - accidental data deletion, clicking links in emails, responding to phishing phone calls, using weak passwords and so on." Thật quá chuẩn.

Mấy cái email phishing giờ tinh vi lắm. Mình dạo này nhận toàn mấy cái giả mạo email từ ngân hàng, nhà cung cấp dịch vụ cloud. Nếu không tỉnh táo, click vào là đi tong tài khoản. Vì vậy, 2FA (Multi-Factor Authentication) là cái mình luôn bật cho mọi tài khoản có thể. "Multi-Factor Authentication – MFA is not always enabled by default. It too must be configured manually. This is one of the most important foundational practices in any security program and one that is still overlooked surprisingly often." (FRSecure). Đúng là một thứ rất quan trọng nhưng lại hay bị bỏ qua.

Và mật khẩu. Đừng dùng mật khẩu dễ đoán, đừng dùng chung mật khẩu. Dùng password manager là cách tốt nhất để tạo và quản lý mật khẩu mạnh, riêng biệt cho từng dịch vụ.

Chơi Hybrid Cloud: Nghe sang, làm thì đau đầu.

Khi hệ thống phát triển, không ít lần mình phải nghĩ đến Hybrid Cloud. Chuyển một phần workload lên cloud để tận dụng khả năng co giãn, nhưng dữ liệu nhạy cảm vẫn giữ on-premise. Nghe thì có vẻ "có cả hai", nhưng thực tế nó phức tạp hơn nhiều. "A common misconception is that hybrid cloud inherently reduces security risks, but in reality, it introduces complexity that can lead to vulnerabilities if not properly managed." – bài viết từ ITU Online IT Training đã nói rất rõ.

Mình nhớ có lần, một đội khác bên mình thử đồng bộ trạng thái database giữa on-prem và cloud. Kết quả là "every time we try to sync state (database replication, cache invalidation, etc), we end up with copies of regulated data sitting in places they shouldn't be." – cái này y chang case một bạn trên forum hostingartisan.com kể. Đau đầu thật.

Giải pháp cho mấy vụ này phức tạp hơn nhiều. Ví dụ, mình đã tìm hiểu về mã hóa cấp trường (field-level encryption) với key quản lý on-premise. Tức là chỉ đồng bộ dữ liệu đã mã hóa lên cloud, key giải mã thì mình giữ. "Consider field-level encryption with key management staying on-prem. Instead of syncing raw state, sync only the encrypted blobs—keep decryption keys behind your firewall." (hostingartisan.com). Cách này hay, nhưng thêm độ trễ.

À, một cái nữa mà ít ai để ý khi dùng database trên cloud: query log. Ngay cả khi dữ liệu của bạn đã được mã hóa trước khi đưa lên cloud, các câu truy vấn (query) mà ứng dụng gửi đến database trên cloud vẫn có thể bị log lại. Và trong đó có thể chứa các thông tin nhạy cảm. "query logs and slow query logs... can leak PII patterns." (hostingartisan.com). Mình đã từng phải dùng "query rewrite proxies to strip sensitive columns" để che giấu những phần nhạy cảm trong câu truy vấn trước khi nó đến cloud. Tốn công sức hơn, nhưng an toàn.

Kết thúc câu chuyện... và vài lời nhắn gửi.

Cái game server Minecraft ngày xưa của mình, sau vụ "hú hồn" đó, mình đã phải ngồi lại cấu hình lại hết. Tắt bớt cổng không dùng, cài `fail2ban` chống brute-force, bật mã hóa backup, và quan trọng nhất là mình chịu khó đọc tài liệu hãng cung cấp, không tin vào "mặc định" nữa.

An toàn dữ liệu là một hành trình liên tục, không phải là đích đến. Đặc biệt với tốc độ phát triển chóng mặt của công nghệ như hiện nay, những "best practice" của 5-10 năm trước có thể giờ đã lỗi thời. "Check that VPS setups are up to date - not just patched but following best practice. I very commonly see out-of-date security setups, by which I mean setups that were state of the art 10 years ago but are now totally irrelevant because the hackers have moved on." (Web Hosting Talk).

Đừng chủ quan, đừng lười biếng. Mỗi ngày dành ra một ít thời gian để xem lại cấu hình, vá lỗi, cập nhật kiến thức. Có như vậy, bạn mới có thể bảo vệ được "tài sản" của mình trên không gian mạng.