Chương 44. Firewall, WAF và network boundary

Ở các chương trước, ta đã nói về:

• Web security.
• Service-to-service security.
• Reverse proxy.
• Load balancer.
• API Gateway.
• CDN.

Chương này nói về ranh giới mạng:

Cái gì được public ra internet?
Cái gì chỉ được nằm trong private network?
Ai được gọi ai?
Request xấu bị chặn ở đâu?
Database có nên mở public không?
Worker có cần public endpoint không?

Các khái niệm chính:

• Firewall.
• Security group.
• WAF.
• Public network.
• Private network.
• Allowlist.
• Blocklist.
• DDoS protection.

Thông điệp chính của chương:

> Network security tốt bắt đầu từ việc giảm bề mặt public. Chỉ public những cửa thật sự cần, còn database, worker, queue, internal service nên private theo mặc định.

---

44.1. Ví dụ dễ hiểu: nhà có cửa chính, cửa kho và két

Một ngôi nhà có nhiều khu vực:

• Cửa chính.
• Phòng khách.
• Nhà bếp.
• Kho.
• Phòng ngủ.
• Két.

Không phải khu vực nào cũng mở ra đường.

Khách có thể vào cửa chính.

Nhưng không thể tự đi vào kho hoặc mở két.

Nếu thợ sửa nhà cần vào kho, bạn mở đúng lúc, đúng người, đúng cửa.

Hệ thống cũng vậy.

Không phải thành phần nào cũng nên public:

Public:
  CDN, load balancer, API gateway, web app entrypoint.

Private:
  database, queue, Redis, worker, internal service, admin-only endpoint.

Mở public càng nhiều, attacker càng có nhiều cửa thử.

---

44.2. Public network là gì?

Public network là phần có thể được truy cập từ internet.

Ví dụ:

https://app.example.com
https://api.example.com
https://cdn.example.com

Public endpoint cần được thiết kế để đối mặt với:

• User thật.
• Bot.
• Scanner.
• Attacker.
• Traffic spike.
• Request sai.
• Request độc.

Public không có nghĩa là không bảo mật.

Public nghĩa là:

Ai cũng có thể thử kết nối.

Vì vậy public surface phải càng nhỏ và càng được bảo vệ càng tốt.

---

44.3. Private network là gì?

Private network là phần chỉ các thành phần nội bộ được truy cập.

Ví dụ:

database.internal
redis.internal
queue.internal
worker subnet
internal-service.local

Private network thường nằm trong:

• VPC.
• Private subnet.
• Kubernetes cluster network.
• Internal service network.
• Docker network.

Ý tưởng:

Internet không gọi thẳng vào đây.

Private không có nghĩa là tuyệt đối an toàn.

Nhưng nó giảm bề mặt tấn công rất nhiều.

---

44.4. Network boundary là gì?

Network boundary là ranh giới giữa các vùng mạng.

Ví dụ:

Internet
-> CDN/WAF
-> Load balancer public
-> App private subnet
-> Database private subnet

Mỗi boundary nên có rule:

Ai được đi qua?
Đi đến đâu?
Port nào?
Protocol nào?

Không nên để mọi thứ nói chuyện với mọi thứ.

Một boundary rõ giúp:

• Giảm rủi ro khi một service bị hack.
• Dễ audit.
• Dễ debug.
• Dễ thiết kế least privilege.

---

44.5. Firewall là gì?

Firewall là lớp kiểm soát traffic mạng.

Nó quyết định:

Cho phép hay chặn kết nối dựa trên IP, port, protocol, direction.

Ví dụ:

Allow inbound TCP 443 từ internet đến load balancer.
Allow app server kết nối PostgreSQL port 5432.
Deny internet kết nối database port 5432.

Firewall thường làm việc ở tầng mạng/transport.

Nó không hiểu sâu:

Đây có phải SQL injection không?
Đây có phải XSS không?
User này có quyền xem submission này không?

Đó là việc của WAF/app/security logic.

Firewall trả lời câu hỏi:

Kết nối này có được phép đi qua không?

---

44.6. Security group là gì?

Trong cloud, security group là firewall gắn với resource.

Ví dụ:

• EC2 instance.
• Load balancer.
• Database.
• Redis.
• Kubernetes node.

Security group định nghĩa inbound/outbound rule.

Ví dụ:

