如何在共享软件包中限制API Gateway及AWS Lambda的访问权限

Hey, let's break down how to solve this problem properly—embedding IAM keys in your shared package is a big no-go, so we need smarter ways to lock down that API Gateway while only letting legitimate users of your software access it.

1. Use Temporary STS Credentials Instead of Long-Term Keys #

Ditch the embedded IAM access keys entirely. Instead, build a lightweight "credential service" in your infrastructure that issues short-lived STS credentials to your software package. Here's how it works:

• Your software first sends a request to this credential service, including some form of proof that it's a legitimate user (like a valid software license key, device fingerprint tied to your user's account, or a token from your app's authentication flow).
• Your credential service validates this proof, then uses an IAM role to generate temporary credentials with only the permissions needed to call your API Gateway (follow the principle of least privilege!).
• The software package uses these temporary credentials to make API requests. Since they expire automatically (you can set the TTL to as short as 15 minutes), even if they're leaked, the window of risk is tiny.

2. Implement a Custom Authorizer for API Gateway #

Instead of relying on IAM directly, set up a custom authorizer (also called a Lambda authorizer) for your API Gateway. This lets you control access with your own logic:

• Your software package generates a unique authorization token for each API request. This token should be signed with a secret that's stored in your backend (never in the software package!)—use something like HMAC-SHA256, combining request details (timestamp, path) with the secret to prevent tampering.
• When the request hits API Gateway, the custom authorizer Lambda function grabs this token, sends it to your backend for validation, and checks if the request comes from a legitimate user of your software.
• If validation passes, the authorizer returns an IAM policy that allows the request; otherwise, it rejects it. This way, your API Gateway stays closed to unauthenticated traffic, and you don't expose any long-term credentials in the package.

3. Proxy Requests Through Your Backend Service #

For the highest level of control, have your software package send requests to your own backend service first, then let your backend forward the request to the API Gateway. Here's why this works:

• Your API Gateway can be configured to only accept traffic from your backend's IP range or VPC—completely locking it down from the public internet.
• Your backend uses an IAM role (no embedded keys!) to authenticate with the API Gateway.
• You can add extra checks in your backend: validate the user's license, enforce rate limits, or sanitize requests before forwarding them. The downside is that you'll need to scale your backend to handle the traffic, but it's the most secure option if your API traffic isn't massive.

Key Best Practices #

• Always follow the principle of least privilege: Never grant more permissions than necessary (e.g., STS credentials should only allow access to your specific API endpoints, not all AWS services).
• Obfuscate your software package's code to make it harder for attackers to reverse-engineer your credential or token generation logic.
• Add rate limiting to any credential service or backend proxy to prevent abuse.

内容的提问来源于stack exchange，提问作者Jorjani