在所有 API 流量前部署 API 閘道
Putting an API gateway in front of everything
Andika 以運行於 Nginx 上的 Kong 作為 API 流量的統一入口,在流量抵達服務前集中執行安全政策。這種做法可統一認證要求、速率限制、請求限制和存取規則,並配合監測 API 活動及基礎設施狀況提升可視性。代價是閘道會成為單一故障點並增加延遲,需妥善處理冗餘及政策更新部署。
As a product grows past a handful of endpoints, API security stops being a feature of individual services and starts being an architectural question. Where do policies live? Who enforces them? How do you know the same rules apply to endpoint number fifty as to endpoint number five?
Our answer, on Andika, was to put an API gateway in front of everything: Kong, running on top of Nginx, as the single entry layer for API traffic before it reaches our services.
What a gateway actually buys you
It's tempting to see a gateway as a fancy reverse proxy. The real value is centralisation of policy:
- One enforcement point. Authentication expectations, rate limits, request constraints, and access rules are applied consistently, before traffic touches application code. A service behind the gateway doesn't each have to reinvent its own perimeter.
- One place to change the rules. When a policy needs tightening, you change it once. You don't go on a scavenger hunt through a dozen services hoping you found every copy of the logic.
- Reduced blast radius for sloppy requests. Malformed, unauthorized, or abusive traffic gets stopped at the edge, where it's cheap to reject, rather than deep in the system, where it's expensive.
The other half: visibility
Blocking bad traffic is only half the job. The other half is seeing what's happening at all.
We paired the gateway with monitoring across API activity and infrastructure behaviour, because policies without observation are just hopes. Watching traffic patterns at the edge is what lets you notice a credential-stuffing attempt as a shape in the data rather than as a postmortem. Earlier detection is the difference between "we rate-limited an odd burst" and "we found out from a user."
The honest trade-off
A gateway is also a single point of failure and a latency hop, and pretending otherwise is how architectures get cargo-culted. You take on operating it properly: redundancy, careful rollout of policy changes, and accepting that every request pays a small toll at the door.
For us, the trade is worth it. Centralised, consistently applied policy plus real visibility beats a scattered set of per-service defences that drift out of sync with each other over time. Security posture you can reason about beats security posture you merely assume.
This post was adapted, with AI assistance, from an article on the Andika blog, where we build a collaborative writing and knowledge platform.
來源:DEV Community · dev.to