Implementing Secure Third-Party Payment Integration for Oracle Cloud Infrastructure (OCI) Instances
Question
You work as a solutions architect for an online retail store creating a portal to allow the users to pay for their groceries using credit cards.
Since the application is not fully compliant with the Payment Card Industry Data Security Standard (PCI DSS), your company is looking to use a third-party payment service to process credit card payments.
The third-party service allows a maximum of 5 public IP addresses at a time.
However, your website is using Oracle Cloud Infrastructure (OCI) Instance Pool Auto Scaling policy to create up to 15 instances during peak traffic demand, which are launched in VCN private subnets and attached to an OCI public Load Balancer.
Upon user payment, the portal connects to the payment service over the Internet to complete the transaction What solution can you implement to make sure that all 15 compute instances can connect to the third party system to process the payments during peak traffic demand? (Choose the best answer.)
Answers
Explanations
Click on the arrows to vote for the correct answer
A. B. C. D.B.
The best solution to make sure that all 15 compute instances can connect to the third party system to process the payments during peak traffic demand is Option A: Route credit card payment request from the compute instances through the NAT Gateway. On the third-party services, whitelist the public IP associated with the NAT Gateway.
Explanation:
PCI DSS requires that credit card information be protected at all times. It is important to ensure that the credit card information is secure during the transaction and during storage. It is recommended to use a third-party payment service to process credit card payments because these services are usually PCI DSS compliant.
The third-party payment service used in this scenario allows a maximum of 5 public IP addresses at a time. However, the application is using an Instance Pool Auto Scaling policy to create up to 15 instances during peak traffic demand. This means that the compute instances that are launched will be more than the maximum allowed by the payment service.
Option A is the best solution to overcome this problem. In this solution, the payment request is routed from the compute instances through the Network Address Translation (NAT) Gateway. The NAT Gateway provides internet access to instances in the private subnet. The NAT Gateway will use one of the 5 public IP addresses provided by the payment service, and all compute instances will use this public IP address to communicate with the payment service.
To ensure that the payment service only accepts requests from the allowed public IP addresses, the public IP address associated with the NAT Gateway is whitelisted on the payment service. This way, all compute instances can connect to the payment service using the same public IP address, which will ensure that the payment service only receives requests from the allowed IP addresses.
Option B is not a feasible solution because the payment service allows a maximum of 5 public IP addresses, and reserving a public IP address for each compute instance will exceed the maximum allowed by the payment service.
Option C is not a feasible solution because it involves routing all payment requests through the Internet Gateway. This will create a single point of failure and will also increase latency.
Option D is not a feasible solution because routing payment requests through the OCI Load Balancer will not ensure that all compute instances can connect to the payment service. The payment service only allows a maximum of 5 public IP addresses, and the load balancer may route requests through different IP addresses each time, which will exceed the maximum allowed by the payment service.
