Regulated payment platform: closing exposure and proving regional recovery
Northwind Payments runs a three-tier card-authorization platform in the Frankfurt region: an internet-facing web tier, a private Java app tier on 40 VM.Standard.E4.Flex instances, and Oracle Base Database Service with a 6 TB primary. The regulator requires that database traffic never traverse the public internet, customer-managed encryption keys be rotated at least every 90 days, and recovery from a regional failure within 1 hour with no more than 15 minutes of data loss. Today the VCN has one public subnet for everything, the database has a public IP, and backups are manual to a bucket in the same region. Security also wants administrative access without exposing SSH. The team has no cross-region DR runbook and uses a single Vault key created 14 months ago. Traffic peaks at 3,000 requests per second; the web tier is behind an OCI Load Balancer.
1. Prioritize the architecture gaps in the current design and map each to an OCI control that closes it. Explain why the order matters for the regulator.
Read the worked answer
The first gap is database exposure. A public IP and a shared public subnet mean the database listener sits on an internet-reachable path, which directly conflicts with the no-public-traffic rule. Move the DB system to a private subnet with no public IP, attach an NSG that permits 1521 only from the app-tier NSG, and remove the internet gateway route from that subnet. Administrative access should use OCI Bastion service sessions instead of SSH ingress.
The second gap is segmentation. One public subnet for all tiers collapses the trust boundary. Build a public load-balancer subnet, private app subnets across ADs, and private DB subnets. Put OCI WAF in front of the load balancer; DDoS protection remains at the edge. Use NSGs per tier rather than broad security lists. Add a service gateway for Object Storage and a NAT gateway only for app patching, so private workloads do not need general internet egress.
The third gap is key hygiene. A single 14-month-old key violates the 90-day rotation rule. Use OCI Vault with a virtual private vault, separate key administrators from crypto users in IAM, enable key-version rotation, and plan re-encryption where required. Audit key usage.
Fourth is recovery. Same-region manual backups cannot survive a regional failure. Add Data Guard to a second region and replicate backups. The order matters because exposure and segmentation are immediate regulatory violations; key hygiene and DR are mandatory but follow containment.
2. Design the target network and recovery architecture for RPO 15 minutes and RTO 60 minutes. Specify subnets, gateways, replication, DNS failover, and the operational runbook.
Read the worked answer
Use a Frankfurt VCN with three tiers. The public subnet contains only the OCI Load Balancer and WAF; it has an internet gateway. Private app subnets span ADs and route outbound patching through a NAT gateway. Private DB subnets have no internet route. A service gateway provides private access to Object Storage for backups and application assets. NSGs enforce app-to-DB and LB-to-app flows; security lists remain coarse fallbacks.
On the database, run the primary in Frankfurt and a Data Guard standby in a second region such as Amsterdam. Use asynchronous redo transport with broker-managed fast-start failover; asynchronous replication can meet a 15-minute RPO while avoiding cross-region commit latency. Replicate backups to the standby region so recovery does not depend on the primary region. Pre-provision the standby network, load balancer, and app capacity, or use infrastructure-as-code to rebuild them quickly.
For RTO, the slow part is usually DNS and application cutover, not database activation. Use OCI DNS failover with health checks or a steering policy, and document a tested sequence: declare disaster, stop application writes, fail over Data Guard, validate database, repoint DNS, start app tier, verify transactions. Run a quarterly game day and record actual RTO. Without testing, a 60-minute target is a hope, not a control.
3. How should Vault keys and administrative access be governed so that the payment team cannot bypass the regulator's controls?
Read the worked answer
Separate duties in IAM. A small security group manages vaults and keys; application and database groups get only crypto-user permission to use specific keys for specific resources. Do not give manage vaults or manage keys to the platform team. Use a virtual private vault for dedicated HSM protection, enable key-version rotation, and record the rotation date. When rotating, create a new key version, re-encrypt data or switch the resource to the new version, then disable the old version after validation. Keep an inventory mapping each database and bucket to its key and owner.
For administration, remove SSH ingress and public IPs from database and app hosts. Use OCI Bastion service sessions with time-bound sessions, or a private jump host managed by a privileged-access group. Enforce MFA at the identity provider for all administrators. Keep one break-glass local administrator in the default identity domain, with MFA, no API keys, and alerting on use. Grant production database SYSDBA only through a controlled group and require a ticket reference in the session audit.
Finally, send Audit logs and Vault usage to a central logging bucket with retention beyond the regulatory minimum. Alert on key disablement, policy changes, and bastion sessions to production. Governance works only when the same team cannot both change the key policy and use the key without independent review.