Cửa không khóa, mời trộm vào nhà!

Password là 123456

Nhớ lần đầu tôi audit một hệ thống serverless, anh dev tự tin khoe: "Hệ thống em bảo mật lắm anh!". Tôi hỏi: "Thế ai có quyền truy cập vào Lambda Functions này?". Anh ấy liền chỉ vào một role IAM với quyền * (tức là "full quyền, muốn làm gì cũng được") và giải thích: "À, tại bọn em cần nhanh nên cứ để thế cho tiện."

Tim tôi lúc đó… muốn rớt ra ngoài.

Thế đấy, trong thế giới serverless, khi bạn không quản lý server vật lý, bảo mật trở thành một cuộc chơi hoàn toàn khác. Thay vì lo lắng về việc ai đó đột nhập vào máy chủ của bạn, giờ đây bạn phải lo lắng về việc:

• Ai có thể gọi hàm của bạn? (Lambda, API Gateway)
• Hàm của bạn có thể truy cập những gì? (IAM Permissions)
• Dữ liệu nhạy cảm của bạn đang ở đâu và được bảo vệ như thế nào? (DynamoDB, S3, Secrets Manager)
• Có lỗ hổng nào trong code của bạn không? (Vulnerabilities)

Nếu bạn không đặt câu hỏi, không đào sâu, không audit kỹ lưỡng, thì hệ thống serverless của bạn chẳng khác nào một ngôi nhà cửa không khóa, mời trộm vào nhà vậy. Tiện thì có tiện đấy, nhưng hậu quả thì… khôn lường!

Và những câu chuyện dở khóc dở cười

Khi audit bảo mật serverless, tôi thường tìm kiếm những "điểm đen" sau:

• Injection Attacks (SQL/NoSQL/Command Injection): "Dạ, em tin tưởng input của người dùng 100% ạ." – Vâng, tin tưởng thì hệ thống sẽ "tin tưởng" trả lại toàn bộ database cho hacker. Đặc biệt với NoSQL như DynamoDB, việc không validate input kỹ lưỡng có thể dẫn đến những hậu quả khó lường.
• Broken Authentication/Authorization: "Ai cũng có thể gọi API của em, miễn là biết endpoint!" – Đáng sợ hơn cả console.log. Đảm bảo API Gateway có phương thức xác thực mạnh mẽ (Cognito, Lambda Authorizer, JWT) và mỗi user chỉ có quyền làm những gì họ được phép.
• Sensitive Data Exposure: "Dữ liệu khách hàng à? Em để trong S3 bucket public ấy, tiện cho việc test." – Hoặc tệ hơn, hardcode mật khẩu database trong mã nguồn Lambda. Luôn nhớ mã hóa dữ liệu cả khi truyền tải (in transit) và khi lưu trữ (at rest). Dùng Secrets Manager hoặc Parameter Store cho các thông tin nhạy cảm.
• Insecure Dependencies: "Thư viện này em tải về từ năm ngoái rồi, chắc không sao đâu anh." – Hàng tá lỗ hổng bảo mật ẩn chứa trong các thư viện cũ kỹ, không được cập nhật. Scan thường xuyên các dependency là việc cần làm ngay và luôn.

Quyền năng vô hạn, trách nhiệm bằng 0

Đây là "vùng đất" màu mỡ nhất cho các lỗ hổng. Nguyên tắc "Least Privilege" là kim chỉ nam. Một Lambda function chỉ nên có quyền truy cập vào những tài nguyên mà nó thực sự cần.

• Có những role IAM nào đang có quyền * không?
• Có những user hoặc service nào đang có quyền quá mức không?
• Chính sách IAM có được gắn chặt chẽ vào các tài nguyên cụ thể không, hay đang quá rộng rãi?

Khi audit, bạn sẽ thấy vô số trường hợp dev tiện tay gán quyền Administrator cho một Lambda chỉ để nó… đọc một file S3. Nghe thì "dở hơi" nhưng rất phổ biến đấy!

Và các lỗ hổng phổ biến

Code của bạn chính là "bộ não" của hệ thống serverless. Nó cần được kiểm tra kỹ lưỡng:

• Static Application Security Testing (SAST): Dùng các công cụ tự động để quét code tìm lỗ hổng (ví dụ: SonarQube, Bandit cho Python, ESLint cho JS/TS).
• Code Review thủ công: Không gì thay thế được "con mắt" của một người có kinh nghiệm để phát hiện những logic security flaw mà công cụ không bắt được.
• Dependency Scanning: Kiểm tra các thư viện bạn đang dùng có lỗ hổng nào không (ví dụ: Snyk, Dependabot).

Thằng ăn trộm vào lúc nào?

Vâng, lại là log! Khi nói đến bảo mật, log không chỉ là để debug, nó là "bằng chứng thép" khi có sự cố.

• Hệ thống có ghi lại đầy đủ các sự kiện quan trọng (login, logout, truy cập dữ liệu nhạy cảm, thay đổi quyền) không?
• Có thiết lập alert khi có hành vi đáng ngờ (ví dụ: truy cập bất thường từ IP lạ, lượng truy cập quá lớn) không?
• Log có được lưu trữ an toàn và không thể bị sửa đổi không?

Nếu không có log bảo mật đầy đủ, khi hacker "ghé thăm", bạn sẽ không biết họ vào bằng cách nào, lấy đi những gì, và đi ra từ đâu. Cứ như một vụ án không có dấu vết vậy.

Chơi đúng luật hay ăn phạt?

Đối với một số ngành (tài chính, y tế), việc tuân thủ các quy định như GDPR, HIPAA, SOC 2 không phải là lựa chọn mà là bắt buộc.

• Bạn có hiểu những quy định này ảnh hưởng đến kiến trúc serverless của mình như thế nào không?
• Dữ liệu khách hàng có được xử lý đúng chuẩn không?
• Có các báo cáo audit định kỳ để chứng minh sự tuân thủ không?

Việc "lơ là" tuân thủ không chỉ gây thiệt hại về uy tín mà còn có thể dẫn đến những khoản phạt "khổng lồ".

Tóm lại: Bảo mật serverless không phải là một "công tắc" bạn bật lên một lần rồi quên. Nó là một quá trình liên tục, đòi hỏi sự chủ động audit, kiểm tra, và cập nhật. Đừng để hệ thống của bạn trở thành "món mồi ngon" cho những kẻ xấu chỉ vì sự tiện tay hay thiếu hiểu biết.