Hôm qua tôi nhận cuộc gọi từ một startup ở TP.HCM: họ vừa phát hiện một nhân viên tạm thời vô tình commit một API key production vào GitHub. Khoảng 45 phút sau đó, một attacker ở Trung Quốc đã dùng key đó để spam 5 triệu requests, gây tổn hại khoảng 200 triệu đồng. Họ không có microservices lúc đó, nhưng nếu có thì vấn đề sẽ còn tệ hơn gấp mười lần.
Đó chính là điều khó hiểu khi bạn xây dựng kiến trúc microservices: mỗi service có cơ chế authentication riêng, mỗi cái lại có thể bị compromise độc lập. Bạn không chỉ phải lo HTTP request từ client bên ngoài, mà còn phải lo service A gọi service B, service B gọi service C... Một lỗi nhỏ ở endpoint nào đó, và toàn bộ chuyên chế sụp đổ.
Vấn đề thực tế không ai muốn nói ra
Trong thực tế, hầu hết các công ty Việt Nam xây dựng microservices mà tôi từng thấy đều có chung một vấn đề: họ quăng tất cả API keys vào .env file, share docker-compose.yml cho cả team, và hy vọng rằng "chưa bao giờ xảy ra vấn đề thì không cần lo". Đó là cách suy nghĩ sai lầm. Thống kê từ Gartner cho thấy 70% security incidents trong các hệ thống microservices liên quan đến authentication hoặc authorization bị sơ hở.
Khi bạn có 20 services, 5 API gateways, và mỗi cái đều cần xác thực với các cái khác, bạn đang chơi với lửa mà không biết. Một cách tiếp cận "brute force" là hardcode credentials ở mọi nơi—nhưng đó chính là cách khiến cơ sở dữ liệu của bạn bị leak lên Pastebin một ngày nào đó.
JWT: Vũ khí phổ biến nhất (và những hạn chế của nó)
JWT được công bố năm 2015 và nhanh chóng trở thành chuẩn de facto. Nó đơn giản: client login, nhận một token, gửi token đó trong header Authorization cho mọi request. Mỗi service có thể verify token mà không cần gọi authorization server. Tuyệt vời, phải không?
Nhưng thực tế không hề đơn giản. JWT có một vấn đề lớn: nó không thể bị revoke ngay lập tức. Nếu một user logout, token của họ vẫn còn hợp lệ cho đến khi nó expire. Nếu một employee bị sa thải, token của họ sẽ hoạt động tới cuối ngày nếu bạn đặt token expiration là 24 giờ (một lỗi lầm phổ biến ở đây).
Chia sẻ bài viết
Bài viết liên quan
Bạn cần tư vấn về công nghệ?
Đội ngũ Idflow luôn sẵn sàng hỗ trợ bạn trong hành trình chuyển đổi số.
Công ty tôi từng làm việc với một fintech startup. Họ dùng JWT với thời hạn 12 giờ. Một ngày, một kỹ sư lỡ tay leaked API key. Mất 12 giờ, hacker mới bị từng chặn hoàn toàn. Nhân viên khác gọi điện cho CEO nói "dự án sắp phá sản", trong khi CEO chỉ biết ngồi chôn chân. JWT không phải là giải pháp cho mọi trường hợp.
mTLS: Bức tường cao nhất (nhưng cũng phức tạp nhất)
Nếu JWT là "chúng tôi dùng ngòi bút đặc biệt để ký vào token", thì mTLS là "chúng ta dùng chứng chỉ cấp bộ để xác thực lẫn nhau". Mỗi service có một certificate, và khi A gọi B, cả A và B đều verify certificate của nhau.
Trong kiến trúc microservices, mTLS là "best practice" khi service-to-service communication. Không nên sử dụng API key đơn giản hoặc JWT trong môi trường internal. Tuy vậy, mTLS có chi phí: bạn cần một PKI infrastructure (hay một service mesh như Istio), certificate rotation process, và debug cũng khó hơn vì bây giờ bạn không chỉ lo logic mà còn lo certificate.
Một lập trình viên ở công ty tôi từng nói: "mTLS là như lắp một hệ thống camera bảo mật tại nhà mình để đảm bảo vợ không lén ăn dessert". Chính xác. Nó hoạt động, nhưng có lẽ quá phức tạp cho vấn đề ban đầu.
API Gateway: Nơi tất cả điều khác lạ bắt đầu
Khi client bên ngoài gửi request, nó không trực tiếp gọi service của bạn—nó gọi API Gateway trước. API Gateway là người bảo vệ, là người canh gác cổng.
Công cụ như Kong, AWS API Gateway, hay Nginx ngày nay có thể enforce rate limiting, IP whitelisting, API key validation, và OAuth 2.0 integration. Nhưng—và đây là cái "nhưng" lớn—nếu service của bạn không có thêm authentication lớp thứ hai, attacker có thể bypass gateway và gọi service trực tiếp (nếu network cho phép).
Một startup ở Hà Nội tôi biết đã test điều này. Họ có API Gateway tuyệt vời. Nhưng service backend của họ được expose trên port 8080 mà không có rate limiting hoặc authentication. Attacker scan mạng, tìm thấy port 8080, vào được. Bài học: không bao giờ tin rằng network firewall là cơ chế bảo mật duy nhất. Mỗi service phải tự bảo vệ mình.
Những điểm cần chú ý
1Rotate credentials thường xuyên—nếu bạn không rotate API keys mỗi 3-6 tháng, bạn đang chơi một trò chơi nguy hiểm.
1Implement audit logging—bạn cần biết ai gọi service của mình, lúc nào, từ đâu. Nếu cảnh báo không xuất hiện sau 6 tháng, attacker sẽ ngồi yên và hút dữ liệu của bạn.
1Zero-trust architecture: không tin bất kỳ ai, thậm chí internal requests. Verify mọi request.
1Secrets management: dùng Vault, AWS Secrets Manager, hay Kubernetes Secrets. Không để credentials ở trong code.
1Thử tấn công chính mình: penetration testing không phải cao xa. Hire một consultant hoặc dùng công cụ như OWASP ZAP để scan API của bạn.
Bảo mật microservices không phải là một thiết lập rồi quên. Nó là một quá trình liên tục, một mindset. Mỗi service là một điểm yếu tiềm tàng, và kẻ xấu đang chờ bạn ngủ gục.
---
Nếu bạn đang xây dựng hệ thống microservices ở Việt Nam, hãy suy nghĩ cẩn thận về bảo mật từ ngày đầu tiên—một công ty như Idflow Technology sẽ giúp bạn thiết kế đúng cách.