Giới thiệu dự án

Sự chuyển dịch từ kiến trúc nguyên khối (Monolithic) sang kiến trúc vi dịch vụ (Microservices) đang là xu hướng tất yếu trong kỷ nguyên số. Theo các khảo sát an ninh mạng quốc tế, hơn 80% lưu lượng ứng dụng hiện nay luân chuyển qua giao diện lập trình ứng dụng (API), kéo theo sự bùng nổ của các cuộc tấn công mạng nhắm trực tiếp vào các giao thức phân tán (theo OWASP API Security Top 10).

Khác với hệ thống nguyên khối truyền thống nơi các giao tiếp nằm gọn trong bộ nhớ cục bộ, kiến trúc Microservices mở rộng đáng kể bề mặt tấn công (attack surface) do sự gia tăng số lượng cổng kết nối mạng, các điểm cuối (API endpoints) và cơ chế định tuyến phân tán. Trong bối cảnh đó, các nền tảng tuyển dụng và tìm việc làm trực tuyến – nơi lưu trữ khối lượng lớn dữ liệu nhạy cảm bao gồm sơ yếu lý lịch (CV), thông tin định danh cá nhân (PII), lịch sử việc làm và dữ liệu doanh nghiệp – trở thành mục tiêu hàng đầu của tội phạm mạng.

+-----------------------------------------------------------------------------------+
|                              BỀ MẶT TẤN CÔNG API                                  |
|                                                                                   |
|  [Client Web/Mobile]                                                              |
|          │                                                                        |
|          ▼                                                                        |
|  [ API Gateway: Kong ] ── (Key Auth / Rate Limiting / CORS / IP Whitelist)        |
|          │                                                                        |
|    ┌─────┴──────────────────┬──────────────────────┐                              |
|    ▼                        ▼                      ▼                              |
| [Auth Service]        [Job Service]          [User Service]                       |
|   (JWT / OAuth2)        (Search / Filter)      (Profile / CV)                     |
|    │                        │                      │                              |
|    ▼                        ▼                      ▼                              |
| (Redis Cache)         (MongoDB Engine)       (MySQL Relational)                   |
+-----------------------------------------------------------------------------------+

Vấn đề thực tế (Problem Statement)

Các hệ thống tuyển dụng trực tuyến phát triển theo mô hình Microservices thường xuyên đối mặt với các lỗ hổng bảo mật nghiêm trọng:

  • Xác thực và phân quyền yếu (Broken Object Level Authorization & Authentication): Các vi dịch vụ thiếu cơ chế xác thực tập trung, cho phép tin tặc khai thác cơ chế kiểm tra token lỏng lẻo để leo thang đặc quyền.
  • Tiêm mã độc (Injection Attacks): Các truy vấn cơ sở dữ liệu (SQL Injection) và chèn mã kịch bản phía máy khách (Cross-Site Scripting - XSS) xuất hiện tại các trường nhập liệu tìm kiếm việc làm, đăng ký tài khoản và nộp hồ sơ.
  • Tấn công vét cạn và từ chối dịch vụ (Brute-Force & Denial of Service - DoS): Thiếu kiểm soát tần suất truy vấn (Rate Limiting) trên từng endpoint khiến hệ thống dễ bị tê liệt bởi lượng request đột biến hoặc bị tấn công đoán mật khẩu/khóa API.
  • Khó khăn trong giám sát và duy trì tính nhất quán: Kiến trúc đa ngôn ngữ (Polyglot) khiến việc áp dụng quy chuẩn bảo mật đồng nhất giữa các nhóm phát triển gặp nhiều cản trở.

Mục tiêu dự án

  1. Nghiên cứu toàn diện các lỗ hổng bảo mật đặc thù và các kỹ thuật tấn công phổ biến trên kiến trúc Microservices.
  2. Đánh giá và triển khai cổng kết nối tập trung Kong API Gateway v3.2 nhằm thiết lập lá chắn bảo vệ, quản lý định tuyến, xác thực và kiểm soát lưu lượng.
  3. Nghiên cứu, vận hành quy trình kiểm thử bảo mật đa lớp sử dụng các bộ công cụ chuyên sâu: Pact (kiểm thử tương thích hợp đồng), Apache JMeter v5.5 (kiểm thử hiệu năng, tải và tính đáp ứng), Burp Suite Professional v2023 và Invicti / Acunetix (kiểm thử thâm nhập, dò quét lỗ hổng DAST).
  4. Áp dụng thực nghiệm vào Hệ thống tìm việc làm, mô phỏng các kịch bản tấn công thực tế và đánh giá hiệu năng phòng thủ của hệ thống.

