A company is running a publicly accessible serverless application that uses Amazon API Gateway and AWS Lambda. The application’s traffic recently spiked due to fraudulent requests from botnets.
Which steps should a solutions architect take to block requests from unauthorized users? (Choose two.)
To block requests from unauthorized users in a publicly accessible serverless application using Amazon API Gateway and AWS Lambda, creating a usage plan with an API key ensures that only genuine users with the key can access the API. This adds an initial layer of protection by restricting access to those possessing the key. Additionally, implementing an AWS WAF rule specifically targets and filters out malicious requests, providing a dynamic and robust way to identify and block botnet traffic. These combined measures effectively help in mitigating the risk from unauthorized users.
C) WAF has bot identification and remedial tools, so it's CORRECT. A) remember the question : "...block requests from unauthorized users?" -- an api key is involved in a authorization process. It's not the more secure process, but it's better than an totoally anonymous process. If you don't know the key, you can't authenticate. So the bots, at least the first days/weeks could not access the service (at the end they'll do, cos' the key will be spread informally). So it's CORRECT. B) Implement a logic in the Lambda to detect fraudulent ip's is almost impossible, cos' it's a dynamic and changing pattern that you cannot handle easily. D) creating a rol is not going to imply be more protected from unauth. request, because a rol is a "principal", it's not involved in the authorization process.
E "An IAM role for EACH (!) user ATTEMPTING (!) to access the API"? Hello no.
Don't use API keys for authentication or authorization to control access to your APIs. If you have multiple APIs in a usage plan, a user with a valid API key for one API in that usage plan can access all APIs in that usage plan. Instead, to control access to your API, use an IAM role, a Lambda authorizer, or an Amazon Cognito user pool.
Agree A and C I don't see how E is feasible as its a public API. How would you create an IAM role for each user?
Only answer C is an obviouis choice. B and D are clearly not right and A is the only remotely viable other answer but even then the documentation on API Keys and Usage quotas states not to rely on it to block API requests; Usage plan throttling and quotas are not hard limits, and are applied on a best-effort basis. In some cases, clients can exceed the quotas that you set. Don’t rely on usage plan quotas or throttling to control costs or block access to an API. Consider using AWS Budgets to monitor costs and AWS WAF to manage API requests. https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-usage-plans.html
https://www.examtopics.com/discussions/amazon/view/61082-exam-aws-certified-solutions-architect-associate-saa-c02/
I'm thinking A and C A - the API is publicly accessible but there is nothing to stop the company requiring users to register for access. B - you can do this with Lambda, AWS Network Firewall and Amazon GuardDuty, see https://aws.amazon.com/blogs/security/automatically-block-suspicious-traffic-with-aws-network-firewall-and-amazon-guardduty/, but these components are not mentioned C - a WAF is the logical choice with it's bot detection capabilities D - a private API is only accessible within a VPC, so this would not work E - would be even more work than A
A/C for security to prevent anonymous access
The combination of using an API key and implementing an AWS WAF rule provides the most comprehensive and effective way to block requests from unauthorized users and protect the company's serverless application from botnet attacks.
I'll throw a curveball over here. "C" is a given as WAF rules can target malicious usage. For example: https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/aws-waf-ip-reputation.html "D" Convert existing public API to a private API. This part is same as A. The additional bit over here is to change the DNS record to a new API endpoint which blocks the requests from unauthorised users also. The unauthorised users will not be redirected from public to private API endpoint. I am assuming that the public API endpoint will be used for authorisation and only authorised users will be redirected to private endpoint. This is more robust as the actual API (private endpoint) never gets hit with requests from unauthorised bots and WAF redirects it back to public URL. Happy to be corrected and challenged
It's a globally published API if you make it private how do other people access it ? A would be the better solution than D
A and C
I do not agree with A as it mentioned the application is publically accessible. "A company is running a publicly accessible serverless application that uses Amazon API Gateway and AWS Lambda". If this is public how can we ensure that genuine user? I will go with CD
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-usage-plans.html https://medium.com/@tshemku/aws-waf-vs-firewall-manager-vs-shield-vs-shield-advanced-4c86911e94c6
If you're wondering why A. It's because you can configure usage plans and API keys to allow customers to access selected APIs, and begin throttling requests to those APIs based on defined limits and quotas. As for C. It's because AWS WAF has bot detection capabilities.
Why option C) vs option E) - It's simpler - We want to protect general access to the API and not granular method/user access. The API is already public so If a user API key is in several usage plans that is not a problem (The API is currently public). The objective is to protect API from abuse from malicious internet users and to NOT protect granular method/user access from users that are using the API in the correct way.
The reasons are: An API key with a usage plan limits access to only authorized apps and users. This prevents general public access. WAF rules can identify and block malicious bot traffic through pattern matching and IP reputation lists. Together, the API key and WAF provide preventative and detective controls against unauthorized requests. The other options add complexity or are reactive. IAM roles per user is not feasible for a public API. Ignoring requests in Lambda and changing DNS are response actions after an attack.
Do the people voting E realize how insane that is? Creating a local IAM user in your account for every user that needs to access the API. No just... no.
use usage plan API key
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-usage-plans.html
A and C ,C is obivious ,however A is the only other which seems to put quota API keys are alphanumeric string values that you distribute to application developer customers to grant access to your API. You can use API keys together with Lambda authorizers, IAM roles, or Amazon Cognito to control access to your APIs
It should be A and C But API Key alone can not help API keys are alphanumeric string values that you distribute to application developer customers to grant access to your API. You can use API keys together with Lambda authorizers, IAM roles, or Amazon Cognito to control access to your APIs.
Important Don't use API keys for authentication or authorization for your APIs. If you have multiple APIs in a usage plan, a user with a valid API key for one API in that usage plan can access all APIs in that usage plan. Instead, use an IAM role, a Lambda authorizer, or an Amazon Cognito user pool.
AC it's essential to note that while API keys are commonly associated with private APIs, they can also be used in conjunction with public APIs. In some cases, even public APIs may require API keys to control usage and monitor how the API is being utilized. The API provider might enforce usage limits, track API usage, or monitor for potential misuse, all of which can be managed effectively using API keys. In summary, API keys are not exclusive to private APIs and can be used for both private and public APIs, depending on the specific requirements and use case of the API provider.
C) WAF has bot identification and remedial tools, so it's CORRECT. A) remember the question : "...block requests from unauthorized users?" -- an api key is involved in a authorization process. It's not the more secure process, but it's better than an totoally anonymous process. If you don't know the key, you can't authenticate. So the bots, at least the first days/weeks could not access the service (at the end they'll do, cos' the key will be spread informally). So it's CORRECT.
C and D are the perfect answers
AC for sure
C) Everyone agrees on C B) Almost impossible cos how do you detect fraudulent IP address from a publicly accessible application D) It's a publicly accessible application, converting the API to a private one defeats the purpose E) IAM role for each user trying to access a publicly accessible API is impossible. It like creating an IAM for each user that tries to use google AUTH for their website A) By implementing API keys and usage plans, you can restrict access to your API to only those users who possess the key, helping to limit fraudulent access.
but i think both option A and E imply that the api access actually have a targeted user if A is possible, why cant E be an apporach?
Ans A, C - A: using API keys and usage plans restricts access to your API to users who have the key, limiting fraudulent access. C: designed to fight bots
A and C
A and C are the correct choices.
A and C
Here https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-usage-plans.html it says this: Don't use API keys for authentication or authorization for your APIs. If you have multiple APIs in a usage plan, a user with a valid API key for one API in that usage plan can access all APIs in that usage plan. Instead, use an IAM role, a Lambda authorizer, or an Amazon Cognito user pool. API keys are intended for software developers wanting to access an API from their application. This link then goes on to say an IAM role should be used instead.
Nevermind my answer. I switch it to A/C because the question states the application is *using* the API Gateway so A will make sense
AWS WAF rule to target and filter out malicious requests and API key to authorize users.
A. Create plans using API keys shared only with real users: While using API keys is a standard way to control access to APIs, using API keys alone may not completely prevent attacks from botnets. Malicious request. B. Incorporate logic in the Lambda function to ignore requests from fraudulent IP addresses: This may be a solution, but filtering that relies more on IP addresses may not be as flexible as using AWS WAF. D. Convert an existing public API to a private API. Update DNS records to redirect users to the new API endpoint: This approach makes the API private, but requires user redirects and may inconvenience existing users.
Don't use API keys for authentication or authorization to control access to your APIs. If you have multiple APIs in a usage plan, a user with a valid API key for one API in that usage plan can access all APIs in that usage plan. Instead, to control access to your API, use an IAM role, a Lambda authorizer, or an Amazon Cognito user pool.
B. Integrate logic within the Lambda function to ignore the requests from fraudulent IP addresses. -> you can think about CORS script write on Lambda to prevent fraudulent IP addresses. C. Implement an AWS WAF rule to target malicious requests and trigger actions to filter them out. -> No comment here as it can use to filter traffic
AC is right answer.
Wrong choices: B-> Integrating logic in lambda is not feasable as you will have to feed data which will increase its size, execution time and therefore overall cost. D-> If it happens then the public will not be able to access it as it is private only clients inside VPC will be abe to access it. E-> You are just giving them access