Bài 41. Hạ tầng dưới dạng mã (IaC), serverless và tự động mở rộng (autoscaling)

Khóa học CompTIA Security+ SY0-801 · Phần 3: Kiến trúc bảo mật · Bài 41 · 🎯 Objective 3.1 · ⏱️ Đọc khoảng 14 phút · 🧪 Không cần lab · 📝 5 câu bài tập cuối bài

🎯 Mục tiêu bài học

• Hiểu Infrastructure as Code (IaC) là gì, lợi ích bảo mật và rủi ro khi làm sai.
• Hiểu serverless khác máy chủ truyền thống ra sao, và trách nhiệm bảo mật thay đổi thế nào.
• Hiểu autoscaling (tự động mở rộng) và các vấn đề bảo mật đi kèm.
• Thấy được ba khái niệm này liên kết với nhau trong một hạ tầng cloud hiện đại.

📎 Vị trí trong đề thi: đây là nhóm khái niệm về cách vận hành hạ tầng hiện đại, tiếp nối Bài 39 và Bài 40. Đề thường hỏi ở mức nhận biết khái niệm và lợi ích/rủi ro bảo mật của từng cách tiếp cận.

💡 Liên hệ thực tế: từ "làm tay" sang "viết thành mã"

Công ty chị Lan từng có thói quen: mỗi khi cần một máy chủ mới, một kỹ sư đăng nhập vào bảng điều khiển cloud và bấm từng bước để tạo ra nó — chọn cấu hình, mở cổng, gắn ổ đĩa. Sau một sự cố (máy chủ mới dựng thiếu một quy tắc tường lửa vì người làm quên bấm), Nam đề xuất đổi cách làm: viết cấu hình hạ tầng thành một tệp văn bản, rồi để công cụ tự dựng chính xác theo tệp đó mỗi lần. Đây là tình huống minh họa, không phải vụ việc có thật.

Vài tháng sau, công ty còn tiến thêm một bước: trang xử lý ảnh đại diện người dùng được viết lại thành một đoạn mã nhỏ, chỉ chạy khi có người tải ảnh lên, không cần giữ một máy chủ chạy suốt ngày đêm cho việc ít khi xảy ra. Và vào đợt khuyến mãi cuối năm, khi lượng truy cập tăng vọt, hệ thống tự thêm máy chủ để phục vụ, rồi tự giảm lại khi hết cao điểm.

Ba thay đổi đó — viết hạ tầng thành mã, bỏ máy chủ thường trực, và tự động co giãn — là ba chủ đề của bài này.

📝 Hình 41a. IaC thay thao tác tay bằng một tệp cấu hình được kiểm soát phiên bản, nên mọi lần dựng đều giống nhau và có thể rà soát trước khi chạy.

📘 Kiến thức cốt lõi

📝 Infrastructure as Code (IaC)

IaC là việc mô tả hạ tầng (máy chủ, mạng, tường lửa, quyền truy cập) bằng tệp cấu hình dạng văn bản, thay vì bấm tay qua giao diện. Công cụ IaC đọc tệp đó và tự động tạo ra đúng hạ tầng được mô tả.

Lợi ích bảo mật:

• Nhất quán: mọi lần dựng đều giống hệt nhau, không còn "quên bấm một bước" như làm tay.
• Kiểm soát phiên bản (Bài 7): tệp cấu hình được lưu trong Git như mã nguồn, nên có thể xem ai đổi gì, khi nào, và quay lui khi có lỗi.
• Rà soát trước khi chạy: thay đổi hạ tầng có thể được đồng nghiệp xem lại (code review) trước khi áp dụng, giống như rà soát mã ứng dụng.
• Phục hồi nhanh sau sự cố: dựng lại toàn bộ hạ tầng từ tệp cấu hình, thay vì nhớ và làm lại từng bước bằng tay.

Rủi ro khi làm IaC không đúng cách:

• Bí mật bị lộ trong mã (hardcoded secrets, Bài 24): mật khẩu hay khóa API bị viết thẳng vào tệp cấu hình rồi đẩy lên kho mã dùng chung.
• Nhân bản lỗi cấu hình hàng loạt: nếu tệp mẫu có một lỗi (như mở cổng quá rộng, Bài 27), lỗi đó bị lặp lại ở mọi nơi dùng tệp đó, thay vì chỉ một chỗ.
• Trôi cấu hình (configuration drift): khi ai đó sửa tay trực tiếp trên hệ thống thật mà không cập nhật lại tệp IaC, hệ thống thật và tệp mô tả không còn khớp nhau, gây nhầm lẫn khi điều tra sự cố.
• Quyền quá rộng cho công cụ IaC: công cụ chạy IaC thường cần quyền cao để tạo tài nguyên, nên tài khoản đó trở thành mục tiêu giá trị cao nếu bị lộ.

Giảm thiểu: quét tệp IaC bằng công cụ tự động trước khi áp dụng (tương tự SAST ở Bài 24), không bao giờ viết bí mật trực tiếp vào tệp mà dùng kho quản lý bí mật riêng, rà soát thay đổi như rà soát mã, và kiểm tra định kỳ để phát hiện trôi cấu hình.

⚡ Serverless (điện toán không máy chủ)

"Serverless" không có nghĩa là không có máy chủ — vẫn có máy chủ chạy ở đâu đó — mà nghĩa là nhà phát triển không phải quản lý máy chủ. Mã chỉ chạy khi có sự kiện kích hoạt (một yêu cầu web, một tệp được tải lên), và nhà cung cấp tự lo việc cấp phát, mở rộng, tắt đi khi không dùng.

Lợi ích bảo mật:

• Bề mặt tấn công nhỏ hơn: không có hệ điều hành thường trực để vá lỗi, không có cổng mạng mở liên tục (Bài 18, 21).
• Mỗi lần chạy thường ở trong môi trường tạm thời, cô lập, giảm nguy cơ một lần chạy ảnh hưởng tới lần sau.

Rủi ro riêng:

• Quyền quá rộng (excessive permissions): một hàm serverless xử lý ảnh nhưng được cấp quyền truy cập toàn bộ cơ sở dữ liệu là vi phạm quyền tối thiểu (Bài 4, 31).
• Phụ thuộc thư viện bên thứ ba: hàm serverless thường gói theo nhiều thư viện, mỗi thư viện là một phần của chuỗi cung ứng (Bài 20).
• Khó giám sát theo cách truyền thống: không có máy chủ cố định để cài công cụ giám sát, cần dùng công cụ dành riêng cho serverless.
• Chi phí có thể bị lợi dụng: nếu bị gọi lặp đi lặp lại bất thường (như một dạng từ chối dịch vụ nhắm vào chi phí), hóa đơn có thể tăng vọt.

Giảm thiểu: áp quyền tối thiểu chặt chẽ cho từng hàm (không dùng một vai trò quyền chung cho mọi hàm), quét thư viện phụ thuộc, giới hạn số lần gọi và đặt cảnh báo chi phí, ghi nhật ký đầy đủ từng lần chạy.

📈 Autoscaling (tự động mở rộng)

Autoscaling là khả năng hệ thống tự thêm hoặc bớt tài nguyên (máy chủ ảo, hàm serverless) theo nhu cầu thực tế, thay vì giữ cố định một lượng tài nguyên lớn phòng khi cao điểm.

Lợi ích bảo mật và vận hành:

• Giúp hệ thống chịu được tải cao đột ngột mà không sập, một phần giảm nhẹ ảnh hưởng của DDoS dạng khối lượng (Bài 30), dù không thay thế được biện pháp chặn DDoS chuyên dụng.
• Tránh lãng phí tài nguyên lúc thấp điểm.

Rủi ro riêng:

• Máy chủ mới dựng tự động phải được cấu hình đúng chuẩn bảo mật ngay từ đầu (nhờ IaC), vì không có người kiểm tra tay từng máy mới trước khi nó phục vụ lưu lượng thật.
• Tấn công làm cạn tài nguyên qua chi phí: kẻ tấn công cố ý tạo lưu lượng giả để buộc hệ thống mở rộng liên tục, gây tốn kém (gần với ý tưởng DDoS ở lớp ứng dụng, Bài 30).
• Máy chủ tự động tắt đi rồi bật lại khiến việc truy vết sự cố khó hơn: máy chủ "phạm lỗi" trong nhật ký có thể đã không còn tồn tại khi đội điều tra vào xem.
• Cấu hình nhóm autoscaling quá lỏng lẻo (như cho phép mở rộng không giới hạn) có thể bị lợi dụng để tạo tài nguyên trái phép nếu kẻ tấn công chiếm được quyền kiểm soát, dùng vào mục đích khác như đào tiền ảo.

Giảm thiểu: luôn dựng máy mới từ mẫu đã được rà soát bảo mật (gắn với IaC), đặt giới hạn trên cho autoscaling và cảnh báo chi phí bất thường, gửi nhật ký về nơi tập trung ngay khi sinh ra (Bài 33) thay vì giữ trên từng máy tạm thời, và giám sát độ tin cậy của lưu lượng trước khi để nó kích hoạt mở rộng.

🔄 Hình 41b. IaC định nghĩa hạ tầng một cách nhất quán, autoscaling dùng đúng định nghĩa đó để dựng thêm tài nguyên, và serverless là dạng tài nguyên không cần quản lý máy chủ bên dưới.

🛡️ Bảng tổng hợp

🎯 Mẹo làm bài: "Hạ tầng được mô tả bằng tệp văn bản, kiểm soát phiên bản" là IaC. "Mã chỉ chạy khi có sự kiện, không cần quản lý máy chủ" là serverless. "Hệ thống tự thêm hoặc bớt tài nguyên theo tải" là autoscaling. Với câu hỏi về rủi ro, luôn nghĩ tới: IaC → bí mật lộ và lỗi nhân bản; serverless → quyền quá rộng; autoscaling → cấu hình sai hàng loạt và khó truy vết.

🧠 Áp vào câu chuyện của Nam

📖 Thuật ngữ cần nhớ

📌 Tóm tắt nhanh

• IaC biến việc dựng hạ tầng thành mã có thể kiểm soát phiên bản và rà soát, nhưng cần tránh để lộ bí mật và nhân bản lỗi cấu hình.
• Serverless giảm bề mặt tấn công nhờ không có máy chủ thường trực, nhưng dễ bị cấp quyền quá rộng cho từng hàm.
• Autoscaling giúp chịu tải cao, nhưng máy mới dựng tự động phải an toàn ngay từ mẫu, và việc máy tạm thời biến mất làm khó truy vết sự cố.
• Cả ba khái niệm hỗ trợ nhau trong một hạ tầng cloud hiện đại: IaC định nghĩa, autoscaling thi hành, serverless là một dạng tài nguyên không cần quản lý máy chủ.

💬 Hỏi & Đáp nhanh

❓ IaC có loại bỏ hoàn toàn lỗi cấu hình không? Không. Nó loại bỏ lỗi do thao tác tay không nhất quán, nhưng nếu bản thân tệp cấu hình có lỗi, lỗi đó sẽ lặp lại ở mọi nơi áp dụng tệp. Vì vậy cần rà soát và quét tệp IaC trước khi dùng, giống như rà soát mã ứng dụng.

❓ Serverless có nghĩa là nhà cung cấp lo hết bảo mật không? Không. Nhà cung cấp lo hạ tầng bên dưới (theo mô hình trách nhiệm chia sẻ, Bài 40), nhưng quyền của từng hàm, mã nguồn hàm, và dữ liệu nó xử lý vẫn là trách nhiệm của người viết và triển khai hàm đó.