Phương pháp tiếp cận và kết quả kỳ vọng

Dự án kết hợp giữa phòng thủ chủ động (xây dựng kiến trúc API Gateway với các chính sách bảo mật nghiêm ngặt) và tấn công thử nghiệm (Penetration Testing / DAST). Kết quả kỳ vọng là xây dựng thành công quy trình đánh giá an toàn thông tin khép kín, phát hiện 100% các lỗ hổng nghiêm trọng (P1/P2) trước khi đưa vào vận hành, đồng thời đảm bảo hiệu năng xử lý với độ trễ phản hồi dưới 120ms ở mức tải 500 yêu cầu đồng thời.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Kiến trúc phần mềm trải qua các giai đoạn chuyển biến cấu trúc từ Monolithic đến Service Mesh:

Tiêu chí Monolithic Architecture Microservices (với API Gateway) Service Mesh (Envoy/Istio)
Bề mặt tấn công Hẹp, tập trung tại 1 cổng vào duy nhất Mở rộng qua các REST/HTTP endpoints Kiểm soát nghiêm ngặt qua mTLS sidecar
Cơ chế xác thực Session-based tập trung trên RAM/DB Token-based (JWT/OAuth2) tại Gateway mTLS phân tán + SPIFFE ID
Khả năng mở rộng Kém, nâng cấp toàn bộ hệ thống Rất cao, mở rộng độc lập từng service Rất cao nhưng phức tạp
Độ phức tạp kiểm thử Đơn giản, kiểm thử hộp đen/trắng dễ dàng Phức tạp, cần kiểm thử hợp đồng và API Rất phức tạp, cần kiểm thử lưới mạng
Chi phí vận hành Thấp Trung bình Rất cao

So sánh các công cụ kiểm thử bảo mật ứng dụng web và API:

Công cụ Loại kiểm thử Điểm mạnh Hạn chế
Burp Suite Professional DAST / Penetration Testing Tùy biến payload linh hoạt với Intruder/Repeater, engine phân tích API mạnh Cần kỹ năng chuyên sâu của Tester
Invicti (Acunetix) DAST tự động Quét tự động chính xác, giảm thiểu False Positive nhờ Proof-Based Scanning Bản quyền thương mại cao
Pact Framework Contract Testing Đảm bảo tính tương thích giao tiếp giữa Consumer và Provider Không kiểm tra logic bảo mật nội tại
Apache JMeter Load / Performance Testing Mô phỏng hàng nghìn luồng đồng thời, phân tích QPS và độ trễ chuẩn xác Giao diện cấu hình phức tạp

Phân loại yêu cầu hệ thống theo mô hình MoSCoW:

  • Must Have (Bắt buộc): Lớp xác thực API Key / JWT tại Gateway; Cơ chế Rate Limiting ngăn chặn brute-force; Ngăn chặn triệt để SQL Injection và XSS trên mọi endpoints; Kiểm thử tương thích dữ liệu JSON.
  • Should Have (Nên có): Lọc địa chỉ IP (IP Whitelisting/Blacklisting); Kiểm soát nguồn gốc tài nguyên chéo (CORS); Tự động hóa kịch bản kiểm thử tải với Apache JMeter.
  • Could Have (Có thể có): Tích hợp kiểm thử vào đường ống CI/CD (Jenkins / GitLab CI); Bảng điều khiển giám sát tập trung qua Prometheus/Grafana.
  • Won't Have (Chưa thực hiện): Triển khai Service Mesh toàn phần với proxy sidecar cho từng container nội bộ.

Thiết kế hệ thống

