Báo Cáo Thực Hành: An Toàn Đám Mây
Thông tin Dự án
Website này là sản phẩm báo cáo thực hành môn An toàn Điện toán Đám mây, được triển khai trên nền tảng Cloudflare Pages kết hợp quản lý mã nguồn qua GitHub.
Thành viên thực hiện
LAB TUẦN 1: Kiến Trúc & CDN
I. Kiến trúc Cloud Computing cơ bản
- Cloud Computing: Sử dụng tài nguyên máy tính qua Internet thay vì quản lý máy chủ vật lý.
- Các mô hình dịch vụ:
- SaaS Ứng dụng trọn gói (Google Drive, Slack).
- PaaS Nền tảng phát triển (Heroku, Cloudflare Pages).
- IaaS Cơ sở hạ tầng ảo hóa (AWS EC2, GCE).
II. Phân tích Rủi ro & Giải pháp
Rủi ro Tiềm ẩn
- Lộ Origin Server: Tấn công trực tiếp vào IP gốc.
- Cache Poisoning: Tiêm dữ liệu sai vào bộ đệm.
- Tấn công Injection (SQLi, XSS) qua API.
- Man-in-the-Middle do cấu hình SSL yếu.
Giải pháp Bảo mật
- Firewall Rules: Chỉ cho phép traffic từ CDN.
- Strict SSL/TLS: Mã hóa toàn trình.
- WAF (Web Application Firewall): Chặn các pattern tấn công.
- Rate Limiting: Chống DDoS.
III. Hình ảnh minh họa
LAB TUẦN 2: Quản Lý Truy Cập, IAM & An Toàn Mạng Trong Điện Toán Đám Mây
- Hiểu cách quản lý truy cập (Identity & Access) trong môi trường cloud.
- Phân biệt rõ Authentication – Authorization – IAM.
- Phân tích sự khác biệt giữa bảo mật mạng truyền thống và Zero Trust.
- Thiết kế mô hình kiểm soát truy cập hợp lý cho hệ thống cloud.
- Nhận diện và đánh giá rủi ro an toàn liên quan đến truy cập trái phép.
I. Kiến thức cơ bản (Yêu cầu 1)
Tài liệu tham khảo:
Khái niệm chính:
- Authentication: Kiểm tra danh tính ("Bạn là ai?"). Ví dụ: Đăng nhập Google/GitHub.
- Authorization: Xác định quyền hạn ("Bạn được làm gì?"). Ví dụ: Quyền truy cập website.
- IAM trong cloud: Quản lý tập trung danh tính và quyền hạn, đảm bảo truy cập đúng tài nguyên.
- Zero Trust: "Never trust, always verify" – Kiểm tra mọi truy cập liên tục.
II. Thiết kế mô hình kiểm soát truy cập (Yêu cầu 2)
Công cụ: Website tĩnh Lab 1, Cloudflare Zero Trust/Access, GitHub.
Truy cập Website Tĩnh- Người dùng (User/Client): Trình duyệt trên thiết bị.
- Yêu cầu truy cập (Request): HTTP/HTTPS tới website.
- Lớp kiểm soát (Cloudflare Access/Zero Trust): Reverse Proxy kiểm tra yêu cầu.
- Khối xác thực (IdP): Google hoặc GitHub.
- Khối kiểm tra chính sách (Policy Engine): Quy tắc như email, IP.
- Tài nguyên đích (Resource): Website tĩnh trên Cloudflare Pages.
- Gửi yêu cầu HTTP/HTTPS tới tên miền.
- Cloudflare Access kiểm tra JWT/Cookie.
- Xác thực: Chuyển hướng đến IdP nếu chưa đăng nhập; cấp JWT nếu thành công.
- Authorization: Kiểm tra Token với Policy.
- Kết nối: Chuyển tiếp nếu thỏa mãn.
- Allow: Vượt qua xác thực và Policy → Truy cập website.
- Deny: Sai đăng nhập hoặc không thỏa Policy → Lỗi, chặn truy cập.
- Thực thi Zero Trust: Kiểm tra mọi truy cập.
- Bảo vệ ứng dụng: Ẩn máy chủ, chặn truy cập trái phép.
- Quản lý IAM tập trung: Xác thực và phân quyền thống nhất.
Sơ đồ và Giải thích
Sơ đồ chia 3 vùng: Người dùng (Untrusted), Kiểm soát (Cloudflare), Tài nguyên (Website/Denied).
Luồng dữ liệu: Request → Xác thực → Cấp quyền → Quyết định (Allow/Deny).
Yêu cầu bổ sung
- Bổ sung Lab 2 vào website Lab 1.
- Kiểm thử an toàn đạt loại A.
- Bảo vệ bằng Cloudflare Access, chỉ truy cập sau đăng nhập Google/GitHub.
- Hành vi: Chưa xác thực (chặn), sai (lỗi), đúng (truy cập).
III. Phân tích rủi ro và so sánh (Yêu cầu 3)
Rủi ro Website public
- DDoS.
- Web Scraping/Crawling.
- Brute-force thư mục ẩn.
Rủi ro Website với IAM
- Lộ thông tin xác thực (Phishing, mật khẩu yếu).
- Cấp quyền quá rộng.
- Session Hijacking.
Rủi ro IAM không Zero Trust
- Lateral Movement.
- Không kiểm soát ngữ cảnh truy cập.
- Rủi ro BYOD.
So sánh mô hình
| Tiêu chí | Truyền thống (Castle-and-Moat) | Zero Trust |
|---|---|---|
| Khái niệm niềm tin | Tin cậy nội bộ (Trust but Verify). | Không tin cậy ai (Never Trust, Always Verify). |
| Phạm vi bảo vệ | Dựa trên biên mạng (Perimeter). | Dựa trên dữ liệu & người dùng. |
| Cơ chế kiểm tra | Kiểm tra một lần tại cửa ngõ. | Kiểm tra liên tục mọi request. |
| Khả năng phản ứng | Chậm, rủi ro lan truyền. | Nhanh, cô lập thiệt hại (Micro-segmentation). |
| Ví dụ | VPN kết nối nội bộ. | Cloudflare Access kiểm tra Token/Device. |
LAB TUẦN 3: Triển khai & An toàn Cloud
Mục tiêu Lab 3
Lab 3 tập trung vào việc triển khai ứng dụng web có lỗ hổng (OWASP Juice Shop) trên môi trường local (Container) để:
- Hiểu cơ chế triển khai ứng dụng Cloud-native bằng Docker.
- Phân tích rủi ro bảo mật (SQL Injection) khi ứng dụng đưa lên môi trường Cloud.
- Chứng minh vai trò của Cloud trong việc khuếch đại rủi ro hoặc cung cấp lớp bảo vệ.
I. Công nghệ sử dụng
II. Quy trình thực hành triển khai
Để mô phỏng môi trường Cloud-native, nhóm đã thực hiện các bước sau:
- Bước 1: Cài đặt Docker Desktop trên Windows và cấu hình tài nguyên.
- Bước 2: Kích hoạt WSL2 (Windows Subsystem for Linux) để chạy Linux container ổn định.
- Bước 3: Pull image
bkimminich/juice-shoptừ Docker Hub. - Bước 4: Chạy container và expose port 3000 (Mapping port).
- Bước 5: Truy cập ứng dụng qua trình duyệt tại
localhost:3000.
Kết luận: Quy trình trên mô phỏng chính xác cách một ứng dụng web được đóng gói và triển khai nhanh chóng (Deployment) giống như trong môi trường Cloud thực tế.
III. Phân tích lỗ hổng: SQL Injection
SQL Injection (SQLi) cho phép kẻ tấn công chèn câu lệnh SQL độc hại qua input form.
- Vị trí: Form Đăng nhập (Login) hoặc Tìm kiếm (Search).
- Nguyên nhân: Thiếu Input Validation và nối chuỗi SQL thủ công.
- Bản chất: Lỗi từ Code ứng dụng, KHÔNG phải lỗi Cloud.
IV. Tại sao lỗ hổng nguy hiểm hơn trên Cloud?
Nếu ứng dụng chạy Local, phạm vi ảnh hưởng chỉ giới hạn trong mạng nội bộ. Tuy nhiên, khi triển khai trên Public Cloud, ứng dụng ngay lập tức đối mặt với các botnet quét lỗ hổng tự động từ Internet toàn cầu 24/7, biến một lỗi nhỏ thành thảm họa lớn.
V. Giải pháp & Trách nhiệm chia sẻ
Các lớp bảo vệ Cloud
- Network: Security Groups, VPC.
- App Security: Web App Firewall (WAF).
- Monitoring: Cloud Logging & Alert.
Cloud không tạo ra lỗ hổng, Cloud chỉ khuếch đại hoặc giảm thiểu hậu quả của lỗ hổng tùy vào cách chúng ta cấu hình.
Bài học: Bảo mật là sự kết hợp giữa Secure Coding (Dev) + Secure Configuration (Ops).
LAB TUẦN 4: Monitoring & Logging trong An Toàn Cloud
Mục tiêu Lab 4
- Hiểu rõ vai trò của Monitoring và Logging trong hệ thống Cloud.
- Phân biệt bản chất, mục đích và cách sử dụng Monitoring vs Logging.
- Áp dụng vào giám sát website/app chạy trên Cloud.
- Liên hệ Monitoring & Logging với Incident Response thực tế.
I. Khái niệm cơ bản
Monitoring
Theo dõi liên tục trạng thái hệ thống theo thời gian thực thông qua metrics để phát hiện sớm bất thường và cảnh báo.
- Metrics: CPU, RAM, latency, error rate, throughput…
- Health check / uptime
- Alerting theo ngưỡng/baseline/anomaly
- Dashboard, SLO/SLA
Logging
Ghi lại các sự kiện đã xảy ra trong hệ thống để phục vụ truy vết, điều tra và kiểm toán.
- Application log, access log
- Authentication / audit log
- Security log (WAF, firewall)
- System / infrastructure log
II. So sánh Monitoring và Logging
| Tiêu chí | Monitoring | Logging |
|---|---|---|
| Dữ liệu | Metrics (time-series) | Events (bản ghi) |
| Câu hỏi trả lời | “Đang có vấn đề không?” | “Đã xảy ra chuyện gì?” |
| Mục tiêu | Cảnh báo sớm, vận hành | Điều tra, kiểm toán |
| Khối lượng | Nhẹ hơn | Lớn, tốn lưu trữ |
III. Đối tượng cần giám sát trong hệ thống Cloud
- Người dùng truy cập: RPS, user online, 4xx/5xx, IP/geo bất thường.
- Session: Số session hoạt động, multi-session, đổi IP/thiết bị.
- Login / Logout: Tỉ lệ fail, brute force, impossible travel.
- Request bất thường: Scan endpoint, WAF event, payload lạ.
- Lỗi hệ thống: 5xx, latency, DB timeout, crash/restart.
IV. Monitoring vs Logging cho từng đối tượng
| Đối tượng | Monitoring | Logging |
|---|---|---|
| User truy cập | RPS, 4xx/5xx, geo spikes | Access log (IP, UA, endpoint) |
| Session | Active sessions, anomalies | Session/Audit log |
| Login | Login fail rate | Auth log, MFA status |
| Request lạ | 401/403/404 spikes | WAF/Security log |
| Lỗi hệ thống | 5xx, latency | Error log, stack trace |
V. Phân tích theo tình huống thực tế
📌 Login fail tăng đột biến
Monitoring phát hiện spike → Logging điều tra IP/user.
📌 Điều tra ai truy cập lúc xảy ra sự cố
Logging là bắt buộc (access/auth/audit log).
📌 Tìm nguyên nhân lỗi hệ thống
Logging chỉ ra root cause, Monitoring khoanh vùng.
VI. Vai trò trong Incident Response
- Monitoring: Detect – cảnh báo sớm.
- Logging: Investigate – kết luận – cải tiến.
- Không có log → IR trở thành “chữa cháy mù”.
Monitoring cho bạn biết hệ thống đang gặp vấn đề.
Logging cho bạn biết ai gây ra vấn đề và bằng cách nào.
LAB TUẦN 5 – ỨNG PHÓ SỰ CỐ & TỔNG HỢP KẾT QUẢ
I. Giới thiệu chung
Trong môi trường điện toán đám mây, câu hỏi không còn là “có xảy ra sự cố an toàn hay không” mà là “khi nào xảy ra và hệ thống có đủ khả năng ứng phó hay không”. Lab Tuần 5 tập trung vào Incident Response (Ứng phó sự cố) – giai đoạn quan trọng nhằm phát hiện, phân tích, khoanh vùng, khắc phục sự cố và rút ra bài học cải thiện hệ thống.
Đây đồng thời là lab tổng hợp, liên kết toàn bộ kiến thức đã thực hiện trong 4 lab trước về cloud, IAM, OWASP và monitoring – logging.
II. Incident Response là gì?
Incident Response là một quy trình có tổ chức nhằm xử lý các sự cố an toàn thông tin, bao gồm việc phát hiện, giảm thiểu tác động, khôi phục hệ thống và ngăn chặn sự cố tái diễn.
Trong môi trường cloud, Incident Response đặc biệt quan trọng do hệ thống luôn public Internet, phạm vi ảnh hưởng rộng và tốc độ lan truyền sự cố rất nhanh.
III. Vai trò của Incident Response trong môi trường Cloud
| Đặc điểm môi trường cloud | Ảnh hưởng đến ứng phó sự cố |
|---|---|
| Tài nguyên co giãn, phân tán | Sự cố có thể lan nhanh nếu không phát hiện kịp thời |
| Truy cập từ Internet | Dễ bị tấn công từ xa, brute-force, scan lỗ hổng |
| Logging tập trung | Hỗ trợ phân tích và điều tra sự cố hiệu quả |
IV. Dấu hiệu cho thấy sự cố an toàn đang xảy ra
- Số lượng request tăng cao bất thường trong thời gian ngắn
- Nhiều lần đăng nhập thất bại liên tiếp
- Truy cập từ địa chỉ IP hoặc vị trí địa lý không quen thuộc
- Tài khoản đăng nhập thành công ngoài khung thời gian thông thường
- Hành vi truy cập không phù hợp với vai trò người dùng
V. Phân loại các sự cố an toàn có thể xảy ra
1. Lộ tài khoản (Credential Leakage)
- Nguyên nhân: mật khẩu yếu, reuse mật khẩu, phishing
- Hậu quả: kẻ tấn công truy cập hệ thống như người dùng hợp lệ
- Liên hệ Lab 2: Authentication, Authorization và IAM
2. Tấn công Brute-force
- Dấu hiệu: nhiều lần đăng nhập thất bại liên tiếp
- Mục tiêu: dò mật khẩu hoặc tài khoản hợp lệ
- Phát hiện thông qua monitoring và logging
3. Khai thác lỗ hổng ứng dụng
- Liên hệ Lab 3: OWASP Top 10
- Ví dụ: Broken Access Control, Injection
- Nguy hiểm hơn khi triển khai trên cloud do phạm vi ảnh hưởng rộng
VI. Tình huống sự cố giả định
Giả định hệ thống website của nhóm ghi nhận trong vòng 10 phút:
- Số lượng request tăng đột biến
- Hơn 50 lần đăng nhập thất bại
- Nhiều truy cập từ IP lạ
Monitoring giúp phát hiện lưu lượng bất thường, trong khi logging cho phép xác định tài khoản bị nhắm tới, thời điểm xảy ra và nguồn tấn công. Sự cố được phân loại là brute-force kết hợp dò tài khoản.
VII. Chu trình Incident Response theo NIST
- Preparation: Thiết lập IAM, logging, monitoring và chính sách truy cập
- Detection & Analysis: Phát hiện dấu hiệu và phân tích log
- Containment: Chặn IP, tạm khóa tài khoản nghi vấn
- Eradication: Vá lỗ hổng, thay đổi thông tin xác thực
- Recovery: Khôi phục dịch vụ và theo dõi hệ thống
- Lessons Learned: Đánh giá và cải thiện hệ thống
VIII. Vai trò của Monitoring và Logging trong ứng phó sự cố
Nếu không có monitoring và logging, hệ thống sẽ không thể phát hiện sớm sự cố, không xác định được nguyên nhân, thời điểm và đối tượng gây ra sự cố. Monitoring hỗ trợ phát hiện, trong khi logging là cơ sở cho điều tra và truy vết.
IX. Trách nhiệm trong môi trường Cloud (Shared Responsibility)
| Thành phần | Chủ thể chịu trách nhiệm |
|---|---|
| Hạ tầng vật lý | Nhà cung cấp cloud |
| Mạng, máy chủ | Nhà cung cấp cloud |
| IAM, cấu hình bảo mật | Người vận hành hệ thống |
| Ứng dụng, mã nguồn | Người phát triển |
X. Tổng hợp kết quả toàn bộ học phần
| Lab | Đóng góp vào an toàn hệ thống |
|---|---|
| Lab 1 | Nền tảng cloud, CDN và bề mặt tấn công |
| Lab 2 | Quản lý truy cập, IAM và Zero Trust |
| Lab 3 | Phát hiện và khắc phục lỗ hổng OWASP |
| Lab 4 | Monitoring, logging và phát hiện bất thường |
| Lab 5 | Ứng phó sự cố và tổng hợp toàn bộ kiến thức |
XI. Kết luận
Qua 5 lab, có thể thấy rằng an toàn điện toán đám mây không chỉ dừng lại ở việc triển khai công nghệ mà là một quy trình liên tục từ phòng ngừa, phát hiện, ứng phó đến cải thiện. Incident Response chính là bài kiểm tra thực tế cho toàn bộ hệ thống bảo mật cloud.