Load balancer SG:
  inbound 443 from 0.0.0.0/0
  outbound 8000 to app SG

App SG:
  inbound 8000 from load balancer SG
  outbound 5432 to database SG

Database SG:
  inbound 5432 from app SG only

Điểm hay:

Cho phép theo security group, không chỉ IP.

Ví dụ:

Database chỉ nhận từ App SG.

Nếu app server IP thay đổi, rule vẫn đúng.

---

44.7. Inbound và outbound

Inbound là traffic đi vào resource.

Outbound là traffic đi ra khỏi resource.

Ví dụ database:

Inbound:
  App server kết nối vào PostgreSQL.

Outbound:
  Database có cần gọi ra internet không?
  Thường là không hoặc rất hạn chế.

Nhiều hệ thống chỉ kiểm soát inbound, bỏ qua outbound.

Nhưng outbound cũng quan trọng.

Nếu một service bị hack, outbound rộng có thể cho attacker:

• Gửi dữ liệu ra ngoài.
• Gọi server độc.
• Dò internet.
• Tải payload.

Không phải lúc nào cũng cần khóa outbound cực chặt từ đầu.

Nhưng với môi trường nhạy cảm, outbound policy rất đáng quan tâm.

---

44.8. WAF là gì?

WAF là Web Application Firewall.

Nó đứng trước web app/API và phân tích request HTTP.

WAF có thể chặn:

• SQL injection pattern.
• XSS pattern.
• Path traversal.
• Bot/scanner phổ biến.
• Request bất thường.
• Một số exploit known CVE.
• Bad IP reputation.

Ví dụ:

GET /search?q=' OR 1=1 --

WAF có thể nhận ra pattern SQL injection và chặn.

WAF hoạt động ở tầng ứng dụng HTTP.

Nó hiểu request web hơn firewall mạng.

---

44.9. WAF khác firewall ở đâu?

Firewall:

IP nào, port nào, protocol nào được kết nối?

WAF:

Request HTTP này có dấu hiệu tấn công web không?

Ví dụ:

Firewall có thể nói:

Internet được gọi HTTPS 443 vào load balancer.

WAF có thể nói:

Request HTTPS này chứa XSS payload, chặn.

Hai thứ bổ sung nhau.

Không nên thay thế nhau.

---

44.10. WAF không thay thế code an toàn

WAF có ích, nhưng không được dùng để biện minh cho code yếu.

Vẫn phải:

• Dùng parameterized query.
• Escape/sanitize output.
• Kiểm tra permission.
• Validate input.
• Chống CSRF.
• Bảo vệ file upload.
• Rate limit.

WAF có thể chặn nhiều payload phổ biến.

Nhưng attacker có thể né WAF.

Và WAF có thể false negative/false positive.

Tư duy đúng:

> WAF là lớp phòng thủ bổ sung, không phải giấy phép viết code bất cẩn.

---

44.11. Allowlist là gì?

Allowlist là danh sách thứ được phép.

Ví dụ:

Chỉ IP văn phòng được vào admin panel.
Chỉ App SG được kết nối database.
Chỉ domain app.example.com được CORS.
Chỉ service grading-worker được gọi internal grading endpoint.

Allowlist thường an toàn hơn blocklist.

Vì mặc định:

Không nằm trong danh sách thì không được.

Phù hợp với:

• Admin endpoint.
• Database access.
• Internal service.
• Webhook provider IP nếu ổn định.
• Private API.

---

44.12. Blocklist là gì?

Blocklist là danh sách thứ bị chặn.

Ví dụ:

Chặn IP spam.
Chặn country nếu cần.
Chặn user agent độc.
Chặn path scan phổ biến.

Blocklist hữu ích để phản ứng với abuse.

Nhưng không đủ làm chiến lược chính.

Vì attacker có thể đổi IP, user agent, pattern.

Tư duy:

Với tài nguyên nhạy cảm:
  allowlist.

Với abuse rộng:
  blocklist có thể hỗ trợ.

---

44.13. Database không nên public

Một lỗi rất nguy hiểm:

Database mở port public ra internet.

Ví dụ:

PostgreSQL 5432 open to 0.0.0.0/0

Dù có password, đây vẫn là rủi ro lớn.

Bot có thể scan và brute force.

Lỗ hổng database có thể bị khai thác.

Sai config có thể lộ dữ liệu.