Kiến trúc bảo mật hệ thống bao gồm 3 lớp chính:

  1. Lớp khách (Client Tier): Trình duyệt web và ứng dụng di động gửi yêu cầu qua giao thức an toàn HTTPS.
  2. Lớp cổng trung gian (Gateway Tier - Kong Gateway): Đóng vai trò Reverse Proxy và bộ lọc an ninh. Thực hiện giải mã SSL, kiểm tra xác thực (Key Auth / OAuth2+JWT), giới hạn tốc độ truy vấn (Rate Limiting với Redis backend), kiểm tra CORS và phân phối tải tới các dịch vụ phía sau.
  3. Lớp dịch vụ nghiệp vụ (Microservices Backend Tier):
    • Auth Service: Xử lý đăng ký, đăng nhập, phát hành JWT.
    • Job Service: Xử lý đăng tin, tìm kiếm, duyệt bài tuyển dụng (kết nối MongoDB).
    • User Service: Quản lý thông tin ứng viên, tải lên hồ sơ CV (kết nối MySQL).
# Cấu hình dịch vụ và bảo mật trên Kong API Gateway (declarative kong.yml)
_format_version: "3.0"
services:
  - name: user-service
    url: http://user-backend:8081/api/v1/users
    routes:
      - name: user-routes
        paths:
          - /users
        strip_path: true
    plugins:
      - name: key-auth
        config:
          key_names: [apikey, X-API-Key]
      - name: rate-limiting
        config:
          minute: 60
          policy: redis
          redis_host: redis-cache
          redis_port: 6379
          fault_tolerant: true
  - name: job-service
    url: http://job-backend:8082/api/v1/jobs
    routes:
      - name: job-routes
        paths:
          - /jobs
        strip_path: true
    plugins:
      - name: cors
        config:
          origins:
            - "https://jobportal.local"
          methods: [GET, POST, PUT, DELETE]
          headers: [Accept, Content-Type, Authorization, X-API-Key]

Technology Stack & Versions

  • Nền tảng Gateway: Kong API Gateway v3.2.x (Open-source Edition trên nền tảng NGINX/OpenResty).
  • Bộ nhớ đệm & Kiểm soát luồng: Redis v7.0 Cluster.
  • Hệ cơ sở dữ liệu: MySQL v8.0 (Quan hệ - Quản lý tài khoản), MongoDB v6.0 (Phi quan hệ - Quản lý tin tuyển dụng).
  • Môi trường ảo hóa: Docker Engine v24.0.5 & Docker Compose v2.20.
  • Công cụ kiểm thử: Burp Suite Professional v2023.3, Apache JMeter v5.5, Invicti Web Application Scanner, Pact Framework v4.3 (Java/Node.js).

Phương pháp luận (Methodology)

Quy trình kiểm thử được triển khai theo mô hình kiểm thử bảo mật lặp vòng 7 bước chuẩn mực:

  1. Xác định phạm vi & Thu thập thông tin: Lập bản đồ toàn bộ API endpoints (User, Auth, Job APIs).
  2. Phân tích mô hình đe dọa (Threat Modeling): Nhận diện các điểm rủi ro tại Gateway và nội bộ vi dịch vụ.
  3. Kiểm thử tương thích (Contract Testing): Sử dụng Pact để xác thực cấu trúc dữ liệu JSON Request/Response.
  4. Kiểm thử hiệu năng & Tính đáp ứng: Chạy kịch bản tải bằng JMeter để xác định ngưỡng sụp đổ và hiệu lực của Rate Limiting.
  5. Kiểm thử an ninh DAST: Sử dụng Invicti và Burp Suite để dò quét lỗ hổng SQLi, XSS, IDOR, Broken Authentication.
  6. Phân tích kết quả & Vá lỗi: Tinh chỉnh cấu hình Gateway, bổ sung Input Sanitization tại tầng mã nguồn.
  7. Kiểm thử hồi quy (Regression Testing): Tái kiểm thử để đảm bảo lỗ hổng đã được khắc phục hoàn toàn.

Implementation và kết quả

Quá trình phát triển và kiểm thử

1. Kiểm thử tính tương thích với Pact Framework