❓ Autoscaling có chống được DDoS không? Giúp hệ thống chịu đựng tốt hơn trong một số trường hợp, nhưng không phải biện pháp chống DDoS chuyên dụng (Bài 30), và nếu không giới hạn, nó có thể khiến kẻ tấn công gây tốn kém chi phí thay vì chỉ làm sập dịch vụ.

📝 Bài tập đánh giá

Tự chọn đáp án cho từng câu, rồi đối chiếu với phần đáp án ở cuối bài.

Câu 1. Lợi ích bảo mật chính của việc dùng Infrastructure as Code thay vì dựng hạ tầng bằng tay là gì?

• A. Luôn rẻ hơn trong mọi trường hợp
• B. Nhất quán giữa các lần dựng, kiểm soát được phiên bản và có thể rà soát trước khi áp dụng
• C. Không cần quan tâm đến cấu hình bảo mật nữa
• D. Tự động vá mọi lỗ hổng phần mềm

Câu 2. Rủi ro đặc trưng khi viết tệp IaC không đúng cách là gì?

• A. Lỗi cấu hình chỉ xảy ra ở một máy duy nhất
• B. Bí mật (mật khẩu, khóa API) có thể bị viết thẳng vào tệp và lộ ra, hoặc một lỗi trong tệp bị nhân bản ở mọi nơi áp dụng
• C. Hệ thống sẽ tự động an toàn hơn
• D. Không có rủi ro nào đáng kể

Câu 3. "Serverless" có nghĩa là gì?

• A. Hoàn toàn không có máy chủ nào tồn tại
• B. Nhà phát triển không phải quản lý máy chủ; mã chạy theo sự kiện kích hoạt
• C. Chỉ dùng được cho ứng dụng on-premises
• D. Luôn chạy liên tục 24/7 không ngừng nghỉ

Câu 4. Rủi ro bảo mật riêng thường gặp với các hàm serverless là gì?

• A. Hàm được cấp quyền vượt quá mức cần thiết cho công việc của nó
• B. Luôn miễn nhiễm với mọi lỗ hổng
• C. Không bao giờ dùng thư viện bên thứ ba
• D. Không thể bị tấn công vì không có máy chủ

Câu 5. Một hệ thống dùng autoscaling để tự thêm máy chủ khi tải cao. Vì sao máy chủ mới dựng tự động cần đến từ mẫu đã được rà soát bảo mật?

• A. Vì không ai kiểm tra tay từng máy mới trước khi nó phục vụ lưu lượng thật, nên lỗi cấu hình sẽ bị nhân bản hàng loạt
• B. Vì máy chủ mới luôn tự động an toàn hơn máy cũ
• C. Vì autoscaling không liên quan gì đến bảo mật
• D. Vì mẫu chỉ ảnh hưởng đến tốc độ, không ảnh hưởng bảo mật

👉 Đáp án

Câu 1: B — IaC mang lại sự nhất quán, kiểm soát phiên bản và khả năng rà soát trước khi áp dụng, so với thao tác tay dễ sai sót và không nhất quán.

Câu 2: B — Hai rủi ro đặc trưng là bí mật bị lộ trong mã và lỗi cấu hình bị nhân bản ở mọi nơi dùng chung tệp.

Câu 3: B — Serverless nghĩa là nhà phát triển không cần quản lý máy chủ; mã chỉ chạy khi có sự kiện kích hoạt, vẫn có máy chủ chạy ở phía nhà cung cấp.

Câu 4: A — Cấp quyền vượt mức cần thiết (excessive permissions) là rủi ro đặc trưng và phổ biến của các hàm serverless.

Câu 5: A — Vì máy mới dựng tự động không qua kiểm tra tay, nên nếu mẫu có lỗi cấu hình, lỗi đó sẽ lặp lại ở mọi máy mới được tạo ra.

📚 Bài viết thuộc khóa học CompTIA Security+ của VNExperts

🧭 Điều hướng