Đúng hơn:

Database nằm private.
Chỉ app server / migration runner / bastion / VPN được kết nối.

Production database không nên là public endpoint cho cả internet.

---

44.14. Redis/queue cũng không nên public

Không chỉ database.

Các thành phần sau cũng không nên public:

• Redis.
• RabbitMQ.
• Kafka.
• Elasticsearch/OpenSearch.
• Internal admin UI.
• Metrics endpoint.
• Worker dashboard.
• Object storage private bucket.

Redis public không auth hoặc auth yếu là thảm họa.

Queue public có thể bị spam job.

Search public có thể lộ dữ liệu.

Metrics public có thể lộ thông tin hệ thống.

Quy tắc:

> Thành phần hạ tầng nội bộ không nên có mặt trực tiếp trên internet trừ khi có lý do rất rõ và bảo vệ rất chặt.

---

44.15. Worker có cần public không?

Thông thường:

Không.

Worker nên lấy job từ queue.

Worker không cần nhận request từ internet.

Ví dụ AI Judge:

API nhận submission.
API tạo GradingJob trong queue.
Worker đọc queue và chấm.

Không cần:

Internet -> grading-worker

Nếu worker có endpoint metrics/health/admin, endpoint đó nên private hoặc bảo vệ chặt.

Worker public là bề mặt tấn công không cần thiết.

---

44.16. Admin panel có nên public không?

Tùy.

Admin panel public nhưng có auth/MFA tốt có thể chấp nhận trong nhiều sản phẩm.

Nhưng admin nhạy cảm nên cân nhắc thêm:

• IP allowlist.
• VPN.
• SSO.
• MFA bắt buộc.
• WAF/rate limit.
• Audit log.
• Separate domain.
• Strong session policy.

Ví dụ:

admin.example.com

không nên chỉ dựa vào:

URL khó đoán.

Security by obscurity không đủ.

---

44.17. Bastion host là gì?

Bastion host là máy trung gian để admin truy cập private network.

Ví dụ:

Developer -> Bastion -> Database private

Thay vì mở database public, bạn chỉ cho bastion/VPN truy cập.

Bastion cần bảo vệ kỹ:

• SSH key/MFA.
• IP allowlist.
• Audit login.
• Không dùng chung account.
• Patch thường xuyên.
• Least privilege.

Ngày nay nhiều cloud có lựa chọn thay thế như:

• Session Manager.
• Cloud SQL Auth Proxy.
• IAM database auth.
• VPN/Zero Trust access.

Ý chính:

> Truy cập admin vào private resource nên đi qua đường kiểm soát, không mở thẳng ra internet.

---

44.18. VPN và zero trust access

VPN cho phép người dùng được cấp quyền vào private network.

Zero trust access hiện đại hơn ở chỗ:

• Xác thực identity.
• Kiểm tra device.
• Policy theo app/resource.
• Audit.
• Không mở toàn mạng nếu không cần.

Ví dụ:

Chỉ engineer on-call được vào database admin tool.
Chỉ trong 2 giờ.
Có MFA.
Có audit.

Không phải team nhỏ nào cũng cần hệ thống phức tạp.

Nhưng nếu có dữ liệu nhạy cảm, truy cập admin nên được quản lý nghiêm túc.

---

44.19. DDoS là gì?

DDoS là Distributed Denial of Service.

Nghĩa là rất nhiều traffic từ nhiều nguồn làm hệ thống không phục vụ được user thật.

DDoS có nhiều dạng:

• Flood băng thông.
• Flood connection.
• HTTP request flood.
• Bot gọi endpoint tốn tài nguyên.

CDN/WAF/load balancer có thể giúp hấp thụ/chặn một phần.

Nhưng app cũng cần:

• Rate limit.
• Cache.
• Queue.
• Timeout.
• Không để endpoint quá tốn tài nguyên public.

DDoS protection không chỉ là mua một dịch vụ.

Nó là thiết kế giảm chi phí xử lý request xấu.

---

44.20. Origin protection

Nếu dùng CDN/WAF nhưng origin vẫn public, attacker có thể bypass CDN.

Ví dụ:

User bình thường:
  Internet -> CDN/WAF -> Origin

Attacker:
  Internet -> Origin trực tiếp

Nếu origin IP lộ và firewall cho mọi IP gọi, CDN/WAF bị né.