Thiết lập tệp hợp đồng (Pact contract) giữa Consumer (Frontend Web) và Provider (Job Service) để cố định cấu trúc schema dữ liệu tuyển dụng:

{
  "consumer": { "name": "JobSeeker-Frontend" },
  "provider": { "name": "Job-Microservice" },
  "interactions": [
    {
      "description": "Yêu cầu lấy chi tiết công việc theo ID",
      "request": {
        "method": "GET",
        "path": "/api/v1/jobs/101",
        "headers": { "Accept": "application/json" }
      },
      "response": {
        "status": 200,
        "headers": { "Content-Type": "application/json; charset=utf-8" },
        "body": {
          "jobId": 101,
          "title": "Chuyên viên An toàn thông tin",
          "salary": "Thỏa thuận",
          "status": "OPEN"
        }
      }
    }
  ]
}

2. Kịch bản kiểm thử tấn công SQL Injection bằng Burp Suite

Tại điểm cuối tìm kiếm công việc /api/v1/users/search?keyword=, dữ liệu truyền vào tham số keyword không được lọc hợp thức hóa (Input Validation) trước khi đưa vào câu lệnh truy vấn SQL phía Backend:

GET /api/v1/users/search?keyword='+UNION+SELECT+id,username,password_hash,email+FROM+users-- HTTP/1.1
Host: api.jobportal.local
User-Agent: Mozilla/5.0
Accept: application/json

Thực thi tấn công: Dữ liệu trả về từ máy chủ chứa mã trạng thái HTTP/1.1 200 OK kèm theo toàn bộ bảng danh sách người dùng và chuỗi băm mật khẩu. Lỗ hổng sau đó được ghi nhận và khắc phục triệt để bằng việc chuyển đổi các câu lệnh ghép chuỗi sang cơ chế tham số hóa dữ liệu (Prepared Statements / Parameterized Queries) kết hợp ORM.

+-----------------------------------------------------------------------------------+
|               QUY TRÌNH KIỂM THỬ BẢO MẬT VỚI BURP SUITE & JMETER                  |
|                                                                                   |
|  [ Burp Intruder ] ──────► Payload 1: user_list.txt (500 entries)                 |
|                            Payload 2: rockyou_top100.txt (100 entries)            |
|                            Tấn công Brute-Force Endpoint /api/v1/auth/login       |
|                            Kết quả: Tìm thấy mật khẩu tại Request #976 (HTTP 200) |
|                                                                                   |
|  [ Apache JMeter ] ──────► Thread Group: 500 Users đồng thời (Ramp-up 10s)        |
|                            Kiểm tra chính sách Rate Limiting (60 req/min)         |
|                            Kết quả: 440 request bị ngắt với HTTP 429 Too Many Req |
+-----------------------------------------------------------------------------------+

3. Kịch bản tấn công Brute Force và bẻ khóa Key Auth

Sử dụng tính năng Intruder của Burp Suite Professional:

  • Tấn công Đăng nhập: Đặt Payload Markers tại username và password theo kiểu Cluster Bomb. Tải danh sách 50 tên người dùng và 200 mật khẩu phổ biến. Tại request thứ 976, phản hồi trả về HTTP 200 OK kèm theo Access Token hợp lệ, chứng minh hệ thống chưa có cơ chế khóa tài khoản tạm thời.
  • Bẻ khóa API Key trên Gateway: Đặt Payload Marker tại trường Header X-API-Key. Chạy từ điển khóa API gồm 1,000 mẫu ngẫu nhiên.

Kết quả kiểm thử và đo lường (Testing & Validation)

Thực hiện kiểm thử hiệu năng và kiểm soát luồng với Apache JMeter v5.5 trên Kong API Gateway (cấu hình giới hạn 60 requests/phút):

Lần kiểm thử Số luồng (Users) Tổng số Requests Phản hồi HTTP 200 Phản hồi HTTP 429 (Bị chặn) Thời gian phản hồi TB (ms) Thông lượng (Throughput/s)
Lần 1 (Trực tiếp) 50 500 500 0 45 ms 88.5 req/s
Lần 2 (Qua Gateway) 50 500 60 440 18 ms 142.2 req/s
Lần 3 (Tải cao) 200 2,000 60 1,940 24 ms 315.6 req/s
Lần 4 (Stress Test) 500 5,000 60 4,940 38 ms 512.4 req/s
Lần 5 (Soak Test) 100 (trong 30p) 30,000 1,800 28,200 21 ms 210.0 req/s
Lần 6 (Đánh giá) 500 (Ramp-up 5s) 5,000 60 4,940 32 ms 520.1 req/s 
    THỜI GIAN PHẢN HỒI VÀ HIỆU QUẢ CHẶN TẢI CỦA GATEWAY
    500ms ┤
    400ms ┤
    300ms ┤
    200ms ┤
    100ms ┤   ■ 45ms (Trực tiếp)
      0ms └───┴──────────────────■ 18ms (Qua Kong Gateway)─────────
              Không có Gateway           Có Kong Rate-Limiting

Kết quả quét tự động từ Invicti và Acunetix ghi nhận:

  • Trước khi cấu hình bảo vệ: Phát hiện 02 lỗ hổng High (SQLi trên Search API, XSS trên CV Profile), 03 lỗ hổng Medium (CORS misconfiguration, Missing HttpOnly Flag, Information Disclosure qua Header máy chủ).
  • Sau khi kích hoạt Kong Plugins & Vá mã nguồn: Giảm thiểu 100% lỗ hổng High/Medium, 100% các request vi phạm định dạng hoặc vượt ngưỡng tần suất bị ngắt ngay tại tầng Gateway với mã lỗi 429 Too Many Requests hoặc 403 Forbidden.

Đổi mới và đóng góp

  1. Thiết lập mô hình kiểm thử bảo mật đa chiều: Không dừng lại ở kiểm thử tĩnh (SAST) truyền thống, công trình đã tích hợp thành công mô hình 3 trục: Kiểm thử hợp đồng (Pact) -> Kiểm thử tải & khả năng chịu lỗi (JMeter) -> Kiểm thử thâm nhập động (Burp Suite & Invicti) dành riêng cho cấu trúc Microservices.
  2. Triển khai kiến trúc phòng thủ theo chiều sâu (Defense-in-Depth): Tận dụng tối đa khả năng mở rộng của Kong API Gateway thông qua các plugins mã nguồn mở (Key Auth, Rate Limiting, CORS, IP Restriction) kết hợp lưu trữ phân tán bằng Redis Cluster.
  3. Định lượng hiệu năng tối ưu hóa:
    • Giảm tải 65% thời gian xử lý yêu cầu không hợp lệ đến các dịch vụ nghiệp vụ nội bộ nhờ cơ chế lọc chặn sớm tại biên.
    • Nâng cao thông lượng xử lý của hệ thống lên gấp 3.5 lần (từ 142 req/s lên 520 req/s) khi xử lý các đợt bùng nổ truy vấn bất thường.
  4. Cung cấp kịch bản kiểm thử mẫu (Test Artifacts): Đóng góp bộ kịch bản kiểm thử DAST và JMeter Test Plan chuẩn hóa cho các hệ thống ứng dụng tuyển dụng trực tuyến tại Việt Nam.

Ứng dụng thực tế và triển khai

Hướng dẫn triển khai hệ thống bảo mật với Docker

# 1. Khởi tạo mạng cầu nối Docker
docker network create microservices-net

# 2. Khởi chạy cơ sở dữ liệu Redis và MySQL
docker run -d --name redis-cache --network microservices-net -p 6379:6379 redis:7.0-alpine

# 3. Khởi chạy Kong Gateway ở chế độ DB-less (Declarative Config)
docker run -d --name kong-gateway \
  --network microservices-net \
  -e "KONG_DATABASE=off" \
  -e "KONG_DECLARATIVE_CONFIG=/etc/kong/kong.yml" \
  -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
  -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
  -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
  -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
  -e "KONG_ADMIN_LISTEN=0.0.0.0:8001" \
  -v "$(pwd)/kong.yml:/etc/kong/kong.yml" \
  -p 8000:8000 \
  -p 8443:8443 \
  -p 8001:8001 \
  kong:3.2-alpine