Cách bảo vệ:

• Origin chỉ allow IP của CDN/load balancer.
• App server private.
• Security group chỉ nhận từ LB.
• Không expose origin DNS public nếu không cần.
• Verify header/token từ CDN nếu phù hợp.

CDN/WAF tốt hơn khi origin không thể bị gọi thẳng dễ dàng.

---

44.21. Public API endpoint cần gì?

Public API nên đi qua:

CDN/WAF nếu phù hợp
-> Load balancer/API Gateway
-> App service private

Cần:

• HTTPS.
• Auth.
• Rate limit.
• WAF/rules nếu cần.
• Request size limit.
• Logging.
• Monitoring.
• Permission ở app.
• Origin protection.

Không nên:

Internet -> app server process trực tiếp -> database

trừ khi là setup nhỏ có bảo vệ rất rõ.

Ngay cả app nhỏ cũng nên có reverse proxy/load balancer hoặc platform router phía trước.

---

44.22. Private service-to-service endpoint

Endpoint nội bộ nên:

• Không public.
• Chỉ service cần thiết gọi được.
• Có service authentication nếu nhạy cảm.
• Có network policy/security group.
• Có audit nếu đọc/ghi dữ liệu nhạy cảm.

Ví dụ:

Grading Service gọi Submission Service để lấy file.

Không nên để endpoint này public internet.

Nếu phải expose vì kiến trúc nào đó, phải bảo vệ như public API:

• Strong auth.
• Rate limit.
• WAF nếu HTTP.
• Audit.
• Scope.

Nhưng mặc định nên private.

---

44.23. Kubernetes NetworkPolicy

Trong Kubernetes, pod thường có thể nói chuyện với nhau nếu không cấu hình hạn chế.

NetworkPolicy cho phép kiểm soát:

Pod nào được gọi pod nào?
Port nào?
Namespace nào?

Ví dụ:

Only api pods can connect to database proxy.
Only grading-worker pods can connect to sandbox service.
Notification worker cannot connect to submission file service.

Không phải mọi team cần NetworkPolicy từ ngày đầu.

Nhưng trong hệ thống nhiều service, nó giúp giảm lateral movement.

Kubernetes không tự động an toàn chỉ vì chạy trong cluster.

---

44.24. Docker network ở local không giống production

Docker Compose có network nội bộ.

Ví dụ:

web
db
redis
worker

Các service có thể gọi nhau bằng tên.

Nhưng nếu bạn publish port database ra host:

5432:5432

thì database có thể được truy cập từ ngoài máy tùy cấu hình firewall.

Local thì tiện.

Production cần cẩn thận:

• Port nào publish?
• Port nào chỉ internal?
• Container nào có network access?
• Secret nào mount vào đâu?

Container network không tự giải quyết security.

---

44.25. Egress control

Egress là traffic đi ra ngoài.

Ví dụ worker gọi:

• AI provider.
• Object storage.
• Email provider.
• Payment provider.

Nếu egress mở toàn bộ, service bị hack có thể gửi dữ liệu ra bất kỳ đâu.

Egress control có thể:

• Allowlist domain/IP cần gọi.
• Dùng NAT gateway/log.
• Chặn metadata service nếu không cần.
• Giới hạn service nào được ra internet.

Với AI Judge:

Grading worker có thể cần gọi AI provider.
Notification worker cần gọi email provider.
Database không cần gọi internet.

Không phải service nào cũng cần outbound giống nhau.

---

44.26. Metadata service protection

Cloud VM/container đôi khi có metadata service.

Nó có thể cấp credential tạm thời cho workload.

Ví dụ địa chỉ kiểu:

169.254.169.254

Nếu app có SSRF, attacker có thể cố gọi metadata service để lấy credential.

Cần bảo vệ:

• Chặn SSRF.
• Cấu hình metadata service version an toàn nếu cloud hỗ trợ.
• Giới hạn IAM role của workload.
• Không cấp role quá rộng.
• Egress policy nếu có thể.

Đây là lý do SSRF nguy hiểm hơn chỉ là "server gọi URL lạ".

Nó có thể dẫn tới cloud credential leak.

---

44.27. WAF false positive và false negative

WAF không hoàn hảo.

False positive:

Request hợp lệ bị chặn.

Ví dụ học sinh nộp đoạn code có chuỗi giống SQL injection.

WAF tưởng là attack.

False negative:

Request độc lọt qua.

Vì vậy WAF cần:

• Monitor.
• Chế độ report/log trước khi block mạnh.
• Rule tuning.
• Bypass/exception có kiểm soát.
• Không thay thế validation ở app.

Với AI Judge, user có thể upload/code text chứa pattern lạ.

WAF cần cấu hình để không chặn nhầm payload hợp lệ, đặc biệt ở endpoint upload/submission.

---

44.28. Rate limiting ở edge

Rate limit có thể đặt ở nhiều nơi:

• CDN/WAF.
• API Gateway.
• App.
• Service nội bộ.

Edge rate limit tốt để chặn sớm:

Login brute force.
Request flood.
Bot scan.
Upload abuse.

Nhưng quota nghiệp vụ vẫn cần app:

Tenant này được chấm bao nhiêu bài/tháng?
User này có còn quota storage không?

Edge không luôn có đủ context nghiệp vụ.

Kết hợp mới đúng.

---

44.29. Network security vừa đủ cho app nhỏ

Một app nhỏ không cần hạ tầng phức tạp ngay.

Nhưng nên có tối thiểu:

Internet
-> CDN/WAF hoặc load balancer/reverse proxy
-> App server
-> Database private hoặc chỉ allow app/admin path
-> Object storage

Các nguyên tắc:

• App public qua HTTPS.
• Database không mở public toàn internet.
• Redis/queue không public.
• Admin endpoint bảo vệ kỹ.
• Secret không nằm trong code.
• SSH/admin access giới hạn.
• Backup có.
• Firewall/security group rõ.

Đây là mức "vừa đủ mà tử tế".

Không cần Kubernetes/mesh mới gọi là production.

---

44.30. Network security cho hệ thống lớn hơn

Khi hệ thống lớn hơn:

Internet
-> CDN/WAF/DDoS protection
-> Public load balancer/API Gateway
-> Private app subnets
-> Private data subnets
-> Worker subnets
-> Managed services

Thêm:

• Security group theo service.
• Private database.
• Private Redis/queue.
• NetworkPolicy nếu Kubernetes.
• Egress control.
• Service-to-service auth.
• Central logging.
• Audit.
• VPN/zero trust admin access.
• Origin protection.

Mục tiêu:

Nếu một service bị compromise, attacker không tự do đi khắp hệ thống.

---

44.31. AI Judge: network boundary đề xuất

Với AI Judge:

Public:

CDN/WAF
Load balancer/API Gateway
Frontend static assets
Public API endpoints

Private:

Database
Redis/queue
Worker
Object storage private bucket/origin
Internal admin tools
Metrics endpoint
Grading sandbox

Allowed flows:

Browser -> CDN/LB -> API
API -> Database
API -> Queue
API -> Object storage presign
Worker -> Queue
Worker -> Object storage
Worker -> AI provider
Worker -> Database/result service

Blocked by default:

Internet -> Database
Internet -> Queue
Internet -> Worker
Internet -> Redis
Internet -> internal metrics

Đây là boundary cơ bản nhưng rất mạnh.

---

44.32. AI Judge: endpoint upload/code cần cẩn thận

AI Judge có thể nhận:

• Zip bài làm.
• Code text.
• PDF.
• Ảnh.
• Prompt/rubric.

Những payload này có thể chứa pattern khiến WAF hiểu nhầm.

Ví dụ code bài làm có:

SELECT * FROM users WHERE ...
<script>
../../path

Đó có thể là bài làm hợp lệ, không phải request attack.

Vì vậy:

• WAF cần rule phù hợp theo endpoint.
• File upload nên qua object storage/presigned URL nếu lớn.
• App/worker vẫn phải sandbox/validate.
• Không tắt toàn bộ bảo mật vì false positive một lần.

Bảo mật phải hiểu ngữ cảnh sản phẩm.

---

44.33. AI Judge: không để sandbox có secret rộng

Nếu hệ thống chạy code user trong sandbox:

Sandbox không nên có:

• Database credential.
• AI provider key.
• Object storage full access.
• Internal network rộng.
• Metadata service access.
• Production secret.

Sandbox nên:

• Network disabled hoặc rất hạn chế.
• CPU/memory/time limit.
• Filesystem tạm.
• User quyền thấp.
• Cleanup sau chạy.