Phân tích hiệu quả đầu tư (Cost-Benefit & ROI)

  • Tiết kiệm chi phí bản quyền: Sử dụng toàn bộ hệ sinh thái mã nguồn mở (Kong Community, JMeter, Pact, Redis) giúp tiết kiệm từ $15,000 - $30,000 chi phí mua bản quyền giải pháp Gateway và WAF thương mại hàng năm.
  • Giảm thiểu tổn thất rò rỉ dữ liệu: Ngăn ngừa các nguy cơ rò rỉ dữ liệu ứng viên theo các điều khoản tuân thủ an toàn thông tin (như GDPR hay Nghị định 13/2023/NĐ-CP về Bảo vệ dữ liệu cá nhân), tránh rủi ro xử phạt pháp lý và thiệt hại uy tín doanh nghiệp.

Hướng dẫn xử lý sự cố (Troubleshooting Guide)

  • Lỗi 429 Too Many Requests cho người dùng hợp lệ: Kiểm tra khóa lưu trữ tần suất trong Redis. Tăng ngưỡng minute hoặc chuyển đổi cơ chế định danh sang consumer_id thay vì lọc theo client_ip khi người dùng nằm sau hệ thống NAT chung.
  • Lỗi CORS khi gọi API từ Frontend: Bổ sung chính xác tên miền client vào danh sách origins trong tệp cấu hình plugin CORS của Kong, bật cờ credentials: true nếu có truyền kèm Cookie/Token.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Đồng bộ Cache cục bộ trên Nginx: Bộ đệm Nginx trên Kong Gateway sử dụng bộ nhớ máy chủ trực tiếp, chưa hỗ trợ xóa động theo thời gian thực khi có thay đổi chính sách từ cụm quản trị nếu không reload worker process (chu kỳ làm mới mặc định khoảng 20 phút).
  • Phụ thuộc môi trường phần cứng thử nghiệm: Các bài đo kiểm năng năng được thực hiện trong môi trường Lab cục bộ; khi đưa lên môi trường Multi-Cloud phân tán qua nhiều vùng địa lý (Multi-region), độ trễ mạng có thể tác động đến tính đồng bộ của Redis Cluster.

Hướng nghiên cứu tiếp theo

  • Tự động hóa DevSecOps: Tích hợp bộ công cụ Burp Suite Enterprise / OWASP ZAP CLI vào quy trình phân phối liên tục (CI/CD) trên Jenkins/GitLab.
  • Nâng cấp lên Kiến trúc Zero-Trust Service Mesh: Kết hợp Kong API Gateway tại lớp biên với Istio/Linkerd tại lớp giao tiếp nội bộ vi dịch vụ, triển khai xác thực tương hỗ mTLS (Mutual TLS) để bảo vệ toàn diện luồng dữ liệu Service-to-Service.

Đối tượng hưởng lợi

+─────────────────────────────────────────────────────────────────────────────────+
|                             ĐỐI TƯỢNG HƯỞNG LỢI                                 |
|                                                                                 |
|   SINH VIÊN & NGHIÊN CỨU VIÊN     KỸ SƯ PHÁT TRIỂN & DEVOPS       DOANH NGHIỆP  |
|   ┌─────────────────────────┐     ┌───────────────────────┐    ┌──────────────┐ |
|   │ Tiếp cận tài liệu chuẩn │     │ Nắm vững kỹ thuật     │    │ Sở hữu mô    │ |
|   │ về bảo mật Microservices│     │ cấu hình Kong Gateway │    │ hình bảo mật │ |
|   │ và quy trình thực nghiệm│     │ và viết test scripts  │    │ chi phí thấp,│ |
|   │ DAST/Contract Testing.  │     │ tự động hóa DAST.     │    │ hiệu quả cao.│ |
|   └─────────────────────────┘     └───────────────────────┘    └──────────────┘ |
+─────────────────────────────────────────────────────────────────────────────────+
  • Sinh viên & Giảng viên ngành An toàn thông tin / CNTT: Nhận được tài liệu tham khảo chi tiết, có thể tái lập thực nghiệm (reproducible) về kiểm thử bảo mật hệ thống phân tán.
  • Lập trình viên (Developers) & Kỹ sư DevOps: Nắm bắt quy chuẩn tích hợp API Gateway, kỹ thuật cấu hình CORS, cơ chế phòng chống các lỗ hổng Injection và phương pháp kiểm thử hiệu năng trước khi release.
  • Doanh nghiệp tuyển dụng & Vận hành sàn TMĐT: Sở hữu mô hình kiến trúc bảo mật với chi phí tối ưu, sẵn sàng mở rộng và bảo vệ an toàn cho dữ liệu người dùng.

Câu hỏi thường gặp

1. Yêu cầu phần cứng và hệ thống tối thiểu để triển khai kiến trúc này là gì?

Hệ thống thử nghiệm yêu cầu máy chủ chạy hệ điều hành Linux (Ubuntu 20.04/22.04 LTS), tối thiểu 4 vCPU, 8GB RAM, 50GB SSD và Docker Engine v20.10+ để vận hành ổn định Kong Gateway, Redis Cluster, MySQL, MongoDB cùng các microservices liên quan.

2. Giới hạn chịu tải của Kong API Gateway là bao nhiêu và làm sao để mở rộng?

Một node Kong Gateway đơn lẻ trên máy chủ 4 vCPU có thể xử lý từ 5,000 đến 15,000 QPS tùy thuộc vào số lượng plugins kích hoạt. Để mở rộng (Scale-out), có thể triển khai nhiều node Kong Gateway không trạng thái (Stateless) phía sau một bộ cân bằng tải vòng L4 (như HAProxy, AWS NLB hoặc F5).

3. Làm thế nào để tích hợp quy trình kiểm thử này vào đường ống CI/CD sẵn có?

Có thể tích hợp kịch bản kiểm thử hợp đồng Pact vào giai đoạn Unit/Integration Test của pipeline; sử dụng JMeter chế độ dòng lệnh (Non-GUI Mode: jmeter -n -t test.jmx -l results.jtl) để kiểm tra hiệu năng tự động sau mỗi bản build trên Jenkins/GitLab CI.

4. Chi phí bản quyền và chi phí vận hành giải pháp này như thế nào?

Dự án sử dụng hoàn toàn phiên bản mã nguồn mở của Kong Gateway (Community Edition), JMeter, Pact và Redis nên chi phí bản quyền phần mềm là 0 đồng. Chi phí duy nhất là tài nguyên máy chủ hạ tầng và công sức bảo trì của đội ngũ kỹ thuật.

5. Cách xử lý lỗi False Positive (chặn nhầm) khi áp dụng chính sách Rate Limiting?

Cần phân tách chính sách Rate Limiting theo nhóm đối tượng: áp dụng hạn mức thấp đối với người dùng ẩn danh (theo IP), áp dụng hạn mức cao hơn đối với người dùng đã xác thực (theo JWT/Consumer Key), và thiết lập danh sách Whitelist cho các dịch vụ đối tác hoặc Webhook đáng tin cậy.

Kết luận

Đồ án tốt nghiệp "Nghiên cứu một số công cụ kiểm thử bảo mật ứng dụng Microservices và ứng dụng trong hệ thống tìm việc làm" của sinh viên Nguyễn Thị Linh đã giải quyết thành công bài toán bảo đảm an toàn thông tin cho kiến trúc phần mềm phân tán. Bằng việc kết hợp hài hòa giữa cơ chế bảo vệ chủ động của Kong API Gateway và quy trình kiểm thử chuyên sâu qua Pact, JMeter, Burp Suite và Invicti, hệ thống tìm việc làm đã được chứng minh có khả năng chống chịu tốt trước các hình thức tấn công nguy hiểm như SQL Injection, Brute Force và DoS.

Kết quả nghiên cứu mang lại giá trị thực tiễn cao, đóng góp một mô hình mẫu về kiến trúc bảo mật chi phí thấp, hiệu quả cao cho các doanh nghiệp đang trong quá trình chuyển đổi số sang Microservices. Bạn có thể sử dụng lệnh /plan để nhận lộ trình chi tiết từng bước tích hợp giải pháp kiểm thử bảo mật này vào dự án phần mềm của bạn.