Đây vừa là security, vừa là network boundary.

Code user không tin cậy không được đứng cùng vùng quyền với service thật.

---

44.34. Những lỗi phổ biến

Lỗi 1:

Database mở public vì "để dễ connect".

Lỗi 2:

Redis/queue public hoặc password yếu.

Lỗi 3:

App server public trực tiếp, bypass CDN/WAF.

Lỗi 4:

Origin vẫn nhận mọi IP dù đã dùng CDN.

Lỗi 5:

Internal endpoint không auth và vẫn reachable từ internet.

Lỗi 6:

Security group mở 0.0.0.0/0 cho port admin.

Lỗi 7:

WAF bật block mạnh nhưng không monitor false positive.

Lỗi 8:

Worker/sandbox có secret quá rộng.

Lỗi 9:

Không kiểm soát outbound, service bị hack gửi dữ liệu ra ngoài dễ dàng.

Lỗi 10:

Tin private network tuyệt đối nên bỏ service auth.

---

44.35. Checklist network security

Hỏi:

• Endpoint nào thật sự cần public?
• Database có public không?
• Redis/queue/search có public không?
• App server có bị bypass CDN/LB không?
• Origin có chỉ nhận từ CDN/LB không?
• Admin endpoint có MFA/IP allowlist/VPN không?
• Security group mở port nào?
• Rule 0.0.0.0/0 có thật sự cần không?
• Worker có public endpoint không?
• Metrics/debug endpoint có bị public không?
• Service nội bộ có auth không?
• Egress từ service có cần giới hạn không?
• WAF có bật report/monitor không?
• WAF có chặn nhầm endpoint upload/code không?
• DDoS/rate limit ở edge có chưa?
• Nếu một service bị hack, attacker đi tiếp được đến đâu?

Checklist này giúp nhìn hệ thống như một bản đồ cửa ra vào.

---

44.36. Bảng chọn nhanh

| Thành phần | Nên public không? | Ghi chú | |---|---:|---| | CDN | Có | Cửa gần user, cache/bảo vệ | | Load balancer/API Gateway | Có | Public entrypoint chính | | App server | Thường không trực tiếp | Nên sau LB/proxy | | Database | Không | Chỉ app/admin path được phép | | Redis | Không | Rất nguy hiểm nếu public | | Queue | Không | Chỉ worker/app cần | | Worker | Không | Đọc queue, không nhận internet | | Metrics/debug | Không public | Bảo vệ bằng VPN/auth | | Object storage public bucket | Chỉ cho public asset | File private dùng signed URL/private bucket | | Admin panel | Tùy | MFA, audit, IP/VPN nếu nhạy cảm | | WAF | Public edge | Chặn pattern web attack, cần tuning |

---

44.37. Tóm tắt bằng AI Judge

Với AI Judge, public surface nên là:

Frontend/CDN
API qua Load Balancer/API Gateway
Webhook endpoint được bảo vệ

Những thứ không nên public:

PostgreSQL
Redis/queue
Worker
Grading sandbox
Internal service endpoint
Metrics/debug endpoint
Private object storage

Network rule nên theo hướng:

Internet chỉ vào cửa public.
App mới vào database/queue.
Worker mới đọc queue và gọi AI provider/object storage.
Sandbox không có secret và không đi lung tung trong mạng.

WAF/CDN giúp chặn một phần traffic xấu, nhưng app vẫn phải:

validate input
check permission
rate limit
sandbox file/code
audit action nhạy cảm

Không có một lớp nào gánh hết bảo mật.

---

44.38. Kết luận của chương

Firewall, security group, WAF và network boundary giúp hệ thống giảm bề mặt tấn công.

Firewall/security group kiểm soát kết nối theo IP/port/protocol.

WAF kiểm tra request HTTP để chặn một số mẫu tấn công web.

Public network là nơi ai cũng có thể thử gọi.

Private network là nơi chỉ thành phần được phép nên đi vào.

Thông điệp cần nhớ:

> Public càng ít càng tốt. Private theo mặc định. Chỉ mở đúng cửa, đúng người, đúng port, đúng lý do.

Ở chương tiếp theo, ta sẽ nói về Docker và container: container giải quyết vấn đề "máy tôi chạy được" như thế nào, image/container/volume/network là gì, Docker Compose dùng khi nào, và vì sao container không làm app tự